Page 1 / 20 :  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Next › »

Aug 01, 2017

fireface UCXについて

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

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

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

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

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

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

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

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

fireface USB settings

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) UCX RATOC メモリ再生 176.4kHz/192kHz
2) nano iDSD LE メモリ再生 384kHz
3) UCX RATOC NAS 176.4kHz/192kHz、 i2s DAC NAS 384kHz
4) nano iDSD LE NAS 384kHz
5) UCX i2s DDC NAS 176.4kHz/192kHz

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

Jul 05, 2017

オーディオ状況報告(2017.07.05.)

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

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

オーディオシステム一覧

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

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

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

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

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

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

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

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

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

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

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

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

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

Jun 25, 2017

ハイレゾとアップサンプリング、384kHz周辺をいろいろと聴いてみた(7月2日、追記)

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

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

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

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

44.1/16 5点 
192/24 6点 
44.1/16を192/24にアップサンプリング 7点 
192/24を192/24にリサンプリング 7点 
44.1/16を384/24にアップサンプリング 8点 
192/24を384/24にアップサンプリング 7点(クリップノイズあり)

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

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

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

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

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

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

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

7月2日追記。
192kHzと44.1kHzを聴き比べてみたけど、同じ音源だとして違和感が無い。
それだけをもって44.1kHzのマスターが192kHzで384kHzではないとは言えないとは思うけど、まあ、自分としては、そうじゃないかなということにしておこうと思う。

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

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

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

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

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

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

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

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

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

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

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

7月26日、追記。
少なくとも同等以上、とか書いたが「以上」ではないみたいだ。よくよく聴き比べないと判断が難しい。

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

May 11, 2017

Moode Audio3.1 384kHz/24bit i2sDACで、メモリ再生を試みる

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

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

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

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

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

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

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

追記。
このエントリーをアップして以降、あれこれポップミュージックを聴いているのだけど、当たり前といえば当たり前だが、良く聴こえるようになる音源ばかりではないようだ。この程度なのかな、と感じさせられる場合もあって、そうした場合はやっぱり荒が目立って聴こえてくるのかな。
音源や録音によってどのような再生方法があっているかは、やはり違うようだ。

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

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

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

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

閑話休題。

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

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

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

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

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

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

pi@moode:~ $ sudo reboot

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

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

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

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

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

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

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

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

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

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

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

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

Apr 25, 2017

Moode Audio3.1にlibsamplerateをインストールして384kHzでi2s出力する

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

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

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

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

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

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

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

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

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

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

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

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

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

./configure
make
sudo make install

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

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

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

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

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

vi /etc/mpd.conf

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

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

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

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

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

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

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

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

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

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

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

音を比較。

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

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

今回、ここまで。

Apr 09, 2017

オーディオ趣味の課題 備忘録

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

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

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

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

2:アップサンプリング(リサンプリング)ファイルの比較

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

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

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

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

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

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

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

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

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

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

5:DietPi

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

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

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

Mar 28, 2017

Fishmans がリマスターで再発されたので1stアルバムを聴いてみた

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

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

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

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

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

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

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

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

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

今更だけど追記。
ハイレゾ化でフィッシュマンズの音楽にもっと近づける - 茂木欣一がそのサウンドについて語る - Phile-web
http://www.phileweb.com/review/article/201611/30/2320.html

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

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

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

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

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

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

Mar 13, 2017

mpdからmpdにflacをHTTPストリーミング機能で配信する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上、備忘録。

Jan 22, 2017

mpdのHTTPストリーミング機能でflacを配信してみる(24日追記)

今回はこれ。
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+を2台。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を起動しないといけない。これって楽曲の冒頭が聞けないのだ。バックグラウンドで動作させる方法を発見できないのも地味に困る。なにか方法があるんじゃないかと思うんだけど。

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

24日、追記。
普通にvolumio1.55にNASをマウントしたのと比較したら、そっちのほうが音がいい。
そしてやっぱり圧倒的に扱いやすかった。快適に扱えるというのは、やはり助かる。

Jan 16, 2017

MinimServerをRaspberry Pi B+で動かしてみた(24日追記)

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だ。

17 items

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

search results : found 11 songs

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

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

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

24日、追記。
piCoreでのメモリ再生と比較してみた。一番に感じたのは、やっぱり音の軽さだ。良くも悪くもしなやかで耳当たりがいい。
よく聴くとメモリ再生の方が情報量は多いんだけど硬くて重い。こんなだったかな、、、と思っていた。
ここで、ふとpiCoreにログインしtopを打ってみたら、mpdのメモリ消費が数%と。

ここで気付いた。
minimserverからの音は176400:24、Fastest Sinc Interpolatorにアップサンプリングした音で、メモリ再生のほうはしていなかった。以前、何かの比較をするのに設定変更してそのままになっていたのだ。
メモリ再生のほうの設定をアップサンプリングするようにしてみたら、当初感じていた硬さは霧散した。重さは濃厚さに転化したように感じる。
こうして比較すると、やはりpiCoreでのメモリ再生の方がいい。minimserverからの音は薄く感じる。
とはいえ、これはi2sDACからの音で、メモリ再生のほうはRATOCのusb-DDCからfirefaceに繋いでいるから、条件が違う。単純な比較じゃないのだ。しかしpiCoreでminimserverの受信環境を構築する余裕はないんだな、、。

