APIC Frame corrupts tags in ID3v2.3

[GoogleCodeExporter]

I need some help adding a picture to a MP3 file.
I'm using PHP-Reader (v1.8) component to read/write a MP3 file and add an 
APIC frame to it.
The problem is that in ID3v2.4 it's fine, but if I choose to save in ID3v2.3, 
the tags get corrupted.
Attached is the code I'm using.

Thank you for your help.

Original issue reported on code.google.com by eresend...@gmail.com on 6 Jun 2010 at 1:29

Attachments:

• apic.php

[GoogleCodeExporter]

By the way, could this be related to issue 12? If so, is there any progress?
Thanks.

Original comment by eresend...@gmail.com on 6 Jun 2010 at 1:34

[GoogleCodeExporter]

Code works for me for my MP3 and JPEG file. However, I did change the mime type 
to
image/jpg to correspond the image type I was inserting. Could you also include a
sample file and an image that I could use to recreate the error.

Original comment by svollbehr on 7 Jun 2010 at 5:18

• Added labels: ID3v2

[GoogleCodeExporter]

Hello svollbehr

Thanks for helping me out.
Attached is a tar file width audio and jpeg image.

Thanks in advance.

Original comment by eresend...@gmail.com on 7 Jun 2010 at 11:25

Attachments:

• apic.tar

[GoogleCodeExporter]

I've notice that I add a mime type of png instead of jpeg, but this is a typo. 
Anyway
I've tested with both and got the same results: bad id3v2 tags acording to 
mp3tag
software.

Thanks!

Original comment by eresend...@gmail.com on 7 Jun 2010 at 11:43

[GoogleCodeExporter]

OK, thanks. I will look into this.

Original comment by svollbehr on 7 Jun 2010 at 2:17

• Changed state: Accepted

[GoogleCodeExporter]

Thanks a ton :)

Original comment by eresend...@gmail.com on 7 Jun 2010 at 4:36

[GoogleCodeExporter]

Took me a while to get this started. I tried several tests where I created a 
tag and then saved it to a file. Tests included were:
 - new tag to an MP3 file with no tags
 - new tag to an MP3 file with tags
 - old tag edit to a new file
 - old tag edit to the same file.

I was able to parse the files after write, I was able to hear the music with 
Windows Media Player and I saw Windows recognizing the title property from the 
ID3v2.3 tags. I did use my own test file though as I couldn't play the file you 
included in Media Player.

However, I do get the same !BAD error for ID3v2.3 tags with Mp3tag and I don't 
really have a clue what is causing that as the files seem to be working as 
expected. It might be that the software doesn't support unsynchronization for 
v2.3. I even used Mp3val to validate the files and they were mostly OK.

While validating the files I did came across another bug in the MP3 content 
copy. It seems that the file copy upon extending the file does not work for the 
first <1024 bytes. This is now fixed and committed to subversion. Luckily, MP3 
players do know how to get pass garbage in the stream.

Original comment by svollbehr on 22 Jun 2010 at 11:00

• Changed state: Started

[GoogleCodeExporter]

Where you able to reproduce this problem with all your MP3 file or was it the 
corrupt MP3 file that was the real problem?

Original comment by svollbehr on 21 Jul 2010 at 7:48

[GoogleCodeExporter]

Florian from Mp3tag noticed that tag size is smaller than the apic frame size 
and hence the !BAD. I will look further into this issue.

Original comment by svollbehr on 21 Jan 2011 at 9:31

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Issue 50 has been merged into this issue.

Original comment by svollbehr on 21 Jan 2011 at 9:32

[GoogleCodeExporter]

I have now fixed the tag size problem and moved it to trunk. I will still carry 
out some additional tests to see whether the images cause additional problems 
for v2.3.

Original comment by svollbehr on 30 Apr 2011 at 10:37

[GoogleCodeExporter]

Hello svollbehr

This is great news.
I will do some testing too and soon I send some feedback.
Thanks

Original comment by eresend...@gmail.com on 30 Apr 2011 at 1:22

[GoogleCodeExporter]

I have made further tests with regard to this problem. I found out that at 
least Windows operating system and Windows Media Player do not quite support or 
read ID3v2.3 tags when they have the unsynchronization scheme applied to them. 
Unsynchronization is mandated by the standard but hardly used anywhere.

Anyways, I want to keep the library close to the standard, so I have added an 
extra option parameter 'compat' that can be set to enable compatibility mode. 
This option basically just disables the automatic unsynchronization on the tag 
so that it is Windows (and possibly others) compatible.

Let me know if you find other issues with regard to the new changes.

Original comment by svollbehr on 2 May 2011 at 7:16

• Changed state: Fixed