前 7 - 16 p ｜ 
もくじ i ｜ 次 7 - 18 n 
現実に居場所があると感じないとき、もしかすると「現実に居場所がない」ということ自体もしっくりしないかもしれないが、 なにより、「現実に居る」ふりをしなければならないとしたら、しっくりしないだろう。 「つまらない」ときは「つまらない」だろうが、 なにより、「つまらないときに楽しそうなふりをする」ことは、単にふつうに「つまらない」以上に苦痛に違いない。 それと同じことだ。
けれど、このことが次のように「現実」と「あなた」のあいだで起きるのは、どうだろう――。 第一に、例えば、けがや病気でからだのどこかが痛いとき、痛いなあという「現実」と、つらいなあという「あなた」の関係においては、 しっくりしない点はないかもしれない。 第二の場合として、あなたはつらいのにあなたの現実が平和だと、しっくりしないかもしれない。 第三の場合として、あなたの現実、つまりあなたの物理的存在に病気のような不具合があるのにもかかわらず、あなた自身につらさがないというのも、 しっくりしない状況ではある。例えば喫煙のようなからだを害する行為が行われつつそれをどうとも思わないとか、 けがをしているのに、なぜかあまり痛みを感じないとか。これらの場合には、理論的には、からだは、あなたに腹を立てるべきかもしれない （けがをしているのに、なんで痛がらないのだ、ばかやろう！ 早く手当しれ！と）。逆に考えると、 第二の場合において、あなたは、あなたのからだに腹を立てるかもしれない （こんなにつらいのに、なぜどこもけがをしていないのだ！と）。
「からだが傷ついているときは、こころがへこむべきだ」とか「こころがへこんでいるときは、からだが傷つくべきだ」というのは、 奇妙な共生関係のロジックだ。そんなに一蓮托生なのだろうか。もし、主従関係があるなら、共生関係は常に水平にはならない。 「あなた」が現実の物理媒体に寄生しているなにものか、であるとするなら、 宿主は現実なのだから、あなたはたぶん現実に従うべきだろうが、そこはそれ、寄生であるから、 現実にとって不利益なことをしでかしもするのだ。 他方、もし、現実の身体のようなものがあなたに従属することで生かされているとするなら、 宿主は「あなた」、寄生者は「現実」であって、主客は逆転する。 この発想はいっけん不自然なようだが、「脳死は人の死」「身体の機能が維持されていても意識が死んでいるなら死んでいる」という立場からすれば、 むしろ物理的現実が従で「あなた」が主ということになる。 その場合でも、「現実に寄生していたあなたが現実のなかで死んだ」のか、 「あなたに寄生していた現実が、あなたの死によって共倒れすることになった」のか、というのは、 どちらの見方もできるし、 それらも、しょせん、人間のことばにすぎない。
OGMは、DirectX 9によってDVobSubへの依存度が下がった。 Win2KでVMR9、 XPでVMR7/9を選択することで原因不明の「字幕が出ない」「ワードラップしない」といった不具合をかかえるユーザの一部が、 問題を解決できるようになった。 しかし多くのユーザは依然DVobSubを使っている。
OGGは、EmmettがCEOでなくなったこともあって、やや先行きが不透明。 フリーの新しいビデオコーデックの話なので、やはりいちばん注目したい。
MK*は2003年5月1日にパブリックテスト版が公開予定。 これは動作する。MuxerとDSFとMPA2MKAの3点が公開されるだろう。 とりあえず使えるのはAがMP3、Vorbis、ひょっとしてAAC、VがDivX、XviDなど。 Muxer, DirectShowFilter とも、日本語環境でそこそこ動作する。 Muxerは速い。 （なかみが上記の組み合わせの場合）MKVファイルのDirectShowFilter（KAxDemux.dll）経由の再生でCPU負荷はOGMと同程度または少し高い。 VP3より（したがってたぶんOgg Theoraより）軽い。 おおむねCPU >1GHz推奨となるだろう。 手元ではDivX+MP3は少しジッターが生じた。XviD+Vorbisはかなりスムーズだった。 手元ではMPCよりTCMPのほうが少し軽い。 現段階ではMKVで可能なことはすべてOGMで可能なので、単に将来的な期待があるというだけで、 乗り換える必要はない。
mpa2mkaは、まだ不安定だが、すでにGUIフロントエンドにこぎつけている。 MKAファイルは「再生できるものはとりあえず再生できる」という状態。 今のところMPAを再格納できるだけなので、MKAに変換する実用的な意味はまだ、ほとんどない。 TCMPとMPCがそこそこ動く。 WinampはMKAをMP1として扱ってしまう（ずれて音は鳴る）。 foobarは動かない。
オーディオ: mp3, vorbis, ac3
ビデオ: divx3, divx5, xvid, vp3
VirtualDubMod 1.5.1.1a [2003-04-24] + KAxDemux.dll [2003-04-23]
「Matroska動画: 特徴と作成」 3通りの実例で特徴を紹介、 後半では動画作成者向けに実際のMUX法を説明
Matroska の最初のパブリック・ベータが日本時間2003年5月1日午前5時に公開される予定。 要点をメモしておく。
MKVをサポートしたVirtualDubMod（通称MooDub）は、VdubModの正式リリースとなる見通し。 言い換えれば、VdubMod 1.5.1.1a 以降は、標準でMKVをサポートする。 これによって、さまざまなオーディオ、ビデオからMKVをマクスしたり、 MKVを再編集することができる。
2003年5月1日公開予定のMoodubはベータ版であり、いくつか注意点がある。
第一の注意点として、現在のMooDubはCue挿入をコントロールできない。 Cueとは、シークをより高速にするための一種のインデックス。 Cueがまったくない状態でOGMと同等のシーク速度が実現されるという。 Cueを加えることで、OGMよりシークが速くなる。 しかし、Cueのぶんファイルサイズが増大する。 したがって「全フレームにCue」「キーフレームにだけCue」「Cueを入れない」といったオプションを目的に応じて使い分けるべきだが、 5月1日リリースされるMooDubには、このようなオプションがなく、常に多めのCueが入る。 言い換えれば、サイズの最適化でなく、シーク速度の最適化でハードコーディングされている。
Cueの挿入量とファイルサイズとのトレードオフについては、 filesize comparisonを見よ。 参考に次のデータもあげておく。
699,475,968 2003-04-26 18:41 Black Hawk Down (2 of 2).avi ←もとのＡＶＩ 698,703,637 2003-04-30 11:59 Black Hawk Down (2 of 2) fullcues.mkv ←フル・キュー 695,564,431 2003-04-27 15:23 Black Hawk Down (2 of 2).mkv ←デフォ・キュー 695,534,296 2003-04-28 19:02 Black Hawk Down (2 of 2) nocues.mkv ←キューなし
この例では、 サイズ最適化のキューなしでもとのAVIより約4MB縮む。 これでもOGMと同等のシークになるという。 しかし、MKVは、MCF時代に考えられていたほど（MCF旧スペック）圧倒的にはサイズを小さくしない。 （デフォルトではAVIやOGMと大して変わらない。少し小さくなることも、少し大きくなることもある。 特に現在のMooDubはCueを入れまくるので、空間効率の最適化はなされない。） このようにMCF時代と変わってきたのは、結局のところ、開発者が「0.1%単位のわずかな差にきゅうきゅうとするより、 ちょっとくらいサイズが増えてもコンテナとして至れり尽くせりのほうが良い」という基本方針をとってきているからだ。
第二の注意点として、MooDubでは、従来のVdubModとかなり操作法が変わった部分がある。 特に大きな違いとして、ビデオに対するオーディオ・サブの全ストリームを、Streamsメニューで一括管理するようになったことがある。 音声ファイルを読み込んだり、デマクスするには、Streams | Stream List メニューを使う。
あるストリームを使わない場合、削除するか、Unselectする。 個々のストリームに対する操作は、その上で右クリックすれば分かる。
また、Direct Stream Copy 等の選択が、ファイルを保存するダイアログ内でも行えるようになった。 このインターフェイスは使ってみるとなかなかべんりだ。ほかにも従来のVdubModからみて、VdubMod1.5.1系は洗練されている。
第三の注意点として、今回のMooDubと今回のDSFの組み合わせでは、音声がモノラルのファイルで不具合が生じることがある。 （この問題は、公開されたv.0.3.0ではすでに解決したようだ。）
DirectShowフィルターKAxDemux.dllは、インストーラーがつくがどうか分からない。
もしつかない場合は、例えば、c:\temp に置いたとして、DOS窓から
regsvr32 "c:\temp\kaxdemux.dll"
によってシステムに登録する。なお KAx とは、MKx の旧称。
公開されるDSフィルターは、あくまで最初のベータであり、開発のプレビューを目的としている。 全般に不安定であるほか、一部の機能は未実装。とくにシーク関係は未実装なので、再生でシーク関係は使えない。
DSFなので基本的にどのプレーヤーでもいけるはずだが、TCMP RC3以上を推奨。 TCMPは「ファイルを開くダイアログ」ですでにMKVをデフォルトで表示するようになっている。
MKVファイル、MKAファイルの関連づけも行える。
なお、Matroskaベータ公開記念のTCMP特別ビルドが公開されるらしい。
オーディオ: mp3, vorbis, ac3, wav
ビデオ: divx3, divx5, xvid, vp3
若干のサンプルファイルは次の場所にある。
http://www.bunkus.org/videotools/mkvtoolnix/samples/
これによってLinuxとの相互運用性も確認される。
まだベータ版（開発テスト版）で実用段階でないことに注意。 MKVの特徴をアピールするものというより、とりあえず動くようになったことをお披露目する程度にすぎない。 OGMよりわずかに重いかもしれない、という程度で、 「最初のベータにしては、まあまあよく動くほうなのかな」というくらいの印象だろう。
MKVそれ自体も、多くのユーザにとっては、OGMでできることは、こっちでもできる、というくらいの違いしかないので、 OGMと同じような使い方をするのなら、べつに乗り換える切実なメリットがあるとも思わない。
一方、MKVの、OGM＋αのαの部分の機能を使いたいと考えているユーザにとっては、それなりの期待もあるだろう。 Linux上では、すでにSRTを入力としてS_TEXT/UTF8ストリームとしてマクスできる。 （<i>タグなどはLinux上では無視される。）UTF8なのでコードページ切り替えが要らず、マルチサバーにとっては福音となる。 WindowsでMKV内のSRTがサポートされるのはそう遠くあるまい。 さらにSSAやUSFがサポートされるだろう。そのあかつきには、現在OGMを使っているサバーの多く、 特にマルチサバーは、MKVを選択肢に入れるだろう。
OGMでSSAをサポートする話も前からあるので、 まだまだどうなるか分からないが、 一般のユーザで日本語字幕を使いたいなら、UTF8ストリームが標準となるMKVは、ひとつの選択肢となるはずだ。 （また画像ベースの字幕もそのままMUXできるようになるらしい。） さしあたってMKVは字幕をいじりたいユーザに関係することで、 映像と音声だけのファイルの場合、当分の間はOGMのユーザはOGMを使い続ければ良いと思われる。 近い将来的には、MPC(MP+)やFlacの音声が使えるので、というニーズも出てくるかもしれない。
VirtualDubMod の新系列 ver.1.5.x のバイナリーが正式公開された。
https://sourceforge.net/project/showfiles.php?group_id=65889
必要なDLLを別にダウンロードするかわりに、
VirtualDubMod_1_5_1_1a_all_inclusive.zip
を選択することもできる。
1.4.xとはメニュー構成が一部、大きく変更されている。 また、1.5.xでは、オープンソースとしては最初の、 汎用マルチメディア・コンテナ形式である Matroska Video (MKV) の読み書きをサポートしている。 ソースが公開されず不具合の改善や改良を自由に行えなかったOGMに代わる第三の選択肢として注目される。
注: AVI で VBR MP3 を使うには（Nandubハック。非推奨）、Options | Preferences | AVI メニューを参照。
同じビデオとオーディオを３種類のコンテナに入れた例（DivX4 + VBR MP3）
新しいTCMP RCがまもなく公開される予定。
このプレーヤーには、MKV用のDirectShow Filterが同梱されるというので、手動でフィルターを登録するのが面倒なユーザは、
TCMPをインストールするのも良いだろう。（ただし、現在のMKVは開発初期のテスト公開にすぎない。
面倒なことが嫌いなユーザは、そもそも最初から手を出さないほうが良い。）
注: 現行のRC3にはDSFはついてない。
DirectShow Filter:
http://matroska.sourceforge.net/downloads/kaxdemux-v0.3.0.zip
インストーラはないので、コマンドラインから手動で regsvr32 を使ってください。
TCMP RC3 - Matroska Edition build 41 (v4.00.41): MatroskaをデフォルトでサポートしたTCMP RC3の新しいビルドが公開された。
リンク先からダウンロードできる。このバージョンにはMKV DirectShowフィルター KAxDemux.dll が同梱されており、
インストール時に自分でフィルターの登録を行う（ファイルはインストール先のsystemサブディレクトリにある）。
したがって、regsvr32 を使う必要ない。
バージョンアップする場合、つまらないトラブルを避けるために、旧版をアンインストールしてリブート、 フォルダも削除してから新しいバージョンを入れると良い。 前に regsvr32 を使ってフィルターを登録した場合、最初に regsvr32 /u を忘れずに。
VirtualDubMod 1.5.1.1a は昨夜のメモ時点から正式公開までのあいだに突貫でCue挿入が改善された。 175.00MBのAVI（XviD+IIS MP3）を単にMKVにtransmuxしたところ、174.09MBになった。 （じつは、昨夜のビルドだと同じテストの結果が175.01MBになって、ほんのわずかにかえって大きくなってしまっていた。）
手元ではMKVの再生は冒頭で少しひっかかる傾向がある。 そこをすぎるとあとは最後までスムーズ。 断続的に起きるジッターでなく冒頭だけなので、コードの改善で解決可能な不具合だろう。
MPA2MKA, WAV2MKAの結果も、一般公開にふさわしく、格段に良くなった。 きれいに再生できる。今後、コメントタグなど原則UTF-8に統一される予定なので、 日本語の文字を使っても余裕でLinuxと相互運用できる。なお、MKAは元のファイルを収納するコンテナで、節約の余地がないので、 元のファイルより少し大きくなる。 MKVはインターリーブ（複数のトラックを合体させるときののりしろ）の構造の工夫によって、 同じことをした場合のAVIやOGMよりコンパクトになる。 175MBのファイルが画質音質に影響なく1メガバイト縮むと考えると、その1MBを音声にまわすとか、いろいろまあ、悪くはないだろうが、 現時点においては、すでに、小さくできることそれ自体はMKVの第一の意義ではなくなっている。
Matroska DirectShow Filter: KAxDemux.DLL 0.3.1
kaxdemux-v0.3.1.zip
5月1日に最初のパブリックベータが公開されたMatroskaだが、速くもDSFが更新され、 冒頭の数秒でジッターが発生する不具合が解決された。 0.3.1に入れ替えたところ、MKVの再生はなめらかで文句なし。 最初は「OGMでできることがこっちでもできるというだけで、今すぐ乗り換える意味はない」と思っていたが、 ここまでなめらかに再生が可能だと、ふと「これでシークがついたら字幕なしのソースはOGMにする意味ないじゃん」とも感じる。 OGMより175MBにつき1MBの割合で小さくなるし。OGMのオハコのVorbisも使えるし。
しかし個人的には、やはり字幕に期待したい。オープンソースのいいところで、SSA2MKSを開発している人もいるようだ。 先が楽しみなフォーマットと思う。
Media Player Classic 6.4.4.8――オプションメニューが洗練されて見やすくなった。 ファイルを開くダイアログ／関連づけメニューにさっそくMKA/MKVが加わった。
MKVtoolnix は、
から成るフリーソフトウェア。現在のバージョンは 0.3.1 で、 MKVtoolnixのページからダウンロードできる。 もともと Linux ツールだったが、Windows 用に移植された。バイナリーが公開されたほか、Cygwin 上でビルドすることもできる。
このうち、MKVmerge は、Cue挿入のコントロールなど、vdubmod ではできない柔軟な処理オプション指定が可能。 例えば、約24分124,734 KBのAVIをvdubmodでMKVにトランスすると124,221 KBになって0.5MBほどサイズが減るが、 MKVmergeのデフォルト（ビデオはキーフレームにキュー、他のストリームはキューなし）だと123,944 KBとなり、 このような24分120MBのファイルでも、約1MB小さくなる。なお完全にキューを入れない設定では123,936KBとなり、さらに微妙に縮んだ。 （キーフレームの割合などたかが知れているので、キーフレームにキューをつけてもつけなくても全体のサイズにはあまり影響しない。）
現在再生側がまだシークをサポートしていないので何とも言えないが、目的によってシーク速度の最適化とファイルサイズの最適化の両端のあいだで、 適切な選択をすれば良いだろう。 シーク重視の設定でMuxすれば、OGM（シークが速いと言われているものの実はIフレームをたどることしかできず案外もたつくこともある）よりいっそう軽くもたつきの少ないシークが可能になるらしい。
foo.mkvの基本情報を file に出力
mkvinfo foo.mkv > file
foo.mkvの詳細情報を file に出力
mkvinfo -v 2 foo.mkv > file
音声映像から成る foo.avi を
bar.mkvにトランス
mkvmerge -o bar.mkv foo.avi
音声ファイル foo.ogg と映像のみのファイル foo.avi を合体させて bar.mkv を得る
mkvmerge -o bar.mkv foo.avi foo.ogg
Cueコントロールの例
mkvmerge -o bar.mkv --cues iframes foo.avi --cues none foo.ogg
（これはデフォルトと同じ）
詳しくは付属のドキュメントをごらんください。
マルチオーディオやマルチサブのOGMで特定のトラックだけを更新したり、トラック番号を入れ替える方法。
OGMの作成では一般に、それぞれのトラックの成分となるファイルがひととおり準備できたあとでmuxを行うが、 muxされた完成品をテスト再生した結果、問題が見つかったりして、 muxを2度3度とやり直すことが珍しくない。
ところが、ストリームの数が10程度、あるいはそれ以上となると、 ストリームの1つを新しいファイルと入れ替えるだけのために全ストリームを個々のファイルから再構築するのは面倒だ。
このような場合、ファイルからすべてremuxする代わりに、 ほとんどの部分は古いOGMからそのままtransmuxして、更新すべきストリームだけファイルからremuxするとべんりだ。
応用として、例えば字幕ストリーム5と6を入れ替えるには、5と6の矢印をいったん削除したあと、 5→6、6→5をそれぞれ結線すれば良い。古いOGMの5はタグもろとも新しいOGMの6に移行し、 古いOGMの6はタグもろとも新しいOGMの5に移行するはずだ。 念のためにremux前にマルチプレクサのプロパティを確認する。
これらの作業はVirtualDubMod系でも実行可能だが、 2003年4月現在、VirtualDubModのビルドによってSRTの字幕最終行データがtransされない不具合があるので、コメント編集やtransmuxerとしては、VirtualDubModは避け、GraphEditを使う。
結線を.GRFファイルに保存してくのは基本的に悪い考えでないが、 GraphEdit上の編集が複雑になると編集情報が保存されないことがあるばかりか、 .GRFの保存では、物理的なファイルの位置が前回mux時から移動してしまっていたり、 何かのはずみで悪いファイルによって上書きされてしまっている場合、問題が発生する。
これに対して、既存の「ほぼ正しいOGM」からGraphEditでtransmuxすれば、既存のOGMのうち、テスト済みの良いトラックは、 そのまま新OGMにtransすることができる。（VdubModより信頼性が高い）