ありふれたvolumioのNASマウントと比較してみる。ハードもOSも条件が同じで、違うのは音源がNASかUPnPかということだけだ。
こうなると、UPnPのほうが見通しがいい音がする。透明感が違うのだ。音の立ち上がりとかもいいんじゃないかな。NASマウントみたいに手軽に使えないのが残念という感じ。軽い音で聞きたい時というのもありそうだと思うので。

Jan 03, 2017

Volumioにマウントした時に機能するシンボリックリンクを作りたい

たぶんこれは初歩的な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が表示される。

Jan 02, 2017

VolumioをUPnP/DLNAで繋いでみた(1月4日、追記あり)

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

昨年末、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。

サーバー レンダラー

サーバーの設定について、前のエントリーを引用。

次に、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

で、今回はDLNAサーバーにNASをマウントしてレンダラーに送る。
サーバー化したvolumioにwebブラウザでアクセスし、音楽データベースであるNASのディレクトリをマウントしていく。
ということなんだけど、ここで問題は、DLNAでは大量のファイルを扱えないし(どうも10000程度が限界らしい?)、原因は分からないが認識できないファイルも出るらしいということ。

当初、NAS上の音楽データ用ディレクトリをそのままvolumioにマウント。
そしてminiDLNAのデータベースを構築しようとしたら(うちのデータは音声ファイルとカバーアート画像ファイルあわせたら、ゆうに10000を超える)、ハングした。その経過は前のエントリに書いたとおり。

そこで対策として、登録する音声ファイルを減らすために、音楽データ用ディレクトリの子ディレクトリを、一つ一つマウントしていった。
次に、画像ファイルをDLNAで管理する必要はなく音声ファイルだけ認識してくれたらいいので、/etc/minidlna.confの記載は以下の様に書き直した。これで音声ファイルのみ管理するようになる。
media_dir=A,/var/lib/mpd/music/NAS

で、複数の子ディレクトリをvolumioにマウントして、トータルファイル数1600強(音楽ファイルのみ)をminiDLNAのデータベースに登録してみたら、数10分かかる。
上記、前回エントリの引用で、service minidlna restart とコマンドを打つと書いてある。
打って数分待つと「 ok 」と表示されて、もういいのかな、と思うんだけど、実はこの時点でtopコマンドを打つと、minidlnaがCPUの50%以上を食って大忙しにしていたりする。
これが仕事を終えるまでは次のステップには進めない、ということ。

volumioにNASをマウントし、volumioのデータベースを構築するだけなら、ファイル数が相当多くても正確に取り込んでくれて登録ミスなどはない(問題を生じるのはこっちが何か間違えているときだけだ)。一方、DLNAのほうは、ファイル数が少なくてもデータベースへの取り込みミスがしばしばあり、原因がはっきりしない。
現時点では、そういうものと思うしかない。

さて、volumioDLNAサーバーのminidlnaが仕事を止めたのを、sshのtop画面で確認し、次はレンダラーだ。
レンダラーのvolumioにwebブラウザ、ncmpcpp、sshでアクセスしてみる。

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

UPNPにvolumioを表示

上の図では「root」と表示されているが「minidlna」と表示されるのが通常運用らしい。何回か再起動するうちに、今はうちでもそう表示されている。どうしたらそうなるかというのは、実はよく分からないんだけど、、、

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

音源を表示

ということなんだけど、実はサーバー側でデータベースが再構築されていた場合、レンダラー側はこれに自動的に合わせてはくれない。レンダラーのほうで登録されているmpdのデータベースと、サーバーのデータベースをすり合わせる必要がある。
つまり、レンダラーのncmpcpp画面には、レンダラー側が作ったデータベースが表示されているということ。
サーバーの実体が表示されてるわけではないのだ。

ncmpcppのブラウズ画面で「u」キーを打つとアップデートできる。
サーバー側のminidlnaとかと、レンダラー側のdjmount、mpdとかで、データのやり取りを行い再構築が行われる。
これにも数10分かかる。
仕事が終わるのを確認するためには、sshでtopを打ち監視しておく必要がある。上級者なら仕事が終わったらビープ音を出すとかスクリプトを書けるんだろうけど、僕には無理。

top画面が落ち着いたら、お疲れ様です。
レンダラーvolumioからncmpcppを使って音が出せるはず。

そういえば、まだあった。
もしも、volumioを何かの事情でシャットダウンした場合、起動したらデータベースの再構築をしないと音が出ないみたいだ。
一旦切れたサーバーとレンダラーの繋がりを戻す必要があるらしい。再構築以外の手段はないのかな、、、

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

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

追記。そういうわけで、その後はmpdを動かしている。
そのほうがNASをマウント、アンマウントするのにwebブラウザを使えて便利だから。

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

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

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

追記だ。
三が日の三日目使ってメインシステムで試聴した。
RCAケーブルを抜き差しして、NASマウント音源のvolumioと比較。

