Saettler's Ton-O-Info
[ Home ] [ 1998 Monolith Company Party ] [ Additional RIFF Documentation ] [ IBM/MS RIFF/MCI Specification 1.0 ] [ Working with a Big Publisher ] [ Saettler's WW2GI Info ]

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

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.

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

Notation<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

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
\'	39	Single quote
\"	34	Double quote
\ddd	Octal ddd	Arbitrary character

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

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

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

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."

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).

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

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

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.

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.

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.

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.

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.

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.

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;

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;

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.

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.

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;

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.

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.

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.

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

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

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	Specifies the number of palette entries 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 is less than 24, dwClrUsed specifies the actual number of colors which the graphics engine or device driver will access. If the wBitCount field is set to 24, dwClrUsed specifies the size of the reference color table used to optimize performance of Windows color palettes.
dwClrImportant	Specifies the number of color indexes that are considered important for displaying the bitmap. If this value is 0, then all colors are important.

fccLocation Value	Chunk Location
‘full’	Palette is located in an external file, and the szPaletteName value specifies a complete filename with path.
‘file’	Palette is located in an external file, and the szPaletteName value specifies a filename without path.
‘elem’	Palette is located in the same compound file containing the DIB. The szPaletteName value specifies the name of the compound file element.

Field	Description
palVersion	Specifies the Windows version number for the structure.
palNumEntries	Specifies the number of palette color entries.
palPalEntry[]	Specifies an array of PALETTEENTRY data structures that define the color and usage of each entry in the logical palette.

Field	Description
peRed	Specifies the intensity of red for the palette entry color.
peGreen	Specifies the intensity of green for the palette entry color.
peBlue	Specifies the intensity of blue for the palette entry color.
peFlags	Specifies how the palette entry is to be used.

Field	Description
dwMapType	FOURCC code specifying the type of palette. Currently, the following palette types are identified: Code Description ‘data’ Specifies an RGB palette. Data chunk contains a LOGPALETTE structure. ‘yuvp’ Specifies a YUV palette. Data chunk contains a YUV palette. ‘xyzp’ Specifies an XYZ palette. Data chunk contains a XYZ palette.
wWhite wBlack	Specify palette-map indices corresponding to the closest value of white and black. These identify the pair of colors with the best contrast for use in cursors, calibration, etc. These values are usually changed if the palette changes. Ignore these fields if they contain 0xFFFF.
wBorder	Specifies the index of the palette entry to be used for any display-border regions, if supported by the display device. Ignore this field if it contains 0xFFFF.
wRegisteredMap	Specifies how many palette entries correspond to a registered color map. Registered entries are stored at the front of the palette. Ignore this field if it contains 0xFFFF.
	Registered map entries are always stored at the beginning of the palette, so wRegisteredMap also indicates the index of the first custom color in the palette. Registered color maps include predefined palettes for general use, forest/nature, or seasides. Currently defined values are the following: Value Description PAL_UNREGISTERED (0xFFFF) Color map does not contain colors from a registered color map. PAL_VGA (0x0000) Color map contains the standard 16 VGA colors. PAL_AVC198 (0x0001) Standard AVC 198-entry palette.
wCustomBase	Specifies the index of the first custom color of the palette. The beginning of the palette contains the entries of the registered map, so wCustomBase also indicates the number of entries in the registered palette. Map entries starting with wCustomBase comprise additional custom colors used in the bitmap. Ignore this value if wRegisteredPalette is PAL_UNREGISTERED, or if wCustomBase contains 0xFFFF.
wCustomCnt	Specifies the number of custom colors in the palette. Ignore this value if wRegisteredPalette is PAL_UNREGISTERED, or if this field contains 0xFFFF.
wRsvBase	Specifies the index of the first reserved color of the palette. Reserved colors are those reserved for menus, text, and other screen elements. Reserved colors must be stored contiguously. Ignore this field if it contains 0xFFFF.
wRsvCnt	Specifies the number of reserved entries. Ignore this field if it contains 0xFFFF.
wArtBase	Specifies the index of the first art color of the palette. Art colors are colors used for text and drawing. Art colors consist of a number of hues, each of which has multiple intensities. The various intensities are used for anti-aliasing, a method of using different shades of a color to improve the quality of images displayed on low-resolution devices. For example, if the first art color is red anti-aliased to black with three intensities, the first three entries in the palette would be dark red, medium red, and bright red. The art colors constitute an array, and all hues have the same number of intensities. The user can set both the number of hues and the number of intensities. Ignore these fields if they contain 0xFFFF.
wArtCnt	Specifies the number of art colors. Ignore this field if it contains 0xFFFF.
wNumIntense	Specifies the number of palette entries reserved for the anti-aliased levels of a given art color. This field must be present if wArtBase is present. Ignore this field if it contains 0xFFFF.

Field	Description
wFormatTag	A number indicating the WAVE format category of the file. The content of the <format-specific-fields> portion of the ‘fmt’ chunk, and the interpretation of the waveform data, depend on this value. You must register any new WAVE format categories. See "Registering Multimedia Formats" in Chapter 1, "Overview of Multimedia Specifications," for information on registering WAVE format categories. "Wave Format Categories," following this section, lists the currently defined WAVE format categories.
wChannels	The number of channels represented in the waveform data, such as 1 for mono or 2 for stereo.
dwSamplesPerSec	The sampling rate (in samples per second) at which each channel should be played.
dwAvgBytesPerSec	The average number of bytes per second at which the waveform data should be transferred. Playback software can estimate the buffer size using this value.
wBlockAlign	The block alignment (in bytes) of the waveform data. Playback software needs to process a multiple of wBlockAlign bytes of data at a time, so the value of wBlockAlign can be used for buffer alignment.

