abk1's scratched blog 3::AUDIO DIARY

今回はこれ。
MPD Stream lossless flac or wav / Takla's Weblog
https://takla.wordpress.com/2014/04/01/mpd-stream-lossless-flac-or-wav/

MPD HTTP streaming reducing CPU load ! / raspberrypi.org forum
https://www.raspberrypi.org/forums/viewtopic.php?f=35&t=43670
MPD and high CPU usage / raspberrypi.org forum
https://www.raspberrypi.org/forums/viewtopic.php?f=35&t=47400

Music Player Daemon/Tips and tricks HTTP ストリーミング / ArchWiki
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

mpdをhttpサーバーに出来るという。flacでもストリーミングできるそうな。
よくよく読んだらvlcかmplayerじゃないと聴けないみたいなんだけど、まあ、試してみた。

使用したのはraspberry pi B+を２台。OSにはraspbian jessie。
まず1台にmpdをインストールしてhttpストリーミングサーバーにする。
流れは以下の通り。

sudo raspi-config
vi /etc/dhcpcd.conf
sudo reboot

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install mpd mpc flac

chmod 777 /etc/mpd.conf
vi /etc/mpd.conf

#
music_directory         "/var/lib/mpd/music"
playlist_directory              "/var/lib/mpd/playlists"
db_file                 "/var/lib/mpd/tag_cache"
log_file                        "/var/log/mpd/mpd.log"
pid_file                        "/run/mpd/pid"
state_file                      "/var/lib/mpd/state"
sticker_file                   "/var/lib/mpd/sticker.sql"
#
#user                           "mpd"
#group                          "nogroup"
#bind_to_address                "localhost"
#bind_to_address                "/run/mpd/socket"
#
#port                           "6600"
#
#### audio_output {
# type          "alsa"
# name          "My ALSA Device"
# device                "hw:0,0"        # optional
#       mixer_type      "hardware"      # optional
#       mixer_device    "default"       # optional
#       mixer_control   "PCM"           # optional
#       mixer_index     "0"             # optional
# }
#
audio_output {
type            "httpd"
name            "My HTTP Stream"
encoder         "flac"          # optional, vorbis or lame
port            "8000"
#### bind_to_address "192.168.1.85"               # 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
}
#
#### samplerate_converter               "Fastest Sinc Interpolator"
#### audio_output_format "96000:16:2"
#

sudo chmod -R 777 /var/log/mpd
sudo chmod -R 777 /run/mpd
sudo chmod -R 777 /var/lib/mpd

sudo mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan/jazz /var/lib/mpd/music
sudo mpd --kill
pstree

