abk1's scratched blog 3

最近はCDリッピング音源をras pi2で24bit/384kHzにアップサンプリングしてi2sDACに出力して聴くことが多い。
情報量が多くなると同時に音色がまろやかで音場空間も広く、192kHzまでのアップサンプリングとは一線を画した音になる。
なぜこんな差が出るのかははっきりしない。
時間軸の情報量を増やすことが正確な再生に必要とは思うのだけど、DACチップの性格なのか、サンプリング周波数自体に意味があるのか。

以前から気になっていたのが、アップサンプリングした音とハイレゾファイルにどの程度の差があるのかということ。

CDリッピングファイルを、TASCAM Hi-Reso Editerで192/24化したファイルとメモリ再生で比較したことがある。このときは192/24化したファイルの方が音がいいという結果だった。その後、じゃあ良質なアップサンプリングを使えばCDリッピングファイルを192/24に近い音で聴けるんじゃないかと気付いて、以降はアップサンプリングして聴いている。
だけど、ハイレゾファイルの音とCD音源をアップサンプリングした音の比較は、できていないままだった。
今回はそれをやってみようということ。

音源に使うのは、以前にも使ったPierre Boulez the Complete Columbia Album Collection CD40、Bartok / The Wooden Prince の一曲目「Introduction」。
44.1/16と192/24のファイルを使う。
比較したのを以下に表にする。なんとなく適当に10段階評価してみた。

192/24のファイルはどうも、44.1/16を192/24にアップサンプリングしたのに及ばない感じ。しかも、192/24であってもlibsamplerateでリサンプリングした方がいいような。
ということは、Hi-Reso Editerによるアップサンプリングよりlibsamplerateによるほうがいいんだろうか。そもそもHi-Reso Editerがどのようなアルゴリズムでアップサンプリングしてるのか、よく分からないということがある。
あと、ファイルが大きくなるとアップサンプリングの負担が大きくなるようで、これは扱うデータ量が増えるので当たり前かも。

実は数か月前、mpd+libsamplerateの出力からハイレゾファイルを作ろうとしてHDDを飛ばすという惨事に至ったことがある。OSから再インストールして環境再構築は大変だしデータは無くすしで、それからは怖いのでやってないんだけど。
本当はファイル同士で比較した方がいいんだろうけど、できていない。

そんなこんなで、自作ニセレゾで比較するというのには限界があるのかと感じ始めた。
自分でもそれが適正な品質なのかどうかが分からない。
そこで、NAXOSから「天上のオルガン」と「天使のハープ」を買った。それぞれ300kHz台のハイレゾ音源と44.1/16のファイルが売られている。これなら自作のファイルよりも比較しやすいんじゃないだろうか。

というわけで比較の顛末。
まず、天上のオルガンを買った。
http://item.rakuten.co.jp/naxos/c/0000000941/
NAXOSの解説がこちら。
http://naxos.jp/digital/kogakki-organ

384/32と、44.1/16をlibsamplerateでアップサンプリングしたのを比較。
それが、どうも腑に落ちない。
具体的にはうまく言えないけど、なんだか音が違うような気がして単純に比較できない感じなのだ。音量はわずかに44.1/16のほうが大きい。
どうなってるんだろう？と思っていたら、下記の記事を見つけた。

「天上のオルガン」384kHz/32bitマスターを聴く - Phile-web
http://www.phileweb.com/news/audio/201403/14/14256.html

この記事によると、Pyramix（384kHz/32bit）とSequoia（192kHz/24bit）の2つで録音を行った、とある。もしかしてマスターが違うから音が違うということなのか？と思ったが、この記事内容からははっきりしない。
192kHzと44.1kHzを比べてみるべきかとも考えたけど、出来ていない。

そこで天使のハープを買った。
http://item.rakuten.co.jp/naxos/nyzc-27266/
http://item.rakuten.co.jp/naxos/nyzc-27268/
NAXOSの解説がこちら。
http://naxos.jp/digital/koggaki-harp

352.8/32と、44.1/16をlibsamplerateでアップサンプリングしたのを比較。
こちらは、何だか違うという感じがない。音量は352.8/32のほうがむしろ大きく聞こえる。
これなら比較しても良さそうかな、と思えた。
結果はというと、44.1のアップサンプリングよりハイレゾ音源の方が繊細で耳あたりがいい鳴り方をする。アンプのボリュームが上がっていきやすい。ある意味、順当な結果になって良かった、という感じ。

実際のところ、こんなので比較が出来たことになるのかな？という気持ちはあるんだけど、高音質マスターからのダウンサンプリングでファイルを作るというのは色々大変なのかもしれないというのはあって、違うんじゃないのかとかあんまり厳しいことは言っても詮ない話じゃないかという考えを最近は持っている。
だから、この辺で良しとしようと思う。

ここまで比較は、moode audio3.1 + i2sDAC によるもの。
現在、moode audioはバージョンアップして10ドル必要になっている。他にmpdでi2sから384kHz出力出来るようなRas pi用のディストリビューションはない。usbなら簡単に出せるのだけど。

そこで、usb出力での384kHzも試してみようかと思うようになった。
usb DACが要る。4千円のi2sDACと比較するんだから、あんまり高価なのはどうも、と思って下記の機種にした。

http://ifi-audio.jp/nanoidsdle.html
ifi nano iDSD LE、戦略価格モデルだそうだ。シンプルなusb DACで384kHzを受けることが出来る。
これとi2sDACを比較してみる。

音源は、44.1/16をlibsamplerateで384/24にアップサンプリングする。
デジタルトラポを何にするか。
もう手軽なのでいいやと思ってpiCore7にした。
piCoreはバージョンアップされててpiCore9がリリースされているんだけど、こっちには現時点ではtczにmpdもdoxygenも用意されていないので、手軽にmpdサーバ用途で使えるpiCoreは7だけだ。

これにiDSD LEをusbケーブルでつなぐ。
最初はまともに音が出なくて、ああ、これも駄目かと思ったが、数日後には普通に音が出るようになっていた。
どうも充電が出来てなかったからじゃないかと思う。

音の比較。 まずpiCore7にNASをマウントした場合。
僕などは過去の経験のせいで、これで普通に音が出るだけでも感心してしまうのだけど、不具合なく、そこそこ聴ける音が出る。
しかし音質はi2sDACのほうがいい。
Ras Piではusb出力が不利な上に、i2s出力自体の優位性があるのだろう。

次にpiCore7でメモリ再生する。NASはアンマウント。
これであっさりi2sDACの音を越える。
i2cDACでは僅かに再生音に滲みがあるが、iDSD LEの音にはそれがない。透明感が高く静謐で、音楽への命の宿り方が違うとまで感じる音がする。

やっぱりRas Piでusbならメモリ再生じゃないといけないんだな、とか思ったりしたけど、どうもこれがfireface UCX、メモリ再生で192kHzの音も越えているっぽい。少なくとも同等以上だと思う。
ここらは突っ込んで比較試聴を繰り返したわけじゃないし、比較するならするでいろんなファクターがあるので注意しないといけないとも思うので、はっきりとは言えない部分がある。

しかし、こうなってくるとi2s出力を使いやすいからという理由でras piにこだわる理由がなくなってくる。
他のハードならもう少しましなのか？
いや、それでもメモリ再生が優位というのは変わらないだろうし、どうしようかなあ、というところだ。

以前のエントリーで、課題を羅列した。
４番の課題、384kHz/24bitの音についてSoXとlibsamplerateの比較は前回のエントリーに上げた。

今回は３番の課題。まず、Moode Audio NAS音源 384/24 i2sDACの音と、piCore メモリ再生 192/24 usb-DDC/firefaceの音の比較について。
両方ともCDのリッピングファイルをlibsamplerateでリサンプリングしている。

結論から書くと、僅差でpiCore メモリ再生で192/24の音のほうがオーディオ的に上の音がする。
繰り返し同じ音源で比較すると、細かいところで情報量が多いことがわかる感じ。
Moode Audio i2sDAC 384/24の音は、192/24と比べたらごく僅かに滲むような感じがある。しかしこれはサンプリング周波数のせいではなく、機器の違いによるものじゃないかと思う。

しかし、どういうんだろう、、、
fireface UCXは、極めて分析的な鳴り方をする。客観的にさせられる音色だ。
対して、Moode Audio NAS音源で384/24の音のほうは、くだけたざっくばらんな音色で鳴る。
結果、音楽に浸りやすい。

Moode 384/24 i2sDACで聴き始めて、ポップミュージックが俄然水を得た魚のように生き生きと歌い出した。クラシックよりもポップミュージックの方が感動が大きいというのは意外な結果だった。いつぞや、音質が良くなるとビリージョエルが生真面目過ぎていただけないと書いたことがあるけど、なんというか、生真面目でどこが悪いかというような聴こえ方になる。そんなことは些細なこととばかりに生々しく歌う。そこには新たな感動がある。まさにオーディオの醍醐味だ。

状況で使い分けしないといけないということなんだろうと思うけど、日常生活の中で使う分には、NAS音源のほうが便利さの点では圧勝だ。
音質は僅差で、魅力的に楽曲を再生する。
結果、最近はMoode Audio3.1ばっかり使うということになっている。

今回、ふと思いついて、Moode Audioの設定を192kHzに変えてみた。
驚いたことに、FMラジオからAMラジオに切り替えたかのような変化を感じる。言い過ぎかな？、ここまで違うか？という感じ。ついこの間までvolumioの普段使いで使っていた設定なんだけど、、、
384kHzに設定を戻すと、なんというか、やはり圧倒的に違う。生真面目なビリージョエルをベールで覆い隠してお茶を濁しているのとは全く違って、当然、バンドサウンドもいい。中島みゆきとか矢野顕子とか、次々聴いてしまう。どうもすっきりしない録音だと思っていたサイモンとガーファンクルが、聴いたことのなかったクリアさと重さをもって再生されたのには驚いた。この重さは、何に由来するのかはっきりしない。いずれ見極めたいところだ。

正直、PCMは384kHzのレベルじゃないと実はダメなんじゃないのか、と最近は思っている。そしてそれは良質なアップサンプリングでもいいのだ。録音さえ良好なら44.1/16のファイルには十分な可聴領域の音楽情報がつまっている。
それを引き出すのに384kHzが必要なのは、たぶんMQAに関連して言われているような時間軸の情報量を増やすことがより正確な再生に必要だからだろう、という理解をしている。

Moode Audio3.1以外だったらどうなのだろう。
他のディストリでi2s 384kHz/24bitを手軽に使えるようになるのは何時になるやら。
エントリーした課題の５番、DietPiをうちのシステムに組み込むというのは、結局、果たせていない。libsamplerateを組み込めないしncmpcppにつなげない。お手上げだ。raspbianで何とかするなんてのは夢のまた夢だ。テクがない。

そして思うのは、firefaceで384kHzを受けたらどんな音になるんだろう、ということ。
RMEから新製品が発売中なのだ。
ADI-2 Pro - Synthax Japan Inc.
https://synthax.jp/adi-2pro.html
やっぱりRMEらしく分析的な音なんだろうか。それとも何かが変わるのか。20万円とかどうよ。Ras pi2のUSB出力を問題なく認識してくれるよね？、、、

あと思うのは、CDをリップした44.1/16のファイルをMQAに変換することに将来的なニーズがあるんじゃないかということ。
44.1/16のファイルをlibsamplerateで384/24にアップサンプリングした音は、44.1/16のファイルをそのまま再生するよりいい音がする。
このデータをMQAファイルに変換してMQAに対応したハードに送ったら、どんな音がするだろう？
あるいはPCM384/24の音と比べたとき、どんな違いがあるだろうか？

閑話休題。

さて、今回のエントリーのタイトル。
３の課題の最後に書いた、Moode Audio3.1でメモリ再生。i2s 384kHz/24bitの音を聴いてみないといけない。
そしてpiCoreメモリ再生192kHz/24bitと比較する。

Moode Audioのmpd設定の記述は以下のようになっている。
music_directory "/var/lib/mpd/music"

そこで、musicディレクトリ下に例えば「RAMPLAY」というディレクトリを作成したら、そこに音楽ファイルを転送できるんだけど、実はしかし、piCoreだったらすべてRAM上で動いているからいいんだけど、MoodeではファイルはmicroSDに書き込まれる。
つまり、これではRAM音源の再生にならない。
RAM diskを設定して、そこに転送した音源を再生できるようにしないとRAMによるメモリ再生は出来ない。
以下、コマンドを羅列。

pi@moode:~ $ df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/root            3.6G  1.4G  2.1G  40% /
devtmpfs             459M     0  459M   0% /dev
tmpfs                464M     0  464M   0% /dev/shm
tmpfs                464M  6.4M  457M   2% /run
tmpfs                5.0M  4.0K  5.0M   1% /run/lock
tmpfs                464M     0  464M   0% /sys/fs/cgroup
/dev/mmcblk0p1        60M   17M   44M  29% /boot
192.168.1.80:/titan  2.7T  1.9T  831G  70% /mnt/NAS/titan
tmpfs                 93M     0   93M   0% /run/user/1000

pi@moode:~ $ sudo vi /etc/fstab

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
#
#（　以下追記　）
#
##### ramdisk
tmpfs   /var/lib/mpd/music/RAMPLAY  tmpfs  defaults,size=500m 0      0  

pi@moode:~ $ sudo reboot

pi@moode:~ $ df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/root            3.6G  1.4G  2.1G  40% /
devtmpfs             459M     0  459M   0% /dev
tmpfs                464M     0  464M   0% /dev/shm
tmpfs                464M  6.4M  457M   2% /run
tmpfs                5.0M  4.0K  5.0M   1% /run/lock
tmpfs                464M     0  464M   0% /sys/fs/cgroup
tmpfs                500M     0  500M   0% /var/lib/mpd/music/RAMPLAY
/dev/mmcblk0p1        60M   17M   44M  29% /boot
192.168.1.80:/titan  2.7T  1.9T  831G  70% /mnt/NAS/titan
tmpfs                 93M     0   93M   0% /run/user/1000
pi@moode:~ $ free
             total       used       free     shared    buffers     cached
Mem:        948292     206960     741332      27756      11760     129320
-/+ buffers/cache:      65880     882412
Swap:            0          0          0

これで、RAMPLAYディレクトリがRAM Diskになる。
FileZillaでアクセスし手頃なファイルを転送してみる。

pi@moode:~ $ df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/root            3.6G  1.4G  2.1G  40% /
devtmpfs             459M     0  459M   0% /dev
tmpfs                464M     0  464M   0% /dev/shm
tmpfs                464M  6.4M  457M   2% /run
tmpfs                5.0M  4.0K  5.0M   1% /run/lock
tmpfs                464M     0  464M   0% /sys/fs/cgroup
tmpfs                500M   95M  406M  19% /var/lib/mpd/music/RAMPLAY
/dev/mmcblk0p1        60M   17M   44M  29% /boot
192.168.1.80:/titan  2.7T  1.9T  831G  70% /mnt/NAS/titan
tmpfs                 93M     0   93M   0% /run/user/1000
pi@moode:~ $ free
             total       used       free     shared    buffers     cached
Mem:        948292     344908     603384     125004      11892     264344
-/+ buffers/cache:      68672     879620
Swap:            0          0          0

pi@moode:~ $ ls -aFl /var/lib/mpd/music/RAMPLAY
total 97220
drwxrwxrwt 2 root root        80 May  9 10:55 ./
drwxrwxrwx 4 mpd  audio     4096 May  9 10:42 ../
-rw-r--r-- 1 pi   pi         554 May  9 10:55 BA-JI - 遊びに行こうよ EP.cue
-rw-r--r-- 1 pi   pi    99543648 May  9 10:56 BA-JI - 遊びに行こうよ EP.flac

ncmpcppから操作、ちゃんと音が出る。メモリ再生機として機能してるかな。
ウェブブラウザからMoodeにアクセスしてNASのマウントを解除する。
いくばくかでもpiCoreの条件には近づけたい。

試聴する。
音源は、Mercury Living Presence 1 CD19をリッピングしたflacの1曲目、Enescu作曲「Romanian Rhapsody No.2」。

区別がつかない、、、滲む感じがどうとかも、はっきりしない、、、
と思いきや、じっくり繰り返し聴き比べるうちに違いを聴き取れるようになってきた。i2sDAC 384/24の音は雑味もある気がするけど情報量も多い。usb-DDC/fireface 192/24は滑らかだが音が大人しい。出るべき音は出ている感じだけど。
僅差ながら、i2sDAC 384/24の音はざっくばらんで鮮烈、まとまりがいいのはfireface 192/24のほうだ。

ここで、MoodeにNASをマウントして、NAS音源のi2sDAC 384/24再生を聴いてみる。
若干、音が緩くなる。あと、メモリ再生では聴き取れていたはずの音が聴こえなくなった。
かなり怪しいんだけど、1分50秒ぐらいから微かにハープの音？がメモリ再生では聴き取れるような気がするのだ。NASマウントでの再生ではハープは2分50秒すぎてからしか聴き取れない。このときの音はかなり音量が大きい。

というか、これってハープ？それとも他の楽器？もっといい装置だったらきれいに聴こえるんだろうか。
そこで思いついて、youtubeにアップされてるオーケストラの動画を検索して確認したら、ハープではなく他の音らしい。あれー、、、
だけどまあ、いずれにせよ、何かが鳴ってるのが聴こえるか聴こえないか、差異がある。
ちなみに、NASをマウントしたままではメモリ再生の有効性は低下するのを再確認した。

他の音源でも試してみたいけど、あんまり時間が無いんだな。

そんなわけで、i2sDAC 384/24再生でも、NAS音源再生よりメモリ再生のほうが音はいい。
i2sDAC 384/24とfireface 192/24、両者のメモリ再生では正直、オーディオとしてのレベルは甲乙付けられなかった。
しかも、どちらの音が僕の好みに合っているのか、決断できない。
これには弱った。
うちのオーディオはどうセッティングしたらいいのか、、、まあ、おいおい考えよう。

悩ましいのは、384kHzでもメモリ再生には意味があるということ。
便利で音がいい384kHzのNAS音源再生で代替するということは出来ないことがはっきりしたわけで、普段使うにはそれで全く問題ないけど、突き詰めて聴くときは、メモリ再生は外せないということになった。
まあ、それ自体はたいした手間じゃないので別にいいんだけど。
むしろ、さらに上を狙う余地があちこちにあるらしいということがはっきりした、ということなんだろうな。

Moode Audioは4月12日にバージョンアップして3.5になり、10ドルかかるようになった。
http://moodeaudio.org/

今回うちで使っているのはバージョン3.1で、今はどこから落せるのか定かではない。
3.1はウェブインターフェイスがまだ心許ない部分があるし、10ドル払って3.5を買って試してもいいんだけど、面倒なので、タイトルに書いた案件についてメモ書きしておく。

今回、参考にしたサイトはこちら。
Moode Audio R3.1 のAdvanced kernel では384kHz再生が可能？: new_western_elec
http://nw-electric.way-nifty.com/blog/2016/12/moode-audio-r31.html

Advanced kernelだ。
カーネルとalsaに手を入れたらi2sから384khzが出せるらしい。
昨年の夏、Linux関係の雑誌に載っていて、その後、僕も試したけど力が及ばなかった。
USBから出すことはありふれたディストリで出来るんじゃないかと思うけど、うちにはUSB384kHzを受ける機材がないのだ。

