abk1's scratched blog 3

今回は、ちょこっと。

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

うちでは、リッピングしたファイルは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に保存するという行程を採っている。
ちゃんと確認してないけど、そういう気がするのでその行程は外さない。保守的である。というか、あつものにこりて、か。

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

今回のエントリーは前回エントリーの続きだ。
（http://blown-lei.net/endive/blosxom.cgi/audio_diary/20230214a.htm）

Deezer hifiのMQAを、Daphile経由でpiCorePlayerに送って再生しようとした顛末を書いている。
有線LANで音が途切れて、WiFiでつないで改善したのは前回エントリーに書いたとおり。
問題は、なんで有線LAN経由だったら途切れるのかということだ。

Deezer MQA音源の352.8kHzで音切れし、176.4kHzではしない。
これはどういうことなのか、最初はM500が行うエンコードの負担が352.8kHzと176.4kHzで違うのかと思った。だから、その上流にあるSqueezeliteの設定を変えることで、多少でも負担を減らせないかと考えた。
しかしNAS音源のMQA 352.8kHzでは音切れしないことが判明。
Squeezeliteの設定は関係ないだろうと判断して、そこを弄るのは止めた。

Deezer音源とNAS音源、ともにMQA 352.8kHzであり、flac 44.1kHz/16bitの同一のフォーマットとして伝送処理される筈と思いきや、音切れが起きるかどうか差異が生じるのはおかしい。
信号処理経路のどこかで、両者に差異が生じている。
どこかで、って、Daphileサーバーより下流には差異がない。上流のデータ信号の差異が、下流に影響しているということか。

Daphileサーバーを変えたらどうか。
6730bは実はテスト用で運用しているサブマシンで、メインのDaphileサーバーはhp Elitebook 2570pが担当している。6730bよりもずっと高性能だ。こっちを使ったら、ちゃんと鳴る？
やってみた。残念でした。同じである。
ということは、NASかストリーミングか、それこそが問題ということになるのか。

どうにかして問題なく再生出来ないか。
他に弄れるところは？、ということで、有線LANからWiFiに変えたら、音切れがおさまった。

これもまた、理由がよく分からない。
Raspberry Pi上の信号伝達経路を変えたら、Deezer MQA 352.8kHzの音が途切れなくなった。WiFiのほうが、Raspberry Pi、piCorePlayerにとって、信号データの処理がやりやすいのだろうと想像できる。
しかし、ボードPCのUSBポートからUSB DACにデータを送るのに、どれほどの大きな負担の差異が生じるというのだろう。
というか、Deezer MQA 352.8kHzは、有線LANだったらラズパイが処理に困るようなデータの伝わり方をしている、ということになるのだろうか。

しかし、ポイントは絞られた。
MQA 352.8kHzが、ストリーミングで、Raspberry Piに有線LANでデータが送られUSB出力される。この３つの条件が揃ったら音切れが起きる。

いくつかの仮説が導かれる。

まず、うちでのストリーミング信号の伝送は、NAS音源データの信号を伝送するよりも、システムの負担になっているらしい、ということ。
これは思い当たることがある。
というのは、今回とは関係なく、MQAではない楽曲で、NAS音源とストリーミング音源を比べたら、わずかだがNASの方が音が良い。
音が違うのは音源のマスターが違うんじゃないかという疑念もあろうけど、僕が聞くような音源は、そうそうお金をかけてリマスターとかされるような音源は少ない。ほとんどがCD化された時点と同じマスターだと思うので、同じデジタルデータで比較できていると言って良いと思うのだ。
話を戻す。
NAS音源の方が音が良いということは、音楽デジタルデータとして、NAS音源の方が上等でシステムにとって扱いやすいということだと思う。
つまりジッターが少ないのだ。
以前、海外のサイトでジッターの解説が書いてあるのを読んだけど、そこにはジッターが多いと音が途切れると書いてあった。僕は、そんな状況が今時あるのかというようなことを書いた気がするけど、どうも今回は当てはまるのかもしれない。

しかし、そもそもMQAというのは、PCMだと原理的に逃れられないジッターの影響を極力排除しようというフォーマットではないかと思うんだけど、そういうフォーマットであるせいか、音がブチブチと切れるような状態であっても、途切れていないときに出てくる音自体はきれいな気がする。なんとかつなげて聴けるようにしたいと思わせる音がする。

次に、Raspberry Pi 3B+のデータ伝送について。
有線LANからWiFi伝送に変更したら音切れがなくなったということは、有線LANで入力しUSBから出力すると音楽信号が劣化する、つまりジッターが増加すると言っていいのではないか。
これは、異論を挟む余地はほとんどないと思う。
たぶんハードの特性によるものだ。USBと有線LANを１つのチップで処理していると思うので、安定した信号送信が出来ないのだと思う。音楽以外で使う分には問題ないのかもしれないが、音楽データだとジッターが大問題になるのだろう。

以上を踏まえて。

ジッターが多い状況だったら、MQA 352.8kHzと、MQA 176.4kHzとで、伝送結果（音が途切れるかどうか）に違いが生まれる。
MQAは折りたたまれたファイルを展開する行程がある。
たぶん展開後のデータ量が多い方、ファイルが大きくなる方が、フルデコードするDACにとって負担が大きくなる。そしてジッターが多いMQA音楽データの処理は、M500にとって、より厄介な仕事になるのだろう。
そうした違いが、再生音が音切れするかどうかに関わってくるのだと思う。176.4kHzはなんとかなったけど、352.8kHzは無理だったのかな。

デジタルデータ処理というのは、一部で問題が生じたら、他にも問題が飛び火するということがあるのかもしれないと思っている。
一部で生じているジッターが、他の場所のジッターの原因になるというようなことだ。
よく分からないから、いい加減な考えだけど。

以上、想像に過ぎないけど考えてみた。音はいい感じで鳴っている。

趣味のオーディオはBGMで聴くだけになっていたけど、Deezerを日々使ううち、昨年12月に2Lレーベルの音源にMQAがあることに気付いた。
どういう状況で気付いたのかは忘れたけど、、いや、思い出した。何の気なしにDeezerで「MQA」を検索したら2LのMQAサンプラーがヒットしたのだ。
調べたらDeezerはずいぶん前にMQA対応してるのだ。
下記、5年前のネット記事のurl。

https://www.phileweb.com/news/audio/201709/06/19032.html
2017/09/06
音楽ストリーミングサービス“Deezer”がMQA音源の配信を開始　PHILEWEB

そして最近になって、どうやら2Lの音源は多くが（全部が？）MQA、352.8kHzらしいということに気付いた。
今回はこの件についてアップしておこうということ。
下記に関連のurlを記載。

使用機器の構成は下記のとおり。

6730bは古いノートPCだが、使い慣れていたのであちこちで使っていた。
このスペックでもDaphileは問題なく動く。ストリーミングが聴けてDeezer以外にSpotify、Qobuz、Tidal、Youtubeなど対応しているがAmazon、Appleには対応していない。
DaphileではLMS（logitech media server）が動いている。
Daphileサーバー自体をプレーヤーにすることも出来るが、うちではラズパイのpiCorePlayerをプレーヤーにして、家庭内LAN経由でデータを送信している。
MQAを鳴らすためには、ウェブブラウザでアクセスして、「Settings」、「Advanced Media Server Settings」の画面から、「player」のタグ選択、「Basic Settings」ボタンから「audio」項目を選択して、プレーヤーのボリュームを100%に固定する必要がある。固定していないとMQAがただのPCMになってしまう。
文章にするとわけが分からないけど、実際に触りながらなら分かると思う。

piCorePlayerは、LMSから受信したデータを「Squeezelite」で受けて、USB DACに出力する。
Squeezeliteというのは、Squeezeboxのエミュレーターということだけど、要はmpdみたいなもんじゃないかと思う。
ウェブブラウザからアクセスして、あれこれと設定ができる。現状の設定は後述。

