imported>Ikskoks at 15:05, 10 January 2021

2021-01-10T15:05:09Z

← Older revision	Revision as of 15:05, 10 January 2021
(No difference)

imported>Ikskoks at 15:05, 10 January 2021

2021-01-10T15:05:09Z

← Older revision		Revision as of 15:05, 10 January 2021
Line 117:		Line 117:

	Unknown		Unknown


			[[Category:File Format]]

imported>DenizOezmen: added format description

2006-08-29T10:57:03Z

added format description

← Older revision	Revision as of 10:57, 29 August 2006
(No difference)

imported>DenizOezmen: added format description

2006-08-29T10:57:03Z

added format description

New page

* [[GRAFs|Return to the list of games]]

Choose archive extension:

== CND ==

* ''' Format Type ''': Sound archive 
* ''' [http://en.wikipedia.org/wiki/Endianness Endian Order] ''': Little Endian 

=== Format Specifications ===

<tt>

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

</tt> 

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: 

<tt>

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

</tt> 

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: 

<tt>

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

</tt> 

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: 

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

==== WVSM compression ====

In this case, the compression type of the general sound data header usually has the value <tt>0xe4</tt>. 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: 

<tt>

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

</tt> 

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: 

<tt>

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

</tt> 

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 ("<tt>val</tt>") of compressed data will be converted to a signed word (<tt>int16</tt>) by evaluating the following simple criterion: 

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

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

Unknown

Indiana Jones And The Infernal Machine CND - Revision history

imported>Ikskoks at 15:05, 10 January 2021

imported>Ikskoks at 15:05, 10 January 2021

imported>DenizOezmen: added format description

imported>DenizOezmen: added format description