まずMoodeAudio3.1のディスクイメージをmicroSDに焼いて、Ras Pi2に刺して起動させる。
家庭内LANのルータでipを確認して、ウェブブラウザでアクセスする。
NASのマウント、時間やip固定など最低限の設定をする。適宜再起動。

i2sデバイスの設定。
うちで使ってるのは下記サイトの製品。Burr-BrownのPCM5102Aを使っている。Ras Pi2でも問題なく動く。
Raspberry Pi Model A+/B+ 対応ハイレゾ DAC カード RBD-02+
http://linuxcom.shop-pro.jp/?pid=79120318

表示右上のメニューボタンをクリックして「Customize」を選択、クリック。Audio device descriptionの項目で「HiFiBerry DAC」をクリック（これをしょっちゅう忘れて製品サイトを訪ねるので、ここにメモしておく）。
ここには凄まじい数のデバイスが登録されている。
こんなにデバイスあるんだなあ、、、

続いて、カーネルだ。
表示右上のメニューボタンをクリックして「Configure」を選択、「System」をクリック。「System Modifications」という項目に、Linux kernelの選択項目がある。
「Advanced」を選択して再起動。

再起動したら、また表示右上のメニューボタンをクリックして「Configure」を選択、今度は「MPD」をクリック。
「Resampling」という項目から量子化ビット数とサンプリングレートを選択できる。
これでi2sDACに384kHzで出力できるようになる。

この時点で、Sample rate converterはSoX。
これにlibsamplerateをインストールする。
sshでMoode Audioにログイン。ユーザはpi、パスはraspberry。
以下、コマンドなど羅列。

cd /usr/local/src
sudo chmod -R 777 .

/usr/local/srcにダウンロードして作業場にする（このディレクトリはそういう場所らしい）。
そのままじゃ権限がなくて蹴られるのでchmodで誰でも触れるようにする。

wget http://www.mega-nerd.com/SRC/libsamplerate-0.1.9.tar.gz
tar xvf lib*
ls
cd lib*9
ls
less INSTALL
pkg-config --cflags --libs sndfile

./configure
make
sudo make install

こんな感じで。
libsamplerateを落して、展開し、ディレクトリに入って、INSTALLファイルの内容を確認。
そこに書いてあるコマンド「pkg-config --cflags --libs sndfile」でシステムの状況を確認。
「-lsndfile 」と返答が返ってくるので、問題なくインストールできそうだと分かる。
あとは、configure、make、install。

次にmpdを再インストールして、libsamplerateを使えるようにする。
moode Audioで使っているのは0.19.19。同じのを使う。
以下、コマンド羅列。

cd /usr/local/src
wget http://www.musicpd.org/download/mpd/0.19/mpd-0.19.19.tar.xz
tar xvf mpd*
cd mpd*9
ls
./configure
make
sudo make install

これで再インストール出来上がり。

さて、mpd.confを設定する。
ウェブブラウザから設定できるのはSoXだけで、libsamplerateは設定できない。だからmpd.confから設定する。
なお、この設定はウェブブラウザの表示には反映されない。

vi /etc/mpd.conf

audio_output_format "384000:24:2"
#### samplerate_converter "soxr very high"
samplerate_converter "Fastest Sinc Interpolator"

こんな感じに書き直す。
「sudo reboot」で、Moode Audioを再起動したら、mpdに設定が反映される。
どうも、mpd --killが効かないので、OS自体を再起動するしかない。再起動が早いので我慢できる。
ps axコマンドで確認したらこんな感じ。

766 ? S<sl  18:16 /usr/local/bin/mpd --no-daemon /etc/mpd.conf

mpd --no-daemonで起動したら、端末からの操作を受付なくなるらしい。
これはどこを修正したらいいのかわからない。

うちのDACボードで、本当に384kHzの音が出てるのかテスターとかで確認したわけじゃないので断言は出来ないんだけど、

pi@moode:~ $ cat /proc/asound/card*/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 384000 (384000/1)
period_size: 16384
buffer_size: 65536
pi@moode:~ $ 

こんな感じ。ウェブブラウザからの表示で確認してもMoodeからは384kHzで出力されている。
それで音が出てるので、出来てるんじゃないかな。

あと、本当にlibsamplerateを使えているのかどうかはtopコマンドで確認するしかない感じ？
SoXだと、CPU負荷はせいぜい30%台。

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  759 mpd       10 -10  113720  24740  13644 S  35.0  2.6   0:18.05 mpd
  600 root      20   0  157036  10600   7532 S   1.0  1.1   0:05.34 worker.php
 1351 pi        20   0    5112   2500   2092 R   1.0  0.3   0:00.50 top

libsamplerateだと100%を越える。3倍の負荷がCPUにかかっている。DAD変換シミュレートは相応の負担がかかる。

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  766 mpd       10 -10  113088  22228  13348 S 106.8  2.3   0:57.09 mpd
  991 pi        20   0    5112   2500   2088 R   1.0  0.3   0:00.08 top
  599 root      20   0  157036  10624   7556 S   0.7  1.1   0:00.48 worker.php

音を比較。

SoXはくっきりした音がする一方、libsamplerateは階調が深いという印象は今までどおり。
音場の左右への広がりは同等。奥行きはlibsamplerateのほうが出る。遠くの音がSoXだとくっきりする分、若干近くなるような気がする。
情報量は、libsamplerateのほうが出ている気がする。微細な音のデリケートな表現の部分で違いが出るという印象があって、これは以前と変わらない。それが聴きやすさ、耳馴染みのよさに繋がってくる。

実は、384kHzともなれば差異が目立たなくなるんじゃないかとか思っていたんだけど（根拠はないんだけど）、違いはやはりあると思った。libsamplerateのほうが僕の嗜好に合うようだ。

今回、ここまで。

最近はアップコンバートに凝っている。
いろんな条件で比較しないといけないとは思うけど、真面目にやらないまま何となくあれこれ聴いている日々だ。
そんなわけで雑感だ。

どこから書いたものか。
まず、libsamplerateとSoXの比較だけど、全く出来ていない。
というか、もっぱらlibsamplerate系で聴いている。比較する暇がまだないのだ。
Volumioはlibresampleというプラグイン（と言っていいのかな？）でアップサンプリングするんだけど、これはlibsamplerateの派生らしい。piCoreでのメモリ再生でも、もっぱらlibsamplerateを使っているのだけど、やはりメモリの消費の傾向とか挙動が似ている。で、こればっかり使っている状況ということだ。
それで不満がないのでしょうがない。SoXと比較する暇はなかなかとれないし、、、
参考のサイトをメモ。

Free Resampling Software - Digital Audio Resampling Home Page
https://ccrma.stanford.edu/~jos/resample/Free_Resampling_Software.html

雑感だから文脈無視して思いつくまま書く。
前回のエントリー以降、アップコンバートによる音の変化を確かめていた。
Ras pi 2 + Picore7 + mpd + libsamplerateでどうなのか。
音質への言及はないが、下記の記事（2015年12月2日付）にうちでの再生と同様な結果がアップされている。

ラズパイ・オーディオでアップサンプリング！ CD音源を変換して高音質再生 (1/3) - Phile-web
http://www.phileweb.com/review/article/201512/02/1888.html

Raspberry Pi 2での試みについて書かれている。以下引用。

CDから取り込んだロスレス音源（44.1kHz/16bit、ALAC）で試した結果は、表1～3に示すとおり。「Fastest Sinc Interpolator」ではインターポレーション（サンプリング周波数を整数倍するときの補間処理）を速度優先で行うため、もっとも情報量が多くなる384kHz/32bitでも余裕で再生できた。 速度／精度のバランスが考慮された「Medium Sinc Interpolator」では、組み合わせによって明暗が分かれた。96kHz/24bitおよび96kHz/32bitはスムーズに再生できたが、192kHz/24bit以上の情報量では音が途切れがちとなってしまう。（中略） 精度を最優先する「Best Sinc Interpolator」では、アップサンプリング処理はほぼ困難だ。

こちらでも同様の結果。
Ras pi2でBest Sinc Interpolatorは無理。Medium Sinc Interpolatorは微妙。Fastest Sinc Interpolatorは安定して動作する。
Ras pi B+でVolumio1.55の場合はFastestなら192/24で問題なく動作する。MediumはPi2よりもっと微妙で実用にする意味が見つけにくいレベルかな。

面白いのは、サンプリング周波数と量子化ビット数の影響よりもlibsamplerateの設定の方が影響が大きいということ。
Pi2の場合だと、Bestは無理、Mediumは微妙、Fastestは安定だ。
Mediumの設定の時に、サンプリング周波数と量子化ビット数を調節してシステムを安定化させようとしても、なんだかあんまり関係無さそうなのだ。というのは、192/16では音切れがおきるけど、176.4/16だと大丈夫だね、と思って聴いていたら2、3日後に途切れるようになったり。
考えてみたら、libsamplerateでもっとも大きな負担になるのはDAD変換シミュレート自体だと思う（他の負担が少ないアップサンプリングの方法で、そこまでしてるのってあんまりなさそうな感じなのだ）。サンプリング周波数と量子化ビット数がどうかっていうのは多少は影響するものの、シミュレート精度に比べたら影響が少ないんだろうと思う。

さて、問題は音だ。
アップサンプリングについてツイッターでつぶやいていたら「アップサンプリングすると音の輪郭が人工的ににじむような気がします」というレスをいただいた。アップサンプリングされた音について、にじんで聞こえる、音色が変るという話は他でも読んだことがある（どこでか忘れたけど）。