systemd-+-2*[agetty]
        |-avahi-daemon---avahi-daemon
        |-cron
        |-dbus-daemon
        |-dhcpcd
        |-mpd-+-{decoder:flac}
        |     |-{io}
        |     |-{output:My HTTP }
        |     `-{player}
        |-ntpd
        |-rsyslogd-+-{in:imklog}
        |          |-{in:imuxsock) S 1
        |          `-{rs:main Q:Reg}
        |-sshd---sshd---sshd---bash---pstree
        |-systemd-journal
        |-systemd-logind
        |-systemd-udevd
        `-thd

途中で何回かリブートしたけど、大体こんな感じ。
mpdをサーバーにできるので、ncmpcppでファイルや曲の選択ができるのが強み。データベースのアップデートはスピーディで、cue sheetも使える。
今回はなぜかapt-get update upgradeしなかったら、apt-get mpdができなかった。
samplerate_converterでアップサンプリングしたら処理能力を超える感じだったので止めた。
sudo mpd --kill でmpdを落としたら、数秒で再起動するようになっているようだ。

次にストリーミング受信機の設定。
mpdで受けれたらいいんだけど無理っぽい。
https://wiki.archlinuxjp.org/index.php/Music_Player_Daemon/Tips_and_tricks には mpc add http://192.168.1.86:8000 とかコマンドでできるみたいなことが書いてあるけど、多分、vorbis or lameじゃないといけないんだろう。

https://takla.wordpress.com/2014/04/01/mpd-stream-lossless-flac-or-wav/ こちらのリンク先などに書いてあるとおり、mplayerを使う。
以下、流れを記載。
あらかじめbootのconfig.txtにi2sDACの設定を書き込んでおく。

sudo raspi-config
vi /etc/dhcpcd.conf
sudo reboot

sudo apt-get install alsa-base

sudo apt-get update
sudo apt-get upgrade

なんかalsaインストールが先になってる。ここらの流れで挙動が変わるかどうかは不明。
mplayerインストールする。

sudo apt-get install mplayer
man mplayer
mplayer -idle -cache 2048 http://192.168.1.86:8000

これで、httpサーバー192.168.1.86からのストリーミングを受信してras piのイヤホンジャックから音を聞ける。なかなかきれいな音だけど、再生開始までcache取り込みの時間がかかる。cacheはデフォルトだともっと少ないらしいのけど、ときに再生中に途切れたり、再生開始のときにノイズが乗るので、コマンドで2048にしている。

しかしi2sDACから音を出したい。
alsaを設定する。

cat /proc/asound/modules
 0 snd_bcm2835
 1 snd_soc_hifiberry_dac

cat /proc/asound/cards
 0 [ALSA           ]: bcm2835 - bcm2835 ALSA
                      bcm2835 ALSA
 1 [sndrpihifiberry]: snd_rpi_hifiber - snd_rpi_hifiberry_dac
                      snd_rpi_hifiberry_dac

1 [sndrpihifiberry]をデフォルトにしないとi2sDACから音が出ないのでasound.confを作る。

sudo vi /etc/asound.conf

pcm.!default {
type hw
card 1
}
ctl.!default {
type hw
card 1
}

pi@raspberrypi:~ $ mplayer -idle -cache 2048 http://192.168.1.86:8000

MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
Cannot open file '/home/pi/.mplayer/input.conf': No such file or directory
Failed to open /home/pi/.mplayer/input.conf.
Cannot open file '/etc/mplayer/input.conf': No such file or directory
Failed to open /etc/mplayer/input.conf.

Playing http://192.168.1.86:8000.
Resolving 192.168.1.86 for AF_INET6...
Couldn't resolve name for AF_INET6: 192.168.1.86
Connecting to server 192.168.1.86[192.168.1.86]: 8000...
Name   : My HTTP Stream
Genre  : Set genre in config
Website: Set website in config
Public : yes
Cache size set to 2048 KiB
Cache fill:  0.00% (0 bytes)   
ICY Info: StreamTitle='NEBULA - Manabu Ohishi Trio - NEBULA';StreamUrl='';
Cache fill: 19.14% (401408 bytes)   
Detected file format: Audio only
Selected audio codec: FLAC (Free Lossless Audio Codec) [libavcodec]
AUDIO: 44100 Hz, 2 ch, s16le, 524.3 kbit/37.15% (ratio: 65536->176400)
AO: [pulse] Init failed: Connection refused
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
[AO_ALSA] Unable to find simple control 'Master',0.
Video: no video
Starting playback...
A:   4.5 (04.4) of 0.0 (00.0)  2.1% 12% 

これでi2sDACから音が出る。終了は「q」キー。
問題は、前記コマンドでmplayerを起動しても、ストリーミング信号が受信できないと数秒で終了してしまうこと。つまり先にmpdサーバーから配信開始してから、mplayerを起動しないといけない。これって楽曲の冒頭が聞けないのだ。バックグラウンドで動作させる方法を発見できないのも地味に困る。なにか方法があるんじゃないかと思うんだけど。

例によって、現時点では音質の確認はしていない。

UPnP関連が続いている。
Raspberry Pi B+ / Raspbianでminimserverを動かしてみた。
以前、NASで扱おうとしてうまくいかなかったのは理解が不十分だったからっぽい。
音質評価はまだしていない。動かすだけでも僕の知識ではなかなか大変だからだ。そのうち追記するつもりだけど、いつになるか分からない。

現状、どんなことになっているか図示してみる。

作業経過をメモしていく。

まずRaspbian Jessie Liteをダウンロード。
https://www.raspberrypi.org/downloads/raspbian/

今回使ったのは、2016-11-25-raspbian-jessie-lite.zip（今日確認したら既に上位バージョンが公開されていた）。
展開してイメージをmicroSDカードに焼く。
sshでログインして操作するつもりだけど、Jessie2016-11-25-raspbian-jessie以降はデフォルトで使えなくなっている。使えるようには、bootパーティションに「ssh」というファイルを置けばいい。カードを手元のPCにマウントして、エディタでファイルを作る。文面は無しでいい。

Raspberry Pi B+を用意して、Raspbianで起動。
sshでログイン。ユーザーはpi、パスはraspberry。

sudo raspi-configで初期設定。
sudo apt-get updateとsudo apt-get upgradeはしていない（というのはjavaのインストールでつまづいたから。しなかったら問題なくインストールできた）。
IPアドレスを固定。
/etc/network/interfacesで設定することが多いようだけど、そこにはman dhcpcd.confを参照しろとあって、/etc/dhcpcd.confを編集しろということらしい。

vi /etc/dhcpcd.conf

interface eth0
static ip_address=192.168.1.83/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1

sudo reboot

こんな感じでIP固定される。

minimserverのサイトを参照。ras piではどうすればいいか書いてある。
http://minimserver.com/install-raspbian.html
minimserverはjavaで動くので、インストール。

sudo apt-get install oracle-java7-jdk
java -version

pi@raspberrypi:~ $ java -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode)

下記からMinimServer-0.8.4-linux-armhf.tar.gzをダウンロード。
http://minimserver.com/downloads/index.html
Linux ARM用にはsoft floatとhard floatが用意されてるんだけど、ras piはhard float用。
以下、参考のサイト。

How can I tell if I am using the hard-float or the soft-float version of Debian/Raspbian?
http://raspberrypi.stackexchange.com/questions/4677/how-can-i-tell-if-i-am-using-the-hard-float-or-the-soft-float-version-of-debian

Check for the existence of the directory:
/lib/arm-linux-gnueabihf
the soft-float version do not have this directory, they have:
/lib/arm-linux-gnueabi
instead, or you can list the packages installed using:
dpkg -l
and see the platform in the third column (all/armhf/armel)

http://minimserver.com/install-raspbian.htmlに書いている通りに進む。
/home/piに落としたファイルをコピー。僕はFilezillaで転送した。

cd /home/pi
tar xf MinimServer-0.8.4-linux-armhf.tar.gz

mkdir music
minimserver/bin/setup

Do you want to change these settings (y/n)?
y
Enable automatic startup for MinimServer (y/n)?
y

minimserver/bin/startc

MinimServer 0.8.4, Copyright (c) 2012-2016 Simon Nash. All rights reserved.
autoUpdate: installed package 'minimserver-0.8-update-96'
Enter command (? for help):
autoUpdate: relaunching runtime
>MinimServer 0.8.4 update 96, Copyright (c) 2012-2017 Simon Nash. All rights reserved.
starting MinimServer[raspberrypi]
Enter content directory, or null to continue:
Enter command (? for help):
>#/

ここで、minimserverが管理するディレクトリを設定する。

>#/home/pi/music
MinimServer[raspberrypi] is running
>

この時点で、minimserverに端末からログインした状態になる。
さて、http://minimserver.com/install-raspbian.htmlからちょっと引用。

11. If MinimServer is running as a terminal application, MinimServer will terminate if the terminal window is closed for any reason. To prevent this happening, press Enter at the command prompt to exit MinimServer, then enter the command:
minimserver/bin/startd
This restarts MinimServer as a daemon background process that will continue to run after the terminal window is closed.

使ってみたらわかるんだけど、exitしたらminimserverも終了するということ。
minimserver/bin/startd
このコマンドで起動させたらデーモンとして動く。

minimserverのサイトはとても詳しく書いてくれているようなんだけど、読むのが大変。

下記コマンドでNASの共有フォルダ/titan/jazzをras piのmusicにマウントできる。
sudo mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan/jazz /home/pi/music

次に、minimwatchを手元のPCにインストール。minimserverをデーモン化したのでminimwatchからコントロールすることになる。
minimwatchがなくてもminimserver自体を操作することは出来るんだけど、前述の通り、exitしたら止まるのでminimwatchから操作する方が便利だろう。

ノートPCのFedoraにインストール。linuxなので下記を参照。
http://minimserver.com/install-raspbian.html
http://minimserver.com/install-linux-mwatch.html
書いてある通りに進む。
minimwatchのダウンロード。javaが合ってないといけないよとか書いてある。
うちのFedoraは32bitなのでMinimWatch-0.8.4-linux-x86.tar.gzを使う。

mkdir minim-home
cd /home/ab/minim-home

tar xf MinimWatch-0.8.4-linux-x86.tar.gz
minimwatch/bin/setup

MinimWatch desktop integration is disabled
MinimWatch automatic startup is disabled

Do you want to change these settings (y/n)?
n

minimwatch/bin/startc

[ab@hp6730bHitachi minim-home]$ minimwatch/bin/startc
MinimWatch 0.8.4 update 49, Copyright (c) 2012-2017 Simon Nash. All rights reserved.
Enter command (? for help):
Selected media server: MinimServer[raspberrypi]
MinimServer[raspberrypi] is running
>?
Commands:
 rescan     restarts the media server and rescans the media library
 props      shows current properties for the media server
 prop n=v   sets media server property name n to value v
 about      shows version and status information for the media server
 stop       stops the media server without exiting the server application
 restart    restarts the stopped or running media server
 close      exits the media server application
 select s   selects media server s for display and control
 refresh    refreshes the status of all media servers
 exit       exits this application
 packages   shows installed packages (with status) and available packages
 install p  installs package p
 remove p   removes installed package p
 undo p     undoes a pending change to installed package p
 relaunch   relaunches the runtime and applies pending package changes
 modules    shows installed modules (with status)
 updates    shows available updates for installed packages
 sleep t    delays execution for t seconds (can be useful for scripting)
 help       (or ?) displays this information
>
>rescan
restarting MinimServer[raspberrypi]
starting MinimServer[raspberrypi]
MinimServer[raspberrypi] is running
>

これで、minimwatchはオーケー。
端末からインストールした「minim-home」ディレクトリに入って、そこでコマンドを打つと操作できる。
うちのシステムではなぜかguiでの操作がうまくいかない。
>MinimWatch desktop integration is disabled
この設定がいけないのかと思って直しても見たけど、変わらない。でもシンプルな使い方ならcuiで困らないかな。

rescan でminimserverが再起動され、ライブラリがアップデートされる。
exit しても、minimwatchが終了するだけでminimserverは動き続ける。

レンダラーの操作。
過去のエントリで書いた手順でレンダラーに設定したvolumioを、ncmpcppで操作する。
「u」キーでアップデート。UPnPサーバのライブラリが、mpdのデータベースに反映される。

以下、ちょっと参考サイト。
Upmpdcli: MPD UPnP Renderer Front-End
https://www.lesbonscomptes.com/upmpdcli/upmpdcli.html

もうひとつ。
MPD and UPnP
https://www.lesbonscomptes.com/upmpdcli/upmpdcli-or-mpdupnp.html
引用。

Back-end integration: mpd-upnp

This is implemented as an MPD Database plugin. Instead of reading files and building its own catalog, MPD accesses an UPnP Media Server both for tag and audio data. Tags are accessed through UPnP, and data is retrieved through HTTP.
MPD then translates the UPnP catalog data to the native MPD client protocol, so that MPD clients think that they are talking to a normal MPD (but instead they are browsing the UPnP Media Server through MPD).
In this configuration, MPD can’t manage local data and tags. The file and UPnP database plugins are mutually exclusive.

そういうわけで、UPnPサーバとmpdの間でデータベースの擦りあわせを行う必要がある。これは、そこそこ時間がかかる。さすがにファイルが数枚なら大したことはないけど、数10枚以上になると数分以上かかってくる。
NASから直接データを読み込むよりもmpdにとっては手間らしい。
まあ、でもこれで音が出る。
レンダラーに、mpd以外の何かデータベースを必要としないものを選択したら、こんな手間は要らないんじゃないかと思うけど、よくわからない。minimstreamerというのを使うのかな。他にもJPLAYと繋いだりとか、色々と手段はあるようだけど。

さて、ncmpcppで検索ができる。
現在、minimserverに登録されているファイル数はこんな感じ、17だ。

ちょっと検索してみると、結果はこんな感じ。

1つのファイルが、Found 11 songsとして表示されている。他にも25 songsとか。
NASマウントでの使用状況では、こういう検索結果表示はみたことがない。1つのファイルは1行で表示される。

これはデータベース構築に時間がかかるわけだと思った。
あと、ファイルが多くなったら実質的に検索として機能するのかどうか。多数のファイルをサーバーに登録したとして、そこから検索で10枚ひっかかったとしたら、表示されるのは200行近くになるのかな。
Beethobenとか検索した日には、大変なことになりそう。
まあ、少なめのファイルを登録して検索なんか使わないという感じで運用したほうが良さそうだ。ncmpcppではなく、他のUPnPクライアントを使えば、きれいに表示されるのかもしれないけど、よく分からない。

気になるのはメモリ再生と比較してどうなんだろうということだけど、おいおいだ。

たぶんこれは初歩的なLinuxの知識なんだろうけど、長年の謎だったのが解決したのでメモる。

volumioはNASをマウントして運用することがあるんだけど、このとき特定のファイルのシンボリックリンクを使いたいと思うことがあった。
つまり複数のディレクトリから見えるようにしたかったということだ。
これが上手くいかなかった。

当初に試みたのは、volumioにsshでログインしてln -sコマンドを使うこと。
volumio1.55の場合、/mnt/NAS/ にNASの共有フォルダがマウントされている。
そこから入ってシンボリックリンクを貼ろうとしたら出来ない。以下のようなエラーがでる。

ln: failed to create symbolic link `OrpheusBaroqueConcertOrpheusChamberOrchestra': Read-only file system

