[gstreamer-bugs] [Bug 342364] [id3demux] Chinese id3 tags sometimes read incorrectly

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=342364
 GStreamer | gst-plugins-good | Ver: 0.10.3





------- Comment #6 from Tim-Philipp Müller  2006-05-20 14:29 UTC -------
> And according to some notes I was reading in Easytag (the app I use to
> edit tags), it says that id3v1 tags are always saved as single-byte.
> So doesn't that mean basically the id3v1 tags will never fully
> support Chinese (which requires double-byte)? 

That is correct. ID3v1 was only really meant to hold Western European strings
(ISO-8859-1/ASCII) and nothing else. How apps/readers/writers deal with that
problem differs. It's pretty much a mess and pretty much unsolvable (GStreamer
falls back on the encoding specified in GST_ID3_TAG_ENCODING for ID3v1 tags if
it's not valid UTF-8, this is a hack though because there are so many ID3v1
tags with other charsets out there)

In short: just don't use ID3v1 tags.



> Yeah, several command line id3 tools read the tag as Unicode (id3v2 being 
> one). Playing around with this has also made me think that Gstreamer apps 
> (like Rhythmbox and Nautilis) are using the id3v1 tag for display.  

Gstreamer shouldn't prefer the ID3v1 tag, at least not by default. By default
the 'id3demux' element should use the tags from the ID3v2 tag if it finds both
an ID3v2 tag and an ID3v1 tag. If it doesn't do that, that's a bug :)

However, GStreamer in fact does read the ID3v2 "wrongly" as well (where
"wrongly = correctly according to spec"), you can see that from the debug log
if you use gst-launch like this:

 $ GST_DEBUG=id3demux:5 ....

(also, I'm only working with the beginning of the file, which doesn't have the
ID3v1 tag).

Needs more looking into ...


-- 
Configure bugmail: http://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.