abk1's scratched blog 3::AUDIO DIARY

デジタルオーディオではノイズ対策が重要になる。
音楽用サーバーはコンピューターであり、筐体内はノイズが多く、ここへの対策が音質向上に効果があるという話がある。
JS PC Audioはそうした対策をしているメーカーだ。
サイトでの記載が以下。

JS PC Audio Blog
2018.01.24 Wednesday　電磁波シールド塗装を試す
http://blog.jspcaudio.net/?eid=311
2021.04.22 Thursday　過去の特注・カスタマイズ
http://blog.jspcaudio.net/?eid=420

JS PC Audio オンラインショップ
電磁波シールド塗装
https://shop-jspcaudio.net/shopdetail/000000000116/
Micro-ATXマザーボード用アンダープレート ATXUP-M
https://shop-jspcaudio.net/shopdetail/000000000187/

JS PC Audioでは、NASなどデジタルオーディオサーバーの内装にノイズ対策を行っている。上でurlを挙げたのは、電磁波シールド塗装と、銅製アンダープレートだ。

今回は、JS PC Audioさんの知見を参考にさせていただき、真似事を試みようというものだ。
うちではapu2d4をPPAPシステムのBack-Endサーバーとして使っていて、LANから受けた音声デジタル信号を、USBからDACに出力している。
これに細工をしていく。
うちのシステムでは音楽用サーバーは他にも動いているんだけど、一番、DACに近く、変化に伴う影響を確認しやすいのではないか、ということと、他のサーバーは殆どノートPCなので、こうした対策は困難だから。NASも2台あるので、それこそJS PC Audioにシールド塗装に出したらどうか、というのはあるんだけど、今回は自分で出来ることを、ということだ。

さて、塗装は難しいので、アンダープレートを参考に、うちで出来ることをやってみた。
JS PC Audioのアンダープレートは1mm厚の銅板で、基盤の下に敷くらしい。
うちのapu2d4、ケースを開けて基盤を外そうと思ったら、CPUの放熱、熱伝導のために、CPUと筐体を密着させるシート片で接着？している。
これが、けっこう硬くくっ付いていて、少々の力では外れない。
壊すようなことになってはまずいので、基盤の上面側に設置することにした。

次、何を使うか。
銅板は、ネット通販ではサイズが難しい。
そういえば、ケーブルのシールドはネット状に編んだ銅線を使っている。そういうのなら工作もしやすそうだ。ということで、銅のスクリーンメッシュを使ってみることにした。

uxcell 銅スクリーンメッシュ 50 cmx30 cm 40メッシュ
https://www.amazon.co.jp/gp/product/B09NR3NBNG/

これを15cm×30cmに切って、半分に畳んで15cm四方にして、基盤側からは絶縁に藁半紙で囲って、ケース内、基盤の上にセットした。縁を基板上のLAN端子と筐体の折り返し部分の隙間に差し込むことになるんだけど、けっこう狭くて、ギリギリな感じだ。
これをコンポにつないで電源を入れて音を聞いてみたら、なんだか効いてる感じ。
なんでしょう、このプラセボ効果は、、、
コントラストが向上している気がする。しっかりした再生音という感じだ。

そのうち、だんだん、なんだか音が滲んできた。
効果は一時的だ。
そう、まだ銅メッシュをGNDに繋いでいないのだった。
細いケーブルを半田付けして、その端に丸形端子をつけて、基盤のGNDにネジ止めする。これで滲みが取れて、安定した。

この音は悪くないようだ。
ベールが1枚剥がれクリアになって、SNが増した。陰影、音像感が向上している。
何より、安定感が増した感じ。

安定感というのは、音色の重心がしっかりして質感が向上したこともあるけど、それよりも有り難いのは、音質変動が少なくなったことだ。
うちでは、しばしば、なんだか今日は音が悪いかなあ、ということがあった。そして原因がはっきりしない。次の日には治っていたり、そうでもなかったり、日によって違うのだ。
これは困るなあ、と思っていたんだけど、それが随分、解消したようなのだ。
求めるクオリティの音が、コンスタントに安定して得られるようになった。

以前から良くなったらいいと思ってはいたんだけど、いざ良くなってみたら、想像していた以上に、非常に有り難いことだった。今日はどうだろうか、今日はいまいちだな、などと思うことなく、聴くことに集中出来る。
余計なことを考えなくていい。
いや、いいですよ。ほんとに。

さて、ネット通販で銅板を入手した。

1枚 99.9%純銅板 150mmx150mm 厚さ0.5mm
https://www.amazon.co.jp/gp/product/B0B9LSSSFZ/

銅メッシュと銅板、どちらがいいのだろうか。
というか、実際のところ銅メッシュで十分に効果が出ているので、今更変える意味があるのかと思いながらの購入だ。
銅メッシュを外して、銅板に付け替えた。

差異はあるのかというと、極めて微妙。
銅板の方が、少しだけしっかりしている感じがする。しかし、本当にそうかな？とも思う。
なにしろ、apu2の電源を切って、蓋を開けて、ネジ回しを使って付け替えて、戻して電源入れて、それで試聴なので、僅かな差異は評価が難しい。
しかし、少なくとも銅メッシュに戻そうという気には、今のところ、ならない。
しかしな、、なんか固いかな、という気がしないでもない、、、

もう暫く、様子見ながら判断するつもり。

最近、roonを試している。
無料お試し期間は2週間しかないので、なかなかきびしい。あと1日、と表示されていたのが、突然消えてお試し終了したので、結局、月払いで延長になった。
試してみようと思った理由は、ここ数年のネット環境の変化が影響しているんだけど、それは後述。

ここでは、roonとdaphileを比較してみる。
比較する意味があるのかというのはあるが、せっかくなので比較してみる。
音質の比較は、していない。というか、まだする暇がない。だから使い勝手のみの比較である。

しばらくの間、新しく気付いたことや分かりにくいところの修正を、追記していくことにした。
そんなに大したことは書かないと思うが。

	roon	daphile
