Bug #44666 for MP3-Tag: Rhythmbox does not recognise tags modified by MP3::Tag

Mon Mar 30 05:50:42 2009 ricky [...] ricky-chan.co.uk - Ticket created

Subject:	Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Mon, 30 Mar 2009 10:51:09 +0100
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Ricky Chan <ricky [...] ricky-chan.co.uk>

Version affected: 0.9714-1 If you have an existing mp3 with id3v2 tags (no id3v1 tags eixsts) when *any* MP3::Tag program modifies the tag, the subsequent mp3 tag's are not recognise by rhythmbox. The same mp3 when modified with python-eyed3 library in Python or id3lib in C++ will continue to be seen. (I was evaluated different mp3 libraries in different programing languages when I stumbled across this). When I issued Update in my script I only write on ID3v2 tags, of course if version 1 tags were also written rythmnbox will *appear* to work, that is because it is reading the version 1 tags, the version 2. Strip away version 1 tags and it stops working. The created tags seems to be valid, as the python code and the c++ code can read and modify the tag fine BUT even after manipulation but other libraries rhythmbox does like it. The only was to make it work is re-create the id3v2 tags NOT using MP3::Tag (I used taglib in c++ to convert tags to 2.4 then id3lib to 2.3 and this worked fine). You can argue that this bug is probably a rhythmbox bug. I have tried to see if setting any config options (like padding, unsync) etc may be the what some mp3 players prefer but I have not been able to find a compatible How to recreate: 1. Get a mp3 with ONLY id3v2 tags (make sure no APE or ID3v1 tags in it), start up rhythmbox,. 2. Use MP3::Tag to change the TYER to something else. 3. Rhythmbox (if configured to monitor the music collection, it probably uses inotify), will not automatically change and list the file as if it has no tags. (remember if you write out with ID3v1 tags it would read these). 4. The mp3 if modified with other libraries will appear to be valid but still won't show in rhythmbox. This can only be rectified by rebuilding the mp3 tag not using MP3::Tag. 5. Get another mp3 with ONLY ID3v2 tags, place it where rhythmbox can see it. 6. Use id3lib related program or eyed3 (python) to modify TYER specifiy that only ID3v2 tags are written. (I use a script to verify only ID3v2 tags exist). Rythmnbox happily sees the changes. I haven't worked out what the issue is, as tagging tools don't mind MP3::Tag modified mp3. It may be a precise padding issue or something like that. I don't have much time to look at this (my evaluation needs to move on) but when I have a chance I will try to work out how rhytmnbox parses tags. Ricky

Mon Mar 30 17:40:22 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Mon, 30 Mar 2009 14:39:59 -0700
To:	Ricky Chan via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Mon, Mar 30, 2009 at 05:50:44AM -0400, Ricky Chan via RT wrote: Show quoted text

> You can argue that this bug is probably a rhythmbox bug.

;-) Show quoted text

> 1. Get a mp3 with ONLY id3v2 tags (make sure no APE or ID3v1 tags in > it), start up rhythmbox,.

Show quoted text

> 2. Use MP3::Tag to change the TYER to something else.

Show quoted text

> I haven't worked out what the issue is, as tagging tools don't mind > MP3::Tag modified mp3. It may be a precise padding issue or something > like that.

a) Take examples/empty_10sec.mp3 (sp?); b) Add *minimal* ID3v2 tag using other tools, so that rhythmbox is happy; c) Change TYER by MP3::Tag so that rhythmbox is not happy any more. (Find a tag in "b" such that removing any frame would break the scenario). d) Email me the resulting file. Show quoted text

> I don't have much time to look at this (my evaluation needs to move on) > but when I have a chance I will try to work out how rhytmnbox parses tags.

Would you have time to do several iteration of checking files if I got some clue? Thanks, Ilya

Mon Mar 30 17:40:24 2009 The RT System itself - Status changed from 'new' to 'open'

