前 9 - 03 p ｜ 
もくじ i ｜ 次 9 - 05 n 
WMA音声のMKV動画には、いくつかの制限事項があります。 普通のやり方では、トラックの言語名を指定したり、フォントを埋め込んだりするのが困難です。 それを何とかする方法です。
以前――といっても、もう4年も前の2000年ごろですが、 VirtualDub は ASF を正式サポートしていました。 （当時は、ASFで動画を作成するユーザもけっこういました。） しかし、Microsoft から「これは当社の特許技術であるからサポートしないように」との要求があり、 サポート中止されました。 また、ブロードバンド以前でHDも小さかった当時、「高圧縮でそこそこの音質」ということが追求された結果、 WMA が MP3 より低レートに強いことが認められ、 通称 DivX Audio として、ハック的に使われていました（機能的には、現在の Ogg Vorbis のようなもの）。 ちなみに、当時の DivX 3自体、MS-MPEG4v3などのハックでしたし、いわゆる Radium Codec も本来無料ではないMP3コーデックの流出版でした。
WMV/WMA をWMコンテナの外で使うことはハックであり、 Microsoft からも警告があったため、 一般に、現在、フリーウェアなどでは WMV(ASF) をサポートしない傾向があります。 MKVToolnix が WMV/WMA をサポートしないのも、一つには権利関係のためです。 現在、Matroska で WMV/WMA は公式にはサポートされていません。
しかし、MKV関係の大御所である Guliverkli では、asf2mkv を公開していますし、 VDM も Windows Media Audio のトラックを含むファイルを読み書きできます。 Microsoft 自身、AVI/OGM/MKVコンテナでWMVを使えるようにするVCM版のコーデックを正式に公開しました。 TmpgEnc も WMV を処理できることで知られています。
このように、WMV/WMA のサポートには、ばらつきがありますが、 結論から言えば、WMAや純粋の（VCM版でない）WMVを、WMV/WMAの枠外で使うと、何かと問題が発生しやすいです。 WMVコンテナで作るなら良いのですが、MKVなどにしたいなら、 できればわざわざWMAなど使わないほうが良いです。何といっても正式サポートでないので。
それでも何かの理由で、WMV/WMAを transmux したいことはあります。 どこかでいったん無圧縮AVIを経由して再圧縮するなら、何も問題はないのですが、 WMV/WMAを「そのまま」ロスレスで取り込むには、いろいろ問題があります。 以下ではWMA音声に限って話を進めます。
このメモは、WMA音声の使用それ自体を推奨するものではありません。 むしろ、WMAはできれば避けるべきですが、何らかの理由でどうしてもWMAをMKVに埋め込む必要がある場合についての覚え書きです。
WMA音声のMKVについては、ずいぶん前にも掲示板で話題になり、 MKVtoolnixのスレでも話題になったことがありますが、 GraphEdit を使えばできるけれど、正式サポートされていないので、いろいろ問題も多いです。 例えば、
ところで、今イタリアで東京ミュウミュウの吹き替えを放送していて、 その録画ビデオをもらったのですが、それが何とWMV形式だったのです。 イタリアにはいい声優さんも多いそうですが、このイタリア語版は残念ながら、あまり魅力的な声ではないです。 ともかく、こういう変てこなモノをもらうと 「よしイタリア語音声 + 日本語字幕で東京ミュウミュウを見てみよう」と、 こちらも変てこなことをしたくなるわけです。字幕は日本語と英語の切り替え、したがってソフトサブ、 日本語字幕は「ことり文字ふぉんと」で今はやりのフォント埋め込み、 音声部分は 65Kbps の WMA なので、これは再圧縮せずにそのまま transmux する。 こうなると、MKVですが、上記のようにWMA音声のMKVは、そのままでは制限が多く、 正攻法ではやりたいことを実現できません。
まず、WMVコンテナからサンプルにしたい部分を切り出し、 無劣化で単純に音声（WMA）を demux します。素材を用意するわけです。 WMV(ASF) をあれこれ加工するツールはいろいろありますが、 Microsoft 純正の Windows Media Editor と Windows Media Stream Editor で無問題。 映像と字幕は別途用意し、これらの各素材を GraphEdit で合体させ、とりあえず MKV にします。
ここまでは簡単ですが、このままでは、フォント埋め込みができないばかりか、 どのトラックも English と表示されてしまいます。 しかし、MMGでは読み込めても、書き出しのときにエラーになってしまうので、そこで行き詰まるわけです。
最初に試したのは、Matroska Stream Editor でした。 これで各トラックの情報を直接書き換え、添付ファイルもできます。
これが仕様通りに動いてくれれば成功です。 読み込みのときにSSAの最後の行が脱落する不具合がありましたが、 そのくらい、あらかじめSSAの一番最後に、0.01秒 \h を表示するダミーの行を入れれば乗り切れます。が、 肝心のフォント埋め込みがうまく機能しませんでした。埋め込みはできるし、MIMEタイプも指定できるのだが、 実際に再生するとうまくいかない。 再生も妙に重く、 MKVinfo で生成物をみても、例外が出たりして、何か問題がある気配。
そこで、 Matroska Stream Editor はやめて、 とりあえず、GraphEdit から出たものをVDMにロードして、言語タグだけは書き換えることにしました。 ところが、これがブレークスルーになりました。 WMA音声のMKVはVDMで再保存（Direct Stream Copy）するとMMGで処理できる形に正規化されることを発見。 つまり、GraphEdit で作ったものを、いったんVDMで保存しなおすと、MMGで処理できるわけで、 そうなれば、後はこっちのもの、添付ファイルだろうが、IDX+SUB形式字幕だろうが、MMGでできることが何でもできるようになります。
ただし、この方法には注意点があって、SSA字幕にタイミングのオーバーラップがあると VDM で開けなくなるので、 GraphEdit では「ビデオ+WMA」だけやって、それをVDMに通し、さらに、MMGにかけて、そのとき字幕などを合体させるのが一般解、 ということになりそうです。
ことり文字ふぉんとをアンインストールしても、ことり文字ふぉんとで字幕が出ました（Windows 98 系ではフォント埋め込みは動作しないかもしれません）。
作成したサンプルは、約8MBですが、そのうち実際の動画は5MBで、3MBは添付のフォントファイルです。 こんな小さいサイズでは日本語フォントの埋め込みはちょっと非効率な感じもしますが、 実験のため、あえてやってみました。 音声はファンダブではなく、実際にイタリアでテレビ放送中のものです。
WMV/WMAを Windows Media の枠外で使うことについては、まだまだ不明な点が多いです。 情報がありましたら、掲示板までお願いします。
アナモルフィック・エンコーディングは、一般に、 縦方向の画像密度を高めたスクイーズ収録の素材に対して用いられます。 スクイーズ状態のピクセルサイズのまま XviD などでエンコーディングし、 再生時に横方向に拡大して表示することにより、正しいアスペクト比で、しかも縦方向の高い解像度感を達成する方法です。
以下で考える「逆アナモルフィック」とは、それとは逆に、 通常のアニメのような、もともと縦方向いっぱいまで画像データがあってレターボックスがない場合に適用できるもので、 再生時アスペクト比4:3、ピクセルサイズ720x480の一般的なNTSC系非スクイーズ素材を、 元のピクセルサイズに近い状態でエンコーディングし、 再生時に縦方向に拡大して表示することにより、正しいアスペクト比で、大画面かつ横方向を高解像度にしよう、 という発想です。
実際には、この方法は必ずしも得策ではないのですが、有利な面もあるので、実験結果をご紹介します。
DVD（NTSC）のデータは通常720x480 つまり 3:2 のピクセルサイズなのに、 実際の再生時アスペクト比は 4:3 で、つまり縦が480なら横が640です。（DVDのデータを「そのまま」再生すると、 人の顔などが横長につぶれて見えます。） 720x480 の設定でTVを録画したときも同様です。 動画では、このデータを（多くの場合、多少クリッピングしてから）640x480 にリサイズすることが当たり前に行われています。 これは標準的な手順で、それ自体としては何も問題ありません。
しかし、横720ピクセルの情報があるものを、わざわざ640に縮小し、せっかくの解像度を10%以上つぶしてしまうのは、 もったいない気もします。他方、クリッピングの結果、縦472などになっているものを、480に拡大するのは、 解像度がないものを水増しするだけで、ある意味無駄です。 そもそも整数倍以外のリサイズは、結局劣化変換なので、リサイズによって、多かれ少なかれ鮮明度も犠牲になりますし、 何より、リサイズは、高品質の方式であればあるほど時間がかかります（Lanczos3）。
そこで、 とりあえずクリッピングだけしておいて、例えば 704x472 のような中途半端なピクセルサイズでもかまわずに、 そのままエンコーディングしてしまい、再生時にアスペクト比を調整する、という方法が考えられます。 通常の（スクイーズ収録に対する）アナモルフィックは縦密度が高いものを横に伸ばして再生しますが、 この場合は、横長になっているものを、縦に伸ばして再生するようにするので仮に「逆アナモルフィック」と呼んでおきます。 Matroska のような新世代のコンテナを使えばこうした「再生時のアスペクト比の指定」自体は簡単ですが、 さて、本当にこの方法で高画質になるのかどうか……。
横640へのリサイズをしないことで、横解像度をフルに生かし、リサイズの時間の節約、リサイズによる鮮明度の低下の回避ができる。 その代わり、エンコードする画面サイズ自体が大きくなるので、同じビットレートでは640x480でやった場合より、全体に画質が下がる。 こうしたメリットとデメリットが、差し引きどうなるかは、状況しだいと思われる。 また、再生時に縦を伸ばすことで、結局はリサイズをしなければならず、CPUの性能によっては、 リアルタイムでのリサイズは、エンコーディング時の、時間をかけた Lanczos3 に質的に負ける可能性がある。 また、現実的にオーバーレイでの再生になり、環境によっては色空間の二重伸張などの問題も出る。 （再生時の問題は、十分なCPUパワーと適切なレンダラーがあれば理論的には解決される。）
DVD（このメモで考えるDVDは、NTSC系のもの。PALのDVDは720x576など。）では、 アスペクト比4:3のものを3:2で収録しているので（レターボックスがある場合それも含めての話）、 厳密に言えば、DVDの原データはすべてアナモルフィック（スクイーズ）とも言えます。 このメモの「逆アナモルフィック」は、まさに「4:3のものが3:2で収録されている」というDVDの「アナモルフィック的」性質に基づくものです。 しかし、4:3のものが3:2になっているというDVDの仕様それ自体のことは、 普通は「アナモルフィック」「スクイーズ」と言いません。 「逆アナモルフィック」というのは、説明の便宜上、このメモで仮にそう呼んでいるだけですから、 誤解のないようにお願いします。
「逆アナモルフィック」で画質が向上するのかどうかテストするため、 次のような二つのサンプルを作成しました。
まず、あるエピソード全体として、1/3 CDサイズ（233.33 MB）になるように2パスでエンコーディング、 という状況を想定。 ただし、音声は 160kbps とします。 そのようにした場合、このサンプル断片（18秒）は、映像だけで 3508 KB になりました。 そこで、このサイズになるように、同じ場面を、サンプル1は、640x480 で普通にエンコーディングし、 サンプル2は、リサイズなし（クリッピングはあり）704x472 でエンコーディングし、 MKVで再生アスペクト比を指定しました （再生時のサイズは 704x528 になります）。 その他のフィルターなどの条件はどちらも同じです。もちろん、.stats ファイルはそれぞれ別に作成します。
これを全画面表示などで比較するわけですが……。 サンプル2のほうが横解像度が高いので大画面では有利なはずですが （再生サイズ640x480で鑑賞するなら、当然サンプル1の方がトク）、 そのかわりレートは同じなので、サンプル1のほうが平方ピクセルあたりの画質は高いです。 レートが十分に高くないと、サンプル2は、データ的に解像度が高くても全体にぼけてしまう可能性があります。 704x472のものを、アスペクト比3:4になるように704x528に横拡大して再生した場合、サンプル2は最適化されるはずです。
理屈はそうなのですが、実際にはどうでしょう。
この一例だけからでは確実な結論は出せませんが、だいたい次のような感じです。
横640でも横720でも、横1000以上の大画面に拡大すると、五十歩百歩で、 720のほうがわずかに横解像度が高いぶん厳密にはメリットがあるが、 そのことよりフレーム単位の品質の優劣のほうが影響が大きいようです（ビットレートにもよる）。 いつでも「小さく鮮明に作って拡大したほうがトク」とは言えず、 極端な話、320x240で超鮮明なソースを作って全画面表示したら、 まぬけに見えるのは明白。 要は「どのくらい拡大するか」という問題で、 現在のPCの一般的な全画面表示では、横640か720弱かという解像度感の違いは大差を生まないようです。
このメモの方法は、オーソドックスな方法と異なるため、思わぬ問題・見落とし・間違いなどがあるかもしれません。 フィードバックは掲示板にお願いします。 中途半端なピクセルサイズは潜在的な問題になる場合もあります。 あくまで「こういう方法もある」という参考程度にお考えください。
ffdshowを使い、設定の output で、Use overlay mixer にチェックを入れます。
TCMP では、これでOKです。
Media Player Classic では、さらに、VMR9 をやめて、Overlay で再生しなければなりません。
最近の MPC は VMR9 でアナモルフィックOKです。
コーデックによっては、色空間の二重伸張などの副作用が出ることもあります。
