abk1's scratched blog 3::AUDIO DIARY

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、

このたびサイトのログを眺めていたら、意外にアクセスが多いのが下記のエントリーだと気付いた。
Raspberry Pi でメモリ再生を試みる（piCore7にmpdをインストールする）－いろいろ追記あり

音質向上を追及した多くのディストリビューションが公開されている中で、正直、piCore7にどの程度のニーズがあるのか分からないんだけど、なるべく分かりやすい形に書き直して、まとめておこうと思った。しかし、結果的に長くて分かりにくい。

piCore7をダウンロード。

以下、tiny core linuxのサイト、piCore7関係のソース。

piCoreはv.9まであるんだけど、mpdを簡単にインストールできるのはv.7しかない。
v.9用TCZとして用意されているライブラリにはDoxygenはないし、Boostはインストールしてもうまく機能しない。v.7のTCZは機能するようだ。
TCZというのはtiny core linux系のOSで扱いやすいようにソフトウェアやライブラリをパッケージ化したようなもので、基本的にはTCZの一覧表に載っているソフトなら簡単なコマンドを打つだけでインストールできる。ときにソフト間の依存性の関係によっては出来ないこともあったり、前述のようにインストールしたのに使えないこともあったりする。

まず使用するras piに合わせてOSを落とす。
落としたらmicroSDに書き込む。

microSDの準備。

microSDにはPICOREというボリュームができているので、その中のconfig.txtを編集する。
うちではi2s出力とusb出力以外は使わないので、もとからある設定について下記のように記載変更している。HDMIやイヤホン出力を使う場合はこんな設定ではいけないらしいけど、どこをどうしたらどうなるかは調べていない。
dtparam=i2c=off,spi=off,i2s=on,i2c_vc=off

i2sデバイスを使用するなら、そのデバイスに合わせた設定を記載する。
例えばhifiberryのデバイスなら、以下のような感じ。

https://www.hifiberry.com/guides/configuring-linux-3-18-x/

DAC/DAC+ Light	dtoverlay=hifiberry-dac
DAC+ standard/pro	dtoverlay=hifiberry-dacplus
Digi/Digi+	dtoverlay=hifiberry-digi
Amp/Amp+	dtoverlay=hifiberry-amp

例えばうちで使っているi2sDACはLINUXCOMのRBD-02+なので「dtoverlay=hifiberry-dac」と書き込む。
http://linuxcom.shop-pro.jp/?pid=79120318

piCore7を起動しsshでログインする。

microSDカードをRaspberry Piに刺して起動する。
余裕のある電源を使うこと。
sshでログイン。userはtc、パスワードはpiCore。
ログインに必要なipアドレスは環境によって変わるのでユーザー各自で確認のこと。ちなみにうちでは、いちいちDNSDHCPサーバーにアクセスして新たに割り振られたipを確認している。
sshでは最初のログインで(yes/no)?と訊かれるので、yesでログインする。

tc@box:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz\
Done.
tc@box:~$

パーティションディスクイメージを拡張。

以下の流れでパーティションディスクイメージを拡張。もともとは最低限の大きさなので、拡張しないと後で諸々のインストールに支障を生じる。

tc@box:~$ sudo fdisk -u /dev/mmcblk0
Command (m for help): p

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
3 heads, 8 sectors/track, 646826 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1            8192       69631       30720   c Win95 FAT32 (LBA)
/dev/mmcblk0p2           69648       93119       11736  83 Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 2
First sector (8-15523839, default 8): 69648
Last sector or +size or +sizeM or +sizeK (69648-15523839, default 15523839): 15523839

上記は、端末画面に表示されたものをそのままコピペしている。
適宜、表記されているpとかdとか2とか、打ち込んでenterキーを押していくと、物事が進行していく。

気を付けないといけないのは、どこからどこまで拡張するか指示するための数字。
Command (m for help): p でパーティションボリュームの状態が表示される。
上記の例では /dev/mmcblk0p2の startが69648、endが93119、ということだけどこれを拡張することになる。
First sectorは、startの69648のまま指示。Last sectorは93119以上にしないといけない。いっぱいに拡張するなら「default 15523839」と表示されているので、15523839と打ち込んで、enterキー。
以降、下記のように続ける。

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
tc@box:~$ 
tc@box:~$ sudo reboot
tc@box:~$ Connection to xxx.xxx.xxx.xxx closed by remote host.
Connection to xxx.xxx.xxx.xxx closed.

ここでリブート。
注意しないといけないのは、パーティション拡張の指示をしたからだと思うんだけど、この時点でsshのkeyが無効になっている。そのままログインしようとしたら撥ねられるので、.ssh/known_hostsに保存されているipアドレス:xxx.xxx.xxx.xxxの行を削除しないといけない。削除したら再度、初回のログインの処理をしていけば、以降はkeyをなくすことはない。

再度、ログインして以降の流れは以下の通り。拡張作業の最終段階。

tc@xxx.xxx.xxx.xxx's password: 
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@box:~$ 
tc@box:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/mmcblk0p2 is mounted on /mnt/mmcblk0p2; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 30
The filesystem on /dev/mmcblk0p2 is now 7727096 (1k) blocks long.
tc@box:~$ 

この流れは http://tinycorelinux.net/7.x/armv6/releases/RPi/README にも書いているが、ちょっと不親切。
コマンドの使い方を調べる必要があった。
うちの記述も分かりやすいとは言えないと思うけど、実際に触ってやってみたら分かるんじゃないかと思う。

ipアドレスを固定。

これも下記のような流れで。
まずifconfigで確認。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr B8:27:EB:36:8A:DF  
          inet addr:192.168.1.116  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:775439 errors:0 dropped:92 overruns:0 frame:0
          TX packets:250166 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1123681152 (1.0 GiB)  TX bytes:24070244 (22.9 MiB)

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

上記の例では、192.168.1.116となっている。これはDNSDHCPサーバーから割り振られたもので、ネットワークの状況次第でこっちの知らぬ間に変わる可能性がある。うちでは変わられては困るので、固定している。
以下、流れを記載。

eth0.shを作る。

tc@box:~$ cd /opt
tc@box:/opt$ ls
bootlocal.sh  bootsync.sh   shutdown.sh   tcemirror
tc@box:/opt$ vi eth0.sh

/optディレクトリに移動。
ここには設定ファイルを置く場所で、ここにeth0.shを作ることでipを固定できる。
viでファイルを作成。
下記のように記載。

#!/bin/sh
pkill udhcpc
ifconfig eth0 192.168.1.82 netmask 255.255.255.0 broadcast 192.168.1.255 up
route add default gw 192.168.1.1
echo nameserver 192.168.1.1 > /etc/resolv.conf

上記の例では、192.168.1.116だったアドレスを192.168.1.82に変更している。

bootsync.shを編集。

引き続き、流れを記載していく。
chmod +x コマンドで実行権限を変更。
さらに、bootsync.shファイルを編集。

tc@box:/opt$ ls
bootlocal.sh  bootsync.sh   eth0.sh       shutdown.sh   tcemirror
tc@box:/opt$ chmod +x eth0.sh
tc@box:/opt$ ls -aFl
total 28
drwxrwsr-x    3 root     staff          200 Jun  4 12:46 ./
drwxr-xr-x   17 root     root           380 Jan  1  1970 ../
-rw-rw-r--    1 tc       staff          403 Jun  4 10:53 .filetool.lst
-rw-rw-r--    1 root     staff          145 Dec 31  2014 .xfiletool.lst
-rwxrwxr-x    1 root     staff          360 Jan 20  2015 bootlocal.sh*
-rwxrwxr-x    1 root     staff          272 Dec 31  2014 bootsync.sh*
-rwxr-xr-x    1 tc       staff          179 Jun  4 12:46 eth0.sh*
-rwxrwxr-x    1 root     staff          613 Dec 31  2014 shutdown.sh*
-rw-rw-r--    1 root     staff           31 Dec 31  2014 tcemirror

tc@box:/opt$ sudo vi bootsync.sh

bootsync.shに「/opt/eth0.sh &」の一行を下記のように書き加える。
起動時にeth0.shに記載した設定を読み込んでくれる。

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

.filetool.lstの編集。

tc@box:/opt$ vi .filetool.lst

.filetool.lstファイルは、前述した「filetool.sh -b」コマンドでデータを保存する場所を設定している。
これに「opt/eth0.sh」を追記する。
追記しなかったら、再起動したら設定が消えてしまうということ。
同時に、いくつか他にも保存して欲しい場所やファイルがあるので、これも追記する。
usr/local/etc/
opt/bootlocal.sh
以上を追記して、以下の通り。以前はetc/fstabも追記していたけど、うちでは使わないので。使うようなら記載を。

opt
home
etc/passwd
etc/shadow
etc/group
etc/gshadow
usr/local/etc/ssh/ssh_host_dsa_key
usr/local/etc/ssh/ssh_host_dsa_key.pub
usr/local/etc/ssh/ssh_host_ecdsa_key
usr/local/etc/ssh/ssh_host_ecdsa_key.pub
usr/local/etc/ssh/ssh_host_ed25519_key
usr/local/etc/ssh/ssh_host_ed25519_key.pub
usr/local/etc/ssh/ssh_host_rsa_key
usr/local/etc/ssh/ssh_host_rsa_key.pub
usr/local/etc/
opt/bootlocal.sh
opt/eth0.sh

忘れないように「filetool.sh -b」を打って、設定が失われないようにする。

tc@box:/opt$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz\
Done.
tc@box:/opt$ sudo reboot

これで再起動したら、指定したipアドレスに固定される。
当然、sshでのログインも新たに固定されたアドレスで行うことになる。
再起動の前に、filetool.sh -bを打ち忘れたら、また最初からやり直しになるので注意。

bootlocal.shを設定。

tc@box:/opt$ vi bootlocal.sh

再起動、ログインして作業を継続。
bootlocal.shは、起動時に実行するコマンドを記載するファイル。
うちでは、下記のようなコマンドを追加で書き込んでいる。mpdの動作環境設定に関係してくる指示で、人によっては要らなかったり、もっと他の内容が望ましい場合もあるだろう。個々の環境や状況に合わせて設定することになる。

mkdir /mnt/music
mkdir /mnt/music/nas
mkdir /mnt/music/ram
touch /mnt/music/ram/dummy.cue
chmod -R 777 /mnt/music

# mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /mnt/music/nas

僕の場合、/home以下にNASのマウントポイントを作る気になれなかったので（間違ってfiletool.sh -bを打ったら、NASのデータをmicroSDに保存するようなことになりかねないので困ると思った）、/mnt以下に起動のたびに作ることにしたということ。
一番下の行のコマンドでNASをマウントさせるようにしている（/etc/fstabに記載するよりも簡単）。
敢えてコメントにしているのは、各種設定の途中ではマウントする必要がないから。一通り作業が終わってmpdの環境が完成したら、コメントアウトしてを外して、filetool.sh -bで保存し、再起動したらNASがマウントされているという塩梅。

各種ライブラリをインストール。

mpdをインストールしたり動かすためのライブラリなどをインストールする。
以下、コマンドのみを羅列。

tce-load -wi gcc.tcz glib2-dev.tcz ncurses-dev.tcz make.tcz automake.tcz compile-essentials.tcz squashfs-tools.tcz bash.tcz bc.tcz pkg-config-doc.tcz pkg-config.tcz
tce-load -wi python-dev.tcz python-doc.tcz python.tcz boost-dev.tcz boost.tcz doxygen-doc.tcz doxygen.tcz
tce-load -wi alsa.tcz alsa-config.tcz alsa-doc.tcz alsa-dev.tcz alsaequal.tcz alsa-locale.tcz

tce-load -wiというコマンドは、TCZライブラリから指定したソフトをダウンロード、インストールしてくれる。
上記のコマンドでmpdなどのインストールに必要な環境と、alsaをインストールした、つもり（本当は、不要なものが混じってるかもしれない）。

この時点でalsaの状況を確認したら下記のような感じ。
接続しているi2sDACの設定ができている。

tc@box:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
tc@box:~$ 

tc@box:~$ ls /opt
alsa/         bootlocal.sh  bootsync.sh   eth0.sh       shutdown.sh   tcemirror

こんな感じで、/optにalsaのディレクトリができている。
つまり、この時点でfiletool.sh -bを打たずにシャットダウンしたら、このディレクトリが消えることになるのかな。詳細は調べてないから正確なことは言えないけど、いろいろとインストールしていく合間に適宜保存のコマンドを打つ必要はありそう。

続いてflacなどの再生デコーダー関係をインストール。コマンドのみ羅列。

tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz
tce-load -wi flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz icu-dev.tcz icu.tcz
tce-load -wi libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz faad2-dev.tcz faad2-doc.tcz faad2.tcz
tce-load -wi libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz

tc@box:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz\
Done.
tc@box:~$ 

忘れず、保存、、、

mpdをインストール。

今回、以下の2通りのやりかたをまとめておく。

• （１）tce-load -wiコマンドでmpdをインストール。
• （２）ソースからコンパイルしmpdをインストール。

（１）tce-load -wiコマンドでmpdをインストール。

tc@box:~$ tce-load -wi mpd-doc.tcz mpd.tcz

上記コマンド一つでmpdのインストールが始まる。
しかし同時にインストールされるものが次々に出て来て、そんなに要るの？と思うほどだ。 インストール終了後は下記のような感じ。

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://
tc@box:~$ 

ffmpegとかdsd関連もインストールされている。

mpdの設定を行っていく。mpd.confファイルはどこにあるんだろう。
デフォルトは~/.mpdconf、~/.mpd/mpd.conf、/etc/mpd.confなので、そこにないかと探しても見つからない。

findコマンドで探したら、下記にmpdconf.exampleがみつかった。
/usr/local/share/doc/mpd/mpdconf.example
/tmp/tcloop/mpd-doc/usr/local/share/doc/mpd/mpdconf.example
これらをコピーして使うよりか、viで設定ファイルを作って、どこかから設定をコピペしたほうが簡単だと思う。
記載例は後述。

（２）ソースからコンパイルしmpdをインストール。

tc@box:~$ wget https://www.musicpd.org/download/mpd/0.19/mpd-0.19.9.tar.xz
tc@box:~$ xz -dv mpd-0.19*
tc@box:~$ tar -xf mpd-0.19*
tc@box:~$ cd mpd-0.19*
tc@box:~/mpd-0.19.9$
tc@box:~/mpd-0.19.9$ ./configure

########### MPD CONFIGURATION ############

Archive support:
	(+bzip2) (-ISO9660) (-ZIP) 
Client support:
	(+IPv6) (+TCP) (+UNIX Domain Sockets) 
Storage support:
	(-NFS) (-SMB) 
File format support:
	(+AAC) (-AdPlug) (+DSD) (-C64 SID) (-FFMPEG) (+FLAC) (-FluidSynth) (-GME) 
	(+libsndfile) (-MikMod) (-MODPLUG) (+MAD) (-MPG123) (-Musepack) 
	(-Opus) (-OggTremor) (+OggVorbis) (-WAVE) (-WavPack) (-WildMidi) 
Other features:
	(+libsamplerate) (-libsoxr) (+libmpdclient) (+inotify) (+SQLite) 
Metadata support:
	(-ID3) 
Playback support:
	(+ALSA) (+FIFO) (+File Recorder) (+HTTP Daemon) (-JACK) 
	(-libao) (+OSS) (-OpenAL) (-OS X) (-Pipeline) 
	(-PulseAudio) (-ROAR) (-SHOUTcast) (-Solaris) (-WinMM) 
Streaming encoder support:
	(+FLAC) (+LAME) (-Shine) (+Ogg Vorbis) (-Opus) (-TwoLAME) (+WAVE) 
Streaming support:
	(-CDIO_PARANOIA) (-CURL) (-SMBCLIENT) (-Soundcloud) 
	(-MMS) 
Event loop:
	epoll

##########################################

Generating files needed for compilation
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/doxygen.conf
config.status: creating systemd/mpd.service
config.status: creating config.h
config.status: executing depfiles commands
MPD is ready for compilation, type "make" to begin.
tc@box:~/mpd-0.19.9$ 

今回、ダウンロードしたmpdは0.19.9。これはTCZで用意されているmpdに合わせた。
ソースからコンパイルするメリットは、システムを小さくできることだ。
１分かそこらでconfigure終了。うまく行ったかに見えた。

tc@box:~/mpd-0.19.9$ make -j4
(ひたすら文字が並ぶ)
src/decoder/plugins/MadDecoderPlugin.cxx:37:17: fatal error: mad.h: No such file or directory
compilation terminated.
Makefile:7346: recipe for target 'src/decoder/plugins/libdecoder_a-MadDecoderPlugin.o' failed

上記のように、エラーでmake終了。configureが通ったのにmakeで止まるという経験は初めてだ。
libmadをアンインストールしないといけないらしい。

