abk1's scratched blog 3

以前のエントリーの終段で、USB ターミネーター兼ノイズフィルターがアップサンプリングサーバーの負荷に伴うノイズの軽減に有効だったと書いた。
初歩的なことで、灯台下暗しだ。
USB ターミネーターを付けた状態で、以前につないでいたスイッチングハブに戻してみたが、以前ほどの精彩を欠く音までには至らないものの、やはり音の速度が下がり音色の鮮度が落ちる。
現状では、カスケード経由の配置のほうが良いということだろう。

さて、そういうことならということで、NAS と Daphileサーバーを、PCトランスポートから離れるように、配置を変えてみた。
アップサンプリングサーバー程ではないかもしれないが、どちらかといえば重いサーバーだ。
PCトランスポートから離す方が良いかもしれない。
これらをつないでいるスイッチングハブ（Buffalo LSW4-GT-8NS）を、ONU を超えて、違う枝に移す。
その流れで、ONU、OPT ISO BOX、Buffalo、GS105E（+ 44.1 mpd サーバー）の連結を、ONU、GS105E（+ 44.1 mpd サーバー）、OPT ISO BOX に変更。

配置変更で、音は変化している。最近、若干気になっていた音の鋭さ、主張が強すぎる感じが解れた。
ただ、本当に良くなっているのかどうかは安易な評価が難しい。
数日聴くうちに、どうも今度は、主張が弱すぎるような気がしてきた。

Buffalo を、GS105E に持ってくる。ONU、GS105E（+ 44.1 mpd サーバー、Buffalo）、OPT ISO BOX という配置。
音は、いい感じ、なのかな。
正直この操作に、ネットワークオーディオ的にどのような意味があるのか、よくわからないのだけど。
サーバーやスイッチングハブが多いと、どうつなぐかでコロコロ音が変わる。
なので、本当は数を減らしてシンプルにしたほうが評価や調整がしやすいだろうと思う。

ちなみに、384 と 44.1。
スケールは 384の方が大きくて余裕があるけど、44.1 のほうがストレートな感じがする。
優劣は、簡単には付け難いが、44.1 のほうが、総合的には勝っている気がする。
384 の音の弱さは、ネットワークとサーバーの弱点に依るものだと思っていて、音源自体が 44.1 より劣っているというわけではないと思う。そこが悩ましいところで、まだ 384 を切り捨てられない理由なのかな。

アップサンプリングサーバーに USB ターミネーターのような対策が効くということは、サーバー自体について検討する余地があるということだ。
実際、うちのアップサンプリングサーバーは、利便性とか置き場の問題とかを優先した結果、ノートPCで運用している。44.1 の mpd サーバーはノートとはいえ筐体中にノイズ対策を施すなどしているが、アップサンプリングサーバーのほうは hp Probook 450 G9 で比較的新しい分、筐体内は部品がきっちり詰め込まれ余裕がなく、全く手を入れていない。
そういうことなので、サーバーを検討する余地が、もとからあるのはあるのである。

しかし、サーバー自体を検討する前に、ちょっと思い付いたことがあった。
もともとアップサンプリングサーバーがあった場所に、PPAP middle-end を追加したら、384 の音はどうなるか、というアイデアだ。
つまり、middle-end を２台にする。
追加された middle-end を経由することで、デジタル信号の打ち直し、ジッター軽減ができないだろうか。
どうなるかは、やってみないとわからない。

middle-end 用のサーバーをすぐに用意できないので、44.1 用の mpdサーバーを試験的に転用する。
sshで 820 G2 にログインし、下記コマンドを打ち middle-end 化する。
データの転送先は、もとからある middle-end だ。
/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/ncat 192.168.1.33 4400" &

Probook 450 G9 の .mpdconf を編集し、PPAP のデータ転送先を 44.1 の mpd サーバー（hp Elitebook 820 G2）に変更する。

820 G2 は 44.1 を PPAP伝送するために、LANの伝蔵速度を 100Base-T に絞っているのだけど、今回は 384 を伝送するので、1000Base-T に変更する。スイッチングハブ（GS105E）で設定しているので、設定変更する。

これで、middle-end ２つで、384 の音が出る。
LANはこんな感じの経路（6月30日、描きもらしていたbuffaloのハブを追加した）。

音は、かなり、いい感じだ。
弱いと感じていた部分が、すっかり払拭されている。いや、すごく、生々しい。正直、、、文句のつけようがない。

面白いことに、デジタルボリュームの違和感が、ほとんど感じられなくなった。
ということは、たぶん、サーバーの負荷に伴うジッターの影響が、かなり少なくなっているのではないかと考えられる。
デジタルボリューム使用による音の違和感は、サーバーへの負荷によるものだと考えていいのではないか。データ変換に伴う音声データの欠損とか、そういうことが理由ではないということだ。

GS105E で VLAN を設定できる。設定したら、更にじわっと、一皮むける。
こうなってきたら、十分に使う意味はある。

この状況で、44.1 と 384 を比較すると、384 が 44.1 を引き離した。
44.1 だけ聴いたら、これで十分だと感じるのだけど、384 のほうが写実性が高い。硬さ、柔らかさ、軽さ、重さ、そうした音色の特性が、音場空間上にバランスよく描き分けられる。まったくもって、贅沢だと思う。

384 の音はすごくいいのだけど、この設定で困るのは、44.1 を PPAP で鳴らせないということだ。
いや、GS105E で 820 G2 の設定を 100Base-T に戻せば出来るのだけど、いちいち変更するのは手間ではある。
まあ、でも、仕方ないかな、、、

取り急ぎ、今日のところはここまで。考えないといけないことが多い。

前回は、アップサンプリングサーバーの負荷に伴うジッターを減らすべく、カスケード接続したハブを経由してデジタル音声データを通すということを試み、概ね上手くいったように思われる。
聴感上の音質は、かなり改善している。

しかし、音像定位は良好とはいえない。正確な再生とは言えないと思う。
複数のスイッチングハブを経由するせいで、スイッチングハブ由来のジッターが影響しているのが原因だと考えている。

そして、そういうジッターの影響かどうか分からないけど、音のスピードは未だ僅かに、44.1 に届かない。
しかし音の階調、グラデーションは、384 へのアップサンプリングの方が優れている。
総合的にどちらが優れているかは、決めにくい。
現状、ほんとうに一長一短だ。

最近、スイッチングハブのカスケード（多段）接続について、議論があるようだ。
今年3月の Stereo Sound Online の記事がある（僕自身はこの記事、ちょっとやりすぎじゃないのかと思った）。
https://online.stereosound.co.jp/_ct/17826033
一方で最近、TOP WINGの菅沼社長が、スイッチのカスケードには意味がないと話されたらしい。
そして僕自身が、アップサンプリングサーバーをカスケード経由にすることで、音質改善の対処をしている。
そんなわけで、僕なりの考えを書いておこうかと思った。

スイッチのカスケードには意味がないと。僕は、それも一つの見識だと思った。
ハブ自体、ノイズや電源の対策を要する器械だ。
それを多数使うことはノイズ源、ジッター源を増やすことでもある。その対策には対価を要する。
つまり、ハブをカスケードすることは、かえってLAN環境を悪化させる可能性を抱えた両刃の剣だ。

TOP WINGは、良質なクロックを積む等、ジッター対策を重視したハブを売り出している。少数精鋭の機械によるネットワーク構成でLAN環境を改善することをコンセプトにした製品を販売しているように思う。極力、ノイズ源を増やさないということだ。
そのコンセプトに、ハブのカスケードは反するように思う。

さて、反対に、スイッチングハブのカスケードが有益な状況はどうなのか。

今回のうちの事例を考える。
音楽サーバーへの負荷に伴うジッターが多い場合。
音声信号にそのジッターが作用し、音質に影響する。
こうした場合は、複数のハブを経由することで、サーバー由来のジッターが剝ぎ取られるのではないか。

但し、カスケード接続される複数のハブに、電源やノイズの対策が充分になされていることが前提になる。
カスケード接続は、サーバー由来のジッターが減る代わりに、ハブ固有のジッターが重積する。再生音にハブのジッターの音が乗るのは避けられない。その影響が大きいか小さいかということだ。
ハブ周りの特性が水準を満たしていないと、改善にはつながらないだろう。
同じ製品でカスケードしたら同じ性質のジッターが重積するので、影響が大きい可能性があるだろう。

過去には、ハブのカスケードによる音質改善がずいぶん言われた。
僕の記憶では、当時は音楽のサーバーは古くて小さく非力な方がノイズが少なく音がいいと言われていた気がする。音源データを蓄える NAS も、今より非力な機械が多かったのではないか。
非力な機械によるデータ処理は、ジッターが増加する。
つまり、サーバー由来のジッターが音声信号に蓄積するような状況が、昔は多かったのではないかと推測する。そのような理由で、スイッチングハブをカスケードするのが有効なジッター対策になるケースが多かったのではないだろうか。

サーバー由来のジッターが問題になる以外の状況で、カスケードが有効な場合はあるか。
考えてみたけど、思いつかない。
そして、サーバー由来のジッターには、電源やノイズの対策、負荷低減などサーバーへの対策を行うほうが正攻法で、将来性につながる改善が得られると思う。うちの場合は、それが限界と思われたので、カスケード接続に望みを託した面がある。

他の対策は、、、思いつかない。
根本的な解決に向けて、なにかいい手があれば良いんだけど。
カスケードは、だめとは言わないけど、反面失うものもそれなりにあると思う。
面白いことに、アップサンプリングは mpdのデジタルボリュームによる音量変更に違和感がなくなった。なんというか、良いことか悪いことか判らない。

改善策になにかないかというので、自作の USB ターミネーター兼ノイズフィルターをアップサンプリングサーバーに2本挿してみた。効けばめっけもんである。
これが、なんだか効いてるみたい。音が速くなった気がする。
デジタルボリュームの違和感は、そんなに強くないが戻ってきた。良いことか悪いことか判らない。

ヘンデルの携帯電話は、少し、手前に移動したかな。あんまり変わらない。
思い付いて WiiM Mini で鳴らしてみたけど、あんまり位置は変わらない。案外、こっちが正しいのかな。
44.1 との比較では、それでもやはり、どちらが上というのは決めにくい。其々に美点があって、難しい。

しかし、これで余剰の USB ターミネーターが無くなった。
必要になったら作らないといけない。

OPT ISO BOX は、ほんとうはどこに置くのが良いのか、あれこれ動かしてみるんだけど、判断しにくい。
ノイズが減るのを期待して LNX-007L とのカスケード配置も試みたんだけど、うちでは伝送がうまくいかないのか音が途切れることがあったので止めている。
音像定位や音質の評価は難しい。
最後には根負けして、耳あたりと好みだけで置き場所を決めることにして、今は ONU 直下に配置している。
どうなのか、しばらく様子を見る。

最近、そんなかんじでデジタルノイズの対策をしていて分かったのは、ジッター環境が改善すると、44.1 やハイレゾが良くなるのに対して、負荷が大きいアップサンプリングは精彩を欠く感じになっていくということだ。音源の性質によって、聴こえ方の変化に違いがある。
簡単な表にしてみる。

音源	ジッターが少ない多い環境	ジッターが多い少ない環境
44.1	本来の音楽情報を引き出す再生ができない。音質不十分。精彩が無いくすんだつまらない音。	本来の音楽再生に近付く。ジッター減に伴い大きく改善し、音楽の躍動感がある良好な音質が得られるようになる。
ハイレゾ（384）	本来の音質を引き出す再生はできないが、比較的、音質は良好。やや大人しく聴こえることが多いか。	かなり本来の音楽再生に近付き、極めて良好な音質で再生される。44.1よりも情報量が多く、聴きごたえがある。
SRC : fastest 〜 best（良質なアップサンプリング）	比較的、音質は良好。ハイレゾ再生との比較では極めて近い音質。	ジッターが減っても改善が少ない。比較的良好な音質に留まる。しかしアップサンプリングサーバーの設定調整によってサーバーの負担を減らせたら、ある程度は改善が見込める。
SRC : ZOH（低品質なアップサンプリング）	音質は不良。しかし、非常にジッターが多い劣悪な環境の場合は、44.1 よりは良い音質が得られることがある。	ジッター減に伴い大きく改善し使用可能な音質になる。ハイレゾにも極めて近い再生音に聴こえるが、情報量はやや少なく若干硬めに聴こえる。

こんなものか。
音源にもよるだろうが、アップサンプリングは ZOH よりは best の設定のほうが使い甲斐があるような気がする。音楽的な訴求性が高いのだ。しかしそこを言うなら、アップサンプリングしない音源のほうが良い。そういう弱点がある。

それにしても、どうなんかなあ、、、うちでは、アップサンプリングは役割を終えたのかなあ。

アップサンプリング音源の音が改善できないというのは大きい。
44.1 は良くなったんだけど、もっと分解能が欲しい。

うちのシステムでは、それはハイレゾレベルの音声データからでないと得られないと思う。高額で高性能なDAC、クロックや、贅を尽くしたネットワークを使えば、44.1からハイレゾの音が聴けるのかもしれない（世間には、そういった対策をすれば44.1で充分、と言われる人もおられる）。
しかし、うちは基本的にはそこまでお金は出せないのだ。
僕は、44.1 をハイレゾレベルの音で聴きたい。だから良質なアップサンプリングを選択していたのだ。
なにか、手はないかなあ。

そうこう考えるうちに、昔はアップサンプリングサーバーを、PCトランスポートから離れた場所に置いていたことを思い出した。
意図してのことではなく、当時は他に置く場所がなかったからだ。

例えばストリーミング音源は、あちこちの中継サーバーを経由してうちに届くからといって、音が劣化するわけではない。
そうしたことが即、音声データのジッターの増加につながるというわけではないのだ。
アップサンプリングサーバーの負担によってデータに積み重ねられたジッターなら、アップサンプリングサーバーから遠路遥々あちこち経由することで、むしろジッターを減らすことが出来るかもしれない。

ものは試し。
アップサンプリングサーバーを移動した。リビングの家庭内LAN WiFi の AP（AtermWG1800HP3）に。
ここがうちの中で一番、PCトランスポートから遠い。

音は、良くなった。
音のスピードが、生命力が、戻ってきた。

起死回生である。
デジタルって、そういうものなんでしょうか。
しかし、本当に良くなってるんだろうなあ？、錯覚だったりしないよね？ むしろ逆に変なジッターが乗った音が妙に良く聴こえている可能性も否定できない。注意してみていく必要がある。
ともあれ、セッティング場所を工面しないといけない。昔、置いていた場所に置けば良いのか？、でも、あんまりきれいじゃないんだよね、、、

その後、もう少し調整。
AP の１つ手前のスイッチングハブにアップサンプリングサーバーを移動。こっちの方が若干良い。

あと、設置場所のセッティングやコンセントの環境が良いから音が良いのかもしれないので、LANケーブルを伸ばしてもとのスイッチングハブにつないでみたけど、そうするとやはり精彩を欠くので、信号があちこち経由することでアップサンプリングサーバー由来のジッターが減少したことが改善の理由、と判断して良いのではないか。
長いケーブルのせいで音が悪化している可能性、それは検証してないけど、短くして試すわけにもいかない。それに長さを言うなら壁の中を走ってリビングのLANポートにつながるケーブルのほうが余程長い。

アップサンプリングサーバーを移動させるなら、384 については、GS105Ev2 を使った VLAN によるネットワーク分離を諦めないといけない。
背に腹は代えられないのか。44.1 の再生時にだけ使用するというのはありかもしれない。
44.1のmpdサーバーを Middle-End化して 384 のデータ伝送を中継させる設定も試してみたが、100base-t での伝送になるので音が途切れる。
やはり、PPAPで 384 以上を伝送するには、1000base-t が必要なのだろう。

さて、Tilgnerの小鳥は正中にいるが、ヘンデルの携帯電話はステージ寄りにいる。
聴こえは良くても、あんまり正確な気がしない。
これは、たぶん、うちのネットワークの癖なんだと思う。
以前、LANアイソレータ（LNX-007L）の配置を変えるだけで、定位が変わるというのを経験している。原因が何かは分からない。器械によるジッターというのは、100% 無くすことは出来ない。原因を特定するのも難しいし、限界があるのである程度は割り切ろうと思う。
それにしてもヘンデルの携帯電話、やけに明瞭に聴こえるんだけど。
ここまで明瞭だったら、たぶん誰でも簡単に気付くと思う。こんなのは今まで聴いたことがない。
そういえば、小鳥や鴉も明瞭かも、、、

