abk1's scratched blog 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１年以上、I-O DATAのHDL2-A6.0をオーディオ用のNASとして使用してきたのだけど、先日のＧＷに入れ替えた。
オーディオルームで使うにはファンのノイズが大き過ぎる。「静かでＡＶ用に問題ない」という評価をネット上では見かけるが、僕はオーディオルームには不適だと思う。

代替機種はQNAPのTurboNAS HS-210にした。
ファンレスというのが大きかったと思う。
従来のQNAPのNASとは音が違うという話もあるので迷ったが、たぶん悪くはないに違いない、と判断した。

ＧＷの最終日にHS-210が届いた。
梱包から出して、HDDを組み込み、LANとACアダプターをつないで、電源を入れる。
そこで設定をはじめる。
WebブラウザでQNAPのサイトにいく。
ファームのインストールにWindows、Mac、Linuxに対応しているとある。

Linux用のツールをダウンロードしてみたのだけど、これがUbuntuの新しいOS用、とある。しかも４つほどなにやらインストールしておかないといけないらしい。
うちのPCノート(Compac6730b OS:Vine Linux 6.1)には４つとも入っていない。
ものはためし、と説明に書かれているコマンドを打ってみたけど、やっぱり何もおきない。

Linuxはあきらめて、Mac miniにMac用のツールをダウンロードしてここに書いてあるみたいな感じでファームをインストールした。
ファームのインストールさえ済んだら、設定はどのパソコンのWebブラウザでも出来る。

その後、設定をするのだけど、よく分からないのは、DLNAサーバとかダウンロードサーバとか、要るの？と思うようなのがいろいろ動いているらしいこと。必須と表示されているのもあったりして、勝手に止めていいものかどうかもよくわからないので、現時点で放置している。
共有フォルダもいろいろと元から設定されている。
だけど、そういうのは無視して新規で自分の好きな名前の共有フォルダを作る。
ここに音楽ファイル（flacとcue）を置く。

データの転送はHDL2-A6.0とHS-210、各々の共有フォルダをCompac6730b上のマウントポイントにマウントして行った。
以前に別件でネットワークフォルダ経由（たぶんSambaだと思う）でデータ転送したら、300GBに１５時間かかった経験があったので、マウントした方がいいのではないかと考えた。

ターミナル上からcpコマンドを使って転送してみたら、50MB/sで１０時間で転送できた。
思ったよりずいぶん速かった。

HS-210にはtelnetでログインできて、コマンドで操作が出来る。だから当初はHS-210上にマウントポイントを作って、HDL2-A6.0の共有フォルダをマウントしてcpしてしまおうと思っていた。
だけど残念なことに、HS-210にはmount.nfsはインストールされていたけど、mount.cifsはインストールされていなかった。
HDL2-A6.0は、mount.cifsでのマウントは受け付けるけど、mount.nfsは受け付けないのだ。
連休が終わる前にHS-210にmount.cifsをインストールして転送を終了するというのは僕の手に余る。
それで、Compac6730bで中継することになった。
一晩で転送できたのだから上出来だ。

音質はどうかということについては、例によってちゃんと評価は出来ていない。
家族もいるので、十分な評価が出来るだけ音量を上げて聴くことがなかなか出来ないということがある。
あと昨日気付いたのだけど、音量を上げたら部屋の中の何かが共振する。何なのかは特定できていない。
しかしそれでもNASから聞こえるノイズが全くなくなったせいか、小音量でも音が良くなったような気がしてしまう。

音切れがなくなったことも大きい。
最近、HDL2-A6.0だと音切れを気にせずに音楽を聴くことが出来なくなっていた。
原因ははっきりしない。
家庭内LANのDHCPサーバを兼ねているCTU装置を再起動したらずいぶんマシになったので、ネットワークが安定しないせいで音が途切れるということは明らかなんだけど、それでも完全にはなくならなかった。
HS-210に変更して今のところ音切れはない。
なんだったんだろう？というぐらいない。

