XRP Ninja

我几乎所有的mp3的album都是gbk，title和artist是utf8(不标准的) 所以我的步骤如下 1. 我用的脚本配合我的tagreader和tagwriter把所有mp3的album转为标准utf8 id3v2 tag储存方式 2. 利用python版的id3iconv，给已经是utf8的title和artist加上encoding标示字节。命令这么写find -name "*.mp3" -exec id3iconv -e UTF-8 {} \; 参考： http://zhllg.blogspot.com/2006/11/audaciousid3tag_12.html

http://guancha.gmw.cn/show.aspx?id=1231 这是光明网（光明日报的网站）上的一篇文章。文章深刻揭示了中国当前的发展模式的严重弊端。 文中主要观点如下： 中国成功地避开了舒尔茨陷阱， 中国的发展是一种不提折旧费用式的发展模式 低工资是国内分配严重不均衡的结果, 这个体制的独特优势在于：它可以未经国民允许就慷慨地牺牲本国国民的福利 竞次战略不走到不能承受的地步很难回头 劳动力无限供给的说法是有人故意强加给大众的一种学术蒙昧 跨国公司对中国政府的俘获能力要远大于本土企业 东方功夫最大的破绽：落后的政治体制，

http://bugs-meta.atheme.org/view.php?id=632 Here is the problem's description: In audacious-plugins' current implementation, when saving MP3's tags, unicode is enabled unconditionally. In save_cb() function in http://svn.atheme.org/audacious-plugins/trunk/src/mpg123/fileinfo.c, [ ^ ] there are two function calls: taglib_set_strings_unicode(1); and taglib_set_id3v2_default_text_encoding(); However, when reading MP3's tags, if chardet is enabled, unicode will be disabled. In fill_entries() function in the same file, there is a conditional compilation: #ifdef USE_CHARDET taglib_set_strings_unicode(FALSE); #endif This may not affect English only users. But for CJK users, this discrepancy of dealing with chardet will lead to MP3's title and artist being rendered as garbled characters.

http://www.kotaku.com/gaming/top/foreigners-and-fights-ps3-jpn-launchs-dark-side-214130.php

首先说一说我对chardet的理解： 如果启用chardet，那么让taglib把所有tag的encoding当做Latin1，然后audacious自己来进行编码侦测。 如果不启用chardet，让taglib把所有tag当UTF8。 相比较amarok，audacious确实给用户多了一种选择。用户可以不转码。转的不"规范"的UTF8编码（也就是只转码，没加encoding byte）的tag也可以显示。 可惜我之前不知道，我用id3v2转了很多mp3，都属于此类情况。 现在我准备向"标准"靠拢。我准备不再用audacious的chardet功能。 我改写了taglib里的例子，用它配合我的id3转码脚本，在结合下面这个网页上的脚本，来把我所有的mp3都转"正确"的编码。 http://paste.ubuntu.org.cn/1090 这样一来amarok里也可以正常显示。否则像现在这样amarok里所有的歌都是乱码，除非不含tag的，可以正确显示文件名。 虽然我不用chardet，不过这个补丁还是要贡献出来。它应该有理由被upstream收录。gentoo-china overlay用户可以直接layman -S后，emerge audacious-plugins http://gentoo-china-overlay.googlecode.com/svn/trunk/media-plugins/audacious-plugins/files/audacious-plugins-1.2.2-mp3-id3tag-edit.patch

在id3v2 tag的问题上。 StringList::toString()里虽然没有利用到encoding 但是在建立TexIdentifationFrame对象的时候，是用到了encoding的。 至于id3v1，那个问题我认为确实是个问题。虽然taglib说它只把id3v1的encoding当Latin1。 不是taglib的问题，那自然就是audacious的问题。确实如此。 在目前的audacious里，在写入时都当做是utf8。但是读取时，如果启用了chardet，那么就当成是latin1，这样读取出来的就是乱码。

