Help - Search - Members - Calendar
Full Version: Help with encoder delay and padding in LAME
Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - Tech
John Miles
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.
kjoonlee
QUOTE (kjoonlee @ Aug 12 2006, 17:13) *
John Miles
QUOTE (kjoonlee @ Oct 19 2006, 21:22) *
QUOTE (kjoonlee @ Aug 12 2006, 17:13) *



Thanks -- that does explain the discrepancy at the beginning of the file. 528 (from the decoder) plus 576 (from LAME) plus 1152 for the info frame = 2256 samples, which is a good match for the silent period I see in the decoded output.

However, it's still not clear what is up with the trailing data. The math almost works if 528 more samples are added to the end of the file before subtracting the enc_padding amount, but it's far enough off (7 or 8 samples of valid data are truncated) that I don't think that's the right answer. This seems to be a case where the decoder is actually failing to flush its (normally silent) last half-frame. I'll look into that a little more closely; we seem to do exactly what SoundForge does, but there's no guarantee that's right.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.