前回のエントリでPhotoFast G-Monster-V2をRAID0で投入してみましたが、いよいよ（個人的には）本編の、SSDでエンコード速度が向上するのかを試してみます。
　より実際に使用する例に近く、ということで、今回は24分程度のアニメ動画を用意し、DivXへのエンコードを試してみることにしました。何故今までと同じ（実写動画をH.264エンコード）ではないかというと、実写ソースならH.264にしたほうがよく見える→わざわざDivXを使用しなくとも、H.264を使用する→H.264ならどう頑張ってもFIRECODER-bluには勝てない、という理由からです（笑）
　さらに今回は、せっかくIntel Core i7を使用しているのだから、ということで、Intel Turbo Boostを有効にして計測してみました。
■ 元データ情報
映像コーデック：Canopus HQ Codec（オンライン－標準）
音声コーデック：非圧縮WAVE 48kHz
ソースの解像度：1920×1080（29.97i）
ファイルサイズ：11,146,128,668バイト（10.3GB）
クリップの長さ：23分34秒
■ エンコード環境
M/B : MSI ECLIPSE SLI
CPU : Intel Core i7-920
Memory : DDR3-1066 1GB×3
OS : Windows Vista Service Pack 2β
HDD : BUFFALO HD-QS2.0TSU2/R5（RAID5 / eSATAへ接続）
SSD : PhotoFast G-Monster-V2 ×2（RAID0 / ICH10Rへ接続）
エンコーダ : TMPGEnc 4.6.3.268 ＋ DivX 6.8.5製品版
TMPGEncのフィルタ : デフォルト設定
DivX Codecの設定 :
　レートコントロール＞「1パス-品質依存」
　コーデックパフォーマンス＞「最も優れた品質」＋「SSE4を使用可能」＋「エンハンスドマルチスレッド」
※出力解像度＆音声フォーマットとDivXのフィクスドクォンタイザは後述します。
※HDDでもSSDでも、入力元ファイル／出力先ファイルは同じドライブを使用しています。つまりHDDならHDDから読んでHDDへ書き、SSDならSSDから読んでSSDへ書き込んでいます。
▼ ケース１：出力解像度を640×360 29.97i（SD）、音声をmp3 192kbps Joint Stereo、クォンタイザをQ4にしたケース
　まずは単純にHDソースをSDソースに変換する例です。画像は左列がHDD（上段がTurbo Boostオン、下段がオフ）での結果、右列がSSD（こちらは両方ともTurbo Boostオンで、上段がストライプサイズ128K、下段が4K）での結果となっています。

　

　結果を並べると、31分14秒：27分46秒：26分00秒：25分46秒ですので、HDD/Turbo Boost無しを基準とするとそれぞれ 0分 0秒：－3分28秒：－5分14秒：－5分28秒、クリップの長さと比較した割合はそれぞれ 132.5％：117.8％：110.3％：109.3％ となり、予想通りの結果となりました。とはいえ（人によっては）たった1分46秒の差が6.5万（RAID0なら13万）、と考えると微妙とも言えますが、ここをプラス思考として考えるのなら、13話分まとめてバッチエンコードすると約1話分時間が空く、ということになります（＾＾；
▼ ケース２：出力解像度を1920×1080 29.97i（HD）、音声をmp3 192kbps Joint Stereo、クォンタイザをQ4にしたケース
　読み書きの量が多くなれば、当然差も広がってくるのではないかと考え、HDソースをHDソース（のDivX動画）に変換する例で比較してみます。画像の並びは先と同様、左列がHDD（上段がTurbo Boostオン、下段がオフ）での結果、右列がSSD（こちらは両方ともTurbo Boostオンで、上段がストライプサイズ128K、下段が4K）での結果となっています。

　