実は、うちでもにじむような音が出ていた。
最初にpiCoreでアップサンプリングを試みて、音質は今までで最高と書いたときの音がまさにそうだったのだ。
これは、なんといえばいいんだろう、、、
ギラギラまばゆいような音で、後光が射してるとでも言えばいいのか、、、はっきり言って、何かがおかしい。それなのに情報量は増えて今迄聴こえなかった音が聴こえる感じなのだ。正直戸惑い、最高とは書いてみたものの、次のエントリーでは「ここまでいいのは怪しいんじゃないか、という気持ちにすらなる」と書かざるをえなかった。何しろ、鬼気迫る怪しい音なのだ。刀を構えた眼光凛々の剣豪に対峙してる感じ。「ああ、、そうですね、あなたホントに凄いよ（汗」と言わないとまずいんじゃないかという感じ。

しかし、それは長く続かなかった。
しばらくしてうちのPi2は電力不足で落ちたのである。鬼気迫るような怪しい音は、やっぱりあぶない音だったのだ。
電源を強化して後の音は、だいぶ落ち着いた。でも、なんとなく後光を背負った感じは残っている。一度落ちたからそう思うのかどうか知らないが、なんだか危なっかしい感触なのだ。176.4/16で当初は安定してると思っていたが、音切れを生じるようになったという経過は前述の通り。
MediumからFastestに変えたら後光はなくなった。
192/24での再生音の情報量はアップサンプリングなしの44.1/16よりも確実に多い。落ち着いていてシャープでより深く見通せる音だ。

どうも、ギリギリの条件でアップサンプリングしていると音がぎらつくような気がする。
電力の不足だったり、スペックの限界だったり、どういう影響なのか分からないが、何しろ音色が変わるのだ。派手なのでそっちのほうがいいという人もいるかもしれない感じだけど、そういう感じなので僕はほどほどにしたほうがいいと思う。
デジタル音楽再生ではシステムに余力があるほうがいい気がする。そのほうが安定して鳴るからだ。

そんなわけで現在、うちではRas pi2 / piCore7 / hifiberry Digi+が２台と、Ras pi B+ / volumio1.55 / RBD-02+が１台で運用中。
piCoreはメモリ再生用。volumioはNAS、ネットラジオでホームユースのBGM用。
どちらもアップコンバートなしには戻れなくなっている。

以下の記事（2016年7月11日付）では、DACチップについて問題提起している。

【藤本健のDigital Audio Laboratory】「アップサンプリング」で音は良くなる? 変わらない? 独自手法を提案する技術者に聞く - AV Watch
http://av.watch.impress.co.jp/docs/series/dal/1009623.html

DACがブラックボックスでアップサンプリング精度が疑問というのは、僕が感じていたことそのもので、とても興味深く読ませていただいた。しかしここには、ぼくが感じているもう一つの疑念には触れていない。
それは「そもそもDACチップってサンプリング定理を再生音に忠実に反映させるだけのスペックを持ってるの？」ということだ。

44.1/16では得られない情報が、同じデータを192/24にアップサンプリングした音だと得られている。
僕はずっと、ジッターの問題でデジタル再生音の違いが生じると思っていた。
しかし今、鳴っている音を前にして考えてみたら、デジタルトラポはRaspberry piとi2sボードで変わっていない。アップコンバートには負担が伴う。つまりジッターの条件は192/24のほうがよほど不利だ。

44.1/16のデータと192/24のデータは、サンプリング定理どおりの変換ならほぼ同じ波形が得られるはずのデータだ（アップコンバートに際して高域にわずかに減衰を生じるらしいが実質的には無視できると思う）。そもそも現在、アップサンプリングによる音質の改善については懐疑的な意見の方が主流だと思う。得られるアナログ波形は同じはずだからだ。
しかし現実に、うちの再生音には明らかな情報量の違いがある。

理由は、DACによる44.1/16の再生は不十分で192/24の再生はより十分に近づく、としか言えない。
得られるアナログ波形が違うのだ。
そもそもDACチップ内でアップサンプリングしなければ十分な再生ができないということは、44.1/16ではサンプリング定理に沿った再生ができないと現に認めてるということではないのか。

こんなことを考えながら普段から聴いてるわけではなくて、書き始めたらこんな所に流れ着いた。
音楽を鳴らしてる時はむしろ考えていない。
考えを整理しようとしていたら、なんということを書いてるんだろう、ということになった。
このあたりでやめておく。

Ras pi 2 + piCore7 + mpd + libsamplerateによるメモリ再生をメインシステムとして使い始めて（と言いながらRas pi B+ + Volumioも普段使いに併用してるけど）、アップサンプリングは微妙なものだということに初めて気付いた。
デジタルだからある程度は正確なのかな、融通きくのかな、という先入観があったのだけど、意外と注意がいるもんなんだな、みだりに上げ下げしちゃいけないんだな、という感じ。

libsamplerateは http://tinycorelinux.net/7.x/armv7/tcz/ ここから簡単にRas pi2用のpiCore7にインストールできるのだけど、よく見たら、soxr.tcz、sox.tcz というのも用意されている。
用意されてるから動くとは限らないが、やってみても損はない。

SoXについては、本家のサイトなどを読んでみようとしたんだけど、よく分からない。
SoX - Sound eXchange
| HomePage http://sox.sourceforge.net/Main/HomePage
| Resampling http://sox.sourceforge.net/SoX/Resampling
| FAQ http://sox.sourceforge.net/Docs/FAQ
| Documentation http://sox.sourceforge.net/Docs/Documentation
https://sourceforge.net/p/soxr/wiki/Home/

http://src.infinitewave.ca/
ここでは、コンバーターの比較をしてるようなんだけど、見方が分からない、、、
lightMPDで採用されてて、libsamplerateよりも軽くて音がいいらしいということなので、どういう仕組みなんだろうというのは興味があるのだけど、英語に弱いというのもあって、どこに何が書いてあるのかよく分からないのだ。

とりあえずpiCore7にインストールしてやってみよう。
早速問題が。
http://git.musicpd.org/cgit/master/mpd.git/plain/NEWS?h=v0.19
>ver 0.19 (2014/10/10)
>* new resampler option using libsoxr

つまり、mpd ver 0.19以上じゃないとSoXが使えない。
piCore7に0.19はインストールできない。 http://blown-lei.net/endive/blosxom.cgi/audio_diary/20160602a.htm

piCore7は止めて、Raspbianでやるか、、、
RaspbianはDebianでVolumioだし、たぶんいけるだろう。
でも、前に試みてから３ヶ月になる。piCoreの中の人ががんばっていればなんとかなってるかもしれない。Ras pi B+用ではダメだがRas pi2用だったらいけるという可能性もある。とりあえずはpiCore7でやれないかどうか確かめる。

Raspberry pi2用piCore7のファイルイメージをこちらから落す。
http://tinycorelinux.net/7.x/armv7/releases/RPi2/
microSDに焼いて設定を書き込んで、Ras pi2に刺して起動。イメージの拡張、アドレス設定、各種インストールしていく。
何がtczに用意されているかは、ここを参考に。http://tinycorelinux.net/7.x/armv7/tcz/
ときにバージョンアップされてファイル名が変わってることがある。

さて、SoXだ。
tce-load -wi sox-dev.tcz sox-doc.tcz soxr-dev.tcz soxr-doc.tcz soxr.tcz sox.tcz
こんなコマンドでいいか？と思ったら、以下のような感じでインストールが始まった。

sox-dev.tcz.dep OK
sox.tcz.dep OK
libao.tcz.dep OK
twolame.tcz.dep OK
libsndfile.tcz.dep OK
flac.tcz.dep OK
libvorbis.tcz.dep OK
lame-dev.tcz.dep OK
libao-dev.tcz.dep OK
libid3tag-dev.tcz.dep OK
libmad-dev.tcz.dep OK
libpng-dev.tcz.dep OK
opencore-amr-dev.tcz.dep OK
twolame-dev.tcz.dep OK
libsndfile-dev.tcz.dep OK
flac-dev.tcz.dep OK
libogg-dev.tcz.dep OK
libvorbis-dev.tcz.dep OK
sqlite3-dev.tcz.dep OK
wavpack-dev.tcz.dep OK

lameとかうちでは要らない気がするんですけど。まあ、いいや、任せよう。
mpdのインストール、できるだろうか。

tce-load -wi mpd-doc.tcz mpd.tcz libmpdclient.tcz libmpdclient-dev.tcz libmpdclient-doc.tcz

Downloading: mpd-doc.tcz
mpd.tcz.dep OK
Connecting to repo.tinycorelinux.net (89.22.99.37:80)
curl.tcz.dep OK
mpd-doc.tcz          100% |***********************************************************************| 36864   0:00:00 ETA
mpd-doc.tcz: OK
libavformat.tcz.dep OK
gnutls.tcz.dep OK
nettle.tcz.dep OK
p11-kit.tcz.dep OK
libavcodec.tcz.dep OK
celt.tcz.dep OK
libswresample.tcz.dep OK
libtheora.tcz.dep OK
libwebp.tcz.dep OK
libtiff.tcz.dep OK
schroedinger.tcz.dep OK
speex.tcz.dep OK
mpg123.tcz.dep OK
pulseaudio.tcz.dep OK
dbus.tcz.dep OK
Xorg-7.7-lib.tcz.dep OK
fontconfig.tcz.dep OK
freetype.tcz.dep OK
harfbuzz.tcz.dep OK
jack.tcz.dep OK
libsamplerate.tcz.dep OK
libcap.tcz.dep OK
libudev.tcz.dep OK
samba4-lib.tcz.dep OK
acl.tcz.dep OK
python.tcz.dep OK
readline.tcz.dep OK
Downloading: talloc.tcz
libmpdclient-dev.tcz.dep OK

