ビデオ日記６

・２００４年１２月１６日

• DVD EASY PACK
  
  　前からTMPGEnc3.0が気になっていたが、アクティベーションが嫌で買っていなかった。まあ2.5で十分って気分もあったが。そこにTMPGEnc DVD EASY PACKである。どうやらアクティベーションがないらしい。私はDVD作成しかしない（AVI出力なら他のツールを使う）ので、これで十分だろう。というわけで購入してみた。これが出るまでは、MPEGやDolbyのライセンスがうるさい（簡単にコピーされるような配布の仕方は許さないとか、どれだけの数がユーザーに渡ったのかちゃんと把握しろとか)のかも、と思っていたのだが、そんなわけではなかったようだ。
  
  　まあTMPGEncがいいと思っている人は3.0を持っているだろうし、アクティベーションが嫌だった人はこんな半端なソフトじゃ満足しないだろうし、かといってソースを突っ込んでカット点やフィルタやメニューをデザインすれば手頃なサイズのイメージを自動的に作ってくれるって程には簡単ではないので初心者には勧められないし、売れる要素がどうも見つけられないソフトである。これが売れるようだと「アクティベーションＮｏ！」って人が多かったってことで、私としては嬉しいんだけど。これが売れないようだとペガシスはアクティベーションなしを出さなくなっちゃいそうだし。この後アクティベーションなしのTMPGEnc3.0（あるいは3.5とか4.0）が出ちゃうとちょっとショックだけど。
  
  　で買ったのはいいのだが、まだ使っていない。それどころかパッケージを開けてもいない。
  
  
• YUV444->420プラグイン 0.04
  
  　Avisynthを使っていたときはよかったのに、DVD2AVI+Aviutlにしたら下方向に僅かな色ずれがでるという話。Avisynthを使ったときのYUV420からYUY2への補間の仕方と、DVD2AVIでAviutlで読み込んだときの補間の仕方（これはDVD2AVIがやっているわけだが）が異なっている、ってコト。Avisynthをどう使ってどう確認したかがわからないが、前者でも補間がどかこで（Avisynthなのかフィルタなのかデコーダーなのかプレイヤーなのか）行われているハズ。
  
  　で、AvisynthでOKだというんだから、それと同じ補間をかけてやればいいということ。補間なしとかを見せると「なにコレ」って言われるのがおち。ノイズ除去とか言ってるのでアニメだ→ノンインタレース化って流れが予想できるし。補間なしで読み込み後、適当なYUV420->444フィルタで気に入ったものを使用すべし。補間後にノンインタレース化するのがいいのか、ノンインタレース化したものを補間するべきかは知らないが。（私はノンインタレース化して意味のあるものを扱ってないので）
  
  　その後の話ではAvisynthの補間のもよう。これは（SSEならば）m2v.auiと同じようなので、m2v.auiを使ってればよさげ。
  
  　ってことで久しぶりにプラグインを更新。この話に出てきたリンク先に従ってインタレースのYUV420にするときに3/4+1/4を行うものを追加。
  
  YUV444->420化フィルタ(004)
  
  

・２００４年１０月１８日

• AVSDeliver AVIUTL 出力プラグイン 0.03
  
  　いろいろと問題が残っていたのが気になっていたのをようやく修正。まずはfunc_get_video_ex()で普通にYUY2データを得るようにした。これにより常にYUY2で渡すようになって速くなった。続いてYUY2フレームキャッシュありの時には、フレーム送信後に次のフレームを要求しておき処理をオーバーラップさせるようにした。aviutlとエンコーダーが別CPUになるのならばキャッシュをオンにした方がよいかと思う。逆に単一CPUのときにはなしのほうがいいのかもしれない（フレームあたり数百キロバイトのコピーがなくなる）。
  　ちなみに私はエンコーダーは未だに決めかねていて、キャプチャ・エンコードのやる気がちょっと減退している。CCEはどうも出力品質に疑問があるし、TMPGEnc3.0ではVBR出力時にこのプラグインが使えない（おそらく２パス目のファイル読み込みがすぐに行われるので、AVIUTLのバッチ処理のファイル切り替えが間に合わない）ってのが痛い。CCEではちゃんと使えるんだけど。
  
  AVSDeliver(0.03)
  

