Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: IETF Opus codec now ready for testing (Read 392345 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

IETF Opus codec now ready for testing

Reply #275
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.

IETF Opus codec now ready for testing

Reply #276
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 

IETF Opus codec now ready for testing

Reply #277
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.

IETF Opus codec now ready for testing

Reply #278
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.

IETF Opus codec now ready for testing

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

IETF Opus codec now ready for testing

Reply #280
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


IETF Opus codec now ready for testing

Reply #282
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?

Quote
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.

Quote
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?

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

I do and hope you do the same

Chris
If I don't reply to your reply, it means I agree with you.

IETF Opus codec now ready for testing

Reply #283
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).


Quote
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.)

IETF Opus codec now ready for testing

Reply #284
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...


Quote
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
If I don't reply to your reply, it means I agree with you.

IETF Opus codec now ready for testing

Reply #285
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.

IETF Opus codec now ready for testing

Reply #286
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: [Select]
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: [Select]
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:

IETF Opus codec now ready for testing

Reply #287
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.


IETF Opus codec now ready for testing

Reply #288
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?

IETF Opus codec now ready for testing

Reply #289
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.

IETF Opus codec now ready for testing

Reply #290
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).

IETF Opus codec now ready for testing

Reply #291
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.

IETF Opus codec now ready for testing

Reply #292
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.

IETF Opus codec now ready for testing

Reply #293
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)

loquor mee menti: factus de materia, cinis elementi...

IETF Opus codec now ready for testing

Reply #294
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.

IETF Opus codec now ready for testing

Reply #295
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)

IETF Opus codec now ready for testing

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

IETF Opus codec now ready for testing

Reply #297
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).

IETF Opus codec now ready for testing

Reply #298
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.

IETF Opus codec now ready for testing

Reply #299
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:)