下午阵雨

下午本来想去NHK放送技术研究所举办的新技术展的,放学的时候还是薄云,结果吃过饭从荞麦屋一出来就发现天空阴云密布,似乎马上就要下起来的样子。早晨听信了天气预报没带雨伞,于是只好作罢回家。

结果果然不出所料,我坐的电车刚驶出地下区段,就见豆大的雨点从天上砸下来。到站之后赶紧往家跑,一进家门,外面就下大了。整个城市笼罩在一片瓢泼之中。

瓢泼持续了半个多小时,就逐渐停了下来。西边的天空率先放晴,金色的西洋洒下来非常漂亮。傍晚的天空充满了幻想色彩  XDDD (图片点击放大)

(前三张手持,最后一张三脚架拍摄。)

Bookoff的全场百元书

学校附近书店不少,比如都营地铁D5出口不远就有一家博文堂,西口京王百货里有家启文堂,旁边小田急百货里还有家三省堂。穿过JR线到东口那边走两步就是纪伊国屋总店,纪伊国屋对面的三越百货里还有一家淳久堂。

其中规模最大、种类最全的大概是纪伊国屋总店了,而且终日人潮汹涌,生意很好。不过我更喜欢对面的淳久堂。人不是很多,比纪伊国屋安静多了。而且很喜欢他7楼的文艺·文库区,很安静,很有氛围。

不上次和同学去学校附近的一家サイゼリア(西餐厅),才发现学校往北走竟然有一家Bookoff。Bookoff是日本一家专门经营二手书和二手音像制品的连锁店铺,可以花很便宜的价格买到二手书。今天放学之后抽时间去里面转了两圈,竟然发现了一本「風を見た少年」的原作。这个剧场版动画我高中的时候看过,超级感动,于是赶紧买下来,原价590日元(不含税)的书才100日元(加上5%的消费税最终价格是105日元)。

PS.更新了相册,传了一些日比谷公园、皇居、上野公园、高尾山的照片上去。

过期DVD简评 星界的纹章/星界的战旗

 

最近就星界系列进行了诸多考察,结合了网上的一些传言,得出了以下结论。

关于制程:

1.纹章和战旗I是35mm胶片,由一家叫做Video Pack Japan的后期公司进行Telecine数字化。从画面上来看,应该是Telecine后通过模拟复合信号输出,采集端应该是劣质3D滤波器进行的色亮信号分离。因为是3D滤波器,所以dot和彩虹不算特别严重的那种,却因为3D滤波器设计得不好造成了严重的残像,甚至出现了3帧内串扰的现象(第n帧中串入了第n-2帧的部分图像)。我隐隐约约地觉着胶卷过带和DVD之间应该还有些别的什么过程,不然不应该造成这么严重的画面问题。只可惜具体怎么弄的只有参与制作的人员才知道。不过,也有可能做YC分离的3D滤波器芯片有bug。据我所知东芝的某款芯片就有很严重的设计缺陷,某些情况下会产生严重的残像。如果看制造年代的话,差不多刚好是那个年代会用到的东西……真令人发指。结合最近的一些很不专业的制作看来,只能说日本很多映像行业从业人员对于专业知识的缺乏简直到了叫人震惊的地步。

强调一下,色度和亮度两个信号一旦复合,是没有办法重新分离开的,带交错的串扰更是导致根本没办法做IVTC。顺带说一句,Lodoss也是这种制程的,根本没办法压。

这种类型的片子如果能够用现在的设备和制程重新做HD Telecine的话,画质会有脱胎换骨的提高,可以直接做出来24p的BD。

2.战旗II是35mm胶片由Sony PCL进行的HD Telecine,画质非常棒,几近完美。WOWOW曾经播过FullHD版本(卫星频道),不过似乎没见到过录像……目前入手可能的版本只有downconv下来的DVD。

3.战旗III据说是原生HD制作,不过没有BD而已。因为II和III已经出了Emotion the best系列的DVD-BOX,所以短期内BD差不多可以断念了。非常幸运的是,当时的DVD是老制程,用色差输出到电脑采集,所以线条边缘很漂亮,没有光环,画面上留下了analog noise,正好起到了debanding的作用。大概是07、08年那阵DVD似乎是改了制程,用HDCAM的图像输出给劣质resizer缩小分辨率,导致了明显的光环(TT的DVD就是这种)。

 