・２００４年１０月４日

• AviSynth TCPDeliver
  
  　YUV->RGB変換を行うとそれなりにデータが落ちていることがわかってしまった。さすがにこれでは気になってエンコードできない、ってことでTMPGEnc2.5に代わる次のエンコーダーを探すことに。現状、TMPGEnc3.0かCCE-Basic/SPかってことになる。素直に行けばTMPGEnc3.0なのだが、ここのライセンス方式がどうにも気に入らない（というよりはこのようなライセンス方式が広まって欲しくない）ってことで手を出す気になれない。CCCDやデジタル放送のコピーワンスのようなものだろうか。素直にVFAPIをYUY2対応にしてくれればよかったのに。しかもYUY2渡しは一度中間AVIファイルを出さないといけないようだ（avs読み込み不可の件はどうなったんだろう？）。てなわけでこいつを買う気はない。
  
  　一方のCCEはAviSynth対応をうたっていて、AviSynthで編集したものを食わせることができる。AVSで渡せるので中間ファイルを出す必要もない。というか、AviSynthでも使わないとリサイズやmpeg読み込みやその他もろもろできないことが多すぎる。しかしAVIUTLからの場合には直接は渡せないのでやっぱり中間ファイルを出さないといけない。VFAPI経由やフレームローダーではRGB渡しになってしまう。
  
  　何かうまい手は．．．と思ってAviSynthを見ていると、最近出た2.5.5からはTCPDeliverなんていうものが追加されている。クライアントからサーバに対してフレームを要求すると、サーバが該当するフレームを送り返してくる。元々はサーバとクライアントが別マシンで、それぞれで処理を行うことで分散処理を考えているようだ。（そういえば昔VFAPIで同様のことをやっていたが、そのときの結論は通信速度がネックになるので「意味なし」だったような．．．）フレームデータを非圧縮で渡すときには、１フレーム(720x480)はYUY2の時に700Kバイト近く、RGB24では1Mバイトくらいもかかっている。
  　これを使ってAVIUTLの出力プラグインでサーバを作れば、AVIUTL->AviSynth->CCEと渡せそうである。それならば素直にAviSynthを使えよ、とかマルチパスエンコードするなら中間ファイルを出したほうがいいよ、とかいう突っ込みもあるが。
  
  
• AVSDeliver AVIUTL 出力プラグイン
  
  　TCPDeliverのソースを見て、LANアナライザでパケットを見て、試しにコンソールアプリを作ったりして、一応機能する程度にできたのがこれ。
  
  AVSDeliver(0.02)
  
  使い方
  　あらかじめAviSynth 2.5.5をインストールしておく。avsdeliver.auoをAVIUTLのプラグインフォルダに入れると、プラグイン出力にAVSDeliverが追加される。オプションとしてポート番号と、インターレース/プログレッシブ、トップファースト/ボトムファーストの選択ができる。ファイル名を適当に入れて保存すると、サーバーが接続待ちとなる。ファイルは作られないので名前は何でもOK。WindowsXP SP2の場合には接続待ちの警告が出る。
  　クライアント側ではスクリプトファイル.AVSに次の１行を入れると、サーバに接続にいき、ソースを得られる。パラメータ類はHelpなどを参照。単にAVIUTLの出力を他のアプリに渡したいのならば、この１行のみでもよい。ただ接続待ち時間が数秒しかないのが難点だ。最後の"None"は圧縮形式を示すが、他に"GZip","Huffman","LZO"の指定ができる。"LZO"はアニメ向き、"Huffman","GZip"は実写向きだという。
  
  TCPSource ("127.0.0.1",22050,"None")
  
  　あとはAviSynthで加工するなり、AVSを別アプリに渡すなりすればOK。普通はRGB24渡しだが、YUY2フレームキャッシュプラグインを入れてチェックしてあると、YUY2渡しとなる。クライアント側でファイルを閉じればAviUtlの方は通常の画面に戻る。YUY2フレームキャッシュはキャッシュがないときだけRGBデータを得るようにしているので、キャッシュとして機能しているはず。とはいえこいつの場合には通信がネックになるのであまり役に立っていない。
  
  　なおAviSynthのTCPDeliverではいろんなフォーマット（YV12とか）で渡せたりするのだが、このプラグインではその辺りは全くできていない。
  
  

