前 9‒06 p ｜ 
もくじ i ｜ 次 9‒08 n 
<kow`> 「世の中には10種類の人間がいる。二進法が分かる者と分からない者だ」
<SpaceRain> はぁ？ だったら2種類の人しかいないじゃん
<SpaceRain> ばーか
<NES> 笑っちゃうよ
<NES> Napsterから何か落としたんだけど
<NES> 終了したとたん、ファイル送ってくれてた相手がさ、おれからその同じファイルを逆にダウンロードし始めるわけ。
<NES> PMして「何やってるの？ それそっちからもらったファイルだよ」
<NES> 「おれの曲を取り返してるんだろ、気違いめ！」
<Cthon98> ねえ、パスワードをタイプするとアスタリスクになるんだよ
<Cthon98> ********* ほら
<AzureDiamond> hunter2
<AzureDiamond> アスタリスクに見えないけど？
<Cthon98> <AzureDiamond> *******
<Cthon98> こっちからはこう見えてるんだ
<AzureDiamond> へー、ほんと？
<Cthon98> ウン、間違いない
<AzureDiamond> おれの hunter2 な hunter2 を hunter2 しれ！！
<AzureDiamond> ハハ、星がいっぱい見えた？
<Cthon98> ｗ うん、「きみが」 hunter2 をタイプすると、他の人には ******* と見えるわけ
<AzureDiamond> おもしろー。IRCにそんな機能があるなんて知らなかったよ
<Cthon98> うん、何度きみが hunter2 ってタイプしても、それは他の人には *******
<AzureDiamond> すげー
<AzureDiamond> 待てよ、なんでおれのパスワード知ってるの？
<Cthon98> そりゃー、あれだよ、「きみの」****** をコピペしただけ、そしたら「きみには」 hunter2 とか見えるんじゃないの、自分のパスだから
<AzureDiamond> ああ、そっか。
<Ben174> : ま、残業して手当てもらうっても、残業の90%はKazaaやりたくてだけどね。就業時間後は回線空いて速度でるからｗ ばれなきゃOK
<ChrisLMB> : うちの会社でそんなことやるやついたら、即刻クビだぞ
<Ben174> : へーどこの会社？
<ChrisLMB> : LowerMyBills.com の技術部長やってんだけど
*** Ben174 (BenWright@TeraPro33-41.LowerMyBills.com) Quit (Leaving)
<superwoman> わたしの元カレさー、口にビールがいっぱい入ってる状態で、口でなにさせたりしたわけ
<GrandCow> はははははは、おれだよ、それやったの、ばか！
<superwoman> ダニーなの?!?!?!
<GrandCow> お母さん?!?!?!?!
<kylev> がははははははは
<kylev> 腹いてー
<kylev> 今さ、なんか女の子がこの階に来て
<kylev> 叫んでんだよ、「社会学のレポートやってくれたら、体でお礼しまーす」とか
<kylev> で、一応どんなレポートなんだって聞いてみたわけよ、おれ
<kylev> 彼女が言うには「フェミニズムの成果と将来」だって
<`Neo> ハハハハハ
<Mendo> 笑 モニターに生意気そうな蜘蛛がいてさ、マウスを動かすと追いかけるんだよ
<spitfire> はは、何それ
<spitfire> スクリーンショットとって見してよ
<spitfire> ん、待てよ
<spitfire> それじゃ意味ないか
<lib1790> で、その大学では、特別に追加で単位がもらえる追加設問があったわけ。「地獄は吸熱的か発熱的か」
<lib1790> で、これがある学生の答案:
<lib1790> まず魂というものが存在すると仮定する。この場合、魂は質量を持たなければならず、
魂の分子1モルを考えることができる。ところで、魂の地獄への流入率・地獄からの流出率はどのくらいだろうか。
魂が一度地獄に入った場合、もう二度とそこから出ることはない、と仮定するのが妥当であろう。
ゆえに、流出率はゼロである。
<lib1790> 一方、流入する魂に関して言えば、今日世界に存在する多数の宗教を考慮すべきである。
これらの宗教のなかには、その宗教に属さなければ地獄に落ちると主張するものもある。
そのように主張する宗教は一つではなく、人々は二つ以上の宗教に属さないから、結局、すべての人間・すべての魂は地獄に落ちると考えられる。
現在の出生率・死亡率を考慮すると、地獄の魂の数は指数関数的に増加していると予想される。
<lib1790> では地獄の容積の変化率について考えてみよう。ボイルの法則によれば、地獄内の温度と圧力が一定に保たれるには、
魂の質量と地獄の容積の比が一定でなければならない。
<lib1790> もし魂が流入する速度に比べて地獄の膨張速度が小さいと、地獄内の温度と圧力は上昇し、最終的には地獄は爆発する。
すなわち、地獄とは灼熱であり、発熱的である。
<liv1790> もちろん、もし地獄の膨張速度が魂の増加率より速ければ、地獄内の温度と圧力は低下し、最終的には地獄は凍結する。
すなわち、地獄とは極寒であり、吸熱的である。
<lib1790> では前者と後者の、どちらが真実であろうか。わたしは、一年のとき、ある女子から遠回しにこんなひどいことを言われた。「極寒地獄みたいな極限状況で、なら、あんたと寝ることもあるかもね！」
今でも彼女と関係を持つことに成功していないという現実を考え合わせると、
極寒地獄というものは発生しないと結論せざるを得ない。
ゆえに、地獄は発熱的である。
<lib1790> ……単位がもらえたのはこの学生だけだった。
追記（2008年2月） RV10は当時としては悪くなかったが事実上開発が止まっており、 この数年でx264に完全に差をつけられた。現在、RV10を使う意味はほとんどない。 この記事は参考として残しておく。
一般ユーザ向けRV9/10 GUIフロントエンド。 再生法ではなく作成法の説明です。
RV10は現在、急速に開発が進んでいます。 特にこのメモは、RV10の2パス旧方式から新方式（Elysian）への移行期に書かれたため、 内容に混乱や流動的な部分が多々あります。参考のためにこの古いメモも残しておきますが、 各自、最新情報を確認するようにしてください。
RealVideo (RV) 9/10（総称RV40）は、低ビットレートに非常に強い。 評判の悪い RealPlayer とは無関係に、コーデックだけ使える。 640x480のサイズの通常の動画は、450Kbpsで一般に高画質と言われるクオリティーになる。 これはMPEG-4系コーデックで通常「高画質」とされるサイズの半分以下だ。
コーデックそれ自体としては、RV9/10は、超高画質志向でも使える。 昔の.rmファイルのイメージはもう当てはまらない。 Matrix 2 Trailerのサンプルファイルを見てほしい。 ただ、XviD 1.0 final版がリリースされている現在（2004年6月）、 一般には、高レートでは XviD 1.0 が良いと思われる。 XviD 1.0 のほうがエンコード速度が非常に速く、再生時負荷も RV9/10 より軽いうえ、再編集などもしやすいからだ。
今回は「少しエンコードに時間がかかってもコンパクトなファイルサイズでそこそこの画質にしたい」という目的でRV10を用い、 あわせて、非常に使いやすいGUIフロントエンド Easy RealMedia Producer (ERM) を紹介する。
「RealPlayer を使わないと .rmvb ファイル（RV9/10）を再生できない」という誤解があるようだが、 DirectShowフィルター（Realmedia Splitter）をインストールすれば、 ほとんどのWindows用プレーヤーで、.rmvbを再生できるようになる。 詳しくは、別記事「RealPlayer の導入法」。
今回の例はSKY PerfecTV! で再放送されたりもしている古典的名作「ベルサイユのばら」。 512x384という通常より一回り小さい画面なのに1話あたり250～350MBというかなり大きなサイズでエンコードされている。 40話あるので、このままCD-Rに保存すると、20枚近くになってしまう。 アニメの歴史に残る古典であり、ウテナの元ネタという意味でも資料的価値が高いので保存はしておきたいものの、 特に高画質でもないのにちょっとサイズが大きすぎる。 まとめて見たいときにCDを20回も入れ替えるのも面倒だ。
ところが、旧作ということもあって、RV10で一話平均87.5MB（映像450Kbps, 音声モノラル56Kbps程度）に落としても、見た目の画質はほとんど変わらない。 これならCD-R1枚に8話焼けるので、40話が5枚に収まる。 音声部分はそのままMP3を使えば再圧縮による劣化もなく手軽だ。 さらに、何話ごとかにまとめて1つのファイルにしてチャプターを打っておけば便利だろう。
1話（もともと1ファイル）を1ファイルに再エンコードするなら、話は簡単だ。 複数話をまとめて1つのファイルにするのも別に面倒なことは何もない。 VirtualDubMod（以下VDMと略）の Append Segment でつなげたいだけ連結して、DirectStreamCopy で1ファイルに書き出してしまうのが、 たぶん、一番手っ取り早い。ただし、何らかの理由で元のファイルの圧縮設定がばらばらだと、この方法では連結できない。 また、何話を連結したらいいか、あらかじめよく計算しておく必要がある。 例えば、CD-R1枚に入れたいのに、20話もつなげてしまったら、いくら何でもレートが足りなくなる。
もうひとつのやり方として、全部同じ設定で1ファイルごとに.rmvbにしておいて、 後から .rmvb 同士を rmeditor で連結する、という方法がある。 この方法は、仕上がりサイズがちょうど良くなるように何話連結するかを後で調整できる、という利点がある。 また、変換元の形式がばらばらでも大丈夫だ。が、逆に .rmvb を作るときに設定を全部同じにしないと連結できなくなるし、 rmeditor はコマンドラインツールなので、初心者には難しいかもしれない。
というわけで、一長一短なのだ。 1ファイルにまとめてチャプターを打つのは実用上も便利で魅力的だが、初めて挑戦するときは、 単純に1つのAVIファイルを1つのRMVBにしてみるのが無難だろう。
今回の例は「とりあえずとっておく」用であり、既に過去にDivXでエンコードされているデータの再圧縮なので多少の劣化は仕方ないが、 高画質志向でやる場合は、最初から huffyuv などの無劣化形式で変換元を用意する必要がある。
音声つきの変換元動画を読み込んで、音声も同時に（AACなどで）再圧縮するのであれば話は簡単だが、 今回の例のように、既にMP3などで圧縮されているものを再圧縮すると、劣化が起きる。 しかも、Real の AAC/HE-AAC（通称RAAC/RACP）は、AACエンコーダの中ではあまり一般の評価が良くない。 再圧縮しなければどうしようもない状況なら仕方ないが、この場合は再圧縮しないでそのままコピーできるので、当然そうする。 VDMでいったん読み込んだ変換元動画について、 メニューの Streams | Stream list から音声を demux （分離）すればいい。 変換元を連結している場合でも、ちゃんと連結済みの状態で音声が分離できるので、心配ない。
RealAudioで圧縮する場合は、変換元は16ビットでなく24ビットのWAVでも問題ないようだ。
Easy RealMedia Producer （以下ERMと略）をインストールして起動する。 このツールは、他のGUIフロントエンド（RealAnime, RealBatch, AutoRV9など）と違って、 producer.exe に相当するコンポーネントを自前で内蔵しているため、安定性が高い。 しかも RV10 Elysian や RACP（RealのHE-AAC）といった最新機能をちゃんとサポートしている。
少し前までは、XMLファイルをエディタで編集してやった内容が、 このGUIフロントエンドを使えば、ほとんど自動でできる。 最先端のオプションを実験するには今でもJobファイルを編集する方法が最も柔軟で確実だが、 標準的な設定で普通にエンコードするぶんには、これで十分。
ERMを起動したら、Add をクリックして、変換元のファイルをリストに追加する。 リスト上にドラッグ＆ドロップでもOK。 次に、リストでそのファイルをクリック選択して [Settings] ボタンを使い、設定ダイアログを呼び出す。 ほとんどデフォルトのままでも、それなりに動作するが、主な設定の内容を確認しておこう。
注意: 以下の説明は、旧方式の2パスを基本にしています。 別記事「[RV10] ERMPで新方式2パス」もごらんください。
AvgBitrate （平均ビットレート）でビットレートを指定する。仕上がりサイズから逆算するか、とりあえず、1回試してみれば、あとは比例計算で分かるだろう。 デフォルトの450はずいぶん低レートだが、RV9/10は、これでも相当に高画質。 超高画質志向にするなら900などにしてもいいかもしれない。
Max Bitrate（最大ビットレート）は、1パス方式では平均の2倍、2パス方式では平均の5倍でいい。 ただし、1パスで作ったものと2パスで作ったものをあとから連結する予定がある場合は、 Max Bitrate を同じにしておく。
もともとストリーミング用だったためだろうが、最大帯域幅は基本属性扱いである。 ビットレート設定が違うと「違う種類のストリーミング」とみなされ後で連結できなくなるから注意。 （追記: rmeditor update for raac and racp (rmto3260.dll) を使うと、ビットレート設定が違っても連結できるようだ。rmto3260.dll は最近の ERM に同梱されている。しかし、部分ごと圧縮した後になって、つなげられないことが分かるとへこむので、 無用な冒険は避ける、どうしても必要ならあらかじめ小さい断片でテストしてからにしよう。）
Startup Latency はデフォルトの60秒のままいじらないこと。 この値を小さくすると実質CBRに近づいて、動きの激しいシーンが荒れる。（RV10 Elysian の2パス方式なら、この値は関係ない。） Video Mode は「ノーマル、スムース（なめらか）、シャープ（くっきり）」などの中から適切なのを選べばいい。 とりあえずノーマルでやって、興味がわいたら他も試してみよう。Video Code (Codec) は、最新の RealVideo 10 で良いでしょう。 Audio Mode は、No Audio（音声なし）にして、後から別に作った音声を合体させるほうが高音質になるが、 面倒ならば、画像と一緒に RealAudio 10 などで圧縮してしまってもいい。
[ RV10/9 Settings ] をクリックして詳細設定に進む。 高画質志向では、EHQを有効にし、High にするといい（ただしそのぶん時間がかかる）。 2パス方式でエンコーディングするには Use Two Pass にチェックを入れる。 もちろん2パスの方が理想的なビット配分になる。動きが激しい場所と静かな場所が混ざっている場合は、特にそうだ。 その代わり、エンコード終了までに約2倍時間がかかる。 全体に中くらいの動きしかないソースでは1パスで問題ないこともある。 時間をかけても理想的にしたいのか、それともそこそこの画質で速くできるほうがいいのか、状況に応じて、決めよう。
注1: 1パス目（分析）は、実際にエンコードを行う2パス目よりかなり速いこともある。 単純計算で2倍時間がかかるわけではない。設定やソースにもよるので、いろいろ試してみてほしい。
注2: レートなどの基本設定が同じなら、1パスで作ったrmvbと2パスで作ったrmvbを連結できる。 とりあえず1パスでやってみて、オーバーサイズや画質上の不具合があったらそこだけ2パスでやり直すという手もある。
上の設定を閉じたら、Filter の [More...] をクリックして、フィルターの詳細設定に進む。 アニメの場合、理論上は、DropDup にチェックを入れるといい（デフォルトでチェックが入っているはず）。 特に旧作では連続している2フレームがまったく同じということがよくあるが（24fpsといいながら実質12fpsとか）、 それを検出して、同じなら脱落させてしまう前処理フィルタ。可変FPSのRVならではの大技だ。 数値は最大何フレーム連続で脱落させるか？ パラメータを2にすると3フレームが同じ絵だったら、2フレーム落とす。 パラメータが1なら、3フレームが同じでも1フレームしか落とさない。 1が安全だが理論上、大きいほうが効果が大きい。 といっても、5フレーム連続で同じ絵ということはほとんどないだろうから、4以上は意味がない。1～3だろう。
冗長な情報を省けること、 重複フレームをなくしたほうがRV40の動き予測アルゴリズムの効率が上がることのふたつの理由から、 このフィルターによって最大10%程度の画質向上が見込まれる。 ただし、あらゆるフィルターがそうであるように、必ず副作用があり、誤爆があるので、 レートに余裕があるなら、オフにしたほうが無難ではある。 ましてや開発途上の新しいフィルターだ。 今回はコンパクトを追求したのでオンにした。
実写の場合、前後のフレームがまったく同じということはあまりないはずだから、 余計なフィルターは使わないほうがいい。フィルターを入れればそれだけ無駄に処理時間が伸びる。
ついでながら、可変FPSということを別の角度から言えば、24fpsのソースと30fpsのソースのそれぞれを.rmvbにして、直接連結できることを意味している。この柔軟さは、場合によって、非常に便利だ。 RMVBコンテナだけでなく、MKVコンテナも可変FPSをサポートしている。
参考として、XviD のアルゴリズムでは、同じ（動きのまったくない）フレームが連続していると、サイズが単に小さくなり、 特に前処理をしなくても全く無駄がない。 フレームを物理的に脱落させなくても要するに「前のフレームと同じというフラグを立てておく」ことにすれば、非常に小さい情報量で同じことができる。
最後に、Output はデフォルトでは、Same as Input Path にチェックが入っている。 foo.avi をエンコードすると、同じフォルダに foo.rmvb が出る設定だ。 分かりやすくて便利だが、同名ファイルが既にあると上書きしてしまう危険があるので注意。 また（あまりないかもしれないが）変換元がCDにある場合、 その同じ場所に.rmvbを書き出そうとしても、普通、書き込めないからエラーになると思う。 一方、Specify a File Name の方にチェックを入れて [Browse...] で出力ファイル名と場所を指定することもできる。 この場合、複数ファイルをまとめて処理するときは、ファイルごとに出力ファイル名をちゃんと手動で指定する必要がある。
書き出したファイルは、次のファイルの処理が始まるか、ERMを閉じるまで、正常に再生できないことがある。
他にも細かい設定がたくさんあるので、興味があったら、いろいろ調べて試してみてください。
設定がカスタマイズできたら、SaveAsDef をクリックして、その設定を標準にしておく。 特に、複数の.rmvb を作って後から連結しようという場合、違う設定で圧縮してしまうとつながらなくなるので、設定を固定すべきだ。 なお、Save/Load ボタンを使って、複数の設定パターンをプロファイルとしてセーブ/ロードすることもできる。
以上のような感じで、リストにある変換元の全ファイルのエンコーディングを設定したら、 Start を押せばバッチ処理が始まる。実際にやってみれば、本当に簡単です。
Auto key frames または Use New Rate Control を使うと大きな不具合があるという報告があります。 1727の「MKVコンテナにすると映像が飛ぶ」に対するレスを見てください。 2パスアルゴリズムの新方式・旧方式が共存することが原因の混乱やバグの可能性もあります。 別記事「[RV10] ERMPで新方式2パス」もごらんください。
音声も同時に圧縮した場合、.rmvb自身を完成品としてもいい。 音声なしの.rmvbを作った場合は、MMGを使って、別に用意しておいた音声と合体させる。 このとき、チャプターデータを読ませることもできる。チャプターデータは、OGM互換形式のものが手軽で便利だ。
CHAPTER01=00:00:00.000 CHAPTER01NAME=01 オスカル！ バラの運命（さだめ） / Oscar! The Destiny of Roses CHAPTER02=00:23:42.326 CHAPTER02NAME=02 舞え！ オーストリアの蝶 / Fly! An Austrian Butterfly CHAPTER03=00:47:25.820 CHAPTER03NAME=03 ベルサイユに 火花散る / Sparks in Versailles
チャプターの文字コードは、Unicode（BOMのあるUTF-16またはBOMのあるUTF-8）が良く、 例えばフランス語やドイツ語の曲名など、特殊文字があっても、Unicodeなら問題ない。 日本語の文字だけなら、普通の日本語の文字コード（Shift_JIS）でもかまわない。 保存形式は普通に.txtでOK。
いずれにしても、MMGのGlobalタブの真ん中へんにあるChaptersからそのファイルを読み込む。 BOMのあるUnicodeなら、文字コードは放っておいても自動処理される（メモ帳でUnicodeで保存した場合は、既にBOMがついている）。 Shift_JISのファイルの場合、Charsetリストから手動でShift_JISを選択する。 どの場合でも、内部的にはUTF-8（つまりUnicode）で格納される。
Easy RealMedia Producer に同梱されている Easy RealMedia Editor でも簡単な作業はできるが、 最終的には、rmeditor や dtdrive といったコマンドラインツールが必要になるかもしれない。 複数の入力ファイルをまとめて1つのファイルにしたいときは、変換元の側で連結しておくのが手っ取り早いから、 コマンドラインが不得意なユーザはその方がいい。
.rmvbを作ってから、それらを連結する方法は次のとおり。
先頭ファイルを読み込んでから、 Settings で Paste Action を選び、くっつけるファイルをくっつける順番にリストに追加する。 GUIフロントエンドのため、コマンドラインから直接作業するほど柔軟にできない面もある。
rmeditor は、Producer 一式をダウンロードして解凍したら、解凍先のルートにある。 rmeditor がいる場合でも、商売気みなぎるHelix Producer Basic をダウンロードする必要はない。 オープンソースの Helix Communityにある Helix Producer 10 を使えば良い。 Helix Community のツールのなかには、ユーザ登録しないとダウンロードできないものもあるが、 捨てメールアドレス一本で済む話だし、それが嫌なら、souxin にもあるし、多くのRV9対応GUIフロントエンドにも同梱されている。
もうひとつの注意点として、rmeditor は、それ単体をPATHの通った場所にコピーしても動作しない。
相対パスで依存関係があるので（必要なコンポーネントごとツリーコピーしても使えるが）とりあえず元のアーカイブのままでフルパスで呼ぶのが良い。
コマンドライン例、
rmeditor -i in1.rmvb -i in2.rmvb -o out.rmvb [-l debug.log]
これで in1.rmvb と in2.rmvb をこの順番に連結して、out.rmvb を作る。 連結するファイルは3つ以上あっても良い。 -l スイッチはログを書き出すもので、なくてもいい。
全部無料のソフトです。
Easy RealMedia Producer & Editor (ERMまたはERMP)使いやすい。RV10 Elysian対応。 RAAC/RACP対応。 DropDupe対応。 JOBファイルを生成して producer.exe を呼び出すよくある簡易フロントエンドでなく、 producerコアを（スタティックリンクで）内蔵しているので安定性が違う。 RV9/10系のGUIフロントエンドとして非常に有望。 中国語ソフトだが、 メニューはインストーラーの最初から英語表示に切り替えられ、 使い方も直感的で分かりやすい。 もう RealBatch を待つのはやめて乗り換えようｗ 難しい設定は不要で、 インストールすればすぐ使える。 RVに興味ある篤志家はお試しください。 （初心者雑誌には適しません）
スレ（Easy RealMedia ProducerV1.71）
2004年7月27日追記 1.71のときの公式サイトは、 http://rick.icpcn.com/ でしたが、 現在（1.8）、http://redcheek.net/erm/ ミラー http://rick.crazyasp.com/ になっています。最新情報は上記スレッドでご確認ください。
この記事の読者でVDMを持ってないかたはいないと思いますが、
http://sourceforge.net/projects/virtualdubmod/
にあります。2004年6月6日現在、1.5.10.1 を適当な場所に解凍後、
Bugfixes (exe only) : 1.5.10.1 build 2439 を別途解凍して、最初に解凍したほうに全部上書きしてください。
現在のVDMは、エンコードのときのスレッド優先度を標準以外にすると（動作自体は問題ないものの）意図した優先度にならないことがあります。 単に映像部分をエンコードするだけの作業なら、ノーマル版のVDの方が軽くて、安定していると思います。 VBR MP3、Ogg Vorbis、AC3などがからむノーマル版ではできない作業、マルチオーディオ、チャプター編集、 OGMやMKV形式を扱うときは、VDMが必要。
MKVtoolnix というツール群のなかの、 GUIフロントエンド。OGMとMKVを広く浅くサポートしているVDMと違い、こちらはMKV専用でほとんど「できることは全部できる」。 MKVの作成には欠かせない。 2004年6月6日現在の最新公式版は0.9.0。 mkvtoolnix-0.9.0.rar と mkvtoolnix runtime archive （ ファイル名 mkvtoolnix-runtime.rar ）の両方をダウンロードして、 両方とも解凍して全部同じフォルダに入れてください。 バージョンアップのときは、runtime の方はそのままでOK。
以下の記事のなかには、一般向けのものと経験者向けのものが混ざっており、 内容もそれぞれその時点での最新情報なので、現状と合わない部分もあります。 適当に取捨選択してご利用ください。
追記（2008年2月） RV10は当時としては悪くなかったが事実上開発が止まっており、 この数年でx264に完全に差をつけられた。現在、RV10を使う意味はほとんどない。 この記事は参考として残しておく。
Easy RealMedia Producer を使ったRV10 の 新方式2パスエンコーディング。
RV10 の開発途中で導入された New Rate Control、いわゆる Elysian のことです。 従来の最大60秒の maxStartupLatency に縛られずに、柔軟にビット配分を行えます。
「avgBitrate、maxBitrate、maxStartupLatency」を使った旧方式の2パスも今でも利用可能で、 そちらの方が実績もあり安定しているかもしれません。目的によっては旧方式でも十分に良い結果が得られます。
以下では、分かりやすくするため「新方式2パス」と関係ないオプションは原則としてすべてオフとし、 そうした関係ないオプションの説明も省略します。 別記事「[RV9/10] Easy RealMedia Producer」も見てください。 用いたバージョンは Easy RealMedia Producer（ERMと略することもあるが以下 ERMP と略）の V1.83 です。バージョンアップで仕様等が変わる場合があります。 新しいRV10は、開発途上だけあって、いろいろと不可解な不具合もあるようです。 フィードバックは掲示板までお願いします。
このメモは、あくまで新方式2パスを使ってみたいユーザのためのものであり、 RV10エンコーディングを一般的におすすめしているわけではありません。
① 新方式でエンコードするときは、旧方式のVBRの設定は、無視されます（jobファイルの avgBitrate と maxBitrate）。 このパラメータは（どうせ無視されるので）何を指定してもかまいませんが、ここでビットレートを指定しても反映されません。 なお、このメモの範囲外ですが、jobファイルを使う場合、新方式でも、後方互換性のためこれらのパラメータは省略できません。
② [RV10/9 Settings...] ボタンで「RealVideo 10/9 Codec Properties」ダイアログを出して、詳細設定を行います（後述）。
③ DropDup（DropDupe）のオンオフ、設定は、Filter の [More...] で行います。
共通の注意事項として、設定内容は、[SaveAsDef] しない限り、その一回限り有効です。 言い換えれば、バッチ処理の場合、1回のエンコードごとに違う設定を適用させることができます。
① 新方式を使う場合、Use New Rate Control にチェックを入れます。
② Use Two Pass にチェックを入れてください。 新方式は、各フレームの複雑度を最後まで全部下調べしたうえで適切なビット配分を行います。 要するに「ふつうの2パス方式」です。旧方式と新方式の差は2パスのアルゴリズムです。1パスでやりたい場合、このメモの内容は意味がありません。
XviD や DivX と違い、 RV9/10 の旧方式では、2パスといえども最大60.0秒の範囲で平均レートを維持していました。これは、RealMedia がストリーミングを大前提として開発されたためでしょう。 ローカルで再生するなら前半10分暴れ回って、後半10分静かだとしたら、ビットを思いっきり前半に集めれば済みますが、 ストリーミングでは最大帯域幅が決まっているので、もしそんなことをすると10分くらいバッファリングしてからようやく再生スタート、 ということになり不便です。新方式の RV10 は、ある意味、そうしたストリーミングの制約を捨てたと考えられます。
③ 仕上がり希望サイズを Target Video Size としてKB単位で指定します。 1MB は 1024KB 、1KB は 1024バイトです。映像部分200MBにしたければ、204800 を指定すれば良いわけです。 このサイズには音声部分は含まれません。 後から音声と合体させる場合、音声ファイルの大きさと、合体のオーバーヘッドを計算に入れて、 トータルの仕上がりサイズが希望どおりになるように計算してください。
RC という略語は、レート・コントロール、つまりビットレート配分の制御のことです。
基本的なことですが、念のため…。 「1パス方式のエンコーディング」と「2パス方式のエンコーディングの1パスめ」を混同しないようにしてください。 1-pass encoding と 1st pass の違いです…。
「2パス方式のエンコード」では、同じソースを2回エンコードします。 仕上がりサイズを効率良くコントロールするためです。
100MBで仕上げろと言われても、ラストの方に動きが激しい（あるいは複雑な絵の）シーンがあるなら前半ではビットを温存する必要があるし、 逆に前半で動きが激しく後半が静かでシンプルな絵なら、前半にたっぷりビットを配分すべきです。 そうした計算をするには、まずはどんな動画なのか下調べをする必要があります。 これが2パス方式の第1パスで、このとき.passファイルに分析結果を記録しときます。
一方、別に仕上がりサイズなんて何メガバイトでもいい、ということもあります。 その場合は、動きが激しければそれなりにビットをたくさん使い、静かなシーンならビットを少なく使えばいいわけです。 これなら下調べが要らないので手っ取り早いですが、その代わり、仕上がりサイズがどうなるかはやってみなければ分かりません。
ときどき「2nd passを選択しても2パスエンコードができません」と訴える人がいますが、 いきなり 2nd pass encoding はできません。 2パスでエンコードしたければ、まずは 1st pass を選択し、それが終わってから 2nd pass を選択するわけです。
1パスめを行うには、 リストボックスから 1st pass を選択します。 1パスめのエンコード時に、フレーム複雑度を分析した .pass ファイルが生成されます。 また「どんな具合だか試しにエンコードしてみました」という 拡張子 .rmvb.null のファイルができます。 .pass ファイルは重要で、これをまず作らないと2パスめができませんが、 .rmvb.null のファイルはダミーなので、削除してかまいません。（もちろん最終的にエンコードが終わったら .pass ファイルも削除してかまいません。）
1パスめが終了した後で、2パスめだけを行う場合には 2nd pass を選択します。
ここまでは XviD や DivX と同じですが、ERMP では、1回の設定だけで、1パスめと2パスめを連続して行うこともできます。 VirtualDubなどで2パスエンコードをするとき、2回分のエンコードのバッチ処理になりジョブリストに2行追加されますが、ERMP の場合、 バッチ処理の「1行分」で1パスと2パスを両方やることもできます。 1パスめと2パスめを続けていっぺんに行いたい場合、 1st & 2nd を選択します。
注意点として、.pass ファイルは、XviDなどと違って名前を選べません。 filename.avi を1パスめだけエンコードするときは filename.pass になり、 1&2パスをまとめてやる場合、realvideo.pass というファイル名が用いられます。 （jobファイルを使うなら、 firstPassFile として任意の .pass ファイルを指定できますが、現在の ERMP にはこのオプションはありません。）
通常は、1st & 2nd を選択し、結果に問題があるなら、2パスめだけをやり直すことになるでしょう。
http://m17n.cool.ne.jp/freeware/
![メールアドレス（画像）: [ http://www.faireal.net/image/2005/addr.png ]](/image/2005/addr.png "メールアドレス <PNG画像>"){kind=small}