S.M.S.L M500は数万円の中国製DACだが768kHzに対応、MQAをフルデコードする。久しぶりに使っているけど、音も良いように思う。
しかしファームの当て方がはっきりしなかったり、使うのに多少の覚悟がいるかも。
僕が買ったのは数年前で、今はmk2、mk3まで製品が出ているらしい。

Squeezeliteの設定。
備忘録でもあるので、説明なく書き変えるかもしれない。

他に「Name of your player」と「LMS IP」を設定してある。LMS IPはDaphileのIPだ。

Squeezeliteのマニュアルがネット上にあるので、引用しておく。

squeezelite - Man Page
https://www.mankier.com/1/squeezelite

-a <params>
Specify parameters used when opening an audio output device.

For ALSA, the format <b>:<p>:<f>:<m>:<d> is used where <b> is the buffer time in milliseconds (values less than 500) or size in bytes (default 40ms); <p> is the period count (values less than 50) or size in bytes (default 4 periods); <f> is the sample format (possible values: 16, 24, 24_3 or 32); <m> is whether to use mmap (possible values: 0 or 1). <d> open ALSA output device twice. (possible values: 0 or 1).
For Linux PortAudio, the value <l> is simply the target latency in milliseconds.
For MacOS, <l>:<r> <l> is target latency in milliseconds. <r> open device in Pro Mode or Play Nice (respective values: 0 or 1).
For Windows, <l>:<r> <l> is target latency in milliseconds. <e> use exclusive mode for WASAPI (possible values: 0 or 1).
When the output is sent to standard output, the value can be 16, 24 or 32, which denotes the sample size in bits. Little Endian only.

-b <stream>:<output>
Specify internal stream and output buffer sizes in kilobytes. Default is 2048:3446.

問題は、音が途切れることがままあること。
設定を詰め切れていないせいなのか、ハードの問題なのか、通信環境によるものやら、はっきりしない。せっかく音は良いのだから、もったいない。

そういうわけで、2LのMQAを聴いているのだけど、少ないながら2L以外でもMQAで配信されている音源があるようだ。
例えば、これとか176.4kHzのMQAだ。
Fairytales - Steve Dobrogosz, Radka Toneff
https://www.deezer.com/ja/album/79443672
Radka Toneffはノルウェーの女性歌手とのこと。どこかで2Lと関わりがあるのかな、などと思っていたら、1982年に亡くなっている。これは名盤なのでお薦め。

ところで、この音源だと音が途切れない。ということは、352.8kHzのMQAはM500の処理能力を越えている、ということがあり得るのか。
ところが、うちのNASに置いてある352.8kHzのMQA（MQA-CDからリッピングしたもの）を再生する分には途切れない。ということはストリーミング環境が良くないのか。聴いてる人が多いのかな。
これは様子を見ながら考えていく。

16日、追記。
Squeezeliteの設定調整では音が途切れるのを止められない。
どうしようかなあ、と思って思い付いた２案。

ひとつはi2sボード（Hifiberry Digi+）を使ってS/PDIF出力してみる方法。光か同軸を使えないか。
しかし確認したらM500は、USB入力はMQA対応しているが、S/PDIF入力はしていない。残念でした。M500 mk2では対応しているようだ。

もうひとつの方法は、WiFiでLANにつないだらなんとかならないかな、というもの。
Rasperry Pi3B+に付いている無線で、家庭内LANにつないで使ってみようと。
Raspberry PiはUSBと有線LANを１つのチップで処理しているという話を昔に聞いたことがある。3B+でもそうなのか、分からないのだけど、無線LANは取り敢えず専用の処理チップが充てがわれている、らしい？、よく分からないけど。

まあ、やってみたら分かるさ、ということで、piCorePlayerをWiFi接続するように設定。
これで今のところ、音切れなくDeezerのMQA 352.8kHzを再生出来ている。

ああー、よかった。これで使える。

もう一つの問題は、音源の曲名などに記載がなければMQAなのかどうか、分からないこと。
うちだとM500で鳴らしてみて初めて分かる。
これはDeezerのほうで、表記なりをどうにかすべきだと思うんだけど、たぶん気にしてないのだろう。まあいっかあ、である。

あけましておめでとうございます。
いろいろありますが皆様のご健康、ご健勝をお祈りし、今年がより良い年でありますように願っております。
更新は滞っていますが、無理ない範囲で運用してまいりますので何卒よろしくお願いいたします。

そんな感じで、新年の挨拶をこのサイト上でしたことが、今まであんまりない。
昔は書いたこともあったが、なんだかいつの間にか、書かなくなった。ツイッターでも明けおめとか、あんまり書かない。
しかし、なんとなく今年は挨拶ぐらいは書いておくことにした。
そんな感じなので内容はない。

ここ数年、世の中コロナで大変だけど、昨年は輪をかけて大変だった。世の中があれやこれやとありすぎて、気持ちが落ち着かないというのも困った。
日本国内も世界情勢も、どうなるのかまったく先が見えない。そんな中で、コロナ対策は毎日が気が抜けない。昨年の秋以降、僕の職場ではコロナクラスターを生じていないということが殆ど無くなった。あっちで収まったと思ったらこっちで発生するというのを繰り返して、コロナ対策担当の職員はそっちにかかりっきりだ。コロナ対策班っていっても、元々それだけやってる職員じゃなくて、やるべき日常業務、役職は別にあるのに選出されてやってるので、開いた穴は他の慣れない職員が肩代わりしているのだ。そんな中で、家族が発症し濃厚接触者になるとかで仕事を休む者もいる。そのような状況が続いていて、みんなの負担が増している。
それでも、まあ、やるしかないということだ。僕などは三が日休めるんだから感謝である。

そんなこんななんだけど、気がついたんだけど、僕がサイト運用し始めて今年の2月で20年になる。
20年といえば、昔だったら成人式だ。
愚痴みたいなことを書いたりするけど、よくまあ、飽きずに続いているものである。
最初はコピーコントロールCD反対のサイトを作ろうと思いたち、わけがわからないので契約しているプロバイダのサービスを借りたのだった。それ以降、契約継続しながら今に至っている。
昨今はCCCDどころか、CD自体が少なくなった。時代は変わる。音楽の有り様を憂うとか、そんな呑気なことは言っていられない時代になりそうだ。
そうはいっても、継続は力なりといわれる。ぼちぼち続けていくつもり。

みなさま、風邪など召されぬように。

すっかりブログ更新が滞っている。
世の中はほんとうに大変だ。
3年前から続くコロナ。今年2月からわけわからん戦争が始まった。
職業柄もあり生活防衛もありコロナの情報は追わなくてはならない。ウクライナの戦争も世界の向かう方向を知らないわけにはいかないので追いかけることになる。
それでもまだ、6月までは余裕があった。

7月、朝鮮半島に拠点を持つ世界平和統一家庭連合（元統一教会。莫大な献金を日本の信者から強制的と言っていい手法で集め、社会問題化している。その金は北朝鮮に流れSLBM開発の一助になったとか、、、）が、日本の政治、特に自民党に何かしらの影響を与えていたということが白日の下に晒された。

何かしらの影響って、ひとことで済ますには規模が大きすぎる。
国政だけではなく地方行政や草の根の活動まで、あちこちに知らない間に浸透され、教育やLGBTなどの方向性に対して人々が気付かないうちに影響を与え、諸外国の右傾化にも日本から巻き上げた金を以って影響を与えていることが、この3ヶ月で広く知られることになった。
これは、全日本国民にとって課題であり、黒歴史且つ将来への禍根そのものであって、知らないでは済まされない。何が起きているかを追いかけないわけにいかない。

