Vorbis находит распакованный размер файла - PullRequest
Новая
       83

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

3 голосов
/ 28 декабря 2011

Я работаю с привязками 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, и у него ограниченная мощность процессора, и это довольно уродливое решение. Это не ответ на любой ответ, я просто знаю, что могу это сделать, но предпочел бы не делать этого.

1 Ответ

0 голосов
/ 08 сентября 2015

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

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

...