Read-only file system、なんだそうだ。
安全上の配慮なのか、volumioはNAS上のファイルを変更できないようになっているらしい。

そこで、QNAP NASにssh、adminでログインして試みる。
hhs210の共有フォルダは、/share/MD0_DATA/ 以下に配置されているので、ここから入ってシンボリックリンクを貼る。
例えば以下のようなコマンド。これでaudiophilesというディレクトリにAA.flacというシンボリックリンクができる。

[/share/MD0_DATA/titan/audiophiles] # ln -s /share/MD0_DATA/titan/classics/A.flac AA.flac

しかし、これがvolumioからは見えない。

試しにNASの共有フォルダを手元のノートPCにマウントしてみると、ファイルとしては存在している。
これをダブルクリックしたら、以下のような表示が出る。

つまり、手元のノートPCにマウントされた場合と、NASの上そのものにあるときでは、シンボリックリンクファイルに記述されたリンク先のパスが違ってしまう。
当たり前だが、今更気付いた。

ということは、volumioにマウントした時に読めるシンボリックリンクを作れば機能するはずだ。
この際、NASをマウントしたノートPC上で作ってしまう。
ノートPC上でのパスがどうなのかは関係なく、volumio上でリンク本体のパスがどうなるかを想定してコマンドを打つ。

[root@hp6730bHitachi audiophiles]# ln -s /mnt/NAS/hs210Saturn/classics/A.flac AA.flac

このシンボリックリンクはノートPC上では機能しないが、volumio上では機能する。
ncmpcppのブラウザでアップデートをかけるとaudiophilesディレクトリにAA.flacが表示される。

あらためて明けましておめでとうございます。

昨年末、UPnP/DLNAは難しいというエントリを上げたんだけど、早々にvolumio1.55を2台、upnpで繋げてしまった。
音質はノイズが多いと書いたけど、i2sDACに出力するようにしたら、かなり解消した。ras piのイヤホン出力で聴いてノイズが多いと思ったけどi2sは影響が少ない様子だ。
ちなみに使ってるのは、raspberry pi B+。
ということで、メモ書きにエントリに書いておく。

まず、前回のエントリの流れで記載。
ras pi、volumioを2つ用意。両方、/etc/minidlna.confを編集、前回のエントリーの最初のほうに書いた通り。
1つをサーバーに、もう1つをレンダラーに割り当てる。
サーバーの設定は、UPNP\DLNA IndexingとDLNA Library ServerをON。レンダラーの設定は、UPNP ControlとUPNP\DLNA IndexingをON。

webブラウザではUPNPは表示されないようなので、これ以上の操作はできない。
ncmpcppからレンダラーのvolumioにアクセスしたら、UPNPと表示されている。そこを選択すると、upnpサーバーのvolumioが表示される。

あとは階層をたどって表示される音源を選択し再生を指示したら、レンダラーのvolumioから音が出る。

前回のエントリー追記で、問題は音にノイズが多いことと、インデックスの更新に手間がかかることと書いた。
まるでチューニングが合ってないラジオのように、ノイズが再生音に乗っている。
インデックスの問題はしょうがないとして、ノイズはなんとかできないだろうかと考えた。Phile webの記事では使えると書いてるんだし。

まず、サーバー側のmpdを止めてみた。
upnpサーバーなんだからmpdは要らないはずだ。sshからmpd --killで止める。問題なくサーバーとして機能している。しかしこうしたらwebブラウザからはアクセスできなくなる。
しかしさほどノイズは減らない。

次にレンダラーの方、mpdのAudio buffer sizeとBuffer before playを増やしてみる。多少の違いはあるようだけど、やはりノイズは多い。

やっぱりイヤホン出力が良くないのかな、と考えてi2sDACを試すことにした。
結局、これで再生音に乗っかるノイズは消えた。これなら使えるレベルかな。
しかし試聴に使用したのはポータブルのアクティブスピーカー。本格的なオーディオシステムでの実力は不明だ。

ノイズは何とかなったとして、インデックスの問題が残っている。これが解消しないと実用に耐えないと思う。
これはUPnP/DLNAサーバーソフトの完成度によって決まると思うので、本気でUPnP/DLNAで音楽再生しようと思ったら、あれこれ探したり試行錯誤していくしかないだろうなと思う。
MinimServerのセッティングがうまくいかなかったのは、ちょっと無念。
個人的には、メモリ再生の方がよほど簡単で楽だと思ってしまった、この1ヶ月だった。

最近はupnp/dlnaをvolumioで使おうと試みていた。
lightMPD/upnpgwがupnpを上手く使って音質向上に成功しているようで、NASをマウントするよりもシステムの負担が少ないのかもしれない。じゃあ手近で使っているvolumioで出来ないか、あわよくば音質改善が見込めないかとか考えた。
そもそも大したスキルがないので上手くいかなかったので、この際なので記録しておく。

volumio1.55ならupnpを使えるということらしい。

ラズパイ・オーディオをDLNAネットワークプレーヤーとして活用する - Phile-web
http://www.phileweb.com/review/article/201604/22/2053.html
Raspberry Pi+Volumio をネットワークオーディオプレイヤーとして使う : アジャイル株式会社
http://www.agilegroup.co.jp/technote/volumio-via-network.html
How to start the DLNA Server for Volumio 1.5 on the Pi
https://volumio.org/forum/how-start-the-dlna-server-for-volumio-the-t2401.html

まずvolumio1.55の設定。
webブラウザからアクセスしてDLNA関係の設定をONにする。
試験的に、volumioにはNAS上の適当なフォルダをマウント。

次に、sshでrootでログイン。パスはvolumio。
/etc/minidlna.confを編集。
#media_dir=/var/lib/mpd/music
上記の行のコメントアウトを外す。
dlnaサーバを再起動するのに以下のコマンドを打つ。
service minidlna restart

これでvolumio1.55がDLNA serverになる。
もしもvolumioにマウントしたNASのデータだけをupnpクライアントに認識させたかったら、/etc/minidlna.confを以下のよう編集したらいい。
media_dir=/var/lib/mpd/music/NAS

確認で、http://volumio:8200/ をwebブラウザで表示。
うちのノートPC(Fedora)はこれでは表示できなかったので、IPアドレスに書き換えて打ち込む。
スナップショット画面が以下。

確かにdlna serverとして動いている。
windows PCのWindows Media Playerから、dlnaサーバーとしてvolumioを認識できた。しかしwindowsから音を出すのが目的じゃない。

