Bug #16803 for MP3-Tag: MP3::Tag can not create valid APIC frames.

Thu Dec 29 23:22:34 2005 Guest - Ticket created

Subject:

MP3::Tag can not create valid APIC frames.

I was not able to make MP3::Tag create a tag with an APIC frame without modifying MP3::Tag sources. It seems that in MP3::Tag::ID3v2, in as_bin(), this line is the culprit: $flags = chr(128) if $tag_data =~ s/\xFF(?=[\x00\xE0-\xFF])/\xFF\x00/g; # sync If I comment that line out, then the problem goes away and I am able to create APIC frames that are valid and can be read by other programs. If I leave that line in, then the tags that MP3::Tag creates are corrupted and not readable by other programs (such as itunes, xmms, amarok etc). I am not sure what that line is supposed to do, but it seems like the sequence of bytes it is looking for in that regex probably are matched in the image data that I am attaching, so its modifying the image data and that results in a corrupted tag. For now I am just leaving that line commented out so that I can create valid APIC tags with MP3::Tag. The way I am creating the tag btw is: $id3v2->add_frame('APIC', chr(0x0), $mime_type, chr(0x0), '', $im_data); It would be nice if this could be fixed so that MP3::Tag could attach cover art. If you need any additional information, please let me know. Regards, Michael Schout

Thu Dec 29 23:26:08 2005 MSCHOUT [...] cpan.org - Correspondence added

Oops. I forgot to log in when I created this ticket. Hopefully you can get in touch with me using this comment...

Fri Dec 30 18:15:11 2005 nospam-abuse [...] ilyaz.org - Correspondence added

