おなじみのMacのプレーヤーソフトAudirvana Plusの1.0.9.0からAmarraやPure MusicのようにiTunesとのリンクができるようになりました。
(下記はベータ版の画面です)
まず左のようにプレイリストを従来のものか、iTunesリンクかを選びます。iTunesリンクを選ぶと右のようにiTunesをプレイリストのように使うことができるようになります。iTunes上の曲をダブルクリックするとAudirvanaで再生ができます。この辺はAmarraなどと同じ感覚です。Audirvanaの画面にAppleロスレスと表示されていますね。
先日のAppleロスレスがオープン化されたという話題とからんで、どういう形式でライブラリを持つかについてまた選択が増えたかもしれませんね。
Music TO GO!
2011年10月31日
2011年10月09日
Audirvana Plusライセンス購入サイトオープン
Audirvana Plusでは初めに15 日使用可能なトライアル版をダウンロードして気に入ったら$49(または39ユーロ)を払ってライセンスコードを購入してアクティベートするという方式です。初めは購入サイトがまだ用意されてなかったのですが、週末にオープンして購入可能になりました。こちらです。
http://audirvana.com/?page_id=112
クレジットカードやPaypalでの支払いが可能です。
それと1.02がアップロードされています。このバージョンに限っては試用期間がリセットされて15日延長されます。つまり初期バージョンをすでに試用している方でもさらに15日間試用が出来ます。
この後は1.xのようなマイナーバージョンアップは無料で行い、2.xにメジャーアップした時にライセンス更新を考えると言うことです。次はiTunesリンク機能とDSDをPCM変換する際の設定追加が加わる予定です。dCS方式のDSDネイティブ再生は検討中とのことです。
作者のDamienさんからはメールが来ていて、早々支払いしたお客さまは日本が多かったそうで、感謝をしてたことを伝えておきます。
http://audirvana.com/?page_id=112
クレジットカードやPaypalでの支払いが可能です。
それと1.02がアップロードされています。このバージョンに限っては試用期間がリセットされて15日延長されます。つまり初期バージョンをすでに試用している方でもさらに15日間試用が出来ます。
この後は1.xのようなマイナーバージョンアップは無料で行い、2.xにメジャーアップした時にライセンス更新を考えると言うことです。次はiTunesリンク機能とDSDをPCM変換する際の設定追加が加わる予定です。dCS方式のDSDネイティブ再生は検討中とのことです。
作者のDamienさんからはメールが来ていて、早々支払いしたお客さまは日本が多かったそうで、感謝をしてたことを伝えておきます。
2011年09月24日
Audirvanaの有料版、Audirvana Plus登場
Mac用のプレーヤーソフトとして人気のAudirvanaですが、その改良版にして有料版のAudirvana Plusが正式にリリースされました。サイトがリニューアルされてこのアドレスからご覧ください。
http://audirvana.com/
世界的にはこの週末のイギリスのUK National Audio ShowにAMRブースで出展されるのがデビューとなります(本日までは情報非公開でした)。私はベータテスターの一人として参加させてもらいましたので、すでに使用していますが、新機能の音質向上などでますます魅力的になったと思います。価格は$49です。
DSD再生も可能で、PCM変換だけではなくPlayback DesignのMPS5などでのネイティブ再生も可能です。またアップサンプリングはFideliaのようにiZotopeのライセンスを受けた高精度なものが搭載され、高精度なディザボリュームなども付加されました。私は最適化機能などがお勧めです。
ちなみに従来のものはAudirvana Freeと呼ばれて引き続き利用可能です。
http://audirvana.com/
世界的にはこの週末のイギリスのUK National Audio ShowにAMRブースで出展されるのがデビューとなります(本日までは情報非公開でした)。私はベータテスターの一人として参加させてもらいましたので、すでに使用していますが、新機能の音質向上などでますます魅力的になったと思います。価格は$49です。
DSD再生も可能で、PCM変換だけではなくPlayback DesignのMPS5などでのネイティブ再生も可能です。またアップサンプリングはFideliaのようにiZotopeのライセンスを受けた高精度なものが搭載され、高精度なディザボリュームなども付加されました。私は最適化機能などがお勧めです。
ちなみに従来のものはAudirvana Freeと呼ばれて引き続き利用可能です。
ライオンでのインテジャーモード(続)
ライオンでインテジャーモードがないって言うのをアップルにバグレポート出したら、冷たく直す予定がないって回答が来たと言うポストがCAに載ってました。
http://www.computeraudiophile.com/content/Integer-Mode-Support-Lion-OS
この問題は短期解決はほぼ無理のようです。
ただ問題としては認識しているのでオフラインで将来的になんらかの案を考えるってところが期待はできます。
http://www.computeraudiophile.com/content/Integer-Mode-Support-Lion-OS
この問題は短期解決はほぼ無理のようです。
ただ問題としては認識しているのでオフラインで将来的になんらかの案を考えるってところが期待はできます。
2011年09月07日
HQ PlayerがLinux対応
HQ PlayerがLinux対応を果たしたようです。
http://www.signalyst.com/consumer.html
ディストリビューションはOpenSUSEでALSAを使用します。Ubuntu 11.04対応も考慮中だそうです。
インストールはリポジトリから行います。
http://www.signalyst.com/linux-instructions.html?
デジタルフィルター内蔵、DSD対応のこの本格的なプレーヤーソフトの参入でLinux方面もまた面白くなるのではないでしょうか。
http://www.signalyst.com/consumer.html
ディストリビューションはOpenSUSEでALSAを使用します。Ubuntu 11.04対応も考慮中だそうです。
インストールはリポジトリから行います。
http://www.signalyst.com/linux-instructions.html?
デジタルフィルター内蔵、DSD対応のこの本格的なプレーヤーソフトの参入でLinux方面もまた面白くなるのではないでしょうか。
2011年07月24日
Mac OSXライオンとオーディオ再生環境の変化 (1)
中間的に少しライオンでのオーディオ環境の変化をまとめてみます。
まず大きな変化はやはりインテジャーモードがライオンでは使えなくなったらしいということです。これはDecibelのBoothとかAudirvanaのDamienも書いてますのでいまのところの統一見解のようです。問題箇所はおそらくはUSBクラスドライバーではないかということ。
Audirvanaは0.9.5が最近出ましたがこの問題に対しては対策がなされていません。やはりプログラムではなくOS側で変更がないと難しそうです。
次の謎の変化はAudioMidiのAudioウインドウで従来の16bitや24bitという表示に加えてなぜかinteger(整数)とかfloatという表示が増えているという点です。ここはDACのネイティブ形式(Physical Format)に見えますし、いろんな憶測はありますがはっきりしたことはまだわかりません。ただしそもそも16bitとか24bitで浮動小数点という形式はないので明示的に表示しただけという話もあります。
自動サンプルレート切り替えとか基本的なMacのビットパーフェクトオーディオ再生のパス・手順に関しては大きく変更はないように思えます。
またiTunesが10.4になり64bit対応されたことで音質の向上があるかもしれません。
それとなにより大きいのは旧Macbook Airで64bitカーネルの実行が許可されたことです。いままではMac Airは64bitカーネルの動作条件は満たしていましたが、アップルの販売政策(と言われています)で実行を制限されていました。効果を確認したい場合は6と4を同時に押しながら立ち上げるか、スタートアップセレクタを使用してください。「このMacについて」からソフトウエアの項で「64ビットカーネルと拡張機能」がはいになっていればOKです。
他のモデルはデフォルトで64bitで立ち上がるはずです。これにより音質はかなり向上して、Decibelなどの64bitアプリでの恩恵をフルに受けられるでしょう。
ミュージックプレーヤーの問題としてはまずAmarraがiTunes10.4を立ち上げると「64bitモードでは読み込めません」と警告が出るようになりました。これは確実に回避するのはiTunesのソフト自体を選択してcmd-iで情報を見て32bitで起動を選択するとウォーニングはでなくなります。ただし最適化の問題があって、開発元では音質を保証しないというようなことがメールで流れていました。
またPure Music Playerではhogモード(排他モード)に入れないという問題がありましたが対応版(1.81d5)がリリースされています。これはスノーレパードでも使えます。
そもそもライオンでの音質という問題ですが、下記に同じマシン(Macbook Pro 17)で二つパーティションを切ってライオンとスノーレパードをDecibelなどで聴き比べた人の感想が乗っています。
http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=92603
同条件で比べてもライオンのほうがより明瞭感がありダイナミックで音場も広いということです。ハイレゾでも差はよりわかりやすいようですね。
インテジャーモードが現在使えないという状況でも、内部の最適化とかAPIの変更によるものかライオンのほうが音質は高いようです。
Mac OSXではスノーレパードで中身を大きく刷新しました。ライオンは外観だけかと思いましたがけっこう中も手は加わっているようです。OS回りは「Beyond BitPerfectを読む」でも書きましたが、特権モードで動作して直接ハードに触るところなので音質に与える影響はあると思います。
まあいろいろと問題はありますが、ポテンシャルもあると思うのでもう少し見ていきたいですね。
まず大きな変化はやはりインテジャーモードがライオンでは使えなくなったらしいということです。これはDecibelのBoothとかAudirvanaのDamienも書いてますのでいまのところの統一見解のようです。問題箇所はおそらくはUSBクラスドライバーではないかということ。
Audirvanaは0.9.5が最近出ましたがこの問題に対しては対策がなされていません。やはりプログラムではなくOS側で変更がないと難しそうです。
次の謎の変化はAudioMidiのAudioウインドウで従来の16bitや24bitという表示に加えてなぜかinteger(整数)とかfloatという表示が増えているという点です。ここはDACのネイティブ形式(Physical Format)に見えますし、いろんな憶測はありますがはっきりしたことはまだわかりません。ただしそもそも16bitとか24bitで浮動小数点という形式はないので明示的に表示しただけという話もあります。
自動サンプルレート切り替えとか基本的なMacのビットパーフェクトオーディオ再生のパス・手順に関しては大きく変更はないように思えます。
またiTunesが10.4になり64bit対応されたことで音質の向上があるかもしれません。
それとなにより大きいのは旧Macbook Airで64bitカーネルの実行が許可されたことです。いままではMac Airは64bitカーネルの動作条件は満たしていましたが、アップルの販売政策(と言われています)で実行を制限されていました。効果を確認したい場合は6と4を同時に押しながら立ち上げるか、スタートアップセレクタを使用してください。「このMacについて」からソフトウエアの項で「64ビットカーネルと拡張機能」がはいになっていればOKです。
他のモデルはデフォルトで64bitで立ち上がるはずです。これにより音質はかなり向上して、Decibelなどの64bitアプリでの恩恵をフルに受けられるでしょう。
ミュージックプレーヤーの問題としてはまずAmarraがiTunes10.4を立ち上げると「64bitモードでは読み込めません」と警告が出るようになりました。これは確実に回避するのはiTunesのソフト自体を選択してcmd-iで情報を見て32bitで起動を選択するとウォーニングはでなくなります。ただし最適化の問題があって、開発元では音質を保証しないというようなことがメールで流れていました。
またPure Music Playerではhogモード(排他モード)に入れないという問題がありましたが対応版(1.81d5)がリリースされています。これはスノーレパードでも使えます。
そもそもライオンでの音質という問題ですが、下記に同じマシン(Macbook Pro 17)で二つパーティションを切ってライオンとスノーレパードをDecibelなどで聴き比べた人の感想が乗っています。
http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=92603
同条件で比べてもライオンのほうがより明瞭感がありダイナミックで音場も広いということです。ハイレゾでも差はよりわかりやすいようですね。
インテジャーモードが現在使えないという状況でも、内部の最適化とかAPIの変更によるものかライオンのほうが音質は高いようです。
Mac OSXではスノーレパードで中身を大きく刷新しました。ライオンは外観だけかと思いましたがけっこう中も手は加わっているようです。OS回りは「Beyond BitPerfectを読む」でも書きましたが、特権モードで動作して直接ハードに触るところなので音質に与える影響はあると思います。
まあいろいろと問題はありますが、ポテンシャルもあると思うのでもう少し見ていきたいですね。
2011年07月14日
Mac OSX ライオンとintegerモード
もうMac OSXライオン発表まで秒読みというところですが、ライオンではインテジャー(integer)モードは使えないという気になるレポートがCAフォーラムにあがってます。
この人は開発ベータ版でテストしたということで、10.6では使えていたということです。理由としてはあるAPIが変更されていてintegerフォーマットを受け付けなくなったからではないかと推測されてますが、すでにAudirvanaのダミアンさんには知らせて対策を考えてもらってるということです。
http://www.computeraudiophile.com/content/OS-X-Lion-and-integer-mode-playback
製品版ではどうか分かりませんが気になるニュースですね。
この人は開発ベータ版でテストしたということで、10.6では使えていたということです。理由としてはあるAPIが変更されていてintegerフォーマットを受け付けなくなったからではないかと推測されてますが、すでにAudirvanaのダミアンさんには知らせて対策を考えてもらってるということです。
http://www.computeraudiophile.com/content/OS-X-Lion-and-integer-mode-playback
製品版ではどうか分かりませんが気になるニュースですね。
2011年06月28日
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に新たな可能性を開くキーともなるでしょう。
翻訳は文意を変えないという約束だったので、"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に新たな可能性を開くキーともなるでしょう。
2011年06月26日
Audirvana作者の技術白書 Beyond bit-perfect: 全翻訳版
Audirvanaの作者のDamienさんがとても興味深い技術文書を書きました。これはコンピューターオーディオにおけるプレーヤーソフトとMacのインテジャーモードについて書かれたものです。そこでDamienさんに連絡してこの全文の日本語翻訳の許可とブログに掲載する許可をもらいました。
原注は原文にある注釈で、訳注はわたしが補足で書いたものです。そのほかはできるかぎり原文を忠実に訳出しています。多少言い回しを変えているところもありますが、文意は変えていないつもりです。文中の[MeitnerGendron91]などは末尾の参照文献のことです。本文中の「わたし」はもちろんDamienさんのことです。
本文はDamienさんに権利がありますので許可無く引用したり転載することはできませんので注意ください。必要な場合はわたしにご連絡ください。
原文はこちらです。(PDFへのリンク)
Beyond bit-perfect:
The importance of the Player Software
And Mac OSX Playback integer mode
ビットパーフェクトを超えて :
プレーヤーソフトウエアの重要性とMac OSX のインテジャーモード再生
Damien Plisson, Audirvana 開発者
(翻訳: ささき@Music To Go)
概要
コンピューターオーディオにおいて、プレーヤーソフトウエアはDACに転送するトランスポートとしてCDドライブの代わりとなるものだ。ビットパーフェクト出力の確保は単なる前提条件であって、ジッターとRFI(Radio Frequency interference : 電波干渉)の低減はいぜん重要である。
この文書は音質に影響を与える主たる要素についてコンピューター側での説明を加えるものだ。それは実際にAudirvanaにおいて実装され、AMR DP-777 DACを普通使われるiTunesとの組み合わせを超えた別次元のオーディオ体験をもたらしている。
その主たる要素とはビットパーフェクト、サンプルレート切り替え、アシンクロナス(非同期)転送、インテジャーモードである。
序文: 究極の目標あるいは理想世界の神話としてのビットパーフェクト
デジタルオーディオの世界において、読み込みエラーやトランスポートの機械的な要因によるジッターの発生はCDプレーヤーの既知の問題として良く知られている。
コンピューターソースはこれらの問題に対してはその影響を受ける恐れがなく、それゆえビットパーフェクトとして知られるオリジナルの信号に忠実であると一般的に考えられている。
しかし残念なことにコンピューターの中のデジタル世界は完全な0と1で構成される理想世界ではない。オーディオ信号はさまざまな構成物を通り、それぞれが音質に影響を与える。
これからその詳細を見ていき、"ソースダイレクト"の手法がその悪影響を最小限に抑え、CDプレーヤーを越える高い音質を達成できることを確認したい。
訳注: 原文のflat-square world(直訳では平板世界)は現実世界に対して理想的な状態の(ありえない)世界の比喩として使用している。
第1章 音質劣化の原因
ビットパーフェクト出力を前提としても、ソース機材としてのコンピューターは二つの大きな理由によって音質が劣化する。
*ソフトウエア要因のジッター
デジタル信号は実際のところ、電圧の閾(しきい)値によって二つの状態が分割されるアナログの波形である。(閾値の上ならば1で、下ならば0ということ)
[MeitnerGendron91]で示されているように受信側はアナログの閾値を越えた瞬間を検知している。加えてある状態から他の状態への遷移は瞬間的ではなく斜面のようになっている。そのためソースの基準電圧(Reference Voltage)のわずかな変化が時間的な変位をもたらしてしまう。
Figure 1: 基準電圧差によるジッター
(1)の基準電圧の差が(2)のrising edge(立ち上がり)の時点でレベル検出をするさいに時間の差を生じてしまう。(Thresholdはしきい値)
つまりソースの基準電圧の変動はジッターを生じる。これは[HawksfordDunn96]に詳述されている通りだ。
これは受け手側の不安定な電源供給やグランド電圧によって左右される閾値測定の変動についても同じことが言える。
さらにコンピューターでさえもグランドは同じケーブルと共有されているためこの影響を与えてしまう。
コンピューターの負荷(computer load)とはCPUと周辺機器からの常に変化する電源要求を意味していて、要求のピークはソフトウエアの挙動と直接関係がある。
*電波およびさまざまな要因による干渉
加えて計算処理やディスクのアクセスなどさまざまな処理は信号線を複雑な波形の電流が流れることを意味しているので、これは電磁的な干渉を引き起こす。いまはアップル製のコンピューターは「ユニボディ」アルミシャーシによって十分な遮蔽が行われているが、ケーブル自体がアンテナとして機能してしまうためにこの遮蔽は十分ではない。
またこれらの波形電流はコンピューターのPSU(電源ユニット)に逆流して主電源を汚してしまう。
第2章 OSXの隠れたオーディオフィルター
現代オペレーティングシステムとしてOSXは実行中のすべてのアプリケーションに、オーディオ出力を含むデバイスへの共有アクセスの手段を提供する必要がある。しかしそれは音質の劣化と引き換えにされてしまっている。
*オーディオ・ミキサー
もし都合の良いことに音楽再生をしているアプリケーションがただひとつであれば、それは信号に影響を与えることはないのでこの場合にはビットパーフェクトは達成できる。
*サンプルレート変換
この共有モデルではデバイスのサンプルレートを楽曲のサンプルレートにあわせて切り替えられないのでサンプルレートが変換されてしまう。
加えてリアルタイムオペレーションのためCPU負荷を減らさねばならないので、最適ではないアルゴリズムが用いられている。
(訳注: MacのAudioMidi設定による変換のこと)
*デジタルボリュームコントロール
OSXはミキサーを介したボリュームコントロールを提供している。(iTunesで提供されているものと同じと言うこと)
デジタルボリュームにおいては100%から離れるほどビットパーフェクトではなくなり、精度の低下を招くことになる。(25%のボリューム値は2bitの精度の低下を意味している)
第3章 DACへのデータ転送
まずはじめに内蔵されているTOSLINKを使用するDACへの接続が考えられるが、これはジッターが多すぎるので本格的な使用には向いていない。
より優れたコンピューターへの接続法としてはUSBもしくはFireWireを使用するのが望ましい。
FireWireはマルチチャンネルの大量なAVデータのストリーミングを保障するように設計されているためプロ市場で長く使われてきた。しかしその複雑な運用方法(たとえばドライバーインストールが必要であるとかホットプラグインでの問題点など)や先行きの不透明感により、いまはUSBが広く使われてきている。
最初のUSBデバイスはアダプティブ(またはシンクロナス)方式であり、これはDACのクロックがコンピューターからの連続的なデータストリームに従属するものである。
最近のさらに進んだUSBデバイスではアシンクロナス方式が採用されている。これはDACがオーディオデータの流れをコントロールし、バッファリングしてDACのより安定した低ジッターのクロックを使用するというものである。それゆえこの方式はUSBストリームのごく短い中断(バスリセットや他のデバイスによるバースト転送)に影響されず、コンピューター側のジッターの多いクロックにあまり左右されない。
これはUSBの簡便さ(ドライバーインストール不要)とFireWireの安定性という二つの世界の良いところを併せ持っていると言える。この方式は音質向上への大きな進歩であるが、DACをコンピューターから完全に切り離すことはできず、グランドループを皮切りに始まる干渉問題やソフトウエア要因のジッターは相変わらず存在している。
第4章 プレーヤーソフトウエアの影響
まず第一にすべてのプレーヤーは次のように信号のビットパーフェクト再生を確保するべきである。
*DACのサンプルレートに曲のサンプルレートを合わせて不要なサンプルレート変換を回避すること。
*他のアプリケーションの干渉を排除するためにデバイスへの排他アクセス(hog mode)を使用する。
さらに第1章で見たようにコンピューターの負荷(および類似の問題)は音質に影響を与える。これらの電流要求とソースの干渉を最小化することがキーとなる。
1. 再生の前に(電源ノイズとRFIの影響を避ける目的で)ディスクアクセスを減少させるためメモリーにロードしておく(メモリー再生)。(原注1)
2. オーディオのデータストリーム処理に関する「同期的CPU負荷」(Syncrounous CPU load)を最小化する。ジッターの低減に加えて、これは特に低域における可聴域のRFIを減少させるのに役立つ。(原注2)
(訳注: 「同期的CPU負荷」(Syncrounous CPU load)とはDACからのリクエストによるCPU負荷のこと。)
第5章 ドライバーレベルでのさらなる最適化:インテジャーモード
OSXでのオーディオ再生は大方がAudio Unit Graph [AppleCoreAudio]のような高レベルのフレームワークによって実行される。
オーディオプレーヤーにおけるまずはじめの最適化はこれらのオーバーヘッドをバイパスして直接CoreAudioでのもっとも低レベルの層であるHAL(Hardware Abstraction Layer)にダイレクトにアクセスすることである(fig2参照)。
Figure 2: 普通のプレーヤーソフトとオーディオファイル向けプレーヤーソフトの概念の違い
訳注) 左は通常のオーディオプレーヤーの流れで四角い囲みの中がAudio realtime graphという高レベルのモジュール。右はオーディオファイル向けプレーヤー。
線の上はユーザー空間(アプリケーションの領域)で下はカーネル空間(OSの領域)。
カーネル空間でデバイスドライバーとDACのやりとりが行われている。
浮動小数点(float)モード
通常の実行ではユーザー空間とカーネル空間の境界を行き来するデータのやりとりは32bit浮動小数点形式で行われる。これは異なるオーディオストリームのミキシングプロセスとソフトウエアクリッピングを容易にする。[ Audio HAL_1]
このときでも24bitの範囲であればビットパーフェクトを達成できることに注意して欲しい。(原注4)
インテジャー(integer)モード
HALへの直接のアクセス[AppleHAL_2]は上述した通常モードにおける下記の二つの大きなオーバーヘッドをバイパスできる可能性がある。
*バッファでのミキシング
*浮動小数点からDACネイティブフォーマットへの変換
Figure 3: 浮動小数点モードとインテジャーモード
訳注) 左は通常の浮動小数点モードの流れを示していて、赤い囲みが本文中で言及されているオーバーヘッドを示している。右がインテジャーモードを示していて、単一のDACネイティブ形式での流れとなっている。
インテジャーモード(fig3)においてはプレーヤーソフトはすでにDACのネイティブ形式にフォーマットされたオーディオストリームを送出する。それゆえ「同期的CPU負荷」をドライバーレベルで最適化することができる。
この動作はカーネル空間であるドライバー内部でリアルタイムで行われるため、音質における最重要経路(クリティカルパス)となっている。なぜならそれらはDACとのデータ転送において即時性が生じる瞬間に起きる最も同期的なものだからだ。
それゆえこの最適化による効果は大きいが、この標準的でないモードを許容できるDACにのみ使用することができる。
結論
コンピューターは優れたミュージックサーバーだが、仮にビットパーフェクトが確保できたとしても音質を低下させるジッターとRFIの根源でもある。
プレーヤーソフトはこのオーディオストリームと関連した同期的な負荷による音質低下の影響を最小化するために、信号経路を最適化して整える必要がある。これにはビットパーフェクトに加えてソースダイレクトがそのキーとなる。
このことがすなわち私がAudirvanaにおいて、インテジャーモードでリアルタイム処理を単純化して、(ディスクからの読み取りやデコード、DACへのネイティブフォーマットへの変換など)他の動作は準備フェーズにオフラインで実行しておくことで、リアルタイム性能を最大限に発揮させるように効率化したということである。
これは完全メモリー再生(Full Memory Play)と呼ばれる。
最も良い結果はAMR DP-777のようにインテジャーモード、アシンクロナスUSBの対応が可能で、これらのすべての最適化の利点を享受できるものによって得ることができる。
(訳注: ComputerAudiophileのDamienさんの書き込みによると他のプレーヤーソフトとAudirvanaはメモリー再生と言う点について異なった考え方を持っている。他のプレーヤーソフトではHDD上のファイルの形式のままメモリにおいておくと言うキャッシュのような考えだが、Audirvanaではサンプルレート変換も含めてあらかじめメモリー上にデコードしたデータを置くと言うことで再生時の負荷を減らすと言う考え方が貫かれている)
原注1) HDDをSSDに交換すると直接的な機械的要因のノイズを取り除くことはできるが、長いケーブルを走る電流波形など他の要因の影響はまだ残る。まだOSのオーバーヘッドも以前として存在している。
原注2) OSXの低レベルオーディオサブシステムでは通常データを512フレーム・チャンクで要求している。つまり周波数では44.1kHzのサンプルレートで〜86Hzに相当する。
原注3) ソフトウエアボリュームコントロールを含むすべてのフィルターが取り除かれればビットパーフェクトは可能である。つまり普通のiTunesでもビットパーフェクトでありうる。
原注4) 32bit浮動小数点は1ビットの符号と8ビットの指数部、23ビットの仮数部から構成される。つまり有意な精度は24bitである。
参考文献
[hawksfordDunn96] Bits is Bits ?
Streophile 1996年3月号
[MeitnerGendron91] Time Distortions Within Digital Audio Equipment Due to Integrated Circuit Logic Induced Modulation Products
Ed MeitnerとRobert Gendronの91回AESコンベンションでの講演資料 (New York, October 1991, Preprint3105)
[AppleCoreAudio] CoreAudio Overview: What is CoreAudio ?
Mac OSX開発者向けライブラリ
[AudioHAL_1] Audio Device Driver Programming Guide: A Walk Through the I/O Model
Mac OSX開発者向けライブラリ
[AppleHAL_2] AudioHardware_h documentation
Mac OSX開発者向けライブラリ
原注は原文にある注釈で、訳注はわたしが補足で書いたものです。そのほかはできるかぎり原文を忠実に訳出しています。多少言い回しを変えているところもありますが、文意は変えていないつもりです。文中の[MeitnerGendron91]などは末尾の参照文献のことです。本文中の「わたし」はもちろんDamienさんのことです。
本文はDamienさんに権利がありますので許可無く引用したり転載することはできませんので注意ください。必要な場合はわたしにご連絡ください。
原文はこちらです。(PDFへのリンク)
Beyond bit-perfect:
The importance of the Player Software
And Mac OSX Playback integer mode
ビットパーフェクトを超えて :
プレーヤーソフトウエアの重要性とMac OSX のインテジャーモード再生
Damien Plisson, Audirvana 開発者
(翻訳: ささき@Music To Go)
概要
コンピューターオーディオにおいて、プレーヤーソフトウエアはDACに転送するトランスポートとしてCDドライブの代わりとなるものだ。ビットパーフェクト出力の確保は単なる前提条件であって、ジッターとRFI(Radio Frequency interference : 電波干渉)の低減はいぜん重要である。
この文書は音質に影響を与える主たる要素についてコンピューター側での説明を加えるものだ。それは実際にAudirvanaにおいて実装され、AMR DP-777 DACを普通使われるiTunesとの組み合わせを超えた別次元のオーディオ体験をもたらしている。
その主たる要素とはビットパーフェクト、サンプルレート切り替え、アシンクロナス(非同期)転送、インテジャーモードである。
序文: 究極の目標あるいは理想世界の神話としてのビットパーフェクト
デジタルオーディオの世界において、読み込みエラーやトランスポートの機械的な要因によるジッターの発生はCDプレーヤーの既知の問題として良く知られている。
コンピューターソースはこれらの問題に対してはその影響を受ける恐れがなく、それゆえビットパーフェクトとして知られるオリジナルの信号に忠実であると一般的に考えられている。
しかし残念なことにコンピューターの中のデジタル世界は完全な0と1で構成される理想世界ではない。オーディオ信号はさまざまな構成物を通り、それぞれが音質に影響を与える。
これからその詳細を見ていき、"ソースダイレクト"の手法がその悪影響を最小限に抑え、CDプレーヤーを越える高い音質を達成できることを確認したい。
訳注: 原文のflat-square world(直訳では平板世界)は現実世界に対して理想的な状態の(ありえない)世界の比喩として使用している。
第1章 音質劣化の原因
ビットパーフェクト出力を前提としても、ソース機材としてのコンピューターは二つの大きな理由によって音質が劣化する。
*ソフトウエア要因のジッター
デジタル信号は実際のところ、電圧の閾(しきい)値によって二つの状態が分割されるアナログの波形である。(閾値の上ならば1で、下ならば0ということ)
[MeitnerGendron91]で示されているように受信側はアナログの閾値を越えた瞬間を検知している。加えてある状態から他の状態への遷移は瞬間的ではなく斜面のようになっている。そのためソースの基準電圧(Reference Voltage)のわずかな変化が時間的な変位をもたらしてしまう。
Figure 1: 基準電圧差によるジッター
(1)の基準電圧の差が(2)のrising edge(立ち上がり)の時点でレベル検出をするさいに時間の差を生じてしまう。(Thresholdはしきい値)
つまりソースの基準電圧の変動はジッターを生じる。これは[HawksfordDunn96]に詳述されている通りだ。
これは受け手側の不安定な電源供給やグランド電圧によって左右される閾値測定の変動についても同じことが言える。
さらにコンピューターでさえもグランドは同じケーブルと共有されているためこの影響を与えてしまう。
コンピューターの負荷(computer load)とはCPUと周辺機器からの常に変化する電源要求を意味していて、要求のピークはソフトウエアの挙動と直接関係がある。
*電波およびさまざまな要因による干渉
加えて計算処理やディスクのアクセスなどさまざまな処理は信号線を複雑な波形の電流が流れることを意味しているので、これは電磁的な干渉を引き起こす。いまはアップル製のコンピューターは「ユニボディ」アルミシャーシによって十分な遮蔽が行われているが、ケーブル自体がアンテナとして機能してしまうためにこの遮蔽は十分ではない。
またこれらの波形電流はコンピューターのPSU(電源ユニット)に逆流して主電源を汚してしまう。
第2章 OSXの隠れたオーディオフィルター
現代オペレーティングシステムとしてOSXは実行中のすべてのアプリケーションに、オーディオ出力を含むデバイスへの共有アクセスの手段を提供する必要がある。しかしそれは音質の劣化と引き換えにされてしまっている。
*オーディオ・ミキサー
もし都合の良いことに音楽再生をしているアプリケーションがただひとつであれば、それは信号に影響を与えることはないのでこの場合にはビットパーフェクトは達成できる。
*サンプルレート変換
この共有モデルではデバイスのサンプルレートを楽曲のサンプルレートにあわせて切り替えられないのでサンプルレートが変換されてしまう。
加えてリアルタイムオペレーションのためCPU負荷を減らさねばならないので、最適ではないアルゴリズムが用いられている。
(訳注: MacのAudioMidi設定による変換のこと)
*デジタルボリュームコントロール
OSXはミキサーを介したボリュームコントロールを提供している。(iTunesで提供されているものと同じと言うこと)
デジタルボリュームにおいては100%から離れるほどビットパーフェクトではなくなり、精度の低下を招くことになる。(25%のボリューム値は2bitの精度の低下を意味している)
第3章 DACへのデータ転送
まずはじめに内蔵されているTOSLINKを使用するDACへの接続が考えられるが、これはジッターが多すぎるので本格的な使用には向いていない。
より優れたコンピューターへの接続法としてはUSBもしくはFireWireを使用するのが望ましい。
FireWireはマルチチャンネルの大量なAVデータのストリーミングを保障するように設計されているためプロ市場で長く使われてきた。しかしその複雑な運用方法(たとえばドライバーインストールが必要であるとかホットプラグインでの問題点など)や先行きの不透明感により、いまはUSBが広く使われてきている。
最初のUSBデバイスはアダプティブ(またはシンクロナス)方式であり、これはDACのクロックがコンピューターからの連続的なデータストリームに従属するものである。
最近のさらに進んだUSBデバイスではアシンクロナス方式が採用されている。これはDACがオーディオデータの流れをコントロールし、バッファリングしてDACのより安定した低ジッターのクロックを使用するというものである。それゆえこの方式はUSBストリームのごく短い中断(バスリセットや他のデバイスによるバースト転送)に影響されず、コンピューター側のジッターの多いクロックにあまり左右されない。
これはUSBの簡便さ(ドライバーインストール不要)とFireWireの安定性という二つの世界の良いところを併せ持っていると言える。この方式は音質向上への大きな進歩であるが、DACをコンピューターから完全に切り離すことはできず、グランドループを皮切りに始まる干渉問題やソフトウエア要因のジッターは相変わらず存在している。
第4章 プレーヤーソフトウエアの影響
まず第一にすべてのプレーヤーは次のように信号のビットパーフェクト再生を確保するべきである。
*DACのサンプルレートに曲のサンプルレートを合わせて不要なサンプルレート変換を回避すること。
*他のアプリケーションの干渉を排除するためにデバイスへの排他アクセス(hog mode)を使用する。
さらに第1章で見たようにコンピューターの負荷(および類似の問題)は音質に影響を与える。これらの電流要求とソースの干渉を最小化することがキーとなる。
1. 再生の前に(電源ノイズとRFIの影響を避ける目的で)ディスクアクセスを減少させるためメモリーにロードしておく(メモリー再生)。(原注1)
2. オーディオのデータストリーム処理に関する「同期的CPU負荷」(Syncrounous CPU load)を最小化する。ジッターの低減に加えて、これは特に低域における可聴域のRFIを減少させるのに役立つ。(原注2)
(訳注: 「同期的CPU負荷」(Syncrounous CPU load)とはDACからのリクエストによるCPU負荷のこと。)
第5章 ドライバーレベルでのさらなる最適化:インテジャーモード
OSXでのオーディオ再生は大方がAudio Unit Graph [AppleCoreAudio]のような高レベルのフレームワークによって実行される。
オーディオプレーヤーにおけるまずはじめの最適化はこれらのオーバーヘッドをバイパスして直接CoreAudioでのもっとも低レベルの層であるHAL(Hardware Abstraction Layer)にダイレクトにアクセスすることである(fig2参照)。
Figure 2: 普通のプレーヤーソフトとオーディオファイル向けプレーヤーソフトの概念の違い
訳注) 左は通常のオーディオプレーヤーの流れで四角い囲みの中がAudio realtime graphという高レベルのモジュール。右はオーディオファイル向けプレーヤー。
線の上はユーザー空間(アプリケーションの領域)で下はカーネル空間(OSの領域)。
カーネル空間でデバイスドライバーとDACのやりとりが行われている。
浮動小数点(float)モード
通常の実行ではユーザー空間とカーネル空間の境界を行き来するデータのやりとりは32bit浮動小数点形式で行われる。これは異なるオーディオストリームのミキシングプロセスとソフトウエアクリッピングを容易にする。[ Audio HAL_1]
このときでも24bitの範囲であればビットパーフェクトを達成できることに注意して欲しい。(原注4)
インテジャー(integer)モード
HALへの直接のアクセス[AppleHAL_2]は上述した通常モードにおける下記の二つの大きなオーバーヘッドをバイパスできる可能性がある。
*バッファでのミキシング
*浮動小数点からDACネイティブフォーマットへの変換
Figure 3: 浮動小数点モードとインテジャーモード
訳注) 左は通常の浮動小数点モードの流れを示していて、赤い囲みが本文中で言及されているオーバーヘッドを示している。右がインテジャーモードを示していて、単一のDACネイティブ形式での流れとなっている。
インテジャーモード(fig3)においてはプレーヤーソフトはすでにDACのネイティブ形式にフォーマットされたオーディオストリームを送出する。それゆえ「同期的CPU負荷」をドライバーレベルで最適化することができる。
この動作はカーネル空間であるドライバー内部でリアルタイムで行われるため、音質における最重要経路(クリティカルパス)となっている。なぜならそれらはDACとのデータ転送において即時性が生じる瞬間に起きる最も同期的なものだからだ。
それゆえこの最適化による効果は大きいが、この標準的でないモードを許容できるDACにのみ使用することができる。
結論
コンピューターは優れたミュージックサーバーだが、仮にビットパーフェクトが確保できたとしても音質を低下させるジッターとRFIの根源でもある。
プレーヤーソフトはこのオーディオストリームと関連した同期的な負荷による音質低下の影響を最小化するために、信号経路を最適化して整える必要がある。これにはビットパーフェクトに加えてソースダイレクトがそのキーとなる。
このことがすなわち私がAudirvanaにおいて、インテジャーモードでリアルタイム処理を単純化して、(ディスクからの読み取りやデコード、DACへのネイティブフォーマットへの変換など)他の動作は準備フェーズにオフラインで実行しておくことで、リアルタイム性能を最大限に発揮させるように効率化したということである。
これは完全メモリー再生(Full Memory Play)と呼ばれる。
最も良い結果はAMR DP-777のようにインテジャーモード、アシンクロナスUSBの対応が可能で、これらのすべての最適化の利点を享受できるものによって得ることができる。
(訳注: ComputerAudiophileのDamienさんの書き込みによると他のプレーヤーソフトとAudirvanaはメモリー再生と言う点について異なった考え方を持っている。他のプレーヤーソフトではHDD上のファイルの形式のままメモリにおいておくと言うキャッシュのような考えだが、Audirvanaではサンプルレート変換も含めてあらかじめメモリー上にデコードしたデータを置くと言うことで再生時の負荷を減らすと言う考え方が貫かれている)
原注1) HDDをSSDに交換すると直接的な機械的要因のノイズを取り除くことはできるが、長いケーブルを走る電流波形など他の要因の影響はまだ残る。まだOSのオーバーヘッドも以前として存在している。
原注2) OSXの低レベルオーディオサブシステムでは通常データを512フレーム・チャンクで要求している。つまり周波数では44.1kHzのサンプルレートで〜86Hzに相当する。
原注3) ソフトウエアボリュームコントロールを含むすべてのフィルターが取り除かれればビットパーフェクトは可能である。つまり普通のiTunesでもビットパーフェクトでありうる。
原注4) 32bit浮動小数点は1ビットの符号と8ビットの指数部、23ビットの仮数部から構成される。つまり有意な精度は24bitである。
参考文献
[hawksfordDunn96] Bits is Bits ?
Streophile 1996年3月号
[MeitnerGendron91] Time Distortions Within Digital Audio Equipment Due to Integrated Circuit Logic Induced Modulation Products
Ed MeitnerとRobert Gendronの91回AESコンベンションでの講演資料 (New York, October 1991, Preprint3105)
[AppleCoreAudio] CoreAudio Overview: What is CoreAudio ?
Mac OSX開発者向けライブラリ
[AudioHAL_1] Audio Device Driver Programming Guide: A Walk Through the I/O Model
Mac OSX開発者向けライブラリ
[AppleHAL_2] AudioHardware_h documentation
Mac OSX開発者向けライブラリ
2011年06月15日
オーディオファイル向けミュージックプレーヤー (17) - BetterSound
またMac用のミュージックプレーヤーソフトの新顔を紹介します。Audirvanaが基本無料でインテジャーモードのサポートなんかは良いけど、やっぱりPure MusicとかAmarraみたいにiTunesと統合されたタイプが欲しい、と思ってた方には良い選択となりそうです。
こらちのHeadFiスレッドで展開されているBetterSoundです。スレッドタイトルと異なり、いまやすっかりBetterSoundスレッドになっています。
http://www.head-fi.org/forum/thread/553416/audirvana-alternatives
今日現在で0.17が最新ですが、すごいスピードで更新しています。
*特徴
Macプレーヤーソフトとしての基本的な特徴はこうなります。
動作環境 MacOSX 10.6
自動サンプルレート切り替え 〇
iTunesとの親和性 〇
FLAC再生 △
インテジャーモード再生 〇
1. iTunes親和性
はじめにBetterSoundを立ち上げておいて、ステータスバーに常駐させる感じで待機させておきます。その状態でiTunesを立ち上げるとiTunes(というかQuickTimeでしょうか)をミュートし、曲選択を利用してBetterSoundが音を再生し、終了したらiTunesのミュートを元に戻すと言うのが基本的な動作のようです。ただ現在バージョンではiTunesボリュームと連動してBetterSound側のボリュームはコントロールできるようです。
2. FLAC再生
iTunesをライブラリソフトとして使うソフト(pure Music, Amarra)に共通する弱点はFLAC再生です。これはiTunesがFLACを認識しないと言うことからきています。
FLAC再生はflukeというFLACをiTunesで再生するためのアプリを使用しています。そのためflukeのインストールが必要です。flukeはBetterSoundと関係なく使えますが、下記からダウンロードします。
http://code.google.com/p/flukeformac/
インストーラーがついているのでインストーラーでインストールします。アンインストールは添付のアンインストーラーを使用します。
iTunesにFLACを登録するには、まず対象のFLACファイルをダブルクリックします。その後にそのファイルをiTunesライブラリにマウスで移動してコピーします。再生はそのファイルを普通にクリックします。
ただ私のMacではBetterSoundとの相性は不安定でした。flukeだけなら問題ないのですが。またflukeの制限から44/16のみの再生に限定されるようです。
FLAC再生は可能だけれどあまり得意ではないというところでしょうか。
3. インテジャーモード対応
BetterSoundもインテジャーモードに対応しています。これでインテジャーモードが使えるMacプレーヤーソフトは3つとなりました。(Audirvana、Pure Music、BetterSound)
インテジャーモードもすっかりMacプレーヤーソフトの定番機能の一つとなってきました。
*使用法
最新バージョンのダウンロードはこちらのavailable hereをクリックするとGoogle docsのダウンロードページに飛びます。ここではGoogle docsのアカウントが必要ですので注意ください。
http://www.head-fi.org/forum/thread/553416/audirvana-alternatives/30#post_7536852
ただ更新が速いのでスレッドをウォッチして最新のものをダウンロードすることをお勧めします。現在他のソフトのように自動アップデータがないのが残念なところです。
ダウンロードしたあとにインストールの必要はありません(Mac全般が基本的にインストーラーというものが不要ですが)。立ち上げるとステータスバーにアイコンが出てきます。そこからプルダウンメニューで設定をすることができます。
まずpreferenceで設定をします。
generalで出力デバイスとインテジャーモードのオンオフの設定ができます。device infoメニューでインテジャーモードの対応を確かめるのはAudirvanaと同じです。音が出ないときはAudio output deviceを出力機器に合わせてください。
Respect iTunes volumeはiTunesのボリューム変化を有効にするかということです。
soundタブではバッファサイズやアップサンプリングの設定ができます。
アップサンプリングはプレーヤーで整数倍にして送ります。またDACの対応サンプルレートを超えるときは自動的に倍にしないようにしているようです。たとえばfoobarのりサンプラーだと2x設定にしていると96k音源を96k対応DACで再生するとdevice unsupportedのようなエラーになりますが、こちらはそうしないようにしているようです。意外と細かいようです。
アップサンプリングはCoreAudioのリサンプラーをBest品質で使用しています。これはFideliaのようにスタジオレベルの凝ったものではないけれども、同じリサンプラーを標準品質で使用しているAudioMidi設定よりはよいと言うことですね。
つまりAudioMidi設定で楽曲のサンプルレートとAudioMidi設定を変えてリサンプリングするよりも、BetterSoundでアップサンプリングして、あくまでAudioMidi設定ではそれとマッチさせると言うほうが音質的に高いということです。(自動サンプリングレート切り替えがあるので意識しなくてもそうしてくれます)
*再生の仕方
設定がすんだらBetterSoundのメニューからLaunch iTunesでiTunesを立ち上げます。またはStart iTunes on startupで常に起動するようにしておきます。
順番はBetterSoundを立ち上げてからiTunesを立ち上げる必要がありますのでこれに注意してください。
操作中はAmarraやPure Musicのような専用パネルは表示せず、ステータスバーにアイコンが出ているだけです。シンプルでよいですね。下の画像の右上にちょっとだけ見えています。
自動サンプリングレート切り替えにも対応しているので、iTunesを手軽にハイサンプリングファイルでも使いやすくしています。
この作者はプレーヤーソフトの音性能はデバイスに書き出すときの効率で左右されると言うことを書いていて、BetterSoundではAudirvana同等でPure Audioよりは高い効率を誇っていると言うことです。
音は透明感があり、クリアに一枚ベールがはがれる感じはAudirvanaと似ています。インテジャーモードでさらに向上ができ、音質的にもかなり良いですね。
iTunesの使い勝手の良さと、Audirvana的な音質の高さを簡単に両立できて無料で使えます。なかなか良いですね。ただし、まだ不安定なところは少しあるかもしれません。
ちなみにBetter Soundではなく、BetterSoundとくっつけて小文字大文字で単語区切りにするのはプログラマーの世界の慣習的なものです。そういうところでもAudirvana的なプログラマ的技術志向のこだわりが垣間見えます。
こらちのHeadFiスレッドで展開されているBetterSoundです。スレッドタイトルと異なり、いまやすっかりBetterSoundスレッドになっています。
http://www.head-fi.org/forum/thread/553416/audirvana-alternatives
今日現在で0.17が最新ですが、すごいスピードで更新しています。
*特徴
Macプレーヤーソフトとしての基本的な特徴はこうなります。
動作環境 MacOSX 10.6
自動サンプルレート切り替え 〇
iTunesとの親和性 〇
FLAC再生 △
インテジャーモード再生 〇
1. iTunes親和性
はじめにBetterSoundを立ち上げておいて、ステータスバーに常駐させる感じで待機させておきます。その状態でiTunesを立ち上げるとiTunes(というかQuickTimeでしょうか)をミュートし、曲選択を利用してBetterSoundが音を再生し、終了したらiTunesのミュートを元に戻すと言うのが基本的な動作のようです。ただ現在バージョンではiTunesボリュームと連動してBetterSound側のボリュームはコントロールできるようです。
2. FLAC再生
iTunesをライブラリソフトとして使うソフト(pure Music, Amarra)に共通する弱点はFLAC再生です。これはiTunesがFLACを認識しないと言うことからきています。
FLAC再生はflukeというFLACをiTunesで再生するためのアプリを使用しています。そのためflukeのインストールが必要です。flukeはBetterSoundと関係なく使えますが、下記からダウンロードします。
http://code.google.com/p/flukeformac/
インストーラーがついているのでインストーラーでインストールします。アンインストールは添付のアンインストーラーを使用します。
iTunesにFLACを登録するには、まず対象のFLACファイルをダブルクリックします。その後にそのファイルをiTunesライブラリにマウスで移動してコピーします。再生はそのファイルを普通にクリックします。
ただ私のMacではBetterSoundとの相性は不安定でした。flukeだけなら問題ないのですが。またflukeの制限から44/16のみの再生に限定されるようです。
FLAC再生は可能だけれどあまり得意ではないというところでしょうか。
3. インテジャーモード対応
BetterSoundもインテジャーモードに対応しています。これでインテジャーモードが使えるMacプレーヤーソフトは3つとなりました。(Audirvana、Pure Music、BetterSound)
インテジャーモードもすっかりMacプレーヤーソフトの定番機能の一つとなってきました。
*使用法
最新バージョンのダウンロードはこちらのavailable hereをクリックするとGoogle docsのダウンロードページに飛びます。ここではGoogle docsのアカウントが必要ですので注意ください。
http://www.head-fi.org/forum/thread/553416/audirvana-alternatives/30#post_7536852
ただ更新が速いのでスレッドをウォッチして最新のものをダウンロードすることをお勧めします。現在他のソフトのように自動アップデータがないのが残念なところです。
ダウンロードしたあとにインストールの必要はありません(Mac全般が基本的にインストーラーというものが不要ですが)。立ち上げるとステータスバーにアイコンが出てきます。そこからプルダウンメニューで設定をすることができます。
まずpreferenceで設定をします。
generalで出力デバイスとインテジャーモードのオンオフの設定ができます。device infoメニューでインテジャーモードの対応を確かめるのはAudirvanaと同じです。音が出ないときはAudio output deviceを出力機器に合わせてください。
Respect iTunes volumeはiTunesのボリューム変化を有効にするかということです。
soundタブではバッファサイズやアップサンプリングの設定ができます。
アップサンプリングはプレーヤーで整数倍にして送ります。またDACの対応サンプルレートを超えるときは自動的に倍にしないようにしているようです。たとえばfoobarのりサンプラーだと2x設定にしていると96k音源を96k対応DACで再生するとdevice unsupportedのようなエラーになりますが、こちらはそうしないようにしているようです。意外と細かいようです。
アップサンプリングはCoreAudioのリサンプラーをBest品質で使用しています。これはFideliaのようにスタジオレベルの凝ったものではないけれども、同じリサンプラーを標準品質で使用しているAudioMidi設定よりはよいと言うことですね。
つまりAudioMidi設定で楽曲のサンプルレートとAudioMidi設定を変えてリサンプリングするよりも、BetterSoundでアップサンプリングして、あくまでAudioMidi設定ではそれとマッチさせると言うほうが音質的に高いということです。(自動サンプリングレート切り替えがあるので意識しなくてもそうしてくれます)
*再生の仕方
設定がすんだらBetterSoundのメニューからLaunch iTunesでiTunesを立ち上げます。またはStart iTunes on startupで常に起動するようにしておきます。
順番はBetterSoundを立ち上げてからiTunesを立ち上げる必要がありますのでこれに注意してください。
操作中はAmarraやPure Musicのような専用パネルは表示せず、ステータスバーにアイコンが出ているだけです。シンプルでよいですね。下の画像の右上にちょっとだけ見えています。
自動サンプリングレート切り替えにも対応しているので、iTunesを手軽にハイサンプリングファイルでも使いやすくしています。
この作者はプレーヤーソフトの音性能はデバイスに書き出すときの効率で左右されると言うことを書いていて、BetterSoundではAudirvana同等でPure Audioよりは高い効率を誇っていると言うことです。
音は透明感があり、クリアに一枚ベールがはがれる感じはAudirvanaと似ています。インテジャーモードでさらに向上ができ、音質的にもかなり良いですね。
iTunesの使い勝手の良さと、Audirvana的な音質の高さを簡単に両立できて無料で使えます。なかなか良いですね。ただし、まだ不安定なところは少しあるかもしれません。
ちなみにBetter Soundではなく、BetterSoundとくっつけて小文字大文字で単語区切りにするのはプログラマーの世界の慣習的なものです。そういうところでもAudirvana的なプログラマ的技術志向のこだわりが垣間見えます。
2011年06月03日
Pure Music Playerもインテジャーモードをサポートしました
予告通り、というかいささか遅れてしまい、待っているみんなにブーイングされながらもなんとか6/1にPure Music PlayerのV1.8が登場してintegerモードがサポートされました。
下記のようにAudio settingのパネルから設定できます。ProtonとDACportでとりあえず試しましたが、どちらもstrict device validationを外すとインテジャーモードが使えました。
いままでと異なるのは、Pure Musicは高精度なデジタルボリューム機能がついているのですが、インテジャーモードになるとその機能が使えずアップサンプリングなどもできないようです。この辺はみなAudio Unit周辺でやっていたようですね。つまりこの辺がそっくりバイパスされていることがわかると思います。左側のパネルが表示されなくなります。
なおV1.8からDSDの再生も可能になりましたが、現在はPCMに変換します。しかし、これがやがてくるDSDネイティブ再生への布石だとすると、インテジャーモードはMacOSでDSD再生するための前提条件として実装されたという見方もできます。Audirvanaでもインテジャーモードを使えばDSDネイティブ対応も可能だと作者が言っていました。
さて、AudirvanaだけではなくPure Music Playerでもサポートされて広がりを見せるMacOSのインテジャーモードですが、次はどこがサポートするのか?
下記のようにAudio settingのパネルから設定できます。ProtonとDACportでとりあえず試しましたが、どちらもstrict device validationを外すとインテジャーモードが使えました。
いままでと異なるのは、Pure Musicは高精度なデジタルボリューム機能がついているのですが、インテジャーモードになるとその機能が使えずアップサンプリングなどもできないようです。この辺はみなAudio Unit周辺でやっていたようですね。つまりこの辺がそっくりバイパスされていることがわかると思います。左側のパネルが表示されなくなります。
なおV1.8からDSDの再生も可能になりましたが、現在はPCMに変換します。しかし、これがやがてくるDSDネイティブ再生への布石だとすると、インテジャーモードはMacOSでDSD再生するための前提条件として実装されたという見方もできます。Audirvanaでもインテジャーモードを使えばDSDネイティブ対応も可能だと作者が言っていました。
さて、AudirvanaだけではなくPure Music Playerでもサポートされて広がりを見せるMacOSのインテジャーモードですが、次はどこがサポートするのか?
2011年06月02日
オーディオファイル向けミュージックプレーヤー (16) - JPLAY
Macのミュージックプレーヤーソフトの台頭を横目でにらんでいたWindowsユーザーのみなさま、お待たせしました。Windows用の新しい高音質ミュージックプレーヤーソフトが出てきました。
しかしちょっとMacのプレーヤーソフト群とは違う(Windowsらしい?)マニアックなソフト、JPLAYです。
JPLAYとはJust Play the musicというような意味のようです。名は体を示すといいますが、この意味はおいおいと分かってきます。下記がJPLAYのホームページです。
http://jplay.eu/
Windows Vistaと7のみの対応です。
ダウンロードはPLAYのボタンを押すとダウンロードページに行きます。インストールは不要で単に解凍したさきのプログラム(jplay.exe)をクリックしてください。
有料ソフトで99ユーロです(無料お試し期間あり)。32ビット版と64ビット版があります。対応フォーマットはWAV、AIFF、FLACです。
まず画面をみていただくと早いんですが、GUIではありません。はい、コマンドで操作します。
設定変更はテキストファイルの編集です。下記は"BIKO"という曲をロードした時の表示です。64サンプルにバッファサイズを設定しましたが、不整合ということでバッファサイズを自動的に拡張している旨が表示されています。
曲は定期的に途切れるんですが、バッファサイズによるグリッチ(不具合)かと思ったんですがデモ版の制約のようです。
*基本的な使い方
0. JPLAYを立ち上げてください。
1. 普通にWindowsのエクスプローラ(デスクトップ画面)でWAVやFLACの入った音楽ライブラリのフォルダに移動して開けてください。
2. 一曲または複数の曲をマウスで選択して右クリックメニュー(またはctrl-cで)コピーしてください。
3. JPLAYのウインドウをアクティブ化(フォーカスをあてて)してスペースバーを押してください。
4. 曲がメモリーにロードされてから再生が開始されます。
再生中の操作
スペース - 次の曲にスキップ
p - ポーズ
r - 曲の先頭に戻る
m - 停止してメニューに戻る
メインメニュー (意味は設定の項を見てください)
h - ハイバネーションモード
b - バッファサイズ切り替え
c - システムクロック切り替え
e - 再生エンジン切り替え
i - インフォメーション
m - MMCSS切り替え
q - 終了
*JPLAYの特徴
1. ハイバネーション・モード (hibernation)
これが一番のJPALYの目玉機能です。
これをオンにするとPCを純粋なPCトラポとするために、OSの不要なプロセスをみな切ります。この時点で音楽再生以外に使えなくなります。cPlay+cMPみたいにできれば専用PCで使って欲しいソフトです。ハイバネーションをオンにして曲を再生するとハイバネーションに入り、曲が終わると通常状態に自動的に復帰する(はず)です。
しかしこれ、強烈です。オンにして再生すると画面が真っ暗になります。キーボードを受け付けません。怖いです(笑)
Fidelizerを上回り、ここまでやるソフトは見たことないですね。試すときは短い曲で、編集中のファイルなどなにもないときに使ってください。
2. そっくりメモリーにロード
選択した曲すべてを一度にメモリーに入れるので効率が良いとのこと。
3. ページメモリー管理
メモリー管理をきっちりやってCPUに負担をかけないということです。
4. システムクロック
5. プライオリティスケジューリング
この辺はFidelizerのようなMMCSSの優先度設定と管理をやっているのではないかと思います。
*設定
設定ファイルはjplay.settingsというインストールフォルダにあるファイルです。これをテキスト編集します。この辺はStealth Playerのiniファイルを編集する感じです。
こちらに詳しく記述されています。
http://jplay.eu/computer-audio/jplay-beginners-guide/
filecache[32 - 65536]
MB単位でメモリー(RAM)上にロードするファイルサイズを指定します。(当然自分のPCのメモリー以下)
最低でも一曲のサイズ分は必要ということで、CD品質の場合は最低128が望ましく、ハイレゾ音源のときは512が必要とのこと(デフォルトは256)。
主に音質というよりはギャップレス再生に重要とのこと。
buffersize [1-1024]
こちらは音質に関係あるということで、ちょっとやっかいです。単位はおそらくサンプルです。最小1サンプルということだと思います。小さいほど良いようで、これを決定するのはPCの性能とオーディオインターフェースのドライバーの性能です。これを調整して行くということのようですね。
clock [0-4]
0=0.5ms、1=15.6ms、2=10ms、3=5ms、4=1ms。OSのレイテンシーを調整するもので、OSのタスク切り替えのスイッチングを早くするということです。ゼロが良いはずです。
engine [0,1]
0=river, 1=beachの再生エンジンを選びます。基本的にキャッシュのアルゴリズムが違うだけだとのこと。
beachはライブっぽくより解像度が高く感じ、riverは穏やかで聴きやすい感じということのようです。ここは好みです。
interface [0,1]
0=WASAPI、1=KS(Kernel Streaming)です。
WASAPIはよりコンパチビリティが高く、KSはより低レベルでレイテンシーが低いだろうとのこと。
force24bits [0,1]
0がデフォルト(16bit)、1にすると常に24bitで送ります。DACで24bit転送が必要な場合にこれを選択します。(foobarのoutputダイアログの24bit選択と同じでしょう)
MMCS [enabled, disabled]
interfaceでWASAPIを選択したときにMultimedia class schedulerを利かせるかを選択します。
**
FAQに「なんでビットパーフェクトなのに音が違うの?」というのがあり、そこではデータがビットパーフェクトであってもタイミングはプレーヤーソフトによって異なる」という回答がなされていますが、そうした点もかなり低いレベルで実現されているソフトといえます。
とにかくハイバネーションモードにはちょっとびっくりしますね。それと設定項目も編集は気を付けた方が良いと思いますが、ベテラン向けのマニアックなソフトと言えます。
ライブラリ機能は割り切っているのも特徴です。
ちなみに他のミュージックプレーヤーのプレイリスト上でコピーしても曲選択が使えるということです。つまり曲管理は他のプレーヤーを使ってくださいということです。
それとJ River Media Centreとかmp3toysなどのライブラリ機能に重点が置かれたプレーヤーとはもっとうまく外部リンク機能を使ってリンクできるそうです。(FAQの項です)
JPLAY自体はStealth PlayerとかcPlayみたいに再生に特化したものなので、ライブラリやプレイリスト管理は他のソフトを組み合わせるということですね。
Macのソフトはわりと使いやすく手軽に高音質を楽しむのに対して、Windowsの方はHQ PlayerとかXXHighEnd、このJPALYとマニアックで一ひねり利いたちっょとベテラン向きのものが多々あると、なかなか切り分けも出ていて面白いのではないかと思います。
しかしちょっとMacのプレーヤーソフト群とは違う(Windowsらしい?)マニアックなソフト、JPLAYです。
JPLAYとはJust Play the musicというような意味のようです。名は体を示すといいますが、この意味はおいおいと分かってきます。下記がJPLAYのホームページです。
http://jplay.eu/
Windows Vistaと7のみの対応です。
ダウンロードはPLAYのボタンを押すとダウンロードページに行きます。インストールは不要で単に解凍したさきのプログラム(jplay.exe)をクリックしてください。
有料ソフトで99ユーロです(無料お試し期間あり)。32ビット版と64ビット版があります。対応フォーマットはWAV、AIFF、FLACです。
まず画面をみていただくと早いんですが、GUIではありません。はい、コマンドで操作します。
設定変更はテキストファイルの編集です。下記は"BIKO"という曲をロードした時の表示です。64サンプルにバッファサイズを設定しましたが、不整合ということでバッファサイズを自動的に拡張している旨が表示されています。
曲は定期的に途切れるんですが、バッファサイズによるグリッチ(不具合)かと思ったんですがデモ版の制約のようです。
*基本的な使い方
0. JPLAYを立ち上げてください。
1. 普通にWindowsのエクスプローラ(デスクトップ画面)でWAVやFLACの入った音楽ライブラリのフォルダに移動して開けてください。
2. 一曲または複数の曲をマウスで選択して右クリックメニュー(またはctrl-cで)コピーしてください。
3. JPLAYのウインドウをアクティブ化(フォーカスをあてて)してスペースバーを押してください。
4. 曲がメモリーにロードされてから再生が開始されます。
再生中の操作
スペース - 次の曲にスキップ
p - ポーズ
r - 曲の先頭に戻る
m - 停止してメニューに戻る
メインメニュー (意味は設定の項を見てください)
h - ハイバネーションモード
b - バッファサイズ切り替え
c - システムクロック切り替え
e - 再生エンジン切り替え
i - インフォメーション
m - MMCSS切り替え
q - 終了
*JPLAYの特徴
1. ハイバネーション・モード (hibernation)
これが一番のJPALYの目玉機能です。
これをオンにするとPCを純粋なPCトラポとするために、OSの不要なプロセスをみな切ります。この時点で音楽再生以外に使えなくなります。cPlay+cMPみたいにできれば専用PCで使って欲しいソフトです。ハイバネーションをオンにして曲を再生するとハイバネーションに入り、曲が終わると通常状態に自動的に復帰する(はず)です。
しかしこれ、強烈です。オンにして再生すると画面が真っ暗になります。キーボードを受け付けません。怖いです(笑)
Fidelizerを上回り、ここまでやるソフトは見たことないですね。試すときは短い曲で、編集中のファイルなどなにもないときに使ってください。
2. そっくりメモリーにロード
選択した曲すべてを一度にメモリーに入れるので効率が良いとのこと。
3. ページメモリー管理
メモリー管理をきっちりやってCPUに負担をかけないということです。
4. システムクロック
5. プライオリティスケジューリング
この辺はFidelizerのようなMMCSSの優先度設定と管理をやっているのではないかと思います。
*設定
設定ファイルはjplay.settingsというインストールフォルダにあるファイルです。これをテキスト編集します。この辺はStealth Playerのiniファイルを編集する感じです。
こちらに詳しく記述されています。
http://jplay.eu/computer-audio/jplay-beginners-guide/
filecache[32 - 65536]
MB単位でメモリー(RAM)上にロードするファイルサイズを指定します。(当然自分のPCのメモリー以下)
最低でも一曲のサイズ分は必要ということで、CD品質の場合は最低128が望ましく、ハイレゾ音源のときは512が必要とのこと(デフォルトは256)。
主に音質というよりはギャップレス再生に重要とのこと。
buffersize [1-1024]
こちらは音質に関係あるということで、ちょっとやっかいです。単位はおそらくサンプルです。最小1サンプルということだと思います。小さいほど良いようで、これを決定するのはPCの性能とオーディオインターフェースのドライバーの性能です。これを調整して行くということのようですね。
clock [0-4]
0=0.5ms、1=15.6ms、2=10ms、3=5ms、4=1ms。OSのレイテンシーを調整するもので、OSのタスク切り替えのスイッチングを早くするということです。ゼロが良いはずです。
engine [0,1]
0=river, 1=beachの再生エンジンを選びます。基本的にキャッシュのアルゴリズムが違うだけだとのこと。
beachはライブっぽくより解像度が高く感じ、riverは穏やかで聴きやすい感じということのようです。ここは好みです。
interface [0,1]
0=WASAPI、1=KS(Kernel Streaming)です。
WASAPIはよりコンパチビリティが高く、KSはより低レベルでレイテンシーが低いだろうとのこと。
force24bits [0,1]
0がデフォルト(16bit)、1にすると常に24bitで送ります。DACで24bit転送が必要な場合にこれを選択します。(foobarのoutputダイアログの24bit選択と同じでしょう)
MMCS [enabled, disabled]
interfaceでWASAPIを選択したときにMultimedia class schedulerを利かせるかを選択します。
**
FAQに「なんでビットパーフェクトなのに音が違うの?」というのがあり、そこではデータがビットパーフェクトであってもタイミングはプレーヤーソフトによって異なる」という回答がなされていますが、そうした点もかなり低いレベルで実現されているソフトといえます。
とにかくハイバネーションモードにはちょっとびっくりしますね。それと設定項目も編集は気を付けた方が良いと思いますが、ベテラン向けのマニアックなソフトと言えます。
ライブラリ機能は割り切っているのも特徴です。
ちなみに他のミュージックプレーヤーのプレイリスト上でコピーしても曲選択が使えるということです。つまり曲管理は他のプレーヤーを使ってくださいということです。
それとJ River Media Centreとかmp3toysなどのライブラリ機能に重点が置かれたプレーヤーとはもっとうまく外部リンク機能を使ってリンクできるそうです。(FAQの項です)
JPLAY自体はStealth PlayerとかcPlayみたいに再生に特化したものなので、ライブラリやプレイリスト管理は他のソフトを組み合わせるということですね。
Macのソフトはわりと使いやすく手軽に高音質を楽しむのに対して、Windowsの方はHQ PlayerとかXXHighEnd、このJPALYとマニアックで一ひねり利いたちっょとベテラン向きのものが多々あると、なかなか切り分けも出ていて面白いのではないかと思います。
2011年05月21日
Macソフトウエア更新情報
うちで紹介してきたMacのミュージックプレーヤーソフトがアップデートされて新機能が入ってたりしていますので少しまとめます。
Ardirvana - 0.9.1でインテジャーモードでXMOS(Class2)対応が可能になりました。
Decibel - 1.2でプラグイン対応となりました。現在下記のようなプラグインがあります。
1. iTunesブラウザ
もともとDecibelではiTunesとのリンクにiTunes上での選択をDecibelで再生するという機能がありましたが、その不便さを解消するためにiTunesライブラリの表示が別ウィンドウできます。
2. Last.fm
WinampやFirefoxのプラグインなんかにもありますが、Last.fmというインターネットラジオ+SNSの参加と再生ができるようにしたものです。
3. IR Remote
赤外線リモコンの機能を追加したもののようです。
4. Growl対応
これはMacOSでサポートしているGrowlという通知機能(なにかあったときにメッセージをウインドウで表示する)をDecibelがサポートしたというものです。
Pure Music Player - 1.8(6/1リリース予定)でインテジャーモードとDSD再生(PCMに変換)がサポートされる予定です。
このほかにもいくつかの新機能が追加されるようです。
Ardirvana - 0.9.1でインテジャーモードでXMOS(Class2)対応が可能になりました。
Decibel - 1.2でプラグイン対応となりました。現在下記のようなプラグインがあります。
1. iTunesブラウザ
もともとDecibelではiTunesとのリンクにiTunes上での選択をDecibelで再生するという機能がありましたが、その不便さを解消するためにiTunesライブラリの表示が別ウィンドウできます。
2. Last.fm
WinampやFirefoxのプラグインなんかにもありますが、Last.fmというインターネットラジオ+SNSの参加と再生ができるようにしたものです。
3. IR Remote
赤外線リモコンの機能を追加したもののようです。
4. Growl対応
これはMacOSでサポートしているGrowlという通知機能(なにかあったときにメッセージをウインドウで表示する)をDecibelがサポートしたというものです。
Pure Music Player - 1.8(6/1リリース予定)でインテジャーモードとDSD再生(PCMに変換)がサポートされる予定です。
このほかにもいくつかの新機能が追加されるようです。
2011年04月27日
コンパイラで音は変わるか?
MacのプレーヤーソフトであるAudirvanaのプログラマDamienさんがおもしろい試みをしています。
それは異なるコンパイラで作成された3つのバージョンをユーザーがブラインドで聞き比べて投票し、次の開発に反映するというものです。
USBケーブルで音が変わるか?なんていうのはもう当たり前、ミュージックプレーヤーソフトで音が変わるか?というのもいまどきなにをという感じで、ついにコンパイラで音が変わるのかという段階に突入したわけです。
Damienさんはこれを実証するために3通りの異なるビルドを作成して、ブラインドで投票を開始しました。これが一週間くらい前です。
http://www.audirvana.com/Site_2/Compiler_test.html
コンパイラというのは簡単に言うと人の書いたプログラムから機械が分かる実行コードを生成するソフトウエアのことです。OSのアップデートなどでビルドという言葉を聞いたことがあると思いますが、簡単に言うとそのビルドするためのソフトといってもよいでしょう。
以前XMOSでコンピューターオーディオのハード的な開発環境について書きましたが、今回はソフトウエアの開発環境とオーディオの音質の関係というわけです。ケーブルとかインシュレーターと違ってユーザーがなにか関与できるものではないのですが、ユーザーにアンケートをとって開発に役立てたというところが面白いところです。
具体的にいうと上のページでA、B、CはそれぞれGCC、LLVM、その混合です。
gccは良く知られているGNUのCコンパイラで、これは私も使ったことがあります。最近はプログラミングからは離れているのでLLVM(Low Level Virtual Machine)というのは知りませんでしたが、使い込まれて古いGCCに比べると新しい視点で設計されたのがLLVMということになると思います。下記記事によるとGCCより3割高速に実行できて、最適化においても5-10%品質が高いということです。
http://journal.mycom.co.jp/articles/2008/06/03/bsdcan6/index.html
アップル自体もLLVMに移行しているということです。ちなみにMacOSXネイティブの開発環境Cocoaの標準開発言語はObjective-Cで、これはNeXTから引き継いだものですね。
その投票結果は昨日発表されました。結果は下記のようになったようです。
http://www.computeraudiophile.com/content/New-OSX-Opensource-audiophile-player-Audirvana#comment-79478
A:30.3% (LLVM)
B:24.2% (GCC)
C:45.5% (LLVM+GCC)
そう大きな差はないんですが、興味深いのは別のコンパイラをまぜて使ったほうが評価が高かったということですね。
実際にAudirvanaの0.8.2はgccで作成されましたが、0.8.3はgcc+LLVMで作成されたようです。この割合は低レベルのルーチン(主にオーディオ出力)はgccで生成し、UIとかプレイリストはLLVMで生成するということです。以前はLLVMのみだったようですが、ためしに作った0.8.2の音質評価が良かったのでこうしたテストになったのでしょう。Audirvanaはかなりきわどい処理をしているようなので枯れたgccのほうが良いということもあるかもしれません。
なんでコンパイラで音が変わるかというと、そのポイントになるのは上で書いた最適化の品質が高くなるということだと思います。実際に同じコンパイラでも最適化スイッチをいじると音は異なってくるということです。
ここでコンパイラと最適化の関係についてちょっと考えてみます。たとえばX=A+B; Y=C+D; Z=E+F; ...のような計算をするときは普通に考えると頭から一ステップずつ計算して行くように思えますが、それは人間の頭が同時にひとつしか実行できないからです。プロセッサがいくつも平行に処理できるのであれば、A+Bの計算をしているときに少し先のE+Fを同時にやって結果を出していれば全体的には高速に実行できます。
しかし、途中に条件分岐があったり、後の計算が先の計算に影響を受けていたりするとそう簡単ではありません。現代のCPUでは予測分岐という手法で本来はその時点でないとどちらに分岐するか分からないのに、あらかじめ分岐を仮定して計算してしまうということも行われます。
もうこうなってくると人間の頭ではとうていついていけませんが、こうしてプロセッサの特性を生かした最適化をするような実行コードを生成するということをしないと現代のプロセッサはまったく性能を発揮することができません。
つまりは最終的にCPUが実行するコードの並びを決定するのは実際は人が書いたプログラムではなくコンパイラですから、同じソースコードでもコンパイラ次第で実行の効率というのは左右されるということです。ですからコンパイラを変えるというのはちょっとサービス止めたりするよりも大きくソフトウエアの実行に影響してもおかしくはありません。
それを考えると最新のLLVMで低レベルを処理したほうが良いようにも思えますが、そうならないのもまたオーディオかな、というところでしょうか。まさにコンピューターらしい理由で音質を追及するわけですが、最後の調整は人の耳というのも面白いところかもしれません。
それは異なるコンパイラで作成された3つのバージョンをユーザーがブラインドで聞き比べて投票し、次の開発に反映するというものです。
USBケーブルで音が変わるか?なんていうのはもう当たり前、ミュージックプレーヤーソフトで音が変わるか?というのもいまどきなにをという感じで、ついにコンパイラで音が変わるのかという段階に突入したわけです。
Damienさんはこれを実証するために3通りの異なるビルドを作成して、ブラインドで投票を開始しました。これが一週間くらい前です。
http://www.audirvana.com/Site_2/Compiler_test.html
コンパイラというのは簡単に言うと人の書いたプログラムから機械が分かる実行コードを生成するソフトウエアのことです。OSのアップデートなどでビルドという言葉を聞いたことがあると思いますが、簡単に言うとそのビルドするためのソフトといってもよいでしょう。
以前XMOSでコンピューターオーディオのハード的な開発環境について書きましたが、今回はソフトウエアの開発環境とオーディオの音質の関係というわけです。ケーブルとかインシュレーターと違ってユーザーがなにか関与できるものではないのですが、ユーザーにアンケートをとって開発に役立てたというところが面白いところです。
具体的にいうと上のページでA、B、CはそれぞれGCC、LLVM、その混合です。
gccは良く知られているGNUのCコンパイラで、これは私も使ったことがあります。最近はプログラミングからは離れているのでLLVM(Low Level Virtual Machine)というのは知りませんでしたが、使い込まれて古いGCCに比べると新しい視点で設計されたのがLLVMということになると思います。下記記事によるとGCCより3割高速に実行できて、最適化においても5-10%品質が高いということです。
http://journal.mycom.co.jp/articles/2008/06/03/bsdcan6/index.html
アップル自体もLLVMに移行しているということです。ちなみにMacOSXネイティブの開発環境Cocoaの標準開発言語はObjective-Cで、これはNeXTから引き継いだものですね。
その投票結果は昨日発表されました。結果は下記のようになったようです。
http://www.computeraudiophile.com/content/New-OSX-Opensource-audiophile-player-Audirvana#comment-79478
A:30.3% (LLVM)
B:24.2% (GCC)
C:45.5% (LLVM+GCC)
そう大きな差はないんですが、興味深いのは別のコンパイラをまぜて使ったほうが評価が高かったということですね。
実際にAudirvanaの0.8.2はgccで作成されましたが、0.8.3はgcc+LLVMで作成されたようです。この割合は低レベルのルーチン(主にオーディオ出力)はgccで生成し、UIとかプレイリストはLLVMで生成するということです。以前はLLVMのみだったようですが、ためしに作った0.8.2の音質評価が良かったのでこうしたテストになったのでしょう。Audirvanaはかなりきわどい処理をしているようなので枯れたgccのほうが良いということもあるかもしれません。
なんでコンパイラで音が変わるかというと、そのポイントになるのは上で書いた最適化の品質が高くなるということだと思います。実際に同じコンパイラでも最適化スイッチをいじると音は異なってくるということです。
ここでコンパイラと最適化の関係についてちょっと考えてみます。たとえばX=A+B; Y=C+D; Z=E+F; ...のような計算をするときは普通に考えると頭から一ステップずつ計算して行くように思えますが、それは人間の頭が同時にひとつしか実行できないからです。プロセッサがいくつも平行に処理できるのであれば、A+Bの計算をしているときに少し先のE+Fを同時にやって結果を出していれば全体的には高速に実行できます。
しかし、途中に条件分岐があったり、後の計算が先の計算に影響を受けていたりするとそう簡単ではありません。現代のCPUでは予測分岐という手法で本来はその時点でないとどちらに分岐するか分からないのに、あらかじめ分岐を仮定して計算してしまうということも行われます。
もうこうなってくると人間の頭ではとうていついていけませんが、こうしてプロセッサの特性を生かした最適化をするような実行コードを生成するということをしないと現代のプロセッサはまったく性能を発揮することができません。
つまりは最終的にCPUが実行するコードの並びを決定するのは実際は人が書いたプログラムではなくコンパイラですから、同じソースコードでもコンパイラ次第で実行の効率というのは左右されるということです。ですからコンパイラを変えるというのはちょっとサービス止めたりするよりも大きくソフトウエアの実行に影響してもおかしくはありません。
それを考えると最新のLLVMで低レベルを処理したほうが良いようにも思えますが、そうならないのもまたオーディオかな、というところでしょうか。まさにコンピューターらしい理由で音質を追及するわけですが、最後の調整は人の耳というのも面白いところかもしれません。
2011年04月18日
Amarraは384k対応へ
Amarraが2.2にバージョンアップされました。大きな点は各ライセンスの制限値が引き上げられ、標準版は384k、miniは192k、ジュニアは96kとなりました。他にもいくつか改良点があります。(国内対応は不明)
Amarraもいまとなっては古さが否めませんでしたが、これで一歩現代の事情にすり合わせができました。ただし価格は同じようです。ジュニアにおいては逆に$20高くなりました。ニューウエーブのDecibel、Fideliaに比べるとまだ高いですね。
Amarraもいまとなっては古さが否めませんでしたが、これで一歩現代の事情にすり合わせができました。ただし価格は同じようです。ジュニアにおいては逆に$20高くなりました。ニューウエーブのDecibel、Fideliaに比べるとまだ高いですね。
2011年03月03日
Fidelizer - Windowsのオーディオ向け最適化ツール
Fidelizerはミュージックプレーヤーそのものではなく、いわゆるPCのオーディオ最適化をするツールです。PCをオーディオ専用に使いたいときに、直接音楽再生に不要なサービスなどを止めたいことがあります。そのためいろいろとウエブをあさってサービスを止めたり、プロセスの優先度を上げたりと四苦八苦したりしますが、それをやってくれるツールというわけです。残念ながらXPではなく、Vista/7専用です。
ただしこれはよくあるサービスの停止が一番の眼目ではなく、Vista以降で導入されたMMCSSによるWindowsのCoreAudioの最適化というところがポイントのようです。MMCSSは以前書きましたが、Vistaから導入されたマルチメディア用のOSレベルのスケジューリング機能です。(そのためVista/7専用となっています)
中で行っているのはオーディオ関連のプロセスをMMCSSを使って最適化することと、システムクロックの解像度を高めるということです。これはオーディオ雑誌に出てくるクロックではなく、コンピューターのベースクロックのことです。これが高まると何が良いかというと、割り込みの精度が向上すると言うことだとおもいます。この辺は前に書いたこのOSのスケジューリングに関する記事もご覧ください。
http://vaiopocket.seesaa.net/article/164063891.html
おそらく下記のGetSystemTimeAdjustment関数みたいなところが関連してくるでしょう。
http://msdn.microsoft.com/ja-jp/library/cc429815.aspx
あちこちにポストされていますが、とりあえずはCAのスレッドです。下記のポストからzipファイルをダウンロードしてください。
http://www.computeraudiophile.com/content/Fidelizer-12-Instantly-computer-audiophile-workstation
恒久的にパッチを当てるものではなく、リブートすれば元に戻ります。またスタートアップに登録して自動起動させることもできます。とりあえず試してみて気に入ったらスタートアップに登録するというのが良いと思います。
* 使い方と効果
わたしのWindows7 64bitで試しました。
ダウンロードしたらFidelizerをダブルクリックして起動します。すると次のような設定画面が現れます。これは試しにセットしてみた項目です。一番下のチェック項目はホームページのデフォルトを変えるだけなので要らないでしょう。
Fidelizeボタンを押すと最適化が始まります。これには数分かかるので待っていてください。
次々に最適化のステップがなされていきます。途中からウインドウが角くなるのがわかると思いますが、アエロも切ります。
このウインドウが出ると最適化完了です。ここでプレーヤーを立ち上げて使ってください。
プレーヤーに対して個別になにか設定を行う必要はありません。共通なWindowsのCoreAudio部分のみ何かしていると思います。止めたいときはリブートしてください。
たしかにリブートすると元に戻りますが、あくまで自己責任でお使いください。ただあまり危ないものではないと思います。(ウイルスチェッカーでは反応します)
Foobar2000で試してみましたが実際に聞いてみるとけっこう効果があり、音がはっきりクリアになります。ちょっと手放せなくなるかもしれません。
いろいろと最適化手段はネットに出ているけど、なにをしてよいかわからない、手を付けるのが怖いという方にも簡単でよいですね。
なおマニアのためにちょっと予防線が張ってあって、DPC latency checkerでは向上が見られないけどほんとに効いてる?というFAQが用意されています。
答えとしてはDPC latency checkerではハードのレイテンシーは測れるけど、ここでやっているようなソフトウエアのレイテンシーの向上は図れない、もしやるとしたらかなり本格的な計測システムが必要なので耳で試してください、というのが書いてあります。
ちょっと面白いのはこの作者の人のAudioAsylumのコメントで、「最近の重なるMacのミュージックプレーヤーの出現に押されているWindowsにまた光を当てたい」と言ってるのが最近の状況を端的に語ってます。
こうしたちょっとマニアックなソフトがWindowsらしくもあります。Windowsファンの方はMacなにするものぞと、ぜひお使いください。
ただしこれはよくあるサービスの停止が一番の眼目ではなく、Vista以降で導入されたMMCSSによるWindowsのCoreAudioの最適化というところがポイントのようです。MMCSSは以前書きましたが、Vistaから導入されたマルチメディア用のOSレベルのスケジューリング機能です。(そのためVista/7専用となっています)
中で行っているのはオーディオ関連のプロセスをMMCSSを使って最適化することと、システムクロックの解像度を高めるということです。これはオーディオ雑誌に出てくるクロックではなく、コンピューターのベースクロックのことです。これが高まると何が良いかというと、割り込みの精度が向上すると言うことだとおもいます。この辺は前に書いたこのOSのスケジューリングに関する記事もご覧ください。
http://vaiopocket.seesaa.net/article/164063891.html
おそらく下記のGetSystemTimeAdjustment関数みたいなところが関連してくるでしょう。
http://msdn.microsoft.com/ja-jp/library/cc429815.aspx
あちこちにポストされていますが、とりあえずはCAのスレッドです。下記のポストからzipファイルをダウンロードしてください。
http://www.computeraudiophile.com/content/Fidelizer-12-Instantly-computer-audiophile-workstation
恒久的にパッチを当てるものではなく、リブートすれば元に戻ります。またスタートアップに登録して自動起動させることもできます。とりあえず試してみて気に入ったらスタートアップに登録するというのが良いと思います。
* 使い方と効果
わたしのWindows7 64bitで試しました。
ダウンロードしたらFidelizerをダブルクリックして起動します。すると次のような設定画面が現れます。これは試しにセットしてみた項目です。一番下のチェック項目はホームページのデフォルトを変えるだけなので要らないでしょう。
Fidelizeボタンを押すと最適化が始まります。これには数分かかるので待っていてください。
次々に最適化のステップがなされていきます。途中からウインドウが角くなるのがわかると思いますが、アエロも切ります。
このウインドウが出ると最適化完了です。ここでプレーヤーを立ち上げて使ってください。
プレーヤーに対して個別になにか設定を行う必要はありません。共通なWindowsのCoreAudio部分のみ何かしていると思います。止めたいときはリブートしてください。
たしかにリブートすると元に戻りますが、あくまで自己責任でお使いください。ただあまり危ないものではないと思います。(ウイルスチェッカーでは反応します)
Foobar2000で試してみましたが実際に聞いてみるとけっこう効果があり、音がはっきりクリアになります。ちょっと手放せなくなるかもしれません。
いろいろと最適化手段はネットに出ているけど、なにをしてよいかわからない、手を付けるのが怖いという方にも簡単でよいですね。
なおマニアのためにちょっと予防線が張ってあって、DPC latency checkerでは向上が見られないけどほんとに効いてる?というFAQが用意されています。
答えとしてはDPC latency checkerではハードのレイテンシーは測れるけど、ここでやっているようなソフトウエアのレイテンシーの向上は図れない、もしやるとしたらかなり本格的な計測システムが必要なので耳で試してください、というのが書いてあります。
ちょっと面白いのはこの作者の人のAudioAsylumのコメントで、「最近の重なるMacのミュージックプレーヤーの出現に押されているWindowsにまた光を当てたい」と言ってるのが最近の状況を端的に語ってます。
こうしたちょっとマニアックなソフトがWindowsらしくもあります。Windowsファンの方はMacなにするものぞと、ぜひお使いください。
2011年02月19日
FLAC Playerの24ビットサポート再燃
前にiPadのUSB DACサポートのことでiOSとFLAC Playerの記事を書いた時に、iOSでは24bitは通せなく、CoreAudioのどこかでカットされているのではないか、と書きました。
http://vaiopocket.seesaa.net/article/170733733.html
このときにFLAC Playerの作者のDanさんにメールして事情を説明して、対応をお願いしていたんですが、その後はなにもありませんでした。しかし今日CAの下記フォーラムでDanさんがきちんと見てくれるという書き込みをしてくれてます。
http://www.computeraudiophile.com/content/iOS-2496-Output-Possible
前に書いた時にはDanさんがFLAC Playerでは意図的に24を16にするような処理はしてないと言ってましたので、CoreAudioのどこかで削ってるかと思ってたんですが、実はPCMデータをオーディオキューに入れる時に削っていたようです。それはLPCMフォーマットの選択が32bitと16bitしかないので、16bitでやっていたということです。そこで下位8ビットが消えていたんでしょう。24bitではオーディオキューに入れられないそうです。そこで32bitに24ビットデータを左詰めして試してみてくれるということです。これはもしうまく行ったらちょっと楽しみなことですね。
http://vaiopocket.seesaa.net/article/170733733.html
このときにFLAC Playerの作者のDanさんにメールして事情を説明して、対応をお願いしていたんですが、その後はなにもありませんでした。しかし今日CAの下記フォーラムでDanさんがきちんと見てくれるという書き込みをしてくれてます。
http://www.computeraudiophile.com/content/iOS-2496-Output-Possible
前に書いた時にはDanさんがFLAC Playerでは意図的に24を16にするような処理はしてないと言ってましたので、CoreAudioのどこかで削ってるかと思ってたんですが、実はPCMデータをオーディオキューに入れる時に削っていたようです。それはLPCMフォーマットの選択が32bitと16bitしかないので、16bitでやっていたということです。そこで下位8ビットが消えていたんでしょう。24bitではオーディオキューに入れられないそうです。そこで32bitに24ビットデータを左詰めして試してみてくれるということです。これはもしうまく行ったらちょっと楽しみなことですね。
Pure Music Playerもintegerモードへ
下記のAudio Asylumのポストによると、Pure Music Playerもintegerモードの開発中だそうですので近いうちにリリースがあるのではないかと思います。
このポストを書いた人は開発中のバージョンを試してみてAudirvanaのintegerモードよりもPure Musicのintegerモードのほうが良いと感じているようです。
http://www.AudioAsylum.com/cgi/vt.mpl?f=pcaudio&m=85807
文中から察するとやはりPure MusicでもAudirvanaのようにCoreAudioのAU(Audio Unit)のバイパスをやるようです。「ミキサーのバイパス」と言ってるところですが、これはAUがAudioMidi設定で示される値にリサンプルするモジュールだからです。ただこれはXPで言うところのカーネルミキサーのバイパスと言うよりは、Vista以降で言うところの排他モードWASAPIに近いものだと思います。
Amarraも似たようにAUバイパスしてるみたいなのでそのうちintegerモード対応するかもしれません。
スレッド上の画像はHAL LABを使用してDACのIntergerモードの対応を確認してるところです。この前Audirvanaのログの確認をしたのと同じくVirtual formatの欄にintegerサポートがあるかを確認していますね。
このポストを書いた人は開発中のバージョンを試してみてAudirvanaのintegerモードよりもPure Musicのintegerモードのほうが良いと感じているようです。
http://www.AudioAsylum.com/cgi/vt.mpl?f=pcaudio&m=85807
文中から察するとやはりPure MusicでもAudirvanaのようにCoreAudioのAU(Audio Unit)のバイパスをやるようです。「ミキサーのバイパス」と言ってるところですが、これはAUがAudioMidi設定で示される値にリサンプルするモジュールだからです。ただこれはXPで言うところのカーネルミキサーのバイパスと言うよりは、Vista以降で言うところの排他モードWASAPIに近いものだと思います。
Amarraも似たようにAUバイパスしてるみたいなのでそのうちintegerモード対応するかもしれません。
スレッド上の画像はHAL LABを使用してDACのIntergerモードの対応を確認してるところです。この前Audirvanaのログの確認をしたのと同じくVirtual formatの欄にintegerサポートがあるかを確認していますね。
Fidelia正式リリース
この前紹介したMacのミュージックプレーヤーのFideliaはライセンスを購入しようとしてもStoreになかったんですが、本日正式リリースしたようです。(下記CAのポストした人はFideliaのベータテストをしてた人です)
http://www.computeraudiophile.com/content/Fidelia-Officially-Released
記事を書いた時はその時のネットの書き込みを見て$119と書いたんですが、実際はずっと安くて$20と言うことです。ただしiZotopeのSRCを使う場合にはAdd onとして$50追加が必要と言うことです。またhogモードの使用もAdd onライセンスが必要です。
買い方はStoreをクリックして、FideliaのBase($19.99)とAdd onタブからiZotopeのライセンス($49.99)のアイコンをクリックではなく、Cartと書かれているエリアにアイコンをドラッグしてカートに追加します。ユーザー情報をすべて埋めて、下でPaypalなどで支払します。ライセンスキーはメールですぐに帰ってきます。あとはFideliaのAdd licenseでそれぞれキーをセットします。
ソフトはライセンスがなくても14日間は無料で試用できます。
それとAudirvanaも無料と紹介しましたが、Paypalで自発的にdonate(寄付)するシェアウエアのようになっています。価格は決まってませんのでお気持ちですが、気に入った人はいくらか入金してあげてください。
http://code.google.com/p/audirvana/
上記ホームページのcontributeから寄付できます。通貨単位はユーロなのでそちらの人のようですね。
http://www.computeraudiophile.com/content/Fidelia-Officially-Released
記事を書いた時はその時のネットの書き込みを見て$119と書いたんですが、実際はずっと安くて$20と言うことです。ただしiZotopeのSRCを使う場合にはAdd onとして$50追加が必要と言うことです。またhogモードの使用もAdd onライセンスが必要です。
買い方はStoreをクリックして、FideliaのBase($19.99)とAdd onタブからiZotopeのライセンス($49.99)のアイコンをクリックではなく、Cartと書かれているエリアにアイコンをドラッグしてカートに追加します。ユーザー情報をすべて埋めて、下でPaypalなどで支払します。ライセンスキーはメールですぐに帰ってきます。あとはFideliaのAdd licenseでそれぞれキーをセットします。
ソフトはライセンスがなくても14日間は無料で試用できます。
それとAudirvanaも無料と紹介しましたが、Paypalで自発的にdonate(寄付)するシェアウエアのようになっています。価格は決まってませんのでお気持ちですが、気に入った人はいくらか入金してあげてください。
http://code.google.com/p/audirvana/
上記ホームページのcontributeから寄付できます。通貨単位はユーロなのでそちらの人のようですね。
2011年02月15日
AudirvanaでのIntegerモード使用の要件
Integer(インテジャー = 整数型)モードをサポートしたAudirvana 0.6.0ですが、問題点をFixするために今日時点では0.6.1がリリースされています。
前記事でも書きましたが、このIntegerモードでは使用するDAC側にも要件があります。昨日の時点ではとりあえずゴードン系のUSB DACはIntegerモードが使えると書きました。このほかにはいま分かっているところではフェーズテックのHD-7Aが動作可能であるようです。HD-7AはiPadのUSB再生も大丈夫でしたが、とても素直な素性を持っているようです。
この他にはDACportはOKでした。しかしhiFaceはだめです。hiFaceでintegerモードをオンにしてもintegerモードで再生されません(通常モードで再生されます)。これを考えるとドライバーも標準ドライバーである必要がありそうです。標準ドライバーの利点というのは単にインストール不要ということだけではなく、こういうところでも利いてくるのかもしれません。
また、24bit要件もあって、0.6.1では16bitが対応されたようですが、16bit integerをサポートしているNuForce uDACはだめでした。integerモードに入りますが、再生ピッチが狂います。ただここは修正されるとは思います。
もしこれ以外の手持ちのDACがIntegerモードで使えるかどうかを確認したければ、下記の方法で確認してください。
1. AudirvanaにDACを認識させる (preferenceのAudio設定からchangeで設定を確認する)
2. Audirvanaのdebug infoメニューから情報を参照する
3. いくつかの項目に分かれていますが、下のほうにvirtual formatsという項目があります。そこに対応フォーマットの詳細が列記されているはずです。そこでinteger形式が含まれているかを確認してください。float(浮動小数点)という記述だけならIntegerモードは使えません。physical formatsの方だけintegerがあってはだめです。
例を挙げます。
これはOKなDACportの例です。下線部分がintegerサポートが明示されている箇所です。
-------------------------------------
Audirvana rev. 0.6.1 debug information:
Currently playing in Integer Mode:
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Hog Mode is on
Devices found : 2
List of devices:
Device #0: ID 0x104 Built-in Output UID:Built-in Output
Device #1: ID 0x106 CEntrance DACport UID:CEntrance DACport
******(省略)
1 output streams:
Stream ID 0x107 2 channels starting at 1
8 virtual formats:
Mixable linear PCM Interleaved 32bits little endian Float @96.0kHz
Mixable linear PCM Interleaved 32bits little endian Float @88.2kHz
Mixable linear PCM Interleaved 32bits little endian Float @48.0kHz
Mixable linear PCM Interleaved 32bits little endian Float @44.1kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @96.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @48.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @44.1kHz
8 physical formats
Mixable linear PCM Interleaved 24bits little endian Signed Integer @96.0kHz
Mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Mixable linear PCM Interleaved 24bits little endian Signed Integer @48.0kHz
Mixable linear PCM Interleaved 24bits little endian Signed Integer @44.1kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @96.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @48.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @44.1kHz
-------------------------------------
これは使えないhiFaceの例です。virtual formatの欄にintegerの記載がありません。
-------------------------------------
Audirvana rev. 0.6.1 debug information:
Hog Mode is off
Devices found : 2
List of devices:
Device #0: ID 0x104 Built-in Output UID:Built-in Output
Device #1: ID 0x106 M2Tech HiFace UID:M2Tech HiFace
******(省略)
1 output streams:
Stream ID 0x108 2 channels starting at 1
1 virtual formats:
Mixable linear PCM Interleaved 32bits little endian Float @44.1 to 192.0kHz
1 physical formats
Mixable linear PCM Interleaved 32bits big endian Signed Integer @44.1 to 192.0kHz
-------------------------------------
再生時のデータの流れを模式的に経路を書くとこの様になります。
Audirvana → CoreAudio (MacOS) → DAC
Virtual formatとはCoreAudioで使われるデータ形式で、普通はfloat(32bit浮動小数点)が使われます。Physical formatとはDACの中で使われるネイティブ形式のことで、普通はinteger(整数)が使われます。
ですから上の図をデータ形式の流れで書くとこうなります。
Audirvana → Virtual format → Physical format
つまりVirtual FormatのところにもIntegerが書かれてあれば、それを利用してDACで使用するPhysical formatであるIntegerのままでCoreAudioを通過できるということだと思います。
まえにCoreAudioではリゾリューションに関しては24bitの「精度」が限界と書きましたが、ここでDAC側が32bit Integerをサポートしていていれば32bitのハイレゾデータ、あるいは24bitから適切なディザ処理をしてビット拡張したデータをCoreAudioで扱えるということかもしれません。
またこの要件は少なくともAudirvanaはそうだということです。開発者もIntegerモードを実装するためには他の方法があるかもしれないが、Audirvanaではこうしている、ということを書いています。
前記事でも書きましたが、このIntegerモードでは使用するDAC側にも要件があります。昨日の時点ではとりあえずゴードン系のUSB DACはIntegerモードが使えると書きました。このほかにはいま分かっているところではフェーズテックのHD-7Aが動作可能であるようです。HD-7AはiPadのUSB再生も大丈夫でしたが、とても素直な素性を持っているようです。
この他にはDACportはOKでした。しかしhiFaceはだめです。hiFaceでintegerモードをオンにしてもintegerモードで再生されません(通常モードで再生されます)。これを考えるとドライバーも標準ドライバーである必要がありそうです。標準ドライバーの利点というのは単にインストール不要ということだけではなく、こういうところでも利いてくるのかもしれません。
また、24bit要件もあって、0.6.1では16bitが対応されたようですが、16bit integerをサポートしているNuForce uDACはだめでした。integerモードに入りますが、再生ピッチが狂います。ただここは修正されるとは思います。
もしこれ以外の手持ちのDACがIntegerモードで使えるかどうかを確認したければ、下記の方法で確認してください。
1. AudirvanaにDACを認識させる (preferenceのAudio設定からchangeで設定を確認する)
2. Audirvanaのdebug infoメニューから情報を参照する
3. いくつかの項目に分かれていますが、下のほうにvirtual formatsという項目があります。そこに対応フォーマットの詳細が列記されているはずです。そこでinteger形式が含まれているかを確認してください。float(浮動小数点)という記述だけならIntegerモードは使えません。physical formatsの方だけintegerがあってはだめです。
例を挙げます。
これはOKなDACportの例です。下線部分がintegerサポートが明示されている箇所です。
-------------------------------------
Audirvana rev. 0.6.1 debug information:
Currently playing in Integer Mode:
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Hog Mode is on
Devices found : 2
List of devices:
Device #0: ID 0x104 Built-in Output UID:Built-in Output
Device #1: ID 0x106 CEntrance DACport UID:CEntrance DACport
******(省略)
1 output streams:
Stream ID 0x107 2 channels starting at 1
8 virtual formats:
Mixable linear PCM Interleaved 32bits little endian Float @96.0kHz
Mixable linear PCM Interleaved 32bits little endian Float @88.2kHz
Mixable linear PCM Interleaved 32bits little endian Float @48.0kHz
Mixable linear PCM Interleaved 32bits little endian Float @44.1kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @96.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @48.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @44.1kHz
8 physical formats
Mixable linear PCM Interleaved 24bits little endian Signed Integer @96.0kHz
Mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Mixable linear PCM Interleaved 24bits little endian Signed Integer @48.0kHz
Mixable linear PCM Interleaved 24bits little endian Signed Integer @44.1kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @96.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @88.2kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @48.0kHz
Non-mixable linear PCM Interleaved 24bits little endian Signed Integer @44.1kHz
-------------------------------------
これは使えないhiFaceの例です。virtual formatの欄にintegerの記載がありません。
-------------------------------------
Audirvana rev. 0.6.1 debug information:
Hog Mode is off
Devices found : 2
List of devices:
Device #0: ID 0x104 Built-in Output UID:Built-in Output
Device #1: ID 0x106 M2Tech HiFace UID:M2Tech HiFace
******(省略)
1 output streams:
Stream ID 0x108 2 channels starting at 1
1 virtual formats:
Mixable linear PCM Interleaved 32bits little endian Float @44.1 to 192.0kHz
1 physical formats
Mixable linear PCM Interleaved 32bits big endian Signed Integer @44.1 to 192.0kHz
-------------------------------------
再生時のデータの流れを模式的に経路を書くとこの様になります。
Audirvana → CoreAudio (MacOS) → DAC
Virtual formatとはCoreAudioで使われるデータ形式で、普通はfloat(32bit浮動小数点)が使われます。Physical formatとはDACの中で使われるネイティブ形式のことで、普通はinteger(整数)が使われます。
ですから上の図をデータ形式の流れで書くとこうなります。
Audirvana → Virtual format → Physical format
つまりVirtual FormatのところにもIntegerが書かれてあれば、それを利用してDACで使用するPhysical formatであるIntegerのままでCoreAudioを通過できるということだと思います。
まえにCoreAudioではリゾリューションに関しては24bitの「精度」が限界と書きましたが、ここでDAC側が32bit Integerをサポートしていていれば32bitのハイレゾデータ、あるいは24bitから適切なディザ処理をしてビット拡張したデータをCoreAudioで扱えるということかもしれません。
またこの要件は少なくともAudirvanaはそうだということです。開発者もIntegerモードを実装するためには他の方法があるかもしれないが、Audirvanaではこうしている、ということを書いています。