MultimediaWiki - User contributions [en]

Outcast SFX

2018-02-25T14:38:06Z

Siberian GRemlin: Created page with "* Extension: sfx * Company: Appeal S.A. SFX files are audio files with GSM 06.10 audio used in http://www.mobygames.com/game/windows/outcast Outcast game for IBM-..."

* Extension: sfx
* Company: [[Appeal S.A.]]

SFX files are audio files with [[GSM 06.10]] audio used in [[http://www.mobygames.com/game/windows/outcast Outcast]] game for IBM-PC.

== SFX File Format ==
File consist 20-byte header and GSM-FR data.

Header contains next fields.
* ''DWORD ID'' -- always equals 0x98765432.
* ''DWORD Channels'' -- unsure? always equals 1 (mono).
* ''FLOAT CompressionFactor'' -- always equals 1.0.
* ''DWORD DataSize'' -- size of audio data.
* ''DWORD SoundFrequencyHz; -- always(?) equals 22050.

After header GSM-FR data coming.

SFX files can be converted by using sfx2wav tool from Impact Inc. or you can cut off header and decompress raw GSM data with [[ffmpeg]] or [[SoX]] tools.

== Links ==
http://playtechs.blogspot.ru/2010/05/reading-outcast-sfx-files.html

[[Category:Audio Codecs]]
[[Category:Game Formats]]

Duck IVF

2017-10-18T07:32:03Z

Siberian GRemlin: /* PC games using IFV files */

* Extension: ivf
* Samples: The test-vectors-* archives available here: https://chromium.googlesource.com/webm/vp8-test-vectors

IVF is a simple file format that transports raw VP8 data.

Multi-byte numbers of little-endian. An IVF file begins with a 32-byte header:

bytes 0-3 signature: 'DKIF'
bytes 4-5 version (should be 0)
bytes 6-7 length of header in bytes
bytes 8-11 codec FourCC (e.g., 'VP80')
bytes 12-13 width in pixels
bytes 14-15 height in pixels
bytes 16-19 frame rate
bytes 20-23 time scale
bytes 24-27 number of frames in file
bytes 28-31 unused

The header is followed by a series of frames. Each frame consists of a 12-byte header followed by data:

bytes 0-3 size of frame in bytes (not including the 12-byte header)
bytes 4-11 64-bit presentation timestamp
bytes 12.. frame data

== PC games using IFV files ==

* Rogue Trooper Redux

[[Category:Container Formats]]

Duck IVF

2017-10-18T07:31:35Z

Siberian GRemlin:

Interplay ACM

2017-06-22T16:09:06Z

Siberian GRemlin: /* Games Using Interplay ACM */

* Extension: acm or wav
* Company: [[Interplay Entertainment]]
* Samples:
* Sample Parser:

* Usage: Sound format
* FourCC: 0x97 0x28 0x03 0x01
* Tools:
** [http://libacm.berlios.de/ libacm]: An open source library for decoding Interplay ACM files

This is a lossy compressed audio format with a rather weak compression ratio. (converted to WAV then recompressed to OGG makes it roughly half size). ACM files can be in varying sample rates, but the common one is 22050 Hz, 16 bits and stereo.

== File Format ==
Multi-byte numbers are little-endian.

The ACM header:
0x00 FOURCC
0x04 sample count
0x08 channel count (some ACM files lie about the channel count)
0x0a sample rate
0x0c levels (4 bits) and subblocks (12 bits)
0x0e <data>

struct ACM_Header {
long fourcc;
long samples;
unsigned short channels;
unsigned short rate;
unsigned short levels : 4;
unsigned short subblocks : 12;
};

The infinity games also contain a WAVC header which contains mostly redundant information. These files are used for all sound except music (ambients, voice over, sound effects).

The WAVC header:

struct WAVC_HEADER {
char wavc_sig[4]; //WAVC
char wavc_ver[4]; //V1.0
long uncompressed; //the uncompressed length (i guess it is raw pcm)
long compressed; //the compressed length
long headersize; //28 (the size of this header, also the offset to the ACM header)
short channels; //1 or 2
short bits; //8 or 16
short samplespersec; //usually 22050
short unknown;
};

== Games Using Interplay ACM ==
* [http://www.mobygames.com/game/baldurs-gate Baldur's Gate]
* [http://www.mobygames.com/game/fallout Fallout]
* [http://www.mobygames.com/game/icewind-dale Icewind Dale]
* [http://www.mobygames.com/game/mdk-2 MDK2]
* [http://www.mobygames.com/game/windows/planescape-torment Planescape: Torment]

[[Category:Game Formats]]

HNM

2010-07-17T18:28:33Z

Siberian GRemlin: /* Games Using HNM */

* Extension: hnm
* Company: [[CRYO Interactive Entertainment]]

HNM is a multimedia format used in almost every computer game by CRYO.

During it's lifetime, format has been changed at least 6(+1) times.
* [[HNM (0)]] aka HNM Zero. Used in debut Cryo' games - Dune (floppy version) and KGB to display animated Cryo logo. Uses typeless chunks and single rotated palette for the whole movie. No sound.
* [[HNM (1)]] Improved version, with typed chunks, dynamic palettes and (optional) soundtrack.
* [[HNM4]] First version, where HNM tag explicitly written in the file header. Used in many games released during 1995-1997.
* [[HNM4 (A)]] Hi-resolution format spin-off, used in ALIENS game. While all file tags indicates genuine HNM4, interframe (de)compression is not compatible.
* [[UBB]] Another hi-resolution spin-off, first appeared in MegaRace 2 game. Same file structure as in HNM4, but completely reworked codec.
* [[HNM6]] Finally, movies comes in hi-color. Based on [[JPEG]] compression.
* Currently, [[Kheops Studio]] uses HNM-successor called [[KSV]] to carry [[XviD]]-encoded FMVs.

This forum discusses the coding algorithms used in the format: http://dune2k.com/forum/index.php?topic=18539.90

== Games Using HNM ==
* [http://www.mobygames.com/game/dos/aliens-a-comic-book-adventure Aliens: A Comic Book Adventure]
* [http://www.mobygames.com/game/atlantis-the-lost-tales Atlantis: The Lost Tales]
* [http://www.mobygames.com/game/china-the-forbidden-city China: The Forbidden City]
* [http://www.mobygames.com/game/commander-blood Commander Blood]
* [http://www.mobygames.com/game/dos/dune Dune]
* [http://www.mobygames.com/game/windows/frank-herberts-dune Frank Herbert's Dune]
* [http://www.mobygames.com/game/windows/gift Gift]
* [http://www.mobygames.com/game/dos/kgb KGB]
* [http://www.mobygames.com/game/dos/lost-eden Lost Eden]
* [http://www.mobygames.com/game/dos/megarace MegaRace]
* [http://www.mobygames.com/game/windows/persian-wars Persian Wars]
* [http://www.mobygames.com/game/windows/philip-jos-farmers-riverworld Riverworld]

[[Category:Game Formats]]

VQA

2010-03-06T17:47:07Z

Siberian GRemlin: /* Games Using VQA */

* Extension: vqa
* Company: [[Westwood Studios]]
* Samples: [http://samples.mplayerhq.hu/game-formats/vqa/ http://samples.mplayerhq.hu/game-formats/vqa/]

VQA stands for Vector Quantized Animation and is a FMV format used in a number of computer games by Westwood Studios.

== Technical Description ==

'''TODO: import and combine Gordan Ugarkovic's documents from [http://multimedia.cx/VQA_INFO.TXT http://multimedia.cx/VQA_INFO.TXT] and [http://multimedia.cx/HC-VQA.TXT http://multimedia.cx/HC-VQA.TXT].
==VQA_INFO.txt==

===NOTE #1===
This document only applies to VQA files in the original C&C and C&C: Red Alert (version 2) as well as Legend of Kyrandia III : Malcolm's Revenge (version 1). It DOES NOT apply to the HiColor VQAs found in Westwood's newer games. They use a somewhat different approach to compressing video data (I will provide some facts about their sound stream, though). Look at my other document (HC-VQA.TXT) for a description of the HiColor VQA movies.

===NOTE #2===
Throughout the document, I will assume that:
* CHAR is 1 byte in size, unsigned,
* SHORT is 2 bytes in size, unsigned,
* LONG is 4 bytes in size.

Each VQA file is comprised of a series of chunks. A chunk can contain
other sub-chunks nested in it. Every chunk has a 4 letter ID (all uppercase
letters) and a LONG written using Motorola byte ordering system (first
comes the Most Significant Byte), unlike the usual Intel system (Least
Significant Byte first).

For example, if you had a value 0x12345678 in hexadecimal, using the Intel
notation it would be written as 78 56 34 12, while using Motorola's
12 34 56 78.

NOTE: Some chunk IDs start with a NULL byte (0x00) because of reasons
that will become apparent later. You should just skip this byte
and assume the next 4 letters hold the chunk ID.

Following the chunk header is the chunk data.

===Typical VQA File===
Here is a scheme of a typical VQA file (nested chunks are indented):

FORM
VQHD
FINF <- Frame data positions
SND? \ <- First sound chunk, contains 1/2 second of sound
SND? | <- Contains 1 frame's worth of sound
VQFR | <- Contains various video data chunks
CBF? | 1st frame data
CBP? |
CPL? |
VPT? /
SND? \
VQFR | 2nd frame data
CBP? |
VPT? /
SND? \
VQFR | 3rd frame data
CBP? |
VPT? /
. . .

NOTE: There can also be some other chunks (i.e. PINF, PINH, SN2J) included,
but they are not relevant (?!) for viewing the movie, so they can
easily be skipped.

===FORM chunk===

This chunk is the main chunk, containing all other chunks.
In case of version 2 and 3 movies, its size is actually the size of the
entire file minus the size of the chunk header (8 bytes). Version 1 movies
seem to have this set to the length of the header VQHD + FINF chunk.

Immediately after the chunk's header, a 4-character signature,
"WVQA" is located. Then come all the other chunks.

===VQHD chunk ("VQa HeaDer" ???)===

This is the header chunk, containing vital information about the movie.
Its size is always 42 bytes.
The information is structured like this:

struct VQAHeader
{
short Version; /* VQA version number */
short Flags; /* VQA flags */
short NumFrames; /* Number of frames */
short Width; /* Movie width (pixels) */
short Height; /* Movie height (pixels) */
char BlockW; /* Width of each image block (pixels) */
char BlockH; /* Height of each image block (pixels) */
char FrameRate; /* Frame rate of the VQA */
char CBParts; /* How many images use the same lookup table */
short Colors; /* Maximum number of colors used in VQA */
short MaxBlocks; /* Maximum number of image blocks */
long Unknown1; /* Always 0 ??? */
short Unknown2; /* Some kind of size ??? */
short Freq; /* Sound sampling frequency */
char Channels; /* Number of sound channels */
char Bits; /* Sound resolution */
long Unknown3; /* Always 0 ??? */
short Unknown4; /* 0 in old VQAs, 4 in HiColor ones ??? */
long MaxCBFZSize; /* 0 in old VQAs, max. CBFZ size in HiColor */
long Unknown5; /* Always 0 ??? */
}

Version denotes the VQA version. Valid values are:
* 1 - First VQAs, used only in Legend of Kyrandia III.
* 2 - Used in C&C, Red Alert, Lands of Lore II, Dune 2000.
* 3 - Lands of Lore III (?), Blade Runner (?), Nox and Tiberian Sun. These VQAs are HiColor (15 bit).

Flags most probably contain some flags. I only know that bit 0 (LSB)
* denotes whether the VQA has a soundtrack or not.
* (1 = Has sound, 0 = No sound)

Width is usually 320, Height is usually 156 or 200 although one movie in
* Red Alert is 640x400 in size (the start movie for the Win95 version).

Each frame of a VQA movie is comprised of a series of blocks that are
BlockW pixels in width and BlockH pixels in height. Imagine the frame
is a mosaic with the blocks being 'pieces' that make up the frame.

BlockW is the width and BlockH is the height of each screen block.
In VQAs version 2 (and perhaps 1) the blocks are usually 4x2.

FrameRate is always 15 in C&C and RA and seems to be 10 in LoK III.

CBParts denotes how many frames use the same lookup table. It also
implies how many parts the new block lookup table is split into.
In C&C and RA it is always 8.

Colors indicates the maximum number of colors used by the VQA.
The HiColor VQAs have this set to 0, while the old movies have
256 or less in here.

Freq is usually 22050 Hz. Note that version 1 movies can have this set
to 0 Hz. In that case, you should use 22050 Hz.

Channels specifies the number of sound channels, i.e. is the sound
mono or stereo. Channels=1 -> sound is mono, Channels=2 -> stereo.
C&C and RA almost always use mono sound.
Version 1 can have this set to 0, but you should use 1 (mono sound).
The majority of Tiberian Sun movies use stereo sound instead.

* Bits indicates whether the sound is 8 bit or 16 bit.
Bits=8 -> 8 bit sound, Bits=16 -> 16 bit sound (surprise! :).
The Legend of Kyrandia III: Malcolm's Revenge uses 8 bits where
C&C, RA, TS, Dune 2000, Lands of Lore III use 16 bits.
Note, again, that version 1 of the VQAs can have this set to 0 in
which case 8 bits are assumed.

MaxCBFZSize is a new entry, specific to the HiColor VQAs. It tells
you the size of the largest CBFZ chunk, in bytes.

Following the chunk data are the sub-chunks.

===FINF chunk ("Frame INFormation" ???)===

This chunk contains the positions (absolute from the start of the VQA)
of data for every frame.
That means that it points to the SND? chunk associated with that frame,
which is followed by a VQFR chunk containing frame's video data.

The positions are given as LONGs which are in normal Intel byte order.

'''NOTE:''' Some frame positions are 0x40000000 too large. This is a flag
indicating those frames contain a new color palette. To get the
actual positions, you should subtract 0x40000000 from the values.

'''NOTE #2:''' To get the actual position of the frame data you have to multiply
the value by 2. This is why some chunk IDs start with 0x00. Since
you multiply by 2, you can't get an odd chunk position so if the
chunk position would normally be odd, a 0x00 is inserted to make
it even.

===SND? chunk ("SouND" ???)===
These chunks contain the sound data for the movie. The last byte of the ID
can be either '0', '1' or '2' so the actual IDs would be "SND0", "SND1"
and "SND2".

In VQAs version 1 (Legend of Kyrandia 3) there are ''NumFrames'' sound chunks.
Old 8 bit VQA movies of version 2 have ''NumFrames+1'' sound chunks.
Note, however, that Dune2000 movies, which are also version 2, but HiColor
have ''NumFrames'' sound chunks, instead.
Version 3 movies also have ''NumFrames'' sound chunks.

In case of the old, 8 bit VQAs, the first chunk contains half a second
(ver. 2) or more (ver. 1) of the wave data, in all (?) the HiColor movies
the first chunk contains exactly the amount of sound required for one
frame of the movie. The downside is this requires a somewhat more advanced
buffering technique on the side of the player in order to allow smooth
playback.

===SND0 chunk===

This one contains the raw 8 or 16 bit PCM wave data. If the data is
8 bit, the sound is unsigned and if it is 16 bit, the samples are
signed.

===SND1 chunk===

It contains 8 bit sound compressed using Westwood's own
proprietary ADPCM algorithm. The chunk has a 4 byte header:

struct SND1Header
{
short OutSize;
short Size;
}

These values are needed for the decoding algoritm (see APPENDIX C).
The encoded samples follow immediately after the header.
It's important to know this algorithm produces UNSIGNED sound, unlike
the IMA ADPCM algorithm supplied here (see below). It is, however very
simple to adapt both algorithms to produce either signed or unsigned
sample output...

===SND2 chunk===

It contains the 16 bit sound data compressed using the IMA ADPCM
algorithm which compresses 16 bits into 4. That's why the SND2 chunks
are 4 times smaller than SND0 chunks and they are used almost all
the time. For the description of the algorithm, see later in the document.

Different VQA versions have different stereo sample layout. In case
of Tiberian Sun stereo sound is encoded the same way as mono except the
SND2 chunk is split into two halfs. The first half contains the left channel
sound and the second half contains the right channel. The layout of
nibbles is as follows: LL LL LL LL LL ... RR RR RR RR RR.
Old movies (C&C, RA) use a different layout. Here, the nibbles are packed
together like this: LL RR LL RR LL RR ... This means that two left channel
samples are packed into one byte and then two right channel samples are
packed into another.

Naturally, the size of a stereo SND2 chunk is exactly twice as big as
a mono SND2.

It is important to note that, when decoding, you have to keep separate
values of ''Index'' and ''Cur_Sample'' for each channel (see APPENDIX B).

===VQFR chunk ("Vector Quantized FRame" ???)===

A chunk that includes many nested sub-chunks which contain video data.
It doesn't contain any data itself so the sub-chunks follow immediately
after the VQFR chunk header.
All following sub-chunks are nested inside a VQFR chunk. They can all
contain '0' or 'Z' as the last byte of their ID.

* If the last byte is '0' it means that the chunk data is uncompressed.
* If the last byte is 'Z' it means that the data is compressed using
Format80 compression. You can find its description in APPENDIX A.

===CBF? chunk ("CodeBook, Full" ???)===

Lookup table containing the screen block data as an array
of elements that each are BlockW*BlockH bytes long. It is always located
in the data for the first frame. In Vector Quantization terminology
these tables are called CODEBOOKS.

There can be max. 0x0f00 of these elements (blocks) at any one time in
normal VQAs and 0xff00 in the hi-res VQAs (Red Alert 95 start movie) although
I seriously doubt that so many blocks (0xff00 = 65280 blocks) would
ever be used.

The uncompressed version of these chunks ("CBF0") is used mainly in
the original Command & Conquer, while the compressed version ("CBFZ")
is used in C&C: Red Alert.

===CBP? chunk ("CodeBook Part" ???)===

Like CBF?, but it contains a part of the lookup table, so to get the new
complete table you need to append CBParts of these in frame order.
Once you get the complete table and display the current frame, replace
the old table with the new one.
As in CBF? chunk, the uncompressed chunks are used in C&C and the compressed
chunks are used in Red Alert.

'''NOTE:''' If the chunks are CBFZ, first you need to append CBParts of them and
then decompress the data, NOT decompress each chunk individually.

===CPL? chunk ("Color PaLette" ???)===

The simplest one of all... Contains a palette for the VQA. It is an
array of red, green and blue values (in that order, all have a size of
1 byte). Seems that the values range from 0-255, but you should mask out
the bits 6 and 7 to get the correct palette (VGA hardware uses only
bits 0..5 anyway).

===VPT? chunk: ("Vector Pointer Table" ???)===

This chunk contains the indexes into the block lookup table which contains
the data to display the frame.
The image blocks are called VECTORS in Vector Quantization terminology.

These chunks are always compressed, but I guess the uncompressed ones
can also be used (although this would lower the overall compression achieved).

The size of this index table is ''(Width/BlockW)*(Height/BlockH)*2 bytes''.

Now, there is a catch: version 2 VQAs use a different layout of the
index table than version 1 VQAs. I will first describe the version
2 table format, as it's more common.

====VERSION 2 INDEX TABLE LAYOUT====
The index table is an array of CHARs and is split into 2 parts - the top
half and the bottom half.

Now, if you want to diplay the block at coordinates (in block units),
say (bx,by) you should read two bytes from the table, one from the top
and one from the bottom half:

LoVal=Table[by*(Width/BlockW)+bx]
HiVal=Table[(Width/BlockW)*(Height/BlockH)+by*(Width/BlockW)+bx]

If HiVal=0x0f (0xff for the start movie of Red Alert 95) you should
simply fill the block with color LoVal, otherwise you should copy
the block with index number HiVal*256+LoVal from the lookup table.

Do that for every block on the screen (remember, there are Width/BlockW
blocks in the horizontal direction and Height/BlockH blocks in the vertical
direction) and you've decoded your first frame!

'''NOTE:''' I was unable to find an entry in the VQA header which determines
whether 0x0f or 0xff is used in HiVal to signal that the block
is of uniform color. I assume that the Wy entry of the header
implies this: If BlockW=2 -> 0x0f is used, if BlockH=4 -> 0xff is used.

====VERSION 1 INDEX TABLE LAYOUT====
Here, the index table is simply an array of SHORTs written in normal, Intel
byte order.

The LoVal and HiVal are given as:

LoVal=Table[(by*(Width/BlockW)+bx)*2]
HiVal=Table[(by*(Width/BlockW)+bx)*2+1]

If HiVal=0xff, the block is of uniform color which is (255-LoVal).
Otherwise, write the block with index number (HiVal*256+LoVal)/8.

===Appendix A===

FORMAT80 COMPRESSION METHOD
by Vladan Bato (bat22@geocities.com)

There are several different commands, with different sizes : from 1 to 5 bytes.
The positions mentioned below always refer to the destination buffer (i.e.
the uncompressed image). The relative positions are relative to the current
position in the destination buffer, which is one byte beyond the last written
byte.

I will give some sample code at the end.

(1) 1 byte
+---+---+---+---+---+---+---+---+
| 1 | 0 | | | | | | |
+---+---+---+---+---+---+---+---+
\_______________________/
|
Count

This one means : copy next Count bytes as is from Source to Dest.

(2) 2 bytes
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
\___________/\__________________________________________________/
| |
Count-3 Relative Pos.

This means copy Count bytes from Dest at Current Pos.-Rel. Pos. to
Current position.
Note that you have to add 3 to the number you find in the bits 4-6 of the
first byte to obtain the Count.
Note that if the Rel. Pos. is 1, that means repeat Count times the previous
byte.

(3) 3 bytes
+---+---+---+---+---+---+---+---+ +---------------+---------------+
| 1 | 1 | | | | | | | | | |
+---+---+---+---+---+---+---+---+ +---------------+---------------+
\_______________________/ Pos
|
Count-3

Copy Count bytes from Pos, where Pos is absolute from the start of the
destination buffer. (Pos is a word, that means that the images can't be
larger than 64K)

(4) 4 bytes
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | | | | | |
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
Count Color

Write Color Count times.
(Count is a word, color is a byte)

(5) 5 bytes
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | |
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
Count Pos

Copy Count bytes from Dest. starting at Pos. Pos is absolute from the start
of the Destination buffer.
Both Count and Pos are words.

These are all the commands I found out. Maybe there are other ones, but I
haven't seen them yet.

All the images end with a 80h command.

To make things more clearer here's a piece of code that will uncompress the
image.

DP = destination pointer
SP = source pointer
Source and Dest are the two buffers

SP:=0;
DP:=0;
repeat
Com:=Source[SP];
inc(SP);
b7:=Com shr 7; {b7 is bit 7 of Com}
case b7 of
0 : begin {copy command (2)}
{Count is bits 4-6 + 3}
Count:=(Com and $7F) shr 4 + 3;
{Position is bits 0-3, with bits 0-7 of next byte}
Posit:=(Com and $0F) shl 8+Source[SP];
Inc(SP);
{Starting pos=Cur pos. - calculated value}
Posit:=DP-Posit;
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end;
1 : begin
{Check bit 6 of Com}
b6:=(Com and $40) shr 6;
case b6 of
0 : begin {Copy as is command (1)}
Count:=Com and $3F; {mask 2 topmost bits}
if Count=0 then break; {EOF marker}
for i:=1 to Count do
begin
Dest[DP]:=Source[SP];
Inc(DP);
Inc(SP);
end;
end;
1 : begin {large copy, very large copy and fill commands}
{Count = (bits 0-5 of Com) +3}
{if Com=FEh then fill, if Com=FFh then very large copy}
Count:=Com and $3F;
if Count<$3E then {large copy (3)}
begin
Inc(Count,3);
{Next word = pos. from start of image}
Posit:=Word(Source[SP]);
Inc(SP,2);
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end
else if Count=$3F then {very large copy (5)}
begin
{next 2 words are Count and Pos}
Count:=Word(Source[SP]);
Posit:=Word(Source[SP+2]);
Inc(SP,4);
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end else
begin {Count=$3E, fill (4)}
{Next word is count, the byte after is color}
Count:=Word(Source[SP]);
Inc(SP,2);
b:=Source[SP];
Inc(SP);
for i:=0 to Count-1 do
begin
Dest[DP]:=b;
inc(DP);
end;
end;
end;
end;
end;
end;
until false;

Note that you won't be able to compile this code, because the typecasting
won't work. (But I'm sure you'll be able to fix it).

===Appendix B===
IMA ADPCM DECOMPRESSION
by Vladan Bato (bat22@geocities.com)
http://www.geocities.com/SiliconValley/8682

Note that the current sample value and index into the Step Table should
be initialized to 0 at the start and are maintained across the chunks
(see below).

====IMA-ADPCM DECOMPRESSION ====

It is the exact opposite of the above. It receives 4-bit codes in input
and produce 16-bit samples in output.

Again you have to mantain an Index into the Step Table an the current
sample value.

The tables used are the same as for compression.

Here's the code :

Index:=0;
Cur_Sample:=0;

while there_is_more_data do
begin
Code:=Get_Next_Code;

if (Code and $8) <> 0 then Sb:=1 else Sb:=0;
Code:=Code and $7;
{Separate the sign bit from the rest}

Delta:=(Step_Table[Index]*Code) div 4 + Step_Table[Index] div 8;
{The last one is to minimize errors}

if Sb=1 then Delta:=-Delta;

Cur_Sample:=Cur_Sample+Delta;
if Cur_Sample>32767 then Cur_Sample:=32767
else if Cur_Sample<-32768 then Cur_Sample:=-32768;

Output_Sample(Cur_Sample);

Index:=Index+Index_Adjust[Code];
if Index<0 then Index:=0;
if Index>88 the Index:=88;
end;

Again, this can be done more efficiently (no need for multiplication).

The ''Get_Next_Code'' function should return the next 4-bit code. It must
extract it from the input buffer (note that two 4-bit codes are stored
in the same byte, the first one in the lower bits).

The Output_Sample function should write the signed 16-bit sample to the
output buffer.

=== Appendix A : THE INDEX ADJUSTMENT TABLE ===

Index_Adjust : array [0..7] of integer = (-1,-1,-1,-1,2,4,6,8);

=== Appendix B : THE STEP TABLE ===

Steps_Table : array [0..88] of integer =(
7, 8, 9, 10, 11, 12, 13, 14, 16,
17, 19, 21, 23, 25, 28, 31, 34, 37,
41, 45, 50, 55, 60, 66, 73, 80, 88,
97, 107, 118, 130, 143, 157, 173, 190, 209,
230, 253, 279, 307, 337, 371, 408, 449, 494,
544, 598, 658, 724, 796, 876, 963, 1060, 1166,
1282, 1411, 1552, 1707, 1878, 2066, 2272, 2499, 2749,
3024, 3327, 3660, 4026, 4428, 4871, 5358, 5894, 6484,
7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899, 15289,
16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767 );

===Appendix C===
WESTWOOD STUDIOS' ADPCM DECOMPRESSION
by Asatur V. Nazarian (samael@avn.mccme.ru)

==== WS ADPCM Decompression Algorithm ====

Each SND1 chunk may be decompressed independently of others. This lets you
implement seeking/skipping for WS ADPCM sounds (unlike IMA ADPCM ones).
But during the decompression of the given chunk a variable (''CurSample'') should
be maintained for this whole chunk:

SHORT CurSample;
BYTE InputBuffer[InputBufferSize]; // input buffer containing the whole chunk
WORD wSize, wOutSize; // Size and OutSize values from this chunk's header
BYTE code;
CHAR count; // this is a signed char!
WORD i; // index into InputBuffer
WORD input; // shifted input

if (wSize==wOutSize) // such chunks are NOT compressed
{
for (i=0;i<wOutSize;i++)
Output(InputBuffer[i]); // send to output stream
return; // chunk is done!
}

// otherwise we need to decompress chunk

CurSample=0x80; // unsigned 8-bit
i=0;

// note that wOutSize value is crucial for decompression!

while (wOutSize>0) // until wOutSize is exhausted!
{
input=InputBuffer[i++];
input<<=2;
code=HIBYTE(input);
count=LOBYTE(input)>>2;
switch (code) // parse code
{
case 2: // no compression...
if (count & 0x20)
{
count<<=3; // here it's significant that (count) is signed:
CurSample+=count>>3; // the sign bit will be copied by these shifts!

Output((BYTE)CurSample);

wOutSize--; // one byte added to output
}
else // copy (count+1) bytes from input to output
{
for (count++;count>0;count--,wOutSize--,i++)
Output(InputBuffer[i]);
CurSample=InputBuffer[i-1]; // set (CurSample) to the last byte sent to output
}
break;
case 1: // ADPCM 8-bit -> 4-bit
for (count++;count>0;count--) // decode (count+1) bytes
{
code=InputBuffer[i++];

CurSample+=WSTable4bit[(code & 0x0F)]; // lower nibble

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable4bit[(code >> 4)]; // higher nibble

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

wOutSize-=2; // two bytes added to output
}
break;
case 0: // ADPCM 8-bit -> 2-bit
for (count++;count>0;count--) // decode (count+1) bytes
{
code=InputBuffer[i++];

CurSample+=WSTable2bit[(code & 0x03)]; // lower 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable2bit[((code>>2) & 0x03)]; // lower middle 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable2bit[((code>>4) & 0x03)]; // higher middle 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable2bit[((code>>6) & 0x03)]; // higher 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

wOutSize-=4; // 4 bytes sent to output
}
break;
default: // just copy (CurSample) (count+1) times to output
for (count++;count>0;count--,wOutSize--)
Output((BYTE)CurSample);
}
}

HIBYTE and LOBYTE are just higher and lower bytes of WORD:
#define HIBYTE(word) ((word) >> 8)
#define LOBYTE(word) ((word) & 0xFF)
Note that depending on your compiler you may need to use additional byte
separation in these defines, e.g. (((byte) >> 8) & 0xFF). The same holds for
4-bit and 2-bit nibble separation in the code above.

''WSTable4bit'' and ''WSTable2bit'' are the delta tables given in the next section.

Output() is just a placeholder for any action you would like to perform for
decompressed sample value.

Clip8BitSample is quite evident:

SHORT Clip8BitSample(SHORT sample)
{
if (sample>255)
return 255;
else if (sample<0)
return 0;
else
return sample;
}

This algorithm is ONLY for mono 8-bit unsigned sound, as I've never seen any
other sound format used with WS ADPCM compression.

Of course, the decompression routine described above may be greatly
optimized.

==== WS ADPCM Tables ====

CHAR WSTable2bit[]=
{
-2,
-1,
0,
1
};

CHAR WSTable4bit[]=
{
-9, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8
};

==HC_VQA.txt==
by Gordan Ugarkovic (ugordan@yahoo.com)
http://members.xoom.com/ugordan

This document describes how to view Westwood's HiColor VQA movies. These
are version 3 movies, but there are at least some version 2 VQAs that are
in this format. I will not describe the whole VQA layout here, I will
just explain how to display the VIDEO stream of the VQA, that is, how
to decompress the CBFZ and VPTR/VPRZ chunks.

First a little warning: I'm not sure which flag denotes the VQA is 8 bit
or 15 bit. I'm pretty convinced it's either bit 4 (0x10) or bit 2 (0x04)
of the Flags entry (see my VQA_INFO.TXT) in the header. Another way would
be to check the Colors entry in the header, if it is 0 it could imply
a HiColor movie.

There's a major difference between the old (8 bit, 256 color) and the new,
HiColor VQAs. Lookup tables are no longer split up into several CBP?
chunks, instead they come in one piece (a CBFZ chunk). Two lookup tables
can now be many frames apart, not just 8 (as usual). This is indicated
by the CBParts entry of the header (see VQA_INFO.TXT), which is set to 0.
Subsequent frames use the last lookup table loaded, of course.

Another thing: It appears the first CBFZ chunk comes inside the VQFR chunk
but the other ones seem to be located inside their own chunks,
called VQFL, which are followed by the usual VQFR chunks (containing
VPTR/VPRZ chunks).

Also, the movies are 15 bit, NOT 16 bit. There is a difference because
in 16 bit color depth there are 6 bits for the green channel, but
the VQAs use 5.

=== The CBFZ chunks===

These are a bit modified since the 8 bit VQAs. If the first byte of the
chunk is not NULL (0x00), it means the chunk is compressed using the
standard Format80 algorithm (see Vladan Bato's text on C&C file formats),
starting from that byte. If the first byte is NULL, the chunk is compressed
using a modified version of Format80 (see below), starting from the next
byte of the chunk. The original Format80 algorithm is used when the
amount of data to be compressed is less than 64 KB, otherwise the 'new'
algorithm is used.

When decompressed properly, a CBFZ chunk expands into 15 bit pixels packed
as shorts in normal Intel byte order. The red, green and blue values are
packed like this:

15 bit 0
0rrrrrgg gggbbbbb
HI byte LO byte

The r,g,b values make up a pixel and they can range from 0-31.
As in the old CBFZ chunks, these pixels make up the block lookup table
(also called a codebook).

=== The VPTR chunks===

These chunks use some sort of differential, run-length algorithm that
only records changes from the previous frame. Therefore, the previous
frame bitmap must be maintained throughout all the frames (you could
just draw the blocks that changed, though). This makes dropping frames
(in case of bad performance) impossible.

When decoding, you take a short int (Intel) from the chunk and examine
its 3 most significant bits (bits 15,14,13). These bits make up a
code prefix that determines which action is to be done.

Here's a list of the prefixes I encountered and their description
(Val is the short int value):

BITS - MEANING

000 - Skip Count blocks. Count is (Val & 0x1fff).

001 - Write block number (Val & 0xff) Count times.
Count is (((Val/256) & 0x1f)+1)*2. Note that this can only
index the first 256 blocks.

010 - Write block number (Val & 0xff) and then write Count blocks
getting their indexes by reading next Count bytes from
the VPTR chunk. Count is (((Val/256) & 0x1f)+1)*2.
Again, the block numbers range from 0-255.

011 - Write block (Val & 0x1fff).

101 - Write block (Val & 0x1fff) Count times. Count is the next
byte from the VPTR chunk.

After this, you take the next short int and repeat the above process.

Every row of blocks is processed individually of others.
When you encounter the end of a row, proceed to the next row
(blocks are processed left to right, top to down).
Repeat this process until all blocks in the frame are covered and
that's it!

Note that the above implies an absolute maximum of 8192 blocks (0x1fff+1).
Also note that prefix 100 is unused (at least in Tiberian Sun) but could
be used somewhere else...?

As for the VPRZ chunks, these are just VPTR chunks compressed with
the standard Format80 algorithm.

=== The modified Format80 scheme ===

This is really only a small modification of the basic algorithm.
The only commands that are modified are commands (3) and (5)
See Vladan's text). Instead of using offsets ABSOLUTE from
the start of the destination buffer, offsets RELATIVE to the
current destination pointer are used. If you ask me, I don't see
why this approach wasn't used in the first place as it would
suffer no disadvantage with the old files and it would be much
easier to compress even larger amounts of data. The guys at WW
were just careless, I guess... :-)

Anyway, in Vladan's algorithm, there is a line in
command (3) that says:
Posit:=Word(Source[SP]);
it should say:
Posit:=DP-Word(Source[SP]);

Likewise, for command (5):
Posit:=Word(Source[SP+2]);
it should be:
Posit:=DP-Word(Source[SP+2]);

== Games Using VQA ==

=== Version 1 ===

* [http://www.mobygames.com/game/win3x/legend-of-kyrandia-malcolms-revenge The Legend of Kyrandia: Malcolm's Revenge]
* [http://www.mobygames.com/game/windows/monopoly Monopoly] (Version 1???)

=== Versions 2 ===

* [http://www.mobygames.com/game/dos/command-conquer Command & Conquer]
* [http://www.mobygames.com/game/dos/command-conquer-red-alert Command & Conquer: Red Alert]
* [http://www.mobygames.com/game/windows/command-conquer-sole-survivor Command & Conquer: Sole Survivor]
* [http://www.mobygames.com/game/lands-of-lore-guardians-of-destiny Lands of Lore: Guardians of Destiny]

=== Versions 3 ===

* [http://www.mobygames.com/game/windows/blade-runner Blade Runner]
* [http://www.mobygames.com/game/windows/command-conquer-tiberian-sun Command & Conquer: Tiberian Sun]
* [http://www.mobygames.com/game/windows/dune-2000 Dune 2000]
* [http://www.mobygames.com/game/lands-of-lore-iii Lands of Lore III]
* [http://www.mobygames.com/game/windows/nox Nox]

==Other Documentation==
http://www.gamers.org/pub/idgames2/planetquake/planetcnc/cncdz/ has lots of data about this format. See vqa_overview.zip and vqafilesguild.zip. Also there is a decoder (vqatoavi) that decodes the dune2000 sample.

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

Bink Container

2010-03-03T19:47:04Z

Siberian GRemlin:

''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''

* Extenstions: bik
* Company: [[RAD Game Tools]]
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games

Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.

== File Format ==

'''This description is known to be incomplete.'''

All multi-byte numbers are stored in little endian format.

Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.

bytes 0-2 file signature ('BIK')
byte 3 Bink Video codec revision (0x62, 0x64, 0x66, 0x67, 0x68, 0x69; b,d,f,g,h,i respectively)
bytes 4-7 file size not including the first 8 bytes
bytes 8-11 number of frames
bytes 12-15 largest frame size in bytes
bytes 16-19 number of frames again?
bytes 20-23 video width (less than or equal to 32767)
bytes 24-27 video height (less than or equal to 32767)
bytes 28-31 video frames per second dividend
bytes 32-35 video frames per second divider
bytes 36-39 video flags
bits 28-31: width and height scaling
1 = 2x height doubled
2 = 2x height interlaced
3 = 2x width doubled
4 = 2x width and height-doubled
5 = 2x width and height-interlaced
bit 20: has alpha plane
bit 17: grayscale
bytes 40-43 number of audio tracks (less than or equal to 256)

for each audio track
two bytes unknown
two bytes audio channels (1 or 2). Not authoritative, see flags below.

for each audio track
two bytes audio sample rate (Hz)
two bytes flags
bit 15: unknown (observed in some samples)
bit 14: unknown (observed in some samples)
bit 13: stereo flag
bit 12: Bink Audio algorithm
1 = use Bink Audio DCT
0 = use Bink Audio FFT

for each audio track
four bytes audio track ID

Revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.

The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.

Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). If bit 0 of an entry is set, that frame is a keyframe; this bit should be masked off to find the actual offset of the frame data in the file.

Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:

for each audio track
four bytes length of audio packet (bytes) plus four bytes.
A value of zero indicates no audio is present for this track.
four bytes number of samples in packet
variable length [[Bink Audio]] packet

variable length [[Bink Video]] packet

== Exe files ==
Bink data can be contained in exe files. To find where to start decoding search for one of 4 id's in the file:
'fKIB'
'gKIB'
'hKIB'
'iKIB'

Note that this is the BIK value in machine order (therefore it appears backwards for x86 binaries).

== External Links ==
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]

[[Category:Container Formats]]
[[Category:Game Formats]]

Sofdec

2010-01-18T17:32:14Z

Siberian GRemlin: /* Games Using Sofdec */

* Extension: sfd
* Company: [[CRI]]
* Website: http://www.cri-mw.co.jp/products/product_sfd_e.htm
* Samples: Official website above, http://samples.mplayerhq.hu/game-formats/sfd/

SFD is a format commonly found on [[Sega Dreamcast]] console games, and is also available for a number of other video game consoles. The files package [[MPEG]] video with a custom ADPCM audio codec called [[CRI ADX ADPCM]].

== Games Using Sofdec ==
* Battle Stadium DON (Nintendo GameCube)
* Crysis Demo (PC)
* [http://www.mobygames.com/game/gamecube/f-zero-gx F-Zero GX (Nintendo GameCube)]
* Marvel Ultimate Allience (PC, Sony Playstation 2)
* [http://www.mobygames.com/game/dreamcast/resident-evil-code-veronica Resident Evil: Code Veronica (Sega Dreamcast)]
* [http://www.mobygames.com/game/gamecube/resident-evil-code-veronica-x Resident Evil: Code Veronica X (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/resident-evil-4 Resident Evil 4 (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/sonic-adventure-2-battle Sonic Adventure 2: Battle (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/soulcalibur-ii SoulCalibur 2 (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/star-fox-assault Starfox Assault (Nintendo GameCube)]
* [http://www.mobygames.com/game/gamecube/star-wars-bounty-hunter Star Wars: Boundy Hunter (Nintendo GameCube)]

[[Category:Game Formats]]

Electronic Arts Formats

2009-03-22T14:29:58Z

Siberian GRemlin: /* Games Using Electronic Arts Multimedia Formats */

* Extensions: ASF, CMV, DCT, SND, TGI, TGV, TGQ, WVE, UV, UV2, VID, MAD, VP6
* Company: [[Electronic Arts]]

Electronic Arts, the video game publishing empire, and the various constituent development houses under its umbrella, have deployed a number of multimedia formats in its games.

EA multimedia formats are comprised of a series of blocks with the following format:

bytes 0-3 block type [[FourCC]]
bytes 4-7 block size (including this 8-byte preamble)
bytes 8.. block payload

It is important to note that there is no consistent byte order for multi-byte numbers. However, order is optimized for target platform, i.e. little-endian for PC/PS/XBOX and big-endian for Mac/Saturn/GameCube.

== Chunk Types ==

* Audio
** [[Electronic Arts SEAD]]: SEAD, SNDC, SEND
** [[Electronic Arts 1SNx]]: 1SNh, 1SNd, 1SNl, 1SNe
** [[Electronic Arts SCxl]]: SCHl, SCCl, SCDl, SCLl, SCEl, and SHEN, SCEN, SDEN, SEEN
* Video
** [[Electronic Arts CMV]]: MVIh, MVIf, MVIe
** [[Electronic Arts TGV]]: kVGT, fVGT
** [[Electronic Arts DCT]]: mTCD
** [[Electronic Arts TGQ]]: pQTG, TGQs (rumored MUVf?)
** [[Electronic Arts TQI]]: pIQT, (rumored UV2f?)
** [[Electronic Arts MAD]]: MADk, MADm, MADe
** [[Electronic Arts VP6]]: MVhd, MV0K, MV0F
** [[Electronic Arts MPC]]: MPCh

== Games Using Electronic Arts Multimedia Formats ==

{| border="1" cellpadding="2"
! Name !! File Ext !! Video Codec !! Audio Codec || Byte Order
|-
| [http://www.mobygames.com/game/dos/nhl-95 NHL 95]
| cmv || CMV || none || le
|-
| [http://www.mobygames.com/game/dos/nhl-96 NHL 96]
| tgv || ? || ? || ?
|-
| [http://www.mobygames.com/game/dos/cybermage-darklight-awakening CyberMage: Darklight Awakening]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/need-for-speed Need for Speed]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/privateer-2-the-darkening Privateer 2: The Darkening]
| tgv || TGV || SEAD/adpcm_ima_ea_sead || le
|-
| [http://www.mobygames.com/game/dos/nba-live-96 NBA Live 96]
| tgv || TGV || 1SNh/EACS/adpcm_ima_ea_eacs || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2]
| dct || DCT || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2 (Demo)]
| uv || TGQ || SCHl/PT/adpcm_ea || le
|-
|rowspan="2"|[http://www.mobygames.com/game/beasts-bumpkins Beasts and Bumpkins]
| vid || TQI || SCHl/PT/adpcm_ea || le
|-
| m10 || none || PT/microtalk10:1? || le
|-
| [http://www.mobygames.com/game/dungeon-keeper-2 Dungeon Keeper 2]
| tgq || TQI (no typo) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/saturn/warcraft-ii-the-dark-saga Warcraft II: The Dark Saga (Sega Saturn)]
| tgq || TGQ || ? || be
|-
| [http://www.mobygames.com/game/superbike-2001 Superbike 2001]
| tgq || ? || ? || ?
|-
| [http://www.mobygames.com/game/saturn/crusader-no-remorse Crusader: No Remorse (Sega Saturn)]
| tgq || TGQ || 1SNh/EACS/mulaw || be
|-
| [http://www.mobygames.com/game/harry-potter-quidditch-world-cup Harry Potter: Quidditch World Cup]
| tgq || TQI (not a typo) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/wing-commander-prophecy Wing Commander: Prophecy]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/the-sims The Sims]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/nba-live-99 NBA Live 99]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-iii-hot-pursuit Need for Speed 3: Hot Pursuit]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-high-stakes Need for Speed 4: High Stakes]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-porsche-unleashed Need for Speed 5: Porsche]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| [http://www.mobygames.com/game/need-for-speed-hot-pursuit-2 Need for Speed 6: Hot Pursuit 2]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| rowspan="2"| [http://www.mobygames.com/game/nba-live-2003 NBA Live 2003]
| mad || MAD || pcm_s16le_planar || le
|-
| asf || none || SCHl/PT/mp3 || le
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2004]
| mad || ? || ? || ?
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2005]
| mad || MAD || SCHl/PT/adpcm_ea_r1, SCHl/PT/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/simcity-4-rush-hour Sim City 4: Rush Hour]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/sims-2 The Sims 2]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/ps2/need-for-speed-underground Need for Speed: Underground (PlayStation 2)]
| mpc || MPC || SCHl/PT/adpcm_ea_r2 || le
|-
| [http://www.mobygames.com/game/ps2/fifa-soccer-07 FIFA 2007 (PlayStation 2)]
| mpc || MPC || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-underground-2 Need for Speed: Underground 2]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-most-wanted Need for Speed: Most Wanted]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-carbon Need for Speed: Carbon]
| vp6 || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth The Lord of the Rings: The Battle for Middle Earth]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/lord-of-the-rings-the-battle-for-middle-earth-ii The Lord of the Rings: The Battle for Middle Earth II]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth-ii-the-rise-of-the The Lord of the Rings: The Battle for Middle Earth II - The Rise of the Witch-King]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/command-conquer-3-tiberium-wars Command & Conquer: Tiberium Wars]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/command-conquer-3-kanes-wrath Command & Conquer: Tiberium Wars: Kane's Wrath]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-prostreet Need for Speed: Pro Street]
| vp6 || VP6 || SHEN/GSTR/ealayer3 || le
|-
| [http://www.mobygames.com/game/command-conquer-red-alert-3 Red Alert 3]
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| Red Alert 3: Uprising
| vp6/snd || VP6 || SCHl/GSTR/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/burnout-paradise-the-ultimate-box Burnout Paradise: The Ultimate Box]
| vp6/sns || VP6 || ealayer3 w/o header || le
|}

In addition to FMV, the EA audio chunk types are frequently used throughout Electronic Arts games for music tracks, audio effects and speech. Older titles use the .ASF file extension for individual music tracks, whereas newer titles store multiple audio sequentially within the one file (hence rational for the ending chunk types) and use a variety of file extensions.

[[Category:Game Formats]]

VQA

2009-03-09T19:16:20Z

Siberian GRemlin: /* Versions 3 */

* Extension: vqa
* Company: [[Westwood Studios]]
* Samples: [http://samples.mplayerhq.hu/game-formats/vqa/ http://samples.mplayerhq.hu/game-formats/vqa/]

VQA stands for Vector Quantized Animation and is a FMV format used in a number of computer games by Westwood Studios.

== Technical Description ==

'''TODO: import and combine Gordan Ugarkovic's documents from [http://multimedia.cx/VQA_INFO.TXT http://multimedia.cx/VQA_INFO.TXT] and [http://multimedia.cx/HC-VQA.TXT http://multimedia.cx/HC-VQA.TXT].
==VQA_INFO.txt==

===NOTE #1===
This document only applies to VQA files in the original C&C and
C&C: Red Alert (version 2) as well as
Legend of Kyrandia III : Malcolm's Revenge (version 1).
It DOES NOT apply to the HiColor VQAs found in Westwood's newer
games. They use a somewhat different approach to compressing video
data (I will provide some facts about their sound stream, though).
Look at my other document (HC-VQA.TXT) for a description
of the HiColor VQA movies.
===NOTE #2===
Throughout the document, I will assume that:
CHAR is 1 byte in size, unsigned,
SHORT is 2 bytes in size, unsigned,
LONG is 4 bytes in size.

Each VQA file is comprised of a series of chunks. A chunk can contain
other sub-chunks nested in it. Every chunk has a 4 letter ID (all uppercase
letters) and a LONG written using Motorola byte ordering system (first
comes the Most Significant Byte), unlike the usual Intel system (Least
Significant Byte first).

For example, if you had a value 0x12345678 in hexadecimal, using the Intel
notation it would be written as 78 56 34 12, while using Motorola's
12 34 56 78.

NOTE: Some chunk IDs start with a NULL byte (0x00) because of reasons
that will become apparent later. You should just skip this byte
and assume the next 4 letters hold the chunk ID.

Following the chunk header is the chunk data.
===Typical VQA File===
Here is a scheme of a typical VQA file (nested chunks are indented):

FORM
VQHD
FINF <- Frame data positions
SND? \ <- First sound chunk, contains 1/2 second of sound
SND? | <- Contains 1 frame's worth of sound
VQFR | <- Contains various video data chunks
CBF? | 1st frame data
CBP? |
CPL? |
VPT? /
SND? \
VQFR | 2nd frame data
CBP? |
VPT? /
SND? \
VQFR | 3rd frame data
CBP? |
VPT? /
. . .

NOTE: There can also be some other chunks (i.e. PINF, PINH, SN2J) included,
but they are not relevant (?!) for viewing the movie, so they can
easily be skipped.

===FORM chunk===

This chunk is the main chunk, containing all other chunks.
In case of version 2 and 3 movies, its size is actually the size of the
entire file minus the size of the chunk header (8 bytes). Version 1 movies
seem to have this set to the length of the header VQHD + FINF chunk.

Immediately after the chunk's header, a 4-character signature,
"WVQA" is located. Then come all the other chunks.

===VQHD chunk ("VQa HeaDer" ???)===

This is the header chunk, containing vital information about the movie.
Its size is always 42 bytes.
The information is structured like this:

struct VQAHeader
{
short Version; /* VQA version number */
short Flags; /* VQA flags */
short NumFrames; /* Number of frames */
short Width; /* Movie width (pixels) */
short Height; /* Movie height (pixels) */
char BlockW; /* Width of each image block (pixels) */
char BlockH; /* Height of each image block (pixels) */
char FrameRate; /* Frame rate of the VQA */
char CBParts; /* How many images use the same lookup table */
short Colors; /* Maximum number of colors used in VQA */
short MaxBlocks; /* Maximum number of image blocks */
long Unknown1; /* Always 0 ??? */
short Unknown2; /* Some kind of size ??? */
short Freq; /* Sound sampling frequency */
char Channels; /* Number of sound channels */
char Bits; /* Sound resolution */
long Unknown3; /* Always 0 ??? */
short Unknown4; /* 0 in old VQAs, 4 in HiColor ones ??? */
long MaxCBFZSize; /* 0 in old VQAs, max. CBFZ size in HiColor */
long Unknown5; /* Always 0 ??? */
}

* Version denotes the VQA version. Valid values are:
1 - First VQAs, used only in Legend of Kyrandia III.
2 - Used in C&C, Red Alert, Lands of Lore II, Dune 2000.
3 - Lands of Lore III (?), Blade Runner (?), Nox and Tiberian Sun.
These VQAs are HiColor (15 bit).

* Flags most probably contain some flags. I only know that bit 0 (LSB)
denotes whether the VQA has a soundtrack or not.
(1 = Has sound, 0 = No sound)

* Width is usually 320, Height is usually 156 or 200 although one movie in
Red Alert is 640x400 in size (the start movie for the Win95 version).

Each frame of a VQA movie is comprised of a series of blocks that are
BlockW pixels in width and BlockH pixels in height. Imagine the frame
is a mosaic with the blocks being 'pieces' that make up the frame.

* BlockW is the width and BlockH is the height of each screen block.
In VQAs version 2 (and perhaps 1) the blocks are usually 4x2.

* FrameRate is always 15 in C&C and RA and seems to be 10 in LoK III.

* CBParts denotes how many frames use the same lookup table. It also
implies how many parts the new block lookup table is split into.
In C&C and RA it is always 8.

* Colors indicates the maximum number of colors used by the VQA.
The HiColor VQAs have this set to 0, while the old movies have
256 or less in here.

* Freq is usually 22050 Hz. Note that version 1 movies can have this set
to 0 Hz. In that case, you should use 22050 Hz.

* Channels specifies the number of sound channels, i.e. is the sound
mono or stereo. Channels=1 -> sound is mono, Channels=2 -> stereo.
C&C and RA almost always use mono sound.
Version 1 can have this set to 0, but you should use 1 (mono sound).
The majority of Tiberian Sun movies use stereo sound instead.

* Bits indicates whether the sound is 8 bit or 16 bit.
Bits=8 -> 8 bit sound, Bits=16 -> 16 bit sound (surprise! :).
The Legend of Kyrandia III: Malcolm's Revenge uses 8 bits where
C&C, RA, TS, Dune 2000, Lands of Lore III use 16 bits.
Note, again, that version 1 of the VQAs can have this set to 0 in
which case 8 bits are assumed.

* MaxCBFZSize is a new entry, specific to the HiColor VQAs. It tells
you the size of the largest CBFZ chunk, in bytes.

Following the chunk data are the sub-chunks.

===FINF chunk ("Frame INFormation" ???)===

This chunk contains the positions (absolute from the start of the VQA)
of data for every frame.
That means that it points to the SND? chunk associated with that frame,
which is followed by a VQFR chunk containing frame's video data.

The positions are given as LONGs which are in normal Intel byte order.

'''NOTE:''' Some frame positions are 0x40000000 too large. This is a flag
indicating those frames contain a new color palette. To get the
actual positions, you should subtract 0x40000000 from the values.

'''NOTE #2:''' To get the actual position of the frame data you have to multiply
the value by 2. This is why some chunk IDs start with 0x00. Since
you multiply by 2, you can't get an odd chunk position so if the
chunk position would normally be odd, a 0x00 is inserted to make
it even.

===SND? chunk ("SouND" ???)===
These chunks contain the sound data for the movie. The last byte of the ID
can be either '0', '1' or '2' so the actual IDs would be "SND0", "SND1"
and "SND2".
In VQAs version 1 (Legend of Kyrandia 3) there are ''NumFrames'' sound chunks.
Old 8 bit VQA movies of version 2 have ''NumFrames+1'' sound chunks.
Note, however, that Dune2000 movies, which are also version 2, but HiColor
have ''NumFrames'' sound chunks, instead.
Version 3 movies also have ''NumFrames'' sound chunks.

In case of the old, 8 bit VQAs, the first chunk contains half a second
(ver. 2) or more (ver. 1) of the wave data, in all (?) the HiColor movies
the first chunk contains exactly the amount of sound required for one
frame of the movie. The downside is this requires a somewhat more advanced
buffering technique on the side of the player in order to allow smooth
playback.

===SND0 chunk===

This one contains the raw 8 or 16 bit PCM wave data. If the data is
8 bit, the sound is unsigned and if it is 16 bit, the samples are
signed.

===SND1 chunk===

It contains 8 bit sound compressed using Westwood's own
proprietary ADPCM algorithm. The chunk has a 4 byte header:

struct SND1Header
{
short OutSize;
short Size;
}

These values are needed for the decoding algoritm (see APPENDIX C).
The encoded samples follow immediately after the header.
It's important to know this algorithm produces UNSIGNED sound, unlike
the IMA ADPCM algorithm supplied here (see below). It is, however very
simple to adapt both algorithms to produce either signed or unsigned
sample output...

===SND2 chunk===

It contains the 16 bit sound data compressed using the IMA ADPCM
algorithm which compresses 16 bits into 4. That's why the SND2 chunks
are 4 times smaller than SND0 chunks and they are used almost all
the time. For the description of the algorithm, see later in the document.

Different VQA versions have different stereo sample layout. In case
of Tiberian Sun stereo sound is encoded the same way as mono except the
SND2 chunk is split into two halfs. The first half contains the left channel
sound and the second half contains the right channel. The layout of
nibbles is as follows: LL LL LL LL LL ... RR RR RR RR RR.
Old movies (C&C, RA) use a different layout. Here, the nibbles are packed
together like this: LL RR LL RR LL RR ... This means that two left channel
samples are packed into one byte and then two right channel samples are
packed into another.

Naturally, the size of a stereo SND2 chunk is exactly twice as big as
a mono SND2.

It is important to note that, when decoding, you have to keep separate
values of ''Index'' and ''Cur_Sample'' for each channel (see APPENDIX B).

===VQFR chunk ("Vector Quantized FRame" ???)===

A chunk that includes many nested sub-chunks which contain video data.
It doesn't contain any data itself so the sub-chunks follow immediately
after the VQFR chunk header.
All following sub-chunks are nested inside a VQFR chunk. They can all
contain '0' or 'Z' as the last byte of their ID.

* If the last byte is '0' it means that the chunk data is uncompressed.
* If the last byte is 'Z' it means that the data is compressed using
Format80 compression. You can find its description in APPENDIX A.

===CBF? chunk ("CodeBook, Full" ???)===

Lookup table containing the screen block data as an array
of elements that each are BlockW*BlockH bytes long. It is always located
in the data for the first frame. In Vector Quantization terminology
these tables are called CODEBOOKS.

There can be max. 0x0f00 of these elements (blocks) at any one time in
normal VQAs and 0xff00 in the hi-res VQAs (Red Alert 95 start movie) although
I seriously doubt that so many blocks (0xff00 = 65280 blocks) would
ever be used.

The uncompressed version of these chunks ("CBF0") is used mainly in
the original Command & Conquer, while the compressed version ("CBFZ")
is used in C&C: Red Alert.

===CBP? chunk ("CodeBook Part" ???)===

Like CBF?, but it contains a part of the lookup table, so to get the new
complete table you need to append CBParts of these in frame order.
Once you get the complete table and display the current frame, replace
the old table with the new one.
As in CBF? chunk, the uncompressed chunks are used in C&C and the compressed
chunks are used in Red Alert.

'''NOTE:''' If the chunks are CBFZ, first you need to append CBParts of them and
then decompress the data, NOT decompress each chunk individually.

===CPL? chunk ("Color PaLette" ???)===

The simplest one of all... Contains a palette for the VQA. It is an
array of red, green and blue values (in that order, all have a size of
1 byte). Seems that the values range from 0-255, but you should mask out
the bits 6 and 7 to get the correct palette (VGA hardware uses only
bits 0..5 anyway).

===VPT? chunk: ("Vector Pointer Table" ???)===

This chunk contains the indexes into the block lookup table which contains
the data to display the frame.
The image blocks are called VECTORS in Vector Quantization terminology.

These chunks are always compressed, but I guess the uncompressed ones
can also be used (although this would lower the overall compression achieved).

The size of this index table is ''(Width/BlockW)*(Height/BlockH)*2 bytes''.

Now, there is a catch: version 2 VQAs use a different layout of the
index table than version 1 VQAs. I will first describe the version
2 table format, as it's more common.

====VERSION 2 INDEX TABLE LAYOUT====
The index table is an array of CHARs and is split into 2 parts - the top
half and the bottom half.

Now, if you want to diplay the block at coordinates (in block units),
say (bx,by) you should read two bytes from the table, one from the top
and one from the bottom half:

LoVal=Table[by*(Width/BlockW)+bx]
HiVal=Table[(Width/BlockW)*(Height/BlockH)+by*(Width/BlockW)+bx]

If HiVal=0x0f (0xff for the start movie of Red Alert 95) you should
simply fill the block with color LoVal, otherwise you should copy
the block with index number HiVal*256+LoVal from the lookup table.

Do that for every block on the screen (remember, there are Width/BlockW
blocks in the horizontal direction and Height/BlockH blocks in the vertical
direction) and you've decoded your first frame!

'''NOTE:''' I was unable to find an entry in the VQA header which determines
whether 0x0f or 0xff is used in HiVal to signal that the block
is of uniform color. I assume that the Wy entry of the header
implies this: If BlockW=2 -> 0x0f is used, if BlockH=4 -> 0xff is used.

====VERSION 1 INDEX TABLE LAYOUT====
Here, the index table is simply an array of SHORTs written in normal, Intel
byte order.

The LoVal and HiVal are given as:

LoVal=Table[(by*(Width/BlockW)+bx)*2]
HiVal=Table[(by*(Width/BlockW)+bx)*2+1]

If HiVal=0xff, the block is of uniform color which is (255-LoVal).
Otherwise, write the block with index number (HiVal*256+LoVal)/8.

===Appendix A===

FORMAT80 COMPRESSION METHOD
by Vladan Bato (bat22@geocities.com)

There are several different commands, with different sizes : from 1 to 5 bytes.
The positions mentioned below always refer to the destination buffer (i.e.
the uncompressed image). The relative positions are relative to the current
position in the destination buffer, which is one byte beyond the last written
byte.

I will give some sample code at the end.

(1) 1 byte
+---+---+---+---+---+---+---+---+
| 1 | 0 | | | | | | |
+---+---+---+---+---+---+---+---+
\_______________________/
|
Count

This one means : copy next Count bytes as is from Source to Dest.

(2) 2 bytes
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
\___________/\__________________________________________________/
| |
Count-3 Relative Pos.

This means copy Count bytes from Dest at Current Pos.-Rel. Pos. to
Current position.
Note that you have to add 3 to the number you find in the bits 4-6 of the
first byte to obtain the Count.
Note that if the Rel. Pos. is 1, that means repeat Count times the previous
byte.

(3) 3 bytes
+---+---+---+---+---+---+---+---+ +---------------+---------------+
| 1 | 1 | | | | | | | | | |
+---+---+---+---+---+---+---+---+ +---------------+---------------+
\_______________________/ Pos
|
Count-3

Copy Count bytes from Pos, where Pos is absolute from the start of the
destination buffer. (Pos is a word, that means that the images can't be
larger than 64K)

(4) 4 bytes
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | | | | | |
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
Count Color

Write Color Count times.
(Count is a word, color is a byte)

(5) 5 bytes
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | |
+---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
Count Pos

Copy Count bytes from Dest. starting at Pos. Pos is absolute from the start
of the Destination buffer.
Both Count and Pos are words.

These are all the commands I found out. Maybe there are other ones, but I
haven't seen them yet.

All the images end with a 80h command.

To make things more clearer here's a piece of code that will uncompress the
image.

DP = destination pointer
SP = source pointer
Source and Dest are the two buffers

SP:=0;
DP:=0;
repeat
Com:=Source[SP];
inc(SP);
b7:=Com shr 7; {b7 is bit 7 of Com}
case b7 of
0 : begin {copy command (2)}
{Count is bits 4-6 + 3}
Count:=(Com and $7F) shr 4 + 3;
{Position is bits 0-3, with bits 0-7 of next byte}
Posit:=(Com and $0F) shl 8+Source[SP];
Inc(SP);
{Starting pos=Cur pos. - calculated value}
Posit:=DP-Posit;
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end;
1 : begin
{Check bit 6 of Com}
b6:=(Com and $40) shr 6;
case b6 of
0 : begin {Copy as is command (1)}
Count:=Com and $3F; {mask 2 topmost bits}
if Count=0 then break; {EOF marker}
for i:=1 to Count do
begin
Dest[DP]:=Source[SP];
Inc(DP);
Inc(SP);
end;
end;
1 : begin {large copy, very large copy and fill commands}
{Count = (bits 0-5 of Com) +3}
{if Com=FEh then fill, if Com=FFh then very large copy}
Count:=Com and $3F;
if Count<$3E then {large copy (3)}
begin
Inc(Count,3);
{Next word = pos. from start of image}
Posit:=Word(Source[SP]);
Inc(SP,2);
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end
else if Count=$3F then {very large copy (5)}
begin
{next 2 words are Count and Pos}
Count:=Word(Source[SP]);
Posit:=Word(Source[SP+2]);
Inc(SP,4);
for i:=Posit to Posit+Count-1 do
begin
Dest[DP]:=Dest[i];
Inc(DP);
end;
end else
begin {Count=$3E, fill (4)}
{Next word is count, the byte after is color}
Count:=Word(Source[SP]);
Inc(SP,2);
b:=Source[SP];
Inc(SP);
for i:=0 to Count-1 do
begin
Dest[DP]:=b;
inc(DP);
end;
end;
end;
end;
end;
end;
until false;

Note that you won't be able to compile this code, because the typecasting
won't work. (But I'm sure you'll be able to fix it).

===Appendix B===
IMA ADPCM DECOMPRESSION
by Vladan Bato (bat22@geocities.com)
http://www.geocities.com/SiliconValley/8682

Note that the current sample value and index into the Step Table should
be initialized to 0 at the start and are maintained across the chunks
(see below).

====IMA-ADPCM DECOMPRESSION ====

It is the exact opposite of the above. It receives 4-bit codes in input
and produce 16-bit samples in output.

Again you have to mantain an Index into the Step Table an the current
sample value.

The tables used are the same as for compression.

Here's the code :

Index:=0;
Cur_Sample:=0;

while there_is_more_data do
begin
Code:=Get_Next_Code;

if (Code and $8) <> 0 then Sb:=1 else Sb:=0;
Code:=Code and $7;
{Separate the sign bit from the rest}

Delta:=(Step_Table[Index]*Code) div 4 + Step_Table[Index] div 8;
{The last one is to minimize errors}

if Sb=1 then Delta:=-Delta;

Cur_Sample:=Cur_Sample+Delta;
if Cur_Sample>32767 then Cur_Sample:=32767
else if Cur_Sample<-32768 then Cur_Sample:=-32768;

Output_Sample(Cur_Sample);

Index:=Index+Index_Adjust[Code];
if Index<0 then Index:=0;
if Index>88 the Index:=88;
end;

Again, this can be done more efficiently (no need for multiplication).

The ''Get_Next_Code'' function should return the next 4-bit code. It must
extract it from the input buffer (note that two 4-bit codes are stored
in the same byte, the first one in the lower bits).

The Output_Sample function should write the signed 16-bit sample to the
output buffer.

=== Appendix A : THE INDEX ADJUSTMENT TABLE ===

Index_Adjust : array [0..7] of integer = (-1,-1,-1,-1,2,4,6,8);

=== Appendix B : THE STEP TABLE ===

Steps_Table : array [0..88] of integer =(
7, 8, 9, 10, 11, 12, 13, 14, 16,
17, 19, 21, 23, 25, 28, 31, 34, 37,
41, 45, 50, 55, 60, 66, 73, 80, 88,
97, 107, 118, 130, 143, 157, 173, 190, 209,
230, 253, 279, 307, 337, 371, 408, 449, 494,
544, 598, 658, 724, 796, 876, 963, 1060, 1166,
1282, 1411, 1552, 1707, 1878, 2066, 2272, 2499, 2749,
3024, 3327, 3660, 4026, 4428, 4871, 5358, 5894, 6484,
7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899, 15289,
16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767 );

===Appendix C===
WESTWOOD STUDIOS' ADPCM DECOMPRESSION
by Asatur V. Nazarian (samael@avn.mccme.ru)

==== WS ADPCM Decompression Algorithm ====

Each SND1 chunk may be decompressed independently of others. This lets you
implement seeking/skipping for WS ADPCM sounds (unlike IMA ADPCM ones).
But during the decompression of the given chunk a variable (''CurSample'') should
be maintained for this whole chunk:

SHORT CurSample;
BYTE InputBuffer[InputBufferSize]; // input buffer containing the whole chunk
WORD wSize, wOutSize; // Size and OutSize values from this chunk's header
BYTE code;
CHAR count; // this is a signed char!
WORD i; // index into InputBuffer
WORD input; // shifted input

if (wSize==wOutSize) // such chunks are NOT compressed
{
for (i=0;i<wOutSize;i++)
Output(InputBuffer[i]); // send to output stream
return; // chunk is done!
}

// otherwise we need to decompress chunk

CurSample=0x80; // unsigned 8-bit
i=0;

// note that wOutSize value is crucial for decompression!

while (wOutSize>0) // until wOutSize is exhausted!
{
input=InputBuffer[i++];
input<<=2;
code=HIBYTE(input);
count=LOBYTE(input)>>2;
switch (code) // parse code
{
case 2: // no compression...
if (count & 0x20)
{
count<<=3; // here it's significant that (count) is signed:
CurSample+=count>>3; // the sign bit will be copied by these shifts!

Output((BYTE)CurSample);

wOutSize--; // one byte added to output
}
else // copy (count+1) bytes from input to output
{
for (count++;count>0;count--,wOutSize--,i++)
Output(InputBuffer[i]);
CurSample=InputBuffer[i-1]; // set (CurSample) to the last byte sent to output
}
break;
case 1: // ADPCM 8-bit -> 4-bit
for (count++;count>0;count--) // decode (count+1) bytes
{
code=InputBuffer[i++];

CurSample+=WSTable4bit[(code & 0x0F)]; // lower nibble

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable4bit[(code >> 4)]; // higher nibble

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

wOutSize-=2; // two bytes added to output
}
break;
case 0: // ADPCM 8-bit -> 2-bit
for (count++;count>0;count--) // decode (count+1) bytes
{
code=InputBuffer[i++];

CurSample+=WSTable2bit[(code & 0x03)]; // lower 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable2bit[((code>>2) & 0x03)]; // lower middle 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable2bit[((code>>4) & 0x03)]; // higher middle 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

CurSample+=WSTable2bit[((code>>6) & 0x03)]; // higher 2 bits

CurSample=Clip8BitSample(CurSample);
Output((BYTE)CurSample);

wOutSize-=4; // 4 bytes sent to output
}
break;
default: // just copy (CurSample) (count+1) times to output
for (count++;count>0;count--,wOutSize--)
Output((BYTE)CurSample);
}
}

HIBYTE and LOBYTE are just higher and lower bytes of WORD:
#define HIBYTE(word) ((word) >> 8)
#define LOBYTE(word) ((word) & 0xFF)
Note that depending on your compiler you may need to use additional byte
separation in these defines, e.g. (((byte) >> 8) & 0xFF). The same holds for
4-bit and 2-bit nibble separation in the code above.

''WSTable4bit'' and ''WSTable2bit'' are the delta tables given in the next section.

Output() is just a placeholder for any action you would like to perform for
decompressed sample value.

Clip8BitSample is quite evident:

SHORT Clip8BitSample(SHORT sample)
{
if (sample>255)
return 255;
else if (sample<0)
return 0;
else
return sample;
}

This algorithm is ONLY for mono 8-bit unsigned sound, as I've never seen any
other sound format used with WS ADPCM compression.

Of course, the decompression routine described above may be greatly
optimized.

==== WS ADPCM Tables ====

CHAR WSTable2bit[]=
{
-2,
-1,
0,
1
};

CHAR WSTable4bit[]=
{
-9, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8
};

==HC_VQA.txt==
by Gordan Ugarkovic (ugordan@yahoo.com)
http://members.xoom.com/ugordan

This document describes how to view Westwood's HiColor VQA movies. These
are version 3 movies, but there are at least some version 2 VQAs that are
in this format. I will not describe the whole VQA layout here, I will
just explain how to display the VIDEO stream of the VQA, that is, how
to decompress the CBFZ and VPTR/VPRZ chunks.

First a little warning: I'm not sure which flag denotes the VQA is 8 bit
or 15 bit. I'm pretty convinced it's either bit 4 (0x10) or bit 2 (0x04)
of the Flags entry (see my VQA_INFO.TXT) in the header. Another way would
be to check the Colors entry in the header, if it is 0 it could imply
a HiColor movie.

There's a major difference between the old (8 bit, 256 color) and the new,
HiColor VQAs. Lookup tables are no longer split up into several CBP?
chunks, instead they come in one piece (a CBFZ chunk). Two lookup tables
can now be many frames apart, not just 8 (as usual). This is indicated
by the CBParts entry of the header (see VQA_INFO.TXT), which is set to 0.
Subsequent frames use the last lookup table loaded, of course.

Another thing: It appears the first CBFZ chunk comes inside the VQFR chunk
but the other ones seem to be located inside their own chunks,
called VQFL, which are followed by the usual VQFR chunks (containing
VPTR/VPRZ chunks).

Also, the movies are 15 bit, NOT 16 bit. There is a difference because
in 16 bit color depth there are 6 bits for the green channel, but
the VQAs use 5.

=== The CBFZ chunks===

These are a bit modified since the 8 bit VQAs. If the first byte of the
chunk is not NULL (0x00), it means the chunk is compressed using the
standard Format80 algorithm (see Vladan Bato's text on C&C file formats),
starting from that byte. If the first byte is NULL, the chunk is compressed
using a modified version of Format80 (see below), starting from the next
byte of the chunk. The original Format80 algorithm is used when the
amount of data to be compressed is less than 64 KB, otherwise the 'new'
algorithm is used.
When decompressed properly, a CBFZ chunk expands into 15 bit pixels packed
as shorts in normal Intel byte order. The red, green and blue values are
packed like this:

15 bit 0
0rrrrrgg gggbbbbb
HI byte LO byte

The r,g,b values make up a pixel and they can range from 0-31.
As in the old CBFZ chunks, these pixels make up the block lookup table
(also called a codebook).

=== The VPTR chunks===

These chunks use some sort of differential, run-length algorithm that
only records changes from the previous frame. Therefore, the previous
frame bitmap must be maintained throughout all the frames (you could
just draw the blocks that changed, though). This makes dropping frames
(in case of bad performance) impossible.

When decoding, you take a short int (Intel) from the chunk and examine
its 3 most significant bits (bits 15,14,13). These bits make up a
code prefix that determines which action is to be done.

Here's a list of the prefixes I encountered and their description
(Val is the short int value):

BITS - MEANING

000 - Skip Count blocks. Count is (Val & 0x1fff).

001 - Write block number (Val & 0xff) Count times.
Count is (((Val/256) & 0x1f)+1)*2. Note that this can only
index the first 256 blocks.

010 - Write block number (Val & 0xff) and then write Count blocks
getting their indexes by reading next Count bytes from
the VPTR chunk. Count is (((Val/256) & 0x1f)+1)*2.
Again, the block numbers range from 0-255.

011 - Write block (Val & 0x1fff).

101 - Write block (Val & 0x1fff) Count times. Count is the next
byte from the VPTR chunk.

After this, you take the next short int and repeat the above process.

Every row of blocks is processed individually of others.
When you encounter the end of a row, proceed to the next row
(blocks are processed left to right, top to down).
Repeat this process until all blocks in the frame are covered and
that's it!

Note that the above implies an absolute maximum of 8192 blocks (0x1fff+1).
Also note that prefix 100 is unused (at least in Tiberian Sun) but could
be used somewhere else...?

As for the VPRZ chunks, these are just VPTR chunks compressed with
the standard Format80 algorithm.

=== The modified Format80 scheme ===

This is really only a small modification of the basic algorithm.
The only commands that are modified are commands (3) and (5)
See Vladan's text). Instead of using offsets ABSOLUTE from
the start of the destination buffer, offsets RELATIVE to the
current destination pointer are used. If you ask me, I don't see
why this approach wasn't used in the first place as it would
suffer no disadvantage with the old files and it would be much
easier to compress even larger amounts of data. The guys at WW
were just careless, I guess... :-)

Anyway, in Vladan's algorithm, there is a line in
command (3) that says:
Posit:=Word(Source[SP]);
it should say:
Posit:=DP-Word(Source[SP]);

Likewise, for command (5):
Posit:=Word(Source[SP+2]);
it should be:
Posit:=DP-Word(Source[SP+2]);

== Games Using VQA ==

=== Version 1 ===

* [http://www.mobygames.com/game/win3x/legend-of-kyrandia-malcolms-revenge The Legend of Kyrandia: Malcolm's Revenge]

=== Versions 2 ===

* [http://www.mobygames.com/game/dos/command-conquer Command & Conquer]
* [http://www.mobygames.com/game/dos/command-conquer-red-alert Command & Conquer: Red Alert]
* [http://www.mobygames.com/game/lands-of-lore-guardians-of-destiny Lands of Lore: Guardians of Destiny]

=== Versions 3 ===

* [http://www.mobygames.com/game/windows/blade-runner Blade Runner]
* [http://www.mobygames.com/game/windows/command-conquer-tiberian-sun Command & Conquer: Tiberian Sun]
* [http://www.mobygames.com/game/windows/dune-2000 Dune 2000(v3)]
* [http://www.mobygames.com/game/windows/nox Nox]

==Other Documentation==
http://www.gamers.org/pub/idgames2/planetquake/planetcnc/cncdz/ has lots of data about this format. See vqa_overview.zip and vqafilesguild.zip. Also there is a decoder (vqatoavi) that decodes the dune2000 sample.

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

Electronic Arts Formats

2007-03-04T05:01:05Z

Siberian GRemlin: /* Games Using Electronic Arts Multimedia Formats */

* Extensions: ASF, CMV, DCT, TGI, TGV, TGQ, WVE, UV, UV2, MAD, VP6
* Company: [[Electronic Arts]]

Electronic Arts, the video game publishing empire, and the various constituent development houses under its umbrella, have deployed a number of multimedia formats in its games.

EA multimedia formats are comprised of a series of blocks with the following format:

bytes 0-3 block type [[FourCC]]
bytes 4-7 block size (including this 8-byte preamble)
bytes 8.. block payload

It is important to note that there is no consistent byte order for multi-byte numbers. However, order is optimized for target platform.

== Chunk Types ==

* Audio
** [[Electronic Arts SEAD]]: SEAD, SNDC, SEND
** [[Electronic Arts 1SNx]]: 1SNh, 1SNd, 1SNl, 1SNe
** [[Electronic Arts SCxl]]: SCHl, SCCl, SCDl, SCLl, SCEl
* Video
** [[Electronic Arts CMV]]: MVIh, MVIf, MVIe
** [[Electronic Arts TGV]]: kVGT, fVGT
** [[Electronic Arts DCT]]: mTCD
** [[Electronic Arts TGQ]]: pQTG, TGQs (rumored MUVf?)
** [[Electronic Arts TQI]]: pIQT, (rumored UV2f?)
** [[Electronic Arts MAD]]: MADk, MADm, MADe
** [[Electronic Arts VP6]]: MVhd, MV0K, MV0F
** [[Electronic Arts MPC]]: MPCh

== Games Using Electronic Arts Multimedia Formats ==

{| border="1" cellpadding="2"
! Name !! File Ext !! Video Codec !! Audio Codec || Byte Order
|-
| [http://www.mobygames.com/game/dos/nhl-95 NHL 95]
| cmv || CMV || none || le
|-
| [http://www.mobygames.com/game/dos/nhl-96 NHL 96]
| tgv || ? || ? || ?
|-
| [http://www.mobygames.com/game/dos/cybermage-darklight-awakening CyberMage: Darklight Awakening]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/need-for-speed Need for Speed]
| tgv || TGV || 1SNx/EACS/pcm_s8 || le
|-
| [http://www.mobygames.com/game/privateer-2-the-darkening Privateer 2: The Darkening]
| tgv || TGV || SEAD/adpcm_ima_ea_sead || le
|-
| [http://www.mobygames.com/game/dos/nba-live-96 NBA Live 96]
| tgv || TGV || 1SNh/EACS/adpcm_ima_ea_eacs || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2]
| dct || DCT || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-ii Need for Speed 2 (Demo)]
| uv || TGQ || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/saturn/warcraft-ii-the-dark-saga Warcraft II: The Dark Saga (Sega Saturn)]
| tgq || TGQ || ? || be
|-
| [http://www.mobygames.com/game/superbike-2001 Superbike 2001]
| tgq || ? || ? || ?
|-
| [http://www.mobygames.com/game/saturn/crusader-no-remorse Crusader: No Remorse (Sega Saturn)]
| tgq || TGQ || 1SNh/EACS/mulaw || be
|-
| [http://www.mobygames.com/game/harry-potter-quidditch-world-cup Harry Potter: Quidditch World Cup]
| tgq || TQI (not a typo) || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/wing-commander-prophecy Wing Commander: Prophecy]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/windows/the-sims The Sims]
| wve || TQI || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/nba-live-99 NBA Live 99]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-iii-hot-pursuit Need for Speed 3: Hot Pursuit]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-high-stakes Need for Speed 4: High Stakes]
| mad || MAD || SCHl/PT/adpcm_ea || le
|-
| [http://www.mobygames.com/game/need-for-speed-porsche-unleashed Need for Speed 5: Porsche]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| [http://www.mobygames.com/game/need-for-speed-hot-pursuit-2 Need for Speed 6: Hot Pursuit 2]
| mad || MAD || SCHl/PT/adpcm_ea_r1 || le
|-
| [http://www.mobygames.com/game/nba-live-2003 NBA Live 2003]
| mad || MAD || pcm_s16le_planar || le
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2004]
| mad || ? || ? || ?
|-
| [http://www.mobygames.com/game/fifa-soccer-2005 FIFA 2005]
| mad || MAD || SCHl/PT/adpcm_ea_r1, SCHl/PT/adpcm_ea_r3 || le
|-
| [http://www.mobygames.com/game/windows/simcity-4-rush-hour Sim City 4: Rush Hour]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/sims-2 The Sims 2]
| mad || MAD || ? || ?
|-
| [http://www.mobygames.com/game/need-for-speed-underground-2 Need for Speed: Underground 2]
| vp6 || VP6 || SCHl/GSTR/ealayer3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-most-wanted Need for Speed: Most Wanted]
| vp6 || VP6 || SCHl/GSTR/ealayer3 || le
|-
| [http://www.mobygames.com/game/need-for-speed-carbon Need for Speed: Carbon]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth The Lord of the Rings: The Battle for Middle Earth]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/lord-of-the-rings-the-battle-for-middle-earth-ii The Lord of the Rings: The Battle for Middle Earth II]
| vp6 || VP6 || ? || ?
|-
| [http://www.mobygames.com/game/windows/lord-of-the-rings-the-battle-for-middle-earth-ii-the-rise-of-the The Lord of the Rings: The Battle for Middle Earth II - The Rise of the Witch-King]
| vp6 || VP6 || ? || ?
|-
| [Command & Conquer: Tiberium Wars]
| vp6 || VP6 || unknown || ?
|}

In addition to FMV, the EA audio chunk types are frequently used throughout Electronic Arts games for music tracks, audio effects and speech. Older titles use the .ASF file extension for individual music tracks, whereas newer titles store multiple audio sequentially within the one file (hence rational for the ending chunk types) and use a variety of file extensions.

[[Category:Game Formats]]