[X] mp3tag handles a bad embed poorly

so I have a mp3 here:

https://www.dropbox.com/s/81wb9uytaf7fjjr/I...20My%20Baby.mp3

and it has an embed that is faulty somehow, and mp3tag does not display it.

however, DrO was able to get it to display it seems via a beta ver of winamp he is working on:

http://forums.winamp.com/showthread.php?p=2992812

assuming that is the embed and not folder art.

so anyway, I'm not sure whats wrong with the embed, but better handling of a bad situation
would be nice.

just to be clear, I love mp3tag and am saying this just to try to help! thanks.

I downloaded the Mp3 and extracted the Cover Art.

Mp3tag saved it to my computer, I then renamed the file to have a png extension.

I tried to open that png with Irfanview (IMHO the best Picure Viewer out there) (with all Plugins installed)

And IrfanView come up with the error: "Can't read file header", and if IrfanView can't read it, there is definitely something wrong with it.

(Please note: Even if you give the picture a wrong extension, Irfanview will warn you, just try it, rename a jpg to a bmp and Irfanview will warn you and will rename it for you.)

But I have no idea why that other program can open it, maybe it uses a Cached version of the image (but that is just pure guessing)

With which program did you add the Cover Art ?

I checked the file with MP3diags and that program says
"The file has an APIC frame but the image couldn't be loaded
"Error loading image in APIC frame".
So the source is somehow corrupted.

I DL'd the file so idk how the pic got in it. in my mp3tag it says its a 161KB file but 0 resolution.

I now think DrO was messing with me before and he did not get it to display.

but are you guys both saying you could extract the image, but not get it to display? did u try manual extensions?

Using Mp3tag I was able to extract the embedded png file from the media file.
The extracted png file has a corrupt header.
The corrupt png file misses the first 9 bytes (89 50 4E 47 0D 0A 1A 0A 00).
After merging both parts together the png file has been repaired.

There seems to be a bad APIC header in the media file.
The "MIME media type" is not correct ... "PNG" instead of "image/png".
The "Picture type" is missing ... should be e. g. $03 for Cover (front).



See also ...
/t/5607/1

DD.20140428.2055.CEST, DD.20140429.1011.CEST




wow, good work, and that is interesting.

another important data point:

I WAS able to see that art as the "file icon" in windows explorer. for some reason, I no longer can, but for a long time, windows explorer would show it.

I have had other reports from other win7 users saying they could see it as well, in windows explorer.

so my question is why/how is windows explorer able to do it, and why did it stop doing it for me?

AND is it reasonable to expect mp3tag to be able to do it, since windows explorer can do it, at least SOME of the time?

in addition to my questions in my previous post, I now have some more...

are you saying the mp3 file had numerous simultaneous problems?

one problem being the png file inside it? how did you find the 9 missing bytes?
were they already in the file? how were they split so u could merge them? what causes that?

is the other problem in the id3 tag? like, is it the syntax of the APIC frame that is wrong?

I can understand 'mime media type' being required there correctly, but is 'picture type' also
required?

I read the link u gave but I am confused by it to be honest.

I will try to answer ... my interpretation for the given case.

It seems to me ... and it looks so in the hex view, that the embedded png file for itself is entirely ok.
There is a correct PNG header.
But due to the bad APIC frame header, Mp3tag cannot extract or display the image in the correct way.

For example ... in the dialog "Extended tags..." Mp3tag displays some leading bytes from the PNG header as the description for the "cover type" or as a comment or something else.

When Mp3tag exports the image data, it cuts off some leading bytes from the PNG file data.
The amount of lost bytes is determined by the bad APIC frame header structure.
In this case there are 9 bytes cut off from the top of the correct PNG file data.

In other words ... Mp3tag expects a correct data structure, but the media file has a corrupt APIC frame.
The given data structure does not fit to the standard data structure for embedded picture, as defined by id3.org, on which Mp3tag relies on, hopefully.

There might be some more quirks in the media file.
Winamp 5.666 was not able to display the tagged ReplayGain values.

DD.20140429.1509.CEST

I think I understand better now, the image file is ok, its just the formatting of data in the tag,
esp the APIC frame which is problematic.

however, I am confused by what I quoted, b/c I CAN see the RG tags in winamp, and in
mp3tag for that matter.

is it possible you made edits to the file/tag with windows? b/c that's known to corrupt RG tags.

thx for your efforts!

I have just downloaded the example file again and now Winamp does show ReplayGain values!
I cannot remember what happens yesterday with the file on my workbench ;-).
I am sorry for the confusion.

Hm, I'm waiting for a statement from the Mp3tag developer himself.
There is also a small probability, that Mp3tag struggles with a 'special feature' in the APIC frame.
Maybe there is necessary just a small adjustment in the Mp3tag code.

DD.20140429.1625.CEST

did he respond?

can u explain what the special feature of the APIC frame is you're talking about?

Using the term "special feature" I simply used an euphemism for "bug".
Florian has not said anything about the APIC problem yet.

I am convinced that the APIC frame has a bad structure and therefore the byte size of the frame is too short ...
(missing 9 byte for example, i. e. the MIME descriptor "image/" and a few bytes more), ...
with the effect, that Mp3tag uses the correct pointer, but accidentally shifted into the data area of the embedded image file, which in turn causes the extraction of the damaged image file.

Mp3tag needs some coding to work around such bad APIC frame.

It would be good to know which application has written the faulty APIC frame.
Then we could tackle the problem at its root.

Regards.

DD.20140502.2050.CEST

unfortunately I have no idea, although in the hex code u posted it mentions quicktime.

the file came from the internet, and even if we knew what created it, who is to say
some other app writing to it didn't somehow damage it the way windows does RG tags?

I'd love to figure out why windows explorer shows the art in the file icon view for some,
and not others, or why it did for me and then stopped doing so for me? but that's outside
of mp3tags scope I guess.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.