意外なことに、悪くない。
というか、NASマウント音源のvolumioよりいいような気がする。
UPnP音源のvolumio、i2sDACの音は、涼しげで見通しがいい気がする。いい意味で軽く、きめ細かくて陰影が深い。比べたらNASマウントのほうが平板な音に聞こえる。

UPnPを使う意味は、あるのかな、、、
メモリ再生との比較は出来ていないけど、、、

なんというか、、、聴いてみたら、なんとかなるもんならしてみたい、と思える音が出てしまった気がする。
でも、日常使用レベルにするにはそれなりのスキルは必要になりそう、という感じかな。

Dec 31, 2016

UPnP/DLNAは難しかった(volumioをupnpで繋いだので追記した)

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

追記。
DLNAで音出し : オーディオ日記 http://yseki118.exblog.jp/25998461/
こちらで書かれていることなど読むと、upnpで音質向上とはいかないということが今更分かる。
頭もハサミも使いようだ。身の丈にあったことを無理せずやったほうが効率いいんだろうな、と思うのだった。

1月4日、さらに追記。
次のエントリーにその後の経過を書いた。意外に音は良かったという結末だ。

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アドレスに書き換えて打ち込む。
スナップショット画面が以下。

miniDLNA画面

確かに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レンダラーとして機能しているのが分る。

top画面

意外なことに、Music Stationはcue sheetの中を読み込んで曲別に楽曲管理してくれるようで、これはすごいと思った。しかし残念なのは、1曲再生するつもりで操作したら、その曲が終わったあと次の曲を再生していく。アルバムの2曲目を再生しようとしたら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以外に古くからあるファイルサーバーがいくつか動いている。それらが表示されているし他にもネットワーク上のデバイスがいくつか、、、

update画面1

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

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

update画面2

とりあえず、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番号をセットにして設定している。
下の図のような感じ。

IPとPort

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

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

気付いたきっかけは、volumioを2台、upnpでつないでみようとしたことだ。
volumioをupnpで継ぐにはUpmpdcliを動かしておく必要があり、mpdのポート6600を変更したら、これが動かなくなるので変えられない。ひとつのネットワークにポート6600のvolumioが2つ存在することになる。
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で繋げてしまった。
音質はノイズが多くピュアオーディオには無理。スキルがないからかもしれないけど。
せっかくなので記録しておく。

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

まず、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で設定された音源が表示される。

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

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

Nov 25, 2016

オーディオ状況報告(2016.11.24.)

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

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

オーディオシステム一覧

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

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

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

さて、最近はメインのデジタルトラポが3つになった。全部192/24にアップサンプリングの設定。
Raspberry Pi2とpiCore7を使ったRAMメモリ再生機が2つ。1台はRATOCのusb-ddcを経由してCOAXをfirefaceに。もう1台は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などに買い替えない理由になっていたりする。

Nov 20, 2016

JPLAYの音を聴いてみるなど

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とで不具合が起きないか心配。
いろいろ設定をいじるのも面倒なのでしないと決めた。

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

( 1 ) 6730b + Windows Server 2012 R2
+ JPLAY USBメモリ音源再生
ral-24192ut1 SM-SX100
( 2 ) ral-24192ut1fireface UCX
( 3 ) ras pi2 + piCore7
+ mpd RAMメモリ音源再生
ral-24192ut1
( 4 ) ral-24192ut1fireface UCX
( 5 ) hifiberry Digi+
( 6 ) ras pi2 + piCore7
+ mpd NAS音源再生
ral-24192ut1

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

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

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

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

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

次に(6)を試す。
以前に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の音(1)は、最初とは全く違う音だった。
(3)や(5)と比較すると音場が一回り大きく広がり、見通しがよく奥行きが出る。音色も鮮烈で生々しい。なにしろ桁違いに空間の情報量が多く感じる。デュアルだとこれ以上ということなので、すごいことだ。
JPLAYはUSB出力の制御がブラックボックス、企業秘密ということらしい。それでここまで変わるということは従来の伝送は何が問題なのかということになる。

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

結果。
とりあえず(1)(2)(4)の差は、(1)と(3、5)の格差に比べたら僅差。

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

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

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

ということで、うちでの試聴の結果、順位をつけるとしたら(1)>(2)>(4)>(5)>(3)。
しかし番外で(4でアップサンプリング)が一番、僕の嗜好に合っている。これは今後は使っていこうかと思う。

早々に追記。若干、誤字修正とか直し忘れの書き換えをした。

Windows専用機を工面してWin Server 2012 R2かWindows 10かを購入してJPLAYというのは、ちょっと現時点ではやる気がしない。
経済的にも時間的にも自宅の空間的にも負担だし、それを切実にやりたいと思うほどにはmpdの音に不満がない。
mpd + ncmpcppでの再生環境が、僕のスタイルに上手くはまっているからというのもあるかもしれない。それを崩す気になれないし、充分に快適だと感じてるということかもしれない。

そんなわけで当面はmpdでやっていく方針。

Page 1 / 20 :  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Next › »