Compac6730bにインストールしたmpdによる再生で、マウントしたNASを切り替えながらのイヤホンでの比較試聴をしてみた感じだと、HS-210のほうが細やかな音が出ていると感じる。
HDL2-A6.0のほうは音に若干にじみがあるように聞こえる。その分ラウドで勢いがあるようにも聞こえるけど。
音の定位もHS-210のほうが明確な気がする。

HDL2-A6.0はクライアントPCのWebブラウザからコントロール・設定をするのだけど、以前はなかなかアクセスできないということがあった。
ログイン画面が開くまで数分以上待たされるぐらいならいいほうで、そこに到達できないこともあった。
ログイン自体も時間がかかり、設定画面にたどり着くのに１０数分を要していた。
ほとほとこれにもうんざりしたというのもNAS交換の理由だ。

HDL2-A6.0は共有フォルダをmpdサーバー上のマウントポイントにマウントして運用していた。
今回、データ移行したあとでアンマウントしたところ、前述したログインがいとも簡単にできるようになった。
もしかしたら、共有フォルダをマウントポイントに載せること自体がHDL2-A6.0にとって負担なのかもしれない。

前述のCompac6730b+mpdでの比較試聴で、HDL2-A6.0は当初は静かだったのだけど、徐々にファンのノイズが増えて「やっぱりまずいのかこれは」という様子だった。
Webブラウザからのアクセスもやや重くなったような印象だった。

どうしたらこんなことにならずに運用できるのか、現時点でははっきりしない。
共有フォルダに置いているファイルが多すぎるのかもと思って、新しい共有フォルダを作ってファイルの転送コピーを試みていたら、ごっそりファイルが消えてしまった。
原因は不明である。
当面、ファイルがなくなってもいい状況で使用するしかなさそうだ（どんな状況なのやら）。

よくそんなので１年以上も使ってたよと思われるかもしれないが、たぶん日々オーディオ三昧だったらもっと早く交換していただろうと思う。短時間しか聴くことができない生活状況なので、心底いやになる前に再生を止めて、いやな気分は忘れることに結果的になっていたのだと思う。
あと、なんか原因究明というのにのめり込む癖があるんだと思う。良し悪しだ。
それでずるずるとこれまで来てしまった。

ファイルを喪失する前にNASの変更が間に合って、本当によかったと思うよ。

XPのサポートが終わるので７に移行。
これに伴いEACを再インストールしたんだけど、やっぱりいろいろ忘れてるので覚書にしておく。

インストールについて。
こちらがダウンロードのページ。
http://www.exactaudiocopy.de/en/index.php/resources/download/
現在、サイトのトップに「最新の日本語版を 無料でダウンロードする。」と書いてあるボタンが表示されることがあるんだけど、これは「hao123という怪しいのとか抱き合わせにインストールするけどいいよね」という最悪なインストーラをダウンロードするサイトにリンクしている。最新の日本語版とか、よく分からない。
EAC単体のインストーラを本家のダウンロードページから簡単に落とせるので間違えないこと。

インストールに際して、音楽ファイルの保存形式を選択するウィンドウが出たりする。このとき選択しておけばたぶん後々面倒がない。僕はflacを選択している。

日本語化のページはこちら。お好みで。
http://sonicdisorder.net/eacinstall.php
最初のEAC起動の前にファイルを入れるということが書いてあるが、後からでも問題ない。再起動したら反映される。

設定。
ドライブオプション。
インストール直後だとギャップ検出がセキュアになってないので、これを直す。以前、設定がおかしいというエントリーを上げたが、どうもインストール直後のデフォルトはInaccurate（不精密）らしい。検出方法は僕はＡを基本にしている。
取り込み方法の設定、ドライブのタグから読み出しコマンドの設定を行う。
オフセットのタグからAccurateRipを設定。

