HydrogenAudio

Hello, Everyone!  :)

It's my personal blind test – MultiCodec at ~192 VBR kbps

All versions of encoders were the newest and stable
LAME MP3 3.100 -V2 (~192 kbps)
Aple LC-AAC 7.10.9.0 via QAAC TVBR q91  (~192 kbps)
xHE-AAC 1.0.7.0 -m 9 (~192 kbps)
Opus 1.3.1 -b 182 (yes, 182, not 192 kbps, that’s way Opus stays on par with all other encoders during bitrate verifitacion on a big number of albums)
Musepack (MPC Encoder 1.30.0 –-stable)   Q5.5 (~192 kbps)
Vorbis Aotuv “OGG” 6.03 -q6 (~192 kbps)

Sampling rate treatment for Opus codec (44.1/48kHz)
Encoding:Original .WAV 44.1 kHz → foobar2000’s dbpoweramp SSRC resampling 48 kHz (onfly feed)→ Opus file 48 kHz  
Decoding:Opus file 48 kHz → SSRC 44.1 kHz .WAV

Hardware
Source: Benchmark DAC1 with built-in headphone AMP HPA2 (24bits/44.1kHz mode)
Headpones: Sennheiser HD 800

Files
LINK (https://drive.google.com/file/d/1rXORkWWacwQV9jjxPY0GjPY-Jx9QYfBx/view?usp=sharing)





Alternative graph of the results
https://i.ibb.co/vwWR8T7/Results-192-kbps.png


Conclusions
... empty spaces...

I'm curious, why you used ssrc resampler when opus use internal resampler? Is ssrc better quality?
Otherwise, excellent work! It's very nice to see opus being fully transparent at 192 kbps.

My turn to say it, Igor: nice chart!  ;)

I want to make a graph to my own listening test. Please tell me which software you have used to generate this graph. 

Great test. I'm really surprised with Musepack.

I'm curious, why you used ssrc resampler when opus use internal resampler? Is ssrc better quality?
Otherwise, excellent work! It's very nice to see opus being fully transparent at 192 kbps.

I haven't any issue with native resampler in Opus in the past. The main reason to use SSRC here was to keep Opus output at 44.1 kHz. 

My turn to say it, Igor: nice chart!  ;)

Thank You! I didn't forget about another chart in poll 2020.  Will see it now.

I want to make a graph to my own listening test. Please tell me which software you have used to generate this graph. 

It's Kamedo2's work https://listening-test.coresv.net/graphmaker5.htm

Great test. I'm really surprised with Musepack.

Uhm. In which way exactly?

Quote from: MiGamer5 on 2020-10-07 17:05:38

I want to make a graph to my own listening test. Please tell me which software you have used to generate this graph. 

It's Kamedo2's work https://listening-test.coresv.net/graphmaker5.htm

Quote from: LithosZA on 2020-10-07 17:10:06

Great test. I'm really surprised with Musepack.

Uhm. In which way exactly?

That it performed really well at 192Kbps. I always thought Musepack needed more bitrate to sound transparent.

I was under  impression that I probably wasn't able to hear any artifact on Musepack at 192 kbps.
Until now.

Musepack has transparent transients but it’s very slightly noisy on high frequencies of tonality.
Its high frequency muffling which is perceived as very slightly dull + flat noise addition.

Anyway those are very minor issues which were detected during critical listening. I won't be able to hear them on some average session of just enjoying a music.  :)

It should have been a hard test, Great work!

Anyway those are very minor issues which were detected during critical listening. I won't be able to hear them on some average session of just enjoying a music.  :)

 
 Specially, in your specific case, if we're talking about --quality 6 or up, as you used --quality 5.5 for your test, right?

I reordered the encoders by score.

(https://listening-test.coresv.net/img2/IgorC_192kbps1enc.png)
(https://listening-test.coresv.net/img2/IgorC_192kbps2enc.png)

MP3	xHE-AAC	Vorbis	AAC-LC	Musepack	Opus
3.5 	5.0 	5.0 	5.0 	5.0 	5.0 
4.5 	4.0 	4.6 	5.0 	5.0 	5.0 
3.8 	4.7 	4.8 	5.0 	5.0 	5.0 
5.0 	5.0 	5.0 	5.0 	5.0 	5.0 
4.2 	4.8 	4.9 	4.9 	4.9 	5.0 
4.2 	4.9 	4.9 	5.0 	5.0 	5.0 
4.8 	5.0 	5.0 	4.7 	4.9 	5.0 
5.0 	5.0 	5.0 	5.0 	5.0 	5.0 
5.0 	5.0 	5.0 	5.0 	5.0 	5.0 
4.7 	5.0 	4.8 	5.0 	5.0 	5.0 
4.8 	5.0 	5.0 	4.9 	4.8 	5.0 
4.0 	4.9 	4.8 	4.8 	4.8 	5.0 
%feature	10	LAME 3.100	exhale 1.0.7	Aotuv 6.03	Apple CoreAudioToolbox.dll 7.10.9.0		MPC Encoder 1.30.0 --stable	Opus 1.3.1
%feature	11	-V2	-m 9	-q6	TVBR q91	Q5.5	-b 182
%feature	12	Average:4.46	4.86	4.90	4.94	4.95	5.00
%samples	01 Castanets
%samples	02 Fatboy
%samples	03 EIG
%samples	04 Bachpsichord
%samples	05 Enola
%samples	06 Trumpet
%samples	07 applaud
%samples	08 Velvet
%samples	09 Linchpin
%samples	10 Angels_Fall_First_ringing
%samples	11 You look good to me
%samples	12 Berling Drug

I know it's a pointless and largely redundant observation, but if xHE-AAC didn't bomb on Fatboy and got a 5 like AAC-LC, Musepack and Opus, it would've just come third. Again, we could make similar "what ifs" observations about all the encoders. It's just that "killer sample" - from your personal listening test - is not handled well by xHE-AAC compared to how well it handled all the other audio samples.

I'm not familiar enough - nor can remember from tests years ago - what the "killer sample" property Fatboy possess. Anyone?

EDIT: thanks for the test and the clear presentation :-)

My thoughts:

• As expected, all of those post-MP3 codecs offer very high fidelity on 192kbps.
  
• Opus is indeed a mighty and stable codec. Even with his trained ear and twelve critical samples, Opus is transparent on 192k.
• Musepack is unexpectedly performing well on 192kbps.
• Apple AAC is nearly transparent in 192kbps, like in my 2011 personal test (https://hydrogenaud.io/index.php?topic=102876.0). 
• xHE-AAC and AAC-LC performs equally well on high rates, except for the Fatboy. Fatboy scored 3.5 in my 96kbps test (https://hydrogenaud.io/index.php?topic=119861.0), and 4.0 in IgorC's 192kbps test.
• MP3 192kbps occasionally drops below 4.0 on hard samples, which is consistent with my tests.

It should have been a hard test, Great work!

Thank you, K.  :)

Specially, in your specific case, if we're talking about --quality 6 or up, as you used --quality 5.5 for your test, right?

Well, higher bitrate implies higher transparency for any encoder. 
I've used --quality 5.5 because it produced  ~192 kbps  and was  on par with other encoders.

I know it's a pointless and largely redundant observation...

I agree. But it's ok.

but if xHE-AAC didn't bomb on Fatboy and got a 5 like AAC-LC, Musepack and Opus, it would've just come third. Again, we could make similar "what ifs" observations about all the encoders. It's just that "killer sample" - from your personal listening test - is not handled well by xHE-AAC compared to how well it handled all the other audio samples.

I see your point. And Yes, we are here basically speculating.
I'll try to put it this way. "What if" Opus was being lucky on  those difficult samples?  ... bun on all of them?  
It's very unlikely that this is just a coincidence or "bad luck/good luck" for some encoder. 
And it's not just a Fatboy sample if we take a look at a  distribution of scores on another samples. 

I'm not familiar enough - nor can remember from tests years ago - what the "killer sample" property Fatboy possess. Anyone?

Sharp transients

EDIT: thanks for the test and the clear presentation :-)

Thank You  :)

