Apr 30, 2026
アップサンプリング再生の音がいまいちなので対策を試みる
先立って、対策前の音について簡単に書いておく。
44.1 はジッターの影響を受けやすい分、最近のノイズや電源への対策に鋭敏に反応して、大きく音質改善している。
384 へのアップサンプリングは、比べたらそこまで大きな改善はない。
両者を比較したら、384 のほうが音の粒が細かく情報量は多く階調も深い。しかし音のスピードは遅く感じる。44.1 と比べると滲んでいるように、霞を被っているように聴こえる。それが音楽を掴みにくくしている。44.1 と比較すると訴求性が低い。
これは、アップサンプリングに伴うジッターの影響だと考えた。
アップサンプリングを行うことは、サーバー自体への負荷になる。これに伴うジッターが影響し、良質なアップサンプリングを行っても音質への恩恵が得られなくなっているのではないか。
昔からアップサンプリングに伴いサーバーに負荷がかかることは指摘されていた。
しかし「サーバーへの負荷」が音質に影響するのを、僕自身が聴き取った（と感じた）のは初めてのことだ。
サーバーへの負荷が問題になるのは、音質への影響以前に音が途切れるとか、まともに再生ができなくなるようなことが多かったと思う。
アップサンプリングに関連しての音質変化については、むしろサンプルレート変換ライブラリに何を選び、どう使うかということのほうが、大きいという認識だった。
うちで libsamplerate (secret rabbit code) を使うのは、サーバーへの負荷が大きくても、他のライブラリより音質の優位性があったからだ。その設定も、fastest から medium、best と変更し、それに伴いサーバーの調整もしてきている。
libsamplerate でも多少は音の感触は変わるが、音質上、それでも使うメリットがあると判断し使っていた。
それが今回は、初めて音質のデメリットの問題になった。
それで、まあ、どうしようかということだ。
アップサンプリングの音は、できれば改善したい。44.1 が改善しているとはいえ、情報量はハイレゾやアップサンプリングに比較すると足りない。
ノイズ対策や電源強化は、おそらくサーバー負荷に伴うジッターの悪影響を際立たせるだけだと思う。
サーバーの負荷を減らし、ジッター自体を減らすしか無いと思う。
真っ先に思い付いたのは、アップサンプリングの設定を変えることだ。
現在の設定は、libsamplerate / best の設定。
これを、fastest に変えたらどうか。負荷は下がるはずだ。
実際、設定を変えながら top を打って、CPU使用率を比較してみたら、負荷は1/10近くまで下がっているようだ。
音を聴いてみたら、問題はある程度、解決するようだ。
best のときに感じていた、どこか曇るような感触がなくなった。こうなると、44.1 と比べても音の細やかさや情報量では優位性がある。
もしかして、medium の設定でもいけるかも？と思ってやってみたら、悪くない。
top で読める CPU への負荷は、best のときの1/4ぐらい。
fastest よりもしっとりして密度があり、極端な言い方になるけど、シフォンケーキがスポンジケーキになるような感触がある。best だとパウンドケーキになるのだけど、どうもジッターが多くなると味のキレが悪くなってしまう。
こうした例えでいうならば、44.1 はクッキーかな。ケーキよりは粗い。
しかし、やはりクッキーからパウンドケーキという例えは極端すぎるかな。そこまで大きな音質差はない。
ここで気付く。medium なら 768kHz に出来るのでは。
一聴して、きれいな音。しかし、キレがいまいちか。CPU負荷は、best、384 の半分ぐらい。
768 なら fastest のほうが音楽の表情が現れるような感じ。CPU使用率は、best、384 の1/4ぐらいか。
libsamplerate は、CPU上の複数のコアで分担させて音声データを並行処理させることをしない。単一のコアが処理を行う。
うちのmpdサーバーのCPUは Intel Core i7-1255U で、12個のコアのうち、もっぱらCPU0 とCPU2 が、交代しながらアップサンプリング処理を請け負っている。それら以外のコアは殆ど働いていない。
それらCPU0 とCPU2の、CPUコア単位での使用率が 20%台ぐらいまでが、音に悪影響を及ぼさない限界、という感じ。
それを超えると、どうも良くない。以前はそうしたCPU由来のジッターの影響には気付かなかったが、ネットワーク環境のノイズが減ると、聴き分けたり感じられるようになるということらしい。
いろいろと、聴いてみて、どうか。
NAXOSの天上のオルガンのハイレゾ（384）は、空間の情報量が多い。空間雑音や音声のニュアンスなど、アップサンプリングでは聴こえない定位の仕方が聴こえる。それだけ明瞭なのだ。
44.1 は比較したら情報量は少ないが、音楽の表現が良質で安定感がある。客観的に見たら、十分にHi-Fiだろう。
アップサンプリングは、これらと比べて音のスピードが僅かに遅い感じがする。微妙な差異でも、音楽表現に影響するので看過できない。
best、medium のほうが、fastest よりもアップサンプリング自体の質は高い。しかし音のスピードは遅くなる。
fastest の設定は CPUコア単位での使用率が 10%前後まで下がる。このぐらいになると、音のスピードの遅延がほぼ感じられなくなる。使用率 20%ぐらいだと使用限界に近くて、まだどこか、ぬるく感じられるようなのだ。
そして暫く使ってみたが、どうもやはり、それでもアップサンプリングの音から受ける印象は、すっきりしない。
buffer の設定をいじってみることにする。
昔、audio_buffer_size と buffer_before_play を調整することで音が変わるというので、調整していたことがあった。積極的に調整するのは久しぶりだ。
当初は、audio_buffer_size 16384、buffer_before_play 75％ という設定だった。どちらかというと重い設定だと思う。best の設定で運用するには、重い設定でないと難しかった。
数字が小さいほうが軽快に動くイメージがある一方で、小さくしすぎると処理が追いつかなくなる。
audio_buffer_size を小さくすると、buffer_before_play を大きくする必要がある。
端折るけど、あれこれ弄った過程で、fastest をやめて、medium に、更に best に戻している。
どうせどうやっても遅れるのならば、best の設定のほうが音が良いように思ったのだ。
結果、audio_buffer_size 131071、buffer_before_play 8％ とした。
131071 というのは、設定できる最大値だ。
8％は逆に小さめ。0％も数字としては設定できるが、どうも挙動が変動して、それに伴って音も変わるような気がする。5％だと、ときどき鳴らし始めに音が途切れる。10％だと僅かに重い？気がする。そういうわけで、今のところは 8％ にして様子を見ているということだ。安定しないようなら 10％にするかな。
しかし、なんとか 44.1と同等レベルの速さに、できたかな。頑張ってようやく同等だ。もしかしたら音源によっては評価が変わるかもしれないし、微妙な感じ。
なんやかんや言って、384 のハイレゾが一番速い。今はそういう状況だ。
今回、mpdの設定を変えることでサーバーの負担低減を試みたが、結局、期待する結果は得られなかった。
期待というのは、384 ハイレゾと同等に近付けるということだ。かなり水を開けられている。仕方ないのかもしれない。44.1 と役割分担できそうなレベルにまで戻せたので、良しとすべきだろう。
しかし上記の調整をしたところ、アップサンプリングではヘンデルの携帯電話がステージ近くに寄って鳴るようになった。
44.1 に比べたら、かなり前方に定位する。
一聴、音は良くなっている気がするのに。
仕方ない。デジタル処理というのはそういうものだと割り切って暫く使ってみる。
サーバーへの負担は相対的なものだから、サーバーを強化するという選択肢も考えられる。
しかし機種選択が難しいと思った。
libsamplerate / best の設定で、384kHzを回しながら、ジッターの影響も無くそうと思ったら、 Intel Core i7-1255U の 4倍以上の速さで動くCPUが必要ということになる。そんなCPUは、まだ無いと思う。
あとは、サンプルレート変換ライブラリを軽いのに変えるという手段もある。
だけど、音質上どうなんだろう。
libsamplerate ですら怪しいのに、他のライブラリで有用性が得られるだろうか。今後の検討だけど実行できる気がしない。そんな暇もなさそうだからだ。
負荷が少ないということであれば、libsamplerate で低品質とされている ZERO_ORDER_HOLD の設定とかもあるかもしれないが、過去に試して全く思わしくなかったので、今更試してみる気はしない。
と、言いつつ、ZOH Sinc Interpolator を試してみた。
正直、、、驚いた。
昔、試したときには、とても実用にする気になれないと思ったのに、そこそこ、きれいな音で鳴るじゃないか。。。
44.1 と比べて、遜色ない。そして、Best Sinc Interpolator と比べても、遜色ない。そういう個性とクオリティを主張できる音だ。
GNDやノイズの対策は、ZOHの音質も、底上げするのだろうか。
そんな可能性は、今まで全く考えたことがなかった。
良い意味ですごく硬質で、クリアに聴こえる音だ。外連味が、全く感じられない。
こんな音は、今まで聴いたことがないような気がする。
ちょい聴き、情報量の感触は 44.1 に近い気がする。しかし微細な領域の再現性は、44.1 をかなり上回る。より正確で透明度が高く聴こえる。そういう感触は、過去にアップサンプリングが上手く行っているときに感じていた感触に近い。、、いや、実際のところ、情報量の判断は簡単ではなさそうなので保留する。
比較すると best 設定のほうが心持ち音が暖色に近く、動感を感じる再生音で、わずかに派手に聴こえる。
NAXOS の天上のオルガン、384ハイレゾと、ZOHによる44.1からのアップサンプリングは、ほとんど同じに聴こえる。僅かにハイレゾのほうが良いのかな。ブラインドでは、区別がつかないだろう。
これにも驚いた。best 設定だと、僅かにフォーカスが甘くてハイレゾに届かないかのように聴こえたのに。
しかし、ヘンデルの携帯電話の位置はステージ側に寄ったままだ。
ZOH では、ほとんどサーバーのCPU使用率が上がらない。
設定は、audio_buffer_size 16384、buffer_before_play 8％ 、こんな感じ。
ここで思う。
ZOH ともなれば、768kHzが簡単に出力できる。
結果は、384 と大きく印象は変わらないというもの。fastest、medium で鳴らしたときには、384 と差があるように思ったが、今回はあまり意味があるようにない。むしろ、明瞭さが減ったような気がする。どうなんだろう。
705.6kHz にしてみる。こっちのほうが、44.1 から ZOH するよりスムーズなはずだ。音は、768 より、若干、見通しが良いような気がする。しかしそれでも敢えて 384 から 700kHz台に変更したいという気にならない。
なんとなく 352.8kHz にしてみる。384 との音の違いは、無いわけではないようだが、あまり感じ取れない。やや 384 の方がおとなしいかな。音質差というほどのものではない。
しかし、ヘンデルの携帯電話は、左手前に近付いた。
ここまでは、サーバー負荷によるジッター以外が原因となっている可能性については書かなかったけど、他の理由も考えられることに途中で気付いた。
アップサンプリングの性質自体による音質劣化の可能性だ。
というのは、libsamplerate によるアップサンプリングは DA-AD 変換をシミュレートする過程で高域の情報が僅かだが失われる。以前は気付かなかったし、気にならなかったのだけど、システムの音質の改善に連れて、それが明瞭になったのかもしれない。
あれこれ mpd の設定を変えて、結局は libsamplerate / best の設定に戻るということは、そういうことではないのか。best だと他の設定よりも高域の減衰は少ないのだから。
しかしそれを考えたら、ZOH のほうが高域の減衰は強い筈なのだ。4kHz以上で徐々に減衰が始まり、しかし 18kHzで 0.5dB 程、22kHzでも 1dB に届かないらしい。僕にはその減衰を聞き取れない。
そして、best の設定だと減衰は 20kHz 以上で始まる。
（参照：https://src.infinitewave.ca/ ）
それにしても。
実際、どうしようかと思う。
其々の設定に、其々の特徴がある。
44.1 は、上手く鳴らしたら鮮やかで、安定した音がする。
ただ、44.1なので、情報量は頭打ちに感じる。たぶん、それはうちの機器の限界だ。100万円のDACとか強力なクロックを使ったら限界を超えられるのだろうか。
libsamplerate の上位のアップサンプリングの美点は、そうした音の色彩を殺さないということがある。更にアップサンプリングによって情報量が増える。弱点は、比較すると安定感がやや少ないことだ。僅かに音のスピードが遅いことが原因だと思うんだけど、どうなのだろう。
352.8 だったら、ヘンデルの携帯電話は、左手前に近付く。ZOHのときと同じだ。しかし暫く聴くうちに、なんとなく違和感を感じるようになって 384 にした。理由の説明は難しい。好みなのかな、どうなのだろう。
ZOH は、安定感が強い。44.1よりもしっかりした音に聴こえる。アップサンプリングによって情報量が増えると同時に、安定感と相まってフォーカスが合うかのような分解能が高い感触の音がする。しかし色彩感は薄くなる。これは、実際のところは微細な情報が欠落しているんじゃないかと思ってるんだけど、、、そうは簡単に思わせないだけの音が出ている。
どうなるだろう。使いながら考える。
