ADX is a lossy proprietary audio storage and compression format developed by CRI Middleware specifically for use in video games. The format is similar in principal to ADPCM, the sound quality is quite good given the small storage sizes used. Its most notable feature is its looping functionality that has proved useful for background music in various games that have adopted the format, such as the Dreamcast and later generation Sonic the Hedgehog games from SEGA, as well as many PlayStation 2 and GameCube games. ADX also has a sibling format, AHX, which uses a variant of MPEG-2 audio and is intended specifically for voice recordings. One of the first games to use ADX was Burning Rangers, on the Sega Saturn.

General Overview

ADX supports a variety of sampling frequencies the same as other audio formats (eg. 22050, 44100, 48000, etc) but the sample depth is locked at 16bits. It does support multiple channels, however there seems to be an implicit limitation of stereo (2 channel) audio although the file format itself can contain up to 255 channels. The only really unusual feature is the looping functionality that enables the audio player to automatically skip backwards after reaching a specified point in the track, theoretically this functionality could be used to skip forwards as well, allowing for conditional playback of non player character responses to player choices within games and conditional playback of music in situations where the player has a choice between entering two or more areas in the game.

Technical Description

This section will provide a complete overview of the known information about the ADX on disk format. This section is intended for people with a background in programming, particularly C.

The ADX format's specification is not freely available, however the most important elements of the structure have been described in various places on the web. The information here may be partially incomplete but is sufficient to build a working codec or transcoder. Note that AHX is not covered here as information about that variant is difficult to find, however a cursory examination with a hex editor reveals a strikingly similar design to ADX 'version 3' minus the looping feature.

A further related file format also exists, ADX files are typically found packed in "AFS" files which are really just a simple variant of a tarball. Source code for an extractor for this format is included in the ADX archive at .

File Header

The ADX disk format is inherently big-endian even when used on little-endian architectures such as the original Xbox or x86 computer. The known layout of the main header is outlined below:

The "Version Mark" field should contain the big-endian values 0x01F40400 (Hexadecimal) for 'version' 4, or 0x01F40300 for 'version' 3. Fields labelled "Unknown" contain either unknown data or otherwise appear to be reserved (ie. filled with null bytes). Fields labelled with v3 or v4 but not both are "Unknown" in the version they are not marked with.

Sample Format

ADX encoded audio data is broken into a series of consecutive blocks of 18 bytes. Each block contains data for one channel only, they are laid out in 'frames', one block for each channel makes up a frame in ascending order. ie. Frame 1: left channel block, right channel block; Frame 2: left, right; etc. The layout of a block itself looks like this:

The scale is a 16bit unsigned big-endian integer. The high bit of the scale is not used, it is a flag for the end of the ADX stream.

Decoding Samples

As noted above, each sample consists of 4bits, the high 4bits of each byte are the first sample with the low 4bits being the second.

The decoding method for a sample is demonstrated below in C99:

The above code assumes the file has been read or mapped into the program address space (see mmap), however this is not necessary in a practical implementation but makes this demonstration simpler.

Before processing the sample, it is necessary to acquire the "block scale" and the byte containing the sample within the file, the calculations used here appear more complex than they truly are, a counter and cache variables would be simpler and more efficient in practice but the entire positional calculations are demonstrated for clarity.

The first calculation finds the channel block for the current sample, this involves converting the 'total samples read' counter into a 'number of frames read' counter then adding the offset of block for the current channel within the frame. The 'block scale' is located at the start so that needs to be converted to the local endian (in this case, ntohs is appropriate for this task) and stored for later. The second calculation moves to the byte within the channel block. As the samples are nybbles, not whole bytes, the if statement cuts off the undesired sample and shifts the nybble appropriately to the low 4bits.

The decoding process involves first adjusting the 4bit signed value for a 32bit [or larger] variable as few desktop processors can handle 4bit numbers directly. The highest bit of the 4bit value is the sign bit, the number itself is formatted in Two's complement. The demonstration code uses a simple trick for sign-extending the value, for example, if sample_4bit is -1 (1111 in binary), which is 15 in unsigned arithmetic, subtracting 16 will convert the number to -1 again in the larger variable.

The next stage is to multiply the sample by the 'block scale' which gives it a rational amplitude, then amplify by a volume, the value used for the volume varies between sources from 0x1000 to 0x4000, it is recommended that you should likely not go higher than 0x4000 as distortion effects may be noticeable in common test files, caused by oversaturating the sound. The next 2 steps include information from the previous two samples to bring the sample in line with the others. The previous sample trackers translate across block boundaries but separate tracker sets must be kept for each channel, the values start at 0 in the first audio frame of the file. Lastly, the sample is divided by 16384 using a downshift to compress into the expected signed 16bit range (-32768 to 32767) then truncated if necessary.

The decoded sample value is a regular raw PCM amplitude sample that can be played on a sound card or fed into an encoder to transcode into some other sound format.

Encryption

ADX supports a simple encryption scheme which XORs values from a linear congruential random number generator with the block scale values. This method is computationally inexpensive to decrypt (in keeping with ADX's real-time decoding) yet renders the encrypted files unusable. The encryption is active when the Version Mark value in the header is 0x01F40408 (note that the final byte is 0x08 instead of 0x00 as in unencrypted files). As XOR is symmetric the same method is used to decrypt as to encrypt. The encryption key is a set of three 16-bit values: the multiplier, increment, and start values for the linear congruential generator (the modulus is 0x7fff to keep the values in the 15-bit range of valid block scales). Typically all ADX files from a single game will use the same key.

The encryption method is vulnerable to known-plaintext attacks. If an unencrypted version of the same audio is known the random number stream can be easily retrieved and from it the key parameters can be determined, rendering every ADX encrypted with that same key decryptable. The encryption method attempts to make this more difficult by not encrypting silent blocks (with all sample nybbles equal to 0), as their scale is known to be 0.

Even if the encrypted ADX is the only sample available, it is possible to determine a key by assuming that the scale values of the decrypted ADX must fall within a "low range". This method does not necessarily find the key used to encrypt the file, however. While it can always determine keys that produce an apparently correct output, errors may exist undetected. This is due to the increasingly random distribution of the lower bits of the scale values, which becomes very hard to separate from the randomness added by the encryption.