Beyond bit-perfectを読む

DamienさんのBeyond bit-perfect翻訳はなかなか反響がありました。ここで少しわたしなりに補足しておきたいと思います。
翻訳は文意を変えないという約束だったので、"Beyond bit-perfect"の翻訳文に私の意見は入っていません。そのかわり本文には訳注を最小限で入れました。本文末の少し長いFull memory Playについての訳注は多少私の意見になるので、Damienさんにこういう風に入れたいと断った上で入れています。そのくらい他人の著作物を翻訳するのは気を使います。
そこでわたし自身のコメントと補足はここに別に書きます。この記事はDamienさんとは関係なく、"Beyond bit-perfect"を読んだ私個人の考えです。

まず簡単に補足すると、ビットパーフェクト(bit perfect)という言葉はCDのデータの情報を一切のロスなく完全に読んで、さらにDACまでの経路上でそのデータにロス(あるいは変化)が発生しないということです。日本では主に前者のCDから読むほうが主で「バイナリー一致」という言葉で知られていましたが、ここではさらに経路上のロスまで言及しています。この経路部分だけをとりだしてBit Transparent(ビット透過)とも言います。
よくデジタルでは音は変わらないのだから、ビットパーフェクトが達成されたら音質は完全ではないか？それではプレーヤーソフトで音が変わる理由は何か？ビットパーフェクトよりも音は良くなるのか？という問いがあると思います。
このDamienさんの文書はまずそれに答えたものです。タイトルの"Beyond bit-perfect"にはそうした意味が込められています。

さらにそれを踏まえて、いま話題のインテジャーモードとは何か、その利点について解説がされています。
まずインテジャーモードとはなにか？と言うことについては、"Beyond bit-perfect"を読むとその利点は処理の最適化であると述べられています。特にドライバーでの最適化がポイントです。
OSと言うのは基本ソフトであるゆえに、アプリケーションソフトより特権を持ったモードで動作し、独立したカーネル空間で動作します。これは安定した動作とハードにアクセスするために必要です。ただミュージックプレーヤーなど一般のアプリケーションの出力も最終的にハードにアクセスが必要になりますが、それはOSの機能を一部間借りするかOSが代行して行われます。ドライバーもその一つです。ドライバーはカーネル空間でOSの一部として動作します。
ドライバーはハードウエアと直接やりとりが行われるところですので、ここの処理が極めて重要と言うのは納得できるところでしょう。さらにDACとのやりとりにおける「同期的なCPU処理」はそこで行われるのでこのタイミングはかなり重要です。

この辺と後で出てくる"Full Memory Play"のことを考え合わせるとAudirvanaの優れた思想と言うのがわかってくると思います。
つまり、クリチカル(決定的)な時点での処理を軽減するために、あらかじめクリチカルでない時点で下ごしらえをしておくということです。

また"Beyond bit-perfect"を読む上でひとつ注意して欲しいのは、この文書はコンピューターオーディオ一般的に通用するものですが、書かれている内容自体はあくまでMacを念頭においているということです。たとえば第二章のサンプルレート変換の項は訳注にも書きましたが、Mac OSXのAudioMidi設定での挙動をもとに書かれています。
Macのオーディオでは、まずAudioMidi設定のAudio設定パネルのサンプリングレートとビット幅の設定がキモであると覚えていてください。ここの設定値と再生しているサンプリングレートが異なるとAudio設定パネルにあわせてリサンプリングされ、ビットパーフェクトではなくなります。アップサンプリングは良いように思えますが、"Beyond Bit-Perfect"にも書いてあるように最適なリサンプリングはしていません。96kデータを再生していてAudio設定が44kのままだと音がダウングレードされますので注意が必要です。また、なにか問題があったらここを確認することが必要です。(この辺は自動サンプルレート切り替えと関係してきます)
これはこちらのMacのCoreAudioについて書いた記事も参照ください。
http://vaiopocket.seesaa.net/article/167849910.html

"Beyond bit-perfect"ではフレームワークという言葉が出てきますが、ここも一つポイントです(本文中のFig2のことです)。
かつてのプログラムならあらゆるソフトウエアの振る舞いをプログラマが書くことが出来ましたが、いまのソフトウエアは遥かに複雑なので、それらをいちいち自分で書くのは現実的ではありません。そこであらかじめ決まったプログラムのモジュールとか骨組みが用意されています。それがフレームワークで、ここで書かれているCoreAudio Graphもその一つです。
しかしこれはいわば既製品スーツみたいなもので、オーダーメイドのような細かなことが出来ません。そこで、直にデバイスに近い低レベル(HALというレイヤー)のプログラムを便利なフレームワークに頼らずに自分で書くのが理想です。それがここで言っているオーバーヘッドの減少です。


ここで"Beyond bit-perfect"からは少し離れますが、もうひとつインテジャーモードの別な側面も書きたいと思います。
わたしは前にさきにかいたMacのCoreAudio記事でインテジャーモードの利点は24bit以上の精度を持つためと書きました。ただこれも間違ってはいないと思います。理由の一つはMacのCoreAudioとWindows Vista以降のCoreAudioを比較すると分かります。Mac OSXのデバイス排他処理であるhogモードはなにやらマニアックな処理の印象がありますが、WindowsのCoreAudioにおいては排他処理はOSのサウンドプロパティでも許可の可能なすっきりとした処理がなされています。Windowsではシンプルにオーディオストリームをオープンするときに排他(占有)モードか共有(ミキサーを通す)モードか明示的に指定します。
こうしてみるとWindowsのCoreAudioの方がMacのCoreAudioより後発な分でより洗練されたものになっていると思います。これは下記のWindows7のWASAPI解説記事も参照ください。
http://vaiopocket.seesaa.net/article/155985528.html
もしMacで排他WASAPIと同じことをするならば、hogモードとインテジャーモードを両方実装が必要になります。hogモードだけだとMac OSXのミキサーであるAudioUnitを経由します。(ただしMax OSXではミキサーを通してもビットパーフェクトでありえます、これはさきのMacのCoreAudio記事に書いています)
このことはオーディオストリームの経路をより自由にできることを意味します。その例は24bitより大きいPCMデータを通すことや、PCM以外を通すことです。

たとえば最近話題のDSD再生において、AudiogateなどではDSD(DFFとかDSF形式)を読んでもいったんDACに出すためにPCMに変換しています。ただここもDACがDSDを受けれるならば、PCMを経由せずにDSD透過(DSDネイティブ)でコンピューターからDACに出せれば理想的です。これにはPCMを想定しない経路が必要なわけです。このDSD直はWindows7では排他モードWASAPIで対応可能と上のWASAPI記事でも書きましたが、MacでDSDネイティブを実現するためにはインテジャーモードが必要です。これは別にDamienさんとメールして確認しています。

現在New Yorkで開催されているAXPONA 2011ショウのStreophileのレポートで、Pure Music PlayerのブースでPure Music Player Ver1.8とプレイバックデザインの新しいDAC MPD-3 D/Aを使用してUSB経由でDSDネイティブで出力しているらしいデモをレポートしています。
http://www.stereophile.com/content/pure-music-does-dsd
これはPure Musicが1.8からDSD対応とインテジャーモードの両対応が可能になったことによると思います。またそれがV1.8の狙いなのでしょう。
(ただし現状のPure Music1.8はDSDをPCMに変換するタイプなのでこれはカスタムバージョンだと思います)
さらに32bit出力が意味があるかは別として、それを実現するのはインテジャーモードです。インテジャーモードは音質の最適化というだけではなく、Macに新たな可能性を開くキーともなるでしょう。