abk1's scratched blog 3::AUDIO DIARY

前のエントリーに追記で、アップコンバートについてちらっと書いた。
Ras piからRas pi2にハードの性能が上がったので出来るんじゃないかと思ってのことだけど、こんなに変わっていいのか？と思うほどだ。
理屈で言えばハイレゾファイルを再生するのと同じじゃないかと思うけど、ずっといいような気がする。ここまでいいのは怪しいんじゃないか、という気持ちにすらなる。

僕が考えるアップコンバートの効果というのは、ジッターが多い環境でより多く得られるということなので、うちの環境はジッターが多いのかなということになるけど、そこは保留して、ちょっとmpdによるアップコンバートについて考えてみようと思った。

mpdでは、アップコンバートに際してlibsamplerateの使用を推奨している。
piCoreではlibsamplerateがtczで用意されていて、下記のコマンドで簡単にインストールできる。
tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz

これがインストールされていない環境でのアップサンプリングは、低品質ということらしい。
低品質とは、どういうことなのか。
libsamplerateによる高品質なアップサンプリングと比べてどう違うのか。

libsamplerateのサイトは以下。
http://www.mega-nerd.com/SRC/index.html

同サイトのSRC Qualityのページ。
http://www.mega-nerd.com/SRC/quality.html
API（Applications Programming Interface）のページ。
http://www.mega-nerd.com/SRC/api.html
Converterについて、Miscellaneous API Documentationのページ。
http://www.mega-nerd.com/SRC/api_misc.html#Converters

まず、SRC Qualityから引用。

Signal-to-Noise Ratio - a measure of how much noise the sample rate conversion process adds to the signal. This is measured in decibels (dB) and the higher this value the better. For most sample rate converters, the SNR will vary depending on the input signal and the ratio between input and output sample rates. The only valid comparison of SNR is between the worst case for for each converter.

Bandwidth - most sample rate converters attenuate high frequencies as part of their operation. Bandwidth can be measured by finding the frequency where the attenuation is 3dB and expressing that as a percentage of the full bandwidth at that sampling rate.

Speed - the faster the better :-).

難しい。ＳＮ比とスピードはなんとなく分かるけど、帯域幅（Bandwidth）って何なのだ。
「ほとんどのサンプルレートコンバーターはそれらの操作に伴って高周波を弱める。」という。
さらに訳してみる。
「帯域幅は、減衰が3dBである帯域を見つけて、サンプリングレートを全帯域幅として、それに対するパーセンテージ表示で測定値とする」という感じだろうか。どういうことだろう、、、

It should be noted that the first three converters above are based on the algorithm by Julius O. Smith which emulates the conversion of the digital signal to an analogue one and then sampling the analogue signal at the new sample rate.

次の引用は、いくつかのサンプルレートコンバータソフトに関しての言及。
訳してみる。
「ここで特記すべきことは、上の３つのコンバーターの基本はジュリアス O.スミスのアルゴリズムに基づいていることで、それがエミュレートするのは、デジタル信号をアナログ信号に変換し、そのアナログ信号を新しいサンプルレートでサンプリングする、という動作である」
つまりDA-AD変換をエミュレートするということか。

ちなみにここで上げられている３つのコンバーターとは、sndfile-resample、Resample、ResampAudioの３つである。
SoX、Shibatch(SSRC)、sr-convertも紹介されているが、これらは他のアルゴリズムということらしい。

次にMiscellaneous API Documentationから引用。

The details of these converters are as follows:

• SRC_SINC_BEST_QUALITY -
  This is a bandlimited interpolator derived from the mathematical sinc function and this is the highest quality sinc based converter, providing a worst case Signal-to-Noise Ratio (SNR) of 97 decibels (dB) at a bandwidth of 97%.
  All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.
• SRC_SINC_MEDIUM_QUALITY -
  This is another bandlimited interpolator much like the previous one. It has an SNR of 97dB and a bandwidth of 90%.
  The speed of the conversion is much faster than the previous one.
• SRC_SINC_FASTEST -
  This is the fastest bandlimited interpolator and has an SNR of 97dB and a bandwidth of 80%.
• SRC_ZERO_ORDER_HOLD -
  A Zero Order Hold converter (interpolated value is equal to the last value). The quality is poor but the conversion speed is blindlingly fast.
• SRC_LINEAR -
  A linear converter. Again the quality is poor, but the conversion speed is blindingly fast.

見覚えがある内容だ。
mpd.confの、audio_output_formatの設定だ。このサイトでも以前に取り上げたことがある。
http://blown-lei.org/endive/blosxom.cgi/audio_diary/20140709a.htm
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20140709a.htm

SRC_SINC_*はSNRは全て97dB、bandwidthは97%、90%、80%と差がある。

「All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.」、訳すと「３つのSRC_SINC_*コンバーターは全てジュリアス O.スミスの技術に拠るものだが、そのコードは独自に開発されたものである」という感じか。

Julius O. Smith氏のサイトと思われるのが以下。
https://ccrma.stanford.edu/~jos/resample/

ZERO_ORDER_HOLDというのはwikipediaにあったり。読んでも僕には意味が分からない。
https://en.wikipedia.org/wiki/Zero-order_hold

ネット上を調べるうちに一目で分かる解説を見つけた。
直線補間アップサンプル（linear converter）も載っている。
http://community.phileweb.com/mypage/entry/2721/20151205/49583/

