GNOME Bugzilla – Bug 362176
Chinese in some mp3 id3 tag does not show correctly.
Last modified: 2006-10-15 19:05:14 UTC
Please describe the problem: Hi, for some mp3 files with Chinese in id3 tags, rhythmobx show garbage character (or garbage "stuff") when displaying on the library or song filter. Those songs data show on iTunes, but not on rhythmbox. Steps to reproduce: Actual results: Garbage characters are displayed. Expected results: Correct Chinese character. Does this happen every time? Yes. Other information:
Created attachment 74690 [details] One of the songs with such problem. (part 1)
Created attachment 74691 [details] One of the songs with such problem. (part 2)
Created attachment 74692 [details] One of the songs with such problem. (part 3)
Created attachment 74693 [details] One of the songs with such problem. (part 4)
I read somewhere that this may be one of gstreamer's problem since it's using a id3 decoding library that follows standard (assuming it's iso8859 or unicode), while, some id3 tags of Chinese songs may be recorded in some elder encoding such as Big5. I'm not sure about the correctness of this, but the fact is that, I did modify some of these songs in iTunes (suppose to be unicode?), but those songs data still screws in rhythmbox. Also, I want to note that in many Chinese songs, there are two tags, id3v1 and id3v2, having data in different encoding (gb and big5). I also wonder if that may be part of the problem. Anyway, this is just some extra information I know of. Hope this helps, and hope you guys can help.
I can't extract those files. You don't need the entire file to check the ID3 tags, just attach the first 50000 bytes (say), using: head --bytes=50000 your-file.mp3
OK, I managed to extract them by concatenating them and then using 7za to extract the. Here's what I get when I look at the tags using the following version of gstreamer on FC-5: $ rpm -q gstreamer gstreamer-plugins-base gstreamer-plugins-good gstreamer-0.10.10-0.gst.1.5 gstreamer-plugins-base-0.10.10-0.gst.1.5 gstreamer-plugins-good-0.10.4-0.gst.1.5 It looks like you have both APE tags and ID3 tags in that file. You should probably be using one or the other, but not both. $ gst-launch playbin -t uri=file:///tmp/1-03\ 失常.mp3 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: ¥¢±` artist: ©x®¦®R album: ¥¢±` track count: 11 track number: 3 disc count: 2 disc number: 1 genre: 流行音樂 FOUND TAG : found by element "apedemux0". genre: ゼ track number: 3 title: ア盽 album: ア盽 artist: ﹛甊 comment: forum.musichk.org FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000
When I import this file in rhythmbox, I only see the APE tags, not the ID3 ones. I'm not sure which ones are the "correct" ones. I have seen this before, gstreamer/rhythmbox will prefer APE tags to ID3 ones when reading or displaying tags, but rhythmbox can only modify ID3 tags.
Exfalso (part of quodlibet) has a plugin that will convert APEv2 tags to ID3v2 then it will delete the APE tags, see: http://www.sacredchao.net/quodlibet/
Rhythmbox (well, GStreamer) can handle files whose ID3 tags are in other characters set, provided that the tag are spec-compliant by setting the header saying what the character set use is. Unfortunately many programs that write tags do so using the locale's character set and don't set the header. There isn't really any way Rhythmbox can deal with this that doesn't break some spec-conforming files.
(In reply to comment #10) > There isn't really any way Rhythmbox can deal with this that doesn't break some > spec-conforming files. GStreamer id3 tag reader uses an env variable (I can't remember its name atm :-/) that you can set to force a specific encoding to be used on broken mp3 files. I wouldn't recommend using it but fixing the files instead
Thanks. I'll try to use that program to remove those APE tags. Since it's not a bug... I guess I'll have to close it. Thanks, everyone.