Cubase のオートメーションはデバイスのバッファサイズに依存する
「teo」という Windows 用の仮想 ASIO ドライバを作った話。
Cubase
にはわりと昔からずっと引きずっている問題がひとつある。
それはタイトルにも書いた通りの症状なのだが、細かく説明するとこうだ。
Cubase でオートメーションを書くとき、こんな感じで線を引くことができる。
こう引くと、音声はフェードアウトし、完全に無音になったあと少し間をおいて元の音量に戻る。
特に何も珍しいことはない普通のオートメーションの使い方なのだが、詳細にデータを見ると実はオーディオの書き出し時にこれはイメージしている程綺麗には出力されず、この精度は ASIO デバイスのバッファサイズに依存して荒くなってしまうという問題がある。
実際に出力例を挙げよう。
ここでは一番顕著に影響が現れる、音量が -∞ から 0.0 に戻る瞬間の部分を見ていこう。
このオートメーションはブラウザウィンドウで見ると以下のようになっている。
1. 1. 3 のタイミングで -∞ から一気に 0.00 に引き戻しているのがわかる。
それを手元にある E-MU 1212M で 96000Hz 32bit float で書きだしたのが以下のもの。
バッファサイズ 100msec というのは日常的に使う値ではないと思うのでこれは極端な例だ。
とはいえ明らかに無音でなければいけないところに山が残っているし、音量が戻る時にどう見てもフェードインしている。明らかに何かがおかしい。
次は E-MU 1212M の最小設定である 2msec で書きだした時の様子が以下のもの。
まだフェードインっぽい挙動は残っているものの、さっきのものに比べると随分改善された。
波形の山の大きさや細かさは特に意図的に見せ方を変えようとしているわけではないので、実際にバッファサイズの設定の変更だけでこれだけの差が出る。
しかも厄介なのは、これはリアルタイムエクスポートするかどうかに関係なく症状が現れる。
2ch でもこの辺で少し語られている。
まあ結局のところバッファサイズに依存するんだからデバイスで許される最小のバッファサイズを使うのが最善なのは言うまでもなく、E-MU 1212M なら 2msec だし、1msec まで行けるデバイスもあるだろう。
しかし、例えば 96000Hz だと1秒間(1000msec)に当然ながら 96000 サンプルもある。
つまり 1msec でも 96 サンプル。
なんかまだ減らせそう。
ということで、ASIO SDK についているサンプルドライバを少し改造してバッファサイズを極端に小さくできる仮想 ASIO デバイスドライバ「teo」を作った（※Windows専用）。
その teo を使用して書き出したのがこちら。
今までで一番ハッキリと境目ができたと思う。
そんなドライバを作った。
teo ASIO Driver v0.3 をダウンロード（Windows 専用）
Old: v0.2
以下、よくある質問と回答的な何か。
どうやって使うの？
書き出しの時だけ切り替えて使う感じで、その時だけ teo ASIO Driver を出力デバイスに選ぶ。
この仮想ドライバ自体は一切発音しないので日常的には全く使えないので注意。
あとリアルタイムエクスポートも諦めたほうがいいですね。
Macなんですけど
へぇ。
Windows なのに動かない
32bit と 64bit 両方のバージョンがあるものの動作確認したのは Windows7 の 64bit 版だけで、
あとは WindowsXP の 32bit 版にインストールまでは確認したぐらい。
それ以外は特に調べてないのでどうなるかわからんですね。
運が悪かったということでどうか。
書き出しめっちゃ遅いんだけど
まあバッファサイズ 0.04msec とかなんで……しょうがないんじゃないかなと……。
サンプル数を少し大きめにすると改善されるかも知れないけど
精度犠牲になるので元も子もない感じになるところもあり、悩ましいところ。
実際のところどう？ なくてもいいんじゃない？
影響が如実に現れることもあるので、精度が高いに越したことはないかな、とは思いますね。
こんなのとか、こんなのとか、状況次第で気になり方も変わるでしょうね。
実際に聴いてみるとどうでしょう？（テストファイル作ってくれた @Gno4166 ありがとう）
Cubase
にはわりと昔からずっと引きずっている問題がひとつある。それはタイトルにも書いた通りの症状なのだが、細かく説明するとこうだ。
Cubase でオートメーションを書くとき、こんな感じで線を引くことができる。
こう引くと、音声はフェードアウトし、完全に無音になったあと少し間をおいて元の音量に戻る。
特に何も珍しいことはない普通のオートメーションの使い方なのだが、詳細にデータを見ると実はオーディオの書き出し時にこれはイメージしている程綺麗には出力されず、この精度は ASIO デバイスのバッファサイズに依存して荒くなってしまうという問題がある。
実際に出力例を挙げよう。
ここでは一番顕著に影響が現れる、音量が -∞ から 0.0 に戻る瞬間の部分を見ていこう。
このオートメーションはブラウザウィンドウで見ると以下のようになっている。
1. 1. 3 のタイミングで -∞ から一気に 0.00 に引き戻しているのがわかる。
それを手元にある E-MU 1212M で 96000Hz 32bit float で書きだしたのが以下のもの。
 |