エンコードオプションの外部エンコーダタグを設定する。
インストール時にflacを選択しているからか、既に表示されている。
「追加のコマンドラインオプション」でファイルに書き込まれるタグの内容が設定されているので、これを自分の都合のいいように編集しておく。
僕の場合、ＣＤ単位のflacとcue sheetで保存すると決めているので、ARTISTやTITLEを「ARTIST=%albumartist%"　"TITLE=%albumtitle%」に変更しておく必要がある。こうしておかないとflacファイルのTrack Titleというタグに、なぜかＣＤの２曲目の曲名が書き込まれる。２曲目がないＣＤだったら何も書き込まれない。
これが、mpdで再生するときクライアント上の表示に反映される。
意味もなく２曲目が表示されてるからといって再生自体の不具合はないけど、あんまり気持ちいいものではない。
ちなみにタグと書いたが、flacの場合はID3タグではなく、FLAC tagsとVorbis commentsに対応してるとのことらしい。必要ないならID3タグは書き込まない設定のほうが無難かもしれない。

メタデータオプションのfreedbタグではfreedbサーバを「http://freedbtest.dyndns.org:80/~cddb/cddb.cgi」に設定。日本語に強いということらしい。

だいたいこんな感じか。

必要がないのに動いているdaemonを停止することで音質向上が見込めるということでやってみた。
そんなに期待してなかったという面があるからかもしれないが、期待以上の変化があった。
画像で例えると、640*480が1600*1200になるような感じ、というと言い過ぎか。
解像度が上がり見通しが良くなる。

最近は過渡特性とかトランジェントと呼ぶらしいが、音声の立ち上がり、立下りが良くなってリアリティが増してくる。肌理細かい音になるので、打楽器のアタック音は際立つけれど耳に障らない音で再生される。ボーカルは細やかなニュアンスが再現されるようになる。
そういう感じを求めているんだけど、デーモンの刈り込みで求めるところに近づくと思う。
楽器の音とか優れた歌い手の声というのは本来から快い音なので、上手く再生されるとそれだけで音楽自体の好みとか関係なく聞き惚れてしまうということがある。オーディオマニアは音ばかり聴いて音楽を聴いてないというけど、それも仕方ないじゃないかという状況になるのが目標といっていいかもしれない。

現在の状況は以下の通り。
刈り込んだデーモンは赤色表示。起動中は青。