そんなわけで、ブログ更新する暇はなくなった。

趣味のオーディオは、BGMで音楽を鳴らす以外はしていない。
手がかかることは出来なくなった。後回しである。
音源のアップサンプリングをどうしたらいいのかというのは大きな課題なのだが、ある程度落ち着くまでは取り掛かれそうにない。なにしろ、試聴に使う音源の選定すら出来ていないのだ。

以上、近況報告まで。

アップ5分後に追記。
うちの職場では現在4回目のクラスタ発生で、ちょっとバタバタしている。
コロナは早く終わっていただきたいのだけど、あと数年以上続くという予測もある。幸い、オミクロンは重症化は少ない。気を付けながらウィズコロナだ。

前回、libsamplerateの「Best」の設定で音を出すことが出来たというエントリーをアップした。
その後で、ふと我に返る。
192kHzって、ふつーにハイレゾだよなあ、、、

うちのシステムは、CDクラスの音源を768kHzという、いうなればスーパーハイレゾに変換して鳴らすというのが目玉である。
今迄、そうすることでCD音源の音をより良い音で聴くことが出来ると考えていた。CD音源そのままの44.1/16から本来の音を引き出すのは結構大変だという認識で、アップサンプリングする方が引き出し易いだろうという考えでやってきている。
しかし、普通のハイレゾレベルへのアップサンプリングなら、普通にハイレゾ購入してそのまま鳴らすほうが、たぶん良いのではないか。

まあ、CD音源しかないんだよという音源もあるし、Deezer HiFiにハイレゾレベルの配信を期待するわけにもいかないので、意味はあるっちゃあるんだけど。
そんなことを考えながら、Best Sinc Interpolator:192kHz で聴いている。

情報量の比較は出来ていない。
しかし微弱な音とか、倍音成分が聴こえ方にデリケートに影響する音源は、明らかに良いような気がする。
アタックの立ち上がりとか余韻が綺麗。
Medium:768kHzよりも、繊細かつ芯が通った音色という印象。
比べたら、Best:192kHzのほうが、しなやかで柔らかく精密なのだ。

前回のエントリーをアップしたときと、評価がずいぶん変わってしまった（あのときは、短時間の印象だけだったから、、、評価は軽々しくするものではないな、、、）。
しかし、これは、まいったな、、、

libsamplerateで700kHz台にアップするより、普通にハイレゾ鳴らす方が良いということになる。
以前、300kHz台のハイレゾと、CDと同クラスの音源をアップサンプリングしたのとを比較したことがある。当時は、殆ど差がないと判断した。僅差でブラインドでは全く分からないと感じた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170625a.htm
libsamplerateの設定も「Fastest」、それでも充分な性能と判断したのだ。
でも、5年も前のことになるのね、、、
当時、44.1＜96＜192＜384だった。その後、384＜768で、今に至る。

それが、今回、ひっくり返った。
Medium:768kHzのアップサンプリングよりも、Best:192kHzのアップサンプリングのほうが良いということなら、それよりも192kHzのハイレゾファイルの方が良いだろう。それが順当だ。
5年前と今と、何が違うんだろう。

5年前のシステムは、Raspberry Pi2、moode audio3.1 + i2sDACでアップサンプリングしていた。NAS音源も使っていたが、高音質を目指すときはRAMメモリ再生という方式。
ハードもソフトも現在とはずいぶん違う。
ということは、当時してみたことを、今のシステムでもう一度やってみるべきかな。
そして、出力形態の違いでどのように音が変わるのか、確認する必要がある。

高域が正確に再生されるかどうかは、音声再生全体に影響する。
libsamplerateの設定で、Best、Medium、Fastestの違いによって、リサンプリングに際しての高域減衰に差が生じる。
以下、引用。

http://www.mega-nerd.com/SRC/api_misc.html#Converters

SRC_SINC_BEST_QUALITY - This is a bandlimited interpolator derived from the mathematical sinc function and this is the highest quality sinc based converter, providing a worst case Signal-to-Noise Ratio (SNR) of 97 decibels (dB) at a bandwidth of 97%.
All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.

SRC_SINC_MEDIUM_QUALITY - This is another bandlimited interpolator much like the previous one.
It has an SNR of 97dB and a bandwidth of 90%.
The speed of the conversion is much faster than the previous one.

SRC_SINC_FASTEST - This is the fastest bandlimited interpolator and has an SNR of 97dB and a bandwidth of 80%.

Bestの設定はリサンプリングに伴う高域の減衰が小さい（大雑把な言い方だが）。
以前はFastestの設定で使っていて、高域の減衰は大きい。その状況でハイレゾファイルと比較して、再生音に差はほぼ無いと思えた。つまり、そのときは高域の差異に伴う音の違いは、殆ど聴き取れなかったのだ。
恐らく、実際に音が違っているのに聴き取れなかったのではない。両者の再生音の高域に差が無かった可能性の方が高い。

どうして差が生じなかったのか。
ハイレゾファイルの再生が、適切に出来ていなかったのかもしれない。
考えられる原因は、ジッターだ。
再生環境のジッターが影響し、ハイレゾファイル再生の高域が劣化した。
アップサンプリングの方は劣化しないのかというと、既に高域が減衰しているので、受ける影響が少なかったのではないか。
結果的に両者の差が僅差となったのではないか。つまり、再生された音声が劣化していたために区別がつかなくなっていた可能性がある。

そして、再生音が劣化したハイレゾ音源よりも700kHz台にアップサンプリングした音の方が良くなった。
サンプリング周波数が上がっていくのと平行して、ノイズ対策や電源、GNDへの手入れが行われ、PPAPの構成も進化し、恐らくは、ジッターへの耐性も5年前よりも向上した。
そうした変化によって、以前はジッターの影響で劣化していた高域特性が改善してきた。
以前よりも、音源の素性が再生音に反映されるようになっているのではないか。

以上、仮説だ。

専門家は、ジッターはおそらく聴き取れないだろうと言う。
https://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-9-when-do-i-care/
たしかに明確にこの音がジッターだと特定するのは難しい。

しかし、ジッターによる音質劣化はかなりのもので、聴き取れる場合も多いと思う。
例えば、80年代のCDプレーヤーで再生した時は冴えない音しかしなかったCD音源が、今の再生環境ではそれなりの音で鳴ることが珍しくない。ジッターへの対処が30年で進歩しているのだ。あの冴えなさ具合を考えたら、ジッターの影響でハイレゾファイルの再生音が僅かに劣化することなど、十分に有り得ると思う。
プレーヤーが安物だったからだろうって？
確かにその可能性は、否定できないのだが。

主旨は違うけど、サンプリング周波数をあれこれ変えて視聴するという試みを2年前にしている。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200524a.htm
CD音源アップサンプリングなしの音質について、仮想アースを使う方が相当良いみたいなことを書いている。
当時は気付かなかったが、たぶん、この時点でも以前とは違っていたのだろう。

あれこれ試聴したとしても、たぶん今更、裏付けは取れない。
でも現在の状況確認は必要だ。

しかしだ、、、これって、体力いるんだよね、、、ゆっくりやるつもりだ。

うちのオーディオの音に、現状、全く不満はない。
しかし不満がないからといって、問題がないわけではない。

明らかな弱点はある。
例えば低音、JBL 4425mk2はバスレフ形式で若干緩い感触があるが35Hz〜20kHz(-6dB)と、体躯の割に低い音域まで出る。8畳の部屋で鳴らしていた時は30Hzが出ていた。しかし部屋が広くなってそこまでは出なくなり、Waltz for Debbyの地下鉄が聞こえなくなった。
部屋の作りのせいで室内音響は左右差があって、だから音像定位は合格点は出せない。
こうした欠点も、僕の要求水準が低いから放置で済んでいる。

