GNOME Bugzilla – Bug 424629
handle multiple id3 tag sets better
Last modified: 2011-07-18 12:09:59 UTC
I'm having trouble editing the tags of the attached mp3 file in Rhythmbox. When I change the artist field from "At The Gates" to "At the Gates", it seems to work ok, but reverts back to the old spelling after a while, similar to the behaviour in bug 362876. I guess this is a GStreamer problem, or a badly mangled file, as other tools such as tagtool does not detect any tags at all. GStreamer versions, gstreamer0.10-alsa 0.10.12-1 gstreamer0.10-ffmpeg 0.10.2-1 gstreamer0.10-gnomevfs 0.10.12-1 gstreamer0.10-lame 0.10.5-0.0 gstreamer0.10-plugins-base 0.10.12-1 gstreamer0.10-plugins-good 0.10.5-4 gstreamer0.10-plugins-really-bad 0.10.3-0.5 gstreamer0.10-plugins-ugly 0.10.5-1 gstreamer0.10-x 0.10.12-1 libgstreamer0.10-0 0.10.12-2 libgstreamer0.10-dev 0.10.12-2 gst-launch-0.10 -t filesrc location=file.mp3 ! decodebin ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: The Fevered Circle artist: At the Gates album: Terminal Spirit Disease date: 1994-01-01 track ID: 96b352f0-7b3f-4e69-af5f-da0d02132d2b genre: Death Metal comment: Exact Audio Copy Secure Mode ID3v2 frame: buffer of 33 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 32 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 32 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 31 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 18 bytes, type: application/x-gst-id3v2-tdrl-frame, version=(int)4 : buffer of 48 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 30 bytes, type: application/x-gst-id3v2-tdtg-frame, version=(int)4 : buffer of 57 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 23 bytes, type: application/x-gst-id3v2-tsop-frame, version=(int)4 : buffer of 34 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 12 bytes, type: application/x-gst-id3v2-tcmp-frame, version=(int)4 track count: 9 track number: 5 album ID: 9f94cc0e-c50c-4fab-8702-0fc57f4cafe9 album artist ID: 35f92c4a-69d0-4ed1-ab9e-05259db89d14 FOUND TAG : found by element "id3demux1". title: The Fevered Circle artist: At The Gates album: Terminal Spirit Disease date: 1994-01-01 track number: 5 ID3v2 frame: buffer of 28 bytes, type: application/x-gst-id3v2-tden-frame, version=(int)4 : buffer of 44 bytes, type: application/x-gst-id3v2-tenc-frame, version=(int)4 comment: Exact Audio Copy Secure Mode genre: Death Metal FOUND TAG : found by element "mad0". duration: 251000000000 bitrate: 200428 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 347493000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
Created attachment 85593 [details] mp3 file
The file has somehow acquired two sets of id3v2 tags. Rhythmbox edits the first tag set, then when it rereads the file, it uses the values from the second set. There are two bugs here: we probably should ignore the second tag set in this instance; and we should only write one set of tags when rewriting tags in a file.
The original idea I had for handling this case is to use gst_tag_list_insert(first_tag, next_tag, GST_TAG_MERGE_KEEP) - that way all existing tags are kept and new ones are added. This seems to be the case that covers most things, like: - multiple ID3 tags (or ID3 and ape tags or whatever). In this case the outermost tag seems to be the most recently added tag most of the time. Since the outermost tag arrives first at the sink, you keep its values with the given merge mode. - multiple different tags from different gstreamer elements (think ID3 tag and mad element) Since those tags are different, the merge mode unions them into one tag.
This problem of not preserving existing tags (if there were additional tags) is basically the same as a bug I filed a while back: bug #348761.
*** Bug 508655 has been marked as a duplicate of this bug. ***
Perhaps in properties the user could be made aware of the multiple tag sets, and asked to choose which they prefer/ or if they want to delete other tag sets.
As a stop gap measure. Does anyone know what the best way is to scrub duplicate id3 tags?
*** Bug 391544 has been marked as a duplicate of this bug. ***
*** Bug 554331 has been marked as a duplicate of this bug. ***
It was suggested to me to try this: gst-launch-0.10 filesrc location=file-to-fix.mp3 ! id3demux ! filesink location=fixed-version.mp3 This cleans the file and keeps only one set of tags, it seems (but you have no control over which set of tags is kept). Can be used to ease the suffering in the meantime. However, ideally I'd like this to run over all the files of a folder, and run in place so that no new files are created (just in case some of you have scripting skills?).
*** Bug 601077 has been marked as a duplicate of this bug. ***
*** Bug 613433 has been marked as a duplicate of this bug. ***
*** Bug 641356 has been marked as a duplicate of this bug. ***
fixed as part of commit 90b7496.