我的audacious和audacious-plugins的版本及USE flag如下： [I] media-sound/audacious Installed: 1.2.1(chardet -gnome nls) [I] media-plugins/audacious-plugins Installed: 1.2.2-r1(aac alsa arts chardet -esd flac -jack -lirc -modplug mp3 -musepack nls -oss -pulseaudio -sid -sndfile timidity vorbis wma) 值得注意的一点是，我都加上了chardet USE flag，这样在UTF-8环境下就不必为本来encoding为GB码的mp3文件里的id3tag转码了。 只需要稍微设置一下： Preference->Playlit->Metadata: auto character encoding detector for: Chinese fallback character encoding: gbk 还有一点是，如果主窗口显示不出汉字。看看你是否选择了这个选项： Preference->Appearance->Fonts->Use bitmap fonts if available 请不要选中这一项试试。如果使用微软雅黑，同时选中这个选项，主窗口的歌曲名如果是汉字就会乱码。而不选则不乱码。 这两个地方设置过后，audacious已经几近完美了。不过还有一个问题，就是修改id3tag保存后，再打开该文件会发现id3tag乱码。 经过我的分析，原因大概是这样： 1. id3v2.4.0标准里定义了tag可以有4种encoding，可以在tag里标明，占用一个字节，其中UTF8的值为3。 2. 如果指定encoding为utf8，taglib在写入时会遵循标准的约定，在tag里用一个字节表示encoding，就是3。 TextIdentificationFrame::renderFields() 3. 但是在读取tag的时候，我发现似乎taglib根本没有考虑这里还有个字节表示encoding。而是把3看作字符串的一部分。 StringList::toString()仅仅是把list

http://groups-beta.google.com/group/gentoo-china/browse_thread/thread/b059f759094c82d4/e1384ded3366dce7?hl=en http://groups-beta.google.com/group/gentoo-china/browse_thread/thread/f1e44fda204bffde/781b86d88c804514?hl=en

First you have to setup a break point. (gdb) b 'server::Checks::chkCleardigits(ost::Script::Line*, ost::ScriptImage*)' don't forget the leading ' before server, so that gdb can complete the whole function prototype for you. Check breakpoint info (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 0x080565f4 in server::Checks::chkCleardigits(ost::Script::Line*, ost::ScriptImage*) at checks.cpp:624 breakpoint already hit 1 time Run the program, and then you find that there are so many calls to this function. However, you are only interested in one particular call. And most importantly, you know a condition which is unique to this call, line->argc>1 Set condition: (gdb) condition 1 line->argc>1 (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 0x080565f4 in server::Checks::chkCleardigits(ost::Script::Line*, ost::ScriptImage*)

I was asked to analyze the usage of this "select.span" command. However, I've no idea wtf the so-called span is. What's worse, it seems that nobody else here could explain to me what it is. I am a totally newbie in this area(I mean IVR), and I think it is known to everyone. However, I did find some clue. I found normally those span should be initialized in the driver. Take capi20's driver as an example, BayonneSpan object is newed in Driver::startDriver(). But unfortunately, the synway's bayonne driver is not complete at this moment. The driver is in bayonne-nonfree package. In my opinion, the biggest problem now is this incomplete synway bayonne driver. If it is finished, many problems will not exist any longer. PS: This "select" thing is discovered by me, when I analyzing "connect". In startDialing() which is called by scrConnect(), there is a call to getPointer() with a single parameter in the form "select.%s". Then I found th

According to e-zone, a Hong Kong magazine, PS3 60GB version will be sold at HK$ 3780 in Hong Kong starting from Nov 17. This price is equal to 56,810 Yen according to the exchange rate on Nov 1, while the expected price of Japan version is 60,000 Yen. This price is also lower than that of US version. The 20GB version will be available in December in Hong Kong. The price will be HK$ 3180. The price is lower than I expected. However, I won't act before Winning Eleven PS3 version is out. :)

This is my /usr/bin/emacs #!/bin/sh emacs.emacs-23.0.0 --enable-font-backend -fn "Consolas-12" "$@"