#audio #mp3 #codec #file-format #mpeg
#Аудио #mp3 #кодек #формат файла #mpeg
Вопрос:
Сейчас я выполняю некоторую работу по декодированию файлов MP3, но у меня есть лишь некоторые базовые знания о файле MP3. В наши дни я внедряю простой декодер для MP3. При сравнении декодированного результата с результатом декодера Maaate я сталкиваюсь с этой проблемой.
Мой декодер извлекает на один кадр больше, чем декодер Maaate. После тщательного изучения результата выборки файла MP3 я нахожу, что первый кадр является ненормальным. Для моего примера файла первый фрейм имеет длину 413 байт с заголовком frame 0xfffb9064 , отличным от всех других фреймов с длиной и заголовком 100 байт 0xfffb1064 .
Мой вопрос: является ли первый «кадр» в результате реальным кадром? Итак, почему он кажется отличным от других? Если нет, то для чего используется эта структура и как отличить ее от других, поскольку они оба совместно используют код синхронизации фреймов 0xfff ?
Ответ №1:
Потоки MP3 не имеют заголовка файла. Звучит немного странно, что у вас есть только один кадр в начале, который длиннее остальных, но это совершенно законно.
Краткое описание битов в заголовке по адресу:http://www.datavoyage.com/mpgscript/mpeghdr.htm
В вашем случае оба типа заголовка имеют общее значение:
- MPEG-1
- Уровень 3
- Не защищено
- 44,1 кГц
- Нет заполнения
- Не является частной
- M / S joint stereo
- Нет авторских прав
- Оригинальный носитель
- Без выделения
Первый кадр отличается от остальных:
- 128 кбит (в результате получается 417 байтовых кадров минус 4 байтовый заголовок)
Остальные:
- 32 кбит (в результате получается 104 байтовых кадра минус 4 байтовых заголовка)
На этой странице есть формула для расчета размера кадра на основе заголовка: 144 * битрейт / частота дискретизации отступ.
Я подозреваю, что 128-битный первый кадр является артефактом (ошибкой) кодировщика, используемого для генерации сэмпла. Это все еще файл с постоянным битрейтом в 32 кбит после первого кадра. Учитывая, что MP3-декодер не может выдавать выходные данные, пока в нем не будет нескольких кадров, и он не достигнет резкого скачка битрейта на полпути, это вряд ли что-то нарушит.
Комментарии:
1. Это неправильная формула. Правильная формула такова: frame_samplerate / 8 * битрейт/ сэмплирование заполнение
Ответ №2:
Самый первый фрейм может использоваться как то, что часто называют «хромым тегом» (название генератора не обязательно должно быть ХРОМЫМ).
Существовал (и все еще может существовать) способ создать этот тег в ffmpeg, когда кодировщик еще не знает, какими будут будущие данные, и поэтому ffmpeg просто использовал бы некоторые значения по умолчанию, такие как 128 кбит / с, вместо скорости, определенной в ваших данных MP3.
Итак, независимо от того, есть ли у вас CBR или VBR, данные не могут быть основаны на этом фрейме.
Чтобы увидеть, есть ли у вас такой тег, распечатайте по крайней мере первые 64 байта (или воспользуйтесь шестнадцатеричным редактором), и вы должны увидеть буквы «Info» (CBR) или «Xing» (VBR) довольно близко к началу (часто около байта 0x24). eyeD3 и ffprobe способны декодировать этот тег.
Здесь у меня есть страница о формате.
Ответ №3:
Вполне может быть, что первый фрейм является фреймом VBR. проверьте здесь и используйте шестнадцатеричный редактор. Надеюсь, это поможет
Комментарии:
1. Почему это было отклонено? Из того, что я вижу, вполне законная причина аномального первого кадра.