Bit Perfectにおけるリサンプル処理について

フォーラム TuneBrowser Bit Perfectにおけるリサンプル処理について

このトピックには9件の返信が含まれ、3人の参加者がいます。6 日と 4 時間前 Tiki さんが最後の更新を行いました。

10件の投稿を表示中 - 1 - 10件目 (全10件中)
  • 投稿者
    投稿
  • #1671

    yubei
    参加者

    Tikiさま、以前メールでは何度かやり取りさせていただきましたが、Forum初投稿です。

    件名についてですが、私もTikiさんのBit Perfectに対する考え方には同意です。Bit拡張を前提にすれば、オーバーサンプリングを全てDACに任せるのか、予めPCで行っておくのか等について、むしろユーザーの選択肢(柔軟性)が増したと考えれば良いのだと思います。

    最近ではBP1(ほどほど)とBase×4のリサンプリングを常用していたのですが、拙のDAC環境(Amlech AL-38432DS)で、WASAPI再生においてBit Perfectを設定すると、Deviceへの出力bit幅が16bitになってしまうことに気付きました。WASAPI再生でもBit Perfectでは無い場合や、ASIO再生でのBit PerfectではDevice仕様の32bitで出力されます。
    WASAPI再生 ASIO

    リサンプル処理は32bitで行わているとのことなので、この時点ではリサンプリング演算に誤差はないのですが、出力時に下位16bitをカットされれば、リサンプリング演算結果に対してBit Perfectで無くなってしまいます。(1サンプル間の10進数データの差が奇数ならば、10進数で最大0.5相当の誤差が生じる?)

    非逓倍リサンプリングについても厳密に言えばBit Perfectでは無いのかもしれませんが、「Bit拡張後のリサンプリング演算結果の出力はBit Perfectとみなす」という前提であっても、出力時に下位16bitをカットされれば、それこそBit Perfectにはならないのではないかと。

    これは、各ユーザーの環境に起因するものなのでしょうが、Deviceへ渡すBit幅が音源Bit幅に対して拡張されていない場合にTuneBrowserがそれを認識できるのであれば、その場合にはリサンプリング処理が有効設定であってもリサンプル処理を無効(TuneBrowser的には半点灯表示?)にする方が、誤解を招かず、Tikiさんの考え方にも合致するように考えますが如何でしょうか。

    #1676

    yubei
    参加者

    補足です。
    「10進数で最大0.5相当の誤差が生じる」とは限りませんね。(^^;
    下表は4倍リサンプリングの場合のサンプルです。(自分の頭を整理するために表にしてみました)
    サンプル計算
    下位16bitカットの場合、僅かですが誤差が出てしまいます。
    この程度で、音に(聴覚上の)差が出るとは思えませんが、あくまでもTuneBrowserにおけるBit Perfectの定義を確認しておきたかったので…。細かくてすみません。

    では。

    #1678

    hiro
    参加者

    みなさん。こんばんは。

    bit perfect に関する技術的な事は良く判りませんが、僅かに差が出るとの事ですが。

    私の環境では、TBのBP無、BP1、BP2の設定で音はかなり変わります。

    BP無 → BP1 → BP2 と変えると奥行きが出て音量も大きいように感じます。

    この要因はどこから来るんでしょうか??

    DAC:TEAC UD-501

    TB:4.2.4 UWP版

    RESAMPLE:88.2K以上はしない。192KにRESAMPLE。

     

     

     

     

    #1700

    Tiki
    キーマスター

    こんばんわ、

    たしかにリサンプル処理を32bitでやっておいて、出力時に(元の形式が16ビットだから?)16ビットというのはちょっとおかしいような気がしますね…。ちょっといま慌ただしく、すぐにはとはいかないのですが、近日改めて動作を確認したいと思います。

    取り急ぎ。

    #1737

    Tiki
    キーマスター

    yubeiさん、こんにちわ。

    現在のTuneBrowserの動作を確認しました。現在は、Resamplerの32bit演算はあくまでも途中経過として扱っていて、16bit Source -> 32bit Resample -> 16bit Result ということなっています。これはyubeiさんご認識の通りだと思います。

    そこでResamplerの結果の扱いを変えて、16bit Source -> 32bit Resample -> 32bit Result と変えてみたのところ、べつの課題が出てきました。

    ASIOとちがい、WASAPIの場合、ソフト側から再生スペックを指定します。44.1kHz/16bitのソースに対してBase x2の設定で手許のRealtekで試してみたところ、本来は88.2kHz/32bitで再生したいところが、対応しているサンプルレートに限りがある(88.2kHzに対応していない)ため、

    1. 16bit Resultの場合 : 96kHz/16bit 再生
    2. 32bit Resultの場合 : 48kHz/32bit 再生

    となりました(自分で作ったソフトに対して「なりました」というのも変ですが)。

    これは、再生処理側としては、目的のサンプルレートで再生できない場合、bit深度を維持しつつできるだけ目標サンプルレート(88.2kHz)より高いサンプルレートでの再生を目指した結果で、今回のRealtekは16bitでは96kHz、32bitでは48kHzまでしか再生できなかったという結果になります。

    わたしももうすこし考えますが、ちょっと面倒なことになっています。元が16bit Sourceだということも考慮した上で、ちなみに上記の1.2.ではどちらが良いですか?(^^;

    なおこれは、デバイスが88.2kHzの再生に対応していなかった故であり、一定の機能以上のDACであれば、88.2kHzも再生できると思うので、このような問題は発生しません。

    #1738

    Tiki
    キーマスター

    hiroさん、こんにちわ。

    音量に明確な差が出ているとしたら、BitPerfectでないときに、ReplayGainとかボリュームとか、そのあたりの設定が有効になっているのかもしれません。

    #1740

    yubei
    参加者

    Tikiさま、休日にもかかわらず対応ありがとうございます。

    > ASIOとちがい、WASAPIの場合、ソフト側から再生スペックを指定します。

    たしかに foobar2k はDeviceでWASAPIを選択した場合、outputビット深度指定がありました。

    > 元が16bit Sourceだということも考慮した上で、ちなみに上記の1.2.ではどちらが良いですか?(^^;

    リサンプリングを許容するという前提に立った「Bit Perfect」であるならば、有意な(0000 0000 0000 0000では無い)データのビット落ちを回避することの方が(私的には)腹落ちします。ソースと同じビットで出力するならば、(Ditherを出す側でやりたいというような)意図がない限り、後はオーバーサンプリングをDACに任せるだけってことで良いのではないかと思っています。

    なので1番か2番か? ということであれば2番に1票。(^^)

    では。

    #1745

    Tiki
    キーマスター

    先ほど、この件を対応した先行版を更新しました。

    またお試しいただければ幸いです。

    #1749

    yubei
    参加者

    Tikiさま

    バージョンアップありがとうございました。
    16bit/44100Hz、16bit/48000Hz、24bit/48000Hz、24bit/88200Hz、24bit/96000Hz、24bit/176400Hz、24bit/192000Hz ファイルの全てにおいて、リサンプリング後の出力良好(32bit出力)です。

    これで、心おきなくBP設定を利用できます。(^^)
    ありがとうございました。

    では。

    #1754

    Tiki
    キーマスター

    ご確認いただき、ありがとうございました。

    いったん、これで行ってみましょう。

10件の投稿を表示中 - 1 - 10件目 (全10件中)

このトピックに返信するにはログインが必要です。