Gap in playback when VBR headers added.

I recorded some gapless stuff using "lame --nogap" and uploaded it to the player. Without VBR headers, it played back flawlessly, but the displayed times were wrong, and FF/REW/seek-tool didn't work exactly as they should (this is expected, of course).

So I used the mp3info program out of Florian Maul's mp3lister to add VBR headers, and re-uploaded. Now the timings are correct, but there's a tiny hiccup between tracks. It's smaller than when I had encoded without --nogap, but it is perceptible. I'd guess it's around 50ms or so, but I'm no judge of that sort of thing.

Is this somehow my fault? If not, is it likely to be fixed, or do I need to make CBR (or ABR?) files to get real gapless playback?

I seem to recall that in order for the lame "nogap" to work, they had to leave out the VBR headers. By adding the headers back in, you've effectively defeated the nogap thing.

If you wish to use nogap to encode the files, but you don't want the VBR header problems, then encode them as constant bit rate files instead.

Note: I have little understanding of how the nogap feature in LAME works, so I'm not sure why VBR headers would have any bearing on the gaplessness of the files. I just seem to recall reading that the nogap feature also removed headers. I could even be wrong about this, I might have read it wrong or be remembering it wrong.

AIUI, the nogap feature of LAME works by shuffling samples from the end of one input file to the beginning of the next (or vice versa) in order that it encodes an exact number of MP3 frames, and the reason that lame doesn't write ID3 or VBR tags is an implementation issue rather than a fundamental technical one. After all, adding headers shouldn't affect any of the audio frames at all (though I didn't verify this myself - should have kept the originals).

Remember that there are two sources of gaps: the encoder and the decoder. I'm pretty sure that I've got the encoder side sorted out, and I suspect that the hiccup occurs when the decoder is parsing the VBR header. That said, I have in the past been known to be mistaken, and I would like to hear from anyone who knows the ARM decoder and can shed more light on this.

I think this is how lame nogap works - or doesnt work. It encodes the whole cd as one stream and then breaks it into parts. I remember reading some of the lame testers posting the same problems on r3mix. This is why only cbr works correctly with nogap. I stopped reading up on whats happening with lame, so things could have changed. No one seemed to interested in fixing the problem or coming up with some other solution. :-(

Sean

In reply to:

---

I think this is how lame nogap works - or doesnt work. It encodes the whole cd as one stream and then breaks it into parts.

---

It does some other stuff, too - like ensuring that the bit reservoir is flushed between tracks (to prevent dependencies between frames in different files).

None of which affects the fact that we ought to have [em]exactly the same MP3 frames[/em] in the stream with or without the VBR header, AFAICS - so the VBR header should make no difference at all to the sound output in normal (1x) playback.
Anyway, I've worked-around by re-encoding at 160kbs CBR for those tracks.