Cubase6バージョンアップ

少し遅れましたが、Cubase6にバージョンアップしました。

A5サイズのコンパクトなパッケージ。製本マニュアルはクイックスタートのみ。

まだほとんど試していない状態ですので、詳細は書けませんが、

バージョンアップのメリットとしてはCPU負荷が下がること、視認性がよくなること。

少なくともこの2点は挙げられると思います。

今回はCubase5.5.3がすでに入っているところへ

Cubase6もインストールするというシチュエーションになっております。

これまで同様バージョン違いは同じOS内に同居可能です。

ただし、Cubase5が入っている場合、Cubase6の初期設定ファイルが

正しく作成されないことがあります。

その場合はCubase5の初期設定フォルダを別に場所に移動させておいて、

Cubase6を起動し、6の初期設定フォルダが作成されたのち、

Cubase5の初期設定フォルダを元の場所に戻せばよいでしょう。

初期設定ファイルの場所はWindows7では次の場所です。

C:\Users\ユーザー名\AppData\Roaming\Steinberg

この中の「Cubase5」「Cubase5_64」フォルダを別の場所に移動させておきましょう。

ただ、この場合Cubase5からの設定が自動では引き継がれませんので、

ショートカットなど各種設定でCubase5のものを引き継ぎたい場合は

面倒かもしれませんが、「Cubase5」フォルダから「Cubase6」フォルダへ

コピーしましょう。

フォルダの構造は基本的に同じですので、同じ場所にコピーすればOKです。

どの設定がどのフォルダ、ファイルなのかはマニュアル等でご確認下さい。

さて、今回はとりあえずCubase6の負荷についてだけ簡単にまとめておきます。

Cubase5.5.3で作成していたプロジェクトファイルを

単純にCubase6で開いてVSTパフォーマンスのメーター値を比較します。

VSTiは20個ほど、エフェクトはUADやWavesなどを多用、
その他マスタリング系の重めのものも使用しています。

Cubase5.5.3(32bit)、バッファー64サンプル

Cubase6.0.0(32bit)、バッファー64サンプル

厳密ではありませんが、大体同じ秒数のところで撮っていますから、

負荷の違いが分かります。劇的な差とはいえないですけれどね。

実際に走らせている感覚では軽いというのがもっと分かると思います。

ちなみに同じファイルを64bit版で読み込んで測定したのは次の通りです。

Cubase5.5.3(64bit)、バッファー128サンプル

Cubase6.0.0(64bit)、バッファー128サンプル

こちらはほぼ同じくらいですが、実際に走らせている感覚では

Cubase6の方が少し軽いと感じます。

ただ、前からも書いている通り、64bit非対応のプラグインがVST BridgeやjBridgeで

動いておりますので、その分5と6での差が出ていないといえそうです。

ちなみに32bitと同じバッファー64では再生できませんでした。

（レッドランプ点灯、バリバリノイズが入ります）

そのため128にしています。

おそらくすべて64bitネイティブのプラグインで作ったとしたら、

5と6の差は32bit版と同等の差が出るのではないかと思います。

とりあえず今回はこんなところで。

Cubaseネタばかりが続いているので、次回は他のプラグインについて書いてみたいと思います。

Cubase64bitと32bitの負荷の違いについて

SSDの新型がこれから続々と登場しますね。
すでに登場したIntel 510シリーズ、
3月登場とされているCrucial C400シリーズ、
そして4月中旬発表のIntel 320シリーズ。


僕的にはC400の256GB、512GB、
Intel 320の300GB，600GBがいくらなのかが
気になりますね。


音源のライブラリーに使用するので、
容量もそこそこ必要になります。
となると、速さとの兼ね合いでC400にする可能性が高いですかね。
あと在庫処分でC300の256GBが安ければ、それもありですね。


さて、本題ですが、Cubase5.5.2の64bitと32bitでの負荷の違い、
以前のブログでも書きましたが、今回はスクリーションショットも載せて
簡単に書いてみたいと思います。


現在作っている曲のTD前の状態で計測しています。


あと64bitは32bitで作っていたプロジェクトファイルを開いただけなので、
64bit用に最適化されているわけではありません。
といっても普通に開けば、64bit対応プラグインはそれに置き換わり、
32bitしかないものはVST Bridgeや予め仕込んでおいたjBridge版が起動します。


計測時点で64bit非対応プラグインとしては、
UAD-2が10個、Wavesが5個、IKのAmplitube3が2個、CSRとかT-RackS3が3個、
Flux:: EpureIIが2個が立ち上がっています。


ソフトシンセはまだ書き出してはいません。


VSTiのラックには16個ほど。
VEProも使っていて、そこに複数起動させたりもしているので、
実際には20数個立ち上がっていると思います。
※全部使っているわけではありません。


負荷の差として出てくるのは、主にVST BridgeやjBridgeを介したものとなります。

CPUはCore i7 980X（オーバークロックはなし）
バッファーは96サンプルにしています。
オーディオI/FはFireface800です。