要求水準が低いと言ったが、容易に手を出すことができない、というのもある。
現状以上の低音が欲しかったら、もっと大きいスピーカーが必要だし、部屋のレイアウトは変えられない。

うちのサイトがPCオーディオ関係のエントリーばっかりなのは、容易に出来る音質改善策だったからというのが大きいと思う。
経済的にも大きなことにならない。といいながら、PCトランスポートを構成するのにうちではPCが5台動いている。apu2が2台と中古ノートPCが3台、トータルで10万以上はかかっている。それに気付いたら、そんなに安価というわけじゃないのか、とも思ったけど、それでこの音なのだから十分に安いとも思う。

これ以上、することはないか、、、
そういう視点でうちのシステムを見ていて、ふと気付いたのが、エントリーのタイトルにしたようなことだった。
これはmpdのアップサンプリング設定だ。
つまり「libsamplerate」で「PCへの負荷が最高となる設定」だったら、どんな音質を引き出せるのかという、これは考えてみたら、Secret Rabbit Code (a.k.a. libsamplerate) を6年前に使い始めてから、ずっと手を付けないままにしていた宿題なのだ。

今まで手を付けなかったのは理由もある。
というのは「Best Sinc Interpolator」で設定して、mpd + libsamplerateを動かすと、まともに音が出ない。

libsamplerateの設定は、Best、Medium、Fastest、ZOH、Linearの5段階。
これらのうち、音質の優位性が得られる設定はBest、Medium、Fastest の３つである。
参考url
Music Player Daemon documentation » Plugin reference
https://mpd.readthedocs.io/en/stable/plugins.html#libsamplerate
Secret Rabbit Code (aka libsamplerate) - Miscellaneous API Documentation
http://www.mega-nerd.com/SRC/api_misc.html#Converters

Best、Medium、Fastestの設定でmpdを動かすには、負担に耐えられるスペックがPCに要求される。

ZOH、Linearの設定は、かなり低スペックなPCでも動く。
しかしあんまり使う意味はない。
現在のうちの環境では、音質悪化する（以前にアップしたジッターの説明サイトでも、実装が悪いASRCでは往々にしてそういうことが起きると書いてある）。
こうした設定で音質が改善するとしたら、デジタル信号伝送の環境が悪いということがあるので、よくよく見直した方がいい。昔のことだが、うちではNASが壊れかけていたときに、こうした低品質な設定で音が良くなったことがあった。

6年前、うちで使っていたPCトランスポートはRaspberry Pi2だった。
mpdのlibsamplerateのデフォルト設定は「Fastest」で、比較的、負担が少ない設定となっている。それでもRas Pi B+にとっては負担が大きくて無理で、Ras Pi2でようやく可能になった。当時はBestどころかMediumの設定も、PCへの負担が大きくて使えなかったのだ。

それが、アップサンプリングのサンプリング周波数を上げるにはPCトランスポートのスペックを上げざるを得なかった。
Raspberry Piからapu2、ノートPCへとスペックを上げて、768kHzへのアップサンプリングが可能となって、気が付いたら、Mediumの設定が使えるようになっていた。
使えるようになって比較したら、FastestよりMediumのほうが音色が濃厚で厚みがある。以降、うちでの設定は変更になった。Phile webに日記をアップしてレスをもらったのが切っ掛けで気付いたので、ほぼ1年前のことになる。

実は最近、気付いたことがある。
CDをうちのシステム（USB-DVDドライブからmpdに読み込む）で鳴らしていると、特定のCDで音が途切れることがある。Mediumの設定をFastestに変えたら途切れなくなる。
つまり、Mediumの設定でCDを鳴らそうと思ったら、スペックが僅かに足りていないのだ。
mpdサーバーのスペックを上げるに越したことはない。

現在、mpdサーバーを担当しているのは、HP EliteBook 820 G2。
過去の経験からは、最も重要なのはメモリのスピードという認識。
820 G2のメモリは、DDR3L-1600。
メモリクロック:200MHz、バスクロック:800MHz、転送速度:12.800GB/s、データ転送速度:1,600MHz、ということらしい。
参考：
https://ja.wikipedia.org/wiki/DDR3_SDRAM
https://ja.wikipedia.org/wiki/DDR4_SDRAM
見れば全部わかるDDR4メモリ完全ガイド、規格からレイテンシ、本当の速さまで再確認
https://akiba-pc.watch.impress.co.jp/docs/sp/1231939.html

CPUは「less /proc/cpuinfo」で確認した。
Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz、2コアだけどスレッドは4（topから見たらCPUが4個と認識される）。
しかし正直、CPUにどの程度のスペックが必要なのかは、よく分からない。

sshからmpdサーバーにログインしてtopで状況を確認していく。libsamplerateの設定はMedium。
mpdのCPU使用率は、0%から25%を変動する。平均は12～16%ぐらい。
1キーで、CPUのスレッドを表示。
音声信号処理の負担がかかっているスレッドが、数秒で切り替わっているようだ。基本的に演算処理は1つのスレッドが担当し、同時並列で複数のスレッドが演算を分担することはないようだ。一度に動くスレッドが４つのうち１つなので、CPU使用率が最大25%ぐらいまでということかな（つまり、そのスレッドとしては100%使い切っているということだ）。
mpdサーバーは、mpdを動かしてるだけではなく、daphileサーバーやPPAPサーバーとも連携しないといけない。スレッド4つは最低欲しい（2つだとなんだか危なっかしい気がする）。
メモリはというと、使用量はそんなに多くない。8GB積んでいるけど使っているのは500MB程度だ。

libsamplerateの設定を「Best」にしてみる。
音を出すと、音が出るのに10秒近くかかる。数秒間だけ音が出た後、途切れ途切れになってしまう。
topでみたら、mpdのCPU使用率が25%に貼り付いている。つまり、最大限使っている。そして、スレッドが切り替わらない。切り替わるのに数10秒かかる。たぶん演算処理が追いついていないのだ。
メモリの状況は、Mediumのときと変わらない。

しかし、数秒間の音は、悪くはなかった。
ちゃんと鳴らすにはもっと速いPCが必要。

どんな機種にするか、、、
今までのようにノートPCの中古にするか、いっそのことミニPCにするか。
ミニPCのほうが安価だ。しかしミニPCの場合、メモリのスペックがなかなか調べても分かりにくいということがある。DDR4までは分かっても、クロックや速度が分からないままで売られていることが多い。あと、BIOSを触ろうと思ったらモニターとキーボードを用意する必要がある。まあ、すりゃあいいじゃんと言われたらその通りなのだけど、、、面倒だ。そこについてはノートPCのほうが扱いやすい。ましである。

とりあえず扱い易さを優先して、中古ノートPCにした。
機種は、HP ProBook 430 G5。
CPUはCore i5 7200U。定格クロックが2.50GHz、第7世代なのかな。
メモリーは8GB。DDR4 PC4-2400が標準だけど、第7世代CPU以前だと2133で稼働するらしい。どうなんだろこれは。
参考：
インテル® Core™ i5-7200U プロセッサー
https://www.intel.co.jp/content/www/jp/ja/products/sku/95443/intel-core-i57200u-processor-3m-cache-up-to-3-10-ghz/specifications.html

結果。
820 G2より僅かにマシだけど、やはり同様に音が途切れて使えない。
topを打つと、CPUの使用率は4スレッドのCPUで25%。使いきっている。「less /proc/cpuinfo」を打つと「cpu MHz : 3100.001」と表示。Core i5 7200Uは最大クロックで動いているようだが、足りていない。