上記の表の、SRC : fastest 〜 best の項目を書き直しておこう。

音源	ジッターが多い環境	ジッターが少ない環境
SRC : fastest 〜 best（良質なアップサンプリング）	比較的、音質は良好。ハイレゾ再生との比較では極めて近い音質。	オーディオ環境全体のジッターが減るに連れて改善はするものの、アップサンプリングサーバーへの負荷に伴うジッターの影響が顕在化し、改善が頭打ちとなる。しかしアップサンプリングサーバーの設定調整による負荷低減やデータ伝送過程の工夫等によって、サーバー由来のジッターの影響を減らせるようであれば、相当の改善が見込める。

しかし、こうなってくると、NAS や Daphileサーバーの場所はそのままでいいのか？ということになる。
だからといって、すぐにどうこうしようという気にはなれないけど。

ばらばらに設置していたオーディオ関係の機器を、あれこれ苦労してまとめた苦労は何だったのだろうか。いや、いろんな知見が得られた。そのための苦労だったのだから、むしろ、もとは十分に採っている筈だ。

先立って、対策前の音について簡単に書いておく。
44.1 はジッターの影響を受けやすい分、最近のノイズや電源への対策に鋭敏に反応して、大きく音質改善している。
384 へのアップサンプリングは、比べたらそこまで大きな改善はない。
両者を比較したら、384 のほうが音の粒が細かく情報量は多く階調も深い。しかし音のスピードは遅く感じる。44.1 と比べると滲んでいるように、霞を被っているように聴こえる。それが音楽を掴みにくくしている。44.1 と比較すると訴求性が低い。

これは、アップサンプリングに伴うジッターの影響だと考えた。
アップサンプリングを行うことは、サーバー自体への負荷になる。これに伴うジッターが影響し、良質なアップサンプリングを行っても音質への恩恵が得られなくなっているのではないか。

昔からアップサンプリングに伴いサーバーに負荷がかかることは指摘されていた。
しかし「サーバーへの負荷」が音質に影響するのを、僕自身が聴き取った（と感じた）のは初めてのことだ。
サーバーへの負荷が問題になるのは、音質への影響以前に音が途切れるとか、まともに再生ができなくなるようなことが多かったと思う。

アップサンプリングに関連しての音質変化については、むしろサンプルレート変換ライブラリに何を選び、どう使うかということのほうが、大きいという認識だった。
うちで libsamplerate (secret rabbit code) を使うのは、サーバーへの負荷が大きくても、他のライブラリより音質の優位性があったからだ。その設定も、fastest から medium、best と変更し、それに伴いサーバーの調整もしてきている。
libsamplerate でも多少は音の感触は変わるが、音質上、それでも使うメリットがあると判断し使っていた。

それが今回は、初めて音質のデメリットの問題になった。
それで、まあ、どうしようかということだ。

アップサンプリングの音は、できれば改善したい。44.1 が改善しているとはいえ、情報量はハイレゾやアップサンプリングに比較すると足りない。
ノイズ対策や電源強化は、おそらくサーバー負荷に伴うジッターの悪影響を際立たせるだけだと思う。
サーバーの負荷を減らし、ジッター自体を減らすしか無いと思う。

真っ先に思い付いたのは、アップサンプリングの設定を変えることだ。
現在の設定は、libsamplerate / best の設定。
これを、fastest に変えたらどうか。負荷は下がるはずだ。
実際、設定を変えながら top を打って、CPU使用率を比較してみたら、負荷は1/10近くまで下がっているようだ。

音を聴いてみたら、問題はある程度、解決するようだ。
best のときに感じていた、どこか曇るような感触がなくなった。こうなると、44.1 と比べても音の細やかさや情報量では優位性がある。

もしかして、medium の設定でもいけるかも？と思ってやってみたら、悪くない。
top で読める CPU への負荷は、best のときの1/4ぐらい。
fastest よりもしっとりして密度があり、極端な言い方になるけど、シフォンケーキがスポンジケーキになるような感触がある。best だとパウンドケーキになるのだけど、どうもジッターが多くなると味のキレが悪くなってしまう。
こうした例えでいうならば、44.1 はクッキーかな。ケーキよりは粗い。
しかし、やはりクッキーからパウンドケーキという例えは極端すぎるかな。そこまで大きな音質差はない。

ここで気付く。medium なら 768kHz に出来るのでは。
一聴して、きれいな音。しかし、キレがいまいちか。CPU負荷は、best、384 の半分ぐらい。
768 なら fastest のほうが音楽の表情が現れるような感じ。CPU使用率は、best、384 の1/4ぐらいか。

libsamplerate は、CPU上の複数のコアで分担させて音声データを並行処理させることをしない。単一のコアが処理を行う。
うちのmpdサーバーのCPUは Intel Core i7-1255U で、12個のコアのうち、もっぱらCPU0 とCPU2 が、交代しながらアップサンプリング処理を請け負っている。それら以外のコアは殆ど働いていない。
それらCPU0 とCPU2の、CPUコア単位での使用率が 20%台ぐらいまでが、音に悪影響を及ぼさない限界、という感じ。
それを超えると、どうも良くない。以前はそうしたCPU由来のジッターの影響には気付かなかったが、ネットワーク環境のノイズが減ると、聴き分けたり感じられるようになるということらしい。

いろいろと、聴いてみて、どうか。
NAXOSの天上のオルガンのハイレゾ（384）は、空間の情報量が多い。空間雑音や音声のニュアンスなど、アップサンプリングでは聴こえない定位の仕方が聴こえる。それだけ明瞭なのだ。
44.1 は比較したら情報量は少ないが、音楽の表現が良質で安定感がある。客観的に見たら、十分にHi-Fiだろう。

アップサンプリングは、これらと比べて音のスピードが僅かに遅い感じがする。微妙な差異でも、音楽表現に影響するので看過できない。
best、medium のほうが、fastest よりもアップサンプリング自体の質は高い。しかし音のスピードは遅くなる。
fastest の設定は CPUコア単位での使用率が 10%前後まで下がる。このぐらいになると、音のスピードの遅延がほぼ感じられなくなる。使用率 20%ぐらいだと使用限界に近くて、まだどこか、ぬるく感じられるようなのだ。

そして暫く使ってみたが、どうもやはり、それでもアップサンプリングの音から受ける印象は、すっきりしない。

buffer の設定をいじってみることにする。
昔、audio_buffer_size と buffer_before_play を調整することで音が変わるというので、調整していたことがあった。積極的に調整するのは久しぶりだ。

当初は、audio_buffer_size 16384、buffer_before_play 75％ という設定だった。どちらかというと重い設定だと思う。best の設定で運用するには、重い設定でないと難しかった。
数字が小さいほうが軽快に動くイメージがある一方で、小さくしすぎると処理が追いつかなくなる。
audio_buffer_size を小さくすると、buffer_before_play を大きくする必要がある。

端折るけど、あれこれ弄った過程で、fastest をやめて、medium に、更に best に戻している。
どうせどうやっても遅れるのならば、best の設定のほうが音が良いように思ったのだ。
結果、audio_buffer_size 131071、buffer_before_play 8％ とした。

131071 というのは、設定できる最大値だ。
8％は逆に小さめ。0％も数字としては設定できるが、どうも挙動が変動して、それに伴って音も変わるような気がする。5％だと、ときどき鳴らし始めに音が途切れる。10％だと僅かに重い？気がする。そういうわけで、今のところは 8％ にして様子を見ているということだ。安定しないようなら 10％にするかな。

しかし、なんとか 44.1と同等レベルの速さに、できたかな。頑張ってようやく同等だ。もしかしたら音源によっては評価が変わるかもしれないし、微妙な感じ。
なんやかんや言って、384 のハイレゾが一番速い。今はそういう状況だ。

今回、mpdの設定を変えることでサーバーの負担低減を試みたが、結局、期待する結果は得られなかった。
期待というのは、384 ハイレゾと同等に近付けるということだ。かなり水を開けられている。仕方ないのかもしれない。44.1 と役割分担できそうなレベルにまで戻せたので、良しとすべきだろう。

しかし上記の調整をしたところ、アップサンプリングではヘンデルの携帯電話がステージ近くに寄って鳴るようになった。
44.1 に比べたら、かなり前方に定位する。
一聴、音は良くなっている気がするのに。

仕方ない。デジタル処理というのはそういうものだと割り切って暫く使ってみる。

サーバーへの負担は相対的なものだから、サーバーを強化するという選択肢も考えられる。
しかし機種選択が難しいと思った。
libsamplerate / best の設定で、384kHzを回しながら、ジッターの影響も無くそうと思ったら、 Intel Core i7-1255U の 4倍以上の速さで動くCPUが必要ということになる。そんなCPUは、まだ無いと思う。

あとは、サンプルレート変換ライブラリを軽いのに変えるという手段もある。
だけど、音質上どうなんだろう。
libsamplerate ですら怪しいのに、他のライブラリで有用性が得られるだろうか。今後の検討だけど実行できる気がしない。そんな暇もなさそうだからだ。

負荷が少ないということであれば、libsamplerate で低品質とされている ZERO_ORDER_HOLD の設定とかもあるかもしれないが、過去に試して全く思わしくなかったので、今更試してみる気はしない。

と、言いつつ、ZOH Sinc Interpolator を試してみた。
正直、、、驚いた。
昔、試したときには、とても実用にする気になれないと思ったのに、そこそこ、きれいな音で鳴るじゃないか。。。

44.1 と比べて、遜色ない。そして、Best Sinc Interpolator と比べても、遜色ない。そういう個性とクオリティを主張できる音だ。
GNDやノイズの対策は、ZOHの音質も、底上げするのだろうか。
そんな可能性は、今まで全く考えたことがなかった。

良い意味ですごく硬質で、クリアに聴こえる音だ。外連味が、全く感じられない。
こんな音は、今まで聴いたことがないような気がする。
ちょい聴き、情報量の感触は 44.1 に近い気がする。しかし微細な領域の再現性は、44.1 をかなり上回る。より正確で透明度が高く聴こえる。そういう感触は、過去にアップサンプリングが上手く行っているときに感じていた感触に近い。、、いや、実際のところ、情報量の判断は簡単ではなさそうなので保留する。
比較すると best 設定のほうが心持ち音が暖色に近く、動感を感じる再生音で、わずかに派手に聴こえる。

NAXOS の天上のオルガン、384ハイレゾと、ZOHによる44.1からのアップサンプリングは、ほとんど同じに聴こえる。僅かにハイレゾのほうが良いのかな。ブラインドでは、区別がつかないだろう。
これにも驚いた。best 設定だと、僅かにフォーカスが甘くてハイレゾに届かないかのように聴こえたのに。
しかし、ヘンデルの携帯電話の位置はステージ側に寄ったままだ。

ZOH では、ほとんどサーバーのCPU使用率が上がらない。
設定は、audio_buffer_size 16384、buffer_before_play 8％ 、こんな感じ。

ここで思う。
ZOH ともなれば、768kHzが簡単に出力できる。
結果は、384 と大きく印象は変わらないというもの。fastest、medium で鳴らしたときには、384 と差があるように思ったが、今回はあまり意味があるようにない。むしろ、明瞭さが減ったような気がする。どうなんだろう。
705.6kHz にしてみる。こっちのほうが、44.1 から ZOH するよりスムーズなはずだ。音は、768 より、若干、見通しが良いような気がする。しかしそれでも敢えて 384 から 700kHz台に変更したいという気にならない。

なんとなく 352.8kHz にしてみる。384 との音の違いは、無いわけではないようだが、あまり感じ取れない。やや 384 の方がおとなしいかな。音質差というほどのものではない。
しかし、ヘンデルの携帯電話は、左手前に近付いた。

ここまでは、サーバー負荷によるジッター以外が原因となっている可能性については書かなかったけど、他の理由も考えられることに途中で気付いた。
アップサンプリングの性質自体による音質劣化の可能性だ。
というのは、libsamplerate によるアップサンプリングは DA-AD 変換をシミュレートする過程で高域の情報が僅かだが失われる。以前は気付かなかったし、気にならなかったのだけど、システムの音質の改善に連れて、それが明瞭になったのかもしれない。
あれこれ mpd の設定を変えて、結局は libsamplerate / best の設定に戻るということは、そういうことではないのか。best だと他の設定よりも高域の減衰は少ないのだから。

しかしそれを考えたら、ZOH のほうが高域の減衰は強い筈なのだ。4kHz以上で徐々に減衰が始まり、しかし 18kHzで 0.5dB 程、22kHzでも 1dB に届かないらしい。僕にはその減衰を聞き取れない。
そして、best の設定だと減衰は 20kHz 以上で始まる。
（参照：https://src.infinitewave.ca/ ）

それにしても。
実際、どうしようかと思う。

其々の設定に、其々の特徴がある。

44.1 は、上手く鳴らしたら鮮やかで、安定した音がする。
ただ、44.1なので、情報量は頭打ちに感じる。たぶん、それはうちの機器の限界だ。100万円のDACとか強力なクロックを使ったら限界を超えられるのだろうか。

libsamplerate の上位のアップサンプリングの美点は、そうした音の色彩を殺さないということがある。更にアップサンプリングによって情報量が増える。弱点は、比較すると安定感がやや少ないことだ。僅かに音のスピードが遅いことが原因だと思うんだけど、どうなのだろう。
352.8 だったら、ヘンデルの携帯電話は、左手前に近付く。ZOHのときと同じだ。しかし暫く聴くうちに、なんとなく違和感を感じるようになって 384 にした。理由の説明は難しい。好みなのかな、どうなのだろう。

ZOH は、安定感が強い。44.1よりもしっかりした音に聴こえる。アップサンプリングによって情報量が増えると同時に、安定感と相まってフォーカスが合うかのような分解能が高い感触の音がする。しかし色彩感は薄くなる。これは、実際のところは微細な情報が欠落しているんじゃないかと思ってるんだけど、、、そうは簡単に思わせないだけの音が出ている。

どうなるだろう。使いながら考える。

今回はタイトル通りの話。
うちの ONU と家庭内LANの AP はともに NEC の製品で、Yuho式アクティブアースを使うことが難しかった。

まず、LAN端子のGNDにつなごうと思ったら、全て縁がプラスチック製でつながらない。
次に ACアダプター端子のGNDにつなぐことを考えたんだけど、手持ちのACアダプター端子の中に、つながるものがなかった。どんな端子を使えばいいのか、ネット検索しても調べ方が悪いのか、規格が分からない。

SNS上で、ACアダプター端子の規格は EIAJ4（JEITA RC-5320A規格）だと教えてもらって、光明が見えた。
そういうわけで、近場の電子部品店で端子を入手して、自作のアダプターを作ってみた。

これでアクティブアースをつなぐことができる。
ONU、AP が2つ、合わせて3箇所にアクティブアースを追加した。

音はどうなったかというと、より粒子が細かく色が鮮やかに、動きが速くテンションの緩急が大きく明瞭に感じる。音場の重なりが分離してバウムクーヘンがミルフィーユになる感じ（この表現、以前に使ったかな、と思ったら4年前だった）。音像の個性がよりはっきりして、音楽性に広がりが生まれる。
僅かな差異と言えば僅かだけど、、、いや、これは僅かではないな、音楽の力は5割増しぐらいに感じる。エネルギーが増しているのだ。

正直、3つを埋めただけで、こうも違うかな、というのはある。
44.1 の音源データが、384 であるかのように聴こえる。かつ、384 のモニター的な感触はないのだ。44.1 は大きく改善した。

384 はというと、より精緻な感触で音楽が鳴る。音色の陰影が深まった。しかし 44.1 ほどの大きな改善はない。
情報量ということだけなら、384 のほうがまだアドバンテージがあるような気がする。しかし、44.1 と比べて、きれいに分離しているという感じがしない。ここに来て初めて、44.1 のほうが音のスピードは速いと感じた。結果、44.1 のほうが、音楽が舞うのだ。躍動感、エネルギー、質量を感じる再生となる。音楽の熱量は 44.1 のほうが上回る。というか、音楽の意志をより強く感じる。
おそらく、アップサンプリングサーバーへの負荷によるジッターが、384 の再生に影を落としているのだと思う。

