Analysis and solution of MP3 label garbled problem under Linux system

Believe that a lot of friends in linux play mp3, no matter what MP3 player, more or less will encounter the problem of MP3 tag garbled. I usually encounter mp3 tag display garbled when all are using ex falso (Quod Libet from a mp3 tag editor) to edit the label, so that my player Quod Libet can normally identify MP3 tags. When there are fewer songs to convert, there is nothing wrong with doing so, but many friends who have just switched from Windows to Linux have a big head, and many of the MP3 tags that appear normal under windows are all messed up under Linux.

Let's take a look at some of the MP3 labels and coding concepts to solve this problem, we will be more clear.

MP3 label types and coding, now mainly exist in these several standards, ID3V1, ID3v2 2.3, ID3v2 2.4, APEv2. They are supported separately by the encoding

ID3v1: only support iso--8859-1

ID3v2 2.3:iso--8859-1, UTF-16

ID3v2 2.4:iso--8859-1, UTF-16, UTF-8

Apev2:utf-8

As we can see from the list above, the label type and coding of MP3 are various, and there is no specification whatsoever. ID3v1 only support iso-8859-1 this kind of encoding, it does not support Chinese, so in general, only the MP3 of ID3V1 tags are basically garbled on Linux, and the ID3v2 2.3 support format increased UTF-16 until ID3v2 Version 2.4 only began to support UTF-8, but ID3v2 's two version standard does not have a unified label content encoding. Here is worth mentioning is APEv2, it has the best extensibility, it unifies the coding format as UTF-8, so long as the player that supports APEv2 reads to play MP3 with APEV2 label will not have garbled problem. Unfortunately, now in the domestic Web site download mp3 Basically have no APEv2 tags, and Linux also does not have a few players to support the APEV2 tag read. (Rhythmbox in Gnome currently supports APEV2 tag reads, including Quod Libet.) )

A MP3 label can contain multiple types, and when a MP3 contains more than two of the 4 types of ID3v1, ID3v2 2.3, ID3v2 2.4, and APEV2, the reading order of the player to the MP3 label is generally up and down, APEv2 ( If the player supports this encoded read)---id3v2---id3v1. So there are times when the same file Rhythmbox the display label (read the APEV2 tag), the other player is not normal (read the ID3 tag).

And then we'll talk about why all the MP3 players have garbled problems in Linux, because these MP3 players rely on the Libid3tag library in the system to read the tag content exactly as ID3. It does not matter what standard tags MP3 (id3v1, ID3v2, APEv2), so long as the contents of the MP3 label are stored in Unicode encoding, the display is certainly normal (ID3v1 's iso-8859-1 strictly does not support Chinese, But it does not mean that it cannot store Chinese. If encountered is to GBK, GB18030, BIG5 and other encoded Chinese content, it will still take it as a iso-8859-1 to read, garbled became inevitable.

Said so much, now the problem becomes simple, it seems that we only need to use the MP3 tag in the GBK, GB18030, BIG5 and other encoded storage of the Chinese content to the Unicode encoding, then basically all Linux players can normally identify the MP3 tag.

About MP3 code conversion, here is a tool----mutagen, if you install Quod Libet, then this package has been installed up. If not, you can do the following command.

sudo apt-get install Python-mutagen

How tools are used

MID3ICONV-E GBK *.mp3 #Convert mp3 files in current directory





Find. -Iname "* .mp3" -execdir mid3iconv-e GBK {} \; #Convert all mp3 files in the current directory (including subdirectories)