前 8 - 24 p ｜ 
もくじ i ｜ 次 8 - 26 n 
画像字幕はサイズが大きい割にソフトサブでもフォントの品質が落ちる。 その代わり、どんな言語のどんなフォントの字幕でも意図どおりのイメージで再生できる、という強みを持つ。
昨日（2003年12月28日）リリースされた Son2VobSub を使って、 SRTまたはSSAを出発点にオリジナルの VobSub形式字幕（idx+sub）を作成する方法を紹介する。 「画像字幕だから再生側の環境に依存せず同じ字幕を出せるが、 ソフトサブだから字幕のオンオフ・切り替えができる」という特徴をもっている。
Vobsub として知られる idx+sub は、画像ベースの字幕データだ。 これまで idx+sub は「DVD内蔵の画像字幕をそのまま保存する」という受け身の目的、つまり IFO→IDX+SUB で使われ、 創作字幕への応用はほとんど考えられなかった。 IDX+SUB をソフト的にMUXする方法がなかった。 ハードサブでは品質的に SSA にかなわない。 Vobsubでハードサブをするという意味はDVDのバックアップやリッピングに限られ、 ファンサブではわざわざ画質の劣る idx+sub 形式でハードサブする理由がなかった。 現在でも、オリジナルの字幕を作るなら、ハードサブでは idx+sub を使う意味はない。
IDX+SUB がソフトサブできるようになって、新たな可能性が生まれた。 IDX+SUB はソフトサブでは積極的な意味がある。SSA→IDX+SUBが実用的になったことで、この可能性は現実のものとなった。
テキストベースの SRT/SSA/ASS などでは、どうしても文字化けの問題がある。 ユニコードのサポートで技術的には問題は解決したのだが、再生側にその言語のフォントがまったくないと困る。 ブラウザで、最新の Mozilla を使ってもシステムにないコードポイントの文字は表示できないのと同じだ。
ソフトサブでは、フォント埋め込みのサポートもまだ十分ではない。したがって、スタイリッシュな任意のフォントを使って、 必ずちゃんと再生できるように保証する確実な方法は画像ベースの字幕なのだ。 再生リソースも比較的少ない。
ただし、これには欠点もあって、テキストベースに比べるとデータサイズがはるかに大きいうえ、絵であるからフォントの画質も悪い。 ソフトサブとはいえ輪郭がぼけている。もちろんアンチエイリアスもかからないし、テキストのように自由にリサイズすることもできない。 また現状、カラオケのような動的なエフェクトも使えない（画像字幕でも例えば24fpsで絵を変えることにより、 将来はエフェクトが使えるようになる可能性がある）。 良くも悪くも固定された絵だ。 ソフトサブなのでオンオフ、切り替えは可能であり、 ハードサブの安心感と、ソフトサブの魅力の両方を少しずつ持っている。 完全なハードサブほど絶対確実でない代わり、オンオフができる。 本格的なソフトサブほど美しくはない代わり、再生環境への依存が少ない。
基本的には、フォント埋め込みがサポートされれば、PC用動画としては Vobsub 形式で自作する意味はなくなる。 それでも、ハードウェアサポートを考えると、画像字幕は重要と考えられる。
まず実例の観察から始めよう。
これらは実際に作ってみたサンプルで、「ことり文字ふぉんと」などの特別なフォントを使用している。 画像字幕だから、再生側に「ことり文字ふぉんと」がなくても、このとおりに再生される。 字幕として十分実用になる品質だ。 市販の DVD の字幕では、これよりもっと不鮮明なものが多いから、このくらいきれいなら満足できるはずだ。
ただし、オリジナルのSSAと比べると輪郭がぼけ気味なのは否めない。 それでも、このSSAを指定フォントがない環境で再生すると何が起こるか分からない、ということを考えれば、 idx+sub も決して捨てたものではない。
Vobsub 形式でソフトサブすることの意味と限界が分かったところで、 実際の作業の説明に入ろう。
「Vobsub」という言葉は、字幕処理ソフトを指すことも多いが、 そのソフトが処理するファイル形式のことを Vobsub と呼ぶこともある（文字通り「VOBの字幕」）。 このメモで「Vobsub形式に変換する」などというのは、もちろんファイル形式のこと。 ちょっと紛らわしいが、「Vobsub」というソフト自身は、「Vobsub形式」以外の字幕データも処理できる。
繰り返し強調しておくが、以下は創作字幕の話であり、DVDの字幕をどうこうする話ではないので、 間違えて初心者向け雑誌などで紹介しないように注意してほしい。
以下、SSA字幕を用意でき、SSAの方がコンパクトで高品質であることを認識しつつ、 あえて特殊な意図で IDX+SUB 形式のオリジナル字幕を作成しようというかたを対象とする。
SSAから始める。SRTの場合、subresync などでSSAに変換しておく。 SSAの準備については既知とする。 不明の点はSSA入門 タイミング編とSSA入門 スタイリング編を参照。
初めにフリーウェアの MaestroSBT （doom9 の download コーナーにある）を使って、SSAをSON形式に変換する。 MaestroSBT は Gabest のツールと相互運用性が低く、経験者はかえってとまどいやすい。 Sub Station Alpha しか使わないなら、あまり問題は起きない。 Gabest系SSAと本家SSAの非互換について詳細は「SSA入門 スタイリング編」を参照。 問題になる点だけ簡単にまとめると、 まず、MaestroSBT はユニコードを通さない。日本語なら Shift_JIS で用意して SSA の encoding パラメータ128を指定する。 次に、ヘッダで16進カラーコードを使えない。10進で書く必要がある。デフォルトのスタイル名 Default に * をつけるかどうかは、 どちらでも通るようだが、問題が発生したときは、なるべく本家SSA仕様に従ってみるとよい。
つまり、これから間接的に Matroska に合体させる目的であるにもかかわらず、 VSFilter などのツールがサポートするSSAと微妙に異なるファイル形式を使うことになる。あとはだいたい使えば分かるが、 デフォルトではSSAのスタイル定義でなく自分自身のフォント設定を使う点に注意。 詳細については、付属の ReadMe.rtf 参照。
MaestroSBT では、日本語・中国語などが文字化けすることがある。 MaestroSBTの文字化け対策参照。
Generate コマンドを使って SSA を SON + SPF + BMP に変換したら、今度はそれを Son2VobSub で IDX+SUB に変換する。 こちらは使いやすく、しかも高速、ノイズも入らない。 オリジナルの IDX+SUB 作成は、従来、SubLog などを使った方法があることはあったが、あまりきれいにできず、 SSAの代わりとするには無理があった。 この Son2Vobsub を使うと、SSA にかなり近い品質の、IDX+SUB 画像字幕データを作れる。 SubLog で Vobsub 形式を自作した経験のあるユーザならこれは感動する。
こうして IDX+SUB が完成したら、あとはDVDから取り出したIDX+SUBの場合と同様に、MKV形式にMUXすればよい。 IDX+SUBソフトサブ参照。 注意点として、古いバージョンの Mkvmerge のなかには、オリジナルの IDX+SUB を読み込めないものがある。 （そのため、オリジナル Vobsub では、バイナリエディタで直接ヘッダを書き換えることもあった。） この問題は、0.7.8くらいで修正されたので、新しいバージョンを使おう。
MaestroSBT で日本語・中国語などの2バイト文字が文字化けする。手動で回避可能。
MaestroSBT は、SSA形式のテキストの字幕データを、SONなどの画像形式の字幕データに変換します。 MaestroSBT は、2004年1月現在、Unicode をサポートしておらず、Windows のコードページに依存します。 日本語なら Shift JIS です。 ところが、 2バイト文字の後半がSSAでの特殊文字 { （半角中括弧開く）にあたる場合が考慮されておらず、 カタカナの「ボ」、漢字の「本」「倍」「怒」などの文字がそのままでは文字化けします。
2バイト文字の直後に半角スペースを空けずにSSAのタグを書いた場合にも、 正しく解釈されないことがあります。
どちらの問題も、暫定的な回避が可能です。
これは MaestroSBT の問題です。SSA自身の問題ではありません。
Unicodeベースであれば、このような問題は原理的に発生しません。 例えば、UTF-8では、先頭バイト以外にASCIIと同じものが出ることはありません。 Unicodeベースでなくても、2バイト目にメタ文字と同じパターンがあるかもしれないことを考慮すれば、 回避可能です。
したがって、MaestroSBT のバージョンアップによって、問題が解決する可能性があります。 また、問題の挙動や、回避策がバージョンアップによって変わる可能性もあります。 このメモの記述は、Version 2.4.3.5 の場合です。
以下で説明する方法は、MaestroSBT 特有の問題の対策で、 一般的に SSA をこのように書くという意味では、ありません。
以下では Shift JIS で説明しますが、 日本語以外でも、ダブルバイト文字で後半バイトにこのようなパターンがあると、 同じ問題が発生すると思われます。
MaestroSBT では、例えば「ボク」が「ャN」に化けます。 Shift JIS の「ボク」は、83 7B 83 4E ですが、7B は SSA での特殊文字 { にあたります。 これが脱落して 83 83 4E が残りますが、 83 83 が全角カタカナの小さい「ャ」、4Eが半角の「N」なので、「ャN」と表示されます。
この問題の回避方法ですが、 MaestroSBT では { の直前が \ だと、 \{ はエスケープされて { そのものになるがその直後1バイトが脱落する、という変な挙動がありますので、 それをハックして、後半バイトに 7B がほしいときは、7B のところをわざと \ にして、 その直後に { とダミーの1バイト（以下#とする）を書けば、ちょうど良くなります。 結果として、入力の SSA のテキストは意味をなさなくなります。 例えば、「ボク」と表示させたいときは「ソ{#ク」と書きます。 「化けた結果がほしいものになるように、最初から逆方向に文字化け」させておくわけです。
繰り返しますが、これは MaestroSBT の文字化け対策にのみ有効であって、 一般のSSAでは「ボク」は「ボク」で良く、「ソ{#ク」などと書けば、かえって表示が乱れるだけなので、 ご注意ください。以下の裏技がすべてのバージョンで通用する保証もありません。
バイナリレベルでの編集のやり方が分からないかたは、 以下の表を参考にしてください。 この表はスクリプトで自動生成したもので、 1文字ずつすべて検証したわけでないので、最終的には必ず自分の目で確認してください。
| この文字を 使いたいときは | こう書く |
|---|---|
| ボ | ソ{# |
| 宮 | 欺{# |
| 須 | 申{# |
| 捜 | 曾{# |
| 畜 | 箪{# |
| 怒 | 貼{# |
| 倍 | 能{# |
| 府 | 表{# |
| 本 | 暴{# |
| 養 | 予{# |
| 几 | 兔{# |
| 施 | 蚕{# |
| 旬 | 十{# |
| 閲 | 噂{# |
| 顎 | 浬{# |
| 鶏 | 圭{# |
| この文字を 使いたいときは | こう書く |
|---|---|
| ＋ （全角） | ―{# |
| к（ロシア文字） | Ы{# |
| 砿 | 構{# |
| 學 | 媾{# |
| 悳 | 彌{# |
| 掉 | 拿{# |
| 桀 | 杤{# |
| 嘴 | 喀{# |
| 毬 | 歃{# |
| 炮 | 濬{# |
| 痣 | 畚{# |
| 窖 | 秉{# |
| 縵 | 綵{# |
| 艝 | 臀{# |
| 蛔 | 藹{# |
| 諚 | 觸{# |
| 轆 | 軆{# |
| 閔 | 鐔{# |
| 驅 | 饅{# |
| 黠 | 鷭{# |
| 垬 | 偆{# |
| 葈 | 砡{# |
| 傔 | 纊{# |
| 硺 | 犾{# |
字幕ではあまり必要ないと思いますが、MaestroSBT では、次のように書けばとおります。
| この文字を 使いたいときは | こう書く |
|---|---|
| { （半角） | \{# |
| \ （半角） | \\# |
実際にはあまりないかもしれませんが、 2バイト目が \ である文字の直後に { が来た場合、 当該文字の後半バイトと、その後ろの { が脱落してしまう、 というものです。単に2バイト目が \ であるだけなら無害で、 よくある「暴走」「可能」などの文字化けは、普通には発生しません。 2バイト目が \ で、しかもその直後が { のときだけ問題がです。SSA独特の { でタグを作る関連です。
この問題を引き起こす文字は、
―ソЫⅨ噂浬欺圭構蚕十申曾箪貼能表暴予禄兔喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭偆砡纊犾
であり、すぐ後ろに { を書きたい場合、\# を挿入すれば、うまくいきます。SSAとして本来、
可能{\fs24}なのかな
のときには、MaestroSBT では、こう書けば大丈夫です:
可能\#{\fs24}なのかな
文字化けする要素があるかどうか事前に検査したり、 文字化けする要素をしないように書き直すことは、 Perlスクリプトを使えば難しくありません。 作業用のコピーをとって、問題がある場所を事前に確認しておくのは良い考えかもしれません。
ここで必要な修正は「半角スペース挿入」のようなわりと無害なものではなく、 破壊的なので、スクリプトで自動処理させる場合は、慎重にやる必要があります。 「MaestroSBT で文字化けさせると、ちょうどうまく元に戻る」ように、絶妙に逆文字化けさせたかどうか、 というのは、入力側を見ても確信できないでしょう。 やはり出力側を目で確認すべきでしょう。 多バイト文字を使った場合は、出力前に、MaestroSBT のプレビュー機能で、 字幕を1行ずつチェックすることをおすすめします。 Enterキーを押すことで次の行、次の行と見れますので、通常、せいぜい数分から10分くらいで、 容易に全部チェックできるはずです。
ダメ文字検査スクリプト: msbtck.pl
中国語でも同様の問題が起きる。
低レートでは XviD より有利、 高レートでも素晴らしいポテンシャルがある、 と評判の RV9（RealVideo）ですが（サンプル）、 GUIフロントエンドに決め手がないのが実情です。 すでに RealBatch を使う方法をご紹介しましたが、 producer.exe を直接使うのがむしろ単純明快かもしれません。 そのとき必要になるのが jobファイル（.rpjf）というXML。 これで最新機能（EHQ、DropDupe）を含むすべてのオプションを完全にコントロールすることができます。 ちょっと試してみたので、ご報告します。
補助的なXMLを使って情報をコマンドラインに流し込むのは MKVmerge のタグファイルなどでも使われている手法であり、 この新しいやり方に慣れておくというのは動画作成者として損はないでしょう。 参考として audienceファイル（.rpad）を使う方法にも触れます。
コマンドライン、AviSynth、そして XML の3つについて最低限の理解が必要ですが、 実際の作業はたいして難しくありません。 コマンドラインがまるで分からないかたは、最初に「MP3・Vorbis・AAC―動画音声の話」を読んでください。
RealOne Player と RealMediaSplitter が存在していることは大前提とします。 （ RealOne Player は問題が多いので、初心者は手を出さないほうがいい。）
Helix DNA Producer 9.2 を用意します。 2003年6月以降のビルドでないと EHQ が使えないのでご注意ください。 例えば搜新を見てください。 producer.exe が本体です（以下 producer と略）。 AviSynth もインストールします。 2004年1月4日現在の最新版は 2.5.3 です。
フィルター済みのソースを huffyuv などで用意します。1分くらいの短いクリップでテストすると良いでしょう。 producer から確実に開けるためには .avs でラッピングしてしまうと速いです。
DirectShowSource("c:\path\filename.avi")
とりあえず、このような1行からなるファイルをエディタで作成して、input.avs とかの名前で保存したらOKです。
jobファイルは、プロジェクトファイルですが、 中身はテキストです（XML）。 標準の拡張子は .rpjf ですが、.xml で問題ありません。 .xml にしたほうが、ブラウザでエラーチェックできたり、ツリー表示できて便利です。 スケルトンとしては次のような感じになっています。 意外と簡単で、わけの分からないGUIフロントエンドより、分かりやすいです。
これを job.xml などの名前で保存して、
producer -j job.xml
とやるだけです。進行状況を詳しくレポートさせるように、-lc スイッチをつけると便利です。
producer -j job.xml -lc "e,w,i,d"
エラー、警告、情報、診断すべて出力せよ、という指示です。
コマンドラインについての詳細は、./docs/CommandLine.htm を見てください。
（-lc の引数の引用符は実際には省略可能です。）
注意 JobファイルはBOMのあるUTF-8ではなく、BOMのないUTF-8Nを使わないと、動作しないようです。 分からなければ半角英数字だけにして、Unicodeを使わず普通に保存しよう。
<?xml version="1.0" encoding="utf-8"?>
<!-- UTF-8で保存すること! -->
<job xmlns="http://ns.real.com/tools/job.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ns.real.com/tools/job.2.0 http://ns.real.com/tools/audience.2.0.xsd">
<!-- 2パスにするか: true か false -->
<enableTwoPass type="bool">true</enableTwoPass>
<parInputs>
<!-- 入力ファイル名 -->
<input xsi:type="avFileInput">
<filename type="string">c:\test\input.avs</filename>
</input>
<!-- DropDupe は後からここに追加 -->
</parInputs>
<parOutputs>
<output>
<!-- 出力ファイル名 -->
<destinations>
<destination xsi:type="fileDestination">
<filename type="string">c:\test\output.rmvb</filename>
</destination>
</destinations>
<mediaProfile>
<!-- 音声をここでは含めないという指示 -->
<disableAudio type="bool">true</disableAudio>
<!-- 使用するプロファイル名 -->
<audienceRefs>
<audienceRef>mySetting</audienceRef>
</audienceRefs>
</mediaProfile>
</output>
</parOutputs>
<audiences>
<audience>
<!-- これがプロファイルにあたる -->
<name type="string">mySetting</name>
<!-- 平均レート 450 KByte/s の例 -->
<avgBitrate type="uint">460800</avgBitrate>
<!-- 最大レート 2パスでは糸目をつける必要ない 平均の5倍にした例 -->
<maxBitrate type="uint">2304000</maxBitrate>
<streams>
<stream xsi:type="videoStream">
<!-- 以下3行はこのままで -->
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv9</codecName>
<encodingType type="string">vbrBitrate</encodingType>
<!-- EHQの設定は後からここに追加 -->
<!-- ストリーミングでなければ最大値で -->
<maxStartupLatency type="double">60.0</maxStartupLatency>
<!-- 最大フレームレート -->
<maxFrameRate type="double">23.976</maxFrameRate>
<!-- キーフレームがなくていい最大の秒数 -->
<maxKeyFrameInterval type="double">10.0</maxKeyFrameInterval>
</stream>
</streams>
</audience>
</audiences>
</job>
<?xml version="1.0" encoding=... のところは、Shift_JIS などとしても理解されません。 UTF-16でもパーサに不具合があるようなので、UTF-8が良いです。
まずは、このスケルトンの jobファイルを使って producer で rmvb を正常に作れるところまで、 持っていってください。 多少の試行錯誤は必要かもしれませんが、本質的に難しい点はないはずです。
では、ここまではできた、という前提で、 上のスケルトンをどうカスタマイズするか、と、EHQなどの設定をどう追加していくか、 という本題に入ります。
<enableTwoPass type="bool">... は false で1パス、true で2パスです。 動きが少ないソースでは1パスでもレートを守れるかもしれませんが、 動きが多いソースでは1パスでは、指定よりサイズがかなり大きくなる傾向があります。 やはり2パスで最適の配分になります。 テストのときは面倒なので、false で良いでしょう。
disableAudio は、入力に音声があっても、 音声はここでは（RM形式で）圧縮しない、という指定です。 通常、音声は Vorbis や AAC のほうが良いでしょう。 RM音声を使いたい場合は、ここは false ですが、その場合、下の audience のほうで、 音声の圧縮設定が必要になります。 一般的なフロントエンドから指定できる以上に、音声の設定はたくさんあります。
平均レートは必要に応じて設定してください。 最大レートの方ですが、 1パスでは最大レートをあまり大きくすると、最大側に振れきったまま清算できずに終わって、 ファイルサイズが予定より大きくなる可能性があります。 「激しい動きだな。後で静かになったら借りは返すぜ」と思って未来のビットを前借りしまくっていたら、 未来にはさらに動きが激しくなって困るような場合です。 「ご利用は計画的に」と思って、最大借り入れ限度額を厳しくしたらいいかというと、 それはそれで激しく動いているのに割り振るビットがなくなり、 おまけに先へ行ったら止め絵ばっかりで「何のためにあんなに節約させたんだ……」という事態にならないとも限りません。 1パスでは、理想のビットレート配分というのは無理です。「この品質ではちょっと」とやり直すくらいなら、 最初から2パスにするのが「急がば回れ」というものでしょう。
2パスでは最後まで分析してから「この程度の動きはまだ序の口だわい、節約節約」とうまくやりくりしてくれます。 maxStartupLatency は、どのくらいの秒数で帳尻を合わせながらやりくりをするか、です。 あまり絞るとVBRの意味がないし、あまり緩めると清算できずに終了する危険が出ますが、 2パスでは最大値で良いでしょう。仕様書には最大は25.0となっているのですが、60.0まで行けるみたいです。 この値は、ストリーミングのとき、その人の帯域幅を最大どのくらいオーバーできるか、 という意味も持ちます。 レートが低い部分が先行していれば、帯域に余裕があるうちに未来の分まで送ってしまえるわけです。 しかし、レートが高いところから始まっていると、後から平均すれば減るとしても、 しばらくバッファリングしないとスタートできなくなります。 （Real Player などで「バッファリング中」といって待たされた経験があると思います。） このパラメータの「最大開始遅延」というのは、そういう観点の名称ですが、 それは結局のところ、ビットレートの補償をやっていい最大時間ということで、 どのくらい激しくVBRできるか、ということとほぼ同じです。
より詳細なリファレンスと実例は、./docs と ./samples/jobs を見てください。 リンクがおかしいところなどの不備も多少ありますが、 JobFile.htm と AudienceFile.htm を見たら、だいたい分かるはずです。
既定値をそのまま使えばいいものはjobファイルに書かなくても大丈夫です。 上のスケルトンが、samplesにあるものよりかなりシンプルになっているのは、そのためです。
EHQはXviDのVHQのように、 動きの表現を最適化することで、 まったく同じ事柄を最大30%程度少ないデータ量で表現できるようにするものです。 要するに品質は同じでいちばんコンパクトになる方法を探そうとします。 EHQをかけてサイズを減らしても品質は落ちませんが（視覚心理系ではなく差分表現の最適化）、 捜索時間がかかります。これは、テキストなどを圧縮するときに、ZIP、RAR、ACEなどを次々試して、 いちばん縮む書庫形式を見つけたらそれにする、というのを、繰り返せば、ZIPならZIPで決め打ちするより数倍時間がかかるのと同じです。 2パスの場合、当然、同じレートで画質があがるわけです。
上のスケルトンで、 <!-- EHQの設定は後からここに追加 --> とある場所に、 次のようなコードを追加します。
<codecProperties type="bag">
<encoderComplexity type="uint">80</encoderComplexity>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
encoderComplexity がパラメータです。 65では時間はほとんど変わらずに、ある程度の最適化ができるそうなので、 忙しい人も常に65はやって良いでしょう。 70で高い効果が現れますが、2倍時間がかかります。 80で非常に高い効果がありますが、コストは通常の3～4倍です。 状況によって選択することになるでしょう。詳しくはRV9-EHQスレを見てください。 上の4行も、そこからコピペしました。
「非常に高い」といっても最高で30%程度の節約です。4倍の時間をかけてまでビットを20～30%節約する価値があるかどうかは、 状況によるでしょう。
前後で同じフレームをドロップすることで最適化するものです。 アニメで効果があります。 RV9 Animation DropDupe Pre-filterで videodupframedropper.dll を入手して、./Tools に入れてください。 入れなくてもエラーにならず警告されないので、作用しているかどうか確認したほうが良いでしょう。 詳しくはリンク先にあるのですが、次のようなコードを追加します。
<prefilters>
<prefilter xsi:type="videoDupFrameDropper">
<enabled type="bool">true</enabled>
<maxDroppedFrames type="uint">3</maxDroppedFrames> <!-- 1の方が安全という説も -->
<maxAvgSSD type="uint">700</maxAvgSSD>
<maxAreaSSD type="uint">6000</maxAreaSSD>
<maxAvgChromaSSD type="uint">200</maxAvgChromaSSD>
<maxAreaChromaSSD type="uint">1500</maxAreaChromaSSD>
<earlyExit type="bool">true</earlyExit>
<enableDetailedLogInfo type="bool">false</enableDetailedLogInfo>
<pluginName type="string">rn-prefilter-dupframedropper</pluginName>
</prefilter>
</prefilters>
参考までに、実際のjob.xmlを置いておきます。
音声も同時にRM形式で圧縮した場合は、.rmvb が完成品です。 Vorbis や AAC(MP4) や MP3 や AC3 などの音声を使う場合には、 MKVToolnix で MKV 形式で結合します。 （ドキュメントを見ると、 .rmvb でも Vorbis は格納できる余地があるような気配で、 実際、./tools に audiovorbiscodec.dll があるので何か方法があるのだと思います。）
./producer.log にデバッグ出力が出るので、特にエラーがあるときは、どこが問題なのか、 参考にしてください。
jobファイルの方が強力ですが、
参考までに、.rpadを使う方式も紹介します。
jobファイルのAudienceの部分だけをXMLで指定するものです。
サンプルは ./audiences にあります。
この場合、入力と出力は、コマンドラインから、
producer -i input.avs -o output.rmvb -ad audience.rpad [-dt]
のようにやります。
-dt (Disable Two-pass) をつけると1パスです。つけないと2パスです。
プレフィルタを使わないなら、
こっちのほうが分かりやすいかもしれません。
この方法ではプレフィルタを書く場所がないので注意。
RV10 では、RV9 よりさらに品質が向上したばかりか、 AAC, HE-AAC, Lossless の音声圧縮もサポートされるなど、 可能性が広がっている
Cost 833.6 milliseconds.