MCI System Commands
Required Commands
Basic Commands
CD Audio (Redbook)
MIDI Commands
Videodisc Commands
Waveform Audio Commands
Multimedia Programming Interface
and Data Specifications 1.0
Issued as a joint design by IBM Corporation and Microsoft Corporation
August 1991
This document describes the programming interfaces and data specifications for multimedia that are common to both OS/2 and Windows environments. These specifications may be enhanced to incorporate new technologies or modified based on customer feedback and, as such, specifications incorporated into any final product may vary.
Microsoft is a registered trademark, and Windows is a trademark of Microsoft Corp.
IBM and OS/2 are registered trademarks of International Business Machines Corporation.
Contents
Chapter
This document describes the file format and control interface specifications for multimedia. These specifications allow developers to use common file format and device control interfaces.
The Resource Interchange File Format (RIFF), a tagged file structure, is a general specification upon which many file formats can be defined. The main advantage of RIFF is its extensibility; file formats based on RIFF can be future-proofed, as format changes can be ignored by existing applications.
The RIFF file format is suitable for the following multimedia tasks:
* Playing back multimedia data
* Recording multimedia data
* Exchanging multimedia data between applications and across platforms
Chapter 2, "Resource Interchange File Format," describes the RIFF format.
A number of RIFF-based and non-RIFF file formats have been defined for the storage of multimedia data. Chapter 3, "Multimedia File Formats," describes the following file formats:
* Bundle File Format
* Device-Independent Bitmap (DIB) and RIFF DIB file formats
* Musical Instrument Digital Interface (MIDI) and RIFF MIDI file formats
* Palette File Format
* Rich Text File Format
* Waveform Audio File Format
The Media Control Interface (MCI) is a high-level control mechanism that provides a device-independent interface to multimedia devices and resource files.
The Media Control Interface (MCI) provides a command set for playing and recording multimedia devices and resource files. Developers creating multimedia applications are encouraged to use this high-level command interface rather than the low-level functions specific to each platform. The MCI command set acts as a platform-independent layer that sits between multimedia applications and the underlying system software.
The MCI command set is extensible in two ways:
* Developers can incorporate new multimedia devices and file formats in the MCI command set by creating new MCI drivers to interpret the commands.
* New commands and command options can be added to support special features or functions required by new multimedia devices or file formats.
Using MCI, an application can control multimedia devices using simple command strings like open, play, and close. The MCI command strings provide a generic interface to different multimedia devices, reducing the number of commands a developer needs to learn. A multimedia application might even accept MCI commands from an end user and pass them unchanged to the MCI driver, which parses the command and performs the appropriate action.
Chapter 3, "Media Control Interface," describes MCI and its command set in detail.
This document discusses several multimedia codes and formats that require registration. These multimedia elements include the following:
* Compression techniques
* RIFF form types, chunk IDs, and list types
* Compound-file usage codes
* Waveform audio format codes
To register these multimedia elements, request a Multimedia Developer Registration Kit from the following group:RIFF forms;registering
Microsoft Corporation
Multimedia Systems Group
Product Marketing
One Microsoft Way
Redmond, WA 98052-6399
The Multimedia Developer Registration Kit also lists currently defined multimedia elements.
Chapter
The Resource Interchange File Format (RIFF) is a tagged file structure developed for use on multimedia platforms. This chapter defines RIFF and describes the file structures based on RIFF. If your application requires a new file format, you should define it using the RIFF tagged file structure described in this chapter.
RIFF (Resource Interchange File Format) is the tagged file structure developed for multimedia resource files. The structure of a RIFF file is similar to the structure of an Electronic Arts IFF file. RIFF is not actually a file format itself (since it does not represent a specific kind of information), but its name contains the words "interchange file format" in recognition of its roots in IFF. Refer to the EA IFF definition document, EA IFF 85 Standard for Interchange Format Files, for a list of reasons to use a tagged file format.
RIFF has a counterpart, RIFX, that is used to define RIFF file formats that use the Motorola integer byte-ordering format rather than the Intel format. A RIFX file is the same as a RIFF file, except that the first four bytes are 'RIFX' instead of 'RIFF', and integer byte ordering is represented in Motorola format. RIFF files;structureFile formats;Resource Interchange (RIFF)
The following table lists some of the notation conventions used in this document. Further conventions and the notation for documenting RIFF forms are presented later in the document in the section "Notation for Representing Sample RIFF Files."RIFF files;notational conventions
| Notation | Description |
| <element label> | RIFF file element with the label "element label" |
| <element label: TYPE> | RIFF file element with data type "TYPE" |
| [<element label>] | Optional RIFF file element |
| <element label>... | One or more copies of the specified element |
| [<element label>]... | Zero or more copies of the specified element
|
The basic building block of a RIFF file is called a chunk. Using C syntax, a chunk can be defined as follows:RIFF chunk;defined in C syntax
typedef unsigned long DWORD;
typedef unsigned char BYTE;
typedef DWORD FOURCC; // Four-character code
typedef FOURCC CKID; // Four-character-code chunk identifier
typedef DWORD CKSIZE; // 32-bit unsigned size value
typedef struct { // Chunk structure
CKID ckID; // Chunk type identifier
CKSIZE ckSize; // Chunk size field (size of ckData)
BYTE ckData[ckSize]; // Chunk data
} CK;
A FOURCC is represented as a sequence of one to four ASCII alphanumeric characters, padded on the right with blank characters (ASCII character value 32) as required, with no embedded blanks. DWORD, in RIFF chunkRIFF files;FOURCC code inBYTE, in RIFF chunkFOURCCdatatype;inRIFFchunk
For example, the four-character code 'FOO' is stored as a sequence of four bytes: 'F', 'O', 'O', ' ' in ascending addresses. For quick comparisons, a four-character code may also be treated as a 32-bit number.
The three parts of the chunk are described in the following table:RIFF chunk;IDRIFF chunk;size
| Part | Description |
| ckID | A four-character code that identifies the representation of the chunk data data. A program reading a RIFF file can skip over any chunk whose chunk ID it doesn't recognize; it simply skips the number of bytes specified by ckSize plus the pad byte, if present. |
| ckSize | A 32-bit unsigned value identifying the size of ckData. This size value does not include the size of the ckID or ckSize fields or the pad byte at the end of ckData. |
| ckData | Binary data of fixed or variable size. The start of ckData is word-aligned with respect to the start of the RIFF file. If the chunk size is an odd number of bytes, a pad byte with value zero is written after ckData. Word aligning improves access speed (for chunks resident in memory) and maintains compatibility with EA IFF. The ckSize value does not include the pad byte.
|
We can represent a chunk with the following notation (in this example, the ckSize and pad byte are implicit):RIFF chunk;notation
<ckID> ( <ckData> )
Two types of chunks, the 'LIST' and 'RIFF' chunks, may contain nested chunks, or subchunks. These special chunk types are discussed later in this document. All other chunk types store a single element of binary data in <ckData>.
A RIFF form is a chunk with a 'RIFF' chunk ID. The term also refers to a file format that follows the RIFF framework. The following is the current list of registered RIFF forms. Each is described in Chapter 3, "Multimedia File Formats."
| Form Type | Description |
| PAL | RIFF Palette Format |
| RDIB | RIFF Device Independent Bitmap Format |
| RMID | RIFF MIDI Format |
| RMMP | RIFF Multimedia Movie File Format |
| WAVE | Waveform Audio Format
|
Using the notation for representing a chunk, a RIFF form looks like the following:RIFF chunk;RIFF form notation
RIFF ( <formType> <ck>... )
The first four bytes of a RIFF form make up a chunk ID with values 'R', 'I', 'F', 'F'. The ckSize field is required, but for simplicity it is omitted from the notation.
The first DWORD of chunk data in the 'RIFF' chunk (shown above as <formType>) is a four-character code value identifying the data representation, or form type, of the file. Following the form-type code is a series of subchunks. Which subchunks are present depends on the form type. The definition of a particular RIFF form typically includes the following:RIFF chunk;in RIFF form
* A unique four-character code identifying the form type
* A list of mandatory chunks
* A list of optional chunks
* Possibly, a required order for the chunks
The form-type code for a RIFF form must be unique. To guarantee this uniqueness, you must register any new form types before release. See "Registering Multimedia Formats" in Chapter 1, "Overview of Multimedia Specifications," for information on registering RIFF forms.
Like RIFF forms, RIFX forms must also be registered. Registering a RIFF form does not automatically register the RIFX counterpart. No RIFX form types are currently defined.
By convention, the form-type code for registered form types contains only digits and uppercase letters. Form-type codes that are all uppercase denote a registered, unique form type. Use lowercase letters for temporary or prototype chunk types. FOURCCdatatype;and registering form typeRIFF chunk;registering
Certain chunk types are also globally unique and must also be registered before use. These registered chunk types are not specific to a certain form type; they can be used in any form. If a registered chunk type can be used to store your data, you should use the registered chunk type rather than define your own chunk type containing the same type of information.
For example, a chunk with chunk ID 'INAM' always contains the name or title of a file. Also, within all RIFF files, filenames or titles are contained within chunks with ID 'INAM' and have a standard data format.
Chunk types that are used only in a certain form type use a lowercase chunk ID. A lowercase chunk ID has specific meaning only within the context of a specific form type. After a form designer is allocated a registered form type, the designer can choose lowercase chunk types to use within that form. See "Registering Multimedia Formats" in Chapter 1, "Overview of Multimedia Specifications," for information on registering form types.
For example, a chunk with ID 'scln' inside one form type might contain the "number of scan lines." Inside some other form type, a chunk with ID 'scln' might mean "secondary lambda number."
RIFF is a binary format, but it is easier to comprehend an ASCII representation of a RIFF file. This section defines a standard notation used to present samples of various types of RIFF files. If you define a RIFF form, we urge you to use this notation in any file format samples you provide in your documentation. RIFF files;form notation
The following table summarizes the elements of the RIFF notation required for representing sample RIFF files:
| Notation | Description |
| <ckID> (<ckData>) | |
| The chunk with ID <ckID> and data <ckData>. As previously described, <ckID> is a four-character code which may be enclosed by single quotes for emphasis. For example, the following notation describes a 'RIFF' chunk with a form type of 'QRST'. The data portion of this chunk contains a 'FOO' subchunk. RIFF('QRST' FOO(17 23)) The following example describes an 'ICOP' chunk containing the string "Copyright Encyclopedia International.": 'ICOP' ("Copyright Encyclopedia International."Z)
|
|
| <number>[<modifier>] | |
| A number in Intel format, where <number> is an optional sign (+ or -) followed by one or more digits and modified by the optional <modifier>. Valid <modifier> values follow: Modifier Meaning None 16-bit number in decimal format H 16-bit number in hexadecimal format C 8-bit number in decimal format CH 8-bit number in hexadecimal format L 32-bit number in decimal format LH 32-bit number in hexadecimal format
|
|
| Several examples follow: 0 65535 -1 0L 4a3c89HL -1C 21HC Note that -1 and 65535 represent the same value. The application reading this file must know whether to interpret the number as signed or unsigned.
|
|
| '<chars>' | |
| A four-character code (32-bit quantity) consisting of a sequence of zero to four ASCII characters <chars> in the given order. If <chars> is less than four characters long, it is implicitly padded on the right with blanks. Two single quotes is equivalent to four blanks. Examples follow. 'RIFF' 'xyz' '' <chars> can include escape sequences, which are combinations of characters introduced by a backslash (\) and used to represent other characters. Escape sequences are listed in the following section.
|
|
| "<string>"[<modifier>] | The sequence of ASCII characters contained in <string> and modified by the optional modifier <modifier>. The quoted text can include any of the escape sequences listed in the following section. Valid <modifier> values follow: Modifier Meaning none No NULL terminator or size prefix. Z String is NULL-terminated B String has an 8-bit (byte) size prefix W String has a 16-bit (word) size prefix BZ String has a byte-size prefix and is NULL-terminated WZ String has a word-size prefix and is NULL-terminated
|
| NULL-terminated means that the string is followed by a character with ASCII value 0. A size prefix is an unsigned integer, stored as a byte or a word in Intel format preceding the string characters, that specifies the length of the string. In the case of strings with BZ or WZ modifiers, the size prefix specifies the size of the string without the terminating NULL. The various string formats referred to above are discussed in "Storing Strings in RIFF Chunks," following later in this section., + Examples follow: "No prefix, no NULL terminator" "No prefix, NULL terminator"Z "Byte prefix, NULL terminator"BZ
|
The following escape sequences can be used in four-character codes and string chunks:Strings,inRIFFchunk;escapesequences"RIFF chunk;escape sequencesEscape sequence;list ofFOURCC data type;escape sequencesRIFF files;escape sequencesNew line escape sequenceCarriage return escape sequenceLine feed escape sequenceTab escape sequenceBackspace escape sequence"Backslash escape sequenceQuote character escape sequence
| Escape Sequence | ASCII Value | Description |
| \n | 10 | Newline character |
| \t | 9 | Horizontal tab character |
| \b | 8 | Backspace character |
| \r | 13 | Carriage return character |
| \f | 12 | Form feed character |
| \\ | 92 | Backslash |
| -HtmlStart--></FONT></TD><!--HtmlEnd--> | 39 | Single quote |
| \" | 34 | Double quote |
| \ddd | Octal ddd | Arbitrary character
|
To unambiguously define the structure of new RIFF forms, document the RIFF form using the basic notation along with the following extended notation:RIFF files;sample file notation
| Notation | Description |
| <name> | |
| A label that refers to some element of the file, where <name> is the name of the label. Examples follow: <NAME-ck> <GOBL-form> <bitmap-bits> <foo> Conventionally, a label that refers to a chunk is named <ckID-ck>, where 'ckID' is the chunk ID. Similarly, a label that refers to a RIFF form is named <formType-form>, where "formType" is the name of the form's type.
|
|
| <name> Ý elements | |
| The actual data represented by <name> is defined as elements. This states that <name> is an abbreviation for elements, where elements is a sequence of other labels and literal data. An example follows: <GOBL-form> Ý RIFF ( 'GOBL' <form-data> ) This example defines label <GOBL-form> as representing a RIFF form with chunk ID 'GOBL' and data equal to <form-data>, where <form-data> is a label that would be defined in another rule. Note that a label may represent any data, not just a RIFF chunk or form. Note: A number of atomic labels are defined in the section "Atomic Labels" later in this document. These labels refer to primitive data types.
|
|
| <name:type> | |
| This is the same as <name>, but it also defines <name> to be equivalent to <type>. This notation obviates the following rule: <name> Ý <type> This allows you to give a symbolic name to an element of a file format and to specify the element data type. An example follows: <xyz-coordinate> Ý <x:INT> <y:INT> <z:INT> This defines <xyz-coordinate> to consist of three parts concatenated together: <x>, <y>, and <z>. The definition also specifies that <x>, <y>, and <z> are integers. This notation is equivalent to the following: <xyz-coordinate> Ý <x> <y> <z> <x> Ý <INT> <y> Ý <INT> <z> Ý <INT>
|
|
| [elements] | |
| An optional sequence of labels and literal data. Surrounded by square brackets, it may be considered an element itself. An example follows: <FOO-form> Ý RIFF('FOO' [<header-ck>] <data-ck>) This example defines form "FOO" with an optional header chunk followed by a mandatory data chunk.
|
|
| el1 | el2 | ... | elN | |
| Exactly one of the listed elements must be present. An example follows: <hdr-ck> Ý hdr(<hdr-x> | <hdr-y> | <hdr-z>) This example defines the 'hdr' chunk's data as containing one of <hdr-x>, <hdr-y>, or <hdr-z>.
|
|
| element... | |
| One or more occurrences of element may be present. An ellipsis has this meaning only if it follows an element; in cases such as "el1 | el2 | ... | elN," the ellipsis has its ordinary English meaning. If there is any possibility of confusion, an ellipsis should only be used to indicate one or more occurrences. An example follows: <data-ck> Ý data(<count:INT> <item:INT>...) This example defines the data of the 'data' chunk to contain an integer <count>, followed by one or more occurrences of the integer <item>.
|
|
| [element]... | |
| Zero or more occurrences of element may be present. An example follows. <data-ck> Ý data(<count:INT> [<item:INT>]...) This example defines the data of the 'data' chunk to contain an integer <count> followed by zero or more occurrences of an integer <item>.
|
|
| {elements} | |
| The group of elements within the braces should be considered a single element. An example follows: <blorg> Ý <this> | {<that> | <other>}... This example defines <blorg> to be either <this> or one or more occurrences of <that> or <other>, intermixed in any way. Contrast this with the following example: <blorg> Ý <this> | <that> | <other>... This example defines <blorg> to be either <this> or <that> or one or more occurrences of <other>.
|
| struct { ...} name | |
| A structure defined using C syntax. This can be used instead of a sequence of labels if a C header (include) file is available that defines the structure. The label used to refer to the structure should be the same as the structure's typedef name. An example follows: <3D_POINT> Ý struct { INT x; // x-coordinate INT y; // y-coordinate INT z; // z-coordinate } 3D_POINT Wherever possible, the types used in the structure should be the types listed in the following section, "Atomic Labels," because these types are more portable than C types such as int. The structure fields are assumed to be present in the file in the order given, with no padding or forced alignment. Unless the RIFF chunk ID is 'RIFX', integer byte ordering is assumed to be in Intel format.
|
|
| // comment | |
| An explanatory comment to a rule. An example follows: <weekend> Ý 'Sat'|'Sun' // Four-character code // for day
|
The following are atomic labels, which are labels that refer to primitive data types. Where available, the equivalent Microsoft C data type is also listed.
DatatypelabelsAtomic labelsRIFF files;primitive data type labels
| Label | Meaning | MS C Type |
| <CHAR> | 8-bit signed integer | signed char |
| <BYTE> | 8-bit unsigned quantity | unsigned char |
| <INT> | 16-bit signed integer in Intel format | signed int |
| <WORD> | 16-bit unsigned quantity in Intel format | unsigned int |
| <LONG> | 32-bit signed integer in Intel format | signed long |
| <DWORD> | 32-bit unsigned quantity in Intel format | unsigned long |
| <FLOAT> | 32-bit IEEE floating point number | float |
| <DOUBLE> | 64-bit IEEE floating point number | double |
| <STR> | String (a sequence of characters) | |
| <ZSTR> | NULL-terminated string | |
| <BSTR> | String with byte (8-bit) size prefix | |
| <WSTR> | String with word (16-bit) size prefix | |
| <BZSTR> | NULL-terminated string with byte size prefix | |
| <WZSTR> | NULL-terminated string with word size prefix |
|
NULL-terminated means that the string is followed by a character with ASCII value 0.
A size prefix is an unsigned integer, stored as a byte or a word in Intel format, that specifies the length of the string. In the case of strings with BZ or WZ modifiers, the size prefix specifies the size of the string without the terminating NULL.
The following example defines <GOBL-form>, the hypothetical RIFF form of type 'GOBL'. To fully document a new RIFF form definition, a developer would also provide detailed descriptions of each file element, including the semantics of each chunk and sample files documented using the standard notation. RIFF forms;example of definition
<GOBL-form> Ý RIFF( 'GOBL' // RIFF form header
[<org-ck>] // Origin chunk (default (0,0,0))
<obj-list>) // Series of graphical objects
<org-ck> Ý org( <origin:3D_POINT> ) // Object-list origin
// An object is a:
<obj-list> Ý LIST( 'obj' { <sqr-ck> | // square,
<circ-ck> | // circle,
<poly-ck> }... ) // or polygon
<sqr-ck> Ý sqr( <pt1:3D_POINT> // one vertex
<pt2:3D_POINT> // another vertex
<pt3:3D_POINT> ) // a third vertex
<circ-ck> Ý circ( <center:3D_POINT> // Center of circle
<circumPt:3D_POINT> ) // Point on circumference
<poly-ck> Ý poly( <pt:3D_POINT>... ) // List of points in a polygon
<3D_POINT> Ý struct // Defined in "gobl.h"
{ INT x; // x-coordinate
INT y; // y-coordinate
INT z; // z-coordinate
} 3D_POINT
The following sample RIFF form adheres to the form definition for form type GOBL. The file contains three subchunks:RIFF forms;exampleRIFF chunk;example
* An 'INFO' list
* An 'org' chunk
* An 'obj' chunk
The 'INFO' list and 'org' chunk each have two subchunks. The 'INFO' list is a registered global chunk that can be used within any RIFF file. The 'INFO' list is described in the 'INFO List Chunk," later in this chapter. RIFF chunk;INFO chunkINFO chunkRIFF files;INFO chunk
Since the definition of the GOBL form does not refer to the INFO chunk, software that expects only 'org' and 'obj' chunks in a GOBL form would ignore the unknown 'INFO' chunk.
RIFF( 'GOBL'
LIST('INFO' // INFO list containing filename and copyright
INAM("A House"Z)
ICOP("(C) Copyright Encyclopedia International 1991"Z)
)
org(2, 0, 0) // Origin of object list
LIST('obj' // Object list containing two polygons
poly(0,0,0 2,0,0 2,2,0, 1,3,0, 0,2,0)
poly(0,0,5 2,0,5 2,2,5, 1,3,5, 0,2,5)
)
) // End of form
This section lists methods for storing text strings in RIFF chunks. While these guidelines may not make sense for all applications, you should follow these conventions if you must make an arbitrary decision regarding string storage. RIFF chunk;text strings in
A NULL-terminated string (ZSTR) consists of a series of characters followed by a terminating NULL character. The ZSTR is better than a simple character sequence (STR) because many programs are easier to write if strings are NULL-terminated. ZSTR is preferred to a string with a size prefix (BSTR or WSTR) because the size of the string is already available as the <ckSize> value, minus one for the terminating NULL character. WSTR format, in RIFF chunkBSTR format, in RIFF chunk
In a string table, all strings used in a structure are stored at the end of the structure in packed format. The structure includes fields that specify the offsets from the beginning of the string table to the individual strings. An example follows:
typedef struct
{
INT iWidgetNumber; // the widget number
WORD offszWidgetName; // an offset to a string in <rgchStrTab>
WORD offszWidgetDesc; // an offset to a string in <rgchStrTab>
INT iQuantity; // how many widgets
CHAR rgchStrTab[1]; // string table (allocate as large as needed)
} WIDGET;
If multiple chunks within the file need to reference variable-length strings, you can store the strings in a single chunk that acts as a string table. The chunks that refer to the strings contain offsets relative to the beginning of the data part of the string table chunk.
In a BZSTR series, a series of strings is stored in packed format. Each string is a BZSTR, with a byte size prefix and a NULL terminator. This format retains the ease-of-use characteristics of the ZSTR while providing the string size, allowing the application to quickly skip unneeded strings.
When storing multiline strings, separate lines with a carriage return/line feed pair (ASCII 13/ASCII 10 pair). Although applications vary in their requirements for new line symbols (carriage return only, line feed only, or both), it is generally easier to strip out extra characters than to insert extra ones. Inserting characters might require reallocating memory blocks or pre-scanning the chunk before allocating memory for it. Multiline string format, in RIFF chunk
The following lists guidelines for deciding which storage method is appropriate for your application. Strings, in RIFF chunk;storage methods
| Usage | Recommended Format |
| Chunk data contains nothing except a string | ZSTR (NULL-terminated string) format. |
| Chunk data contains a number of fields, some of which are variable-length strings | String-table format |
| Multiple chunks within the file need to reference variable-length strings | String-table format |
| Chunk data stores a sequence of strings, some of which the application may want to skip | BZSTR (NULL-terminated string with byte size prefix) series |
| Chunk data contains multiline strings | A multiline string format
|
A LIST chunk contains a list, or ordered sequence, of subchunks. A LIST chunk is defined as follows:
LIST( <list-type> [<chunk>]... )
The <list-type> is a four-character code that identifies the contents of the list.
If an application recognizes the list type, it should know how to interpret the sequence of subchunks. However, since a LIST chunk may contain only subchunks (after the list type), an application that does not know about a specific list type can still walk through the sequence of subchunks.
Like chunk IDs, list types must be registered, and an all-lowercase list type has meaning relative to the form that contains it. See "Registering Multimedia Formats" in Chapter 1, "Overview of Multimedia Specifications," for information on registering list types.
The 'INFO' list is a registered global form type that can store information that helps identify the contents of the chunk. This information is useful but does not affect the way a program interprets the file; examples are copyright information and comments. An 'INFO' list is a 'LIST' chunk with list type 'INFO'. The following shows a sample 'INFO' list chunk:
LIST('INFO' INAM("Two Trees"Z)
ICMT("A picture for the opening screen"Z) )
An 'INFO' list should contain only the following chunks. New chunks may be defined, but an application should ignore any chunk it doesn't understand. The chunks listed below may only appear in an 'INFO' list. Each chunk contains a ZSTR, or null-terminated text string.
| Chunk ID | Description |
| IARL | Archival Location. Indicates where the subject of the file is archived. |
| IART | Artist. Lists the artist of the original subject of the file. For example, "Michaelangelo." |
| ICMS | Commissioned. Lists the name of the person or organization that commissioned the subject of the file. For example, "Pope Julian II." |
| ICMT | Comments. Provides general comments about the file or the subject of the file. If the comment is several sentences long, end each sentence with a period. Do not include newline characters. |
| ICOP | Copyright. Records the copyright information for the file. For example, "Copyright Encyclopedia International 1991." If there are multiple copyrights, separate them by a semicolon followed by a space. |
| ICRD | Creation date. Specifies the date the subject of the file was created. List dates in year-month-day format, padding one-digit months and days with a zero on the left. For example, "1553-05-03" for May 3, 1553. |
| ICRP | Cropped. Describes whether an image has been cropped and, if so, how it was cropped. For example, "lower right corner." |
| IDIM | Dimensions. Specifies the size of the original subject of the file. For example, "8.5 in h, 11 in w." |
| IDPI | Dots Per Inch. Stores dots per inch setting of the digitizer used to produce the file, such as "300." |
| IENG | Engineer. Stores the name of the engineer who worked on the file. If there are multiple engineers, separate the names by a semicolon and a blank. For example, "Smith, John; Adams, Joe." |
| IGNR | Genre. Describes the original work, such as, "landscape," "portrait," "still life," etc. |
| IKEY | Keywords. Provides a list of keywords that refer to the file or subject of the file. Separate multiple keywords with a semicolon and a blank. For example, "Seattle; aerial view; scenery." |
| ILGT | Lightness. Describes the changes in lightness settings on the digitizer required to produce the file. Note that the format of this information depends on hardware used. |
| IMED | Medium. Describes the original subject of the file, such as, "computer image," "drawing," "lithograph," and so forth. |
| INAM | Name. Stores the title of the subject of the file, such as, "Seattle From Above." |
| IPLT | Palette Setting. Specifies the number of colors requested when digitizing an image, such as "256." |
| IPRD | Product. Specifies the name of the title the file was originally intended for, such as "Encyclopedia of Pacific Northwest Geography." |
| ISBJ | Subject. Describes the conbittents of the file, such as "Aerial view of Seattle." |
| ISFT | Software. Identifies the name of the software package used to create the file, such as "Microsoft WaveEdit." |
| ISHP | Sharpness. Identifies the changes in sharpness for the digitizer required to produce the file (the format depends on the hardware used). |
| ISRC | Source. Identifies the name of the person or organization who supplied the original subject of the file. For example, "Trey Research." |
| ISRF | Source Form. Identifies the original form of the material that was digitized, such as "slide," "paper," "map," and so forth. This is not necessarily the same as IMED. |
| ITCH | Technician. Identifies the technician who digitized the subject file. For example, "Smith, John."
|
To define character-set and language information for a RIFF file, use the CSET chunk. The CSET chunk defines the code page and country, language, and dialect codes for the file. These values can be overridden for specific file elements; see "Usage Codes for Extra Header and Extra Entry Fields," later in this chapter, for information on specifying character set information in a compound file.
The CSET chunk is defined as follows:
<CSET chunk> Ý CSET( <wCodePage:WORD>
<wCountryCode:WORD>
<wLanguageCode:WORD>
<wDialect:WORD> )
The fields are as follows:
| Field | Description |
| wCodePage | Specifies the code page used for file elements. If the CSET chunk is not present, or if this field has value zero, assume standard ISO 8859/1 code page (identical to code page 1004 without code points defined in hex columns 0, 1, 8, and 9). |
| wCountryCode | Specifies the country code used for file elements. See "Country Codes," following this section, for a list of currently defined country codes. If the CSET chunk is not present, or if this field has value zero, assume USA (country code 001).
|
| wLanguage, wDialect |
Specify the language and dialect used for file elements. See "Language and Dialect Codes," later in this chapter, for a list of language and dialect codes. If the CSET chunk is not present, or if these fields have value zero, assume US English (language code 9, dialect code 1).
|
Use one of the following country codes in the wCountryCode field:
| Country Code | Country |
| 000 | None (ignore this field) |
| 001 | USA |
| 002 | Canada |
| 003 | Latin America |
| 030 | Greece |
| 031 | Netherlands |
| 032 | Belgium |
| 033 | France |
| 034 | Spain |
| 039 | Italy |
| 041 | Switzerland |
| 043 | Austria |
| 044 | United Kingdom |
| 045 | Denmark |
| 046 | Sweden |
| 047 | Norway |
| 049 | West Germany |
| 052 | Mexico |
| 055 | Brazil |
| 061 | Australia |
| 064 | New Zealand |
| 081 | Japan |
| 082 | Korea |
| 086 | People's Republic of China |
| 088 | Taiwan |
| 090 | Turkey |
| 351 | Portugal |
| 352 | Luxembourg |
| 354 | Iceland |
| 358 | Finland
|
Specify one of the following pairs of language-code and dialect-code values in the wLanguage and wDialect fields:
| Language Code | Dialect Code | Language |
| 0 | 0 | None (ignore these fields) |
| 1 | 1 | Arabic |
| 2 | 1 | Bulgarian |
| 3 | 1 | Catalan |
| 4 | 1 | Traditional Chinese |
| 4 | 2 | Simplified Chinese |
| 5 | 1 | Czech |
| 6 | 1 | Danish |
| 7 | 1 | German |
| 7 | 2 | Swiss German |
| 8 | 1 | Greek |
| 9 | 1 | US English |
| 9 | 2 | UK English |
| 10 | 1 | Spanish |
| 10 | 2 | Spanish Mexican |
| 11 | 1 | Finnish |
| 12 | 1 | French |
| 12 | 2 | Belgian French |
| 12 | 3 | Canadian French |
| 12 | 4 | Swiss French |
| 13 | 1 | Hebrew |
| 14 | 1 | Hungarian |
| 15 | 1 | Icelandic |
| 16 | 1 | Italian |
| 16 | 2 | Swiss Italian |
| 17 | 1 | Japanese |
| 18 | 1 | Korean |
| 19 | 1 | Dutch |
| 19 | 2 | Belgian Dutch |
| 20 | 1 | Norwegian - Bokmal |
| 20 | 2 | Norwegian - Nynorsk |
| 21 | 1 | Polish |
| 22 | 1 | Brazilian Portuguese |
| 22 | 2 | Portuguese |
| 23 | 1 | Rhaeto-Romanic |
| 24 | 1 | Romanian |
| 25 | 1 | Russian |
| 26 | 1 | Serbo-Croatian (Latin) |
| 26 | 2 | Serbo-Croatian (Cyrillic) |
| 27 | 1 | Slovak |
| 28 | 1 | Albanian |
| 29 | 1 | Swedish |
| 30 | 1 | Thai |
| 31 | 1 | Turkish |
| 32 | 1 | Urdu |
| 33 | 1 | Bahasa
|
A JUNK chunk represents padding, filler or outdated information. It contains no relevant data; it is a space filler of arbitrary size. The JUNK chunk is defined as follows:
<JUNK chunk> Ý JUNK( <filler> )
where <filler> contains random data.
The compound file structure is a RIFF-based structure upon which multimedia file formats can be defined. The compound file structure is a parameterized structure that provides for the following:
* Storage of multimedia data elements
* Direct access to multimedia data elements (as opposed to sequential searching)
The goals of the compound file structure are to maximize flexibility and extensibility while minimizing implementation costs. Using the compound file structure, developers of multimedia data formats can define both simple and complex file formats.
The structure is flexible enough to be used for many purposes, but it can be simplified for use with simple file formats. Designers of new multimedia file formats can restrict the use of standard header fields, requiring some and removing others.
For example, a developer might define a compound file format that stores a series of bitmaps in a single file, thus reducing compact disc seek times. Another developer might define a compound file format that contains a special type of audio resource, using the compound file header information to identify the attributes of the audio data stored within.
Files based upon the compound file structure contain the following two RIFF chunks at their topmost level:
* Compound File Table of Contents (CTOC) chunk
* Compound File Element Group (CGRP) chunk
The CTOC chunk indexes the CGRP chunk, which contains the actual multimedia data elements. Defined using the standard chunk notation, a compound file is represented as follows:
<compound file> Ý RIFF('type' <CTOC> <CGRP>)
where 'type' is a FOURCC indicating the file type.
This section describes the CTOC and CGRP chunks in detail.
The CTOC chunk functions mainly as an index, allowing direct access to elements within a compound file. The CTOC chunk also contains information about the attributes of the entire file and of each media element within the file.
To provide the maximum flexibility for defining compound file formats, the CTOC chunk can be customized at several levels. The CTOC chunk contains fields whose length and usage is defined by other CTOC fields. This parameterization adds complexity, but it provides flexibility to file format designers and allows applications to correctly read data without necessarily knowing the specific file format definition.
The CTOC chunk defines the contents of the CGRP chunk. The CTOC chunk has the following components:
* Header information defining the size of the CTOC chunk, the number of entries in the CGRP chunk, the size of the CGRP chunk, and general information about the entire header file
* A parameter table definition defining the size and contents of the header parameter table and CTOC table entries
* A header parameter table defining attributes that apply to the entire compound file.
* CTOC table entries defining the location, size, name, and attributes of the compound file elements contained in the CGRP chunk.
These components appear sequentially in the CTOC chunk. The individual fields in the CTOC chunk are the following:
<CTOC-chunk>Ý CTOC (
<dwHeaderSize:DWORD> // Header information
<dwEntriesTotal:DWORD>
<dwEntriesDeleted:DWORD>
<dwEntriesUnused:DWORD>
<dwBytesTotal:DWORD>
<dwBytesDeleted:DWORD>
<dwHeaderFlags:DWORD>
<wEntrySize:WORD> // Parameter table definition
<wNameSize:WORD>
<wExHdrFields:WORD>
<wExEntFields:WORD>
<awExHdrFldUsage:WORD[wExHdrFields]>
<awExEntFldUsage:WORD[wExEntFields]>
// Header parameter table
<adwExHdrField:DWORD[wExHdrFields]>
[<bHeaderPad:BYTE>]
[<CTOC-table-entry>] // CTOC table entries
)
Each CTOC table entry is defined as follows:
<CTOC-table-entry> Ý
<dwOffset:DWORD>
<dwSize:DWORD>
<dwMedType:DWORD>
<dwMedUsage:DWORD>
<dwCompressTech:DWORD>
<dwUncompressBytes:DWORD>
<adwExEntField:DWORD[wExEntFields]>
<bEntryFlags:BYTE>
<achName:CHAR[wNameSize]>
[<bEntryPad:BYTE>]...
The following sections describe each field in detail.
The header information section defines general information about the CTOC header and about the entire compound file. It contains the following fields:
| Field Name | Description |
| dwHeaderSize | Combined size of header information, parameter table definition, and header parameter table. Use this value to locate the start of the CTOC table entries within the CTOC chunk. |
| dwEntriesTotal | Total number of CTOC table entries, including unused entries and entries corresponding to deleted elements. |
| dwEntriesDeleted | Number of CTOC table entries that correspond to deleted elements. |
| dwEntriesUnused | Number of CTOC table entries that are unused. |
| dwBytesTotal | Combined size of all CGRP elements, including deleted elements. |
| dwBytesDeleted | Combined size of all deleted CGRP elements. |
| dwHeaderFlags | Flags that give information about the entire compound file. The following flags may be used: CTOC_HF_SEQUENTIAL Valid CTOC table entries are arranged in sequential order. If this flag is not set, the CTOC table entries may be in an arbitrary order. CTOC_HF_MEDSUBTYPE The dwMedUsage field of each CTOC table entry contains a FOURCC that indicates how the element is used. If this flag is not set, the dwMedUsage field contains information as defined by the form type.
|
The parameter table definition defines the size and contents of the header parameter table and CTOC table. It contains the following fields:
| Field Name | Description |
| wEntrySize | Size of each CTOC table entry, including any pad bytes. |
| wNameSize | Size of the achName field of each CTOC table entry. Each achName field must be padded with null characters to this length. The achName field is a null-terminated string, so it always contains at least one trailing null character. |
| wExHdrFields | Number of extra header fields, or entries in the awExHdrFldUsage and adwExHdrField arrays. |
| wExEntFields | Number of extra entry fields, or entries in the awExEntFldUsage and adwExHdrField arrays. |
| awExHdrFldUsage | Array of extra header field usage fields. Each entry in this array corresponds to the same numbered entry in the adwExHdrField array and defines how that entry is interpreted. Valid usage codes for each field in this array are listed in "Usage Codes for Extra Header and Extra Entry Fields," later in this chapter. The number of WORDs in this array is defined by the wExHdrFields value. |
| awExEntFldUsage | Array of extra entry field usage fields. Each entry in this array corresponds to the same numbered entry in the adwExEntField array, present in each CTOC table entry, and defines how that entry is interpreted. Valid usage codes for each field in this array are listed in "Usage Codes for Extra Header and Extra Entry Fields," later in this chapter. The number of WORDs in this array is defined by the wExEntFields value.
|
The header parameter table is an optional component generally used to define attributes of the entire compound file.
| Field Name | Type |
| adwExHdrField | Extra header fields. The usage of each cell in the array is defined by the corresponding cell in the awExHdrFldUsage array. The number of DWORDs in this array is defined by the wExHdrFields value.
|
| bHeaderPad | Zero or more NULL pad bytes. There must be enough padding in this field to make the CTOC header an even number of bytes in length.
|
The CTOC table entries define the location, size, name, and other information about the individual compound file elements contained in the CGRP chunk. The number of CTOC table entries is determined by the dwEntriesTotal field in the header information of the CTOC chunk.
Each CTOC table entry is a structure containing the following fields:
| Field Name | Description |
| dwOffset | Byte offset of the compound file element measured from the beginning of the data portion of the CGRP chunk. For example, if dwOffset is 1000 and the chunk ID of the CGRP chunk is at offset 500, the element is at offset 1508 (1000+500+4 (chunk ID)+4 (chunk size field)).
|
| dwSize | Size of the element in bytes. |
| dwMedType | FOURCC value identifying the media element type of the compound file element. This field may be zero if the compound file element is not to be interpreted as a standalone file. If the compound file element is a RIFF form, then the media element type is the same as the RIFF form type. |
| dwMedUsage | Extra usage information for the compound file element. If the CTOC_HF_MEDSUBTYPE flag is set in the dwHeaderFlags field, this field contains a FOURCC that indicates how the element is used. To avoid name conflicts, this FOURCC must be registered. See "Registering Multimedia Formats" in Chapter 1, "Overview of Multimedia Specifications," for information on usage codes. If the CTOC_HF_MEDSUBTYPE flag is not set in the dwHeaderFlags field, this field contains 32 bits of information interpreted as defined by the form type.
|
| dwCompressTech | Compression technique used to compress the media element. If this value is zero, the element is not compressed. See "Compression of Compound File Elements," later in this chapter, for more information. |
| dwUncompressBytes | Number of bytes the compound file element occupies in memory after decompression. This value assumes the decompression technique identified in the dwCompressTech field. If the dwCompressTech field is 0, then the compound file element is not compressed, and this field should equal the dwSize field. |
| adwExEntField | Array of extra entry fields defining attributes of this compound file element. The usage of each cell in the array is defined by the corresponding cell in the awExEntFldUsage array. The number of DWORDs in this array is defined by the wExEntFields value.
|
| bEntryFlags | Flags giving information about the compound file element or this CTOC table entry. Possible values follow; these may be combined: CTOC_EF_DELETED Compound file is marked as deleted and should not be accessed. Do not combine this flag with the CTOC_EF_UNUSED flag. CTOC_EF_UNUSED CTOC table entry is unused and does not refer to any compound file element. This entry can be used to refer to a new compound file element. Do not combine this flag with the CTOC_EF_DELETED flag.
|
| achName | Array of characters containing the name of the compound file element. The number of bytes in this array is defined by the wNameSize value. The string must be padded on the right with NULL characters and must be terminated by at least one NULL character. This field must be an odd number of bytes in length and must be at least one byte long.
|
| bEntryPad | Zero or more NULL pad bytes as needed to make the table entry an even number of bytes in length.
|
The following are valid usage codes for elements in the awExHdrFldUsage and awExEntFldUsage arrays, both of which are fields of the CTOC header. These arrays define the meaning of data stored in the adwExHdrField and adwExEntField "extra fields." All usage codes apply to both header fields and entry fields, unless explicitly stated otherwise.
Values marked in the extra header field arrays generally apply to all elements in the CFRG chunk, while values marked in the extra entry field arrays generally apply only to the element referenced by the corresponding CTOC table entry.
| Flag | Description |
| CTOC_EFU_UNUSED (0x00) | The field is unused. This usage code may be used to logically delete a header field. |
| CTOC_EFU_LASTMODTIME (0x01) | When used to describe an extra header field, the field contains the time that any portion of the CTOC or CGRP was last modified. When used to describe an extra entry field, the field contains the time that the corresponding CTOC table entry, or the compound file element it refers to, was last modified. The field is interpreted as a DWORD containing the number of seconds that have elapsed since 00:00:00 Greenwich Mean Time (GMT), January 1, 1970.
|
| CTOC_EFU_CODEPAGE | The field contains the code page and country code for the achName field. These values override any values specified in a CSET chunk. When used to describe an extra header field, the field contains code-page and country-code information for all CTOC table entries. When used to describe an extra entry field, the field contains information for that specific CTOC table entry.
|
| The low-order word of the field contains one of the following code page values: Zero Use standard ISO 8859/1 code page. This is identical to code page 1004 without code points defined in hex columns 0, 1, 8, and 9. CTOC_CHARSET_CODEPAGE (0x0000nnnn) Use code page 0xnnnn, where 0xnnnn is the 16-bit code page number. For example, 0x00000352 for OS/2 code page 850, or 0x000004E4 for Windows 3.1 code page 1252.
|
|
| The high-order word contains one of the following country codes: Zero Ignore this field. Country code See "Country Codes," earlier in this chapter, for a list of currently defined country codes.
|
|
| CTOC_EFU_LANGUAGE | The field contains language and dialect information for the achName field. These values override any values specified in a CSET chunk. When used to describe an extra header field, the field contains language information for all CTOC table entries. When used to describe an extra entry field, the field contains information for that specific CTOC table entry.
|
| The low-order word of the field contains one of the following language codes: Zero Ignore this field. Language code See "Language and Dialect Codes," earlier in this chapter, for a list of currently defined language codes. The high-order word of the field contains one of the following dialect codes: Zero Ignore this field. Dialect code See "Language and Dialect Codes," earlier in this chapter, for a list of currently defined dialect codes.
|
|
| CTOC_EFU_COMPRESSPARAM0 (0x05) through CTOC_EFU_COMPRESSPARAM9 (0x14) |
Specifies a compression parameter. See "Compression of Compound File Elements," later in this chapter.
|
Compound file elements can be compressed. The dwCompressTech field of a CTOC table entry contains a FOURCC compression technique identifier for the corresponding compound file element. If the field is zero, the compound file element is not compressed.
The definition of a specific compression technique may specify that either the entire compound file element is compressed, or that some specific subset, for example one or more RIFF chunks, is compressed.
The dwUncompressSize field contains the number of bytes that the compound file element will occupy in memory after decompression. If the compound file element is not compressed, this field contain the same value as the dwSize field, which identifies the file size of the compound file element.
Compression techniques may demand extra header fields or extra entry fields for decompression parameters. Compression technique identifiers, and any new entry fields corresponding to decompression technique parameters, must be unique. See "Registering Multimedia Formats" in Chapter 1, "Overview of Multimedia Specifications," for information on registering compression techniques.
The actual elements of data referenced by the CTOC chunk are stored in a compound file Element Group (CGRP) chunk. The CGRP chunk contains all the compound file elements, concatenated together into one contiguous block of data. Some of the elements in the CGRP chunk might be unused, if the element was marked for deletion or was altered and stored elsewhere within the CGRP chunk.
Elements within the CGRP chunk are of arbitrary size and can appear in a specific or arbitrary order, depending upon the file format definition. Each element is identified by a corresponding CTOC table entry.
Using the standard RIFF notation, the CGRP chunk is defined as follows:
<CGRP-chunk> Ý CGRP([<compound file element>]...)
The specific file format definition can specify which of the two chunks appear first the data file. Generally, the CTOC chunk is placed at the front of the file to reduce the seek and read times required to access it. During authoring time, an application might place the CTOC chunk at the end of the file, so it can be expanded as elements are added to the CGRP chunk.
Chapter
This chapter describes the multimedia file formats. Most of these file formats are based on the Resource Interchange File Format (RIFF), described in Chapter 2.
This chapter describes the following file formats:
* Bundle File Format (BND)
* Device Independent Bitmap File Format (DIB)
* RIFF DIB File Format (RDIB)
* Musical Instrument Digital Interface File Format (MIDI)
* RIFF MIDI File Format (RMID)
* Palette File Format (PAL)
* Rich Text Format (RTF)
* Waveform Audio File Format (WAVE)
The Bundle (BND) format contains a series of RIFF chunks or other multimedia files. The BND file is defined as follows:
<BND-file> Ý RIFF('BND' <CTOC-chunk> <CGRP-chunk> )
The <CTOC-chunk> and <CGRP-chunk> formats are defined in "Compound File Structure," in Chapter 2, "Resource Interchange File Format."
Each compound file element must be capable of standing alone as an independent file. An element may not be a random chunk (except the RIFF chunk, indicating a RIFF file) or random binary data (unless the binary data is supposed to be treated as a file).
The Device Independent Bitmap (DIB) format represents bitmap images in a device-independent manner. Bitmaps can be represented at 1, 4, and 8 bits per pixel, with a palette containing colors represented in 24 bits. Bitmaps can also be represented at 24 bits per pixel without a palette and in a run-length encoded format. File formats;Device-Independent Bitmap (DIB)DIB files;Multimedia Windows
This documentation describes three types of DIB files:
* Windows version 3.0 device-independent bitmap files
* OS/2 Presentation Manager version 1.2 device-independent bitmap files
* RIFF device-independent bitmap files
The Windows 3.0 and Presentation Manager 1.2 DIBs are similar, so they are discussed together.
Windows 3.0 and Presentation Manager 1.2 DIB files consist of the following sequence of data structures:DIB files;structure
* A file header
* A bitmap information header
* A color table
* An array of bytes that defines the bitmap bits
The following sections describe each of these structures.
The bitmap file header contains information about the type, size, and layout of a device-independent bitmap (DIB) file. In both the Windows 3.0 and Presentation Manager 1.2 DIBs, it is defined as a BITMAPFILEHEADER data structure:BITMAPFILEHEADER data structure;in DIB fileDIB files;bitmap file header
typedef struct tagBITMAPFILEHEADER {
WORD bfType;
DWORD bfSize;
WORD bfReserved1;
WORD bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
The following table describes the fields.
| Field | Description |
| bfType | Specifies the file type. It must consist of the character sequence BM (WORD value 0x4D42). |
| bfSize | Specifies the file size in bytes. |
| bfReserved1 | Reserved. Must be set to zero. |
| bfReserved2 | Reserved. Must be set to zero. |
| bfOffBits | Specifies the byte offset from the BITMAPFILEHEADER structure to the actual bitmap data in the file.
|
The BITMAPINFO and BITMAPCOREINFO data structures define the dimensions and color information for Windows 3.0 and Presentation Manager 1.2 DIBs, respectively. They are defined as follows:
| Windows 3.0 DIB | Presentation Manager 1.2 DIB |
| typedef struct tagBITMAPINFO { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[1]; } BITMAPINFO; |
typedef struct _BITMAPCOREINFO { BITMAPCOREHEADER bmciHeader; RGBTRIPLE bmciColors[1]; } BITMAPCOREINFO;
|
These structures are essentially alike, and this section discusses them simultaneously. Each field name for the Windows BITMAPINFO structure is followed by the corresponding field name for the Presentation Manager BITMAPCOREINFO 1.2 structure, in parentheses.
The following table describes the fields.
| Windows (PM) Field | Description |
| bmiHeader (bmciHeader) | Specifies information about the dimensions and color format of the DIB. The BITMAPINFOHEADER and BITMAPCOREHEADER data structures are described in the next section. |
| bmiColors (bmciColors) | Specifies the DIB color table. The RGBQUAD and RGBTRIPLE data structures are described in "Bitmap Color Table," later in this chapter.
|
The BITMAPINFOHEADER and BITMAPCOREHEADER structures contain information about the dimensions and color format of Windows 3.0 and Presentation Manager 1.2 DIBs, respectively. They are defined as follows:
DIB files;bitmap information headerBITMAPINFOHEADER data structure;in DIB file
| Windows 3.0 DIB | Presentation Manager 1.2 DIB |
| typedef struct tagBITMAPINFOHEADER { DWORD biSize; DWORD biWidth; DWORD biHeight; WORD biPlanes; WORD biBitCount; DWORD biCompression; DWORD biSizeImage; DWORD biXPelsPerMeter; DWORD biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER; |
typedef struct tagBITMAPCOREHEADER { DWORD bcSize; WORD bcWidth; WORD bcHeight; WORD bcPlanes; WORD bcBitCount; } BITMAPCOREHEADER;
|
Because these structures are essentially alike, except for the added fields in the Windows 3.0 structure, this section discusses them simultaneously. Each field name for the Windows structure is followed by the corresponding field name for the Presentation Manager structure, in parentheses.
The following fields are present in both the Windows 3.0 and Presentation Manager 1.2 formats:
| Windows (PM) Field | Description |
| biSize (bcSize) | Specifies the number of bytes required by the BITMAPINFOHEADER structure. You can use this field to distinguish between Windows 3.0 and Presentation Manager 1.2 DIBs. |
| biWidth (bcWidth) | Specifies the width of the DIB in pixels. |
| biHeight (bcHeight) | Specifies the height of the DIB in pixels. |
| biPlanes (bcPlanes) | Specifies the number of planes for the target device. Must must be set to 1. |
| wBitCount (bcBitCount) | Specifies the number of bits-per-pixel. See "Interpreting the Color Table," later in this section, for more information.
|
The following fields are present only in the Windows 3.0 BITMAPINFOHEADER structure:
| Field | Description |
| biCompression | Specifies the type of compression for a compressed bitmap. It can be one of the following values: |
| Value Meaning BI_RGB Specifies that the bitmap is not compressed. BI_RLE4 Specifies a run-length encoded format for bitmaps with 4 bits-per-pixel. The compression format is a two-byte format consisting of a count byte followed by two word-length color indexes. BI_RLE8 Specifies a run-length encoded format for bitmaps with 8 bits-per-pixel. The compression format is a two-byte format consisting of a count byte followed by a color-index byte. See "Windows 3.0 Bitmap Compression Formats" later in this document for information about the encoding schemes.
|
|
| biSizeImage | Specifies the size in bytes of the image. |
| biXPelsPerMeter | Specifies the horizontal resolution in pixels per meter of the target device for the bitmap. An application can use this value to select a bitmap from a resource group that best matches the characteristics of the current device. |
| biYPelsPerMeter | Specifies the vertical resolution in pixels per meter of the target device for the bitmap. |
| biClrUsed | Specifies the number of color values in the color table actually used by the bitmap. Possible values follow. Value Result 0 Bitmap uses the maximum number of colors corresponding to the value of the wBitCount field. Nonzero If the wBitCount value is less than 24, the biClrUsed value indicates the actual number of colors which the graphics engine or device driver will access. If the wBitCount value is 24, the biClrUsed value indicates the size of the reference color table used to optimize performance of Windows color palettes. If the bitmap is a "packed" bitmap (that is, a bitmap in which the bitmap array immediately follows the BITMAPINFO header and which is referenced by a single pointer), the biClrUsed field must be set to 0 or to the actual size of the color table. See "Interpreting the Color Table," later in this section, for more information on how this field affects the interpretation of the color table.
|
| biClrImportant | Specifies the number of color indexes that are considered important for displaying the bitmap. If this value is 0, then all colors are important.
|
The color table is a collection of 24-bit RGB values. There are as many entries in the color table as there are colors in the bitmap. The color table isn't present for bitmaps with 24 color bits because each pixel is represented by 24-bit RGB values in the actual bitmap data area. Color table;and bitmap colors[bitmap]DIB files;bitmap color tableRGBQUAD data structure;in DIB fileRGBTRIPLE data structure;in DIB file
The color table for Windows 3.0 and Presentation Manager 1.2 DIBs consists of an array of RGBQUAD and RGBTRIPLE structures, respectively. These structures are defined as follows:
| Windows 3.0 DIB | Presentation Manager 1.2 DIB |
| typedef struct tagRGBQUAD { BYTE rgbBlue; BYTE rgbGreen; BYTE rgbRed; BYTE rgbReserved; } RGBQUAD; |
typedef struct tagRGBTRIPLE { BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; } RGBTRIPLE;
|
Because these structures are essentially alike, this section discusses them simultaneously. Each field name for the Windows RGBQUAD structure is followed by the corresponding field name for the Presentation Manager RGBTRIPLE structure, in parentheses.
The colors in the table should appear in order of importance. This can help a device driver render a bitmap on a device that cannot display as many colors as there are in the bitmap. If the DIB is in Windows 3.0 format, the driver can use the biClrImportant field of the BITMAPINFOHEADER structure to determine which colors are important. Color table;color orderRGB values;color table intensityColor table;color intensityBITMAPINFOHEADER data structure;bitmap color importance
The RGBQUAD (RGBTRIPLE) structure contains the following fields:
| Windows (PM) Field | Description |
| rgbBlue (rgbtBlue) | Specifies the blue intensity. |
| rgbGreen (rgbtGreen) | Specifies the green intensity. |
| rgbRed (rgbtRed) | Specifies the red intensity. |
| rgbReserved (no PM equivalent) |
Not used. Must be set to 0.
|
An application can use the biSize (bcSize) field of the BITMAPINFOHEADER (BITMAPCOREHEADER) structure to locate the color table. Each of the following statements assigns the pColor variable the byte offset of the color table from the beginning of the file:BITMAPINFOHEADER data structure;color table locationBITMAPCOREHEADER data structure;color table location
// Windows 3.0 DIB
pColor = (LPSTR)pBitmapInfo + (WORD)pBitmapInfo->biSize
// Presentation Manager 1.2 DIB
pColor = (LPSTR)pBitmapCoreInfo + (WORD)pBitmapCoreInfo->bcSize
The biSize (bcSize) field of the BITMAPINFOHEADER (BITMAPCOREHEADER) structure specifies how many bits define each pixel and specifies the maximum number of colors in the bitmap. Its value affects your interpretation of the color table. BITMAPINFOHEADER data structure;color definitionBITMAPCOREHEADER data structure;color definitionColor table;defining number of colors
The biSize (bcSize) field can have any of the following values:
| Value | Meaning |
| 1 | The bitmap is monochrome, and the color table contains two entries. Each bit in the bitmap array represents a pixel. If the bit is clear, the pixel is displayed with the color of the first entry in the color table. If the bit is set, the pixel has the color of the second entry in the table. |
| 4 | The bitmap has a maximum of 16 colors. Each pixel in the bitmap is represented by a four-bit index into the color table. For example, if the first byte in the bitmap is 0x1F, then the byte represents two pixels. The first pixel contains the color in the second table entry, and the second pixel contains the color in the 16th table entry.
|
| 8 | The bitmap has a maximum of 256 colors. Each pixel in the bitmap is represented by a byte-sized index into the color table. For example, if the first byte in the bitmap is 0x1F, then the first pixel has the color of the thirty-second table entry. |
| 24 | The bitmap has a maximum of 224 colors. The bmiColors (bmciColors) field is NULL, and each three bytes in the bitmap array represent the relative intensities of red, green, and blue, respectively, of a pixel.
|
For Windows 3.0 DIBs, the field of the BITMAPINFOHEADER structure specifies the number of color indexes in the color table actually used by the bitmap. If the biClrUsed field is set to 0, the bitmap uses the maximum number of colors corresponding to the value of the field.
The bits in the array are packed together, but each line of pixels, or scan line, must be zero-padded to end on a LONG boundary. When the bitmap is in memory, segment boundaries can appear anywhere in the bitmap. The origin of the bitmap is the lower-left corner. The following section discusses compression formats for the Windows 3.0 bitmap data.
Windows supports run-length encoded formats for compressing 4- and 8-bit bitmaps. Compression reduces the disk and memory storage required for the bitmap. The following sections describe the compression formats. DIB files;Windows compression formats
When the biCompression field is set to BI_RLE8, the bitmap is compressed using a run-length encoding format for an 8-bit bitmap. This format uses two modes:Compression format;8-bit DIBs[eight]Run-length encoded format;8-bit DIBs[eight]
* Encoded mode
* Absolute mode
Both modes can occur anywhere throughout a single bitmap.
Encoded mode consists of two bytes. The first byte specifies the number of consecutive pixels to be drawn using the color index contained in the second byte. Encoded mode;8-bit DIBs[eight]
Also, the first byte of the pair can be set to zero to indicate an escape that denotes an end of line, end of bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair. In encoded mode, the second byte has a value of 0 to 2.
The following table shows the meaning of the second byte:
| Second Byte | Meaning |
| 0 | End of line. |
| 1 | End of bitmap. |
| 2 | Delta. The two bytes following the escape contain unsigned values indicating the horizontal and vertical offset of the next pixel from the current position.
|
Absolute mode is signalled by the first byte set to zero and the second byte set to a value between 03H and FFH.
The second byte represents the number of bytes that follow, each of which contains the color index of a single pixel. Absolute mode;8-bit DIBs[eight]
Each run must be aligned on a word boundary.
The following example shows the hexadecimal values of an 8-bit RLE bitmap. Under "Expanded Data," the two-digit values represent a color index for a single pixel.
| Compressed Data | Expanded Data |
| 03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01 |
04 04 04 06 06 06 06 06 45 56 67 78 78 move 5 right and 1 down 78 78 end of line 1E 1E 1E 1E 1E 1E 1E 1E 1E end of RLE bitmap
|
When the field is set to BI_RLE4, the bitmap is compressed using a run-length encoding format for a 4-bit bitmap. This format uses two modes:Compression format;4-bit DIBs[four]
* Encoded mode
* Absolute mode
In encoded mode, the first byte of the pair contains the number of pixels to be drawn using the color indexes in the second byte.
The second byte contains two color indexes, one in its high-order nibble (that is, its low-order four bits) and one in its low-order nibble.
The first of the pixels is drawn using the color specified by the high-order nibble, the second is drawn using the color in the low-order nibble, the third is drawn with the color in the high-order nibble, and so on, until all the pixels specified by the first byte have been drawn.
Also, the first byte of the pair can be set to zero to indicate an escape that denotes an end of line, end of bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair. In encoded mode, the second byte has a value from 00H to 02H.
In absolute mode, the first byte contains zero, the second byte contains the number of color indexes that follow, and subsequent bytes contain color indexes in their high- and low-order nibbles, one color index for each pixel.
Each run must be aligned on a word boundary.
The end-of-line, end-of-bitmap, and delta escapes valid for BI_RLE8 also apply to BI_RLE4.
The following example shows the hexadecimal values of a 4-bit RLE bitmap. Under "Expanded Data," the one-digit values represent a color index for a single pixel.
| Compressed Data | Expanded Data |
| 03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01 |
0 4 0 0 6 0 6 0 4 5 5 6 6 7 7 8 7 8 move 5 right and 1 down 7 8 7 8 end of line 1 E 1 E 1 E 1 E 1 end of RLE bitmap
|
This document describes two types of RIFF Device-Independent Bitmap (RDIB) format:
* A simple RDIB consisting of a DIB file enclosed in a RIFF chunk.
* An extended RDIB that allows the creation of more complex bitmaps
To ensure that the maximum number of programs will accept an RDIB file, programs that adopt the extended RDIB format should also accept simple RDIB files. Both formats are described in the following sections.
The simple RDIB format consists of a Windows 3.0 or Presentation Manager 1.2 DIB enclosed in a 'RIFF' chunk. Enclosing the DIB in a 'RIFF' chunk allows the file to be consistently identified; for example, an 'INFO' list can be included in the file.
The simple 'RDIB' form is defined as follows, using the standard RIFF form definition notation:DIB files;RDIB formatRIFF files;RDIB formRDIB file format File formats;RIFF Device-Independent Bitmap (RDIB)RDIB files;description
<RDIB-form> Ý RIFF ( 'RDIB' data( <DIB-data> ))
The <DIB-data> format is defined in "Device Independent Bitmap File Format," earlier in this chapter.
The extended RDIB format, designed to incorporate enhancements such as compression, is defined as follows:
<RDIB-form> Ý
RIFF('RDIB'
<bmhd-ck> // Bitmap header chunk
[ <pal-file> | // Internal palette chunk
<XPAL-ck> ] // External palette chunk
<bitmap-data> ) // Bitmap data
The <pal-file> chunk can be any of the palette-file formats discussed in "Palette File Format," later in this chapter. The <bmhd-ck>, <XPAL-chunk>, and <bitmap-data> are described in the following sections.
The <bmhd-ck> bitmap header chunk is defined as follows:
<bmhd-chunk> Ý bmhd( struct {
DWORD dwMemSize; // If dwPelFormat is 'data', only these
DWORD dwPelFormat; // four fields are present.
WORD wTransType;
DWORD dwTransVal;
DWORD dwHdrSize; // Fields from dwHdrSize forward match
DWORD dwWidth; // the Windows BITMAPINFOHEADER
DWORD dwHeight; // structure, though some fields can
WORD dwPlanes; // contain new values.
WORD dwBitCount;
DWORD dwCompression;
DWORD dwSizeImage;
DWORD dwXPelsPerMeter;
DWORD dwYPelsPerMeter;
DWORD dwClrUsed;
DWORD dwClrImportant;
} )
If the dwCompression field equals BI_RGB or BI_RLE8 or BI_RLE4, then the extended RDIB has the same bitmap format as a simple RDIB.
Each pixel format defines the orientation, or position of the bitmap origin. Windows bitmaps (identified by a value of 'data' in the dwPelFormat field) have the origin at the bottom left. By default, the other formats have the origin at the top left.
| Field | Description | |
| dwMemSize | Equal to the size of the bitmap bits if the bits are uncompressed. For RDIBs with dwPelFormat equal to 'data,' dwMemSize has one of the following values: |
|
| Image Type | Field Value | |
| Non-RLE | Same as dwSizeImage value | |
| 8-bit RLE | Size as an uncompressed, 8-bit image | |
| 4-bit RLE | Size as an uncompressed, 4-bit image
|
|
| dwPelFormat | Specifies a FOURCC code defining the pixel format of the bitmap data. The bitmap data is stored in a chunk (or chunks) that has the same chunk ID as is contained in dwPelFormat. The compression scheme and pixel depth of the bitmap data are recorded in the dwCompression and dwBitCount fields. The current bitmap data values are as follows: |
|
| Value | Bitmap Data Location and Format | |
| 'data' | Bitmap data is stored in a 'data' chunk using the format defined for Windows 3.0 device independent bitmaps (DIBs). An application can display the bitmap properly even if the fields after (and including) dwMemSize are ignored. | |
| 'palb' | Bitmap data is stored in a 'palb' chunk. The pixel format is one of the Windows 3.0 RGB palettized formats (1 to 8 bpp, depending on the value of the dwBitCount field). | |
| 'rgbb' | Bitmap data is stored in a 'rgbb' chunk. Pixel format is packed, unpalettized RGB represented at 16, 24, or 32 bits per pixel. The following shows the ordering of the RGB bits for each pixel-depth value. The first extra bit (if present) is the high-order bit. dwBitCount Extra Red Green Blue 15 1 5 5 5 16 0 5 6 5 24 0 8 8 8 32 8 8 8 8
|
|
| 'yuvb' | Bitmap data is stored in a 'yuvb' chunk. Pixel format is packed, unpalettized YUV. The exact pixel format is currently undefined. By the time this draft is final, the pixel format will be defined similarly to the 'rgbb' definition.
|
|
| wTransType | Specifies the type of transparency representation, if any, used for this image. This is normally used for either image overlay applications, where one image may be visually on top of another, and all pels of the transparency color should not be drawn. Examples include sprites, clip art and motion video overlay. Wherever the transparency color occurs in the picture, the background should be visible. This information is stored with the image, so that multiple images that use the same color map may all have different transparency color. There are 5 different values for the transparency variable. These are: |
|
| Value | Result | |
| BITT_NONE (0x0000) |
No pels are considered transparent in this image.
|
|
| BITT_MAPINDEX (0x0001) |
One of the color map/palette entries should be considered the transparency color. All instances of this pel should NOT be drawn, and the existing background should be allowed to show through.
|
|
| BITT_SINGLECOLOR (0x0002) | A single RGB or YUV value is considered transparent and should not be drawn. | |
| BITT_BITPLANE (0x0003) |
An individual bit plane is considered transparent, and all pels that have that bit or bits "on" should not be drawn.
|
|
| BITT_MULTILEVEL (0x0004) |
A set of bits indicate multiple levels of transparency or opacity. This is usually used with 32-bit RGB, where the high 8 bits indicate transparency.
|
|
| dwTransVal | These bytes allow the image definition to indicate the exact information about the transparent color. The information is dependent on the value of the wTransType as follows: |
|
| wTransType | dwTransVal Contents | |
| BITT_NONE | Not used. | |
| BITT_MAPINDEX | Specifies a palette index, either 0 through 16 or 0 through 255, depending on the number of palette entries. | |
| BITT_SINGLECOLOR | Specifies an RGB or YUV value (2 to 4 bytes in size, depending on the pixel format specified by dwPelFormat). All pels that match dwTransVal should be considered transparent. | |
| BITT_BITPLANE | Specifies a bit mask identifying the bits used to indicate a transparent pel. Any pel that has this set of bits set is totally transparent. This allows multiple colors to be considered transparent. This method works for palettized images; in this case, the value refers to a map entry that is considered transparent. | |
| BITT_MULTILEVEL | Specifies bits to use for transparency levels. These bits act as a mask on every pel, and each pel can be matched to the mask to determine the transparency level for the pel. For example, if dwTransVal has value 0xFF000000, then there are 256 levels of transparency. Each pel can be evaluated against the mask. If the pel has a value FFxxxxxx, then it is fully transparent. If the pel has a value 00xxxxxx, then it is fully visible. If the pel has a value 7Fxxxxxx, then the pel is half visible.
|
|
| dwHdrSize | Specifies the size of the data portion of the <bmhdr> chunk. This is always 40, the size of the BITMAPINFOHEADER structure. | |
| dwWidth | Specifies the width of the DIB in pixels. | |
| dwHeight | Specifies the height of the DIB in pixels. | |
| wPlanes | Specifies the number of planes. This value is normally 1, but it can be 3 or 4 for 24-bit RGB and 32-bit RGB images, respectively. In a multiplane DIB, each color component (for example, red, green, and blue) is stored as a separate plane, and each plan is stored in a separate bitmap data chunk. For example, in a 3-plane, 24-bit 'rgbb' bitmap, the red colors are stored in one 'rgbb' chunk, the green colors in a second 'rgbb' chunk, and the blue colors in a third 'rgbb' chunk. Allowing the separate RGB planes to be compressed independently can dramatically improve the compression ratio. The wPlanes value must be 1 if dwPelFormat equals 'data'. |
|
| wBitCount | Specifies the number of bits per pixel. If the dwPelFormat field equals 'data', this field must contain values compatible with the Windows 3.0 DIB definition. | |
| dwCompression | Specifies the type of compression for a compressed bitmap. It can be one of the following values: |
|
| Value | Meaning | |
| BI_NONE (0xFFFF0000) |
Specifies that the bitmap is not compressed. Pixel values are not padded to four-byte boundaries.
|
|
| BI_RGB (0x00000000) |
Specifies that the bitmap is an uncompressed, 1-, 4-, 8-, or a 24-bit image. For 24-bit images, the palette is optional. Bitmap bits are represented as defined by Windows 3.0 for BI_RGB DIBs. The dwPelFormat field must be set to 'data'.
|
|
| BI_RLE8 (0x00000001) |
Specifies a run-length encoded, compressed bitmap (as defined by Windows 3.0 BI_RLE8 DIBs). The palette is required. The dwPelFormat field must be set to 'data'.
|
|
| BI_RLE4 (0x00000002) |
Specifies a run-length encoded, compressed bitmap (as defined by Windows 3.0 BI_RLE4 DIBs). The palette is required. The dwPelFormat field must be set to 'data'.
|
|
| BI_PACK (0xFFF0001) |
Specifies a simple PACKBITS byte compression scheme consisting of one-byte counts followed by byte data, in the form: <count byte n><data byte1><data byte2>...<data byte n> <count byte n><data byte to repeat> The high-order bit of the count byte n is a decision bit: n Value Data Representation n < 0x80 A run of n+1 non-repeating bytes follows. n > 0x80 Data byte is repeated (n-0x80+1) times. n = 0x80 Reserved.
|
|
| BI_TRANS (0xFFFF0002) |
Specifies transitional compression, using a table of byte transitions or sequences. See "Transitional Compression," following this table.
|
|
| BI_CCC (0xFFFF0003) |
Specifies CCC compression, a method involving encoding each 4-by-4 block of the image using two colors. See "CCC Compression," following this table.
|
|
| BI_JPEGN (0xFFFF0004) | To be defined later, when the ISO completes the official specification.
|
|
| dwSizeImage | Specifies the size in bytes of the compressed image. | |
| dwXPelsPerMeter | Specifies the horizontal resolution in pixels per meter of the target device for the bitmap. An application can use this value to select a bitmap from a resource group that best matches the characteristics of the current device. This field is set to zero if unused. | |
| dwYPelsPerMeter | Specifies the vertical resolution in pixels per meter of the target device for the bitmap. This field is set to zero if unused. | |
| dwClrUsed |