• Musepack is unexpectedly performing well on 192kbps.

 
 

As I understood on 192kbps average (as we all know, MPC only does pure VBR)  as Igor has actually used something slightly above "standard" (--quality 5.5.).

Edit: well, he replied just before I posted this, so there you go.

@includemeout
I've calibrated bitrates on a large number of albums of different genres.

MPC Q5 - 170 kbps - too small
MPC Q6- 210 kbps - was already too large.

MPC Q5.5 hited ~ 192 kbps.

You can also see that MPC had used more bits on tested samples than LC-AAC/MP3/Opus/xHE-AAC.
So bitrate setting for Musepack was more than fair.  ;)

@jaybeee
Also exhale xHE-AAC was the only encoder which was tested with CVBR mode (constrained VBR) while all other competitors were tested in their VBR modes.
exhale only supports CVBR.

@includemeout
I've calibrated bitrates on a large number of albums of different genres.

MPC Q5 - 170 kbps - too small
MPC Q6- 210 kbps - was already too large.

MPC Q5.5 hited ~ 192 kbps.

You can also see that MPC had used more bits on tested samples than LC-AAC/MP3/Opus/xHE-AAC.
So bitrate setting for Musepack was more than fair.  ;)

 
 Thanks. I got that. It's just that I wanted to make sure it was business as usual with MPC (well, in fact higher than "standard", but only slightly) and not some unheard of performance as I may have read into Kamedo's post, but I'll wait for his reply.

No love for faac/faad2? It was the fastest encoder/decoder for me but I didn't like how it sounded even at the highest quality. I hoped to know other people's perception.

No love for faac/faad2? It was the fastest encoder/decoder for me but I didn't like how it sounded even at the highest quality. I hoped to know other people's perception.

I think it might score about the same as MP3

Thanks very much, Igor, for this high-bit-rate test! It is very helpful for me, as the developer of exhale, since my hearing is not good enough anymore for testing such high rates myself. My 2 cents:

First cent

Quote from: jaybeee on 2020-10-07 19:35:20

but if xHE-AAC didn't bomb on Fatboy and got a 5 like AAC-LC, Musepack and Opus, it would've just come third. Again, we could make similar "what ifs" observations about all the encoders. It's just that "killer sample" - from your personal listening test - is not handled well by xHE-AAC compared to how well it handled all the other audio samples.

I see your point. And Yes, we are here basically speculating.
I'll try to put it this way. "What if" Opus was being lucky on  those difficult samples?  ... bun on all of them?  

IMHO these are very good observations and discussions, and both issues (one lower-quality score on exhale, all-identical scores on Opus) are the two extremes of the same issue (outliers), which are addressed by proper statistical analysis. For those not familiar with such things:

When your statistical sample size is small (as is the case here, 1 listener times 12 samples), it is important to consider possible effects caused by the small sample size, in order to avoid drawing conclusions which are not, let's say, statistically solid. Luckily, it's very easy to do a "robust" statistical analysis: there's a publicly available tool called Friedman by ff123 (https://www.rarewares.org/others.php) which e.g. Kamedo2 regularly uses on his personal tests. I fed this tool with a text file containing the first 13 lines of the text box that Kamedo2 posted yesterday:

Code: [Select]

MP3	xHE-AAC	Vorbis	AAC-LC	Musepack	Opus
3.5 	5.0 	5.0 	5.0 	5.0 	5.0 
4.5 	4.0 	4.6 	5.0 	5.0 	5.0 
3.8 	4.7 	4.8 	5.0 	5.0 	5.0 
5.0 	5.0 	5.0 	5.0 	5.0 	5.0 
4.2 	4.8 	4.9 	4.9 	4.9 	5.0 
4.2 	4.9 	4.9 	5.0 	5.0 	5.0 
4.8 	5.0 	5.0 	4.7 	4.9 	5.0 
5.0 	5.0 	5.0 	5.0 	5.0 	5.0 
5.0 	5.0 	5.0 	5.0 	5.0 	5.0 
4.7 	5.0 	4.8 	5.0 	5.0 	5.0 
4.8 	5.0 	5.0 	4.9 	4.8 	5.0 
4.0 	4.9 	4.8 	4.8 	4.8 	5.0 

No matter which option of Friedman.exe I choose (blocked ANOVA, Friedman/Fischer, Tukey's HSD), I always get this report:

AAC-LC is better than MP3
Musepack is better than MP3
Opus is better than MP3
Vorbis is better than MP3
xHE-AAC is better than MP3

Note that it does not say that Opus is better than xHE-AAC or Vorbis, and Kamedo2 privately confirmed to me that I'm using the tool correctly. That's what I mean with "robust statistical analysis". Essentially, Friedman.exe's comments on your discussion could be phrased as: yes, Opus may be "lucky" on at least one sample, and exhale may be "unlucky" on at least one sample (though it can't say which sample). It also means that the plots should be taken with a grain of salt, which is often the case. As Garf once put it on this forum: "Basically, the graphics suck, but they look cute (https://hydrogenaud.io/index.php?topic=90403.msg767004#msg767004)" ;)