| E-MU 1212M 96000Hz 32bit float / バッファサイズ 100msec |
バッファサイズ 100msec というのは日常的に使う値ではないと思うのでこれは極端な例だ。
とはいえ明らかに無音でなければいけないところに山が残っているし、音量が戻る時にどう見てもフェードインしている。明らかに何かがおかしい。
次は E-MU 1212M の最小設定である 2msec で書きだした時の様子が以下のもの。
 |
| E-MU 1212M 96000Hz 32bit float / バッファサイズ 2msec |
まだフェードインっぽい挙動は残っているものの、さっきのものに比べると随分改善された。
波形の山の大きさや細かさは特に意図的に見せ方を変えようとしているわけではないので、実際にバッファサイズの設定の変更だけでこれだけの差が出る。
しかも厄介なのは、これはリアルタイムエクスポートするかどうかに関係なく症状が現れる。
2ch でもこの辺で少し語られている。
まあ結局のところバッファサイズに依存するんだからデバイスで許される最小のバッファサイズを使うのが最善なのは言うまでもなく、E-MU 1212M なら 2msec だし、1msec まで行けるデバイスもあるだろう。
しかし、例えば 96000Hz だと1秒間(1000msec)に当然ながら 96000 サンプルもある。
つまり 1msec でも 96 サンプル。
なんかまだ減らせそう。
ということで、ASIO SDK についているサンプルドライバを少し改造してバッファサイズを極端に小さくできる仮想 ASIO デバイスドライバ「teo」を作った（※Windows専用）。
その teo を使用して書き出したのがこちら。
 |
| teo 96000Hz 32bit float / バッファサイズ 4サンプル(約0.04msec) |
今までで一番ハッキリと境目ができたと思う。
そんなドライバを作った。
teo ASIO Driver v0.3 をダウンロード（Windows 専用）
Old: v0.2
以下、よくある質問と回答的な何か。
どうやって使うの？
書き出しの時だけ切り替えて使う感じで、その時だけ teo ASIO Driver を出力デバイスに選ぶ。
この仮想ドライバ自体は一切発音しないので日常的には全く使えないので注意。
あとリアルタイムエクスポートも諦めたほうがいいですね。
Macなんですけど
へぇ。
Windows なのに動かない
32bit と 64bit 両方のバージョンがあるものの動作確認したのは Windows7 の 64bit 版だけで、
あとは WindowsXP の 32bit 版にインストールまでは確認したぐらい。
それ以外は特に調べてないのでどうなるかわからんですね。
運が悪かったということでどうか。
書き出しめっちゃ遅いんだけど
まあバッファサイズ 0.04msec とかなんで……しょうがないんじゃないかなと……。
サンプル数を少し大きめにすると改善されるかも知れないけど
精度犠牲になるので元も子もない感じになるところもあり、悩ましいところ。
実際のところどう？ なくてもいいんじゃない？
影響が如実に現れることもあるので、精度が高いに越したことはないかな、とは思いますね。
こんなのとか、こんなのとか、状況次第で気になり方も変わるでしょうね。
実際に聴いてみるとどうでしょう？（テストファイル作ってくれた @Gno4166 ありがとう）