WSS File Format

Bis-proprietary WSS files store Pulse Code Modulated (PCM) sound data. It's format is a variant of RIFF WAVE file format used for .wav

There are three sound formats 'accepted' by the engine

*ogg: Vorbis Stereo Music files.
*wav: Raw uncompressed PCM (mono or stereo)
*wss: compressed PCM mono

All formats can store mono/stereo, compressed/uncompressed. The above is the intent of each one.

Due to the Microsoft behemoth, wav files are 'industry standard' raw recording files. They are as good as any other raw recording choice with a range of convenient-to-use tools to do so. Wav files are also used as a standardized interchange format when converting a sound type from X to Y. Although they can be played as is, they are not intended for that purpose. They are unnecessarily huge (for the purposes of playback).

Bis, to their credit, introduced compressed PCM data. To that end, wss files come in three flavours

*Uncompressed: There is no performance, size or benefit between this, and a wav file. It is a not-normally-used, alternative to wav.
*Compressed Byte: Offers a fixed, 50% reduction in file size.
*Compressed Nibble: (Arrowhead only) Offers a fixed. 75% reduction in file size.

The intent of wss is to store compressed mono-only pcm data. The engine and the format allow the other variants but that is not a preferred use (you will get rpt warnings).

As a breakdown, here are the statistics of wss types in OFP and Arrowhead

Offset	OFP	Arrowhead
Stereo	1	19
Mono	43	659
ByteCompressed	4074	24197
NibbleCompressed	none	156

The above should show that the intent has always been to compress mono only pcm data, and the newer nibble format is taking over as of pmc/baf. The reason for mono wss files is straightforward. Almost all sounds in the game are environment, gunshot and engines. You don't need a stereo wind, nor a stereo vehicle noise when the tank is running over you. There is, only one direction, or all directions, the noise is coming from.

Faulty files

A small number of Bis files have errors that cause rpt errors. ALl are heuristically decoded by the engine anyway. They are either straightforward and unintended stereo wss, or encoded nibble files that were actually not formatted properly. There are no 'bad' Operation Flashpoint files. Given the stupendous number of sounds in Arrowhead, and given that a large quantity of wss is derived from Arma One, the few faulty emanations are not unreasonable.

Tools

BI's WavToWSS.exe for encoding wav to wss 3rd party tools such as [Mikero's Wss2Wav _{(dead link)}] for translating both ways

File Format

Offset	Datatype	Content	Description
0	char[4]	"WSS0"	file signature
4	ulong	CompressionType	0 == none. 4 == Nibble compression. 8 == Byte compression
8	ushort	format	Always 1 (WAVE_FORMAT_PCM)
10	ushort	nChannels	1=mono, 2=stereo
12	ulong	SampleRate	e.g. 44100Hz
16	ulong	BytesPerSecond	SampleRate * BlockAlign
20	ushort	BlockAlign	nChannels * BytesPerSample
22	ushort	BitsPerSecond	usually 16
24	ushort	Output Size	See Below
26	byte[fileSize-26]	<soundData>	here the PCM data of the sound is stored

Input Size

The Input Size is the bytes remaining in the file. For uncompressed data it is (logically) always an even number (since it is a count of nShorts / 2). However many Bis wss Delta4 encoded files are corrupt. While they specify uncompressed in the header, they are in fact encoded, and the only way of detecting same is by them having an odd number of bytes to decode. These files cause a rpt error but the engine heuristically decodes them anyway.

Output Size

This 'value' was similar in architecture at least to the wav "datasize" chunk. It appears to be unreliable in intent. And, the intent appears to have changed.

Originally it was very similar to the OutputSize specified by a (compressed) pbo. Specifically,

• = 0 'uncompressed'. Remaining data is the size.
• = input size. uncompressed.
• non zero. The resultant size to extract (in bytes)

The size in fact need not be known because output size is always a defined multiple of the input size.

For Delta4 nibble compression, the value has changed to mean the Delta seed value. But this too is has been corrupted.

In General:

• Uncompressed data will have this set to zero.
• Compressed bytes will have this set to a multiple of the input size or zero.
• Compressed Nibbles are delta seed.

