旧博客（WakiBlog） – 第 14 页

CCTV某些时候还是很知错就改的嘛

看了昨天闭幕式转播的同学有没有发现CCTV转播的风格出现了180度大转弯呢？
首先最明显的就是，罗嗦絮叨的解说词不见了。其次，大场面的镜头给得多了。
看来他们多少还是注意到网络舆论了……呵呵。

读书

学日语三年了，前前后后也看了好多书了，今天整理了一下。下面是我手里的书。

书名后标记“（译）”的使我正在翻译或已经翻译完成的作品，在这里可以找到阅读地址。书后标记“（评）”的书是我写过书评的书，您可以在上面的链接中找到我写的书评。
书名以斜体表示的书目是正在计划购买的书。
书名后标记“（Photocopy）”的是复印本或扫描本。因为手头的扫描本和电子版比较多，所以这个列表以实体书为主。
您也可以到豆瓣去看看我的资料。

文学
幸田露伴
『五重塔』
志賀直哉
『和解』
『城の崎にて・清兵衛の瓢簞・小僧の神様』
杨逸
『時が滲む朝』（Photocopy）
京極夏彦
『魍魎の匣』（Photocopy）
早見和真
『ひゃくはち』

語学
山口仲美
『中国の蝉は何と鳴く？』
『暮らしのことば擬音・擬態語辞典』
『犬は「びよ」と鳴いていた』

歴史
池波正太郎
『幕末新選組』（译）
河合敦
『早分かり日本史』

ラノベ＆ファンタジー
冴木忍
『天高く、雲は流れ』シリーズ　1〜15（译）
井内秀治
『魔神英雄伝ワタル・虎王伝説（1）狐虎吼ゆる』（译）（评）
『魔神英雄伝ワタル・虎王伝説（2）鬼夜叉の野望』
『魔神英雄伝ワタル・虎王伝説（3）虎王対虎王』
氷上慧一
『モンスターハンター　魂を継ぐ者』シリーズ　1〜3（评）
大場惑
『イース1　天界へそびえし魔塔』
『イース2　天空にひそみし魔帝』
有川浩
『図書館戦争』

児童書
あさのあつこ
『バッテリー』1~6（译）（评）
『THE MANZAI』
森絵都
『DIVE!!』
上橋菜穂子
『精霊の守り人』
『闇の守り人』
『夢の守り人』
『虚空の旅人』
『神の守り人来訪編』
『神の守り人帰還編』
『蒼路の旅人』
『天と地の守り人　ロタ王国編』
『天と地の守り人　カンバル王国編』
『天と地の守り人　新ヨゴ皇国編』
『流れ行く者　守り人短篇集』

漫画
土塚理弘
『清村くんと杉小路くんと　1〜4』
『清村くんと杉小路くんよ　1〜2』
28ROUND
『激流血~OVER BLEED~ 1〜2』
皆川亮二
『スプリガン』

冰翼6是个好东西啊

前一阵子天气炎热，机器总是莫名关机、重启，于是为了给CPU凉快凉快，就买了个这个。结果换的时候没换好，直接造成了那块为我服务了正好三年的ASUS报废。只好软磨硬泡从老妈那磨来了￥2500的预算，买了MSI + E8400 + Corsair。买的时候，怕再把主板或者CPU装坏了，前思后想，还买了一个Tt火星9，准备搁置冰翼6。
回家把东西换好之后，加电测试，一次性点亮、装系统、顺利运行。之后马上开x264测试，新U就是不一样，比原来的P4 3.2块了将近四倍。
但是满负荷运行的情况下，CPU温度有60度左右（风扇2000转，在空调底下对着吹有55度），噪声有点大，温度也有点高。最后在VempX的唆使下，还是决定上冰翼6。
冰翼6的扣具比较特殊，四个螺丝钉分开的，没有力度限制，只要你愿意，可以一直往里拧，很容易把主板拧变形（那块ASUS恐怕就是我拧的力度太大压变形了），而且很难保证四颗螺丝加力准确平衡。要知道，一个606克的散热器挂在主板上，就算当时没问题，系统长期运行在扣具压力不平均的情况下，也很容易造成主板慢性变形的。
于是，我很无良地在那块ASUS的尸体上反复练习了一个下午囧练到可以保证主板不变形的情况下，把冰翼6装在了MSI上。
之后，一切安静了……冰翼6在风扇出力半开（1000转）的情况下，把全速运行的E8400压制在了51度（不开空调）！MSI最低支持风扇转速半开，如果可以，我还想把转速调到800转，那样估计可以更加安静。

