Question -- can anyone confirm my understanding of how the so-called Xing/Info tag's enc_delay and enc_padding fields are supposed to work?
I have a 206,240-sample 16-bit .WAV file which, when encoded with LAME 3.97, yields enc_delay=576 and enc_padding=1696. My understanding is that these values are the number of samples that need to be skipped at the beginning and end of the decoded data in order to yield the exact number of samples from the original .WAV file; i.e., for looping purposes.
However, the beginning of the original .WAV PCM sample actually ends up near sample 2258 in the decoded .MP3 file, according to both Sound Forge's and my own MP3 decoder. The end of the original .WAV is near 208,498, or 1158 samples from the end of the 209,656-sample file (i.e., about one 1152-sample frame).
How can I reconcile these figures? Obviously the first 1152-sample frame is devoted to LAME's Xing/Info tag itself, but even accounting for that, there are certainly more than (1152+576) samples between the beginning of the decoded PCM data and the first sample from my original data.
Likewise, the 1696-sample end padding figure makes no sense at all. If I look 1696 samples back from the end of the decoded file, I end up in the middle of some valid audio data.
TIA for any comments on where I might be going wrong.
