Rockbox

Tasklist

FS#9453 - Bad meta-data cause momentary freeze when playing

Attached to Project: Rockbox
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
Task Type Bugs
Category ID3 / meta data
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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
This task depends upon

Closed by  Andree Buschmann (Buschel)
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).
Comment by Rafaël Carré (funman) - Saturday, 04 October 2008, 22:19 GMT
It seems the file has an invalid jpeg image embedded in it, maybe it's the cause of the problem ?
Comment by Ori Avtalion (salty-horse) - Sunday, 05 October 2008, 11:46 GMT
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
Comment by Rafaël Carré (funman) - Tuesday, 14 October 2008, 20:54 GMT
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
Comment by Rafaël Carré (funman) - Tuesday, 14 October 2008, 21:04 GMT
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.
Comment by Magnus Holmgren (learman) - Wednesday, 05 November 2008, 15:20 GMT
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.

Loading...