I'm sure it's already on the "to-do" list. Just thought I'd put it here in case anyone needed a reminder. Gapless playback would be nice, so I can listen to "Dark Side of the Moon" end-to-end without the dropouts. I went to a lot of trouble to de-gap my MP3 files (even writing a piece of software to help me do it).



-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

Why is necessary to de-gap your MP3 files? Why aren't they just
naturally de-gapped? Naively, perhaps, I thought that you could just
rip a track, encode it, and when played back it would be at exactly
the same length as the original.

Richard.

Why is necessary to de-gap your MP3 files? Why aren't they just naturally de-gapped?

I don't know why, but they're not. I think that the people who write MP3 encoders must just not be Pink Floyd fans. I only have experience with the Fraunhofer encoder, but it inserts whole and partial frames of silence at the beginning and end of the MP3 files it creates. I could have a set of perfectly seamless .WAV files sitting on the hard disk, but when they get converted to MP3, there are silent bits there. You can even see the silence when you look at the frames in a binary editor.

I asked Fraunhofer about it and one of their techs basically said, "yeah it does that," but didn't give me any detailed information as to why it happens.

I have not tried the VBR encoder in AudioCatalyst yet, and no one has ever answered my questions about whether or not it creates MP3s without gaps.

Anyway, the only solution I've found is to trim the frames at the song boundaries. The problem is that the silence doesn't end exactly on a frame boundary, so you have to do trial-and-error trimming, listening to the new gap with each attempt. I got so sick of doing this by hand that I wrote a piece of software to help automate the trial-and-error process. It's at my home page if you're interested in looking at it. The software's README.TXT file has more details on why it's needed.


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

