这两个问题啥时能解决呢？希望能尽快解决，期待中.....................

APE是Xine引擎的一个功能缺失，乱码问题倒不如说是标签问题。具体说明引用自己以前的一篇文段：

误区

这条问题是奴家经常在用户中看到的抱怨，这里不论产生这种问题究竟谁对谁错，只是描述真相，澄清也许还在流传中的的认识偏差。奴家希望您看完这些以后，再判断造成自己不便的责任究竟属于哪一方，以及选择一个最适合自己的解决途径。

Amarok中文支持：有关 Amarok的中文乱码也许是国内用户社群中反映最普遍的一个问题，事实上自从Linux桌面应用在国内用户中开始传播以来这个问题就从来没有终止过，也几乎没有什么音频播放器在这个话题中心上能获得豁免。如果我们把问题进一步探究，这里所说的播放器中文支持一般都是特别针对MP3这种音乐格式的标签而言，许多播放器都会在处理这些标签信息时显示乱码，既然如此，奴家想先扼要说明一下MP3音乐标签的演变过程。

这段话是在写完后补上的，如果您觉得下文大量的前因后果描述对您没有价值，奴家在此直接给出结论的概括，然后您可以跳过这一大篇了──Amarok之所以在1.4以后版本对MP3的中文支持出现了问题，是因为那些MP3的制作不符合标准而Amarok却严格符合导致的，一个解决办法是用某些工具将那些MP3的标签编码全部转换成Unicode，但对于其它操作系统平台它不是没有副作用的。

曾公开推行过的MP3标签的标准有很多，从ID3v1到ID3v2，ID3v2中又有到ID3v2 v2.4为止的四个版本，ID3v1和ID3v2两种标签可以在一个文件中同时存在且被识别，但ID3v2标签对于一个MP3文件来说则是唯一的。 ID3v1标签很古老，允许的信息量也少，附在MP3文件尾最后128个字节上，它只支持ISO-8859-1编码集，这是一个西欧语言编码，换句话说它在设计时丝毫不考虑对CJK，即中日韩字符的支持。

后来的ID3v2标准扩展了允许在标签中存放的信息条目，并开始支持Unicode以满足国际化的需要，现在网络上流传的MP3文件如果采用了ID3v2 标签，也大多是以ID3v2 v2.3标准为大致的遵循依据，它允许的合法标签信息存储编码包括ISO-8859-1和UTF16-LE WITH BOM。ID3v2 v2.4是比ID3v2 v2.3更新的标准，UTF-8直到这个版本中才成为了合法的标签信息编码，它弥补了ID3v2v2.3的一些缺憾，但它在实际中有一个问题，那就是缺少应用软件的支持，比起ID3v2 v2.3，ID3v2 v2.4始终没有普及开来。

现在您已经知道了MP3所使用的ID3标签发展过程，那么应该已经注意到ID3v1标签在严格角度上说的确是不支持中文，但为什么那么多年来很多用户在 Windows上没有遇到这个问题，同时许多明明拥有ID3v2标签的大量MP3音乐还是在Linux下不能正常显示标签现在依然是疑问。

答案是，这是因为Windows下大多数播放器都不是Unicode程序，也不遵循实际上Linux下大多数播放器与标签处理机制所严格遵循的标准。奴家没有判断这是对是错，但它显然会让用户改变操作系统时可能受到错误的意识导向。

先说ID3v1标签，虽然它在原则上并不支持中文。但有一个简单的比方可以说明问题──电线里通常包的都是铜丝，其实就算包进去铁丝，它也能用。虽然在 “理论”上ID3v1只接受ISO-8859-1编码，但这不能阻止别人往那最后128位字节里填充任何他所希望的数据，接下来，只要一个并不严格遵循标准的播放器能够以其特有的方案来读取这些数据，那么用户就可以无视标准本身的局限在MP3文件尾写入他所能够阅读的任何信息，包括中文。

