View Single Post
Old 1st May 2014, 00:28   #32
Join Date: Sep 2003
Posts: 27,873
i've finally had a chance to work on this. as such we weren't handling the (incorrectly formatted) value in the APIC tag for the mimetype (we were only expecting image/* instead of just * as with the case of that file). so now we're able to pull the type from these other types of files (which i'm sure is at odds with the expected values but meh, when is anything correctly with ID3v2.x anyway).

additionally i've altered our handling of the origin information so it'll now better cope with cases where there's incomplete embedded artwork and the actual artwork shown is from another source (so it'll show as folder.* now for that file for me which is correct).

as for the bad artwork in the file, it's missing 9 bytes from the start of the file which makes up the PNG file header and by pre-pending them to the start of the data pulled from the APIC frame it's possible to get a working image (like is noted in the other thread). why it's been stored / created missing those bytes i don't know and is at odds with what i've seen elsewhere, but there you go. i probably shouldn't but i'm going to leave the code i put in place to attempt to get a working png file from bad png frames (since i've written it and with the other handling changes, it's not going to have a negative impact compared to skipping over slightly incorrect pieces of artwork).

so as far as i'm now concerned, the actual issues in our code have now been resolved (the initial crash and showing the incorrect origin) and that should leave artwork in a better position than it was (as there were a few other edge cases i found whilst checking over things).
DrO is offline   Reply With Quote