途中で音が切れるのは、メモリよりもCPUの速度が足りないのかもしれない。3GHzでも遅い。
速いCPUを調べてみたが、ノートPC用だと定格クロックは3GHz台が殆んど。最大クロックだと4GHz台以上に届くのがあるけど、どうなんだろうか、そういうのって。
PassMarkという数値が高いCPUはたくさんあるけど、そういうのはコア数やスレッド数が多い。mpd+libsamplerateは1スレッドを占有し音声信号処理に充てる。つまりスレッド数を増やして性能を上げているCPUは、たぶんあんまり意味がない。1スレッドで、どれだけのパフォーマンスを出せるかが重要な筈。

そんな中で気になったCPUをいくつかメモ。
Intel Core i3-12300、i7-10610U、i3-1115G4、、、まだまだある。最大クロック4GHz台で動くCPUだ。
そして、そういうのが載ってるノートPCは高い。中古も高い。じゃあ、mini PCでどうかとなると機種がない（探すのが下手なのかもしれない）。あっても売り切れてるし、今まで買ってきたのと比べたら高い。

あと、今回の試行で、一点、Tiny Coreのほうに問題が見付かった。
現在運用しているmpdサーバーで動いているシステムは、ProBook 430 G5では起動しない。
EFIというのが入ってないためだ。
仕方ないので、TC64 11.1から移植して何とか起動。しかしf9キーから入ってブートローダーを選択しないといけないし「Wrong EFI」と表示が出る。
TinyCorePure64-13.1そのものからだと、そんな面倒しなくてもUSB起動優先の設定さえしておけば、起動ボタンを押すだけでそのまま起動するので、ブートローダー周りの問題なのだろう。
普通に使えるのを作らないと、再起動が簡単にできないので、システムに組み込みにくい。

ハードルが高い、、、

ここでふと、768kHzだから出来ないんじゃね？と思い至る。
430 G5で、設定を192kHzにしてみたら、比較的スムーズに音が出た、、、、、

topコマンドで状況を確認。
mpdのCPU使用率は、0から25%を変動し、平均はだいたい10%台。メインシステムでMediumの設定で使っているときと同じような挙動だ。そこそこ余裕がある。
スレッドも切り替わる。というか、4つのスレッド全てが0%という瞬間がそこそこあって、スレッドの切り替わりはあるけど、ゆっくりと切り替わる。かなり余裕を持って動いている、、、
これなら安定して使えそうだ。

なんだ、、、Best Sinc Interpolator、できたじゃん！

音は、いい。
ある意味、良いのは当たり前だ。PPAPで直結してるんだから。
Medium:768kHzと比べて、どうなのかというのが問題、、、なんだろうか。

ここまでやってなんだけど、どっちでもいいやん、という気分で、本気の聴き比べは、出来ていない。
ちなみに、384kHzだとぎりぎりで、ノイズが入り、数10秒鳴った後で音が途切れ始めた。もう少しスペックを上げたら384kHzで鳴らせそうだ。
そんなギリギリ状態の384kHzの音よりも、安定している192kHzのほうが良かった。
しばらく鳴らした感じでは、Best:192kHzよりも、Medium:768kHzのほうが良さそうだとは思ったけど、、、ちゃんと比較して、各々の傾向が見えてきたら、意外に面白いことがあるかもしれない、という印象だ。しかし、僕の駄耳でははっきりしたことは分からないかもしれない。
音の表面の感触が違う気がする。
Medium:768kHzのほうが明らかに細かい音が聞こえるんだけど、Best:192kHzのほうが、甘い、気がする。

まあ、今は深く追求はしない。
Bestの尻尾を掴むことができたところで良しとしようと思う。

今回は、興味深いサイトがあったので備忘録に書いておこうという主旨。
サイトのオーナーは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では、ジッターを位相ジッターと振幅ジッターという見方で分けた。
ここでは、別のジッターの分類について触れている。
以下、表にする。

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でも最近の機械で鳴らすと、デジタルっぽくない音がすることも多い。
録音も再生機器も良くなったということだろう。

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

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

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

今回は音源の話。
というか、高音質音源リストについて。

海外に「the absolute sound」というオーディオサイトがある。
そこにオーディオファイル向けの高音質音源がリストされている。

The HP Super LP List
by Harry Pearson Nov 17th, 2014
https://www.theabsolutesound.com/articles/the-hp-super-lp-list

2019 TAS Super LP List
BLOG by TAS Staff Jul 10th, 2019
https://www.theabsolutesound.com/articles/2019-tas-super-lp-list

Harry Pearsonという人がまとめた古い音源中心のアナログディスクのリストがあって、TASスタッフが引き継いだということらしいんだけど、2019年を最後に更新されなくなった。コロナの関係とかもあったのかもしれないが。
2020年以降は、こんな感じ。

2020 Top Ten Lists
BLOG by Jeff Wilson Dec 14th, 2020
https://www.theabsolutesound.com/articles/2020-top-ten-lists

2021 TAS Tapeography
BLOG by Jonathan Valin Jan 17th, 2022
https://www.theabsolutesound.com/articles/2021-tas-tapeography

テープのリストって、すごいわね、、、
そして2022年は、こんな感じ。

TAS Super Download List : Classical
MUSIC by TAS Staff Mar 31st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-classical

TAS Super Download List : Jazz
MUSIC by TAS Staff Apr 01st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-jazz

TAS Super Download List : Pop, Rock, and Folk
MUSIC by TAS Staff Apr 01st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-pop-rock-and-folk

Though HP once attempted to compile a list of recommended digital recordings (then only available on CDs and SACDs), he was unable to make consistent progress and eventually abandoned the effort.
Over the next few years, I will attempt to pick up where Harry left off.
For various reasons, I’m going to begin with media available via the Internet, starting with high-resolution downloads from HDtracks. In time, I will add streamed versions of these same titles (assuming they are recommendable, of course).

（翻訳 by Google）
HPはかつて推奨されるデジタル録音のリストを編集しようとしましたが（当時はCDとSACDでのみ利用可能でした）、一貫した進歩を遂げることができず、最終的にその努力を断念しました。
今後数年間で、ハリーが中断したところから再開しようと思います。
さまざまな理由から、HDtracksからの高解像度のダウンロードから始めて、インターネット経由で利用できるメディアから始めます。そのうちに、これらの同じタイトルのストリーミングバージョンを追加します（もちろん、それらが推奨されると仮定します）。

ダウンロードやストリーミングのリストを作っていく計画とのこと。
最初は20個しかないが、TASのWebサイトで毎月1〜2回、新しいタイトルを追加していく意向らしい。
LPのリストは、どうやら2019年が最新版ということで、しばらくは更新されないかもしれない。実際のところ、難しそうな感じだし、割り切って別のリストを構築するというのは、いい考えではないかと思う。

それにしても、オーディオファイル向けの高音質音源のリストというのは難しい。
リストから漏れている音源がどうしても出てくるし、音が良くても楽しめない内容だったらちょっと辛い。

個人的に思うのは、音が「良くない」ソフトというのは少ない。
割合がどのくらいなのかといわれると困るけど、まあ、3分の2以上は、いいオーディオで鳴らしたほうが音が良くなるし、聴き応えもあるように思う。、、まあ、当たり前か。
何について言ってるのかが問題だね、、、クラシックが特にそんな感じかな、、、
JPopは、あんまり音が良くないのが多いとは思う。特にボーカル。お風呂で歌ってるように聞こえるのが多い印象がある。カラオケマイクを通したように聞こえるのだ。まあ、日本はカラオケの国だから仕方ないのかな。それがポップだということもあるし。それでも、ちゃんと録音してると思う音源も探せばそこそこあるような気がするのだけど。そういうわけで、僕にとってJPopで音質がいいというのは、ボーカルの音がいいというのとほぼ同義だったりする。その程度の聴き方しか出来てないということかもしれないが。

話が逸れた。
話が漠然としすぎていてまとまらない。

