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

May 23, 2018

PPAP Back-EndのUSB出力が48kHzになっていたので修正した

どこから書いたものか。
数ヶ月前、nano iDSD LEが壊れた。
PPAP(piped pcm audio play)のバックエンドをつないで音を出そうとしていたら、音が出なくなってしまったのだ。
うちのDACはfireface UCXのCCモードとi2s DACということになった。
LEは音源のサンプリング周波数をLEDの色で表示する機能があった。
CCモードのUCXは入力信号のサンプリング周波数を表示しない。
iPadをつないでいたら、TotalMix FXの画面から見えるんだろうけど、うちにはiPadはない。
そういうわけで、、、
バックエンドのUSB出力が48kHzにリサンプリングされているのについ最近まで気付かなかった。不覚だった、、、

もしもこれを読んで驚いている人がいたら、すみません。おわびします。

下記のエントリーには加筆訂正を入れました。
piCore7でppap (piped pcm audio play)を試みる
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm

それでも、やはりPPAPの音はいい。
サンプリングの良し悪しなんかより、バックエンドで負担軽減のほうがずっと音質改善につながるってことなのかな、、、
感心したり凹んだりしていてもしょうがないので、ちょっとなんとかしようということになる。

なんで気付いたのか書いておかないといけない。

実はずいぶん前にTEAC UD-501を入手していた。
半額以下で売られていて、もともと興味があった機種だったので、迷った末に入手して、したはいいけど、なかなか出番がなくて死蔵していた。
LEから音が出なくなって、使ってみようかとも思ったけど、体調不良もあって伸び伸びに。
体調が回復して、数日前に思い出してつないでみた。
UCXに出力してるのと同じ96kHzで送ったら、UD-501のインジケーターに48kHzと表示されて、あれー???、ということに。

バックエンドにsshでログインして「cat /proc/asound/card*/pcm0p/sub0/hw_params」と打ってみたら「48000」と表示が。
フロントではどうかというと、フロントではalsaは働いていないので「No such file or directory」と表示される。
そうなんだよね、、、だから確認する手段が全くなかったわけではないのだ。
今から思えばだけど、抜けていて気付いてない。

最初は何で48kHzに変換されるのか分からず戸惑ったけど、48kHzといえば、、、というので思い出した。
alsaはデフォルトで48kHzに変換することがある。

過去にあげたエントリー↓5年前だけど、もっと遥か昔のような気がする、、、

http://blown-lei.net/endive/blosxom.cgi/audio_diary/20130302a.htm

mpdを終了し、mpd.confを編集する。

##	device		"hw:0,0"	# optional

文頭の##を削除して保存。
mpdを再起動する。

ALSAはデフォルトでdmixを有効にしている。
5年前はmpd.confのalsaの設定で修正した。
PPAPのバックエンドで同じ手は使えない。どこで設定したらいいのか、、、
alsaのサイトで手がかりがないか探す。

https://www.alsa-project.org/main/index.php/Asoundrc
Asoundrc - AlsaProject

Some notes:

The dmix PCM name is already defined in the global configuration file /usr/share/alsa/alsa.conf.

- The default sample rate for this device is 48000Hz. If you would like to change it use:

aplay -D"plug:'dmix:RATE=44100'" test.wav

- An example command for dmix plugin to use 44100Hz sample-rate and hw:1,0 output device:

aplay -Dplug:\'dmix:SLAVE=\"hw:1,0\",RATE=44100\' test.wav

わからん。 /usr/share/alsa/alsa.confは、piCoreにはない。
それに-D"plug:'dmix:RATE=44100'"って結局dmix使ってるんじゃ?

そういえば、lightMPDはどうしてるんだろう、、、
ということで、今一度、rpi2-smpdplayer-usb-20180103の中を探ってみる、、、
以前、うちのシステムにつなごうとしたことがあったんだけど、結局はよく分からず上手くいかなかった。
何か参考にできないか、、、

smpdplayer.confの中にこんな記載を見つける。

APLAY_ARGS="-D hw:0,0 --test-nowait -q -M --period-size=384 --buffer-size=21888 -t raw -f cd"

これってaplayコマンドのオプションそのものだよね、、、
これを参考に「-D hw:0,0」をうちのシステムに書き込んでみたけど、、、残念、動かない。

hw:がキーワードかな、、、あれこれネット上を探して次に参考にしたのがこちら。

http://takuya-1st.hatenablog.jp/entry/2016/04/18/011246
Raspberry Pi のオーディオ・デバイスを指定して音を再生する。 - それマグで!

aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Left.wav

こんな書き方があるのか、、、
これを参考に、うちのPPAP バックエンドの/opt/bootlocal.shを以下のように書き換える。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=256 --buffer-size=2048 -t raw -f S24_LE -r96000 -c2"

これで、ビンゴ!
UD-501のインジケーターに96kHzが表示されるようになりました!

そんなこんなで、fireface UCXにCCモード上限の96kHzで入力できるようになった。
バックエンドで「cat /proc/asound/card*/pcm0p/sub0/hw_params」を打つと「96000」と表示される。

tc@box:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 256
buffer_size: 2048
tc@box:~$ 

UD-501はどうかといえば、192kHzまではPPAPで使える。384kHzは音が途切れ途切れで使えない。
NASマウントmpdからのUSB出力で、NAS音源の384kHzハイレゾを鳴らせないなら、PPAPで384kHzを鳴らせないのもRasberry pi2のLAN/USB周りの限界ということになるかと思う。
やってみたら、問題なく鳴る。
ということは、うちのPPAPの何処かに348kHzを送れない原因があるということだ。

この辺は今後の課題だ。

追記。
aplay(1) - Linux man page
https://linux.die.net/man/1/aplay

上記サイトをみたら「Valid values are 2000 through 192000 Hertz.」と書いている。
なるほど、aplayを使うなら上限は192kHzだ。

それにしても、UCXで気付かずに聴いていた48kHzの音はなんだか良かった。
このサイトの5年前のエントリーにも、48kHzのときのほうがゆったりして暖かい音が出ていた印象があるとか書いている。
今回の顛末で感じている印象も5年前と同じなのだ。-D plughw:0,0を書き込んだバックエンドから出る音は以前よりもクールで、それは48kHzにしても同様だ。

これはもしかしたら、dmixの音なのかもしれないと思い至った。
前々回のエントリーで書いた、mpdの設定で「mixer_type "software"」を記述する場所によって音色が違う気がする、というのも、alsaの項目内に書けばdmixが働き、そうでないなら働かないとしたら、なんとなく音色が違うのも辻褄が合う。
どんなものだろうか。

May 06, 2018

RAMメモリ再生とppap(pipeed PCM audio play)を比較した

今回は、ほんと報告だけ。
宿題として残っていたタイトルの題目なんだけど、結論から言えば、ほぼ一瞬で決着が付いた。ppapの圧勝だった。
これは実は正直、意外でも何でもなくて、ppapで聴き始めた当初から予測していたことだった。
それぐらい、うちの環境では過去になかった音質で音楽が鳴っているのだ。

試聴環境を以下に列挙。

音源 Faure - Requiem - Philippe Herreweghe, La Chapelle Royale, Ensemble Musique Oblique
Booker T. & The M.G.'s - Melting Pot
DAC fireface UCX CCモード(24/96) / USB029H2RP
アンプ / スピーカー SM-SX100 / 4425mk2 / T900A
方式 RAMメモリ再生 PPAP方式
Hardware / OS raspberry pi 2 / piCore7 Front - raspberry pi 2 / piCore7
Back End - raspberry pi 2 / piCore7
software mpd 0.19.19, libsamplerate, alsa Front - mpd 0.19.19, libsamplerate, nfs, ncat
Back End - ncat, aplay
RAMメモリ再生 PPAP

RAMメモリ再生の弱点は、複雑なエンコードなどの処理を行うmpdが動いているRas Piから、DACにデータを送っていることだ。NASのマウントなどネットワークからのノイズや負担を排除しても、mpd動作自体の負担からは逃れられない。
ppapのバックエンドは、上流から送られてきたデータをDACに受け渡す処理しかしていない。
処理が軽いということは、より安定して動くということだ。
それが決定的な違いを生んでいる。

最近、philewebで話題になっている通称miniPCという再生方式は、windowsでfoobar2000という、それかよ?というシステムで高音質を引き出しているらしい。上流はminimserverでupnp、下流のwindowsは不要なプロセスをカットしDACへの伝送に特化してるという。
設計思想がppapと似ているのが分かる。