インストール	基本的にはアプリケーションを使いたい環境にインストールして使う。 うちではLinuxにインストールした。 https://help.roonlabs.com/portal/en/kb/articles/linux-install coreは、ノートPCに繋いだUSB HDDに最新のFedora OSを入れて、そこにroon coreをインストール。これはroonが提供しているインストール用のスクリプトを使った。 roon bridgeはRas pi 2bにインストールしている（追記：OSはpiCore13.1）。これは「Roon Bridge (armv7hf)」の圧縮ファイルをダウンロードし展開しただけだ。 roonのサイトで説明されているとおりに環境を整えた上で、ダウンロードして好きなところで展開するだけでいいので、なんだこの簡単さは、と驚いた。 実は、coreもそれでいいらしい。 roonの起動はcuiで管理者権限でコマンドを打つので最初は戸惑ったが、分かってしまえば、まあ誰でも出来そうだ。ちなみに下記のような感じ。起動の過程で警告とかも出るが、安定して動いていると思う。 sudo /opt/RoonServer/start.sh sudo ./RoonBridge/start.sh コマンドを打ったあとはctrl+cで抜けていいみたいだ。 2024年4月、追記。 上記の操作方法は、エントリーアップ当時、どうしてこれで問題がなかったのか分からない。どうにも怪しい。あんまり参考にしないほうがいい。	daphileはgentoo linuxベースのOS、ディストリビューションだ。i686かx86_64で動く。 OSイメージファイルをダウンロードしてUSBメモリに書き込んで、起動、インストールして、設定して、と、roonと比べたら準備が面倒くさくて分かりにくい、かな。 しかし、RAM上でOSが動くので、単身で使うなら音質上のメリットがあるかも。 うちでは、USBメモリにインストールして、ノートPCで起動して使っている。
コントローラー	タブレット、スマートフォン タブレットかスマートフォンに、Google PlayとかApp Storeに登録されている「roon」をインストール。 起動したら、家庭内LAN経由でroon CoreやBridgeが表示されるので、そこから設定を行っていく。 追記。roonアプリは日本語設定できるんだけど、出来るなら英語で扱った方がいい。日本語表記だと英語と意味が違うことが時にあるので、嵌ることがある。結果、英語の方が分かりやすい。 簡単と言えば簡単（daphileに比べて設定できる項目も少ない）だけど、分かりにくいことも多い。 僕の場合、聴きたい曲が終わった後で、勝手にroonが選んだ曲が再生されるのに困った。鳴らないように設定する方法を見つけるのに、１週間以上かかってしまった。 PC、Mac（roonアプリ） roonではフィルターを調整したりサンプルレートを変えるなど、設定することが出来る。 そうした高度な設定をしようと思ったら「MUSE」というツールを使うんだけど、タブレットからでは全ての機能は使えないようだ。結局はWindowsかMacにroonをインストールして、そこからMUSEを操作する必要がある。 うちにある古いMac miniにインストールしようとしたら、OSが古いのでroonが動きません、と来た。しかたないのでたまたま最近購入したMac mini M2（主に子供が使っている）にインストール。起動したら自動的にfedoraのroon coreがつながって表示された。 roonのサイトの中で、いくら探してもインストールできるMac OSの条件が書いていない。Windowsについても書いてないようだ。roonというのは、全般的にそういうところがある。 ちなみに「roon mac 条件」でググると、「WindowsではWindows 7以上が必要で、Windows 10が推奨されています。 MacではOS X 10.8（Mountain Lion）以上が必要で、OS10.11（El Capitan）が推奨」と表示されるが、うちの10.13.6（high sierra）で動かない。 ついさっき、roonに下記のように書いてあるのを見つけた。 https://roon.app/en/termsandconditions MAC OS X OPERATING SYSTEM [VERSION 10.9 OR HIGHER] それじゃあ動かんかったが。	PC（ウェブブラウザ） サーバーにDaphileをインストールしたら、起動時にモニターにIPアドレスが表示されるので、家庭内LAN経由でアクセスできる。スマホアプリもあるけど、daphileの場合、パソコンのウェブブラウザからアクセスするのが扱いやすい。そこから設定や操作を行う。 追記。日本語表示には出来ない、と思う。 僕の場合、広い画面とキーボード、マウス等が使えるのは圧倒的なアドバンテージだ（タブレットなどの狭い画面で指で繰り返しスクロールするとか文字入力が不便とか、嫌いなのだ）。 それにしても、Daphileもいいかげん、ユーザーに対して不親切なんだけど、roonとは不親切さの毛色が違う気がする。なんというか、daphileは修行感があり、roonはトラップ感があるような。 タブレット、スマートフォン Squeezerとか使えるコントロールアプリもあるけど、うちでは補助的な感じ。
音源	１：NAS NASをマウントするのに、ウェブ上を検索してやり方を調べる必要があった。 後からMacでやってみたが、タブレットやスマホから設定するよりMacのほうが分かりやすい。なにしろタブレットでは「ネットワーク共有を追加」という表記が、表示されないのだ。 ボタンは一応ある。「/▼」こんな感じで。 ここから共有フォルダを設定出来るとはなかなか気付かない。 もうちょっと分かりやすくして欲しい。 ちなみにSMB（cifs）の共有フォルダの設定は、こんな感じに書いたらつながった。 \\192.168.1.80\SharedMusicFolder (\は半角バックスラッシュ) ２：ネット配信 対応しているサブスクはTidal、Qobuz、KKBOX。これらは契約してないので聴けない。 Dropboxに対応。ネットラジオに対応。日本のだとOttava Radio、Jazz Sakuraが聴ける。他、海外のが多数。 ３：ローカル音源 今回はつないでいない。	１：NAS 後述する理由で、うちではあまり使っていない。 NASのマウント方法は以前このサイトでも書いた。 nfsの場合は、記載例が表示されるので比較的簡単だと思う。 しかしcifsは、例が表示されないことに、今回気付いた。難しいんだねcifsって。あちこちでうまくいかないと言ってる理由が漸く分かった。 ２：ネット配信 ストリーミングは各種プラグインで対応。僕が契約しているサブスク、Deezer、Spotifyが両方聴ける。Tidal、Qobuzにも対応してるが、僕が契約していないので聴けない。 追記。 2024年2月からDeezer、TidalはDaphileで聴けなくなる。詳細は省く。Spotify、Qobuzは引き続き対応している。 2024.04.22.更に追記。 DaphileはDeezerに対応した。但し「プレミアムアカウントのみ対応」とプラグインの注意書きに書いてある。 ネットラジオに対応。今回気付いたが、ラジオ局の検索が局名、urlで可能だ（しかし、便利なのかどうかは分からんな）。地域ローカルを探すことも出来る（例えば岡山だとFMつやまが聴ける）。 他には意外なとこでYoutubeの音声が聴ける。これは侮れない。 ３：ローカル音源 つないでいない。
ディレクトリ表示	× ディレクトリ構造の表示はできないようだ。 その代わりに、検索機能を駆使しないと快適な運用はできないと思う。 検索は、あんまり優秀ではない気がする。Amazonの検索と同等ぐらいの印象かな。 そして検索を補完する機能として、ファイルに書き込まれる「タグ」が重要になると思う。後述するが、うちではこれが満足に機能しない。 検索の印象がいまいちなのも、これが影響しているかもしれない。 2024.04.22.追記。 〇 Hell freezes over: How folder browsing came to Roon - Roon Labs https://blog.roonlabs.com/folder-browsing/ Roonはディレクトリ表示に対応した。賛否あるようだが、僕は使い易くなった。	〇 NASをマウントしたら、ディレクトリ構造を表示できる。 つまり、自分で構築したライブラリの構造を、使用する際に利用できるということだ。 僕の場合、これは大きい。固有名詞を思い出すのが苦手なので、どこのあたりに置いた音源、って感じで探すことがあるので。 しかし、後述する理由で、最近はDaphileにはNASはマウントしていない。 上記のような運用の時は、mpdクライアントのncmpcppを使っている（mpdはディレクトリ構造のライブラリ運用が基本になっていると思う）。
cue sheet対応	× cueシートは読み込まないようだ。	〇 cueシートを読み込みデータベースに取り込む。 これはすごい機能だと個人的には思うが、ファイルが多くなるとサーバーへの負荷が大きい。
安定性 ライブラリ	◯ 使用期間は数週間だけど、安定しているように思う。 マウントしたNASの音楽ファイル7千枚分のデータも読み込んでいるようで、特に不具合はない。 まあ、その程度の枚数ならmpdのライブラリとかも安定しているので、それ自体に驚きはない。 roonの場合、音楽のライブラリとしての機能、ミュージシャンや作品のつながりとか、ネット上の情報やリンクなどが付与される。 こうした情報、どこまでroon core上に蓄積されているのか、はっきり分からない。 そこで、うちの家庭内LANをインターネットから切り離して試してみたが、ちゃんと機能するようだ。つまり、roon coreにそうした情報を込みでライブラリ化していると思われる。なかなか凄いことだ。	△ NASの共有フォルダをマウントすると、Daphileはデフォルトで音源のデータをライブラリに読み込む。 同時に、cueシートもライブラリに読み込むのだけど、うちの環境（なにしろ7千枚ほどのアルバムファイル各々にcueシートが付いている。アルバム1枚10曲としてデータ量は10倍になる）ではサーバーへの負担が大きいようで、過去にはクラッシュを繰り返した。 なので、最近はNASをマウントする使い方はしていない。今回、臨時の都合でマウントしてみたが、ファイルが少ないフォルダに限定して、負荷が少なくなるように配慮している。 まあ、cueシートを多用していない場合には問題にならないかもしれない。 プラグインのアップデートがあるときに、なぜか若干、不安定になるというか、音質が落ちるような気がする。 なんか音悪いな、と思ったらアップデートが来ているということが、よくある。
UPnP	× roon coreをUPnPレンダラーに出来たらおもしろそうなのに（daphileからDeezerの信号を送信できる）、残念ながら出来ない。	〇 プラグインを使うことでUPnPサーバー、レンダラーとして使うことが出来る。 うちではサーバーにして、UPnPレンダラー化したmpdにデータを送っている。
RAAT	〇 RAATで伝送。これは音質上有利らしい、が、どうなんだろう。	× RAATは使えない。
squeezebox	出力先として設定することが出来る。 但し、他でLMSが動作している環境では併用出来ない。roonでsqueezeboxを使おうと思ったら、同一環境のLMS（例えばdaphileサーバーとか）は止める必要がある。	LMSからデータを出力することが出来る。 roonと同一ネットワークでsqueezeboxを共有することは出来ない。roon側の設定を止めるか、daphileを止めるかということになる。 roon側で設定してなければ、共存は可能だ。
使用感	出来ることが絞られてる割には、使い方が分かりにくいと思った。	分かりにくいことが度々ある。多機能、複雑なので、だろう。汎用性は高いと思う。
音源情報	〇 例えば、アルバムに参加したミュージシャンが一覧される。どのトラックに誰が参加してるのか紐付けされる。 ミュージシャンやアルバムの情報には、wikipedia等の記述やレビューが引用され、そこにはリンクが貼ってあって他のミュージシャンや作品に飛べる。 歌詞が表示される。 ツイッターアカウントや、フェイスブック、本人のサイトへのリンクが貼られていることもある。これも便利。ライブの情報とかが表示される場合もある。 ここらへんは、使えるストリーミングに契約していたら、もっと得られる恩恵が広がっていくのだろう。 ひとことでは説明しきれないんだけど、なるほど、これはすごい！、と思った。 特にジャズと、洋楽で恩恵が大きいと思う。 逆に恩恵が少ないのが、意外にクラシックと、当然かもしれないがJポップだ。 × 弱点としては、全ての情報が網羅されているわけではない。 マイナーなミュージシャンの情報はないことが多い。 なぜかバンドメンバーの一部しか表示されないとか、欠けてることもある。この人の情報がなんで表示されないのだ、というケースもある。 例えば「ジャンル」という区分けがあって、そこにいろんなミュージシャンが分類されているんだけど、どこにも表示されない人がいる。そういう人は情報がない。いや、逆か。情報がないからジャンル分けされないのだろう。 そんなことになる原因のひとつは、おそらく僕の「タグ付け」とroonの相性が良くないからだろうと思う。 例えば坂本龍一は、ダウンロード購入したファイルはネット上の情報へのリンクが表示される。坂本龍一だけあって、いろんな情報が出てくる。 しかし僕がリッピングしてタグ付けしたアルバムファイルには全く表示されない。 この場合、ミュージシャンのタグやファイル名が「sakamoto ryuiti 坂本龍一」などとなっていたりする。ryuichiだったら違うんだろうか。分からないけど。 これはうちでライブラリを構築し始めた初期に「ち」は「ti」で統一すると決めたので、そういうことになっている。他にもサ行、タ行周りなど一般的なローマ字表記（ヘボン式という）と違うところがある。うちのは訓令式という表記だ。 しかし、それだけで説明できないこともある。例えば、作曲家のGeorge Enescuは情報がない。wikipedhiaへのリンクすらない。マイナーだから？と思いきや、Vivaldiも情報がない。 何故なのかよく分からない。 Perry FarrellやSex Pistolsも情報がない。Caetano Velosoもない。マイナーとは言えないと思うのだけど。 一方で、Dream DolphinはXアカウントへのリンクがある。そんな感じでいろいろ不思議だ。	〇 PCのウェブブラウザで操作するので、そのまま直接、そのブラウザで新しいタブかウィンドウを開いて、そこから直接、ネット情報にアクセスできる。 しかしこれは、Daphile自体がネットと連携がいいというわけじゃあ、ないんだね。そういう環境が傍に同居してるということだ。 × ところが最近、普通にネット検索していては、情報が簡単に得られない。 作品名やミュージシャンの名でネット検索して引っかかるのは、大量のストリーミングサービスへのリンクで、音楽そのものの情報は直ぐには見付からない。 目を皿にしてスクロールして探さないといけない。うざったくて仕方ない。 実は、これがroonに触ってみようと思った一番の理由だ。今回、roonを使ってみて、なるほどこれなら、かなり目的に適うかな、と思った。
画像表示	△ 音源、アルバムの８、９割がたは絵が付いていない。間違っているケースもある。 画像データは、どうも、僕が音源ファイルを置いた同じフォルダに入れた画像ファイルからセレクトしているようだ。 うちのNASでは、アルバムミュージシャンでフォルダ分けしている。そこには複数のアルバム音源ファイルと、アルバムのcueシート、アルバムの画像ファイルが、まとめて入っている。 １つのアルバムのファイル名は、拡張子以外は同じにしている。 うちでのそういったファイル管理方法を、roonが理解できるわけがない。 たぶん、roonに理解できるルールに沿って画像ファイルに名前をつけたら、問題なくroonアプリ上で表示されるんだろう、と思う。 ミュージシャンは、有名どころは写真が付いて分かりやすい。 これらはネット上から（roonのサーバーから？）画像を引っ張ってくるんだろうけど、意外な人に写真がなかったり、あったりする。 うちでは写真がない人も多い。前述したタグの問題も関係しているのかもしれない。 あと、ライブラリ画面を高速でスクロールすると、表示がずれる。名前と画像が食い違って表示される。これはハードのスペックによって違うのかもしれない。	△ アルバムのアートワークが表示され、絵が付かないのは少ないが、しばしば間違えている。 こちらもどうやら、音源ファイルと同じフォルダに入っている画像から合っていそうなのを表示している。 なぜ合うのと合わないのがあるのか、roonもだが、謎である。 ミュージシャンの画像は表示しない。

