今天装了experimental中的amarok1.4

mingyou

距离AMAROK1.4的发布没几天，我想尝尝鲜，就装了experimental中的Beta3版。装了以后才发现这个版本也就是与ipod的交流改进了，其它的都做了简化。
我前几天上irc，看到有很多人在说charset的事，今天装了amarok1.4后才发现这里的charset转化工具被删掉了。现在好多歌名显示出来都是乱码。

pluskid

因为 字符集 探测那个东西造成 amarok 的很多 bug，所以作者把他删掉了。

mingyou

现在在amarok中改掉的歌名在beep中显示出来还是乱码啊.
这到底是怎么会事?
为什么不能统一呢.

pluskid

Post by mingyou
现在在amarok中改掉的歌名在beep中显示出来还是乱码啊.
这到底是怎么会事?
为什么不能统一呢.

恩？我以前也是这样的，现在好像可以了呀。都用UTF－8的。

mingyou

你再试试，我这里beep下改的名字，amarok显示出来是正常的，而amarok改的，在beep下则是乱码。

four

Post by mingyou
你再试试，我这里beep下改的名字，amarok显示出来是正常的，而amarok改的，在beep下则是乱码。

beep的tag支持很buggy的吧。

mingyou

刚才是错觉，其实现在是这样的：beep下改的名字，amarok显示出来是乱码的，而amarok改的，在beep下也同样是乱码。

seamonkey

bmp在处理ID3v2方面完全是一笔糊涂账。

amaroK用taglib读写ID3，taglib能读取所有版本的ID3，但只能写入ID3v2.4。

ID3现行有这些版本：

v1(.1),最早的，依附于mp3的末尾，容纳的信息量较小。根据标准，只接纳ISO-8859-1编码，但绝大多数程序用系统的locale，或者说是代码页写入ID3v1。


v2.x, 为了弥补v1的不足而诞生。增大了可容纳的信息量，支持unicode。
v2.2, 基本过时了。
v2.3, 位于mp3的头部，好处是有利于流媒体，尽早获取文件的信息，缺点是tag的长度有改变后，整个文件要重写。支持的编码有ISO-8859-1, UTF-16LE with BOM。UTF-16BE with BOM大概也是可以的，但有些程序WMP不能读取它的信息。
v2.3_不支持_UTF-8和UTF-16BE without BOM，所以一定不要把ID3v2.3转码为UTF-8，这是要强调的。
v2.4, 与v2.3相比，改进在于既可以写在文件头部，又可一依附于文件末尾。增加了UTF-16BE with BOM和UTF-8作为合法的编码。

Linux下处理ID3的库主要有taglib和id3lib，大多数KDE程序用taglib，taglib能写入标准的UTF-8编码的ID3v2.4。  id3lib则不能读写ID3v2.4，所以造成了兼容的问题。easytag用id3lib，(现在也可以用taglib，大概还在试验阶段），最近的easytag纠正了过去的错误，写入标准的ID3v2.3。但是id3lib方面有些bug，导致写入的unicode出现错误，easytag开发者给出了patch，但大多数发行版携带的id3lib还没有吸纳这个patch，所以easytag目前还不太可用，除非自己给id3lib打补丁。

Windows方面，一些经典的mp3程序如winamp是彻头彻尾的ansi程序，不知unicode为何物，按系统代码页写入ID3，导致了现在的兼容困境。即使是unicode程序如WMP和RealPlayer也是只读unicode，还是按系统代码页写入tag。 foobar2000完全支持读写unicode，还有一些好的免费的遵循标准的ID3编辑程序如mp3tag等也值得推荐。

个人的看法，还是尽量用标准的ID3v2.3，兼容性最好。v2.4虽然有优点，但普及程度稍差。

像winamp这样不支持unicode的程序就割爱吧。现在的问题是id3lib的bug不彻底解决，就没有一个好用的Linux下的ID3v2.3的编辑软件。还有一个要考虑的是有些mp3硬件播放器的支持如何。

现在还有新兴的替代ID3的标签如APEv2，但在Linux下支持程度较差。

seamonkey

补充一点，amaroK的那个转码选项是以忽略ID3v2为代价的。

Freesnake

什么乱七八糟的ID3
估计这就是一开始开发时没有进行详细的规划的代价……后面越补越乱，最后只好推倒重来……代价那个大啊……