http://asoyaji.blogspot.jp/2018/03/pc.html PCで音楽 - PCオーディオの最新

ppapのフロントでRAMメモリ再生を行なったらどうなのか、というのは突っ込んでいくとあるんだけど、いつかそのうちに気が向けば。
現状で十二分以上に不満がなくて、音楽に浸るほうが先なんだよね。

May 05, 2018

子供と2人で遊ぶトランプゲームを創作したよ

準備

用意するのはトランプ1セットと、カードを広げる場所。プレーヤー2人。
カードからジョーカーを抜いて、赤黒の山26枚ずつに分ける。
プレーヤーは赤黒を決めて自分のカードの山を取る。各々26枚のカードをよく切り、裏にして2枚ずつ13の組に分け、前に並べる。

ゲーム開始

プレーヤーは13の組から戦いに出す組を選び、真ん中に出す。

戦いのルールは簡単。カードをめくり数字が小さいほうが勝ち。
まず双方、1枚目のカードをめくり表にする。

カードの数字を比べ、勝ったカードはそのまま残る。
負けたプレーヤーは負けたカードを流す。数字が同じなら相打ちで双方ともに流す。

1枚目のカードを流したプレーヤーは、残っている2枚目のカードをめくる。
数字が小さいほうが勝ち。負けたり相打ちになったカードは流す。

残ったカードは、勝ち残ったカード、裏返しのまま残ったカード、ともにプレーヤーの点数になる。
プレーヤーのもとに戻し表にして並べておく。

13組の山でこの流れを繰り返す。

勝敗

13組全ての戦いが終わったら点数を集計。カードの数字がそのまま点数になる。
点数が多いプレーヤーが勝ち。

こんな感じ。
13組は多すぎということなら、ハートとスペードを使って2枚6組と最後1枚で勝負するとかもありかな。計算しにくいので絵札は10点でもいい。
あんまり頭を使わずにプレーできるけど、子供はそこが不満な様子だ。

たいていゴールデンウィークの祝日には仕事が入るのが常だったんだけど、今年は珍しく日曜祝日が全部休みになっている。
うちの子供はオリジナルのゲームを創作するのが好きで、でも大抵はルールがわけが分からなくなって完成しない。だけど今回は親が関わることになって、珍しくそれなりに遊べそうな形になったのでアップしてみた。

ゲームに名前が要るんだけど、提案した案は全て子供に却下された。
しょうがないので名無しのままだ。

Posted at 16:34 in letterbox | WriteBacks (0) | Edit

Apr 12, 2018

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

最近のシステム構成は下図のような感じ。

システム構成図

piCore7をpiped pcm audio play方式で使い始めて1ヶ月になる。
僕はずっとmpdクライアントによる音量調節(mpd.confへの記述 : mixer_type "software" 設定によるもの)はalsaを介するものだ思い込んでいて、pipe出力を使うppapでは使えないという理解をしていたんだけど、実際にはmpdの仕様でずっと昔から使えるということが数日前に判明した。
実際、設定してみたらncmpcppから音量調整ができる。
利便性という面でもNASマウント音源をmpdで再生するのと全く遜色なしということになる。
mpd.confの設定は、うっかり間違えて覚えたまま気付かずにいる事が他にもあるかもしれない。バージョンアップで設定方法が変わってるものもある。チェックしておく必要があると思う。

先日、このsoftwareボリュームを使えないと思い込んで、fireface UCX付属のリモートコントローラーを使ってデジタルボリュームを調整したら、アンプのボリュームを弄るよりいいんじゃないかと考えて、試してみた。というのも、うちでは上流の音量を下げなかったらアンプのボリュームをかなり絞る必要があるから。DACの出力を絞ることができれば、アンプのボリュームを開けることが出来る。
これが、あんまり良くなかった。
ちょい聞き、大して差がないけど、プラセボも疑うけど、なんでか、微妙なところで、つまらなく聴こえた。潤いが失われるというのか、砂っぽくなるというか、音楽の生命感が微妙に減衰する。使わないほうがいい。たぶん、DACもデジタルトラポ同様、余計な仕事をさせないほうが音は良いんだと思う。

今回、結果として比較することになったけど、mpdのデジタルボリュームはそうした音質の変化が少ないと思う。

いや、正確には違うかな、、、
以前はaudio_outputの項目内に、type "alsa"と併記してmixer_type "software"と書き込んでいた。
現在はalsa出力は使わないので、audio_output項目とは別に独立したmixer_typeの項目で設定している。
audio_output項目の中に設定していたときは、ボリュームを絞るとなんとなく柔らかい音色になっていた。聴きやすいといえばいいけど、ゆるいのはゆるい。
mixer_typ項目で設定してから、それがなくなった。同じ音質で音量だけ下がる。その一方、音量変化のカーブは急激になった気がする。ちゃんと比較試聴したわけではないんだけど。

アンプのアナログボリュームと比べてどうかは確認していない。
それでも十二分に実用になるレベルだと確認できたのでとりあえず良かった。

そんなこんなで、最近はppapで聴いてばかりいる。
384kHz対応のnano iDSD LEが壊れてしまって、現状うちで対応できるのはi2s DACで192kH、fireface UCX CCモードで96kHzというのもあって、いっそのことと割り切って当面ppapで96/24に固定でいいか、となっている。
768kHz対応するDACが出てたりして、どうしようかと思うけど、しばし考えようかという感じ。

過去に何回か、複数のPCで機能を役割分担するデジタルトラポの方式を試したことがあったけど(upnpやhtmlでの伝送を試したことがある)、共通して感じるのは音色の軽さだ。ppapの音も軽い。軽いというよりスピード感といった方がいいのか。

普通、音が軽い場合は密度感も低い。
例えばケースを付けないRas piにvolumio1.55を刺してi2s DACを鳴らした場合、音は軽く密度も低くなる。ポップミュージック向きのノリが良くて楽しい音で、馴染みやすく気安く聴けるけど、そこでケースを付けたら忽ち楽しくない音になったりする。

役割分担方式の場合、軽いんだけど密度が高い。
重いはずのものが軽く動く感じ。そうなると、まるで音がエネルギーの塊のように見えてくるのだ。聴いていて驚きを感じる音になる。
しかもそれが、極めてさりげない。
この、さりげない、危なげない感じというのは、システムに余計な負担がかかっていない証左だと思う。

ppapは以前に試した役割分担方式よりも、いや、今まで聴いたどのシステムよりも、この驚き感とさりげなさが強い気がする。当たり前のように自然な音なのに、エネルギー感、生命感が強い。
どちらかの方向で優れているのではなく、両立しているのがいい。

こういっては何だが、piCoreはハイファイ再生が得意なディストリとは言えないと思っている。もっと優秀なディストリが沢山あるからだ。
例えば端末でtopを打ったら、何をしてるのか分からないタスクがたくさん表示される。lightMPDベースのバックエンドとか、恐ろしいほどすっきりしている(うちでは起動はできたが、残念ながら音が出なくて根負けした)。比べたらpiCoreは、ゆるいはずだ。せめてリアルタイムカーネル化できないかと思ったりしたけど、能力がないので素のまま使っている。
そんな状態にも関わらず、これだけ鳴れば凄いんじゃないか、と思うだけの音が出る。
それは、この方式が優れているからだと思う。

メモリ再生と比較してみないといけないんだけど、暇がない。
いや、いけないということはないんだけど、しておかないとすっきりしないという感じ。宿題を置いたままで気楽に遊べない感じだ。いつかそのうちにしようと思う。

システム構成図では、新しいNASとしてHS-251が追加になっているんだけど、まだ実際には繋がっていない。
近日中にHDを入手して設置する予定。
HS-210だけでは足りなくなってきたので追加することにした。HS-210のHDを変えることで容量を増やす手もあるんだけど、時間も手間もかかる上に、思ったほど増やせないし、使わなくなった3TBのHDが2つ手元に残る、なんてことになるので、、、いっそ追加でいいやということに。
NASが増えるのはノイズ源が増えるということではあるけど。

イーサネットハブを一部、NETGEAR GS105E-200JPSに交換している。
分かりやすく説明してるサイトのアドレスをメモ。
https://cre027t.jp/gs105e/
NETGEAR GS105Eをオーディオ用HUBとして使う