　順番に結果を並べますと、42分42秒：40分17秒：36分24秒：36分09秒、差はそれぞれ 0分 0秒：2分25秒：6分18秒：6分33秒、クリップ比ではそれぞれ 181.2％：170.9％：154.5％：153.4％となります。HDへの出力では4分程度の差が発生しているあたり、SSDの強さを遺憾なく発揮したというところではないでしょうか。
　逆にストライプサイズは、ベンチマークの数値ほど影響を与えていない結果になっているのも興味深いと思います。この辺りはCrystalDiskMarkやHD Tuneの測定ロジックによるところだと思いますし、アクセス方法はアプリケーション毎に違いますから、難しいところではないかと思います。
▼ ケース３：出力解像度を640×360 59.94p（SD）、音声をmp3 256kbps Stereo、クォンタイザをQ2にしたケース
　いわゆるインタレソースの2倍fps化というヤツです。最近はインタレ保持したままでも、再生側でデインターレース処理を行うことで綺麗に表示することが出来るようになっていますが、色々と考えるのが面倒くさいので（笑）ウチではこの設定を主に使用しています。なおこれはSSDのみで、ストライプサイズでの比較を行っています。

　結果は26分03秒 対 27分02秒 で、これはなんと逆にストライプサイズの大きい方が1分程度早い、という結果になりました。
　で、さらに同じ設定を Core2Quad Q6600＋HDD で実行してみたものはこちら。

　ソースの3倍弱となる、1時間04分03秒で処理が完了していました。Core i7（TurboBoost有り）＋SSD（ストライプサイズ4K）であれば、ほとんど同じ時間で 1920×1080 59.94p、音声 256kbps Stereo、クォンタイザQ2 のしているあたり、技術の進歩は凄いなあ、と痛感しました。
—
2009/01/05 6:47追記：
　Core2Quad Q6600のエンコード時間ですが、映像クロップフィルタと音声ノーマライズフィルタが追加されており、全く同じ設定ではありませんでした…申し訳ありません。
—
▼ SSDをICH10RのRAID0でなく単体で使用した場合はどうか
　左からケース１、ケース２、ケース３、オマケの1920×1080 59.94p Q2 の順です。

　　　

　SD画質のQ4というかなり限定された構成（ケース１）では、23分19秒（98.9％）とやっと100％切りを達成。ICH10RはソフトウェアRAIDなので、この処理にかかるCPU負荷が、SSDのRAID0化で向上した速度よりもエンコードに影響を与えた、という結果になりました。
　それ以外もケース２が36分07秒、ケース３で27分09秒、オマケで1時間03分08秒となり、いずれもICH10RでのRAID0より早いか、またはほぼ同じ時間となっています。つまり容量以外ではソフトウェアRAIDにする意味は何もない、ということになります。
　エンコードでプチフリーズ判定ができるのかどうかはわかりませんが、少なくとも読み書きを激しく行っているはずのエンコード処理において、目に見えて処理が停止するようなことは全くありませんでした。（もっともプチフリーズは、複数のI/Oが並列に発生しないと起こらないので、エンコード処理くらいでは該当しないかもしれません）
■ まとめ
– H.264へのエンコードは素直にハードウェアエンコーダを使用したほうがよい。（これは前から変わらず）
– ソフトウェアエンコードでIntelプラットフォームなら、Core i7＋Turbo Boostで使用するのをオススメ。（※AMDプラットフォームは、省電力のe系統しか触っていないのでよく分かりません^^;）
– PhotoFast G-Monster-V2使用では、HDDよりそれなりに早くなる。ただし価格に見合っているかどうかは各個人次第。
– PhotoFast G-Monster-V2＋ICH10RでのRAID0には、”エンコード速度”の観点に限った話ではうまみがほとんど無い。
– ただしまともなハードウェアRAIDコントローラでのRAID0では、結果が変わってくる可能性がある。
　以上、多分全く参考にならないレビューをお届けしました＾＾；

　最初タイトルに「～を試す」と付けたら、某Watchみたいな見出しになったので却下。
　というわけでPhotoFastの赤SSDことG-Monster-V2を2台購入してみましたので、早速色々テストをしてみました。
　マザーはMSIのECLIPSE SLIで、RAIDも試したいという魂胆からDriveBooster（JMicron 322）のSATAコネクタに接続、ベンチマークを取ってみました。

　…あれ？Readで140MB/s？
　じゃあRAID0にしてみたらいいのか？と…

