Indiana Jones And The Infernal Machine CND

From XentaxWiki
Jump to: navigation, search

Choose archive extension:


Format Specifications

// general CND header
uint32 {4}   - Archive size
char {1216}  - Copyright notice, ASCII art-style
char {64}    - Source path and name
uint32 {280} - Unknown
uint32 {4}   - Number of files
unit32 {4}   - Unknown

Note that the only really interesting piece of information is the number of files. Anything else is either unknown or serves purely informational purposes.

Each file contained in a CND archive is a compressed sound file, and for each such file entry, there follows a seperate descriptor:

// file entry descriptor
uint32 {4} - File ID (probably)
uint32 {4} - Unknown
uint32 {4} - Directory name offset
uint32 {4} - File name offset
uint32 {4} - Data offset
uint32 {4} - Unknown
uint32 {4} - Sampling rate
uint32 {4} - Sample size (bits)
uint32 {4} - Number of channels
uint32 {4} - Data size
uint32 {4} - Unknown
uint32 {4} - Index (probably)

All stored offsets are relative to the beginning of the data section, which follows immediately after the last file entry descriptor. The interesting pieces of information here are the directory and file name offsets, which allow for reconstruction of the original (zero-terminated) file name, as well as the data offset and the sound data-related entries sampling rate, sample size and number of channels.

When seeking to the data offset of a file entry, the following general header of the compressed sound will be encountered:

// general sound data header
uint32 {4} - Uncompressed size
int8 {1}   - Compression type

The uncompressed size denotes the required output buffer size in bytes. The compression type determines the method of compression applied to the sound data, where the following cases are differentiated:

Compression type < 0   --  WVSM compression
Compression type >= 0  --  Other compression

WVSM compression

In this case, the compression type of the general sound data header usually has the value 0xe4. However, other negative values should theoretically lead to the same decompression method. Note that this method can only decompress 16 bit-sound.

When processing the WVSM scheme, the general sound data header is followed by the special WVSM header:

// WVSM header
uint16 {2} - Test1 (0x1111)
uint8 {1}  - Test2 (0x64)
uint16 {2} - Test3 (0x2222)
char {4}   - Identifier ("WVSM")

To be considerer the header of a valid WVSM structure, all the above values have to be correct. After this header structure, the actual compressed sound data follows. The data is organized as frames that result in decompressed data of 4096 bytes each, as long as the uncompressed sound size specified in the general sound data header allows this; thus the last frame may be shorter.

Each frame is prepended by a frame header:

// frame header
uint16 {2} - Unknown
uint8 {1}  - Sample expander
int8 {X}   - Compressed data

For decompression, the sample expander value has to be split into its high and low nibble. Both will be used alternatingly during decompression, starting with the high portion.

Each signed byte ("val") of compressed data will be converted to a signed word (int16) by evaluating the following simple criterion:

if val = 0x80 then
  copy next int16 literally to output, switching byte order
  copy (val shl nibble) to output

The decompression process for this frame continues until 4096 bytes of output have been produced or the final output size has been reached, whichever occurs first. Note that some (usually 10 to 15) bytes of input data after the last frame might stay unused. The purpose of this data is not yet known.

Other compression

This compression method has not yet been researched, as no samples using this method have been found up to now.

MultiEx BMS Script

Not written yet

Compatible Programs