MP3Tag timing (1h00m00s) (probably ID3v2 tag, and ID3v1 are calculated as audio data on CBR MP3 files)
MPC-HC timing (59m51s - the right one)
have you checked the file with the a tool to rule out that the file has a problem?
And then it would be nice, if you could supply such a file.
Checked with MP3Diags / MP3val / fobar2000. All good, no errors on MP3. The timing problem is not happening on a singular file. Good timing on Winamp/Foobar2000/MPC-HC/VLC/Media Player/WMP/IrfanView/Aegisub etc, but not on MP3tag. Tested with different files (with and without tags). Same results, MP3tag (v3.31a) gives wrong time of file. The only fix is to write a Xing/Info header (with MP3packer) to help MP3Tag see real time of file
Can you try with the latest development version ? 3.31d
I compared the data of the following files in Foobar and MP3tag:
| Track | MP3tag | Foobar |
|---|---|---|
| Moon Sequence | 06:19 | 6:18.868 |
| Heavy air | 07:00 | 6:59.802 |
| In search of | 03:33 | 3:33.487 |
| Walk into space | 06:55 | 6:54.943 |
TBH I do not see a significant difference.
I compared the longest Mp3 I have with Mp3tag and Foobar and the results are the same
Foobar2000
Mp3tag
Edit: Maybe send a link to your test file to Florian via PM so he can have a look (refer to this thread if you do so)
I sent a link with instructions to upload the file via PM.
Thank you for the example file. It seems like the file uses no frame padding for the first frame (frame size = 417) and padding for subsequent frames (frame size = 418), so that calculation using the initial frame size is off by the margin you've observed.
I'll probably need to come up with a different way to calculate this in those cases (maybe simple file_size * 8 / bps). Looking at each frame would be too time-consuming.
I'll keep you posted.
2 Likes
This is now fixed with Mp3tag v3.31e. Thank you for reporting!
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.