Within the last two weeks, 3 people asked about the extra padding
of silence you get at the beginning and end of an encoded file.
I wrote an answer, and thought maybe it is time to start a FAQ, or
at least add this to Mike's documentation: (comments & criticisms
welcome, of course)
1. Why does LAME add silence to the beginning and end of each song?
This is because of several factors:
DECODER DELAY AT START OF FILE:
The *decoders* we've tested (mpg123, xmms) introduce a delay of 528
samples. That is, after decoding an mp3 file, the output will have
528 samples of 0's appended to the front. This is because the
standard MDCT/filterbank routines used by the ISO have a 528 sample
delay. It would be possible to write a MDCT/filterbank routine with a
0 sample delay (see description of Takehiro's MDCT/filterbank routine
used in LAME encoding below) but I dont know that anyone has done
this. Furthermore, because of the overlapped nature of MDCT frames,
the first half of the first granule (1 granule=576 samples) doesn't
have a previous frame to overlap with, resulting in attenuation of the
first N samples. The value of N depends on the window type. For
"STOP_TYPE" and "SHORT_TYPE", N=96, while for "START_TYPE" and
"NORMAL_TYPE", N=288. The first frame produced by LAME 3.56 and up
will always be of STOP_TYPE or SHORT_TYPE.
ENCODER DELAY AT START OF FILE:
ISO based encoders (BladeEnc, 8hz-mp3, etc) use a MDCT/filterbank
routine similar to the one used in decoding, and thus also introduce
their own 528 sample delay. A .wav file encoded & decoded will have a
1056 sample delay (1056 samples will be appended to the beginning).
The FhG encoder introduces a 1160 sample delay, for a total
encoding/decoding delay of 1688 samples. I haven't tested
Xing.
Starting with LAME 3.55, we have a new MDCT/filterbank routine written
by Takehiro Tominaga with a 48 sample delay. With even more rewriting,
this could be reduced to 0. And there is no reason an inverse routine
could not be used in a decoder. However, there are a few problems
with using such a short delay:
1.) The psycho-acoustics for the first mp3 frame cannot be processed
until the encoder gets the second frame of input data. Thus
lame_encode() buffers the first frame and does not encode it until
given a second frame of input data.
2.) The 96 samples of the first frame are attenuated by the MDCT
window. If the encoder delay is greater than 96, this window will
have no effect since the first 96 samples are all padding. With a
48 sample encoder delay, the first 48 samples will be improperly
attenuated. (.001 seconds worth of data at 44.1kHz).
3.) In LAME, psycho-acoustics for the first 576 granule are not correct.
This could be fixed, but at the expense of adding more buffering
and code complexity.
If points 2. or 3. bother you, you can increase the encoder
delay by setting ENCDELAY in encoder.h. Set it to 576 to avoid
all possible problems.
PADDING AT THE END OF A FILE
Extra padding at the end of a file can be caused by a couple of things:
1. Because the MDCT's are overlapped, it looks something like this:
<--576 MDCT coefficients--><--576 MDCT coefficients--><--576 MDCT coefficients-->
<-- 576 samples PCM output --><-- 576 samples PCM output -->
So no matter where you truncate your MP3 file, the last 288 samples of
that granule will not be decoded. So LAME appends 288 samples of
padding to the input file to guarantee all input samples will be
decoded.
2. If the number of samples is not an exact multiple of 1152,
then last frame of data is padded with 0's so that it has 1152 samples.
Before lame3.56, we just added a few extra frames to make sure all
internal buffers would be flushed. In lame3.56, we tried to pad
with the exact minimum number of samples needed.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
