FixCue 1.4 发布

终于有时间(咦?)把小薰的编码自动识别代码移植到C#,再加上增添了一些一直想改的功能,这下FixCue终于算是彻底达成我的预期目标了,接下来如果没有重大Bug,估计也不会再进行太多修订了。这次专门写了个文档,不过这类说明文还是不太会写,大家凑合看吧。下载附在最后了。

FixCue使用手册

本软件理念

对于热爱听无损音乐,尤其是ACG无损音乐的人来说,“修复”CUE文件是一件经常会遇到的事情。所谓修复CUE,就是纠正CUE文件的“错误”使得播放软件可以正确识别里面的音轨。一般来说,错误主要分为两类:

  1. 文件编码不对,读取进播放软件是乱码

这是最常见的错误。因为EAC等软件抓轨后,保存的cue是ANSI编码的,那么一些从日本流出的无损其带的CUE也自然是shift-JIS编码,那么用非日文系统打开就会变成乱码。可以说,在Unicode已经诞生这么多年的今天,依然有大量软件使用ANSI,这是一件很让人痛心的事。不过遇到问题解决问题,对于这类错误,我们需要的就是转码了——比起ANSI程序,文本文件的转码相对就简单很多,有一种最简单的方法就是用浏览器打开文本文件,选择(或自动识别)相应的编码即可;当然,也有无数的高级文本编辑器提供相应的功能,但是据我所知,Win下的大部分文本编辑器无法做到“自动识别编码”,这不得不说也是一大遗憾。

  1. 引用的音乐文件不正确

所谓引用的音乐文件就是CUE FILE行所对应的那个文件。虽说CUE是抓轨时自动生成的,引用文件原本不该有问题才对,但是许多职人放流时会将WAV转换成多种多样的无损格式,却又不修改原始的CUE,那么就产生了这类问题。

另外还有一类foobar2000特殊的问题,在此也专门提出。Foobar2000的媒体库功能相信很多人都用到,是一个非常方便的功能。但是如果经常下载日职人放流的EAC的人都知道,日本职人放流CUE往往会有许多个CUE,有的是没有曲目信息的,有的是对应原始WAV的,有的是对应转格式后的无损文件的……如果你转码了其中一个并另存为的话,那么原来的乱码的也在;而这些,全部都会读取到你的Foobar2000媒体库中,非常的杂乱。在原来,我总是采取把这些无用的Cue移动到一个子目录下(基于原档强迫症,并不想删除它们)。但是没想到,foobar2000自从0.9.x某个版本之后,其标准输入组foo_input_std在打开文件而未播放之前,是不会检测文件的有效性的。也就是说如果一个CUE文件是无效的,也会读取到foobar200的媒体库里,这样即使移动到子目录,他也会被读取进来。好在foobar2000的媒体库并不读取隐藏文件,故我后来对于无用的CUE都是隐藏了事。

了解了以上这些问题,自然也就清楚了本软件的目的。本软件的一切都围绕着一点:全自动处理CUE。虽然我也提供了一些手动修改的途径,但是最主要的使用方法,就是把一个含有以上各种错误的CUE通过本软件修复之后,可以完美解决,而不需要再进行任何的人工干预。另外,由于CUE最终还是要用播放器播放的,所以我专门添加了修复完之后自动用播放器打开的功能;另外由于上面提到的Foobar2000媒体库索引的特殊问题,我又增加了能自动处理其他CUE的选项。

软件使用介绍

The FixCue's Snapshot

上图就是FixCue的具体界面。

