Broken Sword - The Sleeping Dragon RWS

Back to index | Edit this page

RWS

Format type: Archive
Endianness: Little-endian

Format Specifications

uint32 {4} - RWS chunk type (0x0000080d)

uint32 {4} - RWS chunk data size
uint32 {4} - RWS chunk version (0x1803ffff)

uint32 {4} - RWS chunk type (0x0000080e)

uint32 {4} - RWS chunk data size

uint32 {4} - RWS chunk version (0x1803ffff)

uint32 {4} - header size

uint32 {36} - Unknown

uint32 {4} - number of tracks

uint32 {20} - Unknown

uint32 {16} - some kind of signature?

char {x} - stream name 1 (zero-terminated, padded to 16 byte boundary)

uint32 {24} - Unknown

uint32 {4} - data size

uint32 {4} - Unknown

// for each track

uint32 {4} - Unknown

uint32 {16} - some kind of signature?

char {x} - stream name 2 (zero-terminated, padded to 16 byte boundary)

// for each track (physical organization)

uint32 {16} - Unknown

uint32 {4} - cluster size

uint32 {12} - Unknown

uint32 {4} - used bytes per cluster

uint32 {4} - track start offset

// for each track (track parameters)

uint32 {4} - sample rate

uint32 {4} - Unknown

uint32 {4} - track data size

byte {1} - Unknown

byte {1} - number of channels

uint16 {2} - Unknown

uint32 {12} - Unknown

uint32 {16} - some kind of signature?

uint32 {4} - Unknown

// for each track

uint32 {16} - some kind of signature?

// for each track (track names)

char {x} - track name (zero-terminated, padded to 16 byte boundary)

uint32 {x} - padding (until chunk has finished, cf. chunk data size)

uint32 {4} - RWS chunk type (0x0000080f)

uint32 {4} - RWS chunk data size

uint32 {4} - RWS chunk version (0x1803ffff)

// until tracks have finished (interleaved track clusters)

// for each track (single track cluster)

// until bytes used per cluster are finished (IMA ADPCM variant blocks)

// for each channel (ADPCM header)

int16 {2} - initial sample

byte {1} - initial index

byte {1} - unused (0x00)

// 7 times

// for each channel (ADPCM sample codes)

byte {4} - 8 sample codes

// for each channel (ADPCM sample codes)

byte {4} - 7 sample codes (final nibble unused)

byte {x} - padding (until cluster has finished)

Notes and Comments

General information

Broken Sword - The Sleeping dragon is based on the RenderWare engine and utilizes its usual stream files to store the game's audio data. The chunk types encountered identify themselves as follows:

0x0000080d - audio container
0x0000080e - audio header
0x0000080f - audio data

Note that all reviewed files consisted of exactly one audio container chunk which in turn was made up of exactly one audio header chunk and one audio data chunk (in that order).

Audio header

One single RWS file supports multiple single tracks which can be mixed on the fly during gameplay. The audio header lists parameters, physical layout organization information as well as names for each track. As the audio data itself is organized in a clustered manner, not only the sampling rate and frequency are relevant for extraction, but also

the track offset, which specifies the track data position relative to the beginning of the audio data,
the cluster size, which fixes the length of one informational unit,
the number of bytes used within a cluster, as one cluster may actually only be partially filled by audio data and
the track size, which specifies the size of one track's data measure in actual used bytes (i. e. not counting cluster waste).

Audio data

The audio data chunk contains the actual track data, organized in clusters as defined in the audio header. Each cluster contains data for exactly one track, while all tracks within a single RWS file are interleaved at cluster level. Thus, to extract one track, one cluster at a time has to be read (starting at the offset given in the audio header), then eventually skipping the other tracks' data before reaching the next cluster belonging to this track. Note that parts of a cluster may be wasted. The number of used bytes in one each cluster can be looked up in the audio header.

Example: Assume three tracks in one RWS file. The data layout will look like this:

 +-----------------+-----------------+-----------------+-----------------+-----------------+-----------------+
 |    Cluster 1    |    Cluster 2    |    Cluster 3    |    Cluster 4    |    Cluster 5    |    Cluster 6    |
 + - - - - - - - - + - - - - - - - - + - - - - - - - - + - - - - - - - - + - - - - - - - - + - - - - - - - - +
 | Track 1 part 1  | Track 2 part 1  | Track 3 part 1  | Track 1 part 2  | Track 2 part 2  | Track 3 part 2  | ...
 + - - - - + - - - + - - - - + - - - + - - - - + - - - + - - - - + - - - + - - - - + - - - + - - - - + - - - +
 |  data   | waste |  data   | waste |  data   | waste |  data   | waste |  data   | waste |  data   | waste |
 +---------+-------+---------+-------+---------+-------+---------+-------+---------+-------+---------+-------+

The wave data within each cluster is stored via IMA ADPCM compressed sample codes. The single blocks are fairly small; each block encodes exactly 64 signed 16 bit PCM samples per channel. The first of these samples is explicitly given in each block's header structure. The remaining 63 samples are compressed and packed into 8 units, each 4 bytes in size, alternatingly for each channel. Every channel's very last nibble within the block is thus unused.

Example: Assuming two channels in one track, the sample layout of a given block will look as follows (X denoting the unused nibbles):

 +---------------+---------------+---------------+---------------+     +---------------+---------------+
 | Ch. 1 unit 1  | Ch. 2 unit 1  | Ch. 1 unit 2  | Ch. 2 unit 2  |     | Ch. 1 unit 8  | Ch. 2 unit 8  |
 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + ... + - - - - - - - + - - - - - - - +
 | Smpl. 1...8   | Smpl. 1...8   | Smpl. 1...8   | Smpl. 1...8   |     | Smpl. 1...7 X | Smpl. 1...7 X |
 +---------------+---------------+---------------+---------------+     +---------------+---------------+