|
Saettler's Ton-O-Info
|
|
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. Contents Chapter 1 Overview of Multimedia Specifications Resource Interchange File Format 1-1 Multimedia File Formats 1-1 Media Control Interface 1-2 Registering Multimedia Formats 1-2 Chapter 2 Resource Interchange File Format About the RIFF Tagged File Format 2-1 Notation Conventions 2-1 Chunks 2-2 RIFF Forms 2-3 Defining and Registering RIFF Forms 2-3 Registered Form and Chunk Types 2-4 Unregistered (Form-Specific) Chunk Types 2-4 Notation for Representing Sample RIFF Files 2-5 Basic Notation for Representing RIFF Files 2-5 Escape Sequences for Four-Character Codes and String Chunks 2-7 Extended Notation for Representing RIFF Form Definitions 2-8 Atomic Labels 2-10 A Sample RIFF Form Definition and RIFF Form 2-11 Storing Strings in RIFF Chunks 2-12 NULL-Terminated String (ZSTR) Format 2-12 String Table Format 2-13 NULL-Terminated, Byte Size Prefix String (BZSTR) Series 2-13 Multiline String Format 2-13 Choosing a Storage Method 2-13 LIST Chunk 2-14 INFO List Chunk 2-14 CSET (Character Set) Chunk 2-16 Country Codes 2-16 Language and Dialect Codes 2-17 JUNK (Filler) Chunk 2-18 Compound File Structure 2-18 Structural Overview 2-19 Compound File Table of Contents (CTOC) Chunk 2-19 Structural Overview 2-19 Header Information 2-21 Parameter Table Definition 2-21 Header Parameter Table 2-22 CTOC Table Entries 2-22 Usage Codes for Extra Header and Extra Entry Fields 2-24 Compression of Compound File Elements 2-26 Compound File Element Group (CGRP) Chunk 2-27 Placement of the CTOC and CGRP Chunks 2-27 Chapter 3 Multimedia File Formats Bundle File Format 3-1 Device Independent Bitmap File Format 3-1 Overview of DIB Structure 3-2 Bitmap File Header 3-2 Bitmap Information Header 3-3 Information Header Structures 3-4 Bitmap Color Table 3-6 Color Table Structure 3-6 Order of Colors 3-6 Field Descriptions 3-6 Locating the Color Table 3-7 Interpreting the Color Table 3-7 Bitmap Data 3-8 Windows 3.0 Bitmap Compression Formats 3-8 Compression of 8-Bit-Per-Pixel DIBs 3-8 Compression of 4-Bit-Per-Pixel DIBs 3-9 RIFF Device-Independent Bitmap File Format 3-10 Simple RDIB Format 3-10 Extended RDIB Format 3-10 Bitmap Header Chunk 3-11 Transitional Compression 3-16 CCC Compression 3-17 Palette Chunk 3-17 External Palette Chunk 3-17 Bitmap Data Chunk 3-17 MIDI and RIFF MIDI File Formats 3-18 Palette File Format 3-18 Simple PAL Format 3-18 Extended PAL Format 3-19 Rich Text Format (RTF) 3-22 Waveform Audio File Format (WAVE) 3-22 WAVE Format Chunk 3-22 WAVE Format Categories 3-23 Pulse Code Modulation (PCM) Format 3-24 Storage of WAVE Data 3-26 FACT Chunk 3-26 Cue-Points Chunk 3-27 Examples of File Position Values 3-28 Playlist Chunk 3-29 Associated Data Chunk 3-29 Label and Note Information 3-30 Text with Data Length Information 3-30 Embedded File Information 3-31 Chapter 4 Media Control Interface MCI Command Strings 4-1 Example of MCI Command Use 4-2 Categories of MCI Command Strings 4-2 Command Syntax Conventions 4-3 System Commands 4-3 Required Commands 4-3 Basic Commands 4-4 Extended Commands 4-4 Extended Commands Reserved for Future Use 4-4 Creating a Command String 4-5 About MCI Device Types 4-6 Using MCI Command Strings 4-6 Opening a Device 4-6 Opening Simple Devices 4-7 Opening Compound Devices 4-7 Using the Shareable Flag 4-8 Using the Alias Flag 4-8 Opening New Device Elements 4-8 Closing a Device 4-8 Shortcuts and Variations for MCI Commands 4-9 Using All as a Device Name 4-9 Combining the Device Type and Device Element Name 4-9 Automatic Open 4-9 Automatic Close 4-9 Using Wait and Notify Flags 4-10 Using the Notify Flag 4-10 Obtaining Information From MCI Devices 4-11 The Play Command 4-11 Stop, Pause, and Resume Commands 4-11 MCI System Commands 4-12 Required Commands for All Devices 4-13 Basic Commands for Specific Device Types 4-14 CD Audio (Redbook) Commands 4-17 MIDI Sequencer Commands 4-20 Videodisc Player Commands 4-25 Waveform Audio Commands 4-29
Chapter 1 Overview of Multimedia Specifications 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. Resource Interchange File Format 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. Multimedia File Formats 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 Media Control Interface 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. Registering Multimedia Formats 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: Microsoft Corporation The Multimedia Developer Registration Kit also lists currently defined multimedia elements.
Chapter 2 Resource Interchange File Format 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. About the RIFF Tagged File Format 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. Notation Conventions 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."
Chunks The basic building block of a RIFF file is called a chunk. Using C syntax, a chunk can be defined as follows: typedef unsigned long DWORD; 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. 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:
We can represent a chunk with the following notation (in this example, the ckSize and pad byte are implicit): <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>. RIFF Forms 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."
Using the notation for representing a chunk, a RIFF form looks like the following: 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: • 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 Defining and Registering RIFF Forms 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. Registered Form and Chunk Types 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. 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. Unregistered (Form-Specific) Chunk Types 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." Notation for Representing Sample RIFF Files 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. Basic Notation for Representing RIFF Files The following table summarizes the elements of the RIFF notation required for representing sample RIFF files:
Escape Sequences for Four-Character Codes and String Chunks The following escape sequences can be used in four-character codes and string chunks:
Extended Notation for Representing RIFF Form Definitions To unambiguously define the structure of new RIFF forms, document the RIFF form using the basic notation along with the following extended notation:
Atomic Labels 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.
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. Note: The WINDOWS.H header file defines the C types BYTE, WORD, LONG, and DWORD. These types correspond to labels <BYTE>, <WORD>, <LONG>, and <DWORD>, respectively.A Sample RIFF Form Definition and RIFF Form 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. <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 Sample RIFF Form The following sample RIFF form adheres to the form definition for form type GOBL. The file contains three subchunks: • 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. 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' Storing Strings in RIFF Chunks 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. NULL-Terminated String (ZSTR) Format 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. String Table Format 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 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. NULL-Terminated, Byte Size Prefix String (BZSTR) Series 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. Multiline String Format 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. Choosing a Storage Method The following lists guidelines for deciding which storage method is appropriate for your application.
LIST Chunk 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. INFO List Chunk 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) 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.
CSET (Character Set) Chunk 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:
Country Codes Use one of the following country codes in the wCountryCode field:
Language and Dialect Codes Specify one of the following pairs of language-code and dialect-code values in the wLanguage and wDialect fields:
JUNK (Filler) Chunk 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. Compound File Structure 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. Structural Overview 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. Compound File Table of Contents (CTOC) Chunk 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. Structural Overview 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. Header Information The header information section defines general information about the CTOC header and about the entire compound file. It contains the following fields:
Parameter Table Definition The parameter table definition defines the size and contents of the header parameter table and CTOC table. It contains the following fields:
Header Parameter Table The header parameter table is an optional component generally used to define attributes of the entire compound file.
CTOC Table Entries 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:
Usage Codes for Extra Header and Extra Entry Fields 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.
Compression of Compound File Elements 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. Compound File Element Group (CGRP) Chunk 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>]...)Placement of the CTOC and CGRP Chunks 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 3 Multimedia File Formats 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) Bundle File Format 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). Device Independent Bitmap File Format 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. 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. Overview of DIB Structure Windows 3.0 and Presentation Manager 1.2 DIB files consist of the following sequence of data structures: • 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. Bitmap File Header 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: typedef struct tagBITMAPFILEHEADER { The following table describes the fields.
Bitmap Information Header 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:
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.
Information Header Structures 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:
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. Common Fields The following fields are present in both the Windows 3.0 and Presentation Manager 1.2 formats:
Windows Fields The following fields are present only in the Windows 3.0 BITMAPINFOHEADER structure:
Bitmap Color Table 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 Structure 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:
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. Order of Colors 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. Field Descriptions The RGBQUAD (RGBTRIPLE) structure contains the following fields:
Locating the Color Table 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: // Windows 3.0 DIB Interpreting the Color Table 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. The biSize (bcSize) field can have any of the following values:
Note on Windows DIBs 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||