デジタル・キャプチャーによる音の相違

 ネットワークオーディオには、CDからキャプチャーしたデジタルのデータが必須ですが、何れRoonとの契約を終えた時点で、CDの購入とキャプチャーには終止符をうつことになります。Roonのローカル音楽DBも出来たら高音質で格納したいので、CDからの音源キャプチャーについて考察してみました。

CDドライブにより音が異なる
 リアルタイムにCDプレーヤーとパソコンに搭載されているCDドライブで、同じCDを再生した場合、音質が異なることは、あたりまえのことで、今更、音質の差が有る事を否定しません。CDを再生する場合、リアルタイムに再生した場合、デジタル情報の波形に対するノイズの影響は、大いに有ると思います。

デジタル・キャプチャーによる音の相違
 異なるCDドライブから、シリアルATA、IDE 経由で、同一パソコンのハードディスクに格納して、違うタイミングで、同一再生環境で聞いた場合、音質の差が生ずるのか否か、を調べてみました。今回は、キャプチャーの翌日に再生を行いました。

比較の方法
 キャプチャーのソフトは、最新のdBPoweramp V16.4(64bit版)を用い、取り込む度に、読み取りレンズの光軸オフセット(アライメント)の調整を行い、アキュレートリップで、6倍速で行いました。そして、そのドライブの個性(癖)を強調するために、キャプチャーしたデジタルデータを、再度、CD-Rに書き込んで、そのCD-Rを再びキャプチャーすること、10回繰り返して、最終のデジタルデータを試聴(比較)に用いる事としました。
 音質の比較を行う前に、Windowsのユーティリティー・ソフト「バイナリ比較 Bn_Cmp」を用い、WAVファイルのヘッダーとトレーラを除きバイナリーで比較を行い、相違がない事を確認した上で、試聴を行いました。

テストドライブは2種類
 なるべく、異なったドライブを用いて、音質差をデフォルメ出来る環境するために、SATAのドライブとDVDライターの黎明期に発売された、由緒正しいIDEインターフェースの日本製ドライブを用いて比較しました。

1.Pioneer DVR-A03
  2001年9月17日 国内製造 IDEインターフェース
  当時の実勢価格 9万円
DSC05542.jpg

今では考えられない程、製造に手間の掛かったDVDのドライブです。
DSC05531.jpg

DSC05538.jpg

2.Panasonic UJ240 2010年2月
  パナソニック システム ネットワークス 福岡県博多製造
  当時の実勢価格 3万円
DSC05544.jpg

DSC05539.jpg

バイナリーでの比較
 WAVは、IBMとマイクロソフトにより決められた、RIFF waveform Audio Formatの一部で、ヘッダー部分には作製された日付、サンプルレート等の制御情報のチャンク(Chunk)と音楽データボディーのチャンクがあるので、単純に比較すると一致しません。そこで、ユーティリティー・ソフトで、比較する場所の開始点をチャンク2の音楽データボディーから行うことにしました。

RIFF waveform Audio Format(WAV)のレイアウト
XWAV.jpg

バイナリーレベルでの比較結果
 どのドライブでも、正常にキャプチャーされた場合は、どのデータも全く同一(Exactry match)で、俗に言う「ビットパーフェクト」です。

肝心な音の比較
 オリジナルのCDからキャプチャーしたWAVと、10回キャプチャーCD焼き込みを繰り返したWAVと聴き比べてみました。結果は、世のため人のため内緒にしておきます。

ドライブにより音が変化するとしたら・・
 変化が生じるとしたら、WAVのヘッダー(チャンク1)にある、パラメータ、アーギュメント等が、何らかの事象により変更された場合は、音質面で変わることは充分にあると思います。例えば、WAVでも擬似タグの設定が可能ですが、標準化出来てないWAVのタグの設定方により、再生が出来ない、WAVプレーヤーとSDメモリメモリープレーヤーが存在します。その様なソフトとプレーヤーは、WAVのタグを正しく処理しないで、誤判断したアーギュメントで誤動作しながら、再生している恐れがあります。有名な再生ソフトで、途中からデジタルノイズとなる音源が有り、foobar2000でファイルコンバージョンを行うと正しく再生されるソフトがあります。そのようなソフトで比較しても、正しい結果は得らません。WAV同士を比較す場合、タグの初期化が必須と言えます。

結論
 来るべきRoonの時代に、「キャプチャーに用いるドライブにより音が異なる」・・・これは、触れないことにします。

Windows10からWindows Server2012に戻す

Windows10からWindows Server2012に戻すことにする

 先日、PCオーディオに用いているパソコンのプラットフォームをWindows7からWindows10 Version1067に更新したが、不満が山積し始めている。元のWindows7をSSDのドライブごと、動態保存してあるので、ものの数分で戻せるので、最終的な戻し方として、Windows Server2012にするかは、後々のたのしみとして、Windows10 Version1067を虐めて、もう少し問題点を炙り出すこととしました。

