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 = 200 change in util.h
filter_l = 191 change 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/ )