こんな感じ。

上記、比較表の中で書いた、roonを試した理由。
PCからウェブブラウザで普通にネット検索しても、音楽の情報が簡単に得られなくなった。検索しても、大量のストリーミングサービスへのリンクが大量に上位で表示される中から、見落とさないように注意しながらスクロールして探さないといけない。
うざったくて仕方なくて、roonに触ってみようと思ったのだ。
今回使ってみて、なるほどこれなら、かなり目的に適うかな、と思った。

roonのライブラリは大したもので、それ自体が触っていて面白いし、アルバムなどに個人的なタグを付けるとか色んな使い方が出来るらしいので、発展性もあるんだろう。そういった環境で、音楽を深堀りしていきやすい。
しかし、そこにかける時間が自分にあるのか、そういうやり方が僕の聴き方にあっているのか、どうなんだろう。

あと、月額12.99ドルで1900円、生涯ライセンスで12万円に見合うかどうか。
というのは、表示されない情報もすごく多いのだ。
そういうのは結局、PCでウェブブラウザで探すしかない。おそらくTidal、Qobuzと契約していたら、だいぶ見える景色も違うのだろうと思うけど。

まあ、もうしばらく使ってみる。

前回のエントリーで、LANの構成図をアップした。
今回は、引き続きLANネットワークを見直し、DACの電源も見直した。
現在のLAN構成図は以下。

