AACなどのクリップ検出のすすめ

sakuさん、こんばんわ。

Tikiです。

あー、見てしまいましたか(^^;。しかもそれを「すすめ」ますか(^^;;;。

とくに音圧の高い系の音楽などは、クリップすることも含めて音作りをされているような感じもするので(すいません音楽制作は詳しくはないのですが)、個人的には、それを視覚的に見えるようにしても、あまり精神衛生上いいことはないのかなと思っていました。

似た例では、ビットパーフェクトを「ほどほど」にしているときには、フェード操作が効きます。ボリュームバーの色を、そのフェード中の200msの間だけ(ビットパーフェクトではなくなるので)オレンジにするように設定することもできるのですが、作ってみたあとで、再生の開始/停止時に一瞬オレンジになるのを目撃しても気ぜわしいだけで何のメリットもないな、と思い、標準設定からは外しました。

自分の思っている設定で鳴っているかどうかを確認できるようにするのはとても大切なことですが、それが確認できたら、あとは細かいことは気にせず(^^;、楽しむのが良いような気がします。

それから、全体ゲインを-3dBにした場合ですが、例示していただいたスクリーンショットに現れているように、現在のTuneBrowserは、ゲインを設定した状態でもクリップは発生し、検出します。聴感上すこし良く感じられたのは、ビット幅としてほぼデバイスの限界値に近いところで鳴っていたものが、余裕を持ったレンジで鳴るようになったからではないかと推測します。私も、日常は-3dB下げて、ReplayGainなどが効く範囲を広くとり、すこし余裕のある範囲で聴いています。

こんばんわ、Tikiです。

もし、お気になるようでしたら、タイトル修正などお願いいたします。

いえ 大丈夫です(たぶん(^^;)。

TuneBrowserのクリップ検出とゲイン(ボリューム)の関係について、きちんとご説明したほうが良いですね。

まずTuneBrowserでのクリップは、32bit float形式のデータで1より大きい(-1より小さい)値を言っています。現在、この形式でデコードしているのはAACとMP3です。

デコード時にこのデータを検出すると、時刻とともにそれを記録します。GUIのほうは、その情報を使って、ピークメータを赤く表示します.

いっぽう再生用のデータのほうは、デコード後、すべていちど32bit整数に変換します. 16bitも24bitも32bit floatもすべてです. そしてある一定のブロックごとにまとめ、必要に応じてリサンプリング処理を行い, デバイス転送待ちのバッファに投入します.

デバイスへの転送は、デバイス側のタイミングに合わせて行います. 上で用意したバッファからブロックを取り出し, ここで 1. 全体ゲイン, 2. デバイス毎のプリアンプ, 3. ボリューム, 4. フェード, 5.リプレイゲイン の5つのボリューム要素のうち、ひとつでも設定する必要があれば時系列に変化させながら演算し、デバイスの要求するビット幅に合わせてバッファへ設定します.

以上の動作からおわかりになるかと思いますが、全体ゲインを演算するときには、すでに32bit整数に正規化されているため、現在の動作では, 残念ながらクリップした情報はその前に失われてしまっていることになります.

ゲイン/ボリュームの制御をデバイスに引き渡す直前に行っているのは, バッファに入れるまえだと, どうしてもディレイが発生し, ボリューム類の操作がとても気持ち悪いものになってしまうためです.

このあたりの処理は以前から悩みどころのひとつで, いまもときどき, この処理を眺めてはもう一歩手を入れるべきか思い巡ったりしています (改善したらいいやんか、という話かもしれませんが、このあたりの処理に手を入れると、期間がかかるのと、プチノイズ系のような捕捉の難しい不具合を出してしまったりするので、どうしても慎重になります).

方法としては、ゲインを下げて音量上げるのね、と思い(AAC以外の)FLACで[-6dB]にして聴いてみました。

ゲインをすこし下げたほうがよいかも、というのは、あくまでも推測です (使い勝手は確実に良くなります). いろいろ試してみてくださいね (^^)

こんばんわ、Tikiです。

1.正規化されたデータを、32bit intから64bit floatに変えてみる

これは、わたしも考えたことがあるのですが、一方で、できるだけビットパーフェクトの状態を維持したいという考えもあって、float型の導入は現在はあまり考えていません。

64bit floatとおっしゃっているのは、仮数部が32bit以上(52bit)あるので、32bit整数相当の精度は格納できるから、というご配慮と拝察しますが、ここはやはり、ビットシフト以外の演算は行わないようにして、オーディオ用ソフトとしての処理の透明性は確保しておきたいと思っています (これまで何度か、TuneBrowserの音質に関連して、この内部でのデータの取扱いについていろいろと疑義のご連絡をいただいたことがあります…(^^;)。

それで、すこしちがうやり方を考えていました。

全体ゲインについて、現行のようにデバイスへの引き渡し直前に適用する方法と、デコード直後の生データに適用する方法を、設定で選択できるようしたらどうか、ということです。

後者の方法であれば、クリッピングは抑制できます。

ただ、その場合、現在のように再生中に動的に切り替えられるようにはせず、全体ゲインを切り替える操作を行ったら、一時的に再生を停止して、ゲインの切り替え後、再生を再開する、というような動作にします。これは、ゲイン切替時にはすでにバッファ内にデータが溜まっており、それらに対して新しいゲインを遡って反映するのは煩雑であるということと、逆に反映しなかった場合に、たとえば-18dBから最大に切り替えると、相応のショック音が出てしまうことが好ましくない故です。

4.2.2は先行版のまま停滞してしまっていますが(UWP版のほうのMicrosoftの審査が今回はなぜか時間がかかっています…)、そのさらに次のリリースに向けて、検討したいと思います。

sakuさん、こんばんわ、Tikiです.

先日リリースした4.2.3の先行版で, 全体ゲインをデコード直後のデータに適用する設定を追加しています. 全体ゲインの選択肢のいちばん下に, 「デコーダに設定」という項目があり, 選択するとチェックマークがつきます.

すこし迷ったのですが、「デコーダに設定」している場合, そのゲインはピークメーター横のボリュームバーには反映されません. ゲイン調整している部位が, TuneBrowserの内部ではまったくちがうところになるのでそのようにしているのですが, ひょっとしたら 作っている側の論理でしかないかもしれないので, もし混乱するようでしたら, その旨教えてください.

よろしくお願いします.

sakuさん、こんばんわ、Tikiです.

夜分にさっそくご確認いただき、ありがとうございました。

表示の件のご指摘、どうもありがとうございます。あらためて確認したところ、結構ケース抜けしていました。(^^; 次のリリースまでに改めます。

ありがとうございました。

sakuさん、こんばんわ、Tikiです.

別項の件も含め、ご確認いただき、ありがとうございました。