Date:	Fri, 30 Dec 2005 15:14:25 -0800
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
To:	via RT <bug-MP3-Tag [...] rt.cpan.org>
CC:	undisclosed-recipients: ;
Subject:	Re: [cpan #16803] MP3::Tag can not create valid APIC frames.
RT-Send-Cc:

On Thu, Dec 29, 2005 at 11:26:08PM -0500, via RT wrote: Show quoted text

> Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=16803 >

Show quoted text

> Oops. I forgot to log in when I created this ticket. Hopefully you can > get in touch with me using this comment...

I need some code sufficient to reproduce your problem. Thanks, Ilya

Fri Dec 30 23:29:51 2005 MSCHOUT [...] cpan.org - Correspondence added

[nospam-abuse@ilyaz.org - Fri Dec 30 18: Show quoted text

> I need some code sufficient to reproduce your problem.

Get a mp3 file called foo.mp3 and a cover image called cover.png (in PNG format. I used a 300x300 image). Run the attached script which will create an ID3v2 tag for the file and create an APIC frame. Once done, try to open the foo.mp3 file in either amarok or itunes. Neither one will be able to read the tag. This is sufficient to reproduce the problem (iTunes and amarok can not read the tag). Now, to "fix" it, do the following: Strip the tag out of foo.mp3 using whatever method you like (I used id3convert --strip foo.mp3). Then comment out the above mentioned line in ID3v2.pm, and re-run bug.pl on the file. When bug.pl is finished, open the file in amarok or itunes again. This time the tag is read without any problems (including the cover art) in both amarok and itunes. I am using: itunes 4.9 on OS X to reproduce this, and amarok 1.3.6 (linked to taglib 1.4 on FreeBSD). Note that the problem only happens if attaching an APIC frame. If you do not attach an APIC frame then the tag is read properly by iTunes and taglib/amarok. In addition, *some* tools *can* read the tags even without the line in question commented out from ID3v2.pm. Specifically, the id3info tool from id3lib seems to have no problems reading the tag. Also the "eyeD3" command line tool from the python eyeD3 package seems to be able to read the tag properly. So I am not sure about that. But iTunes and taglib(amarok) definately CAN NOT read the tags unless the line is commented out of ID3v2.pm. So for some reason that line makes it so that iTunes and taglib can not read the tag.

#!/usr/bin/perl # # test script demonstrating APIC bug in MP3::Tag::ID3v2 # # assumed: foo.mp3 is a new mp3 file with no tag. # assumed: cover.png is a cover image (300x300). use strict; use MP3::Tag; # create a new tag. my $mp3 = MP3::Tag->new('foo.mp3'); $mp3->new_tag('ID3v2'); my $id3 = $mp3->{ID3v2}; # add some basic info. $id3->add_frame('TIT2', 'My Title'); $id3->add_frame('TALB', 'My Album'); # read image data. my $im_data; { open my $fh, '<', 'cover.png'; binmode $fh; local $/ = undef; $im_data = <$fh>; } # add APIC frame. $id3->add_frame('APIC', chr(0x0), 'image/png', chr(0x0), '', $im_data); # write out the tag. $id3->write_tag;

Fri Dec 30 23:31:47 2005 MSCHOUT [...] cpan.org - Correspondence added

In case it helps, I have attached the cover image I used.

Download cover.png
image/png 272.4k

Thu Jan 05 18:43:55 2006 nospam-abuse [...] ilyaz.org - Correspondence added

Date:	Thu, 5 Jan 2006 15:43:04 -0800
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
To:	via RT <bug-MP3-Tag [...] rt.cpan.org>
Subject:	Re: [cpan #16803] MP3::Tag can not create valid APIC frames.
RT-Send-Cc:

On Fri, Dec 30, 2005 at 11:29:51PM -0500, via RT wrote: Show quoted text

> I am using: itunes 4.9 on OS X to reproduce this, and amarok 1.3.6 > (linked to taglib 1.4 on FreeBSD).

I tested with itunes 6.0, and it shows the same bug. mp3info2 -a 'author with y"u' inside' -t "title with y"u' inside" test.mp3 (here y"u' is \xFF\xFB); if you ask itunes to write this data in the tag, it produces a broken (=unsyncronized) tag. If you know any way to force itunes to read unsyncronized tags, please let me know. (Since id3v2.3 is underdefined, I can't be absolutely sure one gets a correct tag from MP3::Tag; again, I would be very interested in how other tools treat the tag with data as above.) Hope this helps, Ilya

Tue Jan 10 21:14:50 2006 nospam-abuse [...] ilyaz.org - Correspondence added

Date:	Tue, 10 Jan 2006 18:06:40 -0800
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
To:	Guest via RT <bug-MP3-Tag [...] rt.cpan.org>
Subject:	Re: [cpan #16803] MP3::Tag can not create valid APIC frames.
RT-Send-Cc:

On Thu, Dec 29, 2005 at 11:22:34PM -0500, Guest via RT wrote: Show quoted text

> > This message about MP3-Tag was sent to you by guest <> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=16803 > > > I was not able to make MP3::Tag create a tag with an APIC frame without modifying MP3::Tag sources. It seems that in MP3::Tag::ID3v2, in as_bin(), this line is the culprit:

Could you please check whether any one of ilyaz.org/software/tmp/empty1.mp3 ilyaz.org/software/tmp/empty2.mp3 shows author/title tags in ITunes? It should be "a with (..)" "t with (..)" correspondingly, here .. is y-diaresis eth: .. | \ / |O | | (picture assumes fixed-width fonts). Thanks, Ilya

Sun Mar 05 09:31:33 2006 BORISZ [...] cpan.org - Correspondence added

Hi, I just encount the same problem. It looks that itunes (6.0.4) is unable to unsync the tags. Since sync is only a backward option for very old players, I wish MP3::Tags has a option to disable sync and work with itunes. empty1.mp3 does not show artist or title. empty2.mp3 works fine. On Di. 10. Jan. 2006, 21:14:50, nospam-abuse@ilyaz.org wrote: Show quoted text

> On Thu, Dec 29, 2005 at 11:22:34PM -0500, Guest via RT wrote:

> > > > This message about MP3-Tag was sent to you by guest <> via

> rt.cpan.org

> > > > Full context and any attached attachments can be found at: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=16803 > > > > > I was not able to make MP3::Tag create a tag with an APIC frame

> without modifying MP3::Tag sources. It seems that in MP3::Tag::ID3v2, > in as_bin(), this line is the culprit: > > Could you please check whether any one of > > ilyaz.org/software/tmp/empty1.mp3 > ilyaz.org/software/tmp/empty2.mp3 > > shows author/title tags in ITunes? It should be "a with (..)" "t with > (..)" correspondingly, here .. is y-diaresis eth: > > .. | > \ / |O > | | > > (picture assumes fixed-width fonts). > > Thanks, > Ilya

-- Boris

Sun Mar 05 09:31:34 2006 The RT System itself - Status changed from 'new' to 'open'

Sun Mar 05 12:14:29 2006 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Sun, 5 Mar 2006 09:14:14 -0800
To:	via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Sun, Mar 05, 2006 at 09:31:34AM -0500, via RT wrote: Show quoted text

> > <URL: http://rt.cpan.org/Ticket/Display.html?id=16803 >

Show quoted text

> I just encount the same problem. It looks that itunes (6.0.4) is > unable to unsync the tags. Since sync is only a backward option for > very old players, I wish MP3::Tags has a option to disable sync and > work with itunes.

Unsync is unalienable part of ID3v2 spec. I doubt many players support non-unsynced MP3s. Nevertheless, an option is not a big deal. Show quoted text

> empty1.mp3 does not show artist or title. > empty2.mp3 works fine.

Thanks; finally, somebody reported back! Yours, Ilya

Wed Mar 21 15:23:52 2007 MSCHOUT [...] cpan.org - Correspondence added

From:

MSCHOUT [...] cpan.org

Hi again. It seems that the id3v23_unsync option you added does indeed fix this problem. iTunes can read APIC frames added if they were created with this option set. However, there is another quirky itunes annoyance that you have to work around if you embed album art using MP3::Tag. iTunes apparently will not recognize any tags that appear after the APIC frame. The way MP3::Tag is currently implemented the tags are written in sorted order, so the APIC tag comes first with basic song information filled in. This means iTunes will read the cover art properly, but will not see any of the other tags (title, album, year track etc). I applied the following patch to ID3v2.pm, which pushes the APIC frame to the end of the tag list instead: --- ID3v2.pm.bak 2007-03-21 14:14:27.000000000 -0500 +++ ID3v2.pm 2007-03-21 14:16:19.000000000 -0500 @@ -455,7 +455,9 @@ # in which order should the frames be sorted? # with a simple sort the order of frames of one type is the order of adding them - my @frames=sort keys %{$self->{frames}}; + # grr APIC must be the last tag for iTunes. + my @frames = grep { $_ ne 'APIC' } sort keys %{$self->{frames}}; + push @frames, 'APIC' if exists $self->{frames}{APIC}; for my $frameid (@frames) { my $frame = $self->{frames}->{$frameid}; After applying this patch, itunes reads album art *and* all other tags correctly. Hooray! I found others reporting that the APIC frame must come last here: http://www.hydrogenaudio.org/forums/lofiversion/index.php/t41777.html (look for APIC in the page)

Wed Mar 21 17:48:29 2007 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Wed, 21 Mar 2007 14:48:04 -0700
To:	via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Wed, Mar 21, 2007 at 03:23:57PM -0400, via RT wrote: Show quoted text

> However, there is another quirky itunes annoyance that you have to work > around if you embed album art using MP3::Tag. iTunes apparently will > not recognize any tags that appear after the APIC frame.

Could this be related to the size of the frame being not what iTunes expects? What is the size written by MP3::Tag, and with iTunes themselves? Thanks, Ilya

Thu Jun 07 13:39:23 2007 MSCHOUT [...] cpan.org - Correspondence added

On Wed Mar 21 17:48:29 2007, nospam-abuse@ilyaz.org wrote: Show quoted text

> On Wed, Mar 21, 2007 at 03:23:57PM -0400, via RT wrote:

> > However, there is another quirky itunes annoyance that you have to work > > around if you embed album art using MP3::Tag. iTunes apparently will > > not recognize any tags that appear after the APIC frame.

> > Could this be related to the size of the frame being not what iTunes > expects? What is the size written by MP3::Tag, and with iTunes > themselves?

Ilya: I just looked into this again. I think whatever was causing this in iTunes has been fixed in version 7.2. I am unable to reproduce this problem under iTunes 7.2, using an unmodified MP3::Tag distribution. As long as I create the tags without the unsync flag set using MP3::Tag, iTunes seems to be happy with them now, including the APIC frame (regardless of its position in the tag) Hooray! So I guess this bug can be closed now. Sorry it took me so long to get back to you on this. Mike

Mon Jun 11 11:45:07 2007 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Mon, 11 Jun 2007 08:44:36 -0700
To:	via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Thu, Jun 07, 2007 at 01:39:29PM -0400, via RT wrote: Show quoted text

> Ilya: > > I just looked into this again. I think whatever was causing this in > iTunes has been fixed in version 7.2. I am unable to reproduce this > problem under iTunes 7.2, using an unmodified MP3::Tag distribution.

Drat! Do you have a machine with older iTunes, so I can understand what was happening? Waiting for ALL people to upgrade brings a major PITA, so if I could put some workaround on my side it may save somebody a lot of time... Show quoted text

> As long as I create the tags without the unsync flag set using MP3::Tag, > iTunes seems to be happy with them now, including the APIC frame > (regardless of its position in the tag) Hooray! > > So I guess this bug can be closed now. > > Sorry it took me so long to get back to you on this.

A lot of thanks anyway, Ilya

Fri Jun 15 10:22:19 2007 mschout [...] gkg.net - Correspondence added

Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Fri, 15 Jun 2007 09:18:56 -0500
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Michael Schout <mschout [...] gkg.net>

Ilya Zakharevich via RT wrote: Show quoted text

> Drat! Do you have a machine with older iTunes, so I can understand > what was happening? Waiting for ALL people to upgrade brings a major > PITA, so if I could put some workaround on my side it may save > somebody a lot of time...

Well I downgraded to iTunes 6.0.2 and I can't seem to reproduce the problem there at this time either. So I guess it really does not matter where in the tag the APIC frame appears. My guess is that when I was having that problem before, I failed to create the tags without the unsync flag set. As long as I use MP3::Tag with: MP3::Tag->config(id3v23_unsync => 0); Then iTunes seems to be happy about everything. I can't seem to reproduce the problem at all as long as the tags do not have the unsync flag set :). Mike

Sat Jun 16 16:27:21 2007 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Sat, 16 Jun 2007 13:26:26 -0700
To:	"mschout [...] gkg.net via RT" <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Fri, Jun 15, 2007 at 10:22:25AM -0400, mschout@gkg.net via RT wrote: Show quoted text

> Well I downgraded to iTunes 6.0.2 and I can't seem to reproduce the > problem there at this time either. So I guess it really does not matter > where in the tag the APIC frame appears. My guess is that when I was > having that problem before, I failed to create the tags without the > unsync flag set. As long as I use MP3::Tag with: > > MP3::Tag->config(id3v23_unsync => 0); > > Then iTunes seems to be happy about everything. I can't seem to > reproduce the problem at all as long as the tags do not have the unsync > flag set :).

A lot of helps with your investigations. Currrently I'm back at my main development machine, and I plan to release a new version (well, when I manage to understand XSLT (yes!) so I can quickly pull new composer-databases from wikipedia... - so maybe not *THAT* quickly). Yours, Ilya

Sat Jun 16 21:01:36 2007 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Sat, 16 Jun 2007 18:01:20 -0700
To:	Ilya Zakharevich via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Sat, Jun 16, 2007 at 04:27:25PM -0400, Ilya Zakharevich via RT wrote: Show quoted text

> A lot of helps with your investigations.

Oups, it should have been "a lot of thanks for ..."; Ilya

Thu Jul 24 21:30:18 2008 rob [...] laddish.net - Correspondence added

From:

rob [...] laddish.net

Show quoted text

> MP3::Tag->config(id3v23_unsync => 0);

I also ran into a similar problem. I'm transcoding mp3's to fit onto a memory stick for my PSP. [play station portable] Since AFAIK lame.exe will not preserve mp3 headers, I'm using perl and the excellent mp3::tag libraries to search through and copy the id3v1 and id3v2 tags. The problem I see is that while the new mp3 files look ok to windows vista (and show the proper album art), it appears corrupted on the PSP. If I take one of these new files, use explorer properties to change something simple like artist and save, the update file views correctly on the PSP. Once I found this thread and added the above config line, everything works and the psp album art appears correctly and is no longer corrupted. Please let me know if there is anything you'd like me to test to help solve the problem [or if I've done something wrong - it wouldn't be the first time :) ] Thanks again for an awesome perl library! I've found it immensely useful in writing scripts to manage my media libraries .... Rob

