Почему существуют Synchsafe Integer? - PullRequest
Новая
       45

Почему существуют Synchsafe Integer?

8 голосов
/ 07 марта 2011

Я начал читать mp3-файлы на c ++.

Все прошло хорошо, пока я не прочитал спецификации ID3-тега. В заголовке ID3v2 есть некоторая информация о его размере, которая хранится в так называемом Synchsafe Integer Это четырехбайтовое целое число, в котором старший бит каждого байта установлен равным нулю.

Я узнал, как преобразовать его в целое число ordenaty, но я не могу перестать задавать себе вопрос, почему целочисленное значение хранится таким ненужным сложным способом.

Я надеюсь, что есть кто-то, кто может сказать мне, почему он хранится таким образом.

Ответы [ 3 ]

23 голосов
/ 13 апреля 2011

Чтобы понять, почему используются безопасные от синхронизации целые числа, полезно немного узнать о формате данных MP3, а также о том, как файл MP3 воспроизводится медиаплеером.Данные MP3 хранятся в файле в виде серии кадров.Каждый кадр содержит небольшую часть цифровой музыки, закодированной в формате MP3, а также некоторые метаданные о самом кадре.В начале каждого MP3-кадра 11 бит (иногда 12), все установлены в 1. Это называется синхронизацией, и это шаблон, который медиаплеер ищет при попытке воспроизвести файл MP3 или поток.Если проигрыватель находит эту 11-битную последовательность, он знает, что обнаружил кадр MP3, который можно декодировать и воспроизвести.

См .: www.id3.org / mp3Frame

Как известно, тег ID3 содержит данные о треке в целом.Тег ID3 - в версии 2.x и выше - находится в начале файла или даже может быть встроен в поток MP3 (хотя это не часто делается).Заголовок тега ID3 содержит поле размером 32 бита, которое указывает, сколько байтов содержится в теге.Максимальное значение, которое может содержать 32-разрядное целое число без знака, равно 0xFFFFFFFF.Поэтому, если мы напишем 0xFFFFFFFF в поле размера, мы будем претендовать на действительно большой тег (прагматически слишком большой).Когда проигрыватель пытается воспроизвести файл или поток, он ищет 11-битную последовательность фрейма данных MP3, но вместо этого находит поле размера в заголовке тега ID3 и пытается воспроизвести тег, так как поле размера имеет первые 11биты установлены.Обычно это звучит не так хорошо, в зависимости от ваших музыкальных вкусов.Решение состоит в том, чтобы создать целочисленный формат, который не содержит 11 битовых последовательностей из всех 1.Следовательно, безопасный для синхронизации формат целого числа.

Безопасное для синхронизации целое число можно преобразовать в целое число в C / C ++, используя что-то вроде следующего: 

int ID3_sync_safe_to_int( uint8_t* sync_safe )
{
    uint32_t byte0 = sync_safe[0];
    uint32_t byte1 = sync_safe[1];
    uint32_t byte2 = sync_safe[2];
    uint32_t byte3 = sync_safe[3];

    return byte0 << 21 | byte1 << 14 | byte2 << 7 | byte3;
}

Надеюсь, это поможет.

3 голосов
/ 09 мая 2011

В дополнение к ответам выше, я хотел бы добавить страницу из моего блога: http://phoxis.org/2010/05/08/synch-safe/

0 голосов
/ 07 марта 2011

6,2. Синхронные целые числа

В некоторых частях тега неудобно использовать схему несинхронизации, поскольку размер несинхронизированных данных заранее неизвестен, что особенно проблематично с дескрипторами размера. Решение в ID3v2 состоит в том, чтобы использовать целочисленные безопасные числа, в которых никогда не может быть ложных синхронизаций. Целочисленные целочисленные значения - это целые числа, которые обнуляют свой старший бит (бит 7), делая семь битов из восьми доступными. Таким образом, 32-разрядное целочисленное безопасное целое число может хранить 28 бит информации.

С http://www.id3.org/id3v2.4.0-structure

Это тесно связано с тем, что в данном документе называется «асинхронизация», вам следует прочитать всю главу 6. Все это связано с максимальной совместимостью с широким спектром программного и аппаратного обеспечения.

...