Bug 111822 - id3 tags should not be encoded in utf-8
Summary: id3 tags should not be encoded in utf-8
Status: CONFIRMED
Alias: None
Product: kaudiocreator
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Gerd Fleischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-31 16:14 UTC by Ruben Jenster
Modified: 2021-03-09 03:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ruben Jenster 2005-08-31 16:14:08 UTC
Version:            (using KDE KDE 3.4.2)
Installed from:    Gentoo Packages

Hi,

I've an UTF-8 encoded system. Unfortunately kaudiocreator seems to use the system locale for ID3 tag encoding (UTF-8 in my case). The Problem is that most software and hardware players can't handle UTF-8 encoded ID3 tags properly.
ID3 tags should be in iso8859-1. 

Even if it easy to change the ID3 tag encoding with easytag it would be better if kaudiocreator would use the right ID3 tag encoding (iso8859-1) even if the system is UTF-8.


Regards 

Ruben
Comment 1 Tristan Miller 2005-10-23 14:25:43 UTC
I don't know what the ID3 standard says about character encoding, but I like my tags to be in UTF-8.  I have music in several different languages, so it's nice to have a single unifying character set.

If the kaudiocreator developers implement this request, please make it a user-configurable setting.
Comment 2 Nigel Stewart 2006-09-21 05:52:57 UTC
I agree there should be an option, and it should be independent
of the system locale.  utf-8 as a default, latin1 as an option.
Comment 3 shattered 2007-02-06 23:52:23 UTC
Only ID3v1 tags *should* be in iso8859-1 (although this rule is often broken and locale-dependent encoding is used).  ID3v2 tags permit Unicode and UTF-8.
Comment 4 Eduardo Habkost 2007-06-15 14:41:12 UTC
I don't know if ID3v1 or ID3v2 tags are being used. My problem here is that Amarok is not reading the tags written by kaudiocreator as UTF-8, showing garbage when there are non-ascii characters, as if it was expecting latin1 contents on the tags, instead.

Example: when I set the title to "Construção" on kaudiocreator, Amarok shows "Construção".

I don't know if it is a kaudiocreator, lame or amarok bug, on my case.

Software versions: Amarok 1.4.5, Kaudiocreator 1.13, KDE 3.5.6-0.3.fc6 Fedora-Core, LAME 32bits version 3.97
Comment 5 Rainer Lay 2007-07-10 10:57:10 UTC
Instead of hard coding the encoding, I suggest a setting in the preferences, so the users can set their desired encodings themself.
Comment 6 Alan Braslau 2007-07-21 19:33:36 UTC
I rip tracks both to flac and to mp3 using kaudiocreator. Amarok reads the flac tags just fine, but the mp3 tags have the wrong character encoding. Of course, my locale is utf-8.
Comment 7 shattered 2007-07-27 14:36:01 UTC
There are two problems.

* kaudiocreator converts tag to locale encoding
* and then calls LAME, which doesn't support id3v2 properly.

So even if you add '--id3v2-only' to LAME's command line options, you still end up with broken tags.  This is especially visible if tags were in Russian.
Comment 8 shattered 2007-07-27 14:38:20 UTC
*** This bug has been confirmed by popular vote. ***
Comment 9 shattered 2007-07-29 15:39:13 UTC
There's an experimental patch at http://sourceforge.net/tracker/index.php?func=detail&aid=1192706&group_id=290&atid=300290 which fixes LAME's id3v2 support.  It's not included in 3.97 (latest release).
Comment 10 shattered 2008-12-06 17:00:21 UTC
Quoting aforementioned sf.net tracker entry:

"In LAME 3.98 stable there is some experimental code you may use. In case
your system has libiconv installed, define the preprocessor symbol
HAVE_ICONV when building LAME frontend executable. Now you can use
'--uTitle abc' '--uAlbum def', '--uArtist ghi', '--uGenre jkl' and
'--uComment mno' to store ID3v2 tags in UCS2 encoding."
Comment 11 Justin Zobel 2021-03-09 03:51:40 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.