このハブは、ポートを選択してvlanを構成することができるので、ちょうどいいのでppapのバックエンドを家庭内LANと切り離すの使うことにした。
効果は、プラセボレベルで効いている感じ。
なんとなくだけど、切り離した方がいいのかな、というか。
UCXのデジタルボリュームとmpdのsoftwareボリュームの比較の方が、これよりはもう少し判断しやすい感じかな。パケットは遮断できても電気的なノイズは完全に遮断できるわけじゃないし、ハブ自体が何かをしたらノイズが増える可能性もある。微妙なものだという気がする。
しばらく使いながら様子を見ようという感じだ。

Mar 25, 2018

今一度、44.1/16を聴き比べる

先日、リサプラーによって再生音の定位に違いを生じるかどうか、libsamplerate使用、SoX使用、アップサンプリングなしの音を比較試聴し、違いがあることを確認した。
DACは、nano iDSD LE。

このとき、libsamplerate、44.1/16へのリサンプリング有る無しで聴き比べたが、違いがあった。
libsamplerateを通した音はlibsamplerateの音になる。
同じ44.1/16でも、リサンプラーを通すとリサンプラーの音になるのだ。

SoXと比較して、libsamplerateのほうが音への影響が良くも悪くも大きいと思う。libsamplerateはDA-AD変換をシミュレートするので、言ってみれば元から全てデジタル信号を再構築するわけだから、音が違って当たり前と、言おうと思えば言える。
しかし、デジタル信号自体が違うから音が違う、でいいのか?

前回の記録から試聴結果を引用してみる。順序は変えている。

44.1/16、リサンプリングなし。(NAS original音源)
チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上~左向きに。2分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

44.1/16 (NAS resample音源)
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台後半、響きが右、後方に向かう傾向が強い。 バス、ほぼ中央右。

44.1/16、リサンプリングなしでCCモード (ppap original音源 DAC:fireface UCX)
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上~左右に広がる。2分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。

なんというか、定位について書かれている文面だけ見たら、LEでのオリジナル音源再生より、リサンプリングした音源の再生のほうが、UCXによるオリジナル音源再生に近いように見えなくもない。そして実際、聴いた音色の感触はそう感じられた。
リサンプリングすることに優位性があるなら、それは何処から生じるのか。
オリジナルデータのほうが正確なのは当たり前だ。リサンプリングがジッター低下につながる理由を探さないといけないってことだ。

構成図を見ながら考えてみる。

オリジナルデータ再生の場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてalsaに送っている。
リサンプリングする場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてlibsamplerateでDA-AD変換シミュレートし、そのデータをmpdがalsaに送っている。
ここで考えたのは、DA-AD変換シミュレートに際してデータがどこかにバッファされるはずだ、ということ。バッファされたデータを送り出すほうが、ジッターが減るのではないか。もともとmpd.conf上にバッファを設定する項目はある。しかしlibsamplerateのDA-AD変換シミュレートに使われるバッファは、たぶん別に用意されるはずだと思う。
バッファされたデータを送り出すということなら、RAMメモリ再生に近いと言えるかもしれない。

RAMメモリ再生で44.1/16にリサンプリングしたら、どう聴こえるだろうか。
試してみよう、、、と思ってた矢先、、、
、、、
nano iDSD LEが壊れたみたいだ、、、
入力の認識はしているようでインジケーターの色も変わるんだけど、音が出なくなった。

i2s DACでやってみようか、、、
聴こえ方がどうか、最初からしないといけないのか、、、
ppapのUCXと定位に差がなかったら、比較できないってことだな。

そういうわけで、piCore7でi2s DACを鳴らす環境をさっさと構築する。
というか、nano iDSD LEに繋がっていたras pi2からmicroSDを抜いて、config.txtを設定して、i2s DACを刺したras pi2に刺し直し、起動させるだけだ。
USBターミネーターは刺すけど、面倒なのでケースなしだ。

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1862     1 tc       S     133m 14.3   0 15.5 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1894     1 tc       S     133m 14.3   0  7.5 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1879     1 tc       S     133m 14.3   0  0.6 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1911     1 tc       S     133m 14.3   0  0.6 mpd

これはlibsamplerateによるアップサンプリングを行っている時のtop表示。
上が順に、192/24、96/24、44.1/16、44.1/16リサンプリングなし、だ。
サンプリング周波数が高いほど、CPU使用が多くなる。44.1/16はリサンプリングしようがしまいがCPU使用率が変わらない。それでも先日、聴き比べた時には確かに音は変わって聴こえたわけで、どこかで何かが何かしてるんだろう。

試聴だ。
音源は前回と同じ、幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリア。

まず、リサンプラーなしの44.1/16、NAS音源。
チェロは右、目の高さ。、、これはUCXよりも中央寄りか?
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。2分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。

次、リサンプリングありの44.1/16、NAS音源。、、柔らかくなる。
チェロは右、目の高さ、、、だけどリサンプラーなしのNAS音源より、さらに内側に聴こえる。右中央?
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは広がるが、、そんな上にいかない。2分台前半、定位は安定。後半、響きが横には向かわない、やや後ろに向かうことあり、、、定位は安定感がある。
バス、ほぼ中央右。

次、リサンプリングありの44.1/16、RAMメモリ音源に替える。
チェロは右、目の高さ。あれ、、NASよりも外に。
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。2分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、安定感がある。
バス、ほぼ中央右。

リサンプラーなしの44.1/16、RAMメモリ音源。
チェロは右、目の高さ。NASよりも少し外で変わらず。UCXと比べてどうだろう、、、
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。2分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、やはり安定感がある。
バス、ほぼ中央右。
リサンプリングのあるなしで、ほとんど変わらない。

リサンプラーなしの44.1/16、NAS音源に戻る。RAMと比べると少し硬いかな。
チェロは右、目の高さ。RAM音源のときよりも5度ほど内側にいるみたい。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。RAMより広がりは大きい。2分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。

UCXで聴いてみる。リサンプラーなしの44.1/16、ppap方式。
チェロは右、目の高さ。NASよりも少し外。RAMメモリ音源と同じ位置。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上に広がる。2分台前半、定位は安定。後半、響きは右からやや後ろに向かう。 バス、ほぼ中央右。

さて、、、図にしてみよう。

チェロの位置が変わるけど、どう評価したものやら。
本来は、リサンプルされたNAS音源の位置が正しいんだろうけど、より高性能なはずのDAC、fireface UCXの再生に近いのはRAM音源再生だ。そもそもコントラバスが中央で、本来の位置の右側から大きく外れているので、正確な再生はできていない中での試聴なので仕方ないかも。

ソプラノは、今回は前回よりも安定して鳴った。
定位のぶれが少ないのだ。
i2s DAC、侮れない。
数千円で買えるHATだから高級な音は望むべくもないので、普段はテスト用やサブシステムで使ってるけど、基本を押さえた音がする印象が以前からある。しかし空間を表現する音が少ないという弱点が逆に良い方向に作用したのかもしれない、のかな?

音色は、リサンプラーを通した音はRAMメモリ再生に近づくと言えば近づく。ソプラノの聴こえ方、響きの出方も似ている(試聴記録の文面、全く変えてないのは我ながらどうかと思うね、、)。
しかしチェロの定位が全く違う。これは、前回の結果と逆になったということだ。
そんなわけで、簡単に結論が出るもんじゃないんだろうけど。

今回はこのくらいにしておく。

Mar 18, 2018

MPDのアップサンプリングによる音への影響を確認してみる

piCore7をpiped pcm audio playのフロントにしたので、最近はこれで鳴らしていることが多い。mpd出力も使うんだけど随分減った。
いろいろあるんだけど、整理がてら書いていく。

まず、ppapだとsoftwareボリュームが使えない(4月8日、追記。これは間違い。mpd.confで設定したら使える)
以前なら音が大きすぎるなと思ったら、ncmpcppを操作してサッと音量を下げることができたが、ppapだとアンプまで歩いて行かないといけない。出力がpipeだからデジタルで調節できないのだ。
まあ、歩けばいいんだけどさ。
何か手立てはないかと思ってるんだけど、できていない。
フロントでalsaからncatに送るようにしたら出来るのかしれないけど、まだ十分に試みていないのだ。

そういうわけで現状、RAMメモリ再生だったらsoftwareボリュームで音量調整ができるけど、ppapならフロントにNASをマウントできるので好きな音源をさくさく選べるという、それぞれの優位性がある状況。両者の音質を比較しないといけないんだけど、これもできていない。