これ全部いるんだろうか。
なんか、今回は使うつもりがないlibsamplerateとかも落ちてきてるんですけど。
最小限のシステムでいいんだけどな、、、

tc@box:~$ mpd -V
Music Player Daemon 0.19.9

Copyright (C) 2003-2007 Warren Dukes 
Copyright (C) 2008-2014 Max Kellermann 
This is free software; see the source for copying conditions.  There is NO
warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Database plugins:
 simple proxy

Storage plugins:
 local smbclient

Neighbor plugins:
 smbclient

Decoders plugins:
 [mad] mp3 mp2
 [mpg123] mp3
 [vorbis] ogg oga
 [oggflac] ogg oga
 [flac] flac
 [opus] opus ogg oga
 [sndfile] wav aiff aif au snd paf iff svx sf voc w64 pvf xi htk caf sd2
 [dsdiff] dff
 [dsf] dsf
 [faad] aac
 [ffmpeg] 16sv 3g2 3gp 4xm 8svx aa3 aac ac3 afc aif aifc aiff al alaw amr anim apc ape 
 asf atrac au aud avi avm2 avs bap bfi c93 cak cin cmv cpk daud dct divx dts dv dvd dxa 
 eac3 film flac flc fli fll flx flv g726 gsm gxf iss m1v m2v m2t m2ts m4a m4b m4v mad mj2 
 mjpeg mjpg mka mkv mlp mm mmf mov mp+ mp1 mp2 mp3 mp4 mpc mpeg mpg mpga 
 mpp mpu mve mvi mxf nc nsv nut nuv oga ogm ogv ogx oma ogg omg opus psp pva qcp qt 
 r3d ra ram rl2 rm rmvb roq rpl rvc shn smk snd sol son spx str swf tgi tgq tgv thp ts tsp 
 tta xa xvid uv uv2 vb vid vob voc vp6 vmd wav webm wma wmv wsaud wsvga wv wve
 [pcm]

Output plugins:
 null fifo alsa ao oss pulse jack httpd recorder

Encoder plugins:
 null vorbis opus lame twolame wave flac

Archive plugins:
 [bz2] bz2

Input plugins:
 file alsa archive curl ffmpeg smbclient

Playlist plugins:
 extm3u m3u pls xspf asx rss cue embcue

Protocols:
 file:// http:// https:// gopher:// rtp:// rtsp:// rtmp:// rtmpt:// rtmps:// smb:// alsa://

なんと、目出度くMusic Player Daemon 0.19.9のインストールができてしまった。しかしなんか、豪勢なシステムが出来てしまった。まるでVolumioだ。
これってメモリ再生に適してるの？
ちなみに、今迄うちでメモリ再生に使ってきているmpdはこんな感じ。

tc@box:~$ mpd -V
mpd (MPD: Music Player Daemon) 0.17.6 

Copyright (C) 2003-2007 Warren Dukes 
Copyright (C) 2008-2012 Max Kellermann 
This is free software; see the source for copying conditions.  There is NO
warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Decoders plugins:
 [vorbis] ogg oga
 [oggflac] ogg oga
 [flac] flac
 [sndfile] wav aiff aif au snd paf iff svx sf voc w64 pvf xi htk caf sd2
 [dsdiff] dff
 [dsf] dsf
 [pcm]

Output plugins:
 null fifo alsa oss httpd recorder

Encoder plugins:
 null vorbis wave flac

Input plugins:
 file

Playlist plugins:
 extm3u m3u xspf pls asx rss cue cue

Protocols:
 file://

こっちのほうがだいぶシンプルだ。
でも、これでSoXで音が出せるかな。
こちらのサイト（http://tatsumi.audio-asc.co.jp/article/425494296.html）を参考に、.mpdconfを設定。

とりあえず、
samplerate_converter "soxr very high"
に設定。
ネット上には、OpenMPは複数のCPU（複数コアを含む）を持った計算機上での並列化に威力を発揮する、とあり、pi2は4coreなので、設定しといたほうがいいんじゃないかと思うけど、どうやらOpenMPをインストールしないといけないらしく、今のところはやめておく。

他、設定はlibsamplerateのほうと同じ。
audio_buffer_size "4096"
buffer_before_play "25%"
audio_output_format "176400:16:2"

音はちゃんと出ました。
ちょっと聴いただけだが、なるほど、SoXとlibsamplerateでは違いはありそう。といっても他の条件があれやこれやと違うんだけど。
現時点では、libsamplerateのほうが耳に優しい音がする感じだ。
SoXのほうが刺激が強い。システムをもっとシンプルにシェイプアップしたらどうなるか、mpdのバージョンによってどう違うのか（libsamplerateのほうはmpd 0.17.6だ）、試みる時間があればやってみたいけど、いつになるかは分からない。

ちなみにtopで確認したら、SoXでは%CPUが4％台。libsamplerateでは20％台になる。

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1520     1 tc       S     135m 14.6   0  4.5 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1414     1 tc       S    62272  6.5   0 25.1 mpd

仮想メモリの数値が違う（SoXのほうがlibsamplerateの倍）のも謎なんだけど、そこで何かしてるんだろう。

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1317     1 tc       S    85724  9.0   0  4.3 mpd

tc@box:~$ mpd -V
Music Player Daemon 0.19.19

Copyright (C) 2003-2007 Warren Dukes 
Copyright (C) 2008-2014 Max Kellermann 
This is free software; see the source for copying conditions.  There is NO
warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Database plugins:
 simple

Storage plugins:
 local

Decoders plugins:
 [mad] mp3 mp2
 [vorbis] ogg oga
 [oggflac] ogg oga
 [flac] flac
 [sndfile] wav aiff aif au snd paf iff svx sf voc w64 pvf xi htk caf sd2
 [dsdiff] dff
 [dsf] dsf
 [pcm]

Output plugins:
 null fifo alsa ao oss httpd recorder

Encoder plugins:
 null vorbis lame twolame wave flac

Archive plugins:
 [bz2] bz2

Input plugins:
 file alsa archive

Playlist plugins:
 extm3u m3u pls cue embcue

Protocols:
 file:// alsa://

前のエントリーに追記で、アップコンバートについてちらっと書いた。
Ras piからRas pi2にハードの性能が上がったので出来るんじゃないかと思ってのことだけど、こんなに変わっていいのか？と思うほどだ。
理屈で言えばハイレゾファイルを再生するのと同じじゃないかと思うけど、ずっといいような気がする。ここまでいいのは怪しいんじゃないか、という気持ちにすらなる。

僕が考えるアップコンバートの効果というのは、ジッターが多い環境でより多く得られるということなので、うちの環境はジッターが多いのかなということになるけど、そこは保留して、ちょっとmpdによるアップコンバートについて考えてみようと思った。

mpdでは、アップコンバートに際してlibsamplerateの使用を推奨している。
piCoreではlibsamplerateがtczで用意されていて、下記のコマンドで簡単にインストールできる。
tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz

これがインストールされていない環境でのアップサンプリングは、低品質ということらしい。
低品質とは、どういうことなのか。
libsamplerateによる高品質なアップサンプリングと比べてどう違うのか。

libsamplerateのサイトは以下。
http://www.mega-nerd.com/SRC/index.html

同サイトのSRC Qualityのページ。
http://www.mega-nerd.com/SRC/quality.html
API（Applications Programming Interface）のページ。
http://www.mega-nerd.com/SRC/api.html
Converterについて、Miscellaneous API Documentationのページ。
http://www.mega-nerd.com/SRC/api_misc.html#Converters

まず、SRC Qualityから引用。

Signal-to-Noise Ratio - a measure of how much noise the sample rate conversion process adds to the signal. This is measured in decibels (dB) and the higher this value the better. For most sample rate converters, the SNR will vary depending on the input signal and the ratio between input and output sample rates. The only valid comparison of SNR is between the worst case for for each converter.

Bandwidth - most sample rate converters attenuate high frequencies as part of their operation. Bandwidth can be measured by finding the frequency where the attenuation is 3dB and expressing that as a percentage of the full bandwidth at that sampling rate.

Speed - the faster the better :-).

難しい。ＳＮ比とスピードはなんとなく分かるけど、帯域幅（Bandwidth）って何なのだ。
「ほとんどのサンプルレートコンバーターはそれらの操作に伴って高周波を弱める。」という。
さらに訳してみる。
「帯域幅は、減衰が3dBである帯域を見つけて、サンプリングレートを全帯域幅として、それに対するパーセンテージ表示で測定値とする」という感じだろうか。どういうことだろう、、、

It should be noted that the first three converters above are based on the algorithm by Julius O. Smith which emulates the conversion of the digital signal to an analogue one and then sampling the analogue signal at the new sample rate.

次の引用は、いくつかのサンプルレートコンバータソフトに関しての言及。
訳してみる。
「ここで特記すべきことは、上の３つのコンバーターの基本はジュリアス O.スミスのアルゴリズムに基づいていることで、それがエミュレートするのは、デジタル信号をアナログ信号に変換し、そのアナログ信号を新しいサンプルレートでサンプリングする、という動作である」
つまりDA-AD変換をエミュレートするということか。

ちなみにここで上げられている３つのコンバーターとは、sndfile-resample、Resample、ResampAudioの３つである。
SoX、Shibatch(SSRC)、sr-convertも紹介されているが、これらは他のアルゴリズムということらしい。

次にMiscellaneous API Documentationから引用。

The details of these converters are as follows:

• 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%.
• SRC_ZERO_ORDER_HOLD -
  A Zero Order Hold converter (interpolated value is equal to the last value). The quality is poor but the conversion speed is blindlingly fast.
• SRC_LINEAR -
  A linear converter. Again the quality is poor, but the conversion speed is blindingly fast.

