Track length sometimes incorrect


I have one track that shows up as 40:34 under length in the Mp3tag file list. When I play it in foobar or WMP it's length is listed as 40:22 and does stop at 40:22.

Just curious why these two applications would differ in their display of the track length?



What kind of a file is it, MP3? Which program did you use to encode the file?


OOps, sorry. forgot the most important part. Anyway it is a VBR MP3 file created using Lame via the --alt-preset standard switch.

Let me know if there's anything else I can tell you.

Thanks :music:

You did not use -t as additional argument, right?

I am asking, because MP3Tag should have a Xing header parser built in, as all my VBR files display the correct length.

Nope, just the basic setting with no extra tags.

Weird... It might be possible that the file is padded with nulls or has nulls at the beginning. :unsure:
Try opening the file with a hex-editor and look at the beginning and end.

Hi Sebastian, do you have any suggestions for programs to use to do this?


I use WinHex, but it's not freeware. Check this out:

Is there somewhere online that shows the format of the MP3 file? esp with regards to the frames?

Are you asking for a program which can tell you the number of frames? Have a look at EncSpot Basic.

I've always had problems with duration on my MP3 VBR files being shown correctly. After getting tired of this, I found a applet called VBRFix. It's beta and it's use at your own risk, but I've done lots of files without any problems. I added it to the tools menu so I can just right click a series of MP3s.

Just a thought.


I guess i'm trying to find out how a typical MP3 application determines the duration of a file. If I can determine that, I can probably go through my file and try and manually add up the times. MP3Library can tell me the numer of frames at each bit rate and also where the first "valid frame" begins. From that info can I manually calculate the duration of a file?

Thanks again, i'm just really curious about the structure of the file being a programmer also (mainframe not PC).

You know, I'm curious about this too. Micro$oft says that WMP gets the MP3 duration from the TLEN frame. When I manually set the TLEN tag in MP3Tag, it still reports the same incorrect time.

VBRFix has an option to preserve or clear the LAME header when it corrects my VBR MP3s. This implies the LAME has it's own headers which are independent of the others.

If there are multiple potential locations to get VBR duration from, this would explain why different applications report different playing times.


erweiterte lokale cddb Abfrage

The post is in German, but the pseudo code is English. :slight_smile:

Windows Media Player 10 calculates the duration of the file based on the Xing header. VBR files encoded by Fraunhofer encoders will not work correctly with WMP (what the duration is concerned) because they use a VBRI header.
Older versions of WMP used to read the duration from the TLEN frame of ID3v2.3 tags.

Hmmm. OK I found out from browsing on Hydrogenaudio that each MP3 frame is made up of 1152 samples and that each frames duration can be calculated using 1152/frequency, so in my case all my "problem" files frames are 1152/44100 seconds long which calculates out to be 0.02612244897959183673469387755102 seconds.

Thread posting here:

Using MP3Library I determined that there are a total of 92,720 frames and when I multiply it out I get 2422 seconds which is 40 minutes and 22 seconds which is what I would have expected and has shown to be the correct duration.

Am I missing something here? I'm wondering if somehow the calculations are being rounded up and not using the full precision of the frame duration string? :flushed: