Re: CBR/ABR quality regressions for q0, q1, q2 and q3

Hello,

when using -q0, another algorithm is chosen to adapt the scale factor 
for the bands (one at a time, instead of all or most at once), as far as 
I can tell. The scale factor determines how much quantization is applied 
for a given band (the encoding precision per band).

With the "one band at a time"-approach, several passes can become 
necessary to find suitable scalefactors, so that the audio data fits 
within a frame of a given size. That slows down encoding speed, but is 
intended to provide better scalefactor choices - except that for CBR and 
ABR, the resulting audio quality often is diminished compared to the 
faster approach.


Best regards,
Maik


Am 26.07.24 um 06:30 schrieb Ross Levis via Lame-dev:
> I see.  What's slowing down the encoding when using -q0 then?
> 
> -----Original Message-----
> From: Maik Merten via Lame-dev [mailto:[email protected]]
> Sent: Friday, 26 July 2024 4:07 pm
> To: [email protected]
> Subject: Re: [Lame-dev] CBR/ABR quality regressions for q0, q1, q2 and q3
> 
> Hello Ross,
> 
> -q4 already has the full Huffman code search. (-q5 does not)
> 
> I'm currently not quite sure any LAME developer with commit access (for
> whatever patch approach) is following this discussion, though.
> 
> Best regards,
> Maik
> 
> Am 26.07.24 um 01:06 schrieb Ross Levis via Lame-dev:
>> I'm not sure that's a good idea.  I believe better quality settings use more aggressive Huffman encoding to pack the file smaller.
>> That will be the main reason it's taking less time encoding at -q4.
>>
>> -----Original Message-----
>> From: Maik Merten via Lame-dev [mailto:[email protected]]
>> Sent: Friday, 26 July 2024 3:15 am
>> To: [email protected]
>> Subject: Re: [Lame-dev] CBR/ABR quality regressions for q0, q1, q2 and q3
>>
>> Hello,
>>
>> I updated the bug report with, perhaps, a better constructed patch:
>>
>> https://sourceforge.net/p/lame/bugs/516/
>>
>> This latest patch simply maps the quality levels 0, 1, 2 and 3 to 4,
>> similarly to how the quality-levels are handled for the new VBR mode.
>>
>> Of course, it would be best to find out *why* the settings 0 to 3 don't
>> work well with CBR and ABR and fix *that*, but this is a very
>> non-interfering (I hope) way to fix the symptoms. It even gives a neat
>> speed-boost.
>>
>> Hopefully, any of the LAME developers with commit access might have a
>> look at that trivial patch.
>>
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/lame-dev
>>
>>
>>
>>
>> _______________________________________________
>> Lame-dev mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/lame-dev
> 
> 
> 
> _______________________________________________
> Lame-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lame-dev
> 
> 
> 
> 
> _______________________________________________
> Lame-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lame-dev