linearというのは本当にlinearなんだなあ、という感じだ。サンプル数が増える以外のメリットはなさそう。これで音質改善するというのは余程の場合だろうなあ、、、
ZOHは、linearに比べたらマシなの？、という感じ。

さて、どういうことか考えてみる。

まず、libsamplerate + mpdによる上位３つのリサンプリング方式はジュリアス O.スミス氏のアルゴリズムに基づいて行われていて、デジタルデータから元のアナログ波形を計算し、その波形のリサンプリングをエミュレートすることで新たなデジタル信号を作り出すということ。
一連の処理をするのに相応のPCパワーが必要だが、Ras pi2でもpiCoreで絞り込めば何とかなる。

PCのパワーがいらないアップサンプリングは元のアナログ波形を想定していない、ということなんだろう。それは前述のリンク先の画像からも明らかだ。
ちょっとそれでいいのかと思ったりするが、実際に過去の経験からは、それでも音質改善に繋がる場合があるというのはあるので、どうなってるんだろうとは思う。
一般的なDACチップで行われているアップコンバートでどのようなことが行われているのか以前から気になってはいたが、ここにきてやっぱり気になるという感じだ。

良質なリサンプリングとされている方式がDA変換をエミュレートするというのは考えさせられるところがある。
以前ネット上で、ハイレゾを作るのにアナログ変換を途中にはさむのはニセレゾじゃないかという議論があった。しかし、良質なリサンプリングはアナログ変換をエミュレートするのだ。
デジタル上のエミュレートで行われることと実際にアナログにするのは全く違うじゃないかって？まあ、そうなんだけどさ。

それから、リサンプリングの過程で高域の情報が失われるらしいこと。「帯域幅（Bandwidth）」という指標で計測され、libsamplerateでは上位の３段階でクオリティを選べること。

この時点でバイナリ一致とか気にすることが無意味になってきている。
リサンプリングでデータが変わる時点でバイナリ一致はないのだけど、アップコンバートした後でダウンコンバートしたら元に戻るのかな、というような曖昧な認識でいたのが違うのだということが分かった。このあたりは、ちょっと認識を改めないといけない。
（分からないのは、デジタルエミュレーションなのに何で高域が減衰するんだろうってこと、、、）

しかし、高域が減衰するといっても「SRC_SINC_FASTEST」でもbandwidthは80%であり、サンプリング周波数を仮に192kHzとしたら、3dB減衰するのは、、、
192 x 0.8 = 153.6(kHz)、、こんな計算でいいんだろうか。
これで可聴領域にどの程度の影響があるのか、はっきりしない。
もしかしたら、bandwidthは90%でもPCのパワーを必要とする「SRC_SINC_MEDIUM_QUALITY」より、bandwidthが80%でも負担が少ない「SRC_SINC_FASTEST」のほうが音がよくなる可能性もあるのではないか。

というか、その良くなってる音って何よってことになる。
つまり、もとのデジタルデータから引き出された音と言っていいのか、作った音じゃないのか、ということだ。

最近、注目されてる音楽フォーマット形式でMQAというのがあるそうなんだけど、従来の音楽ファイルよりも時間的な情報を重視していて音はいいらしい。これが実はバイナリ一致じゃないらしい？という話がある。バイナリ一致じゃないなら正確じゃないとは言えるけど、時間的情報が従来よりもきちんと再生されるなら、そのほうが正確な再生じゃないかとも思える。

ここらは考えだしたらきりがない。自分のスタンスを決めてやっていくしかないのだろう。

さて、音だ。
mpd.confの設定を変えて実際にどんな音になるのか聴いてみよう、と思ったところで息切れした。今後、余裕があったら比べることにする。

とりあえず気が付いたのは、アップサンプリングするならmpd.confのaudio_buffer_sizeの数値を上げる必要があるということ。
この数値が低いと、精彩を欠く音になる。
数値を上げすぎると音が出るまで時間がかかる。
Best Sinc Interpolatorの設定にしたら、88.2/16ですら音切れが起きる。これはRas pi2の限界だろう。

過去の経験では、アップサンプリングしないなら、audio_buffer_sizeはむしろ再生に不具合を生じない範囲で下げたほうが好ましいという印象があった。これはシステムにできるだけ負担をかけない再生ということなんだろうと思っていた。
これに対してアップサンプリングはシステムにより大きな負担を強いる方法で、audio_buffer_sizeを上げること自体はシステムへの負担増加になるとはいえ、アップサンプリングという更なる大きな負担への耐性をシステムが確保するためには、敢えてそうする必要がある、ということなんだろうと考えた。

そこでさっそくの番狂わせが、アップサンプリングなしの状態でも、audio_buffer_sizeが大きいほうが音がいいかもしれない、ということ。過去の経験は何だったのかという感じだ。
過去においては、NASに置いた音源での比較試聴だった。現在はRAMに音源を置いている。それが影響していたのかどうか。それとも他の条件が影響していたのか。今後、余裕があるときに考える。

しかしアップサンプリングなしの設定も含めていろいろ聴かないといけなくなった。なかなか大変だ。
当初は総当たり戦で比較視聴する気でいたが、比較する設定が増えすぎなので考え直さないといけない。

とりあえず今は、
samplerate_converter "Medium Sinc Interpolator"
audio_buffer_size "4096"
audio_output_format "176400:16:2"
buffer_before_play "25%"
という設定で鳴らしている。