摄像机和照相机是有区别滴…

本文并非为BOB或者CCTV而写，而是为摄像机和照相机而写。
这几天网上流传着不少开幕式照片，于是就有人以照片为依据来炮轰转播版本如何如何辜负演出了，如何如何对不起人民了，等等。一开始，我也被那些照片忽悠了，但是仔细一看，图片的比例根本不对嘛，既非4：3也非16：9，一想才明白，那些图片根本不是电视转播的截图，而是照片。
从我个人来说，我也对BOB的版本有所不满，看过其他电视台版本的录像我意识到这场开幕式原来可以被转播得更好。但那些照片并不应该成为我们指责转播质量的依据。
单反相机可以通过装备鱼眼镜头，以超大的广角制造夸张的图像畸变来达到增加画面气势的目的。而这对摄像机镜头来说是不可能达到的。而且看看那些颜色绚丽的照片吧……一定是PS精心调出来的效果。夜里舞台的照度本来就不算强，再加上现场的表演和光照时刻在变化，因此直播情况下是难以调出和照片一样的色彩的。这次造成照片和录像差异的，只有人类的技术水平。或许20年之后，就能看到画面像照片一样精美的的电视了。应该看看真正的区别在哪里。我个人认为差距在导播和摄像的能力（表现在画面切换的精妙程度上、镜头的构思上等等）和机位的安排，而非画质或是气势。
所以，尽管BOB的转播并不是那么尽如人意，我们还是要冷静地对待中外差距，如果只是看到两张照片就谩骂指责，未免网络暴民了一些。建议大家看过国外的录像之后再发言，BOB版拍不出来的画面，国外电视台同样拍不出来。

诡异的CCTV奥运开幕式SD信号

本来兴冲冲地买了一个爱狗USB电视棒想录CCTV-HD的，结果买到之后才了解到必须到能看得到天塔且没有建筑物阻挡的地方才能收到数字信号，遂乖乖断念在家录SD。本地电视台转播质量本来就差，再加上是老楼房，线路质量那是相当的不好，画面经常出现雪花，音质也不理想。但没想到SD一看，才看出来很多好玩的东西。开幕式本身的精彩程度是毋庸置疑的。恐怕以后也难有超越本届奥运会的开幕式了吧。
7：48分直播正式开始，屏幕上出现了鸟巢的画面。结果几秒钟之后字幕一出来我就囧了。

这是搞什么飞机……电视有overscan，没听说过字幕自己overscan的……八成是CCTV偷懒，把HD的信号变形切边之后直接嫁接到SD这边来了。

这两个画面更加证实了我的想法，的确是HD信号变形切边之后嫁接过来的。字幕被切过了……

演出继续，画面切入了会场大屏幕的影像。

竟然是25P的……看来是CCTV事先拿到了带子，直接播的录像。不过这没什么，雅典奥运会转播的时候，公共信号似乎也是这么做的。

之后更囧的事情发生了！看来这时CCTV自己也意识到了信号的问题。时间走到27分钟，也就是人体作画的环节。20473帧开始到20500（27:00.000秒，看来他们是掐着整点算的）帧结束，一个“温柔”的渐变，画面竟然从4：3画面渐变到了Letterbox形式的16：9……OMG……

这时候画面上的“直播”logo也从新闻台的“直播”换成了CCTV-HD台的“直播”。下面是对比：

看来这回变成了把HD信号变形之后加黑边嫁接过来了。这时，字幕也恢复了正常。

但随之而来的问题更囧了，以HD画面的尺寸为准加上去的滚动字幕缩小之后，就算在电脑显示器上也难以辨别，更别说在可怜的破电视上了。
（这张图没有经过缩放，720*576的）

看来CCTV在HD信号和SD信号同时播放方面还没有足够的经验啊，开幕式就直播得这么囧……不过，我估计上述问题应该仅限国内提供SD信号的那几个频道，发送海外的公共信号应该没问题才是。
抛开画面上的囧处和偶热切错的几个镜头和点火前那台信号出问题的摄像机之外，总体来说，还算是完美。