昨年の秋にノイズ対策でUSBターミネーター、LANにフィルターなどを追加し、USB-029H2-RPを導入したところ、音の出方がずいぶん変わった。更にppap方式も追加なので、短期間にほんとにあれこれ変わったので、途中経過が分からないんだけど、どうなってるのか簡単にまとめておく。

まず、素の44.1/16flacファイルの再生音がかなり底上げされた。
ppapで聴く44.1/16は、何しろ堅実でまっとうな再生という印象で、今まで聴いたことがなかった安定感がある。
くっきりした鮮度が高い感触は、以前よりも好ましい方向に強まっている。アップサンプリングした音の方が当たりが優しくて聴きやすいというのはあるんだけど、以前と比べたら差が少なくなった。44.1/16の特徴と思っていた若干肌理が荒い感じは減って、アップサンプリングした時の滑らかな感触に近づいている。
考えてみたら、これってRAMメモリ再生では感じなかったことなのだ。
しかし素の44.1/16でRAMメモリ再生をしたのは随分昔のことで、最近はアップサンプリングしてばかりだった。だから、再生方式による違いなのか、ノイズ対策の方が効いているのか、正確を期すなら確認する必要がある。

アップサンプリングのほうは、改善しているようなんだけど、そこまで大きな変化はない。
以前だったら、44.1/16は384kHzにアップサンプリングしたほうが情報量が多いと言えたんだけど、今は軽々しく言い難い。ちゃんとソースを選んで本腰入れて比較しないと、実際のところがどうなのか分からない。
じゃあ両者の再生音は近づいたのかというと、聴いた感触の違いはむしろ今の方が大きい。
オーディオ的にどちらが優位かがはっきりしなくなり、素の44.1/16の安定感とアップサンプリングの感触の良さ、そういう聴こえ方の嗜好のほうがむしろ、選択に影響する度合いが大きくなったのではないか、という感じ。

そういうところで、nano iDSD LEでアップサンプリングの音を確認することに、どれだけの意味があるのかな、と思うようになった。DACによって違うってことは当たり前にあるってことはあるんだろうけど、じゃあ、アップサンプリングの優位性があるかどうかはDACによる、ってことになるのかな。

以前だったら、明らかに384kHzにアップサンプリングしたほうが良くて、リサンプラーによる違いも明白だったので、ここは突き詰める必要があると思っていたんだけど、現在の音は、そこまでやる意味が減っているような。好みの問題に帰着するならするで、いいんじゃないの?という。
以前の音は、ジッターを生じやすい環境だとアップサンプリング(ハイレゾ)が有利というのに当てはまっていたのかとも思うけど。
今はそうじゃなくなった、のかなあ、、、どうなのか?

かたや、fireface UCXのほうはどうかといえば、これもあれこれあってCCモードのUSB入力になった。
SPDIF入力の時は192kHzにアップサンプリングする優位性があるように感じていた。
CCモードは96/24までなんだけど、これはアップサンプリングした方がいいのかどうか、音色はかなり違うけど分からない。どっちもどっちでいいので選択に迷う。これも先々きちんと比較する必要があるんだろうなと思う。

ああ、、、ひょっとしたら音色の感触が違いすぎるので逆に比較が難しくなってるのかな、、、

アップサンプリングについては、下記アドレスのような問題?も指摘されている。まさか定位に影響するとは。

http://community.phileweb.com/mypage/entry/2408/20180123/58315/

A:44.1KHz/16bit、44.1KHz/24bit、88.2KHz/24bit、176.4KHz/24bit
  ボーカルは中央に安定 チェロは右中央 コントラバスは右

B:48KHz/24、96KHz/24、192KHz/24bit
  ボーカルの定位はあいまいで不安定 チェロは中央、コントラバスは中央右

というように2分されます。AとBの中でも微妙な差はあります。例えば、16bitよりも24bitの方が滑らかで耳障りがよく感じる…とか、ボーカルの安定度は48KHzよりも96KHz、192KHzの方がよい…などです。ただし、その差はAグループとBグループとの音像定位の差ほどではなく微妙です。

アップサンプリングはトラポですることができる一方で、DACチップでも行われる。このへん、兼ね合いはどうなのか。DACチップ内で行われるアップサンプリング自体で定位が変わるということは、なにしろ製品なのだから有り得ないと、思っていいんだよね?、、、
あと、リサンプラーによって違うんだろうかとか。

そんなこんなで、これからどうしようかと思ってたけど取り敢えず、nano iDSD LEで自分なりにアップサンプリングの位置付けを明確にしよう、というところから始める。つまり、素の44.1/16から384/32までのアップサンプリング、をきちんと聴き比べてみようということ。リサンプラーも変えて。

これはppapではやりにくい。たびたびバックエンドを再起動する必要があるからだ。
あと、前回のエントリーに追記したけど、フロントにRas pi2/piCore7を使った場合、アップサンプリングで使えるのは192kHzまでのようだ。うちのppapでは、300kHz台へのアップサンプリングは聴けない。384kHzまでは確認したいので、そういう意味でも使いにくい。
だからNASマウントのmpdで設定を変えながら聴くことになる。

せっかくなので試聴に使うのは前述アドレスのサイトで話題になっている幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリアにする。
まず、44.1/16を聴いてみる、、、
さっそく、前述のサイトで説明されているのとは聴こえ方が違う。
ボーカルは中央に安定 チェロは右中央 コントラバスは右、ということなんだけど、うちではチェロが右でコントラバスが中央あたりに聴こえる。ボーカルは中央なんだけど、歌い始めはこもり気味。数秒で落ち着いたと思ったら、その後は上を向いたり右を向いたりしてるような。録音現場の反射を多く捉えているような聴こえ方。というか、後ろ向いてるの?、、、
そういう録音なの?と思っていたら、聴き込んでる人の解説がアップされていた。

http://community.phileweb.com/mypage/entry/3255/20180127/58351/

一時は右を向いたり左を向いたりしながら歌っているためと、録音のせいにしたりしていたんです。ですが、再生側を追い込んでいくとボーカルは前に出てきて、かつ歌声もぶれなくなりました。

追い込みきれていないということらしい。なんという恐ろしいソフトか、、、
確かにうちの環境は全く反論できない状態にあるが、そうそう追い込む暇はないんだな。
しかたない。
この状況でどう聴こえるかでやってみようか、、、

実際に試聴した時系列に沿って書いていく。

まず、リサンプラーなしの44.1/16。
チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上~左向きに。2分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

ボーカルは1分20秒すぎと2分台後半の定点観測と、他に気付いたことを書いていく。

リサンプラーにSoXを使用。

88.2/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上に向かう。2分台後半、定位がやや右、後方に揺れる傾向あり。
バス、ほぼ中央左。

ソプラノ、口元が正面に向かない感じの時が多い。そんな聴こえ方だ。基本的にそういうソースなんだけど、それでもあれこれやってみた結果、安定して再生出来た時は比較的前を向いて歌っているように聴こえる時間が多かったように思った。

96/24

チェロは右に定位。なんと、目の高さより高くなった。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、かつ響きが固い。1分20秒すぎ、高音の響きが上向き、さらに後方、左にも。2分台後半、やや右、後方に揺れる傾向あり。
バス、ほぼ中央。

176.4/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。響きが固い印象。1分20秒すぎのボーカル、高音の響きが上向きに。2分台後半、響きが右、後方に揺れるように聴こえる。
バス、ほぼ中央左。

194/24

チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、やや硬い。1分20秒すぎのボーカル、高音の響きは上向き。2分台後半、響きが後方に揺れる。硬い響き。
バス、ほぼ中央。

352.8/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上~右向き。2分台後半、響きが右、後方に伸びるように聴こえる。
バス、ほぼ中央左。

384/24

チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やはり、やや響きが広がりぎみでやや硬い。1分20秒すぎのボーカル、高音の響きは上~右。2分台後半、定位が右に揺れる。硬い響き。
バス、ほぼ中央。

SoXで聴いてきて、どうも44.1xのほうが伸びやかで聞きやすい印象。コントラバスの位置がなぜか44.1xで左に寄る。
48xだとチェロがやや上に上がるのと、ソプラノなど音色の響きが固くて聴き辛い印象。300kHz台となればましになるような気はしたけど、、、あんまり変わらないかな、、、

リサンプラーをlibsamplerateに変更。

一気に音色がやさしくなる!
これは違いすぎる。ここまでちょっと辛い試聴だったことに気付かされた。

88.2/24

チェロは右、目の高さ。
ボーカルは中央、正面(やや下がった)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上向き。やさしい響き。2分台後半、響きが前にでる。3分前、後方に揺れる傾向あり。
バス、ほぼ中央右。なんとまあ、SoXとは逆になった。

96/24

チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上~左右向き。2分台後半、やや右による傾向。
バス、ほぼ中央右。

176.4/24

チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上~左右向き。2分台後半、響き、定位ともに右による傾向。
バス、ほぼ中央右。

194/24

チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上~左右向き。2分台前半、定位は右に傾きがち。2分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

352.8/24

チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台前半、定位はやや右に傾く。2分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

384/24

チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台前半、定位はやや右に傾く。2分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

libasmplerateの場合は、サンプリング周波数による差異がSoXほど大きくない。
それと、サンプリング周波数を上げていくと順当に音が良くなっていく感触があったので、何となくいい気分で試聴できた。まあ、アルゴリズムの有り様から考えれば、サンプリング周波数での変化は少ないはずだという予測はしていた。
ものは試しと、libsamplerateで44.1/16にリサンプリングしてみた。

44.1/16

384と変わらない?w
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台後半、響きが右、後方に向かう傾向が強い。さすがに384よりも硬い響き。
バス、ほぼ中央右。

聴き始めは違いがないのかと思ったが、やはりボーカルなどの響きはアップサンプリングした方がいい。
ここでリサンプラーなしと聴き比べる。

44.1/16、リサンプリングなし。

チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上~左向きに。2分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

一言で言うと響きが硬い。
libsamplerateをアップサンプリングなしで通した音の方がずっと聴きやすくなるようだ。これは化粧した音と考えた方がいいのかな、、、しかし聴きやすいほうがいいよな、、、というか、最近はnano iDSD LEで聴くことは減ってきているので、この結果にあまり神経質になる必要はないのだけど。

そういうわけで、fireface UCXでどんな鳴り方になるか聴いてみる。
44.1/16、リサンプリングなしでCCモード、ppap。
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上~左右に広がる。2分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。

こんな感じ。
しかし定位がどうとかよりも音色の格が違う。
NASマウントのLEとppapのUCXの比較だから当たり前だ。

UCXでアップサンプリングも聴いてみるべきか、、、と思ったけど、、、もういいか。
うちでは使うならlibsamplerateと決まっているし、UCXとLEの結果が知れたからといって、だからどうなのかということもあるし。
ともかく、リサンプラーによって良くも悪くも音が変るし、リサンプラーの種類やサンプリング周波数によって変わり方が違うのも確認した。多分、DACによっても違うんだし。きりがないっちゃきりがない。

自分の納得がいくように、気持ちよく聴けるようにやれたら、それでいいと思う。
僕は、一種のゲームのような感覚でオーディオをやってるんだと思う。ひとつクリアしたら次の課題に移るという感覚。
そして幸か不幸か課題には事欠かない。

Mar 01, 2018

piCore7でppap (piped pcm audio play)を試みる

1月半ばからppapに取り組んでいる。
2月上旬での状況を前回のエントリーに書いたんだけど、その後、体調崩して人生初めての入院したりで、まだ本調子じゃない。
それでもようやく進捗があった。
piCore7をフロント化するのに成功した。

追記。せっかく作ってあったので構成図をアップ。

しかし、そもそも何でpiCore7なのか。
今回、フロントをどうするかはかなり難航した。普段使いのノートPC(Fedora26、27)は簡単にフロント化できたんだけど、アップサンプリングがうまくいかず原因は不明。それもあってRaspberry Pi2のフロント化に臨んだんだけど、これが難しかった。

まず、piCoreはpipeが使えないと来た。
その続きで、ライブラリを追加したりshellを変えてみたり、あれこれ試みたけど失敗続き。

次にRaspbian stretchを試みた。以前はちゃんと動いてmpdのインストールも出来たはずだが、今回これが起動しない。いや、起動しているんだけどdhcpサーバからipアドレスが振られないようで、LANに繋がって来ないのだ。原因不明。昔のjessieも引っ張り出してみたけど同様。

じゃあVolumio2でどうか。なんだか構造がよく分からない。mpd.confをいじったりncmpcppでアクセスして操作しても出音に反映されないことがある。どうなってるんだか、分からない。この際と思ってvolumio1.55でやってみたけど、やはりpipeが壊れてると表示される。

Archphile、、、これもLANに繋がらない。

そうこうして、piCore7に戻ってきたのだ、、、
今回あれこれやるうちに、ようやく気付いた。
piCoreの何がいいって、必ず普通に起動するのだ!

動かないことがあるディストリは、繰り返し試みたり試したりするには向かない。
その点、piCoreは焼くのは一瞬だし起動しないということがないしセッティングも短時間で出来上がる。扱いやすいという点で他の追随を許さないのだ(当家比較)。そういうわけで、ついつい使ってしまうんだと思う。

Front

そういうわけで、piCore7に戻ってきた。ようやくなんとかなったけど、何故なんとかなったのか正確な理由は分からない。
今回の流れを記載していく。.ash_historyファイルからコピペ。

filetool.sh -b
sudo resize2fs /dev/mmcblk0p2
ifconfig
vi /opt/eth0.sh
chmod +x /opt/eth0.sh
vi /opt/bootsync.sh
vi /opt/.filetool.lst
filetool.sh -b

ここまでで、基本的なセッティングを終了。
詳細は、http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm こちらのエントリーを参照のこと。
続いて、環境を構築していく。

mpdをインストールするのに必要なコンパイラ等々プログラムをインストール、、、
はっきりしないんだけど、flex、bison、gdbmあたりを追加インストールしたらpipeを使えるようになったような。どれが効いているのかは未確認。

tce-load -wi \
gcc_base-dev.tcz gcc-doc.tcz gcc_libs-dev.tcz gcc_libs.tcz gcc-locale.tcz gcc.tcz \
glib2-dev.tcz glib2-doc.tcz glib2-locale.tcz glib2-python.tcz glib2-dev.tcz \
glibc_add_lib.tcz glibc_apps.tcz glibc_base-dev.tcz glibc_gconv.tcz glibc_i18n_locale.tcz \
glib-networking-dev.tcz glib-networking-locale.tcz glib-networking.tcz \
binutils-dev.tcz binutils-doc.tcz binutils-locale.tcz binutils.tcz \
ncurses-dev.tcz make-doc.tcz make-locale.tcz make.tcz automake.tcz \
autoconf-doc.tcz autoconf.tcz libtool-dev.tcz libtool-doc.tcz \
compile-essentials.tcz squashfs-tools.tcz bash-locale.tcz bash.tcz bc-doc.tcz bc.tcz \
pkg-config-doc.tcz pkg-config.tcz cmake-doc.tcz cmake.tcz

tce-load -wi \
flex-dev.tcz flex-doc.tcz flex-locale.tcz flex.tcz \
gdbm-dev.tcz gdbm-doc.tcz gdbm-locale.tcz gdbm.tcz \
bison-dev.tcz bison-doc.tcz bison-locale.tcz bison.tcz \
python-dev.tcz python-doc.tcz python.tcz boost-dev.tcz boost.tcz \
doxygen-doc.tcz doxygen.tcz pv-doc.tcz pv-locale.tcz pv.tcz \
bash-doc.tcz bash-locale.tcz bash.tcz bc-doc.tcz bc.tcz

次にalsa、nmap、mpdが使うライブラリやエンコーダーをインストール。

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_v7+.tcz alsa-modules-4.1.20-piCore_v7+.tcz \
nmap-doc.tcz nmap.tcz

tce-load -wi \
libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz \
flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz \
icu-dev.tcz icu.tcz libid3tag-dev.tcz libid3tag.tcz \
libmad-dev.tcz libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz

tce-load -wi libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz

filetool.sh -b

続いて、mpdをコンパイルしてインストール。今回使ったのはv0.19.19。
コマンドを羅列。

wget https://www.musicpd.org/download/mpd/0.19/mpd-0.19.19.tar.xz
xz -dv mpd-0.19*
tar -xf mpd-0.19*
cd mpd-0.19*
./configure --enable-pipe-output

