- Status Closed
- Percent Complete
- Task Type Patches
- 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 Jason Yu - 2011-03-13
Last edited by Andree Buschmann - 2011-03-15
Opened by Jason Yu - 2011-03-13
Last edited by Andree Buschmann - 2011-03-15
FS#12009 - m4a (iTunes) embedded album art
Reads the covr tag and sends data to the id3 embedded art structure.
Wasn’t entirely sure how to deal with the file offset when consuming the data. Incrementing the offset like read_mp4_tag does causes a codec failure on target (iPod 5G); worked fine when I either left it alone or returned it to the original position with an additional lseek.
m4a-covr.diff
(1.5 KiB)
Closed by Andree Buschmann
2011-03-15 20:18
Reason for closing: Accepted
Additional comments about closing:
2011-03-15 20:18
Reason for closing: Accepted
Additional comments about closing:
Submitted with r29591.
Can you please attach such m4a-files (1x png, 1x jpg) for validation?
Seems to work for my test file. I’ve written AA into it with easytag on linux and rockbox reads and displays the jpg version fine, the png one isn’t displayed but doesn’t cause horrible failure either.
Looking at taglib, there seems to be metadata in the 16 bytes this patch jumps over (denoting the image time), possibly worth reading in.
Removed that read/lseek brainfart. The first 16 bytes produced by read_mp4_atom is the tag header (see read_mp4_tag). The png detection is there for forward compatibility…
Some sample m4a files: http://www.leyline.com.br/itunes.html
Works like charm for me with the files I downloaded from the link above and two other files with embedded art that I have available.