首次处理BDMV(Hisaishi&MiyazakiAnime 25 Years)的心得

波折的BDMV音轨处理
拿到了“久石让与宫崎骏一起经历的25周年”BDMV，热情满满的要rip第一个BDRIP，不过，上来就被超大 的PCM音轨难住了。

按照以往的经验，用dgavcindex把h264数据索引出来同时抽取音轨，不过，抽取出来的音轨是RAW格式 (PCM)，即只含数据，不含描述(sample rate，depth，channels这些)，不能直接用foobar转成其他格式。
于是 google，转而使用了TsmuxRe，不负所望把2ch和6ch的两条音轨都抽成了wav。不过一看结果傻眼了，6ch这条音轨因为体积太大，被分割 为4G和1.8G两个wav文件，开始猜测tsmuxer使用fat32的系统盘做缓存，导致4G文件限制问题，后来lbs告知，这是wav格式的问题， 前4个字节用来记录文件大小，但是FFFFFFFF只能表示4G，所以，tsmuxer为了wav能正常播放，主动按4G大小切割出来了。
群里的 john大大提议，把pcm喂给flac就可以了，flac支持参数制定音轨的采样等信息。好，马上试试。不过，flac.exe有2G文件限制，生成的 flac超过2G程序就会结束。于是悲剧没有结束。。。
按理说，到了BD横行的这个时代，这种超大文件处理不可能没有简单易行的方案的。等秋月上 线了一问，答曰：eac3to。这个我本来也下了，还是gui版呢，不过打开gui一看，哇，烦不烦，连搜教程、摸索使用都懒了，放弃放弃。不过经秋月一 说，我突然想到，他是让我用cmdline程序处理而不是gui，尽管运行eac3to一看help，超简单超好理解 OTL
eac3to xxx.pcm xxx.wav -2 -24 -48000 -big -4ms，搞定，6G的wav出来了(这时候我还不知道这个超4G的wav其实已经废了OTL)。乐呵呵地去转成tta(上面提到flac有2G限制，所 以转投了tta)，不过处理到1.6G就报告成功退出了，后来我知道，大概是eac3to把实际大小写到wav头去，但是超过了4字节被截断，被截断后的 文件大小就是这1.6G了。崩溃，那这还有什么方法啊。ttaenc.exe又不支持pipe，只能喂它wav，wav废了还搞什么。
抱着死马当 活马医的心态，试着跑eac3to xxx.pcm xxx.flac -2 -24 -48000 -big -4ms，奇迹出现了(其实是正常现象-_,-)，生成的flac顺利跨过2G的坎继续跑下去，跑完生成的这个 文件也正常播放。大概，2G限制只是存在flac.exe而已，在报错的时候，人家也说了，是“该编译版本不支持2G+”，而eac3to是调用 libFLAC.dll来压缩，但是文件是由自己处理，解决的官方编码器的2G限制问题。
接下来再来个aac，eac3to xxx.pcm xxx.aac -2 -24 -48000 -big -4ms -quality=0.5。
事情完美解决了。
补：eac3to 是支持从evo/vob中直接抽取音轨的。不过我没试过。

总结一下：
1、PCM是只包含音频数据，不包含samplerate、 bite depth和channels信息。
   可以使用eac3to或者flac制定必要的参数信息后输出为各种格式。
2、 wav，只支持4G以下的成品。这是因为wav格式的头4个字节用来记录文件大小，然而4字节最大就是4294967295，即4G。
   tsmuxer的处理方式：以4G的单位分割。
   eac3to的处理方式：不理会。最终大于4G的文件大小照样写入4字节中，导致错误wav信息错误。
3、tak，只支持单声道和双声道。
4、 tta，输入不支持pipe，即只能接受wav，鉴于上述wav的限制，此次不应该派上用处。而且，还没看见过有人把tta用到视频封装去呢 -，-
5、flac，官方编译的编码器flac.exe有 2G成品文件限制。
   但是，提供libFLAC.dll这个编码库，eac3to即利用该库开发不受2G限制的flac压缩功能。


BD 的SUP字幕
本来打算用BDSup2Sub 转成idx/sub，在用idxsubocr出来srt的。
结果ocr出来结果缺失和乱序好严重，不知道为什么。。。之前ocr奎 爷的dvd字幕表现还超好了。
不知道是不是BDsup2sub转出来的东西有问题，反正就放弃了，直接挂idx/sub吧 -,-

视 频处理
1080p的视频，噪点满载，超级模糊。
于是，ffft3gpu(sigma=3)强力降噪然后720p输出。
于是，问题 来了：
1、ffft3gpu是使用显卡降噪的，但是，一旦显卡负荷过重（例如还妄想开个片子看看），就不是慢就能了事了，直接就让降噪结果rp。 反正目前使用经验，我的HD2400 128MB，压制480p dvd的时候，还可以看片，没出现过rp。但是这次处理这片1080p片，不说看片了，显卡输出屏幕都是卡卡的,OTL。曾幻想着试过打开播放器，结果就 是40个小时的压制泡汤。ffft3gpu rp的话并不会抛异常停止之类的，直到压制完成后，检查才知道。
2、2小时的2pass的编码需要 40个小时左右。由于外接硬盘，要是不小心碰一下松了，x264就直接退出，白干活。
另外，发现有个陷阱，假如压制输出在本地硬盘，而输入（即 m2ts）在外接硬盘，一旦外接硬盘掉了，x264不会退出，仍然若无其事地继续编码。最终的结果是，编码结束查看的时候发现，在编码到把硬盘断线前的几秒会被一直循环。估计是x264的缓存处理有问题，读不进新的数据，旧的就不会清除，于是，一直取缓存中的旧数据，直到编码到最后的帧数。
权衡一下决定trim出来4段，每段30分钟左右，花一个晚上压制，这样能保证不出现人为干扰的rp问题。
最后用copy /b a.h264+b.h264+c.h264+d.h264 new.h264来合并。
mp4box来mux，大功告成。
3、 vx大大在群里提到说，假如直接trim的话，可能会在trim的地方rp。
他举出的实例是某anime的前后两话是渐变过度的，简单地想用 trim分割的话，就会杯具。
aki提议dgindex里根据idr截取。
我在处理的时候是找出场景直接变换的地方来trim，倒没有悲 剧。