Зачем синхронизировать безопасное целое число? - PullRequest
Новая
       44

Зачем синхронизировать безопасное целое число?

0 голосов
/ 26 октября 2011

Я недавно работаю над ID3v2.4.0. Читая документ 2.4.0, я нашел определенную часть, которую не могу понять - целочисленное для синхронизации. Почему ID3v2 использует этот метод?

Конечно, я знаю, почему ID3v2 использует схему Unsynchronization, которая используется для того, чтобы MPEG-декодер не рассматривал тег ID3 в качестве данных синхронизации MPEG. Но что я не мог понять, так это то, почему целочисленное для синхронизации целое число вместо схемы несинхронизации (= вставка $ 00).

Есть ли какая-то причина, по которой они используют безопасное для синхронизации целое число при выражении размера тега вместо вставки $ 00? Эти два метода дают абсолютно одинаковый эффект.

В документе ID3v2 говорится, что размер несинхронизированных данных заранее неизвестен. Но это утверждение не имеет смысла. Если данные тега хранятся в буфере, можно узнать размер несинхронизированных данных, просто заменив проблемный символ на $ FF 00.

Кто-нибудь может мне помочь?

1 Ответ

2 голосов
/ 27 октября 2011

Я бы предположил для простоты, и схема несинхронизации / синхронизации имеет смысл только при использовании в файле MPEG.

Тривиально прочитать четыре байта и преобразовать их в обычное целое число: 

// pseudo code
uint32_t size;
file.read( &size, sizeof(uint32_t) );
size =   (size & 0x0000007F) |
       ( (size & 0x00007F00) >> 1 ) |
       ( (size & 0x007F0000) >> 2 ) |
       ( (size & 0x7F000000) >> 3 );

Если бы они использовали ту же схему несинхронизации, что и данные кадра, вам нужно было бы прочитать каждый байт отдельно, найти шаблон FF00 и восстановить целочисленный байт за байтом. Кроме того, если поле «size» в заголовке может быть переменным числом байтов, из-за вставки несинхронизированных байтов весь заголовок будет переменным числом байтов. Проще сказать: «, заголовок всегда имеет размер 10 байт и выглядит так ... ».

В документе ID3v2 говорится, что размер несинхронизированных данных заранее неизвестен. Но это утверждение не имеет смысла. Если данные тега хранятся в буфере, можно узнать размер несинхронизированных данных, просто заменив проблемный символ на $ FF 00.

Вы правы, это не имеет смысла. Размер, записанный в заголовке id3v2 и заголовках фрейма, равен размеру после применения несинхронизации, если таковая была применена. Тем не менее, допустимо записывать данные кадра без несинхронизации, поскольку id3v2 может использоваться для маркировки файлов, отличных от mp3, где концепция несинхронизации / синхронизации не имеет смысла. Я думаю , что в разделе 6.2 пытался сказать '1018 * независимо от того, является ли это mp3-файлом, или кадр записан несинхронизированным / синхронизированным, размер кадра всегда записывается в mpeg-безопасной для синхронизации Способ .

В кадрах ID3v2.4 может быть установлен флаг «Индикатор длины данных» в заголовке кадра, и в этом случае вы можете узнать, насколько велик размер буфера после синхронизации. См. Раздел 4.1.2 спецификации.

Кто-нибудь может мне помочь?

Несколько полезных советов от человека, написавшего соответствующий читатель тегов id3v2: не пытайтесь разобраться в спецификации. Об этом наверняка писали сумасшедшие и садисты. Просто смотреть на это снова вызывает у меня кошмары.

...