上流には、HuMANDATA LNX-007Lを追加している。
音が激変した（最近、激変が多い）。
下記に、JS PC Audio オンラインショップから画像を引用。JS PC Audio Blogから説明を引用。

LANアイソレーター LNX-007L
https://www.shop-jspcaudio.net/shopdetail/000000000136/

JS PC Audio Blog
http://blog.jspcaudio.net/?eid=403
「LANアイソレーター LNX-007Lの挿入はもうひと押し欲しいという方にお勧めです。LNX-007Lはフレームグラウンドが繋がっていませんが、端子を使って短絡することも可能な製品です。改善の効果としては、薄いベールが1～2枚剥がれるようなイメージです。」

薄いベールが1～2枚、、、
うちでは1個使用でいきなり、なんというのか、耳から鱗が落ちるというような、それほどの違いがあったように思う。
最初は、PPAP middle-endの手前で使用した。
２つ目はback-endの手前で、そこまでの大きな効果は無かった。
しかし、更に2個、追加して見ようと思い、ONUの周囲で追加した。まあ、取り敢えず、ここらあたりまでかな、、、でも追加の副作用は全く感じないので、更に追加したら何か変わるだろうか、という気持ちはある。
どこで使うのが一番有効なのかは確認していない。一旦付けたらもう外せないと思った。

最近、MFPCが複数台使用から1台に集約されたという話があって、どういう意味だろうと思っていたんだけど、今回、このようなことがあって、音声データがネットワークを経由する弊害から逃れられることには、僕が思うより大きい利得があるのかもしれないと思った。
まあ、見当違いかもしれないけど。

僕の場合は、Daphileは使っているしmpdアップサンプラーはマシンパワーを食うしPPAPは1台に出来ないしで、集約するという方法論は無理なので、暫くは複数台連携でやっていくことになるだろう。

あれこれするうちに、若干だがPPAPサーバーの配置が変わった。
middleとbackの間にハブとアイソレーターが入っている。
実際のとこ、どう配置するのがベストなのか確認していないんだけど、悪化はないのでこの配置で暫く使うつもりだ。

さて、同時に、下流も久しぶりに少し変わっている。

ADI-2 DACと、Pegasus R2R DAC、以前は安定化電源のBY50Sから電源を取っていたが、PB-500-2に繋ぎ変えた。
昔、大して変わらないと思った筈なのだけど、今回繋ぎ変えてみたら、音の陰影がまるで違った。絵で言えば黒が深く色が鮮やかに、空間への浮き方がくっきりして、実体感が増したように思う。
我ながら迂闊だったが、気が付いてよかった。

思い当たるのは、BY50Sのバッテリーがヘタってきてるのが原因ではないかと。
違うかもしれないが。
BY50Sは数年に1回、バッテリー交換しないといけないのだ。そろそろ、そういう時期になる。考えてみたら、そういう配慮をしないといけない電源は、配慮が行き届くしっかりした人じゃないと扱いにくいかもしれない。というか、僕のようなずぼらな人は気を付けないといけないのだろう。
そういう意味で、PB-500-2のほう管理が楽かもしれない。

些事だが、今回からサブシステムは図から外した。
CDはメインシステムで聴くようになり、殆ど使わなくなって久しいので。

前回のエントリーで、システム構成図をアップした。
そこでも書いたけど、上流はゴチャゴチャして整理がついていない。
今回は、家庭内LANの構成を図にしてみた。以前にも作ったことがあるけど、そのときには描いてない部分も書き込んでみている。

追記。
せっかく作った図ではあったんだけど、ONUをOMUと書き間違えている。直すのも面倒なのでこのままにする。

6月下旬の時点で上図のような構成。
黄色がノートPC。紫枠がボードPC。緑枠がNAS。白がスイッチングハブ。グレイがその他のサーバー（DHCP、AP。スイッチングハブと兼用だ）。
なんでこうなってんの、という感じに建て増しの跡がある構成図だ。

ネットワーク上のノイズはオーディオに悪影響がある。今回、問題と思われる場所に手を入れていくことにした。

まず、5GHzで動いているAP。
これは、最初に動かしていたAP（AtermWG300HP）に接続エラーが多かったのを、接続が集中しているせいかもと考えて追加した物だ。
それで状況が改善した印象はなかったが、せっかくあるのだからと使っていた。
こんなところにシステム構成上重要なmpdサーバーが繋がっているのは、置き場が他に確保できなかったからだ。APはノイズ源なので音に影響するかもしれない。

実際のところ、5GHz APは近くにしか電波が届きにくくて使いにくく、いらないと判断し止めることにする。理由は分からないが、エラーもなくなってることだし。
更に、敢えて機能が多い機械であるATERM-16E2EDを此所に使う必然性はないので、NETGEAR GS105に替えて、接続の配置も変える。

音は、変更していくに連れて改善したように思う。ベールがはがれていくような感じ。
しかし、ブラインドで聴き分けるのは難しいかもしれない。

次に、mpdサーバーで処理されたデータ信号がOMUONU、DHCPサーバー（ノイズ源）であるPR-500MIを通るのは良くないのではないか、ということで、3通り接続を変えて試してみた。

ストリーミングの音楽データは、ウェブからPR-500MI、Daphile、PR-500MI、mpdサーバーであるHP PB 450G9、と流れて処理される。
そこから、GS105E、PPAP Back End、と流れていく。

3番目の接続は、ProBook 450G9で処理された信号がPPAP Back Endに向かう際にPR-500MIを通らないのでノイズの悪影響が少なく音がいいのではないか、と予想したのだけど、1番目と変わらない感じ。
意外なことに、信号がPR-500MIを通る2番目が一番良かった。
耳のいい人だったらブラインドでも区別出来るかもしれない。

2番目と1、3番目で何が違うかといえば、NETGEAR GS105Eに繋がっているLANケーブルが２つか３つか、ということだ。
ハブの負担が少ないことに意味がある、のかな、、、

次は、PPAP back-endの近くに音源用のNASが2台あるのがどうなのかと。

これも置き場の確保が難しくて現在の場所に置いてある。
外してみたら音は良くなるのかどうか。
単純に、LANケーブルを外して接続を切って聴き比べた。音源はストリーミングのDeezer HiFiを使った。
これは、意外に差が出なかった。違うような違わないような、、、

NASを移動できる場所もないので、このままで様子を見ることにした。

そういうわけで、現在は下図のような接続になっている。
大して変わっちゃいないが。

あれこれ試みる前と後で、ベールが1枚ぐらい剥がれたぐらいの違いはあるような気がする。
今すぐにできるところはこんなところか。整理がついたとは言いにくいけど、マシになってはいると思う。

前回の状況報告から1年経っている。若干システム上流に変更がある。下流は全く変化がないと思う。
最近のシステム構成は下図のような感じ。