Usually, when you add more samples (like Guruboolez and Kamedo2 did) or listeners (as was done in HA's recent public tests), those issues tend to disappear. Nonetheless, exhale's quality on Fatboy could be a bit higher even to my ears, which brings me to my

Second cent
Indeed, Igor, the reason is an excessive chain of transients on the first half of Fatboy. A few weeks ago I had a possible solution for this, but at the lower bit-rates it degraded the audio quality on some other samples, so I decided not to follow up on that issue. And, as Kamedo2 mentioned, at 96 kbit/s, where the overall audio quality is lower, the score on Fatboy doesn't degrade much more (3.5), see his personal test (https://hydrogenaud.io/index.php?topic=119861).

So I could try to "fix" Fatboy only for CVBR mode 8 or 9, but are people really using these modes much? This would be a fix specific to the first few seconds of that single sample, I don't know any other sample where this issue occurs. If so, I could try to come up with a "test.m4a" file to check if the fix works on the weekend.

Chris

@C.R.Helmrich & @IgorC: thank you for your comments and thoughts on my observation, which I gladly now agree wasn't a redundant one  :))

Clearly in the grand scheme of things such killer samples aren't that common, esp the Fatboy one, and so you're right to wonder whether it's worth trying to fix it, which could negatively impact other audio samples. Of course, these samples are - as evidenced here - very useful for listening tests though.

Very Interesting Igor, thank you for your efforts.

Good effort.
I 'm wondering if the results will be the same if the test is realized with hifi speakers. There is more space de analyze the sounds.

And what about stereo separation in 2 planes.
What codec preserves  most the position of instrument between right and left and from up to down.

Musepack has transparent transients but it’s very slightly noisy on high frequencies of tonality.
Its high frequency muffling which is perceived as very slightly dull + flat noise addition.

Do you think that using lowpass filter switch (--bw 16500 or 17200) would help Musepack to achieve better results?

@C.R.Helmrich
I'm agree with your observations. All post-MP3 formats are generally on par on such bitrate.

Clearly in the grand scheme of things such killer samples aren't that common, esp the Fatboy one, ...

Transients aren't that uncommon. Electronic music is full of them.

Also You make accent only on Fatboy sample and I've alredy mentioned to You that it wasn't the only sample where exhale had an issue.
One of another samples where exhale wasn't transparent is EIG ... which also has transients.

I 'm wondering if the results will be the same if the test is realized with hifi speakers...

Everything is transparent

Do you think that using lowpass filter switch (--bw 16500 or 17200) would help Musepack to achieve better results?

I don't know and I have no plans to dig into that.
As for me, only recommended default settings. Any deviation from default can work for one individual but can break the things for others. Not my type of fun.

 Does anyone has tried opusrug? Is it competitive with some rock, melodic music? How does it score with fatboy or enolaguy? Do you think change the tonality target to 1.2f default could help with pads at low bitrate such as 32 kbps (Romanian music) while reducing the accuracy only a bit?
Anyone interested to try it in Linux?

So far it doesn't beat quality records with pop and it isn't miracles like Jpeg XL, Nero AAC ABR two-pass 69 kbps can sound good on unreleased pop. Also nobody has produced a bitstream of it in Linux and as I heard developers aren't interested because I didn't compile myself and the program should be up to master at least or use opusfile latest, I don't think j m valin or some other opus contributors have read my thread.

Thanks very much, Igor, for this high-bit-rate test! It is very helpful for me, as the developer of exhale, since my hearing is not good enough anymore for testing such high rates myself.

You're always welcome, Chris.  :)
I didn't answer soon because was recovering from covid.  It's all ok now.

Second cent
Indeed, Igor, the reason is an excessive chain of transients on the first half of Fatboy. A few weeks ago I had a possible solution for this, but at the lower bit-rates it degraded the audio quality on some other samples, so I decided not to follow up on that issue. And, as Kamedo2 mentioned, at 96 kbit/s, where the overall audio quality is lower, the score on Fatboy doesn't degrade much more (3.5), see his personal test (https://hydrogenaud.io/index.php?topic=119861).

I see.  As from exhale's topic it's pretty clear that now its priority is lower bitrates <= 96 kbps.  And I can't be more agree with that. There is no reason to work on xHE-AAC and bitrates higher than 96 kbps when LC-AAC with its expired patents does excellent on such high bitrates. Last time I've tried exhale 1.0.7.0 @ 96 kbps and similar bitrates it was the best encoder and performed on par with Opus.

The main targent of this test was "MP3 vs post-MP3 codecs at high bitrate". I suspected but wasn't sure that all post-MP3 encoders were going to perform on par. Detecting where xHE-AAC has some issues was a by-product. Exhale here was for a complete picture, as just another post-MP3 encoder.

Take care, guys

Musepack can go above 320kbps even at --standard, I have some tracks reaching 390 ~ 800kbps. Yet with AAC/Vorbis on tracks like that don't do that despite having no frame limit like MP3/Opus. Yet on Noise/synth focused samples transform codecs really hate it, There some samples i have where the either artifact or have horrid bitrate bloat.

I didn't answer soon because was recovering from covid.  It's all ok now.

Ouch! I'm glad you recovered!

There is no reason to work on xHE-AAC and bitrates higher than 96 kbps ... Last time I've tried exhale 1.0.7.0 @ 96 kbps and similar bitrates it was the best encoder and performed on par with Opus.

I'm glad to hear that. Still, your test sparked my motivation to look at exhale's handling of transients once more. Attached an experiment which, hopefully, improves the Fatboy sample a bit. I can hardly hear a difference. Could you compare this against the encoding in your test if you have time, please?

Chris

Chris,

Yes,  now it's much better.

ABC/HR Version 1.1 beta 2, 18 June 2004
Testname: 

1R = C:\Audio\15_samples\Personal Test 192 kbps\exhale m9 192 kbps\fatboy_exhale_cvbr9_exp17-brmRS2.wav
2R = C:\Audio\15_samples\Personal Test 192 kbps\exhale m9 192 kbps\13 fatboy_30sec.wav

---------------------------------------
General Comments:

---------------------------------------
1R File: C:\Audio\15_samples\Personal Test 192 kbps\exhale m9 192 kbps\fatboy_exhale_cvbr9_exp17-brmRS2.wav
1R Rating: 4.6
1R Comment: 
---------------------------------------
2R File: C:\Audio\15_samples\Personal Test 192 kbps\exhale m9 192 kbps\13 fatboy_30sec.wav
2R Rating: 4.0
2R Comment: Some  ghost speech in R channel.
---------------------------------------
ABX Results:
C:\Audio\15_samples\Personal Test 192 kbps\exhale m9 192 kbps\fatboy_exhale_cvbr9_exp17-brmRS2.wav vs C:\Audio\15_samples\Personal Test 192 kbps\exhale m9 192 kbps\13 fatboy_30sec.wav
    5 out of 5, pval = 0.031

Great, thanks a lot! That would, hypothetically, result in an average score of almost 4.91 on your test set, assuming of course that no other samples are degraded in audio quality. I'll check if that's the case and then add this fix to the upcoming exhale 1.0.8 release.

Chris

Has anyone here tested MPC at Q4.5 which is 160kbps VBR?, Would be fun too see how it fairs to AAC/Ogg/Opus there. No idea why people are perplexed MPC is transparent within 130 ~ 200kbps despite being pretty much modern MP2. It already uses PNS when under 128kbps & i wonder if that helping it a bit even at 200kbps?.

I'm back on HA.org
I'm truly impressed by this test Igor: I know how hard it is to get usable results at such high bitrate. Well done!
Result is not a real surprise to me: MP3 struggles with pre-echo/killer samples and increasing the bitrate doesn't always help.
Post-MP3 formats are therefore better but not equally. However it's very difficult to show on a listening test.

Still, this test shows that an alternative to MP3 is preferable even near 200 kbps.

AAC/OPUS 192kbps, really? ??? This quality is sufficient for this equipment? :o

Source: Benchmark DAC1 with built-in headphone AMP HPA2 (24bits/44.1kHz mode)
Headpones: Sennheiser HD 800

Result is not a real surprise to me: MP3 struggles with pre-echo/killer samples and increasing the bitrate doesn't always help.

MP3 fails to achieve transparency on a wide kind of signals as transients, tonal etc.

MP3's blocksize range is too limited (https://en.wikipedia.org/wiki/Advanced_Audio_Coding#AAC's_improvements_over_MP3):