　まったく変わらない結果にがくり。
　これはオンボードRAIDコントローラではやっぱりしょんぼりな結果にしかならんのか、と思いつつ、上田新聞blog版を見てみると、ICH10Rで200MB/s越えの結果が。
　で、早速現在ICH10Rに接続されているHDDをJMicron 322側（※このコントローラ側からでもブートできる上に、仮にこのコントローラの転送速度が最大140MB/s程度だったとしても、HDDなので十分）につなぎ替え、逆にICH10RへSSDを接続してみると…

　

　ほぼ期待通りの値、READで209MB/s、WRITEで163MB/sとなりました。
　では気を取り直してRAID0（ライトバックキャッシュOFF）にしてみます。

　

　Sequential READは268MB/sになりましたが、Sequential WRITEは133MB/sと低下、逆にRandom READ/WRITE 512KBはそれぞれ237MB/s、85MB/sと上昇。またHDTuneのBurst Rateは低下、という妙な結果となってしまいました。
　これでも十分早いし…と思ってはいましたが、やはり納得できなかったためGoogle先生に聞いてみたところ、ストライプサイズを小さくすると良い（ICH10Rのデフォルトは128K）らしいとの情報が。
　早速ストライプサイズを4Kにして論理ボリュームを作成してテストをしてみます。

　

　IntelのSSDでRAID0を組んだケースには遠く及びませんが、容量は2台構成のRAID0で3倍程度で、価格差は現時点で約＋2万ですから十分とも言えます。
　逆に言うと、単体で512GBになれば、容量以外ではほとんどRAIDにする意味が無いかもしれない、という点ではなかなか面白いかもしれません。（もっとも、まともなハードウェアRAIDカードを付ければ結果は違うのかもしれませんが、残念なことにそこまで投資できませんでした。そもそもICH10RであってもIntel SSD RAID0で470MB/sくらい出せるので、キャッシュ以上の速度向上はあまり見込めないのではないか、と思ったためです）
　HDDと比べると圧倒的な速度となりましたので、次回はこれがエンコード速度に影響を与えるのか、チェックしてみようかと思います。
—
2009/01/04 15:13追記
　Google先生に聞いてみたところ、inDEXさんがAreca ARC-1680ix-12というハードウェアRAIDカード（10万以上する高級RAIDカード）で試される予定であるというエントリーを見つけました。ちょっと期待。

　様々な誘惑に負けてしまいました…