wFormatTag Value	Format Category
WAVE_FORMAT_PCM (0x0001)	Microsoft Pulse Code Modulation (PCM) format

wFormatTag Value	Format Category
IBM_FORMAT_MULAW (0x0101)	IBM mu-law format
IBM_FORMAT_ALAW (0x0102)	IBM a-law format
IBM_FORMAT_ADPCM (0x0103)	IBM AVC Adaptive Differential Pulse Code Modulation format

Sample Size	Data Format	Maximum Value	Minimum Value
One to eight bits	Unsigned integer	255 (0xFF)	0
Nine or more bits	Signed integer i	Largest positive value of i	Most negative value of i

Format	Maximum Value	Minimum Value	Midpoint Value
8-bit PCM	255 (0xFF)	0	128 (0x80)
16-bit PCM	32767 (0x7FFF)	-32768 (-0x8000)	0

Field	Description
dwName	Specifies the cue point name. Each <cue-point> record must have a unique dwName field.
dwPosition	Specifies the sample position of the cue point. This is the sequential sample number within the play order. See "Playlist Chunk," later in this document, for a discussion of the play order.
fccChunk	Specifies the name or chunk ID of the chunk containing the cue point.
dwChunkStart	Specifies the file position of the start of the chunk containing the cue point. This is a byte offset relative to the start of the data section of the ‘wavl’ LIST chunk.
dwBlockStart	Specifies the file position of the start of the block containing the position. This is a byte offset relative to the start of the data section of the ‘wavl’ LIST chunk.
dwSampleOffset	Specifies the sample offset of the cue point relative to the start of the block.

Cue Point Location	Field	Value
In a ‘slnt’ chunk	fccChunk	FOURCC value ‘slnt’.
	dwChunkStart	File position of the ‘slnt’ chunk relative to the start of the data section in the ‘wavl’ LIST chunk.
	dwBlockStart	File position of the data section of the ‘slnt’ chunk relative to the start of the data section of the ‘wavl’ LIST chunk.
	dwSampleOffset	Sample position of the cue point relative to the start of the ‘slnt’ chunk.
In a PCM ‘data’ chunk	fccChunk	FOURCC value ‘data’.
	dwChunkStart	File position of the ‘data’ chunk relative to the start of the data section in the ‘wavl’ LIST chunk.
	dwBlockStart	File position of the cue point relative to the start of the data section of the ‘wavl’ LIST chunk.
	dwSampleOffset	Zero value.
In a compressed ‘data’ chunk	fccChunk	FOURCC value ‘data’.
	dwChunkStart	File position of the start of the ‘data’ chunk relative to the start of the data section of the ‘wavl’ LIST chunk.
	dwBlockStart	File position of the enclosing block relative to the start of the data section of the ‘wavl’ LIST chunk. The software can begin the decompression at this point.
	dwSampleOffset	Sample position of the cue point relative to the start of the block.

Cue Point Location	Field	Value
Within PCM data	fccChunk	FOURCC value ‘data’.
	dwChunkStart	Zero value.
	dwBlockStart	Zero value.
	dwSampleOffset	Sample position of the cue point relative to the start of the ‘data’ chunk.
In a compressed ‘data’ chunk	fccChunk	FOURCC value ‘data’.
	dwChunkStart	Zero value.
	dwBlockStart	File position of the enclosing block relative to the start of the ‘data’ chunk. The software can begin the decompression at this point.
	dwSampleOffset	Sample position of the cue point relative to the start of the block.

Field	Description
dwName	Specifies the cue point name. This value must match one of the names listed in the <cue-ck> cue-point table.
dwLength	Specifies the length of the section in samples.
dwLoops	Specifies the number of times to play the section.

Field	Description
dwName	Specifies the cue point name. This value must match one of the names listed in the <cue-ck> cue-point table.
data	Specifies a NULL-terminated string containing a text label (for the ‘labl’ chunk) or comment text (for the ‘note’ chunk).

Field	Description
dwName	Specifies the cue point name. This value must match one of the names listed in the <cue-ck> cue-point table.
dwSampleLength	Specifies the number of samples in the segment of waveform data.
dwPurpose	Specifies the type or purpose of the text. For example, dwPurpose can specify a FOURCC code like ‘scrp’ for script text or ‘capt’ for close-caption text.
wCountry	Specifies the country code for the text. See "Country Codes" in Chapter 2, "Resource Interchange File Format," for a current list of country codes.
wLanguage, wDialect	Specify the language and dialect codes for the text. See "Language and Dialect Codes" in Chapter 2, "Resource Interchange File Format," for a current list of language and dialect codes.
wCodePage	Specifies the code page for the text.

Field	Description
dwName	Specifies the cue point name. This value must match one of the names listed in the <cue-ck> cue-point table.
dwMedType	Specifies the file type contained in the fileData field. If the fileData section contains a RIFF form, the dwMedType field is the same as the RIFF form type for the file. This field can contain a zero value.
fileData	Contains the media file.