FS#9453 - Bad meta-data cause momentary freeze when playing
Opened by Ori Avtalion (salty-horse) - Saturday, 04 October 2008, 18:52 GMT
Last edited by Andree Buschmann (Buschel) - Thursday, 03 February 2011, 11:41 GMT
|
DetailsTrying to play the following file in Rockbox will freeze the player for a few (long) moments. Afterwards, it will show the metadata and play the file.
http://itc.conversationsnetwork.org/audio/download/ITC.SO-Episode19-2008.08.26.mp3 If the file is the next in the playlist, the same freeze will occur. I have no idea what's wrong with the file's tags, but running "id3v2 -C" on it, which "Converts id3v1 tag to id3v2", makes it work again. If the tags are causing a problem, this should not cause a freeze. The freeze has been confirmed on sansa e280 and gigabeat F60 |
Thursday, 03 February 2011, 11:41 GMT
Reason for closing: Works For Me
Additional comments about closing: No issues with r29902 (on iPod Video 30GB and sim).
http://itc.conversationsnetwork.org/audio/download/ITC.SO-Episode18-2008.08.19.mp3
- The total ID3 header size changed
- The ETCO frame (Event Timing COdes) has been marked as discardable
- The JPEG binary data has been modified, weird since this data should be opaque to tagging programs ..
- Adds some padding after the ID3v2 tag
Maybe id3v2 detects an invalid jpeg file and tries to correct it ?
Also there is no ID3v1 tag in the file (I think it's located right at the end after the MPEG stream), but I notice some string with "LAME3.97", not sure what that means.
The problem is very likely in the part that handles the APIC frame. since it's the only thing modified, but in apps/id3.c I found nothing which looks for embedded image (normal since there is no jpeg decompressor in rockbox afaik).
Since the APIC frame size is not modified, I'm not sure what is causing the problem
Rereading the bindiff to check if I have made a mistake, I see that id3v2 removed some bytes:
-0000230: 6400 00ff ec00 1144 7563 6b79 0001 0004 d......Ducky....
+0000230: 6400 00ff 00ec 0011 4475 636b 7900 0100 d.......Ducky...
Here it replaces ffec00 by ff00ec00, effectively replacing ffec by ff00ec
The problem is that 'ffe' can be seen as 11 bits set to 1, which is what decoding software use to synchronize audio frames.
In the ID3v2 tag, 11 consecutive bits set to 1 (starting on byte aligned offset) should never be met, the unsychronization scheme to be used is explained in http://www.id3.org/id3v2.3.0#sec5
So I believe this file (and the tagger used on it) is severely broken, and rockbox can not avoid such problems.