iTunes has wrong length for mp3 files.

Question

Level 2

390 points

iTunes has wrong length for mp3 files.

I have several mp3 files that iTunes thinks are much longer then they really are. The Finder preview and QuickTime Player both give the correct length. The files play correctly as well except that the time remaining is incorrect. When the end of the song is reached iTunes starts playing the next song. The files play correctly, but it annoys me. If I use "Convert to mp3" on one of the problem files, the converted file shows up properly. I would prefer not to do this though, as it would degrade the quality of the file.

Does anyone have any idea what could cause this and/or how to fix it?

15" Titanium PowerBook G4 Mac OS X (10.3.9) iTunes 6.0.4

Posted on Mar 6, 2006 11:25 AM

Reply

Answer 1

Kevin Lemens Author

Level 2

390 points

Mar 6, 2006 12:05 PM in response to Kay Marczoch

According to iTunes the bitrate of the offending files is 32 kbits/sec. QuickTime gives bitrates in the 180-200 kbit/sec range. I think that's the cause of the discrepancy. Any ideas how to go about fixing it?

Reply

Answer 2

Mar 6, 2006 11:57 AM in response to Kevin Lemens

This erratic behaviour may be caused be slightly corrupted files and/or id3 tags.

Try to open a Get Info window on those files and check options/start,stop time.

Reply

Answer 3

Mar 6, 2006 12:13 PM in response to Kevin Lemens

If owning QuickTime Pro save/export those files through QT.

Reply

Answer 4

Kevin Lemens Author

Level 2

390 points

Mar 7, 2006 7:16 AM in response to Kevin Lemens

I figured out what the problem is. iTunes isn't recognizing that the files are VBR (Variable Bit Rate) files. I found this site:
http://txfx.net/2005/02/08/vbr-mp3-fix/
I'm in the process of trying the solution given there.

Reply

Answer 5

Mar 7, 2006 7:53 AM in response to Kevin Lemens

Good job noticing that! I opened up one of my MP3s in BBEdit (without QuickTime Translation) and found a single XING listed near the end of the header. I'm not too happy running software 'not tested with mpeg 2 5' and 'completely untested'.

This looks like it could be a simple fix (CLI) if what needed to be added was better documented here.

Think you could compare an unfixed file to a fixed one and see if the difference is easily added to any MP3? It might be best to do this on copies and convert the ID3 tag first to test it.

I'm surprised converting the tag from iTunes doesn't fix this.

Reply

Answer 6

Mar 7, 2006 8:02 AM in response to Jason Trindade

I've wondered about this for some time, and realized it was something to do with the VBR, but didn't really have time to worry about it. But I agree, it's a bit scary to read "Not tested at all. Note version 1 doesn't mean it is complete, just the 1st version put on the website. USE AT OWN RISK". Maybe I'll wait a bit to try it 🙂

Reply

Answer 7

Kevin Lemens Author

Level 2

390 points

Mar 7, 2006 8:14 AM in response to Jason Trindade

I'll let you know how it turns out.

What really bugs me is that QuickTime identifies it correctly but iTunes doesn't. Doesn't iTunes rely on QuickTime? Anyway, that reminds me, I need to post feedback to Apple about this.

Reply

Answer 8

Mar 7, 2006 9:45 AM in response to Kevin Lemens

If you bugged it or are going to...

Is the fix working on this file for example?

http://www.gutenberg.org/dirs/etext05/shsof1601.mp3

it reports different lengths by about 5 seconds (low bitrate file).

iTunes, the finder preview in column view, and get info > more info (disclosed) calculate the same erroneous time.

Worse, if you advance the start time a few seconds in iTunes it plays fine, but if you burn it the file starts at a different place further back (crops). This makes it almost useless.

I have no idea why the finder defaults to the iTunes calculation method, but it seems like there are two mp3 codecs installed. One as part of quicktime (intermediate? or packaged in the app) and the other part of iTunes...and the iTunes one is erroneous?

My guess... it's not the app, but the component used in playback. The Finder has it wrong as well (at least on my system with that file).

Reply