Какой самый дальний резервуар MP3 может быть из кадра, ссылающегося на него? - PullRequest
2 голосов
/ 14 мая 2019

Сжатые данные кадра MP3 могут быть меньше, чем пространство, доступное в кадре.Когда это происходит, мы называем доступное пространство резервуаром.

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

Что меня интересует, так это то, насколько далеко резервуар может быть от текущего кадра?

Например, в следующем я показываю 8 кадров.Текущий кадр (CF) и 7 кадров перед ним.

+----+----+----+----+----+----+----+----+
| -7 | -6 | -5 | -4 | -3 | -2 | -1 | CF |
+----+----+----+----+----+----+----+----+

Скажем, CF - это кадр 100 000, может ли он использовать резервуар, все еще доступный в кадре 0?

Или есть ли пределнапример 255 кадров назад?

1 Ответ

1 голос
/ 15 мая 2019

Насколько я знаю, нет конкретного ограничения количества кадров, но есть контрольный предел в 4088 бит (511 байт) назад.Таким образом, точный предел кадра в битовом резервуаре зависит от битрейта.

Я нашел эту информацию в Техническом FAQ LAME :

Данные MP3 длякадр N не сохраняется в кадре N, но может быть распределен по нескольким кадрам.В типичном случае данные для кадра N будут иметь 20%, которые хранятся в кадре N-1, и 80%, хранящиеся в кадре N. Если кодер создает большой битовый резервуар, данные для кадра N могут фактически сохраняться 4088биты обратно в битовый поток.Затем, если возникает очень трудный для кодирования фрагмент, кодировщик может свободно использовать обычные биты для этого кадра плюс до 4088 дополнительных.Полученные данные будут занимать несколько кадров.Начальное отрицательное смещение в потоке битов для данных, связанных с данным кадром в байтах, задается main_data_begin.

...