The 11th Hour ROL

From XentaxWiki
Jump to: navigation, search

ROL/ROQ/RNR

  • Format Type : Multimedia file
  • Endian Order : Little Endian


Preface

Just as the VDX files in The 7th Guest, the ROL, ROQ and RNR files of The 11th Hour represent a multimedia container format allowing for interleaved audio and video data. All files are structured very similarly and the distinction into three types seems a bit arbitrary. Thus all formats will here be discussed in one section.

Format Specifications

Every ROL, ROQ and RNR file is basically a sequence of blocks, each of them having the following structure:

// for each block

byte {1}     - Block Type
byte {1}     - Identifier (?)
uint32 {4}   - Data Size
uint16 {2}   - Block Parameter
byte {X}     - Block Data

The size of the Block Data is defined by the Data Size entry in the header barring a few exceptions discussed in the type explanations below.


Type 0x01 (image information)

This block is usually 8 bytes long and contains the following data structure:

// image information

uint16 {2}   - Image Width
uint16 {2}   - Image Height
uint16 {2}   - Unknown (always 8?)
uint16 {2}   - Unknown (always 4?)



Type 0x12 (still image)

This block simply contains a JPEG formatted image file.


Type 0x20 (mono audio)

This block contains compressed audio data sampled at 22,050 Hz, 16 bit, mono. For conversion into raw sound data (as used in RIFF wave files), each of the bytes within the data block relates to exactly one sample of the resulting sound by the fact that it represents the square root of the difference to the last sample. Decompression would thus take place as follows: The initial 16 bit sample is defined by the Block Parameter field of the block header by XORing it with 0x8000. This sample just serves as the initial "history" and is not written to the output. Now each byte read from the data block alters the last sample in the following way to gain the new sample:

  • If the byte is smaller than 0x80, square it and add it to the last sample.
  • If the byte is larger or equal to 0x80, subtract 0x80, square it and subtract it from the last sample.


Type 0x21 (stereo audio)

This block is similar to 0x20, as it also contains audio data, but this time in stereo mode. Decompression is similar to the mono case, only that the left and the right channel are interleaved, i. e. the first byte relates to the left channel, the second byte relates to the right channel and so on. This time, the high byte of the Block Parameter defines the high byte of the left channel initial sample (again XORed with 0x8000) and the low byte of the Block Parameter defines the high byte of the the right channel initial sample (XORed with 0x8000 as well). The low bytes are set to zero.


Type 0x30 (audio container ?)

This block only seems to function as an audio "container" block, but doesn't seem to have any other purpose.


Type 0x84 (file start)

This block can be only found at the beginning of each ROL, ROQ and RNR file. There does not seem to be any important information contained regarding extraction, but the block header data can vary between the three file types:

  • ROL: Data Size is usually zero, as is the Block Parameter.
  • ROQ: Data Size is usually 0xffffffff, the Block Parameter is 0x001e.
  • RNR: Seems to coincide with ROQ.


Types 0x02, 0x11, 0x17 (video)

These blocks contain data resulting from an advanced video compression scheme, quite similar to modern methods. An in-depth analysis of this format (as well as explanations of the sound data blocks as described above) can be found here. Obviously, Trilobyte lead programmer Graeme Devine took this format, originally developed for The 11th Hour, with him when he went working for id Software. That way, this file format was taken over (probably even without alterations) to be used for video animations in Quake 3.