RIFF Multimedia Movie
| Line 26: | Line 26: | ||
As usual for the RIFF format, the RMMP file is organized into several "subchunks" of the RIFF chunk. However, unlike other RIFF types, there is no LIST chunk, and all chunks strictly follow a set of additions to the RIFF chunk definition here unofficially called "section" for clarity. | As usual for the RIFF format, the RMMP file is organized into several "subchunks" of the RIFF chunk. However, unlike other RIFF types, there is no LIST chunk, and all chunks strictly follow a set of additions to the RIFF chunk definition here unofficially called "section" for clarity. | ||
| + | |||
| + | Some versions of MMM use mostly uppercase chunk names like "VWCF", while other (newer?) versions use mostly lowercase names like "vwcf". | ||
A single section's record in the file consists of: | A single section's record in the file consists of: | ||
* [[FourCC|The 4-byte chunk/section type identifier, normal for RIFF.]] In RMPP, these are restricted to lowercase ASCII. | * [[FourCC|The 4-byte chunk/section type identifier, normal for RIFF.]] In RMPP, these are restricted to lowercase ASCII. | ||
* A 4-byte integer recording the length of the chunk data, which, due to the next element in this list, amounts to the length of the section data in bytes plus four | * A 4-byte integer recording the length of the chunk data, which, due to the next element in this list, amounts to the length of the section data in bytes plus four | ||
| − | * A 4-byte | + | * A 4-byte "resource ID", whose use possibly depends on the chunk type. |
| + | * In many cases the resource ID is followed by a "name" field in the form of a length-prefixed string, plus a padding byte if needed to make the field length an even number. This is usually just an empty string. | ||
* The section data itself | * The section data itself | ||
* Possible a padding byte, if the next section would otherwise begin at an offset not divisible by two, unless the preceding section is the last in the file. This is normal for RIFF. | * Possible a padding byte, if the next section would otherwise begin at an offset not divisible by two, unless the preceding section is the last in the file. This is normal for RIFF. | ||
| − | To summarize, RMMP "sections" are RIFF chunks with the first four bytes occupied by a " | + | To summarize, RMMP "sections" are RIFF chunks with the first four bytes occupied by a "resource ID". |
The first section in an RMMP file is the table of contents, with type "cftc". | The first section in an RMMP file is the table of contents, with type "cftc". | ||
| Line 45: | Line 48: | ||
* The section's typecode (4 bytes) | * The section's typecode (4 bytes) | ||
* The section's length (4 bytes), with the same caveats as the length in the section itself | * The section's length (4 bytes), with the same caveats as the length in the section itself | ||
| − | * The section's | + | * The section's resource ID (4 bytes) |
* The section's absolute offset in the file (4 bytes) | * The section's absolute offset in the file (4 bytes) | ||
The RMMP table of contents always seems to be in the actual order of the sections in the file. It often seems to end in an area of zeroes, sized as if it held entries (i.e. its size is a multiple of 16 bytes). | The RMMP table of contents always seems to be in the actual order of the sections in the file. It often seems to end in an area of zeroes, sized as if it held entries (i.e. its size is a multiple of 16 bytes). | ||
| − | The cftc section seems to always have | + | The cftc section seems to always have resource ID 0. |
==== "dib " ==== | ==== "dib " ==== | ||
This section holds a DIB-like (see [[BMP]]) image, preceded by 2 zero bytes. It is possible that the image may stored with its rows reversed in order, or this may just be an oddity of test data. | This section holds a DIB-like (see [[BMP]]) image, preceded by 2 zero bytes. It is possible that the image may stored with its rows reversed in order, or this may just be an oddity of test data. | ||
| − | The | + | The resource ID of dib sections starts at 1024 and increments by 1 for each subsequent dib section, or occasionally for non-dib sections. |
The DIB lacks a color table, even though it has 8 or fewer bits per pixel (which would usually necessitate one). | The DIB lacks a color table, even though it has 8 or fewer bits per pixel (which would usually necessitate one). | ||
==== "str " ==== | ==== "str " ==== | ||
| − | As the name indicates, this section type holds string data, specifically, what appears to a title. Its | + | As the name indicates, this section type holds string data, specifically, what appears to a title. Its resource ID always appears to be 1024. Its data section consists of: |
* A zero byte | * A zero byte | ||
* A byte of uncertain purpose, always set to 0x54 (84) in the sample data | * A byte of uncertain purpose, always set to 0x54 (84) in the sample data | ||
| Line 64: | Line 67: | ||
==== "ver " ==== | ==== "ver " ==== | ||
| − | This always seems to be the second section in the file. As the name indicates, probably holds file "version". Its data section consists of two bytes, the first of which is zero, and the second of which seems to vary between values that have no easily apparent meaning and zero, without a clear pattern. It seems more likely that the version of the file is stored in the | + | This always seems to be the second section in the file. As the name indicates, probably holds file "version". Its data section consists of two bytes, the first of which is zero, and the second of which seems to vary between values that have no easily apparent meaning and zero, without a clear pattern. It seems more likely that the version of the file is stored in the resource ID, which is always 0x27 (39) in the Microsoft Works sample file linked from this page. |
==== "vwac" ==== | ==== "vwac" ==== | ||
| − | This seems to hold text, possibly interface-related. Along with data of an unknown purpose, it contains scattered blocks of text, prefixed by 4-byte [[big endian]] lengths. It always appears to have the | + | This seems to hold text, possibly interface-related. Along with data of an unknown purpose, it contains scattered blocks of text, prefixed by 4-byte [[big endian]] lengths. It always appears to have the resource ID 1024. |
== Sample files == | == Sample files == | ||
| Line 87: | Line 90: | ||
[[Category:RIFF based file formats]] | [[Category:RIFF based file formats]] | ||
| + | [[Category:Macromedia]] | ||
Revision as of 23:33, 28 April 2024
RIFF Multimedia Movie (also called RIFF RMMP, MMM movie, etc.) is a RIFF-based interactive media format, used mainly on Windows 3.x.
Contents |
Discussion
RIFF RMMP is listed in the original RIFF specification, with the apparently-false claim that it will be described later in the document.
MMM is associated with software such as MacroMind Windows Player and Macromedia Director Player, ancestors of Adobe Director. It's not completely clear what MMM stands for, but one possibility is MacroMind Multimedia Movie.
An MMM file is not a self-contained media format, but is a part of a multi-file application composed of a custom .EXE player app, one or more MMM files, and possibly other media files.
MMM might have only been used on Windows, but some of the applications that use it also have a Mac version. The Mac counterpart to MMM is similar, but based on Macintosh resource format instead of RIFF.[1] Some characteristics of MMM are clearly derived from Macintosh resource format. There was a utility named Gaffer that could convert from the Mac to the Windows format.
Identification
Files begin with "RIFF", and have "RMMP" at offset 8.
Structure
All values given here are little endian, unless otherwise noted. Offsets are relative to the beginning of the file.
RMPP is subset of RIFF. It consists of a single RIFF chunk, meaning that the file is prefixed with ASCII "RIFF" followed by the 4-byte length. The form type of the RIFF chunk is "RMPP", and so this follows the length.
As usual for the RIFF format, the RMMP file is organized into several "subchunks" of the RIFF chunk. However, unlike other RIFF types, there is no LIST chunk, and all chunks strictly follow a set of additions to the RIFF chunk definition here unofficially called "section" for clarity.
Some versions of MMM use mostly uppercase chunk names like "VWCF", while other (newer?) versions use mostly lowercase names like "vwcf".
A single section's record in the file consists of:
- The 4-byte chunk/section type identifier, normal for RIFF. In RMPP, these are restricted to lowercase ASCII.
- A 4-byte integer recording the length of the chunk data, which, due to the next element in this list, amounts to the length of the section data in bytes plus four
- A 4-byte "resource ID", whose use possibly depends on the chunk type.
- In many cases the resource ID is followed by a "name" field in the form of a length-prefixed string, plus a padding byte if needed to make the field length an even number. This is usually just an empty string.
- The section data itself
- Possible a padding byte, if the next section would otherwise begin at an offset not divisible by two, unless the preceding section is the last in the file. This is normal for RIFF.
To summarize, RMMP "sections" are RIFF chunks with the first four bytes occupied by a "resource ID".
The first section in an RMMP file is the table of contents, with type "cftc".
The individual sections that may appear in an RMMP file which have been at least partially decoded are listed below.
Specific Sections
"cftc"
This section holds the table of contents for the RMMP file. It is always the first section. It lists all sections in the file, including itself. Its data content is a series of entries for each section, each entry consisting of:
- The section's typecode (4 bytes)
- The section's length (4 bytes), with the same caveats as the length in the section itself
- The section's resource ID (4 bytes)
- The section's absolute offset in the file (4 bytes)
The RMMP table of contents always seems to be in the actual order of the sections in the file. It often seems to end in an area of zeroes, sized as if it held entries (i.e. its size is a multiple of 16 bytes). The cftc section seems to always have resource ID 0.
"dib "
This section holds a DIB-like (see BMP) image, preceded by 2 zero bytes. It is possible that the image may stored with its rows reversed in order, or this may just be an oddity of test data. The resource ID of dib sections starts at 1024 and increments by 1 for each subsequent dib section, or occasionally for non-dib sections.
The DIB lacks a color table, even though it has 8 or fewer bits per pixel (which would usually necessitate one).
"str "
As the name indicates, this section type holds string data, specifically, what appears to a title. Its resource ID always appears to be 1024. Its data section consists of:
- A zero byte
- A byte of uncertain purpose, always set to 0x54 (84) in the sample data
- A byte holding the length of the string
- The actual string data (not null-terminated)
"ver "
This always seems to be the second section in the file. As the name indicates, probably holds file "version". Its data section consists of two bytes, the first of which is zero, and the second of which seems to vary between values that have no easily apparent meaning and zero, without a clear pattern. It seems more likely that the version of the file is stored in the resource ID, which is always 0x27 (39) in the Microsoft Works sample file linked from this page.
"vwac"
This seems to hold text, possibly interface-related. Along with data of an unknown purpose, it contains scattered blocks of text, prefixed by 4-byte big endian lengths. It always appears to have the resource ID 1024.
Sample files
- Microsoft Works - Gateway 2000 Edition (Microsoft) (1991) (CD image from archive.org) → ISO image → *.MMM
- dexvert samples — video/riffMultimediaMovie
Software
- MMPF.ZIP - Source code (for Windows 3.x) to parse a file. See also the note in DESCRIP.TXT.
- User:Effect2/readRMPP.c
- Deark
Links
- Original RIFF specification
- filext.com .MMM page - Lists two MMM formats
- Wikipedia: MacroMind
