FMODライブラリのSound.readDataとSound.lockの違いを並べ替えようとしています（私はC＃/ C ++でプログラミングしていますが、どの言語でも答えを取ります！）。最終的な目標は、波形のビューを作成することです。これは、Channel.getWaveDataでは（簡単に）実行できないことを理解しています。
私はSound.readDataとSound.lockの両方のアプローチを取得して、それぞれcreateStreamとcreateSoundで同じデータを返すことができました（データが有効かどうか（たとえば、デコードされたデータかどうかはまだわかりません））。可能であれば、メモリフットプリントを最小限に抑えるためにストリームアプローチを使用したいのですが、今読んでいるものが何であるかがよくわかりません。また、ドキュメントが完全に明確ではありません。
さらに調査した結果、2つの間に大きな違いはないと確信しています。少し簡単で柔軟性があるように見えるので、おそらく readData を使用することになります。また、ロックはこのメソッドの紛らわしい名前です:)。
基本的に、この 2 つの違いは、何にアクセスしているかです。
Sound::lock を使用すると、サウンドのサンプル バッファーがロックされるため、createSound を使用してロードすると、ファイルが PCM に解凍され、サンプル バッファーに入れられます。この関数を使用して、そのバッファーに直接アクセスします (必要な部分をロックします)。コンソールを使用している場合、そのデータはネイティブの圧縮形式である可能性があります。補足として、サウンドを「ロック」するというアイデアは DirectSound API に由来します。バッファを「ロック」して、読み書き中にバッファへのアクセスを防止します。オーディオシステム。
Sound::readData は、サウンドから PCM データをプル (ストリーミング) するためのより段階的な方法です。ここでは、圧縮されたデータを各 readData 呼び出しで実際に PCM にデコードしています。これを小さなブロックで行うと、最終的にデコードされた PCM データが常に得られます。このアプローチは、より柔軟でメモリ効率が高くなります。
たとえば、10MB の MP3 をストリームとしてロードし、Sound::readData をチャンクで使用して PCM にデコードできます。それ以外の場合は、サンプルとしてロードして (createSound 時に PCM にデコードします)、大規模なバッファーをロックして PCM を取得する必要があります。
getWaveData は、現在の再生時の波形を表示するために使用されます。ファイルの完全な波形をデコードするために使用しないでください。getWaveData への呼び出しの頻度によっては、同じデータ ブロックが時間内の 1 つのスナップショットであるため、複数回取得される場合があります。