デジタル転送過程でデータ改変は発生しているか

09/10/03初稿

 排他WASAPIで出力されたデジタルデータは本当に改変されずにDACのInputまで届いているのでしょうか?
 逆に、いわゆるカーネルミキサ(本稿ではオーディオエンジンのこともこれで仮称します)を介すると本当にデータが改変されているのでしょうか?

 CDプレーヤの出力を録音して…というは藤本健氏の記事(*)でもう8年前に検証されてますが、PCのファイル再生に関する検証はweb上で確認できなかったので、自分で実験を試みました。
 念のためですが特記しない限り「WASAPI」は排他モードを指します。

*:http://av.watch.impress.co.jp/docs/20010416/dal06.htm


■デジタル転送中にデータ改変は発生しているか

 WAVファイルをuLilithで再生し、S/PDIF接続してデジタルダイレクト録音し、できた録音ファイルを再生ファイルとコンペアします。コンペアには従来と同じく≪WaveCompare≫を用います。
 出力側DDCやS/PDIFケーブルにはあえてフツーの機材を使っています。もともとの目的は排他WASAPIによるデータ改変なしを確認することですが、同時に「フツーの機材」でのデータ改変有無も確認しようという意図からです。
 なお、すべてのボリューム(バランス含む)は「MAX」、すべてのエフェクト系は「OFF」にするのが基本です。

・出力側環境
  ・PC・・・FUJITSU FMV MG70W Vista HomePremiumSP2 32bit
  ・Player・・・uLilith β3
  ・DDC・・・ONKYO UD-5(オーディオ用というよりPCからの5.1ch出力用(*))
  ・USBケーブル・・・UD-5一体型

*:http://www.jp.onkyo.com/support/manual/manualpdf/ud-5_j.pdf

・接続
  ・光デジタルケーブル・・・SONY POC-20A(2.0mで\2,000弱の一般品)

・録音側環境
  ・PC・・・HDC-1L Win7RC 64bit
  ・Recorder・・SONAR8 PRODUCER 64 Trial
  ・DDC・・・SE-U55SX UD-5のOutputを光Inputに入力
  ・USBケーブル・・・ULTRAVIOLET5-2

 ポイントは「録音する側でカーネルミキサ通したら意味がない」ということ。実際、Windows付属の≪サウンドレコーダ≫を使うとWAVコンペア一致しないファイルになります。

 そこで、録音ソフトとしては、排他WASAPIに対応してるという≪SONAR8 PRODUCER(体験版)≫を使います。
 しかし、排他WASAPIにして録音してみましたが全然一致しません。
 初めていじくるDAWソフトで設定の勘どころもないので諦めようかと思いましたが、試しに「WDM/KS」モードにしてみたら…
 来ました来ましたWAVコンペア一致! 数回すべて一致しました。

 排他WASAPIでダメだった理由はよくわかりません。SONAR8のWASAPI実装の問題でしょうか? そう言えばインストール時にひとつエラーが出て無視しましたが(苦笑)。後で思いましたが、もしかしたら排他ではなく共有モードだったのかもしれません。

 一方、再生側のuLilithを「DirectSound(以下DS)」に設定して出力したデータを録音すると、確かに「WAVコンペア一致しない」ファイルができあがります。ところどころじゃなくて全く(微妙に)一致しません。カーネルミキサを通る時に演算されちゃってるんでしょうね。
 そうして出来たWAVファイルを排他WASAPIのビットパーフェクトで聴いてみると、確かに「一枚ヴェールがかかったような」音になります(笑)。DSで出力した時と同じカンジですね。


 ちなみにSE-U55SXはSONAR8上のWDM/KSモードで再生も出来ました。ASIOは動きません(とういか認識しない)。
 WDM/KSってASIOと違って汎用ドライバで使えるんですね。WDM/KS対応のPlayerとかあったらいい音出しそうです。ちょっと調べたところではfoobar2000にKSプラグインがあるみたいです。
 そのうち、≪uLilith with 排他WASAPI≫≪foobar2000 with 排他WASAPI≫≪foobar2000 with KS≫地上最大の決戦でもやってみたいと思います。


 う~む。ウワサは本当だったようです。排他WASAPIはWAVファイルの中身を正確にUSB出力しています。ビットパーフェクト(Bit Perfect)とかビットイグザクト(Bit Exact)とか言うんですか?
 一方、WASAPI以前のAPIはやっぱり改変していました。

 これをハードウェア的な観点で見てみます。
 具体的にデータの流れで言うと、今回の実験では

