Xan DPCM: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
No edit summary
(add fourcc to header)
 
Line 1: Line 1:
Company: [[Origin Systems]]
* FourCC: Axan
* Company: [[Origin Systems]]


Origin's [http://www.mobygames.com/game/dos/wing-commander-iv-the-price-of-freedom Wing Commander IV: The Price of Freedom] and Crusader: No Regret computer games transport multimedia cutscenes in standard Microsoft [[Microsoft Audio/Video Interleaved|AVI]] files. The video in the files is encoded in the [[Origin Xan Codec]] format, and the audio is encoded using a custom format that this page takes the liberty of naming Xan DPCM.
Origin's [http://www.mobygames.com/game/dos/wing-commander-iv-the-price-of-freedom Wing Commander IV: The Price of Freedom] and Crusader: No Regret computer games transport multimedia cutscenes in standard Microsoft [[Microsoft Audio/Video Interleaved|AVI]] files. The video in the files is encoded in the [[Origin Xan Codec]] format, and the audio is encoded using a custom format that this page takes the liberty of naming Xan DPCM.

Latest revision as of 18:45, 28 February 2021

Origin's Wing Commander IV: The Price of Freedom and Crusader: No Regret computer games transport multimedia cutscenes in standard Microsoft AVI files. The video in the files is encoded in the Origin Xan Codec format, and the audio is encoded using a custom format that this page takes the liberty of naming Xan DPCM.

For the Wing Commander IV AVIs, note that an AVI file demuxer will probably need to be modified to support the algorithm. The WAVEFORMATEX headers in the Xan AVI files report the audio coding as format 0x0001: PCM. However, the file's 'auds' chunk begins with the fourcc 'Axan'. A program can either check for this or assume that the file uses Xan DPCM if it uses Xan video. In Crusader: No Regret's AVIs the chunk also begins with 'Axan', but the format is set as 0x594a. The decoding method is the same.

Classifying the Xan audio coding method as a DPCM algorithm is a little shaky. It actually resembles a cross between a DPCM algorithm and a APDCM algorithm. Perhaps the designers could not decide between the two algorithm families and decided to split the difference. The algorithm encodes 16-bit PCM samples as 8-bit bytes by packing a 6-bit delta value along with a 2-bit delta modifier into a byte.

For each chunk of Xan DPCM data, the first 2 or 4 bytes are the initial predictors for that chunk, depending on mono or stereo data, and are encoded as signed, 16-bit, little-endian numbers. A shifter value for each channel is initialized to 4. For each byte in the stream (assuming mono data):

   byte = next byte in stream
   diff = (byte & 0xFC) << 8
   if bottom 2 bits of byte are both 1 (byte & 0x03)
       shifter++
   else
       shifter -= (2 * (byte & 3))
   note that the shift value may not go below 0 and must be saturated here
   shift diff right by shifter value
   apply diff to the current predictor
   saturate predictor to signed, 16-bit range 

Note that diff must be treated as a signed 16-bit number. For stereo data, the bytes represent interleaved samples in LRLR order.