> I'm really sorry for being ignorant and bugging you all for it, and surely
> this has at one time been explained in this list.
>
> But... could somebody quickly explain just what pre-echo is all about? And
> why is it, that LAME has some problems with it, compared to mp3enc?
>
> Ivo
>
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
Take a look at:
www.sulaco.org/mp3/webpages/screenshots/screenshots.html
It has screenshots of a .wav file and the decode mp3 file created
by four different encoders. The results from the ISO code
have very bad pre-echo.
pre-echo is just classical Gibbs oscillations, which is seen
any time you use a fourier-type series expansion to represent
non-smooth data. When you have something like a sharp attack
(like a castanet or symbol), the MDCT representation of this data will
(after quantization) create a lot of oscillations both before and
after the attack.
The oscillations in front of the attack are very bad, since they will
be heard *before* the attack, and are very obvious to the human ear.
It often sounds like a snare has been added to the original track.
Switching to short blocks will isolate the attack to 192 sample
window, so the oscillations are only spread over 192 samples
instead of 576. And adding extra bits from the reservoir
will also reduce the oscillations. Xing does not use short blocks,
but still gets ok pre-echo control by using lots
of bits in the frames where LAME or mp3enc would also switch
to short blocks.
LAME is now quite good at detecting pre-echo - I think just as good as
mp3enc. The algorithm in LAME has been highly tuned both by listening
tests and making sure it switches to short blocks in the same
situations when mp3enc switches to short blocks. But mp3enc still
seems to be slightly better at encoding short blocks, which gives it a
slight edge at 128kbs.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
