Subject: Re: [linux-audio-dev] decoding mp3 files
From: Martin Wolters (martinw_AT_atc.creative.com)
Date: Fri Jun 07 2002 - 20:45:33 EEST
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
> :.........................:
>
This archive was generated by hypermail 2b28 : Fri Jun 07 2002 - 20:37:19 EEST