The same albums (continuous-mix-cds) that played smoothly in beta7 now have quite annoying pauses between tracks; must be more than half a second or so.

I just gave it my litmus test (My hand-trimmed copy of Dark Side of the Moon) and it worked perfectly, no gaps between the tracks.

I wonder what's different about your player than mine?

I suggest turning on disk-drive icon and seeing if you get the "W" symbol to indicate whether the player is stalled.

No, there's no "W"...BUT I think I found something very interesting:

I hear absolutely NO GAP, when I send the wav-files through

"LAME --alt-preset standard --nogap <file1> <file2> ... <filex>"

and listen to them as they are or with ID3-tags added.

Problem is, the empeg doesn't know the correct track-times after this step (usually it thinks the tracks are much longer because the time is calculated from the first vbr-frame or so), so I need to send these mp3's through vbrfix to fix the track-time... after that step, I CAN hear the gaps !


So, as far as I understand this, there is a problem with the gaps ONLY if the time-/frame-value in the header is correct or less than the actual track, but there is NO problem, if that value in the header is HIGHER...

Or to put it simpler:
no gaps if the tracks are shorter than the empeg thinks.

I tried this on several tracks and have the same tracks on my empeg in several states (after LAME, after vbrfix, with ID-tags and without) and so far it really seems to be that way...

I eventually resorted to CBR for tunes which need to be gapless. Like you, VBR files only worked if the VBR header was absent, and that's not acceptable for me (because of the wrong length - Seek Tool doesn't work properly for them). The gaps are much less than half a second for me, though - more like a hiccup or click than a pause.

But wouldn't it work just fine if the header said 'the track is a tenth of a second (or, say, 1 frame) longer than it actually is' ?

I mean, there must be some way to prevent those gaps in the empeg-software... at least if this is as simple as I think it is...

In reply to:

---

But wouldn't it work just fine if the header said 'the track is a tenth of a second (or, say, 1 frame) longer than it actually is' ?

---

I wouldn't expect so - but then, I haven't actually tried it. Have you?

I think the track-length thing is a red herring, and that it's the presence of the VBR header that's causing the gap to appear. Some tracks without a VBR header appear shorter than they actually are (if they begin with a high-bitrate frame). Pink Floyd's "The Wall" tends to encode as a mix of longer and shorter than actual.

it's the presence of the VBR header that's causing the gap to appear.

This is an important distinction, and I think we need to get to the bottom of what's actually causing it. I agree, from the descriptions in this thread so far, that it makes it sound like VBR encoding does seem to have something to do with it.

If the simple lack/presence of VBR headers on the file (the SAME FILE) removes/causes playback gaps, one might think of that as a bug in the empeg player software that should be corrected. Does anyone have more data on this?

In reply to:

---

If the simple lack/presence of VBR headers on the file (the SAME FILE) removes/causes playback gaps, one might think of that as a bug in the empeg player software that should be corrected. Does anyone have more data on this?

---

This is what I've seen - I ripped and encoded an album with Lame VBR nogap, and uploaded it - no gaps. Then I added VBR headers to these same files (using Mark Lords mp3tool, IIRC) and uploaded into a different playlist. The new playlist had gaps - very tiny ones, as I mentioned before, almost like a click.

This means we can rule out anything in the ripping and encoding process. AFAICS, the bug is in either mp3tool or the player software. If someone can do the same test with a different VBR tool, we can be more confident it's a player bug.

New entry created in the internal bug list.

Out of curiosity, do those gaps show up in a gapless computer player, like WinAmp with the appropriate plugin?

...so far I absolutely agree:

Adding the VBR-header using vbrfix or mp3tool causes gaps between files, that didn't have gaps between them before.

I will upload several mp3-files onto my empeg (some appear longer, some appear shorter) with manipulated VBR-headers (I changed the frame-count, which is the only thing I was able to find in these headers so far) to see what's gonna happen then.
Too bad my empeg needs to check disc integrity NOW.....

Still I have to say, on my empeg these pauses are USUALLY very short - but from time to time it takes almost a second before music continues...

well, the tracks in which i changed the framecount of the vbr-header do not behave any better... gaps are the same, even though they show up as being longer in emplode...
would have been cool, though...

Well, I guess I need to correct myself:

- there actually IS a W in the display, when I have LONG gaps inbetween tracks
- in short gaps (like in vbrfix'ed files), there's no W.

Maybe the longer gaps are related to this one: Beta 11 buffer bugs ... ?
As some of my albums don't have Xing-headers and empeg thinks that some tracks are longer than they actually are, maybe that is the reason why the cache isn't ready when the next song starts...

If it were buffering bugs, then the VBR headers wouldn't have any bearing on it.

This is what I've seen - I ripped and encoded an album with Lame VBR nogap, and uploaded it - no gaps. Then I added VBR headers to these same files (using Mark Lords mp3tool, IIRC) and uploaded into a different playlist. The new playlist had gaps - very tiny ones, as I mentioned before, almost like a click.

I tried this. I took the utterly splendid As Heard On Radio Soulwax Part 2, which is a continuous mix, ripped it, and encoded all the tracks using a single lame --nogap command. I uploaded it and it played completely gapless. So far so good.

Then I added a Xing VBR header to each track with Vbrfix v5.2.10. I uploaded them again, and found there were tiny glitches between each track.

After several hours' fiddling with the player code, I checked the files in a text editor. Vbrfix had removed the final frame of many of the files: the gaps weren't at the beginnings of tracks but at the ends.

Mark Lord's mp3tool doesn't randomly drop frames on the floor, but will only repair an existing VBR tag, not create one.

This left me with hacking Lame not to automatically disable VBR headers in --nogap mode (line 667 of lame-3.92/frontend/main.c). But its VBR headers are invalid and they need fixing with mp3tool. With that all done, I did get gapless VBR playback with proper headers on the current player build.

Peter

INTERESTING!!!!

Ah, thanks for investigating this, Peter.

Tony - I think this is FAQable material...

So it sounds like vbrfix is the culprit in this scenario. Did you send a bug report to the author complaining of lost data, or should someone else do it?

Greetings!

I know he has the source posted on his site. There was another version I was looking at also. I was trying (unsuccessfully or you would have heard about it) to integrate the VBRfix logic into mp3tool. Right now, mp3tool will not write a Xing header if it is missing. I started on it, but my time is rather limited at the moment.

I am tempted to try and create a bogus header, append it to the front of the file and throw it to mp3tool. Not graceful, but...

Yeah, I've re-worded that section of the FAQ a bit, based on this new information.

This is all very helpful news, and really reminds me how mad I am at EAC author Andre Wiethoff who curtly ignored my feature request to rip the whole album before decoding so that the -nogap option can be used on an entire album rather than Rip 1, Encode 1, Rip 2, Encode 2, etc. He said something along the lines of "I haven't heard that using -nogap is any better than manually editing out gaps or using gap detection in EAC" blah blah blah.. EAC is great, but this feature is really going to be necessary some day when I want to re-rip all my albums to remove gaps. I might have to do it all manually now.

In reply to:

---

Mark Lord's mp3tool doesn't randomly drop frames on the floor, but will only repair an existing VBR tag, not create one.

---

It's possible that I patched my copy to create a new one. I certainly remember patching Florian Maul's mp3info(*) to write VBR tags on MPEG-2 files, so perhaps that's what I was using.

(*) From the mp3lister sources.

I know he has the source posted on his site.

Not the one I found, he didn't. Perhaps there's another program, also called Vbrfix? This one, maybe? I used the one I linked to above.

Peter

Greetings!

You are correct. The source was for the one on blorp.com. I had seen the other, but not really tried to use it much.