There are a few potential problems with splitting an MP3 bitstream into multiple files. One is keeping the bit reservoir intact. Unlike other layers, Layer III frames are not atomic; the beginning of each frame's audio data usually comes before the frame header. If you want to split the bitstream without losing any audio information, you would need to preserve this reservoir -- probably by creating a silent frame at the beginning of the split point (for the beginning of the second file.) However, this could be the source of a gap; to make this gapless you would need to tell the decoder not to play the first frame during playback.

Even this isn't perfect. A better way to do splits would be to duplicate the frame at the end of the split point, because there is actually another small dependency on the previous frame's windowed IMDCT output. So you would want two extra frames at the beginning of the split point, one to hold the bit reservoir for the dependent frame, and one for the dependent frame (which also holds the bit reservoir for the logical beginning of the split.) The decoder would process these two frames but not begin playing audio until the next frame.

Unfortunately there aren't any standards that I know of, defacto or otherwise, for managing any of this. Most of the issues people have arrise because MP3 is a streaming format, not a file format. An intelligent encoding and playback system needs to be aware of these issues in order to provide the tools and services that do the Right Thing. I don't think we're there yet, but we aren't too far either.

I like Bonzi's idea of having a single large MP3 bitstream with a meta index to individual tracks; jumping around in the bitstream isn't so much of a problem.

-v