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 306627 - Problem with ID3v1 tags when ripping via sound-juicer
Problem with ID3v1 tags when ripping via sound-juicer
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: Normal normal
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 157132 (view as bug list)
Depends on:
Reported: 2005-06-06 08:51 UTC by Kjartan Maraas
Modified: 2006-05-06 12:00 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10

last 10 kb of the file (9.77 KB, video/mpeg)
2005-06-06 08:51 UTC, Kjartan Maraas
Proposed patch (2.28 KB, patch)
2005-11-05 15:13 UTC, Shun-ichi TAHARA
none Details | Review

Description Kjartan Maraas 2005-06-06 08:51:08 UTC
Attaching output of tail -c 10000 file.mp3
Comment 1 Kjartan Maraas 2005-06-06 08:51:45 UTC
Created attachment 47305 [details]
last 10 kb of the file
Comment 2 Tim-Philipp Müller 2005-07-16 15:09:25 UTC
What's the problem exactly?

This looks like a valid ID3v1 tag at the end of the file to me (ID3v2 tags tend
to be at the beginning).

Or is it the fact that the string in the ID3v1 tag is UTF-8 encoded? I saw an
'ö'  (U+00F6) in there as 0xc3 0xb6.

Not sure what the proper way would be. ID3v1 tags usually are encoded in
ISO-8859-X, but what should we do? Just try random ones until it works? The
reader will never be able to figure out what encoding that tag is (because all
bytes are valid in ISO-8859-X). With UTF-8, the reader at least has a chance to
recognise it as such (with a reasonable probability IMHO).

Or am I misunderstanding the problem completely?

Comment 3 Luca Ognibene 2005-09-19 18:45:41 UTC
Comment 4 Tim-Philipp Müller 2005-09-20 08:02:09 UTC
I suppose what we could do is 

  if (strings_can_be_converted_to_iso_8859_1)
  else if (GST_ID3_TAG_ENCODING_environment_variable_is_set
    && strings_can_be_converted_to_that_encoding)

That would reflect the real-world situation a bit better no matter how much it
sucks. Most importantly, I doubt many tag readers will be able to handle utf8 in
ID3v1 tags.

In the end applications shouldn't really write ID3v1 tags, but should write
ID3v2 tags instead, so unicode isn't a problem.

Re-opening until we have decided what the Right Thing To Do here is.


Comment 5 Shun-ichi TAHARA 2005-11-05 15:13:50 UTC
Created attachment 54354 [details] [review]
Proposed patch

This patch will make the lame plugin handle id3 tags just symmetrically to id3
decoder of the mad plugin.
Comment 6 Alex Lancaster 2006-01-06 12:52:21 UTC
I am investigating a downstream bug in rhythmbox (bug #323658) which is quite likely be related to this sound-juicer issue.  

If somebody who is regularly testing gstreamer could test this patch together with rhythmbox and see if it solves the downstream tagging issues in rhythmbox mentioned in that bug that would be helpful.
Comment 7 Jan Schmidt 2006-01-17 16:21:31 UTC
Does this bug apply to 0.10 too? I'm guessing so.
Comment 8 Alex Lancaster 2006-01-17 19:32:34 UTC
(In reply to comment #7)
> Does this bug apply to 0.10 too? I'm guessing so.

Sound-juicer hasn't been ported to 0.10 yet, see bug #325234 

Comment 9 Tim-Philipp Müller 2006-01-17 20:00:34 UTC
There's a branch with the sound-juicer for GStreamer-0.10 port now, see
Comment 10 Andy Wingo 2006-01-27 14:30:03 UTC
*** Bug 157132 has been marked as a duplicate of this bug. ***
Comment 11 Andy Wingo 2006-01-27 14:31:21 UTC
Alex can you try this with the newer sound-juicer?
Comment 12 Alex Lancaster 2006-01-27 15:15:46 UTC
I (In reply to comment #11)
> Alex can you try this with the newer sound-juicer?

Just checked out sound-juicer from CVS.  But I need gnome-doc-utils 0.3.2.  FC-4 (which I run only has 0.2.0).  Can I work around this?  I don't want to have to upgrade my entire system to the bleeding edge GNOME, just the bits that I need and even then I install them in parallel. 

Comment 13 Alex Lancaster 2006-01-27 15:55:39 UTC
Oh, that's just the start of it then I need libnautilus-burn >=2.13.1 and gnome-media-profiles >= 2.11.91, so I don't think there's any chance I can test this on FC-4's GNOME.

Is there any backports planned? ;-)
Comment 14 Andy Wingo 2006-01-27 17:45:33 UTC
Heh, dunno. Perhaps Ross can hook us up with someone that can test :)
Comment 15 Tim-Philipp Müller 2006-05-06 12:00:32 UTC
Tag writing has been removed completely from the lame element in gst-plugins-ugly CVS, so the issue described here shouldn't exist any longer. Please re-open if this is not the case.

 2006-05-06  Tim-Philipp Müller  <tim at centricular dot net>

        * ext/lame/gstlame.c: (gst_lame_get_type),
        (gst_lame_release_memory), (gst_lame_init), (gst_lame_sink_event),
        (gst_lame_setup), (gst_lame_change_state):
        * ext/lame/gstlame.h:
          Remove tag writing from lame (which was completely broken
          anyway, #329184). Leaving GstTagSetter interface around for
          now, albeit non-functional. Should be removed completely
          in 0.11. Use the 'id3v2mux' plugin from -good for writing