まずvolumioを2台、upnpでつなぐことができないか考えた。
MPD-to- MPDでやれるはずなんだけど、レンダラー担当のvolumioが、volumio DLNA serverを認識してくれない。というか、認識させる方法がいくら調べても分からない。

MPD as client to an UPnP/DLNA Media Server
https://www.lesbonscomptes.com/pages/mpd-upnp.html

諦めて、QNAP NASの機能を使う。NAS-to-MPDということになるのかな。
まず、LINNが推奨してるというMinimServerを試みる。AppCenterを使って簡単にインストールできる。

ただ、インストールは簡単だったけど扱いがよくわからない。
設定次第で細かいことも出来そうなんだけど、設定の仕方がよくわからないのだ。設定するのに「MinimWatch」というソフトをインストールしないといけない、とまでは分かった。

サーバーソフトの紹介 『MinimServer』言の葉の穴 http://kotonohanoana.com/archives/1536
MinimServer 導入・設定・運用編 言の葉の穴 http://kotonohanoana.com/archives/8121

ただ細かい設定をしなくても、この時点でvolumioからupnpでNASを認識できている。
ncmpcppで表示できていて、操作して音も出せる。
しかし、cue sheetは表示されず、使えない。表示されている音楽ファイルの再生を指示して音が出るまでに若干時間がかかる。不便だな、設定したら便利になるだろうか、などと思っていたら、MinimServerが認識していないflacファイルが少なからずあることに気付いた。原因ははっきりしない。
MinimWatchは触ってもないけど、諦めることにする。

MinimServerを止めて、最初からQNAP NASに入ってるものを使うことにする。
DLNAメディアサーバー、Music Stationが組み込まれていて、追加でMedia Streaming Add-onをインストールしたらNASからデータをvolumioに送ることができる。操作は、NASのMusic Stationにwebブラウザでアクセスして行う。
つまり、webブラウザでNAS上のアプリを操作し、そのアプリがvolumioにデータを送り、volumioがそれを再生すると。

再生中のvolumioにsshでログインしてtopを打ってみたのが下の画像。
Upmpdcliが働いて、volumioがupnpレンダラーとして機能しているのが分る。

意外なことに、Music Stationはcue sheetの中を読み込んで曲別に楽曲管理してくれるようで、これはすごいと思った。しかし残念なのは、１曲再生するつもりで操作したら、その曲が終わったあと次の曲を再生していく。アルバムの２曲目を再生しようとしたら1曲目から再生される。つまり曲別に管理しているようでもデータの扱いはファイルということだ。再生されている曲と、Music Stationに表示されている曲に齟齬が生じる。
実際、ncmpcppでmpdにアクセスしたら、個別の曲じゃなくアルバムのflacファイルを再生してるのが一目瞭然だ。
upnp/dlnaというのはファイル別で楽曲管理するらしく、cue sheetを使うのは相当難しそう。

MinimServer Forum > MinimServer > General > CUE Sheets
http://forum.minimserver.com/archive/index.php?thread-138-3.html

> The UPnP server protocol requires each track to be sent as a complete file.

あれこれするうちに挙動がおかしくなった。これはまずい。負担はかけられないようだ。
他に触ってみて気づいたのは、やはり音が出るまでに若干時間がかかる。10秒前後かな。再生開始の時にノイズが乗ることがある。
あと、Music Stationでライブラリ管理を行うのは難しい。うちはファイルが多すぎるのだ。目的のファイルを探すのに時間がかかりすぎる。検索機能も使いやすいとは言えない。
アートワーク表示こそ出来ないけどスピーディにファイルにアクセスできるncmpcppに馴染んでいたら、かなり使いにくいと感じてしまう。

そんなわけで、ncmpcppでアクセスして、なんとか出来ることはないかとか考える。
ncmpcppでvolumio経由でupnpサーバーの状況を表示しようと思えばできるようなんだけど、うちにはメイン用とバックアップ用、2つのNASがあるんだけど、NASによってncmpcppで表示できたりできなかったりして理由がよくわからないし、表示できても全てのファイルを網羅できていなかったりして、いろいろわけが分からなかった。
しかし、片方のNASのupnpサーバーを停止してみたら、他のNASのupnpサーバーが機能し始めて？volumioとも繋がった。
ここで初めて気付いたのが、一つのネットワークにupnpサーバーは一つじゃないといけないのかな？ってことだ。よくわからないけど。

ここで興味本位で、ncmpcppのUPNPブラウザ画面からアップデートをかけてみたら（uキーを押すだけ）うちにあるNAS？があれもこれも表示されてきた。これって全部、upnpサーバー？
うちには音楽用のNAS以外に古くからあるファイルサーバーがいくつか動いている。それらが表示されているし他にもネットワーク上のデバイスがいくつか、、、

このときNASでは何をしてるかというとmysqldというデーモンがCPUの70%を食って大忙しだ。webデータベースを作るMySQLのデーモンらしい。一方でvolumioはといえば、topコマンドを打ってみたら何もしてないようだ。データベースの完成待ちという所か。
これが、えらく時間がかかる。
mpdがデータベースを作るのにも時間がかかるが、多分、数10倍以上かかっている。

あまりに時間がかかるので、ncmpcpp上で唯一表示された[Beethoven]のフォルダの中を見てみたら下のスキャン画像のような状況！ 同一ファイルのデータを重複して繰り返し取り込んでいるらしい。。。

とりあえず、volumioをシャットダウン。
速やかにmysqldは仕事を止めて、NASのCPU使用率は通常レベルに戻った。やれやれだ、、、
MinimWatchをインストールしてMinimServerで粘ったほうが良かったかな、、、

volumioでupnpは、うちではハードルが高いかな。
cue sheetも使えないし、操作は手間がいるし、当面は素直にvolumioはNASをマウントして使うことにした。

しかし、あれこれやるうちに新たな発見があった。

うちでは複数のmpdをひとつのノートPCで扱うため、ポートの設定を各々のmpdで変えていた。
ノートPC上に複数のアカウントを作り、各々にmpdサーバーを割り振って、端末のウインドウを開いてアカウントを変えてncmpcppを立ち上げて使う。複数のウィンドウにアカウントを割り振ることで、同時に複数のmpdを操作できる。
mpdとncmpcppのポート設定を合わせて書き換えて使う。デフォルトは6600だが、これを6601、6602、などと変えている。つまり、IPアドレスとport番号をセットにして設定している。
下の図のような感じ。

書き換えていなかったら、以前は上記のような運用は出来なかった。混線するとでもいうのか、ncmpcppとmpdが繋がらなくなるのだ。
つまり、ポート設定を書き換えなければ、ひとつのPCで同時に使えるmpdは１つということで、そういうものなんだと理解をしていた。
ポートを変えるとvolumioはwebブラウザからのアクセスが出来なくなるが仕方ない。大して困らないし。

ところが、いつの間にか、ポートが6600のままで同時に複数のmpdを操作出来るようになっていた。
そもそもIPアドレスが異なるのに、ポートも変えないと繋がらないというのは、何かがおかしいのかもしれない。

気付いたきっかけは、volumioを2台、upnpでつないでみようとしたことだ。
volumioをupnpで継ぐにはUpmpdcliを動かしておく必要があり、mpdのポート6600を変更したら、これが動かなくなるので変えられない。ひとつのネットワークにポート6600のvolumioが２つ存在することになる。
ncmpcppからアクセスできなくなるだろうと思っていたら、問題なく出来てしまった。

以前とは何が変わったかというと、クライアントPCのOSが変わった。以前はVine Linuxだったが現在はFedoraとDebianを使っている。
ポートが6600のままでいいなら、設定などで余分な手間が要らなくなるし、volumioならwebブラウザからのアクセスも可能になる。

新しい知見があったので、やって良かったということかな。

追記。
イラストは下記のサイトのものを加工して使わせていただいています。
GATAG｜フリー素材集 壱 http://01.gatag.net/0006178-free-illustraition/
Publicdomainvectors.org http://publicdomainvectors.org/ja/tag/%E3%83%8F%E3%83%BC%E3%83%89%E3%82%A6%E3%82%A7%E3%82%A2

明けましておめでとうございます。元旦に追記。