ちなみに、ヘンデルのオラトリオの携帯電話は、44.1 の方が 384 よりも明瞭に定位する。場所は左前方手前で差異はないようだが、聴こえやすさが異なる。44.1 のほうが、そこにある違和感が強く表出される。

44.1 のアップサンプリングと、ハイレゾ音源では差が出るだろうか。
比較に使用したのは、NAXOS の「天上のオルガン」。384 のハイレゾと、44.1 音源のアップサンプリングを比較できる。
昔、比較したときは差異は非常に少ないという結果だった。だからうちでは、アップサンプリング再生に舵を切ったのだ。しかし今回は、ハイレゾのほうが良かった。ハイレゾは 44.1 の鳴り方に近い。アップサンプリングの音は、比較するとエネルギーが足りない。
ハイレゾと 44.1 を比べたら、ハイレゾのほうが階調が深い音がする。豊かで余裕がある音で、明らかに優位性が感じられた。

アップサンプリングに伴うサーバーへの負荷が再生音に及ぼす悪影響を、音から聴き取ることが可能になったということだ。
これは、今後のうちのシステムをどうしたらいいかという話になっていく。

いや、実際、どうしましょうかね。

前回は、Petit Susie の使用状況について書いた。今回は、一応その続きなのだけど。

うちでは、Petit Susie の効果を維持するには、ときどきコンデンサーに溜まった電荷を放電させないといけない。だから時々、ACアダプターにつながる側の電源プラグを外して電荷を消費させる。
しかし、そんなことをせずに済むなら、それに越したことはないのだ。
それに後述するが、電荷放電処置の影響なのか不明だが、機械の挙動が不安定になることがあった。そういう意味でも気持ち悪い。

そこで12月下旬、クリスマス前から、Yuho式アクティブアースを使ってみることにした。
https://x.com/rabbit_yuho/status/1940676289247301939
https://philm-community.com/rabbit-yuho/user/user-impressions/2025/04/28/30465/

とはいえコンデンサー1pFは27nFに変更し（理由は手元にあったからだ）、GND直前のコンデンサー１個は付けてないので、変法だ。

まずは、PPAP Back-End に使っている銅板仮想アースに追加してみた。
apu2 のRS-232C端子のGNDにクリップでつなぐ。
電源には Petit Susie を付けたままで、Back-End の音が劣化するのをアクティブアースで防げるかどうか、試してみる。

装着した直後の音は、しっかりした感触で好印象だ。
アクティブアース自体の効き方もあるかもしれない。
音が見えてくるような印象。派手さはないけど基礎がしっかりするような感じがある。
悪くないと思ったので、もう1つ作って、もう1台のPPAP Back-End、Ras Pi 2B にも付けてみる。
こっちも悪くない。同様の効果が感じられる。

仕組みについて考えてみる。
一般的なオーディオコンポーネントで、GNDの安定維持に働いているのは電源だ。
ただ、そうした電源は音を出すのに働いている。
音は電圧変動だ。
どうしたってノイズ源でGNDを乱す。
正確な音声信号を出力しながら、GND電位を乱さず安定を確保する力も強いことが、良質な電源の条件だろう。
それはデジタル機器でも変わらない。
ジッターが音に大きな悪影響を及ぼすデジタルオーディオでは、良質な電源は必須だ。

さて、しかし、GNDを乱す電源と、GNDを安定させる電源が同じというのは、考えてみたら、ちょっとおかしい、のではないか。
しかしじゃあ、GNDを安定させる電源というのは、どこでどういう姿をしていたら良いのか。想像がつくだろうか。

1つの答えが製品のアクティブアースだ。アースの基準値となる高精度な電圧をCPUを使って計算して生成するという。その基準信号を極めて低いインピーダンスでオーディオコンポーネントのGNDに送り込む。なんだかすごい。
但し非常に高価だ。
Telos Audio Design JP
https://telos-audio.jp/index.html

もう1つの答えが、今回のYuho式アクティブアースだ。
電池の安定した電位がGNDの変動を抑え込むということだ。
どうしてそうなるのか分からないけど、これが効いてくれたら助かる。なにしろ安価で手軽にやれる。そして、やってみたら手応えがある。

そして時間経過に連れて、音は変化するかどうか様子を見た。
PPAP Back-End 以外の場所の Petit Susie は、音を出す前に電荷を放電することにした。他を同じ条件にしておかないと比べられない。

３、４日目で、やや緩い感触が出てきた、ような、気がする。
しかしホンマかいな？と思うぐらい、評価に自信がない。音色のグラデーションは存外綺麗だ。やはり気のせいか。
こっちの体調によっても音は変わる。もっと時間をかけないといけない。
と、思っているうちに、ふとテスターでアクティブアースの電圧を測ってみたら、おかしい。
電池のレベルではDC3Vあるのに、コンデンサー直前では0Vなのだ。コンデンサーに電荷は溜められてるかというと、テスターで確かめると電圧の数値が一瞬、放電で上がるので、多少は溜められているらしい。

結局これは、ハンダ付けの不手際で端子周囲が溶けて導通の不良が起きていたのが原因だった。
その後、工作手順を変更し対応。上に挙げた写真は、実は最終形態のものだ。

いろいろばたばたして、試験運用も最初からだ。
どこまで何がどう効いていたのか分からない。
ちゃんと接続できて電圧も安定し、音は前より良くなった、かな、たぶん。プラセボかもしれんが。

そうこうしていたら、Daphile が不調になった。再起動が途中で止まる。USBメモリが壊れた。
再インストールだ。全部、設定し直しだ。
なにかとめんどい。
USBメモリにインストールしていると、こういうことが珍しくないので、今回はPC内蔵のHDDを予め初期化してインストールした（初期化には Fedora のインストーラーを使った）。うちではPC本体へのインストールは初めてだ。どんな違いがあるだろうか。取り敢えず長持ちしてほしい。
いつものようにDeezerで音が出ない。
いろいろ対策を試みたが、結局はやはり決定打はない。
flacのエンコードでエラーになっているのだけど、なにしろ原因が分からない。暫く待てば治る。

Daphile がそんな調子で、一方、mpdサーバーの方も安定しないことがあった。
電源アダプターの電圧が何故か上がらなくなって、Tiny Core Linux が起動しても落ちてしまう。つまりバッテリーも空になってるのだ。アダプターを買い替えないといけないかと思ったんだけど、時間経過で何時の間にか治っていた。
なぜ治ったか不明。

ともにPetit Susie をつないで時々放電していたサーバーだ。
そういう意味で、気持ち悪い。
放電処理はしないほうが良いのかな。それが原因という根拠は無いのだけど。
でもまあ、それで始めたものは仕方ないので、様子見ながら続けるのだけど。

この時点で、それでもオーディオの音は良い。安定している。

さて、年が明けて、音はなおも安定しているようだ。
劣化を感じない。音像はきれいで、音場にもさり気ない広がりと柔らかさがあり硬さや窮屈さを生じない。
安定感があるのが有り難い。いつ鳴らしても期待した音質が得られる。

銅板を使った仮想アースを使い始めたのが、気が付けばもう5年以上前になる。
音質の変動を減らしたいという気持ちだったが、限界があって、数日に1回の頻度で着脱しリセットしないと効果を維持できない。Petit Susie も効果があるが、やはり付けっぱなしだと徐々に副作用が効果を上回るので、コンデンサーを放電する。
Yuho式アクティブアースは、GND周りのそうした音質の悪化を防ぐ効果があるようだ。

Ras Pi B2 で伝送する44.1kHz音源の方も、いい音で鳴る。384kHzと比べても、殆ど遜色ない。
ブラインドでの区別は、たぶん出来ない。
聴き慣れた音源によってはギリギリ出来るかもしれない。細かいところを比べたら差異はあるように思う。音のキレ、グラデーション、深さは384の方が僅かに上回る。44.1の方がややありふれた音に聞こえるようだ。

2台の PPAP Back-End で試用を始めて、あれこれあったが10日が過ぎて三が日も終わるので、アクティブアースを増やすことにした。
Petit Susie を使っているサーバーとスイッチングハブの Petit Susie に追加する。ついでに、PPAP middle-End にPetit Susie をアクティブアース付きで戻すことにした。 ここに使う方が、特に44.1は音が良くなる筈。

アクティブアースは計7台。Petit Susie はなんやかんやで7台なので数は同じだが、使っている場所が違っていたりオーディオ関係以外に付いていたりで、まだ増える余地がある。
本当はPR-500MI（ONU）や、AtermWG1600HP3（AP）などにも使ってみたかったんだけど、GNDにつながる場所がない。分解も出来ないし、NECの機械はガードが硬いのだろうか。
Petit Susie の放電は止める。止めて良好な音を維持できるかどうかだ。

この時点の音は、凄みが増した。
見通しが良いのと安定感が増している。音色が鮮明になる。音に質量がある。ケチらずに多数付けるのがいいのかもしれない。LANターミネーターとかもそうだったが、物量が物を言うところがある。それだけノイズ源の影響があるということだろう。

この状態で1月半ばまで様子を見よう。
と、思ってたが、１日経ってなんだか音が鈍いような気がする。
Back-End の apu2 に近付くと、微かにキィーンと音がする。
Petit Susie が鳴いているのかと思ったが、そうではなくて、apu2 の筐体内で何かが鳴いているようだ。こんなことは今まで無かった。いつから鳴いているのだろう。確認したら MIddle-End からも音がする。
コンデンサーやコイルが何かの拍子に共振するということはあるらしい。

鳴きっぱなしにはしておけない。apu2 から Petit Susie を外したら鳴きは治まった。
アクティブアースはつなぐ。
音は、なんだかすっきりした。凄みはないけど、いい音だと思う。、、案外、このほうがいいのかな。自然な感じがする。

しかし、なんだかいろいろあって、いろいろ分からなくなった。今回はいろいろありすぎる。
他のサーバーやスイッチングハブでは、鳴きは聞こえない。しかし、僕の耳には聞こえない音で鳴いている可能性はあるのかな、、、こういうのは現時点では様子みるより仕方ない。
外した Petit Susie は、上流のスイッチングハブとロスレスmpdサーバーに移動した。
この状態で1月半ばまで様子を見よう。

さて、ぼんやり日にちがすぎるのを待つのも何なので、アクティブアースをテレビに付けてみた。
ブラインドでは分からないだろうけど、画面がきれいになった気がする。

下流サーバーにつながるスイッチングハブの Petit Susie を外してみる。アクティブアースはちょっと細工してLAN端子縁のGNDにつなぐ。音はエネルギー感が下がって地味になる。Petit Susie があるほうが音楽として訴求性が高い音になる。しかし音源によっては、ないほうがリアリティが若干高まるような気がする。
これは、どちらがいいのか即断できない。
まあ、今は試用期間だし、もう暫くは付けた状態でやっていくのだけど、今後は検討が必要だ。

1月半ば、安定している。音がいい。
なんやかやでアクティブアースはあちこちに10個以上になった。
ここまで良好な音質を維持して安定してオーディオを聴けるようになったのは久しぶりな気がする。
そういうわけで、試用期間は終了し、継続使用していく。

末筆ながら、Yuhoさん、ありがとうございます。

11月以降、アップサンプリングの音の課題について考えている。
44.1kHz（ロスレス）の改善に比較して、384kHzへのアップサンプリングは改善が少ない。これはもう少し何とかできないだろうか、ということだ。

まず、アップサンプリングするということ自体の課題。
うちではmpd + libsamplerate で音源のアップサンプリングを行っている。
mpdサーバーに大きい負荷をかけるのは、ノイズ、歪を増やすことになる。負荷自体は減らせないとして、ノイズをどうやって減らすか。

ふと思いついて、mpdサーバーのACアダプターを外してみた。
うちのmpdサーバーはノートPCなので、バッテリー駆動に切り替わる。
そうなると、音の方も僅かだがクリアに、清浄になる。
この手法はアップサンプリング用のサーバーでしか使えない。アップサンプリングしない方のmpdサーバーは古いので、バッテリーがへたっていて、できない。
問題は、うっかりしたらバッテリー切れでmpdサーバーが落ちることだ。もちろん音も不安定になったかな、と思ったら切れてしまう。僕のような人間には不向きだと判明した。

上流サーバー周りで取り敢えず出来るノイズ対策で、一般的なACコンセント用のノイズフィルターを使ってみた。サンワサプライのTAP-AD2Nというもので1個千円しない。
これをmpdサーバーに使う。ついでにNASにも付けてみる。
音は、劇的に変わるというのではないが、使わないよりも使うほうがいいような気がする。どうだろう。

次にアップサンプリングされた音源を、どうやって鳴らすか。
経験的には、44.1はノイズに敏感で、384はノイズに耐性があると思う。しかし、だからといってノイズが多い環境で384を使っていては、本来のポテンシャルは発揮できない。ノイズが減ったら、384の音も良くなっている。
更にノイズを減らしたら、どこまで良くなるだろうか。44.1との差異はどうなるだろうか。
まずは、PPAP Back-End、Middle-Endへの対策ということになるか。

PPAP Back-End、apu2d4に、FX-AUDIO Petit Susie Solid State をつないでみた。
https://www.amazon.co.jp/dp/B0DLG4JJZK

DC電源からのノイズを減らしたいということだ。
ちなみに、Petit Susieの入力プラグ（メス）は、外径 5.5mm / 内径 2.1mm、出力プラグ（オス）は外径 5.5mm / 内径 2.1mm/2.5mm両対応。
apu2の電源プラグは、外径 5.5mm / 内径 2.1mm。
Petit Susie をapu2の電源アダプターにつなぐのにサイズ変換プラグが要る。
ちなみに電源アダプターはスイッチサイエンスで売られている2千円強の一般的なものだ。

音は、より細やかで滲みが少なく、軽やかになる。そして演奏のニュアンスがより明瞭になる。
外すとやや滲む感じになるのだけど、なんというか、音に独特の湿り、艶っぽさが乗る。HiFiからやや離れるが、これはこれでいいのではないか、というような魅力がある。
しかしHiFiを目指すなら、Petit Susieがあるほうがいいと思った。

この時点では、NASの音の方がストリーミングよりも凄みがある。演奏の機微の再生が勝っている。
LMSサーバー（Daphile）は、11月半ばにWiFi接続を止めて有線LAN接続にした。
なんとか置き場は確保した。NASをつないでいるスイッチングハブにつないでいる。
ストリーミングの音は若干改善したと思う。LMSサーバー移動に伴うNASの音の変化は聴き取れない。

Middle-EndにもPetit Susieを使ってみる。
Middle-Endは44.1の経路にも噛んでいるので、これが、更に良くなる。
384も良くなっている気がするけど、いよいよ甲乙が決めにくくなる。微小な音のグラデーションは384の方に分がある。情報量はある。しかし44.1と比べて僅差だ。44.1のほうが訴求性が高いというのか、熱い音だ。384はクールで比較的穏やかに鳴る（あれ、前回エントリーの時から逆転したのかな）。

ここで、NASとストリーミングの優劣の判断が難しくなってきた。
音色の違いはあるが、これも説明しにくい。クオリティは同等だと思った。

ところが、だ。
数日、１週間、と経過するうちに、どうも旗色がおかしくなってくる。
なんだか音が重いのだ。粘りっ気があるというのか。Petit Susieを使い始めた当初に見られた美点が、感じられなくなった。べたっと空気の壁に張り付いたかのように聞こえる。
Back-EndからPetit Susieを外してみたら、音がクリアに軽くなった。以前から聞き慣れた音。
どういうことだろう、と考えるうちに、以前に仮想アースの自作を試みたときの音の変化に近いのではないかと気付いた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200107a.htm

以前の試みとPetit Susie共に、GNDにコンデンサーが繋がっているところが類似している。
最初は良いように思っても、時間の経過と共に改善効果が薄れてしまうところも同じだ。
というか現在、apu2に使っている銅板の仮想アースも、時間が経つと音が曇るので、時々外してやって調整している。コンデンサー付きのものより扱いやすいというだけだ。

当時の検討では、GNDの変化が時間経過と共にDACやアンプの挙動に影響するのではないかと判断した。Back-EndはUSBを通じてこれらに繋がっているのだ。
Back-Endのほうは、残念ながら当面は使用中止だ。
Middle-EndでのPetit Susie使用は継続する。

