Mutagen returning wrong file length

[GoogleCodeExporter]

Hi,

The file can be downloaded here :http://www.sendspace.com/file/fzhiqi 

When I put the file into a banshee media player, I see the length as 1:55:46 
(6946832ms). However, when I run x=mutagen.File('temp_test.mp3', easy=True) and 
print x.info.length, I get 6952.something seconds. It is different by 6 secs.

Is this a bug?

Thank you.

Original issue reported on code.google.com by james.m...@sourcefabric.org on 29 Jun 2011 at 6:12

[GoogleCodeExporter]

The file is indeed estimated at six seconds too long, but I haven't bothered to 
find out why yet. Probably a missing, bad, or unsupported VBR header.

Original comment by joe.wreschnig@gmail.com on 29 Jun 2011 at 7:44

• Changed state: Accepted

[GoogleCodeExporter]

Thank you for the reply.

Can you please guide me on how to spot an issue on this?
We need this so bad :(

Thank you.

Original comment by james.m...@sourcefabric.org on 30 Jun 2011 at 5:46

[GoogleCodeExporter]

The file does have some kind of LAME header, but I don't know offhand what 
information is in it. If you need to fix it I'd suggest starting with 
http://code.google.com/p/mutagen/issues/detail?id=66 which parses some parts of 
a LAME/Info header, and then figure out what else in there might be useful to 
calculate length accurately.

Original comment by joe.wreschnig@gmail.com on 30 Jun 2011 at 7:29

[GoogleCodeExporter]

CBR length calculation was wrong: It used the rounded frame_length values (for 
finding the next frame) including the current frame's padding.

I've also removed the hard coded 144/72/48 values for calculating the frame 
length, since they are just frame_size / 8.

+ adjusted tests (the first two fail with the old calculation, the other two 
round to the same length)

regarding self.padding/self.protected(frame crc): as far as I understand it 
they are frame specific, so they could be removed.

Original comment by reiter.christoph@gmail.com on 2 Jul 2011 at 12:04

Attachments:

• mpeg_length.patch

[GoogleCodeExporter]

Related: The following patch removes the code that should have prevented 
impossible lengths using bitrate/file size, but was never called because the 
arguments in seek are switched. Also the calculation is wrong, resulting in 
1/64 of the real length (if it would have triggered).

Since nobody will miss it and it introduces extra IO, remove it.

Original comment by reiter.christoph@gmail.com on 2 Jul 2011 at 9:51

Attachments:

• mpeg_length_remove.patch

[GoogleCodeExporter]

Thank you for the patch guys, however, that patch didn't fix the problem. I am 
still getting 6 secs longer on the file. Have you guys tested on the file that 
I provided?

Thank you for your support.

Original comment by james.m...@sourcefabric.org on 5 Jul 2011 at 3:15

[GoogleCodeExporter]

Yes, I've tested with your file. Did you apply the first patch 
(mpeg_length.patch)?

"MPEG 1 layer 3, 320000 bps, 44100 Hz, 6946.32 seconds"

Original comment by reiter.christoph@gmail.com on 5 Jul 2011 at 4:41

[GoogleCodeExporter]

Ok sorry about the confusion. Your patch works great.
I have several questions to ask you.

1. What type of files or situations does this bug happen?
2. Is it possible for you guys to release a new version of mutagen with this 
patch?

Thanks for your great support.

Original comment by james.m...@sourcefabric.org on 6 Jul 2011 at 6:11

[GoogleCodeExporter]

This issue was closed by revision r119.

Original comment by reiter.christoph@gmail.com on 24 Jul 2012 at 7:48

• Changed state: Fixed

[GoogleCodeExporter]

The simplification in the first patch wasn't correct for layer 1... use trunk.

james: CBR files with no VBRI/Xing header, depending on the file length.

Original comment by reiter.christoph@gmail.com on 24 Jul 2012 at 8:03