higher coding efficiency for stationary signals (AAC uses a blocksize of 1024 or 960 samples, allowing more efficient coding than MP3's 576 sample blocks);
higher coding accuracy for transient signals (AAC uses a blocksize of 128 or 120 samples, allowing more accurate coding than MP3's 192 sample blocks);

Increasing bitrate on MP3 to ~256-320 kbps doesn't help much to reach quality of  post-MP3 codecs at 192 kbps.

AAC/OPUS 192kbps, really? ??? This quality is sufficient for this equipment? :o

That's what test shows.

Quote from: Pabl on 2020-11-01 10:32:29

AAC/OPUS 192kbps, really? ??? This quality is sufficient for this equipment? :o

That's what test shows.

This applies only to these samples or all music in average?

The test was performed on samples which are harder to encode than an average music.

So MP3 unfit for any music with pre echo/sharp attacks?, at any bit rate. Really wonder how MP3 was green lit with so many issues that even Lame encoder can't fix. Since so much current music uses electronic elements with sounds on par with Eig/fatboy samples. Could explain the upsurge with AAC, Opus, Vorbis for the lossy camp.

Really wonder how MP3 was green lit with so many issues that even Lame encoder can't fix.

At the beginning of hydrogenaudio in 2001 MP3 was—along with WMA—the only suitable lossy format for mobile use (digital audio player, CD-MP3…). Quality issues were well-known here. The audio stayed nevertheless very popular: wide-compatibility, and transparent for most users and even many advanced ones were not horrified by slight smearing. That's why MP3 is still widely used.

IgorC's test highlight MP3's Achilles heel but overall performance is far from being bad. An overal score of 4.46 means “very good with audible but not annoying differences”. The worst sample is ranked at 3.5, which means “between slightly annoying and not annoying”. And this is only 192 kbps. There are two stronger VBR modes (V1 and V0), and of course 320 kbps CBR. All these modes will lower the audibility of distortions and could even eradicate the slightiest artifacts heard at 192 kbps.

15 years ago I performed a very large listening test with 200 samples (https://hydrogenaud.io/index.php?topic=38792.0) (150 classical music + 50 various). The high anchor was also LAME -V2 (3.98 alpha). Results were very similar: 4.58 for classical music and 4.61 for other musical genres. For the small electronic/artifical samples group (5 samples only) MP3's score was lower than Ogg Vorbis 128 kbps. Again, there's nothing new…  ;)

The pre echo/fast attack artifacts I get on stuff like electronic/artifical samples still fail at V0, 320kbps. I moved to other codecs since even just generic crackly static sounds like vinyl, noise, walking on snow would make Lame shoot to 275 ~ 318kbps at V4 setting or have loud pops not in the lossless version.

The pre echo/fast attack artifacts I get on stuff like electronic/artifical samples still fail at V0, 320kbps.

It could be, but they won't be as audible. Overall score will rise further even if full transparency is technically impossible to achieve with MP3.

I moved to other codecs since even just generic crackly static sounds like vinyl, noise, walking on snow would make Lame shoot to 275 ~ 318kbps at V4 setting

During very short moments maybe but overall bitrate is much lower. And 275 kbps frames with V4 are not identical to 275 kbps with V2. Bitrate is only a result: there are maths behind, and different quality settings between different VBR modes.
And it's a smart move from you :) The best MP3 encoder/setting has been surpassed by Vorbis, AAC, MPC for twenty years ago and more recently by OPUS and USAC. Unless specific reason (like a car with limited compatibility) I don't see any reason to stick with MP3.

Yeah if your using <192kb/s their no point with MP3 unless your stuck with stuff that don't support AAC or Vorbis. The sharp rise on AAC & Opus seems to be from that Phones/DAP(android) now use them, MP3 seems to be the last thing people pick when going lossy now.

That it performed really well at 192Kbps. I always thought Musepack needed more bitrate to sound transparent.

It does it still a subband codec like MP2, Some pure noise samples need higher setting to stop bit rate starving them hard.

MP3 seems to be the last thing people pick when going lossy now.

Among people who know maybe, but in general the internet still has way too many posts from people wanting to convert their Youtube downloads or similar from AAC  to MP3, and many that are still convinced that MP3 CBR 320 is "the best", which sometimes leads to the mention of FLAC , which confuses the op even  more.

Quote from: ani_Jackal3 on 2020-11-05 12:02:56

MP3 seems to be the last thing people pick when going lossy now.

Among people who know maybe, but in general the internet still has way too many posts from people wanting to convert their Youtube downloads or similar from AAC  to MP3, and many that are still convinced that MP3 CBR 320 is "the best", which sometimes leads to the mention of FLAC , which confuses the op even  more.

Noticed that too many get very sore when told AAC/Vorbis can be transparent at 160kbps. Since they just go then why does spotify/Apple use 256 ~ 320kbps.

Would love to have seen Fraunhofer FDK AAC Codec Library v4.0.1 codec used in this test at Q10 VBR (average 192 kbit/s) and how good it is against Apple’s encoder at this high bit rate.

Has something changed between FDK AAC 4.0.0 and 4.0.1? With 4.0.0 there's no Q10 VBR. There are 5 VBR mode for LC-AAC: the fourth one is ≃ 136 kbps and the next, fifth and last VBR mode is ≃ 236 kbps. Not very flexible and no ~192 kbps VBR mode with 4.0.0.
>source< (https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing).

Has something changed between FDK AAC 4.0.0 and 4.0.1? With 4.0.0 there's no Q10 VBR. There are 5 VBR mode for LC-AAC: the fourth one is ≃ 136 kbps and the next, fifth and last VBR mode is ≃ 236 kbps. Not very flexible and no ~192 kbps VBR mode with 4.0.0.
>source< (https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing).

Yeah sorry, my mistake. I use Poikosoft’s converter exclusively these days with Apple’s LC AAC encoder. I remember seeing a VBR mode In their FDK AAC offering a bit rate range of 180-230 and a Google search led me to this page but I now see is a beta version: https://www.poikosoft.com/ezcd-fraunhofer-fdk-aac-encoder I’m away from home this weekend so I can’t check my PC.

Just a quick note that the updated FDK AAC settings/tunings in the software I use has been released. Good to see that they’ve been working with Exhale too. I’d love to give it a serious listening test myself but due to the pandemic I don’t currently have the equipment at this high bit rate. https://www.poikosoft.com/music-converter-version-history

Has something changed between FDK AAC 4.0.0 and 4.0.1? With 4.0.0 there's no Q10 VBR. There are 5 VBR mode for LC-AAC: the fourth one is ≃ 136 kbps and the next, fifth and last VBR mode is ≃ 236 kbps. Not very flexible and no ~192 kbps VBR mode with 4.0.0.
>source< (https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing).

I wonder what is the reason for the huge jump in bitrate between 4 & 5?!

Hello,

I wonder what is the reason for the huge jump in bitrate between 4 & 5?!

It seems to be designed like this,

libAACenc/include/aacenc_lib.h

-----------------------------------------------
 VBR_MODE | Approx. Bitrate in kbps for stereo
          |     AAC-LC    |      AAC-ELD
----------+---------------+--------------------
    VBR_1 | 32 (HE-AACv2) |         48
    VBR_2 | 72 (HE-AACv1) |         56
    VBR_3 |      112      |         72
    VBR_4 |      148      |        148
    VBR_5 |      228      |        224
--------------------------------------------

perhaps to accommodate the (superfluous) bandwidth.

libAACenc/src/bandwidth.cpp

static const BANDWIDTH_TAB_VBR bandWidthTableVBR[] = {
    {AACENC_BR_MODE_CBR, 0, 0},
    {AACENC_BR_MODE_VBR_1, 13000, 13000},
    {AACENC_BR_MODE_VBR_2, 13000, 13000},
    {AACENC_BR_MODE_VBR_3, 15750, 15750},
    {AACENC_BR_MODE_VBR_4, 16500, 16500},
    {AACENC_BR_MODE_VBR_5, 19293, 19293},
    {AACENC_BR_MODE_SFR, 0, 0},
    {AACENC_BR_MODE_FF, 0, 0}

    AiZ

Hello,

Quote from: pr0m3th3u5 on 2020-12-03 14:20:58

I wonder what is the reason for the huge jump in bitrate between 4 & 5?!

It seems to be designed like this,

Code: [Select]

libAACenc/include/aacenc_lib.h

-----------------------------------------------
 VBR_MODE | Approx. Bitrate in kbps for stereo
          |     AAC-LC    |      AAC-ELD
----------+---------------+--------------------
    VBR_1 | 32 (HE-AACv2) |         48
    VBR_2 | 72 (HE-AACv1) |         56
    VBR_3 |      112      |         72
    VBR_4 |      148      |        148
    VBR_5 |      228      |        224
--------------------------------------------

perhaps to accommodate the (superfluous) bandwidth.

Code: [Select]

libAACenc/src/bandwidth.cpp

static const BANDWIDTH_TAB_VBR bandWidthTableVBR[] = {
    {AACENC_BR_MODE_CBR, 0, 0},
    {AACENC_BR_MODE_VBR_1, 13000, 13000},
    {AACENC_BR_MODE_VBR_2, 13000, 13000},
    {AACENC_BR_MODE_VBR_3, 15750, 15750},
    {AACENC_BR_MODE_VBR_4, 16500, 16500},
    {AACENC_BR_MODE_VBR_5, 19293, 19293},
    {AACENC_BR_MODE_SFR, 0, 0},
    {AACENC_BR_MODE_FF, 0, 0}

    AiZ

I read the code but I still don't understand what does "to accommodate the (superfluous) bandwidth" mean?

Increasing bitrate on MP3 to ~256-320 kbps doesn't help much to reach quality of  post-MP3 codecs at 192 kbps.

If I am interpreting that correctly... would it be fair to say that if a person is using MP3, that beyond v2 (190kbps average) would be pretty much a waste of storage space in your opinion?

like sound quality keeps increasing at a decent rate for people like you (who can do these listening tests well (which is already clearly above the common person)) on MP3 until v2 (190kbps average) is reached at which point going beyond that is pretty much a waste of storage space. like if there are some quality gains beyond v2 (190kbps average) they are probably very small(?) and the increase in bitrate is not really worth it especially since it appears your tests are samples that don't represent the typical music but more of a worst case scenario type of sample range and if these still score pretty well, which they apparently do, it's safe to say that for music in general that MP3 would easily be satisfactory (even though if post-MP3 formats are a option, use them instead as a general guideline), even if not 'perfect'.

p.s. that's kind of how I am trying to form my suggestions for MP3 in my signature around. like the average person can try v5 (130kbps average) and if that's not good enough for them, use v2 (190kbps average) and forget about it. NOTE: I get what's transparent for one person can vary a bit from another person and all, but just for a quick suggestion, assuming you answer 'yes' to my question, then v5 or v2 sounds like a pretty good guideline for those who don't want to play around with this stuff much. NOTE: I can see how many might just opt for v2 to be on the safe side of sound quality with MP3 since MicroSD cards are huge and near dirt cheap nowadays. but if someone has a older device with limited storage space, then v5 will probably start to look a lot better than v2. so all-in-all, it seems with MP3 that v5 is still a pretty good all-around choice when all things are considered, especially in regards to the common person who's looking for solid efficiency of their storage space.

ThaCrip, do you have any experience with Fraunhofer and Helix encoders when it comes to low bitrates?
I am very interested in hearing your thoughts/opinion about them.

Quote from: ani_Jackal3 on 2020-11-05 11:35:11

The pre echo/fast attack artifacts I get on stuff like electronic/artifical samples still fail at V0, 320kbps.

It could be, but they won't be as audible. Overall score will rise further even if full transparency is technically impossible to achieve with MP3.

Quote

I moved to other codecs since even just generic crackly static sounds like vinyl, noise, walking on snow would make Lame shoot to 275 ~ 318kbps at V4 setting

During very short moments maybe but overall bitrate is much lower. And 275 kbps frames with V4 are not identical to 275 kbps with V2. Bitrate is only a result: there are maths behind, and different quality settings between different VBR modes.
And it's a smart move from you :) The best MP3 encoder/setting has been surpassed by Vorbis, AAC, MPC for twenty years ago and more recently by OPUS and USAC. Unless specific reason (like a car with limited compatibility) I don't see any reason to stick with MP3.

Noticed that stuff with V0 would be still be there but can be ignored but in quieter stuff it can fall apart still like if there too much acoustic instruments playing.  

ThaCrip, do you have any experience with Fraunhofer and Helix encoders when it comes to low bitrates?
I am very interested in hearing your thoughts/opinion about them.

I assume for Helix you mean... https://www.rarewares.org/mp3-others.php#helix_enc ? ; which was last updated in 2005 apparently. I am pretty sure I never used that before. NOTE: Foobar2000 only offers LAME when it comes to MP3 for it's built-in presets and I have been using Foobar2000 as my 'go to' general audio playback/conversion program etc for many years now.

but for Fraunhofer... I may have used that in the early-to-mid 2000's (or so) with some random software (I can't quite recall the software's name) to make MP3's.

or... are you referring to Fraunhofer FhG (Winamp encoder) on AAC? ; because I kept that encoder in a small .7z file (about 500KB (the three dll files are dated Dec 2013)) I made years ago as I know it's noticeably faster at encoding AAC files then Apple's AAC on Foobar2000. but it seems Apple AAC is what people (including myself) generally default to around here when it comes to AAC (AAC-LC) encoding.

I don't even have the Winamp FhG AAC dll's installed to Foobar2000 currently but I could easily enable them if I wanted to. in Foobar2000 it does have a 'AAC (Winamp AAC)' preset available as it allows VBR 1 through VBR 6 (i.e. 32/64/96/128/192/256 kbps options). I think that 'AAC (Winamp AAC)' is still a pretty good all-around choice though. or one might be able to say a good alternative choice to Apple AAC as I was looking around a moment ago I noticed this text on the hydrogenaudio wiki page under 'Fraunhofer AAC Encoders'... "According to the July 2011 96kbps listening tests by IgorC, Winamp's Fraunhofer encoder is better than Nero AAC and tied with the Apple encoder (then part of QuickTime)". ; that info is probably still accurate today given what IgorC said from a post in late 2019 which basically said that about 2009/2011 was the most recent there have been any improvements in general audio quality for AAC/MP3 encoders that people care about (i.e. https://hydrogenaud.io/index.php?topic=118446.msg977450#msg977450 ; at the bottom of his post there ).

Quote from: IgorC on 2020-11-01 19:04:20

Increasing bitrate on MP3 to ~256-320 kbps doesn't help much to reach quality of  post-MP3 codecs at 192 kbps.

If I am interpreting that correctly... would it be fair to say that if a person is using MP3, that beyond v2 (190kbps average) would be pretty much a waste of storage space in your opinion?

No.
I literally have meant what I've written. Nothing more, nothing less.
Now if you ask my experience  with  V2 vs V0, there is certainly improvement going to V0 but that won't do to reach the quality of newer formats at 192 kbps.  To have an idea, V0/CBR320 would be at ~4.6-4.7 score in such test.

p.s. that's kind of how I am trying to form my suggestions for MP3 in my signature around.

It would be better to leave people to choose what's better for them by themselves.
Otherwise the span is too wide, V6...V0.   Also LAME  has a nice wiki --> https://wiki.hydrogenaud.io/index.php/LAME

Yup, V0 just makes Eig.wav less annoying but still not transparent. 256 ~ 320kbps on the post codecs is unneeded unless you find a rare sample that trips them up. 

Now if you ask my experience  with  V2 vs V0, there is certainly improvement going to V0 but that won't do to reach the quality of newer formats at 192 kbps.  To have an idea, V0/CBR320 would be at ~4.6-4.7 score in such test.

Knowing that, ill ask you this... do you think it's enough of a difference to justify using v0(or 320kbps) over v2 in general?

if you answer "No"... then my question to you would be how much lower would you go below v2(like say v3 or v4 etc), if at all? (NOTE: if you answer 'Yes' (to my initial question) then we are probably too far apart as, at least for me, v0 seems to be too much of a bit rate increase for minimal gains even going strictly by your tests of v2(190kbps) @ 4.5 vs v0(245kbps)/320kbps @ 4.6-4.7 since at that rate, maybe short of a very select amount of samples, it seems your nearly at the level of splitting hairs(?) (no offense or anything as you have made solid contributions around here and seem to be one of the more respected members etc))

NOTE: with you leaning a bit more toward sound quality than file size efficiency since we are talking the higher bit rates already which would obviously mean someone who's using those rates is more concerned with sound quality than file size. but at the same time... someone can't really give a answer of v0 or 320kbps either since it's basically THE top of the MP3 sound quality bar and I tend to assume there's a bit rate lower than that where the sound quality gains reach a point to where raising bit rate further is not really worth it anymore. my best guesstimate would be v2 or v3 given the LAME wiki guide since it seems the shift from v4(165kbps) to v3 (175kbps) is when LAME enters 'high quality' mode. so that's why I think I am pretty close claiming v2 (190kbps) is a pretty good set it and forget it option for those more concerned with sound quality but there is still some level of efficiency as I think beyond this point efficiency takes a solid hit for what appears to be minimal(if not very minimal(?)) gains.

It would be better to leave people to choose what's better for them by themselves.
Otherwise the span is too wide, V6...V0.   Also LAME  has a nice wiki --> https://wiki.hydrogenaud.io/index.php/LAME

Agreed. but... I want to keep suggestions in my signature simple for people who don't want to test things much for themselves is all. so while there is no definitive answer, as someone could still argue either way (a lower or higher setting) of my v5(130kbps) and v2(190kbps) suggestions, given your reply here I suspect I am pretty close for those who want a 'set-it-and-forget-it' type of suggestion depending on whether they are concerned mainly with file size (i.e. v5), or not (i.e. v2), but obviously not TOO far either way in favor of file size or sound quality otherwise people could easily say v7 (or so) or just peg the bit rate at v0(or 320kbps CBR) to squeeze every last drop of sound quality out of MP3 which, in my opinion, defeats the purpose of lossy encoders which is to get as high quality as possible (or thereabouts) but keeping the bit rates a bit more sane as it's not worth jacking up bit rate beyond a certain point just to clean up a tiny amount of sound.

that's kind of why I am thinking my two suggestions (i.e. v5 or v2) seem to have a good balance, like one favors file size (without too much of a hit to sound quality(it's still pretty good, especially for general use in a variety of situations)) and the other favors sound quality (without pegging the bit rate TOO high), and would cover just about everyone in regards to file size and sound quality (assuming a person only gets to choose two options like I did in my signature for MP3) short of those who have bad hearing (or those who don't really care about sound quality as long as it's not obviously bad), or those perfectionist types who don't settle for anything less. so I guess, at least in my opinion, that MP3 as a general rule is probably overall best balance of sound/file size between v5-v2 (while one could argue for options between those two, I just tend to either go v5 or v2 and forget about it) for just about everyone lacking some people since you can't please everyone ;)

but thanks for the info and the LAME wiki link which seems to be good info.

p.s. I have mentioned before, at least on my Klipsch Pro-Media speakers on my desktop PC, that going from v7(100kbps) down to v8(85kbps) is when the quality drop becomes obvious for me as I can immediately notice (like within a few seconds tops of any random song switching back and forth) it due to the overall sound being muffled (lacks clarity in the overall sound that you expect to hear) as it's something really obvious when switching back and fourth between the v7 and v8 MP3's. so that LAME wiki guide's, what seems to be minimum suggestion of v6(115kbps), as 'acceptable', is probably a pretty good guideline for a near bare minimum without rolling-the-dice on quality too much. in my opinion, I would almost surely never use below v7(100kbps) even though v6(115kbps) is probably a little more of a safety buffer for those who prefer to keep file size at a minimum but don't want quality taking TOO much of a hit either. but with that said, it's not like v8 is 'horrible' though either but at that point there is just too much of a obvious hit to the overall sound quality to where unless someone is extremely tight on storage space and wants to cram in as many songs as they can into a limited amount of storage space(which probably ain't a real concern for a high percentage of people nowadays), it don't make much sense to use MP3 on a setting any lower than v7 in my opinion as a absolute minimum for MP3.

Less is more

Less is more

Let me put it this way (to keep it short)... with MP3 (LAME), what setting would be your favorite all-around choice between v5-v2?

IIRC LAME options are case sensitive, so it's V2 (or V5), not v2 or v5.

Let me put it this way (to keep it short)... with MP3 (LAME), what setting would be your favorite all-around choice between v5-v2?

-V 3.14 (https://wiki.hydrogenaud.io/index.php/LAME#Recommended_encoder_settings)
Because it's well rounded.

-V 3.14 (https://wiki.hydrogenaud.io/index.php/LAME#Recommended_encoder_settings)
Because it's well rounded.

I should have worded my question to you like that earlier as it appears your "-V 3.14" suggestion seems to be your sweet-spot (like optimal balance between file size/sound quality), which is basically the answer I was looking for and trying to get from you in the first place (and was even a little more precise than I expected ;) ).

so basically you prefer a slightly modified v3 (175kbps average) then, which if I calculated that correctly (since there is only 10kbps difference between v4 to v3 and your nearly at v3), would be about 173-174kbps average. even on a couple songs I converted between V3.14 and v3 was about 100KB difference or so which sounds right since it's barely lower on average bit rate. so your choice, without details, would be basically V3 which is the lowest bit rate of the 'high quality' options based on the LAME wiki link.

but looking at the switches (which I posted below to 'lvqcl')... it appears the "n" in "-V n" equals a number (i.e. 3.14 for example). so it would be typed out like "-V 3.14" (and NOT "-V n 3.14") for custom bit rates with LAME. which is easy enough to do in Foobar2000 as I noticed in Foobar2000 when previously selecting 'MP3 (LAME)' (which in my case it was on v5 already (but any LAME option in the menu will work as there is at least one there if I recall correctly by default)) and then switch over to 'Custom' it already has "-S --noreplaygain -V 5 - %d" there. so given that info, I reasoned out that one can swap the '5' (in the "-V 5" section) with '3.14'. or to spell it out for someone else reading this post who wants to use IgorC's 3.14 suggestion for LAME in Foobar2000... I would simply do "-S --noreplaygain -V 3.14 - %d". then adjust the 'Display' section accordingly which I think "-V 3.14" would be about 174kbps average which is only a touch smaller file size vs the default v3 at which point it's probably just easier for someone reading this to just use the defaults for LAME on Foobar2000 and use the slider to select "V3"(175kbps average) since it's only barely less efficient compared to your preferred standard of V3.14(174kbps average). but if one is more of a perfectionist in this regard(i.e. optimal file size/sound quality combo), then using IgorC's 3.14 is probably a good all-around set it and forget it option.

thanks for your time.

p.s. but now knowing this... it's possible I could tweak my signature so it's "v5 (130kbps) (or v3 (175kbps))". but at the same time, I might just leave it like it is (i.e. "v5 (130kbps) (or v2 (190kbps))" since it's only about a 15kbps difference and might give a little more safety buffer unless you feel the sound quality difference between v3 and v2 is negligible for you in general? ; which I suspect it might negligible because you feel V3.14 (basically V3) is the sweet spot straight up even though you could have went with V2, but did not. hell, come to think of it... if you don't mind me asking, what would be your rough equivalent of LAME @ v3.14(174kbps) with Opus/AAC(Apple)? ; maybe 96-128kbps or so?

IIRC LAME options are case sensitive, so it's V2 (or V5), not v2 or v5.

Did they add the lower case 'v' option at some point? ; because I see the following (which seems to allow 'v' or 'V')....

Variable Bit Rate (VBR)
-v             VBR  ( alias of -V 4 )
--vbr-old      use old variable bitrate (VBR) routine
--vbr-new      use new variable bitrate (VBR) routine (default)
-V n           VBR quality setting  (0=highest quality, 9.999=lowest)
-b  n          specify a minimum allowed bitrate (8,16,24,...,320)
-B  n          specify a maximum allowed bitrate (8,16,24,...,320)
-F             strictly enforce minimum bitrate
-t             disable VBR informational tag
--nohist       disable display of VBR bitrate histogram

so it appears one can do 'v' instead of 'V' but it's probably something that they added into the LAME encoder at some point(?) to make it simpler so if people forget to do the proper "V" and just put "v", it will still work as expected.

Lowercase -v turns on variable bitrate but does not take a parameter. He was probably making a joke by suggesting the pi number.

You write a lengthy essay about "efficiency" in many threads. But in reality we are already freed from constraints of bitrate. Listening to music is about an enjoyment without worry, and not an essential task with an utility where the gain should be maximized.

Lowercase -v turns on variable bitrate but does not take a parameter.

If I understand that correctly... are you saying that using a lowercase 'v' that one can only select the basic V0-9 without the details like '9.999'?

He was probably making a joke by suggesting the pi number.

I see, that went over my head. but knowing that, it's probably his subtle/fancy way of saying I am too concerned with this stuff ;)

You write a lengthy essay about "efficiency" in many threads. But in reality we are already freed from constraints of bitrate. Listening to music is about an enjoyment without worry, and not an essential task with an utility where the gain should be maximized.

Yeah, I get it ;)

but I just tend to prefer some level of efficiency instead of just throwing a boatload of bit rate into the music simply because we can. even though I realize the average person this does not even cross their mind as long as they got a way of listening to their music that sounds good enough. hell, I would not be surprised if many just listen to music on YouTube/iTunes etc. but who knows, I suspect I am out of touch with the younger generation by now and even those who are a bit older generation probably are still stuck with audio CD's, or maybe records.

but as you know, a fair amount of the people around here, tend to be a little more into this stuff than the common person (probably a little OCD to be honest). so we might get a little obsessive about it (which the average person couldn't care less about) and sometimes we need to take a step back and just use a decent bit rate and move on, which is pretty much what you said ;)

thanks for your time.

Yup, V0 just makes Eig.wav less annoying but still not transparent. 256 ~ 320kbps on the post codecs is unneeded unless you find a rare sample that trips them up. 

Try adding -f switch in Lame (256-320k). There should be an improvement on those pre echo samples.

I had to force allshort since I had Lame 3.99a on my PC, Fixes it on more than just eig at the cost of high bitrate. But then again the post codecs are transparent on samples like that at 160kbps with MPC being the most robust.

I had to force allshort since I had Lame 3.99a on my PC, Fixes it on more than just eig at the cost of high bitrate. But then again the post codecs are transparent on samples like that at 160kbps with MPC being the most robust.

MPC sounds very attractive as quality is excellent on Q5 and above but after reading this post, I'm kind of skeptical.
halb27 ran into problem using Q7 in normal listening situation:
https://hydrogenaud.io/index.php?topic=102429.50

It isnt clear if it was a one off or could be repeated.
A single 5/5 isn't always something to be concerned with.
If the artifact is really bad it is enough, but when more subtle and
combined with very high settings you want better score / repeat result (IMO).

So basically continue to use AAC-LC 256Kbps, which is also patent free.

It isnt clear if it was a one off or could be repeated.
A single 5/5 isn't always something to be concerned with.
If the artifact is really bad it is enough, but when more subtle and
combined with very high settings you want better score / repeat result (IMO).

Yes, It's hard to say is it serious or something like very rare case.
However, Joni Mitchell "Cool Water" is not a problem sample (at least I'm considering it as normal cd music),
and when someone notice a problem on normal listening using extreme mpc setting Q7 that is slightly worrying.
But it's probably very rare case and difference should be very subtle on Q7.
btw, nice to hear from you @shadowking ;)

It isnt clear if it was a one off or could be repeated.
A single 5/5 isn't always something to be concerned with.
If the artifact is really bad it is enough, but when more subtle and
combined with very high settings you want better score / repeat result (IMO).

Yup 256kbps Is where 95% of the tuning on MPC went too with the remaining going to 175kbps. For DBT that just a demo test for those I don't even use the full test on foobar DBT app if I'm just checking if my mpc files sound fine.

@jaybeee
Also exhale xHE-AAC was the only encoder which was tested with CVBR mode (constrained VBR) while all other competitors were tested in their VBR modes.
exhale only supports CVBR.

I'm kinda late here, but I just wanted to ask - isn't Opus's "VBR" also kind of constrained? Opus provides no way to specify a target quality and let bitrate be whatever it ends up being, it can only target a specific bitrate (which, yes, it likes to overshoot, but the point still stands).

True VBR is when you throw stereo audio and mono audio at an encoder with the exact same settings and get close to double the bitrate for the former compared to the latter. LAME's -V, Vorbis's -q, etc. all behave this way. There's no way to do this with Opus.

Exhale's CVBR admits 1.25x variation of bitrate.
Opus VBR admits 2x ( for example target bitrate 128  kbps, peak 256 kbps) variation of bitrate and comparable to other VBR encoders. So, yes, it's VBR.

Every encoder has its own VBR implementation and adding it into some category doesn't reflect reality oftenly.
Whether it's  called "quality based" or "true" or  just "VBR" it's secondary. It's VBR.   


P.S. But if You wish,  Opus VBR implementation is quality based VBR.  It increases/decreases bitrate on type of signale (tonal, transients),  stereo (wide, narrow), complexity etc.... So  it's  "true" or "quality based"  if You wish to call it this way.
Opus has no fancy -V or -q mode instead Opus uses -b (bitrate) as targeting bitrate but it doesn't change the fact that it's VBR (outstanding and well tuned one)

P.S.2. It's simple to observe that only Opus was transparent on every killer sample. No way it would be possible if it hadn't well tuned VBR mode.  

Question, Is common for some to rate Lame MP3 at V2 as 4.90?.

P.S.2. It's simple to observe that only Opus was transparent on every killer sample. No way it would be possible if it hadn't well tuned VBR mode.  

It was not my intent to suggest that Opus's VBR "isn't VBR", nor that it isn't well tuned. Merely that it is - nevertheless - constrained, to some degree.

I mean, as long as the bitrate varies in any fashion, that's VBR - literally by definition. The bitrate is variable = variable bitrate = VBR. Whatever Exhale is doing is also VBR, because it produces files with variable bitrate.

I was not aware of the exact difference to which degree Exhale limits the variability of the bitrate compared to Opus, and I do agree that makes Exhale's VBR more constrained than Opus's. Nevertheless, the point remains that Opus has no way of encoding VBR without targetting a specific bitrate. I agree, this doesn't mean that Opus's VBR "isn't VBR". But it does mean that there's no way to encode with Opus while targetting a specific quality level rather than a specific bitrate. And "targetting a specific bitrate" is nothing other than constraining the bitrate to some degree. Yes, it's clearly incredibly well tuned - as obvious from the test results. If anything, the only thing I lament about this situation with Opus's VBR is that it could do even better than it already does, if it provided a way to encode VBR without having any specific target bitrate.

But it does mean that there's no way to encode with Opus while targetting a specific quality level rather than a specific bitrate. And "targetting a specific bitrate" is nothing other than constraining the bitrate to some degree.

https://wiki.xiph.org/OpusFAQ#How_is_the_bitrate_setting_used_in_VBR_mode.3F

How is the bitrate setting used in VBR mode?
Variable bitrate (VBR) mode allows the bitrate to automatically vary over time based on the audio being encoded, in order to achieve a consistent quality

The bitrate setting controls the desired quality, on a scale that is calibrated to closely approximate the average bitrate that would be obtained over a large and diverse collection of audio. The actual bitrate of any particular audio stream may be higher or lower than this average.

Hence, it's quality based.

Quote from: doccolinni on 2021-05-12 16:30:09

But it does mean that there's no way to encode with Opus while targetting a specific quality level rather than a specific bitrate. And "targetting a specific bitrate" is nothing other than constraining the bitrate to some degree.

https://wiki.xiph.org/OpusFAQ#How_is_the_bitrate_setting_used_in_VBR_mode.3F

Quote

How is the bitrate setting used in VBR mode?
Variable bitrate (VBR) mode allows the bitrate to automatically vary over time based on the audio being encoded, in order to achieve a consistent quality

The bitrate setting controls the desired quality, on a scale that is calibrated to closely approximate the average bitrate that would be obtained over a large and diverse collection of audio. The actual bitrate of any particular audio stream may be higher or lower than this average.

Hence, it's quality based.

As much as I'd like it to be so just because they worded it that way, it actually isn't.

Both of these were encoded with bitrate set to 128 (same source audio):
(https://i.imgur.com/1ofwYEc.png)

Since setting the bitrate to 128 resulted in almost the exact same bitrate for both the stereo and the mono encode, the VBR is clearly bitrate based, not quality based.

As much as I'd like it to be so just because they worded it that way, it actually isn't.

Every article, documentation and site indicates Opus's VBR is quality based.  So this "they" is a little bit wider than You think.
I see only one person,You, who thinks than Opus's VBR is not "quality based".


Ask yourself a question if there is a real-case (reasonable ) implementation of VBR which is not quality based and post here example.

Another question will be  whether every real-case VBR encoder  is truely unrestricted and doesn't do some tricky bitrate restrictions based on how much bitrate was already used and so on. You will be surprised that some popular encoders (which have "q" setting) do that. "q" setting is not a panacea.  And here you have a very wide and quality based VBR encoder and complain that it's not quality based just because devs named and mapped "q"  setting with "b" setting.

More realistic two indicators of what someone can expect from encoder is wideness of variability  of VBR implementation and, of course, blind tests.  And Opus's VBR checks those boxes perfectly!.   "q" setting isn't an indicator of anything.

Since setting the bitrate to 128 resulted in almost the exact same bitrate for both the stereo and the mono encode

This has nothing to do with implementation of VBR. It's just a different mapping approach. You just ask an encoder to encode mono file  at that setting. And it does so.

Now if your create a stereo (not mono) file with exact the same L/R channels Opus will lower bitrate because of redundancy as a VBR encoder would do.

Opus brought this upon itself and it is indeed confusing.

If they said the bitrate was the stereo bitrate, and if you had mono or 5.1 it changed the target rate internally to match that quality, then it would make sense to treat the bitrate as a quality figure. But I believe (and I did not test myself sorry), if I have mono or 5.1 and I say 192 kbp, it will average around that 192 kbps in a large enough corpus.

In other words, one has to learn a rating for mono, stereo, 5.1, etc. 192 kbp is more than perfect for stereo, but definitely cannot be of the same quality for 5.1 or event 7.1

That is why it is hard for normal users. (Admittedly I care less as I only do stereo.)

Every article, documentation and site indicates Opus's VBR is quality based.  So this "they" is a little bit wider than You think.
I see only one person,You, who thinks than Opus's VBR is not "quality based".

It is "quality based" to the extent that the bitrate variation within the encode will, to a certain extent, vary depending on the signal complexity, in order to - again, to a certain extent - maintain a certain level of quality. (Note that this is the exact same sense in which pretty much any form of VBR - ABR and constrained VBR included - is "quality based".)

But it is not "quality based" in the sense that providing a target bitrate means just setting a quality level, as very clearly evidenced by the example I posted above: ~128 kbps VBR mono and ~128 kbps VBR stereo are certainly different quality, and yet encoding both with the same target bitrate setting produced them as such - at almost the exact same bitrate, rather than attempting to achieve the same level of quality.

This has nothing to do with implementation of VBR. It's just a different mapping approach.

These two sentences contradict each other. "Mapping approach" is a part of the implementation of VBR. If it has to do with "a different mapping approach", it also has to do with the implementation of the VBR.

You just ask an encoder to encode mono file  at that setting. And it does so.

Yes, that is literally what I am saying - I requested the VBR to achieve a bitrate of ~128 kbps, and it did that rather than achieving a certain level of quality. Therefore, the bitrate setting for the VBR determines a target bitrate, not a target quality. I don't understand why this is so complicated.

All right. I see, We were talking about two different things then. 

Development of Opus is finished nowadays. So don't expect -q setting for mono/stereo/5.1 quality-based setting.
The End.

It is quality based, but they just say find out your acceptable quality indicator (happens to be bit rate over a large average corpus) for mono, stereo, and for each multi-channel, and they will guarantee that we will keep it at that quality. Complicated music will still be above target and simple below. It is not ABR as there is no feedback loop to guarantee the average bitrate not to exceed the bitrate you gave.

IgorC beat me to it, but yeah.

To be honest a bit confusing, but not a show-stopper.

Opus brought this upon itself and it is indeed confusing.

If they said the bitrate was the stereo bitrate, and if you had mono or 5.1 it changed the target rate internally to match that quality, then it would make sense to treat the bitrate as a quality figure. But I believe (and I did not test myself sorry), if I have mono or 5.1 and I say 192 kbp, it will average around that 192 kbps in a large enough corpus.

In other words, one has to learn a rating for mono, stereo, 5.1, etc. 192 kbp is more than perfect for stereo, but definitely cannot be of the same quality for 5.1 or event 7.1

That is why it is hard for normal users. (Admittedly I care less as I only do stereo.)

A quick experiment with this disc image. A typical classical album.
https://www.discogs.com/Smetana-Wiener-Philharmoniker-James-Levine-The-Moldau/release/2148148

(Admittedly I care less as I only do stereo.)

I have a few albums by The Beatles and one or two others that are in mono. It's more annoying than anything else that I can't just actually set the quality level to what I want and forget it, but whenever I want to (re)encode I need to go "ok, so these albums are in mono, so I gotta lower the bitrate, then when I'm done with them raise it back up again...".

In my bitrate table (https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing) (one file = one album ; ~255 albums on various genre), you can see some interesting variations for OPUS VBR:

(https://zupimages.net/up/21/19/v8r3.png) (https://zupimages.net/viewer.php?id=21/19/v8r3.png)

(see the OPUS tab for these details)

For VBR 192 the lowest bitrate for an album is 151 kbps (128 kbps if I include movie soundtrack) and the highest is 235 kbps. The lowest value are usually mono CD (2 identical channels). It is true that some VBR codecs have stronger bitrate amplitude than OPUS but with ±20% on albums (it's probably higher on tracks and for sure much higher on shorter samples) it's clearly not "bitrate based" :)

The lowest value are usually mono CD (2 identical channels). It is true that some VBR codecs have stronger bitrate amplitude than OPUS but with ±20% on albums (it's probably higher on tracks and for sure much higher on shorter samples) it's clearly not "bitrate based" :)

That is with dual-channel mono though. Try single channel. :P

The reason it matters btw, if you check the data in bennetng's message (https://hydrogenaud.io/index.php?topic=120007.msg997571#msg997571), dual channel mono still incurs a not insignificant bitrate penalty compared to single channel for the same quality level. It is simply unnecessarily wasteful to encode mono in dual channel. But, if you tell Opus to encode single channel... then it targets the bitrate, not the quality level.

The reason it matters btw, if you check the data in bennetng's message (https://hydrogenaud.io/index.php?topic=120007.msg997571#msg997571), dual channel mono still incurs a not insignificant bitrate penalty compared to single channel for the same quality level. It is simply unnecessarily wasteful to encode mono in dual channel. But, if you tell Opus to encode single channel... then it targets the bitrate, not the quality level.

I think OPUS detects first the number of channels and then change internally some settings.
If you ask ~128 kbps VBR (-b 128) it will set the encoder differently according to the number of channels. That's why a 1.0 file has a totally different bitrate than a 2.0 file with two identical channels. The same apply for multichannel : -b128 for a 5.1 provides a much worse quality per channel than -b128 for 2.0. Both soundtrack will end with ~120…130 kbps but the stereo will have ~60kbps per channel and the 5.1 only ~20 kbps per channel.

In other words, -b128 doesn't have one single quality target: it has a significantly higher quality target for a mono (1.0) file than for a stereo (2.0) file, and even a much better quality target compared to a 5.1 file.
For the end user it's much easier to manage to get the desired bitrate with non-stereo file. But i's also confusing compared to other codecs.

Exemple: I like the quality of Apple's AAC at ~128 kbps (setting: -q 64). If I want this quality for a movie/concert in 5.1 I just have to keep -q64. But I don't have any idea of the final bitrate (probably ~3× higher because the number of channels is ×3¹).

With Opus, I'd like to keep the quality I'm used to get with -b 128 on CD for my 5.1 movie/concert. I don't have any idea of what setting I should use (probably something close to -b 384¹ because there are three time more channels to reproduce) but I'll know the approximate bitrate I'll get.

___
¹ In fact it should be inferior to this if the encoder is tuned for handling multichannel and encode efficiently channels similarities.

Analyzing a number of listening tests towards my dissertation (http://www.ecodis.de/about.htm#2017) a few years ago, I came up with a simple function which tells you quite accurately how to get roughly the same audio quality for different channel configurations. The following function gives you a weight w for each cc, where cc is the channel configuration written as a decimal number (1.0 for mono, 2.0 for stereo, 5.1 for surround, etc.):

w(cc) = cc^0.75

If you want to know the quality equivalent mono bit-rate of, e.g., 128 kbps stereo, you simply calculate 128 * w(1.0)/w(2.0) = 128 * (1.0/2.0)^0.75 = 76 kbps. That function also tells you that, with 5.1 surround, you need roughly twice the stereo bit-rate for the same level of audio quality. Based on my experience that's quite reasonable, at least with modern codecs like Opus, (x)HE-AAC, and MPEG-H Audio.

Chris

Analyzing a number of listening tests towards my dissertation (http://www.ecodis.de/about.htm#2017) a few years ago, I came up with a simple function which tells you quite accurately how to get roughly the same audio quality for different channel configurations. The following function gives you a weight w for each cc, where cc is the channel configuration written as a decimal number (1.0 for mono, 2.0 for stereo, 5.1 for surround, etc.):

w(cc) = cc^0.75

If you want to know the quality equivalent mono bit-rate of, e.g., 128 kbps stereo, you simply calculate 128 * w(1.0)/w(2.0) = 128 * (1.0/2.0)^0.75 = 76 kbps. That function also tells you that, with 5.1 surround, you need roughly twice the stereo bit-rate for the same level of audio quality. Based on my experience that's quite reasonable, at least with modern codecs like Opus, (x)HE-AAC, and MPEG-H Audio.

Chris

excellent! that should be in the wiki ;)

@IgorC, it's good to see these results. I was a bit worried a few years ago (before Opus 3, admittedly) that Opus at 176 was just a waste of time compared to MP3 - it sounds like that bitrate and codec wasn't too far off the mark. Thanks!