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 124504 - mp3 id3v1 isn't using local encoding
mp3 id3v1 isn't using local encoding
Status: VERIFIED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.0
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-10-13 16:31 UTC by Frederic Crozat
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Frederic Crozat 2003-10-13 16:31:31 UTC
Using sound-juicer to rip an CD containing tracks with latin1 characters
(in my case, track was named "Au-delà des nuages", I discovered gst is
using UTF-8 title (and probably other infos) when writing ID3v1 metadata
for MP3 file.

This is incorrect as most MP3 players/taggers expects those ID3v1 info to
be in local encoding (or ISO8859-1 : it was never specified as showned in
http://www.id3.org/id3v1.html and was only correctly specified with ID3V2)
Comment 1 alexander.winston 2003-12-23 19:47:42 UTC
I'm fairly certain that all ID3v1 data should be in ISO 8859-1.
Comment 2 Thomas Vander Stichele 2004-02-24 16:15:49 UTC
who is right here ?
give us some proof ! :)
Comment 3 alexander.winston 2004-02-24 18:59:51 UTC
Sooooo, I talked to a few people (one of whom was the author of
foobar2000, an audio player with great Unicode support) and it they
agreed that ID3v1 should use the local encoding (apparently many
applications assume this). I think that this bug is valid.
Comment 4 David Schleef 2004-03-18 20:31:20 UTC
I'm pretty sure this is still a problem in 0.8.0, so I'm updating the
version.
Comment 5 Benjamin Otte (Company) 2004-04-22 00:36:23 UTC
Uhm, there is no "local encoding" when you downloaded files from the net. Since
ID3v1 does not specify the encoding to use, people have files encoded in all
sorts of encodings. You can't just rely that it's the local encoding.
The approach taken by GStreamer when reading tags has been to try in that order:
- UTF-8
- locale
- ISO-8859-1
And use the first of these that works.

Tag writing when encoding is done by the lame library and I have absolutely no
clue how we should handle it. Since it's unspecified and UTF-8 is the only
mapping that allows 1:1 conversion, I'd prefer to use that, but if that causes
too many other players to fail we should use a different approach.
We need to keep in mind that it needs to work in non-Western countries, too.

Local encoding is most likely not an option, because Linux user are switching
more and more to using UTF-8 as their locale. Hardcoding 8859-1 is bad for the
other 5 billion people in the world.
Any good solution out there?
Comment 6 Christian Fredrik Kalager Schaller 2004-11-25 18:05:34 UTC
Closing this bug. Reopen Frederic if you think there is something more we could do.