PC→USB→DDC→S/PDIF(光)→DDC→USB→PC

のハードウェア(フツーの機材)においてデータの改変はないことが解ります。
 いわゆる「アイソクロナス転送における1ms単位のデータ欠損」も発生していないと言っていいのではないでしょうか。充分な検証になっているとは言えませんが、WAVコンペア一致したのですから。

 さて、普通の再生時は

PC→USB→DDC→S/PDIF(光)→DAC

ですから、DACへ届いているデータに改変はないと言えるハズです。


■振動によってデータ改変は発生しているか

 さらに追加実験。
 録音中に光ケーブルをぶんぶん揺らします。振動によって「データの改変」が発生して音が悪くなるなら、録音されたファイルもWAVコンペア一致しないハズです。

 …結果は見事に一致。


■データ改変は発生していない…のに音が変わるのは何故か

 上記より、USBケーブルやDDCが超ピュア用じゃなくても、かつ、S/PDIFケーブルが同軸じゃなくて光だろうがましてや安物だろうがバリバリ振動してようが、排他WASAPIでは「PCからDACまでの転送中にデータ改変は発生していない」んだよ実際と言っていいと思います。

 10/09/25追記:デジタルデータはいろんなフォーマットに変換されながら転送されていくワケですが、S/PDIF転送をよくよく考えてみれば、リアルタイム音声波形そのままじゃありませんから、0/1が頻繁に崩れるようだと「音質劣化」じゃなくて「通信エラー」になっちゃって、プチノイズや音切れになるはずです。クロック成分も含めた「バイフェーズエンコーディング」された状態でヘッダ情報とか付加され、ステレオの2chを時分割してシリアルに送ってるワケですから。音声情報部分だけがエラーしまくるワケがない。
 さらについでに、もしビットエラーが発生して全体的な音質を劣化させているなら、データ転送中に下位bitのみがパラパラとまんべんなくバケないと、例えば「全体的にくぐもった音」になったりはしないハズですが、ほとんどがシリアル転送であるDigital-Audio I/Fにおいてそれは考えにくいことです。

 しかし、排他WASAPIを使っても、事実PC-Audioは些細なことで音が変わります。例えばOSが32bitと64bitでも違ったり、制振によっても変わったりするように。
 が、その原因はDigitalDataの0/1が変化しているからではないのです。
 では何故? ポイントは「静的な結果」と「動的な過程」をよく切り分けて考えることかと思います。
 排他WASAPIやWDM/KSを使ったPC-Audioの仕組みでは、静的に言うならPC内のデータは正しくDACまで届けられているワケですから、あとは、その転送過程…USB信号やS/PDIF信号やI2S信号上の動的な

・時間軸上のジッタ
・振幅軸上の変動(信号レベルの変動・・・オーバーシュートなどの能動的電気的ノイズも含む概念として)
・信号及びグランドラインなどに乗る受動的電気的ノイズ

の変化が、最終的にはDAC(およびアナログ段)へ影響してアナログ出力の質を変える、と考えるしかない気がします。

 逆に言うと、PC-Audioの音質向上策はその観点で考えると効率がいいとも言えます。
 DACに直接影響する「振動」や「Player要因以外の電気的ノイズ」ももちろんありますので、それは再生装置の対策課題としてPlayer側の問題とは切り離して考えるようにするとよいと思います。
 詳述はここでは避けますが、だからウチではあえてS/PDIFは光を使って電気的にアイソレートし、電気的ノイズの影響がDACに及ばないようにしています(そもそも影響があるかどうかはまだ解っていませんが)。

 “音楽信号転送以外”のDigital-Audioの音質変化の要因としては、あくまで可能性としてですが、Player状況が変化したことでいわゆるグランドループやAC側へフィードバックが変化し、それがシステム全体に影響を与えている、という考え方もできますが…
 電磁波ノイズによる影響の変化、というのもありますが、流石にOSの設定を変えたことで発生する変化が影響しているとはちょっと考えにくい。

 本件に関する詳細はデジタルで音質が変わるワケの記事をどうぞ。