たいていの音源は、いい装置で鳴らせばいい音で鳴る。
そんな中で、特別に音質がいい音源を選りすぐってセレクトしないといけない。
当然だけど、再生装置、環境によって、音は変わる。
Harry Pearsonの再生環境で最高の音が鳴るディスクが、他の環境で素晴らしく鳴るとは限らない。
The HP Super LP Listの選から漏れた音源が、他の環境で、Harry Pearsonの装置で鳴らすThe HP Super LP Listの最高の音源以上の音で鳴ることが、絶対に無いとは言い切れない。そういう危うさが、高音質音源のリストには付き纏う。
完全に理想的とは言えないオーディオ機材、人の聴覚と感受性以上のセンサーが存在しない、そんな状況で最善を尽くす以外ないのだろう。

それでも「定番」としてのリストはニーズがあり、現実的に必要だと思う。
新しいリストが有用で充実したものになることを願う。

現在のpiCoreの状況がどうなってるのかと思って、確認したことを記録しておく。

なんで突然、piCoreなのかというと、ハードの違いで音が変わるということを思ううちに、そういえば以前はRaspberry Piで鳴らしていたっけと思い、そこから、今はどうなってるんだろうということになったということだ。
piCoreの最新は13になっている。
http://tinycorelinux.net/13.x/armv6/releases/RPi/

nmap.tczは、piCore9まで用意されていて、10はpiCore自体が欠番。11、12ではnmap.tczがリポジトリに用意されていなかった。
しかし現在、piCore13ではnmap.tczがリポジトリに用意されている。ということは、piCore9以前か13だったら簡単にPPAP Back Endを作れるということだ。
http://tinycorelinux.net/13.x/armv6/tcz/

ちなみに、mpd.tczが用意されているのはpiCore7まで。
libmpdclient.tczはpiCore9までだ。
一方、Tiny Coreはというと、Tiny Core x86（32bit版OS）のリポジトリにはmpd-minimal.tcz、libmpdclient.tczが昔から今までずっと用意されている。つまり、実は手軽にmpdを扱うにはこれが一番簡単だ。nmap.tczもあるが、mpd-minimalでpipeが使えるかは確認していない。
http://tinycorelinux.net/13.x/x86/

64bit OSであるx86_64のリポジトリには、mpdが無い。
ソースをダウンロードしてインストールする必要がある。

一方、alsaはというと、piCore11からversion 1.2.2になって、音源のサンプリング周波数が768kHzまで通るようになっている。
piCore9だと、alsaはversion 1.1.1。音源が198kHzまでで良ければ、piCore9以前のバージョンでよくて、300kHz以上なら11以降が必要ということになる。
参考：
Changelog between 1.1.9 and 1.2.1 releases / Alsa Project News
https://www.alsa-project.org/wiki/Changes_v1.1.9_v1.2.1

現在、うちでは768kHz/32bitでPPAP方式を使っていて、Back Endで使っているのはTiny Core Pure 64 v11.0。ハードはapu2だ。
piCore13ならば、768kHzが使えるPPAP Back Endに出来る筈、、、
しかし問題は、Raspberry PiはUSBとLANが同じチップで処理されているんだったかな。Ras Pi4とか、新しいハードだと改善されたらしい？けど、うちに残っているB+とか2とかだと、大量のデータを送るのは、うまくいかない可能性がある。というか、B+とか2とか非力なハードで、768kHz/32bitなんて重い音声データを扱えるんだろうか。

しかしRaspberry Pi とpiCoreでPPAP Back End、apu2と比較できるならしてみたいかな。

せっかくなので、まずはRaspberry Pi B+で試してみる。
以下、工程と設定のメモ。

download
http://tinycorelinux.net/13.x/armv6/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131bp

config.txt rewrite
dtparam=audio=off

login
ssh tc@192.168.1.xxx

sudo fdisk -u /dev/mmcblk0
p
d
2
n
p
2
(write number - /dev/mmcblk0p2 / start)
+100M
w

filetool.sh -b
sudo reboot

login
ssh tc@192.168.1.xxx

sudo resize2fs /dev/mmcblk0p2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore.tcz alsa.tcz alsa-utils.tcz

vi /opt/bootlocal.sh
/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=16384 -t raw -f S32_LE -r768000 -c2"

vi /opt/eth0.sh
#!/bin/sh
pkill udhcpc
ifconfig eth0 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth0.sh

sudo vi /opt/bootsync.sh
/opt/eth0.sh &

filetool.sh -b
sudo reboot

工程終了。
PPAP Middle Endにつないで起動。
Middle Endからsshでログインして、下記コマンドにてUSB DACの認識を確認する。

cat /proc/asound/card0/stream0

音を出してみる。
音は出た。しかし、ノイズだらけで、音楽を聴くというわけにはいかなかった。

Ras Pi2ではどうなのか。

download
http://tinycorelinux.net/13.x/armv7/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131b2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore-v7.tcz alsa.tcz alsa-utils.tcz

上記以外の工程は同じ。
音は出た。やはりノイズだらけだが、音楽は聞き取れる。音程は正しいのに再生速度が遅い。これでは使えない。

PPAP Front Endでのアップサンプリングを止める。
Back Endの設定も合わせる。

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

これでどうか。
まともな音が出る、けど、、、操作へのレスポンスが遅い。
こんなに遅かったっけ、そういえば遅かったかな、、と思うぐらい遅い。
普段、Daphileとmpdで768kHzにアップして聴いてるのと比べても、なんだか遅い気がする。普段使っているシステムは、再生開始の操作をして音が出るまで数秒かかるけど、ボリューム調整への反応は遅くない。それが、Ras Piだと両方とも遅く感じる。 apu2よりもRas Piのほうが遅いハードだからだろうか。
しかし、DaphileとpiCorePlayerの組み合わせだと、そんなに遅く感じない。
もしかしたらLMSやUPnPは、ユーザーがレスポンスが遅いと感じないように作られているのかもしれない。

あれこれ弄るうちに、Daphileシステムの方も不調になってきた。原因不明、、、全システムをリブート。
システム全体の不調が影響したせいかどうか分からないが、音質も敢えてRas Piで聴きたいと思わせるものがない。

今回はここらで撤退することにした。
残念だが致し方なし。

半年前と比べて、若干システム上流を中心に変更がある。
聴こえ方も多少変わった。

最近のシステム構成は下図のような感じ。
前よりすっきりしてるかな。

一番大きな変更は、PPAPのMiddle EndとBack Endを直結したこと。
これは実は長年の懸案であり、今更感はあったのだけど、やってみたら改善効果は大きかった。

何故もっと早くしなかったのかというと、たぶん5、6年以上は前のことだが、最初に直結方式の説明をネット上で読んだときに、わけが分からない、手に負えそうにない、と思ったのが大きいかもしれない。
当時の僕はmpdを触り始めて間がなくて、Linuxにも今程には慣れていなかったので、後回しにした。
後回しになって、そのままになったのだ。
他の手法で音質改善は得られていたし、他にやることもあったので。
ネット上で直結による向上が大きいという話をたまたま読んで、そういえば、という感じで手を付けたということだ。
多少の苦手意識があっても、手を付けたらいいこともあるようだ。

上流の配置が変わり音が変わり、結果、ハブが減った。
NETGEARのGS105Eが1つ外れて1個になった。少ない方が良さそう。Planex FXG-05RPも外せるかなと思ったけど、こっちは外さない方が良かった。

そんなこんなで音質向上したということだけど、よりHi-Fiになったという意味合いだ。

これに伴って、2台のDACの聴こえ方に以前よりも差が出てきた。
ADI-2 DACのほうがよりHi-Fiでモニター的、Pegasus R2R DACのほうが絵画的。それが、より明瞭になってきた。
同時に、情報量の差が明瞭になってきた。ADI-2の方が僅かに情報量が多い。