なんやかんやでvolumio2つをupnpで繋げてしまった。
音質はノイズが多くピュアオーディオには無理。スキルがないからかもしれないけど。
せっかくなので記録しておく。

１月４日、追記。
エントリの上のほうにも追記したけど、実は意外に音は良かった。イヤホンだと以前よりも悪くなったと思ったんだけどな、、、
次のエントリーにその後の経過を書いた。

まず、ras pi、volumioを2つ用意。両方、/etc/minidlna.confを編集、このエントリーの最初のほうに書いた通り。
1つをサーバーに、もう1つをレンダラーに割り当てる。
サーバーの設定は、UPNP\DLNA IndexingとDLNA Library ServerをONに。実は、UPNP\DLNA IndexingはOFFでもいいのかもしれないけど、十分な確認が出来ていない。
レンダラーの設定は、UPNP ControlとUPNP\DLNA IndexingをONに。

webブラウザにはUPNPは表示されないようなので、これ以上の操作はできない。
ncmpcppからレンダラーのvolumioにアクセスしたらUPNPが表示されるので、そこに入るとUPNPサーバーのvolumioで設定された音源が表示される。

あとは階層をたどって表示される音源を選択し再生を指示したら、レンダラーのvolumioから音が出る。

問題は、前述したとおり音にノイズが多いことと、インデックスの更新に手間がかかること。
本来、ファイルが追加されたら自動的にインデックス（データベース）が更新して欲しいんだけど、そうはいかないらしい。自動じゃないのはいいとして、手順がひどく面倒なのだ。
まず、miniDLNAの更新で以下のコマンドをsshから打ち込み。
$ sudo minidlna -R
$ sudo service minidlna restart
更にncmpcppから、レンダラーのmpdのdatabase更新をかける必要がある。以下を参考にした。

Why is the minidlna database not being refreshed? http://stackoverflow.com/questions/5180409/why-is-the-minidlna-database-not-being-refreshed

日常的に使用するのは無理じゃないかなという感想だ。

現在のオーディオシステムについて記録。

以前はテーブルで図を書いていたんだけど、いいかげん限界かと思いLibreOfficeのドロー機能を使って作図した。画像だけ表示で倍の大きさになる。
１回作っておけばあとは楽だろう。

下流は変わらないが、上流が若干変わっている。
大した変化もないのにエントリーとしてあげようというのは、コンポの紹介を久しぶりにしておこうと思ったから。サイトを運営し始めた最初の頃には力を入れて書いているが、最近は何もしていない。まあ、最近はコンポ名で検索すれば簡単に情報が得られるので、必要ないといえばないか。
書き上がった後で読みかえしたら戯れごとかと思うほどに意味がないので、読まないほうがいいとこの時点で注意喚起しておく。

どこからいこう。上流からか。
そうだね、図を一目見てこれは弱い、馬脚だと感じる部分は電源だろう。
OMRON BY50SとSANWAのUSB電源を使ってるのはともかく、上流のNASやルータにはタコ足配線で済ませている。これはどうかと思っているが、後回しになっている。

タコ足配線から繋がるのがQNAPのNASとLANルータが3つ（効果のほどは不明だがジッター対策）。定評があるFX08-miniが2つとオーディオ的評価不明なbuffalo。メモリ再生が中心になってきたので、もはや余り意味がないけど外す気にもならずに繋げている。
QNAPについては、最近ようやく自動バックアップの設定をした。これでHDDが壊れても安心だ。

さて、最近はメインのデジタルトラポが3つになった。全部192/24にアップサンプリングの設定。
Raspberry Pi2とpiCore7を使ったRAMメモリ再生機が2つ。１台はRATOCのusb-ddcを経由してCOAXをfirefaceに。もう１台はHifiberry Digi+の光出力をfirefaceに。
前者の方が音はいい。いや、いいというか、次元が違う？
正直、i2sボードのddcがusb-ddcにここまで差を付けられるとは想定してなかった。メモリ再生じゃないと使えないし、JPLAYを試してみようと思わなければ気付きもしなかったわけで、なんというか、いろいろと綱渡り的、偶然が重なって発見的な使い方だ。
そこまで音質に差があるとはいえ、2台あると運用上の自由度が高くなって便利。firefaceは2つの入力から同時に音を出せる。どちらを聴くか、切り替えは手元のノートPC上の操作で行う。

それにしても、音がよければ音楽が気持ち良く鳴るとは限らないというのを改めて感じる。192/24にアップサンプリングしたメモリ再生の信号をusb-ddcに通したら、ポップミュージックは何だか、音源によってはミュージシャンの素顔が見えすぎる。特にボーカル。楽しくポップなはずなのに「真面目に歌ってる」のが聞こえてしまう、というか。
そういうときは、Raspberry Pi B+とVolumio1.55にi2sDACのNAS音源再生機を使えばいい。ビリージョエルが実は生真面目に歌っているのを、上手に隠して鳴らしてくれる。

fireface UCXはUSB DACではなく、COAX、TOSから入力を受けるDACとして使っている。本当はいろんな機能があるようなんだけど持ち腐れだ。NANOCLOCKSからの入力がある方がいいかどうかは、未だに確かめていない。ほとんどまじないである。

アンプはシャープのSM-SX100。20世紀末のアンプだがこれはうちのシステムの要である。
当時、同価格帯のマークレビンソン、ジェフローランド、ゴールドムンドと比較試聴し、これしかないと決めたのだった。なにしろ情報量とスピーカーの駆動力が一番だった（正確に鳴らすという印象）。音色はゴールドムンドに近かったけど更にスピードが速い。壊れるまで使うと決めて買ったが、もはや壊れても修理がきかない。

そのアンプには電源タップKripton PB-500-2を使用。たぶん中にノイズ対策のフィルターか何か入ってるんじゃないかな。使い始めた頃はすごく効果があると感じた。

VRDS-25xsとDP-5090（これは子供用）は、デジタル出力をアンプに刺して使っている。これは壊れかけているアンプで使える入力端子に限りがあるためのやむをえない処置だ。セレクターのリレーがうまく効かないのだ。
ここ数年のDP-5090の使用頻度は高い。

スピーカーはJBLと、FOSTEXのスーパーツイーターだ。
ネットワークに使ってるのは、チャージカップルドネットワークというJBLの技術をぱくった接続法で、これで繋いだスーパーツイーターは濁りのない高域を再生する、と思う。固定抵抗アッテネーターを使用しないというのもこだわりどころだったりする。長年にわたり使っているが、高級なパーツで組んだのと比較したわけじゃないのでアドバンテージに客観的な説得力はない。しかし4425mk2を4429などに買い替えない理由になっていたりする。

JPLAYはすごく評価されているようなので一度は聴いておくべき、と思っていた。
bugheadも気になるけど今回はJPLAYだ。

予備機として眠っていたhp Compaq 6730bに無償180日のWindows Server 2012 R2を、いろいろ面倒だったけどインストール。これにお試し版のJPLAYをインストール。再生ソフトとしてfoobar2000をインストール。しまい込んでいたral-24192ut1の付属CD-ROMからドライバをインストールして接続したら無事認識して音が出た。
単体PCモードである。
デュアルのほうが音がいいというけど足りないwindows機を調達してまでやる気はない。

ras-pi2 + piCore7のUSB端子にral-24192ut1を継ぐとあっさり認識した。
以前、powerbook G4 + vine linux ppcで認識してくれなかったりras-pi B+ + Volumioで不具合が多かったので不安だったのだけど、問題ないようだ。
（以前の不具合のせいで僕はusb接続に疑いを抱えたままのようだ）

ral-24192ut1を使わずにfireface UCXをクラス・コンプライアント・モード（CCモード）に設定してusb接続するという方法もあるんだけど、基本的にapple製品のみ対応でLinux系OSで音が出るかどうかはディストリ依存らしいし、windowsはそもそも対応していなくて、最近、windowsもUSB Audio Class 2.0に対応したらしいから使えるかも知れないけど、たぶん何かダウンロードしないといけないし、レイテンシーのパフォーマンスが違うのでRMEは推奨しないというようなニュアンスがある。
https://synthax.jp/cc.html
TotalMix FXをインストールしてあるwindows7機（UCXの設定用でPCオーディオには使っていない）にJPLAYをインストールするというのは抵抗がある。FXとJPLAYとで不具合が起きないか心配。
いろいろ設定をいじるのも面倒なのでしないと決めた。

