- Status Closed
- Percent Complete
- Task Type Bugs
- Category Codecs
- Assigned To No-one
- Operating System Sansa AMSv2
- 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 rasferret - 2013-03-28
Last edited by bluebrother - 2013-04-29
Opened by rasferret - 2013-03-28
Last edited by bluebrother - 2013-04-29
FS#12849 - very long parsing time of some mp3 files
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:
I’m using a clip zip with the build 9add11d. timestreching enabled, but not used in this case.
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
Does this file have album art embedded? If so which size?
Yes there is cover art embedded.
300x300 jpg 36KB
Here's a tag export by mp3tag. The file embedds ID3v2.3 tags and there is a very long comment tag with umlauts
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.
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.
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.
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.
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?
With the latest nightly build 850491a it seems to be fixed. Thanks for the effort.