Rockbox

Tasklist

FS#12849 - very long parsing time of some mp3 files

Attached to Project: Rockbox
Opened by Wolfgang Dilg (rasferret) - Thursday, 28 March 2013, 12:43 GMT
Last edited by Dominik Riebeling (bluebrother) - Monday, 29 April 2013, 16:50 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To No-one
Operating System Sansa AMSv2
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Some mp3 files I've listened to the other day take a very long time to load or being parsed in the properties dialog. The player stopps responding for a minute or so before starting playback or displaying the file properites. After that it also takes a very long time to stopp playback or shutting down the player. The transition to the next file also takes this long time.

Here's a link to one of the files:

http://cdn-storage.br.de/mir-live/MUJIuUOVBwQIb71S/iw11MXTPbXPS/_2rc_71S/_-QS/52vd5-ZS/120923_2205_Zuendfunk_Die-Macht-der-Bildermacher.mp3

I'm using a clip zip with the build 9add11d. timestreching enabled, but not used in this case.
This task depends upon

Closed by  Dominik Riebeling (bluebrother)
Monday, 29 April 2013, 16:50 GMT
Reason for closing:  Fixed
Comment by Marcin Bukat (MarcinBukat) - Monday, 22 April 2013, 18:12 GMT
Does this file have album art embedded? If so which size?
Comment by Wolfgang Dilg (rasferret) - Monday, 22 April 2013, 19:02 GMT
Yes there is cover art embedded.

300x300 jpg 36KB
Comment by Wolfgang Dilg (rasferret) - Monday, 22 April 2013, 19:12 GMT
Here's a tag export by mp3tag. The file embedds ID3v2.3 tags and there is a very long comment tag with umlauts
Comment by Dominik Riebeling (bluebrother) - Monday, 22 April 2013, 19:39 GMT
As far as I can tell this is related to the album art embedded in the tag. A similar issue has been reported in the forums (http://forums.rockbox.org/index.php/topic,42955.0.html) recently in which the file contains an album art image of almost 300kiB. While the file linked above has only 36kiB stripping the APIC tag makes it play almost instantly as expected (I'm on an e200v1). The same is true for the file linked in the forum post.
Comment by MichaelGiacomelli (saratoga) - Thursday, 25 April 2013, 19:20 GMT
To be clear, I think this is some kind of bug. We generally seem to be able to parse very large tags with embedded art just fine, so the fact that a few files don't work so well suggests that we have some kind of bug.
Comment by Dominik Riebeling (bluebrother) - Friday, 26 April 2013, 19:07 GMT
Ok, I did some more investigation on this issue. This is a Rockbox issue (and no weird metadata).

Both files in question have ID3v2.3 tags with the "unsynchronization" bit set. The function parsealbumart() states that unsynchronizing album art is not supported so it should simply skip the album art. If I rewrite the tag (using foobar2000) I get a file with the unsynchronization bit cleared. This file plays fine (tried on e200v1). There is a small delay when loading the file but this is something like 1 - 2 seconds (instead of 30+) which isn't surprising to me given that the album art is ~300kiB. The file linked in this task (with an album art image of ~36kiB) loads similarly fast as other files without album art.

Since both files load as expected when the tag is rewritten with the unsynchronization bit cleared and also album art is shown without issues this looks like a problem in skipping album art when the tag uses unsynchronization. If Rockbox doesn't support album art in this case it should skip it gracefully.
Comment by MichaelGiacomelli (saratoga) - Friday, 26 April 2013, 19:13 GMT
I'm kind of amazed that there is a situation where it could block for 30 seconds on a tag without actually crashing or infinitely looping. Any idea what its doing for all that time? On AMSv2 the player doesn't unboost, so it would be using a full 240MHz that entire time.
Comment by Dominik Riebeling (bluebrother) - Friday, 26 April 2013, 22:13 GMT
Ok, the problem should be fixed with 370ed6d -- at least it doesn't appear for me anymore. Can you please try a development version and confirm this?
Comment by Wolfgang Dilg (rasferret) - Monday, 29 April 2013, 07:31 GMT
With the latest nightly build 850491a it seems to be fixed. Thanks for the effort.

Loading...