AAD (Auto Anime Decomb) v0.1.5a - 2009/07/07更新

rextian

为什么载入了ADD脚本还是显示功能出错呢。。。求解。。

LoadPlugin("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\DGDecode.dll")
LoadPlugin("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\vinverse.dll")
LoadPlugin("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\TMM.dll")
LoadPlugin("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\TIVTC.dll")
LoadPlugin("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\TDeint.dll")
LoadPlugin("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\EEDI2.dll")
LoadPlugin("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\a60224.dll")
Import("D:\Program Files\Pure Codec\AviSynth 2.5\plugins\AAD.avs")
MPEG2Source("J:\新建文件夹\11.d2v")
ADD()
==============================================
自抽= =AAD写成了ADD。。搞了半天是自己脑残了。。。。

diseac

找了一段作得比较破的动画，制作了一段样片，用来测试015版本。

AVS：AAD(mode=1,ultimate=true).AUS720(9,2,9,0)

我把原版的VOB也传上来了，有兴趣的朋友不妨尝试一下这个片的IVTC

http://www.namipan.com/d/8f8e810 ... a46947ad153d8f08f09

dgwxx

新年新气象，年关刚过，楼主便送来了热气腾腾的新版AAD。
祝贺新版本发布～

diseac

谢谢dgwxx的支持！

很久没有更新AAD了，在014到015版本之间的这段时间里，我对AVS内的deinterlace方法进行了一些深入研究，总感觉，研究得越多，头绪就越乱。

现在的矛盾主要集中在IVTC的后处理上，也就是AAD的3rd-pass，任何单纯的IVTC插件都很少有可能完美地做到100%判断正确，一套代码也很难完美地应付每一部片子，我想在最近这段时间内整理一下手上的资料，再作一些测试，针对3rd-pass继续更多的优化。也希望对此有深入了解的朋友能给我一些意见和建议，也希望有棘手片源的朋友能分享一下你们的难题，帮助我使AAD的功能越来越强大。

0.1.4是0.1版中最稳定的版本，也是我推荐使用的版本。

下次更新将升级到0.2.0版。

sswroom

找了一段作得比较破的动画，制作了一段样片，用来测试015版本。

AVS：AAD(mode=1,ultimate=true).AUS720(9,2,9,0)

我把原版的VOB也传上来了，有兴趣的朋友不妨尝试一下这个片的IVTC

http://www.namipan.c ...
diseac 发表于 2009-1-27 18:32

剛剛看了一下這段影片, IVTC後完全不用Deinterlace, 細節不多, 不太適合做測試....... 不過影片本身存在不少問題, 要進行修正, 如白邊、Interlaced YUV等

蓝の回忆

感谢更新...
为批量出片提供一条简单途径了..

dgwxx

前些日子压了凉宫DVD，TIVTC做的IVTC，效果很不好。误判的地方比较多，开PP的时候很多帧走了PP，画面抖得一塌糊涂，所以我关掉PP压的。某些片子对于IVTC的相性就很好，某些就很不好。真是困扰= =||

diseac

剛剛看了一下這段影片, IVTC後完全不用Deinterlace, 細節不多, 不太適合做測試....... 不過影片本身存在不少問題, 要進行修正, 如白邊、Interlaced YUV等
sswroom 发表于 2009-1-28 10:26

其实我拿这个片子出来是有原因的，可能S大没有发现。
我用TIVTC(高低cthresh分辨测试)、IT、decomb、a60224等很多滤镜测试，分别会产生不同的错误。
而TIVTC造成的错误甚至无法通过PP或其他手段来修复，还会产生很多文字上的误判！
这个片充分体现的是a60224对于动画的稳定性，以及极低的产生jerk的危险性。
具体位置是在金发女手里的袋子，监督的名字，还有片子最后部分的字幕。
Interlaced YUV我看到了，不过没有想到好的方法来处理。

前些日子压了凉宫DVD，TIVTC做的IVTC，效果很不好。误判的地方比较多，开PP的时候很多帧走了PP，画面抖得一塌糊涂，所以我关掉PP压的。某些片子对于IVTC的相性就很好，某些就很不好。真是困扰= =||
dgwxx 发表于 2009-1-28 16:31

凉宫的片我没有收集，现在也不好弄原版的ISO了，dgwxx如果有时间的话能不能帮我上传几段你觉得比较棘手的片段呢？


