APIC Header

#1

I have been exploring some problems I have been having with Images in various programs at the byte level and have come across something with may be a 'very subtle' bug or may just be my lack of understanding of the topic. I hope someone will help clear it up for me.

When adding cover art using MP3Tag (ID3v2.4) it appears that 4 extra bytes are being added to the APIC header which I cannot account for between the Frame ID and the MIME Type. I have attached a screen print of what I am seeing, but this is found in all of the mp3 files I have experimented with.

My understand of the specification is the following: APIC (4 bytes) Size (4) Flags (2) Text Encoding (1) followed by 'image/jpeg' for a total of 11 bytes before 'image/jpeg'

In the attached screen print, I count 15 and I cannot figure out what the other 4 bytes are for. Any explaination (education) greatly appreciated.

Thanks,
David

APIC_Screen_2.jpg840×180 51.1 KB

APIC_Screen_2.jpg840×180 51.1 KB

[X] mp3tag handles a bad embed poorly
#2

id3.org says Data length indicator

#3

Thanks for the reply. I went back to ID3.org and searched on the Data Length Indicator... but all I was able to find was its description of a flag (bit p). To my eyes there are NO flags set. Could that be the problem? In the attached screen shot both flag positions are zeros. I believe they should be Line 1450h chars 10 and 11 both show '00'

Again, I apologize if I'm wasting your time with a lack of understanding but I have been trying diligently to understand this. Please take another look and let me know what you think.

Thanks,
David :huh:

#4

But this tag here was not last modified by Mp3tag or only edited by Mp3tag?

#5

I use MP3Tag almost exclusively for my tag work... but I will do another test case later to make sure it is happening here.

What are you looking at which leads you to believe that it was edited elsewhere? Is it something I can check before providing you examples in the future?

Are you in agreement with what I am seeing in the screenshot? Am I correct in my assumptions so far, regardless of what wrote the tags? :unsure:

Thanks again for your insight.

David

#6

Attached are 3 screenshots. I ripped a new disc using dbPoweramp which pulled the disc info from allmusic.com (including the album coverart). This is the first screenshot. dbPoweramp uses ID3v2.3 exclusively.

The second screenshot is after using MP3Tag to get tags and art from one of the sources. It was set to save tags using ID3v2.3 UTF-16. This screenshot is strange and I had not looked closely at the v2.3 UTF-16 before.

Notice the spacing immediately before APIC (not A P I C). I haven't even begun to think about this or what it could mean, but it dosen't look right and I thought you should see it. It looks as if it changes encoding type in the middle of the file.

APIC_After_ID3v2.3__crop_r_.jpg367×512 96.1 KB

-continued next post

-continued from previous post.

The third screenshot is after using MP3Tag to get tags and art from one of the sources. This time I set it to save as ID3v2.4 UTF-8. Please notice the number of bytes between 'APIC' and 'image/jpeg'.

APIC_After_ID3v2.4__crop_r_.jpg420×510 95 KB

Thanks,
David


APIC_After_ID3v2.3__crop_r_.jpg367×512 96.1 KB

APIC_After_ID3v2.4__crop_r_.jpg420×510 95 KB

#7

These screenshots are small and not comfortable to read!

2nd picture: Do you mean the space between each character? Then you should look up what unicode utf-16 is.

3rd picture: The flags are set $03 (n + p) so you have 4 byte data length indicator.

picture from 1st post: Tag must have been corrupted by some program.

#8

My apologies... I was having problems getting the screens down to a size the forum would let me upload.

I was noticing that the space between each character stops at APIC. Notice that it is not A P I C ...

Is this correct?

My apologies on this one... I didn't notice that this NEW file had those flags set correctly. If you look at the one from my first post, they were not. I am not sure what program caused that problem and will investigate it further. If I find that scenario, I will provide you with additional information.

The first was the before. A freshly ripped song with tags placed by dbPowerAmp. There I see the flags are all zero and there is no additional bytes for length. Is this a problem? Is there something else you are seeing which appears corrupted?

Thanks,
David

#9

Yes. APIC is the Frame ID and is always 4 characters long and it is independent from encoding settings.

I meant the picture from the first post of this thread. The new one from dbPowerAmp is fine.