I tried cutting MP3 files using Medieval CUE Splitter version 1.0, MP3Cutter 4, mp3DirectCut 2.07 and mp3splt 2.1. All these programs simply cut the file at a frame boundary, which is wrong due to dependencies between frames.

Right after the 4 byte MP3 frame header (in side information) there is a 9 bit value, main_data_begin, which tells the decoder how far back main data for that frame starts. This is used to implement the bit reservoir. The value must be zero at the start of an MP3 file (because the first frame can't refer to previous frames), but it might not be zero in the middle. When a file is cut something needs to be done to fix this. It seems that if I use mp3packer to convert a file to 320 kbps minimizing the bit reservoir ("mp3packer -r -b 320 file.mp3") the frames are independent. Later the cut files can be packed to VBR using mp3packer.

The second dependency is from overlapping transforms. According to what I've read the first granule depends on the previous frame and the second granule depends on the next frame. To get around this at a split I prepend the last frame of the previous file to the file that's beginning. I set the zero padding to 576 (granule size) on the previous file and I set encoder delay to 576 (granule size and also LAME encoder delay) on the file that's beginning. Splits done this way seem to be perfect. Winamp 5.531 and 1.4.0 output the same data they output with the whole file.

These files also appear to play gaplessly on my 5th generation iPod running firmware 1.3 as long as I don't use the menus or seek within the track. Gapless encodes seem to have the same problem, so I guess this is just the iPod firmware sucking and not a problem with my cutting method.

LAME gapless encodes seem to have longer zero padding, as if in some cases an extra frame is added to the end of the track. I can understand the need to add an extra frame if the end of the track happens within the second granule, but why add a frame if it happens in the first granule? Is it a workaround for buggy MP3 decoders which cannot play the last frame?

Note that my split is done with frame granularity, not sample granularity. This is because I didn't want to produce files with long encoder delay. I tried another splitting utility, pcutmp3, which produces files with long encoder delay and that didn't play gaplessly on my iPod, presumably because the firmware ignores the encoder delay.

What do others think of my method of splitting MP3 files? Is there any other software which does it right?

what version of LAME are you using?

When using ipod firmware then I was of the opinion (since I've never owned nor used an ipod) that gapless playback wasn't possible unless you used the iTunes "add gapless playback" feature (or whatever they called it when they created it about 1yr ago).

I've never had a problem with gapless playback after splitting mp3s with mp3directcut or my preferred choice of pcutmp3. BUT I use foobar & a Rockboxed iRiver H120. Thus the media player is often the key here

I was also of the opinion that pcutmp3 is the best mp3 cutter/splitter out there; in the way it technically does the split.

i use total recorder for spliiting/cutting and adding mp3's, the most easy priogram i used for it and all without recompressing

Does it do so in a way described in the initial post? I very much doubt it.

pcutmp3 is the only thing I know that does it "right" and as you say, that's by setting long encoder delays.

Your approach sounds interesting. I wonder if going to 320kbps is always enough to get rid of the bit reservoir? I would imagine it usually (almost always) is, but a lame dev (or similar smart person!) would have to confirm that it stays true in pathological cases.


On players which ignore encoder_delay data, your method would introduce a slight repeat, wouldn't it? Not that the other methods are pretty with such players either.

Cheers,
David.

The longer encoder delays are mainly due to the fact that I'm avoiding making the first frame bigger (by including the bitreservoir from the previous frames) which may be impossible in some rare occasions (ie frame is already 320kbps and requires some bits from the reservoir). So, I'm generating a new first frame that decodes to silence and carries the bitreservoir data for the next frame. This delay is compensated by the higher encoder delay value. The nice thing is IMHO that this method doesn't require reformatting the first frame. Joining the pieces is pretty simple in theory since the original frames are not touched at all.

By the time writing the code it didn't come to mind that some players provided only half-assed LAME tag support (foobar 0.8.x had problems as well as the slimdevice players). But the recent versions can handle them as far as I know.

Cheers!
SG