■録音環境追加:その1

・10/11/06追記:以下環境でもピットパーフェクト転送を確認しました。今回は、レコーダソフトとして≪RecPcmWin≫というフリーソフトを使わせていただきました。
 これによって、Play/RecともWASAPIで行えるようになりました。

・出力側環境
  ・PC・・・ONKYO HCD-1L Windows7 HomePremium 64bit
  ・Player・・・uLilith β3
  ・DDC・・・REX-Link2EX

・接続
  ・光デジタルケーブル・・・SONY POC-20A

・録音側環境
  ・PC・・・FUJITSU FMV MG70W Windows7 HomePremium 64bit
  ・Recorder・・RecPcmWin 1.01 64bit
   (13/01/14追記:1.04から24bit録音も可能に)
  ・DDC・・・SE-U55SX REX-Link2EXのOutputを光Inputに入力
  ・USBケーブル・・・ULTRAVIOLET5-2


■録音環境追加:その2

・11/02/20追記:Creative製「Sound Blaster Digital Music PremiumHD(長い!)」でも、SE-U55SXと同じく光S/PDIF入力でWASAPI録音できることを確認しました。上記構成のSE-U55SX部分を置き換えた環境です。光S/PDIFケーブルとUSBケーブルはめんどくさかったのとmini端子であることから違うものを使ってますが、もはや問題ではないでしょう。超高級品にしたワケでもないし。
 もちろんビットパーフェクトでした。
 RecPcmWinの録音デバイスとして「SPDIF入力(USB Sound Blaster HD)」を選択します。やや気むずかしいようで、環境によってはこれが出てこないこともあるようです。また、このデバイスは「DAC/ADC」としては44.1kHz系をサポートしません(48/96のみ)が、「DDC(USB←→S/PDIF双方向とも)」としては対応しています(44.1/48/96)。DACのクロックを48kHz系しか持っていないということでしょうか。音質へのこだわりから?
 一方、この環境で改めて、uLilithをDSに設定・ボリュームはすべて100%・共有モードの音質は44.1kHz/16bitであることを確認の上録音してみましたが、やっぱり一致しませんでした。



SB-DM-PHD:http://jp.creative.com/products/product.asp?category=1&subcategory=875&product=19829&nav=1&listby=usage

 12/12/24追記:Digital Audio Labolatoryさんの記事(*)によると、当機のDACはAKM製AK4396VF。24.576MHz(48kHzの512倍)のクロック発振器を搭載してるようですので、PLLかけずにマスタークロックにしてるっぽいですね(アナログでは44.1kHz非対応なことからも)。

*:http://av.watch.impress.co.jp/docs/series/dal/20100705_378787.html

 12/12/30追記:このデバイス、自分のS/PDIF出力を自分の入力で録音できるようです(内部ループバックではなく)。ひとつの環境でいろいろ実験できそうです。便利かも(笑)。
 13/01/20追記:自分のアナログ出力も自分で録音できます(内部ループバックではなく)。

 13/01/14追記:≪WaveSpectra 1.50≫でも排他WASAPI録音ができます。上記SoundBlasterのループバックでWAVコンペア一致を確認しました。


■排他WASAPIじゃないと何が起こっているのか

 本項13/01/24追記。

 以下、16bit/44.1kHzを1644、16bit/48kHzを1648、24bit/96kHzを2496と略称します。
 また、すべて、以下環境におけるデジタルダイレクト再生・録音(スペクトル表示)に関してです(アナログ(DAC/ADC)要素はありません)。

  録音再生PC:Windows7 HomePremium SP1 64bit 自作PC
  録音再生DDC:SoundBlaster DigitalMusic PremiumHD
  録音再生パス:S/PDIF外部ループバック

 もちろん各種エフェクトはDisableですしボリュームも100%、余計な入出力はカットしています。
 さらに、もちろんですが録音(スペクトル表示)側のAPIは常に排他WASAPIです。ので、録音プロセスはビットパーフェクトです。

 14/06/14追記:SB-DM-PHDですが、Windows8.1 update 64bitのINBOXドライバだと96kHzでのS/PDIF出力できないようです。Creative製ドライバ入れたら動きました。

