You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(45) |
Dec
(48) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(55) |
Feb
(96) |
Mar
(28) |
Apr
(34) |
May
(46) |
Jun
(136) |
Jul
(25) |
Aug
(77) |
Sep
(107) |
Oct
(119) |
Nov
(142) |
Dec
(165) |
2002 |
Jan
(32) |
Feb
(58) |
Mar
(34) |
Apr
(64) |
May
(56) |
Jun
(30) |
Jul
(38) |
Aug
(30) |
Sep
(53) |
Oct
(89) |
Nov
(77) |
Dec
(67) |
2003 |
Jan
(53) |
Feb
(52) |
Mar
(2) |
Apr
(15) |
May
(34) |
Jun
(14) |
Jul
(23) |
Aug
(16) |
Sep
(24) |
Oct
(34) |
Nov
(40) |
Dec
(94) |
2004 |
Jan
(155) |
Feb
(147) |
Mar
(156) |
Apr
(78) |
May
(54) |
Jun
(79) |
Jul
(17) |
Aug
(26) |
Sep
(23) |
Oct
(10) |
Nov
(35) |
Dec
(41) |
2005 |
Jan
(8) |
Feb
(52) |
Mar
(69) |
Apr
(19) |
May
(44) |
Jun
(50) |
Jul
(42) |
Aug
(84) |
Sep
(60) |
Oct
(51) |
Nov
(126) |
Dec
(104) |
2006 |
Jan
(54) |
Feb
(21) |
Mar
(38) |
Apr
(28) |
May
(39) |
Jun
(91) |
Jul
(39) |
Aug
(26) |
Sep
(135) |
Oct
(120) |
Nov
(146) |
Dec
(129) |
2007 |
Jan
(188) |
Feb
(48) |
Mar
(16) |
Apr
(28) |
May
(56) |
Jun
(67) |
Jul
(88) |
Aug
(45) |
Sep
(32) |
Oct
(30) |
Nov
(59) |
Dec
(26) |
2008 |
Jan
(39) |
Feb
(8) |
Mar
(32) |
Apr
(34) |
May
(48) |
Jun
(100) |
Jul
(73) |
Aug
(93) |
Sep
(42) |
Oct
(30) |
Nov
(24) |
Dec
(16) |
2009 |
Jan
(29) |
Feb
(56) |
Mar
(70) |
Apr
(54) |
May
(24) |
Jun
(28) |
Jul
(17) |
Aug
(6) |
Sep
(15) |
Oct
(32) |
Nov
(11) |
Dec
(16) |
2010 |
Jan
(5) |
Feb
(55) |
Mar
(52) |
Apr
(54) |
May
(7) |
Jun
(33) |
Jul
(27) |
Aug
(34) |
Sep
(11) |
Oct
(18) |
Nov
(15) |
Dec
(35) |
2011 |
Jan
(14) |
Feb
(39) |
Mar
(39) |
Apr
(46) |
May
(85) |
Jun
(17) |
Jul
(53) |
Aug
(23) |
Sep
(7) |
Oct
(38) |
Nov
(34) |
Dec
(22) |
2012 |
Jan
(72) |
Feb
(36) |
Mar
(19) |
Apr
(6) |
May
(12) |
Jun
(12) |
Jul
(28) |
Aug
(15) |
Sep
(2) |
Oct
(25) |
Nov
(2) |
Dec
(4) |
2013 |
Jan
(8) |
Feb
(14) |
Mar
(14) |
Apr
(3) |
May
(3) |
Jun
(16) |
Jul
(8) |
Aug
(2) |
Sep
(14) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
2014 |
Jan
(9) |
Feb
(5) |
Mar
(6) |
Apr
(5) |
May
(2) |
Jun
(6) |
Jul
(4) |
Aug
(1) |
Sep
(11) |
Oct
(3) |
Nov
(14) |
Dec
|
2015 |
Jan
(3) |
Feb
(8) |
Mar
(4) |
Apr
(6) |
May
(25) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(10) |
Nov
|
Dec
(3) |
2016 |
Jan
(9) |
Feb
(4) |
Mar
(7) |
Apr
(1) |
May
(4) |
Jun
|
Jul
(3) |
Aug
|
Sep
(3) |
Oct
|
Nov
(2) |
Dec
|
2017 |
Jan
|
Feb
(6) |
Mar
(6) |
Apr
(5) |
May
(9) |
Jun
(14) |
Jul
(19) |
Aug
(64) |
Sep
(25) |
Oct
(38) |
Nov
(7) |
Dec
(1) |
2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
(7) |
Jun
|
Jul
(9) |
Aug
(3) |
Sep
(8) |
Oct
(2) |
Nov
(1) |
Dec
|
2019 |
Jan
(1) |
Feb
(1) |
Mar
(9) |
Apr
|
May
(2) |
Jun
(14) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(5) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(13) |
Jun
(2) |
Jul
(4) |
Aug
(9) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
2021 |
Jan
|
Feb
|
Mar
(20) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
(1) |
Mar
(12) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
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 |
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 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-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-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: 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-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-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-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 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: 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: 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: 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-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-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-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-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: 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: Karel B. <ba...@ma...> - 2023-10-14 07:11:37
|
Hello, I attach a simple patch which fixes writing ID3 tags on musl and probably also other non-glibc platforms. The problem was that TRANSLIT is a glibc-specific iconv extension making the call to iconv_open fail on musl and causing lame not to write the tags at all (except for numeric ones if I recall correctly) without indicating any error. This patch uses transliteration only when __GNU_LIBRARY__ is defined which should be a reliable way to detect glibc. The patch was originally written for Void Linux [1] and it seems that it has been adopted by at least Alpine [2] as well. [1] https://github.com/void-linux/void-packages/pull/43550 [2] https://git.alpinelinux.org/aports/tree/main/lame/id3tagfix.patch Best regards, K. B. |
From: Kris F. <kfe...@ma...> - 2023-10-12 11:17:48
|
Thanks, Thomas! Yeah, I am a bit more familiar with git workflows, but I now also see that people have mostly been contributing to LAME project via .patch files (here: https://sourceforge.net/p/lame/patches/). So that does seem like the best way forward. I have already created https://sourceforge.net/p/lame/feature-requests/84/ and https://sourceforge.net/p/lame/patches/99/ previously, so I think I can just attach a .patch file there. Appreciate your guidance! Kris From: Thomas Orgis via Lame-dev <lam...@li...> Date: Tuesday, 10 October 2023 at 18:33 To: lam...@li... <lam...@li...> Subject: Re: [Lame-dev] support for ID3v2.4 (UTF-8) When you got something that works, you can just post a patch here as attachment. Git(hub) workflow with merge request is not the only mode of operation. Discussing the patch here or as attachment to a bug tracker item should both work. A bug tracker item would be good to preserve the patch for people to find in case the devlopers don't have time to integrate them soon. Looking at the bug tracker and the time of the last release... some fresh activity would do the project good. (I myself are no active Lame developer, but at some point I worked on libmpg123 integration.) Alrighty then, Thomas _______________________________________________ Lame-dev mailing list Lam...@li... https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev> |
From: David M. C. <da...@kj...> - 2023-10-10 17:56:23
|
I’d love it if we’d all move to GIT > On Oct 10, 2023, at 10:05 AM, Kris Fedorenko via Lame-dev <lam...@li...> wrote: > > Hi LAME developers and users, > > I am still interested in trying to contribute my patch for writing UTF-8 ID3v2.4 tags to LAME. Should I do it on sourceforge (https://sourceforge.net/p/lame/svn/HEAD/tree/)? I do not see a way to fork the project... Would appreciate any help! > > Thanks, > Kris > > From: Kris Fedorenko via Lame-dev <lam...@li... <mailto:lam...@li...>> > Date: Saturday, 20 May 2023 at 17:56 > To: lam...@li... <mailto:lam...@li...> <lam...@li... <mailto:lam...@li...>> > Subject: Re: [Lame-dev] support for ID3v2.4 (UTF-8) > Hi LAME developers and users, > > I have taken a stab at making LAME write UTF-8 ID3v2.4 tags. I think it works correctly, although it is a bit hacky at the moment... If I have time, should I try to clean it up and do a merge request? Would somebody be available to review it and is there anything I need to know about contributing to LAME? > > Thanks, > Kris > > From: Kris Fedorenko via Lame-dev <lam...@li...> > Date: Wednesday, 22 March 2023 at 10:27 > To: lam...@li... <lam...@li...> > Subject: [Lame-dev] support for ID3v2.4 (UTF-8) > Hi LAME developers and users! > > It would be really great if LAME supported writing ID3v2.4 tags. Adoption of ID3v2.4 is growing (came out over 20 years ago!) and in general, UTF-8 is definitely the way forward. > > It doesn't look like there is any active development going on... But any rumors about this or any interest in making this happen? I posted this on sourceforge as a feature request too: https://sourceforge.net/p/lame/feature-requests/84/<https://sourceforge.net/p/lame/feature-requests/84><https://sourceforge.net/p/lame/feature-requests/84<https://sourceforge.net/p/lame/feature-requests/84>> <https://sourceforge.net/p/lame/feature-requests/84/%3Chttps://sourceforge.net/p/lame/feature-requests/84%3E%3Chttps://sourceforge.net/p/lame/feature-requests/84%3Chttps://sourceforge.net/p/lame/feature-requests/84%3E%3E> > Depending on my availability, I might be interested in helping out with this/taking a stab at it... > > Thanks, > Kris > > _______________________________________________ > Lame-dev mailing list > Lam...@li... <mailto:Lam...@li...> > https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev><https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev>> <https://lists.sourceforge.net/lists/listinfo/lame-dev%3Chttps://lists.sourceforge.net/lists/listinfo/lame-dev%3E%3Chttps://lists.sourceforge.net/lists/listinfo/lame-dev%3Chttps://lists.sourceforge.net/lists/listinfo/lame-dev%3E%3E> > > _______________________________________________ > Lame-dev mailing list > Lam...@li... > https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev> > > _______________________________________________ > Lame-dev mailing list > Lam...@li... > https://lists.sourceforge.net/lists/listinfo/lame-dev |
From: Thomas O. <tho...@or...> - 2023-10-10 17:32:29
|
When you got something that works, you can just post a patch here as attachment. Git(hub) workflow with merge request is not the only mode of operation. Discussing the patch here or as attachment to a bug tracker item should both work. A bug tracker item would be good to preserve the patch for people to find in case the devlopers don't have time to integrate them soon. Looking at the bug tracker and the time of the last release... some fresh activity would do the project good. (I myself are no active Lame developer, but at some point I worked on libmpg123 integration.) Alrighty then, Thomas |
From: Kris F. <kfe...@ma...> - 2023-10-10 17:22:19
|
Hi LAME developers and users, I am still interested in trying to contribute my patch for writing UTF-8 ID3v2.4 tags to LAME. Should I do it on sourceforge (https://sourceforge.net/p/lame/svn/HEAD/tree/)? I do not see a way to fork the project... Would appreciate any help! Thanks, Kris From: Kris Fedorenko via Lame-dev <lam...@li...> Date: Saturday, 20 May 2023 at 17:56 To: lam...@li... <lam...@li...> Subject: Re: [Lame-dev] support for ID3v2.4 (UTF-8) Hi LAME developers and users, I have taken a stab at making LAME write UTF-8 ID3v2.4 tags. I think it works correctly, although it is a bit hacky at the moment... If I have time, should I try to clean it up and do a merge request? Would somebody be available to review it and is there anything I need to know about contributing to LAME? Thanks, Kris From: Kris Fedorenko via Lame-dev <lam...@li...> Date: Wednesday, 22 March 2023 at 10:27 To: lam...@li... <lam...@li...> Subject: [Lame-dev] support for ID3v2.4 (UTF-8) Hi LAME developers and users! It would be really great if LAME supported writing ID3v2.4 tags. Adoption of ID3v2.4 is growing (came out over 20 years ago!) and in general, UTF-8 is definitely the way forward. It doesn't look like there is any active development going on... But any rumors about this or any interest in making this happen? I posted this on sourceforge as a feature request too: https://sourceforge.net/p/lame/feature-requests/84/<https://sourceforge.net/p/lame/feature-requests/84><https://sourceforge.net/p/lame/feature-requests/84<https://sourceforge.net/p/lame/feature-requests/84>> Depending on my availability, I might be interested in helping out with this/taking a stab at it... Thanks, Kris _______________________________________________ Lame-dev mailing list Lam...@li... https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev><https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev>> _______________________________________________ Lame-dev mailing list Lam...@li... https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev> |
From: Kris F. <kfe...@ma...> - 2023-05-19 18:16:16
|
Hi LAME developers and users, I have taken a stab at making LAME write UTF-8 ID3v2.4 tags. I think it works correctly, although it is a bit hacky at the moment... If I have time, should I try to clean it up and do a merge request? Would somebody be available to review it and is there anything I need to know about contributing to LAME? Thanks, Kris From: Kris Fedorenko via Lame-dev <lam...@li...> Date: Wednesday, 22 March 2023 at 10:27 To: lam...@li... <lam...@li...> Subject: [Lame-dev] support for ID3v2.4 (UTF-8) Hi LAME developers and users! It would be really great if LAME supported writing ID3v2.4 tags. Adoption of ID3v2.4 is growing (came out over 20 years ago!) and in general, UTF-8 is definitely the way forward. It doesn't look like there is any active development going on... But any rumors about this or any interest in making this happen? I posted this on sourceforge as a feature request too: https://sourceforge.net/p/lame/feature-requests/84/<https://sourceforge.net/p/lame/feature-requests/84> Depending on my availability, I might be interested in helping out with this/taking a stab at it... Thanks, Kris _______________________________________________ Lame-dev mailing list Lam...@li... https://lists.sourceforge.net/lists/listinfo/lame-dev<https://lists.sourceforge.net/lists/listinfo/lame-dev> |
From: Kris F. <kfe...@ma...> - 2023-03-21 17:20:52
|
Hi LAME developers and users! It would be really great if LAME supported writing ID3v2.4 tags. Adoption of ID3v2.4 is growing (came out over 20 years ago!) and in general, UTF-8 is definitely the way forward. It doesn't look like there is any active development going on... But any rumors about this or any interest in making this happen? I posted this on sourceforge as a feature request too: https://sourceforge.net/p/lame/feature-requests/84/ Depending on my availability, I might be interested in helping out with this/taking a stab at it... Thanks, Kris |