This is my first forum post here, although I have been a reader for a while now. I ran into a dilemma recently. I purchased an album off of BandCamp that included a bonus track, but the problem is that they made the last track and the bonus track one file rather than splitting the bonus track into it's own separate file. I'm a perfectionist, so naturally I went about trying to find a program that could cut the mp3 into two separate tracks without compromising quality. This was harder than I imagined.

Most programs that claim to split audio files without re-encoding don't actually do it flawlessly. The data isn't encoded in a truly gapless way, and this bothers the hell out of me. I've referred to several old threads here on the board (Which I will link to in a second) and they all seem to recommend a problem called "pcutmp3" which has been dead since 2009:

I've tried to run the most recent release (0.98 Beta), but to no avail. I just get an error message that states that "a java exception has occurred". I'm running a PC with Windows 7 Home Premium, 64-bit installed. And as explained in the previous threads, programs like Medieval CUE Splitter and mp3Directcut just don't do the job.

So my question is... Are there any other programs today that are able to do what I need, i.e., splitting an mp3 file into two separate files WITHOUT re-encoding them, AS WELL AS making the resulting files play back gaplessly? Surely in the three years since those threds were posted at least one other program has been developed that can do what pcutmp3 used to do, right?

All the MP3 splitters cut on frame boundaries. pcutmp3 is the only one that overlaps (includes extra frames on either side of split points) and then rewrites the LAME tags with correct delay & padding values.

mp3splt doesn't do anything fancy; it's not gapless/glitchless. It splits as close to the desired point as possible, but doesn't rewrite LAME tags. Instead, it just copies the original file's LAME tag into every output file, so the delay & padding values are never both correct. That is, the delay is only correct in the first file, and the padding is only correct in the last file.

Ideally, the padding value would be changed to 0 in all but the last file, and the delay value would be changed to 0 in all but the first file. But then you run into the problem that basically no players support padding values that are less than the decoder delay (529), hence the advantage of pcutmp3's method (though apparently there's some issue with padding values being too big?) ... it at least works in some players, and should be seamless despite the decoder reset between files.