![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonМногие знают (или догадываются), что поток MP3 состоит из последовательности пакетов (фреймов), каждый из которых кодирует ровно 1152 сэмпла исходного звука. Каждый пакет состоит из заголовка (4 байта) и пожатых данных. Длина пакета может быть весьма разнообразной, но она нигде не хранится. Она вычисляется по данным из заголовка. Чтобы ее узнать, надо всего лишь: взять из заголовка два бита, описывающие версию формата, два бита, описывающие частоту сигнала, четыре бита, описывающие битрейт, и один бит, описывающий паддинг. Затем под двум битам частоты взять ее значение из таблички, но если версия 2, то частоту разделить на 2, а если версия 0, то частоту разделить на 4. Затем если версия 3, то взять битрейт из одной таблички (используя те 4 бита заголовка в качестве индекса), а если версия не 3, то из другой таблички. Потом, если версия 3, то взять число 144, а если не 3, то взять 72, умножить на битрейт, разделить на частоту и прибавить паддинг (0 или 1). Повторять для каждого пакета, ибо в случае VBR пакеты в потоке разной длины. Получается, что при фиксированных частоте и битрейте энкодер должен вписаться ровно в заданный размер с точностью до двух байтов, а если не вписывается, то жать сильнее и лишнее место забивать мусором. Зато длину не передаем, большая экономия! :) Вот такой замечательный формат, не зря же за его использование лицензионных отчислений просят.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-03-09 11:45 pm (UTC)Порядка 0.2%: если это поток от которого нет начала а слушаем с середины (судя по тому что из 32 бит заголовка аж 11 всегда заполнены шоб можно было искать фреймы в потоке, это было одним из дизайн-приоритетов), инфу о битрейте+каналах всё равно необходимо иметь в каждом фрейме.
В общем не разделяю твоего скептицизма.
Нормальный формат вполне.
Если посмотришь например как кодируются SMS-ки в сетях GSM (BTW, а GSM кодек для голоса - это вообще пиздец), на microsoft binary xml, или на FAT32 - намного более унылой неочевидной хрени довольно много. Это никак не мешает этим технологиям использоваться чуть менее чем везде.
Причины следующие:
1. Доступность для понимания - обычно на последнем месте в приоритетах (за исключением разработчиков дидактических материалов, конечно). Производительность, надёжность, безопасность - во-первых, время разработки имеющимися в штате людьми - во-вторых, простота на последнем месте.
2. Раньше железки были принципиально менее произвидительными.
3. Почти все распространённые стандарты придуманы в крупных коммерческих компаниях, где достаточно ровно одной их реализации, и только потом они стали открытыми.
no subject
Date: 2011-03-09 11:55 pm (UTC)no subject
Date: 2011-03-10 04:23 am (UTC)