　ということで主たる使用用途であるところのエンコード比較をば。
　幸いなことに前回FIRECODER bluのベンチマークで使用した素材がありますので、これを使用してみました。ただし諸般の事情により、全く同じOSではないのでご注意ください。
　なお使用したエンコードソフトウェアは前回同様、TMPGEnc 4.6.3.268です。
■元データ情報（前回と同じものです）
　1440x1080iのHDVテープをEDIUS 5でキャプチャした、Canopus HQ CodecのAVIファイル（※SS｜EX Vol.4で撮影していた動画です）をエンコードしてみます。
映像コーデック：Canopus HQ Codec（オンライン－標準）
音声コーデック：非圧縮WAVE 44.1kHz
ファイルサイズ：3,093,904,724 バイト（2.88GB）
クリップの長さ：4分30秒
■Core2Quad Q6600（定格動作）でのエンコード
＜エンコード環境＞
M/B : ASUS P5B-E
Memory : DDR2-800 1GB×4（ただしMemory Remapにより2GBしか使用していません）
OS : Windows Vista Service Pack 1
H.264へのエンコード時間（前回のデータより）：17分51秒
DivXへのエンコード時間（前回のデータより）：28分20秒
※DivXへのエンコードは、TMPGEnc内蔵のエンコーダを使用しています。
■Corei7 920（定格動作）でのエンコード
＜エンコード環境＞
M/B : MSI ECLIPSE SLI
Memory : DDR3-1066 1GB×3
OS : Windows Vista Service Pack 2β
H.264へのエンコード時間：11分27秒（Q6600比：64％）
DivXへのエンコード時間：16分54秒（Q6600比：60％）
※DivXへのエンコードは、DivX 6.8.5製品版のエンコーダを使用しています。
　実写動画なので、DivXにするメリットはあまりなかったりもするのですが一応比較してみました。Q6600での比較で6割程度になっているあたり、かなり速度が向上していることが見受けられます。もっともこれくらいであれば、圧倒的にSpursEngineのほうが早い（SpursEngineでは最長で3分29秒）ということも、面白いデータなのではないかなと思います。
　ここで何故エンコーダがTMPGEnc内蔵なのとそうでないのが分かれているのか、ということをご説明しますと、何故かTMPGEnc内蔵DivXエンコーダで、同じソース画像を食わせると、エンコードの最後でアプリケーションエラーとなり、正確なデータが取れないからで、やむなくこのような方法になってしまいました…
■オマケ
　ところである意味本編になりかねない、ソースが24分程度のアニメ動画についても比較してみました。
　コーデックは同じくCanopus HQ Codecで、クリップの長さだけが異なります。また出力フォーマットは1920×1080ではなく、640×360のSD画質にしてみました。
Q6600でのDivXエンコード時間（Q4）：41分41秒
i7-920でのDivXエンコード時間（Q4）：32分35秒（78％）
※これはともに内蔵エンコーダを使用
　興味深いのは、このときCPU負荷率が（1スレッドを除いて）30％程度であったところで、ハードディスクがボトルネックになっている可能性があることです。この辺りはもう少しなんかやってみるかもしれません（笑）
■まとめ
　エンコード目的でDivXなどのソフトウェアエンコードを行う場合は、Core i7を使わない手はないような気がします。もっとも、手頃なマザーの登場とメモリの値段が下落しているとはいえ、7～8万円かかるあたりはまだまだかなあ、と思ったりもします。普段使いだったらAMD 780G＋TDP45WのAthlon X2で十分ですし、コストパフォーマンスは最高ですからね。
　ところで気になっていた騒音と発熱についてなのですが、CPUファンであるASUS Triton81を100％フル稼働させると（轟音ではないにせよ）なかなかの騒音となります。ただ、回転速度を50％くらいに落とすと静かになりますし、そのときの温度は室温20度くらいで38度程度、H.264でのエンコード時は60度程度ですので、思ったほど熱くも五月蠅くもない感じでした。
　ただ、うちの環境だけなのかもしれませんが、NVIDIAのCUDA対応ドライバをインストールすると、何故か次から二度とOSが立ち上がらなくなる（起動直後にハングする）現象に悩まされています。もっとも「前回正常起動時の構成」で起動できるので問題はなく、また幸い使用しているのがGeForce 8800GT（G92コア）なので、古いバージョンのドライバを使用することで解決しているのですが、原因がさっぱり分からず…　今使用している8800GT固有の問題であると根拠なく判断して、GTX260の新コアをつっこんでしまおうか、なんてエンドレスな状態になっています（笑）
2008.12.28追記：
　結局9800GTX+にしてみましたが、やはり同様の事象が発生しています。色々検証してみた結果、どうもCore i7＋GeForce（Release 177以上）＋HDRECSの組み合わせがいけないようで…　トムカノユーザーフォーラムでも書いた（同名のH/Nが使用されていたので、適当に思いついた名前になってます＾＾；）のですが、年明けにもユーザーサポートに投げてみようかと思います。
　ちなみに9800GTX+の場合、Guru3DでForceware 175.70をダウンロードしてインストールすることで回避できます。GTX260/280は177以上しか無いようなので、もしかしたら駄目かもしれません。