・２００４年９月２９日

• 色空間の話(YUV->RGB変換)
  
  　前に色空間の話として書いたことがあったが、あれは本当はYC伸張・縮小の話であった。今回は本当に色空間の話である。
  
  　「YUY2データをRGBにすると変換誤差でデータが失われる」ということがよく言われる。TMPGEnc2.5までは(VFAPI経由で)RGBだったがTMPGEnc3.0ではYUV処理になって情報の欠落がなくなったとか、M2V.VFPではRGBなのだがM2V.AUIにすればYUVで取り込めるので変換によるロスがないとか。私はそれがどれほどのものかよくわかっていなかった。単に丸め誤差によるものだけならば、たかが256中の1〜2程度なので大したことはない（キャプチャやエンコードなどでそれくらいの誤差は簡単に発生している）。
  　だがYUV空間はY方向への円筒形なのだがRGB空間はR,G,B,黒,白を頂点とした３角錐を重ねた形である。これを見ると、特に輝度の高いところや低いところでの情報が相当減っていそうにも思える。YUVでは最大輝度のところでも色情報が乗せられるのに、RGBでは最大輝度は白にしかなりえない。ちなみに右はPCCS表色系。
               
  
  　実際にキャプチャしたデータにそのようなデータがほとんどないようならば、RGB変換によるロスもほとんど関係ないと言える。逆にそのようなデータが多いようだとやっぱり気にしないといけないだろう。このロスはYUV->RGB変換時に負になったり255をオーバーしたので0や255にカットしたことによって発生する。しかしPC上でプレビューやオーバレイでそれを確認したくてもできないのである。なぜならばそれは表示のために（AVIUTLやビデオカードが）RGBに変換していて、削られた状態でしか見ることしかできないからだ。nVidiaの時にはオーバレイでは見えていたような気もするが、ATIではオーバレイにしても確実に見えない。オーバレイの調整を行っても無駄である。nVidiaはオーバレイが伸張しないことがいい方向に出ているのかもしれない。
  
  
• RGB化チェックフィルタ
  
  　というわけでいつものようにAVIUTLでそれを視覚的に確認できるフィルタを作ってみた。内部YUVをRGBに変換してみて、0より小さくなるか255を超えるかする部分のみを表示している。まじめにdoubleで公式どおりに処理しているので重い。（詳細はソースを見て欲しいが）R,G,Bのチェックボックスはそれらのチェックを入れたところだけを調べる。upperは上限を超えたところを、lowerは下限を超えたところを調べる。デフォルトでは全てチェックが入っているので全ての限界を確認できる。スライダーは+-いくつまでを誤差として無視するかを設定する。内部値としてRGB値は0〜4095となるが、これに対する1〜32である。デフォルトである16では-16〜4111までを範囲内と判断する。通常のRGBは255までなので内部では16倍されている。従って一度8bitに落ちたときには16程度までの誤差が発生しうる。
  
  RGBチェックフィルタ(0.01)
  
  　YUY2キャプチャしたものをこれを使って見てみると、特に明るいところでの情報落ちが結構あることに気づく。RGBキャプチャしたものでも多少見られるが、「許容幅」を増やしたり、拡張色調補正のYのgainを減らしたりするとすぐになくなる。
  
  