[root@localhost ab]# chkconfig --list 
NetworkManager  0:off   1:off   2:on    3:off   4:on    5:on    6:off 
anacron         0:off   1:off   2:on    3:off   4:on    5:on    6:off 
apache2         0:off   1:off   2:off   3:off   4:off   5:off   6:off 
atalk           0:off   1:off   2:off   3:off   4:on    5:on    6:off 
atd             0:off   1:off   2:off   3:off   4:on    5:on    6:off 
autofs          0:off   1:off   2:off   3:off   4:on    5:on    6:off 
avahi-daemon    0:off   1:off   2:off   3:off   4:off   5:off   6:off 
avahi-dnsconfd  0:off   1:off   2:off   3:off   4:off   5:off   6:off 
bluetooth       0:off   1:off   2:off   3:off   4:on    5:on    6:off 
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off 
cups            0:off   1:off   2:on    3:off   4:on    5:on    6:off 
dhcpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off 
dhcrelay        0:off   1:off   2:off   3:off   4:off   5:off   6:off 
dkms_autoinstaller      0:off   1:off   2:off   3:off   4:off   5:on    6:off 
dnsmasq         0:off   1:off   2:off   3:off   4:off   5:off   6:off 
dovecot         0:off   1:off   2:off   3:off   4:off   5:off   6:off 
firstboot       0:off   1:off   2:off   3:off   4:off   5:on    6:off 
haldaemon       0:off   1:off   2:off   3:off   4:off   5:on    6:off 
iptables        0:off   1:off   2:off   3:off   4:on    5:on    6:off 
irqbalance      0:off   1:off   2:off   3:off   4:off   5:off   6:off 
iscsi           0:off   1:off   2:off   3:off   4:off   5:off   6:off 
iscsid          0:off   1:off   2:off   3:off   4:off   5:off   6:off 
lirc            0:off   1:off   2:off   3:off   4:off   5:off   6:off 
mdmonitor       0:off   1:off   2:off   3:off   4:off   5:off   6:off 
mdmpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off 
messagebus      0:off   1:off   2:on    3:off   4:on    5:on    6:off 
named           0:off   1:off   2:off   3:off   4:off   5:off   6:off 
netfs           0:off   1:off   2:off   3:off   4:on    5:on    6:off 
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off 
nfs             0:off   1:off   2:on    3:off   4:on    5:on    6:off 
nfslock         0:off   1:off   2:on    3:off   4:on    5:on    6:off 
nmb             0:off   1:off   2:off   3:off   4:off   5:off   6:off 
nscd            0:off   1:off   2:off   3:off   4:off   5:off   6:off 
ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off 
portmap         0:off   1:off   2:off   3:off   4:on    5:on    6:off 
postfix         0:off   1:off   2:on    3:off   4:on    5:on    6:off 
proftpd         0:off   1:off   2:off   3:off   4:off   5:off   6:off 
random          0:off   1:off   2:on    3:on    4:on    5:on    6:off 
rdisc           0:off   1:off   2:off   3:off   4:off   5:off   6:off 
rpcidmapd       0:off   1:off   2:on    3:off   4:on    5:on    6:off 
saslauthd       0:off   1:off   2:off   3:off   4:off   5:off   6:off 
smb             0:off   1:off   2:off   3:off   4:off   5:off   6:off 
sshd            0:off   1:off   2:off   3:off   4:off   5:on    6:off 
syslog          0:off   1:off   2:on    3:on    4:on    5:on    6:off 
udev-post       0:off   1:on    2:on    3:on    4:on    5:on    6:off 
uuidd           0:off   1:off   2:on    3:on    4:on    5:on    6:off 
winbind         0:off   1:off   2:off   3:off   4:off   5:off   6:off 
wpa_supplicant  0:off   1:off   2:off   3:off   4:off   5:off   6:off 
xinetd          0:off   1:off   2:off   3:on    4:on    5:on    6:off 
 
xinetd ベースのサービス: 
        chargen:        off 
        chargen-udp:    off 
        cups-lpd:       off 
        daytime:        off 
        daytime-udp:    off 
        echo:           off 
        echo-udp:       off 
        rsync:          off 
        services:       off 
        swat:           off 
        telnet:         on 
        time:           off 
        time-udp:       off 

atalkやbluetoothなど以前から止めてあったdaemonもあるが、分からないものは放置していた。
手始めにsshdから止めて、 irqbalance、 iscsi、iscsid、 mdmonitor、 avahi-daemon、 dkms_autoinstaller、 firstboot、 netfs、nfs、nfslock、rpcidmapd、portmap、 NetworkManager、 iptables、 haldaemon、messagebus、 anacron、atd、autofs、と止めてしまった。
今のところ、システムは安定していて問題は出ていない。

コマンドについて覚書。

# chkconfig --level 345 iscsi off

上記のような感じでランレベル、サービス名、on/off、で設定する。
システムを再起動したら元に戻ってしまう場合もあるらしいが、Vine Linux 5.2 ppcの場合はこれだけで再起動後にも反映される。

それにしても随分止めたものだ。
haldaemon、messagebusなどはサイトによってはOFFにすべきではないデーモンに分類されている。実際、Powerbookのほうでもあれこれと止めていたらマウスの入力を受け付けなくなって慌てた。
正直なとこ、最後のほうになってくると音がよくなってるのかどうかはっきりしない。十分な試聴が出来ないので評価しないままどんどん止めている。本当は評価しながらしたほうがいいのだろうけど、なかなか難しい。

以下、参考にしたサイト。