見覚えがある内容だ。
mpd.confの、audio_output_formatの設定だ。このサイトでも以前に取り上げたことがある。
http://blown-lei.org/endive/blosxom.cgi/audio_diary/20140709a.htm
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20140709a.htm

SRC_SINC_*はSNRは全て97dB、bandwidthは97%、90%、80%と差がある。

「All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.」、訳すと「３つのSRC_SINC_*コンバーターは全てジュリアス O.スミスの技術に拠るものだが、そのコードは独自に開発されたものである」という感じか。

Julius O. Smith氏のサイトと思われるのが以下。
https://ccrma.stanford.edu/~jos/resample/

ZERO_ORDER_HOLDというのはwikipediaにあったり。読んでも僕には意味が分からない。
https://en.wikipedia.org/wiki/Zero-order_hold

ネット上を調べるうちに一目で分かる解説を見つけた。
直線補間アップサンプル（linear converter）も載っている。
http://community.phileweb.com/mypage/entry/2721/20151205/49583/

linearというのは本当にlinearなんだなあ、という感じだ。サンプル数が増える以外のメリットはなさそう。これで音質改善するというのは余程の場合だろうなあ、、、
ZOHは、linearに比べたらマシなの？、という感じ。

さて、どういうことか考えてみる。

まず、libsamplerate + mpdによる上位３つのリサンプリング方式はジュリアス O.スミス氏のアルゴリズムに基づいて行われていて、デジタルデータから元のアナログ波形を計算し、その波形のリサンプリングをエミュレートすることで新たなデジタル信号を作り出すということ。
一連の処理をするのに相応のPCパワーが必要だが、Ras pi2でもpiCoreで絞り込めば何とかなる。

PCのパワーがいらないアップサンプリングは元のアナログ波形を想定していない、ということなんだろう。それは前述のリンク先の画像からも明らかだ。
ちょっとそれでいいのかと思ったりするが、実際に過去の経験からは、それでも音質改善に繋がる場合があるというのはあるので、どうなってるんだろうとは思う。
一般的なDACチップで行われているアップコンバートでどのようなことが行われているのか以前から気になってはいたが、ここにきてやっぱり気になるという感じだ。

良質なリサンプリングとされている方式がDA変換をエミュレートするというのは考えさせられるところがある。
以前ネット上で、ハイレゾを作るのにアナログ変換を途中にはさむのはニセレゾじゃないかという議論があった。しかし、良質なリサンプリングはアナログ変換をエミュレートするのだ。
デジタル上のエミュレートで行われることと実際にアナログにするのは全く違うじゃないかって？まあ、そうなんだけどさ。

それから、リサンプリングの過程で高域の情報が失われるらしいこと。「帯域幅（Bandwidth）」という指標で計測され、libsamplerateでは上位の３段階でクオリティを選べること。

この時点でバイナリ一致とか気にすることが無意味になってきている。
リサンプリングでデータが変わる時点でバイナリ一致はないのだけど、アップコンバートした後でダウンコンバートしたら元に戻るのかな、というような曖昧な認識でいたのが違うのだということが分かった。このあたりは、ちょっと認識を改めないといけない。
（分からないのは、デジタルエミュレーションなのに何で高域が減衰するんだろうってこと、、、）

しかし、高域が減衰するといっても「SRC_SINC_FASTEST」でもbandwidthは80%であり、サンプリング周波数を仮に192kHzとしたら、3dB減衰するのは、、、
192 x 0.8 = 153.6(kHz)、、こんな計算でいいんだろうか。
これで可聴領域にどの程度の影響があるのか、はっきりしない。
もしかしたら、bandwidthは90%でもPCのパワーを必要とする「SRC_SINC_MEDIUM_QUALITY」より、bandwidthが80%でも負担が少ない「SRC_SINC_FASTEST」のほうが音がよくなる可能性もあるのではないか。

というか、その良くなってる音って何よってことになる。
つまり、もとのデジタルデータから引き出された音と言っていいのか、作った音じゃないのか、ということだ。

最近、注目されてる音楽フォーマット形式でMQAというのがあるそうなんだけど、従来の音楽ファイルよりも時間的な情報を重視していて音はいいらしい。これが実はバイナリ一致じゃないらしい？という話がある。バイナリ一致じゃないなら正確じゃないとは言えるけど、時間的情報が従来よりもきちんと再生されるなら、そのほうが正確な再生じゃないかとも思える。

ここらは考えだしたらきりがない。自分のスタンスを決めてやっていくしかないのだろう。

さて、音だ。
mpd.confの設定を変えて実際にどんな音になるのか聴いてみよう、と思ったところで息切れした。今後、余裕があったら比べることにする。

とりあえず気が付いたのは、アップサンプリングするならmpd.confのaudio_buffer_sizeの数値を上げる必要があるということ。
この数値が低いと、精彩を欠く音になる。
数値を上げすぎると音が出るまで時間がかかる。
Best Sinc Interpolatorの設定にしたら、88.2/16ですら音切れが起きる。これはRas pi2の限界だろう。

過去の経験では、アップサンプリングしないなら、audio_buffer_sizeはむしろ再生に不具合を生じない範囲で下げたほうが好ましいという印象があった。これはシステムにできるだけ負担をかけない再生ということなんだろうと思っていた。
これに対してアップサンプリングはシステムにより大きな負担を強いる方法で、audio_buffer_sizeを上げること自体はシステムへの負担増加になるとはいえ、アップサンプリングという更なる大きな負担への耐性をシステムが確保するためには、敢えてそうする必要がある、ということなんだろうと考えた。

そこでさっそくの番狂わせが、アップサンプリングなしの状態でも、audio_buffer_sizeが大きいほうが音がいいかもしれない、ということ。過去の経験は何だったのかという感じだ。
過去においては、NASに置いた音源での比較試聴だった。現在はRAMに音源を置いている。それが影響していたのかどうか。それとも他の条件が影響していたのか。今後、余裕があるときに考える。

しかしアップサンプリングなしの設定も含めていろいろ聴かないといけなくなった。なかなか大変だ。
当初は総当たり戦で比較視聴する気でいたが、比較する設定が増えすぎなので考え直さないといけない。

とりあえず今は、
samplerate_converter "Medium Sinc Interpolator"
audio_buffer_size "4096"
audio_output_format "176400:16:2"
buffer_before_play "25%"
という設定で鳴らしている。

どこから書いたものか。
現在、うちのオーディオのメインシステムはpiCoreを使ったメモリ再生になっている。
volumio + NASの音も悪くないと思うんだけど、妻は音量を上げたらうるさいというのだ。まあ、それは認めるけどたいしたことないじゃんと思うのだけど、妻としては差が大きいらしい。メモリ再生だと音量を上げてもうるさくないという。確かに、僕もそう思う。
オーディオやってる僕よりも、実は妻のほうが音質にはうるさいのだ。僕はうるさくても案外平気で聴いていたりする。

同じファイルであっても、NASに置くか、RAM上に置くかで、大きな音質差が生じる。
つまり、44.1kHz/16bitの音源の扱いはそれほどデリケートだということだろう。

過去には、調子がよくないNASを良いものに替えることで、音質が改善した経験がある。
このときは、NASの交換に伴ってmpd.confの設定が変わってしまった。調子が悪いNASを使っていたときはアップサンプリングする設定の方が音がよかったのが、NASを交換したら、しない設定の方が音がよくなったのだ。

今回のメモリ再生の試みに関連して http://www.yung.jp/bony/?p=3595 こちらのサイトのオーナーyung氏が同様のことをコメントしている。つまり、mpdのアップサンプリングの設定をやめたというのだ。そのほうが音がいいと。

mpdのアップサンプリング設定をやめるとき、というのがあるようだ。
システムの状況が改善し、ジッターが充分に減ったときには、アップサンプリングしないほうが音がよくなる、ということらしい。

逆に、ジッターが多い状況だとアップサンプリングしたほうが良くなる場合がある。アップサンプリング自体がシステムに負担を強いることだし、アップサンプリング自体の品質がどの程度確保できるかもシステムによるので、やってみないと結果は分からない。

過去には、うちではMac miniからの光出力をDACに送る際に、Mac miniでアップサンプリングしていたことがある。
５ｍばかり光ケーブルを引っ張っていたのでジッターが多かったのだろう。
アップサンプリングすることで、かなり音質が改善した記憶がある。

あと、LANの受け手側のmpdでアップサンプリングしていたことがある。
前述したNASの調子が悪いときの話で、データの転送自体ですらシステムに大きな負担がかかっていた。ジッターが増えやすい環境だったのではないかと思う。そうした場合には、mpdによるアップサンプリングの品質が悪くても、しないよりマシで、したほうが音がよかった。

もっと昔、ニールヤングがリリースしたDVDのハイレゾ音源を、当時はPowerbook G4だったかで再生して、CDと比べて音がいいことに驚いたことがある。もしかしたら元々ミキシングが違うのかもしれないが。ずいぶんクリアになるんだな、と当時は思った。ミキシングが違うからという印象ではなかったのだけど。

そこでタイトルに戻るのだけど、ハイレゾだ。

ファイルをアップサンプリングして再生するということは、ハイレゾを再生するということだ。
アップサンプリングして送信するということは、ハイレゾを送信するということだし、アップサンプリングするということはハイレゾ化するということだろう。

CDからのリッピングファイルをアップサンプリングしただけのファイルやデータなんてニセレゾじゃないかという話があるが、僕はいろいろ考えては見たんだけど、まあ、それもハイレゾだろう、という結論に達した。
問題になるのは売り方だ。
ニセレゾというのは、売り方の問題に関わる言葉だ。
それとハイレゾファイルって実際どうなのか、という問題は別だ。

ここまでの話の流れから、ここで言いたいことは自明だろう。