最適なプラットフォーム
 PCオーディオに最適なプラットフォームは、サウンドドライバーとしASIOしか使わないので、最近のWindowsUpdateと全く無関係のWindows NT4.0をベースとして、装置に組み込む前提とした、Windows Embeddedが理想です。しかし、入手性が悪く、高額です。そして、動画、ゲームソフト機能を除いた、全ての要件を満たして完成系のWindowsXPを今更持ち出すのも如何なものかと思います。そして、次の選択として、OSの規模がコンパクトで、慣れ親しんだ、Windows7 Proの最終バージョンか、機能限定のWindows Server2012にするのが良さそうです。開発の終了は、良くも悪くも「余計なことをしない」、「かまわない」、ということで、スタビリティーは高いといえます。

Windows10 Version1067の問題点
 Windows10は、マイクロソフトの最後のOSとアナウンスされていました、リリースされた当初は、快適な速度で、好感触でしたが、しかし、名前だけWindows10として変わらず、実際には、拒否できないWindows Updateの自動更新で、すっかり入れ替わっています。そして、当初の快適さから、不要な機能の追加により鈍重なOSに成り代わっています。

不明なサービスの増加 
 以下のすべてのサービスがアクティベートされている訳ではないものの、Xbox関連、タイムゾーンの自動更新など、Windowsサーフェース(タブレット)、ゲーム等、使用しない機能が山積している。なにか怪しげな日本語のサービス等、何時から追加されたのでしょう。
ServiceOS.jpg

処理が重い、遅い
 WindowsXP以前に頻発した、カタストロフィックな異常停止はないものの、処理が遅く、ファイルの移動、ログオンに要する時間等が、Windows7から170%増に遅くなっている。

致命的な障害
 リモート デスクトップ接続で、Windows キーが押されたままになる事象が生じており、マイクロソフトから、以下の様にガイダンスが出ているが、基本的に解決してない。これは、リモート側PCのWindows キーが押せない状況で、プログラムの開始指示ができない致命的な障害がある。又、iPadから、マイクロソフト純正のリモート デスクトップ・アプリでも同様の障害があり、これも、解決していない。

以下、Microsoft Technet
https://blogs.technet.microsoft.com/askcorejp/2017/07/24/winkey-keep-pressed/

 Windows10というドン・キホーテが、インテルx86-64というチップにまたがり、パソコンのバックログを解決に奮闘する、しかし最後は・・・

Windows7からWindows10(Version1067)に更新

 PCオーディオ用のサーバーを、Windows7 からWindows10 (Version1067)に更新しました。用途としてミュージックDBとレンダラーなので、頻繁に操作することがないので、暫くの間Windows7で様子見をしていました。しかしWindows7の保守期間が残すと2カ年となつて、充分に熟れているので、マイクロソフトの無償対応の気が変わらない内にWindows 10の最新版を導入することにしました。
 新機能を調べると、不評のウインドウズサーフェス端末に関する機能が、充実していますが、この機能は使わないので、関連する機能と併せて、ゲーム、ショップ、企業向けエンタープライズ・サービスを停止しました。特に問題なく小気味よく動作しています。ソフトは、充分に枯れており、全く問題無く、30分程でアップグレードが完了しました。

海外にあるWindows10へのアップグレードサイト
2018年4月現在でも更新可能です。
https://www.microsoft.com/en-us/accessibility/windows10upgrade
7210Up.jpg

Windows10(Version1067)の音質
 Windows10リリース当初の2年前は、不安定さに加えて、ASIO対応のモジュールにバグが有って、中高音に癖があり採用を見送りましたが、最新のモジュール(Version1067)では、バグフィックスして、Windows7と遜色ない状態までに仕上がっています。

Windows10(Version1067)の動作
 Windows7に比べると、プラットフォームのフェッチ速度が見かけ上早くなっていますが、画面の表示、データの移動は、確実に遅くなっています。Windows10は、山積したバックログのプログラム・テンポラリーフィックスをプログラムソースレベルに反映して、タブレット端末用のブリッジ機能を加えて、Appearanceを変えただけで、基本的なカーネル部分を未着手とした消極的な改善です。設定画面のハイアラキー細部に至ると、Windows7のレガシーな画面と同一です。スクラップアンドビルドでないため、安定動作していて、結果は良かったと思います。マイクロソフト社は、ポストWindowsを作る度胸は無さそうです。

音源データのバックアップ
 総てのデジタルデータのバックアップに言えることですが、バックアップは、一台のバックアップメディアで行わず、必ず複数のバックアップ・メディアを用いて、交互々にキャプチャーします。この方法を、フリップフロップ・ファッションのバックアップと言います。これは、バックアップ実施中にハードのトラブルに遭遇した時に、一世代前に、戻れる事を保証する方法です。