http://www.d3.dion.ne.jp/~koetaka/demon2.html 不要なサービスを停止する STARTUP LINUX
http://www.obenri.com/_minset_cent5/daemon_cent5.html ◇不要デーモンの停止(CentOS5)◇☆お便利サーバー.com☆
http://www.obenri.com/_minset_wbel3/daemon_wbel3.html ◇不要デーモンの停止(WBEL3)◇☆お便利サーバー.com☆
http://d.hatena.ne.jp/weblinuxmemo/20090911/p1 不要なサービスの停止 - Linux Memo: Vine Linux 5 設定 tips
http://ikubo.x0.com/unix/CentOS50_stop_Service.htm 不要なサービスを止める (CentOS 5.0)
http://linux.rakunet.jp/linux/service_stop/service_stop.html 不要なサービスを停止
http://www.kozupon.com/etc/daemon.html Kozupon.com - 不要なデーモンの停止とシステムのセキュアー化！

他にもあちこち見て回った。

自分用にdaemonの一覧表を作ることにした。
前述のサイトから記述をもらったりしている。この場で申し訳ないけど御礼申し上げます。

mpd.confの記載内容に関して。
過去のエントリーで以下のように書いていた。

# MPD Internal Buffering ####

audio_buffer_size		"384"
buffer_before_play		"5%"
#

ここの設定について追記。新規エントリーにする。
参考にリンク。
http://linux.die.net/man/5/mpd.conf

「audio_buffer_size」と「buffer_before_play」のデフォルトは2048と10%らしい。これらを変更することで音質が変わるという。
「audio_buffer_size」の数値はkbである。
「buffer_before_play」はaudio_buffer_sizeのうち何％使うかを０～１００％の範囲で設定できる。

5%は少なめの設定だが、384kbの5%ということなら20kb弱だ。
この数値にどういう意味があるのか分からない。
ひどく少ない。
256kbの５％だと12.8kbになってしまう。
これは44.1/16の音楽データだと0.1秒に満たない。384kbの5%だと0.1秒を超える。
384kbの5%は、44.1/16の音楽データだと0.1秒を超えるぐらい。
しかしうちでは88.2/24にアップサンプリングしてるので、0.1秒よりもっと短いはずだ。

上記の設定で、CD１枚単位をflac+cue sheetにリッピングしたものを通して再生する分には、全く問題ない。
しかしiTSから買ったアルバムを通して聴く場合だと、ライブ盤を再生すると音が途切れるのが分かる。m4aをギャップレス再生できないのだ。
384kb/5%では足りないのだろうか。

bufferに関連してリンク。
http://mpd.wikia.com/wiki/Music_Player_Daemon_Crossfading_Troubleshooting
リンク先から引用してみる。

MPD does crossfading by using the buffer.
The amount of buffer used for crossfading is the size of the buffer minus the amount of space reserved for buffer_before_play.
By default (2MB buffer and 25% buffer_before_play) this is approximately 9 seconds of crossfading for 44.1 khz, 16-bit, stereo audio.
If you have the buffer_before_play set to 100%, there will be no crossfading.

crossfadingという操作がmpdクライアントから設定できる。
曲再生が終わって次の曲に移る際に数秒間かぶるように出来る（秒数も設定できる）。

ここで書かれていることから推測するに、buffer_before_playで使われる以外のbufferに、crossfadingのためのデータを読み込むということらしい。
こうした特別な使途がないなら、ほとんどなくてもいいbufferなのかもしれない。
逆に、before playとcrossfading以外で使うことがあれば不具合があるかもしれない。
ギャップレス再生の不具合とは関係があるのだろうか。
http://linux.die.net/man/5/mpd.confには「Try increasing this if you hear skipping when manually changing songs.」とあるが、skippingというのがどういう状態かよく分からない。

みみず工房掲示板からも引用する。

audio_buffer_size
decoderスレッドからoutputスレッドへデータを受け渡すfifoバッファーのサイズです。
buffer_before_play
audio_buffer_sizeのデータがこれより少なくなるとdecoderが動いてバッファーにデータを追加します。
再生開始時はバッファーにデータがこの値になるまで開始されません。
この値を100%にすると常に空きが出ないようにdecoderが動きます。

