I found something very weird when fooling aroung with audacity today. I was comparing two rips I had made with EAC, both had identical CRCs in the log file except one was compressed with FLAC and one was compressed with LAME v3.97b. Anyways I was zooming in until I could see the individual samples in each version of the rip and at that level they looked completly different. "Wow, perceptual encoding is amazing, it can sound exactly like the original encoding yet have massive differences on a small scale", I remarked to myself. I then zoomed out a bit and to my surprise I spotted that the waves were infact pretty much carbon copies only the mp3 was 50ms ahead of the FLAC at all positions in the song. What's the cause of this? Is it a bug in MP3, FLAC, Audacity or what?

PS: I'm a total n00b when it comes to things like this so please dont flame If what I have noticed is completely run-of-the-mill stuff

Here's a screenie:

This is caused by encoder padding (inserts silent frames in the beginning). It is not a bug.

J.M.

Alrighty then:). Is there a point to this "encoder padding"?

As fas as I know, it makes gapless playpack possible.

Read http://en.wikipedia.org/wiki/Gapless_playback which links to http://lame.sourceforge.net/tech-FAQ.txt

Just to clarify a few things in this thread:

* padding : padding is adding bytes of data, which are not needed. padding is done in a frame by frame, and most usually in CBR files, in order to fill the space to complete the packet size..

* gapless : The effect of having an empty *audio* space at the beginning and the end of the file is the consequence of how MP3 (as well as mp4 and others) compression works. It causes a "delay" between the data generation and the output.
This is precisely what causes songs to *not* be gapless.
LAME adds extra info in its tag where it specifies exactly how many bytes (samples actually) the decoder has to cut off to remove this silence of audio which doesn't belong to the audio.
Of course, this requires the decoder to know about the LAME tag and its gapless values.

Frame padding, which you mention, sounds unrelated to the sample padding which is removed on decoding.