lightMPDを使ってみての感想

新年度がスタートして、こんな記事を書いているような暇はないのですが（－－；・・・。
しかしながら、lightMPDを使ってみての感想を一言だけ追加しておきます。

「CuBox-i4Pro」が不調で回復の見込みもたたない現状ではレガシーなCuBoxを使うしかありません。そうなると、起動用のスクリプトとして「ミミズ工房」さんの「梅雨入りバージョン」を使うか、「lightMPD」を使うかという二つの選択肢が存在します。
もう一つ、「Voyage MuBox」という選択肢があるのですが、これはまあパスしてもいいように思います。

結論から言えば、私個人としては「lightMPD」主体で当分は運用していこうかという結論に達しました。
音質面での「lightMPD」の最大の訴求点はすべてのシステムがメモリ上で動作することでしょう。もちろん、「梅雨入りバージョン」にしてもすべてのシステムはマイクロSDカードに収まっているのですから、一昔前みたいにHDをゴリゴリ動かしながらPCを動作させていた時代と比べれば遙かに「軽い」です。しかし、それでも、完全にメモリ上で動作する「lightMPD」と比べればそれなりの「重さ」を感じます。

Windows時代でも、再生用の音楽ファイルをRAMディスクにおけば音は軽くなりました。再生用のソフトをRAMディスクにに置いても同じような傾向がありました。
これと同じようなことが、CuBox上においても、より高い次元で再現しているような気がします。
Windows時代でも、その「軽さ」を嫌ってRAMディスクを選択しない人がいました。それと全く同じように、「lightMPD」の「軽さ」を嫌う人がいても当然だろうと思います。しかし、「lightMPD」が再生する低弦楽器の風のような軽さは他のシステムではなかなか実現できないものです。私は、この一点に魅力を感じて「lightMPD」を選択することにしました。

ただし、「lightMPD」には「暴れ馬」的な要素もあるので、周波数特性を測定しながらスピーカーのセッティングやイコライザの「DEQ2496」の設定などを再度見直す必要がありそうです。ただし、現状ではそんな時間はとてもとれそうにもないので、そういう細かい部分まで追い込んだ上での音質評価はゴールデンウィークまではできそうもありません。

なお、余談ながら、私がシステムの中核として使っているイコライザの「DEQ2496」が２万円程度しかしない製品であることに「ご注意」をいただくことがよくあります。その内容をかいつまんで紹介すると、そんな安物の機械を使っていると不要なカラーリングが施されて音質面での劣化が避けられないというものです。そして、そういう「ご注意」をいただく方々が推奨してくれるのが定価80万円程度のとあるメーカーの製品です。というか、その定価80万円程度のとあるメーカーの製品を使わない限り、オーディオにおいてはイコライジングをしてはいけないそうです。
私はその80万円近くもする製品は使ったこともありませんし、現物を見たこともないので何ともコメントの返しようもありません。しかし、デジタル領域でのイコライジングというのはPC側でソフト的にでも実現できるものだという「確信」があるので、その程度の作業をするのに80万円近くもするというのは個人的には納得がいかない部分があります。

もちろん、80万円もの金額を投資してその製品を使っておられる方にとってはそれで大いに満足しておられるんでしょうから、私からとやかく言うつもりなどは全くありません。それと同じように、私も2万円程度の機器を十分に満足して使っていますので、できればよけいなお節介は無用にしていただければうれしい限りです。昔から「金持ちけんかせず」というじゃないですか。（＾＾；

閑話休題。

ただ、この一週間ほど「lightMPD」を使ってみて気づいたのは、システム全体がきわめてシンプルであるがために、ちょっとした設定の違いがかなり音質面に影響を与えるような気がしました。
いくつか気づいたことを報告しておきますが、あくまでも私のシステム上において私が感じたことですので、最終的にはご自分で判断してください。

なお、２万円程度の「DEQ2496」で満足しているようなやつの感性などは信じられない（しつこいかな－－；）という方は、できればパスしてください。
できれば、このページだけでなくこのサイト全体をパスしてください。（この人、かなり怒っている・・・ね－－；）

１．システム全体が無事に動作すれば、 [debug]はすべて「no」にする。

これは言うまでもないでしょう。
SSHでログインができない「lightMPD」にとっては、うまく動作しないときの頼りになるのはこの[debug]が「status.txt」にはき出す情報だけです。しかし、システムが無事に動作すればこんなものは一切不要です。
忘れずにすべて「no」にするか、設定自体を削除した方がいいかもしれません。

２．httpサーバー – [httpd]は不要

これは「on」にしておくと、データベース化された「tag_cache」をプラウザから確認できますが、このシンプルなシステムにいて「httpサーバー」を起動させるのは音質面でのデメリットは小さくないように思います。
特別な理由がない限りは基本は「no」にしてhttpサーバーを起動させないようにしたほうがいいでしょう。

３．NASと接続するときはnfsでマウントする

cifsで接続しようとすると、NASでWindowsのファイルサーバー機能を有効にしないといけません。ところが、この「Windowsのファイルサーバー機能」は音質面でのデメリットは小さくありません。そして、そのデメリットは「lightMPD」のようなシンプルなシステムでは影響がかなり大きいように感じます。
nfsで接続しようとすると、NASの側でいくつかの設定が必要になったり、Synologyのように「共有ディレクトリ」の表示の仕方が変わったりと煩わしいことが多いのですが、音質面でのメリットはかなり大きいと思います。

４．nfsでマウントするときのプロトコルはudpを選択する

一昔前は、nfsでマウントするときのプロトコルのデフォルトは「udp」でした。しかし、最近はnfsも「tcp」プロトコルが使えるようになってきたようで、「lightMPD」もデフォルトは「tcp」になっています。
しかし、「lightMPD」のようなシンプルなシステムでは、複雑な「tcp」プロトコルと簡単な「udp」プロトコルでは、音質面での違いがはっきり存在するように思います。当然のことながら、シンプルな「udp」プロトコルの方が音質面では有利です。
もちろん、「udp」は「tcp」のように転送されるデータの正確性を担保しませんが、家庭内のローカルネットワーク上にあるわずか数メートル先のPCにデータを転送するだけですから、「tcp」の正確さよりは「udp」の高速性の方が音質面でのメリットは大きいと思います。
それから転送時のバッファーサイズは「udp」の時はデフォルトは「8192」です。これを無闇に大きくしても音質面でのメリットはあまりないように思いますので、現状はデフォルトで使っています。

SSHでログインできない「lightMPD」では、設定が可能なのは「lightmpd.conf」の編集だけです。
しかし、システム全体がきわめてシンプルな故に、そのちょっとした設定の違いがシビアに音質に影響を与えます。そのシビアさに「lightMPD」の可能性を感じます。