上流は、本来すっきりしている方がノイズが少なくていいのだけど、ごちゃごちゃしている。
mpdサーバーが2機、Daphileサーバーも2機。
これが、恒常的に続くのかどうかもはっきりしない。というか、外すことに意味が見出せないというか、いや、ノイズは減るんでしょう?と思うんだけど、なんか動かしときゃいいじゃないの、大して変わらんじゃないのというか。

Daphileサーバーは其々、メイン機とテスター機で、Youtubeプラグインはテスターにしか入っていない。Youtubeは頻繁には使わないので、今更、メイン機にインストールする気がしない。

mpdサーバーは、1台は先代メイン機で、SRCの設定はMediumで、サンプリング周波数は768kHz。
もう1台は現在のメイン機で、SRCはBestの設定で動かしている。サンプリング周波数は384kHz。なんで２つ動かしているかというと、いちいち設定を書き換えてmpdを再起動するのが面倒だから。

そういうわけでPPAP Back-Endでは、PCM信号を受けるncatコマンドを２つ動かしている。
今後、SRCの効き方を聴き比べようかというようなことになったら、さらにncatを追加して動かすかもしれない。

PPAPの設定は、FrontとBack-End、ペアでしないといけない。設定変更する際に、いちいちFrontのmpdとBack-End、両方の設定を書き換え再起動するのはめんどうだ。
Back-Endで複数のncatを動かして、其々に受け取るPCM信号を予め設定しておけば、設定変更して再起動するのがFrontのmpdだけになる。
そうなると、比較視聴の運用が相当手軽にできる。

まあ、先のことになるだろうけど。
なんというか、こんな感じで気が抜けた状態で、聴き専状態になっている。

Medium/768kHzとBest/368kHzを比較して、はっきり後者の方が音がいいといえる音源は、環境音を録音した音源だ。
例えば下記のようなもの。
Walter Tilgner - Waldesrauschen (Whispering Forest)
https://www.discogs.com/ja/release/8318592-Walter-Tilgner-Waldesrauschen-Whispering-Forest

鳥の鳴き声が、なんというか、人間が作る楽器よりも複雑な音を出せるということがより明らかになるというか。キツツキが木を叩く音のリアルさが、こんな言い方したくないが、激変するのだ。
一方、人が作る音楽は、そこまでの差は出ない。
もちろん差はあるのだけど、大抵の音楽の場合、キツツキほどの差は出ないし、音楽を聴いての感動の質には大差がない。デリケートな音色をした音源は違いが大きく出るように思う。とか言ってるが、まだそんなに多くは聴き込んでいないというのが実際のところ。

世の中がわけがわからないので疲れぎみ。コロナにも注意がいる。頑張っていかないといけない。

前回のエントリーでは、TC64-11.1 mpdサーバーをHP Probook 450 G9で動かした。
どこまでやれるか試しているのだが、ここで問題がある。

カタログ上、450 G9のCPUは最高4.9GHzで動く筈だが、3.7GHzまででしか動いてくれない。
インテルのCPUにはターボ・ブースト・テクノロジーというのがあって、負荷がかかると自動的にクロック周波数を上げるのだけど、それが充分に機能してない？ようなのだ。
原因が分からない。

ネット上で調べたところ、原因として考えられるのは、熱の問題、電力の問題、BIOSのバグ、これらは該当しないだろう。
あと、AVX2、AVX-512のような遅いSIMDがクロックを下げるとか。
これはよく分からない。アクティブなコアが増加するとクロック周波数の上昇率が下がるということらしいが、mpdサーバーで動いているプロセスは少ない。
ほとんどのコアは仕事をしてないようにすら見えるので、これも違う気がする。

うちのmpdサーバー EliteBook 820 G2の状況をメモ。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2886.755
cpu MHz		: 2831.833
cpu MHz		: 2697.611
cpu MHz		: 2694.282

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
tc@box:~$ 

powersaveで動いている。
CPUは2.30GHzだが、動くときには2.8GHz以上で動いている。i5-5300Uのターボ・ブースト利用時の最大周波数は2.90 GHzであり、ブーストが機能している。
（powersaveでもブーストは効くんだね）

そういうわけで、Probook 450 G9のi7-1255Uでターボ・ブーストが機能しない？のが残念な状況だ。
正直、買って試してみないと分からないな、というのはあったので想定内といえばそうなんだけど、820 G2で動いてるんだから多分いけるだろう、と甘い判断をしたわけだ。、、

Probook 450 G9をmpdサーバーとして動かしてみたときの状況。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2608.375
cpu MHz		: 2643.276
cpu MHz		: 3700.000
cpu MHz		: 3700.000
cpu MHz		: 820.543
cpu MHz		: 1357.115
cpu MHz		: 2889.705
cpu MHz		: 1141.198
cpu MHz		: 2205.000
cpu MHz		: 2569.790
cpu MHz		: 1859.254
cpu MHz		: 888.040

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
*snip*

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: 12th Gen Intel(R) Core(TM) i7-1255U
*snip*

tc@box:~$ 

こんな感じで3.7GHzが上限になっている様だ。なんでかねえ、、、

https://www.intel.co.jp/content/www/jp/ja/products/sku/226259/intel-core-i71255u-processor-12m-cache-up-to-4-70-ghz/specifications.html
インテル® Core™ i7-1255U プロセッサー

上記のインテルのサイトによると、
Performance-coresの数　2、Efficient-coresの数　8
Performance-core最大ターボ・フリークエンシー　4.70 GHz
Efficient-core のターボ・ブースト利用時の最大フリークエンシー　3.50 GHz
とある。

https://xtech.nikkei.com/atcl/nxt/column/18/02268/111800001/
最新のインテルCPU、第12世代Coreシリーズは何が違うのか
日経クロステック 2022.12.12

上記記事によると第12世代のインテルCPU、つまりi7-1255Uは、PコアとEコア、2種類のコアを積んでいると。
高い性能が必要な処理はPコア、負荷は低いが常時実行するような処理はEコアが向いているそうだ。
性能を重視した従来のCPUコアがPコアであり、性能よりも電力効率を重視したのがEコアで物理的サイズはPコアの4分の1と。
そんな構造なので、スレッドごとの処理を適切なコアに割り振る「スレッド・ディレクター」というのがCPUに組み込まれていて、負荷が高い処理はPコアに振り分けされるらしい。

実際、topでの挙動を見ると、mpdの処理は専ら「CPU0」と「CPU2」、２つのスレッドが代りばんこに受け持っているようだ。CPU0～3がPコアのスレッドなのかな。
これは、４つのスレッド全てでリレーする、820 G2のi5-5300Uの挙動とは異なる。
しかしそれなら、4GHz以上で動いてもいいと思うのだが、、、

ネット上を調べていたら、CPUの動作クロックを設定する「cpufreq」というツールがあり、Tiny Core 11では「cpupower.tcz」という形でリポジトリ上にあるらしいということが分かった。
インストール。

tc@box:~$ cpupower
Usage:	cpupower [-c|--cpu cpulist ]  []
Supported commands are:
	frequency-info
	frequency-set
	idle-info
	idle-set
	set
	info
	monitor
	help

Not all commands can make use of the -c cpulist option.

Use 'cpupower help ' for getting help for above commands.

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 405 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 657 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

「powersave」を「performance」に変更。
これで、CPUがパフォーマンス優先にセットされた。

これでどうかというと、やはり、3.7GHzまで。
どうしたものかな、と思いながら使っていたら、ときに3.7GHzより少し上が出る。コンスタントには出ない。しかし、どうやら出せないわけじゃないんだろうなと。