在Windows下，很多播放器采取按照当前系统的默认区域设定来读取和写入标签，对简体中文用户来说，这个默认区域一般被映射为GBK，因此这些软件的用户就可以读到它们可辨认的GBK编码字符。但假若严格遵循标准的话，用户能看到的只能是几串乱码。著名的Winamp也许是这类软件中的一个代表。

ID3v1标签标准很落后，不仅是CJK语系用户，以法语、德语、俄语等语言为母语的用户也同样会因为它的限制遭受困扰，就奴家而观第三方应用程序采取无视ID3v1标准的开发策略无可厚非。但ID3v2标签的状况却不是这样，以ID3v2 v2.4为例，它允许Unicode，在标签段中以一个先置的描述字节位来指定之后具体内容的存取编码（从00到03分别代表ISO-8859-1、 UTF-16 WITH BOM、UTF-16 BE WITHOUT BOM、UTF-8，这个描述字节必须正确），所以尽管仍然存在多种存取时的字符编码方式的区别（值得分清的是，Unicode本身只是包含一大组字符的编码表，在计算机内进行通信和输入/输出时还需要定义一种将表意字符编码为可供计算机识别的二进制字节的规范，UTF-8、UTF-16等都是这样的规范），各种语言的用户都得到了关照，可惜从ID3v1时代，甚至是从整个Windows程序发展中流传下的开发习惯已经根深蒂固，绝大多数媒体播放器仍然照以往那样按当前系统的默认区域决定存取标签编码，在简体中文地区就是GBK，在繁体中文地区就是Big5，在日语国家就是Shift-JIS，全世界的 MP3几乎都是如此……除了英语国家似乎不受波及，因为ASCII字符在各种编码规范里几乎都是兼容的。但其它地方来自一个国家的歌曲在另一个国家的用户的播放器里也许就不能识别标签，它的作者、专辑、注释等信息全会是一团乱码，相信国内的用户以前也见过这样的例子，不过说不定已习惯了。虽然同时期里产自非Windows平台上的MP3专辑许多是以Unicode字符保存标签的，意欲保证歌曲标签能够在国际范围内通用，但其绝对数量太少了。

无论各地有什么约定俗成的习惯，Amarok采用的标签读写库TagLib是ID3标准的严格执行者，它没有转码机制，只会按照相应的标准版本所允许的方式去读取和写入标签，即按照描述字节位的定义来确定输入/输出编码。然而，因为Unicode国际标准是和中国的GB系列国家标准是不兼容的，所以大量本地化的MP3标签往往不能被“原文”显示。在Amarok 1.2及更早时它的国际化设计尚不完善略过不提，在Amarok 1.3时虽然在表面上有了很好的国际化支持，包括对中文的支持，但实际上它对本地化标签编码的流行现状作了一个妥协，Amarok提供了一个选项可以将 MP3的ID3标签不以TagLib所给出的标准方式解码，而改以GB18030这样的中国国标码替换解码并显示，实质的问题被掩盖了过去。我们通常都认为Amarok 1.3可以很好地支持中文，但在这背后这个hack性质的转码功能却以忽略ID3v2、Bug引入以及提高程序的复杂性为代价，它也许是一个对我们来说 “好”的解决方案，但对开发者来说却不是一个“正确”的，甚至是根本不该由这个软件来处理的事情，因为这两个人群面对的是不一样的问题和解决问题的思路，而且如果没有一个彻底的办法来根除它，这必然将一直持续下去。

在此奴家插谈一下别的同类软件是如何面对Unicode和本地编码不兼容的问题的。在Windows上，大部分的老字号播放器都已经支持了ID3v2 v2.3 Unicode标签的读取，不过以Unicode写入一般仍然不是这些播放器的首选，这意味着本地编码的MP3文件仍然在不断地被生产出来。另一方面，支持ID3v2 v2.4读的播放器尚不多，Windows Media Player只能支持到v2.3，RealPlayer可读v2.4但仍以 ID3v2 v2.3写入，Foobar则支持读写。在GNU/Linux上，几乎所有现在的主流播放器都支持以Unicode形式对 ID3v2 v2.3的读，v2.4的问题也不大，不过以TagLib为标签库的软件才能正确地支持ID3v2 v2.4的读写。在处理编码兼容问题时的一个典型折中例子是，所有以GStreamer为媒体引擎的软件都可参照一个可任意指定的环境变量GST_ID3_TAG_ENCODING来统一标签的读写编码。当然，如果您的收藏库里混杂有不同的标签编码，乱码依然是难免的。在媒体设备上，情况较为复杂，对编码支持最完善的如iPod，可以正确处理ID3v2 v2.4，但众所周知MP3播放器在市场上五花八门，相当一部分杂牌产品是不支持Unicode或ID3v2 v2.4的。这就是说假如您希望将自己的标准ID3v2 v2.4歌曲传送到自己的MP3播放器，很可能面临不便。

