Resource Interchange File Format: Difference between revisions

Revision as of 16:12, 16 October 2006

Revision as of 00:39, 17 October 2006

Line 30:

* 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 file format consisted of a standard MIDIfile 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 "preudopseudo-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 [[CorelDRAW]]10 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.