I apologize if this issue has already been touched on - but I searched and found a lot of talk regarding this issue for past versions - but not for the impending v2.

So, is no gap being addressed in the release? If so - to what degree? And have any of the alpha testers fiddled with gappless playback in v2? I'm just curious...

Thanks!

- trs

We've got gapless playback now (a little quirky & tedious to achieve but hey...) so I hope no one's broken it for v2 cos it took me absoluuuuuuutely ages to redo all my mp3's (but it was worth it, over 4000 songs and not a glitch between any of them)

Cheers, Sim

Well, from the posts I've read - not many have claimed to actually have gappless playback. All the way up to b13 I noticed people mentioning small gaps even after cleaning up their tags and header info.

BUT, if you were able to achieve seamless playback after redo'ing all of your mp3s' - what did you do to fix them exactly?

mlords mp3tool? other tools?

I appreciate the info.

- trs

I never had trouble setting up nogap mp3s. I just used CBR and the --nogap option in LAME, so there wasn't a problem. From what I understand, gapless mp3s using VBR is still iffy. So I'm pretty much waiting on OGG support to make my life easy.

Ah - there's where I wasn't being specific enough. My questions stems from VBR and no gap.

The version the Alpha testers are running behaves exactly the same in terms of gapless playback as Beta 13. The current beta you've got doesn't insert any gaps between two tracks. The player software is currently doing all it can do. If you can't make the files gapless, the problem is in your MP3 files, not in the player software. Have you read the last stuff I put into the FAQ on this topic? I thought it was reasonably current.

yeah yeah - user(encoder) error - who'da thunkit.

I guess I'll leave it at that. Although would be nice if what you'd previously discussed with hybrid8 was considered in future versions.

- trs

Although would be nice if what you'd previously discussed with hybrid8 was considered in future versions.

Yeah, I'd like to see cross fading be used as a way to get around gapless playback without having to do special encoding. I wonder if there would be a way to select a single fixed time-period for a crossfade that would work nearly universally for all MP3s encoded normally (i.e., no special gapless encoding done). Such as the length of two frames, or four frames, or something like that?

Anyway, cross fading isn't in the 2.0 software... Ah well...

The current beta you've got doesn't insert any gaps between two tracks. The player software is currently doing all it can do. If you can't make the files gapless, the problem is in your MP3 files, not in the player software.

That is likely to be untrue.

Edit: Actually, I think your statement is true for CBR mp3s, but not for VBR mp3s.

I thought that later, he figured out that it's fine for VBR, too. The problem wasn't in the player software, it was in VBRFix. Or something like that.

He did, but it was in the ``current player build'', by which he seems to have meant something post-2.0.

I have not yet achieved gappless playback with vbr - which is why I was hoping to find out if there was any addressing this in the software. But according to what people are saying - if I want gappless playback - I have to stick with cbr.

- trs

BUT, if you were able to achieve seamless playback after redo'ing all of your mp3s' - what did you do to fix them exactly?

Yeah, sorry about being non-specific. The only guaranteed way ahead for me was using CBR encoding, which at 256kps it isn't sacrificing any quality that I can discern (though space gets used up a lot quicker than my VBR lovin' friends, but hey, space is cheap!).

- Rip using EAC (with CDDB for naming)
- Encode 256CBR using WinLAME with --nogap option (http://winLAME.sourceforge.net)
- Tag with your favourite tagger
- Sit back and enjoy your gappless creations

Cheers, Sim

In reply to:

---

Yeah, sorry about being non-specific. The only guaranteed way ahead for me was using CBR encoding, which at 256kps it isn't sacrificing any quality that I can discern (though space gets used up a lot quicker than my VBR lovin' friends, but hey, space is cheap!).

