> X-Authentication-Warning: geek.rcc.se: majordom set sender to
>[EMAIL PROTECTED] using -f
> Date: Wed, 05 Jul 2000 13:36:37 +0200
> From: Istvan Varga <[EMAIL PROTECTED]>
> X-Accept-Language: en
> Content-Type: text/plain; charset=us-ascii
> Sender: [EMAIL PROTECTED]
> Precedence: bulk
> Reply-To: [EMAIL PROTECTED]
> X-UIDL: ==]!!R7P"!4f%#!#H'!!
>
> The decoder in LAME seems to calculate delays incorrectly: when
> encoding in CBR format and decoding back, the delay is 1 sample,
> and in the case of VBR streams, the decoded file has a large
> delay (several hundred samples).
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
I just confirmed this for CBR. But for VBR I also get a delay
off by only 1 sample, not hundreds.
I guess no one has ever looked this closely before :-)
I have no idea where this could come from. The whole
process is symmetric (filterbank, MDCT, inverst MDCT, inverse filterbank)
so the total delay should come out even. If anyone is
really interested, try:
MDCT followed by iMDCT (using MPEG routines). Delay should
be 2*9. In MP3, there are 32 banks, so the total delay
is 2*288 (288 for each transform)
filterbank followed by inverse filterbank. Delay should
be 2*240.
Those estimates are derived from looking at the algorithms
involved, and agree with observations to within 1 sample :-)
Here's a half-baked theory to explain this 1 sample:
The filterbank: As far as I'm concerned, it is a black box which holds
512 samples. You shift in 32 samples at a time, and get 32 samples
out. I always assumed these 32 samples came from the center of the
512 sample window = samples [240,271]. Distance between samples
[240,271] and [0,31] = 240 (the delay given above). But if you treat
the window as *periodic*, with period 512, then the center of the
window is actually samples [240.5,271.5], giving a delay of 240.5.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