• RGB化でのデータ落ちを確認する
  
  　では実際に見てみよう。
  
  　このファイルは適当にYUY2キャプチャしたデータである。（サイズの都合で320x240にして1フレームに削ってある。）これをAVIUTLに読み込んで、先のRGBチェックフィルタをかけるとこうなる。
  

  元の絵	RGBチェックフィルタON これだけのデータがRGB化の際に飽和している

  　結構な部分が範囲外である(まあそういう絵を選んだのだが)。波形表示すると何てことないものに見えるが、RGB表示すると赤がずっと最大にあって飽和していることが分かる。これはヒストグラムのRGBで見ても確認できる。

  YUVの波形表示 問題ないように見えるが

  RGBの波形表示 完全に赤が飽和している

  
  　このAVIファイルをTMPGEnc2.5に入れてMPEG保存し、それをAVIUTL+M2V.AUIに取り込んでみる。プレビューで見ても違いは分からないが、RGBチェックを入れてみれば一目瞭然、情報が相当消えている。（なぜこの段階で完全になくなってないかはよくわからない。TMPGEncやM2V.AUIやAVIUTLでのRGB-YUV変換での誤差やMPEG圧縮時の情報丸めではないかと思われる。）拡張色調補正でY(gain)を少し減らしてやると一気に情報がなくなる。
  

  TMPGEnc2.5でMPEG化後 プレビューでは何てことないが

  RGBチェックをかけてみるとこのとおり

  Y(gain)を-5したもの

  　そこでYUVのままでMPEG変換をしてやると．．．と思ったが、私はRGB変換なくMPEGにできるツールを持っていないようだ。VideoStudio7.0SEやDVD Movie Writer3.0SEでMPEGにしてみたが、共にTMPGEnc2.5と同じ傾向であった。
  
  

• RGB化の対策
  
  　ここでRGB変換があるときの対策を考える。
  
  １．AVIUTLの拡張色調補正でRGB(gain)を抑え、TMPGEnc2.5のカスタム色調補正(RGBコントラスト0原点)で元に戻す。
  ２．キャプチャ時にいわゆるTVスケールで取り込み（本当は違うが）、TMPGEnc2.5でBasic YCbCrで出力するチェックを入れる。
  
  　どちらでもできそうだが、１をやってもTMPGEnc2.5内部ではRGB処理を行っているようでうまくいかない。２ではかなり問題を減らせるが全て解決するわけではないし、階調をある程度損していることになる。まあRGB変換してしまうことの限界だろう。
  
  
  ２の方法でMPEG化したもの
  これを見るとかなりの部分を救えているのだが．．．
  
  

  元の絵をTVスケールにしたもの

  ２の方法でMPEG化したものをTVスケールに これ以上はどうしようもない

  
  　結論としては、
  ・やっぱりYUVで処理を行いたい
  ・RGBにするならばストレート変換にすれば情報落ちは結構軽減される
  ・PC画面上ではその情報落ちを直接確認することは難しい
  というところだろうか。
  
  　ちなみにAVIUTLの拡張色調補正でRGBデータをいじってみても変換による情報落ちは確認できない。このRBG変換のときには切り捨てていないのだろうか。
  
  
  

• YUV-RGB変換式
  
  　ところでYUVとRGBの変換式は次のようになっている。（Y,R,G,Bは0.0〜1.0）
  
  Y = 0.299R + 0.587G + 0.114B
  
  　これを見れば分かるとおり、RGBで一番明るい赤を持ってきても最大輝度には程遠い（0.299でしかない）。また
  
  R = 1.000Y + 1.402V
  G = 1.000Y -0.344U -0.714V
  B = 1.000Y + 1.772U
  
  を見れば分かるとおり、輝度が高い部分に色差があるとすぐに飽和してしまう。逆に輝度が低い部分ではすぐにマイナス値となってしまう（U,Vは-0.5〜+0.5）。R,G,Bの計算上とりうる範囲は
  
  -0.701<R<1.701
  -0.529<G<1.529
  -0.886<B<1.886
  
  となる。これらを0〜1.0に制限しているために情報落ちが起きる。RGB値をマイナスや1.0を超えることを許しているシステムではこの情報落ちは発生しないので、RGB化することのデメリットはほとんどなくなる。
  