そういう感じで音を出す方法は以下のとおり。

音源は以下のとおり。ジャズやポップミュージックも候補はあったけど時間切れ。

• ヒラリー・ハーンのバーバー：ヴァイオリン協奏曲、第一楽章
• ブダペスト弦楽四重奏団のベートーヴェン:弦楽四重奏第１番、第一楽章（8CD box setから）
• カラヤン、ベルリンフィルのホルスト：惑星、火星と土星

まず（３）と（５）、ras-pi2 + piCore7 + mpd　RAMメモリ音源再生で、ral-24192ut1（外部電源使用）と、hifiberry Digi+とfireface UCXの組み合わせを比較。
（５）は日常的に使っていた再生方法だが今回の試聴ではアップサンプリングなし。

驚いたのは、ヒラリー・ハーンとブダペスト弦楽四重奏団では同レベル。ral-24192ut1のほうがメリハリがあり元気な音で、これはこれでいい感じ。比べたらDigi+/UCXは元気がないようにも聴こえる。へえ、と思ってカラヤンの惑星を試したら、Digi+/UCXは破綻なく再生するけどral-24192ut1のほうは大音量時には音が荒れる感じになった。
ral-24192ut1、なかなか健闘している。標準価格￥72,000だっただけのことはある。

その上で、JPLAYの（１）を聴いてみたのだけど、比較して明らかに情報量が少ない。荒くて眠たい感じの音だ。この時点では、単体PCモードだしセッティングは全く詰めていないし音源はRAM上じゃなくUSBメモリだし適当なノートPCで本領発揮は全くしてないので比較するのは無理な条件だからしかたないのかな、、とか、この時点では思った。

次に（６）を試す。
以前にUSB DACでNASの音源を試したのはras-pi B+、Volumioだった。pi2ではどうなのか。
結果からいうと、これはひどい、という音が流れ出てきた。例えばカラヤンの惑星、途中で何か打楽器が鳴るんだけど、これが割れ鐘のように再生されて何が鳴ってるのか分からないのだ。トラブル続きだったras-pi B+、Volumioのときより酷い再生音で、ras-piでusb出力でNASというのは、つくづく最悪だと思った。他のUSB DACなら問題ないんだろうか。

メモリ再生はシステムへの負担が少ないと改めて実感した。今回、USB DACを繋いで繰り返し試聴したけど全く不具合が生じていない。

過去に同等にひどい再生を聴いたことは一度だけある。
何年も前、まだiTunesとAirMac Expressでネットワークオーディオを試みていた時期に、何がいけなかったのか、急にテンポは乱れ、音程は狂い、なんでこんなことになるの？というような再生音を聞いたことがある。デジタル再生でそんなことが起きるとはそれまで考えたこともなく、それ以降、今に至るまで同じ現象には遭遇していない。

全く、デジタルで音楽再生というのは不思議なことばかりだ。

実はここまで書いて11月16日にアップしたけど、数時間後に考え直した。
もう少しJPLAYを試してみよう。案外、何か間違えていたりしたかもしれない、、。一旦、エントリを取り下げた。
そして、やはり間違えていた。このエントリーは加筆修正してアップしている。

ということで、再確認。
間違えていた設定を治してやり直したJPLAYの音（１）は、最初とは全く違う音だった。
（３）や（５）と比較すると音場が一回り大きく広がり、見通しがよく奥行きが出る。音色も鮮烈で生々しい。なにしろ桁違いに空間の情報量が多く感じる。デュアルだとこれ以上ということなので、すごいことだ。
JPLAYはUSB出力の制御がブラックボックス、企業秘密ということらしい。それでここまで変わるということは従来の伝送は何が問題なのかということになる。

とか考えながら（２）と（４）も試してみなければ、と思い出す。
日にちを改めて、再試聴。
音源はカラヤン、ベルリンフィルのホルスト：惑星、火星、金星、木星など。

結果。
とりあえず（１）（２）（４）の差は、（１）と（３、５）の格差に比べたら僅差。

（４）でpiCore7のメモリ再生のUSB出力をral-24192ut1でウォッシュアウトしたらJPLAYの単体PCモードにかなり近付く。しかし若干刺々しい音だ。

（１）の音はそういう刺々しさがどうとか考えさせない音がする。それだけ説得力、存在感がある。鮮烈さと滑らかさと情報量が同居している。ただ、どっちかというと鮮烈さが勝るので（DACによる？）聴くのにエネルギーがいる。これはケーブルとかセッティングとかコンポの調整で変わるかもしれない。
（２）は（１）と比べたら、どっち付かずな感じになる。なんというか良くも悪くも（１）の音ほどの存在感、主張がないのだ。JPLAYからの出力を直接にDACに入力した方が効果がはっきり聴こえるのかもしれない。

ふと思いついて、（４）でmpdの設定を変更し192/24にアップサンプリングしてみると、こっちのほうがいい。アップサンプリングした音は耳馴染みの良さでは（１）を越えている。情報量は同等、音場空間の見通しはごく僅かにJPLAYのほうがいいかどうか。殆ど差異がない。

ということで、うちでの試聴の結果、順位をつけるとしたら（１）＞（２）＞（４）＞（５）＞（３）。
しかし番外で（４でアップサンプリング）が一番、僕の嗜好に合っている。これは今後は使っていこうかと思う。

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

どこから書いたものか。
まず、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

現在のオーディオシステムについて記録。

下流は変わらないが、上流がいろいろ変わっている。

以前はibookとmpdを使ったusbオーディオが中心だったんだけど、そこからRaspberry PiとVolumio、i2sボードを使った方法に移行している。
更に、最近はRaspberry pi2のRAMに音楽ファイルを丸ごと読み込んで再生するメモリ再生方式も取り入れている。 なかなかこれがいい感じだ。

NASからRaspberry piまでの間にはハブを3つ噛ましている。
これはジッター軽減を目指しての所作。
しかしメモリ再生が中心になってくると、あんまり意味がないということになるかも。

DACはfireface UCXに変更になっている。
これに伴って、以前にSRC2496に使おうとしてうまくいかなかったnanoclocksを復帰させている。中古だから壊れているかもと思っていたら、ちゃんと繋がった。しかし、効果のほどは不明だ。
SRC2496はシステムから外れた。

VRDS-25xsは、リッピングしていないCDをちょい聴きするときに使う。ちょい聴き用だからデジタル出力をSM-SX100のデジタル入力に入れている。あんまり推奨される使い方ではない。
DP-5090は子供用。VRDS-25xsを子供に使わせるのはCDがトレイに付いたりして危なっかしい。なんでSM-SX100のTOSに直接入力していないかというと、SM-SX100のセレクターが不調でTOS入力が選択できないからだ。同軸入力はBNCとCOAXがあるので変換したら何とかなる。

SM-SX100は本当にいいアンプだと思うんだけど、生産終了し何年もたったシャープに修理に出すのがちょっと不安な感じになってきている。
nmodeのアンプを入手すべきか、などと考えたりする。

タイトルに２とあるが、実はメモリ再生はpiCore7よりも前にraspbianで成功していた。
そもそも、デバイスの設定をconfig.txtに書き込むとalsaが認識してくれるというのは、raspbianで試みて気付いたことだった。piCore7だけいじっていたときにはこれに気付かず、諦め、まあ気を取り直してraspbianでやってみっか、、、で、気付いたのだ。

ネットで探してもpiCoreのalsaの設定の仕方はよく分からない。
僕は出来合いのi2sDACでhifiberryから設定をもらえたので簡単だったが、USB-DACとかつなぐ場合の設定は全く分からない

それはともあれ。
大したことはないけど、これも備忘録にしておく。

raspbianをmicroSDにインストール、i2sデバイスを設定

僕が使ったのはRaspbian Jessie Liteだ。 https://www.raspberrypi.org/downloads/raspbian/ 上記のサイトからダウンロードできる。

これをmicroSDに焼いて、config.txtにi2sデバイスの設定を書き込む。
下記サイトを参考。
https://www.hifiberry.com/guides/configuring-linux-3-18-x/