近期BD简评 True Tears BDBOX

最近TT很热门,于是我也出手了。

首先大致说一下TTBD的制作流程(以下内容源自官方网站,括号中为笔者注释)。

  • 负责动画制作的P.A. WORKS是在1280*720@30i下完成摄影的。
  • 为了兼容电视放送格式,带交错进行upconv,制作了1440*1080@30i的HDCAM母带(*resize1)(*母带1)。
  • 制作DVD版的时候,以上述母带1为基准进行downconv到SD分辨率,制作了母带2。这个母带2是DVD的母带。
  • 制作BD的时候,以上述母带1为基准,再次rescale,制作了1920*1080@30i的HDCAM-SR格式的母带3。这个母带3就是BD的母带。

因此BD虽然不是从DVD做upconv而来,但经过数次格式转换,质量损失在所难免。由于当初动画制作时的资料已经不全了,所以要做BD只有这一条途径。简单总结一下本篇要点:

  • 大部分片段为HV1280i-(SPICE)型upconv。片中散见重制的镜头,重制镜头应该是在Frame状态下扩大后才Telecine的。
  • 由于经过数次格式转换和重新采样,所以画面显得模糊,远不如当今原生HD分辨率片源制作的BD清晰。(但就算这样画质也比起DVD版有了决定性的提高)
  • OP画中画内外pattern不同。
  • 正片的IVTC准确率相当高。暂时没有发现30i的Fade。
  • ED比较复杂。BD的ED应该是重制过的,但是由于背景采用了老版本的HV1280i upconv素材,所以变得非常麻烦。背景动画是30t在交错状态下upconv到1080@30i的,然后再打上了1080@30p的滚动字幕。

BD的特典比较丰富,但同样问题不少:

  • 第一卷的实拍节目是SD拍摄后带交错upconv到1080。
  • NCOP同样面临画中画问题。
  • NCED很简单,直接反upconv后IVTC即可。
  • 新作特典短剧是1080@24p,不需要处理。
  • Vol2附带了很多版本的健康建议,有24p的、30p的,还有30t upconv后的30i做背景打上1080p字幕的,还有带30i渐变的。
  • TV CM是30t背景叠加30i字幕再在左右加上黑边做的。

TT的问题比较少,不过处理起来同样比较棘手。我的做法:

  • 首先明确主导思路是还原原生分辨率,做720p。做1080费力不讨好,也没必要。
  • 其次需要将upconv画面和非upconv画面分开处理。
    • OP、正片中绝大部分镜头、次回预告是upconv,由于散落在正片中的重制镜头没办法逐一跳出来,所以统一反upconv。反upconv的参数用Destripe(360, 4, 2, 3)会比较好。
    • ED是混合型,由于没办法把画面内部的upconv和非upconv部分分离,所以我统一deinterlace之后resize缩小到720p。这是同时照顾到背景和字幕的折中之策。让背景不至于难看,前景字幕也不会因为反upconv出现锯齿。
    • 由于要保证滚动字幕的流畅性,所以这里ed保留30fps,正片24fps,用timecode实现vfr。
  • 其次是为了实现OP的完美IVTC,需要分段后通过这个脚本对画中画内外部分单独处理。
  • 全部处理完成后,resize到1280*720。译个人口味添加锐化之类的改善观感。

特典:

  • 实拍特典要assumetff()后用Destripe(240, 3, 4, 3)反upconv成1920*480后deinterlace再resize到720*480。
  • 其他特典没什么好说的了,30t的就IVTC,30p的直接压,24p的也直接压。因为字幕全都是1080打上去的,所以就不做反upconv了。
  • NCOP和正片OP一样对付画中画。
  • NCED直接反upconv后IVTC即可。
  • TV CM砍左右黑边到1440*1080后直接deinterlace。

以上为1、2卷做法。第3卷还没开始弄,等开始弄之后再补充吧。

近期BD简评 聖痕のクェイサー

相信这个BD有很多人已经看过了,TV就很极品的画质到了BD也一样极品。对于这个BD,vx童鞋已经写了他的看法,不过生气归生气,这里简单归纳一下这个BD的问题和对应方法。

