Current filter: »jitter« (Click tag to exclude it or click a conjunction to switch them.)
Dec 10, 2023
ストレージ
今回は、大した内容はない。
デジタル音源を扱うストレージは悩ましいという話。
若い頃にデジタルだから音は同じと聞かされ続けたせいか、理屈や体験で理解はできても、未だに「同じ01なのに音が変わる」ことについて、違和感がある。同じデータなら同じ音で鳴ってほしいと思ってしまう。
NAS音源とストリーミングで音が違うのを、同等にしたいと思う。
まあ、その一方で、USB HDDによって音が違うのは、なるほどなあって感じで受け入れているのだけど。
とあるオーディオ評論家が、苦言を呈しておられる。
ジッターの影響を減らすように配慮した音源をイベントで用意しても、オーディオ業者は理解していないので無意味になるということらしい。音質が良くないUSBメモリに音源を入れてくる、配慮した音源を業務用のパソコンに保存される、など。
せっかく配慮した音源を用意しても、周囲の無理解で音源の優位性が失われる。
お気持ちはお察しする。
しかし、僕はむしろ、デジタルコピーしても音質劣化しないようにするにはどうしたらいいのか、を知りたい。
アナログなら評価が定まった良質音源を探すことが出来る。
デジタルではそうもいかない。
形が変わらないアナログと違って、デジタルはコピー、転送、ユーザーの手元で品質がコロコロ変わる。
変わっても元のデータは同じ。
アナログディスクは割れたらおしまい。
デジタルデータはバックアップがあればストレージが壊れても残る。
データは同じだが、アナログの良質音源とは違って「ジッターを帯びた不完全な音源」となる。いや、デジタル音源はすべて、そういうレッテルを、ユーザーが自身によって張り付けざるを得ない。
あるいは、「01だから同じ」と割り切るのかな、、、
ストレージ、USBメモリやHDD、リッピングやコピーの方法、何がいいのか分からない。音源やコンポと違って、批評や評価がないからだ。特定の商品でそういった配慮をしたものはあるけど少数で、技術的なアドバンテージが明確な根拠をもって語られることが、あんまりない気がする。説明があっても、素人にしたら煙に巻かれる様だ。
一方、どのような環境、状況で使うかによって音質は変わるので、素人による製品や手法の評価はままならない。
以前はどんなドライブがいいとかあったが、最近はあんまり見なくなった。いいのがないという話もみたことがあったが、それすら最近はない。
結果、入手した製品を手探りで可能な限り上手く使うしかないのではないか、と言わざるを得なくなる。
その一方で、ストレージのジッターに配慮しない者が多数な世間では、良質な媒体や製品を提供しようとする者への、黙殺ならいいほうで、中傷や批判が主流派として罷り通る。
デジタルコピーしても音質劣化しないようにする、あるいは悪影響を最小限にする方法を、知ることができない。
それは、そういう方法が求められていないから、ということでもある。
もしかしたら、今までの経緯、数十年のデジタルオーディオの変遷の中で、諦められたからかもしれない。
技術的に一般化することが困難なのであれば、ユーザーが戸惑い立ち止まっても、仕方がない面がある。
それは、まじないとかオカルトと言われても反論できないということだ。でも、そうなのかね?
現実にHDDが違えば音が違うが、そうはいっても、実装の仕方でも環境要因でも評価は変わるだろう。簡単にどの製品がいいとも、言いにくいんじゃないかと思う。
そういう意味で、個別の製品は、批評や評価の対象になりにくいと想像する。
だったら、ユーザーが入手できる雑多な製品をユーザーなりに可能な限り上手く使えるようにする、そういう手法やノウハウを、どこかで誰かが提示すべきじゃないだろうか。それも、技術的な根拠を十分に添えて。
できないのかな。それに、誰がするのよ。
でも、そういう状況が生まれてきたら、たぶん、ストレージ使用の悩ましさとか、デジタルオーディオのよく分からなさも、薄れるんじゃないかと思うのだ。
配慮された高価な製品がある一方で、コンシューマー向きで安価な製品を使いこなすノウハウもある。
そういう状況はアナログオーディオでは一般的だ。
デジタルオーディオは、オカルティックな空気の中で、技術とユーザーが分断されている(そうした状況が、いかがわしいYoutuberが再生回数を稼いだりする温床になっている気がする)。
あんまり良くないと思うのだ。
いかがなものだろう。
今に始まったことではないし、難しいんだろうがなあ。
話は変わるけど、そんな面倒なノウハウを考える必要が少ないフォーマットとして、MQAが生まれたと僕は思う。
そういう意味で、技術を潰すのは惜しいと思っている。
Nov 10, 2023
mpdサーバーに銅メッシュを仕込んでみる(17日、追記)
最近、オーディオサーバーのノイズ対策に、筐体内に銅メッシュを仕込むというのを試みている。
まずPPAP Back-End、Middle-Endときて、Daphileサーバー2台に仕込んだ。
次に、mpdサーバーに仕込む。
mpdサーバーはPPAP Frontであり、UPnPレンダラーでもある。うちではそういう構成で運用している。
まず、テスト用mpdサーバー。
機種は、Hp Elitebook 820 G2。中古のノートPCだ。OSはTiny Core 64 11.1。
仕込み中の写真は撮り忘れた。
銅メッシュはキーボードの裏側に置ければ良かったんだけど、分解の手間が多い。本体の底面側を開けるのは簡単なので、そこに絶縁用の藁半紙と一緒に設置した。GNDはファンの縁の地金に銅メッシュを押し付けて取ることに。
気になるのは、銅メッシュの設置位置が筐体の空気吸入孔に重なるので、冷却機能に影響しないかということ。あまり温度が上がるようなら、設置場所を再検討しないといけない。
前回エントリーと同様の方法で、温度を確認した。
3秒ごとの数値を5分間計測しtxtファイルに打ち出し、それを集計し電卓等を使って平均値を出す。
tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt [ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt 44438 (min:44000 max:45000)
音を出していないときの温度は、若干、上がった。風通しが悪いからか、、、
次に、音楽を鳴らしてどうなるか確認した。
ちなみに前エントリー以降、温度計測に際して音源に使っているのは下記CD box、1枚目CDのリッピングflacファイル。NAS音源だ。
Quator Danel - Shostakovich - The Complete String Quartets
https://www.discogs.com/release/8599892
Fastest、192kHz 47926 (min:47000 max:50000) Fastest、768kHz 51383 (min:48000 max:58000) Medium、768kHz 57876 (min:51000 max:65000) Best、192kHz 56093 (min:53000 max:62000)
銅メッシュをつける前と比べたら、若干温度は下がっているのかな。どうだろう。
音質はどうなのか。
Medium、768kHzで鳴らす。
ぐっと、良くなった、気がする。何より色合いが濃くなって力強くなった。以前のテスト系 Medium 768kHzは、メイン系のBest 384kHzと比べたら、良く言えばスマートでモニター的だが線が細い印象だったんだけど、厚みが出てきた。
NAS音源でメイン系と比較してみる。libsamplerateの設定が違うので、音は違う。しかし差異はかなり小さくなった気がする。ブラインドでの聞き分けは、僕には出来ないだろう。
ストリーミング音源はどうだろうか。上述した音源は、Deezerにもある。
以前より、ずっと良くなっていると感じる。
NAS音源との比較では、差はある。比較したらNASの方がキレが良くて生命力が強いのだ。若干、情報量も多いような気がする。しかし、以前よりも差は減った。ブラインドで当てるのは、かなり聞き慣れた音源でないと難しそうだ。
テスト系とメイン系で、ストリーミング音源再生を比較してみる。
設定が違うので音も若干違うが、NAS音源のときと同様、音色の濃さがほぼ同等になった。
テスト系の音は、以前はクールで淡白な感触だった。それが銅メッシュを組み込んでからは、熱を帯びて鳴るようになっている。音色がメイン系に近付いて、色合いが濃くなったような感じだ。同時に、余音のような、音と音の間を埋めるような音が、より明瞭にリアルになった感触がある。
なんというか、これだけ聴いていたら、ストリーミングだけで何が不満なのか、という感じに鳴っている。
ここでテスト系とメイン系、mpdの設定を同じにして比較してみる。
メイン系をテスト系に合わせて、Medium 768kHzに。これはテスト系サーバーにとっては相当重く、メイン系サーバーにとっては比較的軽い操作だ。
音源はストリーミング。
温度だけ見たら、テスト系は20℃近く、メイン系は15℃弱ぐらい上がるようだ。
音は、メイン系の方に余裕があるようで僅かに反応が早い。ブラインドでは分からないんじゃないかな。
以前は、ここまで僅差ではなかった。それでも、この微妙な差は、もしかしたら重要な感じで、響きの美しさはメイン系の方が僅かに良いのかな。
ストリーミング音源使用時の温度。
前述のCDリッピング音源と同じ作品の、Deezer音源を使用した。下記が結果。
Fastest、192kHz 49952 (min:49000 max:51000) Fastest、768kHz 53644 (min:51000 max:61000) Medium、768kHz 60738 (min:53000 max:68000) Best、192kHz 57295 (min:52000 max:63000)
やはり、温度は上がっている。UPnPの負担が増えているので当然か。
そういえば、銅メッシュなしのとき、ストリーミングでどうだったか、記録してないな、、、
銅メッシュを外して、ストリーミングで鳴らしてみた。結果は下記。
Fastest、192kHz 47786 (min:47000 max:49000) Fastest、768kHz 53748 (min:51000 max:62000) Medium、768kHz 60738 (min:53000 max:69000) Best、192kHz 58291 (min:54000 max:64000)
温度はメッシュを付けているときよりも低いときがある。前回エントリーで挙げた、NAS音源を鳴らしていたときよりも低いときもある。銅メッシュで温度が下がるというのが、怪しくなってきた。筐体の蓋を開閉した直後に測ったせいかもしれないが、関係ないかもしれない。本当はもっと繰り返しデータを取るべきなんだろうが、そこまで取り組む根気はない。
銅メッシュを外すと、音は良くも悪くもクールになる。奥行、深みは少ないが、これはこれで、そんなに悪くはない。すっきりしていて涼しくて淡麗だ。しかし比較し評価するなら、メッシュがあるほうがいい。
温度を表にしておく。
無音 | Fastest、192kHz | Fastest、768kHz | Medium、768kHz | Best、192kHz | |
NAS | 44000 | 47267 | 53019 | 59670 | 58452 |
Deezer | 47786 | 53748 | 60738 | 58291 | |
NAS (Cu+) | 44438 | 47926 | 51383 | 57876 | 56093 |
Deezer (Cu+) | 49952 | 53644 | 60738 | 57295 |
さて、次はメイン系mpdサーバーの処理だ。
他のサーバーに比べたら新しい。
機種は、Hp Probook 450 G9。OSはTiny Core 64 14.0。
作業に入る前に、銅メッシュなしの状態で温度のデータを取る。
mpdの設定は、Best、384kHzで固定。そのかわり、音を出してるときのデータは、4回取る。
音を出していないとき 47000 (min:47000 max:47000) NAS音源 70896 (min:69000 max:73000) 71262 (min:64000 max:75000) 71705 (min:65000 max:75000) 71514 (min:70000 max:74000) ストリーミング音源 71442 (min:66000 max:75000) 71252 (min:68000 max:74000) 71292 (min:69000 max:74000) 71609 (min:68000 max:74000)
以上、時系列。
NAS音源を鳴らし始めて3分後からデータをとり始めたけど、ちょっと早いのかもしれない。10分ぐらい待った方がよさそうだ(テスト系のときは数10分後から測り始めている)。
意外だったのは、テスト系ではストリーミング音源で温度が上がる傾向があったのに、メイン系では上がらないことだ。NASとストリーミングの音質の差と温度の差に相関関係がありそうだと思っていたのだけど。
いや、考えてみたら上流のデジタルデータを受け付けているmpdサーバーで、データが同じなのに(まあ、調べたわけじゃないけど、同じだと思うんだよね、、)、上流のサーバーが違ったら発熱量が違うほうが、本当はいけないのだ。
でもそこは、ジッターの差によって、負荷が違うのだろうと想像していた。
メイン系は新しい機種で性能も上で、処理能力が大きいので温度差が出ないのだろうか。
テスト系の音を聴き直してみる。設定は、Medium、384kHz。
たしかにNASとストリーミングでは音質に差があり、聴き比べたら、テスト系よりもメイン系の方が音質差は少ない。しかし少ないながらも、音質の差はあるのだ。CPUの温度には現れないレベルということなのだろうか。
そして、驚いたこと。
テスト系より、メイン系の方が、音が乾いて聴こえるのだ。テスト系の方が生々しい気がする。
テスト系を768kHzで鳴らしてみる。音の雰囲気が変わり、こうなると、メイン系との比較が出来なくなった。
メイン系に銅メッシュを仕込む。
筐体の底板を開けるのは比較的簡単。銅メッシュを仕込む隙間もある。
しかし、簡単にGNDがとれない。丸形端子をネジ止めできたらいいんだけど、意外に適当な使えるネジがない。銅メッシュにケーブルを半田付けし、その先の丸形端子を筐体の地金にテープで貼ることにした。
こんな感じ。

電源を入れ、しばし放置して温度を測る。
音を出していないとき 46000 (min:46000 max:46000) NAS音源 70991 (min:69000 max:74000) 71154 (min:64000 max:74000) 72029 (min:70000 max:75000) 71775 (min:64000 max:74000) ストリーミング音源 71775 (min:62000 max:75000) 70706 (min:56000 max:74000) 72010 (min:64000 max:75000) 72282 (min:71000 max:74000)
銅メッシュを設置する前より、温度はむしろ、上がっているかな。
音質はどうなのかというと、あんまりぱっとしない。良い方に変化した感じはしない。しかし、それより問題があって、なんだかサーバー自体が安定しない感じがするということだ。Daphileからのコントロールが不安定な感じ。
なにしろ、上手く行っていない。
温度が上がるのは良くない。
銅メッシュのサイズが大きすぎて冷却が上手くいっていないのかもしれないと考えて、メッシュの量を半分にして、やや小ぶりに、薄くした。細い針金を編んでいるので、切れ端から銅線がこぼれないように注意が必要だ(コンピューターに入れるので、切れ端が変なところに紛れ込んではまずいと思う)。
音はむしろ、そのほうが良いようだ。
硬い感じがとれて色彩感も出てきた。
温度を再計測。
音を出していないとき 47000 (min:47000 max:47000) NAS音源 72375 (min:70000 max:75000) 71825 (min:67000 max:75000) 71571 (min:70000 max:74000) 71867 (min:64000 max:75000) ストリーミング音源 71896 (min:69000 max:76000) 71328 (min:64000 max:74000) 72049 (min:69000 max:75000) 71961 (min:66000 max:75000)
温度は、あんまり、変わらない。
音はというと、それでも、どうにもすぐれない。
いくつか音源を聴くうちに、濁りがあるように感じられてきた。ベールのように霞みが掛かっている。そのせいか、見え方が違ってくる。遠くまでとどかないのだ。
副作用の方が強い。
銅メッシュを外す。
見通しの良い、以前の音が戻ってきた。
しかし、こうなってくると、テスト系の音も慎重に評価しないといけない。
何らかの歪みが、逆に心地良く聴こえているのかもしれない。GNDにものをつなぐときには注意が必要だ。しばしば反応は鋭敏でいいことばかりではない。
それにしても、2台の違いはどこから生じているのだろう。
ともあれ、しばらく、様子を見ていく。
17日、追記。さて、現状のシステムを聴き続けているのだけど。
なんというか、悪くない。
懸念したテスト系の音質悪化はない。こんなならいいかな、という感じで、メイン系mpdサーバーで生じたような不具合は感じられない。メイン系はもとのまま、変わらない状態で機能している。
音の安定感はある。
そういうわけで、引き続き様子を見ていく。
Oct 31, 2023
アップサンプリングの設定を変えてmpdサーバーの負荷を減らしてみる
現在のうちの環境では、Daphileでmpdサーバーに送るDeezerの音は、同じCD水準のデータでもNAS音源の音には及ばない。
前回のエントリーで、ストリーミング音源はupmpdcliがボトルネックになっていると考えたら、mpdサーバーへの対策が有効ではないか、銅メッシュをmpdサーバーのノイズ対策に使えば負荷が減るのではないか、と考えた。
ここでふと、mpdの負荷を減らしたいなら、アップサンプリングしなければいいんじゃないか、と思い付いた。
Daphileからmpdに送られるのは44.1kHz/16bitのPCMだ。それを何もせずPPAPで送れば、どう聴こえるだろう。
mpdサーバーの負担は減ると思う。
過去に試したときは、アップサンプリングした方が良かった。
今はどうだろう、ストリーミング、いや、UPnP音源だったら、どうなのか。
もともと、僕がアップサンプリングを使うようになったのは、コンピューターをオーディオに使い始めた頃に、SRC2496という機器を使ってアップコンバートして鳴らしていたことがある。これは音が良くなった。あと、壊れかけたNASの音源は、mpdによる非力なアップサンプリングでも音が良くなった。
こうしたことから、ジッターが多い環境では、アップサンプリングしたほうが音が良いのではないか、という仮説を思い付いた。なんでアップサンプリングで音が良くなるんだろう、というところから考え始めている。
つまり、そうした現実の理由付けとして考え始めた仮説だ。
そのうち、アップサンプリングと一言で言ってもいろんな手法があり、音も違うことが分かった。
手法で音が違うということは、DACに入力されるデータが異なっているということだ。
そして、DACチップ内でアップサンプリングするという知識も得る。
アップサンプリングによる音質改善の根拠は、DACチップ自体でアップサンプリング(オーバーサンプリング)するより、良質なアップサンプリングが出来る高スペックのPC等で代行したほうが良いという説明に、比重が移った。
というか、世の中でそういう説明が見られるようになった。
SRC(libsamplerate)などを使って良質なアップサンプリングを行うと音が良くなるのはなぜなのか、という問いの答えが、DACチップはナイキスト定理通りの理想的なDA変換が出来ないのでオーバーサンプリングして精度を高めるより他なく、DACへのデジタル入力前に、より良質なアップサンプリングを行うことが可能なら、そのほうがDA変換の精度が上がるから、ということに現在はなっている。
というのが僕の理解。
音の情報量自体はCDで充分だが、DA再生で充分な精度を出すには技術的限界があるから、理論だけで固めた理想論では済まない。だから高品質なアルゴリズムでアップサンプリングすることが有効ということだ。
精度が要らないなら、この限りではない。精度が出てなくても良い音はざらにある。精度が出ていさえすれば良いというものでもない。
そういうわけでアップサンプリングの品質は重要だと思うけど、ジッターを如何にして減らすかも同時に重要だ。
以前は、アップサンプリングすることでジッターの影響を少なく出来るのではと考えていたけど、今はそれだけで事足りるとは考えない。
ジッター対策は音色に効いてくる気がする。
というか、映画に例えてみると、サンプリング周波数やビット深度がフィルムの大きさ、つまり情報量に影響し、ジッター対策はピントに効いてくるとでもいうか、出てくる音の鮮度、色彩感、陰影に影響する。
両方を高めるのが、今のデジタルオーディオで高音質を得る近道だと思う。
正攻法は、安定して高精度なクロックだ。
しかしクロックを生かすには、ノイズや電源の対策が必須になる。ノイズや電源の上でクロック素子が動いているからだ。当然、デジタル信号そのものも、それらの上で動いている。デジタルで01だと言っても実体は電圧変動なのだから、ノイズや電源の影響を受けないわけがない。その影響こそがジッターということだ。
話が広がりすぎか。話を戻す。
何が言いたいのかというと、アップサンプリングを止めることで、音質は低下する。
しかしmpdサーバーの負担、仕事量が減るので、ジッターの減少、音質の向上に繋がるのではないか、ということ。
逆も言えることで、アップサンプリングを行えば音質は向上する。
しかしmpdサーバーの負担、仕事量が増えるので、ジッターの増加、音質の低下に繋がる。
では、どうすれば一番良い音になるのか、良好なバランスとなるのはどんな設定なのか、という考え方だ。
実際に聴いてみて、確かめるしか術はない。
さて。
うちでは2台のmpdサーバーが動いていて、1台はメイン使用で384kHzへのアップサンプリング用、もう1台はテスト用兼768kHzへのアップサンプリング用になっている。なんでわざわざ2台なのかというと、そのほうが設定切り替えの手間がないからだ。
PPAP Back-Endで両方の設定に対応するコマンドが動いていて、どちらのFrontからでも直ぐに音を出すことが出来る。
Back-Endでtopを打つとこんな感じ。
Mem: 93208K used, 3936688K free, 18376K shrd, 5560K buff, 34180K cached CPU: 0.0% usr 0.0% sys 0.0% nic 99.9% idle 0.0% io 0.0% irq 0.0% sirq Load average: 0.00 0.00 0.00 2/109 1319 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 1318 1290 tc R 4016 0.1 0 0.0 top 1208 1092 root S 15484 0.3 0 0.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=2048 --buffer-size=16384 -t raw -f S32_LE -r384000 -c2 1242 1 tc S 15484 0.3 1 0.0 /usr/local/bin/ncat -kl 4444 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2 1286 1202 root S 5872 0.1 0 0.0 sshd: tc [priv]
まず、テスト用サーバーの設定をいじって、アップサンプリング無しの音を出すことにした。
mpdサーバー(Front)をアップサンプリングしない設定に変更。
Back-Endでは、上記のtop表示だったら「kill 1242」で、テスト用のデータを受信するコマンドを止める。
改めて以下、コマンドを打つ。
/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" &うまくいかない。
音が出るまで時間が掛かり、音が出始めた後のコントロール、音量の調整や再生停止などの操作にすごく時間がかかる。数十秒もかかる。768kHzのデータの方が重そうなのに何でなのか、考えるうちに、もしかしたら、バッファーの設定が影響しているのではと思い付いた。
メインサーバーからのデータを受けるコマンドはrootで起動。テスト用サーバーからのはtc(ログインユーザー)で起動している。
コマンドは2つだが、aplay自体は、もともとひとつだ。
音源がCD同等だと、バッファーの数値はずっと小さくなる。音源データが小さいのでコマンドの設定もそれに合わせている。
しかしメイン用の方はもともと、大きい数値がバッファーに振られている。
多分、テスト用からの音源を鳴らしている時も、メイン用のコマンドが同時に動いているから、バッファーの設定がそっちのまま、大きいままなのではないか。
CD相等の音源にとって、それは過剰なバッファーとなる。
結果、操作に対する反応が遅くなる。mpdサーバーの出音を止めても、バッファーに溜まったデータが切れるまで、暫く音が出続けるのだろう。それが20秒前後にもなる。
どうするか。
そもそもの目的、サーバーの負荷を落とすということなら、アップサンプリングの「質」の設定を落とせばいいという考えもある。
テストサーバーのlibsamplerateの設定は「Medium」なので「Fastest」にしたら負荷は下がる。
そしてメインの384kHzに近い値で低めに設定したら、バッファー数値の影響は回避できないだろうか。
ままよ、やってみた。
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=1024 --buffer-size=8192 -t raw -f S32_LE -r192000 -c2" &
これだと反応の遅れは数秒で、使用に耐える。
音色は良い。
768kHzよりも艶っぽい気がする。
しかし情報量は少なくなる。音像間で分離していた空間が、グラデーションで埋まる。まあ、768kHzと192kHzでは、デジタルデータの情報量は4倍の差があるので、仕方がない。768kHzは良くも悪くもモニター的になる。これは、どちらがいいのかという話になりそう。
テスト用といいながら僕が768kHzで鳴らす環境を維持しているのは、これはこれで捨てがたい面があるからだ。
しかし192kHzだと、USB-HDD音源とストリーミング音源の音の差は、かなり縮まったような気がする。
いや、ほんまかいな、と自分でも思うけど、たぶん縮まってるんじゃないかな(でも、こういうときの自分ってあてにならないんだよな、、)。
Fastest、192kHzの設定だけで比較したら、もうストリーミング中心でいいかもと思うかもしれない。
Back-Endで、メイン用の設定のほうを見直すという方法論もある。
大きいバッファーを小さく出来たら、テスト系への影響を小さく出来るのではないか。
そもそもなぜ、「--period-size=2048 --buffer-size=16384」という設定になっているのか、記憶にない。
たぶん、アップサンプリングするmpdサーバーの増大したバッファーの設定に、合わせて増やしただけだと思うのだ。
減らせるかもしれない。
とりあえず、「--period-size=512 --buffer-size=2048」まで減らした。
問題なく音は出ている。あらー、、、
この状態で、テスト系のアップサンプリングをやめて、まともに使えるかどうか、試してみる。
音の出方は、以前よりは良くなった。
しかし、不安定だ。途切れやすい。
mpdサーバーの方を調整。「audio_buffer_size」を増量、"2048"に。多少は安定したが、再生停止に10秒程かかる。
なんでかわからんが、mpdが音源データをどんどん先走って取り込んでいるようなのだ。Daphileなどのインターフェイスで見ると、曲の時間表示が実際よりもどんどん先に進んでいく。
これでは困る。
結局、多少はアップサンプリングしないと安定しないという、よくわからない状態で、今回はけりをつけることにした。
libsamplerateは「Fastest」、負荷軽減優先だ。
サンプリング周波数は、とりあえず192kHz。
テスト系を受けるBack-Endの設定は「--period-size=256 --buffer-size=2048」に、今はしている。
なんだか、あちこちバランス取りながらの設定で、詰めきれないままのことが今までにもよくあったような気がする。
気のせいかもしれないけど、Fastest、192kHzは、昔よりも良い音が出ている気がする。
ノイズ対策などを経て、ジッターが減っている分、改善があるのかもしれない。
USB-HDD音源とストリーミング音源の音の差も、Fastest、192kHzだったら前述したとおり、差異が少ない。なんとなく、バランスがいい音という印象で安心感がある気がする。
もともと、差異が少なければいいというものではない。
ストリーミングの音を底上げするにはどうしたらいいか、というところから始まった話だ。
しかしここに来て、設定による音の違いは無視できないような気がしている。ノイズ対策が落ち着いたら、どのような設定でどのような音になるのか、ゆっくり時間がある時に、確認したいと思うが、設定の要素が多いので、比較すると言っても単純な話ではない。
大仕事になる。あんまり突っ込んだことはしないかもしれない。
最後にちょっと、温度の比較(CPUだと思うんだけど、はっきりしない)。
テスト用サーバーでコマンドを打って確認してみた。
tc@box:~$ cat /sys/class/thermal/thermal_zone0/temp 44000
こんな感じ。
ただ、今回確認してみて、音を出している時の温度は、かなり変動することが分かった。負荷が多いときは上がるのだろう。
データ取得のために下記コマンドを使用。
5分間のデータを取得する。
tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt
数値だけ得られるならよかったんだけど、行頭に余計な文字列が付くのが残念。
このファイルを、普段使いのノートPCに移して、エディタで要らない文字列を削除して、下記のコマンドで数値を合計して、電卓で平均を計算する(小数点以下は四捨五入した)。
せっかくLinux使ってるんだから、もう少しスマートにやれそうだけど、スキルがない。
[ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt
44000 Fastest、192kHz 47267 (min:47000 max:48000) Fastest、768kHz 53019 (min:47000 max:58000) Medium、768kHz 59670 (min:51000 max:65000)
一番上は音を出していないとき、続いて、それぞれの設定で音を出したときの温度だ。
アップサンプリングの設定、負荷の違いで大きく温度が違うのが分かる。
驚いたのは、音を出していないときの温度は、ずっと44000で5分間一定だったこと。そういうものなんだろうか。あと、負荷が少ないと温度の変動も小さい。
メイン用サーバーは、Best、384kHzの設定で固定している。こっちも少し測ってみた。
データは載せないが、テスト用よりも若干温度が高いようだ。
早々に追記だけど、テスト用サーバー下記設定でデータを取ってみた。
アップサンプリングの周波数が低いと、温度の変動が少ないのかな。負荷の大きさとの関連は小さいのか。どうなんだろう。
Best、192kHz 58452 (min:57000 max:62000)
Mar 14, 2023
リッピング(17日、追記)
今回は、ちょこっと。
リッピングは相当の配慮をしないといけないという意見もある。
うちではけっこう、ざっくばらんだ。
しかし、こだわってる部分もあるので、このたび書いておく。
うちでは、リッピングしたファイルはNASに保存している。
こだわっているのは、リップしたファイルをどういう行程でNASに保存するか、だ。
つまり、リッピングするハード、ソフトには殆どこだわらない。
ソフトは、使い慣れているのでWindows / EACを使っている。
EACの使い方に付いては、1台のノートPCにUSB-DVDドライブを2つつないで、EACを2つ起動していっぺんに2枚のCDをリップしたりしているので、お世辞にも丁寧な扱いとは言えない。
AccurateRipがEACにはあるので正確性はある程度担保されるが、比較データなしとか他のデータと合わないと表示されることもある。そういうときは、エラーなしなら良しとしている。割り切ったもんである。
こだわり処はNASに保存する行程だ。
- リッピングしたファイルは最初に、PCのハードディスクに保存される。
- これをUSBメモリスティックにコピーする。
-
USBメモリスティックを、普段使用のノートPC(OSはLinux Fedora、家庭内LANにつながっている)に刺しなおす。
このノートPCには予め、NASの音楽ファイル用共有ディレクトリがLAN経由でマウントされている。 -
USBメモリスティックから、NASの音楽ファイル用共有ディレクトリに、音源をコピーする。
コピーには「cp」を使用する。
cpとは端末ソフト上で使うコマンド。つまりファイルブラウザは使わないということだ。
こんな感じ。
僕の経験では、というか印象では、USBメモリを使わずハードディスクから直接にNASにコピーしたり、cpを使わずファイルブラウザ上でドラッグドロップしてコピーしたりするのは、音が悪くなる。所謂、デジタルくさい音と昔に言われたような、くぐもったような透明度の低い切れが悪い音、要するにジッターが多いんだろうな、という音になる、、、ような気がする。
気がするというのは、本気で試聴して比べたことがないからだ。
経験的に、こうしたらこうなったような気がするな、という印象である。
そういうわけで、ネットからダウンロードした音源なども同様で、いったんUSBメモリにコピーして、そこから「cp」でNASに保存するという行程を採っている。
ちゃんと確認してないけど、そういう気がするのでその行程は外さない。保守的である。というか、あつものにこりて、か。
以上、まじないのような話だ。
17日、追記。
まじないのような、とは書いたものの、なんで今更自分はこんな怪しいエントリーを上げてるのかな、と考えてみたら、これは実は前回のエントリーの続きなのだ。
つまり、うちのNAS音源はストリーミングよりもジッターが少ない。
その理由は、リッピングの所作によるものではないのかという、そういうことなのだ。
実は、まじないより効いてるのかもしれないという話である。
Jun 28, 2022
earfluff and eyecandy によるJitterの解説 その1
今回は、興味深いサイトがあったので備忘録に書いておこうという主旨。
サイトのオーナーはB&Oの関係者で、音楽技術分野の研究者とのこと。
https://www.tonmeister.ca/wordpress/about/
個人的には、いい加減な知識のままにしていた部分で、重要な知識だと思うので自分のためにも忘れないように、エントリー3回分で書いておく。
3、2、1の順でアップロードすることで、ブログ上では上から1、2、3と並ぶようにしてみた。そのほうが読みやすいはずだ。
何か必要があったら追記訂正するつもり。追記訂正の断りは入れない。見た目が煩わしいので。
しかし、良く分かっている人には、今更感がある内容だと思う。
というのは、出て来る用語をネット検索したら、10年前から残っている解説記事がぽろぽろ引っかかるのだ。どこかで目にしたなあ、ということがあったりする。
分かってる人には、これらは常識なんだと思う。
しかし僕なんかは系統的な知識になってないので、こういう機会でもないと理解が進まないということだ。あと、目についた記事だけ読んで難しすぎて身に付いてないことが往々にしてあるように思う。勉強不足に加えて、僕には難しすぎるのである。
Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/
デジタルオーディオ関係でジッターといえば「時間軸方向での信号波形の揺らぎ」とか「信号の時間的なズレや揺らぎ」とか説明される。
そんなひとことで表現されるジッターだが、原因は多種多様と聞いたことぐらいはある。聞いたことはあっても、その内実については詳しくは知らない。
上記サイトでは、そのジッターの分類について専門家側から説明してくれている。
そういうわけで、ちょっと旅しよう。
Jitter: Part 1 – What is jitter?
Jitter: Part 1 – What is jitter?
http://www.tonmeister.ca/wordpress/2018/08/08/jitter-part-1/
ここは初歩的な所から入る。
僕でも読みながら、うんうん、そういう感じだよね、という感じで読めるパートだ。
ひとつだけ、S-PDIFのデジタル信号の仕組みについて、ああ、そういう仕組みなのか、と分かったのは非常に良かった。オーディオ信号にクロックが乗ってるってどういう意味だろう?と昔から思っていたんだけど、説明があった。
簡単にいえば2bitから1bitを抽出するというか、on-onとoff-offが0で、on-offとoff-onが1、そういう信号で伝送したら、そこからクロックが抽出できるという感じ。英語版wikpedia(https://en.wikipedia.org/wiki/S/PDIF)にも書いてあるが、こちらのサイトの方が分かりやすい。
It’s important for me to note that the example I’ve given here about how that jitter might come to be in the first place is just one version of reality. There are lots of types of jitter and lots of root causes of it – some of which I’ll explain in this series of postings.
(translate by Google)
そもそもそのジッターがどのように発生するかについてここで示した例は、現実の1つのバージョンにすぎないことに注意することが重要です。さまざまな種類のジッターとその根本原因があります。そのうちのいくつかについては、この一連の投稿で説明します。
Jitter: Part 2 – Phase and Amplitude Jitter
Jitter: Part 2 – Phase and Amplitude Jitter
http://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-2/In the previous posting, I talked a little about what jitter and wander are, and one of the many things that can cause it. The short summary of that posting is:
Jitter and wander are the terms given to a varying error in the clock that determines when an audio sample should (or did) occur.Note the emphasis on the word “varying”. If the clock is consistently late by a fixed amount of time, then you don’t have jitter or wander. The clock has to be speeding up and slowing down.
One of the ways you can categorise jitter is by separating the problem into two dimensions – phase (or time) and amplitude.(translate by Google)
前回の投稿では、ジッターとワンダーとは何か、そしてそれを引き起こす可能性のある多くのことの1つについて少し話しました。 その投稿の簡単な要約は次のとおりです。
ジッターとワンダーは、オーディオサンプルがいつ発生するか(または発生したか)を決定するクロックのさまざまなエラーに与えられる用語です。「変化する」という言葉が強調されていることに注意してください。 時計が一定の時間だけ常に遅れている場合は、ジッターやふらつきはありません。 時計は速くなったり遅くなったりする必要があります。
ジッタを分類する方法の1つは、問題を位相(または時間)と振幅の2つの次元に分離することです。
ここで、ちょっと待って、である。
時間と振幅に分けるって、ジッターって時間の問題じゃなかったの?という。
信号の振幅の誤差がデジタル再生に影響するんじゃないのかというのは、僕自身も以前から考えてはいた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200531a.htm
以前のエントリーに書いたのは、DACチップのアナログ信号出力の正確性についての疑いで、それらの誤差も一緒くたにまとめて「ジッター」に括られてるんじゃないのか?という疑問だった。
ここでの話はそういうことではなく、デジタル信号の振幅誤差がデジタル信号のジッターを生むということ。
その内容自体は、納得できる説明だ。
というか、僕にはその知識は無かったが、以前からそうした概念については頭の中に仮説としてあって、しかし実はデジタル技術の世界ではとっくの昔に「振幅ジッター」という概念で説明が成されていたのだと、今回、僕がこのサイトを読んで理解し、得心したということだ。
ここでは「デジタル信号」の解説をしているので、DA変換出力の振幅誤差については関係ない話なので触れられていない、と理解している。
話を戻す。
このエントリーでは、ジッターには「phase jitter(位相ジッター)」と「amplitude jitter(振幅ジッター)」があると書かれている。原因が異なるため、システムの改善を目指すなら、生じているジッターの切り分けをすべき、ということかな。
僕が単純に考えて、
前者には、リクロック含むクロック周り。
後者には、電源とアースの強化とノイズの対策か。
切り分けが困難なら両方に対策するしかない。しかし実際にはもっと複雑な挙動への対策が必要かもしれない。たとえばクロックと言ったって、クロックにも電源があるのだ。キリがないので、どこでカタを付けるかだ。
ちょっとここからうだうだ長くなる。どうでもいい話だ。
僕を困惑させた文面があった。
Wrapping up
If you’re a system developer or if you’re trying to improve your system, you need to know whether you have phase jitter or amplitude jitter in order to start tracking down the root cause of it so that you can fix it. (If your car doesn’t start and you want to fix it, it’s good to find out whether you are out of fuel or if you have a dead battery… These are two different problems…)
However, if you’re just interested in evaluating the performance of a system, one thing you can do is simply to ask “how much jitter do I have?” (If your car doesn’t start, you’re not going to get to work on time… Whether it’s your battery or your fuel is irrelevant.) You measure this, and then you can make a decision about whether you need to worry about it – whether it will have an effect on your audio quality (which is a question that not determined so much by the amount of jitter that you have, but where it is in your system, and how the “downstream” devices can deal with it).
(translate by Google)
まとめシステム開発者の場合、またはシステムを改善しようとしている場合は、問題の根本原因を突き止めて修正できるように、位相ジッターまたは振幅ジッターのどちらがあるかを知る必要があります。 (車が始動せず、修理したい場合は、燃料がなくなっているのか、バッテリーが切れているのかを確認することをお勧めします…これらは2つの異なる問題です…)
ただし、システムのパフォーマンスを評価するだけの場合は、「どのくらいのジッターがありますか?」と尋ねるだけで済みます。 (車が始動しない場合は、時間どおりに仕事をすることができません…バッテリーか燃料かは関係ありません。)これを測定すると、心配する必要があるかどうかを判断できます。それ–それがあなたのオーディオ品質に影響を与えるかどうか(これはあなたが持っているジッターの量によってそれほど決定されない質問ですが、それがあなたのシステムのどこにあるか、そして「下流」のデバイスがそれをどのように扱うことができるか)。
『システムのパフォーマンスを評価するだけの場合は、「どのくらいのジッターがありますか?」と尋ねるだけで済みます』というのは、大雑把過ぎるのではなかろうか。
電気信号の振幅が正確であるためには、電源やGND電位が安定している必要があると、僕は理解している。
最近は、電源やGNDに気を配るのはデジタルオーディオの「いろはのい」みたいなことになっている。誰が言い出したのか、メーカーや技術者側からなのかユーザーサイドからなのか、よく知らない。
どんな電源がいいとかバッテリーがいいとか電柱がいいとか、ノイズ軽減にはどうしたらいいとか仮想アースがどうとか、いろんな知見や試みがある、その一方でどうして効果があるのか、明確な説明は無かったような、分かるような分からないような、そんな感じではなかったか。
しかし、電気信号の振幅誤差も、時間の誤差とまとめてジッターになるんだよ、と。
今までもジッターといえば実は両方を含んでたんだよ、と。
だったら、デジタル系の電源やアースの強化、安定化を目指す必要があるというのは、ジッター対策と考えたら自明なことだ。いつからそうなった?昔からか。。。
デジタルでの音質の劣化は「時間軸方向での信号波形の揺らぎ」が原因で、それをジッターと読んでいた筈だ。
振幅も問題だということなら、「ジッターだけではなく振幅も問題だ(と分かった)」と表現するべきではないのか。
それか「ジッターは時間軸方向の揺らぎで、振幅の揺らぎはほにゃららと呼ぶのだ」とするか。
いや、結果の実態としては同じだからジッターでくくればいいと、、、いや結果が同じでも切り取り方が違ったら受け取り方も対策も違うでしょうに、、、
しかし考えてみたら、ジッターの定義?が「時間軸方向での信号波形の揺らぎ」ということで、もともと原因が何かは問わないのだ。だったらくくっても問題はないという理屈。
そういうわけで、不勉強な僕の言うことが間違ってるんだと思うが、そういう感じで、納得いかない。
納得がいかないとか言ったって、ずっと昔に御布令が出てるのに、いつの間に出してんだ知らねえんだよべらぼうめぇとか言っても言う方がバカで打ち首である。
以上、どうでもいい話だ。
どうでもいい話で長くなりすぎた。次のエントリーに続く。今回のエントリーは横道に逸れすぎである。
earfluff and eyecandy によるJitterの解説 その2
前回に引き続き、earfluff and eyecandy によるJitterの解説について読んでいる。
Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/
今回はPart 3から。
Jitter: Part 3 – Classifying Jitter
Jitter: Part 3 – Classifying Jitter
http://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-3/
Part 2では、ジッターを位相ジッターと振幅ジッターという見方で分けた。
ここでは、別のジッターの分類について触れている。
以下、表にする。
total jitter | random jitter | ||
deterministic jitter (correlated jitter) |
periodic jitter | ||
data-dependent jitter | inter-symbol interference | ||
duty cycle distortion | |||
echo jitter |
Part 4でRandom Jitter、Part 5でDeterministic Jitterについて説明がある。
日本のサイトで用語の解説がある。
random jitter(ランダム・ジッタ)、deterministic jitter(デターミニスティック・ジッタ)
Posted on 2014年12月24日
http://www.de-pro.co.jp/2014/12/24/8209/
Jitter: Part 4 – Random Jitter
Jitter: Part 4 – Random Jitter
https://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-4-random-jitter/You have a signal (the audio signal that has been encoded as a digital stream of 1’s and 0’s, sent through a device or over a wire as a sequence of alternating voltages) and some random noise is added to it for some reason… (Maybe it’s thermal noise in the resistors, or cosmic radiation left over from the Big Bang bleeding through the shielding of your S-PDIF cable, or something else… )
What we’re really talking about is that the jitter is modulating the signal that carries your audio signal – not the audio signal itself. This is an important distinction, so if that last sentence is a little fuzzy, read it again until it makes sense.
(translated by google)
信号(1と0のデジタルストリームとしてエンコードされ、デバイスを介して、または一連の交流電圧としてワイヤを介して送信されたオーディオ信号)があり、何らかの理由でランダムノイズが追加されています…(多分 それは、抵抗器の熱ノイズ、またはビッグバンから残った宇宙放射がS-PDIFケーブルのシールドを介して出血していることなどです…)私たちが実際に話しているのは、ジッターがオーディオ信号自体ではなく、オーディオ信号を運ぶ信号を変調しているということです。これは重要な違いなので、最後の文が少し曖昧な場合は、意味がわかるまでもう一度読んでください。
1 Timing errors of the clock events relative to their ideal positions
2 Timing errors of the clock periods relative to their ideal lengths in timeThese are very different – although they look very similar.
The first is an absolute measure of the error in the clock event – when did that single event happen relative to when it should have happened? Each event can be measured individually relative to perfection – whatever that is. This is called a Phase Modulation of the carrier. It has a Gaussian characteristic (which I’ll explain below…) and has no “memory” (which is explained first).
The second of these isn’t a measure of the events relative to perfection – it’s a measure of the amount of time that happened between consecutive events. This is called a Frequency Modulation of the carrier. It also has a Gaussian characteristic (which I’ll explain below…) but it does have a “memory” (which is explained using Figure 1).
(translated by google)
1 理想的な位置に関連するクロックイベントのタイミングエラー
2 時間の理想的な長さに対するクロック周期のタイミングエラーこれらは非常に異なりますが、見た目は非常に似ています。
1つ目は、クロックイベントのエラーの絶対的な測定値です。その単一のイベントは、発生するはずだった時期と比較して、いつ発生したのでしょうか。 各イベントは、それが何であれ、完璧に関連して個別に測定できます。これは 、搬送波の位相変調と呼ばれます。ガウス特性(以下で説明します…)があり、「メモリ」(最初に説明します)がありません。
これらの2つ目は、完全性に関連するイベントの測定値ではありません。これは、連続するイベント間で発生した時間の測定値です。これは、搬送波の周波数変調と呼ばれます。また、ガウス特性(以下で説明します…)がありますが、「メモリ」(図1を使用して説明)があります。
ちょっと引用だけではなんだかよく分からない。
元サイト原文のほうに図が掲載されている。しかし、ガウス分布は分かるんだけど、位相変調と周波数変調については、よく分からない。
位相変調は、その瞬間だけに影響するもので、周波数変調はその後の信号にも影響を与える(「記憶」と表現されている)ということらしい。
いろんな原因でランダムに生じるジッターがあり、その瞬間だけ影響するものと、後まで影響するものに分けられる、という理解で、とりあえずいいのかな。
Jitter: Part 5 – Deterministic Jitter
Jitter: Part 5 – Deterministic Jitter
https://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-5-deterministic-jitter/Deterministic jitter can be broken down into two classifications:
1 Jitter that is correlated with the data.
This can be the carrier, or possibly even the audio signal itself2 Jitter that is correlated with some other signal
In the second case, where the jitter is correlated with another signal, then its characteristics are usually periodic and usually sinusoidal (which could also include more than one sinusoidal frequency – meaning a multi-tone), although this is entirely dependent on the source of the modulating signal.(translated by google)
決定論的ジッタは、次の2つの分類に分類できます。1 データと相関するジッタ。
これは、キャリア、または場合によってはオーディオ信号自体である可能性があります2 他の信号と相関するジッタ
ジッタが別の信号と相関している2番目のケースでは、その特性は通常 周期的であり、通常は正弦波です(複数の正弦波周波数を含む場合もあります-マルチトーンを意味します)が、これは変調信号のソースに完全に依存します。
まず、決定論的ジッタはデータ依存ジッタと周期ジッタとに分けられるとのこと。
データ依存ジッタには、Intersymbol Interference(符号間干渉:ISI)、Duty Cycle Distortion(デューティ・サイクル歪み:DCD)、Echo Jitter(エコージッター)があるということで、ここではそれらを順番に説明している。
ランダムジッタは予測不能だけど、決定論的ジッタは瞬間毎にどのように動作するかを「予測可能」とのこと。予測可能というのは、僕には意外だった。たぶん僕が考える予測と、サイトオーナーが記載している予測は、どこか意味が違うんだろうと思う。
読んでいて、僕が持っているジッターのイメージに説明内容が近いものは理解しやすかったような気がする。気がするというのは、本当に分かったのかどうかがおぼつかないからだ。
イメージがつかめないものは、分かりにくい。
データ依存のジッター
Data-Dependent Jitter
Data-dependent jitter occurs when the temporal modulation of the carrier wave is somehow correlated to the carrier itself, or the audio signal that it contains. In fact, we’ve already seen an example of this in the first posting in this series – but we’ll go through it again, just in the interest of pedantry.
We can break data-dependent jitter down into three categories, and we’ll look at each of these:(translated by google)
データ依存のジッタは、搬送波の時間変調が搬送波自体、または搬送波に含まれるオーディオ信号と何らかの形で相関している場合に発生します。実際、このシリーズの最初の投稿でこの例をすでに見てきましたが、衒学者のためだけに、もう一度説明します。
データに依存するジッターを3つのカテゴリに分類でき、それぞれを見ていきます。
データ依存って何だと思うけど、データ信号そのものに乗るジッターで、以下の3つに分類されるということらしい。
しかし、本当に3つだけなのか?と考えてしまう自分がいる、、、たぶん何か分かっていないのだ。
符号間干渉
ケーブルで伝送されるうちに、信号の方形波の波形が崩れていくということらしい。
理想のケーブルは現実には存在しないからとのこと。
参考:
https://en.wikipedia.org/wiki/Intersymbol_interference
デューティサイクル歪み
If your transmission system is a little inaccurate, then it could have an error in controlling the duty cycle of the pulse wave. Basically, this means that it makes the transitions at the wrong times for some reason, thus creating a jittered signal before it’s even transmitted.
(translated by google)
伝送システムが少し不正確な場合は、脈波のデューティサイクルの制御にエラーが発生する可能性があります。基本的に、これは、何らかの理由で間違ったタイミングで遷移を行うことを意味します。したがって、送信される前にジッター信号が作成されます。
これは正直良く分からない。
技術実装の問題なんだろうか。
参考:
https://en.wikipedia.org/wiki/Duty_cycle
思い当たるのは、音源を置くHDDによって音が違うというような事象のことを言っているのかもしれない。違うかもしれないけど。
エコージッター
What many people don’t know is that, if you stand in a long corridor or a tunnel with an open end, you will also hear an echo, bouncing off the open end of the tunnel. It’s not intuitive that this is true, since it looks like there’s nothing there to bounce off of, but it happens. A sound wave is reflected off of any change in the acoustic properties of the medium it’s travelling through. So, if you’re in a tunnel, it’s “hard” for the sound wave to move (because there aren’t many places to go) and when it gets to the end and meets a big, open space, it “sees” this as a change and bounces back into the tunnel.
Basically, the same thing happens to an electrical signal. It gets sent out of a device, runs down a wire (at nearly the speed of light) and “hits” the input of the receiver. If that input has a different electrical impedance than the output of the transmitter and the wire (on other words, if it’s suddenly harder or easier to push current through it – sort of….) then the electrical signal will (partly) be reflected and will “bounce” back down the wire towards the transmitter.
(translated by google)
多くの人が知らないのは、長い廊下や開放端のあるトンネルに立つと、トンネルの開放端で跳ね返るエコーも聞こえるということです。跳ね返る物が何もないように見えるので、これが真実であるというのは直感的ではありませんが、それは起こります。音波は、通過する媒体の音響特性の変化によって反射されます。したがって、トンネル内にいる場合、音波が移動するのは「困難」であり(移動する場所が少ないため)、音波が終わりに到達して大きなオープンスペースに出会うと、音波は「見えます」。これは変更としてトンネルに跳ね返ります。基本的に、同じことが電気信号にも起こります。それはデバイスから送信され、(ほぼ光速で)ワイヤーを伝わり、レシーバーの入力に「ヒット」します。その入力が送信機とワイヤーの出力とは異なる電気インピーダンスを持っている場合(言い換えると、電流を押し込むのが突然困難または容易になった場合-ある種…。)、電気信号は(部分的に)反射され、送信機に向かってワイヤーを「バウンス」します。
エコージッターはインピーダンスの問題で生じるらしい。
デジタルケーブルのインピーダンスを合わせるのは大事なことらしい。
周期性ジッター
Periodic Jitter
We press play on the CD, and the audio signal, riding on the S-PDIF carrier wave is sent through our cable to the DAC. However, the signal that reaches the DAC is not only the S-PDIF carrier wave, it also contains a sine wave that is radiating from a nearby electrical cable that is powering the fridge…
CDの再生を押すと、S-PDIF搬送波に乗ったオーディオ信号が、ケーブルを介してDACに送信されます。ただし、DACに到達する信号は、S-PDIF搬送波であるだけでなく、冷蔵庫に電力を供給している近くの電気ケーブルから放射されている正弦波も含まれています…
周期性ジッターについて最後に書かれている。
データ信号とは関係がなく、他の信号と相関するジッタで、多くは周期的に変動するということだ。
冷蔵庫のコンセントにノイズ対策したらコンポの音が良くなったというような、世間では都市伝説めいた扱いをされているあれである。うちの冷蔵庫にもノイズフィルターをかませている。
そうした外来ノイズによって生じるジッターや、システム内でも取り切れなかったノイズとか(電源のノイズとかかな、、)、そうしたものということのようだ。
紛らわしいので一応、書いておく。「Periodic Jitter」は、クロックジッターなどで説明される「周期ジッター(Period jitter / Cycle Jitter)」とは、別物?らしい。
ここらはまだよく分からない。
ジッターは切り取り方によって呼び方がころころ変わるようで、そういうのも分かりにくい原因だと思う。
分かりやすい例から何を言ってるのか分からないようなものまで、ジッターの原因には色々ある。
エントリーの最後に、これらの影響がデジタル信号に積み重なったらどんな影響があるかを図にしている。
Part 6以降は、また切り口が変わるので、今回はここまで。
earfluff and eyecandy によるJitterの解説 その3
前回、前々回に引き続き、earfluff and eyecandy によるJitterの解説について読んでいる。
今回が最後だ。
Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/
今回はPart 6から。
Jitter: Part 6 – What is Affected?
Jitter: Part 6 – What is Affected?
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-6-what-is-affected/So far, we’ve looked at what jitter is, and two ways of classifying it (The first way was by looking at whether it’s phase or amplitude jitter. The second way was to find out whether it is random or deterministic.) In this posting, we’ll talk about a different way of classifying jitter and wander – by the system that it’s affecting. Knowing this helps us in diagnosing where the jitter occurs in a system, since different systems exhibit different behaviours as a result of jitter.
これまで、ジッターとは何か、およびそれを分類する2つの方法を見てきました(最初の方法は、位相ジッターか振幅ジッターかを調べることでした。2番目の方法は、ランダムか決定論かを調べることでした)。この投稿では、影響を受けているシステムによって、ジッターとワンダーを分類する別の方法について説明します。これを知ることは、システムのどこでジッターが発生するかを診断するのに役立ちます。これは、システムが異なれば、ジッターの結果として異なる動作を示すためです。
We can put two major headings on the systems affected by jitter in your system:
data jitter
sampling jitterIf you have data jitter, then the timing errors in the carrier signal caused by the modulator cause the receiver device to make errors when it detects whether the carrier is a “high” or a “low” voltage.
If you have sampling jitter, then you’re measuring or playing the audio signal’s instantaneous level at the wrong time.
These two types of jitter will have different effects if they occur – so let’s look at them in the next two separate postings to keep things neat and tidy.システム内のジッターの影響を受けているシステムには、次の2つの主な見出しを付けることができます。
データジッター
サンプリングジッターデータジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。
サンプリングジッターがある場合は、瞬間的なオーディオ信号レベルを、間違った時間のタイミングで測定したり再生している状態になります。
これらの2つのタイプのジッターは、発生した場合に異なる影響を及ぼします。したがって、次の2つの別々の投稿でそれらを見て、物事をきちんと整理してください。
Part 6は短いので、全文引用した。
しかし、googleまかせではちょっと問題かと思ったので、僕が手を入れることにした。どうだろうね。
Jitter: Part 7 – Data Jitter
Jitter: Part 7 – Data Jitter
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-7-data-jitter/
ここは、正直良く分からない、、、
Part 6で書いてあったことは、『データジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。』とのこと。
要はキャリア信号自体に乗っかる形で影響するジッターという理解でいいのだろうか。
Part 7では「Peak-to-Peak error」、「RMS error」という言葉が出てくる。
これらの用語は、デジタルオーディオの本などでクロックジッター、周期ジッター(Period Jitter)というジッターの説明に出てくるようなんだけど(前に書いたけど、Periodic Jitterとperiod Jitterは、別の概念のような?)、それが、ここに出てきている。
データジッターという言葉は、そもそもグーグル検索で殆んど引っかかって来ない。data jitterなら多少はあるのだけど。なんだか、いろいろ謎である。
説明で「ランダムジッター」を想定している。
説明内容にあるような、ランダムジッターが多すぎたら読み取りエラーを生じるようになるのは、理解できる。
しかしデータジッターは、ランダムジッターだけなんだろうか。
ちょっと、そこの辺りがよく分からない。
もっといろんな作用が起こってると考えないと説明しにくいことがあるような気がする。
あと、ジッターでデータエラーを生じるような悪劣な環境でオーディオをやっているという想定は、かなり限定された状況のような気がする。
データエラーまで生じなくても、データジッターは音に影響するはずなのだ。
そこに触れてないようなのが、よく分からないところ。
技術的に説明しにくいのだろうか。まあ、僕が見当違いを言ってる可能性もある。
Jitter: Part 8.1 – Sampling Jitter - Jitter in the Analogue to Digital conversion
Jitter: Part 8.1 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/28/jitter-part-8-1-sampling-jitter/
ここでは、AD変換について説明している。
個人的には過去に見たことがあるような内容が多いし、あんまり注意して読まなくてもいいかなと思ったら、そうでもないような。
エントリーの下の方に、ジッタの量が一定に保たれている場合に、振幅エラーの量は信号の傾きに応じて変調する、というのを「図6」に示している。「赤い曲線は、サンプルごとの誤差(ジッター信号から元の信号を差し引いたもの)を拡大してプロットしたもの」との、説明がある。
Secondly, if the amount of jitter is kept constant, then the amount of amplitude error will modulate (or vary) with the slope of the signal. This is illustrated in Figure 6, below.
Fig 6. The blue curve is a sine wave to which I have applied excessive amounts of jitter with a Gaussian distribution. The red curve is the sample-by-sample error (the original signal subtracted from the jittered signal) plotted on a magnified scale. As can be seen, the level of the instantaneous error is proportional to the slope of the signal. So, the end result is that the noise generated by the jitter is modulated by the signal. (If you look carefully at the blue curve, you can see the result of the jitter – it’s vertically narrower when the slope is low – at the tops and bottoms of the curve.)
AD変換で、これがデジタル音楽データに乗ったらおおごとだと思うんだけど。
これと同等のことが、DA変換でも起こり得ることじゃないのかと思う。
つまり「図6」の赤い線(線というより塗りつぶされてるが)は、ジッターがアナログ再生音を濁らせる、その様子が可視化されているのではないかと。
ADで起きることなら、DAで起きても不思議はないと思うのだけど、見当違いかもしれないが。
Jitter – Part 8.2 – Sampling Jitter - Jitter in the Digital to Analogue conversion
Jitter – Part 8.2 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-2-sampling-jitter/
part 8.2では、DA変換について説明している。
オーディオ再生だったらこっちがメインだと思ったら、たぶん8.1で説明した内容と多くが被るのだろう、ごく簡単にすませている。
まあ、ジッターの説明でよく見る絵が描いてある。
文末に「I’ve completely omitted the effects of the anti-aliasing filter and the reconstruction filter – just to keep things simple.(単純化するために、アンチエイリアシングフィルターと再構成フィルターの効果を完全に省略しました。)」とある。
Jitter – Part 8.3 – Sampling Rate Conversion
Jitter – Part 8.3 – Sampling Rate Conversion
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-3-sampling-rate-conversion/
ここではサンプリングレート変換について書いてある。
しかし、そんなに多くは書かれていない。
Synchronous Sampling Rate Conversion(同期サンプリングレート変換)とAsynchronous Sampling Rate Conversion(非同期サンプリングレート変換)についての説明がある。
うちで行っているのは、非同期のほうだ。
The good news is that, if the clock that is used for ASRC’s output sampling rate is very accurate and stable, and if the filtering that is applied to the incoming signal is well-done, then an ASRC can behave very, very well – and there are lots of examples of this. (Sadly, there are many more examples where an ASRC is implemented poorly. This is why many people think that sampling rate converters are bad – because most sampling rate converters are bad.) in fact, a correctly-made sampling rate converter can be used to reduce jitter in a system (so you would even want to use it in cases where the incoming sampling rate and outgoing sampling rates are the same). This is why some DAC’s include an ASRC at the input – to reduce jitter originating at the signal source.
(trranlated by google)
幸いなことに、ASRCの出力サンプリングレートに使用されるクロックが非常に正確で安定していて、着信信号に適用されるフィルタリングが適切に行われている場合、ASRCは非常に適切に動作できます。この例はたくさんあります。(残念ながら、ASRCの実装が不十分な例は他にもたくさんあります。これが、多くの人がサンプリングレートコンバーターが悪いと考える理由です。ほとんどのサンプリングレートコンバーターが悪いためです。)実際、正しく作成されたサンプリングレートコンバーターを使用できます。システムのジッターを減らすため(したがって、着信サンプリングレートと発信サンプリングレートが同じ場合にも使用する必要があります)。これが、一部のDACの入力にASRCが含まれている理由です。これは、信号ソースで発生するジッターを低減するためです。
サンプリングレート変換でジッターを減らせると、なんと、ここでお墨付きがもらえた!
うまく実装したらという条件付きだけど。
Jitter – Part 9 – When do I care?
Jitter – Part 9 – When do I care?
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-9-when-do-i-care/In order to talk about WHEN we care about jitter, we have to separate jitter into the categories of Data Jitter and Sampling Jitter
ジッタを気にする場合について話すには、ジッタをデータジッタとサンプリングジッタのカテゴリに分類する必要があります。
このPart 9で最後だ。
データジッターに関しては、機械と接続ケーブルをちゃんと使えと書いてある(うーむ、、、)。
サンプリングジッターのほうのまとめも、大したことは書いてないかな。
Can you hear jitter?
The simple answer to this these days is “probably not”. The reason I say this is that, in modern equipment, jitter is very unlikely to be the weakest link in the chain. Heading this list of likely suspects (roughly in the order that I worry about them) are things like
- aliasing artefacts caused by low-quality sampling rate conversion in the signal flow (note that this has nothing to do with jitter)
- amateurish errors coming out the recording studio (like clipped signals, grossly excessive over-compression, and autotuners) (and don’t get me wrong – any of these things can be used intentionally and artistically… I’m talking about artefacts caused by unintentional errors.)
- playback room acoustics, loudspeaker configuration and listener position
- artefacts caused by the use of psychoacoustic CODEC’s used to squeeze too much information through too small a pipe (although bitrates are coming up in some cases…)
- Dynamic range compression used in the playback software or hardware, trying to make everything sound the same (loudness)
- low-quality loudspeakers or headphones (I’m thinking mostly about distortion and temporal response here
- noise – noise from the gear, background noise in your listening room… you name it.
So, if none of these cause you any concern whatsoever, then you can start worrying about jitter.
最近は、昔ながらの「デジタルっぽい」音源は、ほとんど全く無くなった。
それどころか、昔のCDでも最近の機械で鳴らすと、デジタルっぽくない音がすることも多い。
録音も再生機器も良くなったということだろう。
しかし明瞭に聞こえなくても、ジッターが再生音に影響しているのは確かだと思う。
今でもちょっとしたことで、デジタル音源の音が変わるのだから。
今回、ジッターというのはいろんな切り口があるのだというのを改めて確認した。
それにしても、複雑で意味不明で分かりにくい。その一方で疑問が解けたこともあったので、読んでよかったと思う。引き続き、マイペースではあるけど、勉強していこう。
しかし、疲れた、、、今回はここまで。
May 10, 2022
DVDドライブで聴くCDの音が良いような
うちではCDを聴くのにノートPCにUSB接続したDVDドライブを使っている。
ノートPCといってもTiny Core 64 / mpdをインストールしたPPAPフロントエンドだ。つまり音の出口はうちのメインシステム。
普段、CDはリッピングしてflacにしてNASに置いて鳴らしているんだけど、リッピングができていないときにDVDドライブを使って直接にCDから聴いている。
しかし使い始めた当初から、なんだかこれが音が良いような気がすると思っていた。
ブラインドで分かるとは思えないし、プラセボだろうと思っていたんだけど、その割には何時の間にかリッピング前にCDで聴いてみるということが増えてきた。単にリッピングが面倒だからという説明で納得していていいのか、、、そんなことを考えるようになった。
そういうわけで、ちょっと踏み込んで考えてみようという気持ちになったということだ。
差異があるのはPPAP Frontサーバーだ。
様相を表にしてみる。
mpdがどのように動いているのか、比較する。
strage plugin | input plugin | decorder plugin | output plugin | |
---|---|---|---|---|
Daphile / UPnP | curl | curl | pcm | pipe |
NAS / TCP IP | local | file | flac | pipe |
CD Drive / USB | udisks | cdio_paranoia | pcm | pipe |
mpdの前段の処理が三者三様で異なっていることが分かる。
plugin以外の要素も加えて図にする。

UPnPを使うときはupmpdcliが同時に動いている。topでみたらVSZ %VSZが大きくて、仮想メモリを1.5GBぐらい確保しているようだ。何に使っているのか分からないけど。
DaphileにUPnPのサーバーとコントロールポイントを宛てているのは、Daphileのコントローラーであるウェブブラウザがコントロールポイントというのはどうもしっくりこなかったからだ。ウェブブラウザとDaphileがUPnPでつながっているわけではないと思うので。
スマホアプリのSqueezerとか使ってコントロールする場合はどうなのかな、あれもUPnPとは違うのではなかったかと思うのだけど。

NASから鳴らす場合はnfsが働いているんだけど、昔の経験ではNASのマウントはけっこう重い。甘っちょろいNASはマウントの負担で動かなくなることがある。
UPnPを使う場合よりは図面がすっきりしている。

USB DVD/CDドライブを使う場合は、cdio、dbusあたりが働くのではないかと思うんだけど、よく分からない。しかし何が動いてるにせよ、アドレスの処理とかの負担が少ない分、たぶんLANを通すより軽いのではないだろうか。
mpcは軽いクライアントで殆ど無視できると思うので、LANはPPAP Middle Endへの出力にほぼ専念できるのではないか。
これだけ違ったら、音の良し悪しの判断はともかく、音が違っていたとしてもおかしくないということかな。、、、
いや、音が違っておかしくないということはない。
なぜ違うんだろうというのは疑問として残る。
同じデジタル音源で同じ再生機器であっても、OSで音が違う、再生ソフトで音が違うというのは、しばしば聞く話だ。
しかしデジタル信号としては同じものだ。
(うちはmpdでアップサンプリングするので厳密にいつも同じなのかと問われたら同じ計算してるとしたら同じ結果になるんじゃないかなとしか答えられないんだけど、ビットパーフェクトで鳴らす場合にも実際にそういうことであるわけで)
同じ信号でも音が違うというのは、アナログレコードだったら当たり前のことだと思ってしまう。
しかし、アナログ的に厳密に同じ環境にして鳴らした場合、音の聴き分けは難しいのではないだろうか。
デジタルのCDは、最初は同じCDは同じ音がすると言われた。
アナログはちょっとしたことで変わるけどデジタル信号は01で変わらないからと。
現実、そうは聞こえないと言ったら、機械が悪いとか聞く者の耳が悪いとか言われたものだ。
実際のところ、撲なんかは今でも、同じデジタル信号で同じ音がしないことに、どこか納得できない気分を抱えている。これは何なのか。若い頃に、デジタルは同じ音がしないはずが無いということを叩き込まれたせいなのか?
なんというかな、、、
あれだけ「同じ音だ」と言っていた人達は、今は何処で何をしているのか。
理屈は分からないけど同じ音がするはずがないんだよ、だってデジタル信号といったって電気っていうのはアナログな存在だからね、などと言っても、僕は何だかそれでは気が済まない。
そう、実際にすっかり同じ音が出るようにした上で、「ほら、ここまでのことをしないとデジタルで同じ音は出ないんだよ。あなたたちが言ってたことってすごく底が浅くていい加減で視野狭窄で考えも研究も足りなかったってことが分かったかい?」というふうに言ってやりたいのだと思う。
まあ、無理なんだけど。
デジタルだから同じなんて言ってたけど、今思えば底が浅くていい加減で視野狭窄で考えも研究も足りなかったと思う、と言ってるオーディオ関係者を見たことが無いので、そんな気分になるのかな。
今の状況は「コンポが良くないから音が同じにならないのだ」で済んでしまう。
ソフトで音が変わるなんて、どこかおかしい機械をお使いなんですね、とか。
それって昔と同じじゃんね?
いったいなにをうだうだいってるのか。
要するに、アプリだプラグインだを通すうちに音が変わるのは現実としてあっても理屈が伴っていなくて気持ちが悪いと言いたいのだろう。
ジッターが違うんだろうだけではいまいち足りない気がする。
アプリの違いによって、どのようなジッターが生まれ、どのようにして音に影響するのか、それが説明されないと分からない。
ここらはアナログ的な何かだろう。
というかデジタルな問題ではない。
ソフトウェアが動くことでコンピューターの中でアナログ的な何かが生じているはずだ。瞬間的にではなく、音に影響するぐらい持続的に生じていて、それがソフトウェアによって異なり、デジタル音声データに乗っかって転送され、DA変換の何処かに影響する。
そう考えないと、現実に起きていることの説明がつかない。
だってデジタル信号としては同じなのだから。
僕が思い付くのは、プラグインの動作に周期的に継続して現れる01の並びがあって、これに伴う周期的な電圧変動がクロックを揺らし周期的なジッターとなる、これがデジタル信号に乗って伝送される、周期的な変動だから音に乗る、とか。
まあ、僕なんかが出来るのはこんなふうに取り留めなく妄想じみた思考をすることばかりで、現実には研究できる人にしっかりやってもらうしかないわけだけど。
なんか、今回は要するに愚痴みたいな感じになった。どうなってんだろう。おかしいなあ、、、
May 31, 2020
ジッター再々考
前回、サンプリングパラメータによるジッターの影響の差異についてという、大仰なタイトルのエントリーを上げたんだけど、ない頭でいろいろ考えている。
繰り返し色々考えているので、今回のタイトルは再々考ということだ。アベノマスクもまだ届かないのに我ながら暇なことだ。
前回のエントリーで僕は「PCトラポによるアップサンプリングもジッター対策だと考えて使ってきている。そもそもハイレゾ音源で音が良くなるのは、それ自体がジッター対策になるからだ」と書いた。
ずっと、そう考えてやってきていた。
それが、どうも違うんじゃないかと考え始めている。
違うというか、考えが足りないと。
今回は、その不足分を追加する試みだ。
でも思いつくままの書き散らかしでとっちらかって、例によって科学的な正確さとは縁がない文章なので、世の中では意味がない内容かもしれない。そういう意味では、アベノマスクのいいかげんさを笑えないエントリーだ。
前回エントリーの試聴では、アップサンプリングと、仮想アースによるFGの安定によって、音がどう変わるかを確認したのだけど。
色々と、考えを改めることになった。
うちのデジタルオーディオに纏わる「仮説」についての話だ。
まず、PCトラポでアップサンプリングすることの意味について。
ジッター対策というよりも「アナログ音声の情報量」への貢献のほうが大きいのではないかと思うようになった。
情報量って、アップサンプリングでデジタルなデータ量が増えるのは当たり前(44.1/16から768/32だと30倍以上)なんだけど、データ量=情報量とかいう、そういう話ではない。
以前は、アップサンプリングに伴って情報量が増える理由について、ジッターの影響が少なくなり、DA変換の正確性が向上することによるものだろう、と考えていた。
最近、考えるようになったのは、デジタル信号から変換されるアナログ音声信号の「振幅」の正確性への影響だ。
DA変換後のアナログ信号の振幅が、より正確に再生されるようになることで、音声の情報量が増加するのではないか、ということ。
わけがわからんね。
もう少し整理していく。
録音に際してアナログ音声は、サンプリング周波数で決められた時間間隔でサンプルされ、デジタルデータにAD変換されている。
サンプルされたデータがアナログ出力にDA変換された信号電圧の数値は、サンプルされた時点の数値はデジタルデータ自体から正確に数値化して変換すればいいのだけど、サンプリングされていない、サンプル間のアナログ出力電圧の数値は、DACチップによる補間で決定される。
補間というか、要するにサンプリング定理に則ってDA変換される過程で、サンプル間をつなぐアナログの電圧の値(振幅)がDA変換によって決定される。
NOS DACだとアップサンプリングなし、補間されて得られる数値は、たしかローパスフィルターの品質に影響されるのかな(違っていたら御免なさいだ)。
通常のDACだと、DACチップによるアップサンプリングを行うので、その品質にも影響される。もしもZOH、Linearなど低品質なアップサンプリングを行うDACチップがあったとしたら、十分に正確な振幅値の抽出が難しく、正確なアナログ波形再現が望めないのではないか。
低品質なアップサンプリングでも理論上は音質上の問題は全くないという説明を何処かで何回か読んだのだけど、僕には難しくてよく分からなかった。
ZOH、Linearなど低品質なアップサンプリングを行った場合、下図のようになる。


本来、DACチップが理論通りに働くなら、アップサンプリングに伴う音質の改善を考慮する必要はなくて、NOS-DACの音質はどうとかいう話もないはずなのだ。理論通りにいかないから、どうしようDACチップでアップサンプリングしようというような話に現実のチップがなっている。
そういう現状なのに、ZOH、Linearみたいなアップサンプリングでも音質に影響しないとは、個人的には中々信じられない。実際、PCトランスポートでZOH、Linearといった設定にしてアップサンプリングした場合、DACがADI-2 DACだと明らかに音質低下がある。むしろそんなことはしないほうがいい。
どのような方法にせよ、サンプル間が補間されて電圧が生じないと問題がある筈。
各々のDACチップなりの手法で電圧出力しているのだろうと思う。
そもそも、その補間自体が正確ではなくて、電圧に時間軸の変動があったり電圧自体の誤差があったりしたら、どうだろう。
そうした変動は、たぶんジッターとして再生音に作用する。
つまり、時間の流れのままに変動しているアナログ再生波形として考えた場合、時間軸の変動も電圧の誤差も、結果として出てくるのは「アナログ波形の乱れ」にしかならないので、区別すること自体ができないのではないか、だったら「ジッターの影響」で括られるのではないか、と思うからだ。
ちょっと、DACチップの気持ちになって、アナログ波形を出力してみた図。

我乍らひどい。
あんまり人に見せられないな、怒る人いるんじゃないかな。
実際には、このようなことにはなってないだろうとは思うのだけど。
それはともかく、PCトランスポートで良質なアップサンプリングをしておけば、DACチップによる補間の影響は小さくなる。
元のアナログ波形をPCでシミュレートし、その波形シミュレーションの振幅変動の数値から、新たなデジタル信号をサンプル数を増やして作り出し(そういうアップサンプリングをするということだけど)、そのデジタル信号をDACに伝える。
再生されるアナログ信号がよりAD変換前の信号に近い正確なものとなる。

アップサンプリングしてやらないとサンプル間の電圧が正確に再現されない(断言してるけど仮説だ)。
再生波形の歪みは20kHZとか聴取可能限界以上で生じるんだろうけど、再生音全てに影響すると思う。
正確なサンプルが増えることで、正確な音声信号の「振幅」の再現が可能になる。
より正確なアナログ波形の再現は、音楽の情報量を増やすことにつながる。
これはハイレゾ音源を使用する場合にも当てはまるだろう。
ここまで書いて、ひっくり返すような話だけど、ふつうに44.1/16の信号をDACチップ通したら、オシロスコープでは問題ないアナログ波形が表示される、というのを過去に何回か何処かしらで読んだことがある。つまり、アップサンプリングしたら正常なアナログ波形が得られるというのは、違うのだという。
しかし、じゃあオシロで正常な波形が出ていれば音質に問題がないかといえば、たぶんそうじゃないんだよね。ジッター対策なんか何もしなくたって、オシロの波形は正常でDACから音は普通に出るのだ。
そしてそういう音にオーディオファイルは満足できない。
僕は何を聴いているのだろう、ということになるのだけど。何が一体、どうなってるんだろうね、、、
DACチップに上記のような問題があるというのも仮説で、ジッターがどのようにDACチップに作用するのかもよく分からないのだけど。
次に、仮想アースによるジッター改善に伴い、再生音の音楽性改善がみられることについて。
驚いたのは、アップサンプリングによるよりも、PCトランスポートの仮想アースによるジッター低減のほうが音楽性の改善効果が大きかったことだ。まあ、驚くことじゃないと言われたらそうなんだけど、想定以上の音の変化があった。
ここでいう「音楽性」とは、音色の鮮度、色彩感、生命感といった感触。音色の自然さ、リアリティも含めたいところだが、前回の試聴では逆に不自然に感じられたケースがあり、ことは単純ではないみたい。改善するのが「音楽性」という漠然とした表現しかできないのも難しいところ。
サンプリング周波数には関係なく、ジッター改善に伴い再生音の音楽性の改善がみられる。
さらに今回、新たに気付いた。
サンプリング周波数が一定なら、ジッター改善に伴う音質向上に際して、基本的には情報量の向上は伴わない。
本当に?
いや、でも、なんだかそんな感じだよね?
ちょっとこれは僕にとっては意外なことだった。
僕は今まで、ジッターが改善され音質が良くなれば情報量も増えると、勝手に思い込んでいた。
考えてみたら、うちのオーディオの音質改善は、かなりの場面でアップサンプリングと足並み揃えていたので、「ジッター改善」に伴う情報量の増加について、ちゃんと意識し比較したこと自体がなかった。あるいは、音色が綺麗になって聴き取り易くなったのを「情報量が増えた」というように表現した事も、もしかしたらあったかもしれない。
今回の試聴で、情報量と音楽性、パラメータが2つになって、ちょっと、今まで何してたの?、という気持ちにもなったりしてるんだけど、、、ともかく、ジッター改善に伴う音質改善が、音声の情報量増加につながらないらしい?のは、僕にとってはかなり意外で困惑した。音楽性の向上は情報量の向上によるものと、ずっと考えていたんだからね。
そもそも、アップサンプリングの有無によってDA変換後の情報量が変わるということ自体が、理論的には有り得ないことだ。
デジタルデータはサンプリング定理に沿って再生されれば正確に再現される、理論的には。
現実にはそうはいかない。
ならばジッターを低減さえすれば理想的な再生に近づくに違いない、と考えていた。アップサンプリングで音声の情報量が増えるのは、アップサンプリングによってジッターの影響が減ることで理論的なDA変換に近づくから情報量が増えるのだ、と思っていた。
だけど今回、どうも、ことはそう単純ではない?という考えに至った、ということだ。
ジッターが改善したら「音楽性」が改善するが、音声の情報量は増えない。
正確なアップサンプリングを行うことで、CD音源に含まれている本当の情報量を引き出すことが出来る。
逆に言えば、情報量の向上がなくてもジッターの低減によって再生音の「音楽性」の向上を目指すことは出来る。
また、アップサンプリング自体にジッターの悪影響を減らす作用がある、という以前からの考えは、今でも妥当ではないかと思っている。アップサンプリングで情報量の向上だけではなく、音楽性の改善も得られるからだ(仮想アース程ではないけれど)。
しかし、どんな挙動がどのように作用しているかは分からない。
過去に僕の考えをアップしたことはあったが、当時から科学的な根拠がある論考ではなかったし、当時の考えだけでは足りなかったと思ってこんなエントリーを上げてはいるが、科学技術的根拠がないという意味では相変わらず机上の空論のままなのだ。
今回、更に、もしかしたらと思ったのは、データのサンプリングパラメータによって、ジッターの影響の現れ方が違い、音質劣化の聴こえ方も違うのではないか、ということ。だけど、なんだか手に負えない感があるし、そろそろ息切れ気味なので、今回はここまで。
May 24, 2020
サンプリングパラメータによるジッターの影響の差異について
GW以降、久しぶりに政治的なエントリーをあげたいと思ってたんだけど、まとまらない。
表現者とかアーティスト職の人たちが、政治的発言をすることの難しさと日本の現状についてといった内容。
しかし、どうにもまとめきれない。そうこうするうちに、SNSのツイッター上で「#検察庁法改正案に抗議します」というのがあって。黒川氏が辞任らしい。
なんだかもう、整理がつかん。
そういうのに比べたら、オーディオに関するエントリーは書きやすい。
書きやすいと言いながら、今回のエントリーは、読むのも大変だと思う。
なにしろだらだら長いのだ。
闇雲に何かしてるだけで収拾も付いていないし結論もない。大仰なタイトルだが内容は薄い。
CDが登場した頃、デジタルっぽい音という言葉が生まれた。
音が良くないと多くの人が感じたのだ。
実際、僕が最初にCDを聴いた当時のコンポはひどい代物だったけど、アナログのほうがいい音だと思った。
CDは、くぐもってるというか、生命感がないというか、灰色のベールを被ったような感触で、ひどいコンポでもそれなりに生き生きと鳴るアナログレコードよりCDのほうが音がいいとは思えなかった。10年ぐらいはそんな感じで過ごしていたように思う。
世間でもアナログ優位ということはずっと言われていて、デジタル同等というのは最近だ。
最近、デジタル音源の音は良くなったのだ。
CDも昔より音が良くなった。
録音が良くなった?いや、意外に、昔のCDも今の環境で鳴らすといいことも多い。
つまり、再生環境が良くなった。
再生環境のどこが良くなったんだろうか。
DACチップが変わったとか、いろいろあるんだろうけど、要するにジッターへの対策が昔よりも進んだのだろう。ノイズ対策や電源の強化が、デジタル音源の再生には必須な事も分かってきた。ある程度の対策は、うちでも行っている。
僕は、PCトラポによるアップサンプリングもジッター対策だと考えて使ってきている。
そもそもハイレゾ音源で音が良くなるのは、それ自体がジッター対策になるからだ。
PCM300kHz台でかなりの音質向上があり、700kHz台で更に改善があった。
その700kHz台で聴き始めた、今から1年前に、ボーカル録音への違和感についてエントリーを挙げた事がある。
アップサンプリングについて色々
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20190222a.htm
歌声の録音について自分なりに考えた
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20190320a.htm
先日、これらに訂正の追記を入れているのだけど。
今回のエントリーはそれに関連している。
当時、あらゆる楽音がリアリティを増したように聴こえる中、ポップミュージックのボーカルだけが違和感を増した。
音としての情報量は増えているようなのに、何か聴きづらい。しかも当初はJPop音源しか気付かなかった。
当時の僕は、録音の質に解を求めた。
その後、ボーカルの違和感を感じる音源はJPopだけではなく、欧米の音源にもあることが分かってきた。それも意外な、優秀録音とされていて300kHz台で素晴らしい声を聞かせてくれた音源ですらも。
自分なりに考えたりするうちに、多少は違和感は減っていた。
自分が慣れたのか、とも思っていたんだけど、インシュレーターを新たに追加したりリピーターハブを使ったり仮想アースを足したり、いろいろやっていたのが影響した?というのもあったのかもしれない。
銅板仮想アースをapu2c4、705.6kHz NAS mountで使い始めた時点で、この音質改善はどういうことだ?という気持ちが芽生え始めた。
ここで起きている音の変化は何に伴うものなのか。
アンプに使っていた時のアナログな変化とは違う。
PCトラポのGNDを銅板で拡張することで、GND電位が安定しクロックジッター低減につながっているとしたら、これはジッター低減に伴う音質改善を聴いているということだ、、、
今年の春から、Elitebook 2570pとapu2d4によるPPAP方式に移行した。
PPAPは更にジッターを減らす再生方式だ。
PPAP 768kHzで、いよいよ全く、1年前に感じていた違和感がなくなった。
なくなったのだ。
違和感を感じていたはずの声が、違和感を感じ始める前よりもっと自然に、オーディオ的な驚き、、、いや、音楽自体の美しさそのものをもって耳に届く。
ここに至って、ようやく気がついた。
あの違和感は、残存していたジッターによるものだ。録音のせいなどではない。
そんな断言していいのかね。
最低限の検証は、しないといけない。検証って何って、、、聴くだけなんだけどね。
システムから外していたapu2c4を戻して比較することにした。
apu2c4で、705.6kHz NAS mount再生を試みた。
LANの状況が違う。当時の100Base-Tではなく、1000Base-Tだ。1年前の100Base-Tに戻してもいいんだけど、、、既にFX08-miniは他所で使ってるんだよね。
比較試聴に使った音源は以下。
- 赤い鳥 - heritage from '70s CD選書 ベスト / 翼をください
- 矢野顕子 - Soft Landing / Bye Bye
- 井筒香奈江 - Laidback 2018 / Little Wing
- Joni Mitchell - Blue / A Case of You
- The Rolling Stones - Let It Bleed / Love in Vain ~ Country Honk
PPAP 768kHz | 705.6kHz NAS mount | |
---|---|---|
赤い鳥 翼をください |
イントロのピアノが綺麗。優しい音色だ。歌声の導入も柔く自然で、表情豊か。上手いなあ、と思わず感心する。音楽のニュアンスが伝わるボーカルだ。ハーモニーも綺麗。ドラムやベースも程よい存在感を主張する感じで聴こえる。PPAP 768kHzの音は繊細で丁寧だ。 |
イントロのピアノと歌声、ともに、PPAP 768kHzと比較したら荒さがある。1年前に「スピーカーを通した歌声のようだ」と評価したのはボーカルだけだったけど、改めて比較して聴くとピアノも硬い。ハーモニーやリズム隊も、比べたら雑でやっ付け仕事みたいな印象の音に聞こえる。 |
矢野顕子 Bye Bye |
ピアノとボーカルで曲が始まる。矢野の声は独特のハスキーさがあって、再生環境によっては難しい刺々しさが出るんだけど、そんなことは全くなく、難なく歌の優しさを表現する。 |
やはり「スピーカーを通した音」という感じの聴きにくさがある。矢野の歌は、その表情の変化が再生されないと、芸術性の多くがかき消されてしまうという事が、この試聴でよく分かった。 |
井筒香奈江 Little Wing |
イントロのエレキベースの沈み込みが深い。歌声は自然にひびく。実はこれは、以前に705.6kHzで聴いた時に、そのウィスパーボイスに強い違和感を感じた音源だった。終盤、ボーカルにエコーがかかるんだけど、それも違和感なく聞ける。 |
イントロのエレキベースが、何か不自然、、、歌声は、やはりカサ付いた感じで、ハスキーに聞こえるとも言えるが、不自然だ。終盤のエコーは、神秘的な感じではなく、お風呂場という感じ。安っぽく聞こえる。カラオケのエコーか、、、こんなに違うものか、、、 |
Joni Mitchell A Case of You |
イントロのギター、ささやくように歌い始めるジョニ。音楽は徐々に熱を帯び秘めた思いの発露となっていく。オーディオという機械がどのようにして音楽性という掴みどころがないものに貢献できるのかを見せつけられている感じだ。 |
1年前に洋楽で最初に違和感を感じたのは、優秀録音とされていたこの音源だ。384kHzで聴こえなかったニュアンスが聴こえるのに、歌声に違和感が生じた。何かがうまくいっていない感じ。当時はいろいろ問題が重なっていたけど。しかし、今、聴いても、そんなにひどくはないのだ。圧倒的な芸術ではない、というだけで。それが何か決定的な差異を生んでいる。 |
The Rolling Stones Love in Vain Country Honk |
Love in Vainのほうがクリアで、そこでミックが歌っているかのような音がする。生々しい。酔わせる歌だ。Country Honkのほうがややノイジーで、ラジオからの音のようにも聞こえる歌声。それでも生命感を感じる再生音で、違和感は感じられない。つまり、ノイジーな録音だったらいけないという訳ではないんだね。 |
この再生自体、悪い感じではない。ミックは素晴らしいボーカリストで、その音楽性を引き出していると思う。しかし歌声の深みが違う。他の楽器も含めて、PPAP 768kHzと比較したらわずかに埃っぽい再生音だ。ほんの少しの違いだが、聴く者の感受性への訴えかけはかなり違う。この差はLove in Vainの方が大きかった。 |
こんな感じ。
しかし、、、こんなに違ったっけ? FX08-miniを戻してみるべきか?あと、当時は仮想アースを使っていなかったので、今回のapu2c4にも使っていない。その差異もあるのかもしれないが、、、
PPAP 768kHzのほうが、ずっと音楽的だ。
比べると705.6kHz NAS mountの音は、ノイズっぽい。
ただ、楽器の音は差異が小さいと感じる。違和感が少ない。これに対してボーカルは聴き分けやすい。差が大きいのだ。
改めて聴き直すと、ボーカル以外の楽器音や環境音も違いがあるのがわかる。しかし、やはり違和感とまでは感じられない。人の声は、わずかな差異でも気付きやすいのだと思う。音源によっては全く違うという印象を受ける。逆に差が少ない音源もあるということだ。
ここで、サンプリング周波数によって、どのような聴こえ方の変化があるのか聴き較べてみよう、という気になった。
ハードの条件は同じ、apu2c4、NAS mountだ。
音源は、705.6kHzで聴いたのと同じものを聴く。
384kHz 24bit |
700kHz台と比較したら再生音の情報量は減る。しかし、これはこれでいい音に聞こえる。 |
192kHz 24bit |
翼をくださいは、更に情報量が減ってきたな、という感じ。しかしバランスはとれている。ポップスとして気持ちよく聞けるのは聞ける。 |
96kHz 24bit |
普通に聞ける。でもカーステレオと差別化できるかと言われたら、まあ感動は同じぐらいかな、と思う(うちのマツダロードスターのカーステレオはBoseでデジタルアンプで、音源は320kbps mp3を音楽再生専用にしたBlackberry bold 9000のイヤホンジャックから出力している。こういっちゃなんだが悪くない音がする。低音ときどきブーミーだけど、クラシックでもロックでもいい感じに鳴る)。 |
44.1kHz 16bit |
CDリッピング音源、アップサンプリングなし。 |
44.1kHz 16bit 仮想アース |
ふと思いついて、銅板仮想アースを使ってみる。
付けて鳴らしてみたところ、、、驚いた。 |
96kHz 24bit 仮想アース |
仮想アースなしの時の、カーステレオみたい?という感じはなくなっている。 |
192kHz 24bit 仮想アース |
翼をください、のびやかな歌声、、、コーラスもごちゃっとせずに分離し、同時にハーモニーは溶けあう。ピアノはピアノになった。矢野顕子は芸術家になった。井筒は録音いい感じになってきた。ジョニの唄は96kHzと大きな変化はない。しかし楽器が更に良くなった。ミックも上手いボーカリストだったんだなあ。44.1/16のときのアンバランスな感じは、すっかりなくなった。 |
384kHz 24bit 仮想アース |
192kHzから更に向上、音色のニュアンスがより深いとこまで表現できてる感じ。 |
705.6kHz 32bit 仮想アース |
2ヶ月前までメインシステムで使っていた設定だ。久しぶりに戻して聞いてみる。 |
768kHz 32bit 仮想アース PPAP |
現在のメイン設定、PPAPに戻ってみた。 こうして比較してみたら、サンプリング周波数が小さいほうが仮想アースの影響は大きいようだ。44.1/16では影響が大きすぎて不自然に聞こえてしまった(これはどう考えたらいいのか、よく分からない)。サンプリング周波数を上げるに連れて不自然さは解消した。しかし、では700kHz台では影響が小さいから必要ないかといえば、逆に全くそんなことはなくて、小さな音質変化が大きく音楽性に影響するみたいだ。なんだろうねこれは。 |
96kHz 24bit 仮想アース Ras pi2 i2s optical |
ここで思い付いて、最近、低音質音源用に使っているRaspberry pi2に仮想アースを使ってみることにした。
apu2c4のusb出力と比べたら、仮想アースの効果は少ないみたい。 |
試聴経過は、取り敢えず以上だ。しかし、どう考えたらいいんだろう。いろんな要素が混在して評価しにくい。
まずボーカル。
PPAP 768kHzを基準として、サンプリングパラメータを下げていくにつれて、砂っぽく、ノイズっぽくなっていくのは共通。
384kHzではまだ高評価だ。
192kHzあたりから評価がぼやけてくる。なんというか、ゼネラルオーディオと差別化する意義を見出せなくなってくるというか。
考えてみたら、これってRME ADI-2 DACにとっては、かなり辛口の評価なんだけど、実際、僕の耳にはそう聞こえたんだからしょうがない。i2s-opticalから良質なデジタル信号を入力した時の音は96/24でもかなり良いので、それだけ今回の試聴に使ったusbデジタル信号には問題があるのかも、、、
仮想アース追加後、随分、音色の表情が変わった。
44.1kHz/16bitでの評価は、どう考えたものか難しい。
96kHz以上では、順当に音質改善があるように思う。384kHz以上で何故か洋楽アーティストの声に違和感があるような。これもどう考えるべきか分からない。768kHz PPAPでは違和感ないのだけど、、、
楽器のほうも、サンプリングパラメータを下げていくにつれてノイズっぽくなっていく。
ピアノについての評価が辛い。192kHzでオモチャと評価している。
井筒のベースも評価が辛い、というかパラメータによって随分変わる。
ボーカル同様、仮想アース追加後の方が評価が上がる。
192kHzで、ピアノがピアノになったと評価している。
楽器によって傾向が出ないかとか思ってたけど、録音も違えば音楽ジャンルも違うのでまとまった結論が出せない。当たり前か。
とりあえず、PCトラポに仮想アースは效く効くということではある。GNDの安定によってジッター低減につながっているのだろうか。
ここまでで、つかれた。。。限界を感じるのでこのくらいにする。
Mar 20, 2019
歌声の録音について自分なりに考えた
前回のエントリーで、「日本のポップミュージック、特にボーカルの多くに、僕は違和感を覚えるようになった。生の人の声に聞こえないのだ」「マイクを通した声が、リビングルームのコンポから鳴るように録音されているのだとしたら」と書いた。
まあ、ずいぶんなことを書いたもんだと自分でも思う。
どうしようかと思ったけど、今の自分なりの考えを書いておく。本当は録音を実践して考察するのが筋なんだろうけど、そこまでは出来ていない。既存の音源をいくらか聴いて、頭の中で考えただけの話だ。
自分でもたわごとかもしれないと思う。
2020.05.13.追記。
現在、PPAP方式 768kHzで再生し始めて1か月ほどになるんだけど、1年前に感じていた違和感がなくなった。
違和感を感じていたはずの声が、違和感を感じ始める前よりもっと自然に耳に届いている。
ここに至って、ようやく気がついた。
あの違和感は、残存していたジッターが原因だったのだと思う。
録音のせいなどではなかった。録音が良くない音源もあるのはあるのだけど、それとこれとは別のことだ。
取り急ぎ、追記まで。
ここから下に書いていることは、なんだったんだろうと思うが、今の時点では分からないままだ。
分かったつもりにならないように気を付けないといけない、、、
2020.10.18.遅まきながら、更に追記。
ジッターの影響について確かめようとした試みについて記録。
検証できていると言い切れないけれど、関連エントリーということで記載しておく。
サンプリングパラメータによるジッターの影響の差異について
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200524a.htm
ジッター再々考
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200531a.htm
まず、違和感の原因について。
ボーカル録音は、マイクと口の距離によって随分音が変わるのだそうだ。
ライブで使われるのはダイナミックマイクが多くて、レコーディングで使うのはコンデンサー型が多いとのこと。コンデンサーマイクだと、だいたい20~30cmの間隔が一般的だという。ポップミュージックの場合はそういう録音で、それより距離が離れるとボーカルの訴求性というのか、そういうのが薄れるんだそうだ。でも50cmほどの距離で歌う歌手もいるそうだ。
考えてみたら、数10cmの距離で他者の歌声を聞くということは、現実生活の場面では、まずない。
たぶん、そんなことをしたらかなりうるさいんじゃないかな。
他人の生の歌声を聴く状況は、例えば誰かの誕生日で歌われるハッピーバースディを聞くとか。1m以上離れていることも多いだろう。
現実的な距離、と言っていいのか、離れた距離でボーカル録音された音源について考えてみる。
まず、オペラのライブ録音のようなケース。かなり離れたところから録音することになる。それでもリアルな音声に録音できるのは、そもそもオペラの歌は遠くから聴くものだからだ。オペラ歌手の体は楽器そのものだと思う。楽器を録音するように録音してもいいんじゃないかな。実際を知らないまま考えだけで書いてるから、見当違いかもしれないけど。
ポップミュージシャンの歌い方とは全く違うし、音声の聞かせ方も全く違う。録音で求められるリアリティも全く違うものになり、同列には語れないだろう。
では、例えば民族音楽の現地録音。離れたところから録音することがある。そうした場合は、空気感というのか、歌い手まで距離がある感じが録音されていて、再生音から普通に聴き取ることができる。
歌い方は、市販されているポップミュージックのボーカルと大きくは違わないものだと思う。しかし録音されている音声の聴え方は、かなり異なっている。
じゃあ、それが「リアル」なのかといえば、一概にそうとも言えない。
音声からの距離を感じると、聴くほうの気持ちはどこかクールになる。なぜか分からないけど、ポップミュージックを聴いたときに感じる「親密なリアルな感じ」は感じない。僕自身は、そういう民族音楽の録音の中にも「いい歌だなあ」と感じるようなものはあるんだけど、でも、一般的には「訴求性が低い」ということだと思う。
民族音楽のような音源は学術的な記録としての聴かれ方も重要なので、訴求性が低くくても許容されるし、ポップミュージックと歌声の聴こえ方が違っているのは、客観的になれるので、むしろ良い面もあるだろうと思う。
仮に、遠くに聞こえるような歌声の録音に、バック演奏を付け加えるとしたら、どんな録音だとしっくり来るだろうか。どんな演奏だとはまるのだろう。
それをポップミュージックとして売るとしたら。
たぶん、そうして生まれる音楽の音声は、僕らが慣れ親しんでいるポップミュージックとは全く違うものになるだろう。そして、たぶんだけど、相当売りにくいだろうと思う。
そこらのラジオでかかっても訴求性がある音では鳴らない。ラウドネス・ウォーとは全く無縁だろう。
訴求性のあるボーカルは、近くないといけない。
だから、マイクの傍で歌っている歌声を、離れたところにあるスピーカーから鳴らす。現在のポップミュージックでは歌声にエコーをかけたり歪ませたりすることもあって、そういうのも目的があって、効果を狙ってのことなのだ。
つまり、リアリティとバーチャルの線上で何処に落とし込むか、というのが、僕らが日常的に耳にするポップミュージックのボーカル、ということなのかと。
そのようにして制作された音源の歌声は、昔から広く受け入れられてきているし、むしろ一般的には、人間の生理にも合っているんだろうと思う。人間の生理に甘える形で音楽やオーディオのクオリティが下げられているとも言えるだろうけど。
でもその結果、僕なんかが、マイクを通したような声で違和感があると言ったりするのだ。
これはどういうことなのかとは思うけど。
洋楽で違和感を感じにくいと思ったのは、もしかしたら単に僕自身が英語のネイティブスピーカーに接する機会が少ないからに過ぎないのかもしれない、と今は思っている。つまり、ふだん聴き慣れない音声だったら違和感を感じないかもしれないということ。実際のところはよく分からない。
ポップミュージックに録音された歌声について「リアリティとバーチャルの線上にあるもの」だという認識にいたって以降は、いくらか違和感に振り回されるのは減っている。何がしかの納得が、僕の中で得られたということなのだろう。
ここにきて、音声に幾ばくかのバーチャル感がないと幻想の要素を含むポップには仕上がらないのだろう、という認識が生まれていて、音声のリアリティが強い音声は、より切実な内実の表現に向いている、というふうに思っていたりする。
それでも強い違和感を感じる音源というのはあって、そういうのは、やっぱり録音が良くないと感じる。
エコー感が必要以上に強すぎたり、ハスキーというにはざらついた感じが強すぎるような音声だったりで、欠落を何か過剰に付け加えて補おうとしている感じが強い。
今のシステムでは、そういうのが以前よりも明瞭になるように思う。
一方で、録音がいいというのか、違和感を感じない音源だと、思わず引き込まれるような声になる。歌い手の才能、生きている人の声が、ダイレクトに伝わる感じがする。
これらは、どうも若干遠くで歌ってるように聴こえる音源が多いような気がする。というか、適度な距離に聴こえるのだ。なんというのかな、握手しようと思ったらできそうな感触の歌声になる。
強くはなくても若干の違和感があるもの、つまり多くのポップミュージックの歌声は、今の僕のシステムではマイクに近すぎるように思う。
耳の傍で歌われている歌が、スピーカーの間から聴こえてくるような感じで、荒っぽく聴こえる。本来なら訴求性につながる筈であろう音の近さが、近くで聴こえるはずの音が遠くから聴こえてくるような違和感の原因になってしまっている。
こういうのは、以前には無かったのだ。
そういう感じなので、オペラなどのクラシック音源では、こうした違和感は生じていない。
以前は気持ちよく聴けていたポップ系の音源で生じている。
これは、、何とかしたいところだなー。
しかし、わけの分からないことばっかり書き付けていることよ、、、
Feb 22, 2019
アップサンプリングについて色々
最近はCDリッピング音源を705.6kHz32bitにアップサンプリングして聴いている。
以前は768kHzで聴いていたんだけど、ごくごく稀にクリックノイズが聞こえるような気がして(あくまで気がしてなんだけど)、精神衛生上の判断でそうしている。明らかにノイズが入るというのではないんだけど、、、
だから時々、768kHzに戻したりもする。
なんだか、768kHzのほうが705.6kHzより1割増し繊細な気がする。どうなんだろうね。
先日、mpdの設定を見ていて、libsamplerateはmpd 0.19.19のデフォルトリサンプラーであることを思い出した。libsamplerateがインストールされていれば、ビット深度とサンプリング周波数の設定をするだけで、libsamplerateで「SRC_SINC_FASTEST」の設定でアップサンプリングされるようだ。
そうだったんだなあ、、と見てるうちに、libsamplerateは「ZOH」「linear」といった設定も可能だったことに思い至った。正直、低品質ということで眼中になかったので、じっくり聴いたことがない。しかし、実際にはどんな音になるのか、確認しておくことには意味があると思ったので、ちょっと聴いてみた。
まあ、やっぱり良くないんだけど。
アップサンプリングなし(つまり44.1/16をそのままRME adi-2 DACで鳴らすということ)とZOH、Linear設定の700kHz台アップサンプリングを比べても、アップサンプリングなしの方がいいような気がする。ZOHよりは、linearの方が音がいい。というか、ZOHは刺々しいな。
試聴音源で詳細に比較してエントリーにしようかと思ってたんだけど、、なんか、めんどいな。
今回のエントリーはちょっともう、だらだらしている。
うちのやり方で十分、不満はないし、細かいこと言わなくていいじゃないかという感じ。
最近なんだか、アップサンプリングして聴くという手法が市民権を得つつあるような気がする。以前は、どちらかというと外道な手法というイメージで、正統なオーディオ再生ではないと一般的には認識されている、というふうに感じていた。それでも僕などは音がいいと思って、その手法を選択した。スーパーツィーターの接続に、世間では効果がないとされていたチャージカップルドネットワークを採用して使い続けているような人間だから仕方ないのである。
それが、風向きが変わってきている。
例えば、CHORDのCDトランスポート「Blu MkII」はアップサンプリングしてDACにつなぐ仕様になっている。
https://av.watch.impress.co.jp/docs/news/1041113.html
この機種が発売になったのが2017年、もう2年前のことだ。アップサンプリングしてDACに送るということは、バイナリ一致かどうかなんてもう気にしない、ということだ。僕は何でか、うっかりしたのか、もとからトロいのか、この機械がオーディオ界に及ぼす影響について気が付いていなかった。この頃から、たぶん、デジタルオーディオというものへの認識は変わって来たんじゃないかな。
バイナリ一致が金科玉条では無くなってきている。
MQAというフォーマットも、そうした認識の変化が受け入れられる土壌となっているのかな。
そもそもDACチップ自体がアップサンプリングして鳴らしているということも広く知られるようになってきていて、最近はこんなDACが売られている。
https://www.phileweb.com/interview/article/201902/12/634.html
CDの44.1kHzであっても、DSD1024まで引き上げて最高の音質で聴くというのがPro iDSDのコンセプトだという。Blu MkIIがやってることをトラポでやるかDACでやるかの違いというわけだ。
https://av.watch.impress.co.jp/docs/news/1167703.html
最近、「だれでもわかるハイレゾオーディオ」という本が出版されていて、電子出版で買ってちまちま斜め読みしているのだけど、ここではDACチップが行っているアップサンプリングをPCで代替しても構わないと書かれている。この本は「ハイレゾ」というより「DA変換そのもの」に関する数式苦手なオーディオファイル向け解説書なんだけど、かなり踏み込んだ記述がなされていて非常に面白い。というか、僕の興味の中心を射抜いている。すごく勉強になるし分かりやすい。「ZOH」「linear」についても書かれている。
アップサンプリングに日の目が当たること自体は別にいいのだけど、オーディオファイルの間だけではなく、世間一般でもアップサンプリングへの興味が高まっているようで、「アップサンプリング」でググるといろんなサイトがヒットする。ディープラーニングでアップサンプリングするというサイトがあったりして、それってもしかしてジョーク?とか思うんだけど、世間では案外、そういう感覚なんかもなあ、と複雑な心境になったりしている。
アップサンプリングと名が付くものなら何でもいいということになったら、将来的に僕自身が不利益を被るような気がする。例えば、libsamplerateはPCへの負担が大きいし上質なアップサンプリングだと言っても他と変わらないんなら、いらないね、ということになりはしないか。
もしも、libsamplerateがmpdで使えなくなったら。
SoXでいいじゃんと言われたら、うちはSoXで十分な音質を引き出すスキルがないんだよと言わざるをえない。libsamplerateならインストールさえしておけば後はmpdが勝手に良質なアップサンプリングをしてくれるので非常に助かるのだ。
PCトラポによるアップサンプリングは諦めて、Pro iDSDみたいなDACを買えばいいということになるのかもしれないけど、それはDACによるアップサンプリングの精度が重視されて今後は性能が上がっていくという事が前提になる。ZOHやlinearと同等のアップサンプリングでもいいということになれば、そういう安価で低い性能のDACチップが主流になるに決まっている。そうじゃない高性能DACは僕にとっては高嶺の花となるのだ。しゃれにならない。
そんなこと考えたりしてたら、MQAに否定的な話がアップされている。
記述を一部だけど引用してみる。
さよなら、MQA | | 言の葉の穴
https://kotonohanoana.com/archives/23587まず、MQAはロッシー/非可逆圧縮である。
MQA音源はMQA化された時点で「大元のデータ」から変質しており、二度と元に戻らない。
MQA音源はMQA Limitedの掌の上でしか真価を発揮できない。
なるほど、、、僕は過去のエントリーでMQAへの期待を書いている。
非可逆圧縮ということについて、まず、データの同一性という意味では、アップサンプリング自体がDACチップがするにせよPCトラポでやるにせよ、バイナリ一致の音ではなくなるということだ。一般的なDACで音を聞くことは、バイナリ不一致な音を聞いているということに等しい。そういう意味で、僕みたいなCDデータを700kHz台なんかにアップサンプリングして聞いてるような者にとっては意味が無い、ということがある。非可逆であっても解凍されたデータに充分な情報量があれば問題にならないんじゃないかと思う。
次に、非可逆圧縮の「PCMであれば本来あったはずのデータが削られる」というイメージについては、MQAはAD変換からDA変換まで一連の情報処理であり、録音からPCMデータが作られる段階で、AD変換などで生じる歪みを排除する処理が行われる、と僕は理解している。つまり可逆か非可逆かと分けられるものではない。言ってみれば最初からMQAなわけだから。そういう理解。
非常にわかりやすいMQAの解説が1年半前にアップされていたのでメモで追記。
https://rideonmarin.blogspot.com/2017/10/mqa.html
コラム MQA技術解説についての私的メモ・ロスレスかロッシーか?
しかし、音質がどうなのかという一点。
引用。
Roon 1.6によって「TIDAL Masters/MQAとQobuz/ハイレゾFLACを聴き比べる」ことが可能になり、比較の結果として「MQA音源は同スペックのハイレゾ音源と比較すると音質が劣る」という私自身の結論を得た。
もしその比較が妥当なら、僕もMQAには期待できない、ということになるのかな、、、
うちではmpd + libsamplerateで700kHz台へのアップサンプリングがデフォルトだ。その音は、一般的に流通しているハイレゾ音源そのまま(つまり96kHzや192kHzをDACチップでアップサンプリング)の再生音を凌駕する。ということは、MQAの再生音も越えていると予想される。
実際には聴けていないというのが歯痒いけど、、、
比較の経過は下記アドレスのエントリーに書かれている。読んでみて思うのは、、、判断は実際に聴くまでは保留かな。
https://kotonohanoana.com/archives/23505
なんというか、うちでやってるmpdで700kHz台に上げるというのは、どうなんだろう。一般的な音質比較の対象としていいものかどうか。
MQAは176.4kHzとか96kHzで、MQA対応DACは、そこからどういうフィルタリングをするのだろうか。
上位の周波数にアップサンプリングするのかいな?
しないのなら、700kHzのほうが有利に決まっていると思うし、時間軸の正確性はどうなるのか、、、
使うDACによっても違うだろう。CHORDのDACとかPCM再生が得意なはずだけど、どうなんだろうね(僕はCHORDのDACは聴いたことがないのだ)、、、
最近、うちでオーディオを聴いていて気になるのは「録音」だ。
日本のポップミュージック、特にボーカルの多くに、僕は違和感を覚えるようになった。生の人の声に聞こえないのだ。洋楽だったらロックとかでも、まだ生の人の声に聞こえるのが多い。
とはいっても、そんなにたくさん聴いて確認したわけじゃないので、現時点での印象にすぎないのだけど。
これは何なんだろうと考えるうちに、日本のポップミュージックの録音は、生の声ではなく、コンサート会場のPAを通した歌声を再生しようとしてるんじゃないか、と思い付いた。いくらなんでもそんなことはないだろう、とは思うのだけど、、、でも、コンサート会場やカラオケルームでマイクを通した声が、リビングルームのコンポから鳴るように録音されているのだとしたら、「そうそう、そういう感じの音だよ」と納得がいくというか。
歌声が生の声として再生されるような録音になっていないと感じるのだ。若い人のJポップに限らない。ベテラン歌手の作品でもそういう音がするのが少なくない。必要ないエコー成分が多すぎたり、人の声はこんなガサ付き方しないだろという感じに聞こえたり。
日本のポップミュージックの特徴じゃないのか、と思う。そうした音が似合う音楽が作られているし、たぶん、そうした音楽を再生するのに適したコンポが作られている。
これは、一種の文化的なフィルターとして機能していると思う。
リアルな生の人の声が生きるポップミュージックは、日本ではほとんど作られていない。
僕は最近、リアルな人の声を聴きたいと感じる事が多くて、その結果、はまっているのがアメリカのフォークミュージックだ。ジョーンバエズとかピートシーガーとか、あのあたり。日本の音源で何かないかとなると、再生音に何か違和感を感じる。たぶん録音の、音の問題だと思うのだ。本当はこんな不自然な声じゃないはずだ、と感じることが多い。
現在流通してるハイレゾ、96kHz、192kHzといったレベルだと、そこまで気にならない、というか、気付かない。ラジオやテレビの人の声に違和感を感じないようなものかな。おそらくフォーマットによって違ってくるんだと思う。案外、アナログレコードがうけてるのは、この辺りに理由があるんじゃないかと思っている。受け皿に乗ってるデータが、相対的に上質なのだ。
PCMで700kHzまで上げると、何かしら、圧倒的な差が生じてしまう。まともな録音じゃないと、きびしいのだ。受け皿が大きい分、質の悪さも目立つというのかな。拡大鏡みたいなものなのかもしれない。良質な録音だと素晴らしいのだけど。
2020.05.13.追記。
現在、PPAP方式 768kHzで再生し始めて1か月ほどになるんだけど、1年前に感じていた違和感がなくなった。
違和感を感じていたはずの声が、違和感を感じ始める前よりもっと自然に耳に届いている。
ここに至って、ようやく気がついた。
あの違和感は、残存していたジッターが原因だったのだと思う。録音のせいなどではなかった。
しかし、検証しないといけない。
本当にジッターが原因なのか、どのような作用をしたのか、できれば確かめたい。
2020.10.18.遅まきながら追記。
できれば確かめたいと書いておいて、それっきりになってた。
実際のところ、検証できていると言い切れないけれど、関連エントリーということで記載しておく。
サンプリングパラメータによるジッターの影響の差異について
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200524a.htm
ジッター再々考
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200531a.htm
MQAは録音段階にも踏み込んだ処理を行う。そういう意味で、MQAには期待する部分があった。
しかし録音のクオリティは、MQAかどうかみたいなフォーマットの差異だけではカバーしきれない部分がむしろ大きいだろうと感じている。実際、昔から録音の善し悪しは千差万別だからね。
良質な録音にMQAの処理が加わると、さらなる音質向上が見込めないかと考えたり、MQAで700kHz台にとか将来的にはどうなのかと思ったりする。
しかし700kHz台のPCMは相当のクオリティで、上流再生レベルの受け皿としては、これでもう十分じゃないかと思わせるものがあるのだ。個人的感覚的な物言いで、実際どうなのか分からないけど。
受け皿が大きい分、録音自体がよいかどうか、丁寧に録られているかどうかがこれまで以上に重要になってくると思う。
録音に合わせた再生をどうするかも重要ということになるのかな、と思っている。
Jul 12, 2016
ハイレゾを作って再生してみる、など (追記:アップコンバートすることにした)
どこから書いたものか。
現在、うちのオーディオのメインシステムはpiCoreを使ったメモリ再生になっている。
volumio + NASの音も悪くないと思うんだけど、妻は音量を上げたらうるさいというのだ。まあ、それは認めるけどたいしたことないじゃんと思うのだけど、妻としては差が大きいらしい。メモリ再生だと音量を上げてもうるさくないという。確かに、僕もそう思う。
オーディオやってる僕よりも、実は妻のほうが音質にはうるさいのだ。僕はうるさくても案外平気で聴いていたりする。
同じファイルであっても、NASに置くか、RAM上に置くかで、大きな音質差が生じる。
つまり、44.1kHz/16bitの音源の扱いはそれほどデリケートだということだろう。
過去には、調子がよくないNASを良いものに替えることで、音質が改善した経験がある。
このときは、NASの交換に伴ってmpd.confの設定が変わってしまった。調子が悪いNASを使っていたときはアップサンプリングする設定の方が音がよかったのが、NASを交換したら、しない設定の方が音がよくなったのだ。
今回のメモリ再生の試みに関連して http://www.yung.jp/bony/?p=3595 こちらのサイトのオーナーyung氏が同様のことをコメントしている。つまり、mpdのアップサンプリングの設定をやめたというのだ。そのほうが音がいいと。
mpdのアップサンプリング設定をやめるとき、というのがあるようだ。
システムの状況が改善し、ジッターが充分に減ったときには、アップサンプリングしないほうが音がよくなる、ということらしい。
逆に、ジッターが多い状況だとアップサンプリングしたほうが良くなる場合がある。アップサンプリング自体がシステムに負担を強いることだし、アップサンプリング自体の品質がどの程度確保できるかもシステムによるので、やってみないと結果は分からない。
過去には、うちではMac miniからの光出力をDACに送る際に、Mac miniでアップサンプリングしていたことがある。
5mばかり光ケーブルを引っ張っていたのでジッターが多かったのだろう。
アップサンプリングすることで、かなり音質が改善した記憶がある。
あと、LANの受け手側のmpdでアップサンプリングしていたことがある。
前述したNASの調子が悪いときの話で、データの転送自体ですらシステムに大きな負担がかかっていた。ジッターが増えやすい環境だったのではないかと思う。そうした場合には、mpdによるアップサンプリングの品質が悪くても、しないよりマシで、したほうが音がよかった。
もっと昔、ニールヤングがリリースしたDVDのハイレゾ音源を、当時はPowerbook G4だったかで再生して、CDと比べて音がいいことに驚いたことがある。もしかしたら元々ミキシングが違うのかもしれないが。ずいぶんクリアになるんだな、と当時は思った。ミキシングが違うからという印象ではなかったのだけど。
そこでタイトルに戻るのだけど、ハイレゾだ。
ファイルをアップサンプリングして再生するということは、ハイレゾを再生するということだ。
アップサンプリングして送信するということは、ハイレゾを送信するということだし、アップサンプリングするということはハイレゾ化するということだろう。
CDからのリッピングファイルをアップサンプリングしただけのファイルやデータなんてニセレゾじゃないかという話があるが、僕はいろいろ考えては見たんだけど、まあ、それもハイレゾだろう、という結論に達した。
問題になるのは売り方だ。
ニセレゾというのは、売り方の問題に関わる言葉だ。
それとハイレゾファイルって実際どうなのか、という問題は別だ。
ここまでの話の流れから、ここで言いたいことは自明だろう。
ハイレゾ再生というのは、ジッターが多い環境での音質対策なのだと思っている。
ジッターが少ない環境なら、理論的に44.1kHz/16bitで充分なのだと思う。
ジッターが多い環境になると理論どおりのDA変換とはいかないので、44.1kHz/16bitの音楽再生だと音質劣化が無視できなくなるんだと思う。
話は単純で、サンプリング周波数が多くなったら単位時間当たりのサンプルが増えるので、DA変換に際してのジッターの影響による誤差が相対的に少なくなるのだろうと考えている。
得られる音質改善は対症療法的なものだ。
デジタル音源再生の音質改善の本質はジッター低減だと思うのだが、コンシューマーが取り組むには限界がある。というか、そもそもコンシューマーはジッターについて考えたりなんかしない。mp3で大音量のほうがいいのである。RAMに可逆圧縮ファイルを取り込んだりなんかしないのだ。
思うんだけどハイレゾ音源の利用というのは、もともとコンシューマー向きの再生形態でハイエンドオーディオ向きではないと思う。
ハイエンドコンポであればジッター対策もそこそこ施されているはずだから、恩恵が少ないのではないか。
むしろコンシューマー向きのジッター対策していないオーディオセットでこそ、CDとハイレゾの差がはっきり出るんじゃないかと思うし、コンシューマーは難しいことは考えずにハイレゾ使ったら音がいいねで済んじゃうほうが望ましい。ジッターが少なかったらCDで充分なんて薀蓄はコンシューマーには似合わないし、コンシューマー用の機器ではそもそもジッター対策は打ちにくい。
いや、違うかな、、、
家電店とかでコンシューマー向きのミニコンポとかの音を聴く機会があるけれど、なんというか厚化粧で、これならどんなCDでもおんなじように鳴るだろうな、という印象を受けることがある。あらを隠すことには大成功してるという感じ。これも技術的なノウハウがあるのだろう。
CDとハイレゾの区別は付かないかもしれない。
だとしたらハイレゾの恩恵を受ける層はいないってことになるのかな、、、
話がそれた。
ここで取り上げるのは、CD音源の44.1kHz/16bitのファイルを192kHz/24bitに変換して、メモリ再生したらどう聴こえるだろうかということだ。
ジッター対策を多少なりとも行った環境(メモリ再生環境とはそういうものだと僕は理解している)でハイレゾに意味があるのかということ。
これで意味があるなら、ハイエンドオーディオでもハイレゾに意味があるだろう。
変換に使ったソフトは以下のサイトから落とした。
TASCAM Hi-Res Editor
https://tascam.jp/jp/product/hi-res_editor/top
使った音源は、Pierre Boulez の the Complete Columbia Album Collection というボックスセットから、CD40 Bartok / The Wooden Prince の一曲目、「Introduction」。CDをリッピングして作ってあった 44.1kHz/16bit flacからwav を作成、これを、TASCAM Hi-Res Editorを使って、192kHz/24bit wav を作成した。これを xrecode II を使ってflacにする。
つまり4種類のファイルができる。
ふだん使っているのはflacだが今回は敢えてwavも聴いてみる。
ファイルを作った直後に Compaq 6710b / foobar2000 で再生してiPodのおまけだったイヤホンで聞き比べたら、なんとなく違うような気がする。自作ハイレゾファイルのほうが、いいんじゃないかな。
次に、NASにコピーして、そこからのデータを再生。Compaq 6730b / mpd でイヤホンで聴いてみた。これは、区別が付かない。区別が付かない上に、どうも明らかに精彩を欠く。NASから物理的にもかなり遠いというのもあるのだろうか。しかし、それだけ聴いていたら、それほど音が悪いとも思わないんだけど。比較してしまうと差が明瞭になってしまう。
7月15日、追記。
気を取り直して再度、NASからの音をイヤホンで聴いてみたら、若干だが自作ハイレゾファイルのほうが滑らかで繊細なニュアンスが伝わる音がするようだ。最初に聴いたときは落差に驚いて判別不能に至ったようだ。
訂正しておく。
piCoreでメモリ再生してみる。メインシステムでスピーカーからの音だ。
結果から言えば、わずかだが違う。
ジッターの影響が少なくなれば区別が付かなくなる、という想定だったのだけど、違いはメモリ再生でも聴き取れるように思う。
Ras piなんて使ってるからそんなもんだろと言われても他と比較する術はないが。
192kHz/24bitのほうが繊細でグラデーションが細やかな鳴り方だ。44.1kHz/16bitは勢いがあるけど、やや荒い。ロックには良いだろうけど。ロックは昔からノイジーな音楽で、若者はそのほうが共感できることがある。
困った。自作ハイレゾの方がオーディオ的には音がいい。
というか、CDをリッピングしたファイルから作ったハイレゾでも、ハイレゾとして機能するんじゃないのかな?
何が困るって、CD1枚をリッピングしたflac(うちのライブラリの基本はそれだ)からハイレゾファイルを作って再生するとしたらファイルのサイズがバカにならない。Ras pi 2 のメモリ1GBではとうてい足りない。Ras pi の何がいいって、i2sデバイスが簡単に設定できるところなのだけど、数GB以上のメモリを積んだ他のボードPCを利用するとなると、i2sの工作が大変だ。ソフトウェアの設定も、Ras pi のように簡単にはいかないはずだ。
となると、usb出力を使うことになる。
うちには使えそうなusbデバイスがないのだ。何か探すということになる。
しかし現状で鳴っている音を聞くと、、そこまでするニーズって、僕の中にあるの?と思ってしまう。
他の手段としては、Ras pi 2 に他のメモリを追加して使うとか。usbメモリを刺して、musicディレクトリにマウントしてしまえば数GB以上の空間として使える。若干システムの負担になるのがデメリットだけど、LAN経由でNASを繋ぐほどじゃないはずだ。
というか、ハイレゾ変換ファイルusbメモリ再生をするつもりなんだろうか僕は。
日常的な使用という意味では、メモリ再生以上にハードルが高い。音源を格納したusbメモリを再生出来るネットプレーヤーなどという製品が巷では販売されているのだし、もしかしたらそっちのほうが有望な選択肢なんて事になるやもしれない。
などと考えながら、購入した正規のハイレゾファイルのメモリ再生などしていると、必ずしもハイレゾの方がいい感じに鳴るとばかりは言えないように思えてきた。Waltz for Debbyは、CDからリップした44.1kHz/16bit flacのほうがなんだかいい感じなのだ。HDTracksから購入した96kHz/24bitのファイルがあるんだけど、どうも良くない。ぼんやりしている。以前からハイレゾってこんなかな?ソフトな音だよねと思ってたんだけど、明確になってしまった感じだ。
理由は、おそらくはマスターの劣化によるものだ。
ハイレゾのマスターは、米コンコード社でオリジナル・アナログ・テープより変換された2010年192kHz/24bitリマスターを基にしたDSDマスターが使用されているとか。対して、CDのほうは1997年のもので、アナログマスターテープに20bit K2スーパーコーディングを用いたHQCDだ。
10年以上の時間による経年劣化が、音に反映されているのではないか。
もうひとつ音源を所持していて、Complete Village Vanguard Recordings 1961(日本盤)というもの。これは2002年にデジタル・リマスタリングされたらしく、どうもベースの音が太い。別ものだ。
調べてみたら、Waltz for Debbyという音源はいろいろあって一筋縄に行かないらしい。
こうなると、古い音源が欲しくなる。
これ以上ここに書くと話がとっちらかるので止める。
さて。
ras pi2 + piCore7 は、usbメモリを刺したら自動的に認識してくれる仕様になっているようだ。
tc@box:~$ fdisk -l Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes 3 heads, 8 sectors/track, 322688 cylinders Units = cylinders of 24 * 512 = 12288 bytes Device Boot Start End Blocks Id System /dev/mmcblk0p1 342 2902 30720 c Win95 FAT32 (LBA) /dev/mmcblk0p2 2903 322688 3837432 83 Linux Disk /dev/sda: 8054 MB, 8054112256 bytes 49 heads, 29 sectors/track, 11070 cylinders Units = cylinders of 1421 * 512 = 727552 bytes Device Boot Start End Blocks Id System /dev/sda1 1 11071 7865328 b Win95 FAT32 tc@box:~$ mkdir music/usb tc@box:~$ sudo mount -t vfat /dev/sda1 music/usb
上記コマンドでマウントポイントusbにsda1をマウントできる。
しかし、理由はよくわからないのだけど、これでmusic/usbmに音楽ファイルをsftpで転送出来るのかというと、うまくいかない。権限の問題じゃないかと考えたりしたのだけど、解決できなかった。
しかたないので、以下のようなコマンドでNASの音楽ディレクトリもマウントして、そこからsshでコマンドを打って音楽ファイルをコピーすることにした。
tc@box:~$ mkdir titan tc@box:~$ sudo mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /home/tc/titan
しかし、これもうまくいかない。
というのは、せっかくマウントしたusbメモリをメモリとして使ってくれないようなのだ。
piCoreはどうも、メモリが必要となるとまずはRAM、その次にmicroSDカードを使うように設定されているようで、マウントされてるusbメモリは目もくれず、まずRAMにデータを蓄積し、足りないとmicroSDカードにデータを蓄積していく。数GBのデータをマウントしたusbメモリに転送したつもりが、アンマウントして確認したら空っぽだった。
これでは音を出してもどこにあるデータを再生しているのかわからない。
つまり、usbメモリからの音を聴きたければ、あらかじめデータをusbメモリにコピーしてから刺さないといけない、ということだ。
解決法もあるのかもしれないが、発見できなかった。それでも、音が出るだけ御の字だ。
そんなこんなで、usbメモリに書き込んだファイルとLAN経由の音を比較してみる。音源はMiles DavisのSorcerer。
多少、usbのほうがいい感じ。細かいニュアンスがでるしアタック音のきつさが自然になる。
usbメモリに書き込んだファイルと、RAMに置いた音を比較してみる。、、若干、RAMのほうがいいかな。細かいニュアンスが出ている。比べたらusbのほうが荒々しい。
usbメモリを抜いたら、また変わるのかもしれないけど、ちょっと根気や記憶力が続かなくて比較できないと思う。
一応、音質の比較は LAN < usbメモリ < RAM、ということになった。
しかし、usbとRAMとの音質差はわずかで、激しい音楽の場合はusbでもいいんじゃないかな、という感じだ。
usbメモリにハイレゾ化したファイルを置くようにしたらRAMの不足を補えるかと思ったけど、どうも改善と悪化が打ち消しあってチャラになりそうな予感がする。
RAM再生で比較したら差を聴きとれた Boulez の Bartok / The Wooden Prince 「Introduction」を再生してみる。
RAMにCDからリップした44.1/16のflac、usbにそのファイルから作った自作ハイレゾ192/24のflac。
区別が付かない。
そう思いこんでるからかどうかわからないが、実際区別が付かない。残念だけど、usbメモリを自作ハイレゾの貯蔵庫にというアイディアはどうも無駄ばかり多いということになりそうだ。自作ハイレゾを本気で使う気ならメモリを数GB以上積んだマシンで取り組むべきなんだろう。
もしもusbメモリを貯蔵庫に使えるようなら色々と便利になるだろうにと思っていたんだけど、残念だった。今回はここまで。
7月19日、追記。
ふと思い立って、アップコンバートを試みることにした。
Raspberry pi B+ではとうてい無理だと思っていたんだけど、Ras pi2だったらメモリもCPUも強化されているし、出来るのではないか。
mpdの設定で、量子化ビット数はCDと同じ16のまま、サンプリング周波数を上げることにする。
libsamplerateは、tczが用意されているので、以下のコマンドでインストールできる。
tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz
mpdを再インストールして、.mpdconfを編集する。
サンプリング周波数192kHzでは、Medium Sinc Interpolatorではノイズ、音跳びでうまくいかなかった。
サンプリング周波数176.4kHzだったら、Medium Sinc Interpolatorで再生出来る。
音質は今までで最高だと思う。