raspbianをRas Piで起動した後で、/boot/config.txtに書き込んで再起動でもかまわない。
ちなみにpiCore7だとブート後はconfig.txtが見えなくなる。

ファイルイメージの拡張

Ras Piに刺して起動し、sshでログインする。
ユーザーはpi、パスワードはraspberry。

そこで以下のコマンドでファイルイメージを拡張しておく。ついでにローカル設定とかもしておく。
pi@raspberrypi:~ $ sudo raspi-config

alsaインストール

下記のコマンドでインストール。

pi@raspberrypi:~ $ sudo apt-get install alsa-base

swapを止める

ほっとくと100MB程がswapに取られてしまうので設定しなおす。
コマンドなど経過は下記のとおり。
本当はpiCoreでも止めたいんだけど、こっちは方法が分からない。まあ、音楽ファイル用にswapが使われるので放置でもいいんだろうけど、止めるほうがすっきりしてるんじゃないかという気がする。

pi@raspberrypi:~ $ free
             total       used       free     shared    buffers     cached
Mem:        445124     191848     253276       4460      12388     150836
-/+ buffers/cache:      28624     416500
Swap:       102396          0     102396

pi@raspberrypi:~ $ swapon -s
Filename				Type		Size	Used	Priority
/var/swap                              	file    	102396	0	-1


 pi@raspberrypi:~ $ sudo swapoff --all

pi@raspberrypi:~ $ free
             total       used       free     shared    buffers     cached
Mem:        445124     191848     253276       4460      12396     150852
-/+ buffers/cache:      28600     416524
Swap:            0          0          0
pi@raspberrypi:~ $ 


pi@raspberrypi:~ $ sudo apt-get remove dphys-swapfile
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  dc
Use 'apt-get autoremove' to remove it.
The following packages will be REMOVED:
  dphys-swapfile
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 85.0 kB disk space will be freed.
Do you want to continue? [Y/n] Y
Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_TIME = "en_US.UTF-8",
	LC_MONETARY = "en_US.UTF-8",
	LC_MEASUREMENT = "en_US.UTF-8",
	LC_NUMERIC = "en_US.UTF-8",
	LC_PAPER = "en_US.UTF-8",
	LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 31037 files and directories currently installed.)
Removing dphys-swapfile (20100506-1) ...
Processing triggers for man-db (2.7.0.2-5) ...
pi@raspberrypi:~ $ 

pi@raspberrypi:~ $ sudo reboot

pi@192.168.1.116's password: 
Last login: Mon May 23 23:41:23 2016 from 192.168.1.52

pi@raspberrypi:~ $ free
             total       used       free     shared    buffers     cached
Mem:        445124      62396     382728       4456       6096      31940
-/+ buffers/cache:      24360     420764
Swap:            0          0          0
pi@raspberrypi:~ $ 

freeのメモリが250MBから380MB以上に増えている。

音楽ファイルの置き場をram diskで設定

以下のとおり。意味があるのかどうか分からないが。

pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.6G  890M  2.5G  26% /
devtmpfs        214M     0  214M   0% /dev
tmpfs           218M     0  218M   0% /dev/shm
tmpfs           218M  4.4M  213M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           218M     0  218M   0% /sys/fs/cgroup
/dev/mmcblk0p1   63M   21M   43M  33% /boot

pi@raspberrypi:~ $ 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       /home/pi/music     tmpfs    defaults,size=400m 0      0  

pi@raspberrypi:~ $ sudo reboot

pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.6G  890M  2.5G  26% /
devtmpfs        214M     0  214M   0% /dev
tmpfs           218M     0  218M   0% /dev/shm
tmpfs           218M  4.4M  213M   3% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           218M     0  218M   0% /sys/fs/cgroup
tmpfs           100M     0  100M   0% /home/pi/music
/dev/mmcblk0p1   63M   21M   43M  33% /boot

flacをインストール、mpdをインストール

以下のコマンドでインストールできる。

pi@raspberrypi:~ $ sudo apt-get install flac
pi@raspberrypi:~ $ sudo apt-get install mpd

あとはmpd.confを編集してmpdを動かすだけで音が出るはず。

http://www.yung.jp/bony/ こちらのサイトで５月頃から興味深い試みの報告が行われている。
mpdサーバのRAMに音楽ファイルを読み込んで再生したら、NASをマウントするよりもサーバの負担が少ないので音質改善が見込めるのではないかという話だ。
うちでも昔、NASを交換したときの音質変化に驚いたことがある。
機種によってはcifs、nfsでマウントすることが負担になるNASがあるようで、そうした機種だと音が悪くなる。データの転送自体が不安定になってジッタが増加するのが原因だと思う。
そうした経験があったので「メモリ再生でNAS接続の負担から開放される」という話は、なるほどそうか、という思いだった。

試みたいが、うちにはTiny Core Linuxを走らせるハードがないから出来ないな、と思っていたら、Ras PiでPiCoreという派生OSを走らせることが出来るという。
これは面白そうだ。

結局、raspbianとpiCore7にmpdをインストールした。少々苦労したがなんとかなったので備忘録にしておく。
今回はpiCore7について。

microSDの準備。

piCore7はここから落としてくる。 http://tinycorelinux.net/7.x/armv6/releases/RPi/
これをmicroSDに焼く。

次に、下記のサイトから設定をもらってくる。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

選択する機種によって設定が違うので合わせてconfig.txtに記載する。
ついでに、もとからある設定について下記のように記載変更した。
dtparam=i2c=off,spi=off,i2s=on,i2c_vc=off

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

microSDをRasPiに刺して電源供給するとpiCoreが起動する。
sshでログイン。
ipはxxx.xxx.xxx.116。ここらは環境によって変わる。
http://tinycorelinux.net/7.x/armv6/releases/RPi/README にも書いているが、userはtc、パスワードはpiCoreだ。

適宜、下記のコマンドで設定を保存していく。

filetool.sh -b

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)

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

#!/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

tc@box:/opt$ ls
alsa/         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
drwxr-sr-x    2 root     staff           40 May 31 08:36 alsa/
-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

#!/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 &

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

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/
etc/fstab
opt/bootlocal.sh
opt/eth0.sh

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

ディスクイメージを拡張。

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

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

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 192.168.1.116 closed by remote host.
Connection to 192.168.1.116 closed.



tc@192.168.1.116'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 にも書いているが、ちょっと不親切。
コマンドの使い方を調べる必要があった。

各種ライブラリやalsa、flacなどなどインストール。

下記のコマンドでいろいろインストール。

tc@box:~$ tce-load -wi gcc.tcz glib2-dev.tcz
tc@box:~$ tce-load -wi ncurses.tcz ncurses-dev.tcz make.tcz automake.tcz
tc@box:~$ tce-load -wi compile-essentials.tcz squashfs-tools.tcz bash.tcz bc.tcz
tc@box:~$ tce-load -wi pkg-config-doc.tcz pkg-config.tcz

tc@box:~$ tce-load -wi alsa.tcz alsa-config.tcz alsa-doc.tcz alsa-dev.tcz alsaequal.tcz alsa-locale.tcz alsa-modules-4.1.13-piCore+.tcz alsa-modules-4.1.20-piCore+.tcz

tc@box:~$ tce-load -wi flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz icu-dev.tcz icu.tcz

ぞろぞろ文字やらなにやらインストールの状況が端末に表示される。
なかなか面白い。

当方ではflacをcue sheetで扱えれば充分なので上記のような感じだけど、他に扱いたいファイル形式があるなら適宜必要なものを追加してインストールしておく必要がある。

alsaはユーティリティとかなくてもいいのか？と思ってたけど、なくてもデバイスの認識は出来て音も出るようだ。
この時点でこんな感じ。

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

mpdのインストール。

将来的には分からないけど５月３１日の時点では、tce-load -wi mpd.tcz ではインストールできない。
libopus.tczがないとかでエラーになる。

なのでソースから自分でコンパイルしてということになる。
以下、コマンドを羅列。

tc@box:~$ wget https://www.musicpd.org/download/mpd/0.17/mpd-0.17.6.tar.gz
tc@box:~$ tar xvf mpd*
tc@box:~$ cd mpd*6
tc@box:~/mpd-0.17.6$ ./configure
tc@box:~/mpd-0.17.6$ make

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