TIVTC的自动交错帧记录与手动OVR脚本

上次在这篇帖子里提到了ovr的利用，今天来详细写写。

好长时间没码字了，那么今天就来写一个可能很多高手都会解决的问题，那就是利用TIVTC的自动记录交错与手动OVR脚本来手动指定Post-processing的动作。
在IVTC过程中，一部分帧会走PP，也就是被送去Deinterlace。但是这部分帧当中，有一部分是因为匹配失败而被PP（确实找不到合适的场匹配结果），有一部分是匹配成功但被误判为交错送去PP，而通常情况下只有较少的一部分帧是真正因为无法找到合适的匹配而出现交错的（也就是第一种情况）。

TIVTC的匹配精度很高，绝大多数情况下不会出现错匹配的情况（但是我也遇到过极少数例外的情况发生，需要通过ovr手动指定匹配pattern，这个下次有时间再写）。
TIVTC的问题在于，他的默认参数比较灵敏，在后处理检测时微小的交错也能察觉出来，因此容易造成误判，特别是动画OP/ED中的字幕，经过PP之后，文字不断抖动，非常难看。而那些参数又非常难以调整，常常是这边调好了，那边又坏掉了。虽然通过OVR也可以单独分段指定参数，但我还是建议使用默认参数，最后通过OVR来针对出错的帧进行修正。
因此，我们就需要结合TIVTC的记录输出功能和OVR手写脚本功能来“强制”TIVTC对我们指定的帧进行PP或者不进行PP。

