Формат файла обмена ресурсами ( RIFF ) — это универсальный формат файлового контейнера для хранения данных в виде помеченных фрагментов . [2] Он в основном используется для аудио и видео, хотя его можно использовать и для произвольных данных. [3]
Реализация Microsoft в основном известна благодаря таким форматам контейнеров, как AVI , ANI и WAV , которые используют RIFF в качестве своей основы. [4]
RIFF был представлен в 1991 году компаниями Microsoft и IBM и использовался в качестве формата по умолчанию для мультимедийных файлов Windows 3.1 . Он основан на Interchange File Format, представленном Electronic Arts в 1985 году на Amiga . IFF использует соглашение о порядке байтов от старшего к младшему процессора Motorola 68000 для Amiga , но в RIFF многобайтовые целые числа хранятся в порядке байтов от младшего к старшему процессора x86 , используемого в IBM PC-совместимых компьютерах . Также был представлен формат RIFX, который является форматом от старшего к старшему.
В 2010 году Google представил формат изображений WebP , который использует RIFF в качестве контейнера. [5]
Файлы RIFF полностью состоят из " кусков ". Общий формат идентичен IFF , за исключением порядка байтов, как было указано ранее, и другого значения имен кусков.
Все фрагменты имеют следующий формат:
Два идентификатора куска, "RIFF" и "LIST", представляют кусок, который может содержать подкуски. Данные куска RIFF и LIST (появляются после идентификатора и длины) имеют следующий формат:
Сам файл состоит из одного фрагмента RIFF, который затем может содержать дополнительные подфрагменты: таким образом, первые четыре байта правильно отформатированного файла RIFF будут содержать «RIFF».
Более подробную информацию о формате RIFF можно найти в статье «Формат файла обмена» .
RF64 — многоканальный формат файла, основанный на спецификации RIFF, разработанный Европейским вещательным союзом . Он совместим с BWF и позволяет файлам превышать размеры 4 гигабайта . Это достигается путем предоставления фрагмента «ds64» размером 64 бита (8 байт).
Необязательный фрагмент INFO позволяет «помечать» файлы RIFF информацией, попадающей в ряд предопределенных категорий, таких как авторские права («ICOP»), комментарии («ICMT»), исполнитель («IART»), стандартизированным способом. Эти данные можно прочитать из файла RIFF, даже если остальная часть формата файла не распознана. Стандарт также позволяет использовать определяемые пользователем поля. Программисты, намеревающиеся использовать нестандартные поля, должны иметь в виду, что один и тот же нестандартный идентификатор подфрагмента может использоваться разными приложениями разными (и потенциально несовместимыми) способами.
В соответствии со своей политикой использования .RIFF для всех файлов «мультимедиа» Windows 3.1, Microsoft представила новый вариант существующего формата файлов MIDI, используемого для хранения информации о песнях, которые будут воспроизводиться на электронных музыкальных инструментах. Формат файлов MIDI от Microsoft состоял из стандартного файла MIDI, заключенного в оболочку RIFF, и имел расширение файла .RMI . Поскольку существующий формат файлов MIDI уже поддерживал встроенную информацию «тегирования», это вызывало неудобство, связанное с необходимостью иметь дело с двумя форматами файлов для одного и того же типа информации.
С тех пор Ассоциация производителей MIDI приняла формат MIDI-файлов на основе RIFF и использовала его в качестве основы для «расширенного MIDI-файла», который также включает данные инструментов в формате « DLS », встроенные в тот же файл .RMI.
Для целей каталогизации оптимальное положение для фрагмента INFO находится около начала файла. Однако, поскольку фрагмент INFO является необязательным, его часто опускают в подробных спецификациях отдельных форматов файлов, что приводит к некоторой путанице относительно правильного положения этого фрагмента в файле.
При работе с большими медиафайлами расширение или сжатие фрагмента INFO во время редактирования тегов может привести к тому, что следующий раздел «данных» файла придется читать и перезаписывать обратно на диск, чтобы приспособиться к новому размеру заголовка. Поскольку медиафайлы могут иметь размер в гигабайты, это потенциально ресурсоемкий процесс. Одним из обходных путей является «дополнение» начального фрагмента INFO фиктивными данными (используя «фиктивный фрагмент» или «блок pad») при создании файла. Последующее редактирование может затем расширить или сжать поле «фиктивный», чтобы сохранить общий размер заголовка файла постоянным: разумно написанная часть программного обеспечения может затем перезаписать только заголовок файла при изменении данных тегов, не изменяя и не перемещая основное тело файла.
Некоторые программы пытались решить эту проблему, помещая блок INFO в конец медиафайла, после основного тела файла. Это привело к двум различным соглашениям о размещении блоков, с сопутствующим риском того, что некоторые комбинации программного обеспечения могут привести к игнорированию или постоянной перезаписи данных INFO файла во время редактирования. Более сложные программы будут учитывать возможность «неожиданного» размещения блоков в файлах и реагировать соответствующим образом. Например, когда программа редактирования аудио Audacity обнаруживает файл .WAV с данными INFO, размещенными в конце, она правильно идентифицирует и прочитает данные, но при сохранении переместит блок INFO обратно в заголовок файла.
Хотя CorelDRAW 10 номинально использует структуру файла RIFF, в первоначальном выпуске программы блок INFO был помещен в конец, так что любое встроенное растровое изображение предварительного просмотра не отображалось в файловом менеджере Windows по умолчанию. Утилита «патч», поставляемая с программой, устраняет эту проблему.
Информационные теги RIFF встречаются в аудиофайлах WAV и видеофайлах AVI.
Поле состоит из двух значений (v[0] и v[1]), разделенных пробелом (0x20). Пример кода:
// время в секундах - "объединить" элементы даты и времени с разделителем в виде десятичной точки TimeInSeconds = ( v [ 0 ] * ( 2 ^ 32 ) + v [ 1 ]) * 10 ^ ( -7 ); // сдвигаем базу от 1 января 1601 г. до эпохи Unix 1 января 1970 г. (369 лет и високосных дней) UnixTimeStamp = TimeInSeconds - 134774 * 24 * 3600 ;