GNOME Bugzilla – Bug 309609
Porting to GStreamer 0.10
Last modified: 2006-03-12 08:56:23 UTC
Please describe the problem: Providing a patch I'm using to run Rhythmbox against the current GStreamer 0.9 development branch. This makes playback work. I didn't port (or even look at) the CD burning stuff, since I don't have the dependencies. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 48732 [details] [review] patch to run RB against GStreamer 0.9 branch
That's obviously unmergeable right now. GStreamer 0.9 won't be ready for 2.12, and as such, it's not possible to make it the default (current RB targets 2.12). I would advise that you make it compile-time selectable via a configure switch, and add ifdef's to the player and metadata bits to support 0.9.
Created attachment 51439 [details] [review] Updated patch Updating patch for latest CVS. Just to clarify, these patches aren't intended for merging until GStreamer 0.9 becomes more stable. For now, I'm just putting it up so interested parties can try it out. When GStreamer 0.10 gets closer, I'll look at making it compile conditionally against GStreamer 0.8 as well.
Created attachment 53235 [details] [review] Even-more updated patch Another patch update, this should build against gstreamer cvs from yesterday (october 7), untested with today's changes. Covers all the state-change function/type renames, bus poll changes, and a moved header file. Also some updates for changes in rhythmbox.
Created attachment 55526 [details] [review] another updated patch This patch is updated to current cvs and can support both 0.8 and 0.10 - selected via the --with-player= configure option. I haven't actually tried compiling against 0.9.x with it yet, and will probably need some changes to work. I'm putting this up because I probably won't get a chance to do anything with it over the next few days, and someone else may want to try it.
Tried the 0.10 port compilation, with James's patch, fails with: rb-metadata-gst.c -fPIC -DPIC -o .libs/rb-metadata-gst.o rb-metadata-gst.c: In function 'rb_metadata_load': rb-metadata-gst.c:815: error: too many arguments to function 'gst_element_query_position'
If that is with 0.10, then it doesn't suprise me. Like I said, I hasn't tried compiling against 0.10, so it need to deal with a) changes in Rhythmbox, b) changes in GStreamer, c) fixing any copy-and-paste errors I intoduced, and d) porting the bits that were never ported in the original patch.
Created attachment 55628 [details] [review] New updated patch Further update to James' patch that provides conditional compilation against either 0.8 or 0.10. I've imported my entire collection and been listening with this one against 0.10 for a few hours now this morning.
Created attachment 55636 [details] [review] another updated patch It will now complain if you try to compile with gst 0.10 and DAAP, because the daap element isn't ported yet. Also made the end-of-configure info actually print out.
With this patch i'm getting errors while trying to play several mp3 files, on the main windows only a stop icon appers, but if i select properties in one of this songs i get this on the bottom of the dialog: Internal data flow error.
I've committed the patch to cvs. Issues still remaining: * daap element needs to be ported * "decoded-pad" handler in the metadata loading code needs to link non-audio pads (and extra audio pads) to a fakesink, so that it doesn't emit data-flow errors, which pause loading for 5 seconds.
Created attachment 56437 [details] [review] daap src port seeking sort of mostly works, but the buffered data is played before playback starts from the seek point, which is weird and confusing. It also seems pretty inaccurate for shortish songs, but I don't think that's anything gst 0.10 specific. EOS is reported as a data flow error, which needs fixing.
The patch works okay for me, aside from the seeking issue (which it has always had). I haven't seen any data flow error in my use of it.
Created attachment 56956 [details] [review] updated patch Fixes a few compilation warnings and the like. Since this mostly works, and DAAP support is "experimental" anyway, this could probably be committed if you're happy with it.
This seems to work ok for me.
Created attachment 57585 [details] [review] hopefully final patch This does several things: - combines it all into one file (another mess of #ifdefs) - adds HTTP chunked transfer support (bug 326738) - tries to get seeking working again (bug 318852) Seeking is still shaky and unreliable. It works best with mp3 files using gstreamer 0.8.
Created attachment 57587 [details] [review] hopefully final patch 2 forgot the changes in rb-player-gst.c
Sadly, not the last :( I get this: gcc -DHAVE_CONFIG_H -I. -I. -I.. -DGNOMELOCALEDIR=\"/usr/share/locale\" -DG_LOG_DOMAIN=\"Rhythmbox\" -I.. -I../lib -I../lib -I../corba -I../corba -I../rhythmdb -I../library -I../iradio -I../widgets -I../shell -I../sources -DPIXMAP_DIR=\"/usr/share/pixmaps\" -DSHARE_DIR=\"/usr/share/rhythmbox\" -DDATADIR=\"/usr/share\" -DORBIT2=1 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gnome-vfs-module-2.0 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/libsoup-2.2 -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=pentium4 -fasynchronous-unwind-tables -Wcomment -Wformat -Wnonnull -Wimplicit-int -Wimplicit -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused-function -Wunused-label -Wunused-value -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wall -Werror -std=gnu89 -MT rb-daap-src.lo -MD -MP -MF .deps/rb-daap-src.Tpo -c rb-daap-src.c -fPIC -DPIC -o .libs/rb-daap-src.o cc1: warnings being treated as errors rb-daap-src.c:148: warning: no previous prototype for 'rb_daap_src_get_type' rb-daap-src.c: In function 'rb_daap_src_read_chunk_size': rb-daap-src.c:540: warning: implicit declaration of function 'isxdigit' rb-daap-src.c: In function 'rb_daap_src_stop': rb-daap-src.c:857: warning: control reaches end of non-void function make[2]: *** [rb-daap-src.lo] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/rhythmbox-0.9.2.cvs200601180951/daapsharing' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/rhythmbox-0.9.2.cvs200601180951' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.48167 (%build)
Created attachment 57618 [details] [review] one more.. now builds with --enable-more-warnings
Not quite :( gcc -DHAVE_CONFIG_H -I. -I. -I.. -DGNOMELOCALEDIR=\"/usr/share/locale\" -DG_LOG_DOMAIN=\"Rhythmbox\" -I.. -I../lib -I../lib -I../corba -I../corba -I../rhythmdb -I../library -I../iradio -I../widgets -I../shell -I../sources -DPIXMAP_DIR=\"/usr/share/pixmaps\" -DSHARE_DIR=\"/usr/share/rhythmbox\" -DDATADIR=\"/usr/share\" -DORBIT2=1 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gnome-vfs-module-2.0 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/libsoup-2.2 -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=pentium4 -fasynchronous-unwind-tables -Wcomment -Wformat -Wnonnull -Wimplicit-int -Wimplicit -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused-function -Wunused-label -Wunused-value -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wall -Werror -std=gnu89 -MT rb-daap-src.lo -MD -MP -MF .deps/rb-daap-src.Tpo -c rb-daap-src.c -fPIC -DPIC -o .libs/rb-daap-src.o cc1: warnings being treated as errors rb-daap-src.c:150: warning: no previous prototype for 'rb_daap_src_get_type' make[2]: *** [rb-daap-src.lo] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/rhythmbox-0.9.2.cvs200601181955/daapsharing'
That is bug 325429. You either have to turn off --enable-more-warnings, or update gstreamer (core) to 0.10.2 The patch seems to be working for me.
Fedora upgraded to that today and now this compiles fine for me. Thanks!
Works well for me, with RB and iTunes.
Committed. I'm not going to close this bug, because we still need to fix the pipeline used to do mp3 tag editing, and there's probably some other stuff too.
What needs to be done to port mp3 tag editing? I would like have a crack at it to see if gstreamer 0.10 may have also fixed bug #323658.
Created attachment 57835 [details] [review] non-working tag writing I'd started to do this, this patch is a start. This replaces the use of id3tag with id3demux ! id3mux; it doesn't work at the moment and writes out empty files (which get detected as bad, so it aborts) but I'm fairly that it due to a stupid mistake on my part that I haven't found. Flac tag editing will need to wait until the flactag element is ported to 0.10, and vorbis tag editing will need the vorbistag element ported and fixed so that it works (it didn't work property in 0.8).
There is also a problem with tag reading of the date element with 0.10 gstreamer (why is this field so problematic?) It appears that the underlying type of date has changed from gulong to new GstDate (a GDate wrapper) in 0.10.2 of gstreamer (see bug #170777). This means that dates aren't recognised properly, here is an excerpt of the debug log that demonstrates the problem: [0x922b240] [rb_metadata_gst_load_tag] rb-metadata-gst.c:414 (05:05:50): uri: file:///home/alex/mp3/singletons/untagged/01_Three%20Mile%20Island.mp3 tag: date [0x922b240] [rb_metadata_gst_load_tag] rb-metadata-gst.c:452 (05:05:50): Could not transform tag value type GstDate into gulong I am using 0.10.2 of gstreamer and 0.10.1 of the mp3 plugins (gstreamer-plugins-ugly). $ rpm -qa|grep gstreamer010 gstreamer010-plugins-bad-devel-0.10.0-0.gst.2.4 gstreamer010-plugins-good-devel-0.10.1-0.gst.1.4 gstreamer010-devel-0.10.2-0.gst.1.4 gstreamer010-plugins-good-0.10.1-0.gst.1.4 gstreamer010-plugins-base-devel-0.10.2-0.gst.1.4 gstreamer010-plugins-ugly-devel-0.10.1-0.gst.1.4 gstreamer010-0.10.2-0.gst.1.4 gstreamer010-plugins-base-0.10.2-0.gst.1.4 gstreamer010-plugins-bad-0.10.0-0.gst.2.4 gstreamer010-plugins-ugly-0.10.1-0.gst.1.4
Created attachment 57847 [details] [review] Debugging patch for decoding GstDate problem This is a debugging patch that illustrates where the date decoding problem is and an attempts a (somewhat clumsy) workaround. It works for OGG files (i.e. OGG files now have their date decoded correctly) but not for MP3 files. Could it be that the plugin has not been ported?
Sample output: Upon adding an OGG file to library: Of type GST_TYPE_DATE 2002-01-01 Julian date: 730851 Upon adding an MP3 to library: Of type GST_TYPE_DATE 9999-99-99 Date is NULL Julian date: 0 Of type GST_TYPE_DATE 9999-99-99 Date is NULL Julian date: 0
Created attachment 57888 [details] [review] Fix 0.10 date issue This is a slightly more elegant way of converting the date, by registering a transformation function from GstDate to gulong. The problem of not working for id3 tags is that the GDate inside the GstDate is set to NULL, which I've reported as bug 328241.
(In reply to comment #30) > Created an attachment (id=57888) [edit] > Fix 0.10 date issue > > This is a slightly more elegant way of converting the date, by registering a > transformation function from GstDate to gulong. Works for me for OGG files. > The problem of not working for id3 tags is that the GDate inside the GstDateis > set to NULL, which I've reported as bug 328241. Thanks. I guess when we get non-null GDates this fix should work for MP3. Otherwise no problem committing this patch.
I'm inclined to add GDate <-> ulong conversions directly inside GStreamer, which will obsolete the patch with the next GStreamer core release. The NULL dates issue should be fixed by my changes to the ID3 demuxer on the weekend: Rewrite parsing of text tags to handle multiple NULL terminated strings. Parse numeric genre strings and ID3v2 type "(3)(6)Alternative" style genre strings. Parse dates that are only YYYY or YYYY-mm format.
On further thought, let's do the conversion in Rhythmbox - it seems slightly ugly to add a conversion to gulong in GStreamer, when the obvious representation would be a guint, since that's what g_date_get_julian returns, and it's a very small change in RB.
I've committed the patch (with an additional conversion in the opposite direction, for tag-writing). As Jan mentioned, we should probably be using guint32 instead of gulong - however we would need to change several bits of code. With -plugins-good from cvs, id3 dates work.
Thanks, I'm try to test the CVS checkout of -plugins-good. I have compiled it and installed it successfully in /usr/local/lib/gstreamer-0.10 because I don't want to blow away my RPM installation of gstreamer010-plugins-good which is /usr/lib/gstreamer-0.10. How do I point rhythmbox at the CVS version of the plugins in /usr/local/lib rather than the RPM version so I can test this? gst-register seems to have gone for gstreamer 0.10 and it simply reverted the manual change I put in ~/.gstreamer-0.10/registry.i686.xml.
After hunting around, I think I found it by looking at gst-xmlinspect-0.10 --help I used: GST_PLUGIN_PATH=/usr/local/lib/gstreamer-0.10 ./shell/rhythmbox and it seemed to work.
Yep, exactly right. GST_PLUGIN_PATH settings will override any defaults. You can also link or copy plugin .so files/directory into ~/.gstreamer-0.10/plugins to have them picked up first.
Thanks, I am now testing it and I am finding that it doesn't get the date right for all my albums. I will try and get you a test case. Also it is not recognizing some other tags like title, artist, disc number that were working fine for the 0.8.x versions of the plugins. Are there some limitations with regard to id3v1 vs id3v2 tags? Some of my files are all over the place and the plugin should do the right thing.
In 0.10, we're using a new id3demux that isn't based on libid3tag. It should be considerably faster, and it integrates with GStreamer better, but because it's new code there's bugs to kill. Any sample files that it doesn't work with are appreciated - it works for all the ones I have now.
(In reply to comment #39) > In 0.10, we're using a new id3demux that isn't based on libid3tag. It should be > considerably faster, and it integrates with GStreamer better, but because it's > new code there's bugs to kill. Any sample files that it doesn't work with are > appreciated - it works for all the ones I have now. It seems if the mp3 has only id3v2 tags with year filled in then it returns 0, but if I add an id3v1 tag but only add year, then year appears. In other words it appears to ignore year if it is only present in the id3v2 tag.
(In reply to comment #40) > It seems if the mp3 has only id3v2 tags with year filled in then it returns 0, > but if I add an id3v1 tag but only add year, then year appears. In other words > it appears to ignore year if it is only present in the id3v2 tag. Try importing the file here: http://gstreamer.freedesktop.org/media/incoming/V2.mp3 into CVS rhythmbox with CVS gst-plugins-good and you can see that the date does not get set. Of course, this could still be a bug in rhythmbox's handling of dates.
wow, my testing foo is weak today. Fixed in CVS, properly (fingers crossed) this time.
(In reply to comment #42) > wow, my testing foo is weak today. > > Fixed in CVS, properly (fingers crossed) this time. Thanks, seems to work now. Although it displays 1901 when the ID3v2 tag is there but YER is empty (this could be related to the issue below). My other tagging issues all appear to relate to tracks that were ripped using sound-juicer 2.10. Tags ripped with that version have very nastily botched up ID3v1 and ID3v2 tags (see bug #320767, bug #306627). The old (0.8.x libid3tag?) seemed to work around those tags and display them OK, but the new id3demux doesn't appear to like them at all.
Perhaps the summary should be retitled to "Porting to GStreamer 0.10" to better reflect the porting effort.
Retitling bug to indicate that porting effort is to 0.10.
Created attachment 58324 [details] [review] still non-working tag-editing A slightly updated, but still non-working patch. I must be doing something wrong with using "id3demux ! id3mux" instead of "id3tag", because it writes out unchanged tags (with both 0.8 and 0.10).
(In reply to comment #46) > A slightly updated, but still non-working patch. I must be doing something > wrong with using "id3demux ! id3mux" instead of "id3tag", because it writes out > unchanged tags (with both 0.8 and 0.10). Is it possible to run tagging from the command line using the above pipes? I'd like to just test out retagging some mp3s. What would the syntax look like? gst-launch-0.10 ... id3demux ! id3mux ...
(In reply to comment #46) > Created an attachment (id=58324) [edit] > still non-working tag-editing > > A slightly updated, but still non-working patch. I must be doing something > wrong with using "id3demux ! id3mux" instead of "id3tag", because it writes out > unchanged tags (with both 0.8 and 0.10). OK, here are my results on testing this, which may or may not be useful. If you use the files V1.mp3, V2.mp3, V1V2.mp3 in: http://gstreamer.freedesktop.org/media/incoming/ *V1.mp3 (only contains id3v1 tags) changes revert as you describe, in hexdump it looks like no duplicates were created unlike the problem in bug #323658 where dups were created. *V2.mp3 (only contains id3v2 tags), any change deletes *all* v2 tags, and since there are no v1 tags, resulting file has no tags, and the display goes to "Unknown". *V1V2.mp3 (contains both id3v1 and id3v2 tags), any change means that *all* v2 tags are deleted and the display (and the tags in file) reverts to just the v1 tags. Subsequent changes have no effect (like the problem with V1.mp3). So in summary, it appears that v2 tags are being deleted upon write and updates to v1 tags have no effect. Perhaps this might help narrow down the problem.
(In reply to comment #48) > OK, here are my results on testing this, which may or may not be useful. Btw, only tested with gstreamer 0.10.
I've committed parts of the patch, the bits that make it work with gst 0.10. Since id3mux is broken at the moment, I haven't committed the change from id3tag - so tag editing won't actually work when compiled against 0.10 (unless id3tag/flactag get ported).
(In reply to comment #50) > Since id3mux is broken at the moment, I haven't committed the change from > id3tag - so tag editing won't actually work when compiled against 0.10 (unless > id3tag/flactag get ported). Does the id3mux problem have it's own bugzilla? Also does this change mean there's a chance that bug #323658 might be fixed. ;-) i.e. should tag editing work (at least as well as it did before) with this code if using gstreamer 0.10? I guess if it wasn't a bug in id3tag originally, then it might. I'll give it a test in any case. Thanks.
(In reply to comment #51) > i.e. should tag editing work (at least as well as it did before) with this code if using gstreamer 0.10? I meant gstreamer 0.8!
Created attachment 58495 [details] [review] use id3demux ! id3mux I'm not sure if the id3mux but has been filed in bugzilla or not. The gst 0.8 code is the same as it was before, so nothing will have changed there. This is the patch to use id3demux/id3mux instead of id3tag. For some reason this doesn't seem to work properly with 0.8, and sucks up 100% cpu in the background.
(In reply to comment #53) > I'm not sure if the id3mux but has been filed in bugzilla or not. The gst 0.8 > code is the same as it was before, so nothing will have changed there. > > This is the patch to use id3demux/id3mux instead of id3tag. For some reason > this doesn't seem to work properly with 0.8, and sucks up 100% cpu in the > background. Thanks. Tested the patch, seems to have the same behaviour as that I reported in comment #48 when compiled against gstreamer 0.10. The only new feature appears to be that does compile cleanly against CVS HEAD, I guess that was the point. I guess this is a bug in id3mux, in what other contexts have you heard that id3mux has a problem? I did a search in the gstreamer product, but I couldn't find anything that seemed related. Seems that it is strange for gstreamer switch from a buggy libid3tag plugin to a completely non-working id3mux plugin. As for gst 0.8, couldn't you conditionally compile it to use id3tag for gst 0.8 and id3mux/id3demux for 0.10, or would that be a maintainance nightmare to support two plugins simultaneously?
(In reply to comment #54) > Thanks. Tested the patch, seems to have the same behaviour as that I reported > in comment #48 when compiled against gstreamer 0.10. The only new feature > appears to be that does compile cleanly against CVS HEAD, I guess that was the > point. I'd committed patch of the earlier patch, and attached the rest. > I guess this is a bug in id3mux, in what other contexts have you heard that > id3mux has a problem? I did a search in the gstreamer product, but I couldn't > find anything that seemed related. I'm not sure if it's in bugzilla, I had been talking with people on #gstreamer. I'll have another look later, and file a bug if there isn't one. > Seems that it is strange for gstreamer > switch from a buggy libid3tag plugin to a completely non-working id3mux plugin. id3tag hasn't been ported, but it probably could. > As for gst 0.8, couldn't you conditionally compile it to use id3tag for gst 0.8 > and id3mux/id3demux for 0.10, or would that be a maintainance nightmare to > support two plugins simultaneously? That wouldn't be a problem, and is probably the easiest thing to do. However I don't want to commit this at the moment, because until the plugin gets fixed it will destroy your tags. So unless id3tag gets ported to 0.10, Rhythmbox 0.9.3 won't edit ID3 tags.
To comment #40: Please note, that ID3v2 YER tag was removed in ID3v2.4 (GStreamer marks its tags as ID3v2.4). TYER - Year This frame is replaced by the TDRC frame, 'Recording time' [F:4.2.5]. http://www.id3.org/id3v2.4.0-changes.txt
(In reply to comment #56) > To comment #40: Please note, that ID3v2 YER tag was removed in ID3v2.4 > (GStreamer marks its tags as ID3v2.4). > > TYER - Year > This frame is replaced by the TDRC frame, 'Recording time' > [F:4.2.5]. > > http://www.id3.org/id3v2.4.0-changes.txt OK, but this surely won't mean that gstreamer won't be able to read ID3v2.3 tags? After all many people will have used sound-juicer or grip to rip their mp3 files, and IIRC they used ID3v2.3. I would have thought that gstreamer would read old versions but write ID3v2.4, so what you are saying is that other non-streamer apps may not be able to read the new tags?
Switching to normal priority. Most porting is done in any case (only tag writing needs to be ported).
Yes. ID3v2.3 conforming players can be unable to read ID3v2.4. Specifically: - ID3v2.3 player cannot detect year info from ID3v2.4 TDRC. - ID3v2.3 supports only ISO-8859-1 and UNICODE with BOM. It does not support UTF-8 and UTF-16BE without BOM. There are more less important differences. From my aspect of view, ID3 implementation should support: - ID3v2.4 conforming read/write - ID3v2.3 conforming read/write - ID3v2.4 in ID3v2.3 compatibility mode: use only ISO-8859-1 or UNICODE with BOM, write both TDRC and TYER (TYER is illegal in ID3v2.4, but it should not break anything) - ID3v1 tag with predefined encoding independent on ID3v2 (most ID3v1 supporting hardware players know only one character set, in most cases it is a MS-Windows encoding in country of origin or destination). - ID3v1 intelligent truncating (ask before truncating, ask for all items when one of them needs truncating). - FLAC tag for flac files. - Legal enforcement of some countries and technical work-flow can require copying of ISRC (source identification code for copyright holder identification) while reading CD-DA.
Those kinds of issues are more to do with gstreamer id3demux and id3mux plugins. If you have any problems, please file a bug against those. The remaining issue this bug is addressing is using "id3demux ! id3mux" to support ID3 tag writing with GStreamer 0.10 in Rhythmbox.
Updating the gst-plugins-good to CVS, get the following crash attempting to change tags on an id3v2-only encoded file. http://gstreamer.freedesktop.org/media/incoming/V2.mp3 (gdb) bt
+ Trace 66039
By the way, looking at the code for id3mux in gst-plugins-ugly CVS, it still uses the libid3tag library "behind the scenes" (i.e. it links to the libid3tag.so), it just appears to be renamed. So it's still using the mad plugin for the actual writing I think. Running gst-inspect-0.10 verifies this (and the name of the plugin file is still libgstmad.so): $ gst-inspect-0.10 id3mux Factory Details: Long name: id3 muxer Class: Codec/Muxer/Audio Description: Add ID3 tagging information Author(s): Benjamin Otte <otte@gnome.org> Rank: none (0) Plugin Details: Name: mad Description: id3 tag manipulation and mp3 decoding based on the mad library Filename: /usr/lib/gstreamer-0.10/libgstmad.so Version: 0.10.1 License: GPL Source module: gst-plugins-ugly Binary package: gst-plugins-ugly FC rpm Origin URL: http://gstreamer.freedesktop.org/download/fedora.html
I can now do tag writing with RB, yay using attachment #58495 [details]! http://bugzilla.gnome.org/attachment.cgi?id=58495 It appears that with the latest gst-plugins-ugly package 0.10.2 (not CVS), the id3mux plugin now works although it only writes id3v2.4.0 tags too, which means they are not backwards-compatible with some other applications including easytag, tagtool and id3lib. Using the brand-new plugin tagid3v2mux (not yet in CVS) at bug #333501, rewriting also works. It only generates id3v2.4.0 tags. It got it working using the same patch, but replacing id3mux with tagid3v2mux throughout. 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. There is a very simple bug in rb-song-info.c which causes no tag writing to be done at all, the logic is inverted, currently it says: rb_song_info_sync_entries (RBSongInfo *dialog) { if (dialog->priv->editable) return; .... } clearly it should return if it is *not* editable, i.e.: if (!dialog->priv->editable)
Created attachment 61115 [details] [review] better 0.10 patch This fixes a few minor issues and some warnings with 0.10, and also adds version detection of id3mux. I've also reverted 0.8 tag editing to using id3tag, which works much better for me than id3demux ! id3mux, as the latter seems to often get wedged. If people can test this, I think it could be committed to cvs.
Works for me for gst 0.10.4 with (gst-plugins-ugly 0.10.2).
I've done more testing with 0.8, 0.10 with -ugly 0.10.2, and 0.10 with -ugly 0.10.1. It all seems to work fine, so I've committed the patch to cvs. Huzzah, we can finally close this bug after just over 8 months :)