ハイレゾ再生というのは、ジッターが多い環境での音質対策なのだと思っている。
ジッターが少ない環境なら、理論的に44.1kHz/16bitで充分なのだと思う。
ジッターが多い環境になると理論どおりのDA変換とはいかないので、44.1kHz/16bitの音楽再生だと音質劣化が無視できなくなるんだと思う。

話は単純で、サンプリング周波数が多くなったら単位時間当たりのサンプルが増えるので、DA変換に際してのジッターの影響による誤差が相対的に少なくなるのだろうと考えている。
得られる音質改善は対症療法的なものだ。
デジタル音源再生の音質改善の本質はジッター低減だと思うのだが、コンシューマーが取り組むには限界がある。というか、そもそもコンシューマーはジッターについて考えたりなんかしない。mp3で大音量のほうがいいのである。RAMに可逆圧縮ファイルを取り込んだりなんかしないのだ。

思うんだけどハイレゾ音源の利用というのは、もともとコンシューマー向きの再生形態でハイエンドオーディオ向きではないと思う。
ハイエンドコンポであればジッター対策もそこそこ施されているはずだから、恩恵が少ないのではないか。
むしろコンシューマー向きのジッター対策していないオーディオセットでこそ、CDとハイレゾの差がはっきり出るんじゃないかと思うし、コンシューマーは難しいことは考えずにハイレゾ使ったら音がいいねで済んじゃうほうが望ましい。ジッターが少なかったらCDで充分なんて薀蓄はコンシューマーには似合わないし、コンシューマー用の機器ではそもそもジッター対策は打ちにくい。

いや、違うかな、、、
家電店とかでコンシューマー向きのミニコンポとかの音を聴く機会があるけれど、なんというか厚化粧で、これならどんなCDでもおんなじように鳴るだろうな、という印象を受けることがある。あらを隠すことには大成功してるという感じ。これも技術的なノウハウがあるのだろう。
CDとハイレゾの区別は付かないかもしれない。
だとしたらハイレゾの恩恵を受ける層はいないってことになるのかな、、、

話がそれた。
ここで取り上げるのは、CD音源の44.1kHz/16bitのファイルを192kHz/24bitに変換して、メモリ再生したらどう聴こえるだろうかということだ。
ジッター対策を多少なりとも行った環境（メモリ再生環境とはそういうものだと僕は理解している）でハイレゾに意味があるのかということ。
これで意味があるなら、ハイエンドオーディオでもハイレゾに意味があるだろう。

変換に使ったソフトは以下のサイトから落とした。
TASCAM Hi-Res Editor
https://tascam.jp/jp/product/hi-res_editor/top

使った音源は、Pierre Boulez の the Complete Columbia Album Collection というボックスセットから、CD40 Bartok / The Wooden Prince の一曲目、「Introduction」。CDをリッピングして作ってあった 44.1kHz/16bit flacからwav を作成、これを、TASCAM Hi-Res Editorを使って、192kHz/24bit wav を作成した。これを xrecode II を使ってflacにする。
つまり４種類のファイルができる。
ふだん使っているのはflacだが今回は敢えてwavも聴いてみる。

ファイルを作った直後に Compaq 6710b / foobar2000 で再生してiPodのおまけだったイヤホンで聞き比べたら、なんとなく違うような気がする。自作ハイレゾファイルのほうが、いいんじゃないかな。
次に、NASにコピーして、そこからのデータを再生。Compaq 6730b / mpd でイヤホンで聴いてみた。これは、区別が付かない。区別が付かない上に、どうも明らかに精彩を欠く。NASから物理的にもかなり遠いというのもあるのだろうか。しかし、それだけ聴いていたら、それほど音が悪いとも思わないんだけど。比較してしまうと差が明瞭になってしまう。

piCoreでメモリ再生してみる。メインシステムでスピーカーからの音だ。

結果から言えば、わずかだが違う。
ジッターの影響が少なくなれば区別が付かなくなる、という想定だったのだけど、違いはメモリ再生でも聴き取れるように思う。
Ras piなんて使ってるからそんなもんだろと言われても他と比較する術はないが。
192kHz/24bitのほうが繊細でグラデーションが細やかな鳴り方だ。44.1kHz/16bitは勢いがあるけど、やや荒い。ロックには良いだろうけど。ロックは昔からノイジーな音楽で、若者はそのほうが共感できることがある。

困った。自作ハイレゾの方がオーディオ的には音がいい。
というか、CDをリッピングしたファイルから作ったハイレゾでも、ハイレゾとして機能するんじゃないのかな？

何が困るって、CD１枚をリッピングしたflac（うちのライブラリの基本はそれだ）からハイレゾファイルを作って再生するとしたらファイルのサイズがバカにならない。Ras pi 2 のメモリ1GBではとうてい足りない。Ras pi の何がいいって、i2sデバイスが簡単に設定できるところなのだけど、数GB以上のメモリを積んだ他のボードPCを利用するとなると、i2sの工作が大変だ。ソフトウェアの設定も、Ras pi のように簡単にはいかないはずだ。
となると、usb出力を使うことになる。
うちには使えそうなusbデバイスがないのだ。何か探すということになる。
しかし現状で鳴っている音を聞くと、、そこまでするニーズって、僕の中にあるの？と思ってしまう。

他の手段としては、Ras pi 2 に他のメモリを追加して使うとか。usbメモリを刺して、musicディレクトリにマウントしてしまえば数GB以上の空間として使える。若干システムの負担になるのがデメリットだけど、LAN経由でNASを繋ぐほどじゃないはずだ。
というか、ハイレゾ変換ファイルusbメモリ再生をするつもりなんだろうか僕は。
日常的な使用という意味では、メモリ再生以上にハードルが高い。音源を格納したusbメモリを再生出来るネットプレーヤーなどという製品が巷では販売されているのだし、もしかしたらそっちのほうが有望な選択肢なんて事になるやもしれない。

などと考えながら、購入した正規のハイレゾファイルのメモリ再生などしていると、必ずしもハイレゾの方がいい感じに鳴るとばかりは言えないように思えてきた。Waltz for Debbyは、CDからリップした44.1kHz/16bit flacのほうがなんだかいい感じなのだ。HDTracksから購入した96kHz/24bitのファイルがあるんだけど、どうも良くない。ぼんやりしている。以前からハイレゾってこんなかな？ソフトな音だよねと思ってたんだけど、明確になってしまった感じだ。
理由は、おそらくはマスターの劣化によるものだ。

ハイレゾのマスターは、米コンコード社でオリジナル・アナログ・テープより変換された2010年192ｋHz/24bitリマスターを基にしたDSDマスターが使用されているとか。対して、CDのほうは1997年のもので、アナログマスターテープに20bit K2スーパーコーディングを用いたHQCDだ。
10年以上の時間による経年劣化が、音に反映されているのではないか。
もうひとつ音源を所持していて、Complete Village Vanguard Recordings 1961（日本盤）というもの。これは2002年にデジタル・リマスタリングされたらしく、どうもベースの音が太い。別ものだ。
調べてみたら、Waltz for Debbyという音源はいろいろあって一筋縄に行かないらしい。

こうなると、古い音源が欲しくなる。
これ以上ここに書くと話がとっちらかるので止める。

さて。
ras pi2 + piCore7 は、usbメモリを刺したら自動的に認識してくれる仕様になっているようだ。

tc@box:~$ fdisk -l

Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes
3 heads, 8 sectors/track, 322688 cylinders
Units = cylinders of 24 * 512 = 12288 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1             342        2902       30720   c Win95 FAT32 (LBA)
/dev/mmcblk0p2            2903      322688     3837432  83 Linux

Disk /dev/sda: 8054 MB, 8054112256 bytes
49 heads, 29 sectors/track, 11070 cylinders
Units = cylinders of 1421 * 512 = 727552 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1       11071     7865328   b Win95 FAT32

tc@box:~$ mkdir music/usb
tc@box:~$ sudo mount -t vfat /dev/sda1 music/usb

上記コマンドでマウントポイントusbにsda1をマウントできる。
しかし、理由はよくわからないのだけど、これでmusic/usbmに音楽ファイルをsftpで転送出来るのかというと、うまくいかない。権限の問題じゃないかと考えたりしたのだけど、解決できなかった。
しかたないので、以下のようなコマンドでNASの音楽ディレクトリもマウントして、そこからsshでコマンドを打って音楽ファイルをコピーすることにした。

tc@box:~$ mkdir titan
tc@box:~$ sudo mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /home/tc/titan

しかし、これもうまくいかない。 というのは、せっかくマウントしたusbメモリをメモリとして使ってくれないようなのだ。
piCoreはどうも、メモリが必要となるとまずはRAM、その次にmicroSDカードを使うように設定されているようで、マウントされてるusbメモリは目もくれず、まずRAMにデータを蓄積し、足りないとmicroSDカードにデータを蓄積していく。数GBのデータをマウントしたusbメモリに転送したつもりが、アンマウントして確認したら空っぽだった。
これでは音を出してもどこにあるデータを再生しているのかわからない。

つまり、usbメモリからの音を聴きたければ、あらかじめデータをusbメモリにコピーしてから刺さないといけない、ということだ。
解決法もあるのかもしれないが、発見できなかった。それでも、音が出るだけ御の字だ。

そんなこんなで、usbメモリに書き込んだファイルとLAN経由の音を比較してみる。音源はMiles DavisのSorcerer。
多少、usbのほうがいい感じ。細かいニュアンスがでるしアタック音のきつさが自然になる。
usbメモリに書き込んだファイルと、RAMに置いた音を比較してみる。、、若干、RAMのほうがいいかな。細かいニュアンスが出ている。比べたらusbのほうが荒々しい。
usbメモリを抜いたら、また変わるのかもしれないけど、ちょっと根気や記憶力が続かなくて比較できないと思う。