I've found that blade-enc doesn't seem to have this problem (At least the version I used in the past). However, I now use music match (With the Fraunhofer encoder), as it can rip from my ide drive, and does the titles etc (I'm too lazy to type them in... =)
At some point I might de gap the mp3's, but for the moment, I live with it... =)

Jazz
(List 112, S/N 00030, 4 gig blue)

I use AudioCatalyst's VBR encoding, and I have Dark Side of the Moon ripped and on the empeg. I haven't listened to it in a couple of months (I know, it's almost criminal!) but if I remember correctly, there's a very small, but noticeable, gap of probably less than 1/8 second (although I haven't tried to time this accurately. It's also there in a couple of live albums I have on the empeg.

mac once said that the player shouldn't leave gaps between tracks, so I guess even AudioCatalyst is putting some silence at the end of tracks.

I know this isn't a conclusive answer, but my empeg is about 400-500 miles away during the week (working on client site really sucks!) so I can't check it out easily...

Geoff
---- -------
Reg No. 554, s/n 00064 - It's mine I tell you.... all mine :)

I found that on "Dark Side" and "Wish ...." that (using AC VBR @128 start rate) you can tune the gaps right down, but only to a certain point. After that you start losing music and the pop remains; the gap itself is due to the empeg regarding the tracks as seperate and needing time to start the new track. I noticed that it is still far better than WinAmp's equivalent, so I live with the slight pop it generates. I have stopped noticing.

Mike has said that contiguous track playback has not yet been implemented, so there's not much chance it will change until the more pressing stuff is out of the way.

Don't be impatient - surely half of the fun of the empeg experience is waiting for all those gentle little tweaks that turn up one at a time. If they all arrive in one slug, then there'd be nothing more to wait for, would there?

Don't be impatient - surely half of the fun of the empeg experience is waiting for all those gentle little tweaks that turn up one at a time. If they all arrive in one slug, then there'd be nothing more to wait for, would there?

Kinda like Christmas all year round - I like your way of thinking


Geoff
---- -------
Reg No. 554, s/n 00064 - It's mine I tell you.... all mine :)

Geoff Said:
but if I remember correctly, there's a very small, but noticeable, gap of probably less than 1/8 second

Schofiel Said:
After that you start losing music and the pop remains; the gap itself is due to the empeg regarding the tracks as seperate and needing time to start the new track. I noticed that it is still far better than WinAmp's equivalent, so I live with the slight pop it generates.

I probably forgot to mention... WinAmp doesn't, by default, do gapless output. Simply playing your tracks in WinAmp doesn't test whether they're gapless or not. You can get a plug-in for WinAmp that does do gapless output, and that's what I use to test. I can get my tracks completely gapless with a little bit of work.

I found that on "Dark Side" and "Wish ...." that (using AC VBR @128 start rate) you can tune the gaps right down, but only to a certain point.

I am very interested in finding out from someone whether or not this can work perfectly when using WinAmp's gapless output plug-in. I'd also like to know by what procedure you "tune" the gaps in AC.

-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

I can verify, VBR audiocatalyst DOES produce gap-less mp3's..
-mark

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

Audiocatalyst does NOT put a gap between songs.. Play the songs back to back using apollo (...which has gap-less built in) or winamp (...with the gapless plugin), you won't hear the gaps... I think the empeg is still putting a slight pause there..
-mark

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

The way I did it was to put in the CD, start AC, setup the ID3 tag and MP3 capture parameters, then let CDDB pull down the track names. After the track names are up, with "properties" for the individual tracks I just tweaked start and end times, then played them back in WinAMp. I confess I wasn't aware that there was a "gapless" plugin for WA, so the original statement was made by be playing with WA and then downloading to emma. I thought I got reasonable results, but not brilliant.

TO be honest, I'm not too bothered at the moment; I am sure the guys are going to come up with the proper fix sometime. As they will produce plugins, special effects, module interfaces, API specs, etc. Yet another little fix to anticipate....

I just tweaked start and end times, then played them back in WinAMp

Rob,

There is a much more easy way to do this: MP3Trim

It can automatically eliminate leading or trailing silence, such that the net contents of the track remain. MP3Trim is freeware and quite small (only 181k).

Henno
# 00120

It can automatically eliminate leading or trailing silence, such that the net contents of the track remain. MP3Trim is freeware and quite small (only 181k).

Yup, I used to use MP3Trim as the tool to help me remove the gaps between my MP3 files.

There's only one problem with it:

If you're trying to de-gap a seamless album (i.e. Pink Floyd), the artificial silence doesn't land exactly on a frame boundary. As a result, you must perform some trial and error trimming of the songs on both "ends" of the gap. Doing this in MP3Trim is very tedious because it only opens one song at a time.

That's why I broke down and wrote my own gap-editing utility. I've carefully de-gapped all my Pink Floyd albums and live concert albums with it. I actually consulted the author of MP3Trim to help me write it (I credit him in the Readme.txt). The utility is very preliminary, and it's not even written in a real language (it's in VB3), but it worked enough for all my albums.

That's why I started this thread in the first place. I went to all this trouble to de-gap my MP3's, and then I got the Empeg player and discovered that it didn't do gapless playback. I can't win.




-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

That's why I broke down and wrote my own gap-editing utility.

Thanks, Toni, I've found it on your home page (a beauty BTW). Haven't used it yet, as my Pink Floyds are still waiting to be ripped until I get more disk space. I did try seamless playback when you started this thread, filling up the last 13MB on the empeg, but didn't notice any gaps between the two tracks tried. It may have been shear (bad) luck that there was no pause between these particular two tracks.

Henno

Henno
# 00120

mac once said that the player shouldn't leave gaps between tracks, so I guess even AudioCatalyst is putting some silence at the end of tracks.

*looks around shiftily* Did I? Oh, I did.

Well, I've now realised that there could be small gaps between tracks by virtue of the way mp3 works. There are no gaps in the actual output due to switching tracks but the decoder may output some silence during the switch.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Well, I've now realised that there could be small gaps between tracks by virtue of the way mp3 works. There are no gaps in the actual output due to switching tracks but the decoder may output some silence during the switch.

Then the obvious questions are:

- Do you have code-level control over the decoder, or have you just licensed the binaries (i.e., is it something that you could even fix at all)?

- If you could fix it, would you want to?

- Do you have any test files to compare? I can manufacture you a few small gapless file sets for testing purposes if necessary. And, of course, unit test any new player builds against my Pink Floyd collection.

I know that gapless output is possible with MP3 because I'm doing it on my PC with the WinAmp gapless output plug-in (and some carefully edited MP3 files)...


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

> Do you have code-level control over the decoder

We licenced the binary of X-Audio. Maybe we have some control over what we feed into it - I'm guessing that the silence is caused by partially filled blocks at the end of a track, which we may be able to process a little more intelligently. Mike..?

> If you could fix it, would you want to?

I hope so - half my music collection are mixed dance albums (and the occassional seemless Jarre album).

> Do you have any test files to compare?

See above :-)

Rob

hehe; you just described my music collection...
-mark

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

I believe the problem is actually *in* the mp3 files, as opposed to in the empeg: a mp3 file has to be a whole number of frames. You can't have half a frame. If the wav input ends half way through a frame, you get half a frame of blankness, which the empeg will faithfully reproduce.

I'm guessing, but I suppose the gapless playback tools on the PC do this: on the last frame of a file, they'll cut-short the decoding if the output goes to zero (or very near zero - not sure how quickly it can drop off to zero when encoded).

If this is the case, it could be done on the empeg too. I can't say how high up the priority list it is though, as the maximum gap you would get at the moment (with properly trimmed files) would be 1/38th of a second or so.

Hugo

I believe the problem is actually *in* the mp3 files, as opposed to in the empeg: a mp3 file has to be a whole number of frames. You can't have half a frame. If the wav input ends half way through a frame, you get half a frame of blankness, which the empeg will faithfully reproduce.

You're right about the fact that most MP3 files contain partial blank space at the end (and, believe it or not, also on the beginning) frames. But my files do not because I have painstakingly edited them to remove these gaps. I do this by trimming whole frames then previewing the gap. I have to do this trial-and-error process repeatedly for each gap until the sound appears seamless. This usually involves trimming more than just the silent frames, so that you can get rid of the pop caused by the waveform jumping at the edit point. It's not 100 percent faithful to the original music, but if done carefully, it can be nearly indistinguishable from the original music. See my other posts in this thread for more on the subject.

This is my whole point... I went to a lot of trouble to de-gap many of my MP3s so that I could listen to the albums without dropouts. But the Empeg isn't playing them back gapless.

I'm guessing, but I suppose the gapless playback tools on the PC do this: on the last frame of a file, they'll cut-short the decoding if the output goes to zero (or very near zero - not sure how quickly it can drop off to zero when encoded).

No, the gapless tools on the PC faithfully reproduce the entire frame- including silence if any is encoded into the frame. Until I de-gapped my MP3 files, WinAmp's gapless output plug-in would play the silence in the beginning and end frames. In order to do gapless playback, you need two elements: MP3's without partial silent frames, and a player that handles such files properly.

I'm reasonably sure that the Empeg is currently putting small dropouts between songs, even with properly gapped files. As you say, it's only 1/38th of a second or so. But for a Pink Floyd album, that's 1/38th of a second too long.

I can supply precise example files to demonstrate this if necessary. What do you say, Hugo?



-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

This is a really shonky characteristic of MP3. I can accept that you might need empty space at the first and last frames to get your waveform right, but I'm shocked that the format doesn't allow for "only the first/last x resultant samples of this frame should be played". Maybe the format does allow it, and nobody implements it?

I (obviously from the above comments) have no actual knowledge of the spec. Is there anyone here who knows?

Richard.

I'm shocked that the format doesn't allow for "only the first/last x resultant samples of this frame should be played"... I (obviously from the above comments) have no actual knowledge of the spec. Is there anyone here who knows?

The details of how a given frame are encoded differ among implmentations (the better ones, such as Fraunhofer or Xing are patented). But the specs for the frame headers have been reverse-engineered and published in several places. The reference I use is here.

Basically, what it comes down to, is that each MP3 frame is an independent unit, containing barely enough header data to describe the bitrate/sample-rate/encoding-type of the frame. As far as I know, the information you describe isn't part of the header specification.

Like I said, I can work around it by hand-trimming the MP3 files, but the Empeg Car still leaves gaps...

-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

MP3 is more designed to be a streaming protocol, where there is no real "end": each frame is totally self-contained, which is great for streaming.

Hugo

It's true the MPEG bitstream says nothing about playing partial frames. This information really lives in an abstraction above the bitstream, and has probably been lost after encoding.

I think in order to do gapless playback seamlessly, correctly, and transparently, information about the start and end of a song needs to be tied to numbers of samples from the original PCM source and carried along with the bitstream. This meta information might be stored in an ID3 tag, for example, although I'm not aware of such a tag. (The best I could find is a tag to give the length of a song in milliseconds, not quite what you would want for this purpose.)

Then to do gapless playback, after decoding a frame you could throw away the necessary number of samples to align the frame and end up with a precise number -- the same number of samples as the original source.

This requires some cooperation from your encoder to record where the "real" samples are amongst the padding at the beginning and end. I don't know if any encoders will currently allow you to do this.

-v

I've mentioned this before, but I'll point it out again. Audiocatalyst does gapless ripping by default - you can see that it does using apollo (gapless) and winamp with the gapless plugin.
-mark

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

Guess I'm going to have to buy Audiocatalyst, then. I've still got a few live albums and Pink Floyd albums to rip.

Tony Fabris
Empeg #144

Guess I'm going to have to buy Audiocatalyst, then. I've still got a few live albums and Pink Floyd albums to rip

Tony
Even with AC, there is a tiny slice of silence between Pink Floyd tracks. It seems that empeg needs a split second between tracks shifting gears, or so. (It also shows that Pink Floyd tracks are cut at a point shortly before what you and I would identify as the cut-over point: about a second of the last track is inclided in the intro of the next.)

I hope the empeg guys will find a way to cut out this tiny pause and move seamlessly from track to track. Silencing output only when there is silence in the data.

Henno

Henno
# 00120

I have probably overlooked something, but what about this way of getting gapless mp3s (let's skip playing them correctly for now):

Take a ripper that rips the whole CD in one big wav (for example CDparanoia) and convert it into one large mp3. Then use CD TOC info to chop the mp3 into bite sized pieces (I don't know how this last step is easy or not). Comments?

(Actually, I recall now seeing a CD-ROM with all Beatles music with lyrics, sleeve graphics etc. Each album was a single mp3 (one could play it on WinAmp despite .wav extension), with some kind of index that UI software used to jump to beginning of songs within the album.)


Dragi "Bonzi" Raos
Zagreb, Croatia
#5196

Take a ripper that rips the whole CD in one big wav...

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.

For now, I'm happy with my method (interactively trimming the gaps with the tool I wrote), and I'll probably switch over to Audiocatalyst anyway. This is all just academic until the Empeg can implement true gapless playback.

I recall now seeing a CD-ROM with all Beatles music with lyrics, sleeve graphics etc.

Yeah, I made one like that for my Rush collection. Can't distribute it, though, since it would be copyright infringement to do so. But it was a fun project just for personal use.


Tony Fabris
Empeg #144

Even with AC, there is a tiny slice of silence between Pink Floyd tracks.

Hold on, there, Henno. Let me get this straight: Are you saying that AC cannot create gapless MP3s, or are you saying that even if you create gapless MP3s, the Empeg cannot play them gapless?

You see, you're confusing me with that statement. I already know that the Empeg won't play them gapless, that's why I started this whole thread in the first place. Hugo acknowledged this, and we moved on to the topic of how difficult it was to create gapless MP3's, which is a totally different issue. Your statement makes it sound like AC won't do what Dionysus said it would do.

So which is it? Will AC create gapless MP3's or not?

It also shows that Pink Floyd tracks are cut at a point shortly before what you and I would identify as the cut-over point: about a second of the last track is inclided in the intro of the next.

This is simply due to the nature of CD-Audio production. The cue points on a CD must fall on one-second time boundaries. So when they master a CD, they just place the mark as close to the real cut point as they can. Sometimes this can be off by as much as a second.



Tony Fabris
Empeg #144

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