我们首先要找出哪些帧出了问题。之前我注意到，不少同学还在使用我好多年前用ConditionalFilter + decomb写的那个交错侦测脚本，其实现在TIVTC里面已经内置了相当丰富的交错侦测功能，独立函数ShowCombedTIVTC和IsCombedTIVTC在调试TFM的cthresh、 MI、 chroma、 blockx、 blocky、 metric等参数方面很好用，也可以结合ConditionalFilter写出来交错侦测的脚本，但我们今天要用的是TFM内置的output参数来输出log文件。
首先，我们需要构建出来一个avs脚本，让tfm输出log文件。这个过程相当于IVTC过程的1pass，我们不需要通过这个脚本输出成品，因此要让这个脚本高速地执行，快速得到我们要得log文件。1pass.avs: d2v = "op.d2v" MPEG2Source(d2v) tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true, output="log.txt") PointResize(96, 96)各个参数的目的是在保证检测精度的情况下尽量提高速度。
log.txt就是我们要输出的log文件。现在我们要执行这个脚本，你可以通过播放器去播放它，但是这样还不够快，我们可以让x264以一组简单的参数去压制这个脚本，这样通常能够得到数倍于播放的速度（它在我的E8400 CPU上跑出了150fps）。x264 --crf 51.0 --level 1 --no-fast-pskip --nf --no-cabac --subme 1 --partitions none --me dia --threads 2 --thread-input --aq-mode 0 --progress --no-dct-decimate --no-psnr --no-ssim --output "F:druagaopop.mp4" "F:druagaopop.avs"（注意，请不要用MeGUI去压这个脚本，用MeGUI压制的话tfm之会输出一个空文件，而得不到我们要的log。更不要试图修改log文件，因为之后载入log文件的时候，tfm会检测log文件是否发生过改变。）
压制结束之后，我们会得到一个不小的文件，他包含了tfm对每一帧的处理方式、判断结果。但我们真正需要的是这个文件尾部以#号开头的那一段。
一段典型的该部分log会像下面一样（中文部分是我的注释）：# # # OVR HELP INFORMATION: # # [COMBED FRAMES] #以下是被判断为交错、需要走PP的帧。前面是帧号，后面是该帧的交错度。 # # [Individual Frames] # FORMAT: frame_number (mic_value) # # 1544 (256) # 1545 (256) # 1546 (256) # 1547 (87) # 1548 (108) # 1563 (82) # 1566 (92) # 1569 (99) # 1570 (99) # 1571 (95) # 1572 (110) # 1578 (256) # 1579 (256) # 1613 (256) # 1614 (256) # 2184 (170) # # [Grouped Ranges Allowing Small Breaks] # FORMAT: frame_start, frame_end (percentage combed) # # 1544,1548 (100.0%) # 1563,1579 (47.1%) # 1613,1614 (100.0%) # # # [POSSIBLE MISSED COMBED FRAMES] #下面是tfm觉得交错程度较大，被判断为可能交错的帧，但因为不够阈值设定的值，因此不会走PP，仅提供用户肉眼确认、参考。 # # FORMAT: frame_number (mic_value) # # 455 (17) # 470 (16) # 950 (40) # 1559 (76) # 1560 (76) # 1564 (75) # 1565 (75) # 1567 (74) # 1568 (74) # 1576 (69) # 1577 (65) # 1620 (72) # 1621 (72) # 1623 (73) # 1624 (73) # 1625 (78) # 1626 (70) # 1627 (71) # 1631 (69) # 2177 (20) # 2182 (19) # 2187 (42) # 2192 (58) # # # [u, b, AND AGAINST ORDER (n) MATCHES] #使用了u、b、n这三种匹配方式，得到了“无交错匹配”的帧。为什么说“无交错匹配”而非“正确匹配”呢，因为DVD在制作中可能存在一些bad cut或者Telecine制作错误，u、b、n这三种匹配方式通常可以有更大的几率获得无交错的帧，但是也有可能造成画面一顿一顿的（恰好匹配到了和上一帧或下一帧相同的画面），因此tfm也认为这些帧需要肉眼确认。如果确认发生了jerkness，用户可以通过ovr来选择是输出无交错的帧好，还是通过pp输出一个模糊一些但保持动态的帧好。但这并非本文讨论话题，所以只略微提及一下，详细的……等有时间再写吧。 # # FORMAT: frame_number match or range_start,range_end match # # 319 u # 347 u # 387 u # 428 u # 730 u # 826 u # 920 u # 948 u # 1511 u # 1580 u # 1615 u我又写了一个脚本来逐帧确认交错情况。check.avs: d2v = "op.d2v" MPEG2Source(d2v) tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true)用vdm或者au打开它，跳到[COMBED FRAMES]这段log中提到的帧，逐帧检查，并最终确认1544、1545、1546、1578、1579、1613、1614真正存在交错，其余全部是误判。现在，只需要用记事本写一个文件，告诉tfm其余帧是清白的即可（将误判为交错的帧用-号标记，强制tfm将这些帧直接输出）。
当然，如果你愿意，也可以检查[POSSIBLE MISSED COMBED FRAMES]里面记录的帧的情况，这部分帧被认为是可能存在交错的帧，输出时，这些帧会被当作好帧直接输出。如果这部分帧中真的存在交错，应该在ovr文件中用+号标记。ovr.txt: 1547 - 1548 - 1563 - 1566 - 1569 - 1570 - 1571 - 1572 - 2184 -之后我们通过tfm载入之前的log和ovr文件，并引入PP、decimate。MPEG2Source(d2v) tfm(d2v=d2v, mode=3, pp=4, slow=2, chroma=true, input="log.txt", ovr="ovr.txt") tdecimate(mode=1)这里说明一下，通过input载入之前的log文件可以提高tfm的速度，因为tfm直接从log文件中读取之前做过的计算结果，可以不用再次进行匹配了。而input（也就是tfm自己的计算结果）和ovr文件中指定的策略、参数冲突的时候，ovr的优先权高。

虽然这种工作对于OP/ED来说比较繁重，但是这样通常能够得到更完美的效果。

后记：
TFM的ovr功能超级丰富，几乎可以匹敌手动IVTC的效果。而配合output参数，我们可以用更高的效率来得到更好的结果。
关于p、c、n、b、u等匹配方式，以及通过ovr来指定pattern其实也不是很困难，tfm的readme里面都有很详细的说明。有时间的同学不妨阅读一下。

学棒球

昨天跟杨超同学去一中操场学棒球。从投球和击球学起，我自然是学得……一塌糊涂-_-||嘛…从零开始慢慢来。球被球棒打出去的时候听到清脆的“叮”的一声的时候真的是超爽啊～杨超同学不愧是学了三年，他抛出来的球我总是能打到，相反，我抛出去的球总是不是近了就是远了。
话说，我这学棒球的动机也真是够龌龊的，不知道真正从心里热爱棒球的人如果知道我是因为看了棒球动画才开使喜欢棒球的会有什么反应呢。
最近很显著地感觉到体力的下降，稍微多走一些、累一些就会觉得很疲劳。大学懒惰了三年，把体力都懒惰没了。

