GNOME Bugzilla – Bug 323658
[id3mux] Changing of ID3 tags is broken in gstreamer
Last modified: 2006-06-25 08:52:03 UTC
Please describe the problem: When writing tags rhythmbox doesn't overwrite old ID3 tags (either v1 or v2) when updating using either the single or multiple entry boxes. It also appears to use the oldest ID3 tags when reading the tags from the file. This has the consequence that when updating a file that already has tags in it, that the tags are written to the file, the interface is updated with the new user-entered values, but then a new sync is performed, which re-reads the tags from the file, and uses the oldest tags it finds (i.e. the tags that were intended for overwriting). When viewing tags from other applications (such as tagtool, easytag etc.), the tags displayed are the newest tags in the file, so rhythmbox should either have the same behaviour, or overwrite the old tags. Steps to reproduce: 1. Create an mp3 file 2. Remove *all* tags (e.g. use tagtool, easytag etc.) 3. Import mp3 into rhythmbox 4. Right-click on song, select Properties 5. Update info (note that info is correctly saved). 6. Right-click again on song, select Properties 7. Change a tag (say "Year") Actual results: After step 7, the display reverts to that seen after step 5. Expected results: Should update to the user supplied tags. Does this happen every time? Yes. Other information: The multiple tagging information can be seen by performing a "strings" on the binary mp3 file: Here is an example after step 5: $ strings sample.mp3 TIT2 The District Sleeps Alone TonightTPE1 Postal ServiceTALB Give UpTDRC 1901TCON RockTRCK 1TPOS LAME3.96.1UUUUUUUUUUUUUUUUUUUUUUULAME3.96.1UUUUUUUUUUUUUUUUUUUUUUUUU [... snip ...] UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUTAGThe District Sleeps Alone ToniPostal Service Give Up 1901 Here is an example after step 7: $ strings sample.mp3 kTIT2 The District Sleeps Alone TonightTPE1 Postal ServiceTALB Give UpTDRC 2003TCON RockTRCK 1TPOS TIT2 The District Sleeps Alone TonightTPE1 Postal ServiceTALB Give UpTDRC 1901TCON RockTRCK 1TPOS LAME3.96.1UUUUUUUUUUUUUUUUUUUUUUULAME3.96.1UUUUUUUUUUUUUUUUUUUUUUUUU [... snip ...] UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUTAGThe District Sleeps Alone ToniPostal Service Give Up 1901 TAGThe District Sleeps Alone ToniPostal Service Give Up 2003 It appears it is always using the tag closest to the actual mp3 music contents, rather than the newer tag, which are inserted at the beginning (id3v1) or end (id3v2) of the file.
This could well be a gstreamer problem, I'm using gstreamer-plugins-0.8.11-0.gst.1.4 and gstreamer-plugins-extra-audio-0.8.11-0.lvn.2.4.
See also some previous discussion on this problem at bug #323425.
Created attachment 55837 [details] [review] patch Can you try it with this patch? It will tell gstreamer to do _REPLACE_ALL instead of _REPLACE.
No effect, in fact, if you look at the gstreamer code, the switch for _REPLACE and _REPLACE_ALL does the identical thing, both for 0.8.11: http://cvs.freedesktop.org/gstreamer/gstreamer/gst/gsttag.c?rev=1.26.4.2&only_with_tag=RELEASE-0_8_11&view=markup and 0.10.0: http://cvs.freedesktop.org/gstreamer/gstreamer/gst/gsttaglist.c?rev=1.39&only_with_tag=RELEASE-0_10_0&view=markup
James, can you duplicate this bug on a freshly encoded mp3 file? It could be a problem specific to a particular gstreamer/plugins/extra-audio version.
If you look down furthur, it doesn't. Say you have a file with an artist and a genre tag, and are writing an artist tag, REPLACE will mean the file will end up with one of each, REPLACE_ALL will make it end up with only an artist tag. We don't want to use REPLACE_ALL because that will delete any tags that wedon't understand (which is bad), but I was wondering if it made any difference.
Hmm... I see, but it doesn't seem to work either way. In both cases you get a whole duplicated set of tags every time you try to write or update a tag. Perhaps the bug is in the interaction between gstreamer and the libid3tag library which (presumably) actually does the write. Perhaps it works with the flac backend (haven't tested because I don't have any flac files to test). Have you managed to duplicate the bug at your end?
I can't get it to occur with gstreamer 0.10.0 or 0.8.11. What version of libid3tag do you have?
$ rpm -q libid3tag libid3tag-0.15.1-3.b I am running gstreamer-0.8.10-1, I'll try gstreamer-0.8.11.
Still getting the same problem with gstreamer 0.8.11. What distribution are you using? This is all on Fedora Core 4. Did you try deleting *all* tags and then editing the mp3 file twice? It's the second time you try to change the tags that the problem occurs.
Using gstreamer 0.8.11 on Ubuntu Breezy and using a gstreamer app (Sound-Juicer-2.12.2, libid3tag-0.15.1b-7) to rip the song from cd and encode the tag I find the following: A field that was filled by sound-juicer is acknowledged by Rhythmbox. Closing RB and using easytag v 1.99.7 (uses libid3-3.8.3c2) to re-write the tag results in other sound apps acknowledging the changed tags. But upon restarting RB the tags are re-written. Afterwards not only does RB show the old tag, but other sound apps see the old tag as well. Any field that was not filled by sound-juicer upon extraction can be succesfully written to mulitiple times by easytag and RB will acknowledge the change. A song ripped and tagged by the Grip (uses libid3-3.8.3c2) shows no unusual behaviour. Changes to tags are acknowledged by RB.
Regarding comment #11, did you try changing the tags *within* rhythmbox itself? You need to compile it with the --enable-tag-writing flag to configure.
Again following up on comment #11, it may well be a problem with the way sound-juicer writes ID3 tags, as all the tracks I have had problems with rewriting tags have been originally written with sound-juicer.
But arguing against that is the fact that the problem still occurs even when deleting all tags. Will investigate further.
For a song ripped and tagged with Grip: When I try to write a tag with Rhythmbox it changes them for that session, but upon quitting RB and restarting the tags are back to their original. For a song ripped with sound-juicer: Same behaviour, RB's changes don't keep. Still there's the common problem with all songs ripped and tagged by sound-juicer: They obtain tags that just can't be gotten rid of that only other gstreamer apps see. Even when stripping all tags with other tag editing tools, RB still sees the original tags, while other sound apps correctly see the blank fields. Is there a gstreamer based stand-alone tag-editor? Testing with one should clear up where the problem is.
I don't know if there is a gstreamer based tag-editor, but it might be possible to construct a command-line pipeline to edit the tags, or to use one of the test C programs that are in the gstreamer source to test tag writing via gstreamer.
kanem, can you try posting the results of running "strings" on an mp3 file before and after tagging in RB as I did in the original report?
dashed lines --------------- mean skipping alot of output This is with Rhythmbox cvs of 20 Dec. after ripping with grip: TIT2 OppressionTPE1 Ben HarperTALB Fight For Your MindTYER 1995COMM TCON (17)TRCK Info "$')+.1468;=?CEHJLORUWY\^bdfiknqtvx{} :LAME3.96r --------------------------------------------- TAGOppression Ben Harper Fight For Your Mind 1995 after tagging with easytag: TIT2 new titleTPE1 new artistTALB new albumTYER 1995TRCK 01TCON new genreTLEN 180000 Info "$')+.1468;=?CEHJLORUWY\^bdfiknqtvx{} :LAME3.96r --------------------------------------------------------- TAGnew title new artist new album 1995 So easytag just overwrote the tags as expected. But after tagging with rhythmbox (rb): gtxTIT2 new rb titleTPE1 new rb artistTALB new rb albumTDRC 1995TCON new rb genreTRCK 1TPOS TIT2 new titleTPE1 new artistTALB new albumTYER 1995TRCK 01TCON new genreTLEN 180000 Info "$')+.1468;=?CEHJLORUWY\^bdfiknqtvx{} :LAME3.96r ---------------------------------------------------------- TAGnew title new artist new album 1995 TAGnew rb title new rb artist new rb album 1995 after tagging a 2nd time with rb: ]TIT2 new rb2 titleTPE1 new rb2 artistTALB new rb2 albumTDRC 1995TCON new rb2 genreTRCK 1TPOS gtxTIT2 new rb titleTPE1 new rb artistTALB new rb albumTDRC 1995TCON new rb genreTRCK 1TPOS TIT2 new titleTPE1 new artistTALB new albumTYER 1995TRCK 01TCON new genreTLEN 180000 Info "$')+.1468;=?CEHJLORUWY\^bdfiknqtvx{} :LAME3.96r ------------------------------------------------------------ TAGnew title new artist new album 1995 TAGnew rb title new rb artist new rb album 1995 TAGnew rb2 title new rb2 artist new rb2 album 1995 So rb keeps adding meta data that other players don't see. The weird thing is after closing and restarting rb even it only sees the 'correct' tags that easytag wrote. Now the whole thing again for a song ripped by sound-juicer (sj): ------------------------------------------------------ TAGGround On Down Ben Harper Fight For Your Mind ------------------------------------------------------- TAGGround On Down Ben Harper Fight For Your Mind The first tag info didn't come at the beginning of the strings output, but after those thousands of 'UU's. However, all my music apps see correctly see the tags as written, except for genre which sj didn't fill. After tagging with easytag: GTIT2 new titleTPE1 new artistTALB new albumTRCK 02TCON new genreTLEN 296000 ---------------------------------------------------- TAGGround On Down Ben Harper Fight For Your Mind ------------------------------------------------------ TAGnew title new artist new album So easytag wrote to what I thought of as the usual place. Other audio apps see what easytag did. rb sees the second set here, which is what sj filled. Ignores what easytag did (first set) except for genre which sj never wrote to. after tagging with rb: TIT2 new rb titleTPE1 new rb artistTALB new rb albumTCON new rb genreTRCK 2TPOS GTIT2 new titleTPE1 new artistTALB new albumTRCK 02TCON new genreTLEN 296000 ------------------------------------- TAGGround On Down Ben Harper Fight For Your Mind ------------------------------------- TAGnew title new artist new album TAGnew rb title new rb artist new rb album after rb tagging, and a rb restart, rb still only sees the set in the middle section, the tags that sj wrote. after a 2nd rb tagging it's the same as with the song ripped by grip; more meta data that other players don't see. after an rb restart rb still sees the tags that sj gave it So it looks like two problems: 1a: rb doesn't overwrite tags, it just adds more meta data that other audio players don't see. 1b: rb doesn't even read the tags that it wrote. Which wouldn't be a problem if it wrote tags to the 'correct' place to begin with. 2: sound-juicer writes tags in an entirely different place than either easytag or rb. If these fields are filled then rb ignores all others. If you rip with sound-juicer and use rhythmbox you'd better get the tags right when ripping, because you won't be able to change them later (at least not so rhythmbox will see the changes). I also had this problem with another ripper (Goobox) which uses gstreamer.
(In reply to comment #18) > So it looks like two problems: > 1a: rb doesn't overwrite tags, it just adds more meta data that other audio > players don't see. > 1b: rb doesn't even read the tags that it wrote. Which wouldn't be a problem if > it wrote tags to the 'correct' place to begin with. > > 2: sound-juicer writes tags in an entirely different place than either easytag > or rb. If these fields are filled then rb ignores all others. If you rip with > sound-juicer and use rhythmbox you'd better get the tags right when ripping, > because you won't be able to change them later (at least not so rhythmbox will > see the changes). I also had this problem with another ripper (Goobox) which > uses gstreamer. Thanks for the comprehensive investigation into tag writing. It confirms everything that I have seen so far, but it appears that the problem is even worse that I thought. 1. It appears that the gstreamer backend has some major problems in tag writing, so when the configure option says very experimental, it means it really doesn't work at all. :-( 2. The sound-juicer tag-writing also has problems. So the two core GNOME apps for ripping and reading/writing tags just don't work properly. Not good. So it appears better to rip in third party apps such as grip and do retagging in easytag and/or tagtool for the moment. Where should we take this bug next? Perhaps keep this open, but also open up relevant bugs in gstreamer and sound-juicer and have those bugs "block" this one, that way we can track them easily.
One thing to keep in mind is that gstreamer writes id3v2.4 tags, which many tag handling apps don't support, I'm pretty sure easytag didn't last time I tried those. Apps using either gstreamer or taglib should be able to read them back. I haven't read carefully what is said in this bug, so I'm not sure it's relevant or not, but I thought I'd better mention it :)
(In reply to comment #20) > One thing to keep in mind is that gstreamer writes id3v2.4 tags, which many tag > handling apps don't support, I'm pretty sure easytag didn't last time I tried > those. Apps using either gstreamer or taglib should be able to read them back. > I haven't read carefully what is said in this bug, so I'm not sure it's > relevant or not, but I thought I'd better mention it :) I tried ripping with sound-juicer and then retagging in amarok (which uses taglib rather than libid3tag, which gstreamer uses) and I got the same kinds of problems.
I suspect bug #306627 and bug #320767 may be related to the sound-juicer issues. If somebody who is regularly testing gstreamer could test the patch at bug #306627 and see if it solves the downstream tagging issues in rhythmbox that would be helpful.
Afaict, bug #306627 is about encoding of id3v1 tags when written by lame. id3v1 is obsolete and is appended to the end of the song, and anyway I don't think rhythmbox uses lame to retag mp3 files. So I really doubt this patch will help ;)
(In reply to comment #23) > Afaict, bug #306627 is about encoding of id3v1 tags when written by lame. id3v1 > is obsolete and is appended to the end of the song, and anyway I don't think > rhythmbox uses lame to retag mp3 files. So I really doubt this patch will help > ;) You're right, for mp3 files I think gstreamer (and therefore sound-juicer) uses the libmad plugin which in turn uses libid3tag for the actually tagging. But there is definitely something fishy about the files that sound-juicer generates initially. What other ripping solutions are out there (other than grip)? (Incidentally why are there so many #$@! tagging libraries with such similar names: taglib, libid3tag, id3lib?)
(In reply to comment #20) >Apps using either gstreamer or taglib should be able to read them back. That's what's so strange about this bug, because it appears that sound-juicer and rhythmbox are both apps that use gstreamer for tag reading and writing (and therefore libid3tag) and should therefore be using the same underlying interface. But as you can see from comment #18 and my original post, everytime rhythmbox tries to update the tag, it writes another stanza.
« But as you can see from comment #18 and my original post, everytime rhythmbox tries to update the tag, it writes another stanza. » Imo this can mean two things: either rhythmbox writes a new id3v2 tag each time instead of modifying the existing one, either GST_TAG_REPLACE (or whatever it's called) doesn't work properly, and new tags are appened to the existing id3v2 tag instead of being replaced. hexdump and http://www.id3.org/ should help figuring out what exactly is wrong, and when you know exactly what rhythmbox is doing, you can have a look at gstreamer code to fix it ;) All the discussion about s-j, what tags rhythmbox reads and so on is probably distinct, or maybe it's only caused by rhythmbox writing bogus tags, but thinking about the 2 issues at once is too confusing for me, and probably only adding useless complexity to the problem, so if you want to investigate further this second issue, I'd suggest only using s-j, easytag, grip, ... and rhythmbox *without tag writing*. If there's no issue as long as rhythmbox didn't write any tag, then let's say it's all the same bug, but it's not worth bothering with all those tools when we already have a way to cause bad behaviour using only rb. (and once again, sorry if I missed information from some comments, I must admit I only quickly looked at the bug report)
s-j's tags are written by "liblame" not by any other libraries.
(In reply to comment #27) > s-j's tags are written by "liblame" not by any other libraries. Ah, so that would explain why tagging in rhythmbox isn't the same as tagging in s-j.
(In reply to comment #26) > All the discussion about s-j, what tags rhythmbox reads and so on is probably > distinct, or maybe it's only caused by rhythmbox writing bogus tags, but > thinking about the 2 issues at once is too confusing for me, and probably only > adding useless complexity to the problem, so if you want to investigate further > this second issue, I'd suggest only using s-j, easytag, grip, ... and rhythmbox > *without tag writing*. If there's no issue as long as rhythmbox didn't write > any tag, then let's say it's all the same bug, but it's not worth bothering > with all those tools when we already have a way to cause bad behaviour using > only rb. I think you're right there are two distinct issues: 1. The problem with rhythmbox tag writing (which is the proper subject of this bug) and the addition of duplicate tags, this happens regardless of whether writing to an mp3 file that was originally ripped in s-j or grip (just tested this). 2. Problems with the tags files written by s-j, this should be the subject of another bug. I can work around both by ripping in grip, but not using rhythmbox for modifiying any tags and only updating using tagtool. rhythmbox will "see" any changes made to tags in files ripped with grip, but will not see any changes to tags in files ripped with s-j. > (and once again, sorry if I missed information from some comments, I must admit > I only quickly looked at the bug report) No, I think you've pretty much got it.
On the second issue (problems with mp3's generated by sound-juicer), I've opened a new bug, bug #326438.
In an effort to see whether this was a bug in gstreamer 0.8.11 that's fixed in 0.10, I tried updating to gstreamer 0.10.0 using the gstreamer010 packages for FC4 at gstreamer.freedesktop.org: $ rpm -qa|grep gstreamer010 gstreamer010-plugins-base-0.10.1-0.gst.1.4 gstreamer010-plugins-bad-devel-0.10.0-0.gst.2.4 gstreamer010-plugins-base-devel-0.10.1-0.gst.1.4 gstreamer010-0.10.1-0.gst.1.4 gstreamer010-plugins-ugly-devel-0.10.0-0.gst.3.4 gstreamer010-plugins-good-devel-0.10.0-0.gst.2.4 gstreamer010-plugins-ugly-0.10.0-0.gst.3.4 gstreamer010-plugins-good-0.10.0-0.gst.2.4 gstreamer010-devel-0.10.1-0.gst.1.4 gstreamer010-plugins-bad-0.10.0-0.gst.2.4 and successfully recompiled rhythmbox using --with-playback=gstreamer-0-10 (and --enable-tag-writing). Unfortunately when I open up the Properties tag for a song, it won't let me edit any tags that have already been filled. It will let me tags that haven't been set, but they aren't actually written to the file. Is there any fundamental reason why tag writing won't work with gstreamer 0.10? If so, the configure options should be changed to prevent tag writing being enabled.
Tag-editing not working witg gst 0.10, is just a bug in the porting. I thought there was a bug about it, but can't seem to find it. Hopefully we'll get it fixed soon
(In reply to comment #32) > Tag-editing not working witg gst 0.10, is just a bug in the porting. I thought > there was a bug about it, but can't seem to find it. Hopefully we'll get it > fixed soon Thanks. With regard to rb compiled against gst 0.8, have you managed to duplicate this bug? Has the actual tag writing code changed much from 0.8 to 0.10 such that this writing problem may have been fixed? I looked through the ChangeLog's a while back but didn't find anything that seemed like it addressed bugs in tag writing.
For (id3) tag-writing in 0.10, we need to use id3demux and id3mux instead of id3tag. Also, for some reason I don't have gnomevfssink in 0.10, which make it not work for me (I'm not sure if it's my machine, or it hasn't been ported yet). I can't see how Rhythmbox could cause the issues described in this bug, I think it would either be a) id3tag being crap (which is why it got removed in 0.10), b) a GStreamer problem, or c) an issue with the underlying library (libmad IIRC).
(In reply to comment #34) > For (id3) tag-writing in 0.10, we need to use id3demux and id3mux instead of > id3tag. Also, for some reason I don't have gnomevfssink in 0.10, which make it > not work for me (I'm not sure if it's my machine, or it hasn't been ported > yet). I think that id3demux just got added to 0.10.0.2, at least that's what it says in the changelog for the rpm from gstreamer.freedesktop.org that was just installed (haven't recompiled rb against this yet). Don't know if gnomevfssink is there (is it a plugin?). Does there need to be some code changes to rb itself to make it work with id3demux rather than id3tag, or is just a recompile? $ rpm -q gstreamer010-plugins-good --changelog |head * Wed Jan 11 2006 Thomas Vander Stichele <thomas at apestaart dot org> - 0.10.0.2-0.gst.1 - new prerelease - added i3demux * Wed Dec 14 2005 Thomas Vander Stichele <thomas at apestaart dot org> - 0.10.0-0.gst.2 - glib 2.8 - added cairo > I can't see how Rhythmbox could cause the issues described in this bug Agreed probably not a rb issue. Humour me though: have you managed to duplicate this yourself by ripping a track in mp3 format then attempting to retag within rb? You can start with mp3 ripped with s-j or grip, once rb has written it once, it won't write again. Sorry to harp on about this, but I'd like an rb developer to confirm that I'm not going mad... ;-) > I think > it would either be a) id3tag being crap (which is why it got removed in 0.10), > b) a GStreamer problem, or c) an issue with the underlying library (libmad > IIRC). I think it's either a) or b), but not libmad I think because that only does playback/decoding and gstreamer passes the tagging to id3tag (aka libid3tag).
*** Bug 324683 has been marked as a duplicate of this bug. ***
Pretty sure that this is a problem with gstreamer 0.8.x, reassigning to that product, although difficult to reproduce outside of rhythmbox as there is no way to do it from command-line pipeline. Feel free to reassign back to rhythmbox if it isn't a gst problem.
By the way, the reverting of tags in rhythmbox happens also with using gstreamer 0.10 and patch on bug #309609 against rhythmbox for using the new id3mux plugin from gst-plugins-ugly 0.10.1. (id3mux appears to still be based on libid3tag, so it doesn't seem to be fixed in 0.10). Has *anybody* got working tag-writing with *any* app using *any* version of gstreamer? I can't find any other programs to test this with.
Updated summary to reflect that the problem appears to be changing ID3 tags in gstreamer generally. I can use a id3demux ! id3mux pipeline from the command line to copy a file and it's tags, and writing ID3 tags to a new MP3 file is obviously working from sound-juicer, so that "writing" works, but "changing" doesn't appear to.
(In reply to comment #39) > writing ID3 tags to a new MP3 file is obviously working from sound-juicer, Scratch, that I think that s-j used to (and maybe still does) use the ID3-writing facility from the lame plugin, not id3mux. So that's one less context that id3mux is known to work in.
"Has *anybody* got working tag-writing with *any* app using *any* version of gstreamer?" tag writing worked for me with rhythmbox and gstreamer 0.8 at some point in time, I haven't tested recently.
Thanks. Yes, I had it working with rb very briefly (just before reporting this bug) but even then it would only ever save changes once, subsequent changes would revert. I really meant has anybody got it working recently? I am trying to test both the old id3tag plugin from gst 0.8 and the new id3mux plugin from gst 0.10 in standalone mode, but I haven't found any sample pipelines I can adapt (and it can't be tested via gst-launch, that's out of scope according to wingo, jan schmidt and others on #gstreamer IRC chat).
With non-ID3 tags, it has worked pretty well, writing and editing flac tags, and writing vorbis tags. With ID3 tags, it sometimes works with gstreamer 0.8, but sometimes not.
(In reply to comment #43) > With non-ID3 tags, it has worked pretty well, writing and editing flac tags, > and writing vorbis tags. I meant ID3 tags, sorry, I should have been more specific. > With ID3 tags, it sometimes works with gstreamer 0.8, but sometimes not. Right, that's what I thought. I was also wondering about whether there were any apps other than rhythmbox that even use the ID3 tag writing elements, I mean have they ever been tested outside rhythmbox? I couldn't find any unit tests in gstreamer for either 0.8 or 0.10.
No - Sound Juicer is the only other app I know that's even tried it. I've said in a few places now: Tag re-writing in GStreamer is a fairly unexplored area that needs someone who cares to step up and fix it.
(In reply to comment #45) > No - Sound Juicer is the only other app I know that's even tried it. Bleh. I guessed that was the case, but I was hoping I was wrong. ;-) > I've said in a few places now: Tag re-writing in GStreamer is a fairly > unexplored area that needs someone who cares to step up and fix it. I care, but I don't really have the time to learn the whole gstreamer plugin infrastructure pipelines, pads and whatnot, right now (I'm still getting my head around the rhythmbox code). I was hoping there would be other gst developers who did... ;-) What do most gst developers use for tag re-writing: tagtool or easytag?
I can now do tag writing with RB, yay! Using the brand-new plugin tagid3v2mux (not yet in CVS) at bug #333501, rewriting works. It only generates id3v2.4.0 tags, which means they are not backwards-compatible with some other applications including easytag, tagtool and id3lib. Interestingly enough with the latest gst-plugins-ugly package 0.10.2 (not CVS), it also appears that the old id3mux plugin now works too, although it too only writes id3v2.4.0 tags too. There seems to be some differences between the tags re-written by id3mux vs tagid3v2mux, in that ones written by tagid3v2mux can be read by xmms, but ones written by id3mux cannot. Strange.
(In reply to comment #47) > I can now do tag writing with RB, yay! Using the brand-new plugin tagid3v2mux > (not yet in CVS) at bug #333501, rewriting works. It only generates id3v2.4.0 > tags, which means they are not backwards-compatible with some other > applications including easytag, tagtool and id3lib. I got this working applying this patch: http://bugzilla.gnome.org/attachment.cgi?id=58495 and replacing id3mux with tagid3v2mux throughout. > Interestingly enough with the latest gst-plugins-ugly package 0.10.2 (not CVS), > it also appears that the old id3mux plugin now works too, although it too only > writes id3v2.4.0 tags too. This works applying the above patch, as-is.
A remaining problem is that with id3mux, any tags that aren't supported in gstreamer tag writing backend are overwritten, e.g. TCON (for composer), TCOP (for copyright), TENC (for name of encoder). What should happen is that any tags that gstreamer *doesn't* directly overwrite should be left intact otherwise there will be data lossage.
(In reply to comment #49) > A remaining problem is that with id3mux, any tags that aren't supported in > gstreamer tag writing backend are overwritten, e.g. TCON (for composer), > TENC (for name of encoder). No appropriate GST_TAG_ > TCOP (for copyright) This has actually been fixed now in id3mux since GST_TAG_COPYRIGHT supports this. > What should happen is that any tags that gstreamer *doesn't* directly overwrite should be left intact otherwise there will be data lossage. Since the original issue (double tags being added) has been fixed now. I'm closing this bug and opening up this tag lossage issue as a clone: bug #334375.
There has been a regression in 0.10.3 (and in CVS), id3mux no longer works. In rhythmbox, get the following message: "Error while saving song information File corrupted during write" Re-opening bug.
Created attachment 63556 [details] Corrupted file This pipeline: gst-launch-0.10 filesrc location=V2.mp3 ! id3demux ! id3mux ! filesink location=new.mp3 results in this corrupted file and truncated file (new.mp3), so it appears it is not a rhythmbox issue. This file can't be imported into rhythmbox.
Created attachment 64103 [details] [review] One-line fix to fix id3mux plugin so the mp3 content is written This adds one-line: gst_buffer_set_caps (buffer, GST_PAD_CAPS (tag->srcpad)); before the gst_pad_push() call, which appeared to prevent the actual mp3 content from also being written to the file and resulted in only the tags being written to the file, resulting in the truncated file. This works for me against id3demux in the released gstreamer-plugins-good 0.10.2 as well as gstreamer-plugins-good id3demux in CVS.
Tested with rhythmbox and it tag editing works in rhythmbox with this fix.
Excellent - committed: 2006-04-22 Tim-Philipp Müller <tim at centricular dot net> Patch by: Alexander Lancaster <alexl at users sourceforge net> * ext/mad/gstid3tag.c: (gst_id3_tag_get_caps), (gst_id3_tag_init), (gst_id3_tag_sink_event), (gst_id3_tag_src_link), (gst_id3_tag_chain): When acting as a muxer, set caps on outgoing buffers and set caps on source pad (fixes #323658). Remove unused application/x-gst-tags cruft from the 0.6 days. (better double check I didn't break anything with my additional changes).
*** Bug 345365 has been marked as a duplicate of this bug. ***