【问题标题】:Vorbis finding decompressed size of fileVorbis查找文件的解压缩大小
【发布时间】:2012-01-29 00:48:45
【问题描述】:

我正在使用 JNI 和 Android NDK 绑定来封装 Tremor 版本的 Vorbis。到目前为止,我已经成功地将声音从文件传输到扬声器。

不过,我还希望能够在字节数组中“缓存”小声音,这样当我经常使用这些声音时,就没有多余的解压了。

我的问题是我不知道数组需要多大才能保存 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 能力,这是一个非常丑陋的解决方案。这不是对任何答案的回应,我只知道我可以做到但不想这样做。

【问题讨论】:

    标签: java c oggvorbis vorbis


    【解决方案1】:

    我知道这已经晚了四年,但我从未找到这个问题的真正答案。我很久以前采用的解决方案是使用固定大小字节数组的链表,每个字节代表一块解压缩数据。每个 ov_read 都会将数据存储到一个新的块中,并且块将一个接一个地链接在一起,直到整个文件被解码。后续播放只会从每个块中按顺序获取数据并重播。

    这在解压缩大文件时显然会崩溃,并导致对解压缩的块进行大量内存管理(卸载单个文件意味着完全解除所有块的链接,以便它们可以被垃圾回收)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-07-16
      • 2020-05-24
      • 2011-07-17
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多