ADX (file format)

General Overview

ADX is a compressed audio format but unlike MP3 and similar formats, it doesn't apply a psychoacoustic model to the sound to reduce its complexity. The ADPCM model instead stores samples by recording the error relative to a prediction function which means more of the original signal survives the encoding process; as such ADPCM compression instead trades accuracy of the representation for size by using relatively small sample sizes, usually 4bits. The human auditory system's tolerance for the noise this causes makes the loss of accuracy barely noticeable.

Like other encoding formats, ADX supports multiple sampling frequencies such as 22050 Hz, 44100 Hz, 48000 Hz, etc. however, the output sample depth is locked at 16bits, generally due to the lack of precision already mentioned. It supports multiple channels but there seems to be an implicit limitation of stereo (2 channel) audio although the file format itself can represent up to 255 channels. The only particularly distinctive feature that sets ADX apart from alternatives like IMA ADPCM (other than having a different prediction function) is the integrated looping functionality, this enables an audio player to optionally skip backwards after reaching a single specified point in the track to create a coherent loop; hypothetically, this functionality could be used to skip forwards as well but that would be redundant since the audio could simply be clipped with an editing program instead.

For playback there are a few plugins for WinAmp and a convert to wave tool (see the references section). The open source program / library FFmpeg also has ADX support implemented, however, its decoder is hard coded so can only properly decode 44100 Hz ADXs.

Technical Description

The ADX specification is not freely available, however the most important elements of the structure have been reverse engineered and documented in various places on the web. The information here may be incomplete but should be sufficient to build a working codec or transcoder.

As a side note, the AFS archive files that ADXs are sometimes packed in are a simple variant of a tarball which uses numerical indices to identify the contents rather than names. Source code for an extractor can be found in the ADX archive at.

File Header

The ADX disk format is defined in big-endian. The identified sections of the main header are outlined below:

Fields labelled "Unknown" contain either unknown data or are apparently just reserved (i.e. filled with null bytes). Fields labelled with 'v3' or 'v4' but not both are considered "Unknown" in the version they are not marked with. It should also be noted that this header may be as short as 20 bytes (0x14), as determined by the copyright offset, which implicitly removes support for a loop since those fields are not present.

The "Encoding Type" field should contain one of:

The "Version" field should contain one of:

When decoding AHX audio, the version field does not appear to have any meaning and can be safely ignored.

Sample Format

ADX encoded audio data is broken into a series of 'blocks', each containing data for only one channel. The blocks are then laid out in 'frames' which consist of one block from every channel in ascending order. For example, in a stereo (2 channel) stream this would consist of Frame 1: left channel block, right channel block; Frame 2: left, right; etc. Blocks are usually always 18 bytes in size containing 4bit samples though other sizes are technically possible, an example of such a block looks like this:

The scale is a 16bit unsigned integer (big-endian like the header) which is essentially the amplification of all the samples in that block. Each sample in the block must be decoded in bit-stream order, that is, most significant bit first. For example, when the sample size is 4bits:

The samples themselves are not in reverse so there is no need to fiddle with them once they are extracted. Each sample is signed so for this example, the value can range between -8 and +7 (which will be multiplied by the scale during decoding). As an aside, although any bit-depth between 1 and 255 is made possible by the header. It is unlikely that one bit samples would ever occur as they can only represent the values {0, 1}, {-1, 0} or {-1, 1}, all of which are not particularly useful for encoding songs — if they were to occur then it is unclear which of the three possibilities is the correct interpretation.

ADX Decoding

This section walks through decoding ADX 'version 3' or 'version 4' when "Encoding Type" is "Standard ADX" (0x03). An encoder can also be built by simply flipping the code to run in reverse. All code samples in this section are written using C99.

Before a 'standard' ADX can be either encoded or decoded, the set of prediction coefficients must be calculated. This is generally best done in the initialisation stage:

This code calculates prediction coefficients for predicting the current sample from the 2 previous samples. These coefficients also form a first order Finite Impulse Response high-pass filter as well.

Once we know the decoding coefficients we can start decoding the stream:

Most of the above code should be straightforward enough for anyone versed in C. The 'ADX_header' pointer refers to the data extracted from the header as outlined earlier, it is assumed to have already been converted to the host Endian. This implementation is not intended to be optimal and the external concerns have been ignored such as the specific method for sign extension and the method of acquiring a bitstream from a file or network source. Once it completes, there will be samples_needed sets (if stereo, there will be pairs for example) of samples in the output buffer. The decoded samples will be in host-endian standard interleaved PCM format, i.e. left 16bit, right 16bit, left, right, etc. Finally, if looping is not enabled, or not supported, then the function will return the number of sample spaces that were not used in the buffer. The caller can test if this value is not zero to detect the end of the stream and drop or write silence into the unused spaces if necessary.

Encryption

ADX supports a simple encryption scheme which XORs values from a linear congruential pseudorandom 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 "Flags" value in the header is 0x08. 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 0x8000 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 impossible to separate from the randomness added by the encryption.

AHX Decoding

As noted earlier, AHX is just an implementation of MPEG2 audio and the decoding method is basically the same as the standard, it is possible just to demux the stream from the ADX container and feed it through a standard MPEG Audio decoder like mpg123. The ADX header's "sample rate" and "total samples" are usually correct if a decoder needs them (so should be set by encoder/muxer implementations) but most of the other fields such as the "block size" and "sample bitdepth" will usually be zero — as noted above, the looping functionality is also unavailable.