[X] VBR Files have a wrong playlength

Sorry, but I think that wrong playtime is a big deal. But I belive in Florian and will stay patient. :wink:

I checked on other computer and same thing (1:19:34). :frowning:

Well, I doubt that a deviation of a few seconds is that important. Such errors are normal since the calculation of play times implies floating point calculation and therefore rounding errors. Moreover, there are files which have frames with varying attributes. Take this scenario: an MP3 file consists of frames. 50% of these frames have the padding bit set, the other 50% don't have it set. Now program A can calculate the play time for the whole file taking padding into account, while program B can ignore padding since it's not consistent over the whole file. This simple padding bit can make a difference of a few seconds, depending how long the track is. Now you can't say which of the two programs is right or wrong.

I know all that, but total time then have wrong minutes length. :frowning:

I just wonted for mp3tag to have same playtime like all "standard" programs (winamp, windows media player, cool edit...). -_-

Well, fb2k reports the same length as MP3Tag.

fb2k is maybe faster or use less memory, but I love winamp and his plugins wich are great. :sunglasses:

That's not what I was trying to point out. What I wanted to say is that the playtime issue is not really a bug since other programs (like fb2k) report the same length.

More accurate length reports can be delivered when the whole file was scanned (or at least more than one frame). The problem now is that parsing additional frames will take more time. While this might not be noticable when reading two or three files, it is when reading folders with thousands of MP3s.

milka, the file you've provided has the issue Sebastian already described above. The first frame has no padding bit set, but the second has.

Since Mp3tag only analyzes the first MPEG frame, all calculations are based on this frame. I don't consider this as a bug.

Best regards,
~ Florian

Regarding %_length%, I noticed today that some of, but not all of my MP3 files, which were created from FLAC files, do not show the same time. If the length of the MP3 is different than the length of the FLAC file, it seems to be 1 second off. When I look at the same files in fb2k, this is not the case. The files will have the same times.

From what I can tell, MP3 files get rounded up, but the FLAC version of the song isn't being rounded up.

I have seen the same problem in various MP3 VBR files. MP3Tag reports bitrate as 32kbps and length as (Vbr Rate / 32)*real length, eg. an 3 minute 256k VBR track will be reported as 24 minutes.

This should be fixed with the latest Development Build.

Seems like your files don't have a valid VBR header.

Hmmm. Time shows properly in every other player I have tested the files on (MMJB, WinAmp, PowerDesk Properties, ...).

Any suggestions on a tool to hexdump the VBR header from the MP3? I can throw Perl or Python at the job if needed.

Also, could you give me a URL to the formal spec for the header?

Do you see anything like "Xing" or "VBRI" at the beginning of the MPEG data when you open the file in a hex editor?

Nope. Checked file using XVI32. Text search case insensitive for both strings.

Sorry, but it seems that your files are broken. At least they don't seem to have a VBR header.

Yep. I am coming to that conclusion. All the files in one specific directory show the problem. Must be an artifact of the ripper / encoder used to create the files.

If it is of any value to you I can email you a sample. The smallest example I have is 3.9MB.

Thanks for working on this. However, the rounding issue seems to still be there, although it occurs less frequently. Occassionally, one song from an album will be off by 1 second in the MP3 file when compared to the FLAC file.

After encoding 7 albums to both FLAC and MP3 I still failed at triggering this rounding issue :frowning:

You were definitely correct about the problem and after some digging around I have found a solution.


This utility (source available) scans MP3 files and (re)constructs VBR headers if needed. The fixed files show the correct length in MP3Tag.

FYI. iTunes had the same problem with the files.

There still seems to be a minor discrepancy between tools about what the actual VBR bit-rate is but nothing that appears to be material.


I had some files that were all encoded at 320 but some of them were showing up as very low bitrates like 32 or 48. Windows would report them all at 320K but mp3tag always seemed to have a problem with this particular set of files. I tried everything from removing the tags to upgrading to the newest version of mp3tag but nothing seemed to make them read properly. They would also show up with a very odd file length like over an hour for a 5 minute file. I found this thread and downloaded the tool VBRFIX and it corrected the problem. Now they all show up as 320K in mp3tag.

Thanks to everyone who worked on this thread.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.