Bringing up lame --nogap again

I remember from a few months ago that one of the empeg guys (Peter?) had determined that lame's VBR nogap option worked fine if you did the following things:

1. Hack the lame source to get nogap to work with VBR and to generate VBR headers
2. Use a utility to fix the VBR headers because the ones that lame writes are incorrect or invalid or corrupt.

Is that all still correct? If so, has someone submitted a bug report to the lame developers that their VBR headers are ... well ... lame?

That's not exactly the way I remember it. Here's how I remember it:

- Lame doesn't put VBR headers on Nogap files.

- We never determined why it behaved this way.

- We guessed it was maybe because VBR headers screwed up gapless playback on some players. Not the empeg with the latest software, but just some players. Maybe. So perhaps that's why they did it. But that's just a guess.

- We found that we could run a VBR-header-adder tool on the files and they would still play right on the car player... PROVIDED that the VBR-header-adder tool didn't have a bug that stripped the last frame off of the file.

I don't think LAME needs any bug fixing...

The way I remember it is:

• lame didn't put headers on vbr nogap files because they screwed up nogap playback. The reason that they did that is because they were invalid.
• A tool was used to add headers to the lame --nogap vbr files, but failed because no header existed.
• Lame was hacked to include the headers, despite their brokenness.
• Tool was used to fix broken headers.

Here it is.

Looks like we were both right.

So -- is there any update on this? Is this still the most appropriate way to create accurate nogapped mp3s?

To me, the best way is to just use lame with CBR instead of VBR, then all the problems go away. No fiddling around after the files were created.

To me, the best way is to fix the broken software.

To that extent, it looks like the problem with lame's vbr header always exists and looks like it might be an off-by-one problem. Probably just not counting in the header as a frame, or something like that.

Looking at it now.

I just sent some email to a lame developer. We'll see what comes of it.

Here's my patch.

I'm not sure that the generated headers are still wrong in the current code, but I run mp3tool over them anyway, just in case.

The Xing tags are still wrong whether or not nogap is specified, and that's the real problem I'm trying to get fixed in the lame code. I've not gotten a response yet. I'm trying to get on the lame mailing list, but it's being a pain, and I haven't gotten a response from the developer I emailed directly, but I wouldn't be surprised if it got binned in a spam folder for him, as I sent it to an @users.sourceforge.net account.

If you are trying to get ahold of Mark T, I think he has little interest in nogap at this point. I can't remember who was doing all the work on -nogap.

Well, it's not really a nogap issue. It's a Xing header issue at its core. Once that is solved, it should be possible to reenable Xing headers on nogap, but that's a bridge to be crossed later.

And I am trying to contact Robert Hegemann.