アンプの方も差が出てきて、SM-SX100のほうがHi-Fi。
Brooklyn Ampのほうが情報量は僅かに少なく絵画的。
こうした両者の差が大きくなってきたので、Brooklyn Ampに可変抵抗アッテネーターが使えなくなった。
固定抵抗アッテネーターなら情報量や鮮度の低下が少ないので、まだ使える。使えるというのは、Brooklyn Ampの絵画的な音の美点を、アッテネーターがスポイルしないというような意味合いだ。

DAC2台とアンプ2台で4通りの組み合わせになる。
ADI-2とSX100が最もHi-Fiで情報量が多く、うちのリファレンスということになる。
Pegasusは高音域に美点があり、Brooklyn Ampはボーカル帯域に美点がある。
PegasusとSX100だとPegasusの美点が、ADI-2とBrooklyn AmpだとBrooklyn Ampの美点が表現された音になるようだ。
ところが、じゃあPegasusとBrooklyn Ampだと両者の美点が表現されるのかというと、さにあらず、なんだか曇ったような冴えない音になってしまう。両取りとはいかないようだ。この組み合わせで良く聴こえる音源も探せばある可能性がと思うのだけど、どうなのかな。

M500が此処まで蚊帳の外だ。最近は使うことが少なくなった。
しかし将来的にMQAストリーミングの再生に使えないかと思っている。
Daphileサーバーが２つに増えているが、片方、6730bのほうをテスト運用とYoutube音声などの再生などに使っている。ここからpiCorePlayerに出力しM500に繋いでいる。
piCorePlayerを使った再生は、うちのシステムで唯一、mpdを使わない再生ということになる。

そんなこんなで、この1か月でけっこう変わった。もう手を入れるところは無いかな、、、どうだろう。

コロナだ戦争だとうっとうしい世の中だ。
夏バテしないように気を付けよう。

Brooklyn Ampに使っている「MONITOR1」の実力がどうなのか、ずっとどこかで気になっていた。
MONITOR1 ベリンガー公式
https://www.electori-br.jp/products/625.html
使い始めた当初は、これで充分だと判断した。5000円と安価な製品で、アンプの能力をスポイルしている可能性は否定できない。当時、それも込みで必要十分と判断したのだ。

しかし2年近く経って状況も変わった。
ひとつは、Brooklyn Ampのアップグレードサービスが日本でも受けられるようになったこと。
https://www.mytekdigital.jp/contact/brooklyn-amp-upgrade/
もうひとつは、上流の改善に伴って、相対的にスポイルの度合いが大きくなっているのではないか？という心配。

アッテネーターなので信号劣化が無いということはありえない。
実際にどの程度の影響があるのか、今まではそんなに気にせずに使ってきたけど、今後のためにも確認しておく必要がある。

アップグレードによる音の変化については、stereophileに分かりやすいレビューがある。
ちょっと引用する。

Mytek HiFi Brooklyn AMP+ power amplifier
https://www.stereophile.com/content/mytek-hifi-brooklyn-amp-power-amplifier

"Sometimes, when people listen to the AMP+ version," Jurewicz continued, "they say that the older Brooklyn AMP had this nice midrange, which is essentially a grunge produced by distortions, but it seems to be acceptable in the older model.
The new model is cleaner, with a bigger soundstage and more detail.The AMP+ is more precise.
I would look to achieve that midrange sweetness of the earlier AMP through other means, using other components that are in that direction.

（訳）
「時々、AMP+バージョンを聞いた人の中に、」Jurewicz氏は続けます。「古いBrooklyn AMPのミッドレンジが良かったと言う人がいて、これは本質的に歪みによって生成された汚れですが、古いモデルでは受け入れられるようなのです。
新しいモデルはよりクリーンで、サウンドステージがより大きく、より詳細になっています。AMP+はより正確です。
私なら、そうした傾向がある他のコンポーネントを使用するなど、他の方法で以前のAMPのミッドレンジの心地よさを実現したいと思います。」

なるほど、、、
うちで使っていて、ああ、そういう感じか、、と納得がいく話だ。
要するに、バージョンアップしたら良くも悪くもSM-SX100の音に近付くということらしい。
そしてそうなると、バージョンアップはどうしよう、ということになる。

もともと、Brooklyn AmpはSX100が壊れた時の代替と考えて購入した。
そういう意味では、音が同じでも問題はない。
しかし、なんというんだろうな、、おんなじ傾向のアンプが２台あってもなあ、、という気持ちがあって、バージョンアップに踏みきれないでいる。
まあ、2年前と違ってSX100が修理不能になったときはなったときだという気持ちになっているし（どうやら代替アンプは簡単に見つかりそうなご時世だから）、極端な話、そのときBrooklyn Amp+を買ったっていいのだ。そのときバージョンアップできるならしても良い。ひょっとしたらSX100を越えるかもしれない。

そうなったときに、MONITOR1のクオリティが問題になる。
今は、気が向いたときになんとなく使う感じなので、ゆるい音質で構わない。メインで使うとなったら、ボトルネックになるようでは困る。まあ、そのとき考えればいいっちゃいいんだけど、気になる。

上流の改善は、PPAP Back Endの構成が変わったことによるものだ。Middle、Backへの分割、更に直結化（こっちのほうが大きいかな）によって、どのくらいかな、、アンプをグレードアップするぐらいの改善があった。

直結化したとき、そんなに変わらないな、、と最初は思った。しばらく聴いていて、どうも腑に落ちないと思ううちに、アンプがBrooklyn Ampであることに気が付く。なんとなくSX100で聴いてるような気になっていたのだ。
アンプを切り替えて、改めて改善していることを確認した。
つまり直結化による上流改善の度合いは、Brooklyn AmpからSX100に替えるのと同等だろう、ということだ。

そして、SX100の音の改善が、Brooklyn Ampの改善よりも、かなり大きい感じなのだ。
以前は、Brooklyn Ampは感覚的にSM-SX100の97～99%ぐらいと書いていた。これはブラインドで区別がつくかどうかぐらいで、その後もそれは変わらなかったのだけど、現在は、、90～95%ぐらい？、、多少幅があるけど。
たぶんブラインドで分かる。
そこまで差が付くのは、Brooklyn Ampにはアッテネーターを咬ませていることも影響しているのではないか。

そういうわけで、以下、試聴結果。

其々のアンプについて、MONITOR1使用の有無で音を比べる。
MONITOR1のボリュームは50で固定。普段使っている位置だ。聴感での音量を合わせるためmpd、SM-SX100のボリュームを調整した。
試聴に使った音源は下記。Deezer HiFiのストリーミングを使用した。
Whispering Forest : Walter Tilgner

まず、SM-SX100。

ボリューム : mpd:75/100 SM-SX100:50/128
以前よりも音場、音像の見通しが良くなっている。
隙間が見通せるというのか重なり具合が分かり易くなった。以前の様相をバウムクーヘンとしたら、現在はミルフィーユという感じだ。間に挟まっているのが何なのか見える感じ。それらの質感も違う。より微細なニュアンスが表現されている。
こんなこというとあれなんだが、何か次元が違う感じに良くなった気がする。

ボリューム : mpd:75/100 SM-SX100:90/128 MONITOR1:50/100
MONITOR1をDACとSX100の間に入れてみる。
音量を合わせるためSX100のボリュームを90に上げる。
音は、少しだけ霞んでいる。見通せるという感じが薄れている。
ブラインドでは聴き分けられない、かもしれない、かな？　分かっていて比べたら明らかに違うんだけど。聴き慣れてたら、ブラインドでも分かる違いだと思う。

続いて、Brooklyn Amp。

