GNOME Bugzilla – Bug 362876
Problem editing APE tags in mp3s
Last modified: 2011-07-18 12:34:02 UTC
I have a few songs that seems to be tagged both with ID3 and APE. Rhythmbox import and play these songs fine, but defaults to displaying the APE tags. If I try to edit the tags of one such song, I'm only able to edit the ID3 tags. This is confusing as the tags seem to be uneditable or return to their old settings. I guess Rhythmbox should ignore the APE tags, or be able to edit them. Gstreamer output of one such song: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: AC-DC / Highway To Hell artist: Ac Dc album: Highway To Hell date: 1979-01-01 genre: Hard Rock ID3v2 frame: buffer of 33 bytes, type: application/x-gst-id3v2-ufid-frame, version=(int)4 comment: Description: c0 Comment: www.heavytorrents.org track number: 1 FOUND TAG : found by element "apedemux0". artist: Ac dc title: AC-DC / Highway To Hell album: Highway To Hell comment: www.heavytorrents.org genre: Hard Rock date: 1979-01-01 track number: 1 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 320000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 4540770000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... The file itself: http://www.whiz.se/temp/song.tar
I have noticed this before, for example in bug #362176 comment #7. I'm not sure if this is a rhythmbox or gstreamer issue. gstreamer sees both, but rhythmbox chooses one or the other, but it that could be the way the gstreamer tag interface works. I suspect that rhythmbox takes the last group of tags.
When Rhythmbox is importing tracks, it receives the tags from GStreamer, and doesn't look where they come from. In this case the ID3 tags will be emitted first, and then the APE ones which override them. Perhaps we should add some extra tag-editing code that checks if there are APE tags inside the ID3 ones, and if so removes them.
This also seems somewhat related to bug #348761, because fixing that bug would enable both tags to be kept in the file, and then you could add code which decides which set of tags would be updated in the file (the ID3 tags presumably). Or alternatively you could always wipe any APEv2 tags if they were present and replace them with ID3 tags. Perhaps that would need to be done in any case, because I'm not sure if there is an APEv2 tag-writing element?
Created attachment 75118 [details] [review] potential patch The only relation to that bug is that it's tagging-related. That is about having multiple-valued tags within a tag-type, this is about having two different tag type in one file. I haven't really done any testing, but something like this should work for stripping APE tags that are inside the ID3 ones.
(In reply to comment #4) > The only relation to that bug is that it's tagging-related. That is about > having multiple-valued tags within a tag-type, this is about having two > different tag type in one file. I understand, but it's related because you could use the multiple-valued tags to convert APE tags into ID3 tags, while keeping the original ID3 tags as well (whether or not that is desirable is a different question).
I'd assumed that the ID3 and APE tags were the same and that they weren't meant to both be there.
*** Bug 382395 has been marked as a duplicate of this bug. ***
Created attachment 77987 [details] debug output with patch Doesn't seem to work for my case. Here is the debug output (using patch from bug #383845) when I try to edit Album. Also with or without the patch editing leaves an empty file like: 187 - Ac Dc - Back In Black.mp39E32AD
Here's a test file: http://acs.pha.jhu.edu/~mccannwj/rhythmbox/id3-ape-test.mp3
I can report that this problem still occurs. See also http://ubuntuforums.org/showthread.php?t=292111 "I'm really surprised this hasn't been fixed yet in Rythmbox considering you posted this in 2006, and there are a number of bug reports relating to this issue" How about taking another look at this?
I realized that in my case the problem is caused by having both v2.3 and v2.4 ID3 tags in an mp3 file. It doesn't have anything to do with APE tags. But the effect is the same. The root cause of this problem is that you can have multiple ID3 or APE tags in an mp3, and when this is the case rhythmbox will read from the last such tag and write to the first one.
Comment on attachment 75118 [details] [review] potential patch my almost-finished decodebin2 rewrite of the metadata writing code fixes this properly
Still reproducible on latest git snapshot (origin/master, b5c505ed5): updating tags of an mp3 with an APE tag doesn't seem to work.
fixed in 90b7496 at long last