MultimediaWiki - User contributions [en]

OpenMG

2018-11-29T15:34:06Z

Maxpol: Mor links.

* Website: [http://www.sony.net/Products/OpenMG/ http://www.sony.net/Products/OpenMG/]
* Company: [[Sony]]

Open Media Gate (OpenMG) is a legacy DRM system developed by [[Sony]].

[[Category:Multimedia DRM]]

Sony ATRAC

2018-11-29T15:33:08Z

Maxpol: Tiny improvement.

* Product overview: http://www.sony.net/Products/ATRAC3/overview/index.html#family
* Developer's interview: https://www.sony.net/Products/ATRAC3/special/developers01.html

ATRAC ('''A'''daptive '''TR'''ansform '''A'''coustic '''C'''oding) is the collective name for audio compression technologies
developed by [[Sony]].

This codec family includes the following compression algorithms today:

* [[ATRAC]]
* [[ATRAC3]]
* [[ATRAC3plus]]
* ATRAC Advanced Lossless (AAL)

ATRAC-compressed audio is usually stored in [[Microsoft_Wave|WAV]]/[[Microsoft_Audio/Video_Interleaved|AVI]], [[RealMedia|RM]] and [[Oma|Oma/Omg]] containers.

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]
[[Category: Lossless Audio Codecs]]

ATRAC3plus

2018-11-29T15:31:23Z

Maxpol: More links.

* Format tag: uses WAVE_FORMAT_EXTENSIBLE with the "SubFormat" field set to the following [[GUID]]: E923AABF-CB58-4471-A119-FFFA01E4CE62
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3+/
* Stored in: [[Microsoft_Wave|WAV]] and [[Oma|Oma/Omg]] containers.
* Official information: http://www.sony.net/Products/ATRAC3/tech/atrac3plus.html

= ATRAC3plus introduction =

ATRAC3plus is a proprietary audio compression algorithm developed by [[Sony]]. As in the case of its predecessor [[ATRAC3]], ATRAC3plus represents the next generation of the [[ATRAC]] codec introduced in 1992 with the MiniDisc. Common use of that codec is in nowel Minidisc players and Portable Playstations made by [[Sony]].

Streams coded with ATRAC3plus are usually stored either in the [[Microsoft_Wave|WAV]] container (those files have the ".at3" extension though) or in the Sony's proprietary [[Oma|Oma/Omg]] container. In the case of the [[Microsoft_Wave|WAV]] container the undocumented [[GUID]]:
E923AABF-CB58-4471-A119-FFFA01E4CE62
is used in order to indicate the ATRAC3plus codec.

There is very limited number of software products supporting encoding/decoding of the ATRAC3plus streams; most of them are unfortunately available for [[Microsoft]] Windows only. Those are:

* Sony's own SonicStage software (Windows only)
* ATRAC Codec Plugin for Sony Media Software (Windows only)
* Sonic Studio's expensive N-code plugin for professionals (available for Windows and Mac OS X)

There is a multi-channel version of ATRAC3plus called "ATRAC-X".

= ATRAC3plus technical documentation =

=== Available bitrates ===

ATRAC3plus operates on fixed bitrates only. The following bitrates are offered by the Sony Encoding software:

bitrate frame size (stereo)
------------- -------------------
48 Kbps 280 bytes
64 Kbps 376 bytes
96 Kbps 560 bytes
128 Kbps 744 bytes
160 Kbps 936 bytes
192 Kbps 1120 bytes
256 Kbps 1488 bytes
320 Kbps 1864 bytes
352 Kbps 2048 bytes

=== Coding techniques ===

ATRAC3plus is a hybrid subband/MDCT codec like [[MP3]]. The signal is split into 16 subbands using [http://en.wikipedia.org/wiki/Polyphase_quadrature_filter Polyphase Quadrature Filter] (further PQF) before MDCT and bit allocation. The sample-frame size is 2048 samples per channel.

After the subband splitting ATRAC3plus tries to extract sine waves from each subband using Generalized Harmonic Analysis (further GHA). GHA encodes parameters of extracted sine waves such as frequency, amplitude and phase into final bitstream.

After the sine waves extraction the remained signal (residual) will be transformed into frequency domain by a 128-point [http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform Modified discrete cosine transform]. The resultet MDCT spectrum will be devided into 32 quantization units of unequal width (higher frequencies - wider units). The relationship between QMF bands and quantization units (QU) is shown in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | QMF subband
| colspan="8" style="text-align:center;"| 0
| colspan="4" style="text-align:center;"| 1
| colspan="4" style="text-align:center;"| 2
| colspan="2" style="text-align:center;"| 3
| colspan="2" style="text-align:center;"| 4
| colspan="2" style="text-align:center;"| 5
| 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | Quant unit
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|}

The flowchart of the ATRAC3plus decoding process is shown below:

[[image:Atrac3plus_decoder_flow.png]]

"Bitstream decoder" decodes various sound parameters from supplied frame data. First the residual signal will be decoded by applying inverse quantization, power compensation, inverse MDCT and gain compensation. Then the sine waves will be synthesized according with their parameters such as frequency, amplitude and phase. Then the residual and the synthesized sine waves will be added together. Optionally, some white noise can be added if specified in the bitstream.

This processing will be repeated for each of 16 subbands. Finally the PQF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal.

Various algorithms are used to improve compression results:

* gain control for reducing pre-echo artifacts
* power compensation for better quality at low bitrates

The following techniques are used in order to make the compressed data smaller:

* variable-lenght ([[Huffman]]) coding
* [[Vector_Quantization|vector quantization]] based on trained tables
* [[Differential_Coding|differential coding]]

Probably the most interesting part of the ATRAC3plus codec is the Generalized Harmonic Analysis (GHA) - an inharmonic frequency analysis proposed by Norbert Wiener in 1930. The main advantage of that is an excellent frequency resolution that surpasses the short-time Discrete Furier transformation. However it requires huge amount of calculations. Several algorithms to work around that problem were introduced during last 20 years, for example the one proposed by Dr.Hirata.

==== Coding methods for compressing bitstream parameters ====

Coding methods described in this section serve the purpose of representing different bitstream parameters like word-length, scale factor etc. using a smaller number of bits. It will be achieved by exploring and removing redundancy from the signals being encoded. The coding techniques described here are [[Lossless_compression|lossless]].

===== Huffman coding =====

ATRAC3plus uses this coding technique widely. There are more than 130 different huffman tables in total for coding bitstream signals. Usually more frequently occuring values will have shorter codes.
ATRAC3plus huffman trees are [http://en.wikipedia.org/wiki/Canonical_Huffman_code canonical ones]. That means those can be stored very compactly by specifying the following parameters:

* number of bits of the shortest codeword
* number of bits of the longest codeword
* number of items for every bit length
* order of items

In my code I'm using the following descriptor in order to specify a canonical huffman table:

uint8_t min; /* shortest codeword length */
uint8_t max; /* longest codeword length */
uint8_t num_items[max - min + 1]; /* number of items for every bit length */

For example, the huffman table vlc_tab_index = 3 [[#Huffman tables for delta coding|here]] will be described as follows:

min = 1
max = 5
num_items[1, 0, 2, 3, 2]

The 2nd element of the array "num_items" is set to "0" because there is no codeword with the length of 2 bits.

The following C-pseudocode can be used for generating huffman tables from the descriptor described above during decoder initialization:

code = 0;
index = 0;

for (num_bits = min; num_bits <= max; num_bits++) {
for (i = num_items[num_bits]; i > 0; i--) {
bits [index] = num_bits;
codes[index] = code++;
index++;
}
code <<= 1;
}

The array "bits" receives length in bits for each codeword, "codes" receives codeword itself.

Finally, the order of codes need to be specified. A simple remapping table will be used to translate the code index into final code. For the table described above the translation table will look as follows:

0, 1, 7, 2, 3, 6, 4, 5

===== Delta coding =====

ATRAC3plus utilizes various delta-coding schemes in order to remove linear correlation from the signal. It often uses the [http://en.wikipedia.org/wiki/Modular_arithmetic modular arithmetic] as well. The main advantage of this coding is that only the half of the range of the difference values is required. An example: word-length information coefficients in the range 0...7 need to be transmitted compactly. Using delta coding this would require to code difference values in the range -7...+7, also 15 values.

In the case of modular arithmetic the range of the difference values can be reduced to 0...7 by introducing a "wrap-around" so that the final equation looks like this:

B = (A + delta) & 7;

Below an example with "wrap around":

Consider we need to code the value B = "1" and the reference value A = "6". Then the difference value (delta) will be = "-5". According with equation above the delta value of "3" can be used instead of "-5":

(6 + 3) & 7 = 1;

Another example without "wrap around":

Consider we need to code the value B = "7" and the reference value A = "2". Then the difference value (delta) will be = "5":

(2 + 5) & 7 = 7;

Further variable-length codes will be used to reduce amount of bits of difference values in accordance with their probability.

The following is a description of the delta-coding methods used in ATRAC3plus:

====== Method A: huffman-coded modulo difference to previous ======

Consider the following signal:

3, 6, 6, 3, 3, 3, 4, 2, 2, 1, 1, 1, 3

Now code it using delta coding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Coefficient !! Modulo delta value !! Huffman code !! Number of bits
|-
| align="center" | 3 || align="center" | - || align="center" | - || align="center" | 3
|-
| align="center" | 6 || align="center" | 3 || align="center" | 11110 || align="center" | 5
|-
| align="center" | 6 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 5 || align="center" | 1101 || align="center" | 4
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 4 || align="center" | 1 || align="center" | 100 || align="center" | 3
|-
| align="center" | 2 || align="center" | 6 || align="center" | 1110 || align="center" | 4
|-
| align="center" | 2 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 7 || align="center" | 101 || align="center" | 3
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 2 || align="center" | 1100 || align="center" | 4
|}

The 1st coefficient has no delta value associated with it because there is no previous value. It will be coded "as is" using fixed length of 3 bits. The following delta values get a variable-length code from the table val_tab_index = 2 [[#Huffman tables for delta coding|here]] so the final number of bits to be transmitted will be = 32.
Compared to the unpacked version (13 x 3 bits = 39 bits) the coding method described above will yield a bit-reduction of 7 bits (18% smaller).

====== Method B: huffman-coded modulo difference to master ======

In a stereo mix the signal of the left channel is often very similar to the signal of the right channel (i.e. there is a high cross-correlation between the channels). In this case the estimated sound parameters like word-length or scale factor will have a high similarity as well. Then coding the differential signal between the channels can lead to a significant bit reduction.
Surely at least the one of the channels must be coded independently. Such a channel will be called "master" (it's usually the left channel but ATRAC3plus has the possibility to make the right channel act like a master as well). For the 2nd channel only the difference to master will be coded. The 2nd channel will be called "slave" in this case.

Below an example of such a high-correlated signal:

Left : 6, 5, 6, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1
Right: 6, 5, 6, 2, 2, 2, 3, 1, 1, 1, 2, 1, 1
Diff : 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0

Coding the difference signal using the table val_tab_index = 0 [[#Huffman tables for delta coding|here]] will result in another signal 15 bits long. Compared to the unpacked version (13 x 3 bits = 39 bits) that coding method will yield a bit-reduction of 24 bits (62% smaller).

====== Method C: shorter delta to min ======

Sometimes coefficients in a signal are very close to each other, so subtracting the minimum value from each coefficient will result in smaller deltas whose can be coded using fewer bits.

An example:

2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1

As one can see the values in the sequence above are very similar to each other. Let us find minimum and maximum values and then determine the number of delta bits:

min = 1; max = 2; num_delta_bits = ilog2(max - min + 1) = 1 bit

Now let us encode the sequence above using shorter deltas:

num_delta_bits = 1 will be coded as a 2-bit value
min = 1 will be coded as a 3-bit value
deltas: 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0

The encoded signal is 5 + 1 x 15 = 20 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 25 bits (55% smaller).

Another example:

1, 2, 3, 2, 4, 2, 1, 2, 3, 3, 1, 4, 4, 1, 1

min = 1; max = 4; num_delta_bits = ilog2(max - min + 1) = 2 bits

Now the encoded signal:

num_delta_bits = 2 (will be coded as a 2-bit value)
min = 1 (will be coded as a 3-bit value)
deltas: 0, 1, 2, 1, 3, 1, 0, 1, 2, 2, 0, 3, 3, 0, 0

The encoded signal is 5 + 2 x 15 = 35 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 10 bits (22% smaller).

====== Method D: sequence of numbers in ascending order ======

Sometimes ATRAC3plus have to deal with sequences of numbers (i.e. gain control position information) where all items are known to be in ascending order (i.e. satisfy the following equation: ''Vn+1 > Vn''). Such sequences can be packed without any additional bitstream information by examining previous value (predecessor), calculating magnitude between it and the maximum value and making the decision about number of bits of the next delta value.

Consider the following sequence:

Position index: 0, 1, 2, 3, 4, 5, 6, 7
---------------------------------------------
Position info : 5, 7, 14, 15, 18, 25, 29, 30
---------------------------------------------
Num delta bits: 5, 5, 5, 4, 4, 3, 1, 0

1st coefficient (position index = 0) will be coded directly using 5 bits because the sequence should start somewhere.
The following coefficients (except one with the value of "30") will be coded according to the following pseudocode:

num_delta_bits = ilog2(31 - prev_val);
if (num_delta_bits == 5)
new_val = get_bits(5);
else
new_val = prev_val + get_bits(num_delta_bits) + 1;

Let us return to our sequence. The 2nd value will be coded directly as well using 5 bits because ilog2(31 - 5) = 5. Similar for the 3rd one. No delta coding is applied in that case. The 4th value will be delta-coded using 4 bits:

num_delta_bits = ilog2(31 - 15) = 4 bits;
delta = 18 - 15 - 1 = 2

And so on until we reach the last value = 30. In this case there is only one value that meets our condition ''Vn+1 > Vn'': the value of "31". In this case no delta will be transmitted and the coming value will be calculated just as:

new_val = prev_val + 1;

Therefore the resulting sequence will be 27 bits long. Compared to the unpacked version (8 x 5 bits = 40 bits) this packing method will yield a bit-reduction of 13 bits (32% smaller).

===== Vector quantization with residual encoding =====

One further packing technique used in ATRAC3plus is based on so-called "shape prediction vectors". Encoder decomposes a signal (word-length or scale factor info) into "shape prediction" + residual. Then only the index of the "shape prediction vector" and the huffman-coded residual will be transmitted. The main advantage of this method is when the shape matches the coded signal closely, the residual can be represented very compactly (usually 1-2 bits per value). Moreover, the majority of values of the residual will turn into zeroes, which can be further packed.

Each entry of the "shape prediction tables" contain an average value over 3 coefficients. This helps to keep those tables comparable small. For example, for a signal of 32 values each "shape table" will have 10 entries (last entry contains usually an average value over 5 coefficients).

Consider the following signal to be encoded:

7, 7, 6, 5, 4, 4, 3, 2, 2, 2, 1, 1

Let us "quantize" that signal by diving it into 4 * 3 groups and find the averaged value in each group:

floor((7 + 7 + 6) / 3 + 0.5) = 7,
floor((5 + 4 + 4) / 3 + 0.5) = 4,
floor((3 + 2 + 2) / 3 + 0.5) = 2,
floor((2 + 1 + 1) / 3 + 0.5) = 1

Find a "shape table" in the trained set that closely matches our "quantized" version. It will be (for example):
7, 5, 2, 1

Now compute the residual:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | Original signal
| style="text-align:center;"| 7
| style="text-align:center;"| 7
| style="text-align:center;"| 6
| style="text-align:center;"| 5
| style="text-align:center;"| 4
| style="text-align:center;"| 4
| 3 || 2 || 2 || 2 || 1 || 1
|-
! bgcolor="#f0f0f0" | Unpacked shape table
| 7 || 7 || 7 || 5 || 5 || 5 || 2 || 2 || 2 || 1 || 1 || 1
|-
! bgcolor="#f0f0f0" | Residual
| 0 || 0 || -1 || 0 || -1 || -1 || 1 || 0 || 0 || 1 || 0 || 0
|}

Now select a huffman table that represents the residual above as small as possible. The following huffman tree assigns the shortest code (1 bit) to the most frequently occuring symbol = "0" and 2-bit codes to the others: "1" and "-1":

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | -1
|}

The packed signal will occupy 21 bits: 4 bits "shape table" index + 17 bits residual(7 bits for "zeroes" + 10 bits for "non-zeroes"). Compared to the unpacked version (12 x 3 bits = 36 bits) this packing method will yield a bit-reduction of 15 bits (42% smaller).

===== Value grouping with "group coded" flag =====

If a signal contains lots of zeroes, grouping several values together and assigning the "group coded" flag to each group will achieve a significant bit-reduction. Consider the following sequence of numbers to be encoded:

0, 0, 1, 2, 0, 0, 3, 3, 0, 0, 0, 7, 0, 6, 0, 0

Let us cluster each two values together and assign the "coded" flag (1 bit) to each group:

(0, 0); flag = 0 (group not coded)
(1, 2); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(3, 3); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(0, 7); flag = 1 (group coded)
(0, 6); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)

Thereafter, each "not coded" group requires only one bit to be transmitted indicating that all values in that group are zero. On the other hand, each "coded" group requires one extra bit to be transmitted indicating that at least one value in that group is non-zero. In the case above that overhead is worthwhile because the half of the signal contains zeroes.

The encoded signal is 4 x 1 + 4 x 7 = 32 bits long while the unpacked one is 16 x 3 = 48 bits long. The bit-reduction is thereafter 16 bits (33% smaller).

== Multichannel ATRAC3plus (ATRAC-X) ==

ATRAC3plus supports multichannel streams (up to 8 channels). Such streams are encoded in units customary called "channel block"; each block contains max. 2 channels (ie can be MONO or STEREO). For example, taking the channel_id = 3 and looking at the table below we have a stream containing 2 channel blocks: 1 stereo + 1 mono and thus 3 channels.
The base codec operates on either MONO or STEREO channel blocks only.

=== ATRAC-X channel configurations ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! channel_id !! total channels !! number of channel blocks !! speaker mapping
|-
| align="center" | 0 || align="center" | 0 || align="center" | undefined ||
* undefined
|-
| align="center" | 1 || align="center" | 1 || align="center" | 1 ||
* front: center (MONO)
|-
| align="center" | 2 || align="center" | 2 || align="center" | 1 ||
* front: L, R (STEREO)
|-
| align="center" | 3 || align="center" | 3 || align="center" | 2 ||
* front: L, R
* front: center
|-
| align="center" | 4 || align="center" | 4 || align="center" | 3 ||
* front: L, R
* front: center
* rear: surround
|-
| align="center" | 5 || align="center" | 5+1 || align="center" | 4 ||
* front: L, R
* front: center
* rear: L, R
* LFE
|-
| align="center" | 6 || align="center" | 6+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* rear: center
* LFE
|-
| align="center" | 7 || align="center" | 7+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* side: L, R
* LFE
|}

== Bitstream overview ==

The table below shows the bitstream organization of ATRAC3plus at the top-level. Depends on [[#ATRAC-X channel configurations|channel configuration]] a typical frame may contain more than one channel block. In this case the additional fields [[#channel_block_type|channel_block_type]] and [[#channel_block_data|channel_block_data]] will be included for each block.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! number of bits !! value !! description
|-
| align="center" | start_marker || align="center" | 1 || align="center" | 0 ||
marks the start of the ATRAC3plus bitstream
|-
| align="center" | channel_block_type || align="center" | 2 ||
* 00b - MONO block
* 01b - STEREO block
* 10b - EXTENSION block
| align="center" | type of the channel block
|-
| align="center" | channel_block_data || align="center" | variable || || align="center" | contains encoded sound information
|-
| align="center" | terminator || align="center" | 2 || align="center" | 11b || align="center" | indicates the end of the bitstream
|}

=== Channel block types ===

There are following channel block types in ATRAC3plus:

* '''Mono channel block''': contains monaural sound data.
* '''Stereo channel block''': contains stereophonic sound data.
* '''Extension block''': as indicated by its name it's intended to carry some extension information. Its purpose is unknown though due to the lack of an official description. All existing decoder implementations are programmed to ignore blocks of that type.

=== Channel block layout ===

ATRAC3plus was designed to provide a high-quality sound compression. Therefore it tries to save as much bits as possible. It uses a new coding scheme for channel blocks compared to ATRAC3: channels in a stereo sound are no more coded separately but rather in one stereo channel block. The bitstream for such a block provides the possibility for both channels to share several sound parameters so that there is no need to transmit the same things twice. Depends on correlation between the channels this can lead to a significant bit reduction and thus improve coding quality.

A mono/stereo channel block contains the following pieces of sound information:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! size in bits !! description
|-
| align="center" | [[#Sound header|sound_header]] || align="center" | 6 || width="700" | defines some global sound parameters
|-
| align="center" | [[#Word-length information|wordlength_info]] || align="center" | variable || quantization word length information for each quant unit
|-
| align="center" | scalefactor_info || align="center" | variable || quantization scale factor indexes for each coded quant unit
|-
| align="center" | codetable_info || align="center" | variable || code table table information for each coded quant unit
|-
| align="center" | spectra || align="center" | variable || huffman-coded spectral information for each coded quant unit
|-
| align="center" | window_info || align="center" | variable || tells which IMDCT window shape should be used during the sound reconstruction
|-
| align="center" | gain_info || align="center" | variable || gain envelope used by the gain compensation
|-
| align="center" | gha_info || align="center" | variable || information about sine-like waves in the compressed sound obtained by the GHA. It contains quantized frequency, amplitude and phase for each wave to be synthesized in the decoder.
|-
| align="center" | noise_info || align="center" | 1/9 || contains noise flag, level index and table selector for the white noise to be added during decoding.
|}

==== Sound header ====

At the start of each channel block the sound header is located. It contains the following fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || num_quant_units || valid values: 0...27,31 || width="500" | number of coded quantization units - 1. The value of "0" indicates one coded unit, the value of "31" - 32 ones. The values 28, 29 and 30 are invalid.
|-
| align="center" | 1 || align="center" | x_flag || || to be figured out
|}

==== Word-length information ====

===== Coding summary =====

Word-length (or quantization precision) information follows the sound header. It defines the word-length parameter for each [[#num_quant_units|coded quantization unit]]. This parameter is in the range 0...7, where the value of "7" indicates the highest quantization precision and the value of "1" - the lowest one. The value of "0" means no data, i.e. the corresponding quantization unit was not coded.

In the case of the stereo channel block the word-length parameters for the channel 1(L) will be transmitted first followed by the the word-length parameters for the channel 2(R). The word-lengths for the channel 1 are always coded independently. The word-lengths for the channel 2 can be coded either independently or relative to the channel 1. In this case the 1st channel is called "master" and the 2nd one - "slave".
The word-lengths for the mono block will be coded just like the channel 1 in the stereo block.

In order to keep the word-length data as small as possible ATRAC3plus uses several coefficient packing techniques achieving different amount of bits needed for transmission:

* the coefficients are coded directly (3 bits value). This means no packing and used at high bitrates because the frame size is big enough to keep the infomation unpacked.

* differential coding + huffman-coded delta: the first coefficient is coded directly; all others are huffman-coded deltas to the previous coefficient.

* prediction + huffman-coded residual: this techniques offers the best packing and used at low bitrates. It's analogous to the lossless coding and based on trained shape tables serving as prediction. Later the huffman-coded residual will be added to the prediction prefectly reconstructing the coefficients.

===== Reconstruction of trimmed word-length coefficients =====

Word-length coefficient of the trailing quantization units corresponding to the high spectral bands tend to be either 1 (low-precision) or 0 (not coded). Such coefficients will be ommited and one the following modes will be used in order to reconstruct their values during decoding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! mode code(2 bits) !! num_coded_vals !! split_point_delta !! Action(master) !! Action(slave)
|-
| align="center" | 0 || align="center" | not present
|rowspan="3" style="text-align:center;" | not present
|colspan="2" style="text-align:center;" | no trimmed coefficients
|-
| align="center" | 1
|rowspan="3" style="text-align:center;" | 5 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients to "0"
|-
| align="center" | 2 || width="220" | set all trimmed coefficients to "1" || width="220" | for each trimmed coefficient read one bit of its direct value
|-
| align="center" | 3 || align="center" | 2 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients up to split point to "1" and after split point - to "0". The split point is calculated differently for master and slave channels (see below)
|}

To calculate the split point from [[#split_point_delta|split_point_delta]] do the following:

* for the master channel: number of zeroes = split_point_delta + 1
* for the slave channel: number of ones = split_point_delta + 3

The following C-pseudocode shows how to parse a bitstream according with the table above:

mode = get_bits(2);
if (mode) {
num_coded_vals = get_bits(5);
if (mode == 3)
split_point_delta = get_bits(2);
} else {
num_coded_vals = [[#num_quant_units|num_quant_units]];
}

The following C-pseudocode shows how to reconstruct trimmed word-length coefficients according with the table above:

switch (mode) {
case 0: /* no further action */
break;
case 1:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
break;
case 2:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++) {
if (channel == master)
wl_coeffs[pos] = 1;
else
wl_coeffs[pos] = get_bits(1);
}
break;
case 3:
if (channel == master)
split_point = [[#num_quant_units|num_quant_units]] - split_point_delta - 1;
else
split_point = num_coded_vals + split_point_delta + 3;

for (pos = num_coded_vals; pos < split_point; pos++)
wl_coeffs[pos] = 1;

for (; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
}

===== Word-length coding in detail =====

The word-length information for each channel will be coded as follows:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! comments
|-
| align="center" | 2 || coding_mode || width="500" | indicates the coding mode used.
|-
| align="center" | variable || align="center" | coeff_info || word-length coefficients coded according with the [[#coding_mode|coding_mode]].
|}

The [[#coding_mode|coding_mode]] parameter may be interpreted differently depends on the channel number. The following pseudocode examples explain the coding modes in detail:

===== Mode 0 (master and slave) =====

All coefficients will be directly coded as follows:

for (i = 0; i < [[#num_quant_units|num_quant_units]]; i++)
wl_coeffs[i] = get_bits(3);

===== Mode 1 (master) =====

Leading "n" values are stored directly while trailing ones are packed using [[#Method C: shorter delta to min|Method C: shorter delta to min]] method.

Data stored in the bitstream:

* 2 bits: index of the table of weigths, "0" - indicates "no table used"
* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 5 bits: number of directly coded coefficients ('''num_direct_coeffs'''). This value must be < [[#num_coded_vals|num_coded_vals]]
* 2 bits: size of deltas in bits ('''delta_bits''')
* 3 bits: minimum value ('''min_value''')
* for each '''num_direct_coeffs'''
** 3 bits: coefficient value
* if '''delta_bits''' > 0: for each ([[#num_coded_vals|num_coded_vals]] - '''num_direct_coeffs''')
** '''delta_bits''': delta value to be added to the '''min_value'''

The following C-pseudocode summarizes all above:

weigths_tab_indx = get_bits(2); /* get index of weights table to be added after decoding */

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

num_direct_coeffs = get_bits(5);
if (num_direct_coeffs > [[#num_coded_vals|num_coded_vals]])
ABORT("Invalid number of directly coded coefficients");

delta_bits = get_bits(2);
min_value = get_bits(3);

for (pos = 0; pos < num_direct_coeffs; pos++)
wl_coeffs[pos] = get_bits(3);

for (; pos < num_coded_vals; pos++) {
if (delta_bits)
wl_coeffs[pos] = min_value + get_bits(delta_bits);
else
wl_coeffs[pos] = min_value;
}

/* reconstruct trimmed coefficients as described [[#Reconstruction of trimmed word-length coefficients|here]] */

/* add weighting coefficients if requested */
if (weigths_tab_indx) {
for (pos = 0; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] += [[#Tables of weights|wl_weights]][channel_num][weights_tab_indx - 1][pos];
}

===== Mode 1 (slave) =====

Coding method: [[#Method B: huffman-coded modulo difference to master|Huffman-coded modulo difference to master]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 2 bits: indicates which huffman table from [[#Huffman tables for delta coding|this set]] should be used for decoding
* for each [[#num_coded_vals|num_coded_vals]]
** huffman-coded delta value to be added to the corresponding value of the master channel

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

vlc_sel = get_bits(2); /* selects a huffman table from [[#Huffman tables for delta coding|this set]] */

for (i = 0; i < [[#num_coded_vals|num_coded_vals]]; i++) {
delta = get_vlc(vlc_sel);
wl_coeffs[i] = (master_ch->wl_coeffs[i] + delta) & 7;
}

===== Mode 2 (master) =====

Coding method: [[#Vector quantization with residual encoding|Vector quantization with residual encoding]] and [[#Value grouping with "group coded" flag|Value grouping with "group coded" flag]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]].
* 1 bit: '''enable_grouping''' flag. "1" indicates that residual values were coded pairwise (in groups of two).
* 1 bit: selects one of the first two huffman tables from [[#Huffman tables for delta coding|this set]].
* 3 bits: '''start_value''' selecting a subset of "shape tables" from the trained set.
* 4 bits: '''shape_index''' selecting a "shape table" within the subset indicated by '''start_value'''.
* for each [[#num_coded_vals|num_coded_vals]]
** if '''enable_grouping''' == 1:
*** 1 bit: '''group_coded''' flag
*** if '''group_coded''' == 1:
**** 2 huffman-coded residual values to be added to the unpacked "shape table" using modular arithmetic
** if '''enable_grouping''' == 0:
*** one huffman-coded residual value to be added to the unpacked "shape table" using modular arithmetic

== Annex A: Decoding tables ==

=== Word-length related tables ===

==== Tables of weights ====

The weights below will be added to the decoded word-length coefficients. The tables are organized as follows:
* [channel_number: 0 or 1][index: 0...2][coeff_indx: 0...31]

wl_weights[2][3][32] = {
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
},
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 5, 5, 5, 5, 3, 3, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
};

==== Huffman tables for delta coding ====

PLEASE NOTE: delta values indicated in the tables below will be added using modular arithmetic as described [[#Delta coding|here]], so in the case of "wrap around" the value of "7" will be treated as "-1", the value of "6" = "-2" and so on.

* '''vlc_tab_index = 0''', delta range -1...1

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | 7
|}

* '''vlc_tab_index = 1''', delta range -2...2

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 2
|-
| align="center" | 110 || align="center" | 3 || align="center" | 6
|-
| align="center" | 111 || align="center" | 3 || align="center" | 7
|}

* '''vlc_tab_index = 2''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 5
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 3
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 4
|}

* '''vlc_tab_index = 3''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 3
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 4
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 5
|}

[[Category:Audio Codecs]]
[[Category: Multichannel Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

Oma

2018-11-29T15:27:50Z

Maxpol: Revamp OpenMG description, part 1.

* Extension: oma, aa3
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/oma/

The OpenMG Audio (further OMA) container format is used to encapsulate digital music content for use with Sony's portable players. Files ending with .omg are protected with the [[OpenMG]] [[DRM]] system.

The format is known to carry audio streams encoded with:

* [[ATRAC3]]
* [[ATRAC3plus]]
* [[ATRAC Advanced Lossless]]
* [[MP3]]
* [[PCM|Linear PCM]]
* [[WMA]] (confirmation required)

== File structure ==

A typical OMA file consists of the following three parts:
* metadata container
* extended audio header
* actual sound data

=== Metadata container ===

The metadata container carries overall music info. Except for starting with "ea3" instead of "ID3", it's fully compatible with the ID3v2 format. It uses standard ID3v2 frame types, such as TIT2, TPE1, TALB and TCON. In addition to these standard frame types, TXXX and GEOB frames contain OpenMG-specific metadata.

TXX OMG_TRACK "track number (ASCII)"
TXX OMG_AGENR "content description (ASCII)"
TXX OMG_ATPE1 "leader performer (ASCII)"
GEOB OMG_BLKSI contains a metadata structure. observed strings include:
KEYRING
EKB
SHARE_P_SID
REFID
GEOB OMG_OLINF binary blob

=== Extended audio header ===

Extended audio header contains information about the encapsulated OpenMG audio. This includes codec type, codec specific info (packet size, sample rate, channels and so on) as well as DRM related info (file encryption, content id).

=== Sound data ===

Encrypted or plain-text sound data organized in packets follows the extended audio header.

== Further reading ==

The OMA file format contains a payload scrambled with a 32-bit value [http://www.waider.ie/hacks/workshop/c/mple/FILE_FORMAT_v2.txt].

[[Category:Container Formats]]

ATRAC

2018-11-29T14:02:43Z

Maxpol: Add company name and link.

* Company: [[Sony]]
* Technical: http://www.minidisc.org/aes_atrac.html

The ATRAC codec was introduced in 1992 with the MiniDisc. Common use of the codec is in Sony made Minidisc and Flash based players.

Sony Dynamic Digital System (SDDS), used in theatres, is based on ATRAC.

ATRAC3

2018-11-29T13:57:52Z

Maxpol: Link to the original ATRAC codec page.

* Format tag: 0x270
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3/

= ATRAC3 Introduction =

ATRAC3 is the next generation of the [[ATRAC]] codec. There are three major implementations for the PC:
[[RealAudio atrc]], the Sony ATRAC3 for [[Microsoft Audio Compression Manager API|Audio Compression Manager]] (ACM) and the Sonic Stage implementation.

ATRAC3 supports several different constant bitrates ("flavors"). The following table shows the
bitrate, the size of a frame and the coding mode for each flavor respectively:

No bitrate frame size (stereo) coding mode samples per frame
-- ----------------- ------------------- ------------- -----------------
0 66 kbps (66150) 192 bytes joint stereo 1024 per channel
1 94 kpbs (93713) 272 bytes joint stereo 1024 per channel
2 105 kbps (104738) 304 bytes normal stereo 1024 per channel
3 132 kpbs (132300) 384 bytes normal stereo 1024 per channel
4 146 kbps (146081) 424 bytes normal stereo 1024 per channel
5 176 kbps (176400) 512 bytes normal stereo 1024 per channel
6 264 kbps (264600) 768 bytes normal stereo 1024 per channel
7 352 kbps (352800) 1024 bytes normal stereo 1024 per channel

== Encoding algorithm ==

* Split the input signal into 4 bands using a Quadrature mirror filter (QMF).
* Perform gain control analysis to obtain gain control data.
* Convert all four bands into frequency domain using Modified Cosine Transform (MDCT or MLT).
* Find tonal components.
* Quantization
* Encode the bitstream.

Even though this is for ATRAC2 (http://www.minidisc.org/atrac2.html) most of it applies to ATRAC3.

== Decoding algorithm ==

* Parse the bitstream and extract the following:
** gain control data
** tonal components
** quantized spectral coefficients
* inverse quantization of the tonal components and spectral coefficients
* Merge tonal components and other spectral coefficients together.
* Reconstruct the timedomain signal using inverse MDCT.
* gain compensation
* Apply the QMF synthesis filter to reconstruct the sound.

== Tonal components ==

ATRAC3 extracts the psychoacoustically important tonal components from the input signal spectra
and encodes them separate from the less important spectral data. A tone component is a group of
consecutive spectral coefficients, described with parameters such as location and with. This allows
finer quantization of such coefficients than a quantization within fixed subbands.

== Joint-stereo mode ==

ATRAC3 uses joint-stereo coding at low bitrates (66 and 94 kbps) to achieve better compression.

== Bitstream overview ==

The ATRAC3 bitstream consists of so-called "Channel Sound Units". In stereo mode there are
two such units. The structure of an unit is shown below:

--------------------------------------
| Header |
--------------------------------------
| Gain compensation data |
--------------------------------------
| Tonal components |
--------------------------------------
| Other spectral coefficients |
--------------------------------------

= Decoding Specification =

== Bitstream parsing ==

Parts is '''bold''' mean that a certain amount of bits are to be consumed from the bitstream.

===Header===

If not in the joint-stereo mode, this header should be interpreted as follows:
* '''id (6 bits)''' - should contain the value 0x28
* '''nBandsCoded (2 bits)''' - number of QMF bands were coded. The value of 0 indicates one coded band.

===Gain compensation data===

For each coded QMF band (see nBandsCoded above) the following data will be transmitted:
* '''numGainData (3 bits)''' - number of gain change points coded as level/location pairs. Value of 0 indicates no coded pairs. Each coded pair consists of the following fields:
* '''levcode (4 bits)''' - level code
* '''loccode (5 bits)''' - location code
This data is identical with the gain control tool from the MPEG AAC SSR profile that were also developed by [[Sony]]. Please refer to section "Gain compensation" below for a description how to interpret this data.

===Tonal components===

The presence of tonal components is indicated by the following field:
* '''numToneComp (5 bits)''' - Number of coded tonal components. The value of 0 indicates no coded tonal components.
* '''coding_mode_selector(2 bits)''' -- If this is equal to 2, return error. If this is equal to 3 then every component has it's own bit to select the coefficients coding mode. (VLC/CLC). If this is equal to 1 then all the components are CLC coded. If this is 0 all components are VLC coded. (coding_mode)

* For each tonal component
** For each number of bands, get band flags
*** '''band_flags (1 bit)''' -- Flag per band in the Tonal Component to be processed
** '''coded_values (3 bits)''' -- amount of coded coefficients
** '''quant_step_index (3 bits)''' -- index into the quant step table, if it is less then/equal to 1 then return error
** if coding_mode_selector is 3
*** '''coding_mode (1 bit)''' -- get the bands coding mode (CLC/VLC)

===Other spectral coefficients===

The coefficients coded in this block are assumed not to be "tonal" (noise etc.) They are quantized and coded within fixed subbands. The ATRAC3 divides the whole MDCT spectrum (1024 points) into 32 subbands of unequal width (higher frequencies - wider bands). For each subband ATRAC3 will transmit a scalefactor index and VLC codes for each quantized spectral coefficients. The format of this this block is shown below:
* '''numSubbands (5 bits)''' - number of coded subbands. The value of 0 indicates no coded subbands.
* '''codingMode (1 bit)''' - value indicates the coding mode for ALL subbands:

0 - coefficients are coded using variable length codes (VLC)
1 - coefficients are coded using constant length codes (CLC)

Then follow the array of coding table indexes for each coded band:
* '''tblIndex (3 bits)''' - indicates the coding table used (VLC) or number of bits used (CLC). The value of "0" indicates "skipped" (not coded) subband.
Then follows the array of scalefactor indexes for each coded subband:
* '''sfIndex (6 bits)''' - indicates the index into scalefactor decoding table (see below).
Then follows the codes for each spectral coefficient in this subband. The VLC codes are shown below.

== Transforms ==

=== QMF ===

Three stacked [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filters] are used to split the signal into 4 different frequency bands.

* 0 to 2.75625 kHz (DC to ''f''/16)
* 2.75625 to 5.5125 kHz (''f''/16 to ''f''/8)
* 5.5125 to 11.025 kHz (''f''/8 to ''f''/4)
* 11.025 to 22.05 kHz (''f''/4 to ''f''/2)

==== QMF window ====

The coeffs used in the QMF filter.

float qmf_48tap_half[24] = {
-0.00001461907, -0.00009205479, -0.000056157569, 0.00030117269,
0.0002422519,-0.00085293897, -0.0005205574, 0.0020340169,
0.00078333891, -0.0042153862, -0.00075614988, 0.0078402944,
-0.000061169922, -0.01344162, 0.0024626821, 0.021736089,
-0.007801671, -0.034090221, 0.01880949, 0.054326009,
-0.043596379, -0.099384367, 0.13207909, 0.46424159
};

These coeffs need to be mirrored and scaled by 2.

for (i=0 ; i<24; i++) {
s = qmf_48tap_half[i] * 2.0;
qmf_window[i] = s;
qmf_window[47 - i] = s;
}

=== MLT ===

The transform is a regular MDCT.

==== Windows ====

The overlapping window is not the same for encoding and decoding. Perfect reconstruction is ensured by the encoding and decoding windows having a inverse relation. Technical details can be found in H. Malvar's paper Fast algorithms for orthogonal modulated lapped transforms [http://research.microsoft.com/~malvar/papers/dfsp98.pdf]

====== Encoding ======

for (i = 0; i < 256; i++) {
we[i] = (sin(((i + 0.5) / 256 - 0.5) * PI) + 1.0) * 0.5;
}

====== Decoding ======

for (i = 0; i < 256; i++) {
wd[i] = we[i]/(we[i]^2 + we[255-i]^2)
}

== Huffman coding ==

VLC coding is used to compress the tonal and spectral coefficients.

=== Huffman tables ===

huffcode1[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits1[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode2[5] = {
0x0,0x4,0x5,0x6,0x7,
};

huffbits2[5] = {
1,3,3,3,3,
};

huffcode3[7] = {
0x0,0x4,0x5,0xC,0xD,0xE,0xF,
};

huffbits3[7] = {
1,3,3,4,4,4,4,
};

huffcode4[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits4[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode5[15] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0x1C,0x1D,0x3C,0x3D,0x3E,0x3F,
};

huffbits5[15] = {
2,3,3,4,4,4,4,4,4,5,5,6,6,6,6,
};

huffcode6[31] = {
0x0,0x2,0x3,0x4,0x5,0x6,0x7,0x8,0x9,0x14,0x15,0x16,0x17,0x18,0x19,0x34,0x35,
0x36,0x37,0x38,0x39,0x3A,0x3B,0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
};

huffbits6[31] = {
3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,7,7,
};

huffcode7[63] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0xE,0xF,0x10,0x11,0x24,0x25,0x26,0x27,0x28,
0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x68,0x69,0x6A,0x6B,0x6C,
0x6D,0x6E,0x6F,0x70,0x71,0x72,0x73,0x74,0x75,0xEC,0xED,0xEE,0xEF,0xF0,0xF1,0xF2,
0xF3,0xF4,0xF5,0xF6,0xF7,0xF8,0xF9,0xFA,0xFB,0xFC,0xFD,0xFE,0xFF,
};

huffbits7[63] = {
3,4,4,5,5,5,5,5,5,5,5,5,5,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,7,7,7,7,7,
7,7,7,7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,
};

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

Sony ATRAC

2018-11-29T13:56:33Z

Maxpol: Better formatting + developer's interview.

* Product overview: http://www.sony.net/Products/ATRAC3/overview/index.html#family
* Developer's interview: https://www.sony.net/Products/ATRAC3/special/developers01.html

ATRAC ('''A'''daptive '''TR'''ansform '''A'''coustic '''C'''oding) is the collective name for audio compression technologies
developed by [[Sony]].

This codec family includes the following codecs today:

* [[ATRAC]]
* [[ATRAC3]]
* [[ATRAC3plus]]
* ATRAC Advanced Lossless (AAL)

ATRAC-compressed audio is usually stored in [[Microsoft_Wave|WAV]]/[[Microsoft_Audio/Video_Interleaved|AVI]], [[RealMedia|RM]] and [[Oma|Oma/Omg]] containers.

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]
[[Category: Lossless Audio Codecs]]

Sony ATRAC

2018-11-29T13:51:45Z

Maxpol: Revamp ATRAC family description.

ATRAC (Adaptive TRansform Acoustic Coding) is the collective name for audio compression technologies
developed by [[Sony]].

This codec family includes the following codecs today:

* [[ATRAC]]
* [[ATRAC3]]
* [[ATRAC3plus]]
* ATRAC Advanced Lossless (AAL)

An overview of this product family can be found here: http://www.sony.net/Products/ATRAC3/overview/index.html#family

ATRAC-compressed audio is usually stored in [[Microsoft_Wave|WAV]]/[[Microsoft_Audio/Video_Interleaved|AVI]], [[RealMedia|RM]] and [[Oma|Oma/Omg]] containers.

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]
[[Category: Lossless Audio Codecs]]

ATRAC

2018-11-29T13:51:27Z

Maxpol: Create a basic page for the old famous ATRAC codec.

* Technical: http://www.minidisc.org/aes_atrac.html

The ATRAC codec was introduced in 1992 with the MiniDisc. Common use of the codec is in Sony made Minidisc and Flash based players.

Sony Dynamic Digital System (SDDS), used in theatres, is based on ATRAC.

ATRAC3

2018-11-29T13:43:26Z

Maxpol: Move format tag and samples to the right place.

* Format tag: 0x270
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3/

= ATRAC3 Introduction =

ATRAC3 is the next generation of the ATRAC codec. There are three major implementations for the PC:
[[RealAudio atrc]], the Sony ATRAC3 for [[Microsoft Audio Compression Manager API|Audio Compression Manager]] (ACM) and the Sonic Stage implementation.

ATRAC3 supports several different constant bitrates ("flavors"). The following table shows the
bitrate, the size of a frame and the coding mode for each flavor respectively:

No bitrate frame size (stereo) coding mode samples per frame
-- ----------------- ------------------- ------------- -----------------
0 66 kbps (66150) 192 bytes joint stereo 1024 per channel
1 94 kpbs (93713) 272 bytes joint stereo 1024 per channel
2 105 kbps (104738) 304 bytes normal stereo 1024 per channel
3 132 kpbs (132300) 384 bytes normal stereo 1024 per channel
4 146 kbps (146081) 424 bytes normal stereo 1024 per channel
5 176 kbps (176400) 512 bytes normal stereo 1024 per channel
6 264 kbps (264600) 768 bytes normal stereo 1024 per channel
7 352 kbps (352800) 1024 bytes normal stereo 1024 per channel

== Encoding algorithm ==

* Split the input signal into 4 bands using a Quadrature mirror filter (QMF).
* Perform gain control analysis to obtain gain control data.
* Convert all four bands into frequency domain using Modified Cosine Transform (MDCT or MLT).
* Find tonal components.
* Quantization
* Encode the bitstream.

Even though this is for ATRAC2 (http://www.minidisc.org/atrac2.html) most of it applies to ATRAC3.

== Decoding algorithm ==

* Parse the bitstream and extract the following:
** gain control data
** tonal components
** quantized spectral coefficients
* inverse quantization of the tonal components and spectral coefficients
* Merge tonal components and other spectral coefficients together.
* Reconstruct the timedomain signal using inverse MDCT.
* gain compensation
* Apply the QMF synthesis filter to reconstruct the sound.

== Tonal components ==

ATRAC3 extracts the psychoacoustically important tonal components from the input signal spectra
and encodes them separate from the less important spectral data. A tone component is a group of
consecutive spectral coefficients, described with parameters such as location and with. This allows
finer quantization of such coefficients than a quantization within fixed subbands.

== Joint-stereo mode ==

ATRAC3 uses joint-stereo coding at low bitrates (66 and 94 kbps) to achieve better compression.

== Bitstream overview ==

The ATRAC3 bitstream consists of so-called "Channel Sound Units". In stereo mode there are
two such units. The structure of an unit is shown below:

--------------------------------------
| Header |
--------------------------------------
| Gain compensation data |
--------------------------------------
| Tonal components |
--------------------------------------
| Other spectral coefficients |
--------------------------------------

= Decoding Specification =

== Bitstream parsing ==

Parts is '''bold''' mean that a certain amount of bits are to be consumed from the bitstream.

===Header===

If not in the joint-stereo mode, this header should be interpreted as follows:
* '''id (6 bits)''' - should contain the value 0x28
* '''nBandsCoded (2 bits)''' - number of QMF bands were coded. The value of 0 indicates one coded band.

===Gain compensation data===

For each coded QMF band (see nBandsCoded above) the following data will be transmitted:
* '''numGainData (3 bits)''' - number of gain change points coded as level/location pairs. Value of 0 indicates no coded pairs. Each coded pair consists of the following fields:
* '''levcode (4 bits)''' - level code
* '''loccode (5 bits)''' - location code
This data is identical with the gain control tool from the MPEG AAC SSR profile that were also developed by [[Sony]]. Please refer to section "Gain compensation" below for a description how to interpret this data.

===Tonal components===

The presence of tonal components is indicated by the following field:
* '''numToneComp (5 bits)''' - Number of coded tonal components. The value of 0 indicates no coded tonal components.
* '''coding_mode_selector(2 bits)''' -- If this is equal to 2, return error. If this is equal to 3 then every component has it's own bit to select the coefficients coding mode. (VLC/CLC). If this is equal to 1 then all the components are CLC coded. If this is 0 all components are VLC coded. (coding_mode)

* For each tonal component
** For each number of bands, get band flags
*** '''band_flags (1 bit)''' -- Flag per band in the Tonal Component to be processed
** '''coded_values (3 bits)''' -- amount of coded coefficients
** '''quant_step_index (3 bits)''' -- index into the quant step table, if it is less then/equal to 1 then return error
** if coding_mode_selector is 3
*** '''coding_mode (1 bit)''' -- get the bands coding mode (CLC/VLC)

===Other spectral coefficients===

The coefficients coded in this block are assumed not to be "tonal" (noise etc.) They are quantized and coded within fixed subbands. The ATRAC3 divides the whole MDCT spectrum (1024 points) into 32 subbands of unequal width (higher frequencies - wider bands). For each subband ATRAC3 will transmit a scalefactor index and VLC codes for each quantized spectral coefficients. The format of this this block is shown below:
* '''numSubbands (5 bits)''' - number of coded subbands. The value of 0 indicates no coded subbands.
* '''codingMode (1 bit)''' - value indicates the coding mode for ALL subbands:

0 - coefficients are coded using variable length codes (VLC)
1 - coefficients are coded using constant length codes (CLC)

Then follow the array of coding table indexes for each coded band:
* '''tblIndex (3 bits)''' - indicates the coding table used (VLC) or number of bits used (CLC). The value of "0" indicates "skipped" (not coded) subband.
Then follows the array of scalefactor indexes for each coded subband:
* '''sfIndex (6 bits)''' - indicates the index into scalefactor decoding table (see below).
Then follows the codes for each spectral coefficient in this subband. The VLC codes are shown below.

== Transforms ==

=== QMF ===

Three stacked [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filters] are used to split the signal into 4 different frequency bands.

* 0 to 2.75625 kHz (DC to ''f''/16)
* 2.75625 to 5.5125 kHz (''f''/16 to ''f''/8)
* 5.5125 to 11.025 kHz (''f''/8 to ''f''/4)
* 11.025 to 22.05 kHz (''f''/4 to ''f''/2)

==== QMF window ====

The coeffs used in the QMF filter.

float qmf_48tap_half[24] = {
-0.00001461907, -0.00009205479, -0.000056157569, 0.00030117269,
0.0002422519,-0.00085293897, -0.0005205574, 0.0020340169,
0.00078333891, -0.0042153862, -0.00075614988, 0.0078402944,
-0.000061169922, -0.01344162, 0.0024626821, 0.021736089,
-0.007801671, -0.034090221, 0.01880949, 0.054326009,
-0.043596379, -0.099384367, 0.13207909, 0.46424159
};

These coeffs need to be mirrored and scaled by 2.

for (i=0 ; i<24; i++) {
s = qmf_48tap_half[i] * 2.0;
qmf_window[i] = s;
qmf_window[47 - i] = s;
}

=== MLT ===

The transform is a regular MDCT.

==== Windows ====

The overlapping window is not the same for encoding and decoding. Perfect reconstruction is ensured by the encoding and decoding windows having a inverse relation. Technical details can be found in H. Malvar's paper Fast algorithms for orthogonal modulated lapped transforms [http://research.microsoft.com/~malvar/papers/dfsp98.pdf]

====== Encoding ======

for (i = 0; i < 256; i++) {
we[i] = (sin(((i + 0.5) / 256 - 0.5) * PI) + 1.0) * 0.5;
}

====== Decoding ======

for (i = 0; i < 256; i++) {
wd[i] = we[i]/(we[i]^2 + we[255-i]^2)
}

== Huffman coding ==

VLC coding is used to compress the tonal and spectral coefficients.

=== Huffman tables ===

huffcode1[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits1[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode2[5] = {
0x0,0x4,0x5,0x6,0x7,
};

huffbits2[5] = {
1,3,3,3,3,
};

huffcode3[7] = {
0x0,0x4,0x5,0xC,0xD,0xE,0xF,
};

huffbits3[7] = {
1,3,3,4,4,4,4,
};

huffcode4[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits4[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode5[15] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0x1C,0x1D,0x3C,0x3D,0x3E,0x3F,
};

huffbits5[15] = {
2,3,3,4,4,4,4,4,4,5,5,6,6,6,6,
};

huffcode6[31] = {
0x0,0x2,0x3,0x4,0x5,0x6,0x7,0x8,0x9,0x14,0x15,0x16,0x17,0x18,0x19,0x34,0x35,
0x36,0x37,0x38,0x39,0x3A,0x3B,0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
};

huffbits6[31] = {
3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,7,7,
};

huffcode7[63] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0xE,0xF,0x10,0x11,0x24,0x25,0x26,0x27,0x28,
0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x68,0x69,0x6A,0x6B,0x6C,
0x6D,0x6E,0x6F,0x70,0x71,0x72,0x73,0x74,0x75,0xEC,0xED,0xEE,0xEF,0xF0,0xF1,0xF2,
0xF3,0xF4,0xF5,0xF6,0xF7,0xF8,0xF9,0xFA,0xFB,0xFC,0xFD,0xFE,0xFF,
};

huffbits7[63] = {
3,4,4,5,5,5,5,5,5,5,5,5,5,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,7,7,7,7,7,
7,7,7,7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,
};

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

RealAudio atrc

2018-11-29T13:40:50Z

Maxpol: Add Sony to the list of companies.

* FOURCC: atrc
* Company: [[Sony]], [[Real]]
* Samples: http://samples.mplayerhq.hu/real/AC-atrc/

Found in some old [[RealMedia]] files. The same as the [[ATRAC3]].

== Scrambling ==

In [[RealMedia]] files, the ATRAC3 bitstream is scrambled. To unscramble the stream, perform a XOR on every 32 bits in the frame. The hex value to XOR with is 0x537F6103.

== Extra data format ==

In [[RealMedia]] files, ATRAC3 extra data has the following format (big-endian order):

INT32 id, always 4
INT16 samples per frame, always 1024 * 2
INT16 delay, not used but always 0x88E
INT16 stereo coding mode, 2 - normal stereo, 0x12 - joint stereo

The length of this data is always 10 bytes.

Oma

2018-11-29T13:37:19Z

Maxpol: Repair ATRAC3 link.

* Extension: oma, aa3
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/oma/

Container format used to encapsulate [[ATRAC3]] and [[ATRAC3plus]] for use with Sony's portable players. Files ending with .omg are protected with the [[OpenMG]] [[DRM]] system.

The OMA file format contains a payload scrambled with a 32-bit value [http://www.waider.ie/hacks/workshop/c/mple/FILE_FORMAT_v2.txt]. The format is known to carry MP3 and ATRAC3 audio. The metadata format is a variant of ID3v2 and uses standard ID3v2 frame types, such as TIT2, TPE1, TALB and TCON. In addition to these standard frame types, TXXX and GEOB frames contain OpenMG-specific metadata.

TXX OMG_TRACK "track number (ASCII)"
TXX OMG_AGENR "content description (ASCII)"
TXX OMG_ATPE1 "leader performer (ASCII)"
GEOB OMG_BLKSI contains a metadata structure. observed strings include:
KEYRING
EKB
SHARE_P_SID
REFID
GEOB OMG_OLINF binary blob

[[Category:Container Formats]]

RealMedia

2018-11-29T13:36:32Z

Maxpol: RealAudio atrc ==> ATRAC3

* Extensions: rm, ra, rmvb
* Company: [[Real]]
* Specifications: https://common.helixcommunity.org/2003/HCS_SDK_r5/htmfiles/rmff.htm

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by [[Real]].

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A [[FourCC]] (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no [[FourCC]], it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid [[FourCC]] to identify the audio codec.

Possible [[FourCC]] values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

==== Audio (audio/) ====

===== audio/x-pn-realaudio and audio/x-pn-multirate-realaudio =====
These mimetypes are used to specify streams with RealAudio codecs. There are 3 known versions of this datablock: ra3, ra4, ra5. ra3 is used only with the old 14_4 codec, ra4 and ra5 can be used with all the other codecs.

The audio block has this format

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (3, 4 or 5)
#if version == 3
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
#elseif version == 4 or version == 5
word Unused (always 0)
byte[4] ra signature (".ra4" or ".ra5", depending on version)
dword Unknown (maybe data size)
word Version2 (always equal to version)
dword Header size
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
#if version == 5
byte[6] Unknown
#endif
word Samplerate
word Unknown
word Sample size
word Channels
#if version == 4
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
#endif
#if version == 5
dword Interleaver ID
dword [[FourCC]]
#endif
byte[3] Unknown
#if version == 5
byte Unknown
#endif
dword Codec extradata length
byte[] Codec extradata
#endif

===== audio/X-MP3-draft-00 =====
This is used to store MP3 audio in rm container.
When this mimetype is used the type-specific part of the MDPR header is not used, and its length is set to 0.

The MP3 frames are stored in ADU format (see RFC 3119 for details) with no interleaving (at least this is true in the only known sample).

===== audio/x-ralf-mpeg4 =====
This is used to store [[Real Lossless Codec|ralf]] lossless audio. This is the only known RealAudio codec that does not use the x-pn-realaudio mimetype.

The format of this type-specific data is not known.

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp (in ms)
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official [[Real]] docs (somewhere on [[Helix]] site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC3
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[ClearVideo|CLV1]] - ClearVideo (from helix spec)
* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - H.264 precursor
* [[RealVideo 4|RV40]] - H.264 precursor
* [[BeHere_iVideo|RVTR]] - H.263+ (RV20)
* [[BeHere_iVideo|RVT2]] - RV30 ? (from helix spec hxmtypes.h)

[[Category: Container Formats]]

RealAudio atrc

2018-11-29T13:31:13Z

Maxpol: Minor spelling improvements.

* FOURCC: atrc
* Company: [[Real]]
* Samples: http://samples.mplayerhq.hu/real/AC-atrc/

Found in some old [[RealMedia]] files. The same as the [[ATRAC3]].

== Scrambling ==

In [[RealMedia]] files, the ATRAC3 bitstream is scrambled. To unscramble the stream, perform a XOR on every 32 bits in the frame. The hex value to XOR with is 0x537F6103.

== Extra data format ==

In [[RealMedia]] files, ATRAC3 extra data has the following format (big-endian order):

INT32 id, always 4
INT16 samples per frame, always 1024 * 2
INT16 delay, not used but always 0x88E
INT16 stereo coding mode, 2 - normal stereo, 0x12 - joint stereo

The length of this data is always 10 bytes.

ATRAC3

2018-11-29T13:29:41Z

Maxpol: Repair RealAudio atrc link.

= ATRAC3 Introduction =

ATRAC3 is the next generation of the ATRAC codec. There are three major implementations for the PC:
[[RealAudio atrc]], the Sony ATRAC3 for [[Microsoft Audio Compression Manager API|Audio Compression Manager]] (ACM) and the Sonic Stage implementation.

ATRAC3 supports several different constant bitrates ("flavors"). The following table shows the
bitrate, the size of a frame and the coding mode for each flavor respectively:

No bitrate frame size (stereo) coding mode samples per frame
-- ----------------- ------------------- ------------- -----------------
0 66 kbps (66150) 192 bytes joint stereo 1024 per channel
1 94 kpbs (93713) 272 bytes joint stereo 1024 per channel
2 105 kbps (104738) 304 bytes normal stereo 1024 per channel
3 132 kpbs (132300) 384 bytes normal stereo 1024 per channel
4 146 kbps (146081) 424 bytes normal stereo 1024 per channel
5 176 kbps (176400) 512 bytes normal stereo 1024 per channel
6 264 kbps (264600) 768 bytes normal stereo 1024 per channel
7 352 kbps (352800) 1024 bytes normal stereo 1024 per channel

== Encoding algorithm ==

* Split the input signal into 4 bands using a Quadrature mirror filter (QMF).
* Perform gain control analysis to obtain gain control data.
* Convert all four bands into frequency domain using Modified Cosine Transform (MDCT or MLT).
* Find tonal components.
* Quantization
* Encode the bitstream.

Even though this is for ATRAC2 (http://www.minidisc.org/atrac2.html) most of it applies to ATRAC3.

== Decoding algorithm ==

* Parse the bitstream and extract the following:
** gain control data
** tonal components
** quantized spectral coefficients
* inverse quantization of the tonal components and spectral coefficients
* Merge tonal components and other spectral coefficients together.
* Reconstruct the timedomain signal using inverse MDCT.
* gain compensation
* Apply the QMF synthesis filter to reconstruct the sound.

== Tonal components ==

ATRAC3 extracts the psychoacoustically important tonal components from the input signal spectra
and encodes them separate from the less important spectral data. A tone component is a group of
consecutive spectral coefficients, described with parameters such as location and with. This allows
finer quantization of such coefficients than a quantization within fixed subbands.

== Joint-stereo mode ==

ATRAC3 uses joint-stereo coding at low bitrates (66 and 94 kbps) to achieve better compression.

== Bitstream overview ==

The ATRAC3 bitstream consists of so-called "Channel Sound Units". In stereo mode there are
two such units. The structure of an unit is shown below:

--------------------------------------
| Header |
--------------------------------------
| Gain compensation data |
--------------------------------------
| Tonal components |
--------------------------------------
| Other spectral coefficients |
--------------------------------------

= Decoding Specification =

== Bitstream parsing ==

Parts is '''bold''' mean that a certain amount of bits are to be consumed from the bitstream.

===Header===

If not in the joint-stereo mode, this header should be interpreted as follows:
* '''id (6 bits)''' - should contain the value 0x28
* '''nBandsCoded (2 bits)''' - number of QMF bands were coded. The value of 0 indicates one coded band.

===Gain compensation data===

For each coded QMF band (see nBandsCoded above) the following data will be transmitted:
* '''numGainData (3 bits)''' - number of gain change points coded as level/location pairs. Value of 0 indicates no coded pairs. Each coded pair consists of the following fields:
* '''levcode (4 bits)''' - level code
* '''loccode (5 bits)''' - location code
This data is identical with the gain control tool from the MPEG AAC SSR profile that were also developed by [[Sony]]. Please refer to section "Gain compensation" below for a description how to interpret this data.

===Tonal components===

The presence of tonal components is indicated by the following field:
* '''numToneComp (5 bits)''' - Number of coded tonal components. The value of 0 indicates no coded tonal components.
* '''coding_mode_selector(2 bits)''' -- If this is equal to 2, return error. If this is equal to 3 then every component has it's own bit to select the coefficients coding mode. (VLC/CLC). If this is equal to 1 then all the components are CLC coded. If this is 0 all components are VLC coded. (coding_mode)

* For each tonal component
** For each number of bands, get band flags
*** '''band_flags (1 bit)''' -- Flag per band in the Tonal Component to be processed
** '''coded_values (3 bits)''' -- amount of coded coefficients
** '''quant_step_index (3 bits)''' -- index into the quant step table, if it is less then/equal to 1 then return error
** if coding_mode_selector is 3
*** '''coding_mode (1 bit)''' -- get the bands coding mode (CLC/VLC)

===Other spectral coefficients===

The coefficients coded in this block are assumed not to be "tonal" (noise etc.) They are quantized and coded within fixed subbands. The ATRAC3 divides the whole MDCT spectrum (1024 points) into 32 subbands of unequal width (higher frequencies - wider bands). For each subband ATRAC3 will transmit a scalefactor index and VLC codes for each quantized spectral coefficients. The format of this this block is shown below:
* '''numSubbands (5 bits)''' - number of coded subbands. The value of 0 indicates no coded subbands.
* '''codingMode (1 bit)''' - value indicates the coding mode for ALL subbands:

0 - coefficients are coded using variable length codes (VLC)
1 - coefficients are coded using constant length codes (CLC)

Then follow the array of coding table indexes for each coded band:
* '''tblIndex (3 bits)''' - indicates the coding table used (VLC) or number of bits used (CLC). The value of "0" indicates "skipped" (not coded) subband.
Then follows the array of scalefactor indexes for each coded subband:
* '''sfIndex (6 bits)''' - indicates the index into scalefactor decoding table (see below).
Then follows the codes for each spectral coefficient in this subband. The VLC codes are shown below.

== Transforms ==

=== QMF ===

Three stacked [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filters] are used to split the signal into 4 different frequency bands.

* 0 to 2.75625 kHz (DC to ''f''/16)
* 2.75625 to 5.5125 kHz (''f''/16 to ''f''/8)
* 5.5125 to 11.025 kHz (''f''/8 to ''f''/4)
* 11.025 to 22.05 kHz (''f''/4 to ''f''/2)

==== QMF window ====

The coeffs used in the QMF filter.

float qmf_48tap_half[24] = {
-0.00001461907, -0.00009205479, -0.000056157569, 0.00030117269,
0.0002422519,-0.00085293897, -0.0005205574, 0.0020340169,
0.00078333891, -0.0042153862, -0.00075614988, 0.0078402944,
-0.000061169922, -0.01344162, 0.0024626821, 0.021736089,
-0.007801671, -0.034090221, 0.01880949, 0.054326009,
-0.043596379, -0.099384367, 0.13207909, 0.46424159
};

These coeffs need to be mirrored and scaled by 2.

for (i=0 ; i<24; i++) {
s = qmf_48tap_half[i] * 2.0;
qmf_window[i] = s;
qmf_window[47 - i] = s;
}

=== MLT ===

The transform is a regular MDCT.

==== Windows ====

The overlapping window is not the same for encoding and decoding. Perfect reconstruction is ensured by the encoding and decoding windows having a inverse relation. Technical details can be found in H. Malvar's paper Fast algorithms for orthogonal modulated lapped transforms [http://research.microsoft.com/~malvar/papers/dfsp98.pdf]

====== Encoding ======

for (i = 0; i < 256; i++) {
we[i] = (sin(((i + 0.5) / 256 - 0.5) * PI) + 1.0) * 0.5;
}

====== Decoding ======

for (i = 0; i < 256; i++) {
wd[i] = we[i]/(we[i]^2 + we[255-i]^2)
}

== Huffman coding ==

VLC coding is used to compress the tonal and spectral coefficients.

=== Huffman tables ===

huffcode1[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits1[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode2[5] = {
0x0,0x4,0x5,0x6,0x7,
};

huffbits2[5] = {
1,3,3,3,3,
};

huffcode3[7] = {
0x0,0x4,0x5,0xC,0xD,0xE,0xF,
};

huffbits3[7] = {
1,3,3,4,4,4,4,
};

huffcode4[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits4[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode5[15] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0x1C,0x1D,0x3C,0x3D,0x3E,0x3F,
};

huffbits5[15] = {
2,3,3,4,4,4,4,4,4,5,5,6,6,6,6,
};

huffcode6[31] = {
0x0,0x2,0x3,0x4,0x5,0x6,0x7,0x8,0x9,0x14,0x15,0x16,0x17,0x18,0x19,0x34,0x35,
0x36,0x37,0x38,0x39,0x3A,0x3B,0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
};

huffbits6[31] = {
3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,7,7,
};

huffcode7[63] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0xE,0xF,0x10,0x11,0x24,0x25,0x26,0x27,0x28,
0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x68,0x69,0x6A,0x6B,0x6C,
0x6D,0x6E,0x6F,0x70,0x71,0x72,0x73,0x74,0x75,0xEC,0xED,0xEE,0xEF,0xF0,0xF1,0xF2,
0xF3,0xF4,0xF5,0xF6,0xF7,0xF8,0xF9,0xFA,0xFB,0xFC,0xFD,0xFE,0xFF,
};

huffbits7[63] = {
3,4,4,5,5,5,5,5,5,5,5,5,5,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,7,7,7,7,7,
7,7,7,7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,
};

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

RealAudio atrc

2018-11-29T13:27:33Z

Maxpol: Create its own page for RealMedia clone of Sony ATRAC3.

* FOURCC: atrc
* Company: [[Real]]
* Samples: http://samples.mplayerhq.hu/real/AC-atrc/

Found in some old [[RealMedia]] files. The same as the [[ATRAC3]].

== Scrambling ==

In [[RealMedia]] files the bitstream is scrambled. To unscramble the stream, perform a XOR on every 32 bits in the frame. The hex value to XOR with is 0x537F6103.

== Extra data format ==

In [[RealMedia]] files the extra data is as follows (big-endian order):

INT32 id, always 4
INT16 samples per frame, always 1024 * 2
INT16 delay, not used but always 0x88E
INT16 stereo coding mode, 2 - normal stereo, 0x12 - joint stereo

The length of this data is always 10 bytes.

ATRAC3

2018-11-29T13:26:35Z

Maxpol: Move out RealMedia atrc related stuff to its own page.

= ATRAC3 Introduction =

ATRAC3 is the next generation of the ATRAC codec. There are three major implementations for the PC:
RealAudio8 atrc, the Sony ATRAC3 for [[Microsoft Audio Compression Manager API|Audio Compression Manager]] (ACM) and the Sonic Stage implementation.

ATRAC3 supports several different constant bitrates ("flavors"). The following table shows the
bitrate, the size of a frame and the coding mode for each flavor respectively:

No bitrate frame size (stereo) coding mode samples per frame
-- ----------------- ------------------- ------------- -----------------
0 66 kbps (66150) 192 bytes joint stereo 1024 per channel
1 94 kpbs (93713) 272 bytes joint stereo 1024 per channel
2 105 kbps (104738) 304 bytes normal stereo 1024 per channel
3 132 kpbs (132300) 384 bytes normal stereo 1024 per channel
4 146 kbps (146081) 424 bytes normal stereo 1024 per channel
5 176 kbps (176400) 512 bytes normal stereo 1024 per channel
6 264 kbps (264600) 768 bytes normal stereo 1024 per channel
7 352 kbps (352800) 1024 bytes normal stereo 1024 per channel

== Encoding algorithm ==

* Split the input signal into 4 bands using a Quadrature mirror filter (QMF).
* Perform gain control analysis to obtain gain control data.
* Convert all four bands into frequency domain using Modified Cosine Transform (MDCT or MLT).
* Find tonal components.
* Quantization
* Encode the bitstream.

Even though this is for ATRAC2 (http://www.minidisc.org/atrac2.html) most of it applies to ATRAC3.

== Decoding algorithm ==

* Parse the bitstream and extract the following:
** gain control data
** tonal components
** quantized spectral coefficients
* inverse quantization of the tonal components and spectral coefficients
* Merge tonal components and other spectral coefficients together.
* Reconstruct the timedomain signal using inverse MDCT.
* gain compensation
* Apply the QMF synthesis filter to reconstruct the sound.

== Tonal components ==

ATRAC3 extracts the psychoacoustically important tonal components from the input signal spectra
and encodes them separate from the less important spectral data. A tone component is a group of
consecutive spectral coefficients, described with parameters such as location and with. This allows
finer quantization of such coefficients than a quantization within fixed subbands.

== Joint-stereo mode ==

ATRAC3 uses joint-stereo coding at low bitrates (66 and 94 kbps) to achieve better compression.

== Bitstream overview ==

The ATRAC3 bitstream consists of so-called "Channel Sound Units". In stereo mode there are
two such units. The structure of an unit is shown below:

--------------------------------------
| Header |
--------------------------------------
| Gain compensation data |
--------------------------------------
| Tonal components |
--------------------------------------
| Other spectral coefficients |
--------------------------------------

= Decoding Specification =

== Bitstream parsing ==

Parts is '''bold''' mean that a certain amount of bits are to be consumed from the bitstream.

===Header===

If not in the joint-stereo mode, this header should be interpreted as follows:
* '''id (6 bits)''' - should contain the value 0x28
* '''nBandsCoded (2 bits)''' - number of QMF bands were coded. The value of 0 indicates one coded band.

===Gain compensation data===

For each coded QMF band (see nBandsCoded above) the following data will be transmitted:
* '''numGainData (3 bits)''' - number of gain change points coded as level/location pairs. Value of 0 indicates no coded pairs. Each coded pair consists of the following fields:
* '''levcode (4 bits)''' - level code
* '''loccode (5 bits)''' - location code
This data is identical with the gain control tool from the MPEG AAC SSR profile that were also developed by [[Sony]]. Please refer to section "Gain compensation" below for a description how to interpret this data.

===Tonal components===

The presence of tonal components is indicated by the following field:
* '''numToneComp (5 bits)''' - Number of coded tonal components. The value of 0 indicates no coded tonal components.
* '''coding_mode_selector(2 bits)''' -- If this is equal to 2, return error. If this is equal to 3 then every component has it's own bit to select the coefficients coding mode. (VLC/CLC). If this is equal to 1 then all the components are CLC coded. If this is 0 all components are VLC coded. (coding_mode)

* For each tonal component
** For each number of bands, get band flags
*** '''band_flags (1 bit)''' -- Flag per band in the Tonal Component to be processed
** '''coded_values (3 bits)''' -- amount of coded coefficients
** '''quant_step_index (3 bits)''' -- index into the quant step table, if it is less then/equal to 1 then return error
** if coding_mode_selector is 3
*** '''coding_mode (1 bit)''' -- get the bands coding mode (CLC/VLC)

===Other spectral coefficients===

The coefficients coded in this block are assumed not to be "tonal" (noise etc.) They are quantized and coded within fixed subbands. The ATRAC3 divides the whole MDCT spectrum (1024 points) into 32 subbands of unequal width (higher frequencies - wider bands). For each subband ATRAC3 will transmit a scalefactor index and VLC codes for each quantized spectral coefficients. The format of this this block is shown below:
* '''numSubbands (5 bits)''' - number of coded subbands. The value of 0 indicates no coded subbands.
* '''codingMode (1 bit)''' - value indicates the coding mode for ALL subbands:

0 - coefficients are coded using variable length codes (VLC)
1 - coefficients are coded using constant length codes (CLC)

Then follow the array of coding table indexes for each coded band:
* '''tblIndex (3 bits)''' - indicates the coding table used (VLC) or number of bits used (CLC). The value of "0" indicates "skipped" (not coded) subband.
Then follows the array of scalefactor indexes for each coded subband:
* '''sfIndex (6 bits)''' - indicates the index into scalefactor decoding table (see below).
Then follows the codes for each spectral coefficient in this subband. The VLC codes are shown below.

== Transforms ==

=== QMF ===

Three stacked [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filters] are used to split the signal into 4 different frequency bands.

* 0 to 2.75625 kHz (DC to ''f''/16)
* 2.75625 to 5.5125 kHz (''f''/16 to ''f''/8)
* 5.5125 to 11.025 kHz (''f''/8 to ''f''/4)
* 11.025 to 22.05 kHz (''f''/4 to ''f''/2)

==== QMF window ====

The coeffs used in the QMF filter.

float qmf_48tap_half[24] = {
-0.00001461907, -0.00009205479, -0.000056157569, 0.00030117269,
0.0002422519,-0.00085293897, -0.0005205574, 0.0020340169,
0.00078333891, -0.0042153862, -0.00075614988, 0.0078402944,
-0.000061169922, -0.01344162, 0.0024626821, 0.021736089,
-0.007801671, -0.034090221, 0.01880949, 0.054326009,
-0.043596379, -0.099384367, 0.13207909, 0.46424159
};

These coeffs need to be mirrored and scaled by 2.

for (i=0 ; i<24; i++) {
s = qmf_48tap_half[i] * 2.0;
qmf_window[i] = s;
qmf_window[47 - i] = s;
}

=== MLT ===

The transform is a regular MDCT.

==== Windows ====

The overlapping window is not the same for encoding and decoding. Perfect reconstruction is ensured by the encoding and decoding windows having a inverse relation. Technical details can be found in H. Malvar's paper Fast algorithms for orthogonal modulated lapped transforms [http://research.microsoft.com/~malvar/papers/dfsp98.pdf]

====== Encoding ======

for (i = 0; i < 256; i++) {
we[i] = (sin(((i + 0.5) / 256 - 0.5) * PI) + 1.0) * 0.5;
}

====== Decoding ======

for (i = 0; i < 256; i++) {
wd[i] = we[i]/(we[i]^2 + we[255-i]^2)
}

== Huffman coding ==

VLC coding is used to compress the tonal and spectral coefficients.

=== Huffman tables ===

huffcode1[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits1[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode2[5] = {
0x0,0x4,0x5,0x6,0x7,
};

huffbits2[5] = {
1,3,3,3,3,
};

huffcode3[7] = {
0x0,0x4,0x5,0xC,0xD,0xE,0xF,
};

huffbits3[7] = {
1,3,3,4,4,4,4,
};

huffcode4[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits4[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode5[15] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0x1C,0x1D,0x3C,0x3D,0x3E,0x3F,
};

huffbits5[15] = {
2,3,3,4,4,4,4,4,4,5,5,6,6,6,6,
};

huffcode6[31] = {
0x0,0x2,0x3,0x4,0x5,0x6,0x7,0x8,0x9,0x14,0x15,0x16,0x17,0x18,0x19,0x34,0x35,
0x36,0x37,0x38,0x39,0x3A,0x3B,0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
};

huffbits6[31] = {
3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,7,7,
};

huffcode7[63] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0xE,0xF,0x10,0x11,0x24,0x25,0x26,0x27,0x28,
0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x68,0x69,0x6A,0x6B,0x6C,
0x6D,0x6E,0x6F,0x70,0x71,0x72,0x73,0x74,0x75,0xEC,0xED,0xEE,0xEF,0xF0,0xF1,0xF2,
0xF3,0xF4,0xF5,0xF6,0xF7,0xF8,0xF9,0xFA,0xFB,0xFC,0xFD,0xFE,0xFF,
};

huffbits7[63] = {
3,4,4,5,5,5,5,5,5,5,5,5,5,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,7,7,7,7,7,
7,7,7,7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,
};

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

Sony ATRAC

2018-11-29T13:21:13Z

Maxpol: Link with the ATRAC3 page.

* Format tag: 0x270
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3/
* Technical: http://www.minidisc.org/aes_atrac.html

ATRAC (Adaptive TRansform Acoustic Coding) is the collective name for audio compression technologies
developed by [[Sony]]. This codec family includes the following codecs today: ATRAC, ATRAC3,
ATRAC3plus and ATRAC Advanced lossless.
You can read about it at http://www.sony.net/Products/ATRAC3/overview/index.html#family

The ATRAC codec was introduced in 1992 with the MiniDisc. There is a good description at
http://www.minidisc.org/aes_atrac.html. It is used in MiniDisc portable players
by many companies.

Same as [[RealAudio atrc]], the RealAudio streams are XOR scrambled.

Stored in [[Microsoft_Wave|WAV]]/[[Microsoft_Audio/Video_Interleaved|AVI]], [[RealMedia|RM]] and [[Oma|Oma/Omg]] containers.

Sony Dynamic Digital System (SDDS), used in theatres, is based on ATRAC. Common use of the codec is in Sony made Minidisc and Flash based players.

There are some known variants:
* ATRAC
* [[ATRAC3]]
* [[ATRAC3plus]]
* ATRAC Advanced Lossless (AAL)

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]
[[Category: Lossless Audio Codecs]]

RealAudio atrc

2018-11-29T13:20:19Z

Maxpol: Maxpol moved page RealAudio atrc to ATRAC3: Rename to reflect codec's original name instead of its clone.

#REDIRECT [[ATRAC3]]

ATRAC3

2018-11-29T13:20:19Z

Maxpol: Maxpol moved page RealAudio atrc to ATRAC3: Rename to reflect codec's original name instead of its clone.

* FOURCC: atrc
* Company: [[Real]]
* Samples: http://samples.mplayerhq.hu/real/AC-atrc/

Found in some old [[RealMedia]] files. The same as the [[Sony ATRAC]].

= ATRAC3 Introduction =

ATRAC3 is the next generation of the ATRAC codec. There are three major implementations for the PC:
RealAudio8 atrc, the Sony ATRAC3 for [[Microsoft Audio Compression Manager API|Audio Compression Manager]] (ACM) and the Sonic Stage implementation.

ATRAC3 supports several different constant bitrates ("flavors"). The following table shows the
bitrate, the size of a frame and the coding mode for each flavor respectively:

No bitrate frame size (stereo) coding mode samples per frame
-- ----------------- ------------------- ------------- -----------------
0 66 kbps (66150) 192 bytes joint stereo 1024 per channel
1 94 kpbs (93713) 272 bytes joint stereo 1024 per channel
2 105 kbps (104738) 304 bytes normal stereo 1024 per channel
3 132 kpbs (132300) 384 bytes normal stereo 1024 per channel
4 146 kbps (146081) 424 bytes normal stereo 1024 per channel
5 176 kbps (176400) 512 bytes normal stereo 1024 per channel
6 264 kbps (264600) 768 bytes normal stereo 1024 per channel
7 352 kbps (352800) 1024 bytes normal stereo 1024 per channel

== Encoding algorithm ==

* Split the input signal into 4 bands using a Quadrature mirror filter (QMF).
* Perform gain control analysis to obtain gain control data.
* Convert all four bands into frequency domain using Modified Cosine Transform (MDCT or MLT).
* Find tonal components.
* Quantization
* Encode the bitstream.

Even though this is for ATRAC2 (http://www.minidisc.org/atrac2.html) most of it applies to ATRAC3.

== Decoding algorithm ==

* Parse the bitstream and extract the following:
** gain control data
** tonal components
** quantized spectral coefficients
* inverse quantization of the tonal components and spectral coefficients
* Merge tonal components and other spectral coefficients together.
* Reconstruct the timedomain signal using inverse MDCT.
* gain compensation
* Apply the QMF synthesis filter to reconstruct the sound.

== Tonal components ==

ATRAC3 extracts the psychoacoustically important tonal components from the input signal spectra
and encodes them separate from the less important spectral data. A tone component is a group of
consecutive spectral coefficients, described with parameters such as location and with. This allows
finer quantization of such coefficients than a quantization within fixed subbands.

== Joint-stereo mode ==

ATRAC3 uses joint-stereo coding at low bitrates (66 and 94 kbps) to achieve better compression.

== Bitstream overview ==

The ATRAC3 bitstream consists of so-called "Channel Sound Units". In stereo mode there are
two such units. The structure of an unit is shown below:

--------------------------------------
| Header |
--------------------------------------
| Gain compensation data |
--------------------------------------
| Tonal components |
--------------------------------------
| Other spectral coefficients |
--------------------------------------

= Decoding Specification =

== Bitstream parsing ==

Parts is '''bold''' mean that a certain amount of bits are to be consumed from the bitstream.

===Header===

If not in the joint-stereo mode, this header should be interpreted as follows:
* '''id (6 bits)''' - should contain the value 0x28
* '''nBandsCoded (2 bits)''' - number of QMF bands were coded. The value of 0 indicates one coded band.

===Gain compensation data===

For each coded QMF band (see nBandsCoded above) the following data will be transmitted:
* '''numGainData (3 bits)''' - number of gain change points coded as level/location pairs. Value of 0 indicates no coded pairs. Each coded pair consists of the following fields:
* '''levcode (4 bits)''' - level code
* '''loccode (5 bits)''' - location code
This data is identical with the gain control tool from the MPEG AAC SSR profile that were also developed by [[Sony]]. Please refer to section "Gain compensation" below for a description how to interpret this data.

===Tonal components===

The presence of tonal components is indicated by the following field:
* '''numToneComp (5 bits)''' - Number of coded tonal components. The value of 0 indicates no coded tonal components.
* '''coding_mode_selector(2 bits)''' -- If this is equal to 2, return error. If this is equal to 3 then every component has it's own bit to select the coefficients coding mode. (VLC/CLC). If this is equal to 1 then all the components are CLC coded. If this is 0 all components are VLC coded. (coding_mode)

* For each tonal component
** For each number of bands, get band flags
*** '''band_flags (1 bit)''' -- Flag per band in the Tonal Component to be processed
** '''coded_values (3 bits)''' -- amount of coded coefficients
** '''quant_step_index (3 bits)''' -- index into the quant step table, if it is less then/equal to 1 then return error
** if coding_mode_selector is 3
*** '''coding_mode (1 bit)''' -- get the bands coding mode (CLC/VLC)

===Other spectral coefficients===

The coefficients coded in this block are assumed not to be "tonal" (noise etc.) They are quantized and coded within fixed subbands. The ATRAC3 divides the whole MDCT spectrum (1024 points) into 32 subbands of unequal width (higher frequencies - wider bands). For each subband ATRAC3 will transmit a scalefactor index and VLC codes for each quantized spectral coefficients. The format of this this block is shown below:
* '''numSubbands (5 bits)''' - number of coded subbands. The value of 0 indicates no coded subbands.
* '''codingMode (1 bit)''' - value indicates the coding mode for ALL subbands:

0 - coefficients are coded using variable length codes (VLC)
1 - coefficients are coded using constant length codes (CLC)

Then follow the array of coding table indexes for each coded band:
* '''tblIndex (3 bits)''' - indicates the coding table used (VLC) or number of bits used (CLC). The value of "0" indicates "skipped" (not coded) subband.
Then follows the array of scalefactor indexes for each coded subband:
* '''sfIndex (6 bits)''' - indicates the index into scalefactor decoding table (see below).
Then follows the codes for each spectral coefficient in this subband. The VLC codes are shown below.

== Scrambling ==

In [[RealMedia]] files the bitstream is scrambled. To unscramble the stream, perform a XOR on every 32 bits in the frame. The hex value to XOR with is 0x537F6103.

== Extra data format ==

In [[RealMedia]] files the extra data is as follows (big-endian order):

INT32 id, always 4
INT16 samples per frame, always 1024 * 2
INT16 delay, not used but always 0x88E
INT16 stereo coding mode, 2 - normal stereo, 0x12 - joint stereo

The length of this data is always 10 bytes.

== Transforms ==

=== QMF ===

Three stacked [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filters] are used to split the signal into 4 different frequency bands.

* 0 to 2.75625 kHz (DC to ''f''/16)
* 2.75625 to 5.5125 kHz (''f''/16 to ''f''/8)
* 5.5125 to 11.025 kHz (''f''/8 to ''f''/4)
* 11.025 to 22.05 kHz (''f''/4 to ''f''/2)

==== QMF window ====

The coeffs used in the QMF filter.

float qmf_48tap_half[24] = {
-0.00001461907, -0.00009205479, -0.000056157569, 0.00030117269,
0.0002422519,-0.00085293897, -0.0005205574, 0.0020340169,
0.00078333891, -0.0042153862, -0.00075614988, 0.0078402944,
-0.000061169922, -0.01344162, 0.0024626821, 0.021736089,
-0.007801671, -0.034090221, 0.01880949, 0.054326009,
-0.043596379, -0.099384367, 0.13207909, 0.46424159
};

These coeffs need to be mirrored and scaled by 2.

for (i=0 ; i<24; i++) {
s = qmf_48tap_half[i] * 2.0;
qmf_window[i] = s;
qmf_window[47 - i] = s;
}

=== MLT ===

The transform is a regular MDCT.

==== Windows ====

The overlapping window is not the same for encoding and decoding. Perfect reconstruction is ensured by the encoding and decoding windows having a inverse relation. Technical details can be found in H. Malvar's paper Fast algorithms for orthogonal modulated lapped transforms [http://research.microsoft.com/~malvar/papers/dfsp98.pdf]

====== Encoding ======

for (i = 0; i < 256; i++) {
we[i] = (sin(((i + 0.5) / 256 - 0.5) * PI) + 1.0) * 0.5;
}

====== Decoding ======

for (i = 0; i < 256; i++) {
wd[i] = we[i]/(we[i]^2 + we[255-i]^2)
}

== Huffman coding ==

VLC coding is used to compress the tonal and spectral coefficients.

=== Huffman tables ===

huffcode1[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits1[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode2[5] = {
0x0,0x4,0x5,0x6,0x7,
};

huffbits2[5] = {
1,3,3,3,3,
};

huffcode3[7] = {
0x0,0x4,0x5,0xC,0xD,0xE,0xF,
};

huffbits3[7] = {
1,3,3,4,4,4,4,
};

huffcode4[9] = {
0x0,0x4,0x5,0xC,0xD,0x1C,0x1D,0x1E,0x1F,
};

huffbits4[9] = {
1,3,3,4,4,5,5,5,5,
};

huffcode5[15] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0x1C,0x1D,0x3C,0x3D,0x3E,0x3F,
};

huffbits5[15] = {
2,3,3,4,4,4,4,4,4,5,5,6,6,6,6,
};

huffcode6[31] = {
0x0,0x2,0x3,0x4,0x5,0x6,0x7,0x8,0x9,0x14,0x15,0x16,0x17,0x18,0x19,0x34,0x35,
0x36,0x37,0x38,0x39,0x3A,0x3B,0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
};

huffbits6[31] = {
3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,7,7,
};

huffcode7[63] = {
0x0,0x2,0x3,0x8,0x9,0xA,0xB,0xC,0xD,0xE,0xF,0x10,0x11,0x24,0x25,0x26,0x27,0x28,
0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x68,0x69,0x6A,0x6B,0x6C,
0x6D,0x6E,0x6F,0x70,0x71,0x72,0x73,0x74,0x75,0xEC,0xED,0xEE,0xEF,0xF0,0xF1,0xF2,
0xF3,0xF4,0xF5,0xF6,0xF7,0xF8,0xF9,0xFA,0xFB,0xFC,0xFD,0xFE,0xFF,
};

huffbits7[63] = {
3,4,4,5,5,5,5,5,5,5,5,5,5,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,7,7,7,7,7,
7,7,7,7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,
};

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

Sony ATRAC

2018-11-29T13:16:08Z

Maxpol: Add general ATRAC family description.

* Format tag: 0x270
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3/
* Technical: http://www.minidisc.org/aes_atrac.html

ATRAC (Adaptive TRansform Acoustic Coding) is the collective name for audio compression technologies
developed by [[Sony]]. This codec family includes the following codecs today: ATRAC, ATRAC3,
ATRAC3plus and ATRAC Advanced lossless.
You can read about it at http://www.sony.net/Products/ATRAC3/overview/index.html#family

The ATRAC codec was introduced in 1992 with the MiniDisc. There is a good description at
http://www.minidisc.org/aes_atrac.html. It is used in MiniDisc portable players
by many companies.

Same as [[RealAudio atrc]], the RealAudio streams are XOR scrambled.

Stored in [[Microsoft_Wave|WAV]]/[[Microsoft_Audio/Video_Interleaved|AVI]], [[RealMedia|RM]] and [[Oma|Oma/Omg]] containers.

Sony Dynamic Digital System (SDDS), used in theatres, is based on ATRAC. Common use of the codec is in Sony made Minidisc and Flash based players.

There are some known variants:
* ATRAC
* ATRAC3
* [[ATRAC3plus]]
* ATRAC Advanced Lossless (AAL)

[[Category:Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]
[[Category: Lossless Audio Codecs]]

ATRAC3

2018-11-29T13:15:31Z

Maxpol: Factor out general ATRAC description.

ATRAC3plus

2014-06-22T20:34:35Z

Maxpol: /* Coding techniques */

* Format tag: uses WAVE_FORMAT_EXTENSIBLE with the "SubFormat" field set to the following [[GUID]]: E923AABF-CB58-4471-A119-FFFA01E4CE62
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3+/
* Stored in: [[Microsoft_Wave|WAV]] and [[Oma|Oma/Omg]] containers.
* Official information: http://www.sony.net/Products/ATRAC3/tech/atrac3plus.html

= ATRAC3plus introduction =

ATRAC3plus is a proprietary audio compression algorithm developed by [[Sony]]. As in the case of ATRAC3 ATRAC3plus represents the next generation of the ATRAC codec introduced in 1992 with the MiniDisc. Common use of that codec is in nowel Minidisc players and Portable Playstations made by [[Sony]].

Streams coded with ATRAC3plus are usually stored either in the [[Microsoft_Wave|WAV]] container (those files have the ".at3" extension though) or in the Sony's proprietary [[Oma|Oma/Omg]] container. In the case of the [[Microsoft_Wave|WAV]] container the undocumented [[GUID]]:
E923AABF-CB58-4471-A119-FFFA01E4CE62
is used in order to indicate the ATRAC3plus codec.

There is very limited number of software products supporting encoding/decoding of the ATRAC3plus streams; most of them are unfortunately available for [[Microsoft]] Windows only. Those are:

* Sony's own SonicStage software (Windows only)
* ATRAC Codec Plugin for Sony Media Software (Windows only)
* Sonic Studio's expensive N-code plugin for professionals (available for Windows and Mac OS X)

There is a multi-channel version of ATRAC3plus called "ATRAC-X".

= ATRAC3plus technical documentation =

=== Available bitrates ===

ATRAC3plus operates on fixed bitrates only. The following bitrates are offered by the Sony Encoding software:

bitrate frame size (stereo)
------------- -------------------
48 Kbps 280 bytes
64 Kbps 376 bytes
96 Kbps 560 bytes
128 Kbps 744 bytes
160 Kbps 936 bytes
192 Kbps 1120 bytes
256 Kbps 1488 bytes
320 Kbps 1864 bytes
352 Kbps 2048 bytes

=== Coding techniques ===

ATRAC3plus is a hybrid subband/MDCT codec like [[MP3]]. The signal is split into 16 subbands using [http://en.wikipedia.org/wiki/Polyphase_quadrature_filter Polyphase Quadrature Filter] (further PQF) before MDCT and bit allocation. The sample-frame size is 2048 samples per channel.

After the subband splitting ATRAC3plus tries to extract sine waves from each subband using Generalized Harmonic Analysis (further GHA). GHA encodes parameters of extracted sine waves such as frequency, amplitude and phase into final bitstream.

After the sine waves extraction the remained signal (residual) will be transformed into frequency domain by a 128-point [http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform Modified discrete cosine transform]. The resultet MDCT spectrum will be devided into 32 quantization units of unequal width (higher frequencies - wider units). The relationship between QMF bands and quantization units (QU) is shown in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | QMF subband
| colspan="8" style="text-align:center;"| 0
| colspan="4" style="text-align:center;"| 1
| colspan="4" style="text-align:center;"| 2
| colspan="2" style="text-align:center;"| 3
| colspan="2" style="text-align:center;"| 4
| colspan="2" style="text-align:center;"| 5
| 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | Quant unit
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|}

The flowchart of the ATRAC3plus decoding process is shown below:

[[image:Atrac3plus_decoder_flow.png]]

"Bitstream decoder" decodes various sound parameters from supplied frame data. First the residual signal will be decoded by applying inverse quantization, power compensation, inverse MDCT and gain compensation. Then the sine waves will be synthesized according with their parameters such as frequency, amplitude and phase. Then the residual and the synthesized sine waves will be added together. Optionally, some white noise can be added if specified in the bitstream.

This processing will be repeated for each of 16 subbands. Finally the PQF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal.

Various algorithms are used to improve compression results:

* gain control for reducing pre-echo artifacts
* power compensation for better quality at low bitrates

The following techniques are used in order to make the compressed data smaller:

* variable-lenght ([[Huffman]]) coding
* [[Vector_Quantization|vector quantization]] based on trained tables
* [[Differential_Coding|differential coding]]

Probably the most interesting part of the ATRAC3plus codec is the Generalized Harmonic Analysis (GHA) - an inharmonic frequency analysis proposed by Norbert Wiener in 1930. The main advantage of that is an excellent frequency resolution that surpasses the short-time Discrete Furier transformation. However it requires huge amount of calculations. Several algorithms to work around that problem were introduced during last 20 years, for example the one proposed by Dr.Hirata.

==== Coding methods for compressing bitstream parameters ====

Coding methods described in this section serve the purpose of representing different bitstream parameters like word-length, scale factor etc. using a smaller number of bits. It will be achieved by exploring and removing redundancy from the signals being encoded. The coding techniques described here are [[Lossless_compression|lossless]].

===== Huffman coding =====

ATRAC3plus uses this coding technique widely. There are more than 130 different huffman tables in total for coding bitstream signals. Usually more frequently occuring values will have shorter codes.
ATRAC3plus huffman trees are [http://en.wikipedia.org/wiki/Canonical_Huffman_code canonical ones]. That means those can be stored very compactly by specifying the following parameters:

* number of bits of the shortest codeword
* number of bits of the longest codeword
* number of items for every bit length
* order of items

In my code I'm using the following descriptor in order to specify a canonical huffman table:

uint8_t min; /* shortest codeword length */
uint8_t max; /* longest codeword length */
uint8_t num_items[max - min + 1]; /* number of items for every bit length */

For example, the huffman table vlc_tab_index = 3 [[#Huffman tables for delta coding|here]] will be described as follows:

min = 1
max = 5
num_items[1, 0, 2, 3, 2]

The 2nd element of the array "num_items" is set to "0" because there is no codeword with the length of 2 bits.

The following C-pseudocode can be used for generating huffman tables from the descriptor described above during decoder initialization:

code = 0;
index = 0;

for (num_bits = min; num_bits <= max; num_bits++) {
for (i = num_items[num_bits]; i > 0; i--) {
bits [index] = num_bits;
codes[index] = code++;
index++;
}
code <<= 1;
}

The array "bits" receives length in bits for each codeword, "codes" receives codeword itself.

Finally, the order of codes need to be specified. A simple remapping table will be used to translate the code index into final code. For the table described above the translation table will look as follows:

0, 1, 7, 2, 3, 6, 4, 5

===== Delta coding =====

ATRAC3plus utilizes various delta-coding schemes in order to remove linear correlation from the signal. It often uses the [http://en.wikipedia.org/wiki/Modular_arithmetic modular arithmetic] as well. The main advantage of this coding is that only the half of the range of the difference values is required. An example: word-length information coefficients in the range 0...7 need to be transmitted compactly. Using delta coding this would require to code difference values in the range -7...+7, also 15 values.

In the case of modular arithmetic the range of the difference values can be reduced to 0...7 by introducing a "wrap-around" so that the final equation looks like this:

B = (A + delta) & 7;

Below an example with "wrap around":

Consider we need to code the value B = "1" and the reference value A = "6". Then the difference value (delta) will be = "-5". According with equation above the delta value of "3" can be used instead of "-5":

(6 + 3) & 7 = 1;

Another example without "wrap around":

Consider we need to code the value B = "7" and the reference value A = "2". Then the difference value (delta) will be = "5":

(2 + 5) & 7 = 7;

Further variable-length codes will be used to reduce amount of bits of difference values in accordance with their probability.

The following is a description of the delta-coding methods used in ATRAC3plus:

====== Method A: huffman-coded modulo difference to previous ======

Consider the following signal:

3, 6, 6, 3, 3, 3, 4, 2, 2, 1, 1, 1, 3

Now code it using delta coding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Coefficient !! Modulo delta value !! Huffman code !! Number of bits
|-
| align="center" | 3 || align="center" | - || align="center" | - || align="center" | 3
|-
| align="center" | 6 || align="center" | 3 || align="center" | 11110 || align="center" | 5
|-
| align="center" | 6 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 5 || align="center" | 1101 || align="center" | 4
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 4 || align="center" | 1 || align="center" | 100 || align="center" | 3
|-
| align="center" | 2 || align="center" | 6 || align="center" | 1110 || align="center" | 4
|-
| align="center" | 2 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 7 || align="center" | 101 || align="center" | 3
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 2 || align="center" | 1100 || align="center" | 4
|}

The 1st coefficient has no delta value associated with it because there is no previous value. It will be coded "as is" using fixed length of 3 bits. The following delta values get a variable-length code from the table val_tab_index = 2 [[#Huffman tables for delta coding|here]] so the final number of bits to be transmitted will be = 32.
Compared to the unpacked version (13 x 3 bits = 39 bits) the coding method described above will yield a bit-reduction of 7 bits (18% smaller).

====== Method B: huffman-coded modulo difference to master ======

In a stereo mix the signal of the left channel is often very similar to the signal of the right channel (i.e. there is a high cross-correlation between the channels). In this case the estimated sound parameters like word-length or scale factor will have a high similarity as well. Then coding the differential signal between the channels can lead to a significant bit reduction.
Surely at least the one of the channels must be coded independently. Such a channel will be called "master" (it's usually the left channel but ATRAC3plus has the possibility to make the right channel act like a master as well). For the 2nd channel only the difference to master will be coded. The 2nd channel will be called "slave" in this case.

Below an example of such a high-correlated signal:

Left : 6, 5, 6, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1
Right: 6, 5, 6, 2, 2, 2, 3, 1, 1, 1, 2, 1, 1
Diff : 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0

Coding the difference signal using the table val_tab_index = 0 [[#Huffman tables for delta coding|here]] will result in another signal 15 bits long. Compared to the unpacked version (13 x 3 bits = 39 bits) that coding method will yield a bit-reduction of 24 bits (62% smaller).

====== Method C: shorter delta to min ======

Sometimes coefficients in a signal are very close to each other, so subtracting the minimum value from each coefficient will result in smaller deltas whose can be coded using fewer bits.

An example:

2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1

As one can see the values in the sequence above are very similar to each other. Let us find minimum and maximum values and then determine the number of delta bits:

min = 1; max = 2; num_delta_bits = ilog2(max - min + 1) = 1 bit

Now let us encode the sequence above using shorter deltas:

num_delta_bits = 1 will be coded as a 2-bit value
min = 1 will be coded as a 3-bit value
deltas: 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0

The encoded signal is 5 + 1 x 15 = 20 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 25 bits (55% smaller).

Another example:

1, 2, 3, 2, 4, 2, 1, 2, 3, 3, 1, 4, 4, 1, 1

min = 1; max = 4; num_delta_bits = ilog2(max - min + 1) = 2 bits

Now the encoded signal:

num_delta_bits = 2 (will be coded as a 2-bit value)
min = 1 (will be coded as a 3-bit value)
deltas: 0, 1, 2, 1, 3, 1, 0, 1, 2, 2, 0, 3, 3, 0, 0

The encoded signal is 5 + 2 x 15 = 35 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 10 bits (22% smaller).

====== Method D: sequence of numbers in ascending order ======

Sometimes ATRAC3plus have to deal with sequences of numbers (i.e. gain control position information) where all items are known to be in ascending order (i.e. satisfy the following equation: ''Vn+1 > Vn''). Such sequences can be packed without any additional bitstream information by examining previous value (predecessor), calculating magnitude between it and the maximum value and making the decision about number of bits of the next delta value.

Consider the following sequence:

Position index: 0, 1, 2, 3, 4, 5, 6, 7
---------------------------------------------
Position info : 5, 7, 14, 15, 18, 25, 29, 30
---------------------------------------------
Num delta bits: 5, 5, 5, 4, 4, 3, 1, 0

1st coefficient (position index = 0) will be coded directly using 5 bits because the sequence should start somewhere.
The following coefficients (except one with the value of "30") will be coded according to the following pseudocode:

num_delta_bits = ilog2(31 - prev_val);
if (num_delta_bits == 5)
new_val = get_bits(5);
else
new_val = prev_val + get_bits(num_delta_bits) + 1;

Let us return to our sequence. The 2nd value will be coded directly as well using 5 bits because ilog2(31 - 5) = 5. Similar for the 3rd one. No delta coding is applied in that case. The 4th value will be delta-coded using 4 bits:

num_delta_bits = ilog2(31 - 15) = 4 bits;
delta = 18 - 15 - 1 = 2

And so on until we reach the last value = 30. In this case there is only one value that meets our condition ''Vn+1 > Vn'': the value of "31". In this case no delta will be transmitted and the coming value will be calculated just as:

new_val = prev_val + 1;

Therefore the resulting sequence will be 27 bits long. Compared to the unpacked version (8 x 5 bits = 40 bits) this packing method will yield a bit-reduction of 13 bits (32% smaller).

===== Vector quantization with residual encoding =====

One further packing technique used in ATRAC3plus is based on so-called "shape prediction vectors". Encoder decomposes a signal (word-length or scale factor info) into "shape prediction" + residual. Then only the index of the "shape prediction vector" and the huffman-coded residual will be transmitted. The main advantage of this method is when the shape matches the coded signal closely, the residual can be represented very compactly (usually 1-2 bits per value). Moreover, the majority of values of the residual will turn into zeroes, which can be further packed.

Each entry of the "shape prediction tables" contain an average value over 3 coefficients. This helps to keep those tables comparable small. For example, for a signal of 32 values each "shape table" will have 10 entries (last entry contains usually an average value over 5 coefficients).

Consider the following signal to be encoded:

7, 7, 6, 5, 4, 4, 3, 2, 2, 2, 1, 1

Let us "quantize" that signal by diving it into 4 * 3 groups and find the averaged value in each group:

floor((7 + 7 + 6) / 3 + 0.5) = 7,
floor((5 + 4 + 4) / 3 + 0.5) = 4,
floor((3 + 2 + 2) / 3 + 0.5) = 2,
floor((2 + 1 + 1) / 3 + 0.5) = 1

Find a "shape table" in the trained set that closely matches our "quantized" version. It will be (for example):
7, 5, 2, 1

Now compute the residual:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | Original signal
| style="text-align:center;"| 7
| style="text-align:center;"| 7
| style="text-align:center;"| 6
| style="text-align:center;"| 5
| style="text-align:center;"| 4
| style="text-align:center;"| 4
| 3 || 2 || 2 || 2 || 1 || 1
|-
! bgcolor="#f0f0f0" | Unpacked shape table
| 7 || 7 || 7 || 5 || 5 || 5 || 2 || 2 || 2 || 1 || 1 || 1
|-
! bgcolor="#f0f0f0" | Residual
| 0 || 0 || -1 || 0 || -1 || -1 || 1 || 0 || 0 || 1 || 0 || 0
|}

Now select a huffman table that represents the residual above as small as possible. The following huffman tree assigns the shortest code (1 bit) to the most frequently occuring symbol = "0" and 2-bit codes to the others: "1" and "-1":

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | -1
|}

The packed signal will occupy 21 bits: 4 bits "shape table" index + 17 bits residual(7 bits for "zeroes" + 10 bits for "non-zeroes"). Compared to the unpacked version (12 x 3 bits = 36 bits) this packing method will yield a bit-reduction of 15 bits (42% smaller).

===== Value grouping with "group coded" flag =====

If a signal contains lots of zeroes, grouping several values together and assigning the "group coded" flag to each group will achieve a significant bit-reduction. Consider the following sequence of numbers to be encoded:

0, 0, 1, 2, 0, 0, 3, 3, 0, 0, 0, 7, 0, 6, 0, 0

Let us cluster each two values together and assign the "coded" flag (1 bit) to each group:

(0, 0); flag = 0 (group not coded)
(1, 2); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(3, 3); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(0, 7); flag = 1 (group coded)
(0, 6); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)

Thereafter, each "not coded" group requires only one bit to be transmitted indicating that all values in that group are zero. On the other hand, each "coded" group requires one extra bit to be transmitted indicating that at least one value in that group is non-zero. In the case above that overhead is worthwhile because the half of the signal contains zeroes.

The encoded signal is 4 x 1 + 4 x 7 = 32 bits long while the unpacked one is 16 x 3 = 48 bits long. The bit-reduction is thereafter 16 bits (33% smaller).

== Multichannel ATRAC3plus (ATRAC-X) ==

ATRAC3plus supports multichannel streams (up to 8 channels). Such streams are encoded in units customary called "channel block"; each block contains max. 2 channels (ie can be MONO or STEREO). For example, taking the channel_id = 3 and looking at the table below we have a stream containing 2 channel blocks: 1 stereo + 1 mono and thus 3 channels.
The base codec operates on either MONO or STEREO channel blocks only.

=== ATRAC-X channel configurations ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! channel_id !! total channels !! number of channel blocks !! speaker mapping
|-
| align="center" | 0 || align="center" | 0 || align="center" | undefined ||
* undefined
|-
| align="center" | 1 || align="center" | 1 || align="center" | 1 ||
* front: center (MONO)
|-
| align="center" | 2 || align="center" | 2 || align="center" | 1 ||
* front: L, R (STEREO)
|-
| align="center" | 3 || align="center" | 3 || align="center" | 2 ||
* front: L, R
* front: center
|-
| align="center" | 4 || align="center" | 4 || align="center" | 3 ||
* front: L, R
* front: center
* rear: surround
|-
| align="center" | 5 || align="center" | 5+1 || align="center" | 4 ||
* front: L, R
* front: center
* rear: L, R
* LFE
|-
| align="center" | 6 || align="center" | 6+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* rear: center
* LFE
|-
| align="center" | 7 || align="center" | 7+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* side: L, R
* LFE
|}

== Bitstream overview ==

The table below shows the bitstream organization of ATRAC3plus at the top-level. Depends on [[#ATRAC-X channel configurations|channel configuration]] a typical frame may contain more than one channel block. In this case the additional fields [[#channel_block_type|channel_block_type]] and [[#channel_block_data|channel_block_data]] will be included for each block.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! number of bits !! value !! description
|-
| align="center" | start_marker || align="center" | 1 || align="center" | 0 ||
marks the start of the ATRAC3plus bitstream
|-
| align="center" | channel_block_type || align="center" | 2 ||
* 00b - MONO block
* 01b - STEREO block
* 10b - EXTENSION block
| align="center" | type of the channel block
|-
| align="center" | channel_block_data || align="center" | variable || || align="center" | contains encoded sound information
|-
| align="center" | terminator || align="center" | 2 || align="center" | 11b || align="center" | indicates the end of the bitstream
|}

=== Channel block types ===

There are following channel block types in ATRAC3plus:

* '''Mono channel block''': contains monaural sound data.
* '''Stereo channel block''': contains stereophonic sound data.
* '''Extension block''': as indicated by its name it's intended to carry some extension information. Its purpose is unknown though due to the lack of an official description. All existing decoder implementations are programmed to ignore blocks of that type.

=== Channel block layout ===

ATRAC3plus was designed to provide a high-quality sound compression. Therefore it tries to save as much bits as possible. It uses a new coding scheme for channel blocks compared to ATRAC3: channels in a stereo sound are no more coded separately but rather in one stereo channel block. The bitstream for such a block provides the possibility for both channels to share several sound parameters so that there is no need to transmit the same things twice. Depends on correlation between the channels this can lead to a significant bit reduction and thus improve coding quality.

A mono/stereo channel block contains the following pieces of sound information:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! size in bits !! description
|-
| align="center" | [[#Sound header|sound_header]] || align="center" | 6 || width="700" | defines some global sound parameters
|-
| align="center" | [[#Word-length information|wordlength_info]] || align="center" | variable || quantization word length information for each quant unit
|-
| align="center" | scalefactor_info || align="center" | variable || quantization scale factor indexes for each coded quant unit
|-
| align="center" | codetable_info || align="center" | variable || code table table information for each coded quant unit
|-
| align="center" | spectra || align="center" | variable || huffman-coded spectral information for each coded quant unit
|-
| align="center" | window_info || align="center" | variable || tells which IMDCT window shape should be used during the sound reconstruction
|-
| align="center" | gain_info || align="center" | variable || gain envelope used by the gain compensation
|-
| align="center" | gha_info || align="center" | variable || information about sine-like waves in the compressed sound obtained by the GHA. It contains quantized frequency, amplitude and phase for each wave to be synthesized in the decoder.
|-
| align="center" | noise_info || align="center" | 1/9 || contains noise flag, level index and table selector for the white noise to be added during decoding.
|}

==== Sound header ====

At the start of each channel block the sound header is located. It contains the following fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || num_quant_units || valid values: 0...27,31 || width="500" | number of coded quantization units - 1. The value of "0" indicates one coded unit, the value of "31" - 32 ones. The values 28, 29 and 30 are invalid.
|-
| align="center" | 1 || align="center" | x_flag || || to be figured out
|}

==== Word-length information ====

===== Coding summary =====

Word-length (or quantization precision) information follows the sound header. It defines the word-length parameter for each [[#num_quant_units|coded quantization unit]]. This parameter is in the range 0...7, where the value of "7" indicates the highest quantization precision and the value of "1" - the lowest one. The value of "0" means no data, i.e. the corresponding quantization unit was not coded.

In the case of the stereo channel block the word-length parameters for the channel 1(L) will be transmitted first followed by the the word-length parameters for the channel 2(R). The word-lengths for the channel 1 are always coded independently. The word-lengths for the channel 2 can be coded either independently or relative to the channel 1. In this case the 1st channel is called "master" and the 2nd one - "slave".
The word-lengths for the mono block will be coded just like the channel 1 in the stereo block.

In order to keep the word-length data as small as possible ATRAC3plus uses several coefficient packing techniques achieving different amount of bits needed for transmission:

* the coefficients are coded directly (3 bits value). This means no packing and used at high bitrates because the frame size is big enough to keep the infomation unpacked.

* differential coding + huffman-coded delta: the first coefficient is coded directly; all others are huffman-coded deltas to the previous coefficient.

* prediction + huffman-coded residual: this techniques offers the best packing and used at low bitrates. It's analogous to the lossless coding and based on trained shape tables serving as prediction. Later the huffman-coded residual will be added to the prediction prefectly reconstructing the coefficients.

===== Reconstruction of trimmed word-length coefficients =====

Word-length coefficient of the trailing quantization units corresponding to the high spectral bands tend to be either 1 (low-precision) or 0 (not coded). Such coefficients will be ommited and one the following modes will be used in order to reconstruct their values during decoding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! mode code(2 bits) !! num_coded_vals !! split_point_delta !! Action(master) !! Action(slave)
|-
| align="center" | 0 || align="center" | not present
|rowspan="3" style="text-align:center;" | not present
|colspan="2" style="text-align:center;" | no trimmed coefficients
|-
| align="center" | 1
|rowspan="3" style="text-align:center;" | 5 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients to "0"
|-
| align="center" | 2 || width="220" | set all trimmed coefficients to "1" || width="220" | for each trimmed coefficient read one bit of its direct value
|-
| align="center" | 3 || align="center" | 2 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients up to split point to "1" and after split point - to "0". The split point is calculated differently for master and slave channels (see below)
|}

To calculate the split point from [[#split_point_delta|split_point_delta]] do the following:

* for the master channel: number of zeroes = split_point_delta + 1
* for the slave channel: number of ones = split_point_delta + 3

The following C-pseudocode shows how to parse a bitstream according with the table above:

mode = get_bits(2);
if (mode) {
num_coded_vals = get_bits(5);
if (mode == 3)
split_point_delta = get_bits(2);
} else {
num_coded_vals = [[#num_quant_units|num_quant_units]];
}

The following C-pseudocode shows how to reconstruct trimmed word-length coefficients according with the table above:

switch (mode) {
case 0: /* no further action */
break;
case 1:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
break;
case 2:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++) {
if (channel == master)
wl_coeffs[pos] = 1;
else
wl_coeffs[pos] = get_bits(1);
}
break;
case 3:
if (channel == master)
split_point = [[#num_quant_units|num_quant_units]] - split_point_delta - 1;
else
split_point = num_coded_vals + split_point_delta + 3;

for (pos = num_coded_vals; pos < split_point; pos++)
wl_coeffs[pos] = 1;

for (; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
}

===== Word-length coding in detail =====

The word-length information for each channel will be coded as follows:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! comments
|-
| align="center" | 2 || coding_mode || width="500" | indicates the coding mode used.
|-
| align="center" | variable || align="center" | coeff_info || word-length coefficients coded according with the [[#coding_mode|coding_mode]].
|}

The [[#coding_mode|coding_mode]] parameter may be interpreted differently depends on the channel number. The following pseudocode examples explain the coding modes in detail:

===== Mode 0 (master and slave) =====

All coefficients will be directly coded as follows:

for (i = 0; i < [[#num_quant_units|num_quant_units]]; i++)
wl_coeffs[i] = get_bits(3);

===== Mode 1 (master) =====

Leading "n" values are stored directly while trailing ones are packed using [[#Method C: shorter delta to min|Method C: shorter delta to min]] method.

Data stored in the bitstream:

* 2 bits: index of the table of weigths, "0" - indicates "no table used"
* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 5 bits: number of directly coded coefficients ('''num_direct_coeffs'''). This value must be < [[#num_coded_vals|num_coded_vals]]
* 2 bits: size of deltas in bits ('''delta_bits''')
* 3 bits: minimum value ('''min_value''')
* for each '''num_direct_coeffs'''
** 3 bits: coefficient value
* if '''delta_bits''' > 0: for each ([[#num_coded_vals|num_coded_vals]] - '''num_direct_coeffs''')
** '''delta_bits''': delta value to be added to the '''min_value'''

The following C-pseudocode summarizes all above:

weigths_tab_indx = get_bits(2); /* get index of weights table to be added after decoding */

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

num_direct_coeffs = get_bits(5);
if (num_direct_coeffs > [[#num_coded_vals|num_coded_vals]])
ABORT("Invalid number of directly coded coefficients");

delta_bits = get_bits(2);
min_value = get_bits(3);

for (pos = 0; pos < num_direct_coeffs; pos++)
wl_coeffs[pos] = get_bits(3);

for (; pos < num_coded_vals; pos++) {
if (delta_bits)
wl_coeffs[pos] = min_value + get_bits(delta_bits);
else
wl_coeffs[pos] = min_value;
}

/* reconstruct trimmed coefficients as described [[#Reconstruction of trimmed word-length coefficients|here]] */

/* add weighting coefficients if requested */
if (weigths_tab_indx) {
for (pos = 0; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] += [[#Tables of weights|wl_weights]][channel_num][weights_tab_indx - 1][pos];
}

===== Mode 1 (slave) =====

Coding method: [[#Method B: huffman-coded modulo difference to master|Huffman-coded modulo difference to master]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 2 bits: indicates which huffman table from [[#Huffman tables for delta coding|this set]] should be used for decoding
* for each [[#num_coded_vals|num_coded_vals]]
** huffman-coded delta value to be added to the corresponding value of the master channel

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

vlc_sel = get_bits(2); /* selects a huffman table from [[#Huffman tables for delta coding|this set]] */

for (i = 0; i < [[#num_coded_vals|num_coded_vals]]; i++) {
delta = get_vlc(vlc_sel);
wl_coeffs[i] = (master_ch->wl_coeffs[i] + delta) & 7;
}

===== Mode 2 (master) =====

Coding method: [[#Vector quantization with residual encoding|Vector quantization with residual encoding]] and [[#Value grouping with "group coded" flag|Value grouping with "group coded" flag]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]].
* 1 bit: '''enable_grouping''' flag. "1" indicates that residual values were coded pairwise (in groups of two).
* 1 bit: selects one of the first two huffman tables from [[#Huffman tables for delta coding|this set]].
* 3 bits: '''start_value''' selecting a subset of "shape tables" from the trained set.
* 4 bits: '''shape_index''' selecting a "shape table" within the subset indicated by '''start_value'''.
* for each [[#num_coded_vals|num_coded_vals]]
** if '''enable_grouping''' == 1:
*** 1 bit: '''group_coded''' flag
*** if '''group_coded''' == 1:
**** 2 huffman-coded residual values to be added to the unpacked "shape table" using modular arithmetic
** if '''enable_grouping''' == 0:
*** one huffman-coded residual value to be added to the unpacked "shape table" using modular arithmetic

== Annex A: Decoding tables ==

=== Word-length related tables ===

==== Tables of weights ====

The weights below will be added to the decoded word-length coefficients. The tables are organized as follows:
* [channel_number: 0 or 1][index: 0...2][coeff_indx: 0...31]

wl_weights[2][3][32] = {
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
},
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 5, 5, 5, 5, 3, 3, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
};

==== Huffman tables for delta coding ====

PLEASE NOTE: delta values indicated in the tables below will be added using modular arithmetic as described [[#Delta coding|here]], so in the case of "wrap around" the value of "7" will be treated as "-1", the value of "6" = "-2" and so on.

* '''vlc_tab_index = 0''', delta range -1...1

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | 7
|}

* '''vlc_tab_index = 1''', delta range -2...2

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 2
|-
| align="center" | 110 || align="center" | 3 || align="center" | 6
|-
| align="center" | 111 || align="center" | 3 || align="center" | 7
|}

* '''vlc_tab_index = 2''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 5
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 3
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 4
|}

* '''vlc_tab_index = 3''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 3
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 4
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 5
|}

[[Category:Audio Codecs]]
[[Category: Multichannel Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

ATRAC3plus

2014-06-22T20:32:49Z

Maxpol: /* Coding techniques */

* Format tag: uses WAVE_FORMAT_EXTENSIBLE with the "SubFormat" field set to the following [[GUID]]: E923AABF-CB58-4471-A119-FFFA01E4CE62
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3+/
* Stored in: [[Microsoft_Wave|WAV]] and [[Oma|Oma/Omg]] containers.
* Official information: http://www.sony.net/Products/ATRAC3/tech/atrac3plus.html

= ATRAC3plus introduction =

ATRAC3plus is a proprietary audio compression algorithm developed by [[Sony]]. As in the case of ATRAC3 ATRAC3plus represents the next generation of the ATRAC codec introduced in 1992 with the MiniDisc. Common use of that codec is in nowel Minidisc players and Portable Playstations made by [[Sony]].

Streams coded with ATRAC3plus are usually stored either in the [[Microsoft_Wave|WAV]] container (those files have the ".at3" extension though) or in the Sony's proprietary [[Oma|Oma/Omg]] container. In the case of the [[Microsoft_Wave|WAV]] container the undocumented [[GUID]]:
E923AABF-CB58-4471-A119-FFFA01E4CE62
is used in order to indicate the ATRAC3plus codec.

There is very limited number of software products supporting encoding/decoding of the ATRAC3plus streams; most of them are unfortunately available for [[Microsoft]] Windows only. Those are:

* Sony's own SonicStage software (Windows only)
* ATRAC Codec Plugin for Sony Media Software (Windows only)
* Sonic Studio's expensive N-code plugin for professionals (available for Windows and Mac OS X)

There is a multi-channel version of ATRAC3plus called "ATRAC-X".

= ATRAC3plus technical documentation =

=== Available bitrates ===

ATRAC3plus operates on fixed bitrates only. The following bitrates are offered by the Sony Encoding software:

bitrate frame size (stereo)
------------- -------------------
48 Kbps 280 bytes
64 Kbps 376 bytes
96 Kbps 560 bytes
128 Kbps 744 bytes
160 Kbps 936 bytes
192 Kbps 1120 bytes
256 Kbps 1488 bytes
320 Kbps 1864 bytes
352 Kbps 2048 bytes

=== Coding techniques ===

ATRAC3plus is a hybrid subband/MDCT codec like [[MP3]]. The signal is split into 16 subbands using [http://en.wikipedia.org/wiki/Polyphase_quadrature_filter Polyphase Quadrature Filter] before MDCT and bit allocation. The sample-frame size is 2048 samples per channel.

After the subband splitting ATRAC3plus tries to extract sine waves from each subband using Generalized Harmonic Analysis (further GHA). GHA encodes parameters of extracted sine waves such as frequency, amplitude and phase into final bitstream.

After the sine waves extraction the remained signal (residual) will be transformed into frequency domain by a 128-point [http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform Modified discrete cosine transform]. The resultet MDCT spectrum will be devided into 32 quantization units of unequal width (higher frequencies - wider units). The relationship between QMF bands and quantization units (QU) is shown in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | QMF subband
| colspan="8" style="text-align:center;"| 0
| colspan="4" style="text-align:center;"| 1
| colspan="4" style="text-align:center;"| 2
| colspan="2" style="text-align:center;"| 3
| colspan="2" style="text-align:center;"| 4
| colspan="2" style="text-align:center;"| 5
| 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | Quant unit
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|}

The flowchart of the ATRAC3plus decoding process is shown below:

[[image:Atrac3plus_decoder_flow.png]]

"Bitstream decoder" decodes various sound parameters from supplied frame data. First the residual signal will be decoded by applying inverse quantization, power compensation, inverse MDCT and gain compensation. Then the sine waves will be synthesized according with their parameters such as frequency, amplitude and phase. Then the residual and the synthesized sine waves will be added together. Optionally, some white noise can be added if specified in the bitstream.

This processing will be repeated for each of 16 subbands. Finally the QMF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal.

Various algorithms are used to improve compression results:

* gain control for reducing pre-echo artifacts
* power compensation for better quality at low bitrates

The following techniques are used in order to make the compressed data smaller:

* variable-lenght ([[Huffman]]) coding
* [[Vector_Quantization|vector quantization]] based on trained tables
* [[Differential_Coding|differential coding]]

Probably the most interesting part of the ATRAC3plus codec is the Generalized Harmonic Analysis (GHA) - an inharmonic frequency analysis proposed by Norbert Wiener in 1930. The main advantage of that is an excellent frequency resolution that surpasses the short-time Discrete Furier transformation. However it requires huge amount of calculations. Several algorithms to work around that problem were introduced during last 20 years, for example the one proposed by Dr.Hirata.

==== Coding methods for compressing bitstream parameters ====

Coding methods described in this section serve the purpose of representing different bitstream parameters like word-length, scale factor etc. using a smaller number of bits. It will be achieved by exploring and removing redundancy from the signals being encoded. The coding techniques described here are [[Lossless_compression|lossless]].

===== Huffman coding =====

ATRAC3plus uses this coding technique widely. There are more than 130 different huffman tables in total for coding bitstream signals. Usually more frequently occuring values will have shorter codes.
ATRAC3plus huffman trees are [http://en.wikipedia.org/wiki/Canonical_Huffman_code canonical ones]. That means those can be stored very compactly by specifying the following parameters:

* number of bits of the shortest codeword
* number of bits of the longest codeword
* number of items for every bit length
* order of items

In my code I'm using the following descriptor in order to specify a canonical huffman table:

uint8_t min; /* shortest codeword length */
uint8_t max; /* longest codeword length */
uint8_t num_items[max - min + 1]; /* number of items for every bit length */

For example, the huffman table vlc_tab_index = 3 [[#Huffman tables for delta coding|here]] will be described as follows:

min = 1
max = 5
num_items[1, 0, 2, 3, 2]

The 2nd element of the array "num_items" is set to "0" because there is no codeword with the length of 2 bits.

The following C-pseudocode can be used for generating huffman tables from the descriptor described above during decoder initialization:

code = 0;
index = 0;

for (num_bits = min; num_bits <= max; num_bits++) {
for (i = num_items[num_bits]; i > 0; i--) {
bits [index] = num_bits;
codes[index] = code++;
index++;
}
code <<= 1;
}

The array "bits" receives length in bits for each codeword, "codes" receives codeword itself.

Finally, the order of codes need to be specified. A simple remapping table will be used to translate the code index into final code. For the table described above the translation table will look as follows:

0, 1, 7, 2, 3, 6, 4, 5

===== Delta coding =====

ATRAC3plus utilizes various delta-coding schemes in order to remove linear correlation from the signal. It often uses the [http://en.wikipedia.org/wiki/Modular_arithmetic modular arithmetic] as well. The main advantage of this coding is that only the half of the range of the difference values is required. An example: word-length information coefficients in the range 0...7 need to be transmitted compactly. Using delta coding this would require to code difference values in the range -7...+7, also 15 values.

In the case of modular arithmetic the range of the difference values can be reduced to 0...7 by introducing a "wrap-around" so that the final equation looks like this:

B = (A + delta) & 7;

Below an example with "wrap around":

Consider we need to code the value B = "1" and the reference value A = "6". Then the difference value (delta) will be = "-5". According with equation above the delta value of "3" can be used instead of "-5":

(6 + 3) & 7 = 1;

Another example without "wrap around":

Consider we need to code the value B = "7" and the reference value A = "2". Then the difference value (delta) will be = "5":

(2 + 5) & 7 = 7;

Further variable-length codes will be used to reduce amount of bits of difference values in accordance with their probability.

The following is a description of the delta-coding methods used in ATRAC3plus:

====== Method A: huffman-coded modulo difference to previous ======

Consider the following signal:

3, 6, 6, 3, 3, 3, 4, 2, 2, 1, 1, 1, 3

Now code it using delta coding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Coefficient !! Modulo delta value !! Huffman code !! Number of bits
|-
| align="center" | 3 || align="center" | - || align="center" | - || align="center" | 3
|-
| align="center" | 6 || align="center" | 3 || align="center" | 11110 || align="center" | 5
|-
| align="center" | 6 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 5 || align="center" | 1101 || align="center" | 4
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 4 || align="center" | 1 || align="center" | 100 || align="center" | 3
|-
| align="center" | 2 || align="center" | 6 || align="center" | 1110 || align="center" | 4
|-
| align="center" | 2 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 7 || align="center" | 101 || align="center" | 3
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 2 || align="center" | 1100 || align="center" | 4
|}

The 1st coefficient has no delta value associated with it because there is no previous value. It will be coded "as is" using fixed length of 3 bits. The following delta values get a variable-length code from the table val_tab_index = 2 [[#Huffman tables for delta coding|here]] so the final number of bits to be transmitted will be = 32.
Compared to the unpacked version (13 x 3 bits = 39 bits) the coding method described above will yield a bit-reduction of 7 bits (18% smaller).

====== Method B: huffman-coded modulo difference to master ======

In a stereo mix the signal of the left channel is often very similar to the signal of the right channel (i.e. there is a high cross-correlation between the channels). In this case the estimated sound parameters like word-length or scale factor will have a high similarity as well. Then coding the differential signal between the channels can lead to a significant bit reduction.
Surely at least the one of the channels must be coded independently. Such a channel will be called "master" (it's usually the left channel but ATRAC3plus has the possibility to make the right channel act like a master as well). For the 2nd channel only the difference to master will be coded. The 2nd channel will be called "slave" in this case.

Below an example of such a high-correlated signal:

Left : 6, 5, 6, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1
Right: 6, 5, 6, 2, 2, 2, 3, 1, 1, 1, 2, 1, 1
Diff : 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0

Coding the difference signal using the table val_tab_index = 0 [[#Huffman tables for delta coding|here]] will result in another signal 15 bits long. Compared to the unpacked version (13 x 3 bits = 39 bits) that coding method will yield a bit-reduction of 24 bits (62% smaller).

====== Method C: shorter delta to min ======

Sometimes coefficients in a signal are very close to each other, so subtracting the minimum value from each coefficient will result in smaller deltas whose can be coded using fewer bits.

An example:

2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1

As one can see the values in the sequence above are very similar to each other. Let us find minimum and maximum values and then determine the number of delta bits:

min = 1; max = 2; num_delta_bits = ilog2(max - min + 1) = 1 bit

Now let us encode the sequence above using shorter deltas:

num_delta_bits = 1 will be coded as a 2-bit value
min = 1 will be coded as a 3-bit value
deltas: 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0

The encoded signal is 5 + 1 x 15 = 20 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 25 bits (55% smaller).

Another example:

1, 2, 3, 2, 4, 2, 1, 2, 3, 3, 1, 4, 4, 1, 1

min = 1; max = 4; num_delta_bits = ilog2(max - min + 1) = 2 bits

Now the encoded signal:

num_delta_bits = 2 (will be coded as a 2-bit value)
min = 1 (will be coded as a 3-bit value)
deltas: 0, 1, 2, 1, 3, 1, 0, 1, 2, 2, 0, 3, 3, 0, 0

The encoded signal is 5 + 2 x 15 = 35 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 10 bits (22% smaller).

====== Method D: sequence of numbers in ascending order ======

Sometimes ATRAC3plus have to deal with sequences of numbers (i.e. gain control position information) where all items are known to be in ascending order (i.e. satisfy the following equation: ''Vn+1 > Vn''). Such sequences can be packed without any additional bitstream information by examining previous value (predecessor), calculating magnitude between it and the maximum value and making the decision about number of bits of the next delta value.

Consider the following sequence:

Position index: 0, 1, 2, 3, 4, 5, 6, 7
---------------------------------------------
Position info : 5, 7, 14, 15, 18, 25, 29, 30
---------------------------------------------
Num delta bits: 5, 5, 5, 4, 4, 3, 1, 0

1st coefficient (position index = 0) will be coded directly using 5 bits because the sequence should start somewhere.
The following coefficients (except one with the value of "30") will be coded according to the following pseudocode:

num_delta_bits = ilog2(31 - prev_val);
if (num_delta_bits == 5)
new_val = get_bits(5);
else
new_val = prev_val + get_bits(num_delta_bits) + 1;

Let us return to our sequence. The 2nd value will be coded directly as well using 5 bits because ilog2(31 - 5) = 5. Similar for the 3rd one. No delta coding is applied in that case. The 4th value will be delta-coded using 4 bits:

num_delta_bits = ilog2(31 - 15) = 4 bits;
delta = 18 - 15 - 1 = 2

And so on until we reach the last value = 30. In this case there is only one value that meets our condition ''Vn+1 > Vn'': the value of "31". In this case no delta will be transmitted and the coming value will be calculated just as:

new_val = prev_val + 1;

Therefore the resulting sequence will be 27 bits long. Compared to the unpacked version (8 x 5 bits = 40 bits) this packing method will yield a bit-reduction of 13 bits (32% smaller).

===== Vector quantization with residual encoding =====

One further packing technique used in ATRAC3plus is based on so-called "shape prediction vectors". Encoder decomposes a signal (word-length or scale factor info) into "shape prediction" + residual. Then only the index of the "shape prediction vector" and the huffman-coded residual will be transmitted. The main advantage of this method is when the shape matches the coded signal closely, the residual can be represented very compactly (usually 1-2 bits per value). Moreover, the majority of values of the residual will turn into zeroes, which can be further packed.

Each entry of the "shape prediction tables" contain an average value over 3 coefficients. This helps to keep those tables comparable small. For example, for a signal of 32 values each "shape table" will have 10 entries (last entry contains usually an average value over 5 coefficients).

Consider the following signal to be encoded:

7, 7, 6, 5, 4, 4, 3, 2, 2, 2, 1, 1

Let us "quantize" that signal by diving it into 4 * 3 groups and find the averaged value in each group:

floor((7 + 7 + 6) / 3 + 0.5) = 7,
floor((5 + 4 + 4) / 3 + 0.5) = 4,
floor((3 + 2 + 2) / 3 + 0.5) = 2,
floor((2 + 1 + 1) / 3 + 0.5) = 1

Find a "shape table" in the trained set that closely matches our "quantized" version. It will be (for example):
7, 5, 2, 1

Now compute the residual:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | Original signal
| style="text-align:center;"| 7
| style="text-align:center;"| 7
| style="text-align:center;"| 6
| style="text-align:center;"| 5
| style="text-align:center;"| 4
| style="text-align:center;"| 4
| 3 || 2 || 2 || 2 || 1 || 1
|-
! bgcolor="#f0f0f0" | Unpacked shape table
| 7 || 7 || 7 || 5 || 5 || 5 || 2 || 2 || 2 || 1 || 1 || 1
|-
! bgcolor="#f0f0f0" | Residual
| 0 || 0 || -1 || 0 || -1 || -1 || 1 || 0 || 0 || 1 || 0 || 0
|}

Now select a huffman table that represents the residual above as small as possible. The following huffman tree assigns the shortest code (1 bit) to the most frequently occuring symbol = "0" and 2-bit codes to the others: "1" and "-1":

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | -1
|}

The packed signal will occupy 21 bits: 4 bits "shape table" index + 17 bits residual(7 bits for "zeroes" + 10 bits for "non-zeroes"). Compared to the unpacked version (12 x 3 bits = 36 bits) this packing method will yield a bit-reduction of 15 bits (42% smaller).

===== Value grouping with "group coded" flag =====

If a signal contains lots of zeroes, grouping several values together and assigning the "group coded" flag to each group will achieve a significant bit-reduction. Consider the following sequence of numbers to be encoded:

0, 0, 1, 2, 0, 0, 3, 3, 0, 0, 0, 7, 0, 6, 0, 0

Let us cluster each two values together and assign the "coded" flag (1 bit) to each group:

(0, 0); flag = 0 (group not coded)
(1, 2); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(3, 3); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(0, 7); flag = 1 (group coded)
(0, 6); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)

Thereafter, each "not coded" group requires only one bit to be transmitted indicating that all values in that group are zero. On the other hand, each "coded" group requires one extra bit to be transmitted indicating that at least one value in that group is non-zero. In the case above that overhead is worthwhile because the half of the signal contains zeroes.

The encoded signal is 4 x 1 + 4 x 7 = 32 bits long while the unpacked one is 16 x 3 = 48 bits long. The bit-reduction is thereafter 16 bits (33% smaller).

== Multichannel ATRAC3plus (ATRAC-X) ==

ATRAC3plus supports multichannel streams (up to 8 channels). Such streams are encoded in units customary called "channel block"; each block contains max. 2 channels (ie can be MONO or STEREO). For example, taking the channel_id = 3 and looking at the table below we have a stream containing 2 channel blocks: 1 stereo + 1 mono and thus 3 channels.
The base codec operates on either MONO or STEREO channel blocks only.

=== ATRAC-X channel configurations ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! channel_id !! total channels !! number of channel blocks !! speaker mapping
|-
| align="center" | 0 || align="center" | 0 || align="center" | undefined ||
* undefined
|-
| align="center" | 1 || align="center" | 1 || align="center" | 1 ||
* front: center (MONO)
|-
| align="center" | 2 || align="center" | 2 || align="center" | 1 ||
* front: L, R (STEREO)
|-
| align="center" | 3 || align="center" | 3 || align="center" | 2 ||
* front: L, R
* front: center
|-
| align="center" | 4 || align="center" | 4 || align="center" | 3 ||
* front: L, R
* front: center
* rear: surround
|-
| align="center" | 5 || align="center" | 5+1 || align="center" | 4 ||
* front: L, R
* front: center
* rear: L, R
* LFE
|-
| align="center" | 6 || align="center" | 6+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* rear: center
* LFE
|-
| align="center" | 7 || align="center" | 7+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* side: L, R
* LFE
|}

== Bitstream overview ==

The table below shows the bitstream organization of ATRAC3plus at the top-level. Depends on [[#ATRAC-X channel configurations|channel configuration]] a typical frame may contain more than one channel block. In this case the additional fields [[#channel_block_type|channel_block_type]] and [[#channel_block_data|channel_block_data]] will be included for each block.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! number of bits !! value !! description
|-
| align="center" | start_marker || align="center" | 1 || align="center" | 0 ||
marks the start of the ATRAC3plus bitstream
|-
| align="center" | channel_block_type || align="center" | 2 ||
* 00b - MONO block
* 01b - STEREO block
* 10b - EXTENSION block
| align="center" | type of the channel block
|-
| align="center" | channel_block_data || align="center" | variable || || align="center" | contains encoded sound information
|-
| align="center" | terminator || align="center" | 2 || align="center" | 11b || align="center" | indicates the end of the bitstream
|}

=== Channel block types ===

There are following channel block types in ATRAC3plus:

* '''Mono channel block''': contains monaural sound data.
* '''Stereo channel block''': contains stereophonic sound data.
* '''Extension block''': as indicated by its name it's intended to carry some extension information. Its purpose is unknown though due to the lack of an official description. All existing decoder implementations are programmed to ignore blocks of that type.

=== Channel block layout ===

ATRAC3plus was designed to provide a high-quality sound compression. Therefore it tries to save as much bits as possible. It uses a new coding scheme for channel blocks compared to ATRAC3: channels in a stereo sound are no more coded separately but rather in one stereo channel block. The bitstream for such a block provides the possibility for both channels to share several sound parameters so that there is no need to transmit the same things twice. Depends on correlation between the channels this can lead to a significant bit reduction and thus improve coding quality.

A mono/stereo channel block contains the following pieces of sound information:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! size in bits !! description
|-
| align="center" | [[#Sound header|sound_header]] || align="center" | 6 || width="700" | defines some global sound parameters
|-
| align="center" | [[#Word-length information|wordlength_info]] || align="center" | variable || quantization word length information for each quant unit
|-
| align="center" | scalefactor_info || align="center" | variable || quantization scale factor indexes for each coded quant unit
|-
| align="center" | codetable_info || align="center" | variable || code table table information for each coded quant unit
|-
| align="center" | spectra || align="center" | variable || huffman-coded spectral information for each coded quant unit
|-
| align="center" | window_info || align="center" | variable || tells which IMDCT window shape should be used during the sound reconstruction
|-
| align="center" | gain_info || align="center" | variable || gain envelope used by the gain compensation
|-
| align="center" | gha_info || align="center" | variable || information about sine-like waves in the compressed sound obtained by the GHA. It contains quantized frequency, amplitude and phase for each wave to be synthesized in the decoder.
|-
| align="center" | noise_info || align="center" | 1/9 || contains noise flag, level index and table selector for the white noise to be added during decoding.
|}

==== Sound header ====

At the start of each channel block the sound header is located. It contains the following fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || num_quant_units || valid values: 0...27,31 || width="500" | number of coded quantization units - 1. The value of "0" indicates one coded unit, the value of "31" - 32 ones. The values 28, 29 and 30 are invalid.
|-
| align="center" | 1 || align="center" | x_flag || || to be figured out
|}

==== Word-length information ====

===== Coding summary =====

Word-length (or quantization precision) information follows the sound header. It defines the word-length parameter for each [[#num_quant_units|coded quantization unit]]. This parameter is in the range 0...7, where the value of "7" indicates the highest quantization precision and the value of "1" - the lowest one. The value of "0" means no data, i.e. the corresponding quantization unit was not coded.

In the case of the stereo channel block the word-length parameters for the channel 1(L) will be transmitted first followed by the the word-length parameters for the channel 2(R). The word-lengths for the channel 1 are always coded independently. The word-lengths for the channel 2 can be coded either independently or relative to the channel 1. In this case the 1st channel is called "master" and the 2nd one - "slave".
The word-lengths for the mono block will be coded just like the channel 1 in the stereo block.

In order to keep the word-length data as small as possible ATRAC3plus uses several coefficient packing techniques achieving different amount of bits needed for transmission:

* the coefficients are coded directly (3 bits value). This means no packing and used at high bitrates because the frame size is big enough to keep the infomation unpacked.

* differential coding + huffman-coded delta: the first coefficient is coded directly; all others are huffman-coded deltas to the previous coefficient.

* prediction + huffman-coded residual: this techniques offers the best packing and used at low bitrates. It's analogous to the lossless coding and based on trained shape tables serving as prediction. Later the huffman-coded residual will be added to the prediction prefectly reconstructing the coefficients.

===== Reconstruction of trimmed word-length coefficients =====

Word-length coefficient of the trailing quantization units corresponding to the high spectral bands tend to be either 1 (low-precision) or 0 (not coded). Such coefficients will be ommited and one the following modes will be used in order to reconstruct their values during decoding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! mode code(2 bits) !! num_coded_vals !! split_point_delta !! Action(master) !! Action(slave)
|-
| align="center" | 0 || align="center" | not present
|rowspan="3" style="text-align:center;" | not present
|colspan="2" style="text-align:center;" | no trimmed coefficients
|-
| align="center" | 1
|rowspan="3" style="text-align:center;" | 5 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients to "0"
|-
| align="center" | 2 || width="220" | set all trimmed coefficients to "1" || width="220" | for each trimmed coefficient read one bit of its direct value
|-
| align="center" | 3 || align="center" | 2 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients up to split point to "1" and after split point - to "0". The split point is calculated differently for master and slave channels (see below)
|}

To calculate the split point from [[#split_point_delta|split_point_delta]] do the following:

* for the master channel: number of zeroes = split_point_delta + 1
* for the slave channel: number of ones = split_point_delta + 3

The following C-pseudocode shows how to parse a bitstream according with the table above:

mode = get_bits(2);
if (mode) {
num_coded_vals = get_bits(5);
if (mode == 3)
split_point_delta = get_bits(2);
} else {
num_coded_vals = [[#num_quant_units|num_quant_units]];
}

The following C-pseudocode shows how to reconstruct trimmed word-length coefficients according with the table above:

switch (mode) {
case 0: /* no further action */
break;
case 1:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
break;
case 2:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++) {
if (channel == master)
wl_coeffs[pos] = 1;
else
wl_coeffs[pos] = get_bits(1);
}
break;
case 3:
if (channel == master)
split_point = [[#num_quant_units|num_quant_units]] - split_point_delta - 1;
else
split_point = num_coded_vals + split_point_delta + 3;

for (pos = num_coded_vals; pos < split_point; pos++)
wl_coeffs[pos] = 1;

for (; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
}

===== Word-length coding in detail =====

The word-length information for each channel will be coded as follows:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! comments
|-
| align="center" | 2 || coding_mode || width="500" | indicates the coding mode used.
|-
| align="center" | variable || align="center" | coeff_info || word-length coefficients coded according with the [[#coding_mode|coding_mode]].
|}

The [[#coding_mode|coding_mode]] parameter may be interpreted differently depends on the channel number. The following pseudocode examples explain the coding modes in detail:

===== Mode 0 (master and slave) =====

All coefficients will be directly coded as follows:

for (i = 0; i < [[#num_quant_units|num_quant_units]]; i++)
wl_coeffs[i] = get_bits(3);

===== Mode 1 (master) =====

Leading "n" values are stored directly while trailing ones are packed using [[#Method C: shorter delta to min|Method C: shorter delta to min]] method.

Data stored in the bitstream:

* 2 bits: index of the table of weigths, "0" - indicates "no table used"
* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 5 bits: number of directly coded coefficients ('''num_direct_coeffs'''). This value must be < [[#num_coded_vals|num_coded_vals]]
* 2 bits: size of deltas in bits ('''delta_bits''')
* 3 bits: minimum value ('''min_value''')
* for each '''num_direct_coeffs'''
** 3 bits: coefficient value
* if '''delta_bits''' > 0: for each ([[#num_coded_vals|num_coded_vals]] - '''num_direct_coeffs''')
** '''delta_bits''': delta value to be added to the '''min_value'''

The following C-pseudocode summarizes all above:

weigths_tab_indx = get_bits(2); /* get index of weights table to be added after decoding */

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

num_direct_coeffs = get_bits(5);
if (num_direct_coeffs > [[#num_coded_vals|num_coded_vals]])
ABORT("Invalid number of directly coded coefficients");

delta_bits = get_bits(2);
min_value = get_bits(3);

for (pos = 0; pos < num_direct_coeffs; pos++)
wl_coeffs[pos] = get_bits(3);

for (; pos < num_coded_vals; pos++) {
if (delta_bits)
wl_coeffs[pos] = min_value + get_bits(delta_bits);
else
wl_coeffs[pos] = min_value;
}

/* reconstruct trimmed coefficients as described [[#Reconstruction of trimmed word-length coefficients|here]] */

/* add weighting coefficients if requested */
if (weigths_tab_indx) {
for (pos = 0; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] += [[#Tables of weights|wl_weights]][channel_num][weights_tab_indx - 1][pos];
}

===== Mode 1 (slave) =====

Coding method: [[#Method B: huffman-coded modulo difference to master|Huffman-coded modulo difference to master]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 2 bits: indicates which huffman table from [[#Huffman tables for delta coding|this set]] should be used for decoding
* for each [[#num_coded_vals|num_coded_vals]]
** huffman-coded delta value to be added to the corresponding value of the master channel

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

vlc_sel = get_bits(2); /* selects a huffman table from [[#Huffman tables for delta coding|this set]] */

for (i = 0; i < [[#num_coded_vals|num_coded_vals]]; i++) {
delta = get_vlc(vlc_sel);
wl_coeffs[i] = (master_ch->wl_coeffs[i] + delta) & 7;
}

===== Mode 2 (master) =====

Coding method: [[#Vector quantization with residual encoding|Vector quantization with residual encoding]] and [[#Value grouping with "group coded" flag|Value grouping with "group coded" flag]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]].
* 1 bit: '''enable_grouping''' flag. "1" indicates that residual values were coded pairwise (in groups of two).
* 1 bit: selects one of the first two huffman tables from [[#Huffman tables for delta coding|this set]].
* 3 bits: '''start_value''' selecting a subset of "shape tables" from the trained set.
* 4 bits: '''shape_index''' selecting a "shape table" within the subset indicated by '''start_value'''.
* for each [[#num_coded_vals|num_coded_vals]]
** if '''enable_grouping''' == 1:
*** 1 bit: '''group_coded''' flag
*** if '''group_coded''' == 1:
**** 2 huffman-coded residual values to be added to the unpacked "shape table" using modular arithmetic
** if '''enable_grouping''' == 0:
*** one huffman-coded residual value to be added to the unpacked "shape table" using modular arithmetic

== Annex A: Decoding tables ==

=== Word-length related tables ===

==== Tables of weights ====

The weights below will be added to the decoded word-length coefficients. The tables are organized as follows:
* [channel_number: 0 or 1][index: 0...2][coeff_indx: 0...31]

wl_weights[2][3][32] = {
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
},
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 5, 5, 5, 5, 3, 3, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
};

==== Huffman tables for delta coding ====

PLEASE NOTE: delta values indicated in the tables below will be added using modular arithmetic as described [[#Delta coding|here]], so in the case of "wrap around" the value of "7" will be treated as "-1", the value of "6" = "-2" and so on.

* '''vlc_tab_index = 0''', delta range -1...1

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | 7
|}

* '''vlc_tab_index = 1''', delta range -2...2

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 2
|-
| align="center" | 110 || align="center" | 3 || align="center" | 6
|-
| align="center" | 111 || align="center" | 3 || align="center" | 7
|}

* '''vlc_tab_index = 2''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 5
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 3
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 4
|}

* '''vlc_tab_index = 3''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 3
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 4
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 5
|}

[[Category:Audio Codecs]]
[[Category: Multichannel Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

GoToMeeting Codec

2013-05-07T08:02:48Z

Maxpol: /* ELS values */

* FourCC: G2M2, G2M3, G2M4
* Company: [http://www.gotomeeting.com GoToMeeting (Citrix)]
* Samples:
** G2M2: http://samples.mplayerhq.hu/V-codecs/G2M2/
** G2M3: http://samples.mplayerhq.hu/V-codecs/G2M3/
** G2M4: http://samples.mplayerhq.hu/V-codecs/G2M4/

This is a codec used to save recordings in GoToMeeting. The codec also calls itself GoToWebinar (see [http://www.gotowebinar.com/ http://www.gotowebinar.com/]).

Win32 binary decoder available here: [http://www.gotomeeting.com/codec http://www.gotomeeting.com/codec]

According to samples, all G2M video frames begin with the characters 'G2M[2-4]', followed by a series of chunks. Each chunk has the following layout:

bytes 0-3 length of chunk payload, not including this length field
byte 4 type of chunk
bytes 5.. remainder of payload, format unknown

Supported chunk types are 0xC8-0xCD.

It appears that the minimum size for a G2M frame (possibly a no-change frame) is 14 bytes. This includes the 4 signature bytes, a 4-byte length indicating a chunk length of 6, and a 6-byte payload of type 0xCA followed by 5 more bytes.

G2M3 is the same as G2M2. G2M4 introduces new compression method but the structure remains the same.

In general frame is divided into the number of tiles and each tile is coded separately. Usual tile size is 192x128 pixels

== Frame structure ==

=== Chunk C8 ===

Display information.

Chunk contents (all values are big-endian):

4 bytes image width
4 bytes image height
4 bytes compression mode (should be 2 or 3)
4 bytes tile width
4 bytes tile height
1 byte colour depth (4, 8, 16, 24 or 32)
for 4/8bpp there is a palette in standard RGBTUPLE format
for 16-32bpp there are four bitmasks for each field

=== Chunk C9 ===

Image update.

1 byte tile position in row
1 byte tile position in column
... compressed data

=== Chunk CA ===

Mouse cursor position.

2 bytes cursor position X
2 bytes cursor position Y
1 byte seems to be always 1

=== Chunk CB ===

Mouse cursor shape:

4 bytes data size
1 byte width
1 byte height
1 byte hotspot x
1 byte hotspot y
... cursor bitmask and its inverse (in M$ format)

=== Chunk CC ===

Maybe some resync chunk, it's supposed to contain only 4-byte value equal to 2000.

=== Chunk CD ===

One dword, something to do with time.

== Video compression methods ==

=== Compression method 1 (ELS image) ===

Vanilla augmented ELS coder is used ([http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=582144 The ELS-coder: a rapid entropy coder]) with 36 jots per byte.

==== ELS values ====

Unsigned values are coded using Exponential Golomb notation:

unary prefix + stop bit + remainder, where number of bits in the prefix = number of bits in the remainder

The unary prefix is coded as n -1 zero bits followed by a one bit. E.g. number 5 will be coded as <code>00 1 10</code>.

Here is the decoding algorithm:

count number of bits in the prefix by reading bits from the arithmetic ELS decoder until a "1" is encountered
n = number of zero bits in the prefix, i.e "001" ==> n = 2
read the remainder r as plain binary number of n bits: "10" ==> 2
value = 2n - 1 + r = 22 - 1 + 2 = 5

Signed values are coded as unsigned ones where the LSB indicates the sign:

if (val & 1)
val = - ((val + 1) >> 1);
else
val = val >> 1;

To make compression better every decoded bit uses a context-depended state, so every bit is decoded this way:

bit = els_decode_bit(ctx, &ctx->current_state->rung);
if (bit) {
if (!ctx->current_state->next1) {
ctx->current_state->next1 = new State();
ctx->current_state->next1->rung = 0;
}
ctx->current_state = ctx->current_state->next1;
} else {
if (!ctx->current_state->next0) {
ctx->current_state->next0 = new State();
ctx->current_state->next0->rung = 0;
}
ctx->current_state = ctx->current_state->next0;
}

==== Single pixel coding ====

Decoding single pixel is performed like this:

if (!x && !y) {
R = decode_vlc();
G = decode_vlc();
B = decode_vlc();
} else if (!x || !y) {
if (!y) {
pR = rgb[x - 1, y].R;
pG = rgb[x - 1, y].G;
pB = rgb[x - 1, y].B;
} else {
pR = rgb[x, y - 1].R;
pG = rgb[x, y - 1].G;
pB = rgb[x, y - 1].B;
}
R = pR + decode_vlc_signed();
G = pG + decode_vlc_signed();
B = pB + decode_vlc_signed();
} else {
G = decode_pred(rgb[x - 1, y].G, rgb[x, y - 1].G, rgb[x - 1, y - 1].G);
R = G + decode_pred(rgb[x - 1, y ].R - rgb[x - 1, y ].G,
rgb[x, y - 1].R - rgb[x, y - 1].G,
rgb[x - 1, y - 1].R - rgb[x - 1, y - 1].G);
B = G + decode_pred(rgb[x - 1, y ].B - rgb[x - 1, y ].G,
rgb[x, y - 1].B - rgb[x, y - 1].G,
rgb[x - 1, y - 1].B - rgb[x - 1, y - 1].G);
}

Where <code>decode_pred(A, B, C)</code> looks like this:

diff = decode_vlc_signed();
if (B < max(A, C)) {
if (B > min(A, C)) {
return A - B + C - diff;
} else {
return max(A, C) - diff;
}
} else {
return min(A, C) - diff;
}

==== Image decoding ====

Image decoding is context-dependent and always tries to check some flags and retrieve pixel value from cache instead of decoding it directly.

Overall decoding scheme:

for (y = 0; y < height; y++) {
x = 0;
while (x < width) {
if (x > 1 && y > 0 &&
rgb[x - 1, y] != rgb[x - 2, y] &&
rgb[x - 1, y] != rgb[x, y - 1] &&
rgb[x - 1, y] != rgb[x - 1, y - 1] &&
rgb[x - 1, y] != rgb[x - 2, y - 1] &&
!pixel_in_cache(rgb[x - 1, y])) {
rgb[x, y] = decode_pixel_with_prediction(x, y);
x++;
continue;
}
decode_run(x, y, &run_length, &pix);
if (run_length > 0) {
// pixel value may get changed here
reuse_top_neighbours_if_possible(x, y, run_length, &pix);
while (run_length--) {
rgb[x, y] = pix;
x++;
}
} else if (x > 0 && decode_from_list(rgb[x - 1, y], &pix)) {
rgb[x, y] = pix;
x++;
} else {
rgb[x, y] = decode_pixel_with_prediction(x, y);
if (x)
add_to_list(pixel_list[rgb[x - 1, y]], rgb[x, y]);
x++;
}
}
}

Run decoding:

run_length = 0;

if (x > 1 && x < width - 1 && y > 1) {
L = rgb[x - 1, y];
LL = rgb[x - 2, y];
TR = rgb[x + 1, y - 1];
T = rgb[x, y - 1];
TL = rgb[x - 1, y - 1];
TLL = rgb[x - 2, y - 1];
TTR = rgb[x + 1, y - 2];
TT = rgb[x, y - 2];
TTL = rgb[x - 1, y - 2];

if (x != ctx->last_run_end) {
idx = (TTL != TL) << 0|
(TT != T) << 1 |
(TTR != TR) << 2 |
(TLL != TL) << 3 |
(TL != T) << 4 |
(TR != T) << 5 |
(TL != L) << 6 |
(LL != L) << 7;
flag = els_decode_bit(ctx->left_context[idx]);
} else {
flag = 1;
}
if (flag)
add_to_cache(L);
else
pixel_val = L;
for (;;) {
if (flag) {
// not perfect
idx = (TTL != TL) << 0|
(TT != T) << 1 |
(TTR != TR) << 2 |
(TLL != TL) << 3 |
(TL != T) << 4 |
(TR != T) << 5 |
(TL != L) << 6 |
(LL != L) << 7;
if (els_decode_bit(ctx->top_context[idx])) {
pixel_val = T;
flag2 = 0;
} else {
if (!pixel_in_cache(T))
add_to_cache(T);
flag2 = 1;
}
} else {
flag2 = (pixel_val != T);
}
x++;
if (x >= width - 1)
break;
update L, LL, LR, T, TL, TLL, TTR, TT and TTL;
if (!flag2 && TL == T && T == TR) {
if (!decode_run_length(&x))
break;
update L, LL, LR, T, TL, TLL, TTR, TT and TTL;
}
idx = (TTL != TL) << 0|
(TT != T) << 1 |
(TTR != TR) << 2 |
(TLL != TL) << 3 |
(TL != T) << 4 |
(TR != T) << 5 |
(TL != L) << 6 |
(LL != L) << 7;
if (els_decode_bit(ctx->left_context[idx]))
break;
}
ctx->last_run_end = x;
run_length = x - old_x;
return !flag;
}
if (x > 0) {
if (!els_decode_bit(ctx->left_flag_ctx)) {
pixel_val = rgb[x - 1, y];
run_length = 1;
} else {
add_to_cache(rgb[x - 1, y]);
}
}
if (y > 0) {
top_pix = rgb[x, y - 1];
if (empty_pixel_cache() || first_pixel_in_cache() != top_pix) {
if (!els_decode_bit(ctx->top_flag_ctx)) {
pixel_val = top_pix;
run_length = 1;
} else {
add_to_cache(top_pix);
}
}
}

Decoding run length (essentially the run on the above line is used as a reference and is either returned immediately or a value not greater than it is decoded):

pos_R = x + 1;
pos_RR = x + 2;
while (pos_RR < width && rgb[pos_RR, y - 1] == rgb[pos_R, y]) {
pos_R++;
pos_RR++;
}
bits = log2_int(pos_R - x);
if (els_decode_bit(ctx->dist_context[bits]))
return pos_R - x;
flag = 0;
bit = 1 << (bits - 1);
mask = 0;
run_length = 0;
while (bits >= 0) {
if (((run_length & mask) | bit) < pos_R - x) {
if (els_decode_bit(flag ? ctx->one_context : ctx->length_context[bits])) {
flag = 1;
run_length |= 1 << bits;
}
}
mask |= bit;
bit >>= 1;
bits--;
}

Reuse neighbours if possible:

if (x > 0 && y > 0) {
TL = rgb[x - 1, y - 1];
L = rgb[x - 1, y];
T = rgb[x, y - 1];
if (TL != L && TL != T && !pixel_is_in_cache(TL)) {
if (els_decode_bit(ctx->TL_context[TL])) {
modify current pixel value to be TL
return
}
add_to_cache(TL);
}
}
if (x + run_size < width - 1 && y > 0) {
TR = rgb[x + 1, y - 1];
T = rgb[x, y - 1];
if (T != TR && !pixel_is_in_cache(TR)) {
if (els_decode_bit(ctx->TR_context[TR])) {
modify current pixel value to be TR
return
}
add_to_cache(TR);
}
}

Decoding from list:

list = get_list_for_pixel(rgb[x - 1, y]);
while (list) {
if (!pixel_is_in_cache(list->pix_val)) {
if (els_decode_bit(list->rung)) {
output_pixel_value = list->pix_val;
remove current entry from the list;
return success;
}
add_to_cache(list->pix_val);
}
list = list->next;
}
return fail;

=== Compression method 2 (ELS image + JPEG) ===

This enhances compression method 1 by separating image into two pictures - the one with sharp details and the one with smooth details. The former is compressed as in compression method 1, the latter is coded as JPEG image. One of the layers can be absent in the tile.

Overall coding is quite simple: ELS layer is coded as first 1x1 image containing value that will be used as a transparent color (i.e. the value that should be replaced with JPEG data) and the whole picture.

JPEG data consists of raw scan data for the baseline JPEG with the standard quantisation matrix and VLCs. Only the macroblocks for the ELS image blocks with transparency are coded (or the whole image when ELS data is not present).

ELS-coded data size
ELS-coded data for transparency pixel
ELS-coded data for whole image
JPEG data

ELS-coded data size:

0xxxxxxx
10xxxxxx xxxxxxxx
110xxxxx xxxxxxxx xxxxxxxx
111xxxxx xxxxxxxx xxxxxxxx xxxxxxxx

=== Compression method 3 (deflated image + JPEG) ===

This method resembles compression method 2 except that ELS image is replaced with simple deflated image and macroblock map (what blocks in image to code) is stored explicitly too.

compression subtype (1 byte)
transparent pixel value (3 bytes)
number of palette entries minus one (1 byte)
palette (3-byte entries)
deflated data size (2 bytes big-endian)
deflated data
JPEG macroblock map
JPEG data

Compression subtype (top 3 bits) tells what exact parts are present and how they should be decoded.

* 0 - fill block with the following pixel value
* 1 - decode JPEG only, only JPEG data is present
* 2 - decode only deflated data, no transparent pixel or JPEG data present
* 3 - all features are present

Deflated image data describes palettised mask image (or "synthetic layer"). The image is also compressed further by using the minimal amount of bits for palette indices (e.g. only 2 bits for 3- or 4-colour images) and every line can be skipped instead of coding.

for (y = 0; y < height; y++, dst += stride) {
if (get_bits(8)) // 'line coded' flag
continue;
for (x = 0; x < width; x++)
dst[x] = get_bit(bits_per_index);
}

JPEG macroblock map consists of byte with the number of macroblocks coded minus one and an array of flags packed into bytes LSB first. Zero bit means that the next macroblock should be skipped, set bit means that the next decoded macroblock should be put here. This array continues until all coded macroblocks are flagges. Right after that information an actual JPEG data is stored.

[[Category:Video Codecs]]
[[Category:Incomplete Video Codecs]]
[[Category:Formats missing in FFmpeg]]
[[Category:Screen Capture Video Codecs]]

Apple ProRes

2011-09-21T01:55:47Z

Maxpol: /* Frame header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | creatorID ||
* 'apl0' -> Apple Inc.
* 'arri' -> Arnold & Richter Cine Technik (A&R)
* 'aja0' -> AJA Kona Hardware
|| FOURCC of the creator of the present stream. Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = chrominance factor (picture format):
** "2" - 422
** "3" - 444
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 1 byte || align="center" | reserved1 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | primaries || align="center" | || Color primaries of the coded image (see the description of the 'nclc' extension by Apple).
|-
| align="center" | 1 byte || align="center" | transf_func || align="center" | || Transfer function of the coded image (see the description of the 'nclc' extension by Apple).
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 4 bits || align="center" | src_pix_fmt ||
* 0 - unknown
* 1 - '2vuy' (8-bit 4:2:2)
* 2 - 'v210' (10-bit 4:2:2)
* 3 - 'v216' (10,12,14,16-bit 4:2:2)
* 4 - 'r408' (8-bit 4:4:4:4 with alpha)
* 5 - 'v408' (8-bit 4:4:4:4 with alpha and super black)
* 6 - 'r4fl' (32-bit floating-point 4:4:4:4)
* 7 - 0x20 (8-bit RGB)
* 8 - 'BGRA' (8-bit RGB with alpha)
* 9 - 'n302' seems to be undocumented
* 10 - 'b64a' (16-bit ARGB)
* 11 - 'R10k' (AJA 10-bit RGB)
* 12 - 'l302' seems to be undocumented
* 13-15 invalid
|| Indicates source pixel format.
|-
| align="center" | 4 bits || align="center" | alpha_info || align="center" | || Used in combination with alpha channel coding.
|-
| align="center" | 1 byte || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Picture layout ===

Each picture has the following layout:

Picture header
------------------------------------
Slice index table
------------------------------------
Slices data

The picture header contains two important parameters: width and height factors of a slice. Therefore, those tell the decoder how the coded picture is subdivided.

Slice index table consists of 16bit entries - one for each slice - giving the length of the data for each slice. Thus, it permits independent processing of the slices in means of multi-threading.

Slices data array contains actual encoded macroblock data.

==== Picture header ====

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | slice_hdr_size || size of this header in bits. Must be at least 48 bits (6 bytes) long.
|-
| align="center" | 1 byte || align="center" | scale_factor || scale factor for scaling the quantization matrices (see below).
|-
| align="center" | 2 bytes || align="center" | luma_data_size || size of the luma bitstream in bytes.
|-
| align="center" | 2 bytes || align="center" | u_data_size || size of the chroma U bitstream in bytes.
|-
|}

Although, the length of the chroma V data is not indcated in the slice header, it can be easily calculated as follows:

v_data_size = slice_data_size from slice index table - luma_data_size - u_data_size - (slice_hdr_size / 8);

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-09-19T01:27:10Z

Maxpol: /* Slice header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | creatorID ||
* 'apl0' -> Apple Inc.
* 'arri' -> Arnold & Richter Cine Technik (A&R)
* 'aja0' -> AJA Kona Hardware
|| FOURCC of the creator of the present stream. Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = chrominance factor (picture format):
** "2" - 422
** "3" - 444
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 3 bytes || align="center" | reserved1 || align="center" | 0 || Ignored in the decoder v1. It has some meaning in the version 2.0 that need to be clarified.
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 2 bytes || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Picture layout ===

Each picture has the following layout:

Picture header
------------------------------------
Slice index table
------------------------------------
Slices data

The picture header contains two important parameters: width and height factors of a slice. Therefore, those tell the decoder how the coded picture is subdivided.

Slice index table consists of 16bit entries - one for each slice - giving the length of the data for each slice. Thus, it permits independent processing of the slices in means of multi-threading.

Slices data array contains actual encoded macroblock data.

==== Picture header ====

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | slice_hdr_size || size of this header in bits. Must be at least 48 bits (6 bytes) long.
|-
| align="center" | 1 byte || align="center" | scale_factor || scale factor for scaling the quantization matrices (see below).
|-
| align="center" | 2 bytes || align="center" | luma_data_size || size of the luma bitstream in bytes.
|-
| align="center" | 2 bits || align="center" | u_data_size || size of the chroma U bitstream in bytes.
|-
|}

Although, the length of the chroma V data is not indcated in the slice header, it can be easily calculated as follows:

v_data_size = slice_data_size from slice index table - luma_data_size - u_data_size - (slice_hdr_size / 8);

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-09-19T01:26:54Z

Maxpol: /* Slice header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | creatorID ||
* 'apl0' -> Apple Inc.
* 'arri' -> Arnold & Richter Cine Technik (A&R)
* 'aja0' -> AJA Kona Hardware
|| FOURCC of the creator of the present stream. Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = chrominance factor (picture format):
** "2" - 422
** "3" - 444
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 3 bytes || align="center" | reserved1 || align="center" | 0 || Ignored in the decoder v1. It has some meaning in the version 2.0 that need to be clarified.
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 2 bytes || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Picture layout ===

Each picture has the following layout:

Picture header
------------------------------------
Slice index table
------------------------------------
Slices data

The picture header contains two important parameters: width and height factors of a slice. Therefore, those tell the decoder how the coded picture is subdivided.

Slice index table consists of 16bit entries - one for each slice - giving the length of the data for each slice. Thus, it permits independent processing of the slices in means of multi-threading.

Slices data array contains actual encoded macroblock data.

==== Picture header ====

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

bits 0-2 unused?
bits 3-7 header size
1 byte quantiser scale (1-224)
2 bytes luma data size
2 bytes U data size

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | slice_hdr_size || size of this header in bits. Must be at least 48 bits (6 bytes) long.
|-
| align="center" | 1 byte || align="center" | scale_factor || scale factor for scaling the quantization matrices (see below).
|-
| align="center" | 2 bytes || align="center" | luma_data_size || size of the luma bitstream in bytes.
|-
| align="center" | 2 bits || align="center" | u_data_size || size of the chroma U bitstream in bytes.
|-
|}

Although, the length of the chroma V data is not indcated in the slice header, it can be easily calculated as follows:

v_data_size = slice_data_size from slice index table - luma_data_size - u_data_size - (slice_hdr_size / 8);

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-09-19T01:19:02Z

Maxpol: /* Field/Picture header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | creatorID ||
* 'apl0' -> Apple Inc.
* 'arri' -> Arnold & Richter Cine Technik (A&R)
* 'aja0' -> AJA Kona Hardware
|| FOURCC of the creator of the present stream. Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = chrominance factor (picture format):
** "2" - 422
** "3" - 444
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 3 bytes || align="center" | reserved1 || align="center" | 0 || Ignored in the decoder v1. It has some meaning in the version 2.0 that need to be clarified.
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 2 bytes || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Picture layout ===

Each picture has the following layout:

Picture header
------------------------------------
Slice index table
------------------------------------
Slices data

The picture header contains two important parameters: width and height factors of a slice. Therefore, those tell the decoder how the coded picture is subdivided.

Slice index table consists of 16bit entries - one for each slice - giving the length of the data for each slice. Thus, it permits independent processing of the slices in means of multi-threading.

Slices data array contains actual encoded macroblock data.

==== Picture header ====

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

bits 0-2 unused?
bits 3-7 header size
1 byte quantiser scale (1-224)
2 bytes luma data size
2 bytes U data size

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-09-19T00:55:56Z

Maxpol: /* Frame header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | creatorID ||
* 'apl0' -> Apple Inc.
* 'arri' -> Arnold & Richter Cine Technik (A&R)
* 'aja0' -> AJA Kona Hardware
|| FOURCC of the creator of the present stream. Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = chrominance factor (picture format):
** "2" - 422
** "3" - 444
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 3 bytes || align="center" | reserved1 || align="center" | 0 || Ignored in the decoder v1. It has some meaning in the version 2.0 that need to be clarified.
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 2 bytes || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Field/Picture header ===

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

bits 0-2 unused?
bits 3-7 header size
1 byte quantiser scale (1-224)
2 bytes luma data size
2 bytes U data size

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-09-19T00:50:49Z

Maxpol: /* Frame header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | creatorID ||
* 'apl0' -> Apple Inc.
* 'arri' -> Arnold & Richter Cine Technik (A&R)
* 'aja0' -> AJA Kona Hardware
|| FOURCC of the creator of the present stream. Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = sample depth?
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 3 bytes || align="center" | reserved1 || align="center" | 0 || Ignored in the decoder v1. It has some meaning in the version 2.0 that need to be clarified.
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 2 bytes || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Field/Picture header ===

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

bits 0-2 unused?
bits 3-7 header size
1 byte quantiser scale (1-224)
2 bytes luma data size
2 bytes U data size

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-09-19T00:49:28Z

Maxpol: /* Frame header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | creatorID ||
* 'apl0' -> Apple Inc.
* 'arri' -> Arnold & richter Cine Technik (A&R)
* 'aja0' -> AJA Kona Hardware
|| FOURCC of the creator of the present stream. Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = sample depth?
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 3 bytes || align="center" | reserved1 || align="center" | 0 || Ignored in the decoder v1. It has some meaning in the version 2.0 that need to be clarified.
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 2 bytes || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Field/Picture header ===

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

bits 0-2 unused?
bits 3-7 header size
1 byte quantiser scale (1-224)
2 bytes luma data size
2 bytes U data size

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-09-19T00:43:51Z

Maxpol: /* Field/Picture header */

* FourCCs used to indicate different ProRes flavours in the [[QuickTime_container|QuickTime]] container:
** Apple ProRes 422 High Quality: 'apch' ('hcpa' in little-endian)
** Apple ProRes 422 Standard Definition: 'apcn' ('ncpa' in little-endian)
** Apple ProRes 422 LT: 'apcs' ('scpa' in little-endian)
** Apple ProRes 422 Proxy: 'apco' ('ocpa' in little-endian)
** Apple ProRes 4444: 'ap4h' ('h4pa' in little-endian)
* Company: [[Apple]]
* Whitepaper: http://web.archive.org/web/20101205002240/http://images.apple.com/finalcutstudio/resources/white_papers/L342568A_ProRes_WP.pdf
* New Whitepaper introducing ProRes LT/Proxy/4444: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
* Samples: http://samples.mplayerhq.hu/V-codecs/HCPA/

= ProRes Introduction =

Apple ProRes is a family of proprietary video codecs used for storing and editing high definition video data in Apple's Final Cut Pro. Apple's official whitepaper lists the codec's key features as being:

* intra-only codecs
* visually lossless compression (i.e. compressed images cannot be distinguished from the original by a human observer)
* 4:2:2 / 4:4:4:4 source material
* 10-bit (12-bit for ProRes 4444) sample depth
* variable bitrate

= ProRes 422 Standard Definition / High Quality codec =

ProRes 422 SD/HQ is the same codec operating on two different bitrates (flavours). Two different FOURCCs are used in order to indicate each flavour:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Flavour name !! FOURCC !! Bitrate
|-
| align="center" | Standard Definition (SD) || align="center" | 'apcn' || align="center" | 145 Mbps
|-
| align="center" | High Quality (HQ) || align="center" | 'apch' || align="center" | 220 Mbps
|}

ProRes algorithm is based on the [[Discrete_Cosine_Transform | Discrete cosine transform]] (further DCT) and utilizes the following compression techniques:

* custom hybrid [[Golomb|Golomb-Rice]] / [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exponential Golomb] coding for DCT coefficients
* [[Run_Length_Encoding|run-length coding]]
* [[Differential_Coding|differential coding]]
* [[Scalar_Quantization|scalar quantization]]

The bitstream of the ProRes 422 has been designed to provide the following additional features:

* frame-level multi-threaded encoding/decoding depending on available CPU cores
* spatial scalability providing the possibility to decode a video at different partial resolutions (1/2, 1/4, 1/8 of the full size and so on). ProRes is capable of saving CPU cycles while decoding at smaller resolutions due to a special bitstream layout enabling partial bitstream access and parsing.

== Binary packages and compatibility ==

ProRes codec is currently available as the following binary libraries:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Lib Name !! Version !! Supported OS !! Supported Architecture !! Encoding !! Decoding
|-
| align="center" | AppleProRes422.component || align="center" | 1.0.2 (Build 46) || align="center" | Mac OS X || align="center" | PowerPC || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.qtx || align="center" | 1.0.0.1 || align="center" | Windows || align="center" | x86 || align="center" | No || align="center" | Yes
|-
| align="center" | AppleProResCodec.component || align="center" | 2.0 (Build 224) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | Yes || align="center" | Yes
|-
| align="center" | AppleProResDecoder.component || align="center" | 2.0.1 (Build 227) || align="center" | Mac OS X || align="center" | PowerPC/x86 || align="center" | No || align="center" | Yes
|-
| align="center" | [http://support.apple.com/kb/DL1396 AppleProResDecoder.component] || align="center" | 3.0.0 || align="center" | Mac OS X || align="center" | x86 || align="center" | No || align="center" | Yes
|}

== Frame layout ==

A typical ProRes 422 frame has the following layout:

Frame container atom
------------------------------------
Frame header
------------------------------------
Picture 1
------------------------------------
Picture 2 (interlaced frames only)

=== Frame container atom ===

At the beginning of each frame the frame container atom is located. It has the classical QuickTime atom structure with the ID set to the undocumented ProRes frame type ID:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 4 bytes || align="center" | size || align="center" | frame size in bytes
|-
| align="center" | 4 bytes || align="center" | type || align="center" | 'icpf' ("image codec prores frame"?)
|}

All data is stored in the big-endian format. The value of the field "size" must match frame size from the movie container.

=== Frame header ===

A frame header stores description information, such as frame dimension, frame structure (progressive/interlaced), color information and the like.
All data is stored in the big-endian format.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Value !! Description
|-
| align="center" | 2 bytes || align="center" | hdrSize || || size of this header in bytes. Must be at least 28 bytes long.
|-
| align="center" | 2 bytes || align="center" | version ||
* "0" - supported in all known decoders
* "1" - supported in the version 2.0 only
|| header version.
|-
| align="center" | 4 bytes || align="center" | vendorID? || align="center" | 'apl0' || Ignored in all known decoders.
|-
| align="center" | 2 bytes || align="center" | frameWidth || || Width of encoded frame.
|-
| align="center" | 2 bytes || align="center" | frameHeight || || Height of encoded frame.
|-
| align="center" | 1 byte || align="center" | frameFlags ||
layout: AAxxBBxx where
* bits AA = sample depth?
* bits BB = frame type:
** "0" - progressive
** "1" - interlaced (top-field first)
** "2" - interlaced (bottom-field first)
|| Frame structure flags.
|-
| align="center" | 3 bytes || align="center" | reserved1 || align="center" | 0 || Ignored in the decoder v1. It has some meaning in the version 2.0 that need to be clarified.
|-
| align="center" | 1 byte || align="center" | colorMatrix ||
* "1" = ITU-R BT.709-2 / SMPTE 274M-1995 / SMPTE 296M-1997
* "6" = ITU-R BT.601-4 / SMPTE 170M-1994 / SMPTE 293M-1996
|| Color matrix ID for color conversion between YUV and RGB (see below).
|-
| align="center" | 2 bytes || align="center" | reserved2 || align="center" | 0 || Ignored.
|-
| align="center" | 1 byte || align="center" | QMatFlags ||
layout: xxxxxxCD where
* bit C = 1 -> custom [[#QMatLuma|luma quant matrix]] present
* bit D = 1 -> custom [[#QMatChroma|chroma quant matrix]] present
|| Custom quantization matrices presence indicators.
|-
| align="center" | 64 bytes || align="center" | QMatLuma || || Custom quantization matrix for luminance. Only present if indicated by the bit "C" of the [[#QMatFlags|QMatFlags]].
|-
| align="center" | 64 bytes || align="center" | QMatChroma || || Custom quantization matrix for chrominance. Only present if indicated by the bit "D" of the [[#QMatFlags|QMatFlags]].
|}

=== Field/Picture header ===

This header is present for every picture (field).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Field size !! Field name !! Description
|-
| align="center" | 1 byte || align="center" | pic_hdr_size || size of this header in bits. Must be at least 64 bits (8 bytes) long.
|-
| align="center" | 4 bytes || align="center" | pic_data_size || size of the picture data in bytes.
|-
| align="center" | 2 bytes || align="center" | total_slices || total number of slices in the picture.
At the same times it indicates the number of entries in the slice table.
|-
| align="center" | 4 bits || align="center" | slice_width_factor || slice width = 2 ^ slice_width_factor. Supported slice sizes are therefore 8, 4, 2 and 1 macroblocks wide.
|-
| align="center" | 4 bits || align="center" | slice_height_factor || Ideally slice height = 2 ^ slice_height_factor but in all known decoders only the value of "0" for that factor is allowed.
Thus, only one slice height = 1 macroblock is supported.
|-
|}

=== Slice coding ===

==== Slice header ====

bits 0-2 unused?
bits 3-7 header size
1 byte quantiser scale (1-224)
2 bytes luma data size
2 bytes U data size

==== Codeword encoding scheme ====

Every codeword is encoded as Rice code with three parameters defining coding parameters: maximum prefix length for Rice codes (<code>MP</code>), Rice code parameter (<code>R</code>) and Elias gamma (aka exp-Golomb) code parameter (<code>G</code>).

Decoding process is the following: read unary prefix, if its value more than <code>MP</code> then treat code as Elias gamma, otherwise treat it as Rice code (or pure unary for <code>R</code>=0).

n = get_unary();
if (n > MP) {
val = get_bits(G + (n - MP - 1)) + ((MP + 1) << R);
} else if (R) {
val = (1 << n) | get_bits(R);
} else {
val = n;
}

Coding parameters are packed into one byte:

bits 0-1 MP
bits 2-4 G
bits 5-7 R

So further this byte value will be used to denote parameters.

==== Overall slice coding ====

Add data in slices is stored grouped: data for luma blocks is stored first, for chroma blocks last.
Inside blocks DC coefficients are stored first, then AC coefficients.

==== DC coding scheme ====

DC values are delta-coded. First value and the first difference value are coded with fixed parameters, others depend on previous raw code:

dc_code_params[] = {0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 0x70 };

code = get_code(0xB8);
dc[0] = (code >> 1) ^ -(code & 1);

code = 5;
sign = 0;
for (i = 1; i < num_dcs; i++) {
code = get_code(dc_code_params[min(code, 6)]);
sign ^= -(code & 1);
dc[i] = dc[i - 1] + (((code + 1) >> 1) ^ sign) - sign;
}

==== AC coding scheme ====

AC coefficients from all blocks are coded together as single <code>(skip, val, sign)</code> stream interleaved (i.e. all coefficients at position 1 first, then all coefficients at position 2, etc.).
And again parameters for coding next value are selected depending on previous decoded value:

skip_code_params[] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29, 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
level_code_params[] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28, 0x28, 0x28, 0x28, 0x4C };

pos = num_blocks;
skip = 4;
level = 2;
while (pos < 64 * num_blocks && has_bits_left()) {
skip = get_code(skip_code_params[min(skip, 15)]);
level = get_code(level_code_params[min(level, 9)]) + 1;
sign = get_bit();

pos += skip + 1;
block[pos % num_blocks][scan[pos / num_blocks]] = sign ? -val : val;
}

==== Unquantising ====

DC = 4096 + ((dc_val * quant_matrix[0] * quant_mul) >> 2);

AC = (ac_val * quant_matrix[i] * quant_mul) >> 2;

Base quantising matrices are given in frame header, quantising multiplier is given in each slice header.

==== Scan order ====

Progressive:

0, 1, 8, 9, 2, 3, 10, 11,
16, 17, 24, 25, 18, 19, 26, 27,
4, 5, 12, 20, 13, 6, 7, 14,
21, 28, 29, 22, 15, 23, 30, 31,
32, 33, 40, 48, 41, 34, 35, 42,
49, 56, 57, 50, 43, 36, 37, 44,
51, 58, 59, 52, 45, 38, 39, 46,
53, 60, 61, 54, 47, 55, 62, 63

Interlaced:

0, 8, 1, 9, 16, 24, 17, 25,
2, 10, 3, 11, 18, 26, 19, 27,
32, 40, 33, 34, 41, 48, 56, 49,
42, 35, 43, 50, 57, 58, 51, 59,
4, 12, 5, 6, 13, 20, 28, 21,
14, 7, 15, 22, 29, 36, 44, 37,
30, 23, 31, 38, 45, 52, 60, 53,
46, 39, 47, 54, 61, 62, 55, 63,

[[Category:Video Codecs]]

Apple ProRes

2011-06-17T11:23:58Z

Maxpol: /* Frame layout */

Apple ProRes

2011-06-17T11:23:17Z

Maxpol: /* Binary packages and compatibility */

ATRAC3plus

2010-12-30T22:34:20Z

Maxpol: /* Huffman tables for delta coding */

* Format tag: uses WAVE_FORMAT_EXTENSIBLE with the "SubFormat" field set to the following [[GUID]]: E923AABF-CB58-4471-A119-FFFA01E4CE62
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3+/
* Stored in: [[Microsoft_Wave|WAV]] and [[Oma|Oma/Omg]] containers.
* Official information: http://www.sony.net/Products/ATRAC3/tech/atrac3plus.html

= ATRAC3plus introduction =

ATRAC3plus is a proprietary audio compression algorithm developed by [[Sony]]. As in the case of ATRAC3 ATRAC3plus represents the next generation of the ATRAC codec introduced in 1992 with the MiniDisc. Common use of that codec is in nowel Minidisc players and Portable Playstations made by [[Sony]].

Streams coded with ATRAC3plus are usually stored either in the [[Microsoft_Wave|WAV]] container (those files have the ".at3" extension though) or in the Sony's proprietary [[Oma|Oma/Omg]] container. In the case of the [[Microsoft_Wave|WAV]] container the undocumented [[GUID]]:
E923AABF-CB58-4471-A119-FFFA01E4CE62
is used in order to indicate the ATRAC3plus codec.

There is very limited number of software products supporting encoding/decoding of the ATRAC3plus streams; most of them are unfortunately available for [[Microsoft]] Windows only. Those are:

* Sony's own SonicStage software (Windows only)
* ATRAC Codec Plugin for Sony Media Software (Windows only)
* Sonic Studio's expensive N-code plugin for professionals (available for Windows and Mac OS X)

There is a multi-channel version of ATRAC3plus called "ATRAC-X".

= ATRAC3plus technical documentation =

=== Available bitrates ===

ATRAC3plus operates on fixed bitrates only. The following bitrates are offered by the Sony Encoding software:

bitrate frame size (stereo)
------------- -------------------
48 Kbps 280 bytes
64 Kbps 376 bytes
96 Kbps 560 bytes
128 Kbps 744 bytes
160 Kbps 936 bytes
192 Kbps 1120 bytes
256 Kbps 1488 bytes
320 Kbps 1864 bytes
352 Kbps 2048 bytes

=== Coding techniques ===

ATRAC3plus is a hybrid subband/MDCT codec like [[MP3]]. The signal is split into 16 subbands using [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filter] before MDCT and bit allocation. The sample-frame size is 2048 samples per channel.

After the subband splitting ATRAC3plus tries to extract sine waves from each subband using Generalized Harmonic Analysis (further GHA). GHA encodes parameters of extracted sine waves such as frequency, amplitude and phase into final bitstream.

After the sine waves extraction the remained signal (residual) will be transformed into frequency domain by a 128-point [http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform Modified discrete cosine transform]. The resultet MDCT spectrum will be devided into 32 quantization units of unequal width (higher frequencies - wider units). The relationship between QMF bands and quantization units (QU) is shown in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | QMF subband
| colspan="8" style="text-align:center;"| 0
| colspan="4" style="text-align:center;"| 1
| colspan="4" style="text-align:center;"| 2
| colspan="2" style="text-align:center;"| 3
| colspan="2" style="text-align:center;"| 4
| colspan="2" style="text-align:center;"| 5
| 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | Quant unit
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|}

The flowchart of the ATRAC3plus decoding process is shown below:

[[image:Atrac3plus_decoder_flow.png]]

"Bitstream decoder" decodes various sound parameters from supplied frame data. First the residual signal will be decoded by applying inverse quantization, power compensation, inverse MDCT and gain compensation. Then the sine waves will be synthesized according with their parameters such as frequency, amplitude and phase. Then the residual and the synthesized sine waves will be added together. Optionally, some white noise can be added if specified in the bitstream.

This processing will be repeated for each of 16 subbands. Finally the QMF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal.

Various algorithms are used to improve compression results:

* gain control for reducing pre-echo artifacts
* power compensation for better quality at low bitrates

The following techniques are used in order to make the compressed data smaller:

* variable-lenght ([[Huffman]]) coding
* [[Vector_Quantization|vector quantization]] based on trained tables
* [[Differential_Coding|differential coding]]

Probably the most interesting part of the ATRAC3plus codec is the Generalized Harmonic Analysis (GHA) - an inharmonic frequency analysis proposed by Norbert Wiener in 1930. The main advantage of that is an excellent frequency resolution that surpasses the short-time Discrete Furier transformation. However it requires huge amount of calculations. Several algorithms to work around that problem were introduced during last 20 years, for example the one proposed by Dr.Hirata.

==== Coding methods for compressing bitstream parameters ====

Coding methods described in this section serve the purpose of representing different bitstream parameters like word-length, scale factor etc. using a smaller number of bits. It will be achieved by exploring and removing redundancy from the signals being encoded. The coding techniques described here are [[Lossless_compression|lossless]].

===== Huffman coding =====

ATRAC3plus uses this coding technique widely. There are more than 130 different huffman tables in total for coding bitstream signals. Usually more frequently occuring values will have shorter codes.
ATRAC3plus huffman trees are [http://en.wikipedia.org/wiki/Canonical_Huffman_code canonical ones]. That means those can be stored very compactly by specifying the following parameters:

* number of bits of the shortest codeword
* number of bits of the longest codeword
* number of items for every bit length
* order of items

In my code I'm using the following descriptor in order to specify a canonical huffman table:

uint8_t min; /* shortest codeword length */
uint8_t max; /* longest codeword length */
uint8_t num_items[max - min + 1]; /* number of items for every bit length */

For example, the huffman table vlc_tab_index = 3 [[#Huffman tables for delta coding|here]] will be described as follows:

min = 1
max = 5
num_items[1, 0, 2, 3, 2]

The 2nd element of the array "num_items" is set to "0" because there is no codeword with the length of 2 bits.

The following C-pseudocode can be used for generating huffman tables from the descriptor described above during decoder initialization:

code = 0;
index = 0;

for (num_bits = min; num_bits <= max; num_bits++) {
for (i = num_items[num_bits]; i > 0; i--) {
bits [index] = num_bits;
codes[index] = code++;
index++;
}
code <<= 1;
}

The array "bits" receives length in bits for each codeword, "codes" receives codeword itself.

Finally, the order of codes need to be specified. A simple remapping table will be used to translate the code index into final code. For the table described above the translation table will look as follows:

0, 1, 7, 2, 3, 6, 4, 5

===== Delta coding =====

ATRAC3plus utilizes various delta-coding schemes in order to remove linear correlation from the signal. It often uses the [http://en.wikipedia.org/wiki/Modular_arithmetic modular arithmetic] as well. The main advantage of this coding is that only the half of the range of the difference values is required. An example: word-length information coefficients in the range 0...7 need to be transmitted compactly. Using delta coding this would require to code difference values in the range -7...+7, also 15 values.

In the case of modular arithmetic the range of the difference values can be reduced to 0...7 by introducing a "wrap-around" so that the final equation looks like this:

B = (A + delta) & 7;

Below an example with "wrap around":

Consider we need to code the value B = "1" and the reference value A = "6". Then the difference value (delta) will be = "-5". According with equation above the delta value of "3" can be used instead of "-5":

(6 + 3) & 7 = 1;

Another example without "wrap around":

Consider we need to code the value B = "7" and the reference value A = "2". Then the difference value (delta) will be = "5":

(2 + 5) & 7 = 7;

Further variable-length codes will be used to reduce amount of bits of difference values in accordance with their probability.

The following is a description of the delta-coding methods used in ATRAC3plus:

====== Method A: huffman-coded modulo difference to previous ======

Consider the following signal:

3, 6, 6, 3, 3, 3, 4, 2, 2, 1, 1, 1, 3

Now code it using delta coding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Coefficient !! Modulo delta value !! Huffman code !! Number of bits
|-
| align="center" | 3 || align="center" | - || align="center" | - || align="center" | 3
|-
| align="center" | 6 || align="center" | 3 || align="center" | 11110 || align="center" | 5
|-
| align="center" | 6 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 5 || align="center" | 1101 || align="center" | 4
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 4 || align="center" | 1 || align="center" | 100 || align="center" | 3
|-
| align="center" | 2 || align="center" | 6 || align="center" | 1110 || align="center" | 4
|-
| align="center" | 2 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 7 || align="center" | 101 || align="center" | 3
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 2 || align="center" | 1100 || align="center" | 4
|}

The 1st coefficient has no delta value associated with it because there is no previous value. It will be coded "as is" using fixed length of 3 bits. The following delta values get a variable-length code from the table val_tab_index = 2 [[#Huffman tables for delta coding|here]] so the final number of bits to be transmitted will be = 32.
Compared to the unpacked version (13 x 3 bits = 39 bits) the coding method described above will yield a bit-reduction of 7 bits (18% smaller).

====== Method B: huffman-coded modulo difference to master ======

In a stereo mix the signal of the left channel is often very similar to the signal of the right channel (i.e. there is a high cross-correlation between the channels). In this case the estimated sound parameters like word-length or scale factor will have a high similarity as well. Then coding the differential signal between the channels can lead to a significant bit reduction.
Surely at least the one of the channels must be coded independently. Such a channel will be called "master" (it's usually the left channel but ATRAC3plus has the possibility to make the right channel act like a master as well). For the 2nd channel only the difference to master will be coded. The 2nd channel will be called "slave" in this case.

Below an example of such a high-correlated signal:

Left : 6, 5, 6, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1
Right: 6, 5, 6, 2, 2, 2, 3, 1, 1, 1, 2, 1, 1
Diff : 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0

Coding the difference signal using the table val_tab_index = 0 [[#Huffman tables for delta coding|here]] will result in another signal 15 bits long. Compared to the unpacked version (13 x 3 bits = 39 bits) that coding method will yield a bit-reduction of 24 bits (62% smaller).

====== Method C: shorter delta to min ======

Sometimes coefficients in a signal are very close to each other, so subtracting the minimum value from each coefficient will result in smaller deltas whose can be coded using fewer bits.

An example:

2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1

As one can see the values in the sequence above are very similar to each other. Let us find minimum and maximum values and then determine the number of delta bits:

min = 1; max = 2; num_delta_bits = ilog2(max - min + 1) = 1 bit

Now let us encode the sequence above using shorter deltas:

num_delta_bits = 1 will be coded as a 2-bit value
min = 1 will be coded as a 3-bit value
deltas: 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0

The encoded signal is 5 + 1 x 15 = 20 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 25 bits (55% smaller).

Another example:

1, 2, 3, 2, 4, 2, 1, 2, 3, 3, 1, 4, 4, 1, 1

min = 1; max = 4; num_delta_bits = ilog2(max - min + 1) = 2 bits

Now the encoded signal:

num_delta_bits = 2 (will be coded as a 2-bit value)
min = 1 (will be coded as a 3-bit value)
deltas: 0, 1, 2, 1, 3, 1, 0, 1, 2, 2, 0, 3, 3, 0, 0

The encoded signal is 5 + 2 x 15 = 35 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 10 bits (22% smaller).

====== Method D: sequence of numbers in ascending order ======

Sometimes ATRAC3plus have to deal with sequences of numbers (i.e. gain control position information) where all items are known to be in ascending order (i.e. satisfy the following equation: ''Vn+1 > Vn''). Such sequences can be packed without any additional bitstream information by examining previous value (predecessor), calculating magnitude between it and the maximum value and making the decision about number of bits of the next delta value.

Consider the following sequence:

Position index: 0, 1, 2, 3, 4, 5, 6, 7
---------------------------------------------
Position info : 5, 7, 14, 15, 18, 25, 29, 30
---------------------------------------------
Num delta bits: 5, 5, 5, 4, 4, 3, 1, 0

1st coefficient (position index = 0) will be coded directly using 5 bits because the sequence should start somewhere.
The following coefficients (except one with the value of "30") will be coded according to the following pseudocode:

num_delta_bits = ilog2(31 - prev_val);
if (num_delta_bits == 5)
new_val = get_bits(5);
else
new_val = prev_val + get_bits(num_delta_bits) + 1;

Let us return to our sequence. The 2nd value will be coded directly as well using 5 bits because ilog2(31 - 5) = 5. Similar for the 3rd one. No delta coding is applied in that case. The 4th value will be delta-coded using 4 bits:

num_delta_bits = ilog2(31 - 15) = 4 bits;
delta = 18 - 15 - 1 = 2

And so on until we reach the last value = 30. In this case there is only one value that meets our condition ''Vn+1 > Vn'': the value of "31". In this case no delta will be transmitted and the coming value will be calculated just as:

new_val = prev_val + 1;

Therefore the resulting sequence will be 27 bits long. Compared to the unpacked version (8 x 5 bits = 40 bits) this packing method will yield a bit-reduction of 13 bits (32% smaller).

===== Vector quantization with residual encoding =====

One further packing technique used in ATRAC3plus is based on so-called "shape prediction vectors". Encoder decomposes a signal (word-length or scale factor info) into "shape prediction" + residual. Then only the index of the "shape prediction vector" and the huffman-coded residual will be transmitted. The main advantage of this method is when the shape matches the coded signal closely, the residual can be represented very compactly (usually 1-2 bits per value). Moreover, the majority of values of the residual will turn into zeroes, which can be further packed.

Each entry of the "shape prediction tables" contain an average value over 3 coefficients. This helps to keep those tables comparable small. For example, for a signal of 32 values each "shape table" will have 10 entries (last entry contains usually an average value over 5 coefficients).

Consider the following signal to be encoded:

7, 7, 6, 5, 4, 4, 3, 2, 2, 2, 1, 1

Let us "quantize" that signal by diving it into 4 * 3 groups and find the averaged value in each group:

floor((7 + 7 + 6) / 3 + 0.5) = 7,
floor((5 + 4 + 4) / 3 + 0.5) = 4,
floor((3 + 2 + 2) / 3 + 0.5) = 2,
floor((2 + 1 + 1) / 3 + 0.5) = 1

Find a "shape table" in the trained set that closely matches our "quantized" version. It will be (for example):
7, 5, 2, 1

Now compute the residual:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | Original signal
| style="text-align:center;"| 7
| style="text-align:center;"| 7
| style="text-align:center;"| 6
| style="text-align:center;"| 5
| style="text-align:center;"| 4
| style="text-align:center;"| 4
| 3 || 2 || 2 || 2 || 1 || 1
|-
! bgcolor="#f0f0f0" | Unpacked shape table
| 7 || 7 || 7 || 5 || 5 || 5 || 2 || 2 || 2 || 1 || 1 || 1
|-
! bgcolor="#f0f0f0" | Residual
| 0 || 0 || -1 || 0 || -1 || -1 || 1 || 0 || 0 || 1 || 0 || 0
|}

Now select a huffman table that represents the residual above as small as possible. The following huffman tree assigns the shortest code (1 bit) to the most frequently occuring symbol = "0" and 2-bit codes to the others: "1" and "-1":

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | -1
|}

The packed signal will occupy 21 bits: 4 bits "shape table" index + 17 bits residual(7 bits for "zeroes" + 10 bits for "non-zeroes"). Compared to the unpacked version (12 x 3 bits = 36 bits) this packing method will yield a bit-reduction of 15 bits (42% smaller).

===== Value grouping with "group coded" flag =====

If a signal contains lots of zeroes, grouping several values together and assigning the "group coded" flag to each group will achieve a significant bit-reduction. Consider the following sequence of numbers to be encoded:

0, 0, 1, 2, 0, 0, 3, 3, 0, 0, 0, 7, 0, 6, 0, 0

Let us cluster each two values together and assign the "coded" flag (1 bit) to each group:

(0, 0); flag = 0 (group not coded)
(1, 2); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(3, 3); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(0, 7); flag = 1 (group coded)
(0, 6); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)

Thereafter, each "not coded" group requires only one bit to be transmitted indicating that all values in that group are zero. On the other hand, each "coded" group requires one extra bit to be transmitted indicating that at least one value in that group is non-zero. In the case above that overhead is worthwhile because the half of the signal contains zeroes.

The encoded signal is 4 x 1 + 4 x 7 = 32 bits long while the unpacked one is 16 x 3 = 48 bits long. The bit-reduction is thereafter 16 bits (33% smaller).

== Multichannel ATRAC3plus (ATRAC-X) ==

ATRAC3plus supports multichannel streams (up to 8 channels). Such streams are encoded in units customary called "channel block"; each block contains max. 2 channels (ie can be MONO or STEREO). For example, taking the channel_id = 3 and looking at the table below we have a stream containing 2 channel blocks: 1 stereo + 1 mono and thus 3 channels.
The base codec operates on either MONO or STEREO channel blocks only.

=== ATRAC-X channel configurations ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! channel_id !! total channels !! number of channel blocks !! speaker mapping
|-
| align="center" | 0 || align="center" | 0 || align="center" | undefined ||
* undefined
|-
| align="center" | 1 || align="center" | 1 || align="center" | 1 ||
* front: center (MONO)
|-
| align="center" | 2 || align="center" | 2 || align="center" | 1 ||
* front: L, R (STEREO)
|-
| align="center" | 3 || align="center" | 3 || align="center" | 2 ||
* front: L, R
* front: center
|-
| align="center" | 4 || align="center" | 4 || align="center" | 3 ||
* front: L, R
* front: center
* rear: surround
|-
| align="center" | 5 || align="center" | 5+1 || align="center" | 4 ||
* front: L, R
* front: center
* rear: L, R
* LFE
|-
| align="center" | 6 || align="center" | 6+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* rear: center
* LFE
|-
| align="center" | 7 || align="center" | 7+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* side: L, R
* LFE
|}

== Bitstream overview ==

The table below shows the bitstream organization of ATRAC3plus at the top-level. Depends on [[#ATRAC-X channel configurations|channel configuration]] a typical frame may contain more than one channel block. In this case the additional fields [[#channel_block_type|channel_block_type]] and [[#channel_block_data|channel_block_data]] will be included for each block.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! number of bits !! value !! description
|-
| align="center" | start_marker || align="center" | 1 || align="center" | 0 ||
marks the start of the ATRAC3plus bitstream
|-
| align="center" | channel_block_type || align="center" | 2 ||
* 00b - MONO block
* 01b - STEREO block
* 10b - EXTENSION block
| align="center" | type of the channel block
|-
| align="center" | channel_block_data || align="center" | variable || || align="center" | contains encoded sound information
|-
| align="center" | terminator || align="center" | 2 || align="center" | 11b || align="center" | indicates the end of the bitstream
|}

=== Channel block types ===

There are following channel block types in ATRAC3plus:

* '''Mono channel block''': contains monaural sound data.
* '''Stereo channel block''': contains stereophonic sound data.
* '''Extension block''': as indicated by its name it's intended to carry some extension information. Its purpose is unknown though due to the lack of an official description. All existing decoder implementations are programmed to ignore blocks of that type.

=== Channel block layout ===

ATRAC3plus was designed to provide a high-quality sound compression. Therefore it tries to save as much bits as possible. It uses a new coding scheme for channel blocks compared to ATRAC3: channels in a stereo sound are no more coded separately but rather in one stereo channel block. The bitstream for such a block provides the possibility for both channels to share several sound parameters so that there is no need to transmit the same things twice. Depends on correlation between the channels this can lead to a significant bit reduction and thus improve coding quality.

A mono/stereo channel block contains the following pieces of sound information:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! size in bits !! description
|-
| align="center" | [[#Sound header|sound_header]] || align="center" | 6 || width="700" | defines some global sound parameters
|-
| align="center" | [[#Word-length information|wordlength_info]] || align="center" | variable || quantization word length information for each quant unit
|-
| align="center" | scalefactor_info || align="center" | variable || quantization scale factor indexes for each coded quant unit
|-
| align="center" | codetable_info || align="center" | variable || code table table information for each coded quant unit
|-
| align="center" | spectra || align="center" | variable || huffman-coded spectral information for each coded quant unit
|-
| align="center" | window_info || align="center" | variable || tells which IMDCT window shape should be used during the sound reconstruction
|-
| align="center" | gain_info || align="center" | variable || gain envelope used by the gain compensation
|-
| align="center" | gha_info || align="center" | variable || information about sine-like waves in the compressed sound obtained by the GHA. It contains quantized frequency, amplitude and phase for each wave to be synthesized in the decoder.
|-
| align="center" | noise_info || align="center" | 1/9 || contains noise flag, level index and table selector for the white noise to be added during decoding.
|}

==== Sound header ====

At the start of each channel block the sound header is located. It contains the following fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || num_quant_units || valid values: 0...27,31 || width="500" | number of coded quantization units - 1. The value of "0" indicates one coded unit, the value of "31" - 32 ones. The values 28, 29 and 30 are invalid.
|-
| align="center" | 1 || align="center" | x_flag || || to be figured out
|}

==== Word-length information ====

===== Coding summary =====

Word-length (or quantization precision) information follows the sound header. It defines the word-length parameter for each [[#num_quant_units|coded quantization unit]]. This parameter is in the range 0...7, where the value of "7" indicates the highest quantization precision and the value of "1" - the lowest one. The value of "0" means no data, i.e. the corresponding quantization unit was not coded.

In the case of the stereo channel block the word-length parameters for the channel 1(L) will be transmitted first followed by the the word-length parameters for the channel 2(R). The word-lengths for the channel 1 are always coded independently. The word-lengths for the channel 2 can be coded either independently or relative to the channel 1. In this case the 1st channel is called "master" and the 2nd one - "slave".
The word-lengths for the mono block will be coded just like the channel 1 in the stereo block.

In order to keep the word-length data as small as possible ATRAC3plus uses several coefficient packing techniques achieving different amount of bits needed for transmission:

* the coefficients are coded directly (3 bits value). This means no packing and used at high bitrates because the frame size is big enough to keep the infomation unpacked.

* differential coding + huffman-coded delta: the first coefficient is coded directly; all others are huffman-coded deltas to the previous coefficient.

* prediction + huffman-coded residual: this techniques offers the best packing and used at low bitrates. It's analogous to the lossless coding and based on trained shape tables serving as prediction. Later the huffman-coded residual will be added to the prediction prefectly reconstructing the coefficients.

===== Reconstruction of trimmed word-length coefficients =====

Word-length coefficient of the trailing quantization units corresponding to the high spectral bands tend to be either 1 (low-precision) or 0 (not coded). Such coefficients will be ommited and one the following modes will be used in order to reconstruct their values during decoding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! mode code(2 bits) !! num_coded_vals !! split_point_delta !! Action(master) !! Action(slave)
|-
| align="center" | 0 || align="center" | not present
|rowspan="3" style="text-align:center;" | not present
|colspan="2" style="text-align:center;" | no trimmed coefficients
|-
| align="center" | 1
|rowspan="3" style="text-align:center;" | 5 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients to "0"
|-
| align="center" | 2 || width="220" | set all trimmed coefficients to "1" || width="220" | for each trimmed coefficient read one bit of its direct value
|-
| align="center" | 3 || align="center" | 2 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients up to split point to "1" and after split point - to "0". The split point is calculated differently for master and slave channels (see below)
|}

To calculate the split point from [[#split_point_delta|split_point_delta]] do the following:

* for the master channel: number of zeroes = split_point_delta + 1
* for the slave channel: number of ones = split_point_delta + 3

The following C-pseudocode shows how to parse a bitstream according with the table above:

mode = get_bits(2);
if (mode) {
num_coded_vals = get_bits(5);
if (mode == 3)
split_point_delta = get_bits(2);
} else {
num_coded_vals = [[#num_quant_units|num_quant_units]];
}

The following C-pseudocode shows how to reconstruct trimmed word-length coefficients according with the table above:

switch (mode) {
case 0: /* no further action */
break;
case 1:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
break;
case 2:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++) {
if (channel == master)
wl_coeffs[pos] = 1;
else
wl_coeffs[pos] = get_bits(1);
}
break;
case 3:
if (channel == master)
split_point = [[#num_quant_units|num_quant_units]] - split_point_delta - 1;
else
split_point = num_coded_vals + split_point_delta + 3;

for (pos = num_coded_vals; pos < split_point; pos++)
wl_coeffs[pos] = 1;

for (; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
}

===== Word-length coding in detail =====

The word-length information for each channel will be coded as follows:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! comments
|-
| align="center" | 2 || coding_mode || width="500" | indicates the coding mode used.
|-
| align="center" | variable || align="center" | coeff_info || word-length coefficients coded according with the [[#coding_mode|coding_mode]].
|}

The [[#coding_mode|coding_mode]] parameter may be interpreted differently depends on the channel number. The following pseudocode examples explain the coding modes in detail:

===== Mode 0 (master and slave) =====

All coefficients will be directly coded as follows:

for (i = 0; i < [[#num_quant_units|num_quant_units]]; i++)
wl_coeffs[i] = get_bits(3);

===== Mode 1 (master) =====

Leading "n" values are stored directly while trailing ones are packed using [[#Method C: shorter delta to min|Method C: shorter delta to min]] method.

Data stored in the bitstream:

* 2 bits: index of the table of weigths, "0" - indicates "no table used"
* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 5 bits: number of directly coded coefficients ('''num_direct_coeffs'''). This value must be < [[#num_coded_vals|num_coded_vals]]
* 2 bits: size of deltas in bits ('''delta_bits''')
* 3 bits: minimum value ('''min_value''')
* for each '''num_direct_coeffs'''
** 3 bits: coefficient value
* if '''delta_bits''' > 0: for each ([[#num_coded_vals|num_coded_vals]] - '''num_direct_coeffs''')
** '''delta_bits''': delta value to be added to the '''min_value'''

The following C-pseudocode summarizes all above:

weigths_tab_indx = get_bits(2); /* get index of weights table to be added after decoding */

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

num_direct_coeffs = get_bits(5);
if (num_direct_coeffs > [[#num_coded_vals|num_coded_vals]])
ABORT("Invalid number of directly coded coefficients");

delta_bits = get_bits(2);
min_value = get_bits(3);

for (pos = 0; pos < num_direct_coeffs; pos++)
wl_coeffs[pos] = get_bits(3);

for (; pos < num_coded_vals; pos++) {
if (delta_bits)
wl_coeffs[pos] = min_value + get_bits(delta_bits);
else
wl_coeffs[pos] = min_value;
}

/* reconstruct trimmed coefficients as described [[#Reconstruction of trimmed word-length coefficients|here]] */

/* add weighting coefficients if requested */
if (weigths_tab_indx) {
for (pos = 0; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] += [[#Tables of weights|wl_weights]][channel_num][weights_tab_indx - 1][pos];
}

===== Mode 1 (slave) =====

Coding method: [[#Method B: huffman-coded modulo difference to master|Huffman-coded modulo difference to master]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 2 bits: indicates which huffman table from [[#Huffman tables for delta coding|this set]] should be used for decoding
* for each [[#num_coded_vals|num_coded_vals]]
** huffman-coded delta value to be added to the corresponding value of the master channel

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

vlc_sel = get_bits(2); /* selects a huffman table from [[#Huffman tables for delta coding|this set]] */

for (i = 0; i < [[#num_coded_vals|num_coded_vals]]; i++) {
delta = get_vlc(vlc_sel);
wl_coeffs[i] = (master_ch->wl_coeffs[i] + delta) & 7;
}

===== Mode 2 (master) =====

Coding method: [[#Vector quantization with residual encoding|Vector quantization with residual encoding]] and [[#Value grouping with "group coded" flag|Value grouping with "group coded" flag]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]].
* 1 bit: '''enable_grouping''' flag. "1" indicates that residual values were coded pairwise (in groups of two).
* 1 bit: selects one of the first two huffman tables from [[#Huffman tables for delta coding|this set]].
* 3 bits: '''start_value''' selecting a subset of "shape tables" from the trained set.
* 4 bits: '''shape_index''' selecting a "shape table" within the subset indicated by '''start_value'''.
* for each [[#num_coded_vals|num_coded_vals]]
** if '''enable_grouping''' == 1:
*** 1 bit: '''group_coded''' flag
*** if '''group_coded''' == 1:
**** 2 huffman-coded residual values to be added to the unpacked "shape table" using modular arithmetic
** if '''enable_grouping''' == 0:
*** one huffman-coded residual value to be added to the unpacked "shape table" using modular arithmetic

== Annex A: Decoding tables ==

=== Word-length related tables ===

==== Tables of weights ====

The weights below will be added to the decoded word-length coefficients. The tables are organized as follows:
* [channel_number: 0 or 1][index: 0...2][coeff_indx: 0...31]

wl_weights[2][3][32] = {
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
},
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 5, 5, 5, 5, 3, 3, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
};

==== Huffman tables for delta coding ====

PLEASE NOTE: delta values indicated in the tables below will be added using modular arithmetic as described [[#Delta coding|here]], so in the case of "wrap around" the value of "7" will be treated as "-1", the value of "6" = "-2" and so on.

* '''vlc_tab_index = 0''', delta range -1...1

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | 7
|}

* '''vlc_tab_index = 1''', delta range -2...2

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 2
|-
| align="center" | 110 || align="center" | 3 || align="center" | 6
|-
| align="center" | 111 || align="center" | 3 || align="center" | 7
|}

* '''vlc_tab_index = 2''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 5
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 3
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 4
|}

* '''vlc_tab_index = 3''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 3
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 4
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 5
|}

[[Category:Audio Codecs]]
[[Category: Multichannel Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

ATRAC3plus

2010-12-30T22:25:00Z

Maxpol: /* Mode 1 (master) */

* Format tag: uses WAVE_FORMAT_EXTENSIBLE with the "SubFormat" field set to the following [[GUID]]: E923AABF-CB58-4471-A119-FFFA01E4CE62
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3+/
* Stored in: [[Microsoft_Wave|WAV]] and [[Oma|Oma/Omg]] containers.
* Official information: http://www.sony.net/Products/ATRAC3/tech/atrac3plus.html

= ATRAC3plus introduction =

ATRAC3plus is a proprietary audio compression algorithm developed by [[Sony]]. As in the case of ATRAC3 ATRAC3plus represents the next generation of the ATRAC codec introduced in 1992 with the MiniDisc. Common use of that codec is in nowel Minidisc players and Portable Playstations made by [[Sony]].

Streams coded with ATRAC3plus are usually stored either in the [[Microsoft_Wave|WAV]] container (those files have the ".at3" extension though) or in the Sony's proprietary [[Oma|Oma/Omg]] container. In the case of the [[Microsoft_Wave|WAV]] container the undocumented [[GUID]]:
E923AABF-CB58-4471-A119-FFFA01E4CE62
is used in order to indicate the ATRAC3plus codec.

There is very limited number of software products supporting encoding/decoding of the ATRAC3plus streams; most of them are unfortunately available for [[Microsoft]] Windows only. Those are:

* Sony's own SonicStage software (Windows only)
* ATRAC Codec Plugin for Sony Media Software (Windows only)
* Sonic Studio's expensive N-code plugin for professionals (available for Windows and Mac OS X)

There is a multi-channel version of ATRAC3plus called "ATRAC-X".

= ATRAC3plus technical documentation =

=== Available bitrates ===

ATRAC3plus operates on fixed bitrates only. The following bitrates are offered by the Sony Encoding software:

bitrate frame size (stereo)
------------- -------------------
48 Kbps 280 bytes
64 Kbps 376 bytes
96 Kbps 560 bytes
128 Kbps 744 bytes
160 Kbps 936 bytes
192 Kbps 1120 bytes
256 Kbps 1488 bytes
320 Kbps 1864 bytes
352 Kbps 2048 bytes

=== Coding techniques ===

ATRAC3plus is a hybrid subband/MDCT codec like [[MP3]]. The signal is split into 16 subbands using [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filter] before MDCT and bit allocation. The sample-frame size is 2048 samples per channel.

After the subband splitting ATRAC3plus tries to extract sine waves from each subband using Generalized Harmonic Analysis (further GHA). GHA encodes parameters of extracted sine waves such as frequency, amplitude and phase into final bitstream.

After the sine waves extraction the remained signal (residual) will be transformed into frequency domain by a 128-point [http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform Modified discrete cosine transform]. The resultet MDCT spectrum will be devided into 32 quantization units of unequal width (higher frequencies - wider units). The relationship between QMF bands and quantization units (QU) is shown in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | QMF subband
| colspan="8" style="text-align:center;"| 0
| colspan="4" style="text-align:center;"| 1
| colspan="4" style="text-align:center;"| 2
| colspan="2" style="text-align:center;"| 3
| colspan="2" style="text-align:center;"| 4
| colspan="2" style="text-align:center;"| 5
| 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | Quant unit
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|}

The flowchart of the ATRAC3plus decoding process is shown below:

[[image:Atrac3plus_decoder_flow.png]]

"Bitstream decoder" decodes various sound parameters from supplied frame data. First the residual signal will be decoded by applying inverse quantization, power compensation, inverse MDCT and gain compensation. Then the sine waves will be synthesized according with their parameters such as frequency, amplitude and phase. Then the residual and the synthesized sine waves will be added together. Optionally, some white noise can be added if specified in the bitstream.

This processing will be repeated for each of 16 subbands. Finally the QMF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal.

Various algorithms are used to improve compression results:

* gain control for reducing pre-echo artifacts
* power compensation for better quality at low bitrates

The following techniques are used in order to make the compressed data smaller:

* variable-lenght ([[Huffman]]) coding
* [[Vector_Quantization|vector quantization]] based on trained tables
* [[Differential_Coding|differential coding]]

Probably the most interesting part of the ATRAC3plus codec is the Generalized Harmonic Analysis (GHA) - an inharmonic frequency analysis proposed by Norbert Wiener in 1930. The main advantage of that is an excellent frequency resolution that surpasses the short-time Discrete Furier transformation. However it requires huge amount of calculations. Several algorithms to work around that problem were introduced during last 20 years, for example the one proposed by Dr.Hirata.

==== Coding methods for compressing bitstream parameters ====

Coding methods described in this section serve the purpose of representing different bitstream parameters like word-length, scale factor etc. using a smaller number of bits. It will be achieved by exploring and removing redundancy from the signals being encoded. The coding techniques described here are [[Lossless_compression|lossless]].

===== Huffman coding =====

ATRAC3plus uses this coding technique widely. There are more than 130 different huffman tables in total for coding bitstream signals. Usually more frequently occuring values will have shorter codes.
ATRAC3plus huffman trees are [http://en.wikipedia.org/wiki/Canonical_Huffman_code canonical ones]. That means those can be stored very compactly by specifying the following parameters:

* number of bits of the shortest codeword
* number of bits of the longest codeword
* number of items for every bit length
* order of items

In my code I'm using the following descriptor in order to specify a canonical huffman table:

uint8_t min; /* shortest codeword length */
uint8_t max; /* longest codeword length */
uint8_t num_items[max - min + 1]; /* number of items for every bit length */

For example, the huffman table vlc_tab_index = 3 [[#Huffman tables for delta coding|here]] will be described as follows:

min = 1
max = 5
num_items[1, 0, 2, 3, 2]

The 2nd element of the array "num_items" is set to "0" because there is no codeword with the length of 2 bits.

The following C-pseudocode can be used for generating huffman tables from the descriptor described above during decoder initialization:

code = 0;
index = 0;

for (num_bits = min; num_bits <= max; num_bits++) {
for (i = num_items[num_bits]; i > 0; i--) {
bits [index] = num_bits;
codes[index] = code++;
index++;
}
code <<= 1;
}

The array "bits" receives length in bits for each codeword, "codes" receives codeword itself.

Finally, the order of codes need to be specified. A simple remapping table will be used to translate the code index into final code. For the table described above the translation table will look as follows:

0, 1, 7, 2, 3, 6, 4, 5

===== Delta coding =====

ATRAC3plus utilizes various delta-coding schemes in order to remove linear correlation from the signal. It often uses the [http://en.wikipedia.org/wiki/Modular_arithmetic modular arithmetic] as well. The main advantage of this coding is that only the half of the range of the difference values is required. An example: word-length information coefficients in the range 0...7 need to be transmitted compactly. Using delta coding this would require to code difference values in the range -7...+7, also 15 values.

In the case of modular arithmetic the range of the difference values can be reduced to 0...7 by introducing a "wrap-around" so that the final equation looks like this:

B = (A + delta) & 7;

Below an example with "wrap around":

Consider we need to code the value B = "1" and the reference value A = "6". Then the difference value (delta) will be = "-5". According with equation above the delta value of "3" can be used instead of "-5":

(6 + 3) & 7 = 1;

Another example without "wrap around":

Consider we need to code the value B = "7" and the reference value A = "2". Then the difference value (delta) will be = "5":

(2 + 5) & 7 = 7;

Further variable-length codes will be used to reduce amount of bits of difference values in accordance with their probability.

The following is a description of the delta-coding methods used in ATRAC3plus:

====== Method A: huffman-coded modulo difference to previous ======

Consider the following signal:

3, 6, 6, 3, 3, 3, 4, 2, 2, 1, 1, 1, 3

Now code it using delta coding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Coefficient !! Modulo delta value !! Huffman code !! Number of bits
|-
| align="center" | 3 || align="center" | - || align="center" | - || align="center" | 3
|-
| align="center" | 6 || align="center" | 3 || align="center" | 11110 || align="center" | 5
|-
| align="center" | 6 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 5 || align="center" | 1101 || align="center" | 4
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 4 || align="center" | 1 || align="center" | 100 || align="center" | 3
|-
| align="center" | 2 || align="center" | 6 || align="center" | 1110 || align="center" | 4
|-
| align="center" | 2 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 7 || align="center" | 101 || align="center" | 3
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 2 || align="center" | 1100 || align="center" | 4
|}

The 1st coefficient has no delta value associated with it because there is no previous value. It will be coded "as is" using fixed length of 3 bits. The following delta values get a variable-length code from the table val_tab_index = 2 [[#Huffman tables for delta coding|here]] so the final number of bits to be transmitted will be = 32.
Compared to the unpacked version (13 x 3 bits = 39 bits) the coding method described above will yield a bit-reduction of 7 bits (18% smaller).

====== Method B: huffman-coded modulo difference to master ======

In a stereo mix the signal of the left channel is often very similar to the signal of the right channel (i.e. there is a high cross-correlation between the channels). In this case the estimated sound parameters like word-length or scale factor will have a high similarity as well. Then coding the differential signal between the channels can lead to a significant bit reduction.
Surely at least the one of the channels must be coded independently. Such a channel will be called "master" (it's usually the left channel but ATRAC3plus has the possibility to make the right channel act like a master as well). For the 2nd channel only the difference to master will be coded. The 2nd channel will be called "slave" in this case.

Below an example of such a high-correlated signal:

Left : 6, 5, 6, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1
Right: 6, 5, 6, 2, 2, 2, 3, 1, 1, 1, 2, 1, 1
Diff : 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0

Coding the difference signal using the table val_tab_index = 0 [[#Huffman tables for delta coding|here]] will result in another signal 15 bits long. Compared to the unpacked version (13 x 3 bits = 39 bits) that coding method will yield a bit-reduction of 24 bits (62% smaller).

====== Method C: shorter delta to min ======

Sometimes coefficients in a signal are very close to each other, so subtracting the minimum value from each coefficient will result in smaller deltas whose can be coded using fewer bits.

An example:

2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1

As one can see the values in the sequence above are very similar to each other. Let us find minimum and maximum values and then determine the number of delta bits:

min = 1; max = 2; num_delta_bits = ilog2(max - min + 1) = 1 bit

Now let us encode the sequence above using shorter deltas:

num_delta_bits = 1 will be coded as a 2-bit value
min = 1 will be coded as a 3-bit value
deltas: 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0

The encoded signal is 5 + 1 x 15 = 20 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 25 bits (55% smaller).

Another example:

1, 2, 3, 2, 4, 2, 1, 2, 3, 3, 1, 4, 4, 1, 1

min = 1; max = 4; num_delta_bits = ilog2(max - min + 1) = 2 bits

Now the encoded signal:

num_delta_bits = 2 (will be coded as a 2-bit value)
min = 1 (will be coded as a 3-bit value)
deltas: 0, 1, 2, 1, 3, 1, 0, 1, 2, 2, 0, 3, 3, 0, 0

The encoded signal is 5 + 2 x 15 = 35 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 10 bits (22% smaller).

====== Method D: sequence of numbers in ascending order ======

Sometimes ATRAC3plus have to deal with sequences of numbers (i.e. gain control position information) where all items are known to be in ascending order (i.e. satisfy the following equation: ''Vn+1 > Vn''). Such sequences can be packed without any additional bitstream information by examining previous value (predecessor), calculating magnitude between it and the maximum value and making the decision about number of bits of the next delta value.

Consider the following sequence:

Position index: 0, 1, 2, 3, 4, 5, 6, 7
---------------------------------------------
Position info : 5, 7, 14, 15, 18, 25, 29, 30
---------------------------------------------
Num delta bits: 5, 5, 5, 4, 4, 3, 1, 0

1st coefficient (position index = 0) will be coded directly using 5 bits because the sequence should start somewhere.
The following coefficients (except one with the value of "30") will be coded according to the following pseudocode:

num_delta_bits = ilog2(31 - prev_val);
if (num_delta_bits == 5)
new_val = get_bits(5);
else
new_val = prev_val + get_bits(num_delta_bits) + 1;

Let us return to our sequence. The 2nd value will be coded directly as well using 5 bits because ilog2(31 - 5) = 5. Similar for the 3rd one. No delta coding is applied in that case. The 4th value will be delta-coded using 4 bits:

num_delta_bits = ilog2(31 - 15) = 4 bits;
delta = 18 - 15 - 1 = 2

And so on until we reach the last value = 30. In this case there is only one value that meets our condition ''Vn+1 > Vn'': the value of "31". In this case no delta will be transmitted and the coming value will be calculated just as:

new_val = prev_val + 1;

Therefore the resulting sequence will be 27 bits long. Compared to the unpacked version (8 x 5 bits = 40 bits) this packing method will yield a bit-reduction of 13 bits (32% smaller).

===== Vector quantization with residual encoding =====

One further packing technique used in ATRAC3plus is based on so-called "shape prediction vectors". Encoder decomposes a signal (word-length or scale factor info) into "shape prediction" + residual. Then only the index of the "shape prediction vector" and the huffman-coded residual will be transmitted. The main advantage of this method is when the shape matches the coded signal closely, the residual can be represented very compactly (usually 1-2 bits per value). Moreover, the majority of values of the residual will turn into zeroes, which can be further packed.

Each entry of the "shape prediction tables" contain an average value over 3 coefficients. This helps to keep those tables comparable small. For example, for a signal of 32 values each "shape table" will have 10 entries (last entry contains usually an average value over 5 coefficients).

Consider the following signal to be encoded:

7, 7, 6, 5, 4, 4, 3, 2, 2, 2, 1, 1

Let us "quantize" that signal by diving it into 4 * 3 groups and find the averaged value in each group:

floor((7 + 7 + 6) / 3 + 0.5) = 7,
floor((5 + 4 + 4) / 3 + 0.5) = 4,
floor((3 + 2 + 2) / 3 + 0.5) = 2,
floor((2 + 1 + 1) / 3 + 0.5) = 1

Find a "shape table" in the trained set that closely matches our "quantized" version. It will be (for example):
7, 5, 2, 1

Now compute the residual:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | Original signal
| style="text-align:center;"| 7
| style="text-align:center;"| 7
| style="text-align:center;"| 6
| style="text-align:center;"| 5
| style="text-align:center;"| 4
| style="text-align:center;"| 4
| 3 || 2 || 2 || 2 || 1 || 1
|-
! bgcolor="#f0f0f0" | Unpacked shape table
| 7 || 7 || 7 || 5 || 5 || 5 || 2 || 2 || 2 || 1 || 1 || 1
|-
! bgcolor="#f0f0f0" | Residual
| 0 || 0 || -1 || 0 || -1 || -1 || 1 || 0 || 0 || 1 || 0 || 0
|}

Now select a huffman table that represents the residual above as small as possible. The following huffman tree assigns the shortest code (1 bit) to the most frequently occuring symbol = "0" and 2-bit codes to the others: "1" and "-1":

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | -1
|}

The packed signal will occupy 21 bits: 4 bits "shape table" index + 17 bits residual(7 bits for "zeroes" + 10 bits for "non-zeroes"). Compared to the unpacked version (12 x 3 bits = 36 bits) this packing method will yield a bit-reduction of 15 bits (42% smaller).

===== Value grouping with "group coded" flag =====

If a signal contains lots of zeroes, grouping several values together and assigning the "group coded" flag to each group will achieve a significant bit-reduction. Consider the following sequence of numbers to be encoded:

0, 0, 1, 2, 0, 0, 3, 3, 0, 0, 0, 7, 0, 6, 0, 0

Let us cluster each two values together and assign the "coded" flag (1 bit) to each group:

(0, 0); flag = 0 (group not coded)
(1, 2); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(3, 3); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(0, 7); flag = 1 (group coded)
(0, 6); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)

Thereafter, each "not coded" group requires only one bit to be transmitted indicating that all values in that group are zero. On the other hand, each "coded" group requires one extra bit to be transmitted indicating that at least one value in that group is non-zero. In the case above that overhead is worthwhile because the half of the signal contains zeroes.

The encoded signal is 4 x 1 + 4 x 7 = 32 bits long while the unpacked one is 16 x 3 = 48 bits long. The bit-reduction is thereafter 16 bits (33% smaller).

== Multichannel ATRAC3plus (ATRAC-X) ==

ATRAC3plus supports multichannel streams (up to 8 channels). Such streams are encoded in units customary called "channel block"; each block contains max. 2 channels (ie can be MONO or STEREO). For example, taking the channel_id = 3 and looking at the table below we have a stream containing 2 channel blocks: 1 stereo + 1 mono and thus 3 channels.
The base codec operates on either MONO or STEREO channel blocks only.

=== ATRAC-X channel configurations ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! channel_id !! total channels !! number of channel blocks !! speaker mapping
|-
| align="center" | 0 || align="center" | 0 || align="center" | undefined ||
* undefined
|-
| align="center" | 1 || align="center" | 1 || align="center" | 1 ||
* front: center (MONO)
|-
| align="center" | 2 || align="center" | 2 || align="center" | 1 ||
* front: L, R (STEREO)
|-
| align="center" | 3 || align="center" | 3 || align="center" | 2 ||
* front: L, R
* front: center
|-
| align="center" | 4 || align="center" | 4 || align="center" | 3 ||
* front: L, R
* front: center
* rear: surround
|-
| align="center" | 5 || align="center" | 5+1 || align="center" | 4 ||
* front: L, R
* front: center
* rear: L, R
* LFE
|-
| align="center" | 6 || align="center" | 6+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* rear: center
* LFE
|-
| align="center" | 7 || align="center" | 7+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* side: L, R
* LFE
|}

== Bitstream overview ==

The table below shows the bitstream organization of ATRAC3plus at the top-level. Depends on [[#ATRAC-X channel configurations|channel configuration]] a typical frame may contain more than one channel block. In this case the additional fields [[#channel_block_type|channel_block_type]] and [[#channel_block_data|channel_block_data]] will be included for each block.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! number of bits !! value !! description
|-
| align="center" | start_marker || align="center" | 1 || align="center" | 0 ||
marks the start of the ATRAC3plus bitstream
|-
| align="center" | channel_block_type || align="center" | 2 ||
* 00b - MONO block
* 01b - STEREO block
* 10b - EXTENSION block
| align="center" | type of the channel block
|-
| align="center" | channel_block_data || align="center" | variable || || align="center" | contains encoded sound information
|-
| align="center" | terminator || align="center" | 2 || align="center" | 11b || align="center" | indicates the end of the bitstream
|}

=== Channel block types ===

There are following channel block types in ATRAC3plus:

* '''Mono channel block''': contains monaural sound data.
* '''Stereo channel block''': contains stereophonic sound data.
* '''Extension block''': as indicated by its name it's intended to carry some extension information. Its purpose is unknown though due to the lack of an official description. All existing decoder implementations are programmed to ignore blocks of that type.

=== Channel block layout ===

ATRAC3plus was designed to provide a high-quality sound compression. Therefore it tries to save as much bits as possible. It uses a new coding scheme for channel blocks compared to ATRAC3: channels in a stereo sound are no more coded separately but rather in one stereo channel block. The bitstream for such a block provides the possibility for both channels to share several sound parameters so that there is no need to transmit the same things twice. Depends on correlation between the channels this can lead to a significant bit reduction and thus improve coding quality.

A mono/stereo channel block contains the following pieces of sound information:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! size in bits !! description
|-
| align="center" | [[#Sound header|sound_header]] || align="center" | 6 || width="700" | defines some global sound parameters
|-
| align="center" | [[#Word-length information|wordlength_info]] || align="center" | variable || quantization word length information for each quant unit
|-
| align="center" | scalefactor_info || align="center" | variable || quantization scale factor indexes for each coded quant unit
|-
| align="center" | codetable_info || align="center" | variable || code table table information for each coded quant unit
|-
| align="center" | spectra || align="center" | variable || huffman-coded spectral information for each coded quant unit
|-
| align="center" | window_info || align="center" | variable || tells which IMDCT window shape should be used during the sound reconstruction
|-
| align="center" | gain_info || align="center" | variable || gain envelope used by the gain compensation
|-
| align="center" | gha_info || align="center" | variable || information about sine-like waves in the compressed sound obtained by the GHA. It contains quantized frequency, amplitude and phase for each wave to be synthesized in the decoder.
|-
| align="center" | noise_info || align="center" | 1/9 || contains noise flag, level index and table selector for the white noise to be added during decoding.
|}

==== Sound header ====

At the start of each channel block the sound header is located. It contains the following fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || num_quant_units || valid values: 0...27,31 || width="500" | number of coded quantization units - 1. The value of "0" indicates one coded unit, the value of "31" - 32 ones. The values 28, 29 and 30 are invalid.
|-
| align="center" | 1 || align="center" | x_flag || || to be figured out
|}

==== Word-length information ====

===== Coding summary =====

Word-length (or quantization precision) information follows the sound header. It defines the word-length parameter for each [[#num_quant_units|coded quantization unit]]. This parameter is in the range 0...7, where the value of "7" indicates the highest quantization precision and the value of "1" - the lowest one. The value of "0" means no data, i.e. the corresponding quantization unit was not coded.

In the case of the stereo channel block the word-length parameters for the channel 1(L) will be transmitted first followed by the the word-length parameters for the channel 2(R). The word-lengths for the channel 1 are always coded independently. The word-lengths for the channel 2 can be coded either independently or relative to the channel 1. In this case the 1st channel is called "master" and the 2nd one - "slave".
The word-lengths for the mono block will be coded just like the channel 1 in the stereo block.

In order to keep the word-length data as small as possible ATRAC3plus uses several coefficient packing techniques achieving different amount of bits needed for transmission:

* the coefficients are coded directly (3 bits value). This means no packing and used at high bitrates because the frame size is big enough to keep the infomation unpacked.

* differential coding + huffman-coded delta: the first coefficient is coded directly; all others are huffman-coded deltas to the previous coefficient.

* prediction + huffman-coded residual: this techniques offers the best packing and used at low bitrates. It's analogous to the lossless coding and based on trained shape tables serving as prediction. Later the huffman-coded residual will be added to the prediction prefectly reconstructing the coefficients.

===== Reconstruction of trimmed word-length coefficients =====

Word-length coefficient of the trailing quantization units corresponding to the high spectral bands tend to be either 1 (low-precision) or 0 (not coded). Such coefficients will be ommited and one the following modes will be used in order to reconstruct their values during decoding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! mode code(2 bits) !! num_coded_vals !! split_point_delta !! Action(master) !! Action(slave)
|-
| align="center" | 0 || align="center" | not present
|rowspan="3" style="text-align:center;" | not present
|colspan="2" style="text-align:center;" | no trimmed coefficients
|-
| align="center" | 1
|rowspan="3" style="text-align:center;" | 5 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients to "0"
|-
| align="center" | 2 || width="220" | set all trimmed coefficients to "1" || width="220" | for each trimmed coefficient read one bit of its direct value
|-
| align="center" | 3 || align="center" | 2 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients up to split point to "1" and after split point - to "0". The split point is calculated differently for master and slave channels (see below)
|}

To calculate the split point from [[#split_point_delta|split_point_delta]] do the following:

* for the master channel: number of zeroes = split_point_delta + 1
* for the slave channel: number of ones = split_point_delta + 3

The following C-pseudocode shows how to parse a bitstream according with the table above:

mode = get_bits(2);
if (mode) {
num_coded_vals = get_bits(5);
if (mode == 3)
split_point_delta = get_bits(2);
} else {
num_coded_vals = [[#num_quant_units|num_quant_units]];
}

The following C-pseudocode shows how to reconstruct trimmed word-length coefficients according with the table above:

switch (mode) {
case 0: /* no further action */
break;
case 1:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
break;
case 2:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++) {
if (channel == master)
wl_coeffs[pos] = 1;
else
wl_coeffs[pos] = get_bits(1);
}
break;
case 3:
if (channel == master)
split_point = [[#num_quant_units|num_quant_units]] - split_point_delta - 1;
else
split_point = num_coded_vals + split_point_delta + 3;

for (pos = num_coded_vals; pos < split_point; pos++)
wl_coeffs[pos] = 1;

for (; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
}

===== Word-length coding in detail =====

The word-length information for each channel will be coded as follows:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! comments
|-
| align="center" | 2 || coding_mode || width="500" | indicates the coding mode used.
|-
| align="center" | variable || align="center" | coeff_info || word-length coefficients coded according with the [[#coding_mode|coding_mode]].
|}

The [[#coding_mode|coding_mode]] parameter may be interpreted differently depends on the channel number. The following pseudocode examples explain the coding modes in detail:

===== Mode 0 (master and slave) =====

All coefficients will be directly coded as follows:

for (i = 0; i < [[#num_quant_units|num_quant_units]]; i++)
wl_coeffs[i] = get_bits(3);

===== Mode 1 (master) =====

Leading "n" values are stored directly while trailing ones are packed using [[#Method C: shorter delta to min|Method C: shorter delta to min]] method.

Data stored in the bitstream:

* 2 bits: index of the table of weigths, "0" - indicates "no table used"
* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 5 bits: number of directly coded coefficients ('''num_direct_coeffs'''). This value must be < [[#num_coded_vals|num_coded_vals]]
* 2 bits: size of deltas in bits ('''delta_bits''')
* 3 bits: minimum value ('''min_value''')
* for each '''num_direct_coeffs'''
** 3 bits: coefficient value
* if '''delta_bits''' > 0: for each ([[#num_coded_vals|num_coded_vals]] - '''num_direct_coeffs''')
** '''delta_bits''': delta value to be added to the '''min_value'''

The following C-pseudocode summarizes all above:

weigths_tab_indx = get_bits(2); /* get index of weights table to be added after decoding */

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

num_direct_coeffs = get_bits(5);
if (num_direct_coeffs > [[#num_coded_vals|num_coded_vals]])
ABORT("Invalid number of directly coded coefficients");

delta_bits = get_bits(2);
min_value = get_bits(3);

for (pos = 0; pos < num_direct_coeffs; pos++)
wl_coeffs[pos] = get_bits(3);

for (; pos < num_coded_vals; pos++) {
if (delta_bits)
wl_coeffs[pos] = min_value + get_bits(delta_bits);
else
wl_coeffs[pos] = min_value;
}

/* reconstruct trimmed coefficients as described [[#Reconstruction of trimmed word-length coefficients|here]] */

/* add weighting coefficients if requested */
if (weigths_tab_indx) {
for (pos = 0; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] += [[#Tables of weights|wl_weights]][channel_num][weights_tab_indx - 1][pos];
}

===== Mode 1 (slave) =====

Coding method: [[#Method B: huffman-coded modulo difference to master|Huffman-coded modulo difference to master]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 2 bits: indicates which huffman table from [[#Huffman tables for delta coding|this set]] should be used for decoding
* for each [[#num_coded_vals|num_coded_vals]]
** huffman-coded delta value to be added to the corresponding value of the master channel

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

vlc_sel = get_bits(2); /* selects a huffman table from [[#Huffman tables for delta coding|this set]] */

for (i = 0; i < [[#num_coded_vals|num_coded_vals]]; i++) {
delta = get_vlc(vlc_sel);
wl_coeffs[i] = (master_ch->wl_coeffs[i] + delta) & 7;
}

===== Mode 2 (master) =====

Coding method: [[#Vector quantization with residual encoding|Vector quantization with residual encoding]] and [[#Value grouping with "group coded" flag|Value grouping with "group coded" flag]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]].
* 1 bit: '''enable_grouping''' flag. "1" indicates that residual values were coded pairwise (in groups of two).
* 1 bit: selects one of the first two huffman tables from [[#Huffman tables for delta coding|this set]].
* 3 bits: '''start_value''' selecting a subset of "shape tables" from the trained set.
* 4 bits: '''shape_index''' selecting a "shape table" within the subset indicated by '''start_value'''.
* for each [[#num_coded_vals|num_coded_vals]]
** if '''enable_grouping''' == 1:
*** 1 bit: '''group_coded''' flag
*** if '''group_coded''' == 1:
**** 2 huffman-coded residual values to be added to the unpacked "shape table" using modular arithmetic
** if '''enable_grouping''' == 0:
*** one huffman-coded residual value to be added to the unpacked "shape table" using modular arithmetic

== Annex A: Decoding tables ==

=== Word-length related tables ===

==== Tables of weights ====

The weights below will be added to the decoded word-length coefficients. The tables are organized as follows:
* [channel_number: 0 or 1][index: 0...2][coeff_indx: 0...31]

wl_weights[2][3][32] = {
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
},
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 5, 5, 5, 5, 3, 3, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
};

==== Huffman tables for delta coding ====

PLEASE NOTE: delta values indicated in the tables below will be added using modular arithmetic as described [[#Delta coding based on modular arithmetic|here]], so in the case of "wrap around" the value of "7" will be treated as "-1", the value of "6" = "-2" and so on.

* '''vlc_tab_index = 0''', delta range -1...1

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | 7
|}

* '''vlc_tab_index = 1''', delta range -2...2

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 2
|-
| align="center" | 110 || align="center" | 3 || align="center" | 6
|-
| align="center" | 111 || align="center" | 3 || align="center" | 7
|}

* '''vlc_tab_index = 2''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 5
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 3
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 4
|}

* '''vlc_tab_index = 3''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 3
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 4
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 5
|}

[[Category:Audio Codecs]]
[[Category: Multichannel Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

Apple ProRes

2010-11-20T10:14:08Z

Maxpol: /* ProRes Introduction */

Apple ProRes

2010-11-20T10:13:44Z

Maxpol: /* ProRes Introduction */

Indeo 5

2010-11-11T11:30:10Z

Maxpol: /* GOP header */

* FOURCCs: IV50
* Company: [[Intel]], then [[Ligos]]
* Samples: http://samples.mplayerhq.hu/V-codecs/IV50/
* Samples: http://ligos.com/videoclips/lions/lion_sif_ind5.zip
* Docs: http://www.ligos.com/pdf_docs/Indeo_doc.pdf
* Docs: http://www.ligos.com/pdf_docs/Indeo_FAQ.pdf
* Patent links: http://www.freepatentsonline.com/5532940.pdf
* Patent links: http://www.patentstorm.us/patents/5532940-description.html

== Introduction ==

Indeo5 is the latest version of Indeo Video Interactive(IVI). For an introduction to this compression algorithm see [[Indeo_4#Introduction|Indeo Video Interactive]].

== Indeo Video Interactive Version 5 (Indeo5) ==

For a description of the coding techniques see [[Indeo_4#Brief description of the coding techniques|Brief description of the coding techniques]].

For a description of the interactive features see [[Indeo_4#Brief description of the interactive features|Brief description of the interactive features]].

Indeo5 algorithm is mostly the same as indeo4 with the following differences:

- indeo5 uses a different bitstream format for picture and band headers that allows storing of compressed frames more compactly.

- indeo5 utilizes only the Slant transform. The Haar transform used in indeo4 was dropped due to its low quality.

- indeo5 uses the Daubechies (LeGall) 5/3 wavelet for the subband decomposition/recomposition instead of the Haar wavelet used in indeo4 in order to provide a better quality for the scalability mode.

- bidirectional frames mode seems to be dropped. Actually there is no indeo5 encoder supports its creating. Mac and Xanim decoders contain no code for handling of this kind of frames.

- indeo5 performs a partially encryption of the bitstream if a numeric password ("access key") was specified during encoding.

== Decoder specification ==

Indeo5 has the same picture layout and bitstream organization as indeo4. For a detailed description see [[Indeo_4#Picture layout|Indeo4 picture layout]] and [[Indeo_4#Bitstream organization|Bitstream organization]].

=== Conventions ===

Headers are described in some tables. Each row of those tables describes a value which may be read from the frame. Those tables and rows are presented in the order of appearance in the frame.

Here are the meaning of each columns:
* '''size''': The size of this value in bits. Bits are counted in LSB to MSB order. As an example, with the byte 01110000b, reading 3 bits then 5 bits will return 000b then 01110b. Reading more than 8 bits thus reads as a little-endian value. Think of the get_bits function as filling up the return value from its LSB, using the bits from each byte starting from their LSB.
* '''name''': Kind of variable name, used to reference the value. When a value is named valueX, it generally means we don't know it's purpose. Lines named alignmentX means that bits reader need to skip bits until next byte boundary.
* '''condition''': The value is present in the frame only if this condition is matched. No condition means that the value is always present.
* '''value(s)''': Description of constant values and their meaning.
* '''comments''': Some details about the content of the value.

=== Picture header ===

Picture header of indeo5 consists of three parts:

Picture_start_code, frame_type, frame_number
[GOP header]
Frame header

The first two bytes of a frame tell the decoder how the following data should be interpreted. These include three fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || PSC || always = 0x1F || indeo5 picture start code
|-
| align="center" | 3 || frame_type ||
* 0 => INTRA (key) frame
* 1 => INTER frame
* 2 => droppable INTER frame (scalability mode only)
* 3 => droppable INTER frame
* 4 => NULL frame
* 5...7 are illegal
|| frame type
|-
| align="center" | 8 || frame_number || 0...0xFF || frame number in GOP (0 for I frame)
|}

Null frames don't contain anything else than this header.

==== GOP header ====

This header is present in INTRA (key) frames only. It's used for transfering of some general information (i.e. picture layout) that will be either rarely or never changed during a video sequence. The values in this header are valid for all frames in the GOP.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! condition !! value(s) !! comments
|-
| align="center" | 8 || gop_flags || ||
* bit 0 => 1 - [[#gop_hdr_size|gop_hdr_size]] field is present
* bit 1 => subsampling format: 0 - YVU9, 1 - YV12
* bit 2 => unknown meaning
* bit 3 => transparency status?
* bit 4 =>
* bit 5 => access key protection: 1 - enabled
* bit 6 => local decoding: 1 - enabled
* bit 7 =>
|| GOP header flags (bit 0 is the LSB).
|-
| align="center" | 16 || gop_hdr_size || [[#gop_flags|gop_flags]] & 0x01 || || Size of this header in bytes. Only present in the bitstream if indicated by the [[#gop_flags|gop_flags]] bit 0.
|-
| align="center" | 32 || lock_word || [[#gop_flags|gop_flags]] & 0x20 || ||
Only present in the bitstream if "access key protection" is active (as indicated by the bit 5 of the [[#gop_flags|gop_flags]]). For a description of how to use this field see [[#Access key protection|Access key protection]].
|-
| align="center" | 2 || slice_size_id || [[#gop_flags|gop_flags]] & 0x40 ||
* 0 => 64 x 64
* 1 => 128 x 128
* 2 => 256 x 256
* 3 => unused
|| ID of slice size. Only present if "local decoding mode" is enabled (indicated by the bit 6 of the [[#gop_flags|gop_flags]]).
|-
| align="center" | 2 || luma_levels || ||
* 0 => no decomposition
* 1 => 1 level
* 2 => 2 levels
* 3 => forbidden
|| Number of wavelet decomposition levels for the luma plane. Number of resulting wavelet subbands can be calculated using the following equation: num_bands = [[#luma_levels|luma_levels]] * 3 + 1.
|-
| align="center" | 1 || chroma_levels || ||
* 0 => no decomposition
* 1 => forbidden
|| Number of wavelet decomposition levels for the chrominance planes. The value of "1" is forbidden because no knowing indeo5 software performs any decomposition of the chrominance planes.
|-
| align="center" | 4 || pic_size_id || || || Index into the table of the [[#Standard_picture_sizes|standard picture sizes]]. If the picture has dimensions not listed in the table then this field contains the value of "15" and the actual picture size will be coded using [[#pic_height|pic_height]] and [[#pic_width|pic_width]] fields.
|-
| align="center" | 13 || pic_height || rowspan="2" | [[#pic_size_id|pic_size_id]] == 15 || || Non-standard picture height.
|-
| align="center" | 13 || pic_width || || Non-standard picture width.
|-
| align="center" | variable || band_info_luma || || || Array of the [[#Band_info structure|Band_info structures]] describing each luminance band. For a description how to calculate the number of the luminance bands see here: [[#luma_levels|luma_levels]].
|-
| align="center" | 6-8 || band_info_chroma || || || Array of the [[#Band_info structure|Band_info structures]] describing each chrominance band. Because the chrominance planes are being NEVER decomposed by the existing indeo5 software there is only one band per chrominance plane and therefore only one descriptor of this type.
|-
| align="center" | 3 || alignment1 || rowspan="3" | [[#gop_flags|gop_flags]] & 0x08 || always == 0 || Alignment bits. Must be zero.
|-
| align="center" | 1 || color_flg || || This flag indicates if the [[#transp_color|transp_color]] field is present.
|-
| align="center" | 24 || transp_color || || Transparency fill color.
|-
| align="center" | ?? || alignment2 || || || Align the bitreader on the next byte.
|-
| align="center" | 8 || value1 || || || Unused.
|-
| align="center" | 8 || value2 || || || Unused.
|-
| align="center" | 3 || value3 || || || Unused.
|-
| align="center" | 4 || value4 || || ||
|-
| align="center" | 1 || gop_ext_flg || || || This flag indicates if the [[#gop_ext|gop_ext]] field is present.
|-
| align="center" | variable || gop_ext || [[#gop_ext_flg|gop_ext_flg]] == 1 ||
do { val = getbits(16);
} while(val &0x8000);
|| GOP header extension.
|-
| align="center" | ?? || alignment3 || || || Align the bitreader on the next byte.
|}

==== Frame header ====

This header is present in all kinds of frame except NULL. It's used mainly to transfer a huffman codebook for the macroblock signals and provide checksum information for debugging purposes.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! condition !! value(s) !! comments
|-
| align="center" | 8 || frame_flags || ||
* bit 0 => 1 - [[#pic_hdr_size|pic_hdr_size]] field is present
* bit 1 =>
* bit 2 =>
* bit 3 =>
* bit 4 => 1 - [[#frm_checksum|frm_checksum]] field is present.
* bit 5 => 1 - [[#frm_hdr_ext|frm_hdr_ext]] field is present.
* bit 6 => 1 - [[#mb_huff_desc|mb_huff_desc]] field is present. Otherwise select the default macroblock huffman codebook.
* bit 7 => 1 - [[#band_data_size|band_data_size]] field is present.
|| Frame flags (bit 0 is the LSB).
|-
| align="center" | 24 || pic_hdr_size || [[#frame_flags|frame_flags]] & 0x01 || || Size of the entire picture header in bytes. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 0.
|-
| align="center" | 16 || frm_checksum || [[#frame_flags|frame_flags]] & 0x10 || || Frame checksum for debugging purposes. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 4.
|-
| align="center" | variable || frm_hdr_ext || [[#frame_flags|frame_flags]] & 0x20 ||
To skip it, do the following:
do {
len = getbits(8);
for (i=0; i < len; i++) skipbits(8);
} while(len);
|| Unknown frame header extension. Its content will be ignored by the known indeo5 decoders. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 5.
|-
| align="center" | variable || mb_huff_desc || [[#frame_flags|frame_flags]] & 0x40 || || Macroblock huffman codebook descriptor. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 6. For a description of the format of the huffman codebook descriptors see [[Indeo_4#Codebook descriptors in the bitstream|Codebook descriptors in the bitstream]].
|-
| align="center" | 3 || value5 || || || Unused.
|-
| align="center" | ?? || alignment4 || || || Align the biteader on the next byte.
|}

=== Band header ===

This header describes a wavelet band.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! condition !! value(s) !! comments
|-
| align="center" | 8 || band_flags || ||
* bit 0 => 1 - this band is empty (doesn't contain any coded data).
* bit 1 => 1 - motion vector inheritance mode is enabled.
* bit 2 => 1 - qdelta parameter is present.
* bit 3 => 1 - qdelta inheritance mode is enabled.
* bit 4 => 1 - [[#rv_tab_corr|rv_tab_corr]] array is present.
* bit 5 => 1 - [[#band_hdr_ext|band_hdr_ext]] field is present.
* bit 6 => 1 - [[#rv_tab_sel|rv_tab_sel]] field is present. Otherwise use the default rv_table.
* bit 7 => 1 - [[#blk_huff_desc|blk_huff_desc]] field is present. Otherwise use the default block huffman codebook.
|| Band flags (bit 0 is the LSB).
|-
| align="center" | 24 || band_data_size || [[#frame_flags|frame_flags]] & 0x80 || || Size of the band data in bytes. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 7.
|-
| align="center" | 8 || num_rv_corr || rowspan="2" | [[#band_flags|band_flags]] & 0x10 || || Number of rv_table correction pairs. Must be <= 61. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 4.
|-
| align="center" | variable || rv_tab_corr || || Array of rv_table correction pairs. Its size is [[#num_rv_corr|num_rv_corr]] * 2 bytes. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 4.
|-
| align="center" | 3 || rv_tab_sel || [[#band_flags|band_flags]] & 0x40 || || Indicates which run-value table should be used for decoding. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 6.
|-
| align="center" | variable || blk_huff_desc || [[#band_flags|band_flags]] & 0x80 || || Block huffman codebook descriptor. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 7. For a description of the format of the huffman codebook descriptors see [[Indeo_4#Codebook descriptors in the bitstream|Codebook descriptors in the bitstream]].
|-
| align="center" | 1 || checksum_flag || || || If set [[#band_checksum|band_checksum]] field is present in the bitstream.
|-
| align="center" | 16 || band_checksum || [[#checksum_flag|checksum_flag]] || || Band checksum for debugging purposes. Only present in the bitstream if indicated by the [[#checksum_flag|checksum_flag]].
|-
| align="center" | 5 || band_glob_quant || || || Global quantization level for this band.
|-
| align="center" | ?? || alignment5 || || || Align the biteader on the next byte.
|-
| align="center" | variable || band_hdr_ext || [[#band_flags|band_flags]] & 0x20 ||
To skip it, do the following:
do {
len = getbits(8);
for (i=0; i < len; i++) skipbits(8);
} while(getbits(1));
|| Unknown band header extension. Its content will be ignored by the known indeo5 decoders. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 5.
|-
| align="center" | ?? || alignment6 || || || Align the biteader on the next byte.
|}

== Scalability mode ==

This special feature of Indeo5 allows the decoder to adapt playback to the processor power of the particular machine being used for playback. Indeo5 offers both spatial and temporal scalability. Read more about that technique here: [[Scalable Video Coding]].

=== Spatial scalability ===

Spatial scalability works by dividing the image into a number of frequency bands using wavelet decomposition. These bands represent the image at a different level of sharpness. All bands are necessary to perfectly recreate the original image. But if there is not enough processor power available, the decoder can decompress fewer bands of each frame, rather than simply dropping frames. This produces blurry images, but preserves the motion.

The scalability mode is controlled by the user during encoding. If this mode is disabled the encoder acts like an usual block-based transform compression algorithm: each of the three color planes will be processed using the Slant transform, quantization and Huffman coding.
If the scalability mode is enabled the encoder first performs subband decomposition using the [[Discrete Wavelet Transform]] (DWT). Although each color plane could be theoretically decomposed Indeo5 performs that only on the luminance plane data. This decomposition results in four wavelet bands, each of them is one-fourth of the original picture size. Further those band will be compressed using the Slant transform, quantization and Huffman coding.

==== Wavelet transform ====

The wavelet used in Indeo5 for decomposition/recomposition purposes is referred as CDF 5/3 or LeGall wavelet. It uses in a slightly different form in many other compression algorithms like [[JPEG 2000]] or [[Snow]]. The coefficients for the analysis filters (encoder) are:

h0 = {-1, 2, 6, 2, -1} * 1/8
h1 = {1, -2, 1} * 1/4

where "h0" is the low-pass filter and "h1" is the high-pass filter.

The coefficients for the synthesis filters (decoder) are:

h0 = {1, 2, 1} * 1/2
h1 = {1, 2, -6, 2, 1} * 1/4

where "h0" is the low-pass filter and "h1" is the high-pass filter.

This wavelet transform has the following advantages:

- it allows an integer implementation

- a fast algorithm (lifting) exists

- it produces better quality images than the Haar wavelet used in [[Indeo 4]] for the same purpose

- it allows the perfect reconstruction of the input signal

==== Wavelet bands ====

The [[#Wavelet transform|Wavelet transform]] produces four wavelet bands whose properties are summarized in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! band !! name !! dimensions !! frequency components !! transform
|-
| align="center" | 0 || align="center" | LL ||
* width = pic_width/2
* height = pic_height/2
|| Low freqs in both horizontal and vertical directions || 2D Slant 8x8
|-
| align="center" | 1 || align="center" | HL ||
* width = pic_width/2
* height = pic_height/2
||
* Low freqs in the horizontal direction
* High freqs in the vertical direction
|| 1D Row Slant
|-
| align="center" | 2 || align="center" | LH ||
* width = pic_width/2
* height = pic_height/2
||
* High freqs in the horizontal direction
* Low freqs in the vertical direction
|| 1D Column Slant
|-
| align="center" | 3 || align="center" | HH ||
* width = pic_width/2
* height = pic_height/2
|| High freqs in both horizontal and vertical directions || No transform
|}

The type of the transform used to process a particular band is chosen according to its frequency content. The low frequency image components are the most important components for visual sensitivity. Therefore the transform is selected so that it can process the low frequency components more efficiently than the high frequency ones. For example, the two-dimensional slant transform is used to process the band 0 because it contains the low frequency components in both horizontal and vertical directions. But the band 1 contains low frequency components only in the horizontal direction that's why the one-dimensional slant transform applied to each of the 8 rows in a 8x8 block is used. Similar to it, the band 2 uses the one-dimensional slant transform applied to each of the 8 columns in a 8x8 block. The band 3 contains only high frequency components in both directions therefore no transform is applied to its data. This band will be coded using quantization and entropy coding only.

==== Wavelet recomposition ====

The following section describes the wavelet recomposition - the last stage of the indeo5 decoder reconstructing an image from a plurality of [[#Wavelet bands|wavelet bands]]. It receives up to four separate bands (labeled b0-b3) and generates recomposed plane data by performing two-dimensional wavelet synthesis.

=== Temporal scalability ===

In order to achieve the temporal scalability Indeo5 introduces special droppable frames. The main advantage of such frames is that those can be skipped without damaging the whole video sequence. If there is not enough processor power available, the decoder can decompress fewer frames and thus display the video at reduced frame rate.

== Planes ==
=== Plane data ===

Needs more analysis. Follows plane header.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! nb times !! comments
|-
| align="right" | 1 || value24 || || ||
|-
| align="right" | 1 || value25 || ! [[#value24|value24]] || || plan_data_size = value25
|-
| align="right" | 8 || value26 || [[#value25|value25]] == 1 || || plan_data_size = value26
|-
| align="right" | 24 || value27 || [[#value26|value26]] == 0xFF || || plan_data_size = value27
|}

=== Block header ===

Each plane is split into a number of blocks in the x and y directions. There is one of these headers one after another for each block in the plane.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! nb times !! comments
|-
| align="right" | 1 || value28 || || ||
|-
| align="right" | vlc || value29 || value28 && plane_state17 || ||
|-
| align="right" | 1 || value30 || !value28 && plane_state12 && plane_state1 || ||
|-
| align="right" | 4 || value31 || !value28 && four_blocks || ||
|-
| align="right" | 1 || value32 || !value28 && !four_blocks || ||
|-
| align="right" | vlc || value33 || !value28 && plane_state14 && !plane_state13 && (plane_state17 <nowiki>||</nowiki> value31/2) || ||
|-
| align="right" | vlc || value34 || rowspan=2 | !value28 && !(block_state4 & 2) && !plane_state12 || ||
|-
| align="right" | vlc || value35 || ||
|}

The 'plane_state' states come from plane parsing; they are yet to be connected to the previous data.

block_state4 is too complicated to explain here, sorry!

=== Block data ===

Follows block header. One of these for each plane that has 'plane_flags&1'. The variable 'run' starts at -1 and carries over from one coded plane to the next. I don't really know what I'm doing with vlc's so the names might not be correct... but their functional description is.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! nb times !! comments
|-
| align="right" | vlc || vlc || || rowspan=4 valign=top | while (vlc != vlcEnd) ||
|-
| align="right" | vlc || run_add || rowspan=3 | vlc == vlcEsc || run += run_add + 1
|-
| align="right" | vlc || lindex_lo || rowspan=2 | lindex = lindex_lo <nowiki>|</nowiki> (lindex_hi<<6)
|-
| align="right" | vlc || lindex_hi
|}

If vlc != vlcEsc then run_add is run_table[vlc], lindex is lindex_table[vlc].

After each loop, stored coefficient is: block[ scan_table[run] ] = level_tables[run][lindex-1].

The values of vlcEnd and vlcEsc are variable, as is the vlc table itself. However, they are all fixed for all the planes in the same block. run_table, lindex_table, scan_table are also fixed-per-block. level_tables is per-plane.

== Annexes ==

=== Standard picture sizes ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
! bgcolor="#f0f0f0" | pic_size_id
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | width
| 640 || 320 || 160 || 704 || 352 || 352 || 176 || 240 || 640 || 704 || 80 || 88 || 0 || 0 || 0 || custom
|-
! bgcolor="#f0f0f0" | height
| 480 || 240 || 120 || 224 || 240 || 288 || 144 || 180 || 240 || 240 || 60 || 72 || 0 || 0 || 0 || custom
|}

=== Band_info structure ===

This structure is a part of the [[#GOP header|GOP header]] and describes a wavelet band. Its size is usually 6 bits but can be extended up to 8 bits if the [[#ext_trans|ext_trans]] field is present. The same structure is used to describe both luminance and chrominance bands.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! value(s) !! comments
|-
| align="center" | 1 || mv_res || ||
* 0 - fullpel
* 1 - halfpel
|| Motion vector resolution.
|-
| align="center" | 1 || mb_size_id || ||
* 0 => double
* 1 => single
|| Macroblock size factor. The real size of the macroblock should be calculated as follows: mb_size = [[#blk_size_id|blk_size_id]] << ![[#mb_size_id|mb_size_id]].
|-
| align="center" | 1 || blk_size_id || ||
* 0 => 8x8
* 1 => 4x4
|| Block size id.
|-
| align="center" | 1 || trans_flg || ||
* 0 => standard
* 1 => non-standard
|| If this flag is set the field [[#ext_trans|ext_trans]] specifies a transform used to code this band explicitely. Otherwise the default transform is used.
|-
| align="center" | 2 || ext_trans || [[#trans_flg|trans_flg]] != 0 ||
* 0 => 2D Slant
* 1 => Row Slant
* 2 => Column Slant
* 3 => No transform
|| Specifies a transform that should be used instead of the default transform for this band.
|-
| align="center" | 2 || end_marker || || always == 0 || End marker terminating this structure.
|}

=== Table 1 ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
! bgcolor="#f0f0f0" | table1_id
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || default
|-
! bgcolor="#f0f0f0" | counter4
| 10 || 11 || 12 || 13 || 11 || 13 || 13 || 9
|-
! valign="top" bgcolor="#f0f0f0" | value19
| valign="top" |
{| border="0"
| 1
|-
| 2
|-
| 3
|-
| 4
|-
| 4
|-
| 7
|-
| 5
|-
| 5
|-
| 4
|-
| 1
|}
| valign="top" |
{| border="0"
| 2
|-
| 3
|-
| 4
|-
| 4
|-
| 4
|-
| 7
|-
| 5
|-
| 4
|-
| 3
|-
| 3
|-
| 2
|}
| valign="top" |
{| border="0"
| 2
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 4
|-
| 4
|-
| 3
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 3
|-
| 4
|-
| 4
|-
| 5
|-
| 6
|-
| 6
|-
| 4
|-
| 4
|-
| 3
|-
| 2
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 5
|-
| 4
|-
| 2
|-
| 2
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 4
|-
| 3
|-
| 3
|-
| 2
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 5
|-
| 4
|-
| 3
|-
| 3
|-
| 2
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 5
|-
| 5
|}
|}

default is used when !([[#ph_flags|ph_flags]] & 0x80)

== Games using indeo5 cutscenes ==

* Dino Crisis I: [http://en.wikipedia.org/wiki/Dino_Crisis]
* Lemmings Revolution: [http://en.wikipedia.org/wiki/Lemmings_Revolution]
* Mafia: The City of Lost Heaven [http://en.wikipedia.org/wiki/Mafia:_The_City_of_Lost_Heaven]
* Thief, Parts 1 & 2 : [http://en.wikipedia.org/wiki/Thief_(series)]

[[Category:Video Codecs]]

Indeo 5

2010-11-11T11:29:21Z

Maxpol: /* Picture header */

* FOURCCs: IV50
* Company: [[Intel]], then [[Ligos]]
* Samples: http://samples.mplayerhq.hu/V-codecs/IV50/
* Samples: http://ligos.com/videoclips/lions/lion_sif_ind5.zip
* Docs: http://www.ligos.com/pdf_docs/Indeo_doc.pdf
* Docs: http://www.ligos.com/pdf_docs/Indeo_FAQ.pdf
* Patent links: http://www.freepatentsonline.com/5532940.pdf
* Patent links: http://www.patentstorm.us/patents/5532940-description.html

== Introduction ==

Indeo5 is the latest version of Indeo Video Interactive(IVI). For an introduction to this compression algorithm see [[Indeo_4#Introduction|Indeo Video Interactive]].

== Indeo Video Interactive Version 5 (Indeo5) ==

For a description of the coding techniques see [[Indeo_4#Brief description of the coding techniques|Brief description of the coding techniques]].

For a description of the interactive features see [[Indeo_4#Brief description of the interactive features|Brief description of the interactive features]].

Indeo5 algorithm is mostly the same as indeo4 with the following differences:

- indeo5 uses a different bitstream format for picture and band headers that allows storing of compressed frames more compactly.

- indeo5 utilizes only the Slant transform. The Haar transform used in indeo4 was dropped due to its low quality.

- indeo5 uses the Daubechies (LeGall) 5/3 wavelet for the subband decomposition/recomposition instead of the Haar wavelet used in indeo4 in order to provide a better quality for the scalability mode.

- bidirectional frames mode seems to be dropped. Actually there is no indeo5 encoder supports its creating. Mac and Xanim decoders contain no code for handling of this kind of frames.

- indeo5 performs a partially encryption of the bitstream if a numeric password ("access key") was specified during encoding.

== Decoder specification ==

Indeo5 has the same picture layout and bitstream organization as indeo4. For a detailed description see [[Indeo_4#Picture layout|Indeo4 picture layout]] and [[Indeo_4#Bitstream organization|Bitstream organization]].

=== Conventions ===

Headers are described in some tables. Each row of those tables describes a value which may be read from the frame. Those tables and rows are presented in the order of appearance in the frame.

Here are the meaning of each columns:
* '''size''': The size of this value in bits. Bits are counted in LSB to MSB order. As an example, with the byte 01110000b, reading 3 bits then 5 bits will return 000b then 01110b. Reading more than 8 bits thus reads as a little-endian value. Think of the get_bits function as filling up the return value from its LSB, using the bits from each byte starting from their LSB.
* '''name''': Kind of variable name, used to reference the value. When a value is named valueX, it generally means we don't know it's purpose. Lines named alignmentX means that bits reader need to skip bits until next byte boundary.
* '''condition''': The value is present in the frame only if this condition is matched. No condition means that the value is always present.
* '''value(s)''': Description of constant values and their meaning.
* '''comments''': Some details about the content of the value.

=== Picture header ===

Picture header of indeo5 consists of three parts:

Picture_start_code, frame_type, frame_number
[GOP header]
Frame header

The first two bytes of a frame tell the decoder how the following data should be interpreted. These include three fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || PSC || always = 0x1F || indeo5 picture start code
|-
| align="center" | 3 || frame_type ||
* 0 => INTRA (key) frame
* 1 => INTER frame
* 2 => droppable INTER frame (scalability mode only)
* 3 => droppable INTER frame
* 4 => NULL frame
* 5...7 are illegal
|| frame type
|-
| align="center" | 8 || frame_number || 0...0xFF || frame number in GOP (0 for I frame)
|}

Null frames don't contain anything else than this header.

==== GOP header ====

This header is present in INTRA (key) frames only. It's used for transfering of some general information (i.e. picture layout) that will be either rarely or never changed during a video sequence. The values in this header are valid for all frames in the GOP.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! condition !! value(s) !! comments
|-
| align="center" | 8 || gop_flags || ||
* bit 0 => 1 - [[#gop_hdr_size|gop_hdr_size]] field is present
* bit 1 => subsampling format: 0 - YVU9, 1 - YV12
* bit 2 => unknown meaning
* bit 3 => transparency status?
* bit 4 =>
* bit 5 => access key protection: 1 - enabled
* bit 6 => local decoding: 1 - enabled
* bit 7 =>
|| GOP header flags (bit 0 is the LSB).
|-
| align="center" | 16 || gop_hdr_size || [[#gop_flags|gop_flags]] & 0x01 || || Size of this header in bytes. Only present in the bitstream if indicated by the [[#gop_flags|gop_flags]] bit 0.
|-
| align="center" | 32 || lock_word || [[#gop_flags|gop_flags]] & 0x20 || ||
Only present in the bitstream if "access key protection" is active (as indicated by the bit 5 of the [[#gop_flags|gop_flags]]). For a description of how to use this field see [[#Access key protection|Access key protection]].
|-
| align="center" | 2 || slice_size_id || [[#gop_flags|gop_flags]] & 0x40 ||
* 0 => 64 x 64
* 1 => 128 x 128
* 2 => 256 x 256
* 3 => unused
|| ID of slice size. Only present if "local decoding mode" is enabled (indicated by the bit 6 of the [[#gop_flags|gop_flags]]).
|-
| align="center" | 2 || luma_levels || ||
* 0 => no decomposition
* 1 => 1 level
* 2 => 2 levels
* 3 => forbidden
|| Number of wavelet decomposition levels for the luma plane. Number of resulting wavelet subbands can be calculated using the following equation: num_bands = [[#luma_levels|luma_levels]] * 3 + 1.
|-
| align="center" | 1 || chroma_levels || ||
* 0 => no decomposition
* 1 => forbidden
|| Number of wavelet decomposition levels for the chrominance planes. The value of "1" is forbidden because no knowing indeo5 software performs any decomposition of the chrominance planes.
|-
| align="center" | 4 || pic_size_id || || || Index into the table of the [[#Standard_picture_sizes|standard picture sizes]]. If the picture has dimensions not listed in the table then this field contains the value of "15" and the actual picture size will be coded using [[#pic_height|pic_height]] and [[#pic_width|pic_width]] fields.
|-
| align="center" | 13 || pic_height || rowspan="2" | [[#pic_size_id|pic_size_id]] == 15 || || Non-standard picture height.
|-
| align="center" | 13 || pic_width || || Non-standard picture width.
|-
| align="center" | variable || band_info_luma || || || Array of the [[#Band_info structure|Band_info structures]] describing each luminance band. For a description how to calculate the number of the luminance bands see here: [[#luma_levels|luma_levels]].
|-
| align="center" | 6-8 || band_info_chroma || || || Array of the [[#Band_info structure|Band_info structures]] describing each chrominance band. Because the chrominance planes are being NEVER decomposed by the existing indeo5 software there is only one band per chrominance plane and therefore only one descriptor of this type.
|-
| align="center" | 3 || alignment1 || rowspan="3" | [[#gop_flags|gop_flags]] & 0x08 || always == 0 || Alignment bits. Must be zero.
|-
| align="center" | 1 || color_flg || || This flag indicates if the [[#transp_color|transp_color]] field is present.
|-
| align="center" | 24 || transp_color || || Transparency fill color.
|-
| align="center" | ?? || alignment2 || || || Align the biteader on the next byte.
|-
| align="center" | 8 || value1 || || || Unused.
|-
| align="center" | 8 || value2 || || || Unused.
|-
| align="center" | 3 || value3 || || || Unused.
|-
| align="center" | 4 || value4 || || ||
|-
| align="center" | 1 || gop_ext_flg || || || This flag indicates if the [[#gop_ext|gop_ext]] field is present.
|-
| align="center" | variable || gop_ext || [[#gop_ext_flg|gop_ext_flg]] == 1 ||
do { val = getbits(16);
} while(val &0x8000);
|| GOP header extension.
|-
| align="center" | ?? || alignment3 || || || Align the biteader on the next byte.
|}

==== Frame header ====

This header is present in all kinds of frame except NULL. It's used mainly to transfer a huffman codebook for the macroblock signals and provide checksum information for debugging purposes.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! condition !! value(s) !! comments
|-
| align="center" | 8 || frame_flags || ||
* bit 0 => 1 - [[#pic_hdr_size|pic_hdr_size]] field is present
* bit 1 =>
* bit 2 =>
* bit 3 =>
* bit 4 => 1 - [[#frm_checksum|frm_checksum]] field is present.
* bit 5 => 1 - [[#frm_hdr_ext|frm_hdr_ext]] field is present.
* bit 6 => 1 - [[#mb_huff_desc|mb_huff_desc]] field is present. Otherwise select the default macroblock huffman codebook.
* bit 7 => 1 - [[#band_data_size|band_data_size]] field is present.
|| Frame flags (bit 0 is the LSB).
|-
| align="center" | 24 || pic_hdr_size || [[#frame_flags|frame_flags]] & 0x01 || || Size of the entire picture header in bytes. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 0.
|-
| align="center" | 16 || frm_checksum || [[#frame_flags|frame_flags]] & 0x10 || || Frame checksum for debugging purposes. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 4.
|-
| align="center" | variable || frm_hdr_ext || [[#frame_flags|frame_flags]] & 0x20 ||
To skip it, do the following:
do {
len = getbits(8);
for (i=0; i < len; i++) skipbits(8);
} while(len);
|| Unknown frame header extension. Its content will be ignored by the known indeo5 decoders. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 5.
|-
| align="center" | variable || mb_huff_desc || [[#frame_flags|frame_flags]] & 0x40 || || Macroblock huffman codebook descriptor. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 6. For a description of the format of the huffman codebook descriptors see [[Indeo_4#Codebook descriptors in the bitstream|Codebook descriptors in the bitstream]].
|-
| align="center" | 3 || value5 || || || Unused.
|-
| align="center" | ?? || alignment4 || || || Align the biteader on the next byte.
|}

=== Band header ===

This header describes a wavelet band.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! condition !! value(s) !! comments
|-
| align="center" | 8 || band_flags || ||
* bit 0 => 1 - this band is empty (doesn't contain any coded data).
* bit 1 => 1 - motion vector inheritance mode is enabled.
* bit 2 => 1 - qdelta parameter is present.
* bit 3 => 1 - qdelta inheritance mode is enabled.
* bit 4 => 1 - [[#rv_tab_corr|rv_tab_corr]] array is present.
* bit 5 => 1 - [[#band_hdr_ext|band_hdr_ext]] field is present.
* bit 6 => 1 - [[#rv_tab_sel|rv_tab_sel]] field is present. Otherwise use the default rv_table.
* bit 7 => 1 - [[#blk_huff_desc|blk_huff_desc]] field is present. Otherwise use the default block huffman codebook.
|| Band flags (bit 0 is the LSB).
|-
| align="center" | 24 || band_data_size || [[#frame_flags|frame_flags]] & 0x80 || || Size of the band data in bytes. Only present in the bitstream if indicated by the [[#frame_flags|frame_flags]] bit 7.
|-
| align="center" | 8 || num_rv_corr || rowspan="2" | [[#band_flags|band_flags]] & 0x10 || || Number of rv_table correction pairs. Must be <= 61. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 4.
|-
| align="center" | variable || rv_tab_corr || || Array of rv_table correction pairs. Its size is [[#num_rv_corr|num_rv_corr]] * 2 bytes. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 4.
|-
| align="center" | 3 || rv_tab_sel || [[#band_flags|band_flags]] & 0x40 || || Indicates which run-value table should be used for decoding. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 6.
|-
| align="center" | variable || blk_huff_desc || [[#band_flags|band_flags]] & 0x80 || || Block huffman codebook descriptor. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 7. For a description of the format of the huffman codebook descriptors see [[Indeo_4#Codebook descriptors in the bitstream|Codebook descriptors in the bitstream]].
|-
| align="center" | 1 || checksum_flag || || || If set [[#band_checksum|band_checksum]] field is present in the bitstream.
|-
| align="center" | 16 || band_checksum || [[#checksum_flag|checksum_flag]] || || Band checksum for debugging purposes. Only present in the bitstream if indicated by the [[#checksum_flag|checksum_flag]].
|-
| align="center" | 5 || band_glob_quant || || || Global quantization level for this band.
|-
| align="center" | ?? || alignment5 || || || Align the biteader on the next byte.
|-
| align="center" | variable || band_hdr_ext || [[#band_flags|band_flags]] & 0x20 ||
To skip it, do the following:
do {
len = getbits(8);
for (i=0; i < len; i++) skipbits(8);
} while(getbits(1));
|| Unknown band header extension. Its content will be ignored by the known indeo5 decoders. Only present in the bitstream if indicated by the [[#band_flags|band_flags]] bit 5.
|-
| align="center" | ?? || alignment6 || || || Align the biteader on the next byte.
|}

== Scalability mode ==

This special feature of Indeo5 allows the decoder to adapt playback to the processor power of the particular machine being used for playback. Indeo5 offers both spatial and temporal scalability. Read more about that technique here: [[Scalable Video Coding]].

=== Spatial scalability ===

Spatial scalability works by dividing the image into a number of frequency bands using wavelet decomposition. These bands represent the image at a different level of sharpness. All bands are necessary to perfectly recreate the original image. But if there is not enough processor power available, the decoder can decompress fewer bands of each frame, rather than simply dropping frames. This produces blurry images, but preserves the motion.

The scalability mode is controlled by the user during encoding. If this mode is disabled the encoder acts like an usual block-based transform compression algorithm: each of the three color planes will be processed using the Slant transform, quantization and Huffman coding.
If the scalability mode is enabled the encoder first performs subband decomposition using the [[Discrete Wavelet Transform]] (DWT). Although each color plane could be theoretically decomposed Indeo5 performs that only on the luminance plane data. This decomposition results in four wavelet bands, each of them is one-fourth of the original picture size. Further those band will be compressed using the Slant transform, quantization and Huffman coding.

==== Wavelet transform ====

The wavelet used in Indeo5 for decomposition/recomposition purposes is referred as CDF 5/3 or LeGall wavelet. It uses in a slightly different form in many other compression algorithms like [[JPEG 2000]] or [[Snow]]. The coefficients for the analysis filters (encoder) are:

h0 = {-1, 2, 6, 2, -1} * 1/8
h1 = {1, -2, 1} * 1/4

where "h0" is the low-pass filter and "h1" is the high-pass filter.

The coefficients for the synthesis filters (decoder) are:

h0 = {1, 2, 1} * 1/2
h1 = {1, 2, -6, 2, 1} * 1/4

where "h0" is the low-pass filter and "h1" is the high-pass filter.

This wavelet transform has the following advantages:

- it allows an integer implementation

- a fast algorithm (lifting) exists

- it produces better quality images than the Haar wavelet used in [[Indeo 4]] for the same purpose

- it allows the perfect reconstruction of the input signal

==== Wavelet bands ====

The [[#Wavelet transform|Wavelet transform]] produces four wavelet bands whose properties are summarized in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! band !! name !! dimensions !! frequency components !! transform
|-
| align="center" | 0 || align="center" | LL ||
* width = pic_width/2
* height = pic_height/2
|| Low freqs in both horizontal and vertical directions || 2D Slant 8x8
|-
| align="center" | 1 || align="center" | HL ||
* width = pic_width/2
* height = pic_height/2
||
* Low freqs in the horizontal direction
* High freqs in the vertical direction
|| 1D Row Slant
|-
| align="center" | 2 || align="center" | LH ||
* width = pic_width/2
* height = pic_height/2
||
* High freqs in the horizontal direction
* Low freqs in the vertical direction
|| 1D Column Slant
|-
| align="center" | 3 || align="center" | HH ||
* width = pic_width/2
* height = pic_height/2
|| High freqs in both horizontal and vertical directions || No transform
|}

The type of the transform used to process a particular band is chosen according to its frequency content. The low frequency image components are the most important components for visual sensitivity. Therefore the transform is selected so that it can process the low frequency components more efficiently than the high frequency ones. For example, the two-dimensional slant transform is used to process the band 0 because it contains the low frequency components in both horizontal and vertical directions. But the band 1 contains low frequency components only in the horizontal direction that's why the one-dimensional slant transform applied to each of the 8 rows in a 8x8 block is used. Similar to it, the band 2 uses the one-dimensional slant transform applied to each of the 8 columns in a 8x8 block. The band 3 contains only high frequency components in both directions therefore no transform is applied to its data. This band will be coded using quantization and entropy coding only.

==== Wavelet recomposition ====

The following section describes the wavelet recomposition - the last stage of the indeo5 decoder reconstructing an image from a plurality of [[#Wavelet bands|wavelet bands]]. It receives up to four separate bands (labeled b0-b3) and generates recomposed plane data by performing two-dimensional wavelet synthesis.

=== Temporal scalability ===

In order to achieve the temporal scalability Indeo5 introduces special droppable frames. The main advantage of such frames is that those can be skipped without damaging the whole video sequence. If there is not enough processor power available, the decoder can decompress fewer frames and thus display the video at reduced frame rate.

== Planes ==
=== Plane data ===

Needs more analysis. Follows plane header.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! nb times !! comments
|-
| align="right" | 1 || value24 || || ||
|-
| align="right" | 1 || value25 || ! [[#value24|value24]] || || plan_data_size = value25
|-
| align="right" | 8 || value26 || [[#value25|value25]] == 1 || || plan_data_size = value26
|-
| align="right" | 24 || value27 || [[#value26|value26]] == 0xFF || || plan_data_size = value27
|}

=== Block header ===

Each plane is split into a number of blocks in the x and y directions. There is one of these headers one after another for each block in the plane.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! nb times !! comments
|-
| align="right" | 1 || value28 || || ||
|-
| align="right" | vlc || value29 || value28 && plane_state17 || ||
|-
| align="right" | 1 || value30 || !value28 && plane_state12 && plane_state1 || ||
|-
| align="right" | 4 || value31 || !value28 && four_blocks || ||
|-
| align="right" | 1 || value32 || !value28 && !four_blocks || ||
|-
| align="right" | vlc || value33 || !value28 && plane_state14 && !plane_state13 && (plane_state17 <nowiki>||</nowiki> value31/2) || ||
|-
| align="right" | vlc || value34 || rowspan=2 | !value28 && !(block_state4 & 2) && !plane_state12 || ||
|-
| align="right" | vlc || value35 || ||
|}

The 'plane_state' states come from plane parsing; they are yet to be connected to the previous data.

block_state4 is too complicated to explain here, sorry!

=== Block data ===

Follows block header. One of these for each plane that has 'plane_flags&1'. The variable 'run' starts at -1 and carries over from one coded plane to the next. I don't really know what I'm doing with vlc's so the names might not be correct... but their functional description is.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! nb times !! comments
|-
| align="right" | vlc || vlc || || rowspan=4 valign=top | while (vlc != vlcEnd) ||
|-
| align="right" | vlc || run_add || rowspan=3 | vlc == vlcEsc || run += run_add + 1
|-
| align="right" | vlc || lindex_lo || rowspan=2 | lindex = lindex_lo <nowiki>|</nowiki> (lindex_hi<<6)
|-
| align="right" | vlc || lindex_hi
|}

If vlc != vlcEsc then run_add is run_table[vlc], lindex is lindex_table[vlc].

After each loop, stored coefficient is: block[ scan_table[run] ] = level_tables[run][lindex-1].

The values of vlcEnd and vlcEsc are variable, as is the vlc table itself. However, they are all fixed for all the planes in the same block. run_table, lindex_table, scan_table are also fixed-per-block. level_tables is per-plane.

== Annexes ==

=== Standard picture sizes ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
! bgcolor="#f0f0f0" | pic_size_id
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | width
| 640 || 320 || 160 || 704 || 352 || 352 || 176 || 240 || 640 || 704 || 80 || 88 || 0 || 0 || 0 || custom
|-
! bgcolor="#f0f0f0" | height
| 480 || 240 || 120 || 224 || 240 || 288 || 144 || 180 || 240 || 240 || 60 || 72 || 0 || 0 || 0 || custom
|}

=== Band_info structure ===

This structure is a part of the [[#GOP header|GOP header]] and describes a wavelet band. Its size is usually 6 bits but can be extended up to 8 bits if the [[#ext_trans|ext_trans]] field is present. The same structure is used to describe both luminance and chrominance bands.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size !! name !! condition !! value(s) !! comments
|-
| align="center" | 1 || mv_res || ||
* 0 - fullpel
* 1 - halfpel
|| Motion vector resolution.
|-
| align="center" | 1 || mb_size_id || ||
* 0 => double
* 1 => single
|| Macroblock size factor. The real size of the macroblock should be calculated as follows: mb_size = [[#blk_size_id|blk_size_id]] << ![[#mb_size_id|mb_size_id]].
|-
| align="center" | 1 || blk_size_id || ||
* 0 => 8x8
* 1 => 4x4
|| Block size id.
|-
| align="center" | 1 || trans_flg || ||
* 0 => standard
* 1 => non-standard
|| If this flag is set the field [[#ext_trans|ext_trans]] specifies a transform used to code this band explicitely. Otherwise the default transform is used.
|-
| align="center" | 2 || ext_trans || [[#trans_flg|trans_flg]] != 0 ||
* 0 => 2D Slant
* 1 => Row Slant
* 2 => Column Slant
* 3 => No transform
|| Specifies a transform that should be used instead of the default transform for this band.
|-
| align="center" | 2 || end_marker || || always == 0 || End marker terminating this structure.
|}

=== Table 1 ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
! bgcolor="#f0f0f0" | table1_id
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || default
|-
! bgcolor="#f0f0f0" | counter4
| 10 || 11 || 12 || 13 || 11 || 13 || 13 || 9
|-
! valign="top" bgcolor="#f0f0f0" | value19
| valign="top" |
{| border="0"
| 1
|-
| 2
|-
| 3
|-
| 4
|-
| 4
|-
| 7
|-
| 5
|-
| 5
|-
| 4
|-
| 1
|}
| valign="top" |
{| border="0"
| 2
|-
| 3
|-
| 4
|-
| 4
|-
| 4
|-
| 7
|-
| 5
|-
| 4
|-
| 3
|-
| 3
|-
| 2
|}
| valign="top" |
{| border="0"
| 2
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 4
|-
| 4
|-
| 3
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 3
|-
| 4
|-
| 4
|-
| 5
|-
| 6
|-
| 6
|-
| 4
|-
| 4
|-
| 3
|-
| 2
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 5
|-
| 4
|-
| 2
|-
| 2
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 4
|-
| 3
|-
| 3
|-
| 2
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 5
|-
| 4
|-
| 3
|-
| 3
|-
| 2
|-
| 1
|-
| 1
|}
| valign="top" |
{| border="0"
| 3
|-
| 4
|-
| 4
|-
| 5
|-
| 5
|-
| 5
|-
| 6
|-
| 5
|-
| 5
|}
|}

default is used when !([[#ph_flags|ph_flags]] & 0x80)

== Games using indeo5 cutscenes ==

* Dino Crisis I: [http://en.wikipedia.org/wiki/Dino_Crisis]
* Lemmings Revolution: [http://en.wikipedia.org/wiki/Lemmings_Revolution]
* Mafia: The City of Lost Heaven [http://en.wikipedia.org/wiki/Mafia:_The_City_of_Lost_Heaven]
* Thief, Parts 1 & 2 : [http://en.wikipedia.org/wiki/Thief_(series)]

[[Category:Video Codecs]]

Apple ProRes

2010-11-11T11:20:39Z

Maxpol: /* Frame header */

Apple ProRes

2010-11-11T09:50:42Z

Maxpol: /* Frame header */

Apple ProRes

2010-11-01T12:00:03Z

Maxpol: /* Frame layout */

Apple ProRes

2010-11-01T11:59:35Z

Maxpol: /* Binary packages and compatibility */

Apple ProRes

2010-11-01T11:56:20Z

Maxpol: /* Frame header */

Apple ProRes

2010-11-01T11:52:18Z

Maxpol: /* ProRes 422 Standard Definition / High Quality codec */

Apple ProRes

2010-10-17T21:41:26Z

Maxpol: /* ProRes Introduction */

ATRAC3plus

2010-10-03T17:03:28Z

Maxpol: /* Method D: sequence of numbers in ascending order */

* Format tag: uses WAVE_FORMAT_EXTENSIBLE with the "SubFormat" field set to the following [[GUID]]: E923AABF-CB58-4471-A119-FFFA01E4CE62
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3+/
* Stored in: [[Microsoft_Wave|WAV]] and [[Oma|Oma/Omg]] containers.
* Official information: http://www.sony.net/Products/ATRAC3/tech/atrac3plus.html

= ATRAC3plus introduction =

ATRAC3plus is a proprietary audio compression algorithm developed by [[Sony]]. As in the case of ATRAC3 ATRAC3plus represents the next generation of the ATRAC codec introduced in 1992 with the MiniDisc. Common use of that codec is in nowel Minidisc players and Portable Playstations made by [[Sony]].

Streams coded with ATRAC3plus are usually stored either in the [[Microsoft_Wave|WAV]] container (those files have the ".at3" extension though) or in the Sony's proprietary [[Oma|Oma/Omg]] container. In the case of the [[Microsoft_Wave|WAV]] container the undocumented [[GUID]]:
E923AABF-CB58-4471-A119-FFFA01E4CE62
is used in order to indicate the ATRAC3plus codec.

There is very limited number of software products supporting encoding/decoding of the ATRAC3plus streams; most of them are unfortunately available for [[Microsoft]] Windows only. Those are:

* Sony's own SonicStage software (Windows only)
* ATRAC Codec Plugin for Sony Media Software (Windows only)
* Sonic Studio's expensive N-code plugin for professionals (available for Windows and Mac OS X)

There is a multi-channel version of ATRAC3plus called "ATRAC-X".

= ATRAC3plus technical documentation =

=== Available bitrates ===

ATRAC3plus operates on fixed bitrates only. The following bitrates are offered by the Sony Encoding software:

bitrate frame size (stereo)
------------- -------------------
48 Kbps 280 bytes
64 Kbps 376 bytes
96 Kbps 560 bytes
128 Kbps 744 bytes
160 Kbps 936 bytes
192 Kbps 1120 bytes
256 Kbps 1488 bytes
320 Kbps 1864 bytes
352 Kbps 2048 bytes

=== Coding techniques ===

ATRAC3plus is a hybrid subband/MDCT codec like [[MP3]]. The signal is split into 16 subbands using [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filter] before MDCT and bit allocation. The sample-frame size is 2048 samples per channel.

After the subband splitting ATRAC3plus tries to extract sine waves from each subband using Generalized Harmonic Analysis (further GHA). GHA encodes parameters of extracted sine waves such as frequency, amplitude and phase into final bitstream.

After the sine waves extraction the remained signal (residual) will be transformed into frequency domain by a 128-point [http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform Modified discrete cosine transform]. The resultet MDCT spectrum will be devided into 32 quantization units of unequal width (higher frequencies - wider units). The relationship between QMF bands and quantization units (QU) is shown in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | QMF subband
| colspan="8" style="text-align:center;"| 0
| colspan="4" style="text-align:center;"| 1
| colspan="4" style="text-align:center;"| 2
| colspan="2" style="text-align:center;"| 3
| colspan="2" style="text-align:center;"| 4
| colspan="2" style="text-align:center;"| 5
| 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | Quant unit
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|}

The flowchart of the ATRAC3plus decoding process is shown below:

[[image:Atrac3plus_decoder_flow.png]]

"Bitstream decoder" decodes various sound parameters from supplied frame data. First the residual signal will be decoded by applying inverse quantization, power compensation, inverse MDCT and gain compensation. Then the sine waves will be synthesized according with their parameters such as frequency, amplitude and phase. Then the residual and the synthesized sine waves will be added together. Optionally, some white noise can be added if specified in the bitstream.

This processing will be repeated for each of 16 subbands. Finally the QMF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal.

Various algorithms are used to improve compression results:

* gain control for reducing pre-echo artifacts
* power compensation for better quality at low bitrates

The following techniques are used in order to make the compressed data smaller:

* variable-lenght ([[Huffman]]) coding
* [[Vector_Quantization|vector quantization]] based on trained tables
* [[Differential_Coding|differential coding]]

Probably the most interesting part of the ATRAC3plus codec is the Generalized Harmonic Analysis (GHA) - an inharmonic frequency analysis proposed by Norbert Wiener in 1930. The main advantage of that is an excellent frequency resolution that surpasses the short-time Discrete Furier transformation. However it requires huge amount of calculations. Several algorithms to work around that problem were introduced during last 20 years, for example the one proposed by Dr.Hirata.

==== Coding methods for compressing bitstream parameters ====

Coding methods described in this section serve the purpose of representing different bitstream parameters like word-length, scale factor etc. using a smaller number of bits. It will be achieved by exploring and removing redundancy from the signals being encoded. The coding techniques described here are [[Lossless_compression|lossless]].

===== Huffman coding =====

ATRAC3plus uses this coding technique widely. There are more than 130 different huffman tables in total for coding bitstream signals. Usually more frequently occuring values will have shorter codes.
ATRAC3plus huffman trees are [http://en.wikipedia.org/wiki/Canonical_Huffman_code canonical ones]. That means those can be stored very compactly by specifying the following parameters:

* number of bits of the shortest codeword
* number of bits of the longest codeword
* number of items for every bit length
* order of items

In my code I'm using the following descriptor in order to specify a canonical huffman table:

uint8_t min; /* shortest codeword length */
uint8_t max; /* longest codeword length */
uint8_t num_items[max - min + 1]; /* number of items for every bit length */

For example, the huffman table vlc_tab_index = 3 [[#Huffman tables for delta coding|here]] will be described as follows:

min = 1
max = 5
num_items[1, 0, 2, 3, 2]

The 2nd element of the array "num_items" is set to "0" because there is no codeword with the length of 2 bits.

The following C-pseudocode can be used for generating huffman tables from the descriptor described above during decoder initialization:

code = 0;
index = 0;

for (num_bits = min; num_bits <= max; num_bits++) {
for (i = num_items[num_bits]; i > 0; i--) {
bits [index] = num_bits;
codes[index] = code++;
index++;
}
code <<= 1;
}

The array "bits" receives length in bits for each codeword, "codes" receives codeword itself.

Finally, the order of codes need to be specified. A simple remapping table will be used to translate the code index into final code. For the table described above the translation table will look as follows:

0, 1, 7, 2, 3, 6, 4, 5

===== Delta coding =====

ATRAC3plus utilizes various delta-coding schemes in order to remove linear correlation from the signal. It often uses the [http://en.wikipedia.org/wiki/Modular_arithmetic modular arithmetic] as well. The main advantage of this coding is that only the half of the range of the difference values is required. An example: word-length information coefficients in the range 0...7 need to be transmitted compactly. Using delta coding this would require to code difference values in the range -7...+7, also 15 values.

In the case of modular arithmetic the range of the difference values can be reduced to 0...7 by introducing a "wrap-around" so that the final equation looks like this:

B = (A + delta) & 7;

Below an example with "wrap around":

Consider we need to code the value B = "1" and the reference value A = "6". Then the difference value (delta) will be = "-5". According with equation above the delta value of "3" can be used instead of "-5":

(6 + 3) & 7 = 1;

Another example without "wrap around":

Consider we need to code the value B = "7" and the reference value A = "2". Then the difference value (delta) will be = "5":

(2 + 5) & 7 = 7;

Further variable-length codes will be used to reduce amount of bits of difference values in accordance with their probability.

The following is a description of the delta-coding methods used in ATRAC3plus:

====== Method A: huffman-coded modulo difference to previous ======

Consider the following signal:

3, 6, 6, 3, 3, 3, 4, 2, 2, 1, 1, 1, 3

Now code it using delta coding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Coefficient !! Modulo delta value !! Huffman code !! Number of bits
|-
| align="center" | 3 || align="center" | - || align="center" | - || align="center" | 3
|-
| align="center" | 6 || align="center" | 3 || align="center" | 11110 || align="center" | 5
|-
| align="center" | 6 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 5 || align="center" | 1101 || align="center" | 4
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 4 || align="center" | 1 || align="center" | 100 || align="center" | 3
|-
| align="center" | 2 || align="center" | 6 || align="center" | 1110 || align="center" | 4
|-
| align="center" | 2 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 7 || align="center" | 101 || align="center" | 3
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 2 || align="center" | 1100 || align="center" | 4
|}

The 1st coefficient has no delta value associated with it because there is no previous value. It will be coded "as is" using fixed length of 3 bits. The following delta values get a variable-length code from the table val_tab_index = 2 [[#Huffman tables for delta coding|here]] so the final number of bits to be transmitted will be = 32.
Compared to the unpacked version (13 x 3 bits = 39 bits) the coding method described above will yield a bit-reduction of 7 bits (18% smaller).

====== Method B: huffman-coded modulo difference to master ======

In a stereo mix the signal of the left channel is often very similar to the signal of the right channel (i.e. there is a high cross-correlation between the channels). In this case the estimated sound parameters like word-length or scale factor will have a high similarity as well. Then coding the differential signal between the channels can lead to a significant bit reduction.
Surely at least the one of the channels must be coded independently. Such a channel will be called "master" (it's usually the left channel but ATRAC3plus has the possibility to make the right channel act like a master as well). For the 2nd channel only the difference to master will be coded. The 2nd channel will be called "slave" in this case.

Below an example of such a high-correlated signal:

Left : 6, 5, 6, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1
Right: 6, 5, 6, 2, 2, 2, 3, 1, 1, 1, 2, 1, 1
Diff : 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0

Coding the difference signal using the table val_tab_index = 0 [[#Huffman tables for delta coding|here]] will result in another signal 15 bits long. Compared to the unpacked version (13 x 3 bits = 39 bits) that coding method will yield a bit-reduction of 24 bits (62% smaller).

====== Method C: shorter delta to min ======

Sometimes coefficients in a signal are very close to each other, so subtracting the minimum value from each coefficient will result in smaller deltas whose can be coded using fewer bits.

An example:

2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1

As one can see the values in the sequence above are very similar to each other. Let us find minimum and maximum values and then determine the number of delta bits:

min = 1; max = 2; num_delta_bits = ilog2(max - min + 1) = 1 bit

Now let us encode the sequence above using shorter deltas:

num_delta_bits = 1 will be coded as a 2-bit value
min = 1 will be coded as a 3-bit value
deltas: 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0

The encoded signal is 5 + 1 x 15 = 20 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 25 bits (55% smaller).

Another example:

1, 2, 3, 2, 4, 2, 1, 2, 3, 3, 1, 4, 4, 1, 1

min = 1; max = 4; num_delta_bits = ilog2(max - min + 1) = 2 bits

Now the encoded signal:

num_delta_bits = 2 (will be coded as a 2-bit value)
min = 1 (will be coded as a 3-bit value)
deltas: 0, 1, 2, 1, 3, 1, 0, 1, 2, 2, 0, 3, 3, 0, 0

The encoded signal is 5 + 2 x 15 = 35 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 10 bits (22% smaller).

====== Method D: sequence of numbers in ascending order ======

Sometimes ATRAC3plus have to deal with sequences of numbers (i.e. gain control position information) where all items are known to be in ascending order (i.e. satisfy the following equation: ''Vn+1 > Vn''). Such sequences can be packed without any additional bitstream information by examining previous value (predecessor), calculating magnitude between it and the maximum value and making the decision about number of bits of the next delta value.

Consider the following sequence:

Position index: 0, 1, 2, 3, 4, 5, 6, 7
---------------------------------------------
Position info : 5, 7, 14, 15, 18, 25, 29, 30
---------------------------------------------
Num delta bits: 5, 5, 5, 4, 4, 3, 1, 0

1st coefficient (position index = 0) will be coded directly using 5 bits because the sequence should start somewhere.
The following coefficients (except one with the value of "30") will be coded according to the following pseudocode:

num_delta_bits = ilog2(31 - prev_val);
if (num_delta_bits == 5)
new_val = get_bits(5);
else
new_val = prev_val + get_bits(num_delta_bits) + 1;

Let us return to our sequence. The 2nd value will be coded directly as well using 5 bits because ilog2(31 - 5) = 5. Similar for the 3rd one. No delta coding is applied in that case. The 4th value will be delta-coded using 4 bits:

num_delta_bits = ilog2(31 - 15) = 4 bits;
delta = 18 - 15 - 1 = 2

And so on until we reach the last value = 30. In this case there is only one value that meets our condition ''Vn+1 > Vn'': the value of "31". In this case no delta will be transmitted and the coming value will be calculated just as:

new_val = prev_val + 1;

Therefore the resulting sequence will be 27 bits long. Compared to the unpacked version (8 x 5 bits = 40 bits) this packing method will yield a bit-reduction of 13 bits (32% smaller).

===== Vector quantization with residual encoding =====

One further packing technique used in ATRAC3plus is based on so-called "shape prediction vectors". Encoder decomposes a signal (word-length or scale factor info) into "shape prediction" + residual. Then only the index of the "shape prediction vector" and the huffman-coded residual will be transmitted. The main advantage of this method is when the shape matches the coded signal closely, the residual can be represented very compactly (usually 1-2 bits per value). Moreover, the majority of values of the residual will turn into zeroes, which can be further packed.

Each entry of the "shape prediction tables" contain an average value over 3 coefficients. This helps to keep those tables comparable small. For example, for a signal of 32 values each "shape table" will have 10 entries (last entry contains usually an average value over 5 coefficients).

Consider the following signal to be encoded:

7, 7, 6, 5, 4, 4, 3, 2, 2, 2, 1, 1

Let us "quantize" that signal by diving it into 4 * 3 groups and find the averaged value in each group:

floor((7 + 7 + 6) / 3 + 0.5) = 7,
floor((5 + 4 + 4) / 3 + 0.5) = 4,
floor((3 + 2 + 2) / 3 + 0.5) = 2,
floor((2 + 1 + 1) / 3 + 0.5) = 1

Find a "shape table" in the trained set that closely matches our "quantized" version. It will be (for example):
7, 5, 2, 1

Now compute the residual:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | Original signal
| style="text-align:center;"| 7
| style="text-align:center;"| 7
| style="text-align:center;"| 6
| style="text-align:center;"| 5
| style="text-align:center;"| 4
| style="text-align:center;"| 4
| 3 || 2 || 2 || 2 || 1 || 1
|-
! bgcolor="#f0f0f0" | Unpacked shape table
| 7 || 7 || 7 || 5 || 5 || 5 || 2 || 2 || 2 || 1 || 1 || 1
|-
! bgcolor="#f0f0f0" | Residual
| 0 || 0 || -1 || 0 || -1 || -1 || 1 || 0 || 0 || 1 || 0 || 0
|}

Now select a huffman table that represents the residual above as small as possible. The following huffman tree assigns the shortest code (1 bit) to the most frequently occuring symbol = "0" and 2-bit codes to the others: "1" and "-1":

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | -1
|}

The packed signal will occupy 21 bits: 4 bits "shape table" index + 17 bits residual(7 bits for "zeroes" + 10 bits for "non-zeroes"). Compared to the unpacked version (12 x 3 bits = 36 bits) this packing method will yield a bit-reduction of 15 bits (42% smaller).

===== Value grouping with "group coded" flag =====

If a signal contains lots of zeroes, grouping several values together and assigning the "group coded" flag to each group will achieve a significant bit-reduction. Consider the following sequence of numbers to be encoded:

0, 0, 1, 2, 0, 0, 3, 3, 0, 0, 0, 7, 0, 6, 0, 0

Let us cluster each two values together and assign the "coded" flag (1 bit) to each group:

(0, 0); flag = 0 (group not coded)
(1, 2); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(3, 3); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(0, 7); flag = 1 (group coded)
(0, 6); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)

Thereafter, each "not coded" group requires only one bit to be transmitted indicating that all values in that group are zero. On the other hand, each "coded" group requires one extra bit to be transmitted indicating that at least one value in that group is non-zero. In the case above that overhead is worthwhile because the half of the signal contains zeroes.

The encoded signal is 4 x 1 + 4 x 7 = 32 bits long while the unpacked one is 16 x 3 = 48 bits long. The bit-reduction is thereafter 16 bits (33% smaller).

== Multichannel ATRAC3plus (ATRAC-X) ==

ATRAC3plus supports multichannel streams (up to 8 channels). Such streams are encoded in units customary called "channel block"; each block contains max. 2 channels (ie can be MONO or STEREO). For example, taking the channel_id = 3 and looking at the table below we have a stream containing 2 channel blocks: 1 stereo + 1 mono and thus 3 channels.
The base codec operates on either MONO or STEREO channel blocks only.

=== ATRAC-X channel configurations ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! channel_id !! total channels !! number of channel blocks !! speaker mapping
|-
| align="center" | 0 || align="center" | 0 || align="center" | undefined ||
* undefined
|-
| align="center" | 1 || align="center" | 1 || align="center" | 1 ||
* front: center (MONO)
|-
| align="center" | 2 || align="center" | 2 || align="center" | 1 ||
* front: L, R (STEREO)
|-
| align="center" | 3 || align="center" | 3 || align="center" | 2 ||
* front: L, R
* front: center
|-
| align="center" | 4 || align="center" | 4 || align="center" | 3 ||
* front: L, R
* front: center
* rear: surround
|-
| align="center" | 5 || align="center" | 5+1 || align="center" | 4 ||
* front: L, R
* front: center
* rear: L, R
* LFE
|-
| align="center" | 6 || align="center" | 6+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* rear: center
* LFE
|-
| align="center" | 7 || align="center" | 7+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* side: L, R
* LFE
|}

== Bitstream overview ==

The table below shows the bitstream organization of ATRAC3plus at the top-level. Depends on [[#ATRAC-X channel configurations|channel configuration]] a typical frame may contain more than one channel block. In this case the additional fields [[#channel_block_type|channel_block_type]] and [[#channel_block_data|channel_block_data]] will be included for each block.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! number of bits !! value !! description
|-
| align="center" | start_marker || align="center" | 1 || align="center" | 0 ||
marks the start of the ATRAC3plus bitstream
|-
| align="center" | channel_block_type || align="center" | 2 ||
* 00b - MONO block
* 01b - STEREO block
* 10b - EXTENSION block
| align="center" | type of the channel block
|-
| align="center" | channel_block_data || align="center" | variable || || align="center" | contains encoded sound information
|-
| align="center" | terminator || align="center" | 2 || align="center" | 11b || align="center" | indicates the end of the bitstream
|}

=== Channel block types ===

There are following channel block types in ATRAC3plus:

* '''Mono channel block''': contains monaural sound data.
* '''Stereo channel block''': contains stereophonic sound data.
* '''Extension block''': as indicated by its name it's intended to carry some extension information. Its purpose is unknown though due to the lack of an official description. All existing decoder implementations are programmed to ignore blocks of that type.

=== Channel block layout ===

ATRAC3plus was designed to provide a high-quality sound compression. Therefore it tries to save as much bits as possible. It uses a new coding scheme for channel blocks compared to ATRAC3: channels in a stereo sound are no more coded separately but rather in one stereo channel block. The bitstream for such a block provides the possibility for both channels to share several sound parameters so that there is no need to transmit the same things twice. Depends on correlation between the channels this can lead to a significant bit reduction and thus improve coding quality.

A mono/stereo channel block contains the following pieces of sound information:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! size in bits !! description
|-
| align="center" | [[#Sound header|sound_header]] || align="center" | 6 || width="700" | defines some global sound parameters
|-
| align="center" | [[#Word-length information|wordlength_info]] || align="center" | variable || quantization word length information for each quant unit
|-
| align="center" | scalefactor_info || align="center" | variable || quantization scale factor indexes for each coded quant unit
|-
| align="center" | codetable_info || align="center" | variable || code table table information for each coded quant unit
|-
| align="center" | spectra || align="center" | variable || huffman-coded spectral information for each coded quant unit
|-
| align="center" | window_info || align="center" | variable || tells which IMDCT window shape should be used during the sound reconstruction
|-
| align="center" | gain_info || align="center" | variable || gain envelope used by the gain compensation
|-
| align="center" | gha_info || align="center" | variable || information about sine-like waves in the compressed sound obtained by the GHA. It contains quantized frequency, amplitude and phase for each wave to be synthesized in the decoder.
|-
| align="center" | noise_info || align="center" | 1/9 || contains noise flag, level index and table selector for the white noise to be added during decoding.
|}

==== Sound header ====

At the start of each channel block the sound header is located. It contains the following fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || num_quant_units || valid values: 0...27,31 || width="500" | number of coded quantization units - 1. The value of "0" indicates one coded unit, the value of "31" - 32 ones. The values 28, 29 and 30 are invalid.
|-
| align="center" | 1 || align="center" | x_flag || || to be figured out
|}

==== Word-length information ====

===== Coding summary =====

Word-length (or quantization precision) information follows the sound header. It defines the word-length parameter for each [[#num_quant_units|coded quantization unit]]. This parameter is in the range 0...7, where the value of "7" indicates the highest quantization precision and the value of "1" - the lowest one. The value of "0" means no data, i.e. the corresponding quantization unit was not coded.

In the case of the stereo channel block the word-length parameters for the channel 1(L) will be transmitted first followed by the the word-length parameters for the channel 2(R). The word-lengths for the channel 1 are always coded independently. The word-lengths for the channel 2 can be coded either independently or relative to the channel 1. In this case the 1st channel is called "master" and the 2nd one - "slave".
The word-lengths for the mono block will be coded just like the channel 1 in the stereo block.

In order to keep the word-length data as small as possible ATRAC3plus uses several coefficient packing techniques achieving different amount of bits needed for transmission:

* the coefficients are coded directly (3 bits value). This means no packing and used at high bitrates because the frame size is big enough to keep the infomation unpacked.

* differential coding + huffman-coded delta: the first coefficient is coded directly; all others are huffman-coded deltas to the previous coefficient.

* prediction + huffman-coded residual: this techniques offers the best packing and used at low bitrates. It's analogous to the lossless coding and based on trained shape tables serving as prediction. Later the huffman-coded residual will be added to the prediction prefectly reconstructing the coefficients.

===== Reconstruction of trimmed word-length coefficients =====

Word-length coefficient of the trailing quantization units corresponding to the high spectral bands tend to be either 1 (low-precision) or 0 (not coded). Such coefficients will be ommited and one the following modes will be used in order to reconstruct their values during decoding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! mode code(2 bits) !! num_coded_vals !! split_point_delta !! Action(master) !! Action(slave)
|-
| align="center" | 0 || align="center" | not present
|rowspan="3" style="text-align:center;" | not present
|colspan="2" style="text-align:center;" | no trimmed coefficients
|-
| align="center" | 1
|rowspan="3" style="text-align:center;" | 5 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients to "0"
|-
| align="center" | 2 || width="220" | set all trimmed coefficients to "1" || width="220" | for each trimmed coefficient read one bit of its direct value
|-
| align="center" | 3 || align="center" | 2 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients up to split point to "1" and after split point - to "0". The split point is calculated differently for master and slave channels (see below)
|}

To calculate the split point from [[#split_point_delta|split_point_delta]] do the following:

* for the master channel: number of zeroes = split_point_delta + 1
* for the slave channel: number of ones = split_point_delta + 3

The following C-pseudocode shows how to parse a bitstream according with the table above:

mode = get_bits(2);
if (mode) {
num_coded_vals = get_bits(5);
if (mode == 3)
split_point_delta = get_bits(2);
} else {
num_coded_vals = [[#num_quant_units|num_quant_units]];
}

The following C-pseudocode shows how to reconstruct trimmed word-length coefficients according with the table above:

switch (mode) {
case 0: /* no further action */
break;
case 1:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
break;
case 2:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++) {
if (channel == master)
wl_coeffs[pos] = 1;
else
wl_coeffs[pos] = get_bits(1);
}
break;
case 3:
if (channel == master)
split_point = [[#num_quant_units|num_quant_units]] - split_point_delta - 1;
else
split_point = num_coded_vals + split_point_delta + 3;

for (pos = num_coded_vals; pos < split_point; pos++)
wl_coeffs[pos] = 1;

for (; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
}

===== Word-length coding in detail =====

The word-length information for each channel will be coded as follows:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! comments
|-
| align="center" | 2 || coding_mode || width="500" | indicates the coding mode used.
|-
| align="center" | variable || align="center" | coeff_info || word-length coefficients coded according with the [[#coding_mode|coding_mode]].
|}

The [[#coding_mode|coding_mode]] parameter may be interpreted differently depends on the channel number. The following pseudocode examples explain the coding modes in detail:

===== Mode 0 (master and slave) =====

All coefficients will be directly coded as follows:

for (i = 0; i < [[#num_quant_units|num_quant_units]]; i++)
wl_coeffs[i] = get_bits(3);

===== Mode 1 (master) =====

Leading "n" values are stored directly while trailing ones are packed using [[#Method C: shorter delta to min|Method C: shorter delta to min]] method.

Data stored in the bitstream:

* 2 bits: index of the table of weigths, "0" - indicates "no table used"
* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 5 bits: number of directly coded coefficients ('''num_direct_coeffs'''). This value must be < [[#num_coded_vals|num_coded_vals]]
* 2 bits: size of deltas in bits ('''delta_bits''')
* 3 bits: minimum value ('''min_value''')
* for each '''num_direct_coeffs'''
** 3 bits: coefficient value
* if '''delta_bits''' > 0: for each ([[#num_coded_vals|num_coded_vals]] - '''num_direct_coeffs''')
** '''delta_bits''': delta value to be added to the '''min_value'''

The following C-pseudocode summarizes all above:

weigths_tab_indx = get_bits(2); /* get index of weights table to be added after decoding */

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

num_direct_coeffs = get_bits(5);
if (num_direct_coeffs > [[#num_coded_vals|num_coded_vals]])
ABORT("Invalid number of directly coded coefficients");

delta_bits = get_bits(2);
min_value = get_bits(3);

for (pos = 0; pos < num_direct_coeffs; pos++)
wl_coeffs[pos] = get_bits(3);

for (; pos < num_coded_vals; pos++) {
if (delta_bits)
wl_coeffs[pos] = min_value + get_bits(delta_bits);
else
wl_coeffs[pos] = min_value;
}

/* reconstruct trimmed coefficients as described [[#Reconstruction of trimmed word-length coefficients|here]] */

/* add weighting coefficients if requested */
if (weigths_tab_indx) {
for (pos = 0; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = [[#Tables of weights|wl_weights]][channel_num][weights_tab_indx - 1][pos];
}

===== Mode 1 (slave) =====

Coding method: [[#Method B: huffman-coded modulo difference to master|Huffman-coded modulo difference to master]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 2 bits: indicates which huffman table from [[#Huffman tables for delta coding|this set]] should be used for decoding
* for each [[#num_coded_vals|num_coded_vals]]
** huffman-coded delta value to be added to the corresponding value of the master channel

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

vlc_sel = get_bits(2); /* selects a huffman table from [[#Huffman tables for delta coding|this set]] */

for (i = 0; i < [[#num_coded_vals|num_coded_vals]]; i++) {
delta = get_vlc(vlc_sel);
wl_coeffs[i] = (master_ch->wl_coeffs[i] + delta) & 7;
}

===== Mode 2 (master) =====

Coding method: [[#Vector quantization with residual encoding|Vector quantization with residual encoding]] and [[#Value grouping with "group coded" flag|Value grouping with "group coded" flag]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]].
* 1 bit: '''enable_grouping''' flag. "1" indicates that residual values were coded pairwise (in groups of two).
* 1 bit: selects one of the first two huffman tables from [[#Huffman tables for delta coding|this set]].
* 3 bits: '''start_value''' selecting a subset of "shape tables" from the trained set.
* 4 bits: '''shape_index''' selecting a "shape table" within the subset indicated by '''start_value'''.
* for each [[#num_coded_vals|num_coded_vals]]
** if '''enable_grouping''' == 1:
*** 1 bit: '''group_coded''' flag
*** if '''group_coded''' == 1:
**** 2 huffman-coded residual values to be added to the unpacked "shape table" using modular arithmetic
** if '''enable_grouping''' == 0:
*** one huffman-coded residual value to be added to the unpacked "shape table" using modular arithmetic

== Annex A: Decoding tables ==

=== Word-length related tables ===

==== Tables of weights ====

The weights below will be added to the decoded word-length coefficients. The tables are organized as follows:
* [channel_number: 0 or 1][index: 0...2][coeff_indx: 0...31]

wl_weights[2][3][32] = {
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
},
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 5, 5, 5, 5, 3, 3, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
};

==== Huffman tables for delta coding ====

PLEASE NOTE: delta values indicated in the tables below will be added using modular arithmetic as described [[#Delta coding based on modular arithmetic|here]], so in the case of "wrap around" the value of "7" will be treated as "-1", the value of "6" = "-2" and so on.

* '''vlc_tab_index = 0''', delta range -1...1

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | 7
|}

* '''vlc_tab_index = 1''', delta range -2...2

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 2
|-
| align="center" | 110 || align="center" | 3 || align="center" | 6
|-
| align="center" | 111 || align="center" | 3 || align="center" | 7
|}

* '''vlc_tab_index = 2''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 5
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 3
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 4
|}

* '''vlc_tab_index = 3''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 3
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 4
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 5
|}

[[Category:Audio Codecs]]
[[Category: Multichannel Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]

ATRAC3plus

2010-10-01T11:50:21Z

Maxpol: /* Value grouping with "group coded" flag */

* Format tag: uses WAVE_FORMAT_EXTENSIBLE with the "SubFormat" field set to the following [[GUID]]: E923AABF-CB58-4471-A119-FFFA01E4CE62
* Company: [[Sony]]
* Samples: http://samples.mplayerhq.hu/A-codecs/ATRAC3+/
* Stored in: [[Microsoft_Wave|WAV]] and [[Oma|Oma/Omg]] containers.
* Official information: http://www.sony.net/Products/ATRAC3/tech/atrac3plus.html

= ATRAC3plus introduction =

ATRAC3plus is a proprietary audio compression algorithm developed by [[Sony]]. As in the case of ATRAC3 ATRAC3plus represents the next generation of the ATRAC codec introduced in 1992 with the MiniDisc. Common use of that codec is in nowel Minidisc players and Portable Playstations made by [[Sony]].

Streams coded with ATRAC3plus are usually stored either in the [[Microsoft_Wave|WAV]] container (those files have the ".at3" extension though) or in the Sony's proprietary [[Oma|Oma/Omg]] container. In the case of the [[Microsoft_Wave|WAV]] container the undocumented [[GUID]]:
E923AABF-CB58-4471-A119-FFFA01E4CE62
is used in order to indicate the ATRAC3plus codec.

There is very limited number of software products supporting encoding/decoding of the ATRAC3plus streams; most of them are unfortunately available for [[Microsoft]] Windows only. Those are:

* Sony's own SonicStage software (Windows only)
* ATRAC Codec Plugin for Sony Media Software (Windows only)
* Sonic Studio's expensive N-code plugin for professionals (available for Windows and Mac OS X)

There is a multi-channel version of ATRAC3plus called "ATRAC-X".

= ATRAC3plus technical documentation =

=== Available bitrates ===

ATRAC3plus operates on fixed bitrates only. The following bitrates are offered by the Sony Encoding software:

bitrate frame size (stereo)
------------- -------------------
48 Kbps 280 bytes
64 Kbps 376 bytes
96 Kbps 560 bytes
128 Kbps 744 bytes
160 Kbps 936 bytes
192 Kbps 1120 bytes
256 Kbps 1488 bytes
320 Kbps 1864 bytes
352 Kbps 2048 bytes

=== Coding techniques ===

ATRAC3plus is a hybrid subband/MDCT codec like [[MP3]]. The signal is split into 16 subbands using [http://en.wikipedia.org/wiki/Quadrature_mirror_filter Quadrature Mirror Filter] before MDCT and bit allocation. The sample-frame size is 2048 samples per channel.

After the subband splitting ATRAC3plus tries to extract sine waves from each subband using Generalized Harmonic Analysis (further GHA). GHA encodes parameters of extracted sine waves such as frequency, amplitude and phase into final bitstream.

After the sine waves extraction the remained signal (residual) will be transformed into frequency domain by a 128-point [http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform Modified discrete cosine transform]. The resultet MDCT spectrum will be devided into 32 quantization units of unequal width (higher frequencies - wider units). The relationship between QMF bands and quantization units (QU) is shown in the table below:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | QMF subband
| colspan="8" style="text-align:center;"| 0
| colspan="4" style="text-align:center;"| 1
| colspan="4" style="text-align:center;"| 2
| colspan="2" style="text-align:center;"| 3
| colspan="2" style="text-align:center;"| 4
| colspan="2" style="text-align:center;"| 5
| 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! bgcolor="#f0f0f0" | Quant unit
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
| 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23 || 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|}

The flowchart of the ATRAC3plus decoding process is shown below:

[[image:Atrac3plus_decoder_flow.png]]

"Bitstream decoder" decodes various sound parameters from supplied frame data. First the residual signal will be decoded by applying inverse quantization, power compensation, inverse MDCT and gain compensation. Then the sine waves will be synthesized according with their parameters such as frequency, amplitude and phase. Then the residual and the synthesized sine waves will be added together. Optionally, some white noise can be added if specified in the bitstream.

This processing will be repeated for each of 16 subbands. Finally the QMF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal.

Various algorithms are used to improve compression results:

* gain control for reducing pre-echo artifacts
* power compensation for better quality at low bitrates

The following techniques are used in order to make the compressed data smaller:

* variable-lenght ([[Huffman]]) coding
* [[Vector_Quantization|vector quantization]] based on trained tables
* [[Differential_Coding|differential coding]]

Probably the most interesting part of the ATRAC3plus codec is the Generalized Harmonic Analysis (GHA) - an inharmonic frequency analysis proposed by Norbert Wiener in 1930. The main advantage of that is an excellent frequency resolution that surpasses the short-time Discrete Furier transformation. However it requires huge amount of calculations. Several algorithms to work around that problem were introduced during last 20 years, for example the one proposed by Dr.Hirata.

==== Coding methods for compressing bitstream parameters ====

Coding methods described in this section serve the purpose of representing different bitstream parameters like word-length, scale factor etc. using a smaller number of bits. It will be achieved by exploring and removing redundancy from the signals being encoded. The coding techniques described here are [[Lossless_compression|lossless]].

===== Huffman coding =====

ATRAC3plus uses this coding technique widely. There are more than 130 different huffman tables in total for coding bitstream signals. Usually more frequently occuring values will have shorter codes.
ATRAC3plus huffman trees are [http://en.wikipedia.org/wiki/Canonical_Huffman_code canonical ones]. That means those can be stored very compactly by specifying the following parameters:

* number of bits of the shortest codeword
* number of bits of the longest codeword
* number of items for every bit length
* order of items

In my code I'm using the following descriptor in order to specify a canonical huffman table:

uint8_t min; /* shortest codeword length */
uint8_t max; /* longest codeword length */
uint8_t num_items[max - min + 1]; /* number of items for every bit length */

For example, the huffman table vlc_tab_index = 3 [[#Huffman tables for delta coding|here]] will be described as follows:

min = 1
max = 5
num_items[1, 0, 2, 3, 2]

The 2nd element of the array "num_items" is set to "0" because there is no codeword with the length of 2 bits.

The following C-pseudocode can be used for generating huffman tables from the descriptor described above during decoder initialization:

code = 0;
index = 0;

for (num_bits = min; num_bits <= max; num_bits++) {
for (i = num_items[num_bits]; i > 0; i--) {
bits [index] = num_bits;
codes[index] = code++;
index++;
}
code <<= 1;
}

The array "bits" receives length in bits for each codeword, "codes" receives codeword itself.

Finally, the order of codes need to be specified. A simple remapping table will be used to translate the code index into final code. For the table described above the translation table will look as follows:

0, 1, 7, 2, 3, 6, 4, 5

===== Delta coding =====

ATRAC3plus utilizes various delta-coding schemes in order to remove linear correlation from the signal. It often uses the [http://en.wikipedia.org/wiki/Modular_arithmetic modular arithmetic] as well. The main advantage of this coding is that only the half of the range of the difference values is required. An example: word-length information coefficients in the range 0...7 need to be transmitted compactly. Using delta coding this would require to code difference values in the range -7...+7, also 15 values.

In the case of modular arithmetic the range of the difference values can be reduced to 0...7 by introducing a "wrap-around" so that the final equation looks like this:

B = (A + delta) & 7;

Below an example with "wrap around":

Consider we need to code the value B = "1" and the reference value A = "6". Then the difference value (delta) will be = "-5". According with equation above the delta value of "3" can be used instead of "-5":

(6 + 3) & 7 = 1;

Another example without "wrap around":

Consider we need to code the value B = "7" and the reference value A = "2". Then the difference value (delta) will be = "5":

(2 + 5) & 7 = 7;

Further variable-length codes will be used to reduce amount of bits of difference values in accordance with their probability.

The following is a description of the delta-coding methods used in ATRAC3plus:

====== Method A: huffman-coded modulo difference to previous ======

Consider the following signal:

3, 6, 6, 3, 3, 3, 4, 2, 2, 1, 1, 1, 3

Now code it using delta coding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Coefficient !! Modulo delta value !! Huffman code !! Number of bits
|-
| align="center" | 3 || align="center" | - || align="center" | - || align="center" | 3
|-
| align="center" | 6 || align="center" | 3 || align="center" | 11110 || align="center" | 5
|-
| align="center" | 6 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 5 || align="center" | 1101 || align="center" | 4
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 4 || align="center" | 1 || align="center" | 100 || align="center" | 3
|-
| align="center" | 2 || align="center" | 6 || align="center" | 1110 || align="center" | 4
|-
| align="center" | 2 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 7 || align="center" | 101 || align="center" | 3
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 1 || align="center" | 0 || align="center" | 0 || align="center" | 1
|-
| align="center" | 3 || align="center" | 2 || align="center" | 1100 || align="center" | 4
|}

The 1st coefficient has no delta value associated with it because there is no previous value. It will be coded "as is" using fixed length of 3 bits. The following delta values get a variable-length code from the table val_tab_index = 2 [[#Huffman tables for delta coding|here]] so the final number of bits to be transmitted will be = 32.
Compared to the unpacked version (13 x 3 bits = 39 bits) the coding method described above will yield a bit-reduction of 7 bits (18% smaller).

====== Method B: huffman-coded modulo difference to master ======

In a stereo mix the signal of the left channel is often very similar to the signal of the right channel (i.e. there is a high cross-correlation between the channels). In this case the estimated sound parameters like word-length or scale factor will have a high similarity as well. Then coding the differential signal between the channels can lead to a significant bit reduction.
Surely at least the one of the channels must be coded independently. Such a channel will be called "master" (it's usually the left channel but ATRAC3plus has the possibility to make the right channel act like a master as well). For the 2nd channel only the difference to master will be coded. The 2nd channel will be called "slave" in this case.

Below an example of such a high-correlated signal:

Left : 6, 5, 6, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1
Right: 6, 5, 6, 2, 2, 2, 3, 1, 1, 1, 2, 1, 1
Diff : 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0

Coding the difference signal using the table val_tab_index = 0 [[#Huffman tables for delta coding|here]] will result in another signal 15 bits long. Compared to the unpacked version (13 x 3 bits = 39 bits) that coding method will yield a bit-reduction of 24 bits (62% smaller).

====== Method C: shorter delta to min ======

Sometimes coefficients in a signal are very close to each other, so subtracting the minimum value from each coefficient will result in smaller deltas whose can be coded using fewer bits.

An example:

2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1

As one can see the values in the sequence above are very similar to each other. Let us find minimum and maximum values and then determine the number of delta bits:

min = 1; max = 2; num_delta_bits = ilog2(max - min + 1) = 1 bit

Now let us encode the sequence above using shorter deltas:

num_delta_bits = 1 will be coded as a 2-bit value
min = 1 will be coded as a 3-bit value
deltas: 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0

The encoded signal is 5 + 1 x 15 = 20 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 25 bits (55% smaller).

Another example:

1, 2, 3, 2, 4, 2, 1, 2, 3, 3, 1, 4, 4, 1, 1

min = 1; max = 4; num_delta_bits = ilog2(max - min + 1) = 2 bits

Now the encoded signal:

num_delta_bits = 2 (will be coded as a 2-bit value)
min = 1 (will be coded as a 3-bit value)
deltas: 0, 1, 2, 1, 3, 1, 0, 1, 2, 2, 0, 3, 3, 0, 0

The encoded signal is 5 + 2 x 15 = 35 bits long while the unpacked one is 15 x 3 = 45 bits long. The bit-reduction is thereafter 10 bits (22% smaller).

====== Method D: sequence of numbers in ascending order ======

Sometimes ATRAC3plus have to deal with sequences of numbers (i.e. gain control position information) where all items are known to be in ascending order (i.e. satisfy the following equation: ''Vn+1 > Vn''). Such sequences can be packed without any additional bitstream information by examining previous value (predecessor), calculating magnitude between it and the maximum value and making the decision about number of bits of the next delta value.

Consider the following sequence:

Position index: 0, 1, 2, 3, 4, 5, 6, 7
---------------------------------------------
Position info : 5, 7, 14, 15, 18, 25, 29, 30
---------------------------------------------
Num delta bits: 5, 5, 5, 4, 4, 3, 1, 0

1st coefficient (position index = 0) will be coded directly using 5 bits because the sequence should start somewhere.
The following coefficients (except one with the value of "30") will be coded according to the following pseudocode:

num_delta_bits = ilog2(31 - prev_val);
if (num_delta_bits == 5)
new_val = get_bits(5);
else
new_val = prev_val + get_bits(num_delta_bits) + 1;

Let us return to our sequence. The 2nd value will be coded directly as well using 5 bits because ilog2(31 - 5) = 5. Similar for the 3rd one. No delta coding is applied in that case. The 4th value will be delta-coded using 4 bits:

num_delta_bits = ilog(31 - 15) = 4 bits;
delta = 18 - 15 - 1 = 2

And so on until we reach the last value = 30. In this case there is only one value that meets our condition ''Vn+1 > Vn'': the value of "31". In this case no delta will be transmitted and the coming value will be calculated just as:

new_val = prev_val + 1;

Therefore the resulting sequence will be 27 bits long. Compared to the unpacked version (8 x 5 bits = 40 bits) this packing method will yield a bit-reduction of 13 bits (32% smaller).

===== Vector quantization with residual encoding =====

One further packing technique used in ATRAC3plus is based on so-called "shape prediction vectors". Encoder decomposes a signal (word-length or scale factor info) into "shape prediction" + residual. Then only the index of the "shape prediction vector" and the huffman-coded residual will be transmitted. The main advantage of this method is when the shape matches the coded signal closely, the residual can be represented very compactly (usually 1-2 bits per value). Moreover, the majority of values of the residual will turn into zeroes, which can be further packed.

Each entry of the "shape prediction tables" contain an average value over 3 coefficients. This helps to keep those tables comparable small. For example, for a signal of 32 values each "shape table" will have 10 entries (last entry contains usually an average value over 5 coefficients).

Consider the following signal to be encoded:

7, 7, 6, 5, 4, 4, 3, 2, 2, 2, 1, 1

Let us "quantize" that signal by diving it into 4 * 3 groups and find the averaged value in each group:

floor((7 + 7 + 6) / 3 + 0.5) = 7,
floor((5 + 4 + 4) / 3 + 0.5) = 4,
floor((3 + 2 + 2) / 3 + 0.5) = 2,
floor((2 + 1 + 1) / 3 + 0.5) = 1

Find a "shape table" in the trained set that closely matches our "quantized" version. It will be (for example):
7, 5, 2, 1

Now compute the residual:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|-
! bgcolor="#f0f0f0" | Original signal
| style="text-align:center;"| 7
| style="text-align:center;"| 7
| style="text-align:center;"| 6
| style="text-align:center;"| 5
| style="text-align:center;"| 4
| style="text-align:center;"| 4
| 3 || 2 || 2 || 2 || 1 || 1
|-
! bgcolor="#f0f0f0" | Unpacked shape table
| 7 || 7 || 7 || 5 || 5 || 5 || 2 || 2 || 2 || 1 || 1 || 1
|-
! bgcolor="#f0f0f0" | Residual
| 0 || 0 || -1 || 0 || -1 || -1 || 1 || 0 || 0 || 1 || 0 || 0
|}

Now select a huffman table that represents the residual above as small as possible. The following huffman tree assigns the shortest code (1 bit) to the most frequently occuring symbol = "0" and 2-bit codes to the others: "1" and "-1":

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | -1
|}

The packed signal will occupy 21 bits: 4 bits "shape table" index + 17 bits residual(7 bits for "zeroes" + 10 bits for "non-zeroes"). Compared to the unpacked version (12 x 3 bits = 36 bits) this packing method will yield a bit-reduction of 15 bits (42% smaller).

===== Value grouping with "group coded" flag =====

If a signal contains lots of zeroes, grouping several values together and assigning the "group coded" flag to each group will achieve a significant bit-reduction. Consider the following sequence of numbers to be encoded:

0, 0, 1, 2, 0, 0, 3, 3, 0, 0, 0, 7, 0, 6, 0, 0

Let us cluster each two values together and assign the "coded" flag (1 bit) to each group:

(0, 0); flag = 0 (group not coded)
(1, 2); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(3, 3); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)
(0, 7); flag = 1 (group coded)
(0, 6); flag = 1 (group coded)
(0, 0); flag = 0 (group not coded)

Thereafter, each "not coded" group requires only one bit to be transmitted indicating that all values in that group are zero. On the other hand, each "coded" group requires one extra bit to be transmitted indicating that at least one value in that group is non-zero. In the case above that overhead is worthwhile because the half of the signal contains zeroes.

The encoded signal is 4 x 1 + 4 x 7 = 32 bits long while the unpacked one is 16 x 3 = 48 bits long. The bit-reduction is thereafter 16 bits (33% smaller).

== Multichannel ATRAC3plus (ATRAC-X) ==

ATRAC3plus supports multichannel streams (up to 8 channels). Such streams are encoded in units customary called "channel block"; each block contains max. 2 channels (ie can be MONO or STEREO). For example, taking the channel_id = 3 and looking at the table below we have a stream containing 2 channel blocks: 1 stereo + 1 mono and thus 3 channels.
The base codec operates on either MONO or STEREO channel blocks only.

=== ATRAC-X channel configurations ===

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! channel_id !! total channels !! number of channel blocks !! speaker mapping
|-
| align="center" | 0 || align="center" | 0 || align="center" | undefined ||
* undefined
|-
| align="center" | 1 || align="center" | 1 || align="center" | 1 ||
* front: center (MONO)
|-
| align="center" | 2 || align="center" | 2 || align="center" | 1 ||
* front: L, R (STEREO)
|-
| align="center" | 3 || align="center" | 3 || align="center" | 2 ||
* front: L, R
* front: center
|-
| align="center" | 4 || align="center" | 4 || align="center" | 3 ||
* front: L, R
* front: center
* rear: surround
|-
| align="center" | 5 || align="center" | 5+1 || align="center" | 4 ||
* front: L, R
* front: center
* rear: L, R
* LFE
|-
| align="center" | 6 || align="center" | 6+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* rear: center
* LFE
|-
| align="center" | 7 || align="center" | 7+1 || align="center" | 5 ||
* front: L, R
* front: center
* rear: L, R
* side: L, R
* LFE
|}

== Bitstream overview ==

The table below shows the bitstream organization of ATRAC3plus at the top-level. Depends on [[#ATRAC-X channel configurations|channel configuration]] a typical frame may contain more than one channel block. In this case the additional fields [[#channel_block_type|channel_block_type]] and [[#channel_block_data|channel_block_data]] will be included for each block.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! number of bits !! value !! description
|-
| align="center" | start_marker || align="center" | 1 || align="center" | 0 ||
marks the start of the ATRAC3plus bitstream
|-
| align="center" | channel_block_type || align="center" | 2 ||
* 00b - MONO block
* 01b - STEREO block
* 10b - EXTENSION block
| align="center" | type of the channel block
|-
| align="center" | channel_block_data || align="center" | variable || || align="center" | contains encoded sound information
|-
| align="center" | terminator || align="center" | 2 || align="center" | 11b || align="center" | indicates the end of the bitstream
|}

=== Channel block types ===

There are following channel block types in ATRAC3plus:

* '''Mono channel block''': contains monaural sound data.
* '''Stereo channel block''': contains stereophonic sound data.
* '''Extension block''': as indicated by its name it's intended to carry some extension information. Its purpose is unknown though due to the lack of an official description. All existing decoder implementations are programmed to ignore blocks of that type.

=== Channel block layout ===

ATRAC3plus was designed to provide a high-quality sound compression. Therefore it tries to save as much bits as possible. It uses a new coding scheme for channel blocks compared to ATRAC3: channels in a stereo sound are no more coded separately but rather in one stereo channel block. The bitstream for such a block provides the possibility for both channels to share several sound parameters so that there is no need to transmit the same things twice. Depends on correlation between the channels this can lead to a significant bit reduction and thus improve coding quality.

A mono/stereo channel block contains the following pieces of sound information:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! name !! size in bits !! description
|-
| align="center" | [[#Sound header|sound_header]] || align="center" | 6 || width="700" | defines some global sound parameters
|-
| align="center" | [[#Word-length information|wordlength_info]] || align="center" | variable || quantization word length information for each quant unit
|-
| align="center" | scalefactor_info || align="center" | variable || quantization scale factor indexes for each coded quant unit
|-
| align="center" | codetable_info || align="center" | variable || code table table information for each coded quant unit
|-
| align="center" | spectra || align="center" | variable || huffman-coded spectral information for each coded quant unit
|-
| align="center" | window_info || align="center" | variable || tells which IMDCT window shape should be used during the sound reconstruction
|-
| align="center" | gain_info || align="center" | variable || gain envelope used by the gain compensation
|-
| align="center" | gha_info || align="center" | variable || information about sine-like waves in the compressed sound obtained by the GHA. It contains quantized frequency, amplitude and phase for each wave to be synthesized in the decoder.
|-
| align="center" | noise_info || align="center" | 1/9 || contains noise flag, level index and table selector for the white noise to be added during decoding.
|}

==== Sound header ====

At the start of each channel block the sound header is located. It contains the following fields:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! value(s) !! comments
|-
| align="center" | 5 || num_quant_units || valid values: 0...27,31 || width="500" | number of coded quantization units - 1. The value of "0" indicates one coded unit, the value of "31" - 32 ones. The values 28, 29 and 30 are invalid.
|-
| align="center" | 1 || align="center" | x_flag || || to be figured out
|}

==== Word-length information ====

===== Coding summary =====

Word-length (or quantization precision) information follows the sound header. It defines the word-length parameter for each [[#num_quant_units|coded quantization unit]]. This parameter is in the range 0...7, where the value of "7" indicates the highest quantization precision and the value of "1" - the lowest one. The value of "0" means no data, i.e. the corresponding quantization unit was not coded.

In the case of the stereo channel block the word-length parameters for the channel 1(L) will be transmitted first followed by the the word-length parameters for the channel 2(R). The word-lengths for the channel 1 are always coded independently. The word-lengths for the channel 2 can be coded either independently or relative to the channel 1. In this case the 1st channel is called "master" and the 2nd one - "slave".
The word-lengths for the mono block will be coded just like the channel 1 in the stereo block.

In order to keep the word-length data as small as possible ATRAC3plus uses several coefficient packing techniques achieving different amount of bits needed for transmission:

* the coefficients are coded directly (3 bits value). This means no packing and used at high bitrates because the frame size is big enough to keep the infomation unpacked.

* differential coding + huffman-coded delta: the first coefficient is coded directly; all others are huffman-coded deltas to the previous coefficient.

* prediction + huffman-coded residual: this techniques offers the best packing and used at low bitrates. It's analogous to the lossless coding and based on trained shape tables serving as prediction. Later the huffman-coded residual will be added to the prediction prefectly reconstructing the coefficients.

===== Reconstruction of trimmed word-length coefficients =====

Word-length coefficient of the trailing quantization units corresponding to the high spectral bands tend to be either 1 (low-precision) or 0 (not coded). Such coefficients will be ommited and one the following modes will be used in order to reconstruct their values during decoding:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! mode code(2 bits) !! num_coded_vals !! split_point_delta !! Action(master) !! Action(slave)
|-
| align="center" | 0 || align="center" | not present
|rowspan="3" style="text-align:center;" | not present
|colspan="2" style="text-align:center;" | no trimmed coefficients
|-
| align="center" | 1
|rowspan="3" style="text-align:center;" | 5 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients to "0"
|-
| align="center" | 2 || width="220" | set all trimmed coefficients to "1" || width="220" | for each trimmed coefficient read one bit of its direct value
|-
| align="center" | 3 || align="center" | 2 bits
|colspan="2" style="text-align:center;"| set all trimmed coefficients up to split point to "1" and after split point - to "0". The split point is calculated differently for master and slave channels (see below)
|}

To calculate the split point from [[#split_point_delta|split_point_delta]] do the following:

* for the master channel: number of zeroes = split_point_delta + 1
* for the slave channel: number of ones = split_point_delta + 3

The following C-pseudocode shows how to parse a bitstream according with the table above:

mode = get_bits(2);
if (mode) {
num_coded_vals = get_bits(5);
if (mode == 3)
split_point_delta = get_bits(2);
} else {
num_coded_vals = [[#num_quant_units|num_quant_units]];
}

The following C-pseudocode shows how to reconstruct trimmed word-length coefficients according with the table above:

switch (mode) {
case 0: /* no further action */
break;
case 1:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
break;
case 2:
for (pos = num_coded_vals; pos < [[#num_quant_units|num_quant_units]]; pos++) {
if (channel == master)
wl_coeffs[pos] = 1;
else
wl_coeffs[pos] = get_bits(1);
}
break;
case 3:
if (channel == master)
split_point = [[#num_quant_units|num_quant_units]] - split_point_delta - 1;
else
split_point = num_coded_vals + split_point_delta + 3;

for (pos = num_coded_vals; pos < split_point; pos++)
wl_coeffs[pos] = 1;

for (; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = 0;
}

===== Word-length coding in detail =====

The word-length information for each channel will be coded as follows:

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! size in bits !! name !! comments
|-
| align="center" | 2 || coding_mode || width="500" | indicates the coding mode used.
|-
| align="center" | variable || align="center" | coeff_info || word-length coefficients coded according with the [[#coding_mode|coding_mode]].
|}

The [[#coding_mode|coding_mode]] parameter may be interpreted differently depends on the channel number. The following pseudocode examples explain the coding modes in detail:

===== Mode 0 (master and slave) =====

All coefficients will be directly coded as follows:

for (i = 0; i < [[#num_quant_units|num_quant_units]]; i++)
wl_coeffs[i] = get_bits(3);

===== Mode 1 (master) =====

Leading "n" values are stored directly while trailing ones are packed using [[#Method C: shorter delta to min|Method C: shorter delta to min]] method.

Data stored in the bitstream:

* 2 bits: index of the table of weigths, "0" - indicates "no table used"
* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 5 bits: number of directly coded coefficients ('''num_direct_coeffs'''). This value must be < [[#num_coded_vals|num_coded_vals]]
* 2 bits: size of deltas in bits ('''delta_bits''')
* 3 bits: minimum value ('''min_value''')
* for each '''num_direct_coeffs'''
** 3 bits: coefficient value
* if '''delta_bits''' > 0: for each ([[#num_coded_vals|num_coded_vals]] - '''num_direct_coeffs''')
** '''delta_bits''': delta value to be added to the '''min_value'''

The following C-pseudocode summarizes all above:

weigths_tab_indx = get_bits(2); /* get index of weights table to be added after decoding */

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

num_direct_coeffs = get_bits(5);
if (num_direct_coeffs > [[#num_coded_vals|num_coded_vals]])
ABORT("Invalid number of directly coded coefficients");

delta_bits = get_bits(2);
min_value = get_bits(3);

for (pos = 0; pos < num_direct_coeffs; pos++)
wl_coeffs[pos] = get_bits(3);

for (; pos < num_coded_vals; pos++) {
if (delta_bits)
wl_coeffs[pos] = min_value + get_bits(delta_bits);
else
wl_coeffs[pos] = min_value;
}

/* reconstruct trimmed coefficients as described [[#Reconstruction of trimmed word-length coefficients|here]] */

/* add weighting coefficients if requested */
if (weigths_tab_indx) {
for (pos = 0; pos < [[#num_quant_units|num_quant_units]]; pos++)
wl_coeffs[pos] = [[#Tables of weights|wl_weights]][channel_num][weights_tab_indx - 1][pos];
}

===== Mode 1 (slave) =====

Coding method: [[#Method B: huffman-coded modulo difference to master|Huffman-coded modulo difference to master]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]]
* 2 bits: indicates which huffman table from [[#Huffman tables for delta coding|this set]] should be used for decoding
* for each [[#num_coded_vals|num_coded_vals]]
** huffman-coded delta value to be added to the corresponding value of the master channel

/* parse mode/num_coded_vals/split_point_delta parameters for [[#Reconstruction of trimmed word-length coefficients|trimmed coefficients]] */

vlc_sel = get_bits(2); /* selects a huffman table from [[#Huffman tables for delta coding|this set]] */

for (i = 0; i < [[#num_coded_vals|num_coded_vals]]; i++) {
delta = get_vlc(vlc_sel);
wl_coeffs[i] = (master_ch->wl_coeffs[i] + delta) & 7;
}

===== Mode 2 (master) =====

Coding method: [[#Vector quantization with residual encoding|Vector quantization with residual encoding]] and [[#Value grouping with "group coded" flag|Value grouping with "group coded" flag]].

Data stored in the bitstream:

* 2/7/9 or more bits (depending on mode): info for the [[#Reconstruction of trimmed word-length coefficients|reconstruction of trimmed coefficients]].
* 1 bit: '''enable_grouping''' flag. "1" indicates that residual values were coded pairwise (in groups of two).
* 1 bit: selects one of the first two huffman tables from [[#Huffman tables for delta coding|this set]].
* 3 bits: '''start_value''' selecting a subset of "shape tables" from the trained set.
* 4 bits: '''shape_index''' selecting a "shape table" within the subset indicated by '''start_value'''.
* for each [[#num_coded_vals|num_coded_vals]]
** if '''enable_grouping''' == 1:
*** 1 bit: '''group_coded''' flag
*** if '''group_coded''' == 1:
**** 2 huffman-coded residual values to be added to the unpacked "shape table" using modular arithmetic
** if '''enable_grouping''' == 0:
*** one huffman-coded residual value to be added to the unpacked "shape table" using modular arithmetic

== Annex A: Decoding tables ==

=== Word-length related tables ===

==== Tables of weights ====

The weights below will be added to the decoded word-length coefficients. The tables are organized as follows:
* [channel_number: 0 or 1][index: 0...2][coeff_indx: 0...31]

wl_weights[2][3][32] = {
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
},
{
{5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{5, 5, 5, 4, 4, 4, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
{6, 5, 5, 5, 5, 5, 5, 5, 3, 3, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
};

==== Huffman tables for delta coding ====

PLEASE NOTE: delta values indicated in the tables below will be added using modular arithmetic as described [[#Delta coding based on modular arithmetic|here]], so in the case of "wrap around" the value of "7" will be treated as "-1", the value of "6" = "-2" and so on.

* '''vlc_tab_index = 0''', delta range -1...1

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 10 || align="center" | 2 || align="center" | 1
|-
| align="center" | 11 || align="center" | 2 || align="center" | 7
|}

* '''vlc_tab_index = 1''', delta range -2...2

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 2
|-
| align="center" | 110 || align="center" | 3 || align="center" | 6
|-
| align="center" | 111 || align="center" | 3 || align="center" | 7
|}

* '''vlc_tab_index = 2''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 5
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 3
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 4
|}

* '''vlc_tab_index = 3''', delta range 0...7 (-4...3)

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Huffman code !! Number of bits !! Delta value
|-
| align="center" | 0 || align="center" | 1 || align="center" | 0
|-
| align="center" | 100 || align="center" | 3 || align="center" | 1
|-
| align="center" | 101 || align="center" | 3 || align="center" | 7
|-
| align="center" | 1100 || align="center" | 4 || align="center" | 2
|-
| align="center" | 1101 || align="center" | 4 || align="center" | 3
|-
| align="center" | 1110 || align="center" | 4 || align="center" | 6
|-
| align="center" | 11110 || align="center" | 5 || align="center" | 4
|-
| align="center" | 11111 || align="center" | 5 || align="center" | 5
|}

[[Category:Audio Codecs]]
[[Category: Multichannel Audio Codecs]]
[[Category: QMF Audio Codecs]]
[[Category: MDCT Audio Codecs]]