Odd APIC frame

[Norman Palardy]

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::MPEG::File f(filename);
   if (f.ID3v2Tag())
   {
     TagLib::ID3v2::FrameList l =  f.ID3v2Tag()->frameListMap()["APIC"];
     TagLib::ID3v2::AttachedPictureFrame *p = 0l;
     if(!l.isEmpty())
     {
       TagLib::ID3v2::FrameList::ConstIterator it = l.begin();
       while(it != l.end())
       {
         p = static_cast<TagLib::ID3v2::AttachedPictureFrame *> 
(l.front());
         if(p->type() ==  
TagLib::ID3v2::AttachedPictureFrame::FrontCover || p->type() ==  
TagLib::ID3v2::AttachedPictureFrame::Other)
         {
           break;
         }
         ++it;
       }
       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  
them ?

	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