Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Файловая структура с тегами для мультимедийных файлов ресурсов.
Tagged file structure for multimedia resource files
Формат файлов обмена ресурсами (RIFF) — это универсальный формат контейнера файлов для хранения данных в виде помеченных блоков. Он используется преимущественно для аудио и видео, хотя может применяться и для произвольных данных. Наиболее известны реализации Microsoft в контейнерных форматах, таких как AVI, ANI и WAV, которые основаны на RIFF.
Resource Interchange File Format (RIFF) is a generic file container format for storing data in tagged chunks. It is primarily used for audio and video, though it can be used for arbitrary data. The Microsoft implementation is mostly known through container formats like AVI, ANI and WAV, which use RIFF as their basis.
История
RIFF был представлен в 1991 году компаниями Microsoft и IBM и использовался как формат по умолчанию для мультимедийных файлов Windows 3.1. Он основан на формате Interchange File, представленном компанией Electronic Arts в 1985 году для платформы Amiga. IFF использует старшую (big endian) систему представления чисел, принятую в процессоре Motorola 68000 на Amiga, но в RIFF многобайтовые целые числа хранятся в младшей (little endian) системе, используемой в процессорах x86, применяемых в IBM PC и совместимых с ними компьютерах. Также был представлен формат RIFX, использующий старшую систему представления чисел. В 2010 году компания Google представила графический формат WebP, который использует RIFF в качестве контейнера.
RIFF was introduced in 1991 by Microsoft and IBM and used as the default format for Windows 3.1 multimedia files. It is based on Interchange File Format introduced by Electronic Arts in 1985 on the Amiga. IFF uses the big endian convention of the Amiga's Motorola 68000 CPU, but in RIFF multi byte integers are stored in the little endian order of the x86 processors used in IBM PC compatibles. A RIFX format, which is big endian, was also introduced. In 2010 Google introduced the WebP picture format, which uses RIFF as a container.
Использование части INFO
Факультативный блок INFO позволяет "помечать" файлы RIFF информацией, относящейся к ряду предопределенных категорий, таких как авторские права ("ICOP"), комментарии ("ICMT"), исполнитель ("IART"), в стандартизированном формате. Эти данные могут быть прочитаны из файла RIFF, даже если остальная часть формата файла не распознается. Стандарт также допускает использование пользовательских полей. Программистам, планирующим использовать нестандартные поля, следует учитывать, что один и тот же нестандартный идентификатор подблока может использоваться разными приложениями разными (и потенциально несовместимыми) способами.
The optional INFO chunk allows RIFF files to be "tagged" with information falling into a number of predefined categories, such as copyright ("ICOP"), comments ("ICMT"), artist ("IART"), in a standardised way. These details can be read from a RIFF file even if the rest of the file format is unrecognized. The standard also allows the use of user defined fields. Programmers intending to use non standard fields should bear in mind that the same non standard subchunk ID may be used by different applications in different (and potentially incompatible) ways.
Первоначальные трудности с MIDI-файлами
В соответствии со своей политикой использования RIFF для всех "мультимедийных" файлов Windows 3.1, Microsoft представила новый вариант существующего формата MIDI-файлов, используемого для хранения информации о песнях, предназначенных для воспроизведения на электронных музыкальных инструментах. MIDI-формат Microsoft состоял из стандартного MIDI-файла, заключенного в RIFF-контейнер, и имел расширение RMI. Поскольку существующий формат MIDI-файлов уже поддерживал встроенную информацию для "меток", это привело к недостатку – необходимости работы с двумя форматами файлов для одного и того же типа данных. Ассоциация производителей MIDI впоследствии приняла MIDI-формат на основе RIFF и использовала его как основу для "расширенного MIDI-файла", который также включает данные об инструментах в формате DLS, встроенные в тот же файл RMI.
In line with their policy of using RIFF for all Windows 3.1 "multimedia" files, Microsoft introduced a new variant on the existing MIDI file format used for storing song information to be played on electronic musical instruments. Microsoft's MIDI file format consisted of a standard MIDI file enclosed in a RIFF wrapper, and had the file extension RMI. Since the existing MIDI file format already supported embedded "tagging" information, this caused the disadvantage of having to deal with two file formats for the same type of information. The MIDI Manufacturers Association have since embraced the RIFF based MIDI file format, and used it as the basis of an "extended midifile" that also includes instrument data in "DLS" format, embedded within the same RMI file.
Проблемы размещения INFO-части
Для целей каталогизации оптимальное положение для блока INFO – в начале файла. Однако, поскольку блок INFO является необязательным, он часто отсутствует в подробных спецификациях отдельных форматов файлов, что приводит к путанице относительно его правильного расположения в файле. При работе с большими медиафайлами расширение или сжатие блока INFO при редактировании тегов может потребовать чтения и перезаписи на диск следующего раздела "данные" файла для адаптации к новому размеру заголовка. Учитывая, что медиафайлы могут достигать гигабайтов, это потенциально ресурсоемкая операция для диска. Одним из решений является "дополнение" начального блока INFO фиктивными данными (с использованием "фиктивного блока" или "заполнителя") при создании файла. Последующее редактирование может расширять или сжимать это "фиктивное" поле, чтобы сохранить постоянный общий размер заголовка файла. Программа, разработанная с умом, сможет перезаписывать только заголовок файла при изменении данных тегов, не изменяя и не перемещая основную часть файла. Некоторые программы попытались решить эту проблему, размещая блок INFO в конце медиафайла, после основной части файла. Это привело к двум различным соглашениям о расположении блоков, что создает риск игнорирования или необратимой перезаписи данных INFO файла некоторыми комбинациями программного обеспечения при редактировании. Более продвинутые программы учитывают возможность "неожиданного" расположения блоков в файлах и реагируют соответствующим образом. Например, когда аудиоредактор Audacity обнаруживает WAV-файл с блоком INFO, расположенным в конце, он правильно идентифицирует и считывает данные, но при сохранении перемещает блок INFO обратно в заголовок файла. Хотя CorelDRAW 10 формально использует структуру файла RIFF, в первоначальной версии программы блок INFO размещался в конце, чтобы встроенное растровое изображение предварительного просмотра не отображалось по умолчанию в проводнике Windows. Проблема решается с помощью специальной утилиты ("patch"), поставляемой с программой.
For cataloguing purposes, the optimal position for the INFO chunk is near the beginning of the file. However, since the INFO chunk is optional, it is often omitted from the detailed specifications of individual file formats, leading to some confusion over the correct position for this chunk within a file. When dealing with large media files, the expansion or contraction of the INFO chunk during tag editing can result in the following "data" section of the file having to be read and rewritten back to disk to accommodate the new header size. Since media files can be gigabytes in size, this is a potentially disk intensive process. One workaround is to "pad out" the leading INFO chunk using dummy data (using a "dummy chunk" or "pad chunk") when the file is created. Later editing can then expand or contract the "dummy" field to keep the total size of the file header constant: an intelligently written piece of software can then overwrite just the file header when tagging data is changed, without modifying or moving the main body of the file. Some programs have tried to address the problem by placing the INFO chunk at the end of a media file, after the main body of the file. This has resulted in two different conventions for chunk placement, with the attendant risk that some combinations of software can cause a file's INFO data to be ignored or permanently overwritten during editing. More sophisticated programs will take into account the possibility of "unexpected" chunk placement in files and respond accordingly. For instance, when the audio editing program Audacity encounters a WAV file with end placed INFO data, it will correctly identify and read the data, but on saving, will relocate the INFO chunk back to the file header. Although CorelDRAW 10 nominally uses a RIFF file structure, the program's initial release placed the INFO chunk at the end, so that any embedded preview bitmap would not be displayed under Windows' file manager by default. A "patch" utility supplied with the program fixes this problem.