Home » Bug #2377

[2004-09-23 09:44 UTC] yom at yom dot be

Description:
------------
I'm using MP3_ID v1.7.

There's a mistake in the _readframe() function : when it looks for a frame sync, it first seeks a chr(255) and next checks if the next 3 bits are set. But that 3-bits checks isn't correct and fails on some files.

Reproduce code:
---------------
http://y0m.net/mp3_id/before.php : a sample mp3 where MP3_ID finds a wrong frame sync, with debug. We clearly see that only the first 10 bits are set (11111111110111111111001010011111), so the MP3 informations are rather strange (Bitrate : 0 Frequency : 44100 Mode : Dual Channel Length : -1:59)

Replacing line 659:
} while (!$bits[8] and !$bits[9] and !$bits[10]); // 1st 8 bits true from the while
With 'or' instead of 'and':
} while (!$bits[8] or !$bits[9] or !$bits[10]); // 1st 8 bits true from the while

And you get that result, much better : http://y0m.net/mp3_id/after.php
The script now finds an actual frame sync and gets the right informations from file (Bitrate : 128 Frequency : 44100 Mode : Joint Stereo Length : 97:57)

[2004-09-24 13:44 UTC] alexmerz at php dot net

According to the MP3 frame header definition, the behavoir is correct:

"meaning that you have to find a byte with a value of 255, and followed by a byte with its three most significant bits set"
(http://mpgedit.org/mpgedit/mpeg_format/MP3Format.html)

In your file(s) the last one bit it not set. Your mp3 file is corrupt, not the class.

It would be possible to change the behavoir, but this may cause problems with MP3 files containing ID-Tags v2.