The additional data at the beginning and end of the mp3 files is caused by the need of ovxerlapping frames for the transformation between the time and frequency domain. The length of added samples should be mostly stable: There is only a very finite number of possibilities and it should be easy to detect. So by looking into the wave files (with some sound editor) you should be able to determine that.
I expect about 1200 - 1230 added zeros at the beginning. The number of added zeroes in the end can vary. There is a finite number of possibilities from the mp3 algorithm (like for the beginning), plus a number of zero padding samples that is depend on the size of the original wav-file. (In order to fill up frames). So a possible strategy: 1.) Discard leading zeros (could be automatically detected) 2.) Determine length of original wav-file. 3.) Discard any additional samples at the end. Hope that helps. -M Kristian Peters wrote: >Hello. > >I have encoded a wav to a mp3. But when decoding it back, the wav is slightly bigger >as the original. > >for example: >$ ls -l >-rw-r--r-- 1 kristian adlib 4079698 Jun 7 14:24 H-diff.mp3 >-rw-r--r-- 1 kristian adlib 44969704 Jun 7 15:03 H-diff.wav >-rw-r--r-- 1 kristian adlib 44965580 Jun 5 13:58 H-src.wav > >I read in the lame-FAQ that this is the intended behaviour. (Cause of some technical >reason I don't understand yet.) Are there some differences between all the decoders >out there ? > >I'm currently writing a program that compares wav's and saves the differences to >another file. So it's reasonable bad having an extra chunk of bytes at the beginning >of the data in the wav-file. Is there any specification how to ignore these extra >bytes or to know the size of this extra chunk ? (It's no problem ignoring extra bytes >at the end of the wave...) > >Thank you ! > >*Kristian > > :... [snd.science] ...: > :: _o) > :: http://www.korseby.net /\\ > :: http://gsmp.sf.net _\_V > :.........................: >