まずは32bit版。

次は64bit版。

再生はノイズだらけで正常には使用できません。


ちなみにバッファーを128に上げてやると、

これだと正常に再生されました。


UAD-2なんかは本来負荷はほとんどないんですが、
jBridge介すると、やっぱり負荷が増えてしまいます。
ただ1個目はぐんと増えますが、2個目からは微増といったところです。


このようにバッファー大きめでも構わないって人だと
64bitも行けるかもしれないです。


大きめといっても5～6年前だと128で再生できれば
十分低レイテンシーといえたでしょうしね。


ただ、より低レイテンシーで安定して使いたい人には
32bitがよいかと思います。
もちろんWavesやUADなど、
64bit非対応プラグインは一切使わないという人は
積極的に64bitで行かれるとよいでしょう。



僕の場合はWaves、UAD-2、できればIKも。
これらが64bit対応してくれるまでは、
32bit+VEProで行こうと思っております。

メーカーさん、早く対応させて下さい！

システムをSSDにするにあたって

年末に新しく導入したPCはシステムをSSDにしました。

SSDは容量と値段のバランスからMLCタイプを選んでいます。

MLCは書き換えが1万回とか言われているので、

システムに採用するのはどうかなと思っていましたが、

最近はMLCタイプのSSDをシステムディスクに採用しているPCも結構見かけるし、

MacBookAirもそうですから、いいんじゃないの、と軽い気持ちで採用しました。

それに

http://botchyworld.iinaa.net/ssd.htm#spec

を拝見していますと、Intelなど信頼できるメーカーのものであれば、

そんなに寿命を気にする必要はないかなと思えます。

それに決してHDDの方がSSDより長持ちするってことも言えませんしね。

ちなみに僕が使っているのはIntel X25-M 120GBです。

フォーマット後は約111GBになります。

そこにWindows7 64bit Professional、

さらに音楽制作ソフトやら事務用ソフトやら結構な数をインストールして

現時点では空き容量53GBです。

120GB以上を選んでおけば、まず大丈夫でしょう。

あと寿命の点からも空き容量がある程度ある方が安心です。

さて、最近のSSDはそんなに寿命を気にしなくてもよいだろうと書きましたが、

それでもなるべく書き換えは減らすようにしたいものです。

精神衛生上からも。

でも神経質過ぎるのも考えもの。書き換えを減らそうとする余り、

何でもかんでもHDDに移動させていては、SSDのメリットも薄れていきますからね。

現状僕がやっているのは次のことです。

1.メールデータ、一時ファイルなど頻繁に書き換えが行われるものはHDDに移動させる。

ただし、簡単にできる範囲で。

ユーザーフォルダをすべてHDDに移動させたりはしていません。

ドキュメント、ミュージック、ダウンロードフォルダなど基本的なところだけ。

メールソフト、ブラウザ、それぞれで一時ファイルの場所とか、データ保存先は設定

できるはずなので、それは各ソフトでやっていきます。

いまやっているのはメールソフトのThunderbird、IE、Evernoteなどですね。

GoogleChromeは簡単にソフトで設定はできないみたいなので、

いまのところ、そのままです。つまりSSDにあります。

ただ、このように設定しても、試しにシステムディスクで

今日の日付で更新されたファイルを検索すると、

ぞろぞろ出てくるんですよ。

なので、この辺は実は気休め程度かとも思ったりするんですが、

それでもやらないよりはいいと思うので、という感じです。

※ユーザーフォルダを移動させると、この部分はぐんと減らせるようには思うのです。

ただ、どうも上手く行きませんでした。移動はさせられたのですが、

デスクトップの設定が初期化されてしまっていたり、

ログイン時に少し時間が掛かったり等々。多分失敗しているからでしょうが。　

2回ほど試してみましたが、駄目で、これ以上時間を掛けるわけにもいかず、

現時点では取りやめることにしました。

今後もよほど気が向かないとやらないかも。いい意味での割り切りもできました。

あと、OSが管理している一時フォルダの場所は次のようにして変更します。

現在はIドライブ（HDD）に設定しています。

2.ページングファイルはシステムディスクは「なし」にして、HDDに。

ページングファイルの容量は1024MB。

システム管理だと35GBくらいに設定しようとするんですけれど、

RAMが24GBあるから、1GBくらい設定しておけば十分らしいので。

あと初期サイズと最大サイズを同じ値にしておくと、

仮想メモリの断片化を防ぐことができるらしいので、一応そのようにしています。

3.バックアップを常にしっかり取っておいて、ディスク交換が必要になっても

スムーズに復旧できるようにしておく。

現状ではフリーのParagon Backup ＆ Recovery 2011をメインに、

OS標準の「バックアップと復元」も月一くらいで取っています。

Paragonの方はソフトのアップデートとかする前には必ず取っています。

一度バックアップを取ればあとは差分バックアップでOKです。

Paragonでは一度復元テストも行っております。

