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.

Okay, right now, the player can play nogapped VBR files, but they're nigh unusable because of the issues with FFing and REWing.

Hacking the support for VBR headers back into LAME for nogapped files seems to reintroduce gapping. This is because the VBR headers in LAME have been broken for quite some time (forever?). In the VBR header, there is a field that contains the number of frames in the mp3 file. LAME's frame count was always one less than what it should have been because it failed to count the VBR header itself as a frame.

The frame miscount causes some players to fail to play the final frame, apparently including the empeg player, in all its recent versions.

The specific VBR header fixer being used was also broken and dropped the final frame on the floor when ``fixing'' it, causing the same problem in a different way.

Both of these problems are compounded by the fact that 2.0b13 also seems to introduce gaps when it sees a VBR header, but Peter's build somewhere after b13 has fixed that problem, he reports.

Edit: More untruths. I've gotten so far away from the original issues, I've forgotten what they were.

Edit again: To jibe with Tony's memory, which I think is correct in this case.

IIRC, even if you let lame generate nogapped VBR files without a VBR headers, you still get gaps.

That's not the way I remember it being reported. My recollection is that someone reported "If I don't add the VBR headers back in, it plays fine. But the player has other problems with headerless files, so I add them in. And that's when it plays wrong." And later we found out that the reason was his header-adding tool, not the player. That's the way I recall it happening.

I could be wrong, of course. I frequently am.

Okay. I'll go with you one that one. Let me fix it again.

Can I send someone on the alpha team a pair of nogapped VBR mp3s and see if they can hear a gap in the current alpha build? Actually, maybe a pair or pairs, one fixed using Peter's method and one made directly by a devel version of LAME.

I'd offer, but I'm in the middle of my own set of MP3-related projects this weekend and don't want to add another.

What a pathetic attempt to get the alpha version early.

What stage is v3 in exactly?

We'll find out after 2.0-final is released. It should be possible to release v3-alpha1 to the alpha group almost immediately, and if it seems half decent then a public beta will follow.

Rob

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.

Everything is ready for RC2 except we upgraded to InstallShield 8 recently and somebody needs to convert the installer. We've been a bit busy (understatement) but hopefully we'll get to it soon.

Rob

Hey, I just sat through an Installshield 8 training class all last week. I'll do it!

There is another small issue that I don't think has been discussed. The "--nogap" switch itself (which was an attempt by LAME's developers to solve the "gap" issue) is not actively being supporting or developed. It is (from my reading anyways) likely to be dropped from future builds - HELP

Anyone confirm --nogap is still supported in the latest build, I'm using the one supplied with WinLAME, which works for me.

Cheers, Sim

When I was talking with Mark Taylor to get the problem fixed, he didn't mention anything of the sort. Which is not to say that it's not true.

Regardless, if it works in the current version, since LAME is open source, you'll always have access to the current version. And it's not as if LAME has huge bugs left. I can't imagine what else they could add to it other than to improve the psychoacoustics further. By the time that happens significantly and nogap support has fallen by the wayside, Ogg Vorbis should be available for use on the player.

Out of curiosity, is this the reason that the VBR header inserts a gap, that the player isn't interpreting and skipping over id3 tags and VBR headers, but that something prior to that is interpreting them and telling the player to skip over them, but it's not doing it for the VBR header?

Does anyone know what encoder iTunes uses? I'm curious to find out. I'd imagine it's definitely not Lame. Lame as that would be.

- trs

My guess would be a Fraunhofer reference encoder.

strings /Applications/iTunes/Contents/Resources/English.lproj | grep Fraun

gets you "MPEG Layer-3 audio coding technology licensed from Fraunhofer IIS and THOMSON multimedia."


It's certainly possible, though, that they used some other encoder, and just paied Fraunhofer and Thomson to avoid any legal entaglement with the patent holders.

Everyone has to pay Thompson Fraunhoffer - they own they patents, both for encoding and decoding.

Rob

That's what I thought. Apple could conceivably use LAME in iTunes, but just because it's open source doesn't mean it would be free, as Thomson and Fraunhofer would still get their cut

Fraunhofer doesn't get a cut off LAME. This is the reason LAME exists and is only distributed as source code. Only when someone makes it into a binary that encodes MP3s is it 'illegal.' Apple would never be able to use LAME to encode MP3s bacuse they would be distributing it in binary form.

Remember, Lame Aint an MP3 Encoder.

Right, that's what I'm saying

I don't think that that's true. The LAME site itself reports any number of commercial products that use LAME (one of them being Universal's copy protected CDs), and I doubt that either they would list them or Fraunhofer wouldn't go after them if it were ``illegal''.

All FhG wants you to do is pay money to license their patents. Once you license their patented algorithms, I doubt that they care much how you implement them. If your implementation happens to look just like the LAME implementation, then so be it.

OK, maybe I was talking out of my ass a little bit.

There are many encoders available from different companies, and those companies arel entitled to license them however they see fit. The patent fee comes into play when an encoder reaches a user - someone has to pay it. In practice this is the software vendor - i.e. empeg paid the license for each of your car players.

In theory every user of LAME should pay a fee to Thomson Fraunhoffer if nobody further up the chain has paid it on your behalf. I'm not sure if Thomson waive this as a matter of policy, or just don't bother to attempt to enforce it.

Rob