最近の VirtualDubMod では、コーデックを経由せずに、XviD の .stats ファイルを直接、読み書きできる。 まだ「正式」な機能とは言えないが、知っていると役立つ。
XviD 2パスのエンコーディングでは、品質コントロールよりサイズコントロールが優先される結果、 1パスのエンコーディングでは発生しないような画質上の問題が発生することがある。 この場合、.statsファイルを調べたり、直接いじることで、問題を解決できることがある。 エンコ結果に表面上、問題がなくても .stats を調べると参考になることが多い。 これらの目的のために、すでに、StatsReader や StatsViewer がある。 また、現在のOGMではチャプターの頭がキーフレームになっていないとうまくないので、 画質上には問題がなくても、.statsを編集して、ある場所を強制的にキーフレームにしたいことがよくある。 この目的では、KFF (KeyframeForcer)がある。
最近の VirtualDubMod では、エンコード元のビデオデータと .stats ファイルを同時に読み込んでフレームごとに対照表示できるので、 実際に画像を見ながら、どこにキーフレームが落ちるか、また、そのフレームにどのくらいのビットが配分されているのかなど、 1パスめ終了後、2パスめ開始前に確認できる。
VirtualDubMod 2003年1月17日版以降のビルドが必要なので、 通常の最新版のパッケージ(VirtualDubMod 1.4.13.1 = 2002年12月)を解凍したあと、 「VirtualDubMod bugfix/cvs」の「exe only prerelease」を解凍して、 最初に解凍したなかに上書きしてしまえば良い。 (2003年3月14日現在)
ビデオファイルを読み込んだあと、Tools メニューから対応する .stats を読み込む。 2パスめの前にエンコ元のビデオと対照させることも、 2パスめが終わったあとからエンコ結果と対照させることもできる。 フレームごとに .stats の情報が表示される。 また、 フレームの種類(I か P か)をスペースバーを押すだけで簡単にトグルできるようになっている。 が、コーデックのバージョンの関係なのか、 VirtualDubMod 自身のバグなのか、 実際のエンコーディングになかなかうまく反映されないようだ。 近い将来、バグフィックスリリースのついででなく、正式公開されたらだんだん機能も安定するだろう。 .statsを編集した場合は Tools メニューから新しい .stats を保存し、 XviD のエンコーディング設定画面から新しい .stats を参照するようにする。
エンコード結果に画質上の問題がある場合、問題がある場所が少数で限定されているなら、 問題(例: ブロックノイズ)が出た場所または直前にキーフレームを入れることで、解決、軽減できることが多い。 この方法は、どちらかといえば、古くさい後手後手のアプローチで("AntiShit")、問題が発生してから修正するので時間もかかる。 いつも同様な問題が出る場合には、エンコーディングの設定を考える必要がある。 複雑で洗練された曲線管理を行うより単純なリニアが良いという意見は根強い。 偶発的な問題で、キーフレームの挿入や設定をいじってもなかなか解決しない場合、 問題の場所だけ1パスで部分エンコして、つなげたほうが手っ取り早い。 もちろんサイズに糸目をつけないのなら、最初から品質優先で全部1パスにすれば良い。
チャプターの頭は、その性質上、シーンチェンジであることが多い。 その場合、かなりの確率でもともとキーフレームになっている。 なっていないときは、直接、.statsファイルを書き換えて、 好きな場所がキーフレームになるように指示することもできる。 そうしたければ、チャプターの区切りとの関係で、キーフレームが入る位置を「ずらす」こともできる。 ずらしたいI(現在の予定地)をPにトグルして、 新たなキーフレーム予定地にしたい場所をPからIにトグルすればいい。
この機能はバグフィックスのついでに暫定的に導入されたもので、 正式パッケージにはまだ入っていない。.statsファイルを調べるのはともかく、 キーフレーム挿入とか、うまく機能しないことがある。 (特にBフレームを使った2パスは要注意。)
どこにIを入れようとしているのかビデオ上であらかじめ確認できるだけでもすでにべんりだが、 Nandub の .ecf みたいな感じで発展したら、おもしろいかも。
.stats ファイルとは関係ない一般的なことだが、 現在のOGMではチャプターの時間はあまり正確より、少し手前にずらしたほうが良い。 多くの場合、OGMで音声・字幕は実際の時間より少し後の部分を読み込んでバッファリングしながらぴったりに再生するので、 キーフレームぎりぎりに飛ぶと、画像はぴったりでも、画像とシンクロする音声データが読み込まれない。 シークのときは画像のスタートと音声のスタートが0.何秒か違っても両方が出た瞬間に同期していれば気にならないが、 チャプターだと「初めの音」が欠けてしまうことになって気になる。 (そこがもともと無音ならどうでもいいことだが。)
現在OGMがサポートするSRT字幕では、字幕の位置情報を直接的に指示する方法がない。 必要なら、次のように、特別な字幕にダミーの空行で「下パディング」して、ふつうと違う位置に表示させることができる。
18番の字幕は通常より3行高い位置に出る。
17 00:02:24,680 --> 00:02:28,673 I just stood there. I couldn't move. 18 00:02:40,480 --> 00:02:44,792 <i>30 Years Before</i> <i> </i> <i> </i> <i> </i> 19 00:02:51,480 --> 00:02:53,311 Mrs. Sudo...
複数の人が同時にしゃべって字幕が入り乱れるようなシーンでも利用できる。 ソースにもともとあるハード字幕と重なるのを回避する目的でも使えるが、実際に回避できるかどうかは、再生時のフォントサイズ設定に依存する。 この方法で表示される字幕は、通常の位置より相対的に3行上になる。 それが物理的に何ピクセルの位置になるかは、再生時の環境に依存する。 したがって、自分の環境での出力をあてにして、物理的なレイアウト(例: 画面中央のタイトルロゴ)に使っても、 再生時に画面中央に来る保証はない。
この方法はSRT本来の仕様でなく、暫定的なハックだが、DVDの固定位置字幕より柔軟性がある。 SSA以降の近代的な字幕形式では、字幕スタイルを明示的にコントロールできるのがふつうだ。
2003年3月16日 JavaScript なタイプライター・シリーズ。 今回は、南の島モルディブの文字でやってみました……もちろん、よく分からない文字なので、 Dhivehi thaana - reading and writing the Maldivian language、Alan Wood’s Unicode Resources: Test for Unicode support in Web browsers: Thaana、www.unicode.org/charts/PDF/U0780.pdf などを参考にしました。 (画像は maldive isola maldive より引用)
ターナ文字はインドの南、南の海に浮かぶ島国モルディブの文字です。 モルディブの言語「ディベヒ語(ディヴェヒ、ジベヒ)」(xml:lang="div")を表記するのに使います。 右から左につづります。ディベヒ語は、印欧語族だそうです。広い意味では英語などの西欧語と同じ系統。
Mozilla 1.3 はターナ文字の文字単位の書式方向を正しく処理しない: ターナ文字は、文字単位で右から左に進む固有の属性を持っている。IE 6.0 は、これを正しく処理するが、Mozilla 1.3 は、dir属性で明示的に指定しない限り正しく処理しない。 したがって、プレインテキストのターナ文字を正しく処理できない(例: Mozilla のメーラ)。当初こそユニコード関連のレンダリングでIEに連敗だったMozillaだが、 現在ではIEよりすぐれている面も目立つ(例: ギリシャ語)。が、Unicode 3.0より上になると、まだ実装途上の部分もある。 OSレベルでディベヒ語のMUIさえ作っている企業力なのでフェアな比較ではないかもしれないし、 このことだけで Mozilla が全体としてダメという意味にはならない。
The Dhivehi word ކައޯޓަލަ
means "sweet potato."
dir属性を明示すれば Mozilla でも問題は起きない。しかし、ヘブライ文字、アラビア文字同様(最近のMozillaは、これらの文字を正しく処理する)、dir属性を指定するまでもなく、Unicode仕様上、ターナ文字は文字自体が方向属性を持っている。
Opera 7.03 のターナ文字サポートはいっそう悪い。しかし、Mozilla、Operaとも、右から左へ進む文字でもヘブライ文字のような主要なものについては、よくサポートしている。
再び古典ギリシャ語
従来のUnicode規格になかったU+10000以上の文字に挑戦。Operaが善戦
アラビア語、韓国語でIEに連戦連敗の Mozilla、第3ラウンドは古典ギリシャ語で勝負!