Wed Jul 30 18:05:33 2008 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Wed, 30 Jul 2008 15:05:09 -0700
To:	Rob Laddish via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Thu, Jul 24, 2008 at 09:30:21PM -0400, Rob Laddish via RT wrote: Show quoted text

> Queue: MP3-Tag > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=16803 > >

> > MP3::Tag->config(id3v23_unsync => 0);

> > I also ran into a similar problem. I'm transcoding mp3's to fit onto a > memory stick for my PSP. [play station portable] Since AFAIK lame.exe > will not preserve mp3 headers, I'm using perl and the excellent mp3::tag > libraries to search through and copy the id3v1 and id3v2 tags. > > The problem I see is that while the new mp3 files look ok to windows > vista (and show the proper album art), it appears corrupted on the PSP. > If I take one of these new files, use explorer properties to change > something simple like artist and save, the update file views correctly > on the PSP. > > Once I found this thread and added the above config line, everything > works and the psp album art appears correctly and is no longer corrupted. > > Please let me know if there is anything you'd like me to test to help > solve the problem [or if I've done something wrong - it wouldn't be the > first time :) ]

Please report this bug to Sony (or whoever does PSP). Thanks, Ilya

Fri Aug 08 02:38:18 2008 rob [...] laddish.net - Correspondence added

