Emplode and the player itself get the song length wrong of a large portion of my MP3's. They're all VBR files encoded by MusicMatch and with VBR headers added by Mp3/Tag Studio. Winamp and Windows Media Player have no problem reading the VBR header and acting accordingly, but emplode and the empeg seem to ignore the VBR header, making them think that the files are low bitrate CBR files and displaying an exagerated song length (making the time remaining displays on the player useless). Programs such as EncSpot and MP3Trim report no errors on the files.

I don't have any example short enough to attach, but can mail one to anyone who's interested.

It's perfectly possible that the bug is actually in MusicMatch, by the way. I would appreciate it if somebody could take a detailed look at one of the files and tell me if there's anything wrong with it. If the bug is in MusicMatch however, Winamp and Windows Media Player seem to be able to work around it, so perhaps emplode and empeg could too.

Fixing the VBR headers with MP3TS should have done the trick for you.

Just for the heck of it, try running VBRFix (FAQ entry here) on one of the problem files and see if the empeg likes it (use Replace Tune on the rightclick menu to replace a tune in the player).

If VBRfix does the trick, then it might be a bug in Tag Studio.

Even then, if the "bad" file looks fine in WinAmp, then maybe there's something the empeg guys are missing in their VBR calculations. Empeg guys?

By the way, something I've wondered about song length and VBR...

When I was writing my GapKiller utility, I based everything on frames. I discovered from reading the header specs here that the length of "air time" occupied by a given frame is the same across the file. Even if the frames are different sizes because of different bit rates, their timespan is always the same. For 44khz joint stereo 16-bit files, that time frame works out to about .02612 seconds.

Well, if that's true, then why do we even need VBR synch headers? Shouldn't a piece of software simply be able to index into the file based on the frames? That's what GapKiller does. It does everything by walking through the file one frame at a time.

Maybe that's what WinAmp and Media Player do, and why they don't have a problem displaying files with bad VBR headers?

Just for the heck of it, try running VBRFix (FAQ entry here ) on one of the problem files and see if the empeg likes it (use Replace Tune on the rightclick menu to replace a tune in the player).

I tried, but VBRFix skips the file because it already has a Xing header.

I discovered from reading the header specs here...

That URL seems to be wrong, it points to the same FAQ entry you gave me in your previous post.

Even if the frames are different sizes because of different bit rates, their timespan is always the same. For 44khz joint stereo 16-bit files, that time frame works out to about .02612 seconds.

Well, if that's true, then why do we even need VBR synch headers?

Perhaps so that a player knows that it is a VBR file, and knows its length without having to count the frames? I don't think it could otherwise know either thing, except by scanning the whole file, which is slow and sometimes not even possible (such as when streaming it).

And another thing just occurred to me: there's no way of converting a time code to a byte offset reliably for a VBR file, since all the frames have potentially radically different sizes on disk, so you need some kind of index which tells you where each frame starts, for seeking and resuming.

You're using exactly the same setup as I am and I have exactly the same problem. I have run a couple of these files through a Linux util (can't remember which one but it was recommended on this bbs) and it found problems and corrected them. I understand that it's the encoder that's used in the latest Musicmatch (I think I read it somewhere here). I also believe that the next release of Emplode will fix the files you've uploaded to the player, or at least fix the Metadata so you get the correct info for the file. Can anyone confirm this?

That URL seems to be wrong, it points to the same FAQ entry you gave me in your previous post.

Damn unreliable windows cut and paste functions. Corrected it in that post. It was supposed to point here.

Greetings!

I have the same problem, using Sonic Foundry's Siren to perform the encode. Joe D'Andrea dug up / showed me an article where it might be a problem in the underlying encoder engine, shared by many ripper applications.

Roger promised a fix in the next release (see this thread) for wiping the metadata.

I hope the metadata wipe is enough to fix it. I shudder at the thought of having to reload the empeg... With my latest audiobook purchases, I will probably fill the hard drives to capacity (Dirk Gently's & Harry Potter books). Now if only IBM and Toshiba will come out with those larger drives...

Fixing the VBR headers with MP3TS should have done the trick for you.

Agreed, but even I tried that - no dice ... though loading the file in other players besides the empeg doesn't show any adverse running times.

VBRFix, OTOH, does fix it. (Now, what is it doing that MP3TS isn't? I may check the source more closely.) VBRFix is also one of those utilities I can't run for very long, lest my system slows to a permanent crawl (memory leak, perhaps - anyone else having this issue? I may take a stab at fixing it if that's the case).

In a possibly related instance ...

I am going through PaulG's MP3 collection, picking out those for CDs that we have in common (why rip twice, right?). So I'm on the B's thus far, and I've got P.D.Q. Back on there.

I'm driving around, playing the first track off "On the Air" and I park the car, go into a store, come back, turn on the car, and ... the track comes back on, only about four minutes or so earlier, and with a way-off elapsed time on the display.

Usually I don't notice this with the VBRs with the elapsed time. I usually only notice that the total time is off, and this is for the Rio/empeg only (thus far).

I forward back to the spot I was at when I shut the car off and the display now reads at 30 minutes or so ... only I'm really about ten minutes into the track.

Known issue, FITNR, is it just me, etc., anyone?

I assume you're using 2.0b3. If not then it's a known problem, which should be solved in 2.0 final.

Sounds like the same problem I''m having. Does the offending track play OK in Winamp (i.e. does it display the correct song length, does it display the current bitrate instead of the average bitrate and can you seek normally)? If so, report it as a bug to Empeg, so they know there's more people with this problem. If not then there's probably really a problem with the track (perhaps it doesn't have a VBR header).

/Pepijn

OK! Here's what I found. The track plays fine in both Winamp and the Empeg. I get the current bitrate in Winamp. I can seek normally in both Winamp and the Empeg. The "current time" gotcha arises when I stop the car mid-track (the empeg powers down), start the car (the empeg powers up) and then observe the current time. In a nutshell, it's way off.

Is the current time correct even when you seek really far back and forth through the file on the empeg?

it's a known problem, which should be solved in 2.0 final.

An update ...

With 2.0b7, the shut-the-car-off/turn-it-on bit no longer appears to faze the elapsed time display! That is, if I turn the car off and we're at 3:00 minutes elapsed, if I turn the car back on the player kicks in right around (or at) 3:00 minutes, and at what I believe to be the appropriate point in the song.

This resolves an issue I filed with [email protected] in early December (thanks!).

However, it does faze the new "total time" display (the dividing line with the new, blinking pixel). That is, the track ends before the blinking pixel ever reaches the right side.

Though I haven't checked just yet (but I will RSN), I bet the total time (as MM:SS), if I bring it up, will match up and still appear to be longer than it really is.

The burning question, of course, is, is it an encoder issue or a decoder/player issue? If I drop these files into Windows Media player - the elapsed time is fine. As for WinAmp, I still need to check that one (read: reinstall it first). I'm willing to bet uSoft is doing some other form of compensation to get the proper elapsed time though, and I can understand if the goal here is to stick to the published standards & recommendations and not play clean-up.

Comments welcome ...

Is the current time correct even when you seek really far back and forth through the file on the empeg?

In 2.0b3 it most definitely wasn't. It would skew as I seeked.

I'll have to check this out again in 2.0b7.