Войти
| Первый выпуск | Август 1991 г. ; 29 лет назад ( 1991-08 ) |
|---|---|
| Тип формата | Контейнер |
| Расширен с | Формат файла обмена |
| Расширен до | AVI, ANI, PAL, RDIB, RMIDI, RMMP, WAV |
Resource Interchange File Format ( RIFF ) является родовым файл формата контейнера для хранения данных в помеченных куски. Он в основном используется для хранения мультимедиа, такого как звук и видео, хотя его также можно использовать для хранения любых произвольных данных.
Реализация Microsoft в основном известна через форматы контейнеров, такие как AVI, ANI и WAV, которые используют RIFF в качестве основы.
RIFF был представлен в 1991 году Microsoft и IBM и был представлен Microsoft как формат по умолчанию для мультимедийных файлов Windows 3.1. Он основан на Electronic Arts ' Interchange Format File, введенный в 1985 году на Commodore Amiga, той лишь разницей, что многоканальные байтовые целые числа в мало-Endian формате, произрастающих в 80x86 серии процессоров, используемых в компьютерах IBM PC, а не Большой -endian формат, родной для процессоров серии 68k, используемых в компьютерах Amiga и Apple Macintosh, где широко использовались файлы IFF. Также был представлен формат RIFX с прямым порядком байтов.
В 2010 году Google представил формат изображений WebP, в котором в качестве контейнера используется RIFF.
Файлы RIFF полностью состоят из « фрагментов ». Общий формат идентичен IFF, за исключением порядка байтов, как указано ранее, и другого значения имен блоков.
Все чанки имеют следующий формат:
Два идентификатора блока, «RIFF» и «LIST», представляют блок, который может содержать субчанки. Данные блока RIFF и LIST (появляются после идентификатора и длины) имеют следующий формат:
Сам файл состоит из одного фрагмента RIFF, который затем может содержать дополнительные фрагменты: следовательно, первые четыре байта правильно отформатированного файла RIFF будут содержать символы «R», «I», «F», «F».
Дополнительную информацию о формате 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 и использовала его в качестве основы для «расширенного мидфайла», который также включает данные инструментов в формате « DLS », встроенные в тот же файл.RMI.
Для целей каталогизации оптимальная позиция для блока INFO - около начала файла. Однако, поскольку блок INFO является необязательным, он часто опускается в подробных спецификациях отдельных форматов файлов, что приводит к некоторой путанице в отношении правильного положения этого блока в файле.
При работе с большими медиафайлами расширение или сжатие блока INFO во время редактирования тега может привести к тому, что следующий раздел «данных» файла должен быть прочитан и перезаписан обратно на диск, чтобы приспособиться к новому размеру заголовка. Поскольку медиафайлы могут иметь размер гигабайта, это потенциально интенсивный процесс для диска. Один из обходных путей - «дополнить» ведущий блок INFO с помощью фиктивных данных (с помощью «фиктивного блока» или «блока заполнения») при создании файла. Позднее редактирование может затем расширить или сузить «фиктивное» поле, чтобы сохранить постоянным общий размер заголовка файла: грамотно написанная часть программного обеспечения может затем перезаписать только заголовок файла при изменении данных тегов без изменения или перемещения основного тела файл.
Некоторые программы пытались решить эту проблему, помещая блок INFO в конец медиафайла, после основного тела файла. Это привело к двум различным соглашениям о размещении фрагментов, с сопутствующим риском того, что некоторые комбинации программного обеспечения могут привести к игнорированию или постоянной перезаписи данных INFO файла во время редактирования. Более сложные программы будут учитывать возможность «неожиданного» размещения фрагментов в файлах и реагировать соответствующим образом. Например, когда программа редактирования аудио Audacity встречает файл.WAV с размещенными в конце данными INFO, она правильно идентифицирует и считывает данные, но при сохранении перемещает фрагмент INFO обратно в заголовок файла.
Хотя CorelDRAW 10 номинально использует файловую структуру RIFF, в первоначальной версии программы блок INFO помещался в конец, так что любое встроенное растровое изображение предварительного просмотра по умолчанию не отображалось в файловом менеджере Windows. Утилита «patch», поставляемая с программой, устраняет эту проблему.
Информационные теги RIFF находятся в аудиофайлах WAV и видеофайлах AVI. Теги, которые являются частью спецификации Exif 2.2 (идентификатор тега начинается с «I»), в HTML-версии этой документации имеют подчеркнутое имя тега. Другие теги находятся в файлах AVI, созданных программным обеспечением для редактирования видео Sony Vegas.
| ID тега | Название тэга | Возможность записи | Ценности / примечания |
|---|---|---|---|
| DTIM | DateTimeOriginal | N | Значения формата "dtim" профиля ICC |
| ЛЕНТА | TapeName | N |
Поле состоит из двух значений (v [0] и v [1]), разделенных пробелом (0x20). Образец кода:
// time in seconds - "concatenate" date amp; time elements with a decimal point delimiter TimeInSeconds = (v[0] * (2^32) + v[1]) * 10^(-7); // shift basis from Jan 1, 1601 to Unix epoch Jan 1, 1970 (369 years amp; leap days) UnixTimeStamp = TimeInSeconds - 134774 * 24 * 3600;