None of above is reliable

Note that early versions of wss formatted files did not appear to have this field at all (for uncompressed). There is no way of telling

Decompression

Bis optionally use Delta8 (byte) or Delta4 (nibble) 'Lossy' Compression for mono pcm data only.

The facility exists to handle stereo compression but it isn't employed.

Byte Compression

Compression consists of single encoded byte 'samples' versus uncompressed short 'samples'. Each byte is, effectively, extrapolated to a short, thus making the compressed BYTE array, and the resulting decompressed SHORT array the same number of elements(length). The length is the remaining file length (in bytes) after the header.

C++ code

Function returns a short array, same size as it is compressed byte equivalent

#define LOG10	2.3025850929940456840	//ln(10)
#define LOG2	1.4426950408889634070	//log2(e)
#define MAGIC_NUMBER	((LOG10*LOG2)/28.12574042515172)

short* DeCompress(const char *CompressedData,int len)
{
        short *snap,*OutputData;

	if (!(snap=OutputData=new short[len]))  return 0;
	short LastVal=0;
	for (;len--;CompressedData++)
	{
		if (*CompressedData)
		{
			double asFloat = abs(*CompressedData) *MAGIC_NUMBER;
			double rnd = Round(asFloat);
			asFloat = pow(2.0, asFloat - rnd) * pow(2, rnd);// mantissa -
			if (*CompressedData < 0) asFloat *= -1;
			int asInt = Round(asFloat)+LastVal;
			if (asInt > SHRT_MAX ) asInt = SHRT_MAX ;
			if (asInt < SHRT_MIN) asInt = SHRT_MIN;
			LastVal=(short)asInt;
		 }
		*OutputData++ = LastVal;
	}
	return snap;
}

C# code

If the <soundData> is compressed the following (C#) code can be used for decompression:

PCMData = new Int16[soundData.Length];
for (int j = 0; j < PCMData.Length; j++)
{
  SByte srcSample = (SByte)soundData[j];
  if (srcSample != 0)
  {
    double asFloat = Math.Abs(srcSample) / 28.12574042515172;
    asFloat *= 2.3025850929940456840; //ln(10)
    asFloat *= 1.4426950408889634070; //log2(e)
    double rnd = Math.Round(asFloat);
    double mantisse = Math.Pow(2.0, asFloat - rnd);
    asFloat = mantisse * Math.Pow(2, rnd);
    if (srcSample < 0) asFloat *= -1;
    Int32 asInt = (int)Math.Round(asFloat);
    asInt = (j == 0) ? asInt : (asInt + PCMData[j - 1]);
    if (asInt > short.MaxValue) asInt = short.MaxValue;
    if (asInt < short.MinValue) asInt = short.MinValue;
    PCMData[j] = (Int16)asInt;
  }
  else PCMData[j] = (j == 0) ? (Int16)0 : PCMData[j - 1];
}

Nibble Compression

Although by no means the same thing, Nibble compression is an adaptation of IMA ADPCM compression. Each nibble represents a SHORT of PCMdata. Thus the resultant output size will be four times larger (in bytes).

C++ Code

//
// all honor and glory to T_D
//

static short PCMIndex[] = {-8192, -4096, -2048, -1024, -512, -256, -64, 0, 64, 256, 512, 1024, 2048, 4096, 8192};

static short limits(int PCM)
{
 if(PCM > SHRT_MAX) PCM = SHRT_MAX;
 else if(PCM < SHRT_MIN) PCM = SHRT_MIN;
 return PCM;
}

short * DeCompressNibble(const char *NibbleData,int len)//len in bytes
{
  short  *snap,*pcmData;
  if (!(snap=pcmData=new short[2*len]))  throw GENERR_NOMEM;
  int delta = 0;
  while (len--)
  {   
    byte nibble=*NibbleData++;
   *pcmData++ = limits(delta += PCMIndex[nibble >> 4]);
   *pcmData++ = limits(delta += PCMIndex[nibble & 0x0F]);
  }
  return snap;
}