Re: [Lame-dev] CBR/ABR quality regressions for q0, q1, q2 and q3

[Maik M. <mai...@go...>]

Hello Ross,

I take that you were able to reproduce the problem - it's very helpful 
to have data from several people.

It's been a while (~5 years) since Robert's last commit to LAME, but 
perhaps he's still watching things.

Another thing I found out: It's possible to force the VBR encoding mode 
into CBR operation by setting the lower and upper bitrate limit to the 
same value (not recommended!), for instance like

lame --resample 44100 --lowpass 16000 -V0 -b80 -B80 -q0 test.wav test.mp3

This appears to sound better than CBR with -q0, but worse than CBR with 
-q4 (unsurprisingly, because clearly the VBR code expects to have some 
bitrate breathing room). However, it may indicate that the new VBR 
encoding loop somehow is handling noise_shaping_amp (enabled with 
q0/1/2/3) better than the (old) CBR and ABR encoding loops.


Best regards,
Maik


Am 20.07.24 um 13:35 schrieb Ross Levis via Lame-dev:
> It's definitely a problem.  Anyone know if Robert Hegemann still around/available to take a look at his code?
> 
> -----Original Message-----
> From: Maik Merten via Lame-dev [mailto:lam...@li...]
> Sent: Thursday, 18 July 2024 6:00 pm
> To: lam...@li...
> Subject: Re: [Lame-dev] CBR/ABR quality regressions for q0, q1, q2 and q3
> 
> Hello Ross,
> 
> yes, with LAME's current release (and also LAME's SVN), it's easy to
> come up with samples where -q0 sounds worse than -q4 in CBR and ABR
> encoding. This is especially apparent with low bitrates, but can also be
> detected at the default bitrate of 128 kbps.
> 
> Personally, I haven't had a sample where -q4 sounds worse than -q0 (but
> plenty where -q0 sounds worse than -q4), which is why I'm confident this
> is an actual bug, but I certainly recommend giving it a try with your
> own ears.
> 
> To easily be able to distinguish the difference, one can experiment with
> ambitious low-bitrate encoding (assuming test.wav is CD-quality stereo
> music):
> 
> lame --resample 44100 --lowpass 16000 -b96 -q0 test.wav q0.mp3
> lame --resample 44100 --lowpass 16000 -b96 -q4 test.wav q4.mp3
> 
> (these are settings below MP3's comfort level, but one wouldn't expect
> -q0 to do worse than -q4 nonetheless)
> 
> Depending on the input, -q0 can collapse into a smeary, metallic mess
> where -q4 holds up noticeable better. Usually, the lower the bitrate,
> the more obvious the differences become.
> 
> Some more discussion and audio samples have been posted over at
> https://hydrogenaud.io/index.php/topic,126120.0.html
> 
> Best regards,
> Maik
> 
> 
> Am 18.07.24 um 02:59 schrieb Ross Levis via Lame-dev:
>> I'm not a LAME developer but I am a developer that uses LAME. I'm curious if you are both saying that using -q4 with a CBR
> encoding
>> would actually produce better results than -q0?
>>
>> -----Original Message-----
>> From: Maik Merten via Lame-dev [mailto:lam...@li...]
>> Sent: Thursday, 18 July 2024 4:40 am
>> To: lam...@li...
>> Subject: Re: [Lame-dev] CBR/ABR quality regressions for q0, q1, q2 and q3
>>
>> Hello again,
>>
>> the regression was introduced with
>>
>> https://sourceforge.net/p/lame/svn/6147/
>>
>> With this commit, CBR and ABR encoding was switched over the the newer
>> VBR-psy-model.
>>
>> Other than that, the encoding loops for CBR and ABR apparently were not
>> changed. With the older psy-model (up to revision 6146),
>> noise_shaping_amp being set to 1 or 2 does not appear to have a
>> detrimental effect. This demonstrates IMO that noise_shaping_amp is not
>> in principle incompatible with CBR/ABR, but presumably something went
>> awry when switching over to the VBR-psy-model.
>>
>> Disabling noise_shaping_amp for the affected modes still seems to be the
>> easy workaround, but if it's possible to have noise_shaping_amp work as
>> intended, that'd of course be very neat.
>>
>>
>> Best regards,
>> Maik
>>
>>
>> Am 12.07.24 um 18:57 schrieb Maik Merten:
>>> Hello there,
>>>
>>> it has been observed that with CBR and ABR, perceived audio quality
>>> increases when using faster settings than default.
>>>
>>> A discussion regarding this over at HydrogenAudio:
>>> https://hydrogenaud.io/index.php/topic,126120.0.html
>>>
>>> This is very easily noticeable with very low bitrates, but is also
>>> detectable with the default bitrate of 128 kbps. The discussion thread
>>> on HydrogenAudio includes samples.
>>>
>>> I traced this down to cfg->noise_shaping_amp, which is set to 1 for
>>> -q3/-q2 and is set to 2 for -q1/-q0. Choosing a value of 0 (as for the
>>> faster quality settings) improves perceived audio quality.
>>>
>>> I opened up a bug report a while back over at
>>> https://sourceforge.net/p/lame/bugs/516/ with trivial patches and an
>>> attempt at a theory of why quality might be affected negatively with
>>> noise_shaping_amp being set to 1 or 2. This, however, is merely
>>> speculative, as it's not quite clear to me what settings 1 and 2 are
>>> actually trying to achieve - presumably, those are intended to increase
>>> quality (and perhaps they do in VBR?), but I don't quite understand the
>>> reasoning behind those approaches.
>>>
>>> While setting noise_shaping_amp to 0 is a trivial thing to do, it might
>>> also be (pure speculation, again) that the actual root cause is with the
>>> CBR and ABR encoding loops somehow not interacting properly with
>>> noise_shaping_amp 1/2 and that a "true fix" might involve tinkering with
>>> those encoding loops.
>>>
>>> How would one progress on this issue? With -q3 being the default
>>> setting, rather regrettably CBR and ABR encodings are impacted
>>> negatively by default.
>>>
>>> Another, but most likely minor thing: It appears that noise_shaping_stop
>>> is unused, yet set up by lame_init_qval. I assume this could be removed?
>>>
>>> Best regards,
>>> Maik
>>
>>
>>
>> _______________________________________________
>> Lame-dev mailing list
>> Lam...@li...
>> https://lists.sourceforge.net/lists/listinfo/lame-dev
>>
>>
>>
>>
>> _______________________________________________
>> Lame-dev mailing list
>> Lam...@li...
>> https://lists.sourceforge.net/lists/listinfo/lame-dev
> 
> 
> 
> _______________________________________________
> Lame-dev mailing list
> Lam...@li...
> https://lists.sourceforge.net/lists/listinfo/lame-dev
> 
> 
> 
> 
> _______________________________________________
> Lame-dev mailing list
> Lam...@li...
> https://lists.sourceforge.net/lists/listinfo/lame-dev