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 392685 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

IETF Opus codec now ready for testing

Reply #250
One thing I've noticed is that Opus (the exp version of course) is pushing a lot of bits into pieces at higher bitrates for which other encoders like Vorbis or even Lame are using way less. Since Opus should be at least better than Vorbis at anything there could be probably a lot of average bitrate decrease done while still keeping the same quality overall.


Different things are hard for Opus— so its expected that the rate will go up in some different places.  Its also possible that the encoder is making a mistake.  Do a CBR encode and see if you can get away with lowering the rate.  Examples of it being over eager would be helpful.

IETF Opus codec now ready for testing

Reply #251
I believe Gainless refers to something I would call "bitrate dynamics".

If one reduces the overall bitrate target, it does not only reduce the bitrate for the complex scenes which consume a lot of bitrate, but also for the simple scenes which are satisfied with less bitrate already. Gainless is probably interested in "compressing" only the high bitrate scenes, which he feels seem to get out of control.


If you don't want the encoder to adapt to the material, then use CBR mode.

If the reasoning is something like: "because Opus is better than Vorbis, it should be able to compress any piece/part of a piece of music to the same/better quality using less/same amount of bits" => this simply doesn't follow at all, which is exactly why VBR is boosting the bitrate.


I want the encoder to adapt to the material but maybe a bit more "intelligent". I cannot really imagine e.g. that Opus needs ~160 kbps for a simple kick and a baseline when Lame only takes ~90 kbps for it at the same target bitrate. If the developers would adapt the encoder to these kind of situations more precisely they could save bits that could be used either for decreasing the average bitrate or for parts that are more complex to encode. In short: They could improve the quality while still staying at the same bitrate.

Sorry for being a bit unclear in the last post btw, I was talking about the VBR model of Opus in general.

IETF Opus codec now ready for testing

Reply #252
Post your sample.

IETF Opus codec now ready for testing

Reply #253
I cannot really imagine e.g. that Opus needs ~160 kbps for a simple kick and a baseline when Lame only takes ~90 kbps for it at the same target bitrate.


See NullC's post for a constructive way to determine what is happening.

In general, though, your reasoning is flawed. Opus isn't an improved version of MP3, Vorbis, or AAC. Clips that may be easy to encode for those codecs can be hard for Opus. We'd just expect the reverse to be true more often. It's also possible Opus' psymodel is more accurate and correctly determines more bits are needed for a transparent encode, while the other codecs artifact even if ever so slightly.

For example tonal clips with multiple different tonal instruments are harder for Opus than any of those codecs due to it having shorter blocks with a windowing function that has higher leakage. Music that has a strong lowpass below 20kHz (for example clips that have been decoded from the other codecs) may also be harder to encode for Opus. There may be other cases - those are just the ones that are obvious to me after looking at the codec designs.

IETF Opus codec now ready for testing

Reply #254
OK, substantially different algorithms will legitimately produce remarkably different results, compared to previously known algorithms.

I see you are quite active in your development, so I wish you best success, and I hope to find material to support it...

IETF Opus codec now ready for testing

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

IETF Opus codec now ready for testing

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


It looks like the reasons for the high rate Opus uses on this file are:
1) It's highly tonal, so the encoder tends to boost the rate
2) There isn't much useful content above about 5 kHz, but the encoder currently cannot take advantage of that

The main point that should be addressed is 2), but it's not something that's easy to do. It's a great example of something "simple" that doesn't fit well within the current theory of psycho-acoustics.

IETF Opus codec now ready for testing

Reply #258
is there any news on an eta for getting an RFC number?


IETF Opus codec now ready for testing

Reply #260
Very tonal ... do you know "Stranglehold" by Jeroen Tel? It's an XM (FastTracker "Extended Module") which uses only a single sine wave as "instrument". Use e.g. ModPlug Player (or any audio player with module support and WAV export, e.g. foobar2000) to export it as WAV to get encodable material.



LAME 3.99.5 -V2: 180.0 kbps
Ogg Vorbis aoTuVb6.03 SSE3 -q5: 129.1 kbps
QAAC 1.39 (CATB 7.9.7.9) -V82: 147.7 kbps
Opus 0.9.11-92 (rel. gc329045) music 160: 157.8 kbps (149.6-278.0)
Opus 0.9.11-139 (exp. g2c7f8cd) music 160: 187.8 kbps (138.8-287.2)
Opus 0.9.11-142 (exp. 32024cb5) music 160: 189.2 kbps (137.6-311.6)

