[gstreamer-bugs] [Bug 615813] New: [id3v2mux] Transcoding from flac to mp3, UTF-8 tags get mangled

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=615813
  GStreamer | gst-plugins-good | 0.10.21

           Summary: [id3v2mux] Transcoding from flac to mp3, UTF-8 tags
                    get mangled
    Classification: Desktop
           Product: GStreamer
           Version: 0.10.21
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: cwixon at usa.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


I'm using gstreamer to transcode flac files to mp3 while keeping the metadata,
using the following pipeline:

gst-launch filesrc location="foo.flac" ! decodebin ! audioconvert ! \
lamemp3enc target=quality quality=4 encoding-engine-quality=2 ! xingmux !
id3v2mux ! \
filesink location="bar.mp3"

It looks like UTF-8 encoded tags in the flac files are being treated as 8-bit
ISO-8859-1 tags, so each byte of any multi-byte UTF-8 characters in the
original tag will mistakenly be re-encoded into UTF-8, resulting in garbage.

For example, I have foo.flac containing the following metadata (according to
metaflac --list):

comment[1]: producer=Peter Tägtgren

That's in UTF-8, so the "ä" character is encoded as two bytes, C3 A4.

After the pipeline, I get an bar.mp3 containing this (according to id3demux !
fakesink -t):

producer[xxx]=Peter Tägtgren

That's also in UTF-8, so the original single "ä" character is now four hideous
bytes, C3 83 C2 A4.

Should (or can) id3v2mux identify what encoding is used by incoming metadata? 
If not, is there a manual workaround?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.