You're right, that method would certainly work. If you had one huge MP3, then trimmed it precisely at frame boundaries to split it into multiple tracks, that would work. However, that's a lot of trouble to go to. I know of no tool that lets me easily mark multiple MP3 trim points based on time indices. So that last step really is the tough one.

---

There's programs on the web (mp3split comes to mind) which supposedly trim mp3's into seperate files, but I've noticed taking a seamless mp3 and converting it into several mp3's introduces a slight pause...

btw - audiocatalyst's songs are gapless on my computer - the empeg does introduce a slight (sometimes not even noticible) pause between songs...
-mark


...proud to have one of the first Mark I units

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

you're confusing me ( . . ) Will AC create gapless MP3's or not?

Truth is, I donot know!
I do know that AC can automatically delete leading and trailing silence. This is confirmed when I run MP3Trim on such a file: it doesn't find any empty blocks at the start or end. Thus from that I conclude that AC can create files without leading/trailing blocks that are totally empty. However, I donot know what AC does when it cannot completely fill a final block of an MP3. I assume that it padds it with silence, but cannot check this. If it does, it cannot create gapless MP3's.

I can't verify this. I've removed the final block of the first MP3 of a duo that's supposed to be gapless, but they still show a gap when played on Emma. I can't tell if it was any shorter. Initially I blamed AC for this, but we now know that empeg (also??) inserts silence

In essence 2 questions remain on AC behaviour relating to partially filled blocks:
1) Does AC padd partially filled, final blocks with empty space
2) Does AC always start the first block with data

On Empeg adding silence between tracks:
Hugo acknowledged this, and we moved on to the topic of how difficult it was to create gapless MP3's

I sincerely hope that the empeg folks are looking into this and
1) will find a way to make Empeg truthfully reproduce MP3's / prevent it from inventing a pause that isn't there.
2) will skip any leading empty space in the first block of an MP3 (any intended silence wil be longer than .028seconds; thus there will be quite a few of blocks with only silence -- no one will miss .028 secs)
3) find a way to skip trailing empty space of a partially filled final block (this may be very difficult, unless there is a total block count, somewhere)

Henno
# 00120

> 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.

This is unfortunately why it's impractical to do gapless mp3 with all the encoders/decoders I've seen. The easiest way (heh) to encode gapless mp3 is to encode the entire segment that you want contiguous as one mp3. At least, the encoder should treat it as one contiguous segment even if it outputs to separate files. In other words, the codec shouldn't be reset between tracks.

This is only half the story though - the decoder also needs to know that the two files are contiguous, and not reset. You can't do this if the tracks weren't contiguous because you'll get a strange result for the first frame of the next track (probably an audible click). So there needs to be some way of telling the codec not to reset in one particular case...

If anyone has a util (source?) to split mp3s, I can try hacking around a bit when I get some time (which I don't have much of, unfortunately :)


- John.

(The above may not represent the views of empeg :)

If anyone has a util (source?) to split mp3s, I can try hacking around a bit when I get some time

If you look at your MP3 files in a hex editor (such as UltraEdit), you can see the frame boundaries pretty clearly and can split the files yourself by hand. It's a lot easier than you might think. The detailed specifications for the frame headers are here if you want them.

Tony Fabris
Empeg #144

I dont know exactly how the piece of software you have works, but I have run across a couple of programs that will let you trim mp3 files and wav files.
You can find them at http://mp3trim.8m.com/ They have been useful to me.

Term

I dont know exactly how the piece of software you have works, but I have run across a couple of programs that will let you trim mp3 files and wav files.

Thanks for the link. The software I wrote is unique because it's the only one that's deliberately designed to work on only the gaps between two consecutive tracks. Most trimmer utilities just work on one file, or they're designed to splice files. Cripes, I can do that with a hex editor such as UltraEdit- I don't need a specialized trimmer just to cut and paste files. No, what my gapping software does is allow you to interactively preview the gap and try multiple "live" run-throughs of the gap as you trim the two MP3s simultaneously. And it doesn't save the final changes to the original files until you tell it to.

In practice, it works incredibly well. I've de-gapped several albums with it, and it makes the task a lot easier than it would be if you trimmed each file individually by hand. It's very limited (and very beta) right now, but it works for my purposes.

Oh, and by the way, the author of that MP3trim utility you linked was the guy who helped me write mine. It's a good utility, but isn't useful for interactively editing the gap between two songs.

Tony Fabris
Empeg #144