tc@box:~$ mksquashfs mpd mpd-0.17.6.tcz
tc@box:~$ ls
mpd/               mpd-0.17.6/        mpd-0.17.6.tar.gz  mpd-0.17.6.tcz
tc@box:~$ md5sum mpd-0.17.6.tcz > mpd-0.17.6.tcz.md5.txt
tc@box:~$ ls
mpd/               mpd-0.17.6/        mpd-0.17.6.tar.gz  mpd-0.17.6.tcz  mpd-0.17.6.tcz.md5.txt

tc@box:~$ ls /mnt
mmcblk0p1/ mmcblk0p2/
tc@box:~$ sudo mv *tcz* /mnt/*2/tce/optional

コマンドの羅列にしたら、こんな感じ。
本当は間に文字やら何やらが表示される。

まずwgetコマンドでmpdのサイトからソースを落として解凍。
解凍されたディレクトリでconfigure、make。

ここから後が通常のlinuxと違うところで、mpdフォルダを作ってそこに一式まとめて、make installする。
その一式を、mksquashfsコマンドでtczファイルに圧縮。
md5sumコマンドで付録をつけて、/mnt/mmcblk0p2/tce/optionalディレクトリに送り保存する。
これで管理するのがtiny coreの作法ということだ。

次に、onboot.lstの末尾に、mpd-0.17.6.tczを追記する。

tc@box:~$ sudo vi /mnt/*2/tce/onboot.lst

ちなみに、mpd-0.17.6、mpd-0.16.8はインストールできた。 mpd-0.18.19、mpd-0.19.4、mpd-0.19.5はインストール自体ができなかったり実用にならなかったりしている。

RAMDISKでmusicフォルダを設定

tc@box:~$ sudo mkdir music
tc@box:~$ sudo chmod 777 music

tc@box:~$ sudo vi /etc/fstab
tc@box:~$ 
# /etc/fstab
proc            /proc        proc    defaults          0       0
sysfs           /sys         sysfs   defaults          0       0
devpts          /dev/pts     devpts  defaults          0       0
tmpfs           /dev/shm     tmpfs   defaults          0       0
/dev/zram0  swap         swap    defaults,noauto   0       0
/dev/mmcblk0p1  /mnt/mmcblk0p1  vfat     noauto,users,exec,umask=000 0 0 # Added by TC
/dev/mmcblk0p2  /mnt/mmcblk0p2  ext4     noauto,users,exec    0 0 # Added by TC

tmpfs       /home/tc/music     tmpfs    defaults,size=400m 0      0

これは意味があるのかどうか良く分からない。RAMDISKとして設定しなくても動くみたいだ。
sftpソフトでアクセスして/home/tc/musicに音楽ファイルを転送する。
mpd.confで、ここをmusic_directoryに設定する。

.filetool.lstへの追記

これは、うちの環境で意味があるのかどうか分からないんだけど、一応。

sudo vi /opt/.filetool.lst

以下の３行を追記している。

usr/local/etc/
etc/fstab
opt/bootlocal.sh

bootlocal.shにmpdを記載することでboot時に起動するとかあるようなんだけど、うちでは上手くいかなかった。sshでログインしてmpdコマンドを打って起動させている。

mpdの設定。

tc@box:~$ 
tc@box:~$ mkdir .mpd
tc@box:~$ mkdir .mpd/playlists
tc@box:~$ sudo cp mpd-0.17.6/doc/mpdconf.example ~/.mpdconf
tc@box:~$ 
tc@box:~$ sudo vi .mpdconf

mpd.confを設定する。
mpdのINSTALLファイルにデフォルト指定があるので、そのひとつの~/.mpdconfを選択。
music_directoryなどの設定、alsaを出力に設定。
後は勝手知ったるもので、好きなように設定したらいい。
auto_updateを有効にしておけば、ファイルを入れ替えたらすぐに反映されるので便利。

とりあえず、以上だ。

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

オーディオは鳴らすばかりで音質への配慮をしてない日々が続いている。
気がつけば年が明けて旧正月を迎えようとしている。
覚書として、cue sheetの中を検索する方法をメモっておく。
うちではNAS上のフォルダを手元のノートにマウントしてることが多いのでそこで使うことが多いが、やってみたらvolumioにsshでログインした時も使うことができた。
ただ、うちのvolumioはカーネルをアップしている。アップしてない場合は試していない。

リッピングをCD単位でflacとcue sheetにして管理しているとファイルが少なくて済むのはいいのだけど、個別の曲についてどのファイルに入っているんだろう？となったときに困る。
よく知ってるアルバムならわかるけど（例えばしっかりジョンはジョンの魂に入ってるとか）、クラシックになってくると１つのCDに複数の作曲者や演奏者がいることが当たり前だ。ファイル名にそれらを全部入れるわけにいかないし。
そういうわけで複数のcue シートの中を一括で検索したいということになる。

あちこち調べた結果、find、grep、パイプでlessで表示、でやれることがわかった。
以下、volumioでの流れをコピペ。

root@192.168.1.81's password: 
Linux volumio81 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l
                       ___                                      
                      /\_ \                        __           
         __  __    ___\//\ \    __  __    ___ ___ /\_\    ___   
        /\ \/\ \  / __`\\ \ \  /\ \/\ \ /' __` __`\/\ \  / __`\ 
        \ \ \_/ |/\ \L\ \\_\ \_\ \ \_\ \/\ \/\ \/\ \ \ \/\ \L\ \
         \ \___/ \ \____//\____\\ \____/\ \_\ \_\ \_\ \_\ \____/
          \/__/   \/___/ \/____/ \/___/  \/_/\/_/\/_/\/_/\/___/ 
        
             Free Audiophile Linux Music Player - Version 1.55

                 C 2013 Michelangelo Guarise - Volumio.org
                    192.168.1.81 hifiberryDigi+

Volumio Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jan 19 06:15:14 2016 from 192.168.1.23
root@volumio81:~# ls /mnt
NAS  UPNP  USB
root@volumio81:~# cd /mnt/NAS
root@volumio81:/mnt/NAS# ls
hs210
root@volumio81:/mnt/NAS# cd hs*
root@volumio81:/mnt/NAS/hs210# ls
audio_check  classic  ethnic  jazz  kids  pop
root@volumio81:/mnt/NAS/hs210# find classic -type f -name "*.cue" -exec grep -C 1 -H -i "telemann" {} \; | less

volumioにsshでログインし、 マウントされてるNASの音楽フォルダまで移動する。
そこにはファイルが階層化されたディレクトリに分別されてるので、探したいフォルダの中のcue sheetの中を検索するという流れ。
hs210というディレクトリの下層に、audio_check classic ethnic jazz kids pop、というディレクトリがある。
一番下のコマンドは「classic」というディレクトリのなかの、末尾が「.cue」というファイルすべてを探して、その中の「telemann」という言葉を含む行を検索して、結果をlessで表示してね、って感じ（lessというのはlinuxのテキストビューアだ）。
コマンドにオプションが色々付いているけど説明は省略。

検索結果が、以下のような感じで表示される。
ごちゃごちゃした感じで、使いやすいというわけじゃないけど、ないのに比べたら相当助かっていると思う。

classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-  TRACK 09 AUDIO
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue:    TITLE "Telemann, GP - Concerto for violin, strings & continuo - 1 Adagio"
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-    PERFORMER "Daniel Hope"
--
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-  TRACK 10 AUDIO
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue:    TITLE "Telemann, GP -Concerto for violin, strings & continuo - 2 Allegro"
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-    PERFORMER "Daniel Hope"
--
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-  TRACK 11 AUDIO
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue:    TITLE "Telemann, GP - Concerto for violin, strings & continuo - 3 Presto"
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-    PERFORMER "Daniel Hope"
(END)

cue sheetのパスと、そこに記載された文字列が表示される。
ちなみに「grep -C 1」とコマンドを打っているので、検索に引っかかった行の前後１列も表示されている。この辺はオプションの設定次第で、-Aで後の行、-Bで前の行とか設定できる。「-C 1」の代わりに「-1」でもいいようだ。
うまくスクリプトに出来たらいいんだろうけど、そこまでは出来ていない。