Menu
▾
▴
lame-dev
|
From: Maik M. <mai...@go...> - 2024-07-12 17:04:37
|
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 |
|
From: Maik M. <mai...@go...> - 2024-07-17 17:03:44
|
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 |
|
From: Ross L. <ro...@st...> - 2024-07-18 05:05:10
|
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 |
|
From: Maik M. <mai...@go...> - 2024-07-18 06:00:17
|
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 |
|
From: Ross L. <ro...@st...> - 2024-07-20 11:35:54
|
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 |
|
From: Maik M. <mai...@go...> - 2024-07-21 11:14:50
|
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 |
|
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 |
|
From: Tobias D. <tob...@gm...> - 2024-07-22 12:51:16
|
I noticed that -V9 -q0 does sound identical to -V9 -q4 (at least on
my Sony XM3s), also I cannot spot any difference in encoding time
between the two (which I would expect from different -q settings, as is
clearly the case when using -cbr).
Also AFAIR this has been the case for a very, very long time.
I don't know if this is to be expected and a trivial observation or if
it does indeed add anything to the conversation.
Just my 2 cents,
Tobias
Am 12.07.24 um 18:57 schrieb Maik Merten via Lame-dev:
> 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
|
|
From: Tobias D. <tob...@gm...> - 2024-07-22 13:28:31
|
Out of curiosity, I've run diff on files produced by -V9 -q0 and -V9 -q4, and it turns out they are identical. -q does absolutely nothing when using -V. Am 22.07.24 um 14:37 schrieb Tobias Damisch via Lame-dev: > I noticed that -V9 -q0 does sound identical to -V9 -q4 (at least on > my Sony XM3s), also I cannot spot any difference in encoding time > between the two (which I would expect from different -q settings, as is > clearly the case when using -cbr). > > Also AFAIR this has been the case for a very, very long time. > > I don't know if this is to be expected and a trivial observation or if > it does indeed add anything to the conversation. > > Just my 2 cents, > > Tobias > > > Am 12.07.24 um 18:57 schrieb Maik Merten via Lame-dev: >> 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 |
|
From: Maik M. <mai...@go...> - 2024-07-22 14:37:35
|
Hello Tobias,
with the standard VBR code, only a selection of q-values is actually
active. From lame.c, ca. line ~1000:
/* The newer VBR code supports only a limited
subset of quality levels:
9-5=5 are the same, uses x^3/4 quantization
4-0=0 are the same 5 plus best huffman divide code
*/
if (gfp->quality < 0)
gfp->quality = LAME_DEFAULT_QUALITY;
if (gfp->quality < 5)
gfp->quality = 0;
if (gfp->quality > 7)
gfp->quality = 7;
So indeed, there are only these ranges in VBR:
-q0 to -q4 (maps q0)
-q5 to -q6 (q5 and q6 are effectively the same settings)
-q7 to -q9 (maps to q7)
Best regards,
Maik
Am 22.07.24 um 15:28 schrieb Tobias Damisch via Lame-dev:
> Out of curiosity, I've run diff on files produced by -V9 -q0 and
> -V9 -q4, and it turns out they are identical.
> -q does absolutely nothing when using -V.
>
>
> Am 22.07.24 um 14:37 schrieb Tobias Damisch via Lame-dev:
>> I noticed that -V9 -q0 does sound identical to -V9 -q4 (at least on
>> my Sony XM3s), also I cannot spot any difference in encoding time
>> between the two (which I would expect from different -q settings, as is
>> clearly the case when using -cbr).
>>
>> Also AFAIR this has been the case for a very, very long time.
>>
>> I don't know if this is to be expected and a trivial observation or if
>> it does indeed add anything to the conversation.
>>
>> Just my 2 cents,
>>
>> Tobias
>>
>>
>> Am 12.07.24 um 18:57 schrieb Maik Merten via Lame-dev:
>>> 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
|
|
From: Tobias D. <tob...@gm...> - 2024-07-22 22:24:32
|
Thanks for the clarification Maik, now I understand!
The man page kind of hints at what you explain,
but fails to mention clearly that q0 to q4 is absolutely the same to -V
and also that this setting of highest quality is the default anyway.
Kind regards,
Tobias
Am 22.07.24 um 16:29 schrieb Maik Merten via Lame-dev:
> Hello Tobias,
>
> with the standard VBR code, only a selection of q-values is actually
> active. From lame.c, ca. line ~1000:
>
> /* The newer VBR code supports only a limited
> subset of quality levels:
> 9-5=5 are the same, uses x^3/4 quantization
> 4-0=0 are the same 5 plus best huffman divide code
> */
> if (gfp->quality < 0)
> gfp->quality = LAME_DEFAULT_QUALITY;
> if (gfp->quality < 5)
> gfp->quality = 0;
> if (gfp->quality > 7)
> gfp->quality = 7;
>
>
> So indeed, there are only these ranges in VBR:
>
> -q0 to -q4 (maps q0)
> -q5 to -q6 (q5 and q6 are effectively the same settings)
> -q7 to -q9 (maps to q7)
>
>
> Best regards,
> Maik
>
>
> Am 22.07.24 um 15:28 schrieb Tobias Damisch via Lame-dev:
>> Out of curiosity, I've run diff on files produced by -V9 -q0 and
>> -V9 -q4, and it turns out they are identical.
>> -q does absolutely nothing when using -V.
>>
>>
>> Am 22.07.24 um 14:37 schrieb Tobias Damisch via Lame-dev:
>>> I noticed that -V9 -q0 does sound identical to -V9 -q4 (at least on
>>> my Sony XM3s), also I cannot spot any difference in encoding time
>>> between the two (which I would expect from different -q settings, as is
>>> clearly the case when using -cbr).
>>>
>>> Also AFAIR this has been the case for a very, very long time.
>>>
>>> I don't know if this is to be expected and a trivial observation or if
>>> it does indeed add anything to the conversation.
>>>
>>> Just my 2 cents,
>>>
>>> Tobias
>>>
>>>
>>> Am 12.07.24 um 18:57 schrieb Maik Merten via Lame-dev:
>>>> 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
|
|
From: Maik M. <mai...@go...> - 2024-07-23 05:34:12
|
Hello Tobias, to clarify, -V is not the same as -q. They can be (and are used) in conjunction. -V selects the "audio quality" targeted by the VBR encoder (basically a quality-adaptive bitrate switch), while -q selects the algorithmic complexity (how much effort is spent in the encoder, basically encoding speed). The lower -V, the higher the bitrate. The lower -q, the higher "audio quality per bitrate" (or should be, but that's currently broken for CBR and ABR. VBR is fine.) Maik Am 23.07.24 um 00:24 schrieb Tobias Damisch via Lame-dev: > Thanks for the clarification Maik, now I understand! > > The man page kind of hints at what you explain, > but fails to mention clearly that q0 to q4 is absolutely the same to -V > and also that this setting of highest quality is the default anyway. > > Kind regards, > > Tobias |
|
From: Tobias D. <tob...@gm...> - 2024-07-23 10:02:16
|
Yeah I got that, my reply was ambiguously formulated, sorry.
I think the man page should mention something like:
"When in vbr mode, using -q0, -q1, -q2, -q3, -q4 or no -q at all will
result in the same settings and hence, identical files."
Now back to some actual problems, sorry for the spam!
Tobias
Am 23.07.24 um 07:33 schrieb Maik Merten via Lame-dev:
> Hello Tobias,
>
> to clarify, -V is not the same as -q. They can be (and are used) in
> conjunction.
>
> -V selects the "audio quality" targeted by the VBR encoder (basically a
> quality-adaptive bitrate switch), while -q selects the algorithmic
> complexity (how much effort is spent in the encoder, basically encoding
> speed).
>
> The lower -V, the higher the bitrate.
>
> The lower -q, the higher "audio quality per bitrate" (or should be, but
> that's currently broken for CBR and ABR. VBR is fine.)
>
> Maik
>
>
>
> Am 23.07.24 um 00:24 schrieb Tobias Damisch via Lame-dev:
>> Thanks for the clarification Maik, now I understand!
>>
>> The man page kind of hints at what you explain,
>> but fails to mention clearly that q0 to q4 is absolutely the same to -V
>> and also that this setting of highest quality is the default anyway.
>>
>> Kind regards,
>>
>> Tobias
>
>
>
> _______________________________________________
> Lame-dev mailing list
> Lam...@li...
> https://lists.sourceforge.net/lists/listinfo/lame-dev
|
|
From: Maik M. <mai...@go...> - 2024-07-25 15:44:04
|
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 |
|
From: Ross L. <ro...@st...> - 2024-07-25 23:06:36
|
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:lam...@li...] Sent: Friday, 26 July 2024 3:15 am To: lam...@li... 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 Lam...@li... https://lists.sourceforge.net/lists/listinfo/lame-dev |
|
From: Maik M. <mai...@go...> - 2024-07-26 04:07:26
|
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:lam...@li...] > Sent: Friday, 26 July 2024 3:15 am > To: lam...@li... > 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 > Lam...@li... > https://lists.sourceforge.net/lists/listinfo/lame-dev > > > > > _______________________________________________ > Lame-dev mailing list > Lam...@li... > https://lists.sourceforge.net/lists/listinfo/lame-dev |
|
From: Ross L. <ro...@st...> - 2024-07-26 04:31:10
|
I see. What's slowing down the encoding when using -q0 then? -----Original Message----- From: Maik Merten via Lame-dev [mailto:lam...@li...] Sent: Friday, 26 July 2024 4:07 pm To: lam...@li... 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:lam...@li...] > Sent: Friday, 26 July 2024 3:15 am > To: lam...@li... > 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 > 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 |
|
From: Maik M. <mai...@go...> - 2024-07-26 12:28:52
|
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:lam...@li...] > Sent: Friday, 26 July 2024 4:07 pm > To: lam...@li... > 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:lam...@li...] >> Sent: Friday, 26 July 2024 3:15 am >> To: lam...@li... >> 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 >> 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 |
Thanks for helping keep SourceForge clean.
X