在AAD0.1.5版中，大家不妨尝试下ultimate=true这个参数，虽然它现在依然很慢，但效果相对以前强了不少。（色度有错误的片源慎用！顶部有黑边的还是建议使用014版本）
可能大家发现了，015版里EEDI2不见了，取而代之的是nnedi。实践证明去年Holy所说的nnedi算法更好是正确的，只是比较难以驾驭，而且top2px的参数也是因为这个而搞不见的。

sswroom

剛做了一次詳細的比較, 發現diseac壓的版本細節嚴重不足, 出現白邊等。
下面是比較圖:
-訊源(Resize Only)用AVIUTL來找圖, 以Lanczos 3來Resize (Y、C分開Resize成YUV 4:4:4)
-Diseac的版本是用ffdshow解碼和轉成RGB (High Quality), 用MPC找圖
-我壓的版本是用HQMP Normal Quality + Print Screen鍵找圖, 我是用TMPGEnc + AVIUTL + XviD壓的

留心看看
Diseac的版本是1280x720, 但是細節最少, 連「音響監督」4個字的線條也看不清楚, 不知是AAD的問題還是AVC的問題.........
我的版本看起來比較模糊, 但線條變得幼細, 全屏看起來會覺得解像度較高, 因為白邊會令線條變粗, 解像度下降。

diseac

这个镜头用TIVTC的默认参数会出现很严重的匹配错误，aviutl我没试过。
我压的版本只是用来测试015版本的ultimate参数而已，不是在比清晰度。
清晰度低不是x264的问题，而是我使用了ultimate=true和AUS720造成的。
从理论上讲，我压的片段实际上是240p upsize到 720p

lititude

问一下 如果是pal的 会不会也被做到23.976...
我没有pal的dvd 没做过试验

dgwxx

51# lititude
还真是 囧 我也没弄过PAL。
不过PAL需要做IVTC么……

安静

LoadPlugin("D:\GORDIA~1\AviSynthPlugins\KernelDeInt.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\UnDot.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\dgbob.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\Convolution3d.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\FluxSmooth.dll")
LoadPlugin("D:\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\ffavisynth.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\decomb.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\TIVTC.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\TomsMoComp.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\VSFilter.dll")
LoadPlugin("D:\GORDIA~1\AviSynthPlugins\SimpleResize.dll")
LoadPlugin("D:\DVDrip\AAD_v0.1.5\a60224\a60224.dll")
LoadPlugin("D:\GordianKnot\AviSynthPlugins\nnedi.dll")
LoadPlugin("D:\GordianKnot\AviSynthPlugins\TMM.dll")
LoadPlugin("D:\GordianKnot\AviSynthPlugins\vinverse.dll")
LoadPlugin("D:\GordianKnot\AviSynthPlugins\TDeint.dll")
Import("D:\GordianKnot\AviSynthPlugins\AAD.avs")


a=mpeg2source("H:\SHARE下载\VTS_01_1.d2v")
v1=a.AADTrim(0,1136).AAD(mode=1,finalpass=true,ivtc2pass=true)
v2=a.AADTrim(1137,1213).AAD(mode=2,ivtc3pass = true,ultimate = true)
v3=a.AADTrim(1214,2153).AAD(mode=1,finalpass=true,ivtc2pass=true)
v4=a.AADTrim(2154,31883).AAD(mode=2,ivtc3pass = true,ultimate = true)
v5=a.AADTrim(31884,33841).AAD(mode=1,finalpass=true,ivtc2pass=true)
v6=a.AADTrim(33842,34747).AAD(mode=2,ivtc3pass = true,ultimate = true)
v7=v1+v2+v3+v4+v5+v6
v8=v7.lanczosresize(864,480,5,0,-4,0)
return v8

为啥桢会对错。。。出来个2小时的片子- -

diseac

楼上应当仔细看我在说明文档里关于AADTrim使用方法的解释部分。

VempX

上面sswroom帖的，ToLove的OP镜头，那里确实会出现很严重的错误，但是我查看了一下DVD源，似乎DVD源那里就是有问题的edit，在不做任何处理的情况下，直接打开d2v观察，有些帧自身就是锯齿帧，而非interlaced帧，很困扰
我最近在压ToLove，处理的OP那里我只好写了一大段一大段的ovr，快写死我了……

diseac

とらぶる的DVD很考验人。
VempX压完了后注意下第一集火箭从天上掉下来然后地震时的教学楼场景。
另外还有很多地方没法自动判断，所以这套DVD我选择了winrar压缩，全9卷40GB
P.S. VempX请试试 AAD() 来压那个OP，也许你会满意这个结果。

