IETF Opus codec now ready for testing, That's CELT 0.11 Options

[jmvalin]

Well, I've mainly tried Opus with electronic music and noticed things like unrelated sounds crushing in, artifacts on snares that made them sound like they were breaking apart (aren't that also pre-echos?) or simply heavy distortions on Hi-Hats and cymbals.

One thing worth checking is whether any of these artefacts are caused by clipping of the decoded values. Recent music is often mastered at such high level that lossy compression will cause some clipping when the output is a 16-bit int (not for float output). So it may be worth checking if a lower input level still causes these problems. If so, then it's something we're interested in fixing.

[jmvalin]

That's simply because that l3enc version (which wasn't even version 1.0!) was buggy and frankly sounded like shit. I seriously doubt that at 64 kbps future Opus encoders will sound much better than the recent experimental branch. Which I haven't actually looked at or listened to, but from what NullC writes here it's already well tested for bugs and quality... which that l3enc version wasn't.

Obviously, the Opus reference implementation isn't crappy enough to have as much room for improvement as l3enc did. That being said, even from the current experimental branch there's still room for significant improvements. The current and experimental encoders still have a bunch of decisions that are made by rough heuristics that can definitely be improved. Feel free to give us a hand on those

[NullC]

Obviously, the Opus reference implementation isn't crappy enough to have as much room for improvement as l3enc did. That being said, even from the current experimental branch there's still room for significant improvements. The current and experimental encoders still have a bunch of decisions that are made by rough heuristics that can definitely be improved. Feel free to give us a hand on those

There are also elements of the format that we don't make use of in the existing encoder— the ability to switch frame sizes, changing the bandpass on a frame by frame basis, or switching frames to straight mono automatically. Nor do we have any analysis that adds latency (at a minimum the pitch-prefilter, transient detection, and coding mode decision could be smarter with more lookahead).

There are also more exotic things that could be done which might have useful payoffs, e.g. non-uniform weighing the codebooks search, analysis on the post-prefilter signal, low rate RDO on the band energy.

This post has been edited by NullC: Aug 9 2012, 03:26

[jmvalin]

Oh, and we just released 1.0.0-rc and 1.0.1-rc. Please give those a try and report any problems so we can fix them for the final releases.

[Gainless]

Would be nice to have a compiled encoder.exe from this.

This post has been edited by Gainless: Aug 9 2012, 09:30

[Garf]

Oh, and we just released 1.0.0-rc and 1.0.1-rc. Please give those a try and report any problems so we can fix them for the final releases.

Would be nice to have a compiled encoder.exe from this.

Something went wrong with that release candidate tar, I think, because it's missing all the stuff to compile with MSVC & Win32 that kode54 and me added.

The stuff in git is fine, that's compiled here: http://www.hydrogenaudio.org/forums/index....showtopic=96416

[NullC]

Would be nice to have a compiled encoder.exe from this.

Nothing changed from the files on the site.

[C.R.Helmrich]

Jean-Marc, Greg, I see. The question is how much quality improvement you can get on top of the current encoder state by exploiting/encoder-tuning every tool the Opus decoder supports. From my experience in tuning Fraunhofer's HE-AAC encoder, the improvement can be quite large for individual items, but is surprisingly small on average over a large test set.

What makes you come to that conclusion?

You know what it is. http://www.hydrogenaudio.org/forums/index....st&p=797609

OK, so you took the original_stereo_concat from that test and encoded it with Winamp's HE-AAC, VBR 2, to compare it against USAC?

If those USAC and HE-AAC encoders were tested in CBR mode how can You explain that your FhG HE-AAC (which I consider as best HE-AAC encoder) VBR ends up with practicaly identical quality?

Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well. And besides, the tested SBR configuration isn't the only possible one (see the discussion on downsampled SBR elsewhere on HA). Anyway, it would be nice if you could post on HA (not in this thread) your test results which made you conclude, "VBR ends up with practicaly identical quality". Not only would this help me find out if my VBR code works suboptimally somewhere, it's also required by TOS#8.

