I ran into this problem recently with some podcasts. The problem is
that APIC (2.3+) and PIC (2.2) handle file type differently. APIC uses
a Latin-1 string followed by a nul byte to represent file types. Say,
"image/png\0". PIC, on the other hand, uses just three bytes, so "PNG"
(no termination). As the parser currently searches for the next nul
byte, and 2.2 doesn't have one in the traditional place, the parsing
goes haywire and the frame corrupts.<br>
<br>
<div>The TagLib# AttachedPictureFrame (<a href="https://forgesvn1.novell.com/viewsvn/taglib-sharp/trunk/taglib-sharp/src/TagLib/Id3v2/Frames/AttachedPictureFrame.cs?view=markup" title="https://forgesvn1.novell.com/viewsvn/taglib-sharp/trunk/taglib-sharp/src/TagLib/Id3v2/Frames/AttachedPictureFrame.cs?view=markup" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://forgesvn1.novell.com/viewsvn/taglib-sharp/trunk/taglib-sharp/src/TagLib/Id3v2/Frames/AttachedPictureFrame.cs?view=markup</a>) does the following:<br><br><pre> int pos = 0;<br><br> text_encoding = (StringType) data [pos];
<br><br> pos += 1;<br> <br> int offset;<br> <br> if (Header.Version > 2)<br> {<br> offset = data.Find (TextDelimiter (StringType.Latin1), pos);<br><br> if(offset < pos)
<br> return;<br><br> mime_type = data.Mid (pos, offset - pos).ToString (StringType.Latin1);<br> pos = offset + 1;<br> }<br> else<br> {<br> ByteVector ext =
data.Mid (pos, 3);<br> if (ext == "JPG")<br> mime_type = "image/jpeg";<br> else if (ext == "PNG")<br> mime_type = "image/png";<br> else
<br><br> mime_type = "image/unknown";<br> <br> pos += 3;<br> }</pre></div>
<br>- Brian Nickel<br><br><div><span class="gmail_quote">On 7/13/06, <b class="gmail_sendername">Scott Wheeler</b> <<a href="mailto:wheeler@kde.org">wheeler@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Jul 13, 2006, at 11:13 PM, Norman Palardy wrote:<br><br>><br>> On Jul 13, 2006, at 2:51 PM, Scott Wheeler wrote:<br>><br>>><br>>> On Jul 13, 2006, at 10:19 PM, Norman Palardy wrote:<br>>>
<br>>>> I'm working with a few mp3 files from various sources.<br>>>><br>>>> There seems to be a couple that have very odd attached pictures that<br>>>> taglib gets just slightly wrong.
<br>>>> Apple's iTunes and MS' Windows Media seem to handle these though.<br>>><br>>> Just a guess, but this may be the fact that iTunes has a bug in its<br>>> synch safe integer implementation (it doesn't use them, basically),
<br>>> so it ends up writing invalid lengths for images which messes things<br>>> up in some cases. WMP may have a work around for the iTunes bug.<br>>> What are the sizes of the images that aren't being read properly?
<br>><br>> Manually I copied the data based on the values in the frame (what<br>> appears to me to be a a PIC frame) into a new file, saved it and<br>> then opened it in a image editor. So the value seems to be correct.
<br>> It was only 49974 bytes.<br>><br>> The first 512 bytes of the file are (a snapshot from the hex editor<br>> I use)<br>> <Picture 1.png><br>><br>> When I retrieve the apic frame and iterate over the bytes I see
<br>> that the first 11 bytes of the picture data are not part of the<br>> returned data<br><br>Ah, it's ID3v2.2 -- indeed I haven't really tested APIC (or rather<br>"PIC" in ID3v2.2 terms). It would be useful if you could file a bug
<br>report (and ideally send me the file with the filename as [bug report<br>number].mp3 since I won't be able to seriously look at the issue for<br>a few days and things less often get lost in the bug system.<br><br>Cheers,
<br><br>-Scott<br>_______________________________________________<br>taglib-devel mailing list<br><a href="mailto:taglib-devel@kde.org">taglib-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/taglib-devel">
https://mail.kde.org/mailman/listinfo/taglib-devel</a><br></blockquote></div><br>