Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Topic Options
#65114 - 31/01/2002 11:59 Gap in playback when VBR headers added.
tms13
old hand

Registered: 30/07/2001
Posts: 1115
Loc: Lochcarron and Edinburgh
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?


Edited by tms13 (31/01/2002 12:02)
_________________________
Toby Speight
030103016 (80GB Mk2a, blue)
030102806 (0GB Mk2a, blue)

Top
#65115 - 31/01/2002 12:46 Re: Gap in playback when VBR headers added. [Re: tms13]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#65116 - 31/01/2002 12:47 Re: Gap in playback when VBR headers added. [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#65117 - 01/02/2002 03:37 Re: Gap in playback when VBR headers added. [Re: tfabris]
tms13
old hand

Registered: 30/07/2001
Posts: 1115
Loc: Lochcarron and Edinburgh
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.
_________________________
Toby Speight
030103016 (80GB Mk2a, blue)
030102806 (0GB Mk2a, blue)

Top
#65118 - 02/02/2002 19:26 Re: Gap in playback when VBR headers added. [Re: tms13]
Terminator
old hand

Registered: 12/01/2000
Posts: 1079
Loc: Dallas, TX
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

Top
#65119 - 04/02/2002 08:48 Re: Gap in playback when VBR headers added. [Re: Terminator]
tms13
old hand

Registered: 30/07/2001
Posts: 1115
Loc: Lochcarron and Edinburgh
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.
_________________________
Toby Speight
030103016 (80GB Mk2a, blue)
030102806 (0GB Mk2a, blue)

Top