3

私は JNI と Android NDK バインディングを使用して、Vorbis の Tremor バージョンをラップしています。これまでのところ、ファイルからスピーカーへのサウンドのストリーミングに成功しています。

ただし、小さなサウンドをバイト配列に「キャッシュ」できるようにしたいので、これらのサウンドを頻繁に使用する場合に冗長な解凍はありません。

私の問題は、vorbis ファイル内のすべての PCM データを保持するために必要な配列の大きさがわからないことです。

これらの次の方法を試しましたが、100% うまくいくものはありません。

pcmDuration = ov_pcm_total(vorbisFile, -1);
pcmDuration *= 2;              // 16bit channels
pcmDuration *= vorbisInfo->channels;   // number of channels.

上記は一部のファイルで完全に機能し、必要なサイズを正確に釘付けにします。ただし、他の人にとってはそうではありません。必要なサイズを大幅に (通常は約 1 ～ 2kb) 過小評価するため、明らかに範囲外の例外が発生します。

以下は推奨される解決策ですが、まったく同じ問題があります。上記と同じ結果が得られます。

for(int i = 0; i < ov_streams(vorbisFile); i++)
    size += ov_pcm_total(vorbisFile, i);

Ogg Vorbis ファイルを保持するために必要な実際のバイト サイズを調べるには、どの方法を使用すればよいですか?

編集;

ファイルの全長にわたって ov_reads を実行し、それらの読み取りの合計を解凍サイズとして取得できることはわかっています。ただし、私は Android で作業していて、そもそも CPU パワーが限られているため、2 重に解凍しないことを好みます。これはかなり醜い解決策です。これは回答に対する回答ではありません。できることはわかっていますが、やりたくないのです。

4

1 に答える 1

0

これが 4 年遅れていることはわかっていますが、この質問に対する本当の答えは見つかりませんでした。私がずっと前に行った解決策は、それぞれが圧縮解除されたデータの 1 つのチャンクを表す、固定サイズのバイト配列のリンクされたリストを使用することでした。各 ov_read はデータを新しいチャンクに保存し、ファイル全体がデコードされるまで、チャンクは 1 つずつリンクされます。その後の再生では、各チャンクから順番にデータを取得して再生します。

これは、大きなファイルを解凍するときに明らかにバラバラになり、解凍されたチャンクの大量のメモリ管理につながります (単一のファイルをアンロードすることは、すべてのチャンクを完全にリンク解除してガベージ コレクションできるようにすることを意味します)。

于 2015-09-08T17:05:41.333 に答える