MP3 Players and No-gap playback

Reply #75 – 2004-06-14 12:28:56

@ bennybenz
I'm obviously not Gabriel but I couldn't resist to comment on this.

Quote

How is there a frame inter-dependency (meaning one frame being dependent on an adjacent frame) between the DCT data itself, outside of byte-reservoiring?

In the synthesis step of the decoder the audio samples from the current frame are combined with the previously decoded samples (overlapping windows). This dependency of consecutive frames is in the very nature of the transformation used in encoder and decoder. It reduces (eliminates?) blocking artifacts that would be prominent if the transform windows didn't overlap.

Quote

Also, if you created MP3s from an album that completely filled all of their frames with actual song data, then how could any decoder not be able to play these MP3s gaplessly if it were to remove the ID3 data and abut each of the MP3s' song data as one continuous playback stream? I see no reason why not.

The reason is the transform overlap (as mentioned above) at the beginning of each file. If the decoder has no special "gapless" mode then it starts decoding of each new file with an empty (silent) transform buffer, which results in a small gap (silence) in the output.

Quote

Also, what information does LAME place in the header for gapless playback?

I don't know and leave that one for Gabriel or somebody else.

By the way:

The bit-reservoir works on a different level. It is part of the bit stream (encoded data). Its purpose is to provide some kind of "variable bitrate" even in CBR encoded streams. The bit-reservoir can be seen as a "dynamic buffer" inside the bitstream.

(F are frame headers, the numbers are the contents of the respective frames)

Ok, this is an illustration of a bitstream that does *NOT* use the bit-reservoir.

F 1111111111 F 2222222222 F 3333333333 F 4444444444 F...
You can see, frame headers and contents are nicely ordered.

Now, an illustration of a bitstream that *DOES* use the bit-reservoir:

F 1111122222 F 2333333333 F 3333333333 F 4444444555 F...
Here the frames 1 and 2 use less bits than they could, so they build up the reservoir. Frame 3 uses much more bits than its own frame could contain and uses additional bits from the reservoir. After frame 3 the reservoir capacity is reduced to 0 (zero), so the contents of frame 4 have to start right after the fourth frame header.
The different sizes of the frame contents result from the audio signal and how "difficult" it is to encode it.

Bit reservoir makes MP3 file splitting quite a challenging task because the beginning of the second piece must be modified by the splitter program to save the bit-reservoir contents that are actually located at the end of the first piece. Just try to image that you want to split the example from the second illustration between frame 2 and 3...

Hope this little (?) explanations makes sense to anybody.