From: Ross L. <ro...@st...> - 2024-07-21 11:50:18
|
That's a good test and observation. It should help whoever can resolve it properly. Hopefully someone comes forward. -----Original Message----- From: Maik Merten via Lame-dev [mailto:lam...@li...] Sent: Sunday, 21 July 2024 11:08 pm To: lam...@li... Subject: Re: [Lame-dev] CBR/ABR quality regressions for q0, q1, q2 and q3 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 _______________________________________________ Lame-dev mailing list Lam...@li... https://lists.sourceforge.net/lists/listinfo/lame-dev |