Furthermore the advantage of USAC over HE-AAC is ... 8 kbps. Do You beleive that HE-AAC (64+8) 72 kbps is somehow superior to Opus 64 kbps?

Well, don't know. As you mentioned, which codec does better depends on the audio material. But I hear a significant improvement of HE-AAC 72 kbps over HE-AAC 64 kbps, so I'd say: possibly Btw, where does that 8-kbps rule-of-thumb come from? Is that your own finding?

Consider my post as constructive criticism and not as personal attack.

I do and hope you do the same

Chris

This post has been edited by C.R.Helmrich: Aug 10 2012, 00:54

[IgorC]

OK, so you took the original_stereo_concat from that test and encoded it with Winamp's HE-AAC, VBR 2, to compare it against USAC?

Neither there was a need. It was HE-AAC (the version from a verification test) vs FhG/Winamp HE-AAC (and some other combinations).
I've received the complete package with USAC and HE-AAC samples at all tested bitrates, as well as some additional documentation of verification test.

Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well.

It might be the case. Though there were more than 2 killer samples. Very difficult sample like Castanets, your super-killer Berlin Dug, a lot of trumpets, a lot of tonal samples, mixed samples speech+background noise/music, stereo samples like velvet. It doesn't fit into an easy-to-compress stuff.

Anyway, it would be nice if you could post on HA (not in this thread) ...

It's my personal decision to make publicly available results or not. I have stopped to do that some time ago (with a few exceptions).

Well, don't know. As you mentioned, which codec does better depends on the audio material. But I hear a significant improvement of HE-AAC 72 kbps over HE-AAC 64 kbps, so I'd say: possibly Btw, where does that 8-kbps rule-of-thumb come from? Is that your own finding?

http://www.hydrogenaudio.org/forums/index....st&p=781323
http://www.hydrogenaudio.org/forums/index....st&p=781338

Correct. A more accurate rule of thumb for music and mixed content (not for pure speech) is: USAC at x kbps sounds as good as HE-AAC at x+8 kbps. (Edit: looking at the report Igor linked to, this seems to be roughly true for x >= 16.)

[C.R.Helmrich]

I've received the complete package with USAC and HE-AAC samples at all tested bitrates, as well as some additional documentation of verification test.

Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well.

It might be the case. Though there were more than 2 killer samples. Very difficult sample like Castanets, your super-killer Berlin Dug, a lot of trumpets, a lot of tonal samples, mixed samples speech+background noise/music, stereo samples like velvet. It doesn't fit into an easy-to-compress stuff.

I just listened through the concatenated files, and you're right. It contains a lot of killer samples, basically every sample we used during the development of USAC. I had assumed it contains only the verification items. I guess I'll do my own MUSHRA test with these concatenated files then...

http://www.hydrogenaudio.org/forums/index....st&p=781323
http://www.hydrogenaudio.org/forums/index....st&p=781338

Correct. A more accurate rule of thumb for music and mixed content (not for pure speech) is: USAC at x kbps sounds as good as HE-AAC at x+8 kbps. (Edit: looking at the report Igor linked to, this seems to be roughly true for x >= 16.)

Thanks for reminding me of that post. I had already forgotten about that.

Chris

[Gainless]

Ok, here is one more sample that seems to make problems (with the 1.01 release candidate).

Bombat Sample

There is this sharp sound of some kind of distorted voice on which the encoder introduces noise/distortions. It's especially obvious at 64 kbps, but also noticeable at higher bitrates up to 160 kbps.

[IgorC]

Ok, as NullC suggested I've played a bit around with the CBR mode of Opus (last exp version) and found an even better example at which the VBR mode may exaggerates a bit.

Audio Link

At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg) or even just around 100 kbps (FhG AAC).

Bitrate is only part of story. It's always worthy to check if LAME, Aotuv or FhG decrease bitrate without any audible issues.

My results for this sample:

CODE

ABC/HR for Java, Version 0.53a, 11 August 2012
Testname:

Tester: IgorC

