Hi Tony,

In my experience, there might be a little "volume drop" at the gap point because the bit reservior is effectively null at that point, but whenever I play the trimmed files, I never get any added noise.

There are two other things working against you besides the bit reservoir. FWIW, the frames for which the bit reservoir holds data can no longer be decoded (except for the header and some side information) once severed from the reservoir, so they essentially no longer serve any purpose except to supply future frames with a reservoir. Whether a decoder produces any output (like silence) or just skips the frames is a question of the implementation -- I'm not sure what Xaudio does or what the upcoming ARM decoder will do.

The two things working against you are the Layer III IMDCT overlap outputs and the synthesis polyphase filterbank. Both carry state across frames, and both are typically reset across files. The only way to handle gapless playback seamlessly is in the decoder, although there are a few possible methods.

The most obvious method is to avoid resetting the decoder across files. This is probably only a good idea if the decoder is aware the next file is a continuation of the current...

I've thought about this a lot, and I wonder if it wouldn't be a bad idea to use the private bit in the frame header to instruct the decoder that the current file is a continuation, i.e. the decoder should not reset its state from the end of the previous file. If the decoder reads but does not process frames as long as the private bit is set, this could also be used to restore the bit reservoir. The result would be real gapless playback. All you would need to do when splitting a file is to repeat a few frames from the end of one file at the beginning of the next, setting the private bit in the process. (It's not hard to look at the bit reservoir to figure out how many frames are necessary.)

What do you think?

This is probably only useful for splitting large files into smaller ones; it doesn't address the problem of gapless playback across individual files each encoded separately. I still think that problem requires knowledge of the original PCM source length.

Kudos, Tony, for making a useful tool, regardless whether better gapless playback becomes a reality.

Cheers,
-v