configureの結果表示を転記してみる。

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

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

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

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

(+Pipeline)と表示されている。以前はここまで出来てもmakeで通らなかった。

make
mkdir ../mpd
sudo make DESTDIR=../mpd install
cd
mksquashfs mpd mpd-0.19.19.tcz
md5sum mpd-0.19.19.tcz > mpd-0.19.19.tcz.md5.txt
sudo mv *tcz* /mnt/*2/tce/optional
sudo vi /mnt/*2/tce/onboot.lst

インストール完了。あとはmpd.conf、mpdの動作環境を作成していく。

cp m*9/doc/mpdconf.example .mpdconf
sudo rm -rf mpd*
vi .mpdconf
mkdir .mpd
mkdir .mpd/playlists

filetool.sh -b

mpd.confの記載例。

4月9日、追記。
下記のmpd.confの記載例で、mixer_typeの設定について書き直した。
というのは、僕はずっとmixer_typeはalsaの設定だと思い込んでいたんだけど、mpdのユーザーマニュアルをよく読んでみたらそうではなかった。alsa以外のaudio_outputにも適用されるということらしい。mpdの更新履歴を読んでみたら、どうもv.0.16でそういう仕様になったようだけど、はっきりしない。
詳細は下記アドレスのUser's Manualを参照のこと。The following table lists the audio_output options valid for all plugins と記載がある。
https://www.musicpd.org/doc/user/config_audio_outputs.html

そのUser's Manualを読んで、replay_gain_handlerも設定しておいたほうがいいんじゃないかなと思われたので書き加えている。

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

auto_update     "no"

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

mixer_type "software" ## hardware, software or none
replay_gain_handler "none" ## software, mixer or none

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

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.82 4444"
}

filesystem_charset "UTF-8"
id3v1_encoding "UTF-8"

上記のmpd.confに合わせてmusic_directoryを設定する例。
piCore起動時にmusic_directoryを作って、NASのtitanディレクトリをマウントするように設定している。

vi /opt/bootlocal.sh

(下記をbootlocal.shに追記)

mkdir /mnt/music
mkdir /mnt/music/nas
mkdir /mnt/music/ram
touch /mnt/music/ram/dummy.cue
chmod -R 777 /mnt/music
mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /mnt/music/nas

これら設定を忘れず保存すること。

filetool.sh -b

以上で、piCore7のフロント化、完成。
ちょっと追記。使用に際してはsshでログインしmpdを起動させる仕様。自動起動にはしていない。

3月13日、追記。
フロントにRas pi2/piCore7を使った場合、アップサンプリングで使えるのは192kHzまでのようだ。300kHz台にすると音が出ない。
普段使いのノートPC、HP 6730b/Fedoraでは98kHzが上限だった。上の数値を設定してもなぜか98kHzで出力された(nano iDSD LEのLEDインジケーターで確認)。
どうなってるのかと調べたけどはっきりしない。
ただ、pipeの容量には上限があるということらしく、OSの実装により上限は異なるということらしい。

Man page of PIPE
https://linuxjm.osdn.jp/html/LDP_man-pages/man7/pipe.7.html

Linux 2.6.35 以降では、パイプの容量のデフォルト値は65536バイトだが、 パイプの容量を参照、設定を fcntl(2) の F_GETPIPE_SZ と F_SETPIPE_SZ 操作を使って行うことができる、とある。これがアップサンプリングに上限がある理由なのかどうか分からないけど、fcntlを使うというのも当方には難しく、これ以上は調べずにいる。

Back-End

バックエンドはraspberry pi B+/2、piCore7で組んでいる。
これは初期状態にalsaとnmapしかインストールしていないような状態で、それでもちゃんと動いている。
period-sizeの設定によってCPU使用率がかなり変わるようなので、うちでは256と多めに設定している。そのほうがCPU使用率が下がる。逆にbuffer-sizeは2048と少なめだ。どのくらいがいいのかは確かめていない。

追記。
raspberry pi B+でバックエンドを組んだ場合、USB出力だとプチノイズを生じることに気付いた。
period-sizeやbuffer-sizeの設定を弄る程度では解消しない。
しかし、i2s出力だと問題ないようだ。
USB/LAN周りが脆弱なRas piだと、シングルコアだとデータやタスクの管理に限界があるのかもしれない。piCore以外のディストリでどうかは分からない。

filetool.sh -b
sudo resize2fs /dev/mmcblk0p2
cd /opt
vi eth0.sh
chmod +x eth0.sh
sudo vi bootsync.sh
vi .filetool.lst
filetool.sh -b

( わかりにくいので追記。
ここまでの流れは.ash_historyファイルからのコピペ。
いくつか記録されてないコマンドがあったりする。
詳細は、http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm こちらのエントリーを参照のこと。
)

cd

( 追記。
下記のalsa、nmapのインストールコマンドはras pi B+の場合のコマンド。
pi2/3の場合、alsa-modulesの名称が違うので注意を。
 )

tce-load -wi \
nmap-doc.tcz nmap.tcz alsa-config.tcz alsa-dev.tcz alsa-doc.tcz \
alsaequal.tcz alsa-locale.tcz alsa-modules-4.1.13-piCore+.tcz \
alsa-modules-4.1.20-piCore+.tcz alsa.tcz

( 追記。
4月13日の時点でras pi B+に7.xだとnmapのインストールがうまくいかない。
9.xだったら下記でうまくいく。

tce-load -wi \
nmap-doc.tcz nmap.tcz \
alsa-modules-4.9.22-piCore.tcz alsa-plugins-dev.tcz alsa-plugins.tcz \
alsa.tcz alsa-utils-doc.tcz alsa-utils-locale.tcz alsa-utils.tcz

以上、追記した。 )



filetool.sh -b

vi /opt/bootlocal.sh

(下記をbootlocal.shに追記。適宜編集)

# /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd"
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=256 --buffer-size=2048 -t raw -f S24_LE -r96000 -c2"
# /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=256 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"


(追記後、設定を保存)

filetool.sh -b

5月22日、追記。
上記に「 -D plughw:0,0」の記述を書き加えた。
これがないとUSBに出力が自動的に48kHzにリサンプリングされる。
alsaのデフォルトらしい。
i2s出力はリサンプリングされずに出力されるようだ。

音質評価は未だしていない。追々、余裕があるときに。

Feb 05, 2018

ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jan 03, 2018

piCore7にmpdをインストールする方法

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

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

毎度のことで、今回もあちこちに訂正とか追記、改訂を入れている。 1月9日、sshについて追記訂正した。rebootする前にfiletool.sh -bで鍵を保存してしまえば再ログインで蹴られることはない。こんな当たり前のことに気付くのに1年半かかっているということで、我ながら呆れてしまう。

piCore7をダウンロード。

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

raspberry pi B/B+piCore OShttp://tinycorelinux.net/7.x/armv6/releases/RPi/
TCZhttp://tinycorelinux.net/7.x/armv6/tcz/
raspberry pi 2/3piCore OShttp://tinycorelinux.net/7.x/armv7/releases/RPi2/
TCZhttp://tinycorelinux.net/7.x/armv7/tcz/

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

1月末、追記。数日前に気付いたんだけど、v.6にもmpd.tczが追加されている。 いつの間に、、、記憶違いでなければ、前はなかったと思うんだけど、、、 当方で使ってみるには至っていない。

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

microSDの準備。

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

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

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

DAC/DAC+ Lightdtoverlay=hifiberry-dac
DAC+ standard/prodtoverlay=hifiberry-dacplus
Digi/Digi+dtoverlay=hifiberry-digi
Amp/Amp+dtoverlay=hifiberry-amp

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

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

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

filetool.sh -b について

ログイン直後にfiletool.sh -b コマンドを打つことで、sshの鍵が保存される。

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

piCoreでは、上記タイトルのコマンドで、適宜、変更した設定などを保存しておく必要がある。
全てRAM上で動くOSなので、コマンドを打ってmicroSDに保存するのを忘れていたら、電源を切ると同時に設定していたはずの内容が消失してしまう場合がある。OSを再起動したら設定前の状態、以前に保存した状態に戻っている。
そういう理由で、一通り設定が終了するまでの間にしばしば使用することになるコマンドなので予めここに記述しておく。

filetool.sh -bを打たないまま、下記の行程のパーティション拡張を行なったら、piCore7上にsshの鍵が保存されないので、sshで再ログインしようとした際に蹴られる。もしもそうなったらどうしたらいいかは下の方に記載している。

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

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

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

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

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

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

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

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

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

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

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

うっかりして、filetool.sh -bコマンドを打ってsshの鍵を保存するのを忘れていた場合、リブートしたらsshの鍵が無効になっている。ログインしようとしたら撥ねられる。そうなったら、sshクライアントとして使ってるパソコンの.ssh/known_hostsに保存されている鍵、ipアドレス:xxx.xxx.xxx.xxxの行を削除する。削除したら、初回ログインと同じ行程でログインできる。
filetool.sh -bコマンドでsshの鍵を保存するのを忘れないこと。

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

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

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

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

filetool.sh -b について

piCoreでは、上記タイトルのコマンドで、適宜、変更した設定などを保存しておく必要がある。
全てRAM上で動くOSなので、コマンドを打ってmicroSDに保存するのを忘れていたら、電源を切ると同時に設定していた内容が消失してしまう。OSを再起動したら設定前の状態、以前に保存した状態に戻っている。
そういう理由で、一通り設定が終了するまでの間にしばしば使用することになるコマンドなので予めここに記述しておく。

ipアドレスを固定。

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

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

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

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

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

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

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

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

bootsync.shを編集。

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

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

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

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

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background 
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth0.sh &
.filetool.lstの編集。
tc@box:/opt$ vi .filetool.lst

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

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

いきなり追記。
上の内容を眺めていて、今更一番上に「opt」とあるのに気付く。
これって、/optディレクトリの内容は保存されるってことじゃないだろうか。
試しに、
opt/bootlocal.sh
opt/eth0.sh
の2行を削除して動かしてみる。、、問題ないみたいだ。
.filetool.lstに追記しなくても、bootlocal.shもeth0.shもfiletool.sh -bで保存される。

ということで訂正。
usr/local/etc/のみ追記でいいようだ。
/usr/local/etc/にはalsaのファイルもあるようなので、追記しておいた方がいいんじゃないかな。たぶん、、、

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

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

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

bootlocal.shを設定。

tc@box:/opt$ vi bootlocal.sh

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

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

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

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

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

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

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

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

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

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

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

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

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

tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz
tce-load -wi flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz icu-dev.tcz icu.tcz
tce-load -wi libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz faad2-dev.tcz faad2-doc.tcz faad2.tcz
tce-load -wi libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz
tc@box:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz\
Done.
tc@box:~$ 

忘れず、保存、、、

mpdをインストール。

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

  • (1)tce-load -wiコマンドでmpdをインストール。
  • (2)ソースからコンパイルしmpdをインストール。
(1)tce-load -wiコマンドでmpdをインストール。
tc@box:~$ tce-load -wi mpd-doc.tcz mpd.tcz

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

tc@box:~$ mpd -V
Music Player Daemon 0.19.9

Copyright (C) 2003-2007 Warren Dukes 
Copyright (C) 2008-2014 Max Kellermann 
This is free software; see the source for copying conditions.  There is NO
warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Database plugins:
 simple proxy

Storage plugins:
 local smbclient

Neighbor plugins:
 smbclient

Decoders plugins:
 [mad] mp3 mp2
 [mpg123] mp3
 [vorbis] ogg oga
 [oggflac] ogg oga
 [flac] flac
 [opus] opus ogg oga
 [sndfile] wav aiff aif au snd paf iff svx sf voc w64 pvf xi htk caf sd2
 [dsdiff] dff
 [dsf] dsf
 [faad] aac
 [ffmpeg] 16sv 3g2 3gp 4xm 8svx aa3 aac ac3 afc aif aifc aiff al alaw amr anim
 apc ape asf atrac au aud avi avm2 avs bap bfi c93 cak cin cmv cpk daud dct divx
 dts dv dvd dxa eac3 film flac flc fli fll flx flv g726 gsm gxf iss m1v m2v m2t m2ts
 m4a m4b m4v mad mj2 mjpeg mjpg mka mkv mlp mm mmf mov mp+ mp1 mp2 mp3 mp4 mpc mpeg mpg
 mpga mpp mpu mve mvi mxf nc nsv nut nuv oga ogm ogv ogx oma ogg omg opus psp pva qcp qt
 r3d ra ram rl2 rm rmvb roq rpl rvc shn smk snd sol son spx str swf tgi tgq tgv thp
 ts tsp tta xa xvid uv uv2 vb vid vob voc vp6 vmd wav webm wma wmv wsaud wsvga wv wve
 [pcm]

Output plugins:
 null fifo alsa ao oss pulse jack httpd recorder

Encoder plugins:
 null vorbis opus lame twolame wave flac

Archive plugins:
 [bz2] bz2

Input plugins:
 file alsa archive curl ffmpeg smbclient

Playlist plugins:
 extm3u m3u pls xspf asx rss cue embcue

Protocols:
 file:// http:// https:// gopher:// rtp:// rtsp:// rtmp:// rtmpt:// rtmps:// smb:// alsa://
tc@box:~$ 

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

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

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

(2)ソースからコンパイルしmpdをインストール。
tc@box:~$ wget https://www.musicpd.org/download/mpd/0.19/mpd-0.19.9.tar.xz
tc@box:~$ xz -dv mpd-0.19*
tc@box:~$ tar -xf mpd-0.19*
tc@box:~$ cd mpd-0.19*
tc@box:~/mpd-0.19.9$
tc@box:~/mpd-0.19.9$ ./configure

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

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

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

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

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

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

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

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

tc@box:~$ sudo reboot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.mpdconfの編集例。

tc@box:~$ vi .mpdconf

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

auto_update     "no"
#auto_update_depth "3"

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

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

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

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

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

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

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

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

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

Dec 24, 2017

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

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

audio system

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

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

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


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

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

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

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

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

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

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

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

Dec 23, 2017

赤い鳥の音源について思ったこと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dec 21, 2017

「おんな城主 直虎」が最終回を迎えたり

おかげさまで1年間、楽しませていただきました。

放送中は視聴率が振るわないとか下らない理由で内容のない意味不明なレビュー記事がビジネスニュースのサイトとかに書かれたりしていたけど、今となっては過去の事とされているようだ。練りこまれた台本、台詞回しの凄さ、それに付いて行く役者の演技に魂がこもっていること、などなど、あちこちで今更のように語られている。

しかし、僕なりに感じた直虎の他では見られない魅力というか深淵というのか、この場で書いておこうと思う。
僕は不勉強なので、ありふれた内容の文面かもしれない。予めまとめると、直虎というドラマは異界と隣り合わせの現世を描き切ったことで成功したということを書いている。

どこから手を付けたらいいか。
だらだら書いていく。

この10年以上、僕にはTVドラマを見るという習慣がなかった。
今年の大河、女房子供に付き合う形で見ることになった。女房は歴史オタクで大河にはうるさい。女大河はいまいちなのが多い、「戦さはいやじゃ!」とか言って押し切るからリアリティがない、などと聞かされながら見始めた。

しかし、いきなり僕はオープニングタイトルにもっていかれてしまったのだ。
見てるうちに、不覚にも涙が出てしまった。
そんなドラマ体験は今までないよ。
もしもドラマの内容がダメでもオープニングタイトルだけ1年見てもいいかもな、などと考えた。
それだけ考えて作りこんだ映像、音楽だったと思うし、直虎というドラマの主題がとても上手く表現されていて、長いタイトルにもかかわらず中弛みなく最後まで見てしまう。ドラマ本編で何が語られるのか、オープニングで視聴者にも感じ取れる、いいオープニングタイトルだと思う。

次に、子役かな。
子役が子供の頃の役をするなんて当たり前のことじゃないかと僕なんかは思ってたけど、最近はあまり重視されてなかったらしい。子供時代がきちんと描かれ、しかもこの子役が馬に乗ったり(!)、坊主になったり(!!)する。
このドラマは本気らしい、という気分にさせられる。
ちょっと、こっちも本気で見ないといけないかなというモードにさせられていくのだった。

その子供時代に、竜宮小僧なる謎の言葉が出てくる。あと、井戸が。
異界につながるような井戸が。
この井戸のそばで、登場人物たちは胸の内を語り、ドラマの行く末が決まっていく。異界への窓がぽっかり開いている村では、坊主たちが頻繁に行き来し、主人公もまた尼になっているのだ。そして度々、登場人物たちが井戸端で死者を思い酒を飲んでいる。

このドラマでは、異界の傍に人間界があるということが最初から構造化されているのだ。
最初はそのことには気付かない。
あまりにも自然に、そこにあるので。
しかしドラマの中、そこかしこに、ちらりちらりとそれが異物として顔を出す。
台本は、歴史考証はしっかり踏まえながら新たな解釈を盛り込んでおり役柄の心理描写もすばらしくリアリティがあるのだけど、そこかしこに顔を出す異界からの使者、信号は、このドラマに独特の奥行き、ゆらぎを生み出している。

例えば、徳政令の回。
驚かされたのは亀が演技をしたことだ。
神社で直虎が徳政を受け入れ花押を書こうとしたところ、亀がどこからともなく現れて止めるのである。
見ていたこっちは、これは凄い話だと思った。
そもそも、亀が出てくる必要性は筋書き上はないのだ。直虎本人が1人で決心しても筋書き上は問題ないのだ。でも、でも、亀が止めるのだ。

直虎というドラマでは、亀が直虎を止めることに意味がある。
今から思えば、この展開を受け入れられるかどうかで、たぶん視聴者の篩い分けが成されたのだ。亀を受け入れることで、視聴者はこのドラマの魔法に絡め取られたのだと思う。

最初、僕はそれを「中世らしい感覚」なのだと思っていた。戦国の世を生きる登場人物たちの心理が、当時の宗教観世界観も含めてうまく脚本化されているから、現代人の感覚とは違う死生観、人生観が表現されてドラマにリアリティを与えているのだと。

でも、毎週見続けるうちに、どうもそれだけじゃないと感じ始めた。
心理描写、戦国社会の描写とは別に、彼らを取り巻く世界の表現が、現代的なリアリティから逸脱しているのだ。前述の亀の件もそうだし、空に龍雲が現れたり、信玄を寿桂尼が呪い殺したり、離れているのに同じ手筋で碁を打っていたり。そして、死者から遺されたものが生ける者を動かす力を持つ。
アレルギーに対する減感作療法のように、少しずつ視聴者のガードが崩されていく。

これを「中世らしい感覚」と言って良いのか分からない。
当時は祈りや呪い、迷信が現代よりもずっと深く意味を持っていた時代。世界の成り立ちも、現代とは違っていたんだろうか。点在する目に見えるエピソードと、通奏低音のような何か、それは竜宮小僧の存在感かもしれないし、積み重なる死者たちへの思いかもしれないし、心のうちを隠さなくては生きていけなかった人たちの心の声の行き場なのか。そうした不思議な世界が、こっそりと、しかし実在感を持って描き出されている。
迷信を信じてしまう心性は現代を生きる僕らの心の底にも息づいている。直虎を見ていると、なんというか、それが蠕き始めるような、そんな感覚があるのだ。

その結果、視聴者はどうなるか。直虎が政次を槍で刺すのを受け入れるようになるのだ。
そう、あの名場面、かなり話題になったあの場面。
しかし、考えてもみなよ。
最終回終わって一息ついて覚めた頭でもう一回考えてみようよ。
あんな、とんでもない話ってあるか?
直虎が、政次を刺し殺しちゃうんだよ?
ほんとにあれって究極の信頼関係って涙したりして、本当にそれでいいの???、、、

僕は思うのだけど、あれが通用したのは、視聴者が受け入れることが出来たのは、直虎の舞台が異界とつながった世界、現代人の感覚から外れた世界だということを、みんなが心の奥底で受け入れることができていたからだと思うのだ。
このドラマは、意識してかどうかは分からないけど、そういう構造の下、従来の大河ドラマが絡め取られてきた現代人のリアリティ感覚という縛りを、無化することに成功したと思う。
というか、直虎の世界で通用するリアリティを獲得したというか。
政次ロスが通用する世界観を予め構築できていなければ、あんな場面、絶対に視聴者に受け入れられなかったはずだ。それがこのたび、制作者も視聴者も、これだよね!って感じで受け入れ演じて観てしまった。
あの場面はまるで、神話の世界のイコンか何かが現れたかのようだった。

そして、その流れに乗ったまま、最終回を迎えたわけで。
最終回では、直虎の死に際して、笛が万千代のもとから直虎のところまで飛んでいく。
笛の音を聞いた直虎は子供に戻って願いがかなう未来を見に行く。
最後のシーン、直虎が死後の世界で過ごしている場面でドラマは終わる。
異界、死後の世界が現世の傍にあるという世界観を、あからさまに表現した、そんなファンタジックな展開が全く不自然じゃなくて、むしろ感動的な必然に感じられて、すばらしい最終回だったと思う。

直虎は、制作側と視聴者側ともに、独自の世界に巻き込むことに成功した。
おそらく、これは直虎を主人公に選んだから可能だったんだろうと思う。
半身を異界にかけたような存在でいながら、大河ドラマの主人公を張ることが出来る歴史上の人物は、なかなかない。史実となる資料がほとんどない直虎だから逆に、リアルでありながらファンタジックな実在感を描き出すことが出来たんだろうと思う。
史実が多い人物はファンタジックにできない。下手したら荒唐無稽になってしまうからだ。

そういう意味で、直虎を超える大河ドラマを作るのはかなり難しいはずで、唯一無二となるかもしれない大河を最初から最後まで楽しめた僕は幸運だった。ドラマという異世界で1年間遊ぶことが出来た。単に良く出来たドラマを見たという以上の、不思議な感覚を楽しむことが出来た。

22日、今更分かりやすい言い方を思いついたので追記。
直虎に関わった者はみんな、製作側も視聴者も、竜宮小僧の手の上で遊んだのだ。
徳政令の回、竜宮小僧は亀になった。
その後、竜宮小僧の影は薄くなったかに見えたが、それは竜宮小僧が亀となり直虎宇宙の底を支えたからだ。
ほら、インドの言い伝えでは宇宙の底に亀がいるでしょう。
そういうことなんだ。

年末年始には総集編があるらしい。
http://www.nhk.or.jp/naotora/info/program/article51.html
こんな濃厚なドラマ、半日で尺が足りるんだろうか。どう料理されてるか楽しみだ。

Posted at 12:23 in letterbox | WriteBacks (0) | Edit

Dec 02, 2017

fireface UCXについて再び(不覚だった、、、)

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

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

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

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

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

さくさく追記。 UCXに繋いでいるRas Piに使っているケースをLEのRas Piにも使ってみた。以前使った時は思わしくなかったけど今回は改善効果がみられる感じ。ささやかながらあれこれノイズ対策したのが効いたんだろうか。
UCXのCCモードとLEの384kHz、どうするか、しばらく比べながら使っていこうと思う。

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

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

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

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

早々に追記。CCモードではS/PDIF入力を扱えないと書いたけど、ファームウェアのアップデートで使えるようになっていた。詳しくはRMEのサイトを参照のこと。しかし、アップデートしたら音も変わるかもしれない。

https://synthax.jp/cc.html

今回、AppleよりiOS 6にてマルチ・チャンネルのプレイバックが正式にサポートされたことと、iPad本体の性能向上や8チャンネル以上を取り扱えるアプリの登場などにより、SPDIFやADATを含むFireface UCXの18チャンネルすべての入出力が使用できるようになりました。Fireface UCXのクラス・コンプライアント・モードは、下記のファームウェア・アップデート・ツールによりアップデートすることができます。

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

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

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

Oct 22, 2017

オーディオ状況報告とか、いろいろ(2017.10.22. USB029H2RP導入など)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

早々に追記。アース線を繋いだ方がより安定するように思う。
使っていないアングルフレーム(長さ60cmの鉄片)を引っ張り出して塗料を少し削って電導を確保。FGからそこに落としている。アース線は、これも道具箱の底に埋もれていた、ホームセンターで売ってるようなありふれたものを使っている。

25日、さらに追記。
どうもアースなどの設定以外にも継いでいるDACやケーブルによって安定度が違う様子。RATOCのDDCに継いでいるほうはアース線とかなくても、問題なく鳴っているのだ。ちょっと、いろいろと確認していく必要がありそうだ。

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

audio system

Sep 26, 2017

ノイズ対策をあれこれやると音がずいぶん変わってしまった(11月21日USBターミネーターについて追記)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自作USB簡易フィルター

参考サイト。

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

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

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

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

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

自作USB簡易フィルター部品
自作USB簡易フィルターターミネート抵抗付き

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

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

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