2.  Why does LAME add silence to the beginning each song?



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.  



==========================================================================

3.  Why does LAME add silence to the end of each song?


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.  And in lame3.80,

we finally fixed the bitstream flushing so that the final mp3

frame is properly padded with ancillary data.  




찾아보니까 MP3 인코딩에 가장 많이 쓰이는 LAME 인코더 때문에 발생하는 문제인듯