在Amarok 1.4分支的开发过程中，MP3转码这个妥协的方案遭到了很多诟病，在经过若干次开发者会议的讨论后，他们最终决定将这个功能从新版中清理出去。在Amarok 1.4.0beta1的更新日志中，有这样一条：Recoding mp3 tags has been removed due to many unjustified complications.。这里的用语是很体面，然而在SVN上当时的注解可就没有这样的金属质感，其原话是：**** A, removed all traces of recoding stuff, as discussed numerous times on IRC, private cocktail parties and The All Thing. God bless your tags.。多么畅快淋漓的样子，这里有个相关链接。

在这个消息被确认后，国内的相关论坛上有人这样感悟道：KDE上唯一可用的amaroK即将死去。（注：特指音频播放器领域，另一个类似的KDE软件Juk从来都是没有转码功能的）

到此为止，对Amarok的用户来说维系所谓的标准与所谓的用户习惯之间最后一道平衡杆正被撤去，倾向不同的用户开始产生分野，更偏向维持习惯的用户开始去寻找别的播放器，更偏向维护标准的用户则去依循Amarok的期望修正自己的MP3曲库，当然还有少数程序员试图将Amarok 1.3的转码方案以非官方的形式移植到1.4上。如果您作为读者已经看到了这里，现在应该已经了解了奴家要传达的实情，并不是像很多人所说的那样Amarok对中文支持有缺陷，那是一种模糊的误导。问题的根源其实是因为粗陋的ID3v1，促使大量Windows程序与MP3 制作者不在意标准只考虑本地化所积累下的历史遗留现象。Amarok的做法在标准的角度上是正确的，标准的ID3v2完全可以正常支持中文，只是它和旧的事实标准不兼容，这也许对很多用户来说现在还不是最好的。现在，您可以选择支持用户习惯也可以选择支持标准或是选择支持其它什么办法，但这个判断必须建立在正确的前提上，这正是奴家说了那么多希求达到的目的。

以下是奴家所能罗列出的若干种解决办法：

1、换别的音频播放器，如Audacious、Rhythmbox、Banshee，有不必转换编码的方案，这是支持用户习惯的做法。

2、用专门工具转换标签编码为Unicode，ID3v2任一版本皆可，带描述字节位的UTF-16或UTF-8皆可，但ID3v2 v2.4不被某些Windows播放器和媒体设备支持。这是支持标准的做法。

3、冷落MP3，改用别的音频格式，有损压缩格式如Ogg Vorbis、WMA，无损压缩格式如FLAC，它们有自己的标签格式，罕有编码的历史遗留问题。这是一种中立。

4、试用或开发基于Amarok的另一种解决方案，如自己打补丁加入转码功能，您不必换播放器也不必换编码。但这种做法潜藏Bug的可能性很大。这是另一种中立。

5、改写TagLib，让它具有标签编码的自动探测功能，或是添加可让开发者自行实现的重载函数。但编码探测是很难做到100%准确的，而且数据越少，成功率越低。这也是一种中立。

奴家采取的是第二种做法，不过动机并不是对标准的偏爱，只是它相对最为省事。反正自己不会在Windows上听音乐，也不会去购买杂牌的便携MP3播放器。

很详细了

用 amarok2，然后设置 phonon 的后端为 gstreamer/mplayer 就可以放 ape 了~~