・オーディオエンジンの「データ改変」実態:音が大きいとき
 前述の通り、S/PDIFのデジタルOUTをデジタルINで録音する実験において、「排他WASAPI」はビットパーフェクトですが「DirectSound(以下DS)」はそうではありませんでした。
 エフェクトをかけずミキシングもせずボリューム100%にしていても、「Windowsオーディオエンジン(XPまではカーネルミキサと呼ばれていた)」を通ることによって何らかのデータ改変が発生しているということです。
 改変されちゃうのですから、改変されたデータの改変内容を突き止めるのはまず無理であり、かつ「排他WASAPI使い」としては意味ないことなので放置していましたが、藤本健氏の記事(*)によって概要が解明されました。

*:http://av.watch.impress.co.jp/docs/series/dal/20121112_572414.html

 要約すると以下のようなことが起こっているようです。

 ピークリミッタに以下の問題がある。
  ・ノーエフェクトの単独音声再生の場合でも作動する(*)
  ・処理結果、無視できない波形改変を発生させている(ノイズと言っていいレベル)
  ・DSではなくMMEでボリューム99%以下に設定すると発生しない

*:加工やMixしてないので0dBを越えないハズ。17/05/26追記:アップサンプリングする場合はTruePeakによってピーク上昇する可能性はあるが、当該機能では対応しきれていないと推定。


 ほとんどバグと言っていい“仕様”ですね(苦笑)。

 なお、ミキサにはピークリミッタは当然必要ですので、「ピークリミッタがあること」が問題なのではありません。「リミッタ動作がヘン」ということです。

・オーディオエンジンの「データ改変」実態:音が小さいとき
 さて、そんなこんなでいろいろいじくっている中で≪WaveSpectra 1.50」≫でスペクトルを眺めていた時、オモシロイ現象に遭遇しました。
 Windows7(Vista)のオーディオエンジンでは、出力デバイスの仕様に基づいて出力サンプルレート(ビット深度も添えて)を選択できます。

サンプルレート選択

 ある目的で「すべて0000hのWAVファイル(1644)」つまり“無音データ”のスペクトルを見ていたのですが、DSやMMEの場合、プレーヤソフトでPlayすると-120dBくらいのホワイトノイズが発生します。Stopすると“測定限界以下”に消えます(iTunesではStopしても数秒間保持します。オーディオエンジンに対して再生状態を継続しているのでしょうか)。

1644のDSスペクトル

 録音してバイナリエディタでみてみると、0000hと0001hとFFFFhがランダムに出現していました。つまり、何らかの演算が入っておりその演算誤差で元は0なのに1や-1にバケてしまっているのでしょう。
 これではどんなファイルもデータ改変されて出力されるワケです。「サイン波:440Hz:-10dB」や普通の楽曲(最大音量-0.75dB)ファイルでも±1の差違が発生していました。
 もちろん排他WASAPI再生では当ノイズは発生しません(実際録音してファイル化してみても中身はオール0000h)。

 これによって、「ピークリミッタ」問題だけでなく、「常に余計なプロセスが入っていて、そこで演算誤差が発生する」問題もあることが解りました。
 影響度はさておき、「Windowsオーディオエンジンで音質劣化」と言っていいでしょう。

・2496だと異なる事情
 しかし、ふと2496モードに設定してみたところ、DSでもMMEでもノイズ波形が出現しません。ゼロがゼロのままということです。この場合、オーディオエンジン内で1644→2496リサンプリングが発生しているにも関わらずです(オールゼロなのでリサンプルしてもでオールゼロなのは筋が通ってますけど)。
 そこで思いついたことがありました。