・２００４年９月２７日

• YUV420->YUV444補間
  
  　また逆の考えで4:2:0データを4:4:4（あるいは4:2:2）に補間するフィルタも作ってみた。すなわち1,4法でサンプリングされているとき、1,2法でサンプリングされているとき、それぞれに適した補間方法を選べるようにしてみた。またm2vで行われている補間方法も選べるようになっている。縦の0が補間なし、1が1,4法向け、2が1,2法向け、3がm2v式である。プログレチェックを入れると、1と2は下ラインのみに上下の平均を取り、上ラインは変化しない。プログレの3はm2v法である。横方向にチェックを入れるとYUY2->4:4:4に補間する（左は変化なし、右は隣との平均）。
  
  YUV420補間フィルタ(002)
  
  

  		1,4法	2,3補間 (縦1)		1,2法	3,4補間  (縦2)		m2v法  (縦3)
  1		○	1		○	1		(1ライン*7+-1ライン)/8
  2			0と4の平均		○	2		(2ライン*5+0ライン*3)/8
  3			1と5の平均			1と5の平均		(3ライン*5+5ライン*3)/8
  4		○	4			2と6の平均		(4ライン*7+6ライン)/8
  5		○	5		○	5		(5ライン*7+2ライン)/8
  6			4と8の平均		○	6		(6ライン*5+3ライン*3)/8
  7			5と9の平均			5と9の平均		(7ライン*5+9ライン*3)/8
  8		○	8			6と10の平均		(8ライン*7+10ライン)/8

   
  プログレッシブの時には次のように動作する。

  	2,3補間/3,4補間 (縦1/縦2)	m2v法  (縦3)
  1	1	(1ライン*3+0ライン)/4
  2	1と3の平均	(2ライン*3+3ライン)/4
  3	3	(2ライン*3+2ライン)/4
  4	3と5の平均	(3ライン*3+4ライン)/4

  　この補間方法にはいろいろなやり方がある。例えばMSはここにまた別の方法を出している。（まあサンプリングのやり方も異なるが）
  

・２００４年９月２２日

