インターナショナルオーディオショウのレポートのところで書いた32bit音源の再生問題ですが、インテジャーモードの大御所であるAudirvanaの作者Damienさんにメールして聞いてみたところ、やはり私の理解で間違いないということです。つまりインテジャーモードが使えなければ32bitは8bit欠けて24bitになってしまうと言うことです。
この場合MacOS 10.6でAudirvanaを用いてインテジャーモードが使えれば32bit音源を問題なく再生できるとのこと。
McIntoshのデモの例で言うと、DACプリのC50はESSの32bit DACですからドライバーが32bit対応してあれば受け手は問題ありません。ドライバーが認識されたらAudioMidiに「32bit (整数)」と表示が出るでしょう。32bitは小数点と整数がありますのでここは整数と明記されるライオンのAudioMidiが意味を持ちます。
ここでAudioMidiで32bit整数を指定すれば32bit長の「箱」でDACに送られるのでC50の表示では192kHz 32bitと表示されると思います。つまり外からは一見問題なさそうに見えるでしょう。
ただしCoreAudioで切られていれば下位8bitは実際はヌル(0)でいっているだろうということです。ここで問題視しているCoreAudioのボトルネックはドライバー(HAL)より前のAudio Unitですのでドライバーが32bit対応していてもその前段階でデータは切られてしまいます。
つまり32bitの転送用の「箱」は用意されて32bit長で送られるのですが、「中身」は24bitになってしまうので、それが積めて収納されるため下位はゼロのままとなると思います。
この問題は前に書いたiPadのハイレゾ出力に似ていると思います。
http://vaiopocket.seesaa.net/article/191432693.html
はじめにiPad(iOS4.1だったか)がUSB DACに対応したときはこの「箱」自体が24bitに対応していませんでした。そのため24bit DACでは再生ができませんでした。しかし4.2だったかでこの箱が24bitに対応しました。この結果として24bit DACで再生ができるようになりました。
しかし、24bit音源を再生しても中身は16bitに切られてしまっていたので、結果的に16bitを積めて収納されていました(上のリンクでI2S出力で確認したグラフです)。16bitに切られた理由はiOSのCoreAudioが24bit整数を扱えなかったからです。
その後にFLAC PlayerでDanにお願いして上記問題を工夫して解決し、中身も24bitで出せるようになりました。つまりボトルネックが解消されてきちんと24bitの箱に24bitの中身がつめられるようになったわけです。
もうひとつの考慮点はそもそも再生ソフトが32bit扱えるかということになるようです。たとえば32bitのデータを読んでそれをなんらかの処理をするとします。CoreAudioが32bit浮動小数点で計算しているため24bit整数が「精度」としては限界と言うことと同様にアプリケーション内でも32bitの「精度」を保つ必要があるならば、演算処理は32bitの単精度ではなく64bitの倍精度が必要になります。Aurdirvanaは64bit演算処理していますね。
ですので、32bit音源を扱う際のポイントは再生ソフトがインテジャーモードに対応していることと、ソフトウエアが32bitに対応していることがあげられるということでしょうか。
ただし一応書いておきますが、C50と32bit音源についてはモノを直接持っているわけではありませんからあくまで推測ですので念のため。
ここで書きたかったのは32bit再生というのは単に24bitを再生するのとは異なる考慮点があると言うことです。DSD音源と同様に32bit音源もまた取り組むのに興味あるテーマと言えるのかもしれませんね。
Music TO GO!
2011年11月08日
この記事へのトラックバック