• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category ID3 / meta data
  • Assigned To No-one
  • Operating System iPod 5G
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by ajkessel - 2009-01-16
Last edited by Buschel - 2011-01-30

FS#9805 - m4a metadata read or stored incorrectly

I have an album of m4a tracks. As far as I can tell with any other tool, they all have the identical “genre” tag – “Country”. Yet the album gets split up by RB 3.1 across several genres:


Re-initializing the database doesn’t change the result.

I can provide a sample of the tracks offline if necessary.

Closed by  Buschel
2011-01-30 20:24
Reason for closing:  Fixed
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

Fixed with r29174.

Hi, this seems to be a limitation of the metadata parser when there are very long tags present in the file.
See the forum discussion about this problem here:

Thanks, that seems like a likely cause – either the “comment” field (which MediaMonkey imports from the Amazon album description) and/or the album art. The thread you linked suggested a simple workaround of just increasing ID3V2_BUF_SIZE. Any reason not to do that at least for the iPod 5G builds? I would be happy to test such a build to confirm that it fixes my error.

Because you could also just strip the extraneous tags that we don’t support anyway, like the embedded album art, rather than asking all users to give up a bit of *their* RAM so you can preserve tags Rockbox doesn’t even support anyway.

According to the linked forum thread (post 4) the problem is with tags that rockbox actually supports, so stripping the extraneous tags won’t solve this problem.

Re Llorean – many people who use automated tagging tools will have this problem. It isn’t that I have some special predilection for extra information, I just pointed MediaMonkey at the folders and said “tag it.” The result here can’t possible be the correct behavior. The files work fine with iPod firmware, but then the user is told he needs to reprocess all his automatically tagged files so they display correctly in RB. However it is fixed, I can’t see why RB shouldn’t read in the track, genre, artist, and album correctly (assuming those tags don’t exceed any limits, which I don’t think they do for any of the cases we’re talking about here.)

You can just as easily use MediaMonkey to remove unneeded/unsupported (by Rockbox) tags. Select all files and edit for all files.

But then you’re asking the user to maintain two separate sets of music files (one on the computer, the other for the portable device). Is this a workaround hack or a proposed solution? I assume many users sync their music collection (or some subset thereof) from their computer to the portable device and vice-versa. If the goal is for Rockbox to usable by non-sophisticated people (?), the solution can’t possibly be to tell them they need to edit the metadata on all of the files that play fine on iPod/iTunes and other desktop sofware.

See, we have very limited RAM on Mp3 players (being highly embedded systems). Additionally, Rockbox runs on many players, some of which have much lower RAM than your iPod. And we want to support all equally, getting more out of it (especially battery runtime).

Saving RAM where possible is essential for the battery runtime. So please do not compare Rockbox with the possibilities of a desktop music player, which don’t need to worry about RAM and stuff. And, well, the iPod has pretty much RAM, so Apple probably didn’t care about efficient RAM usage either.

I’m just trying to compare an iPod running RB with an iPod running the Apple firmware – since RB is built for each platform, why can’t it at least work properly on the iPod regarding this metadata issue? Or is there a better fix that doesn’t require more RAM use? It seems like the issue here is the wrong metadata is being stored in RAM; the tags we see (artist, album, genre, track name, track number) are not overloading the buffer.


Available keyboard shortcuts


Task Details

Task Editing