津京高速铁路首日乘坐体会

今天（马上就要变成昨天了-v-）是津京高速铁路开通第一天，刚好需要去北京，所以就顺便体会了一下这条高速铁道。
天津站是新建的，铁路是新修的，动车组是新造的，北京南站也是新建的，连通往北京南站的各条公交线路都是新开通的，一切都是新的。
CRH3型动车组、铁轨、控制、调度的资料该公开的公开了，不公开的似乎也没有公开，所以这里主要描述一下我的主观体验。另外，最近我正在写一篇中国的和谐号动车组与日本的新干线高速列车进行对比的文章，请期待。

由于适逢奥运期间，天津站开站第一天安检非常严格。进入售票大厅的人数收到了限制，每个进入售票大厅的人都要打开行李进行检查，并使用金属探测器(?)对身体进行检查。我的书包里面只有一台笔记本电脑，裤兜里只有手机和钱包，所以在排队10分钟后很快通过了安全检查进入了售票大厅。买票很很顺利，票跟以往的红色火车票不同，是蓝色的，下方印刷了一个序列号，提供自动检票机识别。因为今天是城际铁路开通第一天，天津站还没有正式开放，仅销售12：00以后的车次。最后一班津京D字头动车组于10：40从天津月牙河临时火车站开出。
（GX29拍照的效果实在太糟糕了，请原谅）

我买到了下午1：40的车，一等座。图片是没有经过检票的车票，检票之后序列号部分会印上一个倒三角形标记，车票上部被印上一个方形标记，示意车票使用过。
之后就是漫长的等待。12：10左右，我进入了天津站。进站时同样需要经过安检，这次是X光机+金属探测器。
坐扶梯进入二楼之后，展现在眼前的是宽阔明亮的中央候车厅（实际上也就只有这一个候车厅）。

我在这里等了两个小时，但并不寂寞，我把电脑拿出来看了一会田中大神的创龙传。顺带说一句，因为我没关AirPort，所以电脑不经意间搜到了两个无线信号，一个叫tkytj3，这个信号是加密的，还有一个H3C WBR204g+，这个是没有加密的。我进入了后者的网络，得到了一个192.168.1.15的IP，可惜不能上网，我尝试性地登录192.168.1.1（默认网关），应该是一台路由器，需要密码，我随便试了一个弱密码就进去了（管理员显然没有更改无线路由器的默认密码，我只试了一次就成进入了管理界面，很惊人不是！）。因为我很纯洁很善良，所以就没在他们的路由器里做一些什么恶作剧之类的，只是四处看了看他们的设置就出来了。

咳咳，说正事，没过多久，就有广播提示检票上车（开车前15分钟）。
顺序排队、检票，没有什么波折，之后乘扶梯进站台，一辆动车组停在站台旁。我找到了7号车厢，进去（废话），对号入座。我前面有一个中国人一个老外，还有两个CCAV记者，左边有两位看起来像是领导的人物。
1：40列车准时开车，5分钟之后开始加速，不久稳定在320kM/h左右，一段时间之后再次加速，稳定在额定的运动速度350kM/h。
列车运行非常平稳，因为采用了无缝钢轨，完全没有D字头动车组的振动感（到途中车站附近的时候因为道岔回产生颠簸感）。之后列车员分发了5100水。
30分钟之后，列车准时到达北京南站。因为是第一天，北京南站的情况还是稍显混乱的。地铁还没有开通，出站不是很方便（我要去的地方就在地铁站旁边，所以对地铁比较依赖）。

单从这一次的感受来说，C字头高速城际铁道无论从速度还是乘坐体验已经超过了日本的新干线。（新干线的铁道不是无缝钢轨，最新型的N700型新干线列车的运行最高时速是300kM/h）。高速铁路在中国的发展速度着实惊人，但是我们应该在不断引进技术的同时，更应该注重国外的运营经验。毕竟，新干线在地震等自然灾难多发的日本平安无事故运营数十年可是十分值得佩服的。
国内自从去年运营动车组之后大小事件不断，一方面确实是我们经验不足，另一方面，理应归咎于某些垄断部门责任心和管理的缺失。