功能特性:(抄袭修改自http://kuyur.info/blog/archives/877 233)

–全自动处理CUE
–完整的Unicode支持
–自动检测文本编码
–自定义BIG5 to Unicode的映射表,取代微软自身的CP950,解决日文假名丢失问题
–转换结果保存为utf-8编码的文本
–支持文件拖放操作及命令行打开文档
–自动修正cue中的File行音频文件扩展名
–自动修正cue中的File行旧式“The True Audio”标签为“WAVE”
–CUE右键菜单关联

推荐使用方法:

运行程序,勾选自动保存&自动退出;根据需求修改下面各种选项(推荐勾选所有CUE处理参数,以得到最好效果);注册到右键菜单;关闭。以后,在需要转码的CUE上右键->用FixCue修复之后可以完成所有处理,并立即用播放器打开该Cue进行播放。

提示:因本程序为.NET程序,故开机首次启动需要预编译较慢,请见谅。

功能逐一介绍供查阅:

最上方文本框①:显示输出路径。

打开按钮:打开要处理的CUE。本软件提供三种打开方式:1. 使用此按钮;2. 拖拽文件至程序上;3. 用命令行操作。其中第三种主要是为了添加处理命令到CUE右键菜单而存在的。

编码类型:本软件采取小熏(http://kuyur.info)的编码识别方案,根据码段自动识别Big5/GB/shift-JIS编码,而且对于Big5编码,使用自定义的转码表,因此不会有假名缺失的问题。对于无法识别的编码,则采用此处默认的编码。数字为微软code page编号,日文为932,简体中文为936,繁体中文为950。

自动保存&自动退出:如名。选择自动保存时,打开之后文件后,处理完毕会自动保存;选择自动退出时,保存完毕会自动退出。两者同时使用可以完成全自动处理Cue的过程。

文本框②:如果手动处理文件,那么在打开之后可以在这里人工修改文本。当然,实际用到的机会不是很多。

另存为文件名:设定保存的文件名。可以使用%filename%表示原文件名,暂不支持其他转义符。如果勾选“覆盖原文件”,则覆盖原始文件。(不推荐勾选)

CUE专用选项

虽说本软件专为CUE设计,但是其转码功能也可用于任何文本文件。但是下面这些选项就仅在打开的文件是.cue格式时才有效。

将FILE行”The True Audio”替换为”WAVE”:Foobar2000对于CUE的要求很严格,FILE行的结尾只能是非常有限的几个如WAVE,MP3等。有些软件对于TTA产生的CUE这里会写成”The True Audio”,那么用此选项将其替换为”WAVE”。(推荐勾选)

同目录查找音乐文件替换FILE行文件名:此选项就是用来修复上面提到的第二类CUE问题。其具体逻辑为:首先搜索同目录下的无损格式音乐文件(WAV/FLAC/TTA/TAK/APE)。如果不存在,那么不对FILE行进行任何操作;如果存在且只存在一个,那么将FILE行直接替换;如果存在两个及其以上的音乐文件,那么逐一比对FILE行除了后缀名前面的文件名部分,如果找到一致的则修改之,否则不进行任何修改。之所以要这么复杂的处理,是为了防止有些CD有多碟又放到了同一个目录之下。(推荐勾选)

自动发送到播放器:可以在处理完CUE文件之后,自动用命令行的方式将其传送给其他的程序,如播放器或者文本编辑程序。比如对于我个人来说,会选择用foobar2000打开,那么程序路径就是“D:\Program Files\foobar2000\foobar2000.exe”(不含引号,可以用后面的“浏览..”选择);参数方面,一般程序的参数就是“ %1”(不含引号,注意空格),但是foobar2000如果用此方法将会替换掉这个播放列表,那么我采用另外一种方式“ /add “%1″”,可以只将其添加到播放列表的末端。(根据个人需求勾选)

处理其他cue:可以在处理完CUE文件之后,自动对同目录下的无用CUE(如果你是另存为保存,那么也包括被操作的原始cue文件哦)进行隐藏、删除到回收站、移动到指定的子目录三种处理。其对于无用的逻辑判断类似“同目录查找音乐文件替换FILE行文件名”,如果不存在音乐文件,那么无操作;如果只有一个,那么无脑移动所有其他CUE,如果有多个音乐文件,那么只移动和当前CUE引用文件(去除后缀)一致的CUE,依然是为了防止多碟的情况。(根据个人需求勾选)

注册到右键菜单/从右键菜单卸载:依然是为了方便使用。点击注册之后,会自动在CUE文件的右键菜单增加“用FixCue修复选项”。另外值得一说的是,我发现很多软件的右键菜单注册功能写的都不好,不适用于win7,有些时候会发生注册不上的问题。我这个应该没有此类问题。(推荐注册)

其他说明

软件编写:烈之斩(twitter:@ikenaikoto

最新版本:1.4.4.0

欢迎散布

自动识别编码的代码借鉴自小熏(http://kuyur.info),再次表示感谢

下载地址:GitHub

64位Win7下转码TXT的一种简单方案

转码一直是windows系统下的一个无比蛋疼的问题。对于我个人来说,转码主要是从日文编码(shift-JIS)、小部分从繁体中文编码(big-5)转换。需要被转码的东西无外乎两类:一是ANSI程序,二是含有ANSI编码内容的文件。可以使用的软件包括微软自己开发的Applocale、色神开发的NTLEA、soraapp以及后面一个叫什么NTLE啥啥的记不清了。转码程序很好理解,而“转码文件”的概念,本质上就是先用转码软件对该文件的打开方式程序进行转码,之后再打开该文件,可以看到无乱码的内容(如,txt、zip等)。前者不再赘述,对于后者,最大的一个问题就是“方便性”这点。好比转码winrar这点,applocale就可以做到,但是方便吗?你需要先用applocale加载winrar(到这步你还可以做一个快捷方式),然后再在winrar里逐步找到你需要打开的那个zip文件。而这明显与常人喜欢用资源管理器查看文件这一习惯相悖。NTLEA开创了一种方式,就是他加载的参数,不止可以是exe,而是可以是任意文件类型;其效果就相当于前面所描述的,用它转码该文件的默认打开方式程序,然后打开该文件。这样,如果我需要转码查看一个ZIP,之需要在其之上按下右键,选择“用NTLEA打开”就可以了,相当的方便。

可惜在升级了64位的Win7之后,NTLEA这个一直停留在0.87版本的软件就没法正常运行了(准确地说是对win7支持都不好)。所幸我很快找到了一款替代软件:soraapp,同样是由色神开发的,而且操作比NTLEA更简单,只需要安装一次之后,即可在右键菜单找到“以日文环境打开”/“以繁体中文环境打开”的选项,选用就可以,依然支持所有文件类型,而不是applocate那样残废地只支持exe。不过另外一个问题在于,几乎所有的转码软件都不支持64位程序,包括soraapp。对于最常用的两个软件,winrar和notepad,恰好都是(有)64位的。不过还好,我们可以选择安装32位的winrar,性能上并不会损失太多。但是notepad是系统内置的程序,怎么办呢?

所幸不知道是处于兼容性还是什么原因考虑,其实系统里就备有32位的notepad程序,位于:C:\Windows\SysWOW64\notepad.exe 但是我们应该怎么办呢?直接替换系统里的notepad.exe?或是把txt类型关联到它身上?听起来都不怎么让人舒服。

直到某一天,我无意尝试用soraapp打开被我关联到notepad的cue文件,发现居然被转码了!这是个很奇妙的现象,因为cue的打开方式显然应该是64位的notepad,soraapp应该转码不能才对啊?而且我已经试过无数次用soraapp打开过txt,确实是无法转码才对。打开任务管理器看一看——咦,这个notepad.exe进程后面居然有*32?再打开文件位置——就是刚才提到过的“C:\Windows\SysWOW64\notepad.exe”。

那么为什么.cue和.txt的打开方式会不同呢?让我们去注册表看看。关于文件关联的键值控制,请参见之前的文章。首先看CUE的,位于“HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.cue\UserChoice”里的Progid项。其键值是Applications\notepad.exe。让我们找到这个类里是怎么写的,位于“HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\open\command”——其键值是%SystemRoot%\system32\NOTEPAD.EXE %1:注意,不是windows下面那个notepad,而是在system32下,而且是相对路径。看来,如果用soraapp尝试调用这个的话,大概由于一些接口的缘故,会自动调用32位版本以兼容,从而可以正常转码。虽然具体原理不明白,至少知道“这样可以”;那么为啥txt就不行了呢?我们打开HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt,咦没有UserChoice?哦没关系,看一下HKEY_CLASSES_ROOT\.txt里面的默认键,是txtfile。那么我们定位到它——HKEY_CLASSES_ROOT\txtfile\shell\open\command,看他的键值,居然是C:\Windows\notepad.exe %1?怎么回事,为什么是绝对路径?而且不是system32下那个,难怪soraapp打开它不会自动调用32位版。我们可以它他的的键值直接用上面写的那个替代,就OK了;但是我发现一个很奇怪的现象,就是这个键值过一段时间就会自动恢复原始值,也许是因为这是系统级的键值的缘故?不过我们可以直接修改.txt的打开方式(添加个UserChoice目录)为Applications\notepad.exe,就OK了。

不过最近又发现一个很奇怪的问题,如果把那个32位的记事本exe拷贝到别的地方,居然无法运行,谁知道是怎么回事吗?自愈了囧

几乎佳作——写在《在盛夏等待》最终话之前

很久没有这样一部片,让我每周第一时间下载、赶在别人剧透之前看完,再津津有味地去论坛上看别人讨论了——抛开多角恋爱这一相当吊人胃口的主要因素不谈,其中最吸引人的相信还是本剧较高的制作水平和对人物心理刻画的细腻程度。从这个角度来说,《在盛夏等待》无疑是部水准以上的片子,说是本季JC的良心也不为过。但要说是神作,却又远远不够;即使想说是佳作,也感觉差了那么一口气——比起当年的三角恋神作TT自是不如,本社的《龙与虎》也比本片强不少。

这所谓的“一口气”,说白了还是败在剧情设置上面。首先声明,本片制作人员本来也就没打算搞出什么脱俗的剧情出来——所以当然问题也不是出在“不够新颖”上面。逐一说来,前五集的目的是确定各个人物之间的复杂关系,完成的非常出色。非要说有什么不满就是前两三频繁出现的“妄想”感觉有点不太适合本片的feel,不过反正后面也没有了。六七两集是经典的“引入外部因素减缓加剧内部矛盾”,也算是恋爱剧用烂的手段,一开始我还蛮失望的,不过实际效果还是相当棒的,无论是对剧情的促进程度还是两个配角本身,都是相当抢眼的。第八集的夏日祭和试胆大会,依然是老梗,依然做出了水平。但是接下来的几集就有点下坡路了——好像制作人员把这些老梗全部用完之后,就有点不知所措了。九十两集的主要目的是“清算”所有的感情线路,为接下来的大结局做铺垫——然而无论是高帅富对柑菜的告白还是柑菜自己对男主角的告白,都给人一种不给力的感觉——前者的问题是无论是时机还是双方(或者说加上偷看的美樱)的表现,都给人一种凑数的感觉,之前各种冲突时那种张力完全没有了;后者的问题在于,虽然没错,柑菜自己其实从没有对海人告白过——但是对于观众而言,此次冲突的感情已经在之前高帅富越俎代庖时释放了大半,现在本体来了反而没有了太多刺激了。注意,这里我要说的重点并不是说这两个场景设置不真实——其实这两件事的发生如果在现实中都是相当有可能的——但是从戏剧性需要的角度来说,完成的就不是很美满。其实说到底,原因在于本片之前过于滥用了“A、B两人发生告白、哭诉、etc.,被C抓包”这一可以说是恋爱剧最高潮的场景,以至于到后来,观众已经波澜不惊。第十一话则是我最不满意的——先不说这剧情展开的速度有多扯,姐姐这一角色的道具感有多强,单就说逃离外星人追赶时那一套“十分动画”的无厘头风格和本片前面一贯的风格完全不搭这一点,就足以让我对本片的评价下一个档次。

值得一提的是,本片虽然是个所谓的“多角恋爱”,什么ABCDE的,但是真正有相互冲突的其实只有学姐和柑菜——只有她俩身上发生了“同时喜欢一个人”这种事情。后面的人无非是一串单相思罢了。同理,真正意义上的两情相悦也只有海人和学姐。所以说只要理清海人与这两位之间的关系,后面的D、E的结果也就不言而喻。

接下来谈谈人物。主角海人,作为一个全片没有犯过错的人,但也很难让人对他说什么好话,毕竟是坐拥两大好妹子的准后宫男嘛。而且所谓“全片没有犯过错”,也从一个侧面说明了他的形象不够丰满;实际上,海人身上的剧情还真不算很多,撑死了算是个线索人物,第一男主还是要论高帅富。学姐方面,首先本人就是坚定的天降系黑,更别提学姐无论是人设还是户松遥的这种声线都不是我的菜,所以…就不评价了。这里要专门提出批判的是学姐和海人确定关系之后那甜到发腻的举动,我等柑菜党表示必须进行人道毁灭。至于蓝毛柑菜嘛,可以说在前四五集里绝对是本片第一人气角色,元气娘+少女面对感情时特有的娇羞,可以说是人见人爱呢。但是到了后来,可以看出在论坛上不断有人对其进行诟病,却又总是点到为止——其实说白了,后面柑菜招某些人厌的原因,都是出于对主角的死缠烂打,或者说一厢情愿罢了。无论是读空气也好,对学姐摆黑脸也好,都是单恋中的少女的正常表现。只是,也许比起ACG作品中常见的各种完美性格,显得小家子气了一点。不过最后柑菜自己成了夹心饼干,也算是“罪有应得”了吧(笑)。另外石原夏织我的新嫁好棒好棒的。咳说到完美性格,那自然就是说的D、E两位了——有如此圣母心的追求者,柑菜你说你如果跟了海人以后看到高帅富后背不会发凉吗?高帅富如果找了柑菜后背不会——还好这两者自我结合了(茶)。说来高帅富身上的重要戏份真的是非常的多啊。美樱嘛,妹子是好妹子,后面也行动力爆表,但是为什么我总有一种她是在捡漏的感觉……(被裸族党pia死)什么你说我故意漏掉柠檬?才没有呢,不过对于开上帝视角、都合主义的最佳帮凶有什么好说的呢?

按照惯例该说说制作了。前面已经提过,本片制作上乘,这方面肯定是没什么好指摘的。人设的田中脸你懂的看习惯就成,作画基本没有崩坏。OPED都很棒,不过相对于nagi那被Ray秒出翔来的长相偏厚重的声音果然还是Ray那种尖细的声音更对我胃口,而且nagi原来听太多了听烦了啦。

总评的话,本片按bangumi标准大概7.5分,作为长久以来追番的纪念,给8分也不为过。刻意在最终话之前发表这篇观后感,其实是依然抱有一丝希望,希望制作方能在最后一话搞出什么惊世骇俗的玩意,打肿我的脸。不过也许只能是妄想罢……

辻香織 – day by day 这歌不错

在bili某曲包里听到的,很不错。而且这歌手好小众啊,搜了半天信息不多,还好这张专辑有国人自抓,不过mp3,下载猛击这里(115挂了,这是迅雷快传地址)。

打了份歌词,这里有翻译。Minilyrics服务器上有我传的lrc。

おかえりなさい

作詞・作曲:辻香織 編曲:小宫山圣

祭りの後の寂しさをなんて言えばいいの?
打ち上げ花火の音が今も耳に残る

あと少しで夏休みも終わってしまうから
大人になると切ない気持ち忘れていくのかな?

*
どんなに遠く離れていても きっと繋がってる
いつでも笑顔で迎えるよ あかえりなさいと

下駄の足音が カラカラとなんだか嬉しくなるね
浴衣ではじめて会ったから 照れて顔が見れない

都会へ帰る君に何をしてあげられたかな?
楽しすぎた思い出だけか 心に鳴り響く

愛してるなんて 一度でも言えなかったけれど
必ず会いに行くからねと そっと手を撮った

* くりかえし

Colorful

好久没有看过动画了,尤其是剧场版。今天由于作息实在是太正常导致下午无比的闲于是没事干看了这部存在硬盘很久的“Colorful”。

剥开灵魂出窍呀投胎呀之类的噱头,本片的内核用一句话就可以概括,就是中二少年救赎记——虽然是中三。一个日子过得相当不如意的中学生,在某天无意目击到喜欢的妹子居然是援交少女以及母亲和别的男人在一起。无法承受这两大打击选择了终结自己的生命。而之后却由于机缘巧合获得了续命的机会,那么他的人生到底会怎样继续呢。

本片的剧情可以说是非常单纯,而导演也基本就是平铺直叙。整体跌宕不大,即使是最后一家人吃火锅时的最终情感释放,也没有多么剧烈冲击。可以说真实性相当不错——因为真实的生活总是平淡的,男主人生轨迹的变化也都是平缓的,即使存在一个爆发点,但也并不会多么的强烈。但是这毕竟是一部电影。如此淡如水的发展让观众有些犯困不提,也实在很难称得上是“好看”。牺牲戏剧性总得为电影服务吧,感觉在这方面的牺牲并没有换来什么别东西,比如说深邃的立意啦之类的。而且这片节奏太拖沓,这点无起伏的事儿居然扯了整整2个小时。

从另一个方面来说,对于过了中二期的我,看着这样的男主角犯中二是无比闹心的,能让我坚持心平气和看下去的动力就是指望最后男主大大吃瘪,然后恍然醒悟这种快感啊!而现在呢?男主疯狂刁难他妈天理不容,而最后摊牌时刻居然是选了这么一个场景:一家人操心为男主解决升学问题,而男主却一副无比委屈不被理解的样子:我想去的是和我基友一个学校呀!然后一家人就一哭泯恩仇了——等等,难道喜闻乐见的不应该是男主给他妈跪下磕三个响头然后痛哭流涕吗,怎么变成暗示“都怪你们对我那么用力过度,我才成了中二!”了?虽说男主成这样和家庭有脱不开的干系但是就这样拍拍屁股甩掉中二的原罪?导演你想传达的东西有点居心叵测啊!一家人为男主做的牺牲男主一点表示都没有也太说不过去了吧,导演你个包庇犯!而且,这么平淡的“转变”,什么都不说清楚的话,下面暗流涌动说不定过个几年男主又要玩自杀哦——嘛我不是说要一定说出来把老妈逼疯啦,就那么个意思。而且讽刺意味的是,这个没什么悔意的男主居然从精神上拯救了援交妹和土妹子,而且前者还是发生在摊牌之前——这太囧了吧!

刚才说剧情我用了一个“真实”,那么关于人物……首先配音就败了。里面几乎所有人说话都古怪得很,这应该叫棒读吧?看cast全是一堆演员或者不认识的,让专业的来呀!塑造方面最好的是男主的父母,母亲的戏份基本是受虐,看得人无比心疼;父亲就是最后通过钓鱼开导了男主一番,不说演的多么出色但是至少很恰当地融入了进去。另外就是那位一碰到男主就紧张得口吃的土妹子很萌!那破鞋倒是让人勾不起欲望…主要还是画风吧。另外男主何德何能会被破鞋看上?我早就不相信这种倒贴的童话了啊啊啊啊啊啊

画风我真的不想吐槽的。虽说有一个规律就是屌片的人设/画风不能太好(否则会喧宾夺主?),但是不代表反过来也成立啊!基友啊土妹子啊就不提了,破鞋的脸也没几帧不崩的!!

最后吐个槽,按理说其实男主这个灵魂就是自杀死去的小林的灵魂这种烂梗地球人看到一半都该能看出来才对——但是我却没有看出来啊啊啊我还在想结局一定是男主变成了小林替他接着活下去了!我果然脑子根本就不会转圈了!

总结来说,此片中规中矩,如果不是对中二特别感兴趣就没必要浪费两个小时了;不过介于制作水平相当上乘,看了也不能算浪费时间,就当小憩一下了。评分的话大概在6-7分左右吧。