MultimediaWiki - User contributions [en]

Covox ADPCM

2017-01-16T08:11:53Z

Trixter:

Creative 8 bits ADPCM

2015-02-02T15:24:21Z

Trixter:

* Company: [[Creative]]

These ADPCM schemes are used in [[Creative_Voice|Creative VOC]] files. The only reference decoder is a hardware one: the Creative Sound Blaster (Pro). So this documentation is not based on reverse engineering. It's based on wild guessing and empirical tests but gives good enough results.

'''(Note: The source at https://github.com/joncampbell123/doslib/blob/master/hw/sndsb/sndsb.c claims that this information is incorrect -- this wiki article should be revised to be closer to accurate.)'''

There are three different variation of this codec, which pack samples to either 4, 2.6 or 2 bits. The 2.6 scheme means that every byte is composed of 3 samples of 3 bits for the first and the second and 2 bits for the last.

The three different schemes use the same algorithm with different initial parameters.

=== Initialization ===

The first byte is a raw (not compressed) sample, used as the initial value for prdiction.

step is initialized to 0.

shift is initialized to 2 for 2 bits scheme and to 0 else.

limit is initialized to 5 for 4 bits samples, 3 for 3 bits samples and 1 for 2 bits samples.

=== Decoding ===

Every packed sample is composed of a sign bit (the most significant bit), and a value (the other bits). Let's define sign as 1 when the sign bit is 0 and -1 when the sign bit is 1. Now you can decode a packed sample with the following operation
sample = prediction + sign * (value << (step + shift))
sample have to be clamped to fit into an unsigned byte.

Then prediction is updated to the new sample value, and step is updated using this algorithm:
if (value >= limit)
step++;
else if (value == 0)
step--;
step must be clamped into the 0..3 range.

== External sites ==

* The DOSBox source contains code that claims to decode Creative ADPCM as well, but that code has not yet been verified against the information on this page.

* The VOCEDIT 2 (VEDIT2.EXE) program that came with the Sound Blaster Pro can be used to compress 8-bit PCM .VOC files into all Creative 8-bit ADPCM variants, making it applicable for a reverse-engineering exercise. The same software might be able to unpack packed files as well but this has not been verified. Download link found at VOGONs at http://www.vogons.org/viewtopic.php?t=8634

[[Category:Audio Codecs]]
[[Category:ADPCM Audio Codecs]]

XDC (8088 Domination)

2014-08-14T18:27:10Z

Trixter: Created page with "* Extension: xdv * Website: http://x86dc.wordpress.com XDC is an(other) academic project by Jim Leonard, a.k.a. Trixter. The goal of the project was to play full screen, FM..."

* Extension: xdv
* Website: http://x86dc.wordpress.com

XDC is an(other) academic project by Jim Leonard, a.k.a. Trixter. The goal of the project was to play full screen, [[FMV|full motion video]] on an original IBM PC utilizing the PC's CGA graphics mode. The specs of the "original IBM PC" included:

* Intel 8088 CPU running at 4.77 MHz
* CGA graphics mode: 16KB framebuffer, one video page, limited color
* Sound Blaster audio

XDC stands for X86 Delta Compiler, as its method of operation produces executable code for each video frame, as opposed to traditional codecs which output compressed data. By outputting code instead of data, XDC avoids unnecessary CPU processing normally associated with the load-decompress-translate-update tasks of other codecs. Decompression is performed by CALLing the frame data, where it directly alters the contents of the CGA frame buffer.

An earlier version of this system was the basis of the award-winning demo "8088 Domination" in 2014.

