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

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

このトピックには15件の返信が含まれ、3人の参加者がいます。7 ヶ月、 1 週前 Tiki さんが最後の更新を行いました。

16件の投稿を表示中 - 1 - 16件目 (全16件中)
  • 投稿者
    投稿
  • #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
    キーマスター

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

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

    #1908

    yubei
    参加者

    Tikiさま、2点ほど質問です。

    【1点目】
    非BP時に音量(Vol)スライダをマイナス(減衰)設定している状態でBP設定にするとVolスライダはゼロ固定に戻り操作も出来ず、非BPに戻すとVolスライダは前回設定に戻ります。(想定どおりです)
    次に、非BP時に全体ゲイン設定をマイナス(減衰)設定している状態でBP設定にすると全体ゲインインジケータは半点灯となり、切り替え操作も出来ませんが、音量自体は全体ゲインによる減衰が効いたままです。(これってBit Perfectではない?)これは意図されたものなのでしょうか? それとも本来はVolスライダと同様に、インジケータ半点灯で実際のゲイン0dB(×1.0)」とするか「インジケータ消灯してゲイン0dB(×1.0)」なのでしょうか?

    【2点目】
    BP設定時は「元の楽曲のビット深度にかかわらず32bitとして扱う」とのことですが、仮に16bitまたは24bitまでしか対応していないDACの場合はどうなりますでしょうか?(といいつつ私がそういうDACを持っている訳ではありませんが…)

    困ったことでは無いので、お時間が空いた時にでも御教示ください。
    では。

    #1910

    Tiki
    キーマスター

    こんばんわ。

    【1点目】

    全体ゲインは、「デコーダに設定」の設定でご利用でしょうか? (というか、いまはそれが既定の設定になっていますが…)。

    だとすると、たしかにご指摘の通り、デコーダに設定するゲインにはBitPerfectの設定反映が漏れていました。これは、次のリリースで修正したいと思います。

    【2点目】

    デバイスのビット深度がデコード結果よりも小さい場合は、デバイスバッファに転送する際に、デバイスのビット幅に合わせて下位ビットを切り捨てて引き渡すようにしています。

    よろしくお願いします。

    #1915

    yubei
    参加者

    Tikiさま、早々の御回答ありがとうございます。

    >【1点目】
    >全体ゲインは、「デコーダに設定」の設定でご利用でしょうか?

    すみません、説明不足でした。「デコーダに設定」の場合のみの事象です。

    >【2点目】
    >デバイスのビット深度がデコード結果よりも小さい場合は、デバイスバッファに転送する際に、
    >デバイスのビット幅に合わせて下位ビットを切り捨てて引き渡すようにしています。

    やはり、そうなりますよね。了解です。

    #2012

    Tiki
    キーマスター

    こんにちわ。

    先ほど公開した4.3.1の先行版で、「デコーダに設定」時の全体ゲインの問題に対処しています。よろしければご確認いただけると助かります。

    よろしくお願いします。

    #2013

    yubei
    参加者

    Tikiさま

    4.3.1先行版で、「デコーダに設定」で全体ゲインを設定していた場合でも、BP設定にすればゲインが掛からないことが確認できました。対応ありがとうございました。

    #2014

    Tiki
    キーマスター

    こんばんわ。

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

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

トピック「Bit Perfectにおけるリサンプル処理について」への新規返信追加は締め切られています。