そこで、BIOS関係で節電に関する設定を調整してみることにした。

ネット上に公開されているHPのマニュアルから引用。
HP PC Commercial BIOS (UEFI) Setup
Administration Guide
For Commercial Platforms using HP BIOSphere Gen 7-9 2020 -2022

5.9 Power Management Options Menu

Runtime Power Management	When checked, enables the processor to run at lower frequencies (P-states) when higher performance is not needed. When unchecked, the processor always runs at maximum frequency.
Extended Idle Power States	When checked, enables the processor to rest in lower power states (C-states) when idle.
Power Control	When checked, enables the notebook to support power management applications such as IPM+ that help enterprises reduce power costs by intelligently managing the battery usage of the notebook.
Battery Health Manager	Sets charging policy based on optimizing for battery life or for battery duration. The possible settings are: • Maximize my battery health • Let HP manage my battery charging

しかし設定できる項目が少ない。こんなもんなのかなあ。
ネット上の日本語マニュアルは古いので英語の方を読む。日本語版には書いてないようなことが書いてある。

とりあえず、下記のように設定してみた。

Runtime Power Management	on → off
Extended Idle Power States	on
Power Control	on → off
Battery Health Manager	Let HP → Maximize

設定変えたら、ほとんど動いていなかったEコアたちが一斉に動きだし、音が途切れるように。
Pコアに重要な仕事を降るということをしなくなったようだ。
変更した設定を戻していく。
Power Controlを「on」に。

Pコアに仕事を降るようになった？ようだが、それでも音が途切れる。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: no
    Active: no
tc@box:~$ 

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 841.518
cpu MHz		: 1462.869
cpu MHz		: 1700.000
cpu MHz		: 1703.346
cpu MHz		: 634.992
cpu MHz		: 1034.485
cpu MHz		: 1013.223
cpu MHz		: 1197.852
cpu MHz		: 1119.194
cpu MHz		: 977.032
cpu MHz		: 1196.461
cpu MHz		: 1198.542
tc@box:~$ 

なんか、すごく上手くいってないっぽい。IntelのCPUだという認識が出来ていない。
クロック周波数も上がっていない。

Runtime Power Managementを「on」に戻す。
Power Controlを「off」に。
これで、まともに音が出るようになった。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 966 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
*snip*

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
tc@box:~$ 

これで700kHz台を出そうとしたが、やはり10秒ほどでぶちぶち途切れる。
300kHz台だと問題なく音が出る。
音が出ているときのCPUのクロック周波数の上限は3.7GHz付近で変わらない。
まともに音が出ていないときは、クロック周波数も上がっていない、ということがある。ここの辺り挙動が謎だ。

ちょっと気になったのが、BIOSの説明書に出てきた「IPM+」というもの。
電源管理を行うソフトらしい。
Windowsで起動したら設定できるらしいので、セキュリティブートを有効にしてWindowsを起動し確認してみたら、インストールされていないようだったので、ほっとくことにする。

結局、BIOSの電源関係はあまり関係ないように思われた。

もしかして、Tiny Core OSの問題？とも思ったりもするが、調べてもはっきりしないし、確信もない。

この件は、当面、保留である。

そういうわけで、HP Probook 450 G9 mpdサーバーは、libsamplerateの設定を「Best Sinc Interpolator」、アップサンプリング設定を384kHzで動かしている。

そこそこ余裕を持って動いているように見える。
というのは、topで見るとmpdを担当するCPU0、CPU2、2つのスレッドがともに休んでいる時間がそこそこ見えるからだ。
比較したら、820 G2でMedium、768kHzで動かす方がもっと余裕がある挙動で動く。
Bestの設定は、やはり相当、重いのだと思う。

音はそれに見合うものがあると思うのだけど、音質の確認は流し聴きだけで、十分にはしていない。
音源によってはリアリティがMedium、768kHzより高いと思う。
Medium、768kHzと、Best、192kHzだと、どっちがいいかは好みにもよるかも、みたいな感じだった。これらも真剣に比較しないまま今に至ってるんだけど、Best、384kHzは、それらの水準を超えると思う。

今後、余裕がある時に確認していこうと思う。
課題はいろいろ残っているけど、無理せず、焦らず、という感じ。

今月は、TC64関係のエントリーを２つ上げている。
HP Probook 450 G9で起動できるTC64-14を作るところまでこぎつけた。
今回は、450 G9でmpdサーバーを動かそう、というものだ。

動かすといったって、いちからmpdなどなどをインストールしてサーバーを構築しようというのではない。けっこう大仕事なので、そこまでする余裕はない。
現在、使っているTC64-11.1 mpdサーバーと同じものを、450 G9で動かそうということだ。

もちろん、そのままでは起動できない。
ブートローダーが新しいBIOSである「UEFI」に対応してないからだ。
しかし、Tiny Core Linuxというのは、かなり融通無碍なディストリビューションだ。
タイトルにあるように、過去の資産を使って、動くものを設えようというのが今回の話。
そんなに長い話にならない。

準備するのは、
１）　インストールするためのUSBメモリ、１つ。
２）　現在のPCオーディオシステムに使っているmpdサーバーTC64-11.1のイメージファイル。
３）　先日作った450 G9で起動できるTC64-14のイメージファイル。

さて、手順だ。

上記の２）、３）を日常使いのPC（うちのOSはFedora）上に準備する。
（今回の場合、２）は過去にバックアップしたimgファイルがある。３）も先日作ったのをパーティションイメージとして保存している。）

USBメモリを日常使いのPCに刺し、インストールするパーティションを作る。
mpdサーバーのimgファイルの大きさは500MB強なので、1GBもあれば十分以上。
使うソフトはユーティリティの「ディスク」。
ファイルシステムは「FAT」を選択。
パーティションが出来た時点で、自動的にシステム上にマウントされファイルブラウザに表示される。ここにmpdサーバーをインストールしていく。

次に、mpdサーバーTC64-11.1のイメージファイルを「ディスクイメージマウンター」でマウントする。ファイルブラウザ上に表示されたimgファイルアイコンを右クリックで、メニューからアプリ選択するので手軽で簡単だ。
マウントしたmpdサーバーTC64-11.1のボリュームから、「tce」フォルダをコピー、USBメモリの1GBのボリュームにペーストする。

次に、TC64-14のイメージファイルを同様にしてマウントする。
マウントしたTC64-14のボリュームから、「EFI」フォルダと「syslinux.cfg」をコピー、USBメモリの1GBのボリュームにペーストする。

以上で出来上がりだ。
450 G9でブートできる。

こういうコピー＆ペーストでOSインストールする方法は、Tiny Coreの入門書に書いてある。
http://tinycorelinux.net/book.html

過去にこうしたやり方は何回か試みたことがあったんだけど、なぜかついぞ上手くいったことが無かった。
だから今回、これで動くようなので、僕自身がびっくりしている。
（ファイルシステムに無頓着だったから上手くいかなかったのかもしれない）

そのうち、暇が出来たら使ってみようと思う。
しかし、使えるのかな、これ、、、

（使えました、、取り敢えずBest Sinc Interpolatorで384kHz、この音はいいかもしれない、、、）

前説

最新のコンピューターを使うには新しい知識が必要だ。それらはどんどん古くなる。
アップデートしないといけないんだけど、僕の場合はどこかに書いておかないと忘れるので備忘録として書いておく。
今回、オーディオの話はないんだけど、Tiny Coreはうちではオーディオ以外で使うことはあまりなさそうなので、オーディオのエントリーにしておく。