圣痕炼金士在制作过程中应该是1280*720@30i,也就是说虽然那分辨率上升到了720,但依旧采用了SD时代的制作方式。制作时,将做好的720@24p素材进行Telecine转换成720@30t之后进行特效、合成、剪辑等操作。不过实际上本片的制程则更加混乱。这点从一些小细节上就能窥知一二:

  • OP是背景动画部分和飘带特效分别Telecine之后叠加而成。OP的工作人员字幕是720分辨率下加上去的。
  • 片中的Fade In和Fade Out有些是30i,有些是30t。30i部分是Telecine之后剪辑的时候加的Fade,而30t则是24p部分就加好了Fade,之后再Telecine。
  • ED的字幕是将背景的动画部分由720i分场纵向扩大成1080i之后通过1080p(/i?)打上去的。
  • ED中部分镜头的画中画有可能是和背静分别Telecine后合成的(这个还不确信,暂时算保留)。

可见,这个片子的制作过程混乱到了简直令人发指的地步,丝毫不见专业性。如此混乱的编辑方式,有可能是源于日本动画通常采用分镜头外包加工的现状造成的。不同外包公司完成的不同规格的画面最终被以这种不负责任的方式拼接到了一起。看来还有好多厂商完全没习惯HV制作的样子。

由于绝大多数日本电视台采用的母带标准是HDCAM(Squeeze 16:9 1440*1080@30i),所以为了迎合这个标准,720i的画面只能带着交错分场进行resize,对画面造成了很大的伤害(线条发虚、细节损伤等等),这个过程成为upconv。虽然说是upconv,但具体操作方法各种各样。各个厂商采用的方法不一而足,甚至同一个片子在不同电视台播出所采用的方法都是不一样的。目前尚没有人公布过具体方法,所以目前一切处理基本都是在“盲目”和“经验”下进行的。

由于BD中的数据采用了MBAFF来存储,所以导入avs之后加一个assumetff()或许会好点(可能对IVTC会有些正面的帮助)。

为了还原原始分辨率的图像,日本职人写了Destripe这个AviSynth脚本(和辅助滤镜插件)。AviUtl平台上则有インタレース維持リサイズ和クロスコンバート補正プラグイン两个插件。

经过Destript作者的总结,带interlace的upconv主要有四种,其中常见的两种他分别起名字叫“HV1280-i(GONZO)”和“HV1280-i(SPICE)”。聖痕のクェイサー在播出的时候是这两种的混合体,再加上电视台自主规制的部分,变得相当复杂。不过BD似乎比较单纯的是SPICE的类型。

对于GONZO型的片子,Destripe的作者给出的参数是Destripe(360, 6, 4, 3),不过这个片用这个参数的话,线条边缘会出现微妙的锯齿,用Destripe(360, 4, 2, 3)可能会好一些,不过就算这样线条也依旧会发生奇妙的“疙疙瘩瘩”的感觉,看起来并不顺。这里可以用去锯齿滤镜来掩人耳目,或者加一个warpsharp或许也可以达到改善线条的效果。此外,ED的字幕是在1080打上去的,所以经过处理之后字幕本身一定会有锯齿,这个问题是没办法解决的。或许ED整个用PureVideo Deinterlace之后缩小到720会好一些?

Destripe输出的反upconv画面是1920*720i,所以依旧需要做IVTC。这里简单说一下反upconv和IVTC的关系。通常比较容易想象到的思路是,由于upconv产生的纵向条纹会干扰到IVTC滤镜的判断,因此在反upconv后做IVTC似乎会比较合理一些。事实上迄今似乎没人统计或是总结过反upconv对IVTC准确率的影响,因此理论上先做IVTC和后做IVTC似乎都可以(下次写True Tears BD-BOX的时候还会说这个问题)。

由于聖痕のクェイサー的制作相当混乱,所以给IVTC带来了巨大的困难:

  • 难点1:30i的Fade。
  • 难点2:OP的丝带特效,由于丝带动态高又抢眼,和背静的pattern又不同,所以基本可以看作30i,每帧都有动态。
  • 难点3:正片匹配率低,PP误判率高。

以上是处理这个片子的时候需要注意的问题和总体思路,中间夹杂了一些基础知识和臆测,欢迎拍砖。八仙过海,各显神通。

DGAVCIndex到DGIndexNV索引文件的转换

最近遇到一个奇怪的现象,就是DGIndexNV经常会打不开一些m2ts文件(比如《聖剣の刀鍛冶》的一些部分),错误提示说:

