AMD phenom 960T BE(6コア化)からFX-8350へ変更してからハードのマッチングがずれた。
どうずれたかというと、全く持って私の環境独自のものであるのだが、割安な深夜電力を利用できる時間内で処理できるCPU能力とそれに付随するSSD容量のバランス。
TSファイルからmp4へTMPGencVMW5を使用してのエンコード。
120GB（実質111GB)で960Tだとちょうどの時間で完了できる能力だったが、今では二時間程度早く終了する。
それだけ効率化した証左なのだが、今までがわかりやすかっただけに使いづらい。
単純に計算して20～30GB増やせればいいが、そんなサイズのちょうどいい容量がない。 🙁
ちなみに、エンコードを速くするためにSSDを導入する効果は少ないと思われる。
結構な処理能力のCPUで、同時処理エンコード数を上げていけばHDDのシークタイムよりも絶対的に短いから効果があるだろうが、それはむしろ記録ハードがCPUなどに追いついていないだけのことで、SSDにすればそれを解消したに過ぎないだろうし。
それよりも編集画面での表示スピードが向上するおかげで効率が上がるというメリットの方が大きい。
RAID0なHDDならSSDと遜色ないが、私はシークの多発を抑えるために一度SSDに転送してからエンコードするように変更した。
RAID0なうえにマスターのバックアップがないので、リスク回避目的で。
＜2013.09.17追記＞
windows7のシステムディスクとプログラムファイルフォルダ、エンコードtempフォルダなどを40GBのHDDでまかなっていたが、たまにtempフォルダから溢れてエンコードがエラーで終了することがあった。
やはり容量が少ないのは厳しい。
そこで上記の検証も含めて、250GBの2.5inch HDDへお引っ越し。
そもそもちょうどよい容量のSSDがあればそれが一番だったが…。
todo backupで移動。
変更はHDDのみ。
ADATA AS510S3-120GM-Cやramディスクは変わらず。
ただし、40GBのHDDの転送速度が遅いからといって、検証に使うには少々古すぎる。
実用に耐えない、現実離れした小容量HDDは検証しても意味がない。 🙄
単純にシークの発生する同時処理で検証。
TMPGencの設定「先読みキャッシュの設定」
「エンコード時に映像の先読みを行う」＆「エンコード時に音声の先読みを行う」をオンオフで似た環境を作る。
実情に合わせて三つのTSファイルをバッチ処理で同時処理。
サイズはフルHDからQHDへ縮小リサイズ。
フルHDのTSなので10～20Mbps前後、これが三つ同時（縮小リサイズでCPU負荷は小さい）にキャッシュ無しで読み込み、グラフを一目見てはっきり解るほどの違いではないが、全く同じ状況にも関わらずCPU負荷は若干少ない。
キャッシュオフだとHDDがボトルネックになり得る。
目で見てすぐ解るのがHDDアクセスランプ。
キャッシュ無しだとHDDランプが延々と点滅を繰り返す。
シークが間に合っていない。
一方、最大サイズ512MBのキャッシュオンだとほとんどアクセスがない。
これから至るに、サーバーCPUでなければエンコードのスピードアップのためにSSDの必要性はあまりなく、HDDで比較的新しいものなら必要充分な性能を有している可能性が高い。