RIFF

From Wikipedia, the free encyclopedia

The Resource Interchange File Format (RIFF) is a generic meta-format for storing data in tagged chunks. It was introduced in 1991 by Microsoft and IBM, and was presented by Microsoft as the default format for Windows 3.1 multimedia files. It is based on Electronic Arts's Interchange File Format, introduced in 1985, the only difference being that multi-byte integers are in little-endian format, native to the 80x86 processor series used in IBM PCs, rather than the big-endian format native to the 68k processor series used in Amiga and Apple Macintosh computers, where IFF files were heavily used.

The Microsoft implementation is mostly known through file formats like AVI, ANI and WAV, which use the RIFF meta-format as their basis.

RIFF files consist entirely of "chunks". The overall format is identical to IFF, except for the endianness as previously stated, and the different meaning of the chunk names.

All chunks have the following format:

4 bytes: an ASCII identifier for this chunk, e.g. "fmt " or "data".
4 bytes: an unsigned, little-endian 32-bit integer with the length of this chunk (except this field itself and the chunk identifier).
variable-sized field: the chunk data itself, of the size given in the previous field.
a pad byte, if the chunk's length is not even.

Two chunk identifiers, "RIFF" and "LIST", introduce a chunk that can contain subchunks. Their chunk data, after the identifier and length, has the following format:

4 bytes: an ASCII identifier for this particular chunk (in the case of the RIFF chunk: for the entire file, such as "AVI " or "WAVE").
rest of data: subchunks.

The file itself consists of one RIFF chunk, which then can contain further subchunks: hence, the first four bytes of a correctly-formatted RIFF file will spell out "R", "I", "F", "F".

More information about the format can be found in the Interchange File Format article.

1 Use of the INFO chunk
2 Controversies
3 See also
4 Some common RIFF file types
5 External links

[edit] Use of the INFO chunk

The official Microsoft documentation for Windows 3.1 states that the INFO chunk should be placed at the beginning of the file. This allows fast access to the file's descriptive metadata, and lets file system software and multimedia file management applications quickly scan the top of each file and extract author information, icon thumbnails, preview audio, formatting information, and so on.

When Windows XP's file management software encounters an RIFF-format file, it will automatically attempt to read this INFO chunk, and the user can specify some common RIFF fields (e.g. Author, Copyright date) that can be used to supplement the more usual file property fields such as file size and creation date.

[edit] Controversies

In line with their policy of using .RIFF for all Windows "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 "new" MIDI file format consisted of a standard MIDI file enclosed in a RIFF "wrapper", and had the extension .RMI. This caused some upset at the time, since it took a while for existing music software to be updated to use the new format, and not everyone accepted that the creation of a new file format was justified in this case.

When dealing with large video files, expanding or contracting the INFO chunk can result in the entire file (which might be several gigabyes in size) having to be rewritten, which is a disk-intensive process. The correct workaround to this problem is to "pad out" the INFO chunk using dummy data (using a "dummy chunk" or "pad chunk") when a large file is created, so that later editing can expand or contract the "dummy" field to keep the total size of the INFO chunk constant: an intelligently-written piece of software can then overwrite just the INFO chunk when header data is changed, and does not have to modify or move the main body of the file. However, since this method requires a certain amount of additional work on the part of the software programmer, and since the full RIFF specifications were scattered amongst Microsoft's documentation, some programmers believed that it was legal (and simpler) to place the INFO chunk at the end of a RIFF file, and some faulty documentation began to circulate recommending this practice. Misplacing the INFO chunk in this way means that the data will not be read by all media programs, and also means that there is a risk that the entire INFO chunk may be accidentally discarded or overwritten by software that strictly adheres to the official file specification.

These "pseudo-RIFF" files seem to be more common on the Macintosh, perhaps because "mac" programmers are less likely to have access to first-hand Windows documentation. In general, the writers of Mac media software and cross-platform programs tend to be more aware of this potential problem than people producing Windows-only applications: for instance, circa 2004, Apple's QuickTime media software running under Windows seemed to correctly identify and read misplaced INFO chunks, but Sony's Windows-only media software (and Windows itself) would not. This can be a major problem when processing media files in bulk, since a "harmless" batch-processing operation such as format-conversion or normalisation can result in an entire library's-worth of files having their metadata irretrivably destroyed before a user notices. This issue is most relevant to libraries originating on the Macintosh plaform, or from broadcast facilities using software written to EBU specifications.

Although CorelDRAW10 nominally uses a RIFF file structure, it places the INFO chunk at the end, so that any embedded preview bitmap will not be displayed under Windows' file manager by default. An add-on utility supplied with the program fixes this problem.