一応、音質の比較は LAN ＜ usbメモリ ＜ RAM、ということになった。
しかし、usbとRAMとの音質差はわずかで、激しい音楽の場合はusbでもいいんじゃないかな、という感じだ。

usbメモリにハイレゾ化したファイルを置くようにしたらRAMの不足を補えるかと思ったけど、どうも改善と悪化が打ち消しあってチャラになりそうな予感がする。
RAM再生で比較したら差を聴きとれた Boulez の Bartok / The Wooden Prince 「Introduction」を再生してみる。
RAMにCDからリップした44.1/16のflac、usbにそのファイルから作った自作ハイレゾ192/24のflac。

区別が付かない。
そう思いこんでるからかどうかわからないが、実際区別が付かない。残念だけど、usbメモリを自作ハイレゾの貯蔵庫にというアイディアはどうも無駄ばかり多いということになりそうだ。自作ハイレゾを本気で使う気ならメモリを数GB以上積んだマシンで取り組むべきなんだろう。

もしもusbメモリを貯蔵庫に使えるようなら色々と便利になるだろうにと思っていたんだけど、残念だった。今回はここまで。

tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz

NASを変更して２ヶ月になる。
その間になんとなく気になることが出てきた。

変更以前は、mpd.configのaudio_output_formatの設定でアップサンプリングして使っていた。
88200:24:2が良さそうだと感じていた。
それがどうも良さそうじゃなくなってきた。
最近は44100:24:2にしたりしていた。

なんだろうか、と思っていたところ、mpd.conf(5) - Linux man pageで興味深い記載を見つけた。
audio_output_formatの次、「samplerate_converter」の項目だ。
以下引用。読みやすいように改行を少し変えている。

samplerate_converter
This specifies the libsamplerate converter to use. The supplied value should either be an integer or a prefix of the name of a converter. The default is "Fastest Sinc Interpolator".

At the time of this writing, the following converters are available:

Best Sinc Interpolator (0)
Band limited sinc interpolation, best quality, 97dB SNR, 96% BW.

Medium Sinc Interpolator (1)
Band limited sinc interpolation, medium quality, 97dB SNR, 90% BW.

Fastest Sinc Interpolator (2)
Band limited sinc interpolation, fastest, 97dB SNR, 80% BW.

ZOH Interpolator (3)
Zero order hold interpolator, very fast, very poor quality with audible distortions.

Linear Interpolator (4)
Linear interpolator, very fast, poor quality.

internal
Poor quality, no floating point operations. This is the default (and only choice) if MPD was compiled without libsamplerate.

For an up-to-date list of available converters, please see the libsamplerate documentation (available online at ).

internalというのはmpdに組み込まれているという意味らしい。
和訳してみる。
「クオリティは低く、浮動小数点演算をしない。libsamplerateなしにmpdがコンパイルされているようならこれがデフォルトになる（そして、これしか選択できない）。」
なんとまあ。

mpdをインストールしたときに出来るconfig.logを確認したら記述があった。
「configure:8115: WARNING: libsamplerate not found -- disabling libsamplerate resampling」
96/24までリサンプリングしてもCPUの負担が大して増えないのは、増えないなりの理由があったというわけだ。

そういうわけで、audio_output_formatの項目をコメントアウトしてみた。
もとのflacファイルのフォーマット（44.1kHz/16bit）のままで出力されるはずだ。
どうも、悪くないようだ。
というか、これが一番良さそうだ。

NASを変更する前は、それでもリサンプリングしたほうが良いような気がしていた。
何で変わったのかは分からない。
しょっちゅう音切れを起こしていたし、NASからの信号自体の品質も低かったのかもしれない。そういう状況だったから、低品質でもリサンプリングするほうが多少ジッター軽減につながっていたのかもしれない。
かもしれないばっかりだが。

いろいろ変わったので、現在のオーディオシステムについて記録しておく。

４月６日、ちょっといろいろ追記。
一部、書き間違えを訂正している。

昨年９月のエントリーで書いたのと比べて、DACの上流が変わっている。

まずCDプレーヤーだけど、TEACのVRDS-25xsを外して、KenwoodのDP-5090に変更している。
理由は、実はVRDS-25xsだとCDを入れっぱなしにするとターンテーブルにCDがくっついてしまうことがあるから。めったにはないんだけど、そうなると天板を開けるなりしてCDを取り出さないといけない。僕以外の家族が使うことを想定しているので、マニアックで高音質目指した機種よりトラブルが少ない機種のほうが望ましい。
VRDS-25xsよりもいい音がPCトランスポートで得られる目星がついたかも？ということもある。

RCA(COAX)出力をBNC、さらにBJC-XP-TRCでXLRに変換してDACに入力している。
なぜか分からないけど、odeon-liteのRCA入力周りの状態によって、たびたびodeon-liteのリレーが動くということがある。25xsでもDP-5090でも同じで、電源ケーブルその他対策を講じてみたけど、なかなか直らない。
CDプレーヤーからの出力をBJC-XP-TRCをかませてXLRに入れると、この不具合がない。
これでいいや、ということにしてしまった。

PCトランスポートとしてibook G4を追加している。
mac miniのAudirvana Plusと、ibook G4のmpdを使い分けできるようにしているが、最近は主にmpdを使っている。
理由は、実はmac miniを子供に占拠されてるからだ。４才の子がPOCOYOを観てるのにいちいちどけと言ってゴソゴソするのは面倒だ。メモリを8GBも積んでいてメインマシンにするつもりだったんだけど、そうもいかなくなっている。
その点、mpdなら離れた場所にあるクライアントからオーディオ再生の指示が出せる。音質は、未だ試行錯誤中だけど定評どおり期待できそうな感じだ。

mpdの出力は、現在は88.2kHz/24bitにしている。
アップサンプリングの周波数は元のファイルの整数倍がいいという話を随所で聞くので44.1kHzの倍にした。
あと、整数倍でのアップサンプリングのほうがibookへの負担が少ないだろうと思ったから。デジタルオーディオではシステムが安定して動くという事が音質上極めて重要だと個人的に思っている。そのためには負荷が少ないほうがいいのではと考えた。
96kHzのときと聴き比べは出来ていないが、なんとなく音がしっかりしたような気がする。
じゃあなぜmac miniは96kHzなのかというと、こっちはなんとなく96kHzのほうがいいような気がしたから。理由はよく分からない。気のせいかもしれない。メモリ8GBが効いてるのかも知れない。

以前は、mac miniからの光出力を直接SRC2496の光入力に繋いでいたが、今はAT-HDSL-1に繋いで同軸出力に変換している。
代わりにibook G4、RAL-2496UT1からの出力を光入力に繋いでいる。以前はこっちをAT-HDSL-1に繋いでいたんだけど、USBから光、さらに同軸と、こんなに変換を繰り返すことにどういう意味があるのかと感じて入れ替えた。

ibook本体は、ラック下の床に邪魔にならないように置いている。のぞきこむと白いリンゴが光っているのが見える。
mac miniはコンポから若干離れたとこのＴＶ台に、モニター付けてセッティングしている。前述したとおり最近はもっぱら子供が使っている。AudirvanaとiTunesからの音声を５ｍもの長さの光ケーブルでオーディオコンポに出力している。

トランスポートからのデジタル出力は全てSRC2496に入れている。
これはDDコンバーターで「リサンプリング」することでジッターを低減するという。
mac miniからの５ｍの光ケーブルをDACに繋ぐ場合、直接だととてもVRDS-25xsの音質に届かなかったが、SRC2496を間にかますだけで超えてしまった。それからというもの僕はリサンプリング信者になってしまった。

ほかにもいくつか変更がある。
以前は繋いであったTU-875を外している。これはスイッチが壊れてしまったから。
アナログプレーヤーを使う際に必要なのでいずれは修理したい。

DEQ2496によるイコライジング・室内音響調整は、したいけど出来ないまま。
繋いではいるけど使ってないので今回は書いていない。
本当はカセットデッキのテープ再生をデジタル変換してPCに記録するのにも使いたいんだけど、出来ていない。

AirMac Expressは繋ぐとこがなくなったしオーディオとして使ってないので外した。
別室のプリンタに繋いだら便利かも、とか考えている。

あと、ここには書いていないが、SRC2496の外部クロックに某製品を繋いでいた。
SRC2496の内部クロックは良くないという話を読んだことがあったから、ものは試しと。
しかし、これがどうも繋いでいるとポップノイズが出る。音声再生中に限らずクロックのスイッチを入れているとプチ、プチ、というので、クロックの不具合のような気がする。あれこれ思いつく対策をとってみたけど、結局、外部クロックを使わなかったら不具合ないようだということで、外してしまった。
使う方がいい音がするということもないように思ったので、当面は外部クロックなしで使うつもり。
もしかしたら、ヤフオクで落とした中古だったので壊れているのかもしれない。

odeon-lite以下の下流は、SM-SX100、4425mk2、T900A、と１０年前から変わっていない。
それだけ気に入ってる構成なわけで、換え難いところがある。

今後の課題。まず、いずれはNASを変更したい。
オーディオルームで使うには静粛性に難がある。しばしばファン？の音が気になる。

次にDAC。
odeon-liteはいい音だと思うけど、DSDに対応してないし、ノイズに対してデリケートすぎるとこがあるので配線とか気を使う。
最新のDACの音に興味があるということもあるし、ibookのmpdからのUSB出力を受けるのが、そのUSBから電源供給を受けるRAL-2496UT1というのはどうなんだろうか、という気持ちもあったりする。外部電源が製品化されてるけど４万円もする。それなら新しいDACを買いたい。
ただ、odeon-liteが壊れない限り当分先のことになるとは思う。