1L = D:\Samples\01_Kick_sample\FhG VBR 5 192 kbps.wav
2L = D:\Samples\01_Kick_sample\48kHz_192kbps_Opus(transients build)_44.1kHz_SoX.wav
3L = D:\Samples\01_Kick_sample\AoTuV VBR q6 192 kbps .wav
4R = D:\Samples\01_Kick_sample\LAME 3.99.5 V2.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Samples\01_Kick_sample\FhG VBR 5 192 kbps.wav
1L Rating: 4.9
1L Comment:
---------------------------------------
2L File: D:\Samples\01_Kick_sample\48kHz_192kbps_Opus(transients build)_44.1kHz_SoX.wav
2L Rating: 4.8
2L Comment:
---------------------------------------
3L File: D:\Samples\01_Kick_sample\AoTuV VBR q6 192 kbps .wav
3L Rating: 4.4
3L Comment: muddy bass. Probably as well as some tine pre-echo
---------------------------------------
4R File: D:\Samples\01_Kick_sample\LAME 3.99.5 V2.wav
4R Rating: 3.5
4R Comment: pre/post echo.
---------------------------------------

ABX Results:

Even such mature codecs like Vorbis and LAME drop bitrate but aslo drop quality. While only FhG AAC (VBR 5 192 kbps) could drop bitrate down to 120 kbps without any audible issues. I'm not sure how it will be easy or difficult to do that for Opus.

Ok, as NullC suggested I've played a bit around with the CBR mode of Opus (last exp version) and found an even better example at which the VBR mode may exaggerates a bit.

Audio Link

At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg) or even just around 100 kbps (FhG AAC).

Agree, CBR 96 kbps was already very good.
It's great sample where Opus could save bitrate. All encoders decrease the bitrate on this sample without any audible issue. FhG AAC (VBR 5 ~192 kbps) shines again, 105 kbps while keeping perfect quality.

Ok, here is one more sample that seems to make problems (with the 1.01 release candidate).

Bombat Sample

There is this sharp sound of some kind of distorted voice on which the encoder introduces noise/distortions. It's especially obvious at 64 kbps, but also noticeable at higher bitrates up to 160 kbps.

It's rather a killer sample itself than a particular issue for 1.0.1. I couldn't find any other lossy codec that makes any better for this sample.
Comparison with HE-AAC:

CODE

ABC/HR for Java, Version 0.53a, 11 August 2012
Testname:

Tester: IgorC

1L = D:\Samples\HA_opus_topic\03 Bombat\Opus_EXP7_Transients_64kbps_resampled_44.1kHz_SoX.wav
2L = D:\Samples\HA_opus_topic\03 Bombat\Opus_1.0.1_64kpbs_resampled_44.1kHz_SoX.wav
3R = D:\Samples\HA_opus_topic\03 Bombat\FHG_VBR3_64kbps.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Samples\HA_opus_topic\03 Bombat\Opus_EXP7_Transients_64kbps_resampled_44.1kHz_SoX.wav
1L Rating: 3.8
1L Comment:
---------------------------------------
2L File: D:\Samples\HA_opus_topic\03 Bombat\Opus_1.0.1_64kpbs_resampled_44.1kHz_SoX.wav
2L Rating: 3.8
2L Comment:
---------------------------------------
3R File: D:\Samples\HA_opus_topic\03 Bombat\FHG_VBR3_64kbps.wav
3R Rating: 3.4
3R Comment:
---------------------------------------

ABX Results:

This post has been edited by IgorC: Aug 11 2012, 20:49

[IgorC]

The first quote of previous post is wrong.
Shoud be

I know that the argumentation "If Vorbis can do it then Opus can do it even better" is not really appropiate in general, I'm mainly talking about the really basic examples where a lot of encoders are behaving similarly.

Here is the kick sample I mentioned.
Kick sample

Tested with a target bitrate of 192 kbps and the difference to other encoders is pretty obvious: While Lame, FhG AAC and Vorbis are using 120-130 kbps in average, Opus is reaching out with 181 kbps.

[Kvanto]

Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?