- Rip using EAC (with CDDB for naming)
- Encode 256CBR using WinLAME with --nogap option (http://winLAME.sourceforge.net)
- Tag with your favourite tagger
- Sit back and enjoy your gappless creations

---

exactly the method I use for CD's : winLAME solves the problem of command line length limitations, so you can tag from filename after gaplessly encoding with winLAME

Can someone confirm this command line for gapless encoding is right :

lame --alt-preset cbr 256 --nogap t000.wav t001.wav ... t00x.wav

NOTE #1 : single spaces used throughout - I seem to remember this has been as issue in the past.
NOTE #2 :I dont specify the MP3 name in the command line, just accept the default name created.

It seems to work ok, but I do get the odd 'click' at some track transitions.

Anyway, cross fading isn't in the 2.0 software...

It is in 3.0 but it doesn't currently offer the user such a small cross fade. I'm not sure this is really the answer for gapless playback - a smart method to detect and jump over the offending silence is the only way to be sure of not affecting the beat. I think the gapless playback algorithm could be modified to do this as well.

Rob

Version 3.0 *dribble*

How is that coming along? Will it see the light of day any time soon?

He did, but it was in the ``current player build'', by which he seems to have meant something post-2.0.

Ah, I should have said "current branch build". I meant that I couldn't hear any gaps in playback with a post-beta13 2.0 build.

Peter

Is that still the case? I'd hate to get a 2.0 final and have had that come and go in between releases.

Okay, ``hate'' is a strong word....

What stage is v3 in exactly?

a smart method to detect and jump over the offending silence is the only way to be sure of not affecting the beat

I'd like to see something which did this. The problem is that, because of the lossy way MP3s are encoded, sometimes the extra bits of silent data aren't perfectly silent. They contain some of the MP3 artifacting such as echo or pre-echo... very faint, but present. So it would be hard for an algorithm to be able to tell the difference between a gap in the encoding and a song that was "supposed to be" that way.

But clever software could still do it. Even if there was "supposed to be" a really quiet part near the end/beginning of a song, it would still be OK if the software cut off a fraction of a second's worth of it. You could have the gapless algorithm choose to only trim within a few frames of the beginning or end of the song.

It is in 3.0 but it doesn't currently offer the user such a small cross fade.

Well, consider this a feature request for that very thing, then.

A little off topic but what is the status of the bugg blatt fixes release? Is that emplode version ready to go? I desperately need USB support under XP to do a clone.

a smart method to detect and jump over the offending silence is the only way to be sure of not affecting the beat

I'd like to see something which did this. The problem is that, because of the lossy way MP3s are encoded, sometimes the extra bits of silent data aren't perfectly silent.

There's an id3v2 field, ETCO, that allows you to specify the intro and outro silence transition times.

There's an id3v2 field, ETCO, that allows you to specify the intro and outro silence transition times.

I'd rather have something that worked correctly on-the-fly, instead of needing to fill out a tag. I'm sure that a cleverly-written piece of playback software could do it.

In fact...

I see a real market for a piece of software like that, in the lines that Rio currently has and is planning on for the future. I mean, if a Joe Sixpack sticks a Pink Floyd CD into a Jupiter or a Visteon unit, they'd be unhappy to hear the gaps.

a smart method to detect and jump over the offending silence is the only way to be sure of not affecting the beat

I'd like to see something which did this.

The crossfade module for xmms does it, in my opinion somewhat imperfectly. Still, it's possible now.

While I understand your point, a ripper could conceivably do this and be precise about it, since it knows track lengths to start with. Of course, that doesn't take into consideration intro silence.

a ripper could conceivably do this and be precise about it

Yes - but the caveat here is that the VBR encoding is not providing gapless playback. CBR works great when it comes to gapless playback - but in order to achieve true gapless playback with VBR It seems as though help from the player software IS needed.

- trs

Okay, to summarize:

1. The mp3 spec does not inherently provide a facility to make songs gapless. They must be of particular (although variable) lengths, and ending at an arbitrary point is impossible.
2. Due to some other technical issues with the mp3 spec, it's possible that there might also be leading silence introduced when an audio file is encoded.
3. The id3v2 tagging spec provides a facility to ``mark'' these erroneous silent segments at the beginning and end. An mp3 player that understood these marks could notice them and edit them out. Currently, no known mp3 player does so.
4. Also, inserting those id3v2 marks might be non-trivial to the point of requiring human intervention. Then again, it might be possible for a ripper or encoder to do it automatically. Regardless, the point is again moot, as no current ripper or encoder does.
5. It is feasible that a quick crossfade architecture in an mp3 player could make two mp3 files seem gapless. WinAMP has such a facility, and reviews are mixed.
6. The mp3 encoder LAME provides a ``nogap'' option when encoding. It apparently slightly modifies the beginning and ending points of the tracks given to it so that they fit the natural mp3 break points. By all accounts, this works perfectly when encoded in either CBR or VBR mode. However, it does not write a VBR header when encoding to VBR mode, which causes the empeg player to not be able to calculate absolute positions properly, which makes internal FFs and REWs nearly impossible.
7. The current version of LAME has a bug that writes incorrect VBR headers all the time (that is, nogapped or not -- in fact, you have to hack VBR header support for nogapped encoding into current LAME builds; it had been disabled to fix this problem, due to a misdiagnosis on the LAME developers' part based on this unnoticed bug), which makes many players fail to play the final mp3 frame. At least one VBR header fix program also deletes the final frame when trying to fix it. Not hearing the final frame of one mp3 before playing the next sounds very similar to the standard mp3 gap when the two are meant to flow into each other, and is essentially unnoticeable when they're not. The VBR header bug in LAME should be fixed in current development sources.
8. The empeg player software also has a bug that introduces a gap, apparently when it sees a VBR header, even if it's correct. This bug is also reported to have been fixed in current builds, but there's been no independent verification.
9. Ogg Vorbis does not have a gapping problem at all.

Edit: Fixed major problems.

Edit again: One. More. Time.

Edit trifecta: Once again

When in VBR mode, it does not. The current version of LAME has a bug that writes incorrect VBR headers

I thought it wrote no VBR headers at all. And that's where the problem started... to wit...

which makes many players drop the final mp3 frame

I thought that the "Drop final MP3 frame" was not a playback issue. But rather, people trying to correct the above thing (no VBR headers at all) were running VBRfix on their files, and that a bug in that program actually deleted the last MP3 frame.

The empeg player software also has a bug that introduces a gap, apparently when it sees a VBR header.

I thought that this wasn't the case. I thought that the problem was the above thing: VBRfix had a bug that deleted the last MP3 frame.

I could have sworn that the sequence of events I wrote was discoverd and reported by one of the empeg folk. I'd be interested if they could come in here and confirm or deny.

Oops. I made one mistake in my summary, which then dominoed. Let me go back and fix it and then I'll explain.