図１ NTSC 信号の色解像度
NTSC 信号はアナログ信号なので、水平方向の解像度というのはあっても無いようなものだと言われています。確かに輝度信号に関してはその通りで、サンプリング周波数を変更すれば、どんなに高解像度なデータも手に入れることが可能です。（ソースにそんな高周波信号が含まれているかどうかは別にして）
しかし、色信号は別で、結構厳密に水平方向解像度を決定することができます。次の図を見てください。
まず、NTSC では色信号は 3.58MHz 成分の基準（カラーバースト）信号からの位相差と振幅差という形に変換されて、輝度信号と重畳されています。（S 端子経由の場合は重畳こそされないものの 3.58 MHz 基準信号からの位相差と振幅差という形なのは変わらない）
輝度信号と色信号が重畳されたコンポジット信号から色信号と輝度信号を分離する方法について書き始めると分量が溢れるので、今回は色信号の水平解像度に関してのみ解説します。図１には色々と余計な数字が書き込まれてたり、２ライン毎に 7.16 MHz 分ずれてたりしますが、今回はそれについては気にしないでいてください。
図１の黒の四角（a,b,c,d すべて）が 3.58 MHz の１ブロックに相当しますが、NTSC 信号では 3.58 MHz に色信号を位相＆振幅変調するため、色信号を 3.58 MHz の単位ごとにしか変更できません。
図１の濃灰色で区切ったブロック（a,b をペアに、c,d をペアにした場合）は、3.58 MHz の２倍の 7.16 MHz に、淡灰色で区切ったブロック（a,b,c,d すべてを別に考えた場合）は 3.58 MHz の４倍の 14.32 MHz に相当するので、もしも 14.32 MHz でサンプリングするならば NTSC の色空間は YUV 4:1:1 形式であるといえます。
14.32 MHz YUV 4:1:1 形式であると考える場合、正方ピクセルの 640x480 と同等の領域での水平解像度は、輝度 748, 色差 187 になります。また、7.16 MHz YUV 4:2:2 形式であると考える場合、水平解像度は輝度が 374 で色差が 187（これは変わらない）になります。
D3 テープなどのコンポジット系デジタルフォーマットでは 14.32 MHz で（Y/C 重畳された）コンポジット信号をそのままサンプリングし、デジタル記録します。ここから再生されるデータは NTSC の壁を超えることはできません。
さて DVD の場合ですが、こちらは 13.5 MHz YUV 4:2:0 フォーマットでコンポーネント記録されているので、水平方向解像度は輝度 704, 色差 352 と、NTSC 信号の２倍近い水平方向色解像度を持ちます。
つまり、何が言いたいのかというと「DVD のソースにコンポジット系素材（NTSC 信号）なんざ使うなボケ」と言いたい訳です。
DVD は、少なくとも水平方向色解像度に関しては、NTSC を超えることのできる器です。素材が古くてコンポジット系ソースしか残っていなかったというなら仕方が無いですが、DVD での販売を視野にいれた映像を作成する場合、コンポジット系テープ素材で作成するというのはバカと罵られても仕方のないことだと言えるでしょう。画質が落ちるので、売上が伸びませんよ〜。
んなこと気にするのはヲがつく人種だけだというのは同意します。が、だからこそ、ヲがつく人種相手に商売をしてる自覚があるのならばそういったことも気にするべきではないでしょうか。
補足。60 Hz システム（いわゆる NTSC）での DV は 13.5 MHz YUV 4:1:1 なので、水平方向色解像度は 176 になり、NTSC よりも劣ります。なんでこんなフォーマットを採用してるかというと、全てはインタレースと 2:3 プルダウンのためです。同じインタレースでも 2:3 プルダウンの無い 50 Hz システム（いわゆる PAL）の DV では 13.5 MHz YUV 4:2:0 形式なので、水平方向色解像度は DVD と同じ 352 になります。
昨日、NTSC 信号は水平方向色解像度が DVD よりも劣っているので、コンポジット系素材は DVD のマスター用に使うべきではないという趣旨の事を書きました。
しかし、コンポジット系素材の最大の問題は解像度ではなく Y/C が重畳（コンポジット）されているという点にあります。
一度重畳されてしまった Y/C 信号を完全に分離できる方法はありません。どんな分離方法を採用してもドット妨害やクロスカラー、残像などのノイズに悩まされることになります。例えば次の絵は１次元 Y/C 分離に特有の、ドット妨害ノイズの例です。
本来直線になるべき縦の色境界線がギザギザになっているのが見えると思いますが、これがドット妨害です。もう一度、図１に登場してもらいます。
図１で、２ライン毎に 3.58 MHz のブロックが半分ずつずれています。左右に書いてある数字は行番号です。左に書いてある数字がトップフィールドの行番号、右に書いてある数字がボトムフィールドの行番号です。なお、ここでの行番号はインタレース送信データの走査線順での数値になっています。図１には横方向で 3.58 MHz ブロック４つ分しか書いていませんが、実際にはこれが 187 個存在してます。
まず、色信号は 3.58 MHz 成分の基準信号に乗って重畳されるのですが、NTSC 信号の水平周波数 15.734 kHz で 3.58 MHz を割ると 227.5 となり、１ライン毎に丁度半分ずつずれていきます。
有効な画像情報を載せることのできる最初の走査線である２２ラインが図１の位置だったとすると、その次の走査線である２３ラインでは 3.58 MHz ブロックは水平方向に 7.16 MHz 分ずれた位置に来ます。さらに次の走査線である２４ラインでは再度 7.16 MHz ずれて、元の場所に戻ります。これ以降でも同様に繰り返しながら進み、ボトムフィールドの走査線に到達すると……。ボトムフィールドの最初の有功走査線は 285 ラインで、奇数の走査線なので、やはり 7.18 MHz 分ずれますから、図１のようになります。
これらを踏まえて、もう一度図２を見てください。なんとなくドット妨害の原因がみえてくるかと思います。
Y/C 分離はクロスカラーのいいサンプルが手に入っていないため一時中断。そのうち続きを書く予定です。
さて、TMPGEnc の MPEG ツールでも出来たような気がしてたのですが、実際に試してみると駄目だったので作ってみました。MPEG-2 の 23.976/24 fps ストリームを 29.97/30 fps ストリームに RFF/TFF 書き換えて変換するツールです。cine2tv-0.1.0.lzh から落せます。
あちこち手を抜いて作ったのでいろいろと制限があります。まず、プログラムストリームには対応してません。当然トランスポートストリームにも対応してません。
さらに、コマンドライン用で GUI はついてません。えーと、皆さん既に m4c で慣れてるみたいだから大丈夫かな〜と思ったりもするのですけど……。
……ごめんなさい。プログラムストリーム対応と GUI の作成は日曜日に手をつけます。今日のところはこれぐらいで勘弁してください。
あと、私は H+ も DVD-R も DVD プレイヤー（専用機）も持っていないので、PowerDVD でのテストしかしてません。一応再生はできて、再生時間が短くなるようなことは無かったので大丈夫だとは思いますが、基本的に人柱用だという事を忘れないように。オリジナルのストリームは残しといた方が良いですよ〜。
メールチェックしてバグ確認。_open() で _O_CREATE フラグを忘れていたという大変頭の悪いバグだと判り、何故テストで気がつかなかったのだろうと悩む。
どうやら _lseeki64() を使おうと途中で fopen() から _open に切り替えたため、テスト中は既にファイルが存在していてバグに気がつかなかったらしい。反省。処理状況を表示しようなどと考えなければ良かったのだろうか。
その後、デフォルトだと作成したファイルが読み込み専用になっているとか、テスト環境で DiskFull のため途中までしかファイルが出力できなくなっていたりとか、シーケンスヘッダに書き込む fps が間違っていたりとか色々バグがあったので修正。
cine2tv-0.1.1.lzh から落とせるのでどうぞ。
日曜は寝倒してたので新機能の追加はなし。PS 対応からぼちぼち進めてる。速ければ明日あたりに PS 対応版が出せそうだけど、GUI 版はちっと時間がかかるかもといったところ。
cine2tv-0.2.0.lzh PS に対応したつもり。つもりというのは、いつものようにあまりテストをしていないからだったり。
それでも 0.1.0 のようなことは無いはず。一応一通り動くのは確認して、再生でもエラーがないことを確認したけど、ストリームによってはエラーになる可能性もあるから。
バグが出た場合は報告をお願いします。
Code Red II はどうやら全体的にすごい騒ぎになっていた模様。職場のあれはまだ可愛いほうであったらしい。昨日ネットワークが遅かったのも Code Red II のせいだったらしいのでびっくり。
そのためかどうかは不明だけど、今日はまだ会社（職場とは別）の POP サーバに繋がらないのでメールを読むのがつらい。サーバからメールを取ってこようとするたびにタイムアウト待ち状態になるので。
えぇっ！ GUI 版作ってくれるんですかぁ。ありがとうございますぅ。まだぜんぜん手をつけてなかったんですよ〜。と、大半の人には意味不明の戯言を発しておいて。
しばらく間があいちゃったけど 前回 の続き。今回は２次元 Y/C 分離です。何度も出てきてるのでいい加減飽きてきたかもしれませんが、一応もう一度 図１ を見てください。
２２ラインと２３ラインは色信号が 7.16 MHz 分（半周期分）ずれています。つまりこの二つの走査線部分の原画像が全く同じものであったとしても、色信号は半周期ずれたものが重畳されていることになります。実際に図を書くと次のようになります。
これは２２ライン（黒の波線）と２３ライン（赤の波線）が同一色で塗りつぶされている場合の NTSC 波形に等しいのですが、ここで、両走査線の信号を足し合わせると色信号を除去して輝度信号を取り出すことが、片方から片方を引けば輝度信号を除去して色信号を取り出すことができます。これが２次元 Y/C 分離の原理です。
２次元 Y/C 分離を使用すると色境界は次の図４の右上部分のようになり、ドット妨害は解消されます。しかし、今度はクロスカラーという新たな問題が発生します。
図４の斜めの直線に色信号が乗っているのが見えると思いますが、これはソース映像には含まれていない信号で、２次元 Y/C 分離の副作用として現れたものです。これをクロスカラーといいます。
前後のラインで輝度信号が同一の場合は２次元 Y/C 分離で完全に色信号と輝度信号を分離できるのですが、走査線間の輝度信号に違いがある場合その違いを色信号と誤認識してクロスカラーにしてしまうのです。クロスカラーは２次元 Y/C 分離の宿命であり、まず避けることはできません。
２次元 Y/C 分離では斜めの線や輪郭部分にクロスカラーノイズが発生しますが、これを解消する目的で考案されたのが３次元 Y/C 分離です。
まず、第１フレームの２２ラインが正位置であったとします。すると、第２フレームの２２ラインは 7.16 MHz ずれた位相反転位置になります。60 Hz システムでは１フレームの走査線数は 525 本なので第２フレームの２２ラインは第１フレームの５４７ラインに相当し、偶数走査線と奇数走査線になるのでそれぞれ 7.16 MHz ずれた位置になり、同位置では位相が反転します。
この状態で２次元 Y/C 分離と同様に、NTSC 信号を足し合わせれば輝度信号を、引けば色信号を取り出すことができます。これを３次元 Y/C 分離といいます。サンプルは次の図５を見てください。
３次元 Y/C 分離の弱点は、２次元 Y/C 分離の弱点と同じです。２次元 Y/C 分離は隣り合う走査線の中身が同じであることを前提にした分離方法なので、斜めの線といった走査線間で違う内容のデータが含まれている場合にクロスカラーが発生しました。３次元 Y/C 分離の場合、前後のフレームで同じ走査線には同じデータが含まれていることを前提とした分離方法なので動画部分では正常に分離ができずにノイズがでてしまいます。
ノイズのサンプルと詳細についてはまた次回に。
３次元 Y/C 分離の続きは東芝 YCS6 チップのエラーを発症させるサンプルがまだ作れていないので暫くお休み。あ、GUI 版ありがとうございます。ありがたく頂きました。
ん〜と、そういうわけで、こちらでは cine2tv の GUI 版はつくりません。欲しい方は DVDExploring@aNythingElse から頂いてください。
今ナニをやってるかというと、昼休みにちょっと本屋まで出かけては LaLa DX 立ち読みしてたりします。嗚呼ダメ人間。
同じく現実逃避として、今更ながらフーリエ変換しらべてます。いいかげんフルバ＆スクライドの初めに入る時報がむかついてきたので。時報って 1kHz のトーンだから、先頭１秒に対して フーリエ変換 -> 1kHz 成分除去 -> 逆フーリエ で何とかなる……はずなんだけど。
ちょっと不安だけど、こういう AviUtl プラグインってなかったよね〜。あと、私の記憶が正しければ、AviUtl 0.96i でしか動かないプラグインは SSTP プラグインだけだったような。使ってる人って居るのかな？
なんで日曜なのに更新してるのかというと……昨日夜に M1 が落ちてるのに気が付いてた人なら判りますね。つまりそういうことです。家人が「雷が鳴ったから」とほざいて M1 のネットワークケーブルぶち抜いてくれてました。
ありがたくて涙が出そうです。折角の日曜なのに片道電車賃 1000 円＆２時間使って実家に戻り、ケーブル元に戻して PC の再起動。ついでだから SP2 と Code Red パッチも当てときました。WEB サーバは Apache なので当面は安全なのですけど、FTP が IIS なもので。
Windows 2000 で動く（サービスタイプの）オープンソースな FTP デーモンか、もっと言えば SSH デーモンがあれば良いんですけどね〜。素直に FreeBSD か Linux にしとけという声がどこからか聞こえてくるような気もしますが……。
さて本題。時報の除去ソフトですが、FFT ルーチンは 大浦 さん の FFT パッケージをそのまま利用することにして、コマンドラインから WAV ファイルを扱うものであれば何とか動くものが出来つつあります。
今のところ、フルバの OP をサンプルに実験中で、最初のピアノの音が上手く保持できずに悩んでます。やっぱり 1 kHz 成分の単純除去を目指すのではなく、逆位相の 1 kHz トーンを作成してぶつけるアクティブノイズリダクション形式の方が良いのかな〜と。
これだけだと別に阿呆でもなんでもないんですが、とりあえずバンドエリミネートフィルタ形式で AviUtl のプラグインにしようかと考えた時点で気が付いちゃったんです。「私は AviUtl で音を扱ってない」ということに。
M4C で処理する都合上、音の切り出しには VideoMaid 使ってるし、エンコードはレベル調整兼ねての SoundEngine (Lampy) 経由の gogo.dll だし。独りで使うだけならバッファのコントロールとか気にせずに、WAV ファイルを扱うだけで済むスタンドアロンの CUI 版で充分なんじゃないかな〜と。実際に作りはじめるまで気が付かないあたりが阿呆ですね。
ただ、まあ言っちゃったことだし、AUF 作ります。一応除去時間と除去周波数とサイドバンドの幅と窓関数を指定できる形にする予定でいますのでよろしく。今日帰らずに済んでれば４時間作業できたんですけどね〜。遅れ気味です。
んーと、現状での処理サンプルだと これ が こんな かんじになる。処理パラメータは 2048 点で FFT かけて、85 番（996.01 Hz）を中心に左右に 20 点分の周波数情報を完全に除去してから 逆フーリエしたもの。一応先頭 2 秒に対してのみ処理して、残りの 6 秒分は生データのまま。
どうも FFT のサンプルポイント数も可変にしなきゃいけないようなので、AUF つくるのはかなり面倒。あ〜、FILTER_PRIORITY_HIGH が必須かも。
なんとか今日中に完成させないと、明日の放映に間に合わないわけでちびっと焦ってる。の割には昨日は帰宅してすぐに寝てしまったからさっぱり作業が進んでないし。
の〜割には M1 が本日正午あたりからまた死亡してくれたようなのでどうしてくれようかという気分。関東だと今日は天気も悪くないはずなのにいったいどうしてなのでしょう。ping すら通らないし。最低。リブートだけで復活してくれるようなら良いのだけど。
えーと、時報の除去は今のところフーリエ変換でやる方針で作業してるのだけど、実際のところフーリエ変換の場合、次数が少ないとピークが広がってしまうし、次数が多いと時間変化に追随できなくなるしであまり良くないのかもと考えた。
そゆことはまず性能低くてもいいから動くものをリリースして、それから考えろと言われると正論なだけに耳が痛いのだが、現実逃避。
さて、フーリエ変換は割鶏焉用牛刀という感じがするわけで、別の方法がないか探してみようかと考えてみると、また表記のゆれが……。
特定周波数帯だけを除去するフィルタのことを、私はバンドエリミネートフィルタと呼ぶものだと思っていたのだけど、ざっと調べただけでも「ノッチフィルタ」・「バンドリジェクトフィルタ」・「バンドストップフィルタ」の別表記がみつかる訳で、英語で検索してもこれが同様だったりするから嫌になる。
仕方がないからハイパスフィルタとローパスフィルタを組み合わせるかと考えて HPF の設計方法を検索してみても、出てくるのはアナログフィルタの作り方のみ。うっが〜チェビシェフにもバタワースにも LC 回路にも興味はないんじゃ〜と喚き出したくなる。やっぱり適当な信号処理の教科書買っといた方が良いのかも。
久しぶりにまじめにお仕事。Ruby Net::SMTP で protocol::readline が何故か初回のみ 30 秒きっかりブロックするのであちこち調べる。環境は RedHat 7.1J ほぼデフォルトに ruby-1.6.4 をソースからコンパイル。
最初は CGI 側で $stdout.close とかやっときゃ良いのだろうと思っていたのだが、どうやら $stdout.close 時点で apache から CGI は殺されてしまうらしい。
仕方がないのでまじめに調べ始める……が、断念。何故か ruby-win32 では発生しないらしいというのが唯一の収穫。なんとなくカーネルの再構築を試すと改善しそうな気もするのだけど、面倒なので回避。
諦めて fork に逃げることに。リファレンスマニュアルを眺めても良く分からず、サンプルを探しても見つからなかったので、とりあえず fork do 〜 end でブロッキング部分を囲んでみるかと試す。どうやら正解だったらしい。
てなわけで無理矢理完成させた時報除去用 AviUtl プラグイン。AUF から落とせます。コマンドライン版はパラメータ変えるたびに再コンパイルが必要な欠陥品なのでとてもリリースできません。
ちうか、最適な設定値を探すためにもリアルタイムで波形をモニタできる AviUtl プラグイン形式は非常にありがたいわけでそれが主目的で作ったものだったりする。いちいち設定変えてコンパイルして動かして PCM 編集ソフトで読み込んで波形眺めて聞いて確認してって気が狂いそうになってくるから。
まだ動くものが完成したばかりで、さっぱり最適値を見つけられてないのだけど、今のところ第一候補は FFT サイズ 12 (4096) の 幅 50 で窓関数非使用。
設定値によってはノイズが増えて聞けたもんじゃなくなるので、やっぱり DFT に見切りをつけて MDCT+可変ブロックサイズ（MP3 なんかで判るように、一度周波数領域に変換してから逆変換する方法としての実績がある）に走るべきだろうかとか、FIR バンドエリミネートフィルタの方が良いのかもとか、時報除去だけならいちいち周波数領域に変換なんてしないでフェーズロックして逆位相の波をぶつけるのが一番楽じゃないかとかあれこれ考えつつ、とりあえずリリース。
それとも性能が悪いのは単にフーリエ変換を実数領域でのみ扱っているからで複素数領域で処理するようにすれば多少は変わるのだろうか……と悩みが深い。
時報除去の 0.2.0 です。AUF からどうぞ。何とか今日中に実家にもどれました。つか残り 20 分でこれ書きあげることが出来るのかちょっと心配。
えーと、昨日「性能が悪い」とか書いてたけれど、どうやらあれはバグのせいというか……つまり……ロジックが間違っていたというか……その……私のミスだったらしい。DFT のブロック同士を繋げる際の計算でしくじっていて、それで音が悪かったみたいです。
その辺の修正をして、ついでにフェードイン処理も追加して（ってこれは他にプラグインがあったはずだけど、時報除去は他のプラグインとの共存が面倒なんで）ある程度実験して万人向けのまあ納得できるデフォルト値に変更しました。まだエンコードしてなかったら今日のフルバや昨日のスクライドで試してください。
これも昨日の戯言ですが「MDCT+可変ブロックサイズに走るべきか」とか書いてますが、よくよく考えれば実数離散フーリエ変換って DCT とほぼ同じだし、M ってのがブロック同士にすこし重なりを持たせてブロック歪みの発生を抑えることだとしたら、時報除去ってそれと殆ど違わない処理してるので、何言ってんだこいつ状態ですね。
まあ個人的にはほぼ満足がいく物ができたので、別方面からのアプローチは停止します。しばらく離れてたシリアル・ママをこの休みの間に進めておきたいかな〜と思ってます。
えーと、8/2 にドット妨害についてあれこれ書きましたが、それについての訂正です。次の図を見てください。
これは、輝度および色飽和度が同じで、色相のみが違う色が隣同士になった場合の色境界での NTSC 波形です。NTSC 信号では色相を位相変調するので、色相が変わる点では波形に不連続点ができます。
理想 NTSC 信号ならば不連続点が存在できるので、カラーバースト信号にロックした 4FSC でサンプリングし、位相 0 度の点を -Cb, 位相 90 度の点を -Cr, 位相 180 度を +Cb, 位相 270 度を +Cr 信号と考え、それにあわせて Y を決定する 1-D Y/C 分離でも、ドット妨害を出さずに Y/C 分離できるのですが、現実の系ではこのような不連続点を持った波形を送ることはできません。
結果、位相 0 度の点は大幅にずれ、本来認識されるべき Cb とは違った Cb' が認識され、Cb - Cb' 分の色信号が輝度側に漏れ出し、結果ドット妨害になります。
……前 書いたのと違うじゃないか……ですか。えーと一応、あのプログレッシブ状態での 2 行単位での段差はあります。１次元 Y/C 分離では確かに段差が出るんです。
ただし、それはあくまでも垂直方向での段差であって、その段差がさらに水平方向に輝度の異なる点として分断されている説明にはなりません。ドット妨害というのは点状のノイズのことを言うので、NTSC 信号の歪みを考えなければ説明できません。
というわけで >> 443 へ、>> 393 の方が正しいです。名無しさんで書き込むのも、実名であそこに書き込むのもどうかと思ったので、誤解のされようがないこちらに書きました。
言い訳。一応このことは 8/2 を書いた翌日には気が付いてた(証拠： もりのみやこ さんのページの「なんでも掲示板」 8/3 の書き込み参照）のだけど、訂正する機会がなくて放置してました。えと、盲信されてた方はいないと思いますが、いたら申し訳ないです。
オランダ旗でのドット妨害ってこんな形かな。
１が原信号（２ライン）、２が足して割ったもの（輝度信号）、３が引いて割ったもの（色信号）。で、輝度信号が波線になってるのでこれがドット妨害。色信号は振幅が半分になるので（そもそも輝度成分で変なオフセットがつくからどうなるのかあやふやだけど）薄くなる。
ただこういうケースって大昔のガラス遅延管とか使ってたころの２次元処理（適応とか一切考えずにひたすら２次元処理する）場合じゃなきゃ出ないと思うのだけど……最近購入した TV でそれが出たとしたらよっぽどの安物ということになりそう。
検索ワード拾おうと思って Apache のアクセスログと戯れる。Ruby サイコー。何も考えずに書いてるから実行速度は遅いけど、コード書くのが楽。
で、今まで気が付かなかったのはアレなんだけど、どうやら AV Watch 内の某記事から m2v.vfp がリンクされていたらしい。最近アクセス数が増えてたのはツール更新情報系からの流入だと思ってたんだけど、それだけじゃなくあちらからの流入もあったようだ。
もちっとマイナー路線の方が好きだったんだけど仕方がないか。一応リンクは自由にというページだから文句を言う筋合いは無いし。
で、ちょっぴり怖かった検索キーワード。
その１――「やすし」――何故このキーワードでここに辿り着いたのか判らない。多分 IE の Referer 漏れかとも思うのだけど、その割には８月中だけで 8 件も同じアクセスがあったので怖い。
その２――「ΔΣ 具体的 回路」――この辺は私も調査中です。何か判ったら教えてください。ただ、WEB で探す場合は英語で探した方が技術情報は見つけやすいです。或いは大学の図書館などで探した方が情報量は多いかもしれません。
夏休み最終日。実家に戻ってすぐに体調を崩してしまったので殆ど寝倒してしまっただけだというのが悔やまれる。シリアル・ママも内部仕様考えてるだけで時間切れになってしまったし。
休みでかえって調子を悪くしてるんじゃ世話無いよな〜と思いつつ関東の奥地に向けて出発。まあ Referer チェック用のスクリプトをタスクに入れられただけで良しとしますか。
明日からは朝か昼か夕方のみの更新に戻ります。それでは。
明日１８時半までに台風がどこかに行っててくれることを希望するダメ人間。降雨障害で録画失敗したらショック大きいだろうな〜。
スクライドおよびフルバの音は、昨日ようやく時報除去版との置き換えが完了。６話分まるまる音を交換するのはやっぱり疲れた。MP3 から再エンコードしちゃえば楽だったのだろうけど、一応 DV から再取込みしてたもので休みが初日と最終日の２日間潰れてしまった。
もちっと判りやすい VC のマニュアルってないのかしらん。タスクトレイに常駐させたいアプリケーション（タスクバーには入らない）のウィンドウを最小化した場合の挙動を変えたいと思って調べはじめて、結局 OnSystemCommand をオーバライドすれば良い（MFC の場合）と判ったのが 6 時間後。
まぁ、そればっかり調べてた訳ではないけど、OnSystemCommand 自体もクラスウィザードじゃ作れないから意味不明のお呪いを書く破目になるしでますます VC が嫌いになっていく。
今回は３次元 Y/C 分離に特有の残像についてです。まずは次のサンプルをみてください。
上段が原画像で、中段が Y/C 分離結果。下段が Y/C 分離結果の原寸画像（部分）です。見事に色が変化した部分で残像（というよりももはやこれはドット妨害と言うべき）が発生します。
……あまりの酷さ――原因を推測＆計算して一番酷い結果が出るだろうサンプルを用意したから当然なのだけど――に、３次元 Y/C 分離ってものすごく使えない技術なのではと考えてしまったかもしれません。しかし、安心ください。ここまで酷いのは東芝製３次元 Y/C 分離チップ YCS6 を採用している一部のデッキ（Panasonic NV-DM1 とか）だけです。
少なくとも、私が現在 Y/C 分離専用機＆BSチューナとして使用している Victor HR-VTG300 ではこのような残像は出ません。そのかわりクロスカラーが増えますが、ここまで腐った残像が出るよりもマシです。
この残像の原因については、また次回に。本当は今回でこのシリーズを終わりにしようかと思っていたのですが、原因を追求してみたところ非常に笑える結果を得ることができたので、１回で片づけるのは惜しくなりました。
前回のサンプルでは現画像に２つの色しか使用していません。その色を YIQ 変換し、NTSC での色成分信号波形にすると、次の図のようになります。
サンプルで使用した色は「輝度が同一」・「位相は反転」するように選択した色なので、正位置での波形は図のようになります。片方の色で塗りつぶされていた部分が次のフレームで位相反転色に切り替わる場合、二つの波形は全く同一のものとなります。（１走査線毎にカラーバースト信号が半波長ずれるため）
これを３次元 Y/C 分離で処理すると、輝度信号は分離前の NTSC 信号そのものになり、色信号は失われてしまいます。まさしく、前回のサンプル画像が出来上がってしまうわけです。
通常はこのような問題が発生しないよう、前のフレームと現在のフレームで走査線を検証し、相関が低い場合は２次元処理に切り替えるものなのですが、この Y/C 分離チップでは検出機能が弱く、全く違う色信号がのっている場合でも３次元処理を行い、結果として残像（ドット妨害）を発生させてしまいます。
当初は、色相が 180 度回っている場合など、特殊な場合にのみこのエラーが出るものと予想していました。しかし、次の色の組み合わせでも残像は発生します。
図１０は次の２つの色信号を切り替えた場合の残像の発生状況を示したものです。
この２つの色は、輝度が似ている以外、位相も振幅も別に特別な関係にあるわけではありません。むしろ同じ信号だと認識するのが難しいほどだと思うのですが、この場合も（本来実行すべきでない）３次元処理を適用して残像を発生させています。
これだけを見ると、まるで３次元処理を適用するかのチェックに輝度成分の比較しかしていないように見えるのですが、まさかそんな手抜き処理はしていないと信じたいものです。
ほぼ８月中ずっと、途中間を空けながら Y/C 分離について書いてきました。１次元・２次元・３次元、それぞれの処理の欠点を一通り書き終わったのでまとめます。
最良の Y/C 分離方法はありません。そもそも混ぜないのが一番です。混ぜたら最後、二度と元の映像は取り出せません。ので、混ぜてはいけません。
DVD（コンポジットマスターの腐れは別）や CS、SDTV のデジタル BS についてはそれで解決できるのですが、問題は地上波およびアナログ BS 放送などの Y/C 混合された NTSC 信号で送出される映像の場合です。
この場合、最低１度は Y/C 分離することになるのですが、これは個人の好みで好きな Y/C 分離装置を使ってくださいとしか書く事ができません。
現在私が Y/C 分離に使用している Victor の HR-VTG300 は、可能ならば３次元処理を行うが、無理な場合はすぐに２次元処理に切り替える方式です。私はドット妨害よりもクロスカラーが、残像よりもクロスカラーが望ましいと考える人間なので、このデッキは個人的なこのみに合致し、満足できています。しかし、他の方にとってもこれが当てはまるかどうか判りません。
それぞれで、満足の行く Y/C 分離機を探してください。
今月は本気でやばかった。実際どれくらいやばかったかというと、お客様の都合で電気が止まりかけるぐらい。
いや、前日にもうすぐ振り込み日じゃんと気が付いたから通勤定期の購入をしばらく延ばすことでなんとか引き落とし不能攻撃は回避することができたのだけど。
といいつつ来月もやばくなる予定。NOIR ２巻を買ったりやきいもに手をだしたり、９月８日には「歌月十夜」を求めにアキバへ旅立とうとしていたり、あまつさえこの厳しい状況の中でイマサラ PS2 買ったりしてるため。
むーこんなにぎりぎりの生活を続けてて大丈夫なのかしら。
現在熊本城に引っかかっているため不定期更新です。やっぱり FFX も買わずに GPM をはじめるのは今更ですか。
購入自体は今年の初めに済ませておいたのですが、VGS が Win2K で動かなかったり P4 で動かなかったりと色々あり、PS2 購入してようやく開始。とりあえずは絢爛舞踏を目指す予定。
昨晩はほんの少ししか寝てないため今日は半分夢の中に旅立ちながらお仕事。へろへろになりながら来週あたりに行われる予定のデモ準備。
Windows 2000 の IPv6 Technology Preview 相手に調べものしてるのだけど、「RFC2553 を読め」以外に API の解説が一切無いのはどうかと思う。一応サンプルアプリケーションのソースはついてきたけど。
ローカルマシンの IPv6 アドレスを（プログラムから）知りたい場合に何を呼べば良いのかなと思っても、糸口すら無い状態。gethostname() & getipnodebyname() で手に入ったのは結局 IPv4 アドレスだけだったし。
良く判らなかったので避けてた getaddrinfo() をホゲればどうにかなるのか明日調べてみる予定。
Gecko ならもう少しまともになってると思っていたのに残念。Netscape の CSS 対応の話。<UL> とか <OL> タグでインデント幅を変更したいという要求があったため CSS で逃げれるかなと思って調べてみると IE と Netscape で解釈が全然違ってる。
ul = {
margin-left: 1em;
}
と書いた場合、IE ならば上位ブロックの記述領域から 1em 分のマージンを確保してインデントにする（幅は小さくなる）のに対し、Netscape の場合はブラウザがデフォルトで持ってるインデント幅に対して 1em を足したものインデントにしてくれる。（幅は広くなる）
CSS の思想からするとどう考えても IE の方が正しいと思うのだけどな〜。CSS というのは HTML からデザインやレイアウトに関するものを別にするのが目的だよね。IE の場合だと、タグが標準で持っているスタイルを CSS で上書きするけど、Netscape の場合タグに（CSS では変更不能な）標準のレイアウトがあって、それを CSS で補正するという形になってしまうから、HTML からデザイン要素を除くという目的に適合していない気がする。
ついでに書くと、Netscape で上のスタイルと同じ事をしたい場合、次のように指定しなければいけない。
ul = {
margin-left: -2em;
}
当然 IE でこれを見るとトンでもないことになる。これが IE と Netscape が逆なら規格を中途半端に無視するくらならいっそサポートするなと叫んでさんざバカにしてあげたいところなのだけどな〜。個人では Netscape 6.1 を使用中なんで Mozilla の皆さんにはもう少しがんばって欲しいところ。（最新版で CSS フルサポートしてくれるなら、旧バージョンはバグがあるので使わないでくださいといえるから）
で対策としては……
今回は CGI だったから無理矢理 CSS に逃げた（後でものすごく後悔した）けど、静的な HTML の場合最後の手段しか無いような気がする。
個人的に重大な転機が訪れたのだけど、大変良い条件だったのだけど、石橋を叩いて渡らないことに決定。
後悔せずに済むように、日々努力することにしよう。