VempX

确实，火箭掉下来那里，画面震动的时候，很多帧都是bad edit，那里写ovr的时候就差点写死我
AAD处理OP真的是做到了完美，不过正片中的一些场景会被误判丢入PP后处理 囧，比如春菜拿着书本走路的时候

这个场景会被误判做Deinterlace

另外我给你发Email问你关于渐变交错是如何杀掉的，你告诉我是vinverse.dll，我查了一下，貌似是一个deinterlace滤镜？其实我在Email里想问的是，如果判断出渐变有交错？AAD的finalpass效果真的非常好，渐变的交错确实都统统杀干净了，但是渐变的交错是咋判别出来的呢？tfm的话，要把cthresh开的非常低才能发现渐变里的交错 囧

diseac

简单地说
1、春菜拿的书上带有横向梳齿状条纹，tfm和tdeint都会把这种条纹判断为交错，如果我用AAD的话，我会关掉2nd和3rdpass。
2、vinverse并不检查任何交错，它的作用是解除细微的交错。那么对P祯会不会有影响呢？答案是对画面质量没有影响。但是，一个P祯，用了vinverse处理的，和不用的，被AVS输出成图象后数据内容有所不同。

先简单说这么多吧，等过几天不忙时抽空做个实验给大家看。

dgwxx

58# diseac
上次试了试，我觉得说Vinverse对P帧没有影响是不确切的。对P帧实施Vinverse之后，画面的细节量会出现一个比较明显的下降（毕竟是无差别地进行了Deinterlace）。因此，Diseac的“对Progressive没影响”这种说法恐怕会引起细节厨的不满，毕竟细节确实是没了，再怎么说没影响也多少有点那个（撇清关系：我不是细节厨 囧）。
迄今为止fade造成的交错确实没人能完美处理，AAD的做法的确是个值得肯定的尝试，从某种意义上来说在“去交错”和“压低对画面的影响”两方面成功地取得了平衡。不知道有没有办法百尺竿头更进一步，要是能将将真正的Progressive和fade区别开来就好了。

我最近想了想（只是空想而已，还没有进行大量实验证实），如何在数学上将真正的Progressive和fade in/out（这里只讨论fade in/out，cross fade完全是另一种情况，应当另当别论）交错之间区分开来，就是说，建立一个数学模型，可以通过数学方法将前后二者进行区分。提供以下几个思路给Diseac参考：
1.Fade in/out一般在几十帧内完成，在这个过程中伴随着全屏幕的luma信号的剧烈变化。就是说要满足的条件有两个：
　1.1 这个变化时间是限定了的，要在几十帧的时间里，两帧不行（画面突然从黑变白，因为这是切镜头而不是fade），几百帧也不行。
　1.2 出现luma变化的必须是100%的像素都在变，而且变化的值要相近（不是相等，因为动画制作过程中是相等，但因为DVD的有损编码会造成不等）。
这里大致又会出现四种情况，白->画面、画面->白、黑->画面、画面->黑，具体实现的时候需要分情况考虑。
2.无论是Progressive还是fade in/out，在经过Vinverse之后，画面的mi必然降低（废话）。我猜测，交错帧在通过vinverse后mi值降低的幅度要大于非交错帧降低的幅度。tfm计算出的mi会随着阈值的改变而改变。那么如果能够找出来，在哪个阈值下，这种区分度最大的话，再加上1中所述的条件，应该就能够找出绝大部分的fade交错了。
3.同时，我们还要小心的是，不能完全相信tfm的场匹配结果。因为还存在另一种情况，那就是，fade是24的，可以通过场匹配来完美回到24。但tfm因为不能正常识别fade的交错，可能会输出错误的匹配。所以，条件2的应用还应该再加上一道保险：mi值的显著降低必须是连续的，才能判定为fade。

以上乱语了一番，毕竟只是胡思乱想。而就算我没猜错，单纯依靠脚本或者插件来实以上判断现也是非常困难的。如果能够将luma变化反应为数值输出log，再结合tfm计算的mi值，专门写一个程序来分析log的话，要识别出此类交错也不是不能做到的。

悍匪

横向细密纹理造成的误判的确头疼，幸好不少动画这样的场景并不多，祈祷新房昭之一样的监督不再出现吧XD。书、地板、某些木板材质、圆形缩放的魔法阵等等图像都容易误判掉
问下diseac 桑，对这样的镜头“关掉2nd和3rdpass”是不是还会有误判出现呢