—————————
Warning
—————————
Cannot find audio data. Ensure that your PIDs
are set correctly in the Stream menu. Refer to the Users Manual for details.

Hit Yes to continue notifying this specific error type; hit No to disable it.
Hit Cancel to suppress all further errors.
—————————
是(Y)   否(N)   取消  
—————————

而同一个m2ts用DGAVCIndex就能顺利打开。但是又需要用NV的PureVideo Deinterlace来做Deinterlace。于是我打起了dga的主意,看看格式相近的两种Index文件能否进行互相转换。

幸运的是,无论DGAVCIndex生成的dga文件还是DGIndexNV生成的dgi文件都是单纯的文本文件,只需要用记事本一类的纯文本编辑器打开即可进行编辑。而DGIndexNV的文档中也存在dgi文件格式的说明。AVC对应的dgi文件分为四个段落,MPG和VC1对应的索引格式略有不同,详细请参考DGIndexNV文档。

第一个段落是文件头信息。
文件的第一行是文件版本号,用来实现DGDecodeNV.dll和DGMultiDecodeNV.dll对索引文件版本号的识别。版本之间一一对应,没有跨版本兼容性。第二行是DGDecNV存在的路径,不过说白了应该是证书文件的路径,用于以上两个dll载入的时候寻找证书文件。然后是一个空行进入第二节。

第二节是m2ts文件信息。
该小节描述m2ts文件的路径和大小。每行前半部分是m2ts的绝对路径,后半部分是m2ts的大小(字节)。间隔一个空行进入第三节。

第三节是设置区。
这段基本与dga相同,只有一行需要更改,因此本文略过不加详述。间隔一个空行进入第四节。

第四节是索引数据区。
这段基本与dga相同,只需要添加一行。第四节最后有两个空行。

以下是修改方法:
1.第一行文件版本由“DGAVCIndexFile7”改成“DGAVCIndexFileNV5”,然后换行,加入DGIndexNV的路径。
2.在第二节的m2ts文件后面空一个空格,加上文件大小(字节数)。
3.把第二节最后一行的DGAVCIndex路径删除。
4.删掉第三节中间的“FO 2”这行。
5.在第四节最后一行加入“0.00% FILM”。

以下是修改前(dga):

DGAVCIndexFile7

d:BD0000.m2ts
d:DGAVCDec

STREAM 1
PKTSIZ 192
VPID 4113
FO 2
YUVRGB 1
LUMFILT 0 0
CLIP 0 0 0 0
RANGE 0 6369386495
AUDIO

[第四节省略]

以下是修改后(dgi):

DGAVCIndexFileNV5
d:DGDecNV

d:BD0000.m2ts 6369386496

STREAM 1
PKTSIZ 192
VPID 4113
YUVRGB 1
LUMFILT 0 0
CLIP 0 0 0 8
RANGE 0 6369386495
AUDIO

[第四节前半部分省略]
0.00% FILM

这样一来,DGIndexNV无法处理的m2ts文件就可以经由DGAVCIndex索引后,通过修改索引文件的方法让DGMultiDecodeNV加载并deinterlace了。

对Blog的前端略作改进

昨天大概花了一上午加一晚上的时间对Blog的操作性和细节进行了小小的调整。Waki-Blog的核心代码已经将近一年没有进行过重大的调整和维护了,对于一个人从零开始建造并维护这样一个工程我自己都有点惊讶。

昨天主要改进了三个地方,两处前端一处后台。

1.在页首添加了工具栏,改善操作不便。

