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 507074 - Desktop-wide setting for preferred tag encoding
Desktop-wide setting for preferred tag encoding
Status: RESOLVED OBSOLETE
Product: gnome-tweak-tool
Classification: Applications
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: GNOME Tweak Tool maintainer(s)
GNOME Tweak Tool maintainer(s)
plumbing
Depends on:
Blocks:
 
 
Reported: 2008-01-03 17:43 UTC by Roman Polach
Modified: 2018-01-24 15:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Roman Polach 2008-01-03 17:43:10 UTC
Please describe the problem:
Totem/gstreamer displays ID3 tags info when playing MP3 files...
But it does not autodetect correct character set of those ID3 tags if it is
cp1250 nor it have any support to let user choose character set in Options dialog.



Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
sample mp3 where the problem exists:
http://launchpadlibrarian.net/10535961/vidis_vidis.mp3

I can check with audacious that id3 tag is correct there: See this:

-- audacious --
Title: Vidíš, vidíš
Artist: Bratři Ebenové
Album: Já na tom dělám

-- totem --
Title: Vidí, vidí
Artist: Bratøi Ebenové
Album: Já na tom dìlám

screenshot of totem:
http://launchpadlibrarian.net/10536027/screenshot-totem.png

screenshot of audacious:
http://launchpadlibrarian.net/10536104/screenshot-audacious.png

Note: This problem is not the one fixed in #451707
Comment 1 Tim-Philipp Müller 2008-01-03 18:29:36 UTC
It is impossible to correctly detect the encoding of ID3v1 tags. audacious probably assumes that encoding == current locale, so it probably just gets lucky here.

This works fine for me:

 $ GST_TAG_ENCODING=CP1250 gst-launch-0.10 -t playbin uri=file:///home/tpm/samples/507074-vidis_vidis_cp1250_tags.mp3 

FOUND TAG      : found by element "id3demux0".
           title: Vidíš, vidíš
          artist: Bratři Ebenové
           album: Já na tom dělám
    track number: 0

There isn't really anything better we can do here (that works in the general case), so what you really need/want is either an option in the totem preferences dialog to set the preferred encoding for these things, or even a GNOME desktop wide setting for this (since you'll have the same issue in rhythmbox, exaile, banshee, tracker/beagle etc.).

Not sure where this belongs, so moving over to the gnome-control-center folks for now, maybe they've got some more ideas.

Note: this is relevant to a whole bunch of formats/inputs, not only ID3v1 tags.
Comment 2 Roman Polach 2008-01-03 20:55:42 UTC
An totem option for this sounds good.
E.g. audacious allows to set encoding manually too.
Comment 3 Bastien Nocera 2008-01-15 23:53:40 UTC
I don't really think this has its place in the control-center, but we could move that to using the same setting as the subtitle encoding in Totem.

Then I'd just need to make sure that totem-video-indexer uses that GConf setting when getting tags. Is there a programmatic way to set GST_TAG_ENCODING, Tim?

I'm afraid it could break proper UTF-8 tags though...
Comment 4 Tim-Philipp Müller 2008-01-16 09:20:30 UTC
> I don't really think this has its place in the control-center, but we could
> move that to using the same setting as the subtitle encoding in Totem.

Fine with me, it just seemed to me that if there's a setting that's shared between a whole bunch of gnome applications, it makes sense to put it in a central location.


> Then I'd just need to make sure that totem-video-indexer uses that GConf
> setting when getting tags. Is there a programmatic way to set GST_TAG_ENCODING,
> Tim?

Only g_setenv().


> I'm afraid it could break proper UTF-8 tags though...

It shouldn't, we usually just short-circuit: if it passes g_utf8_validate(), we just assume it's UTF-8 and only try the user-specified encodings if the input is not UTF-8.

Comment 5 Jeremy Bicha 2017-06-07 00:18:28 UTC
Is this still an issue?

Can't we just use UTF-8?
Comment 6 Roman Polach 2017-06-07 06:57:36 UTC
Well, it is and it will be an issue until
all mp3 around the world magically change
its tag encoding to utf8. ;)
Comment 7 GNOME Infrastructure Team 2018-01-24 15:02:58 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-tweaks/issues/10.