# Length (duration) calculation for MP4 files

**URL:** https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527
**Category:** No Bugs
**Created:** [June 5, 2022, 7:15pm UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527 "2022-06-05T19:15:13Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![CamdenTommy](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@CamdenTommy](https://community.mp3tag.de/u/CamdenTommy)
#### Post date: [June 5, 2022, 7:15pm UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527/1 "2022-06-05T19:15:13Z")

</div>

This may not be a new report, but I did a quick check and didn't find it so here goes:

I have an MP4 file where there's a discrepancy between the calculated length in MP3Tag and the length as reported by both VLC Media Player and the Windows Property Details tab, which leads me to believe it may be a problem in MP3Tag. MP3Tag reports the length as 3h57m. VLC Media Player and Properties report it as 4h17m. The file is 24 fps (instead of the more usual 30 or 29.97 fps) so I'm thinking that might the crux of the issue. I'm running the 316-x64 version.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 5, 2022, 7:42pm UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527/2 "2022-06-05T19:42:20Z")

</div>

perhaps this is something similar to mp3s with vbr:

> [@\[X\] VBR Files have a wrong playlength](https://community.mp3tag.de/t/x-vbr-files-have-a-wrong-playlength/2281/24):
>
> 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.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 5, 2022, 8:12pm UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527/3 "2022-06-05T20:12:28Z")

</div>

If you can upload the file and send me a private link to download it, I can have a look and analyze the file. Otherwise it's nearly impossible to say something about it.

---

<div class="post-metadata">

### Author: ![CamdenTommy](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@CamdenTommy](https://community.mp3tag.de/u/CamdenTommy)
#### Post date: [June 5, 2022, 10:40pm UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527/4 "2022-06-05T22:40:50Z")

</div>

I was thinking the discrepancy (a word I chose carefully but unfortunately didn't use consistently) was due to the frame rate, but as you suggest it could very well be related to variable bit rate, as I have no idea what algorithm MP3tag uses or what factors the length/duration estimate is based on. I have only seen the discrepancy once, and if nobody else has noticed the discrepancy on MP4 files, it is IMO not worth Florian's time to pursue it any further, and I apologize for bringing it up.

---

<div class="post-metadata">

### Author: ![CamdenTommy](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@CamdenTommy](https://community.mp3tag.de/u/CamdenTommy)
#### Post date: [June 5, 2022, 10:46pm UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527/5 "2022-06-05T22:46:49Z")

</div>

Thanks for the reply – it’s a huge file and to be honest it’s not a big deal, I just thought you should be aware of it in case someone else comes up with the same problem. Mine could be a one-off and unless it’s a general problem it’s not worth messing with. Cheers!

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 6, 2022, 7:32am UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527/6 "2022-06-06T07:32:06Z")

</div>

OK, I have no other option as to move it to #Bug Reports > No Bugs then. If you find a smaller files that shows a similar discrepancy, please let me know.

One last thing maybe: you could verify the integrity of the file using foobar2000 as outlined here:

> [@How to check files for errors?](https://community.mp3tag.de/t/how-to-check-files-for-errors/44633):
>
> It’s required and often helps to reduce support cycles to check files for errors before filing a bug report. Symptoms of erroneous files are often missing or wrong bitrate or length audible blips or skips tags seem to be sticky and cannot be removed There are some really good tools to check the files for errors, namely MP3 Diags — identifies many different issues in MP3 files Website: [http://mp3diags.sourceforge.net](http://mp3diags.sourceforge.net) Download: [MP3 Diags - Getting MP3 Diags](http://mp3diags.sourceforge.net/010_getting_the_program.html#binWindows) If the font size in MP3 Diags is …

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [July 6, 2022, 6:22pm UTC](https://community.mp3tag.de/t/length-duration-calculation-for-mp4-files/57527/8 "2022-07-06T18:22:08Z")

</div>

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