based on an amplified (about +9 dB, nearly normalized) 24-bit export from ModPlug Player with some sound enhancements enabled

IETF Opus codec now ready for testing

Reply #261
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?

IETF Opus codec now ready for testing

Reply #262
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?


Your question doesn't make any sense to me. Opus is a set, standardized codec. You can not change it and expect it to stay compatible. You can improve the quality of the encoder by improving the encoding decisions, which will generally be done by improving the psymodel to advise the encoder when it makes sense to do or not do something (of which one would be "spend more bits here"). It's very exceptional to improve a lossy encoder (for a given codec) by anything that doesn't depend on the psymodel.

I could replace "Opus" by AAC/MP3/Vorbis/... in the above sentence.

IETF Opus codec now ready for testing

Reply #263
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?

Well, Opus was on deep freeze during more than year. All last improvements come from tuning of VBR and psy.  There is still a lot  to improve.
Opus is already better than AoTuv and HE-AAC at 64 kbps. Even future standard (USAC) can't do any better than Opus at the same 64 kbps. Opus should do already better than Vorbis at 96 kbps too.
Given superior quality of Opus at 64 kbps and its good scalability I'm confident that it will present the same advantage at higher bitrates. But it will take time.

IETF Opus codec now ready for testing

Reply #264
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?
The encoder does make a lot of decisions, any of which might be improved- just from what little I know about it these include overall VBR rate control, long vs short blocks for each frequency band, whether to tilt the normal per-band bit allocation in favor of lower or higher frequencies, whether to boost the bits used by a particular band, whether to change the stereo mode, whether to change the codec mode (LP/hybrid/MDCT), and more.

But as Garf said, the psymodel is how a lossy encoder makes its decisions. So your question sounds much like "What I really wonder is how much potential cars still have for transportation. Is there still any way they can get me from place to place apart from using a motor or an engine?"

The latest tonal "problem samples" only seem to be problems for the experimental version's rate control, not problems for the codec's quality. I admittedly don't have golden ears, but I can't abx them at 64kbps using the non-experimental 0.1.4 opus-tools build.

IETF Opus codec now ready for testing

Reply #265
The latest tonal "problem samples" only seem to be problems for the experimental version's rate control

The experimental branch actually improves quality of tonal samples.

IETF Opus codec now ready for testing

Reply #266
The latest tonal "problem samples" only seem to be problems for the experimental version's rate control, not problems for the codec's quality. I admittedly don't have golden ears, but I can't abx them at 64kbps using the non-experimental 0.1.4 opus-tools build.


No one is claiming to ABX it with EXP either, they're claiming that at high rates its using more rate than it strictly needs to.

IETF Opus codec now ready for testing

Reply #267
IgorC, NullC: Uh, I'm quite aware of that. What part of "only seem to be problems for rate control, not quality" didn't you guys understand?

If I need to be more explicit: the experimental version's increase in quality of tonal samples in general seems to be accompanied by some minor problems with rate control on these specific samples.

IETF Opus codec now ready for testing

Reply #268
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?


Your question doesn't make any sense to me. Opus is a set, standardized codec. You can not change it and expect it to stay compatible. You can improve the quality of the encoder by improving the encoding decisions, which will generally be done by improving the psymodel to advise the encoder when it makes sense to do or not do something (of which one would be "spend more bits here"). It's very exceptional to improve a lossy encoder (for a given codec) by anything that doesn't depend on the psymodel.

I could replace "Opus" by AAC/MP3/Vorbis/... in the above sentence.


Sorry if the question came along a bit stupid, I wasn't really aware of the fact that the bitstream freeze means it's totally impossible to add some new technical abilities. 

What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?

Well, Opus was on deep freeze during more than year. All last improvements come from tuning of VBR and psy.  There is still a lot  to improve.
Opus is already better than AoTuv and HE-AAC at 64 kbps. Even future standard (USAC) can't do any better than Opus at the same 64 kbps. Opus should do already better than Vorbis at 96 kbps too.
Given superior quality of Opus at 64 kbps and its good scalability I'm confident that it will present the same advantage at higher bitrates. But it will take time.


Maybe I got it wrong, but I thought that the Psymodel is at least so far done that the rough behaviour (these bitrates for noisy samples, that one for...) is set properly and that it's now more about fixing the last problems for difficult/exceptional cases. But that would be more a question for NullC. I would be a bit careful with the statement that Opus is generally better than HE-AAC at 64 kbps btw, in my experience the FhG AAC encoder never had heavy problems with any sample (with the price of being slightly defficient at high frequencies), while Opus has quite a lot ones.


What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?
The encoder does make a lot of decisions, any of which might be improved- just from what little I know about it these include overall VBR rate control, long vs short blocks for each frequency band, whether to tilt the normal per-band bit allocation in favor of lower or higher frequencies, whether to boost the bits used by a particular band, whether to change the stereo mode, whether to change the codec mode (LP/hybrid/MDCT), and more.

But as Garf said, the psymodel is how a lossy encoder makes its decisions. So your question sounds much like "What I really wonder is how much potential cars still have for transportation. Is there still any way they can get me from place to place apart from using a motor or an engine?"

The latest tonal "problem samples" only seem to be problems for the experimental version's rate control, not problems for the codec's quality. I admittedly don't have golden ears, but I can't abx them at 64kbps using the non-experimental 0.1.4 opus-tools build.


I was more thinking about some new techniques instead of just deciding how to use the ones that are already there (as I assume that this is set at least substantially), but as Garf pointed out that's unfortunately not possible.

IETF Opus codec now ready for testing

Reply #269
I would be a bit careful with the statement that Opus is generally better than HE-AAC at 64 kbps btw, in my experience the FhG AAC encoder never had heavy problems with any sample (with the price of being slightly defficient at high frequencies), while Opus has quite a lot ones.

Probably You are not sensitive to pre-echo artifacts. Absolutely (!) every HE-AAC encoder exposes transients issues and that's where Opus has an advantage over it.
I have done a very extensive tests on HE-AAC vs Opus during last year on very large set of samples.

Feel free to  try the last experimental build on big set of samples and post your results.

IETF Opus codec now ready for testing

Reply #270
I would be a bit careful with the statement that Opus is generally better than HE-AAC at 64 kbps btw, in my experience the FhG AAC encoder never had heavy problems with any sample (with the price of being slightly defficient at high frequencies), while Opus has quite a lot ones.

Probably You are not sensitive to pre-echo artifacts. Absolutely (!) every HE-AAC encoder exposes transients issues and that's where Opus has an advantage over it.
I have done a very extensive tests on HE-AAC vs Opus during last year on very large set of samples.

Feel free to  try the last experimental build on big set of samples and post your results.


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.

IETF Opus codec now ready for testing

Reply #271
Now that's really strange. 

You really don't hear issues with HE-AAC  but Opus ... on electronic music. It's completely vice-versa for average listener.

Please, search for eig and fatboy samples .... the most tested electronic samples.

IETF Opus codec now ready for testing

Reply #272
I was more thinking about some new techniques instead of just deciding how to use the ones that are already there (as I assume that this is set at least substantially), but as Garf pointed out that's unfortunately not possible.
Have you ever compared the original 1994 l3enc mp3 encoder with modern encoders? There were no "new techniques" in the mp3 format, which was frozen in 1992, just vastly improved ways of making the decisions afforded by the format. The improvment is tremendous. Current opusenc may do a somewhat better job of showing the possibilities of opus than l3enc did for mp3, but there's still plenty of room for improvement without breaking the bitstream format.

IETF Opus codec now ready for testing

Reply #273
Even future standard (USAC) can't do any better than Opus at the same 64 kbps.

What makes you come to that conclusion? So far, the only reasonable demos of the quality USAC can offer are the bit-streams used in the MPEG verification test, which are CBR and created by an encoder which wasn't tuned for killer items like Fatboy and eig. A decent-quality USAC stereo encoder is not yet publicly available.

Quote from: jensend link=msg=0 date=
Have you ever compared the original 1994 l3enc mp3 encoder with modern encoders? There were no "new techniques" in the mp3 format, which was frozen in 1992, just vastly improved ways of making the decisions afforded by the format. The improvment is tremendous.

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.

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

IETF Opus codec now ready for testing

Reply #274
Even future standard (USAC) can't do any better than Opus at the same 64 kbps.

What makes you come to that conclusion?

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


So far, the only reasonable demos of the quality USAC can offer are the bit-streams used in the MPEG verification test, which are CBR and created by an encoder which wasn't tuned for killer items like Fatboy and eig. A decent-quality USAC stereo encoder is not yet publicly available.

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

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