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).
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.
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.
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.
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.