From:

rob [...] laddish.net

Hello Ilya, FYI, I had this crop up again with album art, and noticed the artwork sometimes shows up as corrupted under windows Vista too. If I use the unsyc=>0 workaround below, Vista displays the graphic ok again. I've attached a copy of the album art. It isn't always a problem under Vista ... since it occurs in both Vista and the PSP, it implies to me that it is more likely to be a problem with MP3::Tag. I'll look into reporting it to Sony, but don't they will be as helpful as you. Cheers, Rob On Wed Jul 30 18:05:33 2008, nospam-abuse@ilyaz.org wrote: Show quoted text

> On Thu, Jul 24, 2008 at 09:30:21PM -0400, Rob Laddish via RT wrote:

> > Queue: MP3-Tag > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=16803 > > >

> > > MP3::Tag->config(id3v23_unsync => 0);

> > > > I also ran into a similar problem. I'm transcoding mp3's to fit onto a > > memory stick for my PSP. [play station portable] Since AFAIK lame.exe > > will not preserve mp3 headers, I'm using perl and the excellent mp3::tag > > libraries to search through and copy the id3v1 and id3v2 tags. > > > > The problem I see is that while the new mp3 files look ok to windows > > vista (and show the proper album art), it appears corrupted on the PSP. > > If I take one of these new files, use explorer properties to change > > something simple like artist and save, the update file views correctly > > on the PSP. > > > > Once I found this thread and added the above config line, everything > > works and the psp album art appears correctly and is no longer

corrupted. Show quoted text

> > > > Please let me know if there is anything you'd like me to test to help > > solve the problem [or if I've done something wrong - it wouldn't be the > > first time :) ]

> > Please report this bug to Sony (or whoever does PSP). > > Thanks, > Ilya

Download album_art.jpg
image/jpeg 50.3k

Fri Aug 08 15:02:13 2008 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #16803] MP3::Tag can not create valid APIC frames.
Date:	Fri, 8 Aug 2008 12:01:59 -0700
To:	Rob Laddish via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Fri, Aug 08, 2008 at 02:38:21AM -0400, Rob Laddish via RT wrote: Show quoted text

> It isn't always a problem under Vista ... since it occurs in both Vista > and the PSP, it implies to me that it is more likely to be a problem > with MP3::Tag.

I envy your logical skills. ;-) Show quoted text

> I'll look into reporting it to Sony, but don't they will be as helpful > as you.

On the other hand, if NOBODY reports this, they will DEFINITELY not fix PSP... Yours, Ilya