そして、暫く経って、どうもまだ何か、僅かに曇りがある。
Middle-Endも、Petit Susieを外す。曇りが取れる。これは、どうしたものかね。
ここで、Petit Susie除去に伴う44.1の音の変化を確認していないのに気付く。
まあ、仕方ない。Petit Susieを戻しても、変化の確認が出来るようになるには日数がかかる。取り敢えず外すのは確定だ。

ともあれ、こういう経緯でMiddle-End、Back-EndでのPetit Susie使用を終了した。デジタル信号伝送の下流のサーバーでは使いにくい。時間が経つと、悪影響が出てくる。それにしても、単純にDACのGNDにつながってるから影響するというのでは説明出来ない。何なのだろう。

そういうわけでせっかく入手したPetit Susieなのに、使わないでは勿体ない。上流のサーバーではどうだろうか。

mpdアップサンプリングサーバーの Probook 450 G9 にPetit Susie Solid State をつないでみる。
電源プラグは、外径 4.5mm / 内径 3.0mm。
珍しい変換ケーブルが必要なので、Amazonで頼んでも2週間ほどかかる。
つないでみて、多少は、いいのかな。
少し見通しが良くなったような気がする。ACアダプターを外した時ぐらいの効果は、あるのかな。

Daphileサーバー、Probook 430 G5 にもつないでみる。これも電源プラグは、外径 4.5mm / 内径 3.0mm。
音は、あんまり変わらんかな、どうかな、まあ、呪いとして付けておくかな、、。

さらに、NAS（hs-264、hs-210）にもつないでみる。これらは、ネット上を調べても電源プラグの情報が出て来ない。電源アダプターにも書いてない。取説は、箱を引っ張り出すのが面倒だ。
実際につないでみて、外径 5.5mm / 内径 2.1mm と確認した。これなら変換プラグはいらない。
あと、敢えて高価なものでなくてもいいかもしれんと考え、安価な方の「Petit Susie」にした。
https://www.amazon.co.jp/dp/B0848W4JZF

しかし、これらは、効いてるんじゃないかな。
音色が美しい。美しいのは、もしかしたらPetit Susieのコンデンサーやコイルの性格が出ているのかもしれない。
しかしそれ以上に、音が見えやすくなった。クリアで精緻な音だ。
これはノイズが減った効果があるからだと思う。しかし、矛盾するようだが、音像が溶け合う傾向があるような気がする。音源によっては、定位の仕方が以前と違うような気がする。音場が深くなったのか。どうなんだろうかな。小鳥はちゃんと定位するから様子見だ。

問題は、日にちが経つに連れて弊害が出てくるかどうかだ。
暫く経過を見る。
ロスレス伝送用のmpdサーバー、EliteBook 820G2の電源プラグは外径 7.4mm 内径 5.0mm。手持ちの変換プラグではつなげない。 プラグが届くのにも時間がかかる。改善効果の変遷を確認した後になるかもしれない。

そうこうするうちに、音が途切れることが。
途切れるのは困る。
1週間ほど過ぎて、12月半ば、450 G9（mpdサーバー）から Petit Susie を外してみる。
音色がクリアになる。
430 G5（Daphileサーバー）からも外す。外したほうが、いいかな。
NASもなんとなく音が鈍いので外した。
どうも、やはり、時間が経つと副作用のほうが大きくなる。

ここで、Petit Susie のコンデンサーに溜まった電荷を放電させて（Petit Susie にはそういうことに使えるビスが付いている。放電させたら小さな火花が出る）、サーバーに戻すと、いいような気がする。
気がするんだが、どうなんかなあ。
どうやら、コンデンサーに溜まる電荷は、ときに放電してやらないといけないようだ。いったい何が溜まってるんだろう。

しかし、なんだな、放電したらリカバーできるんだったら、PPAP Back-Endに使うのもありなのか。
そういう思い付きのもと、Back-End に戻した。
悪くない。やはり、使ったら使ったで効果がある。

しかし、管理をどうするかな。
ゼムクリップとかで放電したら火花が出る。
なんとなく物騒だ。
あと、サーバーの置き場所によっては放電させるのが面倒だ。正直、Back-End以外はやや面倒な場所にある。
疑問なのは、サーバーに通電したままコンデンサーの放電をしても良いのかどうか。そんなことをしたら急激に電圧が変動してサーバーの動作に支障があるかもしれないし、下手したら壊れやしないかな。分からないけど、だったら電源を落としてからコンデンサー放電をしないといけないだろう。

Middle-End は再起動後にsshからコマンドを打ってやらないといけないのと、プラグ着脱が面倒な場所にある。
新しいmpdサーバーと Daphile はノートPCで、電源管理は簡単（電源プラグを抜くとバッテリー駆動に切り替わるので、オンオフは気にしなくて良い）だが、これも置き場の問題がある。
古い方のmpdサーバーはもともと不具合があって、電源を落としての再起動に際しては機体を引っ張り出してやらないといけないので結構な手間だ。
QNAPのNASのオンオフは、ウェブブラウザからアクセスしてシャットダウンしないといけない。シャットダウンにも起動にも、数分以上の時間がかかる。待たないといけない。しかしまあ、待つだけといえば待つだけで、他の手間はないんだけど。

管理上、気安くできるのは、PPAP Back-End。手軽にアクセスできる場所に設置しているし、電源のオンオフ、つまり電源プラグの着脱だけで他にすることがない。Petit Susie の給電側のプラグを抜けば、それだけでコンデンサーの電荷はapu2で消費されるので、放電したのと同じ状態になる（ほんとかなあ、、、）。
同様の手法で対応できるのは、新しいmpdサーバーと Daphile のノートPCということになる。置き場の問題があるだけだ。
ちなみに電荷が放電し切るまで、apu2は10秒ぐらい。ノートPCは1〜2分以上かかる。バッテリーを積んでるからだろうか。手作業でテスターで測ってるので正確ではない。
これら3台ぐらいなら、この手法でやれるかな、、、

で、やってみたら、実際、音が良くなるようだ。
しかし、そうしょっちゅうか定期的にか、電源プラグを外してというのもなあ、、、忘れること多そうだな。
GNDにアクティブに作用する仮想アースが製品化されている。そういうのを使えば良いんだろうか。しかし1台20万円近くするのでおいそれとは手を出しにくい。

スイッチングハブに Petit Susie を使ったら、どんな効果が得られるだろうか。
もしかしたら、サーバーに使うよりも効果があるかもしれない。そしてサーバーのときのような副作用がなければ有り難い。

うちのネットワークではNETGEARのハブをあちこちで使っている。
確認したらプラグは外径 5.5mm / 内径 2.1mm なので、Petit Susie はそのまま使える。
いくつか使ってみたら、なかなかいい感じだ。
というか、そうとういい。サーバーに使うより、いいみたい。

本当はPR-500MI（ONU）や、AtermWG1600HP3（AP）にも使ってみたかったんだけど、プラグ径が、調べても分からない。
どうもNECの製品はACアダプターのプラグが特殊仕様で汎用品が使えないのが多いらしい。
つなげないなら仕方がない。
APがつながっているNETGEARのハブに使ったら、Amazon Fire TV Stick（WiFiでつながっている）の画質が良くなったように見える。輪郭が鮮明な感じ、色合いや動きが明瞭な感じ。これはちょっと意外だったが、考えてみたらオーディオの音が変わるのだから、映像でもそういう効き方があってもおかしくない。

さて、ここまで来て、当初のアップサンプリング音源の音質がどうなるかというところから随分と離れてきている。
44.1の音の方は、どうも Middle-End の Petit Susie を外したら、384に差を付けられたようで、なんだかちょっとゆるい。そもそもmpdサーバーの方も、384は Petit Susie を使っているので有利なのだ。
ハンデがある比較では、しても意味がない。

というわけで、現在進行形な話で、まだ結論はない。まあ、焦らずやっていこうと思う。

今回は、最近のオーディオシステムの音の変化について。
最近のエントリーに、デジタル信号の違いに鋭敏になってきている気がすると書いた。もうちょっと見えてきた内実を記録しておく。

mpdのデジタルボリュームに因る音の劣化に敏感になったみたいだというのは、前回に書いた。
アンプのボリュームを使うほうが良いというだけではなく、どうも、M500（DAC）でもDAC本体のデジタルボリュームを使うほうが良いようだ。以前はmpdのボリュームと差異が感じられなかったが、今はM500のボリュームを使うほうが良い気がする。
どういうことだろうね。

昨今の一般的なネットワークオーディオは、タブレットからWiFi経由でコントロールするのが主流だと思う。
うちはそうではない。LMSのコントローラーとしてウェブブラウザや、mpdクライアントのncmpcppを日常使用に使っているノートPC上で動かしている。
これが、音を出しているときにはウィンドウを閉じたりバックグラウンドに回したりして、カーソルやマウス、キーボードの操作に影響されないようにしたほうが、音が良く安定感があり音色が澄んで聴こえるようになった。
同時に有線LANを外して、WiFi接続にしたほうが良いような気がする。これはおそらく、ノートPCの電圧の変動が有線LANケーブルを通じてLANネットワークに影響するのを防ぐことが出来るからだと思う。
以前から、こういったことが多少は音に影響しているのかな、と思うことはあったが、明らかではなかった。
それがどうやら、配慮したほうが良さそうだということになってきている。
わずかで微妙な差異なのだけど、放任できなくなってきている。
更に、以前なら普段使いのPCでYoutube動画を流したりしていても、そう影響ないなと思っていたのだけど、最近はどうも少し音が曇る。いろいろ日常的なPCの使用に影響が出てきている、というか、そういうセッティングになってるということなのだろうけど。

実際のところ、オーディオのコントローラーと普段使うPCは、分けたくない。
タブレットの操作は嫌いだし、PCを増やすとなると置き場の問題がある。如何にノイズを抑えるかを考えないといけない。

NASとストリーミング（LMS）の比較だと、現在はNASの方が優れた音が出ている。
LMSサーバーのWiFi接続を止めて、以前の場所に有線接続するのも考えるのだけど、置き場の工面が難しい。それに、LMSサーバーの場所を戻したら、NASの音質への影響もあると思われるので、良いかどうかはやってみないと分からない。

かなり大きな変化がある。libsamplerateで384/32にアップサンプリングした音と、44.1/32でCDとビットパーフェクトの音、以前は明らかにアップサンプリングしたほうが良かった。
それが今は、どちらがいい音なのかと問われたときに、答えに窮するぐらい、44.1/32の音が改善している。
そして逆に、384/32にアップサンプリングした音は、どこか冴えない気がする。以前ほどには良くない気がする。以前はあった美点が薄れて透明度が低い感じ、どこか曇りがある気がする。
細かい比較試聴は出来ていない。
大雑把な印象で整理できていないので、焦らず時間をかけて聴かないといけない。
それに、そもそもmpdサーバーが違うし、Back-Endも違うので、これも考慮して検討、試行しないといけない。あと、44.1系と48系という違いがある。これも比較するなら揃えないといけない。
今の音を比較するには、以前のような単純なやり方では済まないだろうという予感がする。

デジタル信号の変化やノイズに鋭敏に反応するということは、デジタルデータをより正確にDA変換しているということなのかもしれない。だから、44.1/32のほうが384/32よりも改善の恩恵が大きいのかもしれない。44.1の方がデータが粗い分、DA変換の正確性への要求度が高いと思われるからだ。
もう一つの可能性として、アップサンプリングを行うmpdサーバーへの負荷がジッターとして音に作用している可能性がある。以前は大きな影響としては現れなかったのが、今の鋭敏な環境だと明瞭になるのかもしれない。
ほんとかな。

ここまで色々書いてきているけど、音源によって印象が違うこともある。mpdのボリュームでもいいじゃないかと思ったり。
やはり、じっくり時間をとって聴き比べないと、間違える。

そういうわけで、とりあえず、mpdサーバーとBack-Endを統一して聴き比べてみた。
mpdサーバーはメインシステムのProBook 450G9。libsamplerateのBestの設定で384kHzへのアップサンプリングが出来る機械ということだと、これに決まってしまう。
Back-Endもメインシステムで、apu2d4。
Back-Endに384、44.1、どちらの信号も受けることが出来るよう設定して、USB出力をRME ADI-2 DACに送る。
mpdサーバーの.mpdconfを切り替えることで、伝送するデジタルデータを変えて比較する。

ここで問題が生じる。
PPAPというオーディオ伝送方式は、ハードウェアに依存する部分が大きい。どう依存するかというと、44.1は100Base-Tが必要で、384は1000Base-Tのほうが良さそうという、そういう感じなのだ。

450G9のLAN経路をスイッチングハブで100Base-Tに設定し、apu2のLANにDMJ-100BTを介在させることで、44.1はなんとかギリギリ安定して伝送する。
これで384が通るか？と思ったけど、なんとか鳴った。昔は100Base-Tだと鳴らなかった。LANのノイズが少なくなると伝送が安定するのかもしれない。
そういう状況で音を出すと、どうも384も44.1も、ともに本領発揮しない感じ。
44.1は機体自体が100Base-Tで動くRas Pi2Bと、古い機械である820G2の組み合わせのほうが生き生きと鳴るような気がする。
384はやはり、1000Base-Tで流したほうが、余裕があるような気がする。100Base-Tだと音が硬くて窮屈な気がする。
Ras Pi2Bと450G9で組ませてみると、これもどうもなんだかしっくりこない。伝送もいまいち安定しないし、雑味が強くなる。

そういうわけで、単純に機械を固定して比較することは、あんまり意味が無さそうなのだ。
普段の使用に際しては、アップサンプリングは850G9とapu2、44.1は820G2とRas Pi2Bで鳴らすことにした。本領発揮できる音で使い分けるほうがいい。
そうした音を聴いて比べると、以前よりもずっと僅差になった。
情報量だけ比べたら384のほうが優位なのだけど、44.1のほうが明瞭で歌心が感じられ、こちらのほうが良いという人も少なくないだろう。

しかし、1年前に試聴したときは、明らかにアップサンプリングのほうが良いという結論だった。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240830a.htm

上記の過去エントリーによると、Ras Pi2Bと820G2の組み合わせで44.1から384まで音が出ていたようだ。
当時はLANの伝送速度について意識していない。
当時のシステムは多分、下記エントリーの配置。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240715a.htm
なんで問題なく44.1が鳴ったのか考えてみたら、当時はRas pi2BへのLANの経路に100Base-TのスイッチングハブであるFX-08miniを使っていた。恐らくはこれが、44.1を伝送するのにうまく働いてくれたのだろう。

このときは簡単なテストのようなつもりで、主力機の方は使っていない。たまたま偶然、当時は問題なく鳴ったので試聴ができたようなんだけど、820G2ではmpdを最良の設定で動かすことができない。たしか、Bestの設定で鳴らせるのは192までだったと思う。Mediumならたしか、768kHzでも使えた気がする。
この際なので、このときの機械で比較試聴してみる。
同時に、384kHzと、352.8kHzの比較もする。以前は44.1と300台に明確な差があったので、384と352.8を比べることに大きな意味を感じなかったんだけど、今は聴いてみないと分からない。44.1と352.8の音は近いかもしれない。

ちょっと問題がある。
Ras Pi2B（piCore 14.1）ではncatコマンドを2つ同時に走らせることができない。理由は不明。だからサンプリング周波数を変えるたびに、Back-Endの設定を書き変えて再起動しないといけない。試聴の環境としては良くないが、仕方ない。
そういうわけで、設定を切り替え再起動しながらの試聴だ。
なお、mpdサーバーから44.1は100Base-Tで出力し300台は1000Base-Tで出力している。現在のLANでは、そうしないと安定しないからだ。
音源はDeezerのflac音源を使用した。

352.8kHzは、ときどきプチッとノイズが入る。音自体は、悪くはないのだけど何かすっきりしない。384kHzは、352.8よりも、たおやかな感じの音色。やはりプチノイズがたまにある。あまりアップサンプリング再生の環境が良いとは言えないのだろう。
44.1kHz、しっかりした音色で鳴る。意外にも352.8よりもいいような気がする。情報量はやや少ないけど補って余りある安定感がある。安定感というのは音の実体感だ。音のニュアンスに説得力がある。44.1はやや音量が大きいかのように聞こえる。
この結果は何だろう。
384と352.8のギャップは説明しにくい。使いたいと思えるのは、384と44.1ということになる。なぜ352.8がいまひとつ良くないのか分からない。もしかしたら、mpdサーバーである820G2のクロックの性格に因るのだろうか。アップサンプリングに際して、384のほうに何かが有利に働くのだろうか。想像、雑感の域を出ない。
384も44.1より優れていると言いにくい。音数は多いようだけど、それがオーディオ的な心地よさに結び付いていない感じがする。