まず今回、HP ProBook 450 G9を入手した。
HPのネットショップで注文。
メモリはデフォルトの8GB DDR4-3200のままだが、CPUを「Intel(R) Core(TM) i7-1255U」に変更。最大4.7GHzで走る。
新品のPC購入、しかも10万円以上なんて、たぶんMacBook Pro (Mid 2010)以来じゃないかな。

450 G9、とりあえずTiny Coreを走らせようとして分かったこと。

ブートはセキュリティがかかっている。
流石、最新型だ。
セキュアブートをOFFにしないとUSBからは起動しない。
OFFにしていたら、元々インストールされているWindows11からは起動できなくなる。ONに戻したら起動可能になる。
ちょっと、ややこしい。
側から見ただけではONなのかOFFなのか分からない。覚えておくか、BIOSの確認が必要だ。

32bit OSは起動しない。
つまり、Tiny Coreのインストール用イメージである「CorePlus」は起動できない。
2019年10月のエントリー（http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027a.htm）に書いてある手法は、そのままでは使えないことが分かった。

途中、ProBook 430 G5も弄ってみた。

先ず、「TinyCorePure64-14.0」のイメージをUSBメモリに書き込み、PCに刺す。
PC起動、escキー、f10キーからBIOS設定画面に移行。
Advanced画面を開く。
Secure Boot Configurationから、Configure Legacy Support and Secure Boot を「Legacy Support Enable and Secure Boot Disable」に設定。
Boot Optionから、起動優先順位でUSBを上げる。

Main画面を開き「Save Changes and Exit」を選択。「Yes」をクリック。
PCが再起動。
grub2の起動画面が表示される。
この時点で「tc」が選択されている。enterキー。
Tiny Core 起動。
こんな感じ。
このようにBIOSを設定したら、起動できる。

f9キーからのBoot Menuではどうかというと、USBからの起動で「UEFI」と「Legacy」を選択できる。
UEFI-xxxx（USBスティック名）からだと、f9を推さなかった時と同じ流れで起動。
Legacy-xxxx（USBスティック名）を選択したら、grubの起動選択画面が表示される。enterで起動。UEFIで起動したときと表示のされ方が違う。

こんな感じで、TinyCorePure64は起動するんだけど、「CorePure64-14.0」は起動できない。
違いは「EFI」ディレクトリの有無。
このディレクトリの奥にはefiboot.imgやgrub.cfgがある。CorePure64には、これがない。
どうやら、新しい機械で起動するには、EFIに対応している必要があるようだ。

こうして起動した「TinyCorePure64-14.0」だけど、「読み出し専用」でブートされるので実質的には使えない。ソフトのインストールや設定が出来ない。
理由は分からないのだけど、これらのイメージは元々CD-R用らしく、使えるようにするには「インストール」する作業が必要なのだろう。

インストール用イメージである「CorePlus」はどうか。
電源ボタンを押すだけでは起動できない。
BIOSから起動する必要がある。
f9キーを押してBoot Menuを表示。
UEFIからは起動しない。「TinyCorePure64-14.0」とは挙動が違う。
Legacyを選択すると、TinyCorePure64と同じ流れで起動できる。違うのは、どのようなOS、window managerを使うかとか、CLI（最近はCUIって言わないのかな）で起動するか、などを選択して起動させることが出来ることだ。

ProBook 450 G3ではどうか。
これは以前から普段使い用になっている古めのノートPC。

TinyCorePure64、CorePlusは起動できる。 BIOSからのBoot Menu。
UEFI-xxxx（USBスティック名）を選ぶと起動しない。
Legacy-xxxx（USBスティック名）を選ぶと起動できる。OS起動の選択画面表示、選択、enterで起動。 CorePure64は、起動しない。

さて、新型のProBook 450 G9ではどうか。「TinyCorePure64-14.0」の起動を試みる。

PC起動、escキー、f10キーからBIOS設定画面に移行。
Advanced画面を開く。Boot Optionから、起動優先順位でUSBを上げる。
Secure Bootの設定はここにはない。
Security画面を開く。
ここにSecure Boot Configurationがある。クリックで設定画面に移行。「Secure boot」のチェックを外す。
Main画面、「Save Changes and Exit」。
再起動。
f9キーで起動を選択。
legacy UEFIという選択肢は、ない。
UEFIから起動したら、grub起動画面が表示される。430 G5のときと同じような画面だ。
enterキー。
画面が真っ暗なままになる。
家庭内LANを確認したらIPアドレスは振られていてpingは通る。だけどこれでは手も足も出ない。ブラックボックスみたいなものでOSが起動しているのかどうかも分からない。

（5月9日追記。真っ黒な画面のまま「sudo poweroff」を打ったらPCがシャットダウンした。OSは動いている。）

他に手は無いか。
Security画面から、TPM Embedded Securityの設定画面に。
TPM Deviceを「hidden」に。これで起動してみたら、「Tpm Ppi」という画面が表示される。
TPMが切れるけどいいか？AcceptならF1だと。F1キーを押す。
再起動。
grub起動画面表示、enterキー、画面真っ暗。同じである。
関係ないのなら、危なっかしいのでTPMの設定は戻しておく。

他にも、grub起動画面から選択項目を変えてみたり、grubコンソールからの起動なども試みたが、同じ。
CorePlus、CorePure64は起動しない。f9から選択しても結局蹴られる。

試みにFedoraのインストール用イメージをUSBメモリに書き込んで起動を試みたところ、Secure boot有効でも起動する。流石、Fedora。
ままよ、なにはともあれ、起動できるTiny Coreをインストールできるか、やってみよう、、、

やってみたらなんとかなった。
前説、ここまで。

最新のTCを、最新のPCで動かす

まず、うちのオーディオシステムに使っているTiny CoreをOSインストーラーにする。
うちのPPAPシステムは、Tiny Core Pure64-11.1で作られている。
それらはimgファイルにバックアップしてあって、USBメモリに書き込めば利用できる。これに「tc-install.tcz」をインストールしたら、OSインストーラーとして使える。

インストールに使うハードはUEFI、Legacy、両方使える環境が必要。
ProBook 430 G5を選択。

mpdサーバーのimgファイルをUSBメモリに書き込んで、ProBook 430 G5で起動。
BIOSからLegacyを選択。
sshでLAN経由でログインし操作する。
tceコマンドで「tc-install.tcz」をインストール。

もう1本、USBメモリを用意してFATでフォーマット。なぜFATかというと、grub2をインストールするから。
これを430 G5に刺して、fdisk -lでデバイスを確認。
コマンド「sudo tc-install.sh」を打ち、このUSBメモリにTCをインストールする。ネットインストールを選択したら、最新のTiny Core Pure64-14をインストールできる。
以下、経過。

tc@box:~$ sudo tc-install.sh
>

Core Installation.
Install from [R]unning OS, from booted [C]drom, from [I]so file, or from [N]et. (r/c/i/n): n
>
The latest version is 14.0
Enter architecture (32)bit, (64)bit or (q)uit: 64
>

Select install type for /tmp/net_source/corepure64.gz

Frugal
* Use for frugal hard drive installations.
Note: You will be prompted for disk/partion and formatting options.

HDD
* Use for pendrives. Your BIOS must support USB-HDD booting.
* A single FAT partition will be made.
Note: Requires dosfstools extension.
Warning: This is a whole drive installation!