「2496モードなら、オーディオエンジンを通してもビットパーフェクトが可能なのではないか?」

 これは試してみるっきゃない。

 この時気をつけなければならないのが上記「ピークリミッタ問題」です。これを発生させないようにするため、波形生成ソフト≪WaveGene 1.40≫で2496「440Hzサイン波:-10dB」のWAVファイルを生成してこれを用いました。
 このファイルをDSとMMEで再生、排他WASAPI録音してみたところ、見事にWAVコンペア一致するではないですか。

 続けて出力サンプルレート設定だけ1644や1648に変更して対応するフォーマットのファイルを再生録音してみたところ、やっぱり一致しません。

・ピークリミッタはどうか
 引き続き、2496モードにおける「ピークリミッタ問題」の有無も確認。
 2496「440Hzサイン波:0dB」を生成して再生録音してみたところ、一致しませんでした。
 録音したファイルを波形編集ソフト≪SoundEngine≫の「解析」で見てみると、最大音量が-0.28dBになっていました。再生したファイルはもちろん0dBと解析されます。
 つまり、「単独再生でもピークリミッタが効いて波形改変されてしまう」問題は健在(苦笑)なようです。
 ちなみに、上記を受けて「440Hzサイン波:-0.28dB」ファイルを生成して再生したところ、ビットパーフェクトを確認しました。

・オーディオエンジンを通ってもビットパーフェクト
 以上より、DSやMMEによるオーディオエンジン経由でも、2496モードかつピークリミッタ問題が発生しないファイルなら、ビットパーフェクトが可能であることが判明しました。

 1644や1648と2496で事情が異なる理由は解りませんが、XPの「カーネルミキサ」は48kHz固定だったという情報から、Vista以降の「オーディオエンジン」内の2496処理は新設されたものであり、1644や1648とはプログラムの出自が違うためかもしれません。
 …もしかしてVista以降は「すべての音源は2496にしてから内部処理」になってる可能性も?
 13/01/25追記:↑と最初書きましたが、そうではないようです。
 演算誤差は、44.1kHzでも24bit(2444モード)だと発生しませんが、逆に96kHzでも16bit(1696モード)だと発生します。
 つまり、おそらくサンプルレートには関係なく24bitの場合は発生しないのですね。
 オーディオエンジンを経由する場合、可能なら24bit設定で使った方がよさそうです。

 なお、≪WaveGene≫で「ホワイトノイズ:0dB」2444ファイルを生成してマーカを付けて再生録音、マーカに位置合わせして反転ミックスしたところ、残念ながら「最大-30dB程度のノイズ」が発生していることを確認しました。24bitでも「ピークリミッタがノイズを発生させる問題」は厳然と存在するようです。
 藤本氏の指摘通り、ノイズデータは実際に再生すると「チリチリ」とハッキリ聴こえます。
 ダメぢゃん。

・24bitならビットパーフェクトにできるプレーヤ
 上記24bit時のビットパーフェクトは以下で確認しました。
   ・≪foobar2000 1.1.15≫のDSモード
   ・≪uLilith(Core2 x64 12/03/07版)≫のDSモード
   ・≪WaveSpectra 1.50≫のMMEモード
 WMP(12.0.7601.175149)では何故か録音ファイルの「最後の16サンプル」だけ000000hになっちゃいました。なんだかバッファ制御関連のお茶目なバグっぽいですね。これを音質的に聴き分けられる人間はいないと思いますので、まあ、大きくみれば「ほぼビットパーフェクト」と言っていいでしょう。

 問題はiTunes。10.0.0も11.0.1もビットパーフェクトできません(全面的に異なるデータになる)。QuickTime(DSでもWASAPI共有でも)も同様です。これについてはiTunesは何をしてるのかを考察した記事に引き継ぎとしたいと思います。

・ディザってる?
 16bit時の差違は「ディザ処理」という話もあるようです。
 が、ERIとしては以下の理由で“MSの意図せぬ結果(演算誤差)”と考えた方がいいのではと思っています。

・そもそもディザは24bit→16bitなどの変換時、まるめ誤差によるノイズ感を隠蔽するため敢えてノイズを付加することのハズだが、変換してないのに付いてる。

・デジタルデータとしては±1の差違でスペクトルはホワイトノイズ型となるため、聴感上の差違(改善)になるとは思いにくい。
 foobar2000のディザ処理による差違はもっと大きく、ディザ有無の差分抽出したファイルは最大音量-60dBに達し(SoundEngineの「解析」による)、スペクトルはフラットではなく特に高域に盛り上がりを持つ(foobar2000のディザを確認した記事参照)。