Mon Mar 30 18:16:24 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Mon, 30 Mar 2009 15:16:11 -0700
To:	Ricky Chan via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Mon, Mar 30, 2009 at 02:39:59PM -0700, Ilya Zakharevich wrote: Show quoted text

> a) Take examples/empty_10sec.mp3 (sp?); > b) Add *minimal* ID3v2 tag using other tools, so that rhythmbox is happy; > c) Change TYER by MP3::Tag so that rhythmbox is not happy any more. > > (Find a tag in "b" such that removing any frame would break the scenario). > > d) Email me the resulting file.

Oups, of course I would need BOTH files... Sorry, Ilya

Tue Mar 31 04:44:19 2009 ricky [...] ricky-chan.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Tue, 31 Mar 2009 09:44:55 +0100
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Ricky Chan <ricky [...] ricky-chan.co.uk>

I'll have to get back to you as using empty_10sec.mp3. MP3::Tag is working fine with rhythmbox. I create fresh ID3v2 header using another tool, then added/changed tags with MP3::Tag. It's not causing a problem. I've also tested using MP3::Tag to create new ID3v2 from a empty_10sec.mp3. No problems either. Seems to be only from mp3's I have with existing tags. I'll work on trying to replicate it on to a fresh copy of empty_10sec.mp3. When I do I'll get back to you.. (although I may be able to work out the reason by then!). Ricky Ilya Zakharevich via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=44666 > > > On Mon, Mar 30, 2009 at 02:39:59PM -0700, Ilya Zakharevich wrote: >

>> a) Take examples/empty_10sec.mp3 (sp?); >> b) Add *minimal* ID3v2 tag using other tools, so that rhythmbox is happy; >> c) Change TYER by MP3::Tag so that rhythmbox is not happy any more. >> >> (Find a tag in "b" such that removing any frame would break the scenario). >> >> d) Email me the resulting file. >>

> > Oups, of course I would need BOTH files... > > Sorry, > Ilya > >

Tue Mar 31 05:01:48 2009 ricky [...] ricky-chan.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Tue, 31 Mar 2009 10:02:19 +0100
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Ricky Chan <ricky [...] ricky-chan.co.uk>

Found it, MP3::Tag makes tags which have Album Art (APIC) not show up correctly in rhythmbox if MP3::Tag is used to modify it. using other tools don't have this issue. Attached is two mp3s. 1. rhythmbox_happy.mp3 created using * a fresh copy of empty_10sec.mp3 * Using eyeD3 to add APIC and Artist (ID3v2 - 2.3 ONLY written). Rhythmbox was happy with this file. 2. rhythmbox_not_happy.mp3 created using * A copy of rhythmbox_happy.mp3 (so was working) * added TYER (tried to set to 2009). Rhythmbox can no longer read the ID3v2 tag. However MP3::Tag, eyeD3, id3lib, taglib, etc.. can read this file fine.... Ricky Ilya Zakharevich via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=44666 > > > On Mon, Mar 30, 2009 at 02:39:59PM -0700, Ilya Zakharevich wrote: >

>> a) Take examples/empty_10sec.mp3 (sp?); >> b) Add *minimal* ID3v2 tag using other tools, so that rhythmbox is happy; >> c) Change TYER by MP3::Tag so that rhythmbox is not happy any more. >> >> (Find a tag in "b" such that removing any frame would break the scenario). >> >> d) Email me the resulting file. >>

> > Oups, of course I would need BOTH files... > > Sorry, > Ilya > >

Download example.zip
application/zip 19.9k

Message body not shown because it is not plain text.

Tue Mar 31 05:34:23 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Tue, 31 Mar 2009 02:34:07 -0700
To:	Ricky Chan via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Tue, Mar 31, 2009 at 05:01:50AM -0400, Ricky Chan via RT wrote: Show quoted text