• YUV420のインターレース
  
  　いつものようにキャプチャしてMPEGエンコードしたものをチェックしていると．．．このように赤ラインが１ラインだけ浮いているものを発見（赤の一番下の部分）。止まった字幕のため、非常に気になる。今回はこれについて考えてみる。
  　結論から言えば、この現象はインターレースで4:2:0でサンプリングしていると発生しうる現象である。
  

  (1)キャプチャしたAVIファイル

  (2)MPEG2にしたもの

  
  　簡単にするためにここでは縦の１ラインのみに注目する。
  
  　インターレースで4:2:0のときにはフレームで見ると次のように色差データが共有されている。1〜8がフレームでのライン数とすると、1,3,5,7がトップフィールド、2,4,6,8がボトムフィールドである。

  ライン
  1(top)	(色差1)
  2	(色差2)
  3(top)	(色差1)
  4	(色差2)
  5(top)	(色差3)
  6	(色差4)
  7(top)	(色差3)
  8	(色差4)

  
  　このとき5ラインと6ラインの境目で赤→黒に色が変わっているときには、4:2:0にした際に色差データの間引きにより赤が浮いたラインが１ラインだけ出てしまう。（赤->16、黒->0）

  	元データ	1,4法	平均
  1	16	16	16
  2	16	16	16
  3	16	16	16
  4	16	16	16
  5	16	16	8
  6	0	0	0
  7	0	16	8
  8	0	0	0

  
  　これが最初のサンプルで起きていた現象である。なお、4:2:2→4:2:0のサンプリングとしては、1ライン目と4ライン目をサンプリングするのが一般的のようだ（本当かどうかよくわからない）。ここではこれを1,4法と呼んでおく（他では聞いたことのないネーミングだが）。この場合には5ラインと6ラインの間、6,7の間、7,8の間のどのときにも１ラインの浮きが発生する。4,5間のときには浮いたラインは発生しない。つまり3/4で発生する。

  	元データ 4,5間	1,4法		元データ 5,6間	1,4法		元データ 6,7間	1,4法		元データ 7,8間	1,4法
  1○	16	16		16	16		16	16		16	16
  2	16	16		16	16		16	16		16	16
  3	16	16		16	16		16	16		16	16
  4○	16	16		16	16		16	16		16	16
  5○	0	0		16	16		16	16		16	16
  6	0	0		0	0		16	0		16	0
  7	0	0		0	16		0	16		16	16
  8○	0	0		0	0		0	0		0	0

  
  　一方、一般的に考えられる1,2ライン目を採用する方法では次のようになり、発生するのは1/4である。

  	元データ 4,5間	1,2法		元データ 5,6間	1,2法		元データ 6,7間	1,2法		元データ 7,8間	1,2法
  1○	16	16		16	16		16	16		16	16
  2○	16	16		16	16		16	16		16	16
  3	16	16		16	16		16	16		16	16
  4	16	16		16	16		16	16		16	16
  5○	0	0		16	16		16	16		16	16
  6○	0	0		0	0		16	16		16	16
  7	0	0		0	16		0	16		16	16
  8	0	0		0	0		0	16		0	16

  
  　また平均をとる方法も考えられる。このとき発生するのは2/4である。（がラインの色は薄くなる）

  	元データ 4,5間	平均法		元データ 5,6間	平均法		元データ 6,7間	平均法		元データ 7,8間	平均法
  1	16	16		16	16		16	16		16	16
  2	16	16		16	16		16	16		16	16
  3	16	16		16	16		16	16		16	16
  4	16	16		16	16		16	16		16	16
  5	0	0		16	8		16	8		16	16
  6	0	0		0	0		16	8		16	8
  7	0	0		0	8		0	8		16	16
  8	0	0		0	0		0	8		0	8

  
  　で、TMPGEncは1,2法のようである。このときの暫定的な対処として、上に２ラインずらしてしまうという手がある。

  	元データ 4,5間	1,2法	２ラインずらす	1,2法
  1○	16	16	16	16
  2○	16	16	16	16
  3	16	16	16	16
  4	16	16	0	16
  5○	16	16	0	0
  6○	0	0	0	0
  7	0	16	0	0
  8	0	0	0	0

  　これで作ったのが下の(3)の絵。この部分だけ見れば問題は分かりにくくなっている。しかし考えれば分かるとおり、他の部分で新たに浮いてしまう可能性がある。
  

  (1)キャプチャしたAVIファイル

  (2)普通にMPEG2にしたもの

  (3)色タイミング補正-8してMPEG2

  　ちなみに1,4法の時には6,7間で変化していたときには同様の処理で誤魔化せるが、5,6間、7,8間で変化しているものでは浮いてしまうことには変わりがない。
  
  
  

