- Status Closed
- Percent Complete
- Task Type Bugs
- Category ID3 / meta data
- Assigned To No-one
- Operating System All players
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#9453 - Bad meta-data cause momentary freeze when playing
Trying 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
Closed by Buschel
2011-02-03 11:41
Reason for closing: Works For Me
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
2011-02-03 11:41
Reason for closing: Works For Me
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
No issues with r29902 (on iPod Video
30GB and sim).
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
It seems the file has an invalid jpeg image embedded in it, maybe it’s the cause of the problem ?
I don’t think that’s the cause. This file has the same invalid jpeg and starts playing immediately:
http://itc.conversationsnetwork.org/audio/download/ITC.SO-Episode18-2008.08.19.mp3
I looked at the difference between the original mp3 and the same file modified by id3v2 -C:
- 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
I forgot to mention that when I extract the image with eyeD3 -i . from the 2 files, they are identical ..
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.
I suspect adding a periodic yield() to __find_next_frame (in apps/mp3data.c) would fix the freezing. Playback would still be a bit slow to start though.