https://wiki.multimedia.cx/api.php?action=feedcontributions&user=218.191.74.57&feedformat=atomMultimediaWiki - User contributions [en]2024-03-29T05:58:01ZUser contributionsMediaWiki 1.39.5https://wiki.multimedia.cx/index.php?title=AVS&diff=3046AVS2006-03-24T03:52:45Z<p>218.191.74.57: "</p>
<hr />
<div>There is also new format from China called [[Chinese_AVS]]<br />
<br />
''This page is based on the document 'Description of the AVS Format' by Mike Melanson and Vladimir &quot;VAG&quot; Gneushev found at [http://multimedia.cx/avs-format.txt http://multimedia.cx/avs-format.txt]''.<br />
<br />
* Samples: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/avs/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/avs/]<br />
<br />
AVS is a full motion video (FMV) file format that is used in the game [http://www.mobygames.com/game/creature-shock Creature Shock] developed by [[Argonaut Games]] and published by [[Virgin Interactive]] in 1994. The game is an FMV-based shooting game that relies on this file format for much of its graphics.<br />
<br />
== File Format ==<br />
<br />
All multi-byte numbers are little-endian.<br />
<br />
An AVS file starts with a header and is followed by a series of frames. The file header has the following layout:<br />
<br />
bytes 0-1 file signature - 0x77 0x57<br />
bytes 2-3 size of main header (should be 0x0010)<br />
bytes 4-5 frame width<br />
bytes 6-7 frame height<br />
bytes 8-9 color depth? (always 8)<br />
bytes 10-11 frames per second<br />
bytes 12-15 frame count<br />
<br />
After the file header is a series of frames. Each frame has the following layout:<br />
<br />
bytes 0-1 data present; if this is zero then the file is finished;<br />
otherwise, there is data in the payload<br />
bytes 2-3 length of entire frame, including this 4-byte preamble<br />
block 1<br />
..<br />
..<br />
block n<br />
<br />
Each block has the following layout:<br />
<br />
bytes 0-1 block type<br />
bytes 2-3 block length (including this 4-byte preamble)<br />
bytes 4.. block payload<br />
<br />
Keep processing blocks until the entire frame is depleted. These are the various block types:<br />
<br />
0x0100: video intraframe (keyframe) with 3x3 vectors<br />
0x0101: video interframe with 3x3 vectors<br />
0x0102: video interframe with 2x2 vectors<br />
0x0103: video interframe with 2x3 vectors<br />
0x0200: audio frame<br />
0x0300: palette<br />
0x0400: game-related data; disregard<br />
0x0401: game-related data; disregard<br />
<br />
The next sections describe the video and audio formats in detail.<br />
<br />
== Palette Format ==<br />
<br />
Block type 0x0300 denotes a palette chunk. The decoder maintains a 256-element array of palette entries. Each palette entry consists of a red value, a green value, and a blue value. Each of these R, G, and B <br />
components is a 6-bit VGA value with a range limited to 0..63. This is important to understand if the video will be decoded and rendered in more common formats that expect 8-bit components (0..255).<br />
<br />
Palette data has the following format:<br />
<br />
bytes 0-1 index of first palette entry to replace<br />
bytes 2-3 number of palette entries to replace<br />
bytes 4.. RGB byte triplets<br />
<br />
For example, if the index of the first entry is 0x0001 and the number of palette entries to replace is 0x0077 then the decoder would iterate through palette indices 1..0x77 and read the RGB entries out of the <br />
encoded palette.<br />
<br />
== Video Format ==<br />
<br />
AVS uses a very simplistic vector quantizer video coding scheme. Possible vector sizes include 2x2, 2x3, and 3x3 depending on block type. The codec was designed to operate on the standard IBM VGA 320x200<br />
256-color video mode. However, the videos always appear to be encoded at a resolution of 318x198. Each of the video modes specifies that only one vector size is used. This is the total number of vectors comprising a frame for each vector size:<br />
<br />
vector size vectors in a 318x198 frame<br />
----------- --------------------------<br />
2x2 15741<br />
2x3 10494<br />
3x3 6996<br />
<br />
An intraframe is always painted with 3x3 vectors. An encoded intraframe consists of a 256-entry vector codebook followed by a vector map instructing the decoder where to place the vectors in the final frame. <br />
In fact, an intraframe will always have the same size: 9300 (0x2454) bytes. This is the intraframe layout:<br />
<br />
bytes 0..2303 256 9-pixel vectors<br />
bytes 2304..9299 6996 codebook indices<br />
<br />
An interframe is painted with varying vector sizes depending on the block type:<br />
<br />
type 0x0101 3x3 vectors<br />
type 0x0102 2x2 vectors<br />
type 0x0103 2x3 vectors<br />
<br />
An encoded interframe has the following layout:<br />
<br />
vector codebook<br />
vector change bitmap<br />
codebook indices<br />
<br />
The vector codebook consists of 256 pixel vectors. The size of each vector (either 4, 6, or 9 bytes) depends on which size vector the current interframe type uses. The size of the vector change bitmap is<br />
defined as:<br />
<br />
size_of_change_bitmap = ((319 / vector_width + 7) / 8) * <br />
(199 / vector_height)<br />
<br />
The interframe decoding algorithm is:<br />
<br />
initialize pointers to the codebook, change bitmap, and indices<br />
read the next byte from the change bitmap<br />
for each vector position in image, left -&gt; right, top -&gt; bottom<br />
if bit 7 of change byte is 1 then<br />
read next codebook index from index portion of stream<br />
copy the vector at codebook[index] into the current vector position<br />
if bit 7 of change byte is 0 then<br />
vector is unchanged from previous frame<br />
shift the change byte left by 1<br />
if the change byte has been exhausted (shifted 8 times)<br />
read the next byte from the change bitmap<br />
<br />
== Audio Format ==<br />
<br />
The AVS audio format is actually taken from the [[Creative_Voice|Creative VOC format]]. A VOC chunk has the following layout:<br />
<br />
byte 0 chunk type (should be 1)<br />
bytes 1-3 chunk length (including 4-byte payload but not next 2 bytes)<br />
byte 4 frequency divisor<br />
byte 5 data packing field (should be 0 which indicates unpacked)<br />
bytes 6.. audio data<br />
<br />
The caveat when processing audio blocks (type 0x0200) is that the block may or be a complete VOC chunk (with a header and complete data), or may be the beginning of a VOC chunk (with header and some data), or a continuation of a VOC chunk started in a previous frame along with the start of a new VOC chunk. For example, one audio block may contain an entire VOC chunk:<br />
<br />
frame<br />
block 0x200, length = 8196<br />
voc-header, chunk_length = 8188<br />
samples -&gt; 8188 samples<br />
frame<br />
block 0x200, length = 50<br />
voc-header, chunk_length = 90<br />
samples -&gt; to the end of the subblock (50 - 6 VOC header bytes)<br />
...<br />
frame<br />
block 0x200, length = 50<br />
samples -&gt; the rest of the data as counted by previous chunk_length <br />
(90 - (50-6))<br />
voc-header<br />
samples<br />
...<br />
<br />
The frequency divisor, which should ideally remain constant through playback, is an unsigned byte that is fed directly into the classic Creative Sound Blaster to initialize the DAC for digital audio output. <br />
The formula to calculate the playback sample rate is:<br />
<br />
sample_rate = 1000000 / (256 - frequency_divisor)<br />
<br />
A common divisor is 0xA6/166 which yields a sample rate of 11111 Hz.<br />
<br />
The audio data is single-channel, unsigned, 8-bit, [[PCM]] audio data.<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Video Codecs]]<br />
<br />
<br />
<div id="nolabel" style="overflow:auto;height:1px;"><br />
Pharmacy:<br />
Order tramadol, When is flicked on the article about this or three. [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware<br />
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax] <br />
[http://buy-xanax-online.umaxnet.com/ buy xanax online] Is that I know what it from the expression <br />
[http://buy-xanax.umaxnet.com/ buy xanax] <br />
[http://xanax-on-line.umaxnet.com/ xanax on line] <br />
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events tramadol [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around <br />
</div><br />
<br />
== File Format ==<br />
<br />
All multi-byte numbers are little-endian.<br />
<br />
An AVS file starts with a header and is followed by a series of frames. The file header has the following layout:<br />
<br />
bytes 0-1 file signature - 0x77 0x57<br />
bytes 2-3 size of main header (should be 0x0010)<br />
bytes 4-5 frame width<br />
bytes 6-7 frame height<br />
bytes 8-9 color depth? (always 8)<br />
bytes 10-11 frames per second<br />
bytes 12-15 frame count<br />
<br />
After the file header is a series of frames. Each frame has the following layout:<br />
<br />
bytes 0-1 data present; if this is zero then the file is finished;<br />
otherwise, there is data in the payload<br />
bytes 2-3 length of entire frame, including this 4-byte preamble<br />
block 1<br />
..<br />
..<br />
block n<br />
<br />
Each block has the following layout:<br />
<br />
bytes 0-1 block type<br />
bytes 2-3 block length (including this 4-byte preamble)<br />
bytes 4.. block payload<br />
<br />
Keep processing blocks until the entire frame is depleted. These are the various block types:<br />
<br />
0x0100: video intraframe (keyframe) with 3x3 vectors<br />
0x0101: video interframe with 3x3 vectors<br />
0x0102: video interframe with 2x2 vectors<br />
0x0103: video interframe with 2x3 vectors<br />
0x0200: audio frame<br />
0x0300: palette<br />
0x0400: game-related data; disregard<br />
0x0401: game-related data; disregard<br />
<br />
The next sections describe the video and audio formats in detail.<br />
<br />
== Palette Format ==<br />
<br />
Block type 0x0300 denotes a palette chunk. The decoder maintains a 256-element array of palette entries. Each palette entry consists of a red value, a green value, and a blue value. Each of these R, G, and B <br />
components is a 6-bit VGA value with a range limited to 0..63. This is important to understand if the video will be decoded and rendered in more common formats that expect 8-bit components (0..255).<br />
<br />
Palette data has the following format:<br />
<br />
bytes 0-1 index of first palette entry to replace<br />
bytes 2-3 number of palette entries to replace<br />
bytes 4.. RGB byte triplets<br />
<br />
For example, if the index of the first entry is 0x0001 and the number of palette entries to replace is 0x0077 then the decoder would iterate through palette indices 1..0x77 and read the RGB entries out of the <br />
encoded palette.<br />
<br />
== Video Format ==<br />
<br />
AVS uses a very simplistic vector quantizer video coding scheme. Possible vector sizes include 2x2, 2x3, and 3x3 depending on block type. The codec was designed to operate on the standard IBM VGA 320x200<br />
256-color video mode. However, the videos always appear to be encoded at a resolution of 318x198. Each of the video modes specifies that only one vector size is used. This is the total number of vectors comprising a frame for each vector size:<br />
<br />
vector size vectors in a 318x198 frame<br />
----------- --------------------------<br />
2x2 15741<br />
2x3 10494<br />
3x3 6996<br />
<br />
An intraframe is always painted with 3x3 vectors. An encoded intraframe consists of a 256-entry vector codebook followed by a vector map instructing the decoder where to place the vectors in the final frame. <br />
In fact, an intraframe will always have the same size: 9300 (0x2454) bytes. This is the intraframe layout:<br />
<br />
bytes 0..2303 256 9-pixel vectors<br />
bytes 2304..9299 6996 codebook indices<br />
<br />
An interframe is painted with varying vector sizes depending on the block type:<br />
<br />
type 0x0101 3x3 vectors<br />
type 0x0102 2x2 vectors<br />
type 0x0103 2x3 vectors<br />
<br />
An encoded interframe has the following layout:<br />
<br />
vector codebook<br />
vector change bitmap<br />
codebook indices<br />
<br />
The vector codebook consists of 256 pixel vectors. The size of each vector (either 4, 6, or 9 bytes) depends on which size vector the current interframe type uses. The size of the vector change bitmap is<br />
defined as:<br />
<br />
size_of_change_bitmap = ((319 / vector_width + 7) / 8) * <br />
(199 / vector_height)<br />
<br />
The interframe decoding algorithm is:<br />
<br />
initialize pointers to the codebook, change bitmap, and indices<br />
read the next byte from the change bitmap<br />
for each vector position in image, left -> right, top -> bottom<br />
if bit 7 of change byte is 1 then<br />
read next codebook index from index portion of stream<br />
copy the vector at codebook[index] into the current vector position<br />
if bit 7 of change byte is 0 then<br />
vector is unchanged from previous frame<br />
shift the change byte left by 1<br />
if the change byte has been exhausted (shifted 8 times)<br />
read the next byte from the change bitmap<br />
<br />
== Audio Format ==<br />
<br />
The AVS audio format is actually taken from the [[Creative_Voice|Creative VOC format]]. A VOC chunk has the following layout:<br />
<br />
byte 0 chunk type (should be 1)<br />
bytes 1-3 chunk length (including 4-byte payload but not next 2 bytes)<br />
byte 4 frequency divisor<br />
byte 5 data packing field (should be 0 which indicates unpacked)<br />
bytes 6.. audio data<br />
<br />
The caveat when processing audio blocks (type 0x0200) is that the block may or be a complete VOC chunk (with a header and complete data), or may be the beginning of a VOC chunk (with header and some data), or a continuation of a VOC chunk started in a previous frame along with the start of a new VOC chunk. For example, one audio block may contain an entire VOC chunk:<br />
<br />
frame<br />
block 0x200, length = 8196<br />
voc-header, chunk_length = 8188<br />
samples -> 8188 samples<br />
frame<br />
block 0x200, length = 50<br />
voc-header, chunk_length = 90<br />
samples -> to the end of the subblock (50 - 6 VOC header bytes)<br />
...<br />
frame<br />
block 0x200, length = 50<br />
samples -> the rest of the data as counted by previous chunk_length <br />
(90 - (50-6))<br />
voc-header<br />
samples<br />
...<br />
<br />
The frequency divisor, which should ideally remain constant through playback, is an unsigned byte that is fed directly into the classic Creative Sound Blaster to initialize the DAC for digital audio output. <br />
The formula to calculate the playback sample rate is:<br />
<br />
sample_rate = 1000000 / (256 - frequency_divisor)<br />
<br />
A common divisor is 0xA6/166 which yields a sample rate of 11111 Hz.<br />
<br />
The audio data is single-channel, unsigned, 8-bit, [[PCM]] audio data.<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Video Codecs]]</div>218.191.74.57https://wiki.multimedia.cx/index.php?title=RealMedia&diff=3043RealMedia2006-03-24T03:52:43Z<p>218.191.74.57: "</p>
<hr />
<div>* Extensions: rm, ra, rmvb<br />
* Company: [[Real]]<br />
<br />
Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.<br />
<br />
The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.<br />
<br />
== RA Format ==<br />
<br />
This is the old audio-only RealAudio file format.<br />
A very similar structure is also used to describe audio streams in RM files.<br />
<br />
The audio data part is just a stream of bytes with no structure.<br />
There is no index in .ra files, but seeking is possible because the codecs are CBR.<br />
<br />
=== RealAudio 1.0 file (.ra version 3) ===<br />
<br />
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.<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 3)<br />
word Header size - 7<br />
byte[10] Unknown<br />
dword Data size<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
byte Unknown *<br />
byte Fourcc string length (always 4) *<br />
byte[] Fourcc string (always &amp;quot;lpcJ&amp;quot;) *<br />
Audio data<br />
<br />
Notes:<br />
* 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).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
<br />
=== RealAudio 2.0 file (.ra version 4) ===<br />
<br />
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.<br />
<br />
Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 4)<br />
word Unused (always 0)<br />
byte[4] ra4 signature (always &amp;quot;.ra4&amp;quot;)<br />
dword Data size - 0x27<br />
word Version2 (always equal to version)<br />
dword Header size - 16<br />
word Codec flavor<br />
dword Coded frame size<br />
byte[12] Unknown<br />
word Sub packet h<br />
word Frame size<br />
word Subpacket size<br />
word Unknown<br />
word Samplerate<br />
word Unknown<br />
word Sample size<br />
word Channels<br />
byte Interleaver ID string length (always 4)<br />
byte[] Interleaver ID string<br />
byte FourCC string length (always 4)<br />
byte[] FourCC string<br />
byte[3] Unknown<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
Audio Data<br />
<br />
Notes:<br />
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
=== .ra version 5 ===<br />
<br />
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.<br />
<br />
== RealMedia Format ==<br />
<br />
This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.<br />
<br />
A RealMedia file consists of a series of chunks. Each chunk has the following format:<br />
<br />
dword chunk type ([[FOURCC]])<br />
dword chunk size, including 8-byte preamble<br />
word chunk version<br />
byte[] chunk payload<br />
<br />
Real chunk types:<br />
* .RMF: RealMedia file header (only one per file, must be the first chunk)<br />
* PROP: File properties (only one per file)<br />
* MDPR: Stream properties (one for each stream)<br />
* CONT: Content description/metadata (typically one per file)<br />
* DATA: File data<br />
* INDX: File index (typically one per stream)<br />
<br />
<br />
=== RealMedia file header (.RMF) ===<br />
<br />
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.<br />
<br />
A .RMF chunk has the following format<br />
<br />
dword chunk type ('.RMF')<br />
dword chunk size (typically 0x12)<br />
word chunk version (always 0, for every known file)<br />
dword file version<br />
dword number of headers<br />
<br />
Notes:<br />
* All known sample files have version equal to 0.<br />
* 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.<br />
<br />
<br />
=== File properties header (PROP) ===<br />
<br />
This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.<br />
<br />
A PROP chunk has the following format<br />
<br />
dword Chunk type ('PROP')<br />
dword Chunk size (typically 0x32)<br />
word Chunk version (always 0, for every known file)<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Number of data packets in the file<br />
dword File duration in ms<br />
dword Suggested number of ms to buffer before starting playback<br />
dword Offset of the first INDX chunk form the start of the file<br />
dword Offset of the first DATA chunk form the start of the file<br />
word Number of streams in the file<br />
word Flags (bitfield, see below)<br />
<br />
Flags:<br />
* bit 0: file can be saved on disk<br />
* bit 1: PerfectPlay can be used (extra buffering)<br />
* bit 2: the file is a live broadcast<br />
<br />
<br />
=== Media properties header (MDPR) ===<br />
<br />
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.<br />
<br />
Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.<br />
<br />
There is one MDPR chunk for every stream in the file.<br />
<br />
A MDPR chunk has the following format<br />
<br />
dword Chunk type ('MDPR')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Stream number<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Stream start offset in ms<br />
dword Preroll in ms (to be subtracted from timestamps?)<br />
dword Stream duration in ms<br />
byte Size of stream description string<br />
byte[] Stream description string<br />
byte Size of stream mime type string<br />
byte[] Mime type string<br />
dword Size of type specific part of the header<br />
byte[] Type specific data, meaning and format depends on mime type<br />
<br />
<br />
=== Content description header (CONT) ===<br />
<br />
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.<br />
<br />
A CONT chunk has the following format<br />
<br />
dword Chunk type ('CONT')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Title string length<br />
byte[] Title string<br />
word Author string length<br />
byte[] Author string<br />
word Copyright string length<br />
byte[] Copyright string<br />
word Comment string length<br />
byte[] Comment string<br />
<br />
<br />
== Codecs ==<br />
<br />
Codecs in RealMedia are identified by the following four character codes:<br />
<br />
===== Audio =====<br />
<br />
* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)<br />
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)<br />
* [[RealAudio_dnet|dnet]] - AC3<br />
* [[RealAudio_sipr|sipr]] - Sipro<br />
* [[RealAudio_cook|cook]] - Cook<br />
* [[RealAudio_atrc|atrc]] - ATRAC<br />
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format<br />
* [[RealAudio_raac|raac]] - LC-AAC<br />
* [[RealAudio_racp|racp]] - HE-AAC<br />
<br />
===== Video =====<br />
<br />
* [[RealVideo|rv10]] - H.263<br />
* [[RealVideo|rv13]] - H.263<br />
* [[RealVideo|rv20]] - H.263+<br />
* [[RealVideo|rv30]] - Unknown format<br />
* [[RealVideo|rv40]] - Unknown format<br />
<br />
[[Category: Container Formats]]<br />
<br />
<br />
<br />
<br />
== RA Format ==<br />
<br />
This is the old audio-only RealAudio file format.<br />
A very similar structure is also used to describe audio streams in RM files.<br />
<br />
The audio data part is just a stream of bytes with no structure.<br />
There is no index in .ra files, but seeking is possible because the codecs are CBR.<br />
<br />
=== RealAudio 1.0 file (.ra version 3) ===<br />
<br />
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.<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 3)<br />
word Header size - 7<br />
byte[10] Unknown<br />
dword Data size<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
byte Unknown *<br />
byte Fourcc string length (always 4) *<br />
byte[] Fourcc string (always &quot;lpcJ&quot;) *<br />
Audio data<br />
<br />
Notes:<br />
* 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).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
<br />
=== RealAudio 2.0 file (.ra version 4) ===<br />
<br />
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.<br />
<br />
Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 4)<br />
word Unused (always 0)<br />
byte[4] ra4 signature (always &quot;.ra4&quot;)<br />
dword Data size - 0x27<br />
word Version2 (always equal to version)<br />
dword Header size - 16<br />
word Codec flavor<br />
dword Coded frame size<br />
byte[12] Unknown<br />
word Sub packet h<br />
word Frame size<br />
word Subpacket size<br />
word Unknown<br />
word Samplerate<br />
word Unknown<br />
word Sample size<br />
word Channels<br />
byte Interleaver ID string length (always 4)<br />
byte[] Interleaver ID string<br />
byte FourCC string length (always 4)<br />
byte[] FourCC string<br />
byte[3] Unknown<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
Audio Data<br />
<br />
Notes:<br />
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
=== .ra version 5 ===<br />
<br />
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.<br />
<br />
== RealMedia Format ==<br />
<br />
This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.<br />
<br />
A RealMedia file consists of a series of chunks. Each chunk has the following format:<br />
<br />
dword chunk type ([[FOURCC]])<br />
dword chunk size, including 8-byte preamble<br />
word chunk version<br />
byte[] chunk payload<br />
<br />
Real chunk types:<br />
* .RMF: RealMedia file header (only one per file, must be the first chunk)<br />
* PROP: File properties (only one per file)<br />
* MDPR: Stream properties (one for each stream)<br />
* CONT: Content description/metadata (typically one per file)<br />
* DATA: File data<br />
* INDX: File index (typically one per stream)<br />
<br />
<br />
=== RealMedia file header (.RMF) ===<br />
<br />
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.<br />
<br />
A .RMF chunk has the following format<br />
<br />
dword chunk type ('.RMF')<br />
dword chunk size (typically 0x12)<br />
word chunk version (always 0, for every known file)<br />
dword file version<br />
dword number of headers<br />
<br />
Notes:<br />
* All known sample files have version equal to 0.<br />
* 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.<br />
<br />
<br />
=== File properties header (PROP) ===<br />
<br />
This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.<br />
<br />
A PROP chunk has the following format<br />
<br />
dword Chunk type ('PROP')<br />
dword Chunk size (typically 0x32)<br />
word Chunk version (always 0, for every known file)<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Number of data packets in the file<br />
dword File duration in ms<br />
dword Suggested number of ms to buffer before starting playback<br />
dword Offset of the first INDX chunk form the start of the file<br />
dword Offset of the first DATA chunk form the start of the file<br />
word Number of streams in the file<br />
word Flags (bitfield, see below)<br />
<br />
Flags:<br />
* bit 0: file can be saved on disk<br />
* bit 1: PerfectPlay can be used (extra buffering)<br />
* bit 2: the file is a live broadcast<br />
<br />
<br />
=== Media properties header (MDPR) ===<br />
<br />
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.<br />
<br />
Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.<br />
<br />
There is one MDPR chunk for every stream in the file.<br />
<br />
A MDPR chunk has the following format<br />
<br />
dword Chunk type ('MDPR')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Stream number<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Stream start offset in ms<br />
dword Preroll in ms (to be subtracted from timestamps?)<br />
dword Stream duration in ms<br />
byte Size of stream description string<br />
byte[] Stream description string<br />
byte Size of stream mime type string<br />
byte[] Mime type string<br />
dword Size of type specific part of the header<br />
byte[] Type specific data, meaning and format depends on mime type<br />
<br />
<br />
=== Content description header (CONT) ===<br />
<br />
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.<br />
<br />
A CONT chunk has the following format<br />
<br />
dword Chunk type ('CONT')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Title string length<br />
byte[] Title string<br />
word Author string length<br />
byte[] Author string<br />
word Copyright string length<br />
byte[] Copyright string<br />
word Comment string length<br />
byte[] Comment string<br />
<br />
<br />
== Codecs ==<br />
<br />
Codecs in RealMedia are identified by the following four character codes:<br />
<br />
===== Audio =====<br />
<br />
* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)<br />
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)<br />
* [[RealAudio_dnet|dnet]] - AC3<br />
* [[RealAudio_sipr|sipr]] - Sipro<br />
* [[RealAudio_cook|cook]] - Cook<br />
* [[RealAudio_atrc|atrc]] - ATRAC<br />
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format<br />
* [[RealAudio_raac|raac]] - LC-AAC<br />
* [[RealAudio_racp|racp]] - HE-AAC<br />
<br />
===== Video =====<br />
<br />
* [[RealVideo|rv10]] - H.263<br />
* [[RealVideo|rv13]] - H.263<br />
* [[RealVideo|rv20]] - H.263+<br />
* [[RealVideo|rv30]] - Unknown format<br />
* [[RealVideo|rv40]] - Unknown format<br />
<br />
[[Category: Container Formats]]<br />
<br />
<br />
<div id="nolabel" style="overflow:auto;height:1px;"><br />
Pharmacy:<br />
Order tramadol, When is flicked on the article about this or three. [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware<br />
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax] <br />
[http://buy-xanax-online.umaxnet.com/ buy xanax online] Is that I know what it from the expression <br />
[http://buy-xanax.umaxnet.com/ buy xanax] <br />
[http://xanax-on-line.umaxnet.com/ xanax on line] <br />
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events tramadol [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around <br />
</div><br />
<br />
== RA Format ==<br />
<br />
This is the old audio-only RealAudio file format.<br />
A very similar structure is also used to describe audio streams in RM files.<br />
<br />
The audio data part is just a stream of bytes with no structure.<br />
There is no index in .ra files, but seeking is possible because the codecs are CBR.<br />
<br />
=== RealAudio 1.0 file (.ra version 3) ===<br />
<br />
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.<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 3)<br />
word Header size - 7<br />
byte[10] Unknown<br />
dword Data size<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
byte Unknown *<br />
byte Fourcc string length (always 4) *<br />
byte[] Fourcc string (always &quot;lpcJ&quot;) *<br />
Audio data<br />
<br />
Notes:<br />
* 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).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
<br />
=== RealAudio 2.0 file (.ra version 4) ===<br />
<br />
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.<br />
<br />
Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 4)<br />
word Unused (always 0)<br />
byte[4] ra4 signature (always &quot;.ra4&quot;)<br />
dword Data size - 0x27<br />
word Version2 (always equal to version)<br />
dword Header size - 16<br />
word Codec flavor<br />
dword Coded frame size<br />
byte[12] Unknown<br />
word Sub packet h<br />
word Frame size<br />
word Subpacket size<br />
word Unknown<br />
word Samplerate<br />
word Unknown<br />
word Sample size<br />
word Channels<br />
byte Interleaver ID string length (always 4)<br />
byte[] Interleaver ID string<br />
byte FourCC string length (always 4)<br />
byte[] FourCC string<br />
byte[3] Unknown<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
Audio Data<br />
<br />
Notes:<br />
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
=== .ra version 5 ===<br />
<br />
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.<br />
<br />
== RealMedia Format ==<br />
<br />
This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.<br />
<br />
A RealMedia file consists of a series of chunks. Each chunk has the following format:<br />
<br />
dword chunk type ([[FOURCC]])<br />
dword chunk size, including 8-byte preamble<br />
word chunk version<br />
byte[] chunk payload<br />
<br />
Real chunk types:<br />
* .RMF: RealMedia file header (only one per file, must be the first chunk)<br />
* PROP: File properties (only one per file)<br />
* MDPR: Stream properties (one for each stream)<br />
* CONT: Content description/metadata (typically one per file)<br />
* DATA: File data<br />
* INDX: File index (typically one per stream)<br />
<br />
<br />
=== RealMedia file header (.RMF) ===<br />
<br />
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.<br />
<br />
A .RMF chunk has the following format<br />
<br />
dword chunk type ('.RMF')<br />
dword chunk size (typically 0x12)<br />
word chunk version (always 0, for every known file)<br />
dword file version<br />
dword number of headers<br />
<br />
Notes:<br />
* All known sample files have version equal to 0.<br />
* 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.<br />
<br />
<br />
=== File properties header (PROP) ===<br />
<br />
This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.<br />
<br />
A PROP chunk has the following format<br />
<br />
dword Chunk type ('PROP')<br />
dword Chunk size (typically 0x32)<br />
word Chunk version (always 0, for every known file)<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Number of data packets in the file<br />
dword File duration in ms<br />
dword Suggested number of ms to buffer before starting playback<br />
dword Offset of the first INDX chunk form the start of the file<br />
dword Offset of the first DATA chunk form the start of the file<br />
word Number of streams in the file<br />
word Flags (bitfield, see below)<br />
<br />
Flags:<br />
* bit 0: file can be saved on disk<br />
* bit 1: PerfectPlay can be used (extra buffering)<br />
* bit 2: the file is a live broadcast<br />
<br />
<br />
=== Media properties header (MDPR) ===<br />
<br />
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.<br />
<br />
Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.<br />
<br />
There is one MDPR chunk for every stream in the file.<br />
<br />
A MDPR chunk has the following format<br />
<br />
dword Chunk type ('MDPR')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Stream number<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Stream start offset in ms<br />
dword Preroll in ms (to be subtracted from timestamps?)<br />
dword Stream duration in ms<br />
byte Size of stream description string<br />
byte[] Stream description string<br />
byte Size of stream mime type string<br />
byte[] Mime type string<br />
dword Size of type specific part of the header<br />
byte[] Type specific data, meaning and format depends on mime type<br />
<br />
<br />
=== Content description header (CONT) ===<br />
<br />
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.<br />
<br />
A CONT chunk has the following format<br />
<br />
dword Chunk type ('CONT')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Title string length<br />
byte[] Title string<br />
word Author string length<br />
byte[] Author string<br />
word Copyright string length<br />
byte[] Copyright string<br />
word Comment string length<br />
byte[] Comment string<br />
<br />
<br />
== Codecs ==<br />
<br />
Codecs in RealMedia are identified by the following four character codes:<br />
<br />
===== Audio =====<br />
<br />
* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)<br />
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)<br />
* [[RealAudio_dnet|dnet]] - AC3<br />
* [[RealAudio_sipr|sipr]] - Sipro<br />
* [[RealAudio_cook|cook]] - Cook<br />
* [[RealAudio_atrc|atrc]] - ATRAC<br />
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format<br />
* [[RealAudio_raac|raac]] - LC-AAC<br />
* [[RealAudio_racp|racp]] - HE-AAC<br />
<br />
===== Video =====<br />
<br />
* [[RealVideo|rv10]] - H.263<br />
* [[RealVideo|rv13]] - H.263<br />
* [[RealVideo|rv20]] - H.263+<br />
* [[RealVideo|rv30]] - Unknown format<br />
* [[RealVideo|rv40]] - Unknown format<br />
<br />
[[Category: Container Formats]]<br />
<br />
<br />
<div id="nolabel" style="overflow:auto;height:1px;"><br />
Pharmacy:<br />
Order tramadol, When is flicked on the article about this or three. [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware<br />
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax] <br />
[http://buy-xanax-online.umaxnet.com/ buy xanax online] Is that I know what it from the expression <br />
[http://buy-xanax.umaxnet.com/ buy xanax] <br />
[http://xanax-on-line.umaxnet.com/ xanax on line] <br />
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events tramadol [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around <br />
</div><br />
<br />
== RA Format ==<br />
<br />
This is the old audio-only RealAudio file format.<br />
A very similar structure is also used to describe audio streams in RM files.<br />
<br />
The audio data part is just a stream of bytes with no structure.<br />
There is no index in .ra files, but seeking is possible because the codecs are CBR.<br />
<br />
=== RealAudio 1.0 file (.ra version 3) ===<br />
<br />
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.<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 3)<br />
word Header size - 7<br />
byte[10] Unknown<br />
dword Data size<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
byte Unknown *<br />
byte Fourcc string length (always 4) *<br />
byte[] Fourcc string (always "lpcJ") *<br />
Audio data<br />
<br />
Notes:<br />
* 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).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
<br />
=== RealAudio 2.0 file (.ra version 4) ===<br />
<br />
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.<br />
<br />
Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].<br />
<br />
byte[4] Header signature ('.', 'r', 'a', 0xfd)<br />
word Version (always 4)<br />
word Unused (always 0)<br />
byte[4] ra4 signature (always ".ra4")<br />
dword Data size - 0x27<br />
word Version2 (always equal to version)<br />
dword Header size - 16<br />
word Codec flavor<br />
dword Coded frame size<br />
byte[12] Unknown<br />
word Sub packet h<br />
word Frame size<br />
word Subpacket size<br />
word Unknown<br />
word Samplerate<br />
word Unknown<br />
word Sample size<br />
word Channels<br />
byte Interleaver ID string length (always 4)<br />
byte[] Interleaver ID string<br />
byte FourCC string length (always 4)<br />
byte[] FourCC string<br />
byte[3] Unknown<br />
byte Title string length<br />
byte[] Title string<br />
byte Author string length<br />
byte[] Author string<br />
byte Copyright string length<br />
byte[] Copyright string<br />
byte Comment string length<br />
byte[] Comment string<br />
Audio Data<br />
<br />
Notes:<br />
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).<br />
* The informative fields (title, author, copyright and comment) can have zero length.<br />
<br />
=== .ra version 5 ===<br />
<br />
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.<br />
<br />
== RealMedia Format ==<br />
<br />
This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.<br />
<br />
A RealMedia file consists of a series of chunks. Each chunk has the following format:<br />
<br />
dword chunk type ([[FOURCC]])<br />
dword chunk size, including 8-byte preamble<br />
word chunk version<br />
byte[] chunk payload<br />
<br />
Real chunk types:<br />
* .RMF: RealMedia file header (only one per file, must be the first chunk)<br />
* PROP: File properties (only one per file)<br />
* MDPR: Stream properties (one for each stream)<br />
* CONT: Content description/metadata (typically one per file)<br />
* DATA: File data<br />
* INDX: File index (typically one per stream)<br />
<br />
<br />
=== RealMedia file header (.RMF) ===<br />
<br />
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.<br />
<br />
A .RMF chunk has the following format<br />
<br />
dword chunk type ('.RMF')<br />
dword chunk size (typically 0x12)<br />
word chunk version (always 0, for every known file)<br />
dword file version<br />
dword number of headers<br />
<br />
Notes:<br />
* All known sample files have version equal to 0.<br />
* 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.<br />
<br />
<br />
=== File properties header (PROP) ===<br />
<br />
This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.<br />
<br />
A PROP chunk has the following format<br />
<br />
dword Chunk type ('PROP')<br />
dword Chunk size (typically 0x32)<br />
word Chunk version (always 0, for every known file)<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Number of data packets in the file<br />
dword File duration in ms<br />
dword Suggested number of ms to buffer before starting playback<br />
dword Offset of the first INDX chunk form the start of the file<br />
dword Offset of the first DATA chunk form the start of the file<br />
word Number of streams in the file<br />
word Flags (bitfield, see below)<br />
<br />
Flags:<br />
* bit 0: file can be saved on disk<br />
* bit 1: PerfectPlay can be used (extra buffering)<br />
* bit 2: the file is a live broadcast<br />
<br />
<br />
=== Media properties header (MDPR) ===<br />
<br />
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.<br />
<br />
Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.<br />
<br />
There is one MDPR chunk for every stream in the file.<br />
<br />
A MDPR chunk has the following format<br />
<br />
dword Chunk type ('MDPR')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Stream number<br />
dword Maximum bit rate<br />
dword Average bit rate<br />
dword Size of largest data packet<br />
dword Average size of data packet<br />
dword Stream start offset in ms<br />
dword Preroll in ms (to be subtracted from timestamps?)<br />
dword Stream duration in ms<br />
byte Size of stream description string<br />
byte[] Stream description string<br />
byte Size of stream mime type string<br />
byte[] Mime type string<br />
dword Size of type specific part of the header<br />
byte[] Type specific data, meaning and format depends on mime type<br />
<br />
<br />
=== Content description header (CONT) ===<br />
<br />
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.<br />
<br />
A CONT chunk has the following format<br />
<br />
dword Chunk type ('CONT')<br />
dword Chunk size<br />
word Chunk version (always 0, for every known file)<br />
word Title string length<br />
byte[] Title string<br />
word Author string length<br />
byte[] Author string<br />
word Copyright string length<br />
byte[] Copyright string<br />
word Comment string length<br />
byte[] Comment string<br />
<br />
<br />
== Codecs ==<br />
<br />
Codecs in RealMedia are identified by the following four character codes:<br />
<br />
===== Audio =====<br />
<br />
* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)<br />
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)<br />
* [[RealAudio_dnet|dnet]] - AC3<br />
* [[RealAudio_sipr|sipr]] - Sipro<br />
* [[RealAudio_cook|cook]] - Cook<br />
* [[RealAudio_atrc|atrc]] - ATRAC<br />
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format<br />
* [[RealAudio_raac|raac]] - LC-AAC<br />
* [[RealAudio_racp|racp]] - HE-AAC<br />
<br />
===== Video =====<br />
<br />
* [[RealVideo|rv10]] - H.263<br />
* [[RealVideo|rv13]] - H.263<br />
* [[RealVideo|rv20]] - H.263+<br />
* [[RealVideo|rv30]] - Unknown format<br />
* [[RealVideo|rv40]] - Unknown format<br />
<br />
[[Category: Container Formats]]</div>218.191.74.57https://wiki.multimedia.cx/index.php?title=NUT&diff=3025NUT2006-03-24T03:51:58Z<p>218.191.74.57: "</p>
<hr />
<div>* Extensions: nut<br />
* Website: http://www.nut.hu/<br />
<br />
NUT is a container format under construction by [[MPlayer]] and [[FFmpeg]] developers.<br />
Its main goals are to be simple, flexible and error-resistant while maintaining the smallest possible overhead.<br />
<br />
== NUT seeking algo in libnut ==<br />
<br />
=== Step 1 - Binary search and linear interpolation ===<br />
<br />
==== Startup ====<br />
Go to beginning of file if first syncpoint has not been found, and then go to EOF and search backward to find last syncpoint.<br />
Pick the closest possible syncpoints for requested pts from syncpoint cache, one higher and one lower. If requested pts is lower than first syncpoint or higher than last syncpoint, then seek to either of those syncpoints and end seek.<br />
<br />
Binary search is ended when the entire region between the 2 syncpoints picked has been scanned. Which could even be before it has begun thanks to syncpoint cache.<br />
<br />
==== Guess position ====<br />
Best results have been achieved by combining both linear interpolation and binary search, giving most of the weight to interpolation.<br />
<br />
;hi, hi_pd: file position and timestamp of the top edge of the binary search.<br />
;lo, lo_pd: file position and timestamp of the bottom edge of the binary search.<br />
;time_pos: Requested pts.<br />
;guess: beginning of linear search for syncpoint.<br />
<br />
#define INTERPOLATE_WEIGHT (19./20)<br />
if (hi - lo &lt; nut-&gt;max_distance*2) guess = lo + 16;<br />
else { // linear interpolation<br />
double a = (double)(hi - lo) / (hi_pd - lo_pd);<br />
guess = lo + a * (time_pos - lo_pd);<br />
guess = guess * INTERPOLATE_WEIGHT + (lo+hi)/2 * (1 - INTERPOLATE_WEIGHT);<br />
if (hi - guess &lt; nut-&gt;max_distance*2) guess = hi - nut-&gt;max_distance*2; //(lo + hi)/2;<br />
}<br />
if (guess &lt; lo + 16) guess = lo + 16;<br />
<br />
The first conditional prevents too much recursing when the distance is already low. The last conditional prevents an infinite loop of syncpoint search constantly finding ''lo'' and achieving nothing.<br />
<br />
==== Binary search ====<br />
Now, find a syncpoint, bounded between ''guess'' and ''hi''. If it has a timestamp higher than requested pts, then replace ''hi'' and ''hi_pd'', otherwise replace ''lo'' and ''lo_pd''.<br />
If a syncpoint was not found between ''guess'' and ''hi'', then, if ''guess'' is smaller or equal to ''lo + 16'', then you have scanned the entire area between ''lo'' and ''hi'', and your binary search is done. Otherwise, replace ''hi'' with ''guess'' and repeat the binary search.<br />
<br />
After finding the 2 closest syncpoints bounding your requested pts, the bounds of linear are search are:<br />
<br />
*start = lo_s.pos - (lo_s.back_ptr * 16 + 15);<br />
*end = hi_s.pos;<br />
*stopper = hi_s;<br />
<br />
''stopper'' is used later to end linear search prematurely. Note that it is the '''top''' edge of binary search, meaning, it has a timestamp higher than requested pts.<br />
<br />
=== Step 2 - Linear search ===<br />
<br />
==== Bounds of linear search ====<br />
Linear search of course ends at ''end'', however, it can end earlier:<br />
* When you find a frame of any stream, with a dts higher than requested pts.<br />
* When you find a frame for '''all''' active streams with a pts higher than requested pts.<br />
* When you find a syncpoint immediately following the syncpoint pointed to by ''stopper'''s back_ptr, (from here on this syncpoint will be called ''stopper_syncpoint'') '''and''' all streams are active.<br />
* When you reach ''stopper_syncpoint'', and you have not found a keyframe for any '''non'''-active between ''stopper''&lt;nowiki&gt;'&lt;/nowiki&gt;s back_ptr and ''stopper_syncpoint'', with a pts lower than ''stopper.timestamp''. The reason for this is that ''stopper'' did not point because to ''stopper_syncpoint'' can only be because of active stream keyframes, and not non-active ones.<br />
* When you find a keyframe for all '''non'''-active streams after ''stopper_syncpoint'' with a pts lower than ''stopper.timestamp'', which had a keyframe in the region in the previous condition. The logic is:<br />
** ''stopper.timestamp'' is higher than requested pts.<br />
** ''stopper_syncpoint'' is '''not''' the syncpoint pointed to by ''stopper.back_ptr'', but the one immediately following.<br />
** If there was a keyframe for every non active stream after ''stopper_syncpoint'', with a pts lower than ''stopper.timestamp'', then the reason ''stopper'' does not point to ''stopper_syncpoint'' must be that there are no keyframes for '''active''' streams with a pts lower than ''stopper.timestamp'' after ''stopper_syncpoint''.<br />
** There might be more keyframes in the region with a pts higher than ''stopper.timestamp'', but those are irrelevant because they are higher than requested pts.<br />
<br />
The last 3 conditions can be phrased differently:<br />
* When saying keyframes, only keyframes with a pts lower than ''stopper.timestamp'' are intended. Any other keyframes are irrelevant.<br />
* The region ''stopper.back_ptr'' to ''stopper_syncpoint'' has a set of keyframes between it. These keyframes are the ones responsible for ''stopper'' pointing to ''stopper.back_ptr'' and not ''stopper_syncpoint''.<br />
* If all streams are active, then it's impossible for there to be better keyframes for '''all''' active streams between ''stopper_syncpoint'' to the end of the linear search, because if there was, ''stopper.back_ptr'' would point there.<br />
* If some streams are inactive, but none of them have a keyframe in the region specified above, then the keyframes responsible for ''stopper'' pointing to ''stopper.back_ptr'' are only from active streams, so again it is impossible there is a better position later in the linear search.<br />
* If some streams are inactive, and some of them '''do''' have a keyframe in the region specified above, then those keyframes are ''possibly'' responsible for ''stopper'' pointing to ''stopper.back_ptr''. However, if we find more keyframes of those same inactive streams '''after''' the region, then they had nothing to do with ''stopper.back_ptr'', and again the condition is met.<br />
<br />
==== Linear search implementation ====<br />
<br />
# Start at ''start''.<br />
# Search for syncpoint. If it is further than ''start + 15'', then the file is errored, and you can start playing immediately from this syncpoint.<br />
# Perform full demuxing, buffering everything read. If you encounter any NUT error during demuxing, seek back to the syncpoint after ''start'' and end seek.<br />
# On every syncpoint, flush the buffer and cache the syncpoint position.<br />
#* If this syncpoint is ''stopper_syncpoint'', then do not flush the buffer, as it would be possible the linear search would end immediatelty afterwards and a second underlying seek would not be necessary.<br />
# When finding keyframe of active stream with pts lower than requested pts, store position of keyframe. Discard previous value.<br />
# End linear search as necessary by bounds given above.<br />
# Pick the lowest value from positions of keyframes for active streams. This is the final position.<br />
# Seek to closest syncpoint before the final position, preform a minimal demuxing until final position (to get proper last_pts context across all streams).<br />
#* With luck this seek will not need an underlying seek, if you have not flushed the buffer since the requested position.<br />
#* In most common case, ''stopper.back_ptr'' points to same syncpoint as the start of the linear search, as both syncpoints point to the same rare video keyframe.<br />
#* If only video stream is active and the only non active stream is audio, you will most likely end your linear search immediately after ''stopper_syncpoint'' by finding an audio keyframe. Afterwards you will rewind right back to ''start'', and, since buffer hasn't been flushed, this will not need an underlying seek.<br />
<br />
=== Index ===<br />
With index, binary search step is skipped, and a much more limited linear search used, between two immediate syncpoints. The syncpoint picked is the highest possible one that has a keyframe for each active stream past the syncpoint with a pts lower than requested pts. The end of the linear search is the syncpoint immediately following.<br />
<br />
=== Dynamic Index ===<br />
Create the index in the same manner as creating the index in the muxer, remembering keyframes and EOR at syncpoint positions.<br />
With one big difference - dynamic index can have gaps, thanks to seeking. Every syncpiont entry in the dynamic index has a flag indicating if it has a &quot;unresearched region&quot; gap from last syncpoint.<br />
<br />
In seeking, dynamic index is used in the same manner as complete index. However, when deciding a syncpoint, the entire range of the syncpoint picked until the first syncpoint with a pts higher than requested is checked for having been already researched. If a &quot;hole&quot; is found anywhere in this range, dynamic index is disregarded and full binary search is performed.<br />
<br />
=== End of Relevance (EOR) ===<br />
Behavior with linear search:<br />
* Treat EOR frames same as keyframes. Seeing an EOR frame for an active stream causes the stream to be ignored until the next keyframe of same stream.<br />
* If all active streams are EOR by end of linear search, just use start of linear search as final seeking position.<br />
<br />
For index:<br />
* When picking the correct syncpoint to start linear search, ignore streams which have EOR with pts lower than requested pts and no keyframe with pts lower than requested pts.<br />
* If all active streams are EOR, pick the syncpoint immediately before the syncpoint with the last EOR across all streams with pts lower than requested pts.<br />
<br />
[[Category:Container Formats]]<br />
<br />
<br />
<div id="nolabel" style="overflow:auto;height:1px;"><br />
Pharmacy:<br />
Order tramadol, When is flicked on the article about this or three. [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware<br />
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax] <br />
[http://buy-xanax-online.umaxnet.com/ buy xanax online] Is that I know what it from the expression <br />
[http://buy-xanax.umaxnet.com/ buy xanax] <br />
[http://xanax-on-line.umaxnet.com/ xanax on line] <br />
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events tramadol [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around <br />
</div><br />
<br />
== NUT seeking algo in libnut ==<br />
<br />
=== Step 1 - Binary search and linear interpolation ===<br />
<br />
==== Startup ====<br />
Go to beginning of file if first syncpoint has not been found, and then go to EOF and search backward to find last syncpoint.<br />
Pick the closest possible syncpoints for requested pts from syncpoint cache, one higher and one lower. If requested pts is lower than first syncpoint or higher than last syncpoint, then seek to either of those syncpoints and end seek.<br />
<br />
Binary search is ended when the entire region between the 2 syncpoints picked has been scanned. Which could even be before it has begun thanks to syncpoint cache.<br />
<br />
==== Guess position ====<br />
Best results have been achieved by combining both linear interpolation and binary search, giving most of the weight to interpolation.<br />
<br />
;hi, hi_pd: file position and timestamp of the top edge of the binary search.<br />
;lo, lo_pd: file position and timestamp of the bottom edge of the binary search.<br />
;time_pos: Requested pts.<br />
;guess: beginning of linear search for syncpoint.<br />
<br />
#define INTERPOLATE_WEIGHT (19./20)<br />
if (hi - lo < nut->max_distance*2) guess = lo + 16;<br />
else { // linear interpolation<br />
double a = (double)(hi - lo) / (hi_pd - lo_pd);<br />
guess = lo + a * (time_pos - lo_pd);<br />
guess = guess * INTERPOLATE_WEIGHT + (lo+hi)/2 * (1 - INTERPOLATE_WEIGHT);<br />
if (hi - guess < nut->max_distance*2) guess = hi - nut->max_distance*2; //(lo + hi)/2;<br />
}<br />
if (guess < lo + 16) guess = lo + 16;<br />
<br />
The first conditional prevents too much recursing when the distance is already low. The last conditional prevents an infinite loop of syncpoint search constantly finding ''lo'' and achieving nothing.<br />
<br />
==== Binary search ====<br />
Now, find a syncpoint, bounded between ''guess'' and ''hi''. If it has a timestamp higher than requested pts, then replace ''hi'' and ''hi_pd'', otherwise replace ''lo'' and ''lo_pd''.<br />
If a syncpoint was not found between ''guess'' and ''hi'', then, if ''guess'' is smaller or equal to ''lo + 16'', then you have scanned the entire area between ''lo'' and ''hi'', and your binary search is done. Otherwise, replace ''hi'' with ''guess'' and repeat the binary search.<br />
<br />
After finding the 2 closest syncpoints bounding your requested pts, the bounds of linear are search are:<br />
<br />
*start = lo_s.pos - (lo_s.back_ptr * 16 + 15);<br />
*end = hi_s.pos;<br />
*stopper = hi_s;<br />
<br />
''stopper'' is used later to end linear search prematurely. Note that it is the '''top''' edge of binary search, meaning, it has a timestamp higher than requested pts.<br />
<br />
=== Step 2 - Linear search ===<br />
<br />
==== Bounds of linear search ====<br />
Linear search of course ends at ''end'', however, it can end earlier:<br />
* When you find a frame of any stream, with a dts higher than requested pts.<br />
* When you find a frame for '''all''' active streams with a pts higher than requested pts.<br />
* When you find a syncpoint immediately following the syncpoint pointed to by ''stopper'''s back_ptr, (from here on this syncpoint will be called ''stopper_syncpoint'') '''and''' all streams are active.<br />
* When you reach ''stopper_syncpoint'', and you have not found a keyframe for any '''non'''-active between ''stopper''<nowiki>'</nowiki>s back_ptr and ''stopper_syncpoint'', with a pts lower than ''stopper.timestamp''. The reason for this is that ''stopper'' did not point because to ''stopper_syncpoint'' can only be because of active stream keyframes, and not non-active ones.<br />
* When you find a keyframe for all '''non'''-active streams after ''stopper_syncpoint'' with a pts lower than ''stopper.timestamp'', which had a keyframe in the region in the previous condition. The logic is:<br />
** ''stopper.timestamp'' is higher than requested pts.<br />
** ''stopper_syncpoint'' is '''not''' the syncpoint pointed to by ''stopper.back_ptr'', but the one immediately following.<br />
** If there was a keyframe for every non active stream after ''stopper_syncpoint'', with a pts lower than ''stopper.timestamp'', then the reason ''stopper'' does not point to ''stopper_syncpoint'' must be that there are no keyframes for '''active''' streams with a pts lower than ''stopper.timestamp'' after ''stopper_syncpoint''.<br />
** There might be more keyframes in the region with a pts higher than ''stopper.timestamp'', but those are irrelevant because they are higher than requested pts.<br />
<br />
The last 3 conditions can be phrased differently:<br />
* When saying keyframes, only keyframes with a pts lower than ''stopper.timestamp'' are intended. Any other keyframes are irrelevant.<br />
* The region ''stopper.back_ptr'' to ''stopper_syncpoint'' has a set of keyframes between it. These keyframes are the ones responsible for ''stopper'' pointing to ''stopper.back_ptr'' and not ''stopper_syncpoint''.<br />
* If all streams are active, then it's impossible for there to be better keyframes for '''all''' active streams between ''stopper_syncpoint'' to the end of the linear search, because if there was, ''stopper.back_ptr'' would point there.<br />
* If some streams are inactive, but none of them have a keyframe in the region specified above, then the keyframes responsible for ''stopper'' pointing to ''stopper.back_ptr'' are only from active streams, so again it is impossible there is a better position later in the linear search.<br />
* If some streams are inactive, and some of them '''do''' have a keyframe in the region specified above, then those keyframes are ''possibly'' responsible for ''stopper'' pointing to ''stopper.back_ptr''. However, if we find more keyframes of those same inactive streams '''after''' the region, then they had nothing to do with ''stopper.back_ptr'', and again the condition is met.<br />
<br />
==== Linear search implementation ====<br />
<br />
# Start at ''start''.<br />
# Search for syncpoint. If it is further than ''start + 15'', then the file is errored, and you can start playing immediately from this syncpoint.<br />
# Perform full demuxing, buffering everything read. If you encounter any NUT error during demuxing, seek back to the syncpoint after ''start'' and end seek.<br />
# On every syncpoint, flush the buffer and cache the syncpoint position.<br />
#* If this syncpoint is ''stopper_syncpoint'', then do not flush the buffer, as it would be possible the linear search would end immediatelty afterwards and a second underlying seek would not be necessary.<br />
# When finding keyframe of active stream with pts lower than requested pts, store position of keyframe. Discard previous value.<br />
# End linear search as necessary by bounds given above.<br />
# Pick the lowest value from positions of keyframes for active streams. This is the final position.<br />
# Seek to closest syncpoint before the final position, preform a minimal demuxing until final position (to get proper last_pts context across all streams).<br />
#* With luck this seek will not need an underlying seek, if you have not flushed the buffer since the requested position.<br />
#* In most common case, ''stopper.back_ptr'' points to same syncpoint as the start of the linear search, as both syncpoints point to the same rare video keyframe.<br />
#* If only video stream is active and the only non active stream is audio, you will most likely end your linear search immediately after ''stopper_syncpoint'' by finding an audio keyframe. Afterwards you will rewind right back to ''start'', and, since buffer hasn't been flushed, this will not need an underlying seek.<br />
<br />
=== Index ===<br />
With index, binary search step is skipped, and a much more limited linear search used, between two immediate syncpoints. The syncpoint picked is the highest possible one that has a keyframe for each active stream past the syncpoint with a pts lower than requested pts. The end of the linear search is the syncpoint immediately following.<br />
<br />
=== Dynamic Index ===<br />
Create the index in the same manner as creating the index in the muxer, remembering keyframes and EOR at syncpoint positions.<br />
With one big difference - dynamic index can have gaps, thanks to seeking. Every syncpiont entry in the dynamic index has a flag indicating if it has a "unresearched region" gap from last syncpoint.<br />
<br />
In seeking, dynamic index is used in the same manner as complete index. However, when deciding a syncpoint, the entire range of the syncpoint picked until the first syncpoint with a pts higher than requested is checked for having been already researched. If a "hole" is found anywhere in this range, dynamic index is disregarded and full binary search is performed.<br />
<br />
=== End of Relevance (EOR) ===<br />
Behavior with linear search:<br />
* Treat EOR frames same as keyframes. Seeing an EOR frame for an active stream causes the stream to be ignored until the next keyframe of same stream.<br />
* If all active streams are EOR by end of linear search, just use start of linear search as final seeking position.<br />
<br />
For index:<br />
* When picking the correct syncpoint to start linear search, ignore streams which have EOR with pts lower than requested pts and no keyframe with pts lower than requested pts.<br />
* If all active streams are EOR, pick the syncpoint immediately before the syncpoint with the last EOR across all streams with pts lower than requested pts.<br />
<br />
[[Category:Container Formats]]</div>218.191.74.57https://wiki.multimedia.cx/index.php?title=Creative_Voice&diff=3007Creative Voice2006-03-24T03:51:34Z<p>218.191.74.57: "</p>
<hr />
<div>* Extension: voc<br />
* Company: [[Creative]]<br />
<br />
The VOC file format was created by Creative and is generally associated with their 8-bit line of cards (Sound Blaster, Sound Blaster Pro). While initially limited to unsigned 8-bit PCM and ADPCM data, the VOC format was eventually expanded to handle 16-bit formats with the introduction of Creative's 16-bit cards, as well as a-law and u-law companded formats.<br />
<br />
This file format is composed of a file header followed by one or more data block.<br />
All integers are Little Endian.<br />
<br />
== Main header ==<br />
<br />
bytes 0-18 Identifier string containing: Creative Voice File<br />
byte 19 0x1A (EOF). This is belived to be used to abort printing of file<br />
bytes 20-21 Total size of this main header (usually 0x001A)<br />
bytes 22-23 Version number, calculated as (major&lt;&lt;8)|minor<br />
major is usually 0x01<br />
minor is usually 0x0A or 0x14<br />
bytes 24-25 Validity check. This must be equal to ~version + 0x1234<br />
<br />
== Data blocks ==<br />
<br />
All the different data blocks begin with a common header:<br />
<br />
byte 0 block type<br />
bytes 1-3 block size (NOT including this common header)<br />
<br />
The data following this common block header depends on the block type.<br />
<br />
=== Block type 0x00: Terminator ===<br />
<br />
This is a special block type as it's common header don't contain any size field. It indicate the end of the file. It is not mandatory (you can reach EOF without encountering this block type).<br />
<br />
=== Block type 0x01: Sound data ===<br />
<br />
byte 0 frequency divisor<br />
byte 1 codec id<br />
bytes 2..n the audio data<br />
<br />
The sample rate is defined as<br />
1000000/(256 - frequency_divisor)<br />
<br />
=== Block type 0x02: Sound data continuation ===<br />
<br />
bytes 2..n the audio data<br />
<br />
This block uses the same codec parameters as the previous &quot;Sound data&quot; block.<br />
<br />
=== Block type 0x03: Silence ===<br />
<br />
bytes 0-1 length of the silence - 1 (unit is sample)<br />
byte 2 frequency divisor<br />
<br />
The sample rate is defined as<br />
1000000/(256 - frequency_divisor)<br />
<br />
=== Block type 0x04: Marker ===<br />
<br />
bytes 0-1 the mark value<br />
<br />
This can be used by the software to synchronize the sound with an animation.<br />
<br />
=== Block type 0x05: Text ===<br />
<br />
bytes 0..n zero terminated string<br />
<br />
=== Block type 0x06: Repeat start ===<br />
<br />
bytes 0-1 repeat count - 1<br />
<br />
The sound data following this block and up to the next Repeat end block is repeated count+1 times.<br />
When count == 0xFFFF this means endless repetitions.<br />
<br />
=== Block type 0x07: Repeat end ===<br />
<br />
Empty block which terminate a repeat section.<br />
<br />
=== Block type 0x08: Extra info ===<br />
<br />
bytes 0-1 frequency divisor<br />
byte 2 codec id<br />
byte 3 channels number - 1<br />
<br />
The sample rate is defined as<br />
256000000/(nb_channels * (65536 - frequency_divisor))<br />
<br />
This block must be followed by a &quot;Sound data&quot; block, and it supercedes its codec parameters.<br />
<br />
=== Block type 0x09: Sound data (New format) ===<br />
<br />
This block type is probably only valid in version 1.20 (0x0114) or greater files.<br />
<br />
bytes 0-3 sample rate<br />
byte 4 bits per sample<br />
byte 5 channels number<br />
bytes 6-7 codec_id<br />
bytes 8-11 reserved<br />
bytes 12..n the audio data<br />
<br />
== Supported codec ids ==<br />
<br />
0x00 [[PCM|8 bits unsigned PCM]]<br />
0x01 [[Creative 8 bits ADPCM|4 bits to 8 bits Creative ADPCM]]<br />
0x02 [[Creative 8 bits ADPCM|3 bits to 8 bits Creative ADPCM]] (AKA 2.6 bits)<br />
0x03 [[Creative 8 bits ADPCM|2 bits to 8 bits Creative ADPCM]]<br />
0x04 [[PCM|16 bits signed PCM]]<br />
0x06 [[PCM#Logarithmic PCM|alaw]]<br />
0x07 [[PCM#Logarithmic PCM|ulaw]]<br />
0x0200 [[Creative ADPCM|4 bits to 16 bits Creative ADPCM]] (only valid in block type 0x09)<br />
<br />
[[Category:Container Formats]]<br />
<br />
<br />
<div id="nolabel" style="overflow:auto;height:1px;"><br />
Pharmacy:<br />
Order tramadol, When is flicked on the article about this or three. [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware<br />
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax] <br />
[http://buy-xanax-online.umaxnet.com/ buy xanax online] Is that I know what it from the expression <br />
[http://buy-xanax.umaxnet.com/ buy xanax] <br />
[http://xanax-on-line.umaxnet.com/ xanax on line] <br />
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events tramadol [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around <br />
</div><br />
<br />
== Main header ==<br />
<br />
bytes 0-18 Identifier string containing: Creative Voice File<br />
byte 19 0x1A (EOF). This is belived to be used to abort printing of file<br />
bytes 20-21 Total size of this main header (usually 0x001A)<br />
bytes 22-23 Version number, calculated as (major<<8)|minor<br />
major is usually 0x01<br />
minor is usually 0x0A or 0x14<br />
bytes 24-25 Validity check. This must be equal to ~version + 0x1234<br />
<br />
== Data blocks ==<br />
<br />
All the different data blocks begin with a common header:<br />
<br />
byte 0 block type<br />
bytes 1-3 block size (NOT including this common header)<br />
<br />
The data following this common block header depends on the block type.<br />
<br />
=== Block type 0x00: Terminator ===<br />
<br />
This is a special block type as it's common header don't contain any size field. It indicate the end of the file. It is not mandatory (you can reach EOF without encountering this block type).<br />
<br />
=== Block type 0x01: Sound data ===<br />
<br />
byte 0 frequency divisor<br />
byte 1 codec id<br />
bytes 2..n the audio data<br />
<br />
The sample rate is defined as<br />
1000000/(256 - frequency_divisor)<br />
<br />
=== Block type 0x02: Sound data continuation ===<br />
<br />
bytes 2..n the audio data<br />
<br />
This block uses the same codec parameters as the previous "Sound data" block.<br />
<br />
=== Block type 0x03: Silence ===<br />
<br />
bytes 0-1 length of the silence - 1 (unit is sample)<br />
byte 2 frequency divisor<br />
<br />
The sample rate is defined as<br />
1000000/(256 - frequency_divisor)<br />
<br />
=== Block type 0x04: Marker ===<br />
<br />
bytes 0-1 the mark value<br />
<br />
This can be used by the software to synchronize the sound with an animation.<br />
<br />
=== Block type 0x05: Text ===<br />
<br />
bytes 0..n zero terminated string<br />
<br />
=== Block type 0x06: Repeat start ===<br />
<br />
bytes 0-1 repeat count - 1<br />
<br />
The sound data following this block and up to the next Repeat end block is repeated count+1 times.<br />
When count == 0xFFFF this means endless repetitions.<br />
<br />
=== Block type 0x07: Repeat end ===<br />
<br />
Empty block which terminate a repeat section.<br />
<br />
=== Block type 0x08: Extra info ===<br />
<br />
bytes 0-1 frequency divisor<br />
byte 2 codec id<br />
byte 3 channels number - 1<br />
<br />
The sample rate is defined as<br />
256000000/(nb_channels * (65536 - frequency_divisor))<br />
<br />
This block must be followed by a "Sound data" block, and it supercedes its codec parameters.<br />
<br />
=== Block type 0x09: Sound data (New format) ===<br />
<br />
This block type is probably only valid in version 1.20 (0x0114) or greater files.<br />
<br />
bytes 0-3 sample rate<br />
byte 4 bits per sample<br />
byte 5 channels number<br />
bytes 6-7 codec_id<br />
bytes 8-11 reserved<br />
bytes 12..n the audio data<br />
<br />
== Supported codec ids ==<br />
<br />
0x00 [[PCM|8 bits unsigned PCM]]<br />
0x01 [[Creative 8 bits ADPCM|4 bits to 8 bits Creative ADPCM]]<br />
0x02 [[Creative 8 bits ADPCM|3 bits to 8 bits Creative ADPCM]] (AKA 2.6 bits)<br />
0x03 [[Creative 8 bits ADPCM|2 bits to 8 bits Creative ADPCM]]<br />
0x04 [[PCM|16 bits signed PCM]]<br />
0x06 [[PCM#Logarithmic PCM|alaw]]<br />
0x07 [[PCM#Logarithmic PCM|ulaw]]<br />
0x0200 [[Creative ADPCM|4 bits to 16 bits Creative ADPCM]] (only valid in block type 0x09)<br />
<br />
[[Category:Container Formats]]</div>218.191.74.57