Hello. I have some mp3 files that are 32kbps stereo at 11khz. When I try getting the duration with getID3, it is always a bit too short. If I open the mp3 files in any player, they all have the correct duration, but getID3 seems to return the wrong one.
I have used ['playtime_seconds'] and ['playtime_string'], and the duration is always the same (too short). Does anyone know a fix for this? Thanks in advance for any input!
Duration is wrong
-
James Heinrich
- getID3() v1 developer
- Posts:1477
- Joined:Fri May 04, 2001 4:00 pm
- Are you a spambot?:no
- Location:Northern Ontario, Canada
- Contact:
Re: Duration is wrong
If you can provide a sample file I can take a look.
-
leafsfan
- User
- Posts:2
- Joined:Tue Apr 01, 2014 5:22 pm
- Are you a spambot?:no
Re: Duration is wrong
Thanks for your reply, James! The mp3 file is located at https://www.dropbox.com/s/lj3wsj65wgl5kj8/ramsden.mp3
It should be 14:59 or 899918 milliseconds. But getID3 says that it is 14:56 (895700 milliseconds).
Thanks for your help with this! I really appreciate it!
It should be 14:59 or 899918 milliseconds. But getID3 says that it is 14:56 (895700 milliseconds).
Thanks for your help with this! I really appreciate it!
-
James Heinrich
- getID3() v1 developer
- Posts:1477
- Joined:Fri May 04, 2001 4:00 pm
- Are you a spambot?:no
- Location:Northern Ontario, Canada
- Contact:
Re: Duration is wrong
I took a quick look at your sample file.
getID3 says: 895.7 seconds
Winamp says: 895 seconds
CoolEdit 2000 says: 14:55.708 (as in 895.708 seconds)
Adobe Audition says: 14:55.708 (as in 895.708 seconds)
BS Player says 14:55
Windows Media Player says 14:55
Windows Explorer says 14:55
QuickTime Player v7.7.4 (Windows) says 14:59.92
VirtualDubMod v1.5.1 says 14:59.975
There is a 32-byte ID3v2 header, but that shouldn't be enough to throw off any time estimates.
Interestingly, I decoded the MP3 -> WAV via both VirtualDubMod (since it sees the longer time interval), and Winamp (which sees the 14:55 playtime on initial load) and the rendered waveform is 14:59.918 from VirtualDub and 14:59.757 from Winamp. At a quick listen to the playback, it would seem that there's about 2 seconds missing from the beginning and 2 seconds missing from the end when the file is decoded as the 14:55 playtime.
The MP3 has 17,225 frames of 208 bytes each = 3,582,800 bytes + 32 bytes for ID3v2 header = 3,582,832 filesize.
Since this is MPEG v2.5 Layer III there are 576 samples per frame, at 11025 samples per second = 17225*576/11025 = 9,921,600 samples / 11,025 samples/second = 899.918 seconds
getID3 (and I suspect many other programs) obtains its calculated 14:55.7 playtime from 3582832-32 bytes of audio data, at 32000 bits per second gives exactly 895.7 seconds ((3582832 - 32) * 8) / 32000 = 895.7
At this point I don't see how the two conflicting data should be reconciled. I'll have to look at it in more detail later.
getID3 says: 895.7 seconds
Winamp says: 895 seconds
CoolEdit 2000 says: 14:55.708 (as in 895.708 seconds)
Adobe Audition says: 14:55.708 (as in 895.708 seconds)
BS Player says 14:55
Windows Media Player says 14:55
Windows Explorer says 14:55
QuickTime Player v7.7.4 (Windows) says 14:59.92
VirtualDubMod v1.5.1 says 14:59.975
There is a 32-byte ID3v2 header, but that shouldn't be enough to throw off any time estimates.
Interestingly, I decoded the MP3 -> WAV via both VirtualDubMod (since it sees the longer time interval), and Winamp (which sees the 14:55 playtime on initial load) and the rendered waveform is 14:59.918 from VirtualDub and 14:59.757 from Winamp. At a quick listen to the playback, it would seem that there's about 2 seconds missing from the beginning and 2 seconds missing from the end when the file is decoded as the 14:55 playtime.
The MP3 has 17,225 frames of 208 bytes each = 3,582,800 bytes + 32 bytes for ID3v2 header = 3,582,832 filesize.
Since this is MPEG v2.5 Layer III there are 576 samples per frame, at 11025 samples per second = 17225*576/11025 = 9,921,600 samples / 11,025 samples/second = 899.918 seconds
getID3 (and I suspect many other programs) obtains its calculated 14:55.7 playtime from 3582832-32 bytes of audio data, at 32000 bits per second gives exactly 895.7 seconds ((3582832 - 32) * 8) / 32000 = 895.7
At this point I don't see how the two conflicting data should be reconciled. I'll have to look at it in more detail later.
-
jrf
- User
- Posts:2
- Joined:Mon Aug 11, 2014 11:51 am
- Are you a spambot?:no
Re: Duration is wrong
Hi James, leafsfan,
I'm running into a related issue, where the 'playtime_string' and 'playtime_seconds' are off by a second most of the time.
I kind of think this is to do with the calculations with floats which have a notorious loss of precision. I'll do some tests locally to see if that's the cause. If so, I'll send in a pull request to the GitHub repo with the fix.
Smile,
Juliette
I'm running into a related issue, where the 'playtime_string' and 'playtime_seconds' are off by a second most of the time.
I kind of think this is to do with the calculations with floats which have a notorious loss of precision. I'll do some tests locally to see if that's the cause. If so, I'll send in a pull request to the GitHub repo with the fix.
Smile,
Juliette
-
jrf
- User
- Posts:2
- Joined:Mon Aug 11, 2014 11:51 am
- Are you a spambot?:no
Re: Duration is wrong
Ok, tested and finding that it's not so much to do with GetID3, but with the way WordPress has implemented it's use...
-
James Heinrich
- getID3() v1 developer
- Posts:1477
- Joined:Fri May 04, 2001 4:00 pm
- Are you a spambot?:no
- Location:Northern Ontario, Canada
- Contact:
Re: Duration is wrong
I'd be surprised if float imprecision had anything to do with it. A float will have a generally-imprecise value, but that value should be many many decimal places over from being relevant to the duration of an audio/video file (as in it might be off by a few nanoseconds, possibly even microseconds, but nothing more than that from float-based errors).