• どうしたらいいのか
  
  　ではどうしたらいいのか？実はエンコードで完全に消すことはできない。状況はYC混合されたものを完全には分離できない（ドット妨害、クロスカラー、残像）のと同様、一度間引かれた色差データは元通りには戻せないのである。普通は再生時に適度に補間処理を入れて浮いたラインを目立たなくさせるのだが、そうでない再生系も多い。逆に補間処理を入れてしまうと縦方向の色の解像度が落ちて色がにじんだ感じになってしまうのでまた問題になる。
  　これがインターレースで4:2:0の時の問題である。ノンインターレースの時には少なくとも色が浮くことはない。
  
  ・対策１
  　色タイミング補正で0/0/-8/-8にして、様子を見る。
  
  ・対策２
  　4:2:0化フィルタのサンプリング方法を変えてみて、様子を見る。＋色タイミング補正も試す。
  
  ・対策３
  　ノンインターレース化する。
  
  ・対策４
  　放っておいて、再生系での補間に任せる。
  
  
  　というわけで4:2:0フィルタをちょっと変えてみた。このフィルタを通してTMPGEncに渡すことで、TMPGEncのサンプリング方法を無効にしてこのフィルタの方法に変えることができる。方法は上に挙げた1,4法、1,2法、平均法がある。プログレッシブチェックを入れると、1,4と1,2は上サンプリングに、平均は平均を取るようになる。また水平方向にも左サンプルか平均かを選べる。
  
  　　4:4:4->4:2:0フィルタ(0.03)
  

・２００４年９月１２日

• LDプレイヤー(PIONEER CLD-919)
  
  　今まで使っていたLDプレイヤーは壊れていてCAVが再生できなくなっていた。そこで中古屋を探して目をつけたのがCLD-919だった。こいつはえらく古く、90〜91年頃のものらしい。それでも当時の上位機種で、20万くらいしていたようだ。他にも激安のCLD-R4とか、DVD兼用のもの(DVL-919とか)とかもあり、新しいので故障や劣化については比較的安心できるのだが、高い割りには性能がいまいちって気がするのでパスする。正直キャプチャ専用に使い、CLD-01程度で十分だったのでDVD機能はもちろん、両面再生、ドルビーデジタル、DTS、3DYC分離、デジタルメモリーなどの付加機能はまったく必要としていなかったのだが。
  
   　どれにするか散々迷った挙句、CAVを全部キャプチャする程度に動けばいいやってことで古いが高性能そうなCLD-919にしてみた。家に帰って動作チェックし、使いたい機能には何の問題もないことを確認した。キャプチャ画像はちょっと???だ（悪いがCLD-01との差がよくわからない）。そして音はアナログ音（LD側のDAC）とデジタル音（USBサウンドのDAC)とがぜんぜん違う音なんで驚いた。LD側の音は厚みが大違い。これと比べるとUSBのはペラペラな音に聞こえてしまう。このプレイヤーのDACは8倍オーバーサンプリングの20bitというやつで、この辺りや電源周りなどで差が出てきているようだ。まあキャプチャにはデジタルアウトしか使わないので関係ないが。
   　今後はこれでCAVを中心にキャプチャする予定。
  
  
• SRC(Sampling Rate Converter)
  
  　LDではデジタルサウンドは44.1kHzで収録されているが、DVD化にあたっては48kHzにレート変換をしないといけない。今まではSSRCというやつを使っていたが、音楽ものをキャプチャしてLPCMで作ってじっくり聞いれいるとちょっと不満があった。
   　そこで他にレート変換できるものを探して、デジオンサウンドライトというUSBサウンドに付属していたソフトでもレート変換が可能なことがわかり、CDリッピングしたデータを元に試してみた。
   　品質的にはほとんど問題ないというか、SSRCとの違いがほとんどない。しかしじっくり聞き比べてみると、高音部での表現などははこっちのほうが好ましい。SSRCでは高音楽器(ハイハットとか)の分離が悪くて他の音と混じった感じだし微妙なテンポのずれが感じられたが、DigiOnSoundLightでは元と同じくちゃんと分離して聞こえる。逆に問題点は感じないので、変換は手間だがLPCMにするときにはこれで変換することに決めた。（ただ、本当に微妙な差ではある）

http://www10.plala.or.jp/p205tb16/video6.html

坂井瑞穂