Google了一下,lame的编码,他们的解释是这样的.<div>http://lame.sourceforge.net/tech-FAQ.txt</div><div>================================</div><div><span style="line-height: normal; white-space: pre-wrap;">2. Why does LAME add silence to the beginning each song?</span><pre style="line-height: normal; word-wrap: break-word; white-space: pre-wrap;">
This is because of several factors:
DECODER DELAY AT START OF FILE:
All *decoders* I have tested 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).
(actually, the observed delay is 1057 samples. For even more
technical discussions about this, see the mp3encoder mailing list
archive)
The FhG encoder (at highest quality) 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 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).
2.) Filterbank contamination problems. This it rather technical, see
below.
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 1. 2. or 3. do not bother you, you can decrease the
the encoder delay by setting ENCDELAY in encoder.h. The default
right now is 576.
More technical details on very short ENCDELAY:
Here is an example:
granule 1 granule 2
576 samples 576 samples
| 192 | 192 | 192 | 192 | 192 | 192 |
data: < all zeros' >< real data >
short block <--------->
<--------->
<--------->
end block <---------------------->
output: | 192 | 192 | 192 |
granule 2 is the first granule that is encoded. granule 1 is
the fictitious previous granule that doesn't really exist, except
that the output of the decoder for granule 2 is going to be combined with
the data in the buffer which would have held the decoded output of
granule 1. I will assume the decoder initializes this buffer with
zeros.
Lets ignore quantization. The lapped MDCT followed
by the IMDCT is lossless. That means that the IMDCT output
from granule 2 when added to the IMDCT output from granule 1
is identical to the input.
In our case, the decoder just sets the granule 1 IMDCT output to all
0's because it never actually computes this and is just initializing a
buffer. But the output of granule 2 IMDCT is computed correctly.
output = granule_1_output + granule_2_output
granule_1_output: encoder uses all 0's, which is incorrect since
the MDCT (if it was performed) would have seen
some of the data in granule 2.
granule_2_output: correct
Therefor, the output will be correct *except* where it uses data from
granule 1, but this can effect at most the first 96 samples.
However, the polyphase filterbank is another story:
The data (with first 96 samples corrupt) is then sent to the
inverse polyphase filterbank. I dont know much about how this
albatross works, but I think it has an effective window length of
512. So the bad data in the first 96 samples can corrupt
samples up to 96+512. </pre><pre style="line-height: normal; word-wrap: break-word; white-space: pre-wrap;">============================</pre><pre style="line-height: normal; word-wrap: break-word; white-space: pre-wrap;">希望对您有帮助.
</pre></div><div><br></div>