Zip
* Use for pendrives. Drive will be formatted into two FAT partitions.
* One small one for USB_ZIP boot compatibility, and used to hold Tiny Core.
* The remaining partition will be used for backup & extensions.
Note: Requires dosfstools and perl extensions.
Warning: This is a whole drive installation!

Select Install type [F]rugal, [H]DD, [Z]ip. (f/h/z): h
>

Select disk for corepure64
	 1. sda
	 2. sdb	On a removable device.
	 3. sdc	On a removable device.
Enter selection ( 1 - 3 ) or (q)uit: 3
>
Install Extensions from this TCE/CDE Directory:
>

Select Formatting Option for sdc1
	 1. ext2
	 2. ext3
	 3. ext4
	 4. vfat
Enter selection ( 1 - 4 ) or (q)uit: 4
>

Enter space separated boot options: 
Example: vga=normal syslog showapps waitusb=5 

vga=normal syslog showapps waitusb=5 
>

Last chance to exit before destroying all data on sdc1
Continue (y/..)? y
>

Writing zero's to beginning of /dev/sdc
Partitioning /dev/sdc
Formatting /dev/sdc1
mkfs.fat 3.0.26 (2014-03-07)
1+0 records in
1+0 records out
440 bytes (440B) copied, 0.005070 seconds, 84.8KB/s
UUID="E84A-CD33"
Setting up corepure64 image on /mnt/sdc1
Applying syslinux.
Installation has completed
Press Enter key to continue.
tc@box:~$ 

さて、最新の64-14をインストールしたUSBメモリが出来たら、ここから起動。
まだUEFIからは起動できない。
Legacyを選んで起動する。
パスワードを設定。 tceからopensshをインストール、設定、起動。 filetool.sh -bで保存。

LAN経由でログインし操作できるようにするのは、本体のキーボードが日本語キーボードとして使えないので不便だからだ。たぶんUSキーボードの設定になっている。「*」を打つのに「shiftと8」、「_」を打つのに「shiftと-」を打たないといけない。
ssh経由で操作したら、使い慣れた日本語キーボードを使うことが出来る。

これにtceで「tc-install.tcz」をインストール（後々、インストーラーとしても使えるようにするため）。
更に「grub2-multi.tcz」をインストール。grub-2.06がインストールされる（因みに64-11だったらリポジトリが異なるのでgrub-2.04だ）。

これだけでは、grub2は機能しない。
ブートローダーインストールのコマンドを打つ。
下記コマンドは、tceで表示されるgrub2-multi.tczの説明の中に表示された記述例に少し手を入れたもの。

tc@box:~$ sudo grub-install --target=x86_64-efi --boot-directory=/mnt/sdb1/EFI/BOOT --efi-directory=/mnt/sdb1 --removable

Installing for x86_64-efi platform.
grub-install: warning: cannot open directory `/usr/local/share/locale': No such file or directory.
Installation finished. No error reported.
tc@box:~$ 

警告出て大丈夫かと思ったが、警告だけでNo errorだからいいらしい。
再起動、UEFIから起動したら、grub2操作画面が表示された。grub2が表示されるということは、前進じゃん？
しかしbootを打っても起動しない。
何かエラーの表示の後で「booting in blind mode」と表示されて文鎮化する。

一般的には「grub.cfg」ファイルは、ユーザーがみだりに編集してはいけないということになっている。
しかしTiny Core Linuxは違う。フォーラムに書き込まれた内容によると、どうやらユーザーが編集して作ることになっているようだ。流石Tiny Core。

grub.cfgがないので、作る。
まずは、TinyCorePure64から流用し、あちこちネット上の情報を集め書き換え、下記の通り。
置き場は「EFI/BOOT/grub」でいいのだろう、と。 Legacy BIOSから起動して書き込む。「filetool.sh -b」を打たなくても保存される。

vi /mnt/sdb1/EFI/BOOT/grub/grub.cfg

# Load Graphical modules
insmod efi_gop

set gfxmode=auto
set gfxpayload=keep
set gfxterm_font=unicode
terminal_output gfxterm

linux /boot/vmlinuz64 loglevel=3 vga=791
initrd /boot/corepure64.gz

これで、UEFIから起動したgrub2操作画面から「boot」を打つとOSが起動するようになった。
insmod の設定がないと、blind mode になるらしい。

ところが、Legacyで起動し動かしていた間にインストールしたopensshが起動していない。パスワードも失くしているようだ。
どうも、UEFIから起動するかLegacy BIOSから起動するかで、挙動が変わるらしい。
/opt/.filetool.lstも見当たらない。どこに行ったのか。というか、何で無くなってるのだろう。

仕方ない。
UEFIから起動したところから、環境を１から作り直してみる。どうなるんだろう、、、
残念。
何故か解らないが、構築した環境を保存できない。
これでは使えない。どうなってるんだろうかな、、、

ここからフォーラム等々調べて、grub.cfgの記載は下記の通りになった。

loadfont unicode

insmod all_video

terminal_output gfxterm

linux /boot/vmlinuz64 loglevel=3 waitusb=5 vga=791
initrd /boot/corepure64.gz

boot

waitusb=5 が無かったら、OS起動時にUSBメモリから読み込まないものが出るらしい。あるべきものが無いままにOS起動するので、パスワードを紛失したりtceでインストールが出来なくなったりするらしい。
記載追加することで、Legacyで起動したときと同じように問題なく動くようになった。

最下行に「boot」を追加。
これで、grub2操作画面にならずにOSが起動するようになった。
sshからrebootを打てば再起動してそのままsshで再ログインできる。棚の下に押し込んだままで再起動をかけることが出来るということだ。利便性は大きく向上する。

ProBook 450 G9でも動くかな、、、動きました！ミッションクリア！

しかし今回、なんとかなったけど、UEFIから起動するしかない、最新の機械しかない環境で、TCを動かそうとしたらどうしたらいいのだろうか。何か方法はあるんだと思うけど、未確認。

今回は、ちょこっと。

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

うちでは、リッピングしたファイルは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経由だったら途切れるのかということだ。

有線LAN　Deezer, 2LのMQA（352.8kHz）	とぎれる
有線LAN　Deezer, Fairytales MQA（176.4kHz）	とぎれない
有線LAN　NAS音源のMQA（352.8kHz）	とぎれない
WiFi　Deezer, 2LのMQA（352.8kHz）	とぎれない

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を記載。

2L - the Nordic Sound All releases - 2L Music Store	https://www.2l.no/ https://shop.2l.no/collections/all
Deezer	https://www.deezer.com/
Daphile	https://daphile.com/
piCorePlayer	https://www.picoreplayer.org/

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

Daphile（logitech media server）	Compaq 6730b
piCorePlayer（Squeezelite）	Raspberry Pi 3b+
USB DAC	S.M.S.L M500

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の設定。
備忘録でもあるので、説明なく書き変えるかもしれない。

Audio output device settings	USB Audio（これは必須。設定しないと音が出ない）
Output setting	hw:CARD=AUDIO,DEV=0
ALSA setting <b>:<p>:<f>:<m>:<d>	<8192>:<128>:<f>:<0>:<d>
Buffer size settings	4096:8192
Priority setting	45

他に「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からリッピングしたもの）を再生する分には途切れない。ということはストリーミング環境が良くないのか。聴いてる人が多いのかな。
これは様子を見ながら考えていく。

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

前回、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では、ジッターを位相ジッターと振幅ジッターという見方で分けた。
ここでは、別のジッターの分類について触れている。
以下、表にする。

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以降は、また切り口が変わるので、今回はここまで。