tc@box:~/mpd-0.19.9$ cd /mnt/*2/tce
tc@box:/mnt/mmcblk0p2/tce$ ls
mydata.tgz  onboot.lst  ondemand/   optional/
tc@box:/mnt/mmcblk0p2/tce$ vi onboot.lst

tc@box:~$ sudo reboot

tc@box:~$ cd /mnt/*2/tce
tc@box:/mnt/mmcblk0p2/tce$ rm optional/libmad.tcz*
rm: remove 'optional/libmad.tcz'? y
rm: remove 'optional/libmad.tcz.md5.txt'? y

tc@box:/mnt/mmcblk0p2/tce$ sudo reboot

/mnt/mmcblk0p2/tce/onboot.lstの記載から、libmad.tczの１行を削除し保存（ここはfiletool.sh -bを使わなくてもいい）、reboot。
さらに、/mnt/mmcblk0p2/tce/optionalから、libmad.tcz関連を削除して、reboot。
これでアンインストールできる。

アンインストールしてconfigureしてmakeしたら、エラーなく終了。

tc@box:~/mpd-0.19.9$ make -j4
(ひたすら文字が並び１０分で完了)

tc@box:~/mpd-0.19.9$ mkdir ../mpd
tc@box:~/mpd-0.19.9$ sudo make DESTDIR=../mpd install

tc@box:~/mpd-0.19.9$ cd
tc@box:~$ mksquashfs mpd mpd-0.19.9.tcz
tc@box:~$ md5sum mpd-0.19.9.tcz > mpd-0.19.9.tcz.md5.txt
tc@box:~$ ls
mpd/                    mpd-0.19.9.tar          mpd-0.19.9.tcz.md5.txt
mpd-0.19.9/             mpd-0.19.9.tcz
tc@box:~$ sudo mv *tcz* /mnt/*2/tce/optional
tc@box:~$ ls
mpd/            mpd-0.19.9/     mpd-0.19.9.tar
tc@box:~$
tc@box:~$ sudo vi /mnt/*2/tce/onboot.lst

tiny core linux系では、ひとまとめにインストールしてtczファイルを作って管理する。
今回の場合、コンパイルしたデータからtczファイルとtcz.md5.txtファイルを作る。
これらのファイルを/mnt/mmcblk0p2/tce/optionalディレクトリに移動させて、onboot.lstの末尾に、mpd-0.19.9.tczと記載を追記する。

これでインストール終了。
しかしlibmadをアンインストールしたので、mp3は聞けない。

ところで、GCCの最適化をしてコンパイルしmpdをインストールする方法がある。
最適化について参考にさせていただいたサイトは下記のとおり。

みみず工房
http://mimizukobo.sakura.ne.jp/index.html
2017/10/21(PC_Audio) gccの最適化オプション

new_western_elec
http://nw-electric.way-nifty.com/blog/2016/08/mpdpi-2-pi-3-5a.html
MPDをソースコードからコンパイルしてPi 2 Pi 3に最適化する方法

僕には最適化について知識はないので、上記サイトでPi2とPi3用に紹介されているコマンドを打った。

./configure CFLAGS="-O2 -march=armv7-a -mtune=cortex-a7 \
-mfpu=neon-vfpv4 -mfloat-abi=hard" \
CXXFLAGS="-O2 -march=armv7-a -mtune=cortex-a7 \
-mfpu=neon-vfpv4 -mfloat-abi=hard" \
--with-systemdsystemunitdir=/lib/systemd/system

これも一見、問題なくconfigure終了したかに見えたけど、やはりmakeの段階でエラーになった。
libmadをアンインストールして再度configureしたら、make、installできた。
本当はalsaなどのインストールもソースから最適化してコンパイルを試みるべきだったかもしれないけど見送った。ちょっとそこまで試行錯誤する余裕がなくて、、、

mpdの設定を行っていく。mpd.confファイルが必要だ。

tc@box:~$ ls
mpd/            mpd-0.19.9/     mpd-0.19.9.tar
tc@box:~$ ls m*9/doc
developer.xml    doxygen.conf.in  mpd.conf.5       protocol.xml
doxygen.conf     mpd.1            mpdconf.example  user.xml

tc@box:~$ cp m*9/doc/mpdconf.example .mpdconf

ダウンロード、解凍したファイルの中にmpdconf.exampleがある。
それを、/home/tcディレクトリにコピーして.mpdconfを作り編集。ここに置くのが一番簡単かな。
しかし素のmpdconf.exampleを編集するより、viで作って既存のmpdサーバーから設定をコピペして編集したほうがいろいろ早いだろうと思う。

この時点で、インストールの作業場として使ったmpdディレクトリや落として解凍したファイルなどが残っている。
これらは、もう要らないので削除していい。
残していたら、filetool.sh -bに際して無駄に時間がかかる。
mpd.confのdb_fileの設定場所によっては、保存するのにfiletool.sh -bを使うことになるので、削除しておいたほうが快適になる。

tc@box:~$ ls
mpd/            mpd-0.19.9/     mpd-0.19.9.tar
tc@box:~$ sudo rm -rf mpd*

.mpdconfの編集例。

tc@box:~$ vi .mpdconf

music_directory                "/mnt/music"
playlist_directory             "~/.mpd/playlists"
db_file                        "~/.mpd/database"
log_file                       "~/.mpd/log"
pid_file                       "~/.mpd/pid"
state_file                     "~/.mpd/state"
sticker_file                   "~/.mpd/sticker.sql"

auto_update     "no"
#auto_update_depth "3"

audio_output {
        type            "alsa"
        name            "My ALSA Device"
        device          "hw:0,0"        # optional
        mixer_type      "software"      # optional
##      mixer_device    "default"       # optional
##      mixer_control   "PCM"           # optional
##      mixer_index     "0"             # optional
}

samplerate_converter            "Fastest Sinc Interpolator"
audio_buffer_size               "8192"
buffer_before_play              "20%"
audio_output_format             "192000:24:2"

filesystem_charset              "UTF-8"
id3v1_encoding                  "ISO-8859-1"

上記は一部で一例。各自で自分の環境やニーズに合わせて編集する必要がある。

tc@box:~$ mkdir .mpd
tc@box:~$ mkdir .mpd/playlists

.mpdconfのplaylist_directoryなどの設定に合わせて、.mpdディレクトリなどコマンドで作成。

mpdを起動しmpd clientでアクセスする。

sshからmpdコマンドで起動。最初の起動に際してはライブラリファイルがないと警告がでるけど無視していい。
好みのmpd clientでアクセスして、コントロール。

ざっとこんなところ。 mpdのインストール方法によって音の違いを比較しようかとも思ってたんだけど、そのうち、余裕があるときに。

現状のシステムは下の図の通り。

mpdを環境に最適化してインストールした方がいいという話があって、piCore7でできないか試みたけど未だ出来ていない。どこがまずいのか、boostがないとかエラーが帰ってくる。余裕があるときに、また試してみたいと思っているが何時になるかわからない。
piCoreは未だにmpdを簡単にインストールできるのはversion7だけみたいだ。
piCorePlayerのほうがtiny core系ラズパイ用音楽プレーヤーの本流だから、放置されてるということなのかもしれない。

ノイズ対策をいろいろやった結果と、fireface UCXをCCモードで使うようになって、随分様相が変わってしまった。
以前はUCXのCOAX(24/198)入力とiDSD LEのUSB(24/384)入力の音を比較したりしていたけど、UCXはCCモード(24/96)にすることで音質向上が著しく、価格差を反映した音質格差になったので、比較する気にもなれなくなってしまった。
どちらをメモリ再生に使ったらいいんだろうかとか考えたりしてたんだけど、USB-029H2-RPの恩恵なのか、NASマウントでの音質もかなり向上してしまったので、最近はもっぱらNASマウントで聴いている。本腰入れてNASとメモリ再生を比較したり、USB-029H2-RPを外してみるとかするべきなんだろうけど出来ていない。

piCore7には、NASのマウントポイントとメモリ再生用に使うディレクトリ、両方を起動時に作るように設定している。
以下メモ書き。
/opt/bootlocal.shに下記を記載。

mkdir /mnt/music
mkdir /mnt/music/nas
mkdir /mnt/music/ram
touch /mnt/music/ram/dummy.cue
chmod -R 777 /mnt/music

mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /mnt/music/nas

うちでは自動的にmpdを起動するとか洒落たことはせずに、sshでログインしてmpdを起動している。
以前は、NASをマウントするのもsshからコマンドを打っていたけど、この程、上記の記載で自動化した。起動プロセスが終了するまでの時間が数秒長くなるようだ。

スマートじゃないけど「ram」の下にdummy.cueを作ることで、mpdのライブラリ管理が簡単になる。
つまり、RAMメモリ再生とNAS再生が単一のpiCore7で簡単に切り替えができるようになる。

メモリ再生に際しては、sshからコマンドを打ってNASをアンマウントし、/mnt/music/ramに音楽ファイルを転送し「ram」のライブラリを再構築して使えばいい。

NAS再生に戻したければ、sshからコマンドを打ってNASを再マウントすれば滞りなく使える。
「nas」のライブラリは、NASに音源を追加した際にmpdでライブラリのアップデートをかけた後、sshからpiCore7にバックアップコマンドを送ってやればマイクロSDカードに保存され、piCore7再起動時には保存された状態で復活するように設定している。
mpdのライブラリアップデートは、昔に比べたらずいぶん速くなった気がする。
数千枚のファイルがあっても10分ぐらいで終わる。
あと、昔は下位ディレクトリ単位でのアップデートってできたっけ？ ファイルが少ないディレクトリのアップデートで済む場合（例えば、Beethovenのディレクトリだけアップデートするとか）は、一瞬〜数秒しかかからない。

最近はupnp/dlnaをシステムの中心に据えたシステムが一般的だと思う。
そもそも市販のネットワークプレーヤーがそうだし、upnp/dlnaを使用することで音質向上を追求するlinuxシステムもある。
upnpを避けてるわけではないんだけど、うちでは使うに使えない事情がある。
音楽ファイルのほとんどが、CD1枚まるごとをflac+cue sheetで保存したもので、upnpはcue sheetに対応していないということ。そういうファイルが数千枚あって、今更、それらを曲ごとのファイルに変換していく気にはとてもなれない。
結果、mpdとmpd clientという古典的システムで運用している。
そうせざるを得ないんだけど、十分に快適だ。
なのに、なんでmpd clientは減っているんだろうかと思う。淘汰されてるのかな。mpd clientに滅びられては困るのだ。切実に。

UCXの24/96でこのレベルなら384kHzでどうかとか、384kHz再生をiDSD LE単体で試してみるとか、MQAってどうなのかとか、デジタルオーディオはまだまだ面白そうなので、時間があれば取り組みたい。

今回は音源の話。
「赤い鳥」というのは昭和の時代に活躍していたフォークグループ。「翼をください」を作ったグループだ。
翼をくださいという曲はエヴァンゲリオンで使われたり中二病のテーマソングみたいな扱いを最近はされているようだが、僕が子供の頃にはそれこそ学校でコーラスで歌ったりして、それなりに思い入れがある曲だったりする。
でも、そんな赤い鳥をなぜこんなところで取り上げるのか。
そもそもはアマゾンのレビューから始まったのだ。以下、引用。

赤い鳥 コンプリート・コレクション （2003/2/19 発売）
https://www.amazon.co.jp/dp/B00007KKZB/

この素晴らしい音楽の遺産を、しかし台無しにしているのがマスタリングです。ここではお名前を出すのは控えますが、大きく音楽性を損なってしまうほどのお粗末なマスタリングに心底ガッカリしています。
試しにLPを取り出し比較視聴してみましたが、テイクが違うかと思うほどに赤い鳥の音楽は歪められています。
ソニー・ミュージックには猛省を望み、これだけの音楽に関わるにふさわしいエンジニアによってマスタリングし、あらためて発売をしていただきたいものです。

ここまで貶していながら、具体的にどのような音なのかは全く記載がないのだ。
どうなってるんだろうと思うじゃない？

赤い鳥については、オリジナルアルバムの音源入手が困難となっている。
というか、mp3やaacだったらアマゾンやアップルミュージックで買える。
CD音源となるとオリジナルアルバムの多くは上記のようなボックスじゃないと売っていない。中古CDは高額になっている。ハイレゾはない。

翼をくださいを作ったグループは他にどんな音楽をやっていたんだろう、オリジナルアルバムを買えないかなと思って、アマゾンに行ってみたところ、へえ、コンプリートボックスってあるんだ、と思ってレビューを読んだら音が悪いと。
赤い鳥といえばハーモニーを聞かせるグループだと思うので、音質に問題があるとしたら分かった上で買わないと嫌だし、どうなってるのか確かめたい。そこで、いくつか中古でCD発売された時期を変えて買えば、音質傾向をつかめるんじゃないだろうか、と考えた。
そこで初めて、オリジナルアルバムCDが入手困難だと知ったわけだ。

そのくせ、やたらとベスト盤は出ている。
あと、青春の何たら、みたいなコンピレーション盤。たいてい、翼をくださいが入っている。
つまり赤い鳥は、当時流行った数曲しかニーズがないのだ。というか、ニーズがないとレコード会社に思われている。まあ実際、アマゾンのレビューを見たらオリジナルアルバムなんて欲しがる人はそんなにいないんだろうなと思うけど、、、
音質なんか気にする特種な人種はコンプリート・コレクションを買えということになるのかな。mp3で気に入ったらコンプリート・コレクションを買えということかな。CD12枚で定価15,000円だ。1枚千円強ならむしろ日本では安い方だ。
そういえば、アルファレコードなのでベストが多いのか？と思ったり、、、

こんなところで比べるのもなんだけど、ここ数年、海外ではCD5枚で2000円前後のボックスがあれこれと出ている。
ありがたいことに、僕はLou Reedのオリジナルアルバムをこれでほとんど揃えた。Lou Reedのオリジナルアルバムは廉価盤ボックスでほとんど揃うのだ。これがなかったら、敢えて揃えようと思わなかっただろう。数枚重複したが、1万円以下で20作品以上全部を揃えられると考えたら大した問題ではない。ベルベットアンダーグラウンド以降の彼の軌跡を辿る日々が続いていたある日、訃報が届いた。
廉価盤ボックスの作品群を聴いてなかったら、僕はどんな思いで彼の訃報に接していただろう。

他にも、初期のFleetwood Mac、Fairport ConventionとSandy Denny、Weather Report、Eyeless in Gaza、Lynyrd Skynyrd、etc、、、そういう音源がなかったら積極的に触れることはなかったと思われるものに、次々に触れることができた。ロックやポップスだけではなく、ジャズやクラシックも最近入手するのはボックスが多い。こっちも昔なら考えられないような値段で買える。置き場の問題もあるので、そうそう買ってばかりではいられないんだけど。
そういう廉価商法が必ずしも偉いとは言わないけど、音源入手が容易になるのはユーザーにとってはありがたい。最初のうちは音質を不安視してたのだけど（実際、怪しい音源も売られている）、案外、手を掛けずに詰め込まれた音源は下手なリマスターをしてないので逆に良かったりするので侮れない。

実は僕はこの5、6年、新しいポップミュージックにほとんど触れないまま過ごしてきている。これは、震災後の僕の気分があるのかもしれない。なにしろ、旧いものを漁ってばかりいる。安価なボックスはそれを助長したかもしれない。

日本でもオリジナルアルバムの詰め合わせを3000円ぐらいで出せばいいのにと思う。それでもニーズがないかな？

さて、そんなこんなで入手したCD音源は以下の通り。括弧内は発売年。

• 竹田の子守唄 (2013)
• GOLDEN☆BEST/赤い鳥 翼をください~竹田の子守唄 (2009)
• 赤い鳥 (1998)
• パーティー (1995)
• 美しい星 (1995)

聴き比べたのは「翼をください」と他いくつかのベスト盤収録曲。
結論から言うと、20世紀の音源の方が音がいい。
2013年リリースの「竹田の子守唄」は音圧が高くて聴きづらくボーカルの繊細さは失われている。下記のソニーのサイトに行くと2013年リマスター音源と書いてある。
https://www.sonymusicshop.jp/m/item/itemShw.php?site=S&cd=MHCL000030033
まあ、この音源だったら、ハイレゾがあってもいらないな、mp3でいいかな。
赤い鳥 (1998)、パーティー、美しい星 (1995)は、聴きやすい音質だと思った。

GOLDEN☆BESTは、2013年リマスターよりは余程20世紀の音源に近い音源を使っている気がする。
収録曲「竹田の子守唄」だけ少し他と違うような気がしたんだけど、新しく追加された音源らしい。これはなんというか、2013年の音源の音圧を下げたような印象。でも20世紀音源の竹田の子守唄は聴けてないんだよね（音源の有無もはっきりしない）。
下記、ソニーのサイトの引用。

https://www.sonymusicshop.jp/m/item/itemShw.php?site=S&ima=0653&cd=MHCL000001571

※こちらは完全生産限定盤の通常商品です ※MHCL-127（2002/06/19 発売）に『竹田の子守唄 (アルバム・バージョン)』を収録し、『白い墓』未収録の新規編集盤

そこで、コンプリート・コレクションっていつリリースされたのかというと、2003年。
リマスターされてないとしたら、僕が新しい音源に比べたら音がいいと判断した20世紀の音源を、アマゾンのレビュアーは批判したことになる。

コンプリート・コレクションの音源は20世紀のものと同じなんだろうか。
もしかして、一番近いと思われるのは、2002年のGOLDEN☆BESTということになるのかな。同じソニーだし。

そんなこんなで追加入手したCD音源は以下の通り。括弧内は発売年。

• 赤い鳥ゴールデン☆ベスト (2002)
• Super Best of the Red Birds (1998)
• CD選書 ベスト「翼をください」 (1995)
• 赤い鳥 - ベストアルバム (1987)

聴き比べたのは「翼をください」だけなんだけど、やはり古い音源の方が音がいい。音色の響きがきれいで透明感がある。そのかわり音圧は低め。
98年のSuper Best of the Red Birdsでやや音圧が上がる。以降、音源が新しくなるにつれ少しずつざわざわした感触になっていく。2002年のゴールデン☆ベストになるとやや音色のテンションが上がり刺々しくなり、何か違うんじゃないかという印象を持つ。この音源は2009年のGOLDEN☆BESTと同等じゃないかと思う。
それを明らかに強く押し進めたのが2013年のリマスターオリジナル再発盤という感じ。

困った。ここまで違うとオリジナルアルバムが再発されても買う気になれないじゃないか。
というか圧縮音源でもいいってことかな。将来的にハイレゾで改善する期待も薄い印象だ。
コンプリート・コレクションの音質がゴールデン☆ベストと同等だとしたら、アマゾンのレビュアー氏の記述も、20世紀の音源から時系に沿って音質の変化を聴いたら納得させられるように思う。

赤い鳥に限らず、国内外問わず、リマスターが必ずしも音質改善につながらないという印象がある。
古い作品ばかり買っているからというのではないけど、最近の僕は20世紀にリリースされた中古CDを漁ることが増えてきた。音圧が高い最新リマスターよりも、安心できる音がする場合があるように思う（もちろん新しい音源の方がいい場合もあるだろうけど）。

おそらく、アナログマスターの状態が思わしくないような20世紀の作品は、ハイレゾファイルや新しいデジタルマスターを作るにあたっては20世紀のCDデータから作った方がいい場合もあるんじゃないだろうか。
もとのCD音源の音質とアップサンプリングの質に依存するとは思うけど、案外、素直な特性でハイレゾ化できる場合も多いと思うのだ。
ただそうなると、ユーザー側からハイレゾ音源として認められるかどうかという問題が出てくるだろうとは思うけど、だからといって、出自を曖昧にしたり誤魔化したりするようなことは絶対にして欲しくないとも思う。

赤い鳥のオリジナルアルバムの20世紀音源がリマスターなしに再発されたら買いたいけど、難しいだろうなあ、、、

以前のエントリーで僕はこんなことを書いた。

fireface UCXについて（2017.09.05.追記あり）
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170801a.htm

なるほど、Linuxはディストリ依存なのかな、、、
この時点で、CCモードは今はもういいかな、ということで終了（早っ！）。
本当はUCXを再起動してみるとかしないといけないんだろうけど、そのうち暇なときに試すことにする。

このとき、もっと本気でCCモードの音を確認していれば、、、、、、、

要するにfireface UCXのCCモードはCOAX入力よりも数段音が良かった、ということ。
24/96以上は受け付けないのでpiCore7のmpdもそういう設定なんだけど、384kHz入力のnano iDSD LEの数段上を行っている。
価格差でも当然？そのとおりだ。

先月はノイズ対策など細々いじっていたんだけど、一段落して余裕が出来たので思い立ってCCモードの音を確認した。
UCXのUSB端子にUSB-029H2-RPを介してRaspberry Pi2を接続。
これで前回は音が出たんだけど、今回は出ない。mpdは動いていて、mpdクライアントの指示も受けるけど、[paused]になって音が出ないのだ。
これは以前試した時、mpdの設定を切り替えた時にも、あったことだ。

前回はそこで止めてしまったんだけど、今回はCCモードを再起動してみた。UCXのノブを押したり回したり、手順さえ分かっていれば簡単だ。
そうしたら音が出るようになった。
なるほど、こうしたらいいんだね、、、
改めて音を聴いて、、、しまった、今迄なにしてたんだ自分は、と思わされたということ。

以前、UCXに複数のデジタル入力を繋いで音を出していたことがある。COAXとTOSに入力して、同時に音が出せるのだ。やろうと思えば更にUSBにMacやWindowsを継いで音を出すこともできるはず（そこまではしなかったけど）。
これは、けっこう面白かった。いちいちアンプのセレクタを切り替えなくてもいいのも便利。CDプレーヤーをUCXに繋いでおけば、子供にアンプのセレクタをいじらせることなくCDプレーヤーを使わせるだけで音を出す事ができる。
しかし、このやり方だと若干音質が悪化した。RMEでも負担が多い再生は避けた方がいいんだな、と思ったものだ。
さて、、、
今回、初めて気付いたんだけど、UCXはそのままではCCモードで使えない。RMEのサイトの解説（https://synthax.jp/cc.html）によると、CCモードは基本的に「iPadのために設定」されたモードで、CCモード専用のファームウェアで動く。だから、再起動して切り替えるのだ。
これは基本的にUSB入力の音声だけ受けて、COAXやTOSの入力には反応しなくなる。MIDIとかは使えるらしいけど。
機能を絞り込んだOSに替えるようなものだろうか、、、

専用のファームだよ？、、、、
それって、悪くないに決まってるんじゃないのか、と、今更、考えたり。今更、、、まあいいよ、気付かないままよりいいよ。

そんなこんなで、RAL-24192ut1とNANOCLOCKSはシステムから外れた。

以前は、生真面目な音はRMEの特徴でNANOCLOCKSをつなぐと若干硬さがほぐれると理解していたんだけど、CCモードにしたら以前感じていた硬さが霧散してしまった。ぼくがRMEの傾向と思っていたものは、全くの見当違いだったようだ。
外部クロックの有無で明確な変化は聴き分けられなかった。いや、プラセボレベルかもしれないけど、むしろ継がない方が、UCXの内部クロックにまかせたほうが、のびやかに聴こえる気がしたので外してしまった。

CD音源の16/44.1を、Ras Pi2側で24/96にアップサンプリングしたほうがいいかどうかは、まだ十分に見極めができていない。
今後、使いながら考えて行くつもり。

世間ではいろいろあるけど、うちのオーディオもあれこれと弄っている。そんなに大きな機材変更は無いんだけど、記録しておく。

まず、前回からの引き続きでLAN terminatorを自作してスイッチングハブに刺している。
参考にしたのは下記のサイト。

音がよくなるLAN端子用Xターミネーターとオープンピン
kanaimaru.com/NWA840/005.htm

47Ωの抵抗を1、2、3、6番端子の線(橙、橙/白、緑、緑/白)につなぎ、他の端をまとめる。
以下、写真。

以前、LANケーブルを自作しようとしてキットを購入していたので、LAN端子は余るほど手元にある。
ケーブルは、数10年前10数年前に使っていたものでシース外側の皮膜が破れて使えなくなっているようなものを切って使うことにした。銅線が固くて作業がしやすい。
4本だけ繋がっていればいいので、4本刺してモジュラー圧着工具で固めて、シースを剥いたところ。

4本刺さっていればいいのでシースの色違いがあったり。
1000BASE-Tの場合は8本全部をターミネイトする必要があるということで、写真のようにシースを剥いた。
実際、使っているのは100BASE-Tのスイッチングハブなので必要ないんだけど。

完成したらこんな感じ。透明の熱収縮チューブで絶縁している。

実際使ってみた感じ、確かに効いている感じだった。
いろんなことを同時並行でやっているのでこんな音源でこう変化したとか言えないんだけど、音の見通しが良くなる感じなのは今までデジタル再生で改善が見られたときの感触と同じように感じる。
ちなみに、FX08-miniの開いていたLANポート5つを全部埋める形で使っている。

次に、ラックを追加した。
うちではアングルフレームを使ってオーディオラックを組んでいるんだけど、これが手狭になってきたので。
いろんなケーブルがラックの中を縦横に走っていて、何か手を入れようにも、どこがどう繋がっているのか分からず、コンセント一つ抜くのにも一苦労する状態だったので、使いやすくなるように分けたのだ。
もっと早くしておけば良かった。

同時に、スピーカーをはじめコンポの位置を見直した。
全体的に右に寄せて、左側にあるピアノから離すことにした。といっても40cmほど移動したに過ぎないんだけど。
どれほどの変化が得られているかは確認できていない。

あと、USB029H2RPをこちらのサイトから購入した。

USBアイソレータ USB-029H2-RP | セレクトアイテム | JS PC Audio オンラインショップ
http://www.shop-jspcaudio.net/shopdetail/000000000096/

USB伝送に際してGalvanic isolationを行うらしい。
難しいことはよく分からないので省略。

とりあえず繋いでみて聴いていたらプチ、プチとノイズが乗る。
音はいいんだけどどうしたものかと確認していったところ、アースの設定によって安定性が違ってくる事が分かった。

これはメーカーのサイトから引用する写真なんだけど、SW1(1, 2)、SW2の設定によって、アースの状態を変えることが出きるようになっている。
当初はSW1(1)、SW2をON、SW1(2)をOFFで聴いた。上流、下流でアースを分離できるというので、どういうもんだろうと思ったのだ。ノイズが乗るのでSW1(2)をONにして、一時はノイズが消えたかと思った。ただ、なんだか音は普通になってしまった。
こんなものかな、と思っていたら、またノイズ。
USB029H2RPを外したら、普通に音が出ている。
こりゃ失敗した買い物だったかなと思いながら、USB029H2RPの電源アダプターをタップから外したら、ふっと音が軽くなった気がした。使っていない電源アダプターを外すだけでも音って変わるんだね、、、

さて、そこで上の写真を見ていて気づいたのは、電源アダプターのGNDが、USB029H2RP本体、さらに上流下流の機器のGNDと繋がっている、ということ。SW1(1)をOFFにしたら、これを切ることができる。SW2ははっきりしないけど、電源ラインに関係あるようだから切ろうかな、、、
SW1(1)、SW2をOFF、SW1(2)をONに。
うちではこれでノイズがなくなった。音質への効果は大きい。付けたら外せないと思う。

そんなこんなで、コンポの状況はこんな感じ。
以前、描き忘れていたものも描き加えている。

どうも、腑に落ちないこと、驚くことが多い昨今だ。

９月中旬、なんだか最近、音が悪いということでチェックしてみたら、５ｍのLANケーブルがハブに刺しっぱなしになっていた。
数日前にPCを継いで作業して、PC側だけ抜いて忘れていた。
このケーブルをハブから抜いたら、音も改善した。
LANケーブルはノイズを拾うアンテナになるとどこかで聞いた事があるけど、なるほどこういうことがあるのかと思った。

同じ頃、これもイーサネットハブの案件で、FX08-miniの電力供給をUSBバスパワーからでも出来るというので、付属のACアダプターを安いUSBハブ（USB-HSM410W、各ポートにスイッチ付き）に付け替えてみたところ明らかに音が悪化し、あわてて元に戻すということもあった。
ハブの電源管理もおろそかには出来ないと改めて感じた。

そういうわけで最近、ノイズ対策関係でいくつか試みている。
あんまり取り止めがないのは問題だけど、あれこれ手を出している状況だ。

昨年２月に、どこで良いと聞いたのか忘れたけど八光電機製作所のDMJ-100BTを入手して、ルーターのノイズが大きいということをどこかで読んだり、ネットブラウザの挙動の影響が大きいという自分なりの経験から、オーディオ機器とそれ以外を分けるところに組み込んでいた。
製品サイトへのリンクと画像引用。

http://www.hachiko-denki.co.jp/html/product_09.html

当時、どこに使うのがいいか比較したかどうかは、記憶にない。
これをnano iDSD LEのトラポに使っているRas pi2の直前に付け替えたら、随分いい方向に音が変わってしまった。
こっちのほうが効くということは、オーディオ周りのLANもノイズが多いということだ。
NASとかRas piはそもそもノイズ源だから、当たり前かも。

そこで問題なのは、良いほうに変わってしまったnano iDSD LEと、fireface UCXの音が、違いすぎるのだ。
例えば、Steely Danのアルバム、Ajaの１曲目、Black Cow。曲が始まって程なくしてベースの低音に合わせて他の弦？の音が聞こえるんだけど（これは何だ？と思って調べたけど、クラヴィネットらしい）、これがLEだと分離して聴こえて、UCXだとほぼ一体化して聴こえる。どちらが正しいのか分からないけど、LEのほうがいい気がする。

話は変わるが、うちでは半年前にピアノを搬入して以降、ステレオ定位がかなりおかしくなっている。
なにしろスピーカーの左外側にアップライトピアノがあるのだ。
当初は、思ったほど問題ないじゃないか、と思って安心していたんだけど、その後、リスニングポイントを移動すると異次元な音場再生になることに気がついて、これは大きな課題なんだけど、手を付けられないままになっている。
普段聴いてる場所だったら、意外にも大した影響がないんだけど、それでもときどき、本来と違うあらぬところに音像が移動していたりする。前述のBlack Cowのクラヴィネットも、イヤホンで聴くのと若干違う鳴り方をする。このまま済ませていていいもんじゃないんだけど、どこにスピーカーを移動したものか、難しいんだよね。。。

とりあえず、DMJ-100BTを追加注文した。
LANケーブルのノイズ管理はよく分からないので、まずは製品頼りだ。
メモリ再生だから大して関係ないだろうと思っていたUCX側のトラポRas pi2に繋いだら、思わず笑うぐらい良くなった。
一体化して聴こえていたBlack Cowのベースとクラヴィネットが分離して聴こえるようになったし、クラシックとかもいい感じ。

しかし、やはり再生音はLEとUCXでかなり違う。
UCXのほうがクリアでゴージャスな鳴り方に聞こえる。LEはスマートでさりげないと言えばいいけど線が細くて比べると情報量が少ない。UCXのほうが緻密にも関わらず見通しが良く、なんだか、かなり良くなった。
なんということだろう。
以前よりもDACによる音の違いが大きくなった。

他に、LAN周りについては下記のサイトを参考にLANターミネーターを作ろうと思ったけど、できていない。

音がよくなるLAN端子用Xターミネーターとオープンピン
kanaimaru.com/NWA840/005.htm

一方、LAN対策と平行してUSB周りで何か出来ないかを考えていた。

Ras pi2には４つのUSB端子があって、USB DACに信号やバスパワーを出力する。実はmicro USB端子とも電気的に繋がっていて、USB端子からRas pi2自体への電力供給もやろうと思えば出来たりするらしい。
ここはノイズ対策したほうがいいだろうということで、自作の簡易フィルターを咬ませてみた。
バスパワーのラインとGND間をキャパシタで継ぐ。容量は0.22μF。-3dBのローパスフィルターということかな、、
信号ラインへのノイズ対策は電源ラインの安定化を通じて間接的に、ということになる。4つあるUSB端子のうち、どれでもいいから使っていない端子に刺せばフィルターとして機能するだろうという考えだ。

参考サイト。

PCで音楽: ブラックマター USBフィルター
http://asoyaji.blogspot.jp/2014/04/usb.html

BP5を使ったUSBケーブルDCフィルター : 新大陸への誘い
http://tackbon.ldblog.jp/archives/52344589.html

参考サイトではコンデンサーは1μFを2つ使ってるしコイルも多いしかなり効きそうだ。うちのは偶々手元にあるのを継げただけで試行錯誤もしていないし貧相なのでこういうとこに出すのは恥ずかしい。でもまあ、そうも言ってられないので写真まで載せてみた。

効果はというと、ないよりあるほうがいいかな。
DMJ-100BTが刺したらすぐに変化が見えるのに対して、こっちのほうは時間がかかる感じ。
刺してから良くなるのにも、外してから悪くなるのにも時間がかかるようだ。
僕の生活パターンでは、数十分以上続けてオーディオを鳴らして変化を確認することがなかなか出来ないので、次の日に音を聞いて変化を確かめるという感じになる。だから、あるほうがいいような気がする、という感じだ。

11月21日、追記。
コンデンサーだけじゃなくて抵抗も使ったらUSB端子をターミネートできるということを今更知った。ネットで検索したら、けっこうあちこちで自作されて使われてるんだね、、、
ターミネートするということなら、1個だけじゃなくて空いてる3つの端子全てに刺すべきだよね、、、
そういうわけで、自作して残ってる端子を埋めてみた。
使っている抵抗は100Ω。
最初に作ったフィルターにも100Ωを追加した。
コンデンサーは余ってるのを使う。残ってる0.22μFだけじゃ足りなくなったので0.68μFも使っている。
シールドとかしてないのでいかがなものかと思うけど、まあいいか。

音は、若干きめ細かく柔らかになるかな。良くも悪くも落ち着いて聴きやすい感じになっている。
コンデンサー1本だけだった時よりも効果は大きいみたいだ。

こういうことをやっているうちに、以前気になっていたアップサンプリング周波数はどの程度必要なのかとか、そういうことは置き去りになってしまっている。
ノイズや電源をある程度以上対策しないと、機械が本領発揮してくれない。そんな状態での比較は難しい。
あと、もっと条件を整えた上で比較した上で考え直さないといけない感じだ。192kHzと384kHzの差異は、ここに来てDACの違いに覆い隠されてしまった。やり方を変えて考え直さないといけないと思っている。

最近、CD音源をリッピングしたflacを384kHzにアップサンプリングして再生している。
そうこうするうちに、上限が192kHzのfireface UCXの立ち位置が微妙なことになってきた。たしかにいい音が出るんだけど、どこか、入り込めない音がする。客観的に聴きたい時は、これ以上はない最適という感じ。しかし音楽に没入しにくいのは、良し悪しだ。

しかし考えてみたら、繋いで音が出るように簡単な設定をしただけで今まで使ってきている。
使いこなしてるとは言えないのだ。
300kHz以上での再生と比べて云々とか考えるには、少なくとも自分なりに納得できる程度まで、fireface UCXの能力を確認しておかないとまずいんじゃないかと改めて考え始めたということだ。

まずCCモードを試す。
RMEの説明はこちら。引用。

Fireface UCX クラス・コンプライアント・モード - Synthax Japan Inc
https://synthax.jp/cc.html
理論上はLinuxでも十分に動作するはずですが、検証がなされておらず、個々のディストリビューションに依存するでしょう。しかしながら、RMEではWindowsとMac OS Xの双方に最適化された専用デバイス・ドライバを用意しており、専用デバイス・ドライバを用いることで超低レイテンシーな動作を可能とし、クラス・コンプライアント・モードはWindowsとMac OS Xのどちらにも適切ではありません。

Ras pi2、piCore7、mpd、libsamplerateのusb出力をUCXで受けてみる。
結果、ちゃんと音が出た。
ただ、mpd.confは192kHzにアップサンプリングの設定だけど、96kHzで出力されている。何がどう作用してそうなっているのかは、はっきりしない。CCモードの上限が96kHzなんだろうか。
逆にアップサンプリングなしの設定にしたら、何故かちゃんと再生しない。ぶちぶち途切れる。なんだ、ちゃんと音が出ないじゃないか。

なるほど、Linuxはディストリ依存なのかな、、、
この時点で、CCモードは今はもういいかな、ということで終了（早っ！）。
本当はUCXを再起動してみるとかしないといけないんだろうけど、そのうち暇なときに試すことにする。

COAX入力に戻す。
次の懸案はクロックだ。今更感が相当あるけど、しかたがない。
今まで、効果の程ははっきりしないと言いながら、中古のRosendahl NanoclocksからWordクロックを入力して使ってきたんだけど。
改めてもう少し弄ってみようと。

うちではUCXの設定は、windows7マシンとusb接続して「Settingダイアログ」というソフトから行うようになっている。
これの「Input Status」の項目、「Word」と「SPDIF」の表示。
「Word」は外部クロック入力。「SPDIF」はRAL-24192ut1からの入力。

「SPDIF」のほうが、SyncとLockの表示が切り替わるのを繰り返している。
Syncは同期、Lockは有効だ。ちなみにNo Lockだと無効。
SyncとLockを繰り返しって、同期できたり、できなかったりということかな、、、
それでも問題なく音は出ている。
はたしてどうなんだろう、、、

今回、改めて確認していったところ、外部クロックが176.4kHzだと、Lockが出る頻度が少なくなる。
今まで192kHzの設定で使って、他の設定はあまり顧みずに来て、こんなものだろうと思ったまま気付かなかったわけだ。
マニュアルはあんまり詳しくない。多分初歩的過ぎて説明していないのだと思う。
RMEのサイトには、Lock表示には注意を、とあるんだけど、、、
引用する。

Fireface Settingsを理解する
http://audio.synthax.jp/guide/chapter3/firefacesettings/
特に、この表示が「Lock」の場合は要注意です。サンプルレートは合っているため音自体は入力されますが、ワードクロックが同期していないのでブツブツといったノイズが発生することがあります。

これはUCX導入当時に読んだには読んだんだけど、解決策が無かったし、再生音にノイズはなく音質も充分だと思ったので、まあいいか、となっていた。
ここには、SPDIF入力を使う場合は、そのクロックを使えとも書いている。
しかし、結局、なんとなくRosendahlを繋いで、今まで来たんだよね、、、

Ras piのクロックは２重で変動するという記事がある。引用する。

Volumio　でジッターを無理やりなくしてみる - ほーりーさんの日記
http://horliy.seri.gr.jp/mt/horliy-blog/2015/02/volumio-1.html
BCM2835 のクロック生成回路は、単位時間内のクロックパルスのうち、いくつかの長さを短くすることで、単位時間当たりのクロック数を正確にする。という機能をもっています。
つまり、クロック幅の正確さを犠牲にすることで、周波数の正確さを獲てるわけですね。オシロでみたクロックの波形が2重になって見えるのは、その短くなったクロックを観測してしまっているため。

これが関係しているのかな。
上流のRas pi2のクロックが変動するから、RAL-24192ut1のCOAXのクロックが影響を受けるんだろうか。
記事を引用しておいて今更だけど、上記の記事はRaspberry pi B+でVolumioを使う場合の記事。
Ras pi B+はBCM2835だけど、うちで使っているのはRas pi2で、SoCは、BCM2836かBCM2837だ。クロック周りの問題の程度も違っている可能性はあるけど、pi2では改善したという話も寡聞にして聞かないし、どうなんだろうかね。

何で192kHzと176.4kHzでLockの頻度が変わるのかは分からない。
というか、これっていっそLockに固定されている方がいいのか、多少でもSyncが多い方がいいのかすら、分からない。
データ自体はマスタークロックに沿って処理されるので関係ない、で、いいのかね。

外部クロックのケーブルを外して、UCXのinternal clockに切り替えてみる。
当然、「Word」はNo Lockになる。
192kHz入力の「SPDIF」でSyncとLockを繰り返すのは変わらず。internalで176.4kHzだと、Lock表示の頻度は減らない。
どういうことだろ？
UCXのinternal clockよりもRosendahlのクロックのほうが、RAL-24192ut1に近いということ？
音はRosendahlよりinternal clockのほうが、ちょっと固いような気がする。

RAL-24192ut1のSPDIFをマスターにしてみたらどうか。
ちょっと、薄いような気がする。
なんやかんやで、Rosendahlのクロックをマスターにしたのが、まろやかに深く鳴る気がする。気がする、プラセボかな、で今まで来ているんだよね、、、

今までの記述は、Ras pi2（piCore7, mpd, libsamplerate）からのusb出力をRATOC RAL-24192ut1でDDコンバートしてCOAXでUCXに送っている場合。 i2sボードからCOAXに出力するという方法もある。
外していたhifibery Digi+を戻して使ってみる。ディストリはpiCore7で同じ。

マスタークロックはRosendahlを選ぶ。「SPDIF」はLockのままだ。Sync表示が出ない。
RAL-24192ut1経由と比べたら、ちょっと音が固いかな、、、

hifibery Digi+からのクロックをマスターにしてみる。実は今までに試してどうだったか記憶がない。
良くないクロックだという先入観があって、試してないかもしれない。
試してみたらSyncで固定した。
意外w。
でもまあ、SyncとLockを繰り返すRAL-24192ut1のクロックでもマスター指定したらSyncするんだから、意外でも何でもないか。
音は乾いた感じでそっけない。
Ras piのクロックってひどいのかな？と思う割には、そんなに悪くはないんだけど。
Ras pi B+とpi2の比較は試していないので、どれぐらい差があるのかはわからない。

マスターをinternal clockに切り替えたら、音に少し潤いが乗ってくる。Rosendahlに切り替えたら、さらに潤いが増す感じ。

プラセボだよとかブラインドで区別つかないだろうと言われたら言い返せないけど、Rosendahlを繋いでRAL-24192ut1を通した方が音がいいような気がする。
気付くか気付かないかの僅かな差だけど、何となく違う感じで、効いていると思う。
176.4kHzと192kHz、どっちが優位かの区別は付けられなかった。

もしかしたら、良質なクロックが乗ったSPDIF入力を使うほうがUCXは本領を発揮できるのかもしれない。
リクロックできるDDCを使ってはどうかということになるのかな。しかし、これだけのために新たなDDCを導入するというのも、そもそも上手くいくかどうかやってみないと分からないし、意味があるのかどうかも判然としないので躊躇する。

NAS音源同士で、Moode Audio 384kHzでi2s DACに出力した音と、piCore7 176.4kHz/192kHzでUCXに出力した音を比較してみる。
ほとんど区別がつかない。敢えて言うなら、わずかに前者の方が若干元気で、後者は大人しい。

現在、うちではプリメインアンプの上流をどうするかという課題に直面している。限られたアナログ入力を何で分け合うかという選択をしないといけない。
今まで、UCXはメモリ再生の下流を受け持ってきた。
これと、ifi nano iDSD LEのメモリ再生を比べる必要がある。
NASマウント音源だと、nano iDSD LEはi2s DACボードを越えられないと分かっている。使うならメモリ再生で、UCXと競合する。
前々回のエントリーで、nano iDSD LEをUCXと同等以上と書いたんだけど、、、

試聴。
使った音源は、Hilary Hahn の Barber & Meyer Violin Concertos、Joni Mitchell の Blue（20P2-2119）。
クロックはRosendahl。
結果。
メモリ再生で比較したら、僅かにUCXのほうが上だ。繊細な表現の部分で僅差だけどいい音が出ている。
前々回のエントリーのときは第一印象が強すぎて、聴き誤ったみたい。
ある意味、ほっとしたような残念なような。
しかし、音源やＴＰＯによってはnano iDSD LEのほうが生きる場合もあるかも。
順位をつけてみる。

１）　UCX　RATOC　メモリ再生　176.4kHz/192kHz
２）　nano iDSD LE　メモリ再生　384kHz
３）　UCX　RATOC　NAS　176.4kHz/192kHz、　i2s DAC　NAS　384kHz
４）　nano iDSD LE　NAS　384kHz
５）　UCX　i2s DDC　NAS　176.4kHz/192kHz

こんな感じだろうか。
そういうことなら、現状では今までどおりUCXをメモリ再生に、i2s DACをNASマウント再生に使うということで良さそうだ。

現在のオーディオシステムについて記録。前回が11月なので半年以上たっている。

前回、LibreOfficeのドロー機能で作った図はHDDが飛ぶのと同時に消えたので、また作り直した。
今度こそ１回作っておけばあとは楽だろう。

変化したところを見ていく。
まず、タコ足配線のテーブルタップに「filter」が刺さっている。
これはAC100Vにも刺さっていて、コンデンサーを使った自作ノイズフィルターといったところ。

参考にしたのは以下のリンク。
VGP2007SUMMERを受賞した電源ノイズリダクション製品「Noise Harvester」を福田雅光氏が体験
http://www.phileweb.com/news/audio/200706/22/7306.html
画像
http://www.phileweb.com/news/audio/image.php?id=7306&row=2

Noise Harvesterは簡単な回路図が公開されていて、どうやらコンデンサーだけで効かしてるらしい。
他にはこれも参考にした。

のんとろっぽ　audio TIPs　まずは、安井式電源フィルターのお話
http://nontroppo2010.web.fc2.com/etc_tips.htm

安井式電源フィルターはコンデンサ、コイル、抵抗による簡単なフィルター。
これらの記事を参考に、簡単すぎて恥ずかしいようなものをタップと壁コンセントに刺している。

しかし、これが意外なほどの音質改善効果があった。
特に効いたのは、SM-SX100のCOAX入力。つまりCDプレーヤーDP-5090の音が大きく改善したのだ。昔からSM-SX100のデジタル入力はよくないと言われていたんだけど、これなら充分使えるという感じになった。
今は子供が主に使っているんだけど、傍から聴いていて良くなったのがはっきり分かった。

あと、FX08-miniの配置が多少変わっている。直列じゃなく並列なのはあちこちに動かしているうちに結果としてこうなったから。図のA/Dの丸いマークはACアダプターを表している。
２つのFX08-miniは、かたや以前からある装置に、かたや新規のDAC、ifi nano iDSD LEに繋がっていく。

さて、一応メインのデジタルトラポはRaspberry Pi2が3つ。全部、mpdが動いている。そのうち2つが「384/24」にアップサンプリングの設定。
半年前は192kHzだったので倍になった。
Hifiberry Digi+はお蔵入りに。
192kHzのPi2はfireface UCXに繋がっている。それがUCXの上限だからだ。

Moode AudioにlibsamplerateをインストールしCD音源を384kHz出力にアップサンプリングしてi2s DACで聴き始めてから、こっちの方向性で動いている。
なにしろCD音源から簡単に高音質が得られる。
天上のオルガンのような300kHz以上のハイレゾ音源には及ばないけど、かなり迫ることが出来る。
僕はCD音源が多いので助かるのだ。

nano iDSD LEは安いDACで取り急ぎ実験に必要ということで購入したけど、最近のDACの進歩はとても速いと感じさせられた。今後、上流をどう組んでいくか考えないといけない。

192kHzのfireface UCXと、384kHzのnano iDSD LE、両者の比較は出来ていない。
まあ、そのうちしようと思うけど、ともにメモリ再生なので、手軽に聴けるMoode + i2sDACに使用機会を奪われている。
この2台はRCAケーブルのbasis1.4を分け合っていて、どちらかを使用するときにはケーブルを継ぎかえるようになっている。アンプのRCA入力端子2組のうち１組が使えないので、そういう使い方になっている。

書き忘れていたけど、piCore7はメモリ再生でusb出力。Moode AudioはNASマウントでi2s出力で使用している。
NASの手軽さでメモリ再生の音が出たら本当にありがたいんだけど。

あとは、VRDS-25xsが外れた。トレイが動かなくなった。物置にしまってあって、修理したいと思ってるけど手が回らない。どうやって修理するのか調べるところからやらないといけない。
正直、復帰は難しいかなと思うけど、捨てる気にはなれないので当分はしまっておくつもり。
長いことありがとう、お疲れさまという感じ。

最近は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のほうが僕の嗜好に合うようだ。

今回、ここまで。

個人的メモのエントリー。
趣味でオーディオをしていると、これはどうしたらいいだろうと思うことが出てくるのだけど、時間は無限ではないので課題が蓄積してくる。そして気がつくと忘れているのだ。ツイッターにメモしたりしてるけど、あれって流れていくので遡るのが面倒。
だから、ここに書いておくことに。
書いただけで、余力がない課題は放置になるかもしれないけど。

１：アップサンプリングと自作ハイレゾの比較

以前、CDをリッピングした音源からTASCAMのHi-Res Editorを使って192/24の音源を作成し、元の音源と比較するということをしたことがあってエントリーに上げている。
Ras-Pi2 + piCore + mpd によるメモリ再生で、192/24の音源のほうがいいという結論だった。
これ以降、うちではリッピングした44.1/16の音源をmpd + libsamplerate で192/24にアップサンプリング（リサンプリング）して聴くようになったんだけど、これと192/24の音源ファイルを比較したらどうなのか、というのが出来ていない。

音が違ったとしても全く不思議じゃないだろうし、どう違うか何時か確認してみたいところではあるけど。

２：アップサンプリング（リサンプリング）ファイルの比較

前述のとおり以前、CDをリッピングした音源からTASCAMのHi-Res Editorを使って192/24の音源を作成したのだけど、設定を変えて作成したらどうなるのか。或いは他のソフトだとどうなのか。
Hi-Res Editorの場合、どういったアルゴリズムとかでアップサンプリングしているのかよく分からない。しっかり調べたら分かるのかもしれないが、出来ていないのだ。業務用機器を扱ってるメーカーなので、悪くはないだろうと思うのだけど。
他のソフトを入手しないといけないし、いつになるか分からない。

３：Moode Audio NAS音源で384/24の音と、piCore メモリ再生で192/24の音

うちでは、mpd + libsamplerate によるアップサンプリングを日常的に使用している。
ひとつは、Ras-Pi2 + piCore + mpd によるメモリ再生。
もうひとつ、最近使っているのが、Ras-Pi2 + Moode Audio + i2s DAC によるNAS音源再生だ。

Moode Audioを使うようになったのは、384/24でi2sDACに出力できると知ったから。
少々苦労した記憶があるが、libsamplerate をインストールして使っている。
topコマンドでCPUの数値が100%強。クアッドコアCPUだから100を超える数値が出る。

これは、なかなか侮れない音がする。
なにしろ、かなり音量を上げていても、家族がうるさいと言うことがめっきり減った。比較対象は普段使いだったVolumio1.55で192/24なのだけど、これで鳴らしていると音量を上げたらうるさいと言われることが多かった。音量上げてるんだから当たり前だけど。それが、Moodeで384/24にしてから、なんでか減っている。
気を使われているだけかもしれないけど。

384/24のi2sDACの音は聴き疲れせず聴いていられるし、違和感がない気がする。
これだけ良ければ、他のディストリもそのうちi2s出力で384kHzに対応するのではないかと期待しているんだけど、どうだろう。Raspbianでカーネルやalsaをいじって何とか384kHz出力する方法がないかと調べてみたりしたけど、僕にはスキルが足りなすぎる。

そういう状況なわけだが、Moode AudioのNAS音源で384/24の音と、piCoreのメモリ再生で192/24の音を比較したいんだけど、出来ていない。
piCoreの出力はUSBからDDC、Fireface UCXなので単純に比較はできないけど。
じゃあ、Moode Audio + i2sDAC でメモリ再生できないだろうか、というのも置きっ放しの課題。

この課題は、現在のうちのシステムで音質が最高なのはどの方法なのかを確認することになると思っている。

４：384kHz/24bitの音について、SoXとlibsamplerateの比較

ということで、Moode Audioで384kHzをi2sDACに出力している。もともとSoXが入っていて、libsamplerateを追加している。
過去のエントリーに書いたけど、piCore で192kHzにアップサンプリングする場合は libsamplerate のほうが自分の好みに合う音がするということだった。
Moodeで384kHzでは違いがあるのか。
既に違いはありそうだという印象があるんだけど、確かめるまではしていない。

５：DietPi

DietPi というディストリがあって、i2s 384 kHz/32bit に対応してるという話がある。
以下、参考サイト。
https://zigsow.jp/item/322840/review/320971
http://dietpi.com/phpbb/viewtopic.php?f=9&t=900&p=4073

うちのRas Pi2で動かすとこまでは行ったんだけど、ncmpcppがつながらないというところで止まっている。
既にMoodeで聴いていて緊急性がないので、いつになるやら分からない。

とりあえず、こんなところかな。細かいとこ言い出したらきりがないけど。

今回は音源の話。
フィッシュマンズのデビューアルバム「Chappie, Don't Cry」は1991年にメディアレモラスからリリースされた。
当時、僕はこれを買ったのだけど、その価値にあまり気付いていなかった。オーディオ的には、むしろショボいと思っていた。
今にして思えば入手当時は、このCDのポテンシャルを引き出すに充分な再生環境ではなかった。
所謂ミニコンポで、スピーカーのセッティングの工夫とか何やら初歩的な細工をしながら聴いていたと思う。

その後、オーディオ環境は変遷し歳月は流れ、このCDの録音の良さに気付いたのは多分、2005年頃を過ぎてからのことだ。というのは「空中」「宇宙」というベスト盤がリリースされたちょうどその頃から、またフィッシュマンズを聴き始めていたから。
2005年頃には、現在のコンポに近い構成だ。上流がVRDS-25xsとOdeon-Liteでアンプとスピーカーは同じである。このサイトの過去記事を読み返してみたら、この頃にAirMacExpressを使ったPCオーディオも始めている。
そうこうする中で、何の気なしに聴いていて気がついたのだろうと思う。

この作品からは、J-Popらしからぬ生々しい音声が聴ける。
その音質は、少なくとも高音質の洋楽作品と同等レベル以上と思っている（ファンの欲目は、ないと思うけど、どうだろう）。
でも、このCDが高音質だという話は、僕は自分のサイトとamazonの僕のレビュー以外では見たことがない。どういうことだろうと思うことがあるんだけど。
おそらくは真価を引き出す再生が難しいのだ。
どんな音なのかというと、自然な録音だ。
高い声で歌う２０代男性の生の声がありのままに聞こえてくる。曲によってはわずかにリバーブ処理がかかっているが、かけてないんじゃないかなという曲も多く、生々しい。楽器の音もそんな感じだ。

洋楽で高音質といえば、Walter Beckerの「Circus Money」が思い浮かぶんだけど、楽器や声の音声が、粒立ちがいいというのか、くっきりと聞こえてくる。21世紀の高音質という感じ。たぶんミニコンポでもそこそこしっかり鳴るように配慮されている。スタジオでの加工は前提だし、それがあってこその高音質という感じ。
対して「Chappie, Don't Cry」のレモラス盤はというと、ちょい聴きすっきりしない。粒立ちもいいようには聴こえない。くぐもって聞こえる。なにしろ最近のCDと比べると録音レベルが低いのだ。じゃあ音量を上げたらいいのかというと、たぶん再生能力が低いコンポでは大きな印象の変化はないだろう。
しかしコンポの性能が上がってきたら、前述したような生々しさが顕わになってくる。飾りがない、まさにそこで歌っているようなニュアンスの歌声が立ち現れてくる。極端な言い方になるけど、ポップミュージックのスタジオ録音なのにフィールドレコーディングした民謡のような佇まいの歌声だと思う。楽器の音もそんな感じだ。

昨年にリマスターされて再発になったと、遅まきながら知るに及ぶ。
以下、参考サイトのアドレス。

http://mora.jp/topics/interview/fishmans-hires/
フィッシュマンズハイレゾ化記念　リマスタリングエンジニアに訊く　Posted on 2016年10月19日 mora.jp
http://ototoy.jp/feature/2016022400/1/
クラムボン、過去13作品DSD配信開始──名マスタリング・エンジニア、木村健太郎に訊く"良い音"とは OTOTOY

なんというか、エンジニア氏の悩みどころが垣間見れるインタビューだ。
あんまり音圧を上げると音が変わるけど、配慮せざるを得ない部分もある、、、
どうなったのか気になり始めた。
初期レモラス盤（とおそらく同等のポニーキャニオン盤）は今後なくなっていくだろうし、今後の流通は今回のリマスター音源が中心になっていくだろうから、、。

CDを購入して比較した。
僕の印象では、21世紀のスタジオから生まれた音になっている。エンジニア氏が言うように環境に左右されない、聴き手に届きやすい音になっていると思う。音圧は上がってるけど、それでも出来るだけオリジナルの音を生かそうとした結果が見えるように思う。うちのシステムでも強く、くっきりした音を聴くことが出来た。
その分、レモラス盤で聴くことが出来た生々しさは、ごく僅かに後退している。フィールドレコーディングの音からスタジオの音になったという感じ。つまり、J-Popらしからぬ生々しい音声から、J-Popとしてはかなり高音質な作品になった、と思う。一般的なオーディオシステムでも扱いやすいだろう。一番変化を感じる曲が「夏の思い出」。もともと全体的にぼんやりした音像（わざとだとおもうけど、あまりその意図が成功しているとは言い難い気が正直していた）だったのが、くっきりした。佐藤伸治の声もクリアに。これは、はっきりと聴きやすくなった。
この曲以外は、基本的に原曲の良さが生かされているリミックスだと感じた。

ハイレゾは、今回は買っていない。
いずれ買うとしたら後期のほうだろう。アルバム単位じゃなく曲単位からかな。
今回の「Chappie, Don't Cry」リマスターは僕は良かったと思った。

自分だけが高音質だと思う音源といって他に思い当たるのは、The Whoの「四重人格（Quadrophenia）」だ。

この作品、1985年にCD化されたんだけど、僕自身が入手したのはずっとあとのことだ。どこを探してもなかったからだ。
最初に入手したのはサントラのアナログ盤で、これじゃない感が漂うものだった。
ようやく入手した日本盤CDはしかし、聴いて「しょぼいなあ」と思った。納得がいかなくて輸入盤も買ったが同じ音でがっかりしたものだ。両方とも今だに所持しているけど。ちゃんとハイファイに鳴らしたら目眩くばかりの音像空間が広がると気付いたのは、これも今のアンプとスピーカーになってのことだ。スーパーツイーターを付けた頃じゃなかったかな。
このCDも、僕以外の人が音がいいといってるのを聞いたことがない。どういうことだろうかと思うことがある。

この作品は1996年リミックスされた。それが2011年にリマスターされたCDがデラックスエディションとしてリリースされて、僕はこれも入手している。
リミックスの時かららしいんだけど、ボーカルのロジャーダルトリーの声がかなり大きくなっている。楽器の音も全体的に強い音になって、要は小さいコンポでもロックっぽく鳴るようになった。
僕は「四重人格」というのは、嵐のような楽音の中で吹き飛ばされそうなほど小さいのに揺らがずに聴こえてくるジミーの声があってこそ、音楽世界が成り立つと感じている。そういう鳴り方を聴いていると、その世界にはまり込んでしまいそうな感じなのだ。初期CD音源をしっかりしたコンポで鳴らすとそんな鳴り方をする。

ジミーの声が大きくて、押しても引いても倒れないような聴こえ方をすると、これは世界が違うんじゃないかと感じてしまう。しかし、そういう音のほうが小さいコンポで聞いたときには盛り上がるんだろうと思う。
健気なジミーの声が聴こえたら感動するけど、聴こえないんじゃしょうがない。
実際、mp3にしてカーステレオで聴いたらデラックスエディションも悪くない。

参考サイトのアドレス。
http://www.e-onkyo.com/news/231/
GREAT3片寄明人の「ハイレゾ・コラム」 第5回 The Who 『四重人格』（後編）2014/11/21

だらだら書いてきて、何が言いたいのか分からないけど、音源って難しいなと思う。
売るとなれば、再生環境に配慮しないわけにはいかない。
ハイファイ用ミックスとポータブル用ミックスの両方を売るとか、いっそ抱き合わせて売るとかしていいんじゃないかとか、とりとめなく考える。
音源が良くないとオーディオという趣味は成り立たないのだけど。

前回、mpdをhttpサーバーにしてflacをストリーミングするというエントリーを上げた。
vlcかmplayerじゃないと聴けないみたいと書いたんだけど、mpdでストリーミングを受けることができた。
内容は薄いので前エントリーへの追記で済まそうかとも考えたけど、新規にした。

使用したのは、サーバーに日常使いのhp 6730b Fedora25にインストールしたmpd。
レンダラーはraspberry pi2にインストールしたMoode Audio。
Moode Audioは384kHzへのアップサンプリング出力をi2sDACに送ることが可能。最近これにlibsamplerateをインストールしてBGM用に使っている。ちゃんと音質を確認したわけでは無いけど、いい感じじゃないかな。
普段はNASをマウントして使っているんだけど、httpストリーミングではどうかという考えもあった。

まず普段使いの6730bの、.mpdconfを設定。

audio_output {
type            "httpd"
name            "My HTTP Stream"
encoder         "flac"          # optional, vorbis or lame
#       port            "8000"
#       bind_to_address "0.0.0.0"               # optional, IPv4 or IPv6
##      quality         "5.0"                   # do not define if bitrate is defined
#       bitrate         "128"                   # do not define if quality is defined
#format         "44100:16:2"
#       max_clients     "0"                     # optional 0=no limit
}

こんな感じで。
ちなみに"flac"が"wave"だと上手くいかなかった。もとのファイルがflacだからなのかどうか分からないが。
操作は普通にmpdクライアントから行う。

次にレンダラー。
参考にしたのは下記、Arch Linuxのサイトの説明。
https://wiki.archlinuxjp.org/index.php/Icecast_%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%9F%E3%83%B3%E3%82%B0#MPD
https://wiki.archlinuxjp.org/index.php/Music_Player_Daemon/Tips_and_tricks#HTTP_.E3.82.B9.E3.83.88.E3.83.AA.E3.83.BC.E3.83.9F.E3.83.B3.E3.82.B0

使うのは、既にインストールされている「mpc」。
これはcuiモードで使用するクライアント。
当初はpiCore7でやろうと思ったんだけど、考えてみたらmpcをインストールしていない。
そこでインストールというのも面倒になってraspbianの使用も考えたけど、ありもののMoodeを使うことにした。

Moode Audioにsshでログイン。ユーザーはpi、パスはraspberry。
サーバーの6730bを操作してストリーミングを開始しておく。
Moode Audioのsshに戻って以下のコマンドを打つと数秒待って音が出始める。

mpc add http://192.168.1.24:8000/mpd.flac | mpc play

http://192.168.1.24 というのは6730bのアドレス。8000はポート番号で変更設定していなければこれで固定。
「mpc add http://192.168.1.24:8000/mpd.flac」だけだと、ストリーミングがmpdのplaylistに登録されるだけで音はでない。
パイプ「|」を使って「mpc play」を追加することで、再生される。
「mpc play」を続けて打っても別に構わないんだけど、1行のコマンドで済む方がいいよね。

ちなみにmpcのマニュアルは「man mpc」でも読めるけど以下のリンクにもある。
https://linux.die.net/man/1/mpc

マニュアルを読んで、今回初めて上手く使えたように思う。
要するに普段使っているncmpcppでしていることをコマンドでやるソフトということ。
ncmpcppは端末上で動くけど、実際の操作感覚はかなりguiな感じで、マウスも時には使ってみたりと感覚的に使える。
mpcはそれを剥ぎ取った感じで、すべてcuiだ。mpcを使いやすくしたのがncmpcppという感じだ。ncmpcppはマニュアルを熟読しなくても使える。まあ、操作キーの確認ぐらいは必要だけど。

さて、音はめでたく出たのだけど、音が出るまで数秒以上かかるのと、どうも安定しない。
ぽつぽつ途切れる感じだし音色もよくない。
top画面で見た限りでは、Moodeの負担が増えたようにも見えないんだけど、どこかで上手くいかないんだろう。
結局、Moodeの設定でアップサンプリングを止めたら解消した。
コマンドを打つとすぐに音が出るし（出音の直後は少しだけ不安定だけど）、途切れるような感じもない。
音質の比較はしていないけど、まあ、現時点ですごく良くなったという驚きは感じない。普通にいい音だね、といいう感じだ。

upnpでは普通にアップサンプリング出来ていたのでそういうものだと思っていたんだけど、httpストリーミング受信では勝手が違うらしい。upmpdcliのような連携して補助するソフトの有無によるのかな。

以上、備忘録。