CRI ADX file
- Extensions: adx, ahx
- Company: CRI
ADX is an audio container file format, mainly used with CRI ADX ADPCM It supports a single audio stream with optional looping information. It is in turn found as an audio stream in Sofdec videos, interleaved into AIX files, and packed in AAX container files.
There are two header formats, known as "type 03" and "type 04" due to a notably different byte. There is an additional "type 05", but it is used only in two Sofdec videos in Buggy Heat, and has no loop information.
All integers are big-endian.
|0x04||1||format (3 for ADX)|
|0x05||1||block size (typically 18)|
|0x06||1||bits per sample? (4)|
|0x12||1||loop data style ("type": 03, 04, or 05)|
|0x13||1||encryption flag (other flags?)|
|type 03 loop data|
|0x1c||4||loop start sample|
|0x20||4||loop start byte|
|0x24||4||loop end sample|
|0x28||4||loop end byte|
|type 04 loop data|
|0x28||4||loop start sample|
|0x2c||4||loop start byte|
|0x30||4||loop end sample|
|0x34||4||loop end byte|
It is common for the header to be incomplete if the file does not loop; the data offset will then be small so there isn't enough space for the loop data.
No channel count other than 1 or 2 has ever been seen. For 5.1 surround sound tracks, AIX is used to interleave together three 2-channel ADX files, which suggests that the ADX format is not intended to handle any higher number.
It is possible that the extra 16 bytes for type 04 are involved in setting the initial decoder history; they are nonzero in the second segments of some AIXs (which may need some way to match up the history from one segment to another).
The basic file structure is used in a few related formats by CRI. Each uses a different value for the "format" field (byte 4). Known values are:
|2||fixed coefficient ADPCM (specifics unknown)|
|4||ADX with exponential scale|
Only 3 and 0x11 are in common use.
An ADX file begins with the header. The header contains the byte offset (from byte 2 of the file) of the audio data. The audio data is a series of frames of data with no additional framing from the container, left and right frames interleaved if stereo. At the end of the stream is a single dummy frame, identifiable by a set high bit in the scale, the "scale" value is 0x8001. The next two bytes are a 16 bit big endian integer specifying the number of bytes left in the file (not including the two bytes themselves). Thus for a file with the bare minimum dummy frame (18 bytes, the standard ADX frame size), the frame will be:
80 01 00 0e
followed by 14 zero bytes. Larger dummy frames are also seen, for padding. The purpose of the dummy frame is to allow the decoder to read 18 bytes (or more) at a time without worrying about hitting the end of the file. The decoder simply must check the high bit of the scale to know if it has hit the end of the stream. It should be noted that the structure of the dummy frame is similar to that of the ADX header: 0x8000 or 0x8001, followed by an offset, with the offset counting bytes immediately after the offset itself.
In between the header and the audio data there is useless padding. Immediately before the audio data, the last 6 bytes of padding is the signature "(c)CRI" in ASCII.