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