After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 323658 - [id3mux] Changing of ID3 tags is broken in gstreamer
[id3mux] Changing of ID3 tags is broken in gstreamer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.3
Other All
: Normal major
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 324683 345365 (view as bug list)
Depends on:
Blocks: 334375
 
 
Reported: 2005-12-09 19:04 UTC by Alex Lancaster
Modified: 2006-06-25 08:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (515 bytes, patch)
2005-12-10 10:45 UTC, James "Doc" Livingston
rejected Details | Review
Corrupted file (41 bytes, application/octet-stream)
2006-04-15 10:32 UTC, Alex Lancaster
  Details
One-line fix to fix id3mux plugin so the mp3 content is written (554 bytes, patch)
2006-04-22 13:05 UTC, Alex Lancaster
committed Details | Review

Description Alex Lancaster 2005-12-09 19:04:51 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.
Comment 1 Alex Lancaster 2005-12-09 19:06:56 UTC
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.
Comment 2 Alex Lancaster 2005-12-09 19:09:51 UTC
See also some previous discussion on this problem at bug #323425.
Comment 3 James "Doc" Livingston 2005-12-10 10:45:22 UTC
Created attachment 55837 [details] [review]
patch

Can you try it with this patch? It will tell gstreamer to do _REPLACE_ALL
instead of _REPLACE.
Comment 4 Alex Lancaster 2005-12-10 17:43:17 UTC
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
Comment 5 Alex Lancaster 2005-12-10 19:16:33 UTC
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.
Comment 6 James "Doc" Livingston 2005-12-11 01:46:06 UTC
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.
Comment 7 Alex Lancaster 2005-12-11 02:11:25 UTC
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?
Comment 8 James "Doc" Livingston 2005-12-11 12:07:33 UTC
I can't get it to occur with gstreamer 0.10.0 or 0.8.11. What version of
libid3tag do you have?
Comment 9 Alex Lancaster 2005-12-11 14:23:39 UTC
$ rpm -q libid3tag
libid3tag-0.15.1-3.b

I am running gstreamer-0.8.10-1, I'll try gstreamer-0.8.11.
Comment 10 Alex Lancaster 2005-12-11 14:44:59 UTC
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.
Comment 11 Jalani Kanem 2005-12-16 20:18:22 UTC
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.
Comment 12 Alex Lancaster 2005-12-17 01:28:53 UTC
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.
Comment 13 Alex Lancaster 2005-12-17 01:31:31 UTC
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.
Comment 14 Alex Lancaster 2005-12-17 01:33:06 UTC
But arguing against that is the fact that the problem still occurs even when
deleting all tags.  Will investigate further.
Comment 15 Jalani Kanem 2005-12-17 03:51:01 UTC
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.
Comment 16 Alex Lancaster 2005-12-17 10:16:07 UTC
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.
Comment 17 Alex Lancaster 2005-12-17 10:19:19 UTC
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?
Comment 18 Jalani Kanem 2005-12-21 10:04:51 UTC
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.
Comment 19 Alex Lancaster 2006-01-06 06:55:45 UTC
(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.

Comment 20 Christophe Fergeau 2006-01-06 09:14:20 UTC
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 :)
Comment 21 Alex Lancaster 2006-01-06 12:43:04 UTC
(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. 

Comment 22 Alex Lancaster 2006-01-06 12:50:40 UTC
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.
Comment 23 Christophe Fergeau 2006-01-06 12:55:49 UTC
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 ;)
Comment 24 Alex Lancaster 2006-01-06 13:01:17 UTC
(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?)

Comment 25 Alex Lancaster 2006-01-06 13:08:44 UTC
(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.

Comment 26 Christophe Fergeau 2006-01-06 13:28:15 UTC
« 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)
Comment 27 Bastien Nocera 2006-01-06 13:31:23 UTC
s-j's tags are written by "liblame" not by any other libraries.
Comment 28 Alex Lancaster 2006-01-06 14:03:18 UTC
(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. 

Comment 29 Alex Lancaster 2006-01-06 14:09:36 UTC
(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.

Comment 30 Alex Lancaster 2006-01-10 10:16:26 UTC
On the second issue (problems with mp3's generated by sound-juicer), I've opened a new bug, bug #326438.
Comment 31 Alex Lancaster 2006-01-11 03:38:04 UTC
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. 
Comment 32 James "Doc" Livingston 2006-01-12 10:21:38 UTC
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
Comment 33 Alex Lancaster 2006-01-12 14:33:20 UTC
(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.

Comment 34 James "Doc" Livingston 2006-01-13 14:10:50 UTC
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).
Comment 35 Alex Lancaster 2006-01-13 14:57:15 UTC
(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).
 

Comment 36 Alex Lancaster 2006-01-27 11:38:33 UTC
*** Bug 324683 has been marked as a duplicate of this bug. ***
Comment 37 Alex Lancaster 2006-02-09 14:19:27 UTC
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.
Comment 38 Alex Lancaster 2006-02-16 15:20:49 UTC
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.
Comment 39 Alex Lancaster 2006-02-16 15:26:40 UTC
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.
Comment 40 Alex Lancaster 2006-02-16 15:36:09 UTC
(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.
Comment 41 Christophe Fergeau 2006-02-16 15:45:41 UTC
"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.
Comment 42 Alex Lancaster 2006-02-16 15:57:15 UTC
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).
Comment 43 James "Doc" Livingston 2006-02-17 04:51:57 UTC
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.
Comment 44 Alex Lancaster 2006-02-21 13:39:11 UTC
(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.
Comment 45 Jan Schmidt 2006-02-21 14:07:59 UTC
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.

Comment 46 Alex Lancaster 2006-02-21 14:23:00 UTC
(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?

Comment 47 Alex Lancaster 2006-03-06 22:59:45 UTC
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.

Comment 48 Alex Lancaster 2006-03-06 23:01:39 UTC
(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.
Comment 49 Alex Lancaster 2006-03-07 02:33:50 UTC
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.
Comment 50 Alex Lancaster 2006-03-13 05:09:03 UTC
(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.
Comment 51 Alex Lancaster 2006-04-15 10:13:15 UTC
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.
Comment 52 Alex Lancaster 2006-04-15 10:32:19 UTC
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.
Comment 53 Alex Lancaster 2006-04-22 13:05:36 UTC
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.
Comment 54 Alex Lancaster 2006-04-22 13:11:23 UTC
Tested with rhythmbox and it tag editing works in rhythmbox with this fix.
Comment 55 Tim-Philipp Müller 2006-04-22 18:50:45 UTC
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).
Comment 56 Tim-Philipp Müller 2006-06-25 08:52:03 UTC
*** Bug 345365 has been marked as a duplicate of this bug. ***