User:Mjb/MP3

Lossless MP3 editing

Editing MP3s without transcoding (and thus degrading) the audio can be accomplished by the following methods.

To be absolutely safe:

1. mp3packer -b 320 -r inputfile.mp3 tempfile.mp3 to all but eliminate bit reservoir usage
2. Edit tempfile.mp3 in mp3DirectCut
3. mp3packer -s -t -z tempfile.mp3 outputfile.mp3 to recompress to VBR

However it's generally safe just use mp3DirectCut on the files, if all you're doing is trimming silence/noise from the ends. Generally. Problems:

• If you cut off frames from the beginning, then the new first frame(s) might not be decodable because their main data began up to 511 bytes back, not counting frame headers. That is, it was in the frames that got cut off. It would be nice if mp3DirectCut would color such frames so you can make an informed decision as to which ones are safe to cut, if any.
• If you cut off the last frame, then the last 529 samples of the last frame you kept won't be decoded because there's no more padding.
• Due to granule overlap, 288 samples at each truncated end will be about inaccurate and too quiet because the rest of their info was in a frame that's no longer there.

I'm not sure how mp3DirectCut deals with encoder padding and delay in the LAME tag.

There's another lossless editor called mpgedit. There's a console version (mpgedit) and a graphical version (xmpgedit), and it is available for multiple platforms. However, when I tried it on Windows, it didn't really work at all. Its editing interface isn't intuitive, and mp3DirectCut seems to just be a little better all around.

I used to use mpTrim for trimming silence from the ends, but the freeware version only works on smallish files, and it has nothing resembling a wave editor, so you have to 'earball' it. I now prefer mp3DirectCut.

MP3 splitting

MP3 splitting, such as with a cue sheet, is a can of worms. MP3 frames always output a fixed number of samples (1152, if 44.1 kHz). Thus, cutting on a frame boundary means cutting on an 1152-sample boundary, usually. You can't really cut with any more precision than that. However if you include an extra frame beyond the one you're cutting in, and then adjust encoder padding & delay values, your "gapless playback"-aware decoder can output just the samples you wanted. AFAIK, the only splitting tool that will do this correctly is called pcutmp3, a java command-line program. mp3DirectCut does let you overlay a cue sheet, but it only cuts on frame boundaries, doesn't include overlapping frames, and it messes up the padding & delay tags.

MP3 gapless playback

LAME always stores padding & delay values in the LAME tag, so it's always "gapless" in the sense that the number of samples output will be correct, given a decoder that supports those values. But it's my understanding that if you just encoded the tracks one at a time, LAME didn't have access to the previous and next track's frames, which are needed in order to know how to best encode the frames near the boundaries of the current track. From what I've read, it seems 288 samples on either side of the boundary between a pair of tracks will be at half volume (not confirmed, though). The psychoacoustic model may also be affected for adjacent frames (I think 2 frames before & after). I can't say with certainty what really happens, but you don't get the same samples at the boundaries when encoding separate tracks as when encoding the whole album at once. So the proper thing to do, to get split tracks, is to encode the entire set of tracks all at once by invoking LAME with the --nogaptags --nogap options. The problem, though, is that the resulting files will have no padding (except in the last file), which is a situation that players (even foobar2000) generally don't account for. These unpadded files won't be played to the very end. What a player has to do, to support playback of such files, is start feeding the next file's frames to the decoder when the end of the current file is reached. As far as I know, very few players do it. Rockbox supposedly does. Do any others?

Anwyay, the HydrogenAudio forums have a number of posts suggesting that --nogap is deprecated or obsolete, but unless I'm mistaken, that's clearly not the case. Abandoned, yes. Deprecated for basic gapless playback, yes. But obsolete, no. If properly supported in players, it should offer superior gapless playback, at least from a technical perspective, if not an audible difference.

I'd be interested to see the results of splitting a pair of tracks with pcutmp3, as compared to encoding them with --nogaptags --nogap. Does it produce the same frames and padding/delay values? Even if it doesn't, does it produce the same output when decoded?