ここも参考にリンク。
http://d.hatena.ne.jp/propella/20061202/p2 ALSA PCM プログラミングのサウンドバッファ - 言語ゲーム

「audio_buffer_size "384" buffer_before_play "5%"」だと、20kb弱のbufferを切らさないようにdecoderが動いてるってことになる？
audio_buffer_size "1024" buffer_before_play "100%"といった設定だと、1MBのbufferを常に抱えることになる。
全く状況が違ってくるだろう。
常にdecoderが動いてるというのは望ましい状態なのかどうか。
buffer_before_playが100%だと常にdecoderが動くということだけど、buffer_before_playが小さい場合もdecoderが動く頻度が多くなると思う。
再生音にどんな変化があるのだろう。

どんな設定がいいのか、試行錯誤してみる。

こういう試行錯誤がやりやすくなった背景にはibook G4をtelnetサーバーにしたということがある。
当初はsshを考えていたんだけど「鍵」の扱いが面倒でやめた。もしかしたら鍵を使わない設定も出来るのかもしれないが分からなかった。家庭内LANなのでと割り切ってsshdも止めてしまった。

telnetサーバーはVine Linux ppc 5.2には最初からは入ってないので、Synapticパッケージマネージャを使ってインストールした。
当然だけどtelnetを使うと何かと楽だ。いちいちオーディオラックの下からibookを引っ張り出す必要がないし、ncmpcppを操作しながら、同じ画面でmpdサーバーの状況も操作できるというのは面白い。

クラシックの歌劇のCDを曲ごとにリッピングし、flacで保存したものを再生する。
「audio_output_format」は44.1kHz、16bitに固定した。

まず「audio_buffer_size "256"」にしてみる。
「buffer_before_play」の値は、0、10、50、100と換えてみた。
結果、これでは数秒間しか音が出ないことが分かった。
256では駄目みたいだ。

次に「audio_buffer_size "264"」にしてみる。
再生自体に問題はない。
しかし「buffer_before_play "100%"」にするとncmpcppでFキーを押して早送りすると、そのあと音が出なくなるなど再生の不具合が出る。
「buffer_before_play "10%"」にすると問題なくなった。
buffer_before_play以外のbufferは使用状況によっては不可欠かもしれない。
ギャップレス再生は問題なし。

いろいろ試していく。
こまごま書いていっても分かりにくいので、結果を表にする。
縦軸が「buffer_before_play」。
横軸が「audio_buffer_size」だ。

• b : 再生しても数秒間しか音が出ない状態。
• f : Ｆキーで早送りしたときに不具合が生じる。
• np : no problem

npとfの両方が付いているのは、不具合が出る頻度が少ないと感じた所である。
あまり厳密に回数を数えたりまではしなかったので、印象での評価だ。

ざっと見た感じ、早送りにはbuffer_before_play以外のbufferが必要だと分かる。
必要な数値を計算してみる。
1024*(1-0.8)≒200、320*(1-0.5)=160、264*(1-0.3)≒185

どうやら、200kb程の余裕があれば、問題なく早送り出来るようだ。
余分のbufferが足りないと早送りの後で音が出なくなったりする。それでも何回かＦキーなどを連打したら音が出る。
しかし、buffer_before_playが100%だとそれも上手くいかない。早送り自体が出来ないこともあり、止まったときに音を出すにはトラックの初めから再生するしかないようだ。

ギャップレス再生はaudio_buffer_sizeが256kbのとき以外の条件だと問題なく出来た。
256kbでは再生自体がままならなかったので仕方ない。
ということは、ギャップレス再生の可否はbufferの大きさには依存しないということだ。

m4aだとどうか。実は、audio_buffer_sizeが1024でも音が途切れる感じがあった。では、audio_buffer_sizeの数値によって途切れる感じが違ってくるかというと、以外にそうでもない。
mpdの設定よりも、ファイル形式による影響のほうが大きいのかもしれない。

現在の設定は以下の通り。きりがいい数値にした。

audio_buffer_size		"320"
buffer_before_play		"10%"

設定によって確かに音色の感触は違う。
しかし、どの設定が優れているかの判断は難しいと思った。
audio_buffer_sizeが大きいとゆったりした感触になるというのは世評のとおりだと感じた。

buffer_before_playの数値による違いは、どうもはっきりしなかった。
100%だとやや窮屈に聞こえるような印象で、音飛びさえなければ0%のほうがいいような気がする。しかし、そんな印象は気のせいじゃないか？という気もする。
素人考えだが、「0%」というけど実際に再生直前の音楽データのbufferを「0kb」で回してるなんてことは考えにくくて、実はmpdが勝手に判断してデータを切り回してると考えたほうが実際に近いのではないかと思う。

ちなみに、選曲時に「skipping」と思われる不具合も生じなかった。
そういうわけでbuffer_before_playは少なめだ。

アップサンプリングについての音質評価はまだしていない。しかし、少なくともbuffer_before_playの数値よりは影響が大きい印象だ。

ファイル形式によるギャップレス再生の不具合の違いは、そのうちまた確かめてみようと思う。
僕が使ったm4aファイルが、もともと良くないものだった可能性だってあるからだ。
iTunesで同じCDをリップして確認する必要があると思う。

これも結構困ったのを思い出したのでエントリーにする。

現在は、PCオーディオ実験室で紹介されてる自動マウントのような、高度な設定はしていない。
iBook G4の起動後、ランレベル３の端末からコマンドを打ち込んで「Music」ディレクトリにマウントさせるという、原始的な手法をとっている。
そんなに困らないから今のままでいいかな、と思っている。

ファイルシステムをマウントするにあたって、まず「マウントポイント」を作る。
うちの場合、「/root/Music」をmpdのmusic_directoryに指定してるので、ここに空のディレクトリを作りマウントポイントにする。
次に、以下のようなコマンドを打ってみた。
以下のようなというのは、はっきり覚えてないからである。

# mount -t nfs //192.168～(マウントするNASのディレクトリのパス) /root/Music/(マウントポイント名)

これが上手くいかなかった。マウントしない。
PCオーディオ実験室のエントリーには「cifs」とか「smbfs」といった文字列が出てくる。ファイルシステムをマウントするにあたって、ファイル形式によって選択する文字列が違ってくるらしい。
nfsじゃダメだったのでcifs、smbfsとやってみたけど、やはり上手くいかなかった。

そこで「man mount」でマニュアルを読んでみたけど、よく分からない。
これにはまいった。
外付けHDDにするなんて手間はかけられない。

ネット上で手がかりをさがしているうち「cifs」というのがあると知る。
Windows上のファイルにLinuxからアクセスするには（mount.cifs編） － ＠IT
これを試したら当った。

# mount -t cifs //192.168～(マウントするNASのディレクトリのパス) /root/Music/(マウントポイント名)

これで、NAS上のディレクトリをmusic_directoryにマウントできた。

ところがまだ問題があった。
NAS上にはiTunes Libraryの音楽ファイル用ディレクトリも置いてある。これを/root/Music/にマウントしようとしたら出来なかった。
ディレクトリ名に「iTunes Media」が使われているので、コマンドに半角スペースが混じる。そのままでは正しいコマンドとして成り立たなくなるのだ。

対策は簡単で、パスを""(ダブルクォーテーション)で囲むだけでいい。

# mount -t cifs //"192.168～(マウントするNASのディレクトリのパス)" /root/Music/(マウントポイント名)

これで問題なくマウントできた。
\(バックスラッシュ)を使ってコマンドを書く方法もあるということだが、試みていない。

毎回こんな長ったらしいコマンドを打つのは大変なので、「alias」に登録してある。
bashの設定ファイル「.bashrc」に、コマンドをマウントポイント名でaliasに登録してあるので、マウントポイント名を端末に打ち込むだけでマウントできる。
ダブルクォーテーションを使ってるコマンドは、'(クォーテーション)を併用して書いている。

これぐらいなら手間だとあんまり思わないので、これでいけてる感じだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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