This post has been edited by Kvanto: Aug 11 2012, 21:57

[saratoga]

Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?

Pretty much anything will be transparent. At those bitrates, you can probably use mp2 just as well.

[eahm]

foobar2000 1.1.14 beta 3 released (http://www.foobar2000.org/download):

Added Opus encoding support in Converter (requires external opusenc.exe binary) (beta 3).

This post has been edited by eahm: Aug 11 2012, 23:06

[jensend]

Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?

Both of these codecs should be basically transparent by the time you reach 192kbps (if not long before). Being able to find a sample where you can hear any difference -in completely ideal circumstances- between either codec at 192kbps and the original would be extraordinarily rare. For the quality of either at 192kbps to be worse than the original by enough to seriously impact your normal music-listening experience is unheard of.

How on earth would you propose to compare codec performance at bitrates well above their normal transparency threshholds? What basis would you have for saying "though x and y both sound identical to the original, x performs better than y"?

If you're trying to preserve non-perceptible details of the original then it's foolish to be looking at lossy codecs, which are designed around human perception. (Lossless codecs often get roughly 50% compression; for CD audio that means ~700kbps.)

If you only care about how it's perceived when listening then there's no point in considering >192kbps rates with either of these codecs.

[Gainless]

Thanks for the tests Igor, noticed the bad performance of Lame at the Kick sample and FhG at the Bombat sample now either. A definately Opus related problem I've noticed though is that the exp version performs generally better at tonal samples than the "official" one, but in return often worse at certain other situations. A good example is this sample:

VD Sample

While the 1.0.1 rc handles the rythmic snare in it pretty well (at 64 kbps) the exp version introduces some kind of crackling sounds.

This post has been edited by Gainless: Aug 12 2012, 10:25

[larryfine]

I'm a strange here so...

Original file:

01. Giorgio Federico Ghedini - Mazurka (1908).wav --> 44.056.576 bytes

Compressed with Opus:

> opusenc.exe --bitrate 512 --music

01. Giorgio Federico Ghedini - Mazurka (1908).opus --> 15.794.176 bytes (lossy)

Compressed with TAK:

> Takc.exe -e -ihs -pMax

01. Giorgio Federico Ghedini - Mazurka (1908).tak --> 12.816.384 bytes (lossless)

[Gainless]

Well, if you set the encoder to 512 kbps it'll keep the resulting file around that bitrate, no matter how far it could be compressed further losslessly.

[zerowalker]

Opus has received the IETF's approval to become a standard. There will be some weeks of publication / pure-editorial delay and it will receive and RFC number and we'll make the big public announcements.

Now is really the time to get support into applications (well, this was also true for some time, but doubly so now). If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

I say Mumble, but it already says it´s going to have support so not sure it counts?
Other than that, i say Megui, for encoding?

And Youtube for allowing Opus decoding for there Re-Encode (probably a bit harder here as it´+s not open source or anything)

[CoRoNe]

Doesn't MeGUI use Avisynth and BassAudio for audio encoding? In that case it's already possible.

[zerowalker]

Doesn't MeGUI use Avisynth and BassAudio for audio encoding? In that case it's already possible.

Not sure what BassAudio is?

But well, it´s probably Very Easy to implement, as it just redirect to the encoder pretty much.


But, does anyone know if youtube supports Opus? (can´t see that it does).

[CoRoNe]

I'm sorry, I'm mixing up encoding and decoding.
Opus decoding through Avisynth is already possible with BassAudio, but the encoding part...that's indeed up to MeGUI to add a profile. In the meantime you could use avs2pipe to pipe Avisynth's audio output to the input of the audio encoder of your choosing.

[zerowalker]

I'm sorry, I'm mixing up encoding and decoding.
Opus decoding through Avisynth is already possible with BassAudio, but the encoding part...that's indeed up to MeGUI to add a profile. In the meantime you could use avs2pipe to pipe Avisynth's audio output to the input of the audio encoder of your choosing.

Oh, well i will just wait for MeGUI, as youtube doesn´t support Opus yet i think:)