> 1. rhythmbox_happy.mp3 created using > * a fresh copy of empty_10sec.mp3 > * Using eyeD3 to add APIC and Artist (ID3v2 - 2.3 ONLY written). > > Rhythmbox was happy with this file. > > 2. rhythmbox_not_happy.mp3 created using > * A copy of rhythmbox_happy.mp3 (so was working) > * added TYER (tried to set to 2009). > > Rhythmbox can no longer read the ID3v2 tag. However MP3::Tag, eyeD3, > id3lib, taglib, etc.. can read this file fine....

They differ too much... Could you start with a file which already has TYER, and change the year it using MP3::Tag... And, for extra robustness, do it with unsync disabled... [My guess is that rhythmbox's bug is that it cannot read anything after APIC. And since MP3::Tag sorts frames alphabetically, APIC is at front... You can try to test with changing `sort' to `reverse sort' in build_tag()...] Yours, Ilya

Tue Mar 31 05:56:06 2009 ricky [...] ricky-chan.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Tue, 31 Mar 2009 10:56:38 +0100
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Ricky Chan <ricky [...] ricky-chan.co.uk>

Using unsync, seemed to do the trick. I had ruled out this as a possible cause originally, as I tried each configurable option and applied to a test collection of mp3's. a couple had failed. To my fault I didn't log down what files I used as tests, and which options where variants from default settings. I will re-apply modifications to couple of hundred existing mp3 files which are rhythmnbox happy using unsync. If I don't see any problems, then I must have messed up my original test. If there is any with issues, I will try the reverse sort modification in ID3v2.pm as suggested. If any issues persist, I will work out how to replicate with empty_10sec.mp3. Many thanks for helping. Ricky Ilya Zakharevich via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=44666 > > > On Tue, Mar 31, 2009 at 05:01:50AM -0400, Ricky Chan via RT wrote: >

>> 1. rhythmbox_happy.mp3 created using >> * a fresh copy of empty_10sec.mp3 >> * Using eyeD3 to add APIC and Artist (ID3v2 - 2.3 ONLY written). >> >> Rhythmbox was happy with this file. >> >> 2. rhythmbox_not_happy.mp3 created using >> * A copy of rhythmbox_happy.mp3 (so was working) >> * added TYER (tried to set to 2009). >> >> Rhythmbox can no longer read the ID3v2 tag. However MP3::Tag, eyeD3, >> id3lib, taglib, etc.. can read this file fine.... >>

> > They differ too much... Could you start with a file which already has > TYER, and change the year it using MP3::Tag... And, for extra > robustness, do it with unsync disabled... > > [My guess is that rhythmbox's bug is that it cannot read anything > after APIC. And since MP3::Tag sorts frames alphabetically, APIC > is at front... > > You can try to test with changing `sort' to `reverse sort' in > build_tag()...] > > Yours, > Ilya > >

Tue Mar 31 09:29:27 2009 nospam-abuse [...] ilyaz.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Tue, 31 Mar 2009 06:29:10 -0700
To:	Ricky Chan via RT <bug-MP3-Tag [...] rt.cpan.org>
From:	Ilya Zakharevich <nospam-abuse [...] ilyaz.org>

On Tue, Mar 31, 2009 at 05:56:07AM -0400, Ricky Chan via RT wrote: Show quoted text

> I will re-apply modifications to couple of hundred existing mp3 files > which are rhythmnbox happy using unsync. If I don't see any problems, > then I must have messed up my original test. > > If there is any with issues, I will try the reverse sort modification in > ID3v2.pm as suggested. > > If any issues persist, I will work out how to replicate with > empty_10sec.mp3.