バッチリ、問題なく復元成功でした。

いくつかSSDをシステムディスクにする際の（僕なりの）ポイントを書きましたが、

なんだかんだいって、結局バックアップが一番大事かなと思います。

そしてこれはSSDに限らずパソコンを使う人すべてにとって大事ですね。

音ネタをSSDに置くことでどれだけ高速化できるか

今回システムをSSDにしましたが、あらゆることが高速でとても快適です。

特にCubaseを起動させながら、ブラウザやメールソフトなどを次々に起動させてもストレスなく、

ササッと立ち上がるのは何とも爽快です。

しかし、音楽制作者にとって最大のメリットはやはり大容量の音ネタに使うことです。

まず第一弾としてSpectrasonicsのOmnisphere、Trilian、StylusRMXをSSDに移しました。

SSDはIntel X25-M 120GB。値段がいま2万円を切るくらいで、速さと信頼性など、

バランスの取れた製品だと思います。

速さではCrucial Real SSD C300が現状最速のようですが、今回はIntelで行きます。

当初お手軽に増設できることからeSATA+2.5インチHDDケースという構成で考えていました。

しかし、eSATAは残念ながら3.0Gbpsと書かれていても、その値は出ないことが分かりました。

ボード次第かもしれませんが、僕が使っているセンチュリー「ポートを増やしタイ」シリーズの

eSATAでは3.0Gbpsと謳われているものの、ベンチマークでは120MB/sくらいしか
出ませんでした。これでは折角のSSDのメリットがありません。
現在内蔵で積んでいるHitachiの7200rpm 2TBでもそれ以上の速度が出ていますから。
まあ静音化にはなりますけれどね。

というわけで、予定を変更して、内蔵ポートに搭載することにしました。

結果260MB/sくらいのシーケンシャルリードとなりました。

　では、実際どのくらい速くなったかを
　簡単に検証してみます。
　Omnisphereの比較的軽いパッチなどは
　瞬時にロードしてしまえて、
　具体的なロード時間を測るのは困難です。
　そこで、激重のTrilianのパッチで、
　ロード時間を測ってみたいと思います。
　計測はiPhoneのストップウォッチを使って、
　パッチ名をクリックした瞬間から計測開始、

　完全にロードが終わったら計測終了とします。

　プリロードメモリーサイズの設定はHDD/SSDとも
　同じで、起動後初めてパッチをロードした時、

　つまり前に読んだサンプルがRAMに残っていない
　状態で測定しました。

　プリロードメモリーサイズは11時くらいの位置でした。
　（左の画像参照）


なお、こういうのはベンチマークと同じで何回か計測してその平均値を出すべきですが、

時間が掛かってしまいますので、１回だけ測った値であることをお断りしておきます。

厳密な検証が目的ではないですので。

●HDD（2TB,7200rpm）　※ライブラリーの移動前に計測　

Trilian AC2 True Staccato（以下AC2） 　　　　2374.3MB　　39.2秒

Clean Fender　True Staccato（以下Fender）　1183.3MB　　28.9秒

StudioBassAll TrueStaccato（以下SB All）　　1176.9MB　　34.1秒

ほぼ同じ容量のCleanFenderとStudioBassに差があるのは、

HDDの記録場所によるものかもしれません（CleanFenderの方が少し外周なのかも）

あるいは、たまたまそうなったという誤差の範囲。
あるいは、容量はほぼ同じでもStudioBassの方がファイル数が多いのかもしれません。

●SSD(Intel X25-M 120GB）

AC2　　　11.4秒　　　　　　　　　　

Fender　12.7秒　　　　　　　　

SB All　　12.7秒　　　　

かなり速くなりました。


参考までにメモリー関係の３つのツマミをすべて最小値にした場合の計測結果です。

AC2　      10.9秒

Fender　   8.4秒

SB All　   11.4秒

３つとも9時に設定した場合。　

AC2　      11.5秒

Fender　    8.3秒

SB All　   11.2秒

なぜかプリロード最小よりも早いパッチがありますね。

この辺が1回しか測っていないというアバウトな検証結果ならではですが、

そんなに大きな差はないという印象です。体感的にもそう思いました。

ちなみにOmnisphereの場合、以前ここの値を小さくし過ぎると、
書き出しの際に音飛びを起こしたことがあります。もちろんHDDの時です。
で、12時手前くらいの位置で解決したので、以後Omnisphereはその位置で使っていました。

今回SSDということで最小値で行くか、とも思いましたが、
それによって格段に速くなるわけでもないので、
とりあえず9時ぐらいに設定しておいて、
問題があれば増やすという感じで行こうかと思っています。

なお、Omnisphereの方が経験上Trilianよりも少し多くしておく方がよいと思います。

このようにSSDはやはり相当なメリットがあります。

ただ、eSATA+裸族などの多段ケースで8台増設、なんて目論見は
もろくも崩れ去ってしまいました。

次回はシステムをSSDにするにあたって、僕が注意したことを書きたいと思います。