Формат файла обмена ресурсами ( RIFF ) — это универсальный формат файлового контейнера для хранения данных в помеченных фрагментах . [2] В основном он используется для аудио и видео, хотя его можно использовать и для произвольных данных. [3]
Реализация Microsoft в основном известна благодаря таким контейнерным форматам, как AVI , ANI и WAV , которые используют в качестве основы RIFF. [4]
RIFF был представлен в 1991 году компаниями Microsoft и IBM и использовался в качестве формата по умолчанию для мультимедийных файлов Windows 3.1 . Он основан на формате файлов обмена , представленном 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 с использованием фиктивных данных (с использованием «фиктивного фрагмента» или «заполняющего фрагмента») при создании файла. Позднее редактирование может затем расширить или сузить «фиктивное» поле, чтобы сохранить постоянным общий размер заголовка файла: разумно написанная часть программного обеспечения может затем перезаписать только заголовок файла при изменении данных тегирования, не изменяя и не перемещая основную часть файла. файл.
Некоторые программы пытались решить эту проблему, помещая фрагмент 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 ;