此前Blog的功能链接我都放在sidebar里,但目前这个主题再放在sidebar里的话怎么弄都不好看,于是只好放进了footer里。但功能链接放进footer里所带来的一大问题就是操作非常的不便。这次就在header里增加了一个工具栏来弥补这个缺陷。目前的设计是:
·在登录前,工具栏显示“登录、注册、移动版”的链接(目前我关闭了注册,所以看不到注册链接)。
·登陆后根据用户权限自动显示用户可以进行的操作。
·页面载入完成之后,工具栏从不透明渐变成70%透明(先通过透明度渐变动画提示用户工具栏的存在,然后淡出其在视野内所占比重,让用户的注意力重新回到内容上去)。鼠标移入工具栏区域后恢复不透明,移出后恢复透明。(一切都拜jQuery这样一个便利的东西所赐啊……

2.美化了Ajax登录窗

不多说了,只是微调了一下CSS和HTML。

3.改进了JavaScript载入的方式。用php将后台7个.js文件(225.7kb)整合、打包、压缩、缓存、输出,压缩后33.8kb,只消耗一次HTTP请求。

此外,从去年起我就决定在此后的前端中只在最低的水平照顾对IE的兼容性。只保证IE浏览下的排版和可使用性,不照顾任何IE的美观需求。因此,透明、圆角、覆盖等特效一概不保证在IE能够顺利使用。不是我抛弃了IE,是时代抛弃了IE。

四颗螺丝导致的杯具

1月29日下午,日本东海道新干线“回声659号(16辆编组300系)”通过新横滨-小田原区间时接触网(架线)断电,双向轨道完全停运3小时,影响56辆列车共15万人出行。

东海道新干线停运

初步调查结果是一个1985年安装的辅助吊线架在列车通过时损坏导致架线断裂。随后,刚才那辆“回声659号”的集电弓在辅助吊线架不远的地方被发现。因此很多人初步推测是那个1985年以来从未更换过的吊线架在腐蚀、断裂之后与集电弓发生碰撞,结果集电弓被pia飞了,架线被扯断了。

但是后来的调查结果令所有人大跌眼镜——吊线架被冤枉了,问题出在列车本身。

要想说明白这个问题先要从集电弓的构造说起。列车从接触网(架线)取电,需要一个弓形的结构与接触网接触,称为集电弓。这个集电弓是由一个具有弹性的臂状结构支撑的。臂状结构负责将集电弓向上顶起,使其与接触网接触。二者之间由4根螺丝进行固定。

1月27日,这辆出问题的“回声659号”在东京大井车辆基地进行车体检修的时候,发现6号车和12号车的集电弓出现磨损状况,需要进行更换。工人更换集电弓之后本应用螺丝将集电弓和支撑臂进行固定,但这人杯具地忘记了这点,更换之后没拧螺丝就把集电弓玩了“放置play”。而更加杯具的是,这个工作是由两个人共同进行,其中进行最终确认的那人竟然没有发现这点。

于是这辆“餐(惨)车”就这样开出了车辆基地,28号早晨还在东京和新大阪之间跑了个来回。当它跑到出事的新横滨-小田原的时候,集电弓飞了出去,具有弹性的支撑臂向上弹起打在了辅助吊线架上,扯断了接触网,于是就停电了……

东海道新干线事故

事故最终被认定为人为事故,而负责操作的工人表示“螺丝和螺栓很多,具体数字不清楚。从螺丝数量上不能判断有没有固定。”

从这个事件上看来,人最终还是成了最不可靠的因素。哪怕是配置两个人的工作最后还是以不可靠收场。人的可靠性靠两点保证,一是可靠的制度和标准,二是人去严格地执行可靠的制度,二者缺一不可。可靠的制度是在事故和问题中不断总结、建立起来的。这点,在最近大刀阔斧四处上马的国内高铁(=高价铁路)尤为值得注意。嘛……TDB本身就是最不靠谱的因素就是了。

改造了一下虚拟机里的Firefox 3.6

利用Strata40这个主题对Firefox进行了一些改造。成果如下(点击看大图):

Firefox 3.6

主要用到的扩展:
Fission 1.0.9 – 在地址栏中显示进度条。
Hide Caption 0.7.6.1 – 隐藏标题栏,并实现迷你菜单栏的效果。原配的迷你菜单栏图标太难看了,于是自己动手PS了一个换进去(地址栏右边那个小齿轮的图标)。
Omnibar 0.6.7.20091104 – 让地址栏和搜索栏合体。
StrataBuddy 0.1.6.9c – 让停止和刷新按钮合体并显示在地址栏右端。同时将标签栏置于窗口顶端。

同时隐藏了书签栏和菜单栏。当隐藏菜单栏的时候,Hide Caption会自动显示迷你菜单栏按钮。
这样一来,Firefox繁杂的窗口马上简洁不少。同时,易用性没有显著下降。简洁、不炫,使我喜爱的风格 😀
因为Strata40在Mac下有问题,StrataBuddy也没有办法在Mac下安装,整个操作是在虚拟机里的Windows XP下进行的。装了插件之后启动照样神速,还是在虚拟机里。FF3.6太神奇啦啊啊啊啊~~