　ここ最近はベンチマークばっかりのような気がしますが、まあそんなもんなんでしょうね…
　というわけでThomon-Canopus（旧Canopus）製SpursEngine搭載H.264エンコーダ、FIRECODER blu（http://www.thomson-canopus.jp/catalog/firecoder_blu/firecoder_blu_index.php）のベンチマークを取ってみましたので、遅まきながらだらだらと。
■元データ情報
　1440x1080iのHDVテープをEDIUS 5でキャプチャした、Canopus HQ CodecのAVIファイル（※SS｜EX Vol.4で撮影していた動画です）をエンコードしてみます。
映像コーデック：Canopus HQ Codec（オンライン－標準）
音声コーデック：非圧縮WAVE 44.1kHz
ファイルサイズ：3,093,904,724 バイト（2.88GB）
クリップの長さ：4分30秒
■テストケース
＜ケース１：FIRECODER bluでH.264変換＞
Blu-ray出力時の解像度変換：1920×1080
1920×1080時の画質設定：最高品質
＜ケース２：TMPGEnc 4.6.3.268でH.264変換＞
　素材はすでにEDIUS 5で編集済みということで、TMPGEnc側でのカット編集やフィルタ設定は、デフォルトで入ってしまうインターレース解除と映像リサイズを除き実施／追加していません。
　またコーデックの設定は、FIRECODER使用時とある程度条件を合わせるために以下のようにしています。
・映像設定
　プロファイル：Main
　レベル：自動（4.1以下）
　フレームレート：29.97fps（インターレース）
　レート調整モード：1パス 可変ビットレート
　それ以外はデフォルト
・音声設定
　エンコーダ種別：AACエンコーダ
　サンプリング周波数：48000 Hz
　ビットレート：384kbps（※CBRには出来ないのでVBRになります）
　それ以外はデフォルト
＜ケース３：参考情報 TMPGEnc 4.6.3.268でDivXへ変換＞
　TMPGEnc上で出来る設定はほとんどありませんが、最高品質設定でクォンタイザを4に設定しています。
　CPUはCore2Quad Q6600（2.4GHz）、CUDAはフィルタを使用していないので、自動でOFFとなりました。
■エンコード結果
＜ケース１：FIRECODER bluでH.264変換＞
・エンコード品質＝画質優先
　エンコード時間：3分29秒
　ファイルサイズ：652,615,680 バイト（622MB）
　平均ビットレート：18Mbps
・エンコード品質＝標準画質
　エンコード時間：3分21秒
　ファイルサイズ：442,312,704 バイト（421MB）
　平均ビットレート：12Mbps
・エンコード品質＝容量優先
　エンコード時間：3分18秒
　ファイルサイズ：244,131,840 バイト（232MB）
　平均ビットレート：6Mbps
※音声はどの設定でも48kHz/384Kbps/CBRで固定
　実際に見比べてみますと、元々のソースはHDV（MPEG-2 1440×1080 1080i 29.97fps 25Mbps）となっているわけですが、そもそもの素材が比較的暗所で撮影されているためか、そこまで大きな映像の破綻はありませんでした。とはいっても、標準画質と容量優先では、ある程度差が分かるという印象です。
　処理時間が微妙に違うのは、単にHDDへの書き込みが多いためなのでしょう。
＜ケース２：TMPGEnc 4.6.3.268でH.264変換＞
エンコード時間：17分51秒
ファイルサイズ：345,272,196 バイト（329MB）
　当たり前ではありますが、ソフトウェアエンコードには非常に分が悪いテストとなりました。
　ところでTMPGEncでエンコードしたH.264動画は、なぜかMedia Player Classicでは綺麗に再生できないんですよね…　音声がVBRだと駄目、とかあるかもしれませんね。
※2008/12/06 18:06追記※
　そういえば画質について触れていませんでしたが、Nero 8のShowTimeで確認するかぎり、FIRECODERの標準画質とそれほど大きな差はないような印象です。あくまでソースが自分自身で撮影した動画をそのまま使用しただけなので、おそらく編集でテロップとか出したりすると、明確な差が現れるようになるのではないか、と思われます。
＜ケース３：参考情報 TMPGEnc 4.6.3.268でDivXへ変換＞
エンコード時間：28分20秒
ファイルサイズ：609,738,286 バイト（581MB）
　当然ではありますがもっとも遅く、また容量も比較的大きくなりました。元々DivXの場合、ビットレートがかなり激しく上下するので、実写動画だとかなり容量が大きくなる傾向があります。
　逆にアニメーションなど、DivXが得意とするジャンルでは、（エンコード速度は置いておいて）ファイルサイズはH.264の半分程度になったりします。
■まとめ
　結局は映像素材とコーデックを使い分けるべき、という当たり前の結果になってしまいました（笑）　こりゃやっぱりCore i7導入するしかないのかな…なんて＾＾；
　でもなんだかんだいって、このエンコード速度はかなりやみつきになりそうです。
※2008/12/06 18:06追記※
　重要なことを書きそびれていますが、あくまで現時点では、「EDIUS 5で取り込んで編集してH.264へエンコードする」という、比較的狭い使用用途に限って、かなり役に立つボードなのではないかなと思います。それ以外は正直まだまだじゃないかなと。
　いかんせんまだ全然使い込まれていないボードですので、今後のソフトウェア展開次第では面白いことになるのではないでしょうか。

