Subject: Re: [linux-audio-dev] decoding mp3 files
From: Kristian Peters (kristian.peters_AT_korseby.net)
Date: Fri Jun 07 2002 - 21:03:46 EEST
Paul Davis <pbd_AT_op.net> wrote:
> i don't know precisely whats going on there, but mp3 is a *lossy*
> compression technique. whether or not the data size is the same or
> not, you will not get the same data back after the mp3 cycle as you
> started with. this isn't a decoder-specific issue - its inherent to
> the way mp3 works. comparing two wavs that have been through this
> process will never find them to be the same.
Yes. This is exactly what I want to do ! I wanna compare several codecs for their quality. But to do this the right way, the resulting wav must have the same length as the original one. And it seems that mpg123 produces a different output as "lame --decode" does..
But that was not my question. What I really want to know is how can I detect the amount of bytes the decoder adds before the real data starts ?
The lame-FAQ says this:
1. Why does LAME add silence to the beginning each song?
[...]
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.
[...]
Maybe that's too specific here... My program should work with any mp3 correctly.. Thus I've to know the size the decoder adds before the data starts.
*Kristian
:... [snd.science] ...:
:: _o)
:: http://www.korseby.net /\\
:: http://gsmp.sf.net _\_V
:.........................:
This archive was generated by hypermail 2b28 : Fri Jun 07 2002 - 21:05:05 EEST