・ディザ処理はそれなりにCPU能力を使うという。
 E-350環境を400MHzにアンダークロックし、foobar2000の1644ファイル再生(オーディオエンジンはもちろん1644モード)でタスクマネージャCPU負荷率を比べると、
   ・DS = 11%
   ・WASAPI(event)Dither Off = 13%
   ・WASAPI(event)Dither On = 17%
程度となる。アルゴリズムは異なるだろうが、オーディオエンジンでディザ処理しているとすると負荷が小さすぎるのではないか。

・多重ディザ処理は御法度らしい。
 プレーヤ側でかけることもあり得るのに、オーディオエンジン側で常にかけているとは考えがたい。

・ディザ処理は聴感上の音質向上を図るものである。
 ピークリミッタ問題を見逃す(放置する)程度に“音質に拘りのない”MSが、わざわざそんな「音質のためのプラスα」な機能を盛り込むとは思えない(爆)。


 なお、もちろん本項は上記環境における確認結果であり、環境が異なれば異なる可能性も否定はできません(といってDDCが影響するとも思えませんが)。

 さらに… 本項書いてから3日後、PlayPcmWinの作者であるyamamoto2002さんがすでに半年前「24bitなら改変なし」に関連する検証(*)されてらっしゃったのを発見したことを記録しておきます。

*:http://community.phileweb.com/mypage/entry/2721/20120826/32495/


■S/PDIFでExcelデータを転送する

 本項13/02/08追記。

 排他WASAPIなどのデータ改変しないAPIとfoobar2000などのデータ改変しないプレーヤで送出された音声データは、USBやS/PDIFを経由しても改変はありません(エラーしたら別ですが前述の検証通り普通はエラーしません)。
 つまり、音声データ転送も、再送機能こそありませんがれっきとしたデータ転送システムなのであり、であれば音声データでなくてもパーフェクトに送れるハズです。
 また、WAVフォーマットにおいてはヘッダ後の音声データ部分は純粋に0と1としてのみ扱われますので(例えば特定のパターンをエラーと見なすといった規定はない)、例えばExcelデータを埋め込んだWAVファイルでもビットは音声と見なされて改変なく転送されるということです。
 それはもちろんマトモな音にはなりませんが、S/PDIF経由でデジタル再生録音する分にはDACやスピーカを壊すこともありません。

 そこで、以下の実験を試みました。

・無音WAVデータファイルを準備(音声データ部分はオールゼロ)

・それより容量の小さなExcelファイルを準備(データの最後のパターンが判りやすいファイルがよい)

・バイナリエディタでExcelデータをすべてコピー、無音WAVファイルの音声データ先頭アドレスである2Ch以降に上書き貼り付け(サンプル単位に合わせた方がキモチはいいです。2Ch以降16bitステレオなら4Byte単位で先頭が来ます)

WAVフォーマットについては解説記事を書いていますのでよろしければどうぞ。

・ビットパーフェクト環境で再生・録音

・録音ファイルをバイナリエディタで開き、元Excelファイルの先頭と末尾に相当する部分を見つけ出し、前後をカットして保存
 Excelデータが音声として表示されたヘンテコ波形の前後を波形編集ソフトでギリギリまでカットしてからの方が、Excel部分は見つけ易いでしょう(ただし波形編集ソフトによってはカット以外の処理をかけてしまいますので注意が必要です)

・ファイル拡張子を「.xls」に変更

 …見事にExcelファイルとして開けました。

 特に意味はありませんが、「ああ、確かにこの環境はビットパーフェクトなんだなぁ」という実感はできますよ(笑)。


メインメニューへ

テーマ : オーディオ
ジャンル : 趣味・実用

最新記事
ERIへようこそ

Author:らかせ
「最新記事」または
「メインメニュー」からどうぞ

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です

・一応、拍手にコメント(非公開)付けられるようにしてあります

・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください

・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください

・引用の考え方については「007:諸事」をご参照ください

・アフィリエイトはAmazonのみです

・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

カテゴリ
検索フォーム
FC2カウンター