So the recent discusions of the 96/576 sample attenuation problem for the very first frame led me to take a closer look at the filterbank/MDCT routines. The total delay of these routines is only 48 samples. However, they do assume the first 286 samples of the buffer have already been processed by the last call to mdct_sub48. So for the first frame, this resulted in treating the first 286 samples as though they were zero. Not a problem because LAME's default encoder delay is 576, but it is a problem if you want to test values of ENCDELAY below 286. This is now fixed: during initialization, mdct_sub48 will be "primed" with the correct data, and then when it is called to process the first frame, the 286 samples will already be in the internal mdct buffers. So you can now actually use a delay as low as 96. If you get the latest version from CVS, you can check this out with the frame analyzer: set ENCDELAY = 96 and encode something like a square wave (or anything with a sharp attack). Take a look with the frame analyzer, encoding at 320kbs. There is very little attenuation of the data after 96 samples, however there is some small amplitude distortion visable in the plots, which is mostly gone a short way into the second granule. I believe this is the filterbank contamination I mentioned earlier, and the extent of the contamination beyond the 96 samples does seem to be around 512 samples. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