ボリューム : mpd:85/100 Brooklyn Amp:x MONITOR1:50/100
MONITOR1のボリュームは50で固定。
Brooklyn Ampはボリュームがないのでmpdで音量を調整する必要がある。聴感で音量を合わせると、若干mpdのボリュームが上がった。
これだけ聴いていたら、悪くない。
しかしSX100と比べたら、良く言えばまったりしていて、見通しが良くない。マットすぎる感じ。
Brooklyn Ampの音も以前よりは改善している筈なのだけど、比較してしまうとそんな気がしなくなる。

ボリューム : mpd:50/100 Brooklyn Amp:x
MONITOR1を外すと音量が上がるので、mpdのボリュームを絞る。
音の曇りがなくなった。見通しが良い。
かなりSX100に近付く。しかしSX100で感じられるレベルの音場、定位の明瞭さには届かない。バウムクーヘンからミルフィーユへの途上という感じかな。
それでも直結化以前のSX100よりいいかもしれない。これは記憶との照合でかなり微妙なところだ。直結以前の設定に戻して比べるといいんだろうけど、そこまでするのは色々と面倒だ。
MONITOR1併用のSM-SX100と、同等ぐらいか、いや上回っている？　ケーブル抜き差ししながらの試聴で、これも微妙だ。

今回、試聴してみたら、Brooklyn AmpにMONITOR1を併用することで、SM-SX100との音質の差が開いてきている気がする。
いや、書き方がまずくて誤解を招きそうなので訂正。以前はMONITOR1併用で気にせず聴けたけど、上流の改善に伴ってSX100の音が大きく改善したので、ギャップが気になり始めたということだ。
今のところ運用上の問題になっていないので、当面は様子を見ながら使うつもりだ。

今更だけど、やはりアッテネーターは使わずに済むなら使わないに越したことはないと思った。
問題は、使わないとmpdのボリュームだけで音量調整することになるので、音源によってはmpdのボリュームを10まで下げるとか、そういうレベルの調整が必要になること。
さすがにそうなるとデジタル信号レベルでの劣化が心配、、、
音質を維持するには、より良質なアッテネーターかプリアンプが必要ということになるだろうか。しかしXLRでつなぐ必要があるので、製品から探すとしたら機種選択が厳しい。
なかなかどうにも悩ましいので、気長に考えようかと思う。

LANの直結を今まで試みていなかったのは、利便性が低下することと、色々やりかたを調べるのが面倒だったからだ、、、
しかし、やり残していることなのでやることにした。

さて、、、先立っての試験運用を何を使ってやるか。
LAN端子を2つ以上持っている機械は、うちにはapu2以外にない。メインシステムで試すしかないということだ。
トラブルがあっては面倒なので、apu2のSDカードをバックアップしておく必要があるかな、、、
普段からバックアップを取ってないのかといわれたら、どれがバックアップなのか分からなくなっているのだ。何をやってるのかまったく分からない。

そんなことを考えていたら、そういえば暫く前にBack EndのイメージをGoogleにアップしてたっけ、と思い出した。
あれを落としてきて試せばいいんじゃないの。
tc64-11-1-base1z-2020-04-05-PPAP-BE.img
https://drive.google.com/file/d/1kHhCtR4WCWs3_8i32JrVgGFin-YK9KIZ/view?usp=sharing
そういうわけで、ダウンロード。
カードに焼く。

物理的に遠くに離してあったMIddle EndをBack Endの近くに戻す。
まず状況。

   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:40  
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42922414 errors:0 dropped:2894 overruns:0 frame:0
          TX packets:43024988 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:62288871488 (58.0 GiB)  TX bytes:62314222899 (58.0 GiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:41  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:42  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

現在、IP固定の設定はしていない。DHCPサーバーからeth0にアドレスを取得している。
今回はeth1のIPを固定してみる。

ところで、どれが0でどれが2だったかいつも分からなくなるので写真を貼っておく。
シリアルケーブル端子に近い方が0である。

IP固定は昔、piCoreを使っていた頃はよく設定していた。
だけど、最近はしていないのですっかり忘れている。というか、Tiny CoreでのIP固定はしたことがない。
複数のイーサネットポートを扱うのも初めてだ。
どうなんだろ、piCoreみたく/optにeth1.shを作って置いといたらいいのかな、、、

Middle End の電源を落として、ケースの蓋を開ける。
SDカードを入れ替えて、起動する。
以下、sshでログインしてからの経過。

vi /opt/eth1.sh

#!/bin/sh
pkill udhcpc
ifconfig eth1 192.168.10.2 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth1.sh

sudo vi /opt/bootsync.sh

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth1.sh &

filetool.sh -b
sudo reboot

viでeth1の設定ファイル「eth1.sh」を作成。IPを192.168.10.2で固定する。nameserverの記述は要らないのではないかと思ったのでコメント化した。
chmodで実行権限を与える。
bootsync.shファイルに「/opt/eth1.sh &」を書き加える。
filetool.sh -bで保存し、リブート。

リブート後、sshでログイン。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:40  
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:562 errors:0 dropped:28 overruns:0 frame:0
          TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:52631 (51.3 KiB)  TX bytes:35785 (34.9 KiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:41  
          inet addr:192.168.10.2  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:42  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

eth1に「192.168.10.2」が振られている。
次はこれをMiddle Endにしていく。
過去エントリーを参考。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210824a.htm
PPAP Back-Endをタンデム化

sudo vi /opt/bootlocal.sh

/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/ncat 192.168.10.10 4400"

filetool.sh -b
sudo reboot

bootlocal.shファイルに上記のようにコマンド記載。Back EndのIPを「192.168.10.10」とする。
これで動くのかな、、、
合わせて、Back Endのほうも設定し直していくということになる。

Back Endのほうは、イメージを焼くのは飛ばしてsshにログインして設定した。
Middle Endでの試行でIP固定の設定ぐらいまでは出来そうな目星は付いたので。
（6月8日、下記の書き間違いを修正した）

vi /opt/eth1.sh

#!/bin/sh
pkill udhcpc
ifconfig eth1 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth1.sh

sudo vi /opt/bootsync.sh

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth1.sh &

filetool.sh -b
sudo reboot

Middle Endと同じ手法で、eth1の設定を行っていく。
filetool.sh -bで保存し、リブート。

リブート後、sshでログイン。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:58  
          inet addr:192.168.1.89  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:44 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6283 (6.1 KiB)  TX bytes:5919 (5.7 KiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:59  
          inet addr:192.168.10.10  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:5A  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

eth1に「192.168.10.10」が振られている。

さて、直結で機能するかどうか。
Back Endのeth0からLANケーブルを抜く。
MiddleとBackのeth1端子をLANケーブルでつなぎ、Midlle EndからsshでBack Endにログインしてみる。

tc@box:~$ ssh tc@192.168.10.10
The authenticity of host '192.168.10.10 (192.168.10.10)' can't be established.
ECDSA key fingerprint is SHA256:eICMkwr/u6JIomP1WNI9YocJTnDxmI8M7ICHoj/oeEY.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.10.10' (ECDSA) to the list of known hosts.
tc@192.168.10.10's password: 
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@box:~$ 

いけました、、、
次、ncmpcppからFrontのmpdに音楽再生の指示を出してみる、、、音は出ました！

はあ、、やってみたら簡単なものである。
もとのつなぎ方と直結、両者の違いを図にしてみた。

音質はどうか。
例えばベールが1枚はがれたようなとか、、薄皮1枚のベール？、、
前とあんまり変わらないような。
正直、違いが分からない、、、どうなんだろう。
まあ、耳が悪いということなのかもしれない、、、

まあ、でも、せっかく設定したのだし、暫くはこれで使っていこうと思う。
暫く使った後で戻したら、こんなに違うんだっけ！ということもあるかもしれないし。

pkill udhcpc
sudo ifconfig eth0 down

pkill udhcpc
sudo ifconfig eth2 down