== XDV File Format ==
The [https://github.com/MobyGamer/XDC/blob/master/XDC_GLOB.PAS header] is stored in the github repository for the project:

<nowiki>'XDCV' - 4 bytes, header signature
numpackets - 2 bytes, word value, number of packets that follow header
largestpacket - 2 byte, word value, size in bytes of largest packet in the file
achunksize - 2 bytes, word value, size of each audio chunk.
This is always a fixed value even when compressed audio formats
are in use, because each audio compression method produces
fixed-size output chunks.
samprate - 2 bytes, word value, playback sample rate in Hz
vidmode - 1 byte, 1=160x200x16 composite CGA, 2=640x200x2 (others to follow?)
numbcols - 1 byte, width of screenmode in byte columns (ie. 80)
numprows - 1 byte, height of screenmode in pixel rows (ie. 200)
features - 1 byte, bitfield, reserved for special handling:
padding - rest of header is padded to the first sector boundary (512)
</nowiki>

"Features" are currently unused.

After the header, comes one or more audio+video "packets" with the
following structure:

0..end of videochunk
...unknown # of padding...
audiochunk..end of packet

The very beginning of the packet is the video chunk, which is of a
variable size. The very end of the packet is the audio chunk, which can
easily be found by seeking backwards from the end "achunksize" bytes.
All packets are aligned to sector boundaries (ie. the nearest 512-byte
boundary). The data in the packet between the video and audio chunks is
undefined (although likely filled with 0).

Video playback framerate is derived by the audio sample rate divided by the
audio chunk size. It is possible (in fact, likely) that neither the framerate
or audio sample rate will be a common/expected value. For example, samplerate
could have been adjusted during creation from 32Khz to 32008Hz to avoid drift,
or the framerate could be a non-integral number like 29.97 or 23.976.

Packets are padded to the nearest sector boundary (512-byte boundary). At the
end of an XDV stream is an index that stores the size of each packet in
sectors, one value per byte. (For example: A (tiny) stream that has
numpackets=4 would have, at EOF-4, 4 bytes, one for each packet to read, with
each value multiplied by 512 to get the packet length.) Loading the index is
as easy as reading [numpackets] from the header and then seeking to
EOF-[numpackets], then reading [numpackets] bytes. This index must obviously
be loaded prior to playback so that the player knows how much data to load
from disk for each packet.

== Video Format ==
The video format operates in CGA graphics mode, which is an interlaced framebuffer utilizing 16KB of RAM. Each byte can represent 1-bit, 2-bit, or 4-bit graphics with 2, 4, or 16 colors respectively.

The interlaced memory arrangement represents even lines starting at offset 0, then odd lines starting at offset 8192. Only lines 0 through 199 are visible; extra data in the framebuffer outside of the first 200 lines is not displayed.

=== Data Resources ===

* http://trixter.oldskool.org/2014/06/19/8088-domination-post-mortem-part-1/
* http://en.wikipedia.org/wiki/Color_Graphics_Adapter#The_CGA_color_palette

== Audio Format ==
The audio format used in 8088 Corruption is simply unsigned, mono, 8-bit [[PCM]].

[[Category:Video Codecs]]
[[Category:Platform-Dependent Codecs]]

Category:Platform-Dependent Codecs

2014-07-25T21:23:59Z

Trixter:

List of all codecs that were designed or engineered for a specific hardware platform.

This sub-category describes "one-off" implementations that demonstrate [[FMV]] on a specific vintage, homebrew, or console platform. The category is meant to denote any platform not typically designed to be capable of decoding or displaying FMV (ie. limited color palette, limited memory, very slow CPU, no mass-storage device, etc.)

Said codecs have highly platform-dependent implementations and limitations that make them mostly unsuitable for more general-purpose use.

[[Category:Video Codecs]]

SGA

2014-07-25T21:21:18Z

Trixter:

* Extension: SGA
* Samples: [http://samples.mplayerhq.hu/game-formats/segacd/sga/ http://samples.mplayerhq.hu/game-formats/segacd/sga/]

SGA is a chunk-based multimedia file format used primarily in games by [[Digital Pictures]] for the [[Sega CD]] console system. Early versions of the format store uncompressed video frames, while later revisions add features such as [[LZ]] compression, tile maps, and overlapping chunks. The extension for SGA files is usually ".SGA", but some files from ''Supreme Warrior'' have the extensions ".CLP" and ".PT1", and some files from ''Slam City with Scottie Pippen'' have extensions that include numbers (e.g. ".SG0", ".S37", etc.). Variations of the format are found in versions of Digital Pictures games for [[DOS]] PCs and the [[3DO]]. In those versions all video and audio is stored in large, monolithic files rather than individual files.

== File Format ==
All multi-byte numbers in a SGA file are big-endian, since the Sega Genesis and Sega CD both use big-endian Motorola 68000 CPUs.

There are three known methods of storing data in SGA files:

(1) In the majority of files, each chunk is stored using 2048 byte sectors due to the nature of CD storage. The first sector in the file contains 2048 bytes of data, each subsequent sectors contain a 2 byte header specifying how much of the chunk is left followed by 2046 bytes of data. One item to be aware of is if the value of the header is zero then to skip the next 2046 bytes and check the next header. (I'm presuming this has something to do with padding the CD for faster loading?)

(2) Some files, in particular the audio-only files in ''Night Trap'' (all variations), do not use length indicators at the start of sectors. The files contain strictly chunk headers and data.

(3) Later versions of the SGA format, as seen in ''Slam City with Scottie Pippen'', ''Prize Fighter'', and ''Supreme Warriors'', introduced a scheme in which chunks can overlap/interrupt other chunks. In this type of file, each sector begins with a two-byte sector header, with the top four bits set to a non-zero value, which we might call the chunk index. If the following twelve bits are set to zero, then we are at the start of a new chunk using the current index. If the following twelve bits are non-zero, then we are looking at a length value, similar to previous formats. A decoder written to handle this type of file would have to keep track of multiple chunks simultaneously. Videos used in ''Slam City'' use a container chunk (type F1) which generally contains a video chunk followed by an audio chunk. Videos in ''Supreme Warrior'' begin with what appears to be a global header (type F0) in addition to the F1 container chunk, but at present it is unknown how to interpret the metadata. There is also another chunk type, F2, whose use is presently unknown. F2 chunks can also exist in separate files of the extension ".F2". So far, all that it known about F2 chunks is that they often contain what appear to be filenames.

Most SGA files do not contain a global header, but have headers for each chunk. In files of type (1) and (2), headers are never split across sector boundaries. In files of type (3), chunk headers can be split across sector boundaries as long as they are contained within a chunk of type F1. Chunks are word aligned, can contain video or audio. The basic header is 4 bytes long, and is shared by all chunk types.

Byte Description
---- -----------
0 Chunk type
1 Stream index (Sewer Shark in particular uses this for its branching path-based gameplay)
2-3 Payload length

This is followed by more metadata:

Byte Description
---- -----------
4-7 Time in [[SMPTE]] format

Video chunks for the Sega CD contain the following metadata:

Byte Description
---- -----------
8 Data flags
9 Palette count (1-4)

A value of 1 for the topmost bit of byte 8 means that the chunk uses a tile map. Data for the tile map immediately follows the tile data. Each entry in the tile map is two bytes long, and consists of a tile index and flags for features such as vertical and horizontal flipping. Bits 3 and the lowermost bit 1 are usually set to 1, although their exact purpose is unknown. There may be some connection between bit 1 and tilemaps, though, since tilemap behavior seems to change when the bit is not set.
Metadata in video chunks for the Sega CD 32X are as follows:

Byte Description
---- -----------
8 Palette start offset (usually 1)
9 Palette update size (a value of 0 means use existing palette)

Then more metadata (both Sega CD and Sega CD 32X):

Byte Description
---- -----------
10 tiles per column
11 tiles per row

In overlay chunk types D1 (and possibly D4), byte 10 indicates the number of tiles in the chunk, and byte 11 indicates the length the data for what are assumed to be codes that specify the layout of the tiles. Since each tile takes up 32 bytes, the length of the tile data is equal to the value in byte 10 * 32. Tile data is immediately followed by layout codes, which as of this writing are yet to be deciphered.

Certain types of video chunks contain additional metadata, which is detailed below in the sections related to the various chunk types.

Audio chunks have the following metadata:

Byte Description
---- -----------
8-9 Sample rate
10 (Probably) Number of channels / bytes per sample (usually 1)
11 Unknown (usually 0)

== Chunk Types ==
Some known chunk types are:

* $81: encoded video (used in most Sega CD 32X games by Digital Pictures)
* $A1: audio, sign/magnitude 8-bit PCM
* $C1: uncompressed video (used in Night Trap SCD, Sewer Shark, Corpse Killer SCD, and others)
* $C2: compressed video (used in Corpse Killer SCD, Slam City with Scottie Pippen, and others?)
* $C4: compressed? video (used in Slam City with Scottie Pippen)
* $C6: compressed video (used in Night Trap SCD "DPLOGO.SGA", Sewer Shark, Make My Video C&C, and others)
* $C7: compressed video (used in Prize Fighter and others)
* $C8: compressed video (used in Sewer Shark, Make My Video C&C, and others)
* $CB: compressed video (used in Prize Fighter, Double Switch "DPLOGO.SGA", Corpse Killer 32X)
* $CD: compressed video (used in Double Switch)
* $D1: uncompressed overlay video (used in Sewer Shark when killing a Ratigator(TM), etc)
* $D4: compressed? overlay video (used in Corpse Killer SCD/32X for the zombies)
* $E7: (un)compressed video (used in the Make My Video series)
* $E8: compressed video (used in Ground Zero Texas)
* $E9: compressed video (used in Ground Zero Texas)
* $F0: container for other chunks (used in Slam City with Scottie Pippen)
* $F1: container for other chunks (used in Slam City with Scottie Pippen)
* $F2: metadata of unknown use

As of this writing, the format and compression of the following types are generally understood: 81, A1, C1, C6, C7, C8, CB, CD, E7, and F1.

== Encoded Video $81 ==
This type of video is probably most appropriately called "encoded" rather than "compressed". Video frames of this type are represented with a series of codes that indicate the size, color, and pixel layout of the graphics to be drawn, rather than, for example, LZSS encoded byte streams as in previous versions of SGA files.

The encoding scheme has been completely reverse-engineered, and a functional decoder has been written. A detailed description of the codes will be added at a later time.

== Audio $A1 ==
Audio sample rate can be determined in the following way (for NTSC systems only?):

SamplesPerSecond = ((Byte 8 << 8) + Byte 9) * SEGA_CD_PCM_INCREMENT

SEGA_CD_PCM_INCREMENT is ~15.8945723, and is calculated as SEGA_CD_PCM_FREQUENCY_MAX / 2048

SEGA_CD_PCM_FREQUENCY_MAX is ~32552.084, and is calculated as SEGA_CD_CPU_FREQUENCY / 384

SEGA_CD_CPU_FREQUENCY is 12500000, and is calculated as SEGA_CD_CRYSTAL_FREQUENCY / 4

SEGA_CD_CRYSTAL_FREQUENCY is 50000000

The sample rate can also be used to determine the frame rate of video by using the formula SamplesPerSecond / NumSamples, where NumSamples is the length of the audio data in the audio chunk.

== Uncompressed Video $C1 ==
For compatibility with the Genesis' video hardware, video frames in this format (and all its derivatives) are made up of linear 8x8 pixel tiles. Each pixel consists of a 4-bit (one nibble) palette index, thus each tile takes up 32 bytes. The length of the tile data can be calculated as tilesPerColumn * tilesPerRow * 32.

Palette data immediately follows the tile data. Each palette is 18 bytes long. Palettes are stored in an unusual format. As the genesis normally uses either RGB or BGR stored in nibbles (even though only the top 3 bits are used).

<pre>
bitmap={1,2,4}

For bit=0 to 2
for color=0 to 15
red[color]+=Top Most Bit of Data *bitmap[bit]
next
next
</pre>

Repeat for green and blue.

Reading 2 bits for each tile, determines which of the 4 palettes to use.

<pre>
For Row=0 to RowMax
For Col=0 to ColMax
PalMap[Row*ColMax+Col]=Top 2 Bits of data
Next
Next
</pre>

When drawing a tile you would select the palette based upon PalMap. Note that palette maps for 2 palette frames use only 1 bit per palette map entry vs 2 bits for 3 or 4 palettes.

If a frame has a tilemap, the tilemap immediately follows the palette data. Each tilemap entry is 16 bits long, and so the length of the tilemap in bytes is tilesPerColumn * tilesPerRow * 2. Tilemaps also contain palette information, and so frames with tilemaps do not contain a separate palette map. The top 4 bits of a tilemap entry indicate the palette index of the tile, and the remaining 12 bits indicate the index of the tile itself.

== Compressed Video $C6, $C7, $C8 ==
Chunks in this format contain the same basic elements as chunks of type C1 (tiles, palette, palette map, tilemap, etc), but are compressed in LZSS format. The compressed data are comprised of several 34 byte LZSS blocks. Each block contains a one word (2 bytes) tag of compression flags followed by 16 words of data.

The tag is read in bits, starting with the most significant (left most) bit. For each bit set to 0, there is an uncompressed word literal. For each bit set to 1, the following word is a displacement/length reference in the following format:

<pre>LLLD DDDD DDDD DDDD

L = Amount of words to copy (amount of bytes to copy * 2)
D = Displacement</pre>

This may be calculated as:

<pre>for count = 0 to top 3 bits of LZ word * 2
data[current + count] = data[current + count - last 13 bits of LZ word]
next</pre>

Note that the displacement, unlike the copy amount, is based on bytes, not words. Also, the displacement does not have to be word aligned.

After the entire tag is read, the next flag block is read, and the process continues. The sequence ends when an reference word's top three bits are all zeros.

In C7 format chunks, the top three bits represent the amount of words to copy minus one. Any decoder that implements C7 decoding must take this into account.

Most chunks in C6, and all chunks C8 and E7 formats require that adjacent pixels in even-numbered lines be swapped for frames to be correctly displayed. The exact reason for this is unclear, although since Sega CD video often contains a lot of checkerboard dithering, swapping pixels would eliminate the checkerboard patterns and lead to higher amounts of identical/redundant data, thus leading to more efficient compression. There is currently no known way to determine which C6 chunks require pixel swapping, however, it seems that pixel swapping only occurs in C6 frames that use fewer than 3 palettes and that do not use a tilemap.

== Compressed Video $CB, $CD, $E7 ==
Like other compressed chunk formats, chunks in this format consist of several 34 byte LZSS blocks. Each block contains a one word (2 bytes) tag of compression flags followed by 16 words of data.

For each bit set to 1, the following word is a displacement/length reference in the following format:

<pre>LLLL DDDD DDDD DDDD

L = Amount of words to copy minus one (amount of bytes to copy * 2)
D = Displacement</pre>

This may be calculated as:

<pre>for count = 0 to (top 4 bits of LZ word + 1) * 2
data[current + count] = data[current + count - last 12 bits of LZ word]
next</pre>

Chunks of type E7 are used in the Make My Video series, and contain three subframes, which are stacked on top of each other to complete the whole frame. C7 chunks have an additional six bytes of metadata containing three 16-bit values. The topmost bit of each value indicates whether the data for that frame is raw (1) or compressed (0). The remaining 15 bits represent the length of the data for the subframe, with an apparent maximum value of 0x1500. The data for each subframe immediately follows the metadata in order, which is followed by 180 bytes of palette data in the usual format.

== Games Using SGA ==
* Night Trap
* Sewer Shark
* Power Factory Featuring C&C Music Factory
* Make My Video series
* Ground Zero: Texas
* Prize Fighter
* [http://www.mobygames.com/game/sega-cd/double-switch Double Switch]
* Slam City with Scottie Pippen
* Corpse Killer
* Supreme Warrior

== Decoders/Converters ==
* A decoder has been written that can currently decode SGA files from Night Trap (SCD and 32X), Sewer Shark (including stream selection), Corpse Killer (SCD and 32X), Prize Fighter, Double Switch, as well as various other games, and convert them to AVI format files. It has yet to be released to the public.

[[Category:Game Formats]]
[[Category:Platform-Dependent Codecs]]

2014-07-21T15:58:56Z

Trixter:

List of all codecs that were designed or engineered for a specific hardware platform.

This sub-category is meant to describe "one-off" implementations typically demonstrating [[FMV]] on a vintage or homebrew platform, or on any platform not typically capable of decoding or displaying FMV.

[[Category:Video Codecs]]

2006-01-18T07:03:54Z

Trixter:

''This document is based on the document 'Description Of The Origin Xan Video Codec' by Mike Melanson and Mario Brito found at [http://multimedia.cx/xan-format.txt http://multimedia.cx/xan-format.txt].''

In 1994, Origin published the third installment of their popular Wing Commander space flight combat simulation games, [http://www.mobygames.com/game/dos/wing-commander-iii-heart-of-the-tiger Wing Commander III: Heart of the Tiger]. The game is distributed as 4 CD-ROMs and the underlying story was driven by a lot of full motion video (FMV). The FMV is transported in a [[Wing Commander III MVE|custom file format with the extension mve]] (see the references for more information on this format). The video data in these files is compressed with a custom, unidentified video codec (referred to here as the WC3 codec).

The WC3 codec is a computationally simple video codec that is designed to compress frames of RGB video data at a nominal resolution of 320x165 pixels. The coding method embodies both intraframes (keyframes) and interframes. The algorithm relies on variations of run-length coding and textbook Huffman coding. For interframe compression, the algorithm uses run-based motion compensation. This varies from usual MC methods which are block-based.

== Unpacking Algorithm ==

The WC3 video codec relies on the following bytewise unpacking algorithm taking an output buffer and an input buffer:

wc3_unpack(unsigned char *dest, unsigned char *src):
x = next byte
if bit 7 of x is 0:
offset = next byte
/* x: 0aabbbcc */
size = bottom 2 bits of x (0..3) (this represents bits 'cc')
bytecopy size bytes from src to dest
size = (x & 0x1C) >> 2 + 3 (this represents bits 'bbb')
bytecopy size bytes from current pos - ((x & 0x60) << 3) + offset + 1
else if bit 6 of x is 0:
fetch next byte from stream as byte1
fetch next byte from stream as byte2
size = top 2 bits of byte1 (0..3)
bytecopy size bytes from src to dest
size = bottom 6 bits of x + 4 (range: 4..67)
bytecopy size bytes from dest - ((byte1 & 0x3F) << 8) + byte2 + 1
else if bit 5 of x is 0:
fetch next byte from stream as byte1
fetch next byte from stream as byte2
fetch next byte from stream as byte3
size = bottom 2 bits of x (0..3)
bytecopy size bytes from src to dest
size = byte3 + 5 + ((x & 0xC) << 6);
bytecopy (dest,
dest - ((((x & 0x10) >> 4) << 0x10) + 1 + (byte1 << 8) + byte2),
size);
else (this means one of the top 3 bits was 1)
size = (x & 0x1F) * 4 + 4
if size > 0x70
break
copy size bytes from src to dest

This process is repeated in a loop until the break in the else case. On the way out, copy (x & 3) bytes from src to dest.

An important note about the preceding pseudocode description: When the code says that a 'bytecopy' operation is to be performed from buffer a to buffer b, neither a memcpy nor a memmove call will do. The reason is that the bytecopy function is often used to copy between overlapping memory regions. It is not uncommon for dest to equal (src + 1). This has the net effect of turning 'A' into 'AAAAAA...". This function was originally implemented on x86 microprocessors as a 'repz stosb' instruction, which means to store a string by byte repeatedly.

== WC3 Codec Format ==

The [[Wing Commander III MVE]] file format packages sequences of video and audio frames together marked by SHOT chunks. Each SHOT chunk has a 768-byte RGB palette specified in the file header. The file demuxer must make the appropriate palette available to the video decoder when a new SHOT begins.

A chunk of WC3 Xan data is formatted as follows:

header | segment 1 | segment 2 | segment 3 | segment 4

The header contains offsets to each of the segments within the chunk:
* Segment 1 contains Huffman-coded image compression codes.
* Segment 2 contains auxiliary size information.
* Segment 3 contains interframe motion vectors.
* Segment 4 contains raw or compressed palettized video data.

The chunk header is always 8 bytes long. The on-disk data format for a chunk header is:

bytes 0-1 absolute offset of segment 1 within chunk (always offset 8)
bytes 2-3 absolute offset of segment 2 within chunk
bytes 4-5 absolute offset of segment 3 within chunk
bytes 6-7 absolute offset of segment 4 within chunk

All of the 16-bit segment offsets are stored in little endian byte order. Note that the offset of segment 3 within an intracoded chunk (keyframe) ought to be 0x0000 as there are no motion vectors for an intraframe.

The first step in decoding a frame involves decoding the Huffman codes in segment 1 in order to decode the compression codes. The segment is laid out as follows:

byte 0 number of values in the Huffman tree (should be 22)
bytes 1..44 Huffman tree table
bytes 45.. Huffman-coded data.

There are 22 values in the Huffman tree since there are 22 possible compression codes (0..21) used to assemble the final output frame. Actually, there is one more value found in the table (22) that signals
the end of the Huffman stream. The root of the Huffman tree is at the last byte of the table. Bits in the bytes of the Huffman-coded bits are coded right-to-left.

Assumng the Huffman tree table is stored in huff[44] where the bytes are indexed 0..43, and the root node is at index 43. The decoding algorithm is:

while (value @ current node index != 22)
if the next bit in the coded stream is 0
move current node index to (current node index - 22)
else
move current node index to (current node index - 1)
if (value < 22)
decompression code found, place in output buffer and reset the
current index to the root node

After decoding the compression codes, check the first byte of segment 2 to see if the raw pixel data needs to be decoded. If the first byte equals 0x02, pass the remainder of the buffer through the wc3_unpack function. Otherwise, use the data from the second byte forward as the pixel data.

The final step builds the frame and uses data from all 4 segments. The algorithm operates as follows (assuming a palettized output buffer that is width * height bytes in size):

flag = 0
index = 0
while index < frame size (width * height):
x = next compression code in segment 1
size = 0
if x is 0, toggle flag and goto next iteration
if x is 1..8, size = x
if x is 12..18, size += (x - 10) (net effect: add 2..8)
if x if 9 or 19, size = next byte in segment 2
if x is 10 or 20, size = the next BE_16 number in segment 2
if x is 11 or 21, size = the next BE_24 number in segment 2
if x < 12:
toggle flag
if flag is 1, run is unchanged from previous frame:
for each count in size, copy pixel from same index in previous
frame
else /* flag is 0 */:
for each count in size, copy the next pixel in segment 4 to the
output
else:
motion byte = next byte in segment 3
x = top nibble of motion byte
y = bottom nibble of motion byte
sign-extend the nibbles in x and y
copy size bytes from the position referenced by (x, y) in the
previous frame to the current frame
reset flag

Note that BE_16 means a 16-bit number in big endian format, and BE_24 means a 24-bit number in big endian format.

== Codec Trivia ==

Origin originally advertised a 486/33 and 2X (300KB/s) CDROM drive as the minimum requirements for playing the video. However, video playback functions perfectly on a 386/40 (about 20% slower than a 486/33) and, with few exceptions, plays just fine on a 1X (150KB/s) CDROM drive. This suggests that Origin was either being conservative with requirements in an effort to ward off anticipated tech support calls caused by flaky clones (a common occurance, unfortunately), or possibly had originally targeted 1X CDROM drives but had to go over the 150KB/s datarate in a few scenes due to low picture quality.

(For the curious, the scenes that don't quite make the 1X datarate cut are scenes where more than 30% of the scene is changing in every frame, such as the spaceflight sequences in the introduction, or scenes that take place in the hanger.)

[[Category:Video Codecs]]
[[Category:Game Formats]]