新年早々なにをやってるんだろうと思わなくも無いのだけど。SSTP プラグインなる AviUtl プラグインを唐突に作成してしまった。
えと、普通のヒトには何の役にも立たないプラグインです。まだ pixelpoly.auf の方が役に立つかな〜っつ〜感じで。
とりあえず なにか をDL してその日のうちに作ったものなので、まだキャラクターを掴みきってません。最初はしゃべる内容もユーザ側で設定できるようにしようかと思ったのですが、スキル不足により断念しました。そのうち何とかしたいところです。
文才無いので、セリフ考えてくれる方募集してます。なんでしたら、そちらでコンパイルまで済ませて配布されても構いません。
中身はソケットと AUF の基本だけで、たいした技術を使ってる訳でもないですから。
やはりスキンを変更すると SSTP 由来のセリフが違和感ありまくり。メッセージによってはかなり痛いものまである。
スクリプトは INI から読み取ることにして、ユーザに設定させようかとも考えたけど、それだとランダムメッセージの実現が困難。予定調和の世界も良いけど、やはり意外性がなければ飽きられてしまう。
どのようなスキンでも成り立つ事務的なメッセージのみを表示させることで逃げるという手段もあるけど、それは嫌だ。せっかく 何か を使うのだから、それなりの遊び心を持ちたい。
とりあえず sstp.auf の現状は、偽春菜専用。もし他のスキンで使用して吐き気をもよおしたとしても無保証。
えんいー
SSTP プラグインを更新。SSTP for 偽春菜 に改名。ついでに送りつける毒電波を多少変更。エンドメッセージのランダム化は一時断念。
偽春菜専用だとしてもまだ痛いメッセージがあるのが悲しい。己の文才の無さを痛感。メッセージパターンを増やしたいのだけど、それ下手にやるとさらに痛いネタが増える。良いネタが思いつかない。
憂鬱。というわけで協力者募集中。
といってもまだ仕様が固まってないんだよな〜。メッセージ案だけでなく、こんな処理方式はどうかとかの提案も嬉しいです。
補足：「こうすればメッセージ分離してランダムメッセージも実現できるんじゃないか」とか「メッセージフォーマットはこっちの方が美しくないか」とか「こしたらも少し処理時間の予測を正確にできるんじゃない」とか「出力ファイル名も言えや」とか「処理時間もっと単位を区切って何時間何分何秒で言え」とか
もっと真面目に lex とか yacc とか BNF とかの勉強をしておくべきだったのだろうか。字句解析、構文解析、ああ面倒。
とりあえずメッセージカタログのフォーマットは INI フォーマットを流用することにして……しまうと階層化が面倒だけれども、我慢する。
% は既に SAKURA スクリプトの特殊文字だから……、シェルとか perl にならって $ を変数宣言に使うことにしよう。
セクションが変数（ランダムも可）に対応して、パターン数とかは任意に設定できるようにしてしまおう。えーと、再帰と連結リストで簡単（ではないけど）に実装できるな。
あとは制御構造をどうするかだな〜。今はフレーム数と消費時間で反応変えてるけど、ここも変更できるようにしたい。
少しずつ準備しとこう。すぐに作るのは無理だから。
うん。金土日は遊んでた。本日は買ったきりライナーノート読んだだけで放置してた DVD などを鑑賞。
ながらでポチポチとコーディングを進めてる。一応メッセージカタログの仕様は決定。当面テキストには手をつけず器の完成に専念する予定。
う〜ん、ひょっとして Platform SDK とかでは INI ファイルのアクセス関数って用意されてないのだろうか。探し方が悪いのかもしれないが未だ発見できず。全部書くのは嫌だな〜。
あと予想処理時間を算出するアルゴリズムも考えておかなければいけないんだよな〜。なるべく正確に算出する簡単な方法はないものだろうか。
ホントはタイトルを「革命的同志達よ」にでもしようかと一瞬考えたのだけど、このページを現在置いてるところが大学なのでより穏当な表現に修正。というよりも、今そんな事書くと洒落ではすまないような不穏な雰囲気なので。
この寒い中一日中立ち番してる大学職員の方々やこーあんの皆様はホントご苦労様デス。一応手紙は来てたとはいえ、本気で入り口で学生証見せてくださいと言われるとは思ってませんでした。
しっかし、何で学生会館建て替えるだけ（じゃ無いのかな？）でこんな騒ぎになるんでしょうね〜。いやはや。右や左の皆々様ホントご苦労なことです。
追記：INI のアクセス関数ですが、親切な方々のメールで無事解決しました。この後お礼のメール書きます。
別名無能なプログラマ。昨日一日で作れた関数が shift_jis_next_char() 一個だけだというのは悲しすぎる。というよりも、shift_jis_next_char() をいちいち作らなければいけない C が腐っているというべきなのだろうか？
とかいって、これも作らなくても済むものだったりするとかなりアレな気分。車輪の再発明って楽しいよね。
まーそれはそれとして、何か ですけど、せりこはまだ試してないので、当分 sakura.exe とはお別れして haruna.exe を起動することにしました。うにゅうやふきだしがまばたきしてくれても全然嬉しくないので。もう少し落ち着くまで様子を見ることにします。
公開テスト版だからバグあるのは当然なんですけど、思えば 1/3 の p33.98 が一番安定してたような。
追記： メッセージカタログ読み込みモジュール完成。後は AUF にマージすれば終了。ただし、未だ予測アルゴリズムは思いつかず。問題は、アクティブなフィルタ数やソースサイズ、出力サイズが手に入ったとしても、どうやってそれをパラメータ化するかなんだよね〜。過去の消費時間のログ取っといて学習させる？
けっこうあっさりと動くようになったので、SSTP AviUtl プラグイン Ver. 0.3.0 を公開。当初の予定よりも大分機能低下してしまったが、全ては私の技術不足ゆえ。
前バージョンとの違いはスクリプトをプログラムから分離してユーザ側で設定できるようになっただけで、誤差 10% 以内で処理時間を予想できるようになったり、より多彩な状況感知機能がついたりした訳ではない。
その辺は AviUtl 本体の対応待ち段階。
でも、スクリプトをユーザ側で設定できるようにして、状況感知機能を充実させても使う人がいるかどうかがちょっと疑問。だって、未だにスクリプト案の提案とか一通も送られてこないし。
掲示板も無しにフィードバックを期待する方が間違ってるのかな〜。
追記： どこでもいっしょ、USB マスコットハブ ですか……。これを見て、1/6 メイやら REAL 偽春菜やらの実現も近いと考えてしまう私はどう考えても終ってますね。はい、自覚はあります。
AviUtl 0.96i がリリースされたので、新機能を利用して SSTP v.0.3.1 に更新。幾つか諦めたこともあるけど、一応当初予定していた機能はほぼ実装完了。
それなりに色々と変更できるようになってるはずです。スクリプトは TPP ファイルで定義できます。詳しいことは添付の nharuna.tpp のコメントを読んでください。
何か追加してほしい分岐条件とかありましたら、メール下さい。可能であれば実装します。
で、どんな事を諦めたかというと、${hoge${fuga}} てなのの実現。これがどんな意味を持つかは TPP 書いてみようと思ったことのある人じゃなきゃ判らないだろうけど……。
TPP ファイルでは、Perl の変数展開のように、${fugahoge} で文字列中にその変数の実体が入るようにしてある。${fuga${hoge}} というのは、${} を入れ子化することで変数名すら実行時に決められるようにしようという壮大かつ無意味な機能。
絶対に誰も使わないだろうけど、できたらできたで面白いから、ついでに付けとこうかと思ってた。けど、どうにも面倒だったので断念。
あと、処理時間の予測だけど、誤差 10% 以内というのはどうも無理っぽい。私の環境では学習後でも 20 〜 30% の誤差を含んだ時間になってしまう。う〜ん、モデルが間違ってるのかも。
何か のページが死んでいて最近偽春菜をネットワーク更新ができないのが悲しい。というわけで、AI についての由し無し事を。
一応忠告。私はたまに BIT とか読んで判ったつもりになってる素人の半可通なので話半分に読んでいただきたい。そもそも情報工学は専攻してないし。つーか、他人の話を疑う知性ぐらいはもとうね。
枕終了、以下本題。
AI には２種類あって、それは今回のタイトルの真面目なものと不真面目なもの。ただし、口の悪い人は「まだ真面目な AI というのは存在しないから世の中には１種類の AI しかない」とか言ったりする。
真面目な AI のモデルとしては、HMX-12 とかを連想すると良いかも。意識と感情を持ち、自己の概念をもつ仮想人格。人間と同じ「意識」をもつホンモノの人工知能。
これに対して不真面目な AI というのは、意識を持たせようなどという夢をみるのは諦めた、入力に対して一定の判断条件にしたがって出力を返すだけの反応装置のこと。
現実的で真面目なアプローチじゃないかと感じるかもしれないけど、根底にあるのは「どーせ使ってる人間には判りゃしないって、要はそれっぽく、知能があるように思わせればそれでいいんだよ」というものなので、不真面目という評価が適当。
不真面目な人工知能の基本理論は、人間の会話を入力と出力が１対１、あるいは１対多で対応するブラックボックスとしてモデル化し、データベースとして実現しようというもの。
真面目な AI の例は物語の中にしか存在しないけど、不真面目な AI の例は結構ある。知ってる限りで最古の人工知能は、精神科医ゲーム。ゲームの内容は、コンピュータが幾つか質問をしてきて、プレイヤーが回答を入力すると精神状態やらなにやらを評価してアドバイスしてくれるというもの。確か Emacs Lisp にも移植されていたような。
勿論、最古の人工知能だからジョークとして作成されたもので、まともなアドバイスは帰ってこない。登録済みのパターンの中からそれっぽい結果＋ランダムで反応を選んで出力するだけのもの。
この手の人工知能システムの場合、最大の問題点はあらかじめ登録されたパターンの中からしか反応が返ってこないということ。ある程度ランダム要素を入れて反応を変化させていたとしても、登録パターンが固定されている限り必ず何時か飽きられてしまう。
膨大なパターンを用意することで飽きられる瞬間の到来を遅くすることも理論的には可能だけれども、一生かかっても飽きることがないほどのパターンを用意するためには、最低でも同じだけの時間が必要になってしまう。現実的には不可能。
一括払いできない貧乏人はローンを組もうというアプローチもある。ネットワーク経由で登録パターンを更新することで、反応を変化させ、飽きられる瞬間の到来を避けようという方法。この方法は予め膨大なパターンを用意するのに比べれば多少現実的になる。ただし、トータルの作業量が膨大であるという事実には変化がない。
手動でパターンを更新する必要を避けるためには、AI に何らかのパターン学習手段を持たせる必要がある。これが単純な対話型 AI の場合は、適当にチャットとかをサンプリング元にして反応データベース作成すればある程度楽にできるはず。多分。確か ゆいチャット とかはそんなアプローチだった記憶が。
ただし、この手段を取れるのはユーザ対話型 AI の場合だけで、その場合でも反応データベースに膨大なリソースを要求してしまう。あまり現実的ではない。
そろそろ話題が発散しかけているので無理矢理にタイトルに戻してまとめ。このように、不真面目な AI の実現にすら膨大な困難が待ち受けている。まして真面目な AI を実現するための困難はこれの比ではない。HMX-12 実現への道は遠いのだ。
ソケット - ソルトチケットの略。キエサルヒマ大陸での基本紙幣。王都の貴族連盟が管理する塩専売公社のみに精製が許されている塩との交換券。１ソケットで塩１０グラムと交換可能。基本的に４大都市圏でしか効力を持たず、辺境では利用されない。ところでオーフェンってもう完結しちゃったのでしょうか？
パケット - パスタチケットの略。明治大学生田正門前のタックでスパゲティ大盛りを頼むと貰える券。５０枚ためると１回無料に。
ラケット - ライスチケットの略。別名お米券。江戸中期、藩財政の悪化に苦しむ遠野美凪が乱発し農民一揆などの社会問題を引き起こした。カムイ伝は名作です。必読。
綺麗なコードと汚いコードの見分け方。ソースコードが見れなくても判ります。
まず、一通り使ってみてバグがあるかどうか。バグに気が付かなければ、それはかなり綺麗なソースコードで書かれています。次に、バグが見つかった場合。不具合報告を行い、作者が不具合の存在を確認してから修正するまでに要する時間を計りましょう。即日修正されれば、かなり綺麗なソースコードで書かれています。１週間前後ならば、比較的綺麗なソースコードで書かれていると判断してよいと思います。それ以上かかる場合は、汚いソースコードだと判断して間違いありません。
世の中には様々なコーディングスタイルがあり、そのスタイルによって綺麗なコードの基準は異なります。
例えば、変数名の付け方にしても、CantReadThis とか CRT とか cant_read_this, cantreadthis, cANTrEADtHIS, c@nt_r3@d_th1s と色々です。
人は、自分と同じスタイルのコードを綺麗だと考えがちですが、それでは一般的な判断基準には使えません。
そこで、何故綺麗なコードを書く必要があるのかという基本に戻って考えてみると、その目的は「バグが入りにくくなるように」と「バグをすぐ潰せるように」の２つです。
つまり、バグがあり、いつまでたってもバグを潰せないプログラムは、汚いコードで書かれているのです。なにしろ目的が達成できてないのですから。
というわけで、汚いからソースコードは恥ずかしくて出さないというのはあまり意味のある行動ではありません。バグが入っている時点で恥なのです。バグが潰せずに仕様といって逃げるのが恥なのです。
うーん、なんだか自分で自分の首を絞めてるような気がしてきました。と、いうわけで、私が公開してるプログラムでなんか妙な動きすることがあったら、教えてください。バグの入ってるものが世の中に出回っているのは非常に恥ずかしいので。
と、言われたとか言われなかったとか。MPEG2 の編集ソフトの話。今年に入ってからは SSTP と戯れていたので、当然昨年末から状況はちっとも変わっていない。
むう、しかし大学には卒論というのもあってある程度の量の文章を書かないと卒業することができないわけで。
さらにいうなら SSTP は圧縮中でもなんか喋れた方が楽しいのじゃないかとかいう意見もあったり。
ようやく水菜エンドまで到達した「顔のない月」も幾つか CG 抜けがちらほらと……。
業務連絡。AUF の変更点はアーカイブファイル名変更のみです。中身は変わってません。
卒研のシミュレーションで構造最適化を実行するはずが、全原子を動かさない設定にしていたと気が付いたとき。
あの２０時間はなんだったのだろう。表面の Sn 原子 13 個を動かす設定に書き直して実行したところ、１６時間経過してやっと 1 MD ステップ動いただけ。
う〜、先は長い。卒論は完全に FHI98MD の使用手引きだけになってしまうかも。なんか結果が出てくれればそれも追加ということで。
えーと、３次補間の画質について疑問のある方は、縮小アルゴリズム を読んでください。AUF の関連情報からもリンクしときました。
ホントは別ページにまとめて、エイリアスノイズとか FIR フィルタの原理についてもっと詳しく書いといた方が良いんでしょうけどね〜。手が遅いもので。
てのが、そろそろ出るらしい。まだ秋葉原の店頭までは来てないみたい。製品詳細 と プレスリリース
プレスリリースが去年の 11 月で、出荷開始が 12 月ということだから、そ〜ろそろ店頭に出てくる頃だと思うのだけどな〜。
んと、20G プラッタの 7200 rpm IDE HDD ということらしい。60GXP つうわけで、最大容量は 60G なんだけど、これは…… 75GXP の 5 プラッタという設計に無理があったという反省なのか、100G あっても無駄になるだけという現実的判断なのかちょっと悩む所。
そろそろ本気でディスクスペースが逼迫してきてるので、安ければ買いたいところなのだけど。問題は初物価格がどれくらいになって、そこからある程度に落ちてくるまでにどれだけかかるか。
年末に作った MMX 版 FIR フィルタの精度がボロボロという事が判明し、落ち込み中。嗚呼、端数切り捨ては駄目ですか。４並列なんて論外ですか。加減算での桁落ちを甘く見ては駄目ですか。
MMX で非 MMX 版と同精度を保つには２並列が限界になってまうので速度ほとんど変わらなくなって、しかも現在は４バイトアライメント取れてる垂直方向 FIR フィルタが、アライメント取れなくなってしまうんですけど〜。
仕方がない。SSE に逃げよう。SSE なら最大４並列可能だからアセンブラソースの構造はそれほど変更せずに済むはず。
結果の出ない努力に意味はない。全ての努力は結果が出て初めて意味を持つ。というわけで、昨日の作業の結果報告。
某比較用 15 sec の 640x480 ムービーを低域通過フィルタ（タップ１５）と３次補間で 320x240 に縮小してスパゲッティ２１号で出力するのに要した時間。
INT - 7:50 SSE - 5:18 MMX - 3:21
SSTP プラグインがはじめて役にたったかも。というのは置いといて。SSE 遅すぎ。もっと速く int16 <-> float 変換できる方法があれば何か変わるのかもしれないけど、今使ってるのは悪友 K から貰ったコードのまんまパクリだからな〜。
なぜ packed int32 と packed float の相互変換しか SSE には用意されてないのだろう。packed int16 と packed float の変換があれば楽なのに。
まあ、スピードについては諦めるとして、問題の画質は MMX 版と比較して向上したのか。
……一応ヒストグラム見てても極端に暗くなって、RB が弱く、G が強くなることはなかったのだけど……。リンギングノイズは変わらずくっきりはっきり残ってる。
float だと仮数部 23 ビットだから 32 ビットと比較してまだ精度が足りないのか〜とか考えながら、とりあえず C バージョンのコードを float を使って計算するように修正してみると……出ない。リンギングがさっぱり出ない。
どうやらアセンブラコードが根本的に腐っているのではないかという可能性が濃厚。根が深い。解決の目処は立たずお先真っ暗。
LPF で SIMD 使うとリンギングが出まくるバグは、デバッグモードで動かしてみたところあっさり原因が判明。あまりにも恥なバグなのでこれに関してはもう触れない。Ver. 0.3.2 で直ってます。精度も SSE 版ならまともになりました。MMX 版の高精度化はもすこし精神的に余裕ができてからになります。
卒論煮詰まっちまったぜ突発企画なので続けられるかどうか判らないのけど、一応（１）を付けておく。今回の話題はビデオ編集の基本、タイムコードの事。
まずタイムコードというのは 00:01:20:00 とかいう形で表されるデータで、ビデオのフレームと再生時間の対応を表している。コロンで区切られた４つのデータは、HH:MM:SS:FF という意味を持ち、左から、時間：分：秒：フレーム となる。
つまりタイムコードでは、フレーム 0 は 00:00:00:00 と、フレーム 1 は 00:00:00:01、フレーム 2 は 00:00:00:02 と表される。では、3000 フレームはタイムコードだとどう表されるか。
タイムコードのフレームレートによってこの問題の正答は変化する。24fps タイムコードだと 3000 フレームは 00:02:05:00 となるし、30fps タイムコードだと 00:01:40:00 になる。もちろん 24fps と 30 fps だけじゃなくて、25fps とか 12fps とか 60fps とかのタイムコードも存在する。
さて、NTSC は規格で 29.97 fps と定められている。じゃあ、29.97fps タイムコードってのはあるんだろうか？
結論を書くと、29.97fps タイムコードというのは存在しない。そもそもタイムコードではフレーム単位の整数しか扱えないので 29.97fps なんていう端数の含まれたフレームレートは表現できない。29.97fps の場合フレーム 30 は 1.001 秒から 0.033 秒間表示されるフレームだけど、30fps タイムコードで 00:00:01:00 と書くことしかできない。
この場合、実際にフレームが表示される時間とタイムコードの時間がずれる事になるけれど、元々タイムコードというのはビデオ編集時の目安にしか過ぎないものなので、あんまり問題は発生しない。
一般に、端数を含むフレームレートのデータをタイムコードで表現する場合、29.97 -> 30 のように、端数部分を切り上げて、整数のフレームレートに直すことになってる。
この方法のタイムコードが基本なのだけど、NTSC 用の長時間の素材を編集する場合、タイムコードと実際の時間のずれが大きくなってタイムコードが目安にすら使えなくなってしまう。
じゃあ仕方がないから、何とか誤魔化す方法を考えなきゃな〜という訳でひねり出されたのがドロップフレームタイムコードというもの。今まで説明してきたタイムコードはノンドロップタイムコードと呼ばれて区別される。
ドロップフレームタイムコードについての話は次の機会に。
どうも 何か 方面は偉い騒ぎになってるようだけど、そういった世の中の動きには背を向けて前回の続き。けっこう間があいちゃったけど。
NTSC の 29.97 fps を 30fps ノンドロップフレームタイムコードで表す場合、実際に映像が表示される時間と編集時に使用するタイムコードの時間がずれるという問題があった。実際にどれくらいずれてるかというと、50 分間で約 3 秒ずれる。タイムコードでは 50 分きっかしに表示されることになってるフレームが、実際にはその 3 秒後に表示されるということ。いくらただの目安といえ、これでは全く使い物にならない。
そこで登場するのがドロップフレームタイムコード。次のような方法でタイムコードと実時間とのずれを調整する。
実際の例の方が判り易い筈。という訳で、ノンドロップフレームタイムコード（NDF）とドロップフレームタイムコード（DF）を実際のフレーム番号との対応で比較してみる。
| フレーム | NDF | DF |
| 0 | 00:00:00:00 | 00:00:00:00 |
| 1 | 00:00:00:01 | 00:00:00:01 |
| 2 | 00:00:00:02 | 00:00:00:02 |
| … | … | … |
| 29 | 00:00:00:29 | 00:00:00:29 |
| 30 | 00:00:01:00 | 00:00:01:00 |
| 31 | 00:00:01:01 | 00:00:01:01 |
| … | … | … |
| 1799 | 00:00:59:29 | 00:00:59:29 |
| 1800 | 00:01:00:00 | 00:01:00:02 |
| 1801 | 00:01:00:01 | 00:01:00:03 |
| … | … | … |
| 3597 | 00:01:59:27 | 00:01:59:29 |
| 3598 | 00:01:59:28 | 00:02:00:02 |
| 3599 | 00:01:59:29 | 00:02:00:03 |
| 3600 | 00:02:00:00 | 00:02:00:04 |
| 3601 | 00:02:00:01 | 00:02:00:05 |
| … | … | … |
| 17980 | 00:09:59:10 | 00:09:59:28 |
| 17981 | 00:09:59:11 | 00:09:59:29 |
| 17982 | 00:09:59:12 | 00:10:00:00 |
| 17983 | 00:09:59:13 | 00:10:00:01 |
| 17984 | 00:09:59:14 | 00:10:00:02 |
| … | … | … |
無駄に長くて読む気が無くなるだろうけど、注目して欲しいポイントは、1800 フレームおよび 17982 フレームでのドロップフレームタイムコードのフレームの変化。分の桁が変化する際にはフレーム 0, 1 を飛ばしてフレーム 2 としてカウントするというのと、10 で割り切れる分の場合にはフレーム 0, 1 を飛ばさないというのはこういうこと。
ドロップフレームタイムコードとフレーム数を相互変換する場合の式は次のようになる。面倒なんで C のソースコードそのまま張り付け。
void timecode2frame(TIMECODE *in, int *out)
{
int minute;
minute = in->hh * 60 + in->mm;
*out = 17982 * (minute/10) + 1798 * (minute%10);
*out += in->ss * 30 + in->ff;
}
void frame2timecode(int in, TIMECODE *out)
{
out->hh = in / 17982 / 6;
out->mm = in / 17982 % 6 * 10 + (in % 17982 - 2) / 1798;
out->ss = ((in % 17982 - 2) % 1798 + 2) / 30;
out->ff = ((in % 17982 - 2) % 1798 + 2) % 30;
}
ドロップフレームタイムコードでは、00:50:00:00 はフレーム 89910 となって、実時間でも 00:50:00.000 となり、ずれは無くなる。10分単位であればタイムコードが信頼性を持つわけ。
長編の NTSC 向け映像を編集する場合などにはドロップフレームタイムコードが使用される。一応もう少し続く予定。次回はタイムコードについての注意点とか、NTSC のフレームレートとか。
ドロップフレームタイムコードというのは実際に映像フレームを捨てているのではなく、単に一定周期で一つの映像フレームを３タイムコードフレームとして数えることがあるという、ただそれだけのもの。だから、ドロップフレームタイムコードで数えようと、ノンドロップフレームタイムコードで数えようと映像データ自体は変化しない。単にタイムコードの数値が変化するだけ。
さらに、１分 ―― 1800 フレーム以内のデータの場合、ドロップフレーム / ノンドロップフレームに関わらず、タイムコードは一致する。これが CM 等でノンドロップフレームタイムコードが使用される理由。１分以内のデータならタイムコードは一致するから、計算が楽なノンドロップフレームタイムコードを使うわけ。
ついでに言うと、日本国内でアナログ放送されてる NTSC 信号は 29.97fps 固定。放送局内で、クロックジェネレータを使用し同期信号を作成して、それにロックさせてアナログ NTSC 信号を送信してるので 29.97 fps からずれることはまず無い。デジタル BS とかだと、送られてきた MPEG ビットストリームを NTSC 信号に変換するステップが入るので、デコーダの精度によっては同期がずれて 29.97 fps から外れることがあるけど。VHS などのテープメディアからの再生時も同様。
これが本当かどうか疑問がある人は、こんな方法 で確認してみるのも良いかも。まあ、サウンドカードのサンプリングクロックがずれてる場合には全然信頼性がなくなっちゃうけど。
NTSC 自体は 29.97 fps 固定なので「ドロップフレームタイムコードで作成されてる本編は 29.97 fps だけど、CM とかはノンドロップフレームタイムコードなので 30 fps になり、29.97fps で通してキャプチャすると音ずれの原因になる」というのは幻想。作成時に使用していたタイムコードによらず、アナログ NTSC 放送では常に 29.97fps になる。
もう一つ。MPEG ではビデオストリーム内にタイムコードが一応存在するけど、これは音声と映像の同期を取るためには使用されない。映像と音声の同期は、システムストリームに用意されている、SCR （システムクロックリファレンス）という、27MHz 精度のクロックをもとに調整される。タイムコードは同期を調整するのには精度が荒すぎて使えないのだ。
ついでに言うと、リップシンクに使わないんじゃ何入れたって構わないだろうという考えなのか、タイムコードに出鱈目な値を入れてくれる商用 MPEG2 エンコーダまであったりする。つまり、タイムコードというのはそれぐらいどうでも良いデータだったりするわけ。
誇れない仕事は悲しいね あれを作ったのは確かにボクなのに 彼は永遠の世界に旅立ち 残っているのはボクだけなのに 彼の名前で公開したものが 実はボクが作ったものだと 明かすことができない
別に素晴らしい文章にふれて臓腑に届くほどの感動を受けたという話ではない。単に体調崩して腹に来てるだけ。
土・日・月と半死状態で、仕方がないので御不浄の住人になりつつ波の引いている間に卒論を進める日々。ああ全然進まない。
今は csh+awk+α の入り組んだパズルを解くべく努力中。WINDOWS 環境で動くような仕組みをでっち上げるのと、UNXI の基本操作を全て書くのはどちらが楽なのだろうと不毛な妄想をもてあそんでしまう。
一番楽なのは全イオンの擬ポテンシャルファイルを solaris 上で作成しておき、後はコピーして使ってねと投げてしまうことなのだけど、それやっちゃうと為にならないよぅ。