Bastyen (私から +1) が示すように、デシベルの計算は実際には単純ではなく、多数のサンプルを調べる必要があります。ただし、サウンド サンプルはアニメーションのビジュアル フレームよりもはるかに頻繁に実行されるため、集計メジャーを作成するとうまくいきます。
たとえば、優れたビジュアル アニメーション レートは 1 秒あたり 60 回更新され、サウンドの最も一般的なサンプリング レートは 1 秒あたり 44100 回です。したがって、735 サンプル (44100 / 60 = 735) は、ビジュアライザーとのインターフェイスに適した選択になる可能性があります。
ところで、私が読んだすべての公式 Java チュートリアル (私は大ファンです) の中で、javax.sound.sampled に付随するものが最も難しいことがわかりました。http://docs.oracle.com/javase/tutorial/sound/TOC.html
しかし、それでも読む価値があります。もし私が書き直しを担当していたら、もっとたくさんのコード例があるでしょう。最適なコード例のいくつかは、「ファイルとフォーマット コンバーターの使用」の説明など、いくつかのセクションに分かれています。
RMS を計算したくない場合は、特定のサンプル数のローカルの高値および/または低値を保存するハックがあります。これらの数値をデシベルに関連付けるのは疑わしいですが、選択したマッピングをビジュアライザーに与えると、MAYBE が役立つ可能性があります。問題の一部は、特定の波の単一ポイントの値が大きく変動する可能性があることです。局所的な高値は、エネルギーやボリュームに関するものではなく、構成高調波の位相によるものである可能性があります。
PCM の上位と下位の値は、おそらく 0 と 256 ではなく、8 ビット エンコーディングでは -128 から 127 である可能性が高くなります。より一般的なのは、16 ビット エンコーディング (-32768 ~ 32767) です。しかし、Bastyen のリンクをたどれば、こつをつかむことができます。コードをビットエンコーディングから独立させるには、他の計算を行う前にデータを正規化 (-1 から 1 の間の浮動小数点数に変換) する可能性があります。