Created attachment 47305 [details]
last 10 kb of the file

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?

Cheers
 -Tim

ping

I suppose what we could do is 

  if (strings_can_be_converted_to_iso_8859_1)
    convert_to_iso_8859_1;
  else if (GST_ID3_TAG_ENCODING_environment_variable_is_set
    && strings_can_be_converted_to_that_encoding)
    convert_to_that_encoding;
  else
    use_utf8;

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.

Cheers
 -Tim

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.

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.

Does this bug apply to 0.10 too? I'm guessing so.

(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 

There's a branch with the sound-juicer for GStreamer-0.10 port now, see

http://www.burtonini.com/blog//computers/sound-juicer/sj-gst10-2006-01-14-20-20

*** Bug 157132 has been marked as a duplicate of this bug. ***

Alex can you try this with the newer sound-juicer?

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. 

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? ;-)

Heh, dunno. Perhaps Ross can hook us up with someone that can test :)

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
          tags.