Re: [MP3 ENCODER] Lame re-sampling bug?
Ooops ! But since he mentioned 19, what is the correct magic number ? maybe 10 is another one ? ;) - Original Message - From: "Frank Klemm" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 08, 2000 10:39 PM Subject: Re: [MP3 ENCODER] Lame re-sampling bug? | On Fri, Sep 08, 2000 at 06:48:49PM +0200, Steve Lhomme wrote: | Hum... | And if 19 is a magic value, why didn't you use the following ? | | BLACKSIZE = 200 | filter_l = (BLACKSIZE - 19) | | | David: can you run the same test with a stencil 10x bigger? | | To do this, change: | | | | BLACKSIZE = 200change in util.h | | filter_l = 191change in util.c | | | | 200 - 19 == 191 ??? | | -- | Frank Klemm | | -- | MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) | | | -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
On Fri, Sep 08, 2000 at 06:48:49PM +0200, Steve Lhomme wrote: Hum... And if 19 is a magic value, why didn't you use the following ? BLACKSIZE = 200 filter_l = (BLACKSIZE - 19) | David: can you run the same test with a stencil 10x bigger? | To do this, change: | | BLACKSIZE = 200change in util.h | filter_l = 191change in util.c | 200 - 19 == 191 ??? -- Frank Klemm 19 was just a bad coincidence :-) The size of the filter is given by filter_l, and it can be any odd number. But the amount of storage allocated is given by #define BLACKSIZE I think it is ok as long as filter_l BLACKSIZE. This is one of those coding practices Frank would be horrified by :-) I was too lazy to add malloc()'s in lame_init() and free()'s in lame_encode_finish for the two variables related to the filter, so they are explicitly dimensioned using BLACKSIZE. If filter_l BLACKSIZE, the code will stop with an error. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
Hum... And if 19 is a magic value, why didn't you use the following ? BLACKSIZE = 200 filter_l = (BLACKSIZE - 19) | David: can you run the same test with a stencil 10x bigger? | To do this, change: | | BLACKSIZE = 200change in util.h | filter_l = 191change in util.c | | If this improves results, then I guess we will have to | add yet another option :-) | | | | Ahh yesss... | | As you one remarked - yet another option nobody knows the ideal value | for ;-) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
On Fri, Sep 08, 2000 at 06:48:49PM +0200, Steve Lhomme wrote: Hum... And if 19 is a magic value, why didn't you use the following ? BLACKSIZE = 200 filter_l = (BLACKSIZE - 19) | David: can you run the same test with a stencil 10x bigger? | To do this, change: | | BLACKSIZE = 200change in util.h | filter_l = 191change in util.c | 200 - 19 == 191 ??? -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Lame re-sampling bug?
Hello all, this is a forward of a thread on http://bboard.mp3.com/mp3/ubb/Forum1/HTML/003127.html : OK, I gave in and did a quick resampling test. It shows why you shouldn't use lame to do your resampling. Here's three plots. 1) Original signal. 2) Resampled via Cool Edit, 3) Resampled via lame. http://privatewww.essex.ac.uk/~djmrob/mp3board/orig.gif This is my original test signal. You're looking at a spectral (frequency domain) plot. The time axis is samples. There's an upward tone sweep, some very quiet tones, then a downwards tone sweep with an 18kHz tone mixed in with it (the crossing green lines on the right). http://privatewww.essex.ac.uk/~djmrob/mp3board/cep.gif This is the test signal resampled to 32kHz by Cool Edit Pro, using the highest quality setting (999). Basically, you have what you had before, minus the stuff that was over 16kHz (which can't be represented in a 32kHz sampled system - Nyquist theorem). The background noise is slightly higher than I'd like (-84dB rather than -96dB - possible in CEP if you go into the 32-bit domain to do the resampling, then dither back to 16-bits), but overall, it's a pretty good resample. http://privatewww.essex.ac.uk/~djmrob/mp3board/lame.gif This is the result of the same resampling process, carried out by lame. As you can't just resample in lame, I used: lame --resample 32 -h -b 256 orig.wav lame.mp3 then decoded the mp3 using Winamp 2.22. You get the same thing encoding at 320kbps too. As you can see, lame adds some severe aliasing distortion. At it's worst, it's at about -24dB. The original sine wave was at -6dB. The distortion is at 14.5kHz which means it aliased from 17.5kHz - therefore whatever anti-alias filter lame is using has a -18dB rejection ratio at 17.5kHz. It should be down to -96dB or lower by then. What does this sound like? Well, on a simple test signal like this, the most audible problem is that as the frequency of the test tone increases beyond 16kHz, rather than continuing to increase beyond the range of your hearing, it starts coming down again. The ultrasonic part you shoudln't be able to hear is reflected back into the region where you CAN hear it. This is bad. The other problem is that you're effectively adding spectral components to the signal. This makes the job of an mp3 encoder harder - which ones should it discard? I used lame 3.86BETA for this test. CEP took 1 minute to resample this 20 second test file. By using a lower quality setting (256), it can do it in real time, and still do OK. Lowering the quality (increasing the speed) further degrades its performance. Lame can resample AND encode the signal in 9 seconds, which explains why it does such a poor job. Maybe someone working on lame can add an optional high quality resampling routine? Can someone on the mail list suggest it? Hope this is some interest. If it's not, ignore me! Any questions are welcome. David. http://www.David.Robinson.org/mp3decoders/ The truth about mp3 decoding quality updated. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
Bug is not the right word. Unless someone has been really screwing with the code. It's just not the most accurate way of doing it but it is reasonably fast. Trust me There are worse resampling routines in theis world. -- Scott Manley (AKA Szyzyg) Streaming Media Hacker www.myplay.com Listening to Music Like This Downtempo, Leftfield http://www.myplay.com/mp/nowpl/now_playing_frame.jsp?plid=273242start=1 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
This could very will be a bug, but it my also just be the correct resonce of the medium quality lowpass filter used by LAME. For resampling, LAME is using a 19 point lowpass filter with a Blackman window. The position of the window is adjusted to do the resampling at the same time. For a near-perfect filter, you need to use many more than 19 points (like thousands, and then it becomes benificial to use a lapped transform instead of an FIR filter) which will be much slower. CoolEdit may be doing something like that. Before we look for bugs, maybe David could test LAME with a larger filter size? David: can you run the same test with a stencil 10x bigger? To do this, change: BLACKSIZE = 200change in util.h filter_l = 191change in util.c If this improves results, then I guess we will have to add yet another option :-) Mark X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f Date: Thu, 7 Sep 2000 19:47:21 +0200 From: Roel VdB [EMAIL PROTECTED] X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Sender: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] Hello all, this is a forward of a thread on http://bboard.mp3.com/mp3/ubb/Forum1/HTML/003127.html : OK, I gave in and did a quick resampling test. It shows why you shouldn't use lame to do your resampling. Here's three plots. 1) Original signal. 2) Resampled via Cool Edit, 3) Resampled via lame. http://privatewww.essex.ac.uk/~djmrob/mp3board/orig.gif This is my original test signal. You're looking at a spectral (frequency domain) plot. The time axis is samples. There's an upward tone sweep, some very quiet tones, then a downwards tone sweep with an 18kHz tone mixed in with it (the crossing green lines on the right). http://privatewww.essex.ac.uk/~djmrob/mp3board/cep.gif This is the test signal resampled to 32kHz by Cool Edit Pro, using the highest quality setting (999). Basically, you have what you had before, minus the stuff that was over 16kHz (which can't be represented in a 32kHz sampled system - Nyquist theorem). The background noise is slightly higher than I'd like (-84dB rather than -96dB - possible in CEP if you go into the 32-bit domain to do the resampling, then dither back to 16-bits), but overall, it's a pretty good resample. http://privatewww.essex.ac.uk/~djmrob/mp3board/lame.gif This is the result of the same resampling process, carried out by lame. As you can't just resample in lame, I used: lame --resample 32 -h -b 256 orig.wav lame.mp3 then decoded the mp3 using Winamp 2.22. You get the same thing encoding at 320kbps too. As you can see, lame adds some severe aliasing distortion. At it's worst, it's at about -24dB. The original sine wave was at -6dB. The distortion is at 14.5kHz which means it aliased from 17.5kHz - therefore whatever anti-alias filter lame is using has a -18dB rejection ratio at 17.5kHz. It should be down to -96dB or lower by then. What does this sound like? Well, on a simple test signal like this, the most audible problem is that as the frequency of the test tone increases beyond 16kHz, rather than continuing to increase beyond the range of your hearing, it starts coming down again. The ultrasonic part you shoudln't be able to hear is reflected back into the region where you CAN hear it. This is bad. The other problem is that you're effectively adding spectral components to the signal. This makes the job of an mp3 encoder harder - which ones should it discard? I used lame 3.86BETA for this test. CEP took 1 minute to resample this 20 second test file. By using a lower quality setting (256), it can do it in real time, and still do OK. Lowering the quality (increasing the speed) further degrades its performance. Lame can resample AND encode the signal in 9 seconds, which explains why it does such a poor job. Maybe someone working on lame can add an optional high quality resampling routine? Can someone on the mail list suggest it? Hope this is some interest. If it's not, ignore me! Any questions are welcome. David. http://www.David.Robinson.org/mp3decoders/ The truth about mp3 decoding quality updated. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
Mark Taylor wrote: This could very will be a bug, but it my also just be the correct resonce of the medium quality lowpass filter used by LAME. For resampling, LAME is using a 19 point lowpass filter with a Blackman window. The position of the window is adjusted to do the resampling at the same time. For a near-perfect filter, you need to use many more than 19 points (like thousands, and then it becomes benificial to use a lapped transform instead of an FIR filter) which will be much slower. CoolEdit may be doing something like that. Before we look for bugs, maybe David could test LAME with a larger filter size? David: can you run the same test with a stencil 10x bigger? To do this, change: BLACKSIZE = 200change in util.h filter_l = 191change in util.c If this improves results, then I guess we will have to add yet another option :-) Ahh yesss... As you one remarked - yet another option nobody knows the ideal value for ;-) Upsampling uses a different algorithm - has anyone looked at that? -- Scott Manley (AKA Szyzyg) Streaming Media Hacker www.myplay.com Listening to Music Like This Downtempo, Leftfield http://www.myplay.com/mp/nowpl/now_playing_frame.jsp?plid=273242start=1 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
:: :: As you one remarked - yet another option nobody knows the ideal value :: for ;-) :: :: Upsampling uses a different algorithm - has anyone looked at that? :: Yes. Sounds bad. Especially CDs with some distortions above 15 kHz (dithering noise, 15.75 kHz or 16 kHz tones). -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
