Определить «допустимый фрагмент mp3» для decodeAudioData (WebAudio API)

Я пытаюсь использовать decodeAudioData для декодирования и воспроизведения начальной части большого mp3-файла в javascript. Мой первый, грубый подход заключался в том, чтобы отрезать несколько байтов от начала mp3 и передать их в decodeAudioData. Неудивительно, что это не удается.

После некоторого копания кажется, что decodeAudioData может работать только с «действительными фрагментами mp3», как задокументировано Fair Dinkum Thinkum, здесь.

Однако нет никаких разъяснений о структуре действительного mp3-чанка (автор вышеупомянутого не вникает в это). Я знаю о различных сплиттерах mp3, которые существуют, но я хотел бы подойти к этому программно. (Я пытаюсь реализовать своего рода «потоковую передачу для бедных», используя nodejs на стороне сервера).

Итак, будет ли достаточно разбиения на заголовки кадров mp3 или мне нужно сделать больше? (возможно, «закрывая» каждый фрагмент, добавляя некоторые данные в конце?) Как насчет «резервуара байтов»? Это вызовет проблемы? Для справки, сейчас я работаю с cbr mp3 со скоростью 128 кбит/с. Это как-то упростит процесс?

Будем признательны за любую информацию о том, что decodeAudioData ожидает в качестве действительных данных.

Спасибо.

PS: я понимаю, что это, возможно, запрос на разъяснение post, но моя низкая репутация не позволяет мне публиковать комментарии. Поэтому я не вижу, как еще это сделать, но с новым вопросом. Еще раз спасибо.


person biril    schedule 06.05.2012    source источник
comment
Фрагмент mp3 — это один кадр, представляющий 0,028 секунды аудио. Размер этого кадра является переменным, в зависимости от битрейта закодированного звука. CBR mp3 упрощает задачу, потому что размер кадра будет постоянным во всем файле, и вы можете тривиально вычислить смещение любой конкретной метки времени в аудио.   -  person Marc B    schedule 06.05.2012
comment
Оказывается, это не так, поскольку, например, mp3-файлы со скоростью 128 кбит/с содержат 417-байтовые кадры, а также 418-байтовые кадры. (некоторые кадры содержат дополнительный байт в качестве заполнения)   -  person biril    schedule 07.05.2012


Ответы (2)


После дополнительных экспериментов с decodeAudioData (в Chrome) я нашел следующее:

  • Любой начальный фрагмент mp3 будет успешно декодирован, если он разделен на границе кадра mp3. Обнаружение этой границы не всегда может быть тривиальным (например, включать синтаксический анализ заголовков mp3), поскольку даже mp3 с постоянным битрейтом не всегда содержат кадры постоянного размера. Например, mp3-файлы со скоростью 128 кбит/с содержат 417-байтовые кадры, а также 418-байтовые кадры. (некоторые кадры содержат дополнительный байт в качестве заполнения).
  • Произвольный фрагмент mp3 не гарантирует декодируемость, даже если он разделен на точных границах кадра с «обеих сторон». Некоторые фрагменты такого рода могут быть декодированы, но другие вызывают ошибку decodeAudioData. Я предполагаю, что это связано с битовым резервуаром mp3, который создает зависимость между мп3 кадры.
person biril    schedule 09.11.2012

Если вы разделите файл на части, начиная с действительных заголовков MP3 (12 битов «1», выровненных по границе байта: FF Fx), у вас, скорее всего, все будет хорошо.

person lenik    schedule 06.05.2012
comment
Я тоже так думал, но мои результаты до сих пор показывают обратное: в данный момент я только пытаюсь заняться более простым случаем воспроизведения начального сегмента mp3. Любой кадр, найденный в этом начальном сегменте, очевидно, начинается с допустимого заголовка, но все равно не удается выполнить decodeAudioData... - person biril; 06.05.2012
comment
как насчет конца фрагмента, он заканчивается непосредственно перед началом следующего заголовка FFFx? если вы оставите лишние данные или обрежете их слишком коротко, это может повлиять на воспроизведение. - person lenik; 06.05.2012
comment
Да, кажется, это помогает. Спасибо, и я буду публиковать любые новые результаты. - person biril; 06.05.2012