USBからIEEE1394への再チャレンジ

 USBのノイズ対策として投入したUSBのアイソレータであるINTONAの二次側バスパワー(5V)の品質が、好ましくない事が、導入当初から気になっていて、昨日、改めて計測してみました。供給する電圧が、USBのコンソーシアムで定義されているDC5Vより低くDC4.65Vで、電圧が不足気味です。又、最大の問題は、その電源を分離型DC-DCコンバータで生成している為に、ノイズ成分が160mVもあります、又、供給電力も500mAの供給が潤沢に出来ない為に、INTONAのバスパワー使用を控えていました。

対策
 そこで、クリーンなDC5Vを別途用意して、バスパワーとしてFireface側のUSB-typeBの直前で、供給することにしました。当初は電池で供給を考えましたが、使用時間に伴う電圧降下等を考えると、落ち着かないので、AC100Vからトランスを用いて、レギュレーターは、TIのTPS7A4700を用いて、150mAの電源を作成して、リニアー電源で供給することにしました。

DC5V、低ノイズ電源
DSC05352.jpg

USBからバスパワ不要なIEEE1394へ
 USBを使うと、バスパワーDC5Vの品質、ノイズが云々等と、一寸食傷気味な事と、一年ほど前に、USB2.0とIEEE1394a(FireWire 400)との音の違いを正当に評価可能な環境で聴き比べて、圧倒的にIEEE1394aの方が優れていることを体験したので、USBからIEEE1394への更新を進めることにしました。 FireWireは音楽データ等を限られた時間内に転送専門のチップを用いて、確実転送するように設計されており帯域をフルに使えます。USBは他のキーボード等の機器から割り込みを考慮しているので、CPUの処理に依存しており、帯域に余裕を残すよう動作しています。したがって、USBの方がCPUのユーティライゼションが高くなり、ノイジーとなります。

Kalea Informatique IEEE1394a(Firewire400)のカードで、OSコンを用いて、水晶発振子ではなくCMOS発振器(裏面)を用いています。
DSC05350.jpg

冷静に判断
 今回、バスパワーのクリーンな電源を作成して、動作確認を終了したところで、USBの接続携帯(下図:上)を眺めて、「屋下に屋を架す」状態で有ることに気が付き、この方法を改める事にしました。やはりFirewire400(下図:下)によるシンプルな接続の方が良さそうです。

Buspower.jpg

DACとワードクロックの関係

 昨年、ノイズ対策中にネットワーク・オーディオの要であるDACを交換しました。従前のRME Fireface UCから、同社のUCXに交換(アップグレード)したのですが、その時には、気づかなかった事として、内部のSteady Clockと外部のワードクロックで、音質の差が、かなり有ることに気が付きました。ノイズ対策を行う前は、その差は僅かでしたが、ノイズ対策によりクロックの確度の差が、顕著に音質面に現れてきました。

RME Fireface UCX
フロントパネルWCが点灯して、ワードクロックの供給とロックを表します。
W_CLOCK.jpg

クロックの見なし
 デジタル音源の要であるクロックを、以下のフローの様にコンディショナル・リサンプリングを行います。
W_Clk.jpg
 基本的には、CD音源が大半なので、ルビジウムのワードクロックを176.4kHz(4逓倍)に統一します。CDの場合は、44.1kHzから2逓倍の88.2kHzとして、88.2kHz、176.4kHzのSACD系は、リサンプリングせずにそのまま再生します。48kHz,96kHz、192kHzは、176.4kHzにリサンプリングする仕組みです。あいにく48kHz系のダウンロードして購入したハイレゾ音源が不利になりますが、正直、ハイレゾの殆どが、高音質でありながら、良い演奏が少ないので、CD系を優先しています。48kHz系に傾注して聞く場合は、ルビジウムのワードクロックを192kHz(4逓倍)に切り替えて、音源はリサンプリングしないで、再生します。

クロックの違いによる音の差
 DAC内部のSteadyClockをベースに再生すると、言葉で表現が難しいですが、簡単に言うと、「つまらない音」です。それと較べて、クロックをルビジウムのワードクロックにすると、不思議な事に音場感が豊かで、艶やかになります。特に前後関係の音場感が豊かになり聴いていて、とても楽しいです。何故、このように為るか不思議ですが、ノイズ対策前は、この様な現象をそれ程に感じませんでした。一時、ルビジウム・クロックの使用中止を考えましたが、残して置いて良かったと思いました。

ワードクロックと内部クロック
 RMEのサイトでは、SteadyClock(ステディークロック)の優位性を図柄入で力説しています。確かに他の業務用DACに較べて優れています。それでもルビジウム・クロックの方が優れているのか不明です。
 分周により得られるワードクロックと内部クロックでは、かなりのハンディーがあって、用途が異なります。クロックの電源品質、クロックの立ち上がり波形、中心周波数近傍のスプリアス等、ディープな部分でよく解りません。取り敢えず音が良かったので、現時点では結果良しとします。

SteadyClock™
https://synthax.jp/steadyclock.html