しかしこれが、850G9とapu2で384を鳴らすと、音色に説得力が宿る。44.1よりも優位性があるように思えるのだけど、前述したが、44.1のほうが好みだという人がいてもおかしくないと思う。384はどこか素っ気ない感じがする。
352.8も聴いてみた。ブラインドでは聴き分けにくいと思うが、384よりメリハリがあるような気がする。しかし384の方が階調が深い。352.8は、820G2の時ほどではないけど、何故か粗さを感じる。なんとなくジッターの影響を思わせる感触だ。根拠は薄弱で理由は不明だ。
384の陰影の深さと44.1の実体感、両方が得られたら良いのだろうけど。

ともあれ、以前のように明確にアップサンプリングしたほうが良いとは、言えなくなった。
それぐらいロスレス音源の再生音は良くなっている。

僕は昔から、ノイズやジッターが多い環境では、良質なアップサンプリングで処理した音源のほうが有利ではないかと言っていた。
今回の結果と、昨年の結果を比較検討すれば、それはそれで、正しいのだと思う。
正しいのだとしても、では良質な環境ではハイレゾに意味がないということに、なるだろうか。それは後日に譲るとして、アップサンプリングデータの再生環境について、考えたほうが良いかもしれない。本領発揮は出来ていないのではないかという気がする。

ここで、突然だが、そもそもは上流サーバーをUPSにつないだことが現在の懸案の要因だということに立ち返る。
NASをUPSにつなぐのは致し方ない。
しかし、mpdサーバー（Tiny Core OSで電源ラインでオフ可）やスイッチングハブをつなぐ必要性はない。

ということで、UPSからそれらを外し、電源経路を分ける。
複数の音源や設定を変えての音質評価はこれからだけど、明らかに音がスッキリした。384、かなり本領を発揮している。
NASは、このままでいいのかな、仕方ないかな。
下流サーバーはUPSを外したら音が悪くなるのが、やはりこうなると謎だ。
44.1との比較。
384は音楽の色が増して、44.1のほうが地味になった。これも意外。まさか逆転するとは。
44.1は、静かになった。前のほうが派手で良かったという人もいるかもしれない。しかし、落ち着いたかな。音が大きく聴こえていたのが、なくなった。細かいニュアンスが出るようになった気がする。
情報量は、かなり僅差。しかし音の間の空間の情報に差が出る。そういうデリケートな表現に384の優位性が出る。そう、こういうところが聴こえるようでないと、384にする意味はない。

それにしても、384と44.1、両方とも良くなった感じ。
そして、ブラインドでは、かなり区別が難しいレベルになったと思う。

LANmuteだけど、抜け防止ピンをカットしてみた。
うちではやはり、切ったほうがいい感じだ。僅かだが荒れみが減る。
LANポートによっては、抜け防止ピンをカットしたらコネクタがポートから抜けて留まらなくなることがあるので、いらないLANケーブルのピンを切って挿しても抜けずに使えるかをポートごとに確かめないといけない。これは要注意なので記載しておく。

あと、アップサンプリングしないハイレゾ音源を聴いて比較する必要がある。まだできてない。

こうなってくると、以前はなんでノイズの影響が少なかったのかということも気になる。
ノイズが多い環境では、相対的にノイズの影響を受けにくいということはあるかもしれない。1年前のノイズが多かったであろう環境でも、そこそこの音が鳴っていたのは不思議だ。いや、アップサンプリングしかいい音に聞こえなかったという意味でも、それはいい音ではなかった、足りなかったのだろうかなあ。
それは今の音を聴いて思う。
簡単にそういうこと言っては誤るんだけど。
1年前の記憶との比較だから、曖昧になるのも仕方がないところがある。

今回は、大した内容はない。
デジタル音源を扱うストレージは悩ましいという話。

若い頃にデジタルだから音は同じと聞かされ続けたせいか、理屈や体験で理解はできても、未だに「同じ01なのに音が変わる」ことについて、違和感がある。同じデータなら同じ音で鳴ってほしいと思ってしまう。
NAS音源とストリーミングで音が違うのを、同等にしたいと思う。
まあ、その一方で、USB HDDによって音が違うのは、なるほどなあって感じで受け入れているのだけど。

とあるオーディオ評論家が、苦言を呈しておられる。
ジッターの影響を減らすように配慮した音源をイベントで用意しても、オーディオ業者は理解していないので無意味になるということらしい。音質が良くないUSBメモリに音源を入れてくる、配慮した音源を業務用のパソコンに保存される、など。
せっかく配慮した音源を用意しても、周囲の無理解で音源の優位性が失われる。
お気持ちはお察しする。

しかし、僕はむしろ、デジタルコピーしても音質劣化しないようにするにはどうしたらいいのか、を知りたい。

アナログなら評価が定まった良質音源を探すことが出来る。
デジタルではそうもいかない。
形が変わらないアナログと違って、デジタルはコピー、転送、ユーザーの手元で品質がコロコロ変わる。
変わっても元のデータは同じ。

アナログディスクは割れたらおしまい。
デジタルデータはバックアップがあればストレージが壊れても残る。
データは同じだが、アナログの良質音源とは違って「ジッターを帯びた不完全な音源」となる。いや、デジタル音源はすべて、そういうレッテルを、ユーザーが自身によって張り付けざるを得ない。
あるいは、「01だから同じ」と割り切るのかな、、、

ストレージ、USBメモリやHDD、リッピングやコピーの方法、何がいいのか分からない。音源やコンポと違って、批評や評価がないからだ。特定の商品でそういった配慮をしたものはあるけど少数で、技術的なアドバンテージが明確な根拠をもって語られることが、あんまりない気がする。説明があっても、素人にしたら煙に巻かれる様だ。

一方、どのような環境、状況で使うかによって音質は変わるので、素人による製品や手法の評価はままならない。
以前はどんなドライブがいいとかあったが、最近はあんまり見なくなった。いいのがないという話もみたことがあったが、それすら最近はない。

結果、入手した製品を手探りで可能な限り上手く使うしかないのではないか、と言わざるを得なくなる。
その一方で、ストレージのジッターに配慮しない者が多数な世間では、良質な媒体や製品を提供しようとする者への、黙殺ならいいほうで、中傷や批判が主流派として罷り通る。

デジタルコピーしても音質劣化しないようにする、あるいは悪影響を最小限にする方法を、知ることができない。
それは、そういう方法が求められていないから、ということでもある。
もしかしたら、今までの経緯、数十年のデジタルオーディオの変遷の中で、諦められたからかもしれない。

技術的に一般化することが困難なのであれば、ユーザーが戸惑い立ち止まっても、仕方がない面がある。
それは、まじないとかオカルトと言われても反論できないということだ。でも、そうなのかね？

現実にHDDが違えば音が違うが、そうはいっても、実装の仕方でも環境要因でも評価は変わるだろう。簡単にどの製品がいいとも、言いにくいんじゃないかと思う。
そういう意味で、個別の製品は、批評や評価の対象になりにくいと想像する。

だったら、ユーザーが入手できる雑多な製品をユーザーなりに可能な限り上手く使えるようにする、そういう手法やノウハウを、どこかで誰かが提示すべきじゃないだろうか。それも、技術的な根拠を十分に添えて。
できないのかな。それに、誰がするのよ。

でも、そういう状況が生まれてきたら、たぶん、ストレージ使用の悩ましさとか、デジタルオーディオのよく分からなさも、薄れるんじゃないかと思うのだ。
配慮された高価な製品がある一方で、コンシューマー向きで安価な製品を使いこなすノウハウもある。
そういう状況はアナログオーディオでは一般的だ。
デジタルオーディオは、オカルティックな空気の中で、技術とユーザーが分断されている（そうした状況が、いかがわしいYoutuberが再生回数を稼いだりする温床になっている気がする）。

あんまり良くないと思うのだ。
いかがなものだろう。
今に始まったことではないし、難しいんだろうがなあ。

話は変わるけど、そんな面倒なノウハウを考える必要が少ないフォーマットとして、MQAが生まれたと僕は思う。
そういう意味で、技術を潰すのは惜しいと思っている。

最近、オーディオサーバーのノイズ対策に、筐体内に銅メッシュを仕込むというのを試みている。

まずPPAP Back-End、Middle-Endときて、Daphileサーバー2台に仕込んだ。
次に、mpdサーバーに仕込む。
mpdサーバーはPPAP Frontであり、UPnPレンダラーでもある。うちではそういう構成で運用している。

まず、テスト用mpdサーバー。
機種は、Hp Elitebook 820 G2。中古のノートPCだ。OSはTiny Core 64 11.1。
仕込み中の写真は撮り忘れた。
銅メッシュはキーボードの裏側に置ければ良かったんだけど、分解の手間が多い。本体の底面側を開けるのは簡単なので、そこに絶縁用の藁半紙と一緒に設置した。GNDはファンの縁の地金に銅メッシュを押し付けて取ることに。
気になるのは、銅メッシュの設置位置が筐体の空気吸入孔に重なるので、冷却機能に影響しないかということ。あまり温度が上がるようなら、設置場所を再検討しないといけない。

前回エントリーと同様の方法で、温度を確認した。
3秒ごとの数値を5分間計測しtxtファイルに打ち出し、それを集計し電卓等を使って平均値を出す。

tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt
[ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt

44438 (min:44000 max:45000)

音を出していないときの温度は、若干、上がった。風通しが悪いからか、、、

次に、音楽を鳴らしてどうなるか確認した。
ちなみに前エントリー以降、温度計測に際して音源に使っているのは下記CD box、1枚目CDのリッピングflacファイル。NAS音源だ。
Quator Danel - Shostakovich - The Complete String Quartets
https://www.discogs.com/release/8599892

Fastest、192kHz
47926 (min:47000 max:50000)

Fastest、768kHz
51383 (min:48000 max:58000)

Medium、768kHz
57876 (min:51000 max:65000)

Best、192kHz
56093 (min:53000 max:62000)

銅メッシュをつける前と比べたら、若干温度は下がっているのかな。どうだろう。

音質はどうなのか。
Medium、768kHzで鳴らす。
ぐっと、良くなった、気がする。何より色合いが濃くなって力強くなった。以前のテスト系 Medium 768kHzは、メイン系のBest 384kHzと比べたら、良く言えばスマートでモニター的だが線が細い印象だったんだけど、厚みが出てきた。

NAS音源でメイン系と比較してみる。libsamplerateの設定が違うので、音は違う。しかし差異はかなり小さくなった気がする。ブラインドでの聞き分けは、僕には出来ないだろう。

ストリーミング音源はどうだろうか。上述した音源は、Deezerにもある。
以前より、ずっと良くなっていると感じる。
NAS音源との比較では、差はある。比較したらNASの方がキレが良くて生命力が強いのだ。若干、情報量も多いような気がする。しかし、以前よりも差は減った。ブラインドで当てるのは、かなり聞き慣れた音源でないと難しそうだ。

テスト系とメイン系で、ストリーミング音源再生を比較してみる。
設定が違うので音も若干違うが、NAS音源のときと同様、音色の濃さがほぼ同等になった。
テスト系の音は、以前はクールで淡白な感触だった。それが銅メッシュを組み込んでからは、熱を帯びて鳴るようになっている。音色がメイン系に近付いて、色合いが濃くなったような感じだ。同時に、余音のような、音と音の間を埋めるような音が、より明瞭にリアルになった感触がある。
なんというか、これだけ聴いていたら、ストリーミングだけで何が不満なのか、という感じに鳴っている。

ここでテスト系とメイン系、mpdの設定を同じにして比較してみる。
メイン系をテスト系に合わせて、Medium 768kHzに。これはテスト系サーバーにとっては相当重く、メイン系サーバーにとっては比較的軽い操作だ。
音源はストリーミング。
温度だけ見たら、テスト系は20℃近く、メイン系は15℃弱ぐらい上がるようだ。
音は、メイン系の方に余裕があるようで僅かに反応が早い。ブラインドでは分からないんじゃないかな。
以前は、ここまで僅差ではなかった。それでも、この微妙な差は、もしかしたら重要な感じで、響きの美しさはメイン系の方が僅かに良いのかな。

ストリーミング音源使用時の温度。
前述のCDリッピング音源と同じ作品の、Deezer音源を使用した。下記が結果。

Fastest、192kHz
49952 (min:49000 max:51000)
Fastest、768kHz
53644 (min:51000 max:61000)
Medium、768kHz
60738 (min:53000 max:68000)
Best、192kHz
57295 (min:52000 max:63000)

やはり、温度は上がっている。UPnPの負担が増えているので当然か。
そういえば、銅メッシュなしのとき、ストリーミングでどうだったか、記録してないな、、、
銅メッシュを外して、ストリーミングで鳴らしてみた。結果は下記。

Fastest、192kHz
47786 (min:47000 max:49000)
Fastest、768kHz
53748 (min:51000 max:62000)
Medium、768kHz
60738 (min:53000 max:69000)
Best、192kHz
58291 (min:54000 max:64000)

温度はメッシュを付けているときよりも低いときがある。前回エントリーで挙げた、NAS音源を鳴らしていたときよりも低いときもある。銅メッシュで温度が下がるというのが、怪しくなってきた。筐体の蓋を開閉した直後に測ったせいかもしれないが、関係ないかもしれない。本当はもっと繰り返しデータを取るべきなんだろうが、そこまで取り組む根気はない。

銅メッシュを外すと、音は良くも悪くもクールになる。奥行、深みは少ないが、これはこれで、そんなに悪くはない。すっきりしていて涼しくて淡麗だ。しかし比較し評価するなら、メッシュがあるほうがいい。
温度を表にしておく。

	無音	Fastest、192kHz	Fastest、768kHz	Medium、768kHz	Best、192kHz
NAS	44000	47267	53019	59670	58452
Deezer		47786	53748	60738	58291
NAS (Cu+)	44438	47926	51383	57876	56093
Deezer (Cu+)		49952	53644	60738	57295

さて、次はメイン系mpdサーバーの処理だ。

他のサーバーに比べたら新しい。
機種は、Hp Probook 450 G9。OSはTiny Core 64 14.0。
作業に入る前に、銅メッシュなしの状態で温度のデータを取る。
mpdの設定は、Best、384kHzで固定。そのかわり、音を出してるときのデータは、4回取る。

音を出していないとき
47000 (min:47000 max:47000)

NAS音源
70896 (min:69000 max:73000)
71262 (min:64000 max:75000)
71705 (min:65000 max:75000)
71514 (min:70000 max:74000)

ストリーミング音源
71442 (min:66000 max:75000)
71252 (min:68000 max:74000)
71292 (min:69000 max:74000)
71609 (min:68000 max:74000)

以上、時系列。
NAS音源を鳴らし始めて3分後からデータをとり始めたけど、ちょっと早いのかもしれない。10分ぐらい待った方がよさそうだ（テスト系のときは数10分後から測り始めている）。

意外だったのは、テスト系ではストリーミング音源で温度が上がる傾向があったのに、メイン系では上がらないことだ。NASとストリーミングの音質の差と温度の差に相関関係がありそうだと思っていたのだけど。

いや、考えてみたら上流のデジタルデータを受け付けているmpdサーバーで、データが同じなのに（まあ、調べたわけじゃないけど、同じだと思うんだよね、、）、上流のサーバーが違ったら発熱量が違うほうが、本当はいけないのだ。
でもそこは、ジッターの差によって、負荷が違うのだろうと想像していた。
メイン系は新しい機種で性能も上で、処理能力が大きいので温度差が出ないのだろうか。

テスト系の音を聴き直してみる。設定は、Medium、384kHz。
たしかにNASとストリーミングでは音質に差があり、聴き比べたら、テスト系よりもメイン系の方が音質差は少ない。しかし少ないながらも、音質の差はあるのだ。CPUの温度には現れないレベルということなのだろうか。
そして、驚いたこと。
テスト系より、メイン系の方が、音が乾いて聴こえるのだ。テスト系の方が生々しい気がする。

テスト系を768kHzで鳴らしてみる。音の雰囲気が変わり、こうなると、メイン系との比較が出来なくなった。

メイン系に銅メッシュを仕込む。
筐体の底板を開けるのは比較的簡単。銅メッシュを仕込む隙間もある。
しかし、簡単にGNDがとれない。丸形端子をネジ止めできたらいいんだけど、意外に適当な使えるネジがない。銅メッシュにケーブルを半田付けし、その先の丸形端子を筐体の地金にテープで貼ることにした。
こんな感じ。

電源を入れ、しばし放置して温度を測る。

音を出していないとき
46000 (min:46000 max:46000)

NAS音源
70991 (min:69000 max:74000)
71154 (min:64000 max:74000)
72029 (min:70000 max:75000)
71775 (min:64000 max:74000)

ストリーミング音源
71775 (min:62000 max:75000)
70706 (min:56000 max:74000)
72010 (min:64000 max:75000)
72282 (min:71000 max:74000)

銅メッシュを設置する前より、温度はむしろ、上がっているかな。
音質はどうなのかというと、あんまりぱっとしない。良い方に変化した感じはしない。しかし、それより問題があって、なんだかサーバー自体が安定しない感じがするということだ。Daphileからのコントロールが不安定な感じ。
なにしろ、上手く行っていない。

温度が上がるのは良くない。
銅メッシュのサイズが大きすぎて冷却が上手くいっていないのかもしれないと考えて、メッシュの量を半分にして、やや小ぶりに、薄くした。細い針金を編んでいるので、切れ端から銅線がこぼれないように注意が必要だ（コンピューターに入れるので、切れ端が変なところに紛れ込んではまずいと思う）。

音はむしろ、そのほうが良いようだ。
硬い感じがとれて色彩感も出てきた。

温度を再計測。

音を出していないとき
47000 (min:47000 max:47000)

NAS音源
72375 (min:70000 max:75000)
71825 (min:67000 max:75000)
71571 (min:70000 max:74000)
71867 (min:64000 max:75000)

ストリーミング音源
71896 (min:69000 max:76000)
71328 (min:64000 max:74000)
72049 (min:69000 max:75000)
71961 (min:66000 max:75000)

温度は、あんまり、変わらない。
音はというと、それでも、どうにもすぐれない。
いくつか音源を聴くうちに、濁りがあるように感じられてきた。ベールのように霞みが掛かっている。そのせいか、見え方が違ってくる。遠くまでとどかないのだ。
副作用の方が強い。
銅メッシュを外す。
見通しの良い、以前の音が戻ってきた。

しかし、こうなってくると、テスト系の音も慎重に評価しないといけない。
何らかの歪みが、逆に心地良く聴こえているのかもしれない。GNDにものをつなぐときには注意が必要だ。しばしば反応は鋭敏でいいことばかりではない。
それにしても、2台の違いはどこから生じているのだろう。

ともあれ、しばらく、様子を見ていく。

現在のうちの環境では、Daphileでmpdサーバーに送るDeezerの音は、同じCD水準のデータでもNAS音源の音には及ばない。

前回のエントリーで、ストリーミング音源はupmpdcliがボトルネックになっていると考えたら、mpdサーバーへの対策が有効ではないか、銅メッシュをmpdサーバーのノイズ対策に使えば負荷が減るのではないか、と考えた。
ここでふと、mpdの負荷を減らしたいなら、アップサンプリングしなければいいんじゃないか、と思い付いた。

Daphileからmpdに送られるのは44.1kHz/16bitのPCMだ。それを何もせずPPAPで送れば、どう聴こえるだろう。
mpdサーバーの負担は減ると思う。
過去に試したときは、アップサンプリングした方が良かった。
今はどうだろう、ストリーミング、いや、UPnP音源だったら、どうなのか。

もともと、僕がアップサンプリングを使うようになったのは、コンピューターをオーディオに使い始めた頃に、SRC2496という機器を使ってアップコンバートして鳴らしていたことがある。これは音が良くなった。あと、壊れかけたNASの音源は、mpdによる非力なアップサンプリングでも音が良くなった。

こうしたことから、ジッターが多い環境では、アップサンプリングしたほうが音が良いのではないか、という仮説を思い付いた。なんでアップサンプリングで音が良くなるんだろう、というところから考え始めている。
つまり、そうした現実の理由付けとして考え始めた仮説だ。

そのうち、アップサンプリングと一言で言ってもいろんな手法があり、音も違うことが分かった。
手法で音が違うということは、DACに入力されるデータが異なっているということだ。
そして、DACチップ内でアップサンプリングするという知識も得る。

アップサンプリングによる音質改善の根拠は、DACチップ自体でアップサンプリング（オーバーサンプリング）するより、良質なアップサンプリングが出来る高スペックのPC等で代行したほうが良いという説明に、比重が移った。
というか、世の中でそういう説明が見られるようになった。
SRC（libsamplerate）などを使って良質なアップサンプリングを行うと音が良くなるのはなぜなのか、という問いの答えが、DACチップはナイキスト定理通りの理想的なDA変換が出来ないのでオーバーサンプリングして精度を高めるより他なく、DACへのデジタル入力前に、より良質なアップサンプリングを行うことが可能なら、そのほうがDA変換の精度が上がるから、ということに現在はなっている。
というのが僕の理解。

音の情報量自体はCDで充分だが、DA再生で充分な精度を出すには技術的限界があるから、理論だけで固めた理想論では済まない。だから高品質なアルゴリズムでアップサンプリングすることが有効ということだ。
精度が要らないなら、この限りではない。精度が出てなくても良い音はざらにある。精度が出ていさえすれば良いというものでもない。

そういうわけでアップサンプリングの品質は重要だと思うけど、ジッターを如何にして減らすかも同時に重要だ。
以前は、アップサンプリングすることでジッターの影響を少なく出来るのではと考えていたけど、今はそれだけで事足りるとは考えない。
ジッター対策は音色に効いてくる気がする。
というか、映画に例えてみると、サンプリング周波数やビット深度がフィルムの大きさ、つまり情報量に影響し、ジッター対策はピントに効いてくるとでもいうか、出てくる音の鮮度、色彩感、陰影に影響する。
両方を高めるのが、今のデジタルオーディオで高音質を得る近道だと思う。

正攻法は、安定して高精度なクロックだ。
しかしクロックを生かすには、ノイズや電源の対策が必須になる。ノイズや電源の上でクロック素子が動いているからだ。当然、デジタル信号そのものも、それらの上で動いている。デジタルで01だと言っても実体は電圧変動なのだから、ノイズや電源の影響を受けないわけがない。その影響こそがジッターということだ。

話が広がりすぎか。話を戻す。
何が言いたいのかというと、アップサンプリングを止めることで、音質は低下する。
しかしmpdサーバーの負担、仕事量が減るので、ジッターの減少、音質の向上に繋がるのではないか、ということ。

逆も言えることで、アップサンプリングを行えば音質は向上する。
しかしmpdサーバーの負担、仕事量が増えるので、ジッターの増加、音質の低下に繋がる。

では、どうすれば一番良い音になるのか、良好なバランスとなるのはどんな設定なのか、という考え方だ。
実際に聴いてみて、確かめるしか術はない。

さて。
うちでは2台のmpdサーバーが動いていて、1台はメイン使用で384kHzへのアップサンプリング用、もう1台はテスト用兼768kHzへのアップサンプリング用になっている。なんでわざわざ2台なのかというと、そのほうが設定切り替えの手間がないからだ。
PPAP Back-Endで両方の設定に対応するコマンドが動いていて、どちらのFrontからでも直ぐに音を出すことが出来る。
Back-Endでtopを打つとこんな感じ。

Mem: 93208K used, 3936688K free, 18376K shrd, 5560K buff, 34180K cached
CPU:  0.0% usr  0.0% sys  0.0% nic 99.9% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.00 0.00 0.00 2/109 1319
  PID  PPID USER 	STAT   VSZ %VSZ CPU %CPU COMMAND
 1318  1290 tc   	R 	4016  0.1   0  0.0 top
 1208  1092 root 	S	15484  0.3   0  0.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=2048 --buffer-size=16384 -t raw -f S32_LE -r384000 -c2
 1242 	1 tc   	S	15484  0.3   1  0.0 /usr/local/bin/ncat -kl 4444 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
 1286  1202 root 	S 	5872  0.1   0  0.0 sshd: tc [priv]

まず、テスト用サーバーの設定をいじって、アップサンプリング無しの音を出すことにした。
mpdサーバー（Front）をアップサンプリングしない設定に変更。
Back-Endでは、上記のtop表示だったら「kill 1242」で、テスト用のデータを受信するコマンドを止める。
改めて以下、コマンドを打つ。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd" &

うまくいかない。
音が出るまで時間が掛かり、音が出始めた後のコントロール、音量の調整や再生停止などの操作にすごく時間がかかる。数十秒もかかる。768kHzのデータの方が重そうなのに何でなのか、考えるうちに、もしかしたら、バッファーの設定が影響しているのではと思い付いた。

メインサーバーからのデータを受けるコマンドはrootで起動。テスト用サーバーからのはtc（ログインユーザー）で起動している。
コマンドは２つだが、aplay自体は、もともとひとつだ。

音源がCD同等だと、バッファーの数値はずっと小さくなる。音源データが小さいのでコマンドの設定もそれに合わせている。
しかしメイン用の方はもともと、大きい数値がバッファーに振られている。
多分、テスト用からの音源を鳴らしている時も、メイン用のコマンドが同時に動いているから、バッファーの設定がそっちのまま、大きいままなのではないか。
CD相等の音源にとって、それは過剰なバッファーとなる。
結果、操作に対する反応が遅くなる。mpdサーバーの出音を止めても、バッファーに溜まったデータが切れるまで、暫く音が出続けるのだろう。それが20秒前後にもなる。

どうするか。
そもそもの目的、サーバーの負荷を落とすということなら、アップサンプリングの「質」の設定を落とせばいいという考えもある。
テストサーバーのlibsamplerateの設定は「Medium」なので「Fastest」にしたら負荷は下がる。
そしてメインの384kHzに近い値で低めに設定したら、バッファー数値の影響は回避できないだろうか。
ままよ、やってみた。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=1024 --buffer-size=8192 -t raw -f S32_LE -r192000 -c2" &

これだと反応の遅れは数秒で、使用に耐える。
音色は良い。
768kHzよりも艶っぽい気がする。
しかし情報量は少なくなる。音像間で分離していた空間が、グラデーションで埋まる。まあ、768kHzと192kHzでは、デジタルデータの情報量は4倍の差があるので、仕方がない。768kHzは良くも悪くもモニター的になる。これは、どちらがいいのかという話になりそう。
テスト用といいながら僕が768kHzで鳴らす環境を維持しているのは、これはこれで捨てがたい面があるからだ。

しかし192kHzだと、USB-HDD音源とストリーミング音源の音の差は、かなり縮まったような気がする。
いや、ほんまかいな、と自分でも思うけど、たぶん縮まってるんじゃないかな（でも、こういうときの自分ってあてにならないんだよな、、）。
Fastest、192kHzの設定だけで比較したら、もうストリーミング中心でいいかもと思うかもしれない。

Back-Endで、メイン用の設定のほうを見直すという方法論もある。
大きいバッファーを小さく出来たら、テスト系への影響を小さく出来るのではないか。

そもそもなぜ、「--period-size=2048 --buffer-size=16384」という設定になっているのか、記憶にない。
たぶん、アップサンプリングするmpdサーバーの増大したバッファーの設定に、合わせて増やしただけだと思うのだ。
減らせるかもしれない。
とりあえず、「--period-size=512 --buffer-size=2048」まで減らした。
問題なく音は出ている。あらー、、、

この状態で、テスト系のアップサンプリングをやめて、まともに使えるかどうか、試してみる。
音の出方は、以前よりは良くなった。
しかし、不安定だ。途切れやすい。
mpdサーバーの方を調整。「audio_buffer_size」を増量、"2048"に。多少は安定したが、再生停止に10秒程かかる。
なんでかわからんが、mpdが音源データをどんどん先走って取り込んでいるようなのだ。Daphileなどのインターフェイスで見ると、曲の時間表示が実際よりもどんどん先に進んでいく。
これでは困る。

結局、多少はアップサンプリングしないと安定しないという、よくわからない状態で、今回はけりをつけることにした。
libsamplerateは「Fastest」、負荷軽減優先だ。
サンプリング周波数は、とりあえず192kHz。
テスト系を受けるBack-Endの設定は「--period-size=256 --buffer-size=2048」に、今はしている。
なんだか、あちこちバランス取りながらの設定で、詰めきれないままのことが今までにもよくあったような気がする。

気のせいかもしれないけど、Fastest、192kHzは、昔よりも良い音が出ている気がする。
ノイズ対策などを経て、ジッターが減っている分、改善があるのかもしれない。
USB-HDD音源とストリーミング音源の音の差も、Fastest、192kHzだったら前述したとおり、差異が少ない。なんとなく、バランスがいい音という印象で安心感がある気がする。

もともと、差異が少なければいいというものではない。
ストリーミングの音を底上げするにはどうしたらいいか、というところから始まった話だ。
しかしここに来て、設定による音の違いは無視できないような気がしている。ノイズ対策が落ち着いたら、どのような設定でどのような音になるのか、ゆっくり時間がある時に、確認したいと思うが、設定の要素が多いので、比較すると言っても単純な話ではない。
大仕事になる。あんまり突っ込んだことはしないかもしれない。

最後にちょっと、温度の比較（CPUだと思うんだけど、はっきりしない）。
テスト用サーバーでコマンドを打って確認してみた。

tc@box:~$ cat /sys/class/thermal/thermal_zone0/temp
44000

こんな感じ。
ただ、今回確認してみて、音を出している時の温度は、かなり変動することが分かった。負荷が多いときは上がるのだろう。

データ取得のために下記コマンドを使用。
5分間のデータを取得する。

tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt

数値だけ得られるならよかったんだけど、行頭に余計な文字列が付くのが残念。
このファイルを、普段使いのノートPCに移して、エディタで要らない文字列を削除して、下記のコマンドで数値を合計して、電卓で平均を計算する(小数点以下は四捨五入した)。
せっかくLinux使ってるんだから、もう少しスマートにやれそうだけど、スキルがない。

[ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt

44000

Fastest、192kHz
47267 (min:47000 max:48000)

Fastest、768kHz
53019 (min:47000 max:58000)

Medium、768kHz
59670 (min:51000 max:65000)

一番上は音を出していないとき、続いて、それぞれの設定で音を出したときの温度だ。
アップサンプリングの設定、負荷の違いで大きく温度が違うのが分かる。
驚いたのは、音を出していないときの温度は、ずっと44000で5分間一定だったこと。そういうものなんだろうか。あと、負荷が少ないと温度の変動も小さい。

メイン用サーバーは、Best、384kHzの設定で固定している。こっちも少し測ってみた。
データは載せないが、テスト用よりも若干温度が高いようだ。

早々に追記だけど、テスト用サーバー下記設定でデータを取ってみた。
アップサンプリングの周波数が低いと、温度の変動が少ないのかな。負荷の大きさとの関連は小さいのか。どうなんだろう。

Best、192kHz
58452 (min:57000 max:62000)

今回は、ちょこっと。

リッピングは相当の配慮をしないといけないという意見もある。
うちではけっこう、ざっくばらんだ。
しかし、こだわってる部分もあるので、このたび書いておく。

うちでは、リッピングしたファイルはNASに保存している。
こだわっているのは、リップしたファイルをどういう行程でNASに保存するか、だ。
つまり、リッピングするハード、ソフトには殆どこだわらない。

ソフトは、使い慣れているのでWindows / EACを使っている。
EACの使い方に付いては、１台のノートPCにUSB-DVDドライブを２つつないで、EACを２つ起動していっぺんに2枚のCDをリップしたりしているので、お世辞にも丁寧な扱いとは言えない。
AccurateRipがEACにはあるので正確性はある程度担保されるが、比較データなしとか他のデータと合わないと表示されることもある。そういうときは、エラーなしなら良しとしている。割り切ったもんである。

こだわり処はNASに保存する行程だ。

1. リッピングしたファイルは最初に、PCのハードディスクに保存される。
2. これをUSBメモリスティックにコピーする。
3. USBメモリスティックを、普段使用のノートPC（OSはLinux Fedora、家庭内LANにつながっている）に刺しなおす。
   このノートPCには予め、NASの音楽ファイル用共有ディレクトリがLAN経由でマウントされている。
4. USBメモリスティックから、NASの音楽ファイル用共有ディレクトリに、音源をコピーする。
   コピーには「cp」を使用する。
   cpとは端末ソフト上で使うコマンド。つまりファイルブラウザは使わないということだ。

こんな感じ。

僕の経験では、というか印象では、USBメモリを使わずハードディスクから直接にNASにコピーしたり、cpを使わずファイルブラウザ上でドラッグドロップしてコピーしたりするのは、音が悪くなる。所謂、デジタルくさい音と昔に言われたような、くぐもったような透明度の低い切れが悪い音、要するにジッターが多いんだろうな、という音になる、、、ような気がする。
気がするというのは、本気で試聴して比べたことがないからだ。
経験的に、こうしたらこうなったような気がするな、という印象である。

そういうわけで、ネットからダウンロードした音源なども同様で、いったんUSBメモリにコピーして、そこから「cp」でNASに保存するという行程を採っている。
ちゃんと確認してないけど、そういう気がするのでその行程は外さない。保守的である。というか、あつものにこりて、か。

以上、まじないのような話だ。

今回は、興味深いサイトがあったので備忘録に書いておこうという主旨。
サイトのオーナーはB&Oの関係者で、音楽技術分野の研究者とのこと。
https://www.tonmeister.ca/wordpress/about/

個人的には、いい加減な知識のままにしていた部分で、重要な知識だと思うので自分のためにも忘れないように、エントリー3回分で書いておく。
３、２、１の順でアップロードすることで、ブログ上では上から１、２、３と並ぶようにしてみた。そのほうが読みやすいはずだ。
何か必要があったら追記訂正するつもり。追記訂正の断りは入れない。見た目が煩わしいので。

しかし、良く分かっている人には、今更感がある内容だと思う。
というのは、出て来る用語をネット検索したら、10年前から残っている解説記事がぽろぽろ引っかかるのだ。どこかで目にしたなあ、ということがあったりする。
分かってる人には、これらは常識なんだと思う。
しかし僕なんかは系統的な知識になってないので、こういう機会でもないと理解が進まないということだ。あと、目についた記事だけ読んで難しすぎて身に付いてないことが往々にしてあるように思う。勉強不足に加えて、僕には難しすぎるのである。

Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/

デジタルオーディオ関係でジッターといえば「時間軸方向での信号波形の揺らぎ」とか「信号の時間的なズレや揺らぎ」とか説明される。
そんなひとことで表現されるジッターだが、原因は多種多様と聞いたことぐらいはある。聞いたことはあっても、その内実については詳しくは知らない。
上記サイトでは、そのジッターの分類について専門家側から説明してくれている。
そういうわけで、ちょっと旅しよう。

Jitter: Part 1 – What is jitter?

Jitter: Part 1 – What is jitter?
http://www.tonmeister.ca/wordpress/2018/08/08/jitter-part-1/

ここは初歩的な所から入る。
僕でも読みながら、うんうん、そういう感じだよね、という感じで読めるパートだ。

ひとつだけ、S-PDIFのデジタル信号の仕組みについて、ああ、そういう仕組みなのか、と分かったのは非常に良かった。オーディオ信号にクロックが乗ってるってどういう意味だろう？と昔から思っていたんだけど、説明があった。
簡単にいえば2bitから1bitを抽出するというか、on-onとoff-offが０で、on-offとoff-onが１、そういう信号で伝送したら、そこからクロックが抽出できるという感じ。英語版wikpedia（https://en.wikipedia.org/wiki/S/PDIF）にも書いてあるが、こちらのサイトの方が分かりやすい。

It’s important for me to note that the example I’ve given here about how that jitter might come to be in the first place is just one version of reality. There are lots of types of jitter and lots of root causes of it – some of which I’ll explain in this series of postings.

(translate by Google)
そもそもそのジッターがどのように発生するかについてここで示した例は、現実の1つのバージョンにすぎないことに注意することが重要です。さまざまな種類のジッターとその根本原因があります。そのうちのいくつかについては、この一連の投稿で説明します。

Jitter: Part 2 – Phase and Amplitude Jitter

Jitter: Part 2 – Phase and Amplitude Jitter
http://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-2/

In the previous posting, I talked a little about what jitter and wander are, and one of the many things that can cause it. The short summary of that posting is:
Jitter and wander are the terms given to a varying error in the clock that determines when an audio sample should (or did) occur.

Note the emphasis on the word “varying”. If the clock is consistently late by a fixed amount of time, then you don’t have jitter or wander. The clock has to be speeding up and slowing down.
One of the ways you can categorise jitter is by separating the problem into two dimensions – phase (or time) and amplitude.

(translate by Google)
前回の投稿では、ジッターとワンダーとは何か、そしてそれを引き起こす可能性のある多くのことの1つについて少し話しました。 その投稿の簡単な要約は次のとおりです。
ジッターとワンダーは、オーディオサンプルがいつ発生するか（または発生したか）を決定するクロックのさまざまなエラーに与えられる用語です。

「変化する」という言葉が強調されていることに注意してください。 時計が一定の時間だけ常に遅れている場合は、ジッターやふらつきはありません。 時計は速くなったり遅くなったりする必要があります。
ジッタを分類する方法の1つは、問題を位相（または時間）と振幅の2つの次元に分離することです。

ここで、ちょっと待って、である。
時間と振幅に分けるって、ジッターって時間の問題じゃなかったの？という。

信号の振幅の誤差がデジタル再生に影響するんじゃないのかというのは、僕自身も以前から考えてはいた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200531a.htm
以前のエントリーに書いたのは、DACチップのアナログ信号出力の正確性についての疑いで、それらの誤差も一緒くたにまとめて「ジッター」に括られてるんじゃないのか？という疑問だった。

ここでの話はそういうことではなく、デジタル信号の振幅誤差がデジタル信号のジッターを生むということ。
その内容自体は、納得できる説明だ。
というか、僕にはその知識は無かったが、以前からそうした概念については頭の中に仮説としてあって、しかし実はデジタル技術の世界ではとっくの昔に「振幅ジッター」という概念で説明が成されていたのだと、今回、僕がこのサイトを読んで理解し、得心したということだ。
ここでは「デジタル信号」の解説をしているので、DA変換出力の振幅誤差については関係ない話なので触れられていない、と理解している。

話を戻す。
このエントリーでは、ジッターには「phase jitter（位相ジッター）」と「amplitude jitter（振幅ジッター）」があると書かれている。原因が異なるため、システムの改善を目指すなら、生じているジッターの切り分けをすべき、ということかな。

僕が単純に考えて、
前者には、リクロック含むクロック周り。
後者には、電源とアースの強化とノイズの対策か。
切り分けが困難なら両方に対策するしかない。しかし実際にはもっと複雑な挙動への対策が必要かもしれない。たとえばクロックと言ったって、クロックにも電源があるのだ。キリがないので、どこでカタを付けるかだ。

ちょっとここからうだうだ長くなる。どうでもいい話だ。

僕を困惑させた文面があった。

Wrapping up

If you’re a system developer or if you’re trying to improve your system, you need to know whether you have phase jitter or amplitude jitter in order to start tracking down the root cause of it so that you can fix it. (If your car doesn’t start and you want to fix it, it’s good to find out whether you are out of fuel or if you have a dead battery… These are two different problems…)

However, if you’re just interested in evaluating the performance of a system, one thing you can do is simply to ask “how much jitter do I have?” (If your car doesn’t start, you’re not going to get to work on time… Whether it’s your battery or your fuel is irrelevant.) You measure this, and then you can make a decision about whether you need to worry about it – whether it will have an effect on your audio quality (which is a question that not determined so much by the amount of jitter that you have, but where it is in your system, and how the “downstream” devices can deal with it).

(translate by Google)
まとめ

システム開発者の場合、またはシステムを改善しようとしている場合は、問題の根本原因を突き止めて修正できるように、位相ジッターまたは振幅ジッターのどちらがあるかを知る必要があります。 （車が始動せず、修理したい場合は、燃料がなくなっているのか、バッテリーが切れているのかを確認することをお勧めします…これらは2つの異なる問題です…）

ただし、システムのパフォーマンスを評価するだけの場合は、「どのくらいのジッターがありますか？」と尋ねるだけで済みます。 （車が始動しない場合は、時間どおりに仕事をすることができません…バッテリーか燃料かは関係ありません。）これを測定すると、心配する必要があるかどうかを判断できます。それ–それがあなたのオーディオ品質に影響を与えるかどうか（これはあなたが持っているジッターの量によってそれほど決定されない質問ですが、それがあなたのシステムのどこにあるか、そして「下流」のデバイスがそれをどのように扱うことができるか）。

『システムのパフォーマンスを評価するだけの場合は、「どのくらいのジッターがありますか？」と尋ねるだけで済みます』というのは、大雑把過ぎるのではなかろうか。

電気信号の振幅が正確であるためには、電源やGND電位が安定している必要があると、僕は理解している。
最近は、電源やGNDに気を配るのはデジタルオーディオの「いろはのい」みたいなことになっている。誰が言い出したのか、メーカーや技術者側からなのかユーザーサイドからなのか、よく知らない。
どんな電源がいいとかバッテリーがいいとか電柱がいいとか、ノイズ軽減にはどうしたらいいとか仮想アースがどうとか、いろんな知見や試みがある、その一方でどうして効果があるのか、明確な説明は無かったような、分かるような分からないような、そんな感じではなかったか。

しかし、電気信号の振幅誤差も、時間の誤差とまとめてジッターになるんだよ、と。
今までもジッターといえば実は両方を含んでたんだよ、と。
だったら、デジタル系の電源やアースの強化、安定化を目指す必要があるというのは、ジッター対策と考えたら自明なことだ。いつからそうなった？昔からか。。。

デジタルでの音質の劣化は「時間軸方向での信号波形の揺らぎ」が原因で、それをジッターと読んでいた筈だ。
振幅も問題だということなら、「ジッターだけではなく振幅も問題だ（と分かった）」と表現するべきではないのか。
それか「ジッターは時間軸方向の揺らぎで、振幅の揺らぎはほにゃららと呼ぶのだ」とするか。
いや、結果の実態としては同じだからジッターでくくればいいと、、、いや結果が同じでも切り取り方が違ったら受け取り方も対策も違うでしょうに、、、
しかし考えてみたら、ジッターの定義？が「時間軸方向での信号波形の揺らぎ」ということで、もともと原因が何かは問わないのだ。だったらくくっても問題はないという理屈。

そういうわけで、不勉強な僕の言うことが間違ってるんだと思うが、そういう感じで、納得いかない。
納得がいかないとか言ったって、ずっと昔に御布令が出てるのに、いつの間に出してんだ知らねえんだよべらぼうめぇとか言っても言う方がバカで打ち首である。

以上、どうでもいい話だ。

どうでもいい話で長くなりすぎた。次のエントリーに続く。今回のエントリーは横道に逸れすぎである。

前回に引き続き、earfluff and eyecandy によるJitterの解説について読んでいる。

Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/

今回はPart 3から。

Jitter: Part 3 – Classifying Jitter

Jitter: Part 3 – Classifying Jitter
http://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-3/

Part 2では、ジッターを位相ジッターと振幅ジッターという見方で分けた。
ここでは、別のジッターの分類について触れている。
以下、表にする。

total jitter	random jitter
	deterministic jitter (correlated jitter)	periodic jitter
		data-dependent jitter	inter-symbol interference
			duty cycle distortion
			echo jitter

Part 4でRandom Jitter、Part 5でDeterministic Jitterについて説明がある。

日本のサイトで用語の解説がある。
random jitter（ランダム・ジッタ）、deterministic jitter（デターミニスティック・ジッタ）
Posted on 2014年12月24日
http://www.de-pro.co.jp/2014/12/24/8209/

Jitter: Part 4 – Random Jitter

Jitter: Part 4 – Random Jitter
https://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-4-random-jitter/

You have a signal (the audio signal that has been encoded as a digital stream of 1’s and 0’s, sent through a device or over a wire as a sequence of alternating voltages) and some random noise is added to it for some reason… (Maybe it’s thermal noise in the resistors, or cosmic radiation left over from the Big Bang bleeding through the shielding of your S-PDIF cable, or something else… )

What we’re really talking about is that the jitter is modulating the signal that carries your audio signal – not the audio signal itself. This is an important distinction, so if that last sentence is a little fuzzy, read it again until it makes sense.

(translated by google)
信号（1と0のデジタルストリームとしてエンコードされ、デバイスを介して、または一連の交流電圧としてワイヤを介して送信されたオーディオ信号）があり、何らかの理由でランダムノイズが追加されています…（多分 それは、抵抗器の熱ノイズ、またはビッグバンから残った宇宙放射がS-PDIFケーブルのシールドを介して出血していることなどです…）

私たちが実際に話しているのは、ジッターがオーディオ信号自体ではなく、オーディオ信号を運ぶ信号を変調しているということです。これは重要な違いなので、最後の文が少し曖昧な場合は、意味がわかるまでもう一度読んでください。

1 Timing errors of the clock events relative to their ideal positions
2 Timing errors of the clock periods relative to their ideal lengths in time

These are very different – although they look very similar.

The first is an absolute measure of the error in the clock event – when did that single event happen relative to when it should have happened? Each event can be measured individually relative to perfection – whatever that is. This is called a Phase Modulation of the carrier. It has a Gaussian characteristic (which I’ll explain below…) and has no “memory” (which is explained first).

The second of these isn’t a measure of the events relative to perfection – it’s a measure of the amount of time that happened between consecutive events. This is called a Frequency Modulation of the carrier. It also has a Gaussian characteristic (which I’ll explain below…) but it does have a “memory” (which is explained using Figure 1).

(translated by google)
1 理想的な位置に関連するクロックイベントのタイミングエラー
2 時間の理想的な長さに対するクロック周期のタイミングエラー

これらは非常に異なりますが、見た目は非常に似ています。

1つ目は、クロックイベントのエラーの絶対的な測定値です。その単一のイベントは、発生するはずだった時期と比較して、いつ発生したのでしょうか。 各イベントは、それが何であれ、完璧に関連して個別に測定できます。これは 、搬送波の位相変調と呼ばれます。ガウス特性（以下で説明します…）があり、「メモリ」（最初に説明します）がありません。

これらの2つ目は、完全性に関連するイベントの測定値ではありません。これは、連続するイベント間で発生した時間の測定値です。これは、搬送波の周波数変調と呼ばれます。また、ガウス特性（以下で説明します…）がありますが、「メモリ」（図1を使用して説明）があります。

ちょっと引用だけではなんだかよく分からない。
元サイト原文のほうに図が掲載されている。しかし、ガウス分布は分かるんだけど、位相変調と周波数変調については、よく分からない。
位相変調は、その瞬間だけに影響するもので、周波数変調はその後の信号にも影響を与える（「記憶」と表現されている）ということらしい。
いろんな原因でランダムに生じるジッターがあり、その瞬間だけ影響するものと、後まで影響するものに分けられる、という理解で、とりあえずいいのかな。

Jitter: Part 5 – Deterministic Jitter

Jitter: Part 5 – Deterministic Jitter
https://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-5-deterministic-jitter/

Deterministic jitter can be broken down into two classifications:

1 Jitter that is correlated with the data.
This can be the carrier, or possibly even the audio signal itself

2 Jitter that is correlated with some other signal
In the second case, where the jitter is correlated with another signal, then its characteristics are usually periodic and usually sinusoidal (which could also include more than one sinusoidal frequency – meaning a multi-tone), although this is entirely dependent on the source of the modulating signal.

(translated by google)
決定論的ジッタは、次の2つの分類に分類できます。

1 データと相関するジッタ。
これは、キャリア、または場合によってはオーディオ信号自体である可能性があります

2 他の信号と相関するジッタ
ジッタが別の信号と相関している2番目のケースでは、その特性は通常 周期的であり、通常は正弦波です（複数の正弦波周波数を含む場合もあります-マルチトーンを意味します）が、これは変調信号のソースに完全に依存します。

まず、決定論的ジッタはデータ依存ジッタと周期ジッタとに分けられるとのこと。
データ依存ジッタには、Intersymbol Interference（符号間干渉：ISI）、Duty Cycle Distortion（デューティ・サイクル歪み：DCD）、Echo Jitter（エコージッター）があるということで、ここではそれらを順番に説明している。

ランダムジッタは予測不能だけど、決定論的ジッタは瞬間毎にどのように動作するかを「予測可能」とのこと。予測可能というのは、僕には意外だった。たぶん僕が考える予測と、サイトオーナーが記載している予測は、どこか意味が違うんだろうと思う。
読んでいて、僕が持っているジッターのイメージに説明内容が近いものは理解しやすかったような気がする。気がするというのは、本当に分かったのかどうかがおぼつかないからだ。
イメージがつかめないものは、分かりにくい。

データ依存のジッター

Data-Dependent Jitter

Data-dependent jitter occurs when the temporal modulation of the carrier wave is somehow correlated to the carrier itself, or the audio signal that it contains. In fact, we’ve already seen an example of this in the first posting in this series – but we’ll go through it again, just in the interest of pedantry.
We can break data-dependent jitter down into three categories, and we’ll look at each of these:

(translated by google)
データ依存のジッタは、搬送波の時間変調が搬送波自体、または搬送波に含まれるオーディオ信号と何らかの形で相関している場合に発生します。実際、このシリーズの最初の投稿でこの例をすでに見てきましたが、衒学者のためだけに、もう一度説明します。
データに依存するジッターを3つのカテゴリに分類でき、それぞれを見ていきます。

データ依存って何だと思うけど、データ信号そのものに乗るジッターで、以下の３つに分類されるということらしい。
しかし、本当に３つだけなのか？と考えてしまう自分がいる、、、たぶん何か分かっていないのだ。

符号間干渉

ケーブルで伝送されるうちに、信号の方形波の波形が崩れていくということらしい。
理想のケーブルは現実には存在しないからとのこと。
参考：
https://en.wikipedia.org/wiki/Intersymbol_interference

デューティサイクル歪み

If your transmission system is a little inaccurate, then it could have an error in controlling the duty cycle of the pulse wave. Basically, this means that it makes the transitions at the wrong times for some reason, thus creating a jittered signal before it’s even transmitted.

(translated by google)
伝送システムが少し不正確な場合は、脈波のデューティサイクルの制御にエラーが発生する可能性があります。基本的に、これは、何らかの理由で間違ったタイミングで遷移を行うことを意味します。したがって、送信される前にジッター信号が作成されます。

これは正直良く分からない。
技術実装の問題なんだろうか。
参考：
https://en.wikipedia.org/wiki/Duty_cycle

思い当たるのは、音源を置くHDDによって音が違うというような事象のことを言っているのかもしれない。違うかもしれないけど。

エコージッター

What many people don’t know is that, if you stand in a long corridor or a tunnel with an open end, you will also hear an echo, bouncing off the open end of the tunnel. It’s not intuitive that this is true, since it looks like there’s nothing there to bounce off of, but it happens. A sound wave is reflected off of any change in the acoustic properties of the medium it’s travelling through. So, if you’re in a tunnel, it’s “hard” for the sound wave to move (because there aren’t many places to go) and when it gets to the end and meets a big, open space, it “sees” this as a change and bounces back into the tunnel.

Basically, the same thing happens to an electrical signal. It gets sent out of a device, runs down a wire (at nearly the speed of light) and “hits” the input of the receiver. If that input has a different electrical impedance than the output of the transmitter and the wire (on other words, if it’s suddenly harder or easier to push current through it – sort of….) then the electrical signal will (partly) be reflected and will “bounce” back down the wire towards the transmitter.

(translated by google)
多くの人が知らないのは、長い廊下や開放端のあるトンネルに立つと、トンネルの開放端で跳ね返るエコーも聞こえるということです。跳ね返る物が何もないように見えるので、これが真実であるというのは直感的ではありませんが、それは起こります。音波は、通過する媒体の音響特性の変化によって反射されます。したがって、トンネル内にいる場合、音波が移動するのは「困難」であり（移動する場所が少ないため）、音波が終わりに到達して大きなオープンスペースに出会うと、音波は「見えます」。これは変更としてトンネルに跳ね返ります。

基本的に、同じことが電気信号にも起こります。それはデバイスから送信され、（ほぼ光速で）ワイヤーを伝わり、レシーバーの入力に「ヒット」します。その入力が送信機とワイヤーの出力とは異なる電気インピーダンスを持っている場合（言い換えると、電流を押し込むのが突然困難または容易になった場合-ある種…。）、電気信号は（部分的に）反射され、送信機に向かってワイヤーを「バウンス」します。

エコージッターはインピーダンスの問題で生じるらしい。
デジタルケーブルのインピーダンスを合わせるのは大事なことらしい。

周期性ジッター

Periodic Jitter

We press play on the CD, and the audio signal, riding on the S-PDIF carrier wave is sent through our cable to the DAC. However, the signal that reaches the DAC is not only the S-PDIF carrier wave, it also contains a sine wave that is radiating from a nearby electrical cable that is powering the fridge…

CDの再生を押すと、S-PDIF搬送波に乗ったオーディオ信号が、ケーブルを介してDACに送信されます。ただし、DACに到達する信号は、S-PDIF搬送波であるだけでなく、冷蔵庫に電力を供給している近くの電気ケーブルから放射されている正弦波も含まれています…

周期性ジッターについて最後に書かれている。
データ信号とは関係がなく、他の信号と相関するジッタで、多くは周期的に変動するということだ。
冷蔵庫のコンセントにノイズ対策したらコンポの音が良くなったというような、世間では都市伝説めいた扱いをされているあれである。うちの冷蔵庫にもノイズフィルターをかませている。
そうした外来ノイズによって生じるジッターや、システム内でも取り切れなかったノイズとか（電源のノイズとかかな、、）、そうしたものということのようだ。

紛らわしいので一応、書いておく。「Periodic Jitter」は、クロックジッターなどで説明される「周期ジッター（Period jitter / Cycle Jitter）」とは、別物？らしい。
ここらはまだよく分からない。
ジッターは切り取り方によって呼び方がころころ変わるようで、そういうのも分かりにくい原因だと思う。

分かりやすい例から何を言ってるのか分からないようなものまで、ジッターの原因には色々ある。
エントリーの最後に、これらの影響がデジタル信号に積み重なったらどんな影響があるかを図にしている。

Part 6以降は、また切り口が変わるので、今回はここまで。

前回、前々回に引き続き、earfluff and eyecandy によるJitterの解説について読んでいる。
今回が最後だ。

Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/

今回はPart 6から。

Jitter: Part 6 – What is Affected?

Jitter: Part 6 – What is Affected?
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-6-what-is-affected/

So far, we’ve looked at what jitter is, and two ways of classifying it (The first way was by looking at whether it’s phase or amplitude jitter. The second way was to find out whether it is random or deterministic.) In this posting, we’ll talk about a different way of classifying jitter and wander – by the system that it’s affecting. Knowing this helps us in diagnosing where the jitter occurs in a system, since different systems exhibit different behaviours as a result of jitter.

これまで、ジッターとは何か、およびそれを分類する2つの方法を見てきました（最初の方法は、位相ジッターか振幅ジッターかを調べることでした。2番目の方法は、ランダムか決定論かを調べることでした）。この投稿では、影響を受けているシステムによって、ジッターとワンダーを分類する別の方法について説明します。これを知ることは、システムのどこでジッターが発生するかを診断するのに役立ちます。これは、システムが異なれば、ジッターの結果として異なる動作を示すためです。

We can put two major headings on the systems affected by jitter in your system:

data jitter
sampling jitter

If you have data jitter, then the timing errors in the carrier signal caused by the modulator cause the receiver device to make errors when it detects whether the carrier is a “high” or a “low” voltage.
If you have sampling jitter, then you’re measuring or playing the audio signal’s instantaneous level at the wrong time.
These two types of jitter will have different effects if they occur – so let’s look at them in the next two separate postings to keep things neat and tidy.

システム内のジッターの影響を受けているシステムには、次の2つの主な見出しを付けることができます。

データジッター
サンプリングジッター

データジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。
サンプリングジッターがある場合は、瞬間的なオーディオ信号レベルを、間違った時間のタイミングで測定したり再生している状態になります。
これらの2つのタイプのジッターは、発生した場合に異なる影響を及ぼします。したがって、次の2つの別々の投稿でそれらを見て、物事をきちんと整理してください。

Part 6は短いので、全文引用した。
しかし、googleまかせではちょっと問題かと思ったので、僕が手を入れることにした。どうだろうね。

Jitter: Part 7 – Data Jitter

Jitter: Part 7 – Data Jitter
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-7-data-jitter/

ここは、正直良く分からない、、、

Part 6で書いてあったことは、『データジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。』とのこと。
要はキャリア信号自体に乗っかる形で影響するジッターという理解でいいのだろうか。

Part 7では「Peak-to-Peak error」、「RMS error」という言葉が出てくる。
これらの用語は、デジタルオーディオの本などでクロックジッター、周期ジッター（Period Jitter）というジッターの説明に出てくるようなんだけど（前に書いたけど、Periodic Jitterとperiod Jitterは、別の概念のような？）、それが、ここに出てきている。
データジッターという言葉は、そもそもグーグル検索で殆んど引っかかって来ない。data jitterなら多少はあるのだけど。なんだか、いろいろ謎である。

説明で「ランダムジッター」を想定している。
説明内容にあるような、ランダムジッターが多すぎたら読み取りエラーを生じるようになるのは、理解できる。
しかしデータジッターは、ランダムジッターだけなんだろうか。
ちょっと、そこの辺りがよく分からない。
もっといろんな作用が起こってると考えないと説明しにくいことがあるような気がする。

あと、ジッターでデータエラーを生じるような悪劣な環境でオーディオをやっているという想定は、かなり限定された状況のような気がする。
データエラーまで生じなくても、データジッターは音に影響するはずなのだ。
そこに触れてないようなのが、よく分からないところ。
技術的に説明しにくいのだろうか。まあ、僕が見当違いを言ってる可能性もある。

Jitter: Part 8.1 – Sampling Jitter - Jitter in the Analogue to Digital conversion

Jitter: Part 8.1 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/28/jitter-part-8-1-sampling-jitter/

ここでは、AD変換について説明している。
個人的には過去に見たことがあるような内容が多いし、あんまり注意して読まなくてもいいかなと思ったら、そうでもないような。

エントリーの下の方に、ジッタの量が一定に保たれている場合に、振幅エラーの量は信号の傾きに応じて変調する、というのを「図6」に示している。「赤い曲線は、サンプルごとの誤差（ジッター信号から元の信号を差し引いたもの）を拡大してプロットしたもの」との、説明がある。

Secondly, if the amount of jitter is kept constant, then the amount of amplitude error will modulate (or vary) with the slope of the signal. This is illustrated in Figure 6, below.

Fig 6. The blue curve is a sine wave to which I have applied excessive amounts of jitter with a Gaussian distribution. The red curve is the sample-by-sample error (the original signal subtracted from the jittered signal) plotted on a magnified scale. As can be seen, the level of the instantaneous error is proportional to the slope of the signal. So, the end result is that the noise generated by the jitter is modulated by the signal. (If you look carefully at the blue curve, you can see the result of the jitter – it’s vertically narrower when the slope is low – at the tops and bottoms of the curve.)

AD変換で、これがデジタル音楽データに乗ったらおおごとだと思うんだけど。
これと同等のことが、DA変換でも起こり得ることじゃないのかと思う。
つまり「図6」の赤い線（線というより塗りつぶされてるが）は、ジッターがアナログ再生音を濁らせる、その様子が可視化されているのではないかと。
ADで起きることなら、DAで起きても不思議はないと思うのだけど、見当違いかもしれないが。

Jitter – Part 8.2 – Sampling Jitter - Jitter in the Digital to Analogue conversion

Jitter – Part 8.2 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-2-sampling-jitter/

part 8.2では、DA変換について説明している。
オーディオ再生だったらこっちがメインだと思ったら、たぶん8.1で説明した内容と多くが被るのだろう、ごく簡単にすませている。
まあ、ジッターの説明でよく見る絵が描いてある。

文末に「I’ve completely omitted the effects of the anti-aliasing filter and the reconstruction filter – just to keep things simple.（単純化するために、アンチエイリアシングフィルターと再構成フィルターの効果を完全に省略しました。）」とある。

Jitter – Part 8.3 – Sampling Rate Conversion

Jitter – Part 8.3 – Sampling Rate Conversion
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-3-sampling-rate-conversion/

ここではサンプリングレート変換について書いてある。
しかし、そんなに多くは書かれていない。

Synchronous Sampling Rate Conversion（同期サンプリングレート変換）とAsynchronous Sampling Rate Conversion（非同期サンプリングレート変換）についての説明がある。
うちで行っているのは、非同期のほうだ。

The good news is that, if the clock that is used for ASRC’s output sampling rate is very accurate and stable, and if the filtering that is applied to the incoming signal is well-done, then an ASRC can behave very, very well – and there are lots of examples of this. (Sadly, there are many more examples where an ASRC is implemented poorly. This is why many people think that sampling rate converters are bad – because most sampling rate converters are bad.) in fact, a correctly-made sampling rate converter can be used to reduce jitter in a system (so you would even want to use it in cases where the incoming sampling rate and outgoing sampling rates are the same). This is why some DAC’s include an ASRC at the input – to reduce jitter originating at the signal source.

(trranlated by google)
幸いなことに、ASRCの出力サンプリングレートに使用されるクロックが非常に正確で安定していて、着信信号に適用されるフィルタリングが適切に行われている場合、ASRCは非常に適切に動作できます。この例はたくさんあります。（残念ながら、ASRCの実装が不十分な例は他にもたくさんあります。これが、多くの人がサンプリングレートコンバーターが悪いと考える理由です。ほとんどのサンプリングレートコンバーターが悪いためです。）実際、正しく作成されたサンプリングレートコンバーターを使用できます。システムのジッターを減らすため（したがって、着信サンプリングレートと発信サンプリングレートが同じ場合にも使用する必要があります）。これが、一部のDACの入力にASRCが含まれている理由です。これは、信号ソースで発生するジッターを低減するためです。

サンプリングレート変換でジッターを減らせると、なんと、ここでお墨付きがもらえた！
うまく実装したらという条件付きだけど。

Jitter – Part 9 – When do I care?

Jitter – Part 9 – When do I care?
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-9-when-do-i-care/

In order to talk about WHEN we care about jitter, we have to separate jitter into the categories of Data Jitter and Sampling Jitter

ジッタを気にする場合について話すには、ジッタをデータジッタとサンプリングジッタのカテゴリに分類する必要があります。

このPart 9で最後だ。

データジッターに関しては、機械と接続ケーブルをちゃんと使えと書いてある（うーむ、、、）。
サンプリングジッターのほうのまとめも、大したことは書いてないかな。

Can you hear jitter?

The simple answer to this these days is “probably not”. The reason I say this is that, in modern equipment, jitter is very unlikely to be the weakest link in the chain. Heading this list of likely suspects (roughly in the order that I worry about them) are things like

• aliasing artefacts caused by low-quality sampling rate conversion in the signal flow (note that this has nothing to do with jitter)
• amateurish errors coming out the recording studio (like clipped signals, grossly excessive over-compression, and autotuners) (and don’t get me wrong – any of these things can be used intentionally and artistically… I’m talking about artefacts caused by unintentional errors.)
• playback room acoustics, loudspeaker configuration and listener position
• artefacts caused by the use of psychoacoustic CODEC’s used to squeeze too much information through too small a pipe (although bitrates are coming up in some cases…)
• Dynamic range compression used in the playback software or hardware, trying to make everything sound the same (loudness)
• low-quality loudspeakers or headphones (I’m thinking mostly about distortion and temporal response here
• noise – noise from the gear, background noise in your listening room… you name it.

So, if none of these cause you any concern whatsoever, then you can start worrying about jitter.

最近は、昔ながらの「デジタルっぽい」音源は、ほとんど全く無くなった。
それどころか、昔のCDでも最近の機械で鳴らすと、デジタルっぽくない音がすることも多い。
録音も再生機器も良くなったということだろう。

しかし明瞭に聞こえなくても、ジッターが再生音に影響しているのは確かだと思う。
今でもちょっとしたことで、デジタル音源の音が変わるのだから。

今回、ジッターというのはいろんな切り口があるのだというのを改めて確認した。
それにしても、複雑で意味不明で分かりにくい。その一方で疑問が解けたこともあったので、読んでよかったと思う。引き続き、マイペースではあるけど、勉強していこう。

しかし、疲れた、、、今回はここまで。