emplode and jemplode not parsing vbr correctly?

when i import vbr files, the length that is extrapolated from the track is always off. the more i experiment with it, i'm more i'm certain that there is something wrong with the vbr header parsing code used in both programs. before you assume that my mp3s just need to be vbrfixed, just note that the mp3s in question was freshly created by lame 3.9.3 with the use of --preset mw-us (avergae of 40kbps for voice). i assume that lame would create valid xing vbr headers. and for fun, i've also ran it thru mp3ts (makes it WAY off... like 1 minute shorter in winamp and even more in (j)emplode), vbrfix, and mpxutil (no change).

the files in question are long lectures, about an hr. long. at first, i thought it to be a problem with mpeg-2.5, so i resampled to 44100, and the same thing happens. its hard to catch on shorter tracks, but from what i've seen, it adds 1 second ot the length for every 6-7 minutes. so a track that show 71:35 in winamp shows 71:44 in both emplode/jemplode. and this is driving me crazy. its not too critical with music, but to be constantly rewinding and secondguessing if i heard a part of a lecture after i pause or start the car is really an inconvenience.

There actually is a bug with respect to VBR in all released versions of lame, including the one you're using. It's fixed in CVS, but it may be easier to use another utility to fix the files. I know for a fact that Mark Lord's mp3tool does the right thing, if you can get a binary for your OS. I'm sure others also work, but I don't know which ones. I know some definitely do not, and will actually end up truncating your mp3s.

IIRC, there was also a bug in the empeg player software in regards to MPEG-2.5 and seeking, but that may not be your problem, as I think you're not using 2.5 anymore, since you say you resampled to 44100, and that frequency is only available in standard MPEG-1 mp3s. But I could be wrong about any part of that.

ok, have proof now. download Paulway's Club Mix 2003, which is VBR encoded. in winamp, and tag&rename, it displays the time as 115:58. when imported using (j)emplode, it reads 116:14.

ok, have proof now. download Paulway's Club Mix 2003, which is VBR encoded. in winamp, and tag&rename, it displays the time as 115:58. when imported using (j)emplode, it reads 116:14.

Good catch. It looks like all current versions of Emplode and RMM believe Xing-header VBR files to be 0.227% too long, due to a rounding error. FITNR.

Peter

cool. thanks. but what happens to all the VBR tracks already on the device? are we gonna need to re-up it? if so, might i suggest in creating a program to regenerate all *1 fids that is run directly on the empeg? probably a lot quicker if most of the encoded songs are VBR than reuploading.

If you get a moment, can you drop me a line with the patch for that so I can fix RMML/jEmplode also?

If you get a moment, can you drop me a line with the patch for that so I can fix RMML/jEmplode also?

In tags/mp3_frame_info.cpp at about line 363,

length_ms = (m_xingHeader.frames * frame_len) / (m_xingHeader.samprate / 1000);

is obviously wrong and should read:

length_ms = (int)((UINT64)m_xingHeader.frames * frame_len * 1000 / m_xingHeader.samprate);

This stuff is GPL and in Emptool.

Peter

Ah yes .. I'm guessing the original was to avoid an overflow, since I recall changing another one of these in RMML/jEmplode for the same reason. I don't know how similar our two versions are anymore, but I have a similar line in my parseXingHeader and parseVBRIHeader. I can't recall now if I changed the second one TO the broken way as an overflow fix. I'll just upcast it to a double .. I think that will keep it from getting screwed up.

Thanks Peter ... ms