Odd APIC frame
npalardy at great-white-software.com
Thu Jul 13 22:19:14 CEST 2006
I'm working with a few mp3 files from various sources.
There seems to be a couple that have very odd attached pictures that
taglib gets just slightly wrong.
Apple's iTunes and MS' Windows Media seem to handle these though.
A test suggests that one of the differences is the mimetype that
taglib reports for these pictures.
One that I can read the image from successfully reports "image/png"
as the mime type.
The one I cannot read the picture from reports the mime type is "PNG".
I've looked at both with a hex editor and indeed they do seem to have
different frame types, but when I use code like
TagLib::ID3v2::FrameList l = f.ID3v2Tag()->frameListMap()["APIC"];
TagLib::ID3v2::AttachedPictureFrame *p = 0l;
TagLib::ID3v2::FrameList::ConstIterator it = l.begin();
while(it != l.end())
p = static_cast<TagLib::ID3v2::AttachedPictureFrame *>
TagLib::ID3v2::AttachedPictureFrame::FrontCover || p->type() ==
TagLib::String tls = p->mimeType();
std::cout << tls.toCString(unicodeStrings) ;
I get these two different mimetypes
And when I get the picture data, the one that has the PNG type has 11
bytes missing from the PNG header, so it ends up with a mangled picture.
A couple questions :
1) has anyone seen files like this before and how did you deal with
2) if this is unique, does anyone have an idea what I should hunt
down in the handling of the ID3 tags to fix this ?
And if anyone wants these two files I'd be glad to send them along
for further analysis
More information about the taglib-devel