Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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
Attached to Project: Rockbox
Opened by salty-horse - 2008-10-04
Last edited by Buschel - 2011-02-03

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

No issues with r29902 (on iPod Video 30GB and sim).

funman commented on 2008-10-04 22:19

It seems the file has an invalid jpeg image embedded in it, maybe it’s the cause of the problem ?

salty-horse commented on 2008-10-05 11:46

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

funman commented on 2008-10-14 20:54

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

funman commented on 2008-10-14 21:04

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.

learman commented on 2008-11-05 15:20

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing