QQ登录

只需一步,快速开始

 找回密码
 注册

QQ登录

只需一步,快速开始

楼主: realwhz

升级到rhythmbox0.9.3后编码出了问题

[复制链接]
发表于 2006-6-19 11:57:51 | 显示全部楼层
[quote:ba2ce1d6fd="xLoneStar"]看起来 gstreamer 0.10 再度回到了老路上。据联系过他们的人称,他们明确拒绝支持 ID3v2 里非 UTF-8 的编码。 [/quote]

[quote:ba2ce1d6fd="yangh"]我这没问题。只是我用的 cvs 版的补丁。 [/quote]

cvs 的补丁?

cvs 的 gstreamer 0.10 支持非 UTF-8 的编码吗?
回复

使用道具 举报

发表于 2006-6-19 23:35:04 | 显示全部楼层
[quote:042be1a9f1="xLoneStar"][quote:042be1a9f1="hzhr"]UTF-8 locale 下使用还是有问题,没有将 GBK 转成 UTF-8 输出。[/quote]
请阅读一下这个补丁,设置环境变量 GST_ID3_TAG_ENCODING=gbk[/quote]
已经设置了。Gstreamer版本0.10.8。在打你的补丁之前,GBK locale下,还是有很多mp3文件的tag识别不对;打了补丁之后,大部分文件的tag识别对了。但在UTF-8 locale下,没有一个是对的。
回复

使用道具 举报

发表于 2006-6-21 00:13:38 | 显示全部楼层
在打好补丁、设好环境变量后,使用这个命令查看效果:

$ gst-launch -t filesrc location=变的坚强.MP3 ! decodebin ! audio/x-raw-int ! fakesink

应该会是只有在支持 UTF-8 的终端中才能看见中文。抱歉我使用全 UTF-8 环境,所以没有在 GB locale 下测过。当然这个补丁本身是不依赖于 locale 的,它有自己的环境变量 GST_ID3_TAG_ENCODING。可以 gbk、gb2312、gb18030 等换着试。

如果命令打下去仍然看不见中文,那估计是你系统的问题了,你可以把该 mp3 传上来,我们大家帮你试试。

补丁打在 g-p-good 0.10.3 上,不是 gstreamer,也不是 g-p-ugly。
回复

使用道具 举报

发表于 2006-6-21 20:35:15 | 显示全部楼层
[quote:2337a02fc3="xLoneStar"]在打好补丁、设好环境变量后,使用这个命令查看效果:

$ gst-launch -t filesrc location=变的坚强.MP3 ! decodebin ! audio/x-raw-int ! fakesink

应该会是只有在支持 UTF-8 的终端中才能看见中文。抱歉我使用全 UTF-8 环境,所以没有在 GB locale 下测过。当然这个补丁本身是不依赖于 locale 的,它有自己的环境变量 GST_ID3_TAG_ENCODING。可以 gbk、gb2312、gb18030 等换着试。

如果命令打下去仍然看不见中文,那估计是你系统的问题了,你可以把该 mp3 传上来,我们大家帮你试试。

补丁打在 g-p-good 0.10.3 上,不是 gstreamer,也不是 g-p-ugly。[/quote]
多谢,已经找到原因了。原先是设置成 GST_TAG_ENCODING=GBK,GB18030,UTF-8 ,我记得在0.8下是可以的。后来查看你的补丁,发现多个编码之间是用 G_SEARCHPATH_SEPARATOR_S 也就是 : 来分隔,改成 GST_TAG_ENCODING=GBK:GB18030:UTF-8 就可以了。还发现 rhythmbox 不会自动更新 tag 信息,打了补丁后,非得删掉重新加入才可以。
建议还是不用 G_SEARCHPATH_SEPARATOR_S 来分隔编码,因为不同系统下这个字符并不一样,比如在 Windows 下是 ; 。
回复

使用道具 举报

发表于 2006-6-21 20:59:57 | 显示全部楼层
不好意思见笑了,其实这个补丁大部分代码都是gst中现成的,我只是拷贝了一下。包括你说的 G_SEARCHPATH_SEPARATOR_S,实际上我都没怎么看过。鉴于现有的代码就是这样的,我觉得我们还是保持现状吧;)
回复

使用道具 举报

发表于 2006-6-21 21:13:30 | 显示全部楼层
实际是 linux 中环境变量都用:分隔的,如 PATH, DISPLAY, 主机:端口号。用逗号的太少了。
回复

使用道具 举报

发表于 2006-6-22 22:08:59 | 显示全部楼层
[quote:7f6896d0df="yangh"]实际是 linux 中环境变量都用:分隔的,如 PATH, DISPLAY, 主机:端口号。用逗号的太少了。 [/quote]
用 , 是比较少,但是考虑万一有一天Gstreamer移植到Windows,G_SEARCHPATH_SEPARATOR_S就变成 ; 号了,所以这个环境变量又会设置不对了。
回复

使用道具 举报

发表于 2006-6-29 23:35:19 | 显示全部楼层
实在不好意思,不知道怎么安装patch
回复

使用道具 举报

发表于 2006-6-30 13:48:16 | 显示全部楼层
如果你用 fc5 的话,我给它打了个包。如果用 magiclinux,仓库里也有。
回复

使用道具 举报

发表于 2006-7-15 01:53:08 | 显示全部楼层
ubuntu 6.06,不知道怎么打这个布丁啊。。。
回复

使用道具 举报

发表于 2006-7-15 16:38:59 | 显示全部楼层
我想你需要找个会打包的人帮你。Penguin? 在不在?
回复

使用道具 举报

发表于 2006-7-16 11:51:36 | 显示全部楼层
[quote:96c3bad391="xLoneStar"]我想你需要找个会打包的人帮你。Penguin? 在不在?[/quote]
您是补丁作者,难道您不能帮我解释下该怎么操作么?麻烦您了
回复

使用道具 举报

发表于 2006-7-17 09:01:26 | 显示全部楼层
晕.. :neutral:

最近家里网络中断。暂无法提供这些服务。 :neutral:
回复

使用道具 举报

发表于 2006-7-17 21:13:37 | 显示全部楼层
根据 id3v2.4.0 的标准,tag 里的字符串可以使用 ISO-8859-1、UTF-16、UTF-16BE、UTF-8 四种编码。咱们 id3 tag 用 gb 编码的其实是宣称它用的 ISO-8859-1 的编码,这样的 tag 也就是在中国的电脑上有可能正常显示(只是有可能,也不一定,咱们都是目击证人,呵呵)。如果是遵照人家的标准写的 tag 的话,拿到哪台电脑上都能正常显示,只要有合适的字体就行。

用 千千静听 写的 UTF-16 编码的 id3v2.3.0 tag 就是合乎标准的,可以正常地在 windows 里,在 rhythmbox 里,在 totem 里显示──不用任何补丁和设置的。至于 mp3 随身听,只要是神智健全的产品,都支持标准的。现成的例子就是前面那位兄弟的 iriver,还有 nokia 的手机。

xLoneStar 老兄,不是我泼你的冷水,我觉得与其写一个纵容错误的补丁,不如写程序把现有的 mp3 转一转。毕竟标准本来就是用来遵守的。我自己就写了一个 C 语言程序把我的 mp3 转成 id3v2.4 UTF-16 编码的了。现在在 Linux 下和 千千静听 里都没问题,可是 Windows Media Player 不认──好像它最高就认 3.0 的 tag。难怪 千千静听 写的 tag 是 3.0 而不是 4.0 的。

另外,beep-media-player 写的 tag 是 UTF-8 编码的,但它也没遵守标准。以致于在 rhythmbox 这些遵守标准的播放器里不能显示,在 Windows 里也不能显示……晕……因为 easytag 和 id3v2 这些程序和 bmp 用的一样都是 id3lib 这个库,所以,它们写的 tag 应该也是不标准的。推荐使用 eyeD3 这个程序。

不要用 id3lib 这个库了。我写的那个程序用的是 libid3tag 这个库。另外好像 libtag 库也可以用,不过是 C++ 语言的。
回复

使用道具 举报

发表于 2006-7-18 09:43:23 | 显示全部楼层
这样的观点我已经反驳过很多次了,其实不太愿意重复,不过还是提一提。

1)起源。使用GB2312字串不是邪恶之举。在整个 Unicode 概念出现之前,改革开放的春风吹拂大地时,(1980年)人们发明GB2312,作为 ASCII 的扩展,目的是使大量西文现成软件,不必进行修改就可直接支持中文。ID3标签问题亦属此列。

2)现状。中国的互联网上有不计其数的mp3(D版之国)。假设其中有一半具有中文标签,再一半是 ID3v2。那么不计其数的 1/4 仍然是不计其数。其中绝大部分用的是 GB2312。

我决不否认 Unicode 方案更先进,但此刻我们不是在进行先进性教育。当这个古老国度的绝大部分人都在使用,并且预计根据惯性仍将持续使用一种不太先进的方案时,我们绝不能称这种现状为“错误”。广泛应用本身就证明着合理性。

落后的方案是落后的,但不意味着我们的软件就无法兼容它。我的方案证明了我们可以两头兼顾。

我十分欣喜地看到你和许多其他人正致力于推进先进的 Unicode 方案。这很好,同时我还十分欣喜地发现我的方案并不会对你们的方案造成阻碍,我们是互补的。

最后,本贴提出的是一个针对mp3标签乱码的解决方案。欢迎就方案本身进行讨论,但我不希望进行关于“是否有必要”的讨论了。对后一个话题感兴趣的朋友请另开新贴,我会欣然前往灌水。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

GMT+8, 2024-3-29 08:08 , Processed in 0.108442 second(s), 12 queries .

© 2021 Powered by Discuz! X3.5.

快速回复 返回顶部 返回列表