　今までBUFFALOのTeraStation ProとTeraStation Livingの二台構成を使用していたのですが、FullHDのDivX動画（SS｜EXで撮ったもの）をTeraStation側に置いておき、それを見るとどうもカクついてしまうのが気になっていました。しばらくは仕方ないかー、ということで我慢して使用していたのですが、つい最近になってITmediaでQNAP製TS-409Proのレビュー（http://plusd.itmedia.co.jp/pcuser/articles/0808/13/news007.html）が掲載されているのを見てしまいまして、静かみたいだし、冬にもリプレースしようかなあ、と思っていたわけです。
　そんなこんなしているうちに、その上位機種であるTS-509 Pro（http://www.unistar.jp/product/qnap/turbo_station/ts509pro/）が発売されました。Celeron 1.6GHzのCPUと1GB Memoryを搭載する、要するに小型PCのNASなのですが、その分価格も4万円くらい高く、二の足を踏んでいました。
　が、ここで物欲が収まることはなく、結局購入してしまいましたので（笑）取り急ぎベンチマークをお届けします。
　なおTS-509 Proは1TB×5（Seagate ST31000340NS）をRAID-6で使用、TeraStationはPro/LivingともにRAID-5で使用しています。
＜ベンチマーク環境＞
　CPU : Intel Core2Quad Q9300
　OS : Windows Vista Business SP1
　Memory : 2GB
　NIC : Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller
　→ JumboFrame 9014バイト設定
　注）クライアントは同一ですが、NASの接続に使用しているケーブルタイプ、ケーブル長はそれぞれ異なります。
　　　TeraStaion Living：フラットタイプ／CAT.6／2m
　　　TeraStation Pro：普通のUTPタイプ／CAT.5E／1.5m
　　　QNAP TS-509Pro：フラットタイプ／CAT.6／7m
　まずはTeraStation Living（JumboFrame:7K／Firm:1.14－左）、TeraStation Pro（JumboFrame:7K／Firm:1.22－右）のベンチマーク結果です。

　

　実際に同じケーブル長、同じケーブルタイプでベンチマークをとってもTeraStation Proのほうが良い数字を出していますし、体感も少し早く感じます。
　続いてQNAP TS-509Pro（JumboFrame:なし／Firm:2.03－左）、あとは参考として取得したNetwork上にあるWindows XP／AthlonX2 BE-2350機のディスク（RAIDなし－中）、ローカルディスク ST3320613AS（RAIDなし－右）のベンチマーク結果です。

　　

　さすがにローカルディスクには勝てませんが、それでもTeraStationと比較しても倍以上の速度が出ています。
　もっともこれはベンチマークテストの結果なので、実際の転送はそこまでの速度はでない（Vistaのダイアログによると大体47MB／s～50MB/s程度）のですが、それでも十分早いことが分かります。また、先の”カクついていた”動画についても全く問題なく再生できるようになりました。
　それとダウンロードステーション（PC無しでNASがダウンロードを行う機能）が結構便利で、LinuxのCD/DVDイメージなどの比較的大きなデータをダウンロードするのによく使用しています。
　そんなTS-509 Proも、TeraStation2台よりは若干五月蠅いという欠点はあります。それでも十分静かなのですが、エアフローのための筐体内部の空洞、それに全面吸気口が比較的大きいので、そのせいなのかもしれません。
　またSeagate ST31000340NSも書き込みがゴリゴリと音を立てるタイプのディスクなので、正直あまりオススメではありません（＾＾；　二年保証にこだわらなければ（そもそも二年以上使いつづけ…ゲフンゲフン）静音／低発熱と噂のWesternDigitalのWD10EACS/EADSあたりを使用するのが、コストパフォーマンス的にも良いと思います。
　少し高い買い物ではありましたが、プチプチと途切れながらの動画を見ることが無くなったこともあり、非常に満足しています。
　今回もっとも後悔している点は、やはりBarracuda ES.2にこだわってしまったことでしょうか…ね＾＾；