Just keep in mind that unsync is important ONLY if some frame contains 0xFF 0xF* or 0xFF 0xE*. Unless you use non-Latin language, such pairs would appear only in "large exotic" frames, such as binary contents of APIC. When a program parses unsync data wrong (as most do :-[), it messes the length of frame, so it can't find starts of the following frames. Essentially, if it "just ignores errors", the frames following unsync'ed frame essentially disappear. I hope that now you know what to look for, Ilya

Tue Mar 31 10:14:49 2009 ricky [...] ricky-chan.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Tue, 31 Mar 2009 15:15:25 +0100
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Ricky Chan <ricky [...] ricky-chan.co.uk>

Ilya, Thanks for you patience. I think the issue is resolved (and it is mine and rhythmbox's error). I tested against 2000 mp3 and no problems occured (with unsync disabled). A lot of them either are utf8 encoded or UTF16 (LE) encoded so the unsync disclaimer applies. I think my original tests was done on mp3's that were already in a state that rhythmnbox couldn't handle and using MP3::Tag afterwards wasn't a proper test. I seem to recall I used SetUnsync disabled with id3lib on the same files, and all tags where wiped afterwards. I will test again with other MP3 tag tools with unsync enabled. If I get the same issues I can raise this with rhythmbox as a bug. Many thanks. Ricky Ilya Zakharevich via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=44666 > > > On Tue, Mar 31, 2009 at 05:56:07AM -0400, Ricky Chan via RT wrote: >

>> I will re-apply modifications to couple of hundred existing mp3 files >> which are rhythmnbox happy using unsync. If I don't see any problems, >> then I must have messed up my original test. >> >> If there is any with issues, I will try the reverse sort modification in >> ID3v2.pm as suggested. >> >> If any issues persist, I will work out how to replicate with >> empty_10sec.mp3. >>

> > Just keep in mind that unsync is important ONLY if some frame contains > 0xFF 0xF* or 0xFF 0xE*. Unless you use non-Latin language, such pairs > would appear only in "large exotic" frames, such as binary contents of > APIC. > > When a program parses unsync data wrong (as most do :-[), it messes > the length of frame, so it can't find starts of the following frames. > Essentially, if it "just ignores errors", the frames following > unsync'ed frame essentially disappear. > > I hope that now you know what to look for, > Ilya > > >

Tue Mar 31 10:47:44 2009 ricky [...] ricky-chan.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Tue, 31 Mar 2009 15:48:19 +0100
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Ricky Chan <ricky [...] ricky-chan.co.uk>

I've confirmed having unsync enabled with other tagger's also cause problem. So I can raise this with rhythmbox now. Both id3lib and eyeD3 by default disables unsync and only is using it if it is already set (hence issues when I used MP3::Tag first). RB shows may 1 or 2 tags, but the first non latin1 encoding it see's it shows it incorrectly and ignores all subsequent tags. unsync only works with rythmnbox with simple frames and latin1 it seems. I'm off to raise the bug with them, many thanks. Many thanks. Ricky

Fri Apr 24 16:26:59 2009 ricky [...] ricky-chan.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #44666] Rhythmbox does not recognise tags modified by MP3::Tag
Date:	Fri, 24 Apr 2009 21:26:23 +0100
To:	bug-MP3-Tag [...] rt.cpan.org
From:	Ricky Chan <ricky [...] ricky-chan.co.uk>

FYI, http://bugzilla.gnome.org/show_bug.cgi?id=577468 Should be fixed in gstreamer 0.10.15. Ricky Ilya Zakharevich via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=44666 > > > On Tue, Mar 31, 2009 at 05:56:07AM -0400, Ricky Chan via RT wrote:

>> I will re-apply modifications to couple of hundred existing mp3 files >> which are rhythmnbox happy using unsync. If I don't see any problems, >> then I must have messed up my original test. >> >> If there is any with issues, I will try the reverse sort modification in >> ID3v2.pm as suggested. >> >> If any issues persist, I will work out how to replicate with >> empty_10sec.mp3.

> > Just keep in mind that unsync is important ONLY if some frame contains > 0xFF 0xF* or 0xFF 0xE*. Unless you use non-Latin language, such pairs > would appear only in "large exotic" frames, such as binary contents of > APIC. > > When a program parses unsync data wrong (as most do :-[), it messes > the length of frame, so it can't find starts of the following frames. > Essentially, if it "just ignores errors", the frames following > unsync'ed frame essentially disappear. > > I hope that now you know what to look for, > Ilya > >