Vorbis, находя декомпрессированный размер файла

Question

Я работаю с привязками JNI и Android NDK для обертывания версии Vorbis от тремора. До сих пор мне удалось перевести звук из файла в динамики.

Однако, я также хотел бы иметь возможность «кэшировать» небольшие звуки в массивах байтов, поэтому нет избыточной декомпрессии, когда я часто использую эти звуки.

Моя проблема заключается в том, что я не знаю, насколько большой массив должен содержать все данные PCM в файле vorbis.

Я пробовал следующие методы, ни одна из которых не работает в 100% случаев.

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

Приведенные выше работы идеально подходят для некоторых файлов, а гвозди точно соответствуют требуемому размеру. Однако для других это не так. Он резко недооценивает (обычно примерно на 1-2 кбайт) необходимый размер, что явно приводит к исключениям из-за пределов.

Данное решение было рекомендовано, но имеет ту же проблему. Это дает те же результаты, что и выше.

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

Какой метод я должен использовать для определения фактического размера байта, необходимого для хранения файла Ogg Vorbis?

EDIT;

Я знаю, что могу просто делать ov_reads по всей длине файла и брать сумму этих чтений в виде разукрупненного размера. Однако я бы предпочел не удваивать распаковку, так как я работаю в Android, и в первую очередь это имеет ограниченную мощность процессора, и это довольно уродливое решение. Это не ответ на какой-либо ответ, я просто знаю, что могу это сделать, но предпочел бы этого не делать.

Answer 1

Я знаю, что это уже четыре года, но я не нашел реального ответа на этот вопрос. Решение, с которым я давно пошло, состоял в том, чтобы использовать связанные списки массивов байт фиксированного размера, каждый из которых представляет один кусок декомпрессированных данных. Каждый ov_read будет хранить данные в новом фрагменте, и куски будут соединяться друг с другом один-на-следующий, пока весь файл не будет декодирован. Последующее воспроизведение просто захватывало данные из каждого фрагмента последовательно и воспроизводило его.

Это, разумеется, разваливается при распаковке больших файлов и приводит к большому количеству управления памятью для распакованных фрагментов (разгрузка одного файла означает полное удаление всех фрагментов, чтобы они могли собирать мусор).