RM/RMVB文件格式總結

 

RM/RMVB文件格式總結

RM文件格式是標準的標記符文件格式，RM文件格式把標記符塊組合成頭塊，數據快，索引塊，這些標記符塊的組合方法如下：
.RMF頭塊
RealMedia File Header(RM 文件頭)

PROP屬性頭
Properties（屬性頭）

MDPR媒體屬性頭
（可含多個）
Media Properties（媒體屬性頭1）


Media Properties（媒體屬性頭2）


------（其他媒體屬性頭3—n）

CONT內容描述頭
Content Properties（內容描述頭）

DATA數據段（可含多個）
Data Chunk Header（數據塊頭）


Data Packets（數據包）


------（其他數據包）


Data Chunk Header（數據塊頭）


Data Packets（數據包）


------（其他數據包）


---------（其他數據段）

INDX索引段（可含多個）
Index Section（索引段）


------（其他索引段）

    RM文件格式是標記符文件格式，所以塊的先後次序並不確定，只有RM文件頭必須是文件的第一個塊。典型的RM格式文件的頭段：RM文件頭（必須是文件的第一塊）、屬性頭、媒體屬性頭、內容描述頭。在RM文件頭後面，其他的頭可以按任何次序出現，除了索引頭以外，其他的頭都必須要。

RM/RMVB 文件格式-.RMF(文件頭)
每一個RM文件都以RM文件頭開始，RM文件頭標識文件是RMF類型，在RM文件中只有一種RM文件頭,因爲RM文件頭的內容可能隨着RMF的版本不同而改變，所以頭結構裏面有個版本域來指明有什麼其他的額外域存在。下面的數據結構就是RM文件頭的數據存儲方式：
RealMedia_File_Header
{
       UINT32 object_id;
       UINT32 size;
       UINT16 object_version;
       if((object_version= =0)||(object_version= =1))
       {
              UINT32 file_version;
              UINT32 num_headers;
       }
}
結構中包含有如下成員： 
object_id，RM文件的唯一標識(“.RMF”)，所有的RM文件都以這個標識開頭，用32個二進制位表示；
size，RM頭段的大小，用32個二進制位表示；//上述結構體中五個元素都含有時，爲18字節
object_version，RM文件頭的版本，決定結構中其他成員的取捨，用16個二進制位表示；
file_version，RM文件的版本，用32個二進制位表示；
num_headers，頭段中RM文件頭後面的包含的頭的個數，用32個二進制位表示。注：num_headers具體指那些頭的個數不明，有文件該值爲7，但僅包含1個PROP，3個MPPR，1個CONT，如果算上.RMF共6個；另外有文件該值爲7，包含有1個PROP，3個MPPR，1個CONT，如果算上.RMF共6個，如果算上INDX（3個）則總數是9個。
如圖: 

RM/RMVB 文件格式-PROP(屬性頭)
屬性頭  PROP
屬性頭描述了RM文件的一般媒體屬性，RM系統的組件根據屬性頭進行適當的配置來處理RM文件或RM流中數據。在RM文件中只有一個屬性頭，下面的數據結構就是屬性頭的數據存儲方式：
Properties
{
       UINT32 object_id; [0-3]
       UINT32 size;[4-7]
       UINT16 object_version;[8-9]
       if(object_version==0)
       {
              UINT32 max_bit_rate;[10 - 13]
              UINT32 avg_bit_rate;[14 - 17]
              UINT32 max_packet_size;[18 - 21]
              UINT32 avg_packet_size;[22 - 25]
              UINT32 num_packets;[26 - 29]
              UINT32 duration;[30 - 33]
              UINT32 preroll; [34 - 37]
              UINT32 index_offset; [38 - 41]
              UINT32 data_offset; [42 - 45]
              UINT16 num_streams; [46 - 47]
              UINT16 flags; [48 - 49]
       }
}
結構中包含有如下成員：
object_id，屬性頭唯一標識 （“PROP”）,用32個二進制位表示；
size,屬性頭大小,用32個二進制位表示；10+40字節
object_version，RM文件頭版本，決定結構中其他成員的取捨，此結構中此值爲零，用16個二進制位表示； 
max_bit_rate，網絡傳輸時要求的最大比特率，用32個二進制位表示；
avg_bit_rate，網絡傳輸時要求的平均比特率，用32個二進制位表示；
max_packet_size，最大媒體數據包的大小（以字節計算），用32個二進制位表示；
avg_packet_size，平均媒體數據包的大小（以字節計算），用32個二進制位表示；
num_packets，媒體數據包個數，用32個二進制位表示；
duration，媒體文件應該播放的時間（以毫秒計算），用32個二進制位表示；
preroll，回放之前的預留毫秒數，用32個二進制位表示；
index_offset，索引頭到文件開始的偏移，這個值可爲零，表明沒有索引段，用32個二進制位表示；
data_offset，數據段到文件開始的偏移，用32個二進制位表示（注:在RM文件中可以有不止一個數據塊頭，這個值只表示第一個數據塊頭到文件開始的偏移，其他數據塊頭的偏移可以從數據塊頭中next_data_header域得到）；
num_streams，在主頭段中包含的全部媒體屬性頭（MDPR）的個數，用16個二進制位表示；
flags，包含文件信息的位掩碼，用16個二進制位表示。具體信息如下表，其它位應設置爲零。//flags，文件中flag出現過如下值：0009，000b 所以下述位掩碼顯然不完全。文件信息的位掩碼錶：
位
標誌
描述
0
保存允許
如果是1，就允許保存此文件到磁盤
1
最佳播放
如果是1， 建議使用額外的緩存
2
實況
如果是1， 表明媒體流來自實況廣播
圖例:


RM/RMVB 文件格式-MDPR(媒體屬性頭)
媒體屬性頭描述了RM文件中每個媒體流的特定屬性，RM系統的組件根據媒體屬性頭進行適當的配置來處理RM流中的媒體數據，RM文件中每一個媒體流有一個媒體屬性頭。
媒體屬性頭的整體組成
下面的數據結構就是媒體屬性頭的數據存儲方式： 
Media_Properties
{
       UINT32 object_id;[0 - 3]
       UINT32 size;[4 - 7]
       UINT16 object_version;[8 - 9]
       if(object_version==0)
       {
              UINT16 stream_number; [10 - 11]
              UINT32 max_bit_rate; [12 - 15]
              UINT32 avg_bit_rate; [16 - 19]
              UINT32 max_packet_size;[20 - 23]
              UINT32 avg_packet_size;[24 - 27]
              UINT32 start_time;[28 - 31]
              UINT32 preroll; [32 - 35]
              UINT32 duration; [36 -39]
              UINT8  stream_name_size;[40 - 40]
              UINT8[stream_name_size]  stream_name;[41 - 41]
              UINT8 mime_type_size;[42 - 42]
              UINT8[mime_type_size]   mime_type;[43 - 43]
//決定Type_Specific_Data
              UINT32 type_specific_len;[44 - 47]
              UINT8[type_specific_len]   Type_Specific_Data;[48 - 51]
//詳細說明見後文
       }
}
媒體屬性頭結構中包含有如下這些成員：
object_id:媒體屬性頭唯一標識，爲“MDPR”；
size，表明媒體屬性頭的大小；
object_version，媒體屬性頭版本號；
stream_number，流的標識，表明RM媒體文件中此媒體屬性頭代表的是哪個數據流（視頻數據流或音頻數據流），在數據段中的每個數據包中都包含有類似的標識以表明數據是屬於哪個媒體流。當版本號爲零時此成員才存在；
max_bit_rate，網絡上傳輸此媒體流所要求的最大比特率，當版本號爲零時此成員才存在；
avg_bit_rate，網絡上傳輸此媒體流所要求的平均比特率，當版本號爲零時此成員才存在；
max_packet_size，媒體流數據包的最大容量（以字節計算），當版本號爲零時此成員才存在；
avg_packet_size，媒體流數據包的平均容量（以字節計算），當版本號爲零時此成員才存在；
start_time，開始時間（毫秒錶示），用於加到數據包時間標誌上，當版本號爲零時此成員才存在；
preroll，和start_time相反的時間尺度（毫秒錶示），用於從數據包時間標誌中減去的值，當版本號爲零時此成員才存在；
duration，流的持續時間，當版本號爲零時此成員才存在；
stream_name_size，流名稱所佔字節數，當版本號爲零時此成員才存在，用8個二進制位表示；
stream_name，流的名稱，版本號爲零時此成員才存在，大小不定；
mime_type_size，表明下個成員（mime_type）所佔的存儲空間，版本號爲零時此成員才存在，用8個二進制位表示；
mime_type，和流相關的MIME形式的類型或子類型字符串，版本號爲零時此成員才存在，大小不定；mime_type：1、audio/x-pn-realaudio；2、video/x-pn-realvideo；3、logical-fileinfo
type_specific_len，表明下個成員(pe_specific_data）所佔的存儲空間，版本號爲零時此成員才存在，；
Type_Specific_Data，一般用來保存對流進行處理的特殊數據，版本號爲零時此成員才存在，大小不定。 
圖示1:


RealMedia-rmff
    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 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 28_8, dnet and 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 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 
lpcJ - RealAudio 1.0 (VSELP) 
28_8 - RealAudio 2.0 (LD-CELP) 
dnet - AC3 
sipr - Sipro 
cook - Cook 
atrc - ATRAC 
ralf - RealAudio Lossless Format 
raac - LC-AAC 
racp - HE-AAC 
Video 
RV10 - H.263 
RV13 - H.263 
RV20 - H.263+ 
RV30 - H.264 precursor 
RV40 - H.264 precursor 

static const PVCodecTag rm_codec_tags[] = {
    { CODEC_ID_RV10,   MKTAG('R','V','1','0') },
    { CODEC_ID_RV20,   MKTAG('R','V','2','0') },
    { CODEC_ID_RV20,   MKTAG('R','V','T','R') },
    { CODEC_ID_RV30,   MKTAG('R','V','3','0') },
    { CODEC_ID_RV40,   MKTAG('R','V','4','0') },
    { CODEC_ID_AC3,    MKTAG('d','n','e','t') },
    { CODEC_ID_RA_144, MKTAG('l','p','c','J') },
    { CODEC_ID_RA_288, MKTAG('2','8','_','8') },
    { CODEC_ID_COOK,   MKTAG('c','o','o','k') },
    { CODEC_ID_ATRAC3, MKTAG('a','t','r','c') },
    { CODEC_ID_SIPR,   MKTAG('s','i','p','r') },
    { CODEC_ID_AAC,    MKTAG('r','a','a','c') },
    { CODEC_ID_AAC,    MKTAG('r','a','c','p') },
    { CODEC_ID_NONE },
};

Appendix E: RealMedia File Format (RMFF) Reference 
    The Helix architecture supports RealMedia File Format (RMFF), which enables Helix to deliver high- quality multimedia content over a variety of network bandwidths. Third-party developers can convert their media formats into RMFF, enabling Helix Universal Server to deliver the files to RealPlayer or other applications built with the Helix Client and Server Software Development Kit. Third-party developers can thereby use Helix to transport content over the Internet to their own applications. 
    RealMedia File Format is a standard tagged file format that uses four-character codes to identify file elements. These codes are 32-bit, represented by a sequence of one to four ASCII alphanumeric characters, padded on the right with space characters. The data type for four-character codes is FOURCC. Use the HX_FOURCC macro to convert four characters into a four-character code. 
    The basic building block of a RealMedia File is a chunk , which is a logical unit of data, such as a stream header or a packet of data. Each chunk contains the following fields: 
Four-character code specifying the chunk identifier 
32-bit value specifying the size of the data member in the chunk
Blob of opaque chunk data 
    Depending on its type, a top-level chunk can contain subobjects. This document describes the tagged chunks contained in RMFF, as well as the format of the data stored in each type of tagged chunk. 
Tagged File Formats 

RealMedia File Format organizes tagged chunks into a header section, a data section, and an index section. The organization of these tagged chunks is shown in the following figure. 
Sections of a RealMedia File 

Header Section 
    Because RMFF is a tagged file format, the order of the chunks is not explicit, except that the RealMedia File Header must be the first chunk in the file. However, most applications write the standard headers into the file's header section. The following chunks are typically found in the header section of RMFF: 
RealMedia File Header (this must be the first chunk of the file) Properties Header Media Properties Header Content Description Header 
After the RealMedia File Header object, the other headers may appear in any order. All headers are required except the Index Header. The following sections describe the individual header objects. 
RealMedia File Header 
    Each RealMedia file begins with the RealMedia File Header, which identifies the file as RMFF. There is only one RealMedia File Header in a RealMedia file. Because the contents of the RealMedia File Header may change with different versions of RMFF, the header structure supports an object version field for determining what additional fields exists. The following pseudo-structure describes the RealMedia File Header: 
RealMedia_File_Header
{
  UINT32    object_id;
  UINT32    size;
  UINT16    object_version
 ;

  if ((object_version == 0) || (object_version == 1))
  {
    UINT32   file_version;
    UINT32   num_headers;
  }
}
The RealMedia File Header contains the following fields: 
object_id The unique object ID for a RealMedia File (.RMF ). All RealMedia files begin with this identifier. The size of this member is 32 bits. size The size of the RealMedia header section in bytes. The size of this member is 32 bits. object_version The version of the RealMedia File Header object. All files created according to this specification have an object_version number of 0 (zero) or 1. The size of this member is 16 bits. file_version The version of the RealMedia file. The Helix Client and Server SDK only covers files with a file version of either 0 (zero) or 1. This member is present on all RealMedia_File_Header objects with an object_version of 0 (zero) or 1. The size of this member is 32 bits. num_headers The number of headers in the header section that follow the RealMedia File Header. This member is present on all RealMedia_File_Header objects with an object_version of 0 (zero) or 1. The size of this member is 32 bits. 
Properties Header 
The Properties Header describes the general media properties of the RealMedia File. Components of the RealMedia system use this object to configure themselves for handling the data in the RealMedia file or stream. There is only one Properties Header in a RealMedia file. The following pseudo-structure describes the Properties header: 
Properties
{
  UINT32    object_id;
  UINT32    size;
  UINT16    object_version;

  if (object_version == 0)
  {
    UINT32   max_bit_rate;
    UINT32   avg_bit_rate;
    UINT32   max_packet_size;
    UINT32   avg_packet_size;
    UINT32   num_packets;
    UINT32   duration;
    UINT32   preroll;
    UINT32   index_offset;
    UINT32   data_offset;
    UINT16   num_streams;
    UINT16   flags;
  }
}
The Properties Header contains the following fields: 
object_id The unique object ID for a Properties Header ('PROP'). The size of this member is 32 bits. size The 32-bit size of the Properties Header in bytes. The size of this member is 32 bits. object_version The version of the RealMedia File Header object. All files created according to this specification have an object_version number of 0 (zero). The size of this member is 16 bits. max_bit_rate The maximum bit rate required to deliver this file over a network. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. avg_bit_rate The average bit rate required to deliver this file over a network. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. max_packet_size The largest packet size (in bytes) in the media data. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. avg_packet_size The average packet size (in bytes) in the media data. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. num_packets The number of packets in the media data. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. duration The duration of the file in milliseconds. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. preroll The number of milliseconds to prebuffer before starting playback. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. index_offset The offset in bytes from the start of the file to the start of the index header object. This value can be 0 (zero), which indicates that no index chunks are present in this file. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. data_offset The offset in bytes from the start of the file to the start of the Data Section. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 32 bits. 
Note: There can be a number of Data_Chunk_Headers in a RealMedia file. The data_offset value specifies the offset in bytes to the first Data_Chunk_Header. The offsets to the other Data_Chunk_Headers can be derived from the next_data_header field in a Data_Chunk_Header. 
num_streams The total number of media properties headers in the main headers section. This member is present on all Properties objects with an object_version of 0 (zero). The size of this member is 16 bits. flags Bit mask containing information about this file. The following bits carry informationall of the rest should be zero: BitFlagDescription 0Save_EnabledIf 1, clients are allowed to save this file to disk. 1Perfect_PlayIf 1, clients are instructed to use extra buffering. 2LIveIf 1, these streams are from a live broadcast. 
The size of this member is 16 bits. 
Media Properties Header 
    The Media Properties Header describes the specific media properties of each stream in a RealMedia file. Components of the RealMedia system use this object to configure themselves for handling the media data in each stream. There is one Media Properties Header for each media stream in a RealMedia file. The following pseudo-structure describes the Media Properties header: 
Media_Properties
{
  UINT32     object_id;
  UINT32     size;
  UINT16     object_version;

  if (object_version == 0)
  {
    UINT16                      stream_number;
    UINT32                      max_bit_rate;
    UINT32                      avg_bit_rate;
    UINT32                      max_packet_size;
    UINT32                      avg_packet_size;
    UINT32                      start_time;
    UINT32                      preroll;
    UINT32                      duration;
    UINT8                       stream_name_size;
    UINT8[stream_name_size]     stream_name;
    UINT8                       mime_type_size;
    UINT8[mime_type_size]       mime_type;
    UINT32                      type_specific_len;
    UINT8[type_specific_len]    type_specific_data;
  }
}
The Media Properties Header contains the following members: 
object_id The unique object ID for a Media Properties Header ("MDPR"). The size of this member is 32 bits. size The size of the Media Properties Header in bytes. The size of this member is 32 bits. object_version The version of the Media Properties Header object. The size of this member is 16 bits. stream_number The stream_number (synchronization source identifier) is a unique value that identifies a physical stream. Every data packet that belongs to a physical stream contains the same STREAM_NUMBER . The STREAM_NUMBER enables a receiver of multiple physical streams to distinguish which packets belong to each physical stream. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. max_bit_rate The maximum bit rate required to deliver this stream over a network. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. avg_bit_rate The average bit rate required to deliver this stream over a network. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. max_packet_size The largest packet size (in bytes) in the stream of media data. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. avg_packet_size The average packet size (in bytes) in the stream of media data. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. start_time The time offset in milliseconds to add to the time stamp of each packet in a physical stream. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. preroll The time offset in milliseconds to subtract from the time stamp of each packet in a physical stream. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. duration The duration of the stream in milliseconds. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. stream_name_size The length of the following stream_name member in bytes. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 8 bits. stream_name A nonunique alias or name for the stream. This member is present on all MediaProperties objects with an object_version of 0 (zero). This size of this member is variable. mime_type_size The length of the following mime_type field in bytes. This member is present on all MediaProperties objects with an object_version of 0 (zero). This size of this member is 8 bits. mime_type A nonunique MIME style type/subtype string for data associated with the stream. This member is present on all MediaProperties objects with an object_version of 0 (zero). This size of this member is variable. type_specific_len The length of the following type_specific_data in bytes. The type_specific_data is typically used by the data type renderer to initialize itself in order to process the physical stream. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is 32 bits. type_specific_data The type_specific_data is typically used by the data type renderer to initialize itself in order to process the physical stream. This member is present on all MediaProperties objects with an object_version of 0 (zero). The size of this member is variable. 
Logical Stream Organization 
    A RealMedia file can contain a higher-level grouping of physical streams. This grouping is called a logical stream. Logical streams contain the following information: 
Identifies which physical streams are grouped together into a logical stream. Contains name value properties that can be used to idnetify properties of the logical stream. (such as language, packet grouping, and so on.) 
A logical stream is represented with a Media Properties Header. The mime type of the physical stream is preceeded with "logical- ". For example, the mime type for an ASM-compatible RealAudio stream is audio/x-pn-multirate-realaudio . A logical stream consisting of a set of RealAudio physical streams would therefore have the mime type logical-audio/x-pn-multirate-realaudio . An example of a logical stream is shown in the following figure.
Logical Stream Organization 

In this example there is one logical stream, one low bit rate audio stream and one high bit rate audio stream. This results in a RealMedia file with three Media Property Headers and three data sections. The type_specific_data field of the logical stream's Media Property Header contains a LogicalStream structure. This structure contains all of the information required to interpret the logical stream and its collection of physical streams. The structure refers to the low bit rate and high bit rate audio streams. The LogicalStream structure also contains the data_offset s to the start of the data section for each physical stream. 
The logical stream number assigned to the logical stream is determined from the stream_number field in the Media Properties Header. 
There is also one special logical stream of MIME type "logical-fileinfo " containing information about the entire file. There should only be one media header with this type. Behavior of players and editing tools is undefined if you have more than one. 
The ASM rules contained in the logical-fileinfo stream are used to define precisely how bandwidth will be divided between the streams in the file. The logical-fileinfo may also contain a name-value pair that specifies which stream combinations should be served to older players. 
LogicalStream Structure 
The following sample shows the LogicalStream structure: 
LogicalStream
{
  ULONG32 size;
  UINT16       object_version;

  if (object_version == 0)
  {
    UINT16  num_physical_streams;
    UINT16     physical_stream_numbers[num_physical_streams];
    ULONG32   data_offsets[num_physical_streams];
    UINT16       num_rules;
    UINT16        rule_to_physical_stream_number_map[num_rules];
    UINT16    num_properties;
    NameValueProperty        properties[num_properties];
  }
};
The LogicalStream structure contains the following fields: 
size The size of the LogicalStream structure in bytes. The size of this structure member is 32 bits. object_version The version of the LogicalStream structure. The size of this structure member is 16 bits. num_physical_streams The number of physical streams that make up this logical stream. The physical stream numbers are stored in a list immediately following this field. These physical stream numbers refer to the stream_number field found in the Media Properties Object for each physical stream belonging to this logical stream. The size of this structure member is 16 bits physical_stream_numbers[] The list of physical stream numbers that comprise this logical stream. The size of this structure member is variable. data_offsets[] The list of data offsets indicating the start of the data section for each physical stream. The size of this structure member is variable. num_rules The number of ASM rules for the logical stream. Each physical stream in the logical stream has at least one ASM rule associated with it or it will never get played. The mapping of ASM rule numbers to physical stream numbers is stored in a list immediately following this member. These physical stream numbers refer to the stream_number field found in the Media Properties Object for each physical stream belonging to this logical stream. The size of this structure member is 16 bits. rule_to_physical_stream_map[] The list of physical stream numbers that map to each rule. Each entry in the map corresponds to a 0-based rule number. The value in each entry is set to the physical stream number for the rule. For example: 
rule_to_physical_stream_map[0] = 5
This example means physical stream 5 corresponds to rule 0. All of the ASM rules referenced by this array are stored in the first name-value pair of this logical stream which must be called "ASMRuleBook" and be of type "string". Each rule is separated by a semicolon. 
The size of this structure member is variable. 
num_properties The number of NameValueProperty structures contained in this structure. These name/value structures can be used to identify properties of this logical stream (for example, language). The size of this structure member is 16 bits. properties[] The list of NameValueProperty structures (see NameValueProperty Structure below for more details). As mentionied above, it is required that the first name-value pair be a string named "ASMRuleBook" and contain the ASM rules for this logical stream. The size of this structure member is variable. 
NameValueProperty Structure 
The following sample shows the NameValueProperty structure: 
NameValueProperty
{
  ULONG32             size;
  UINT16               object_version;

  if (object_version == 0)
  {
    UINT8   name_length;
    UINT8       name[namd_length];
    INT32         type;
    UINT16     value_length;
    UINT8      value_data[value_length];
  }
}
The NameValueProperty structure contains the following fields: 
size The size of the NameValueProperty structure in bytes. The size of this structure member is 32 bits. object_version The version of the NameValueProperty structure. The size of this structure member is 16 bits. name_length The length of the name data. The size of this structure member is 8 bits. name[] The name string data. The size of this structure member is 8 bits. type The type of the value data. This member can take on one of three values (any other value is undefined), as shown in the following table: typeDescriptionvalue_length 032-bit unsigned integer property4 1buffervariable 2stringvariable 
The size of this structure member is 32 bits. 
value_length The length of the value data. The size of this structure member is 16 bits. value_data[] The value data. The size of this structure member is 8 bits. 
Content Description Header 
    The Content Description Header contains the title, author, copyright, and comments information for the RealMedia file. All text data is in ASCII format. The following pseudo-structure describes the Content Description Header: 
Content_Description
{
  UINT32     object_id;
  UINT32     size;
  UINT16      object_version
 ;

  if (object_version == 0)
  {
    UINT16    title_len;
    UINT8[title_len]  title;
    UINT16    author_len;
    UINT8[author_len]  author;
    UINT16    copyright_len;
    UINT8[copyright_len]  copyright;
    UINT16    comment_len;
    UINT8[comment_len]  comment;
  }
}
The Content Description Header contains the following fields: 
object_id The unique object ID for the Content Description Header ("CONT"). The size of this member is 32 bits. size The size of the Content Description Header in bytes. The size of this member is 32 bits. object_version The version of the Content Description Header object. The size of this member is 16 bits. title_len The length of the title data in bytes. Note that the title data is not null-terminated. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is 16 bits. title An array of ASCII characters that represents the title information for the RealMedia file. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is variable. author_len The length of the author data in bytes. Note that the author data is not null-terminated. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is 16 bits. author An array of ASCII characters that represents the author information for the RealMedia file. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is variable. copyright_len The length of the copyright data in bytes. Note that the copyright data is not null-terminated. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is 16 bits copyright An array of ASCII characters that represents the copyright information for the RealMedia file. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is variable. comment_len The length of the comment data in bytes. Note that the comment data is not null-terminated. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is 16 bits. comment An array of ASCII characters that represents the comment information for the RealMedia file. This member is present on all Content Description Header objects with an object_version of 0 (zero). The size of this member is variable. 
Data Section 
    The data section of the RealMedia file consists of a Data Section Header that describes the contents of the data section, followed by a series of interleaved media data packets. Note that the size field of the Data Chunk Header is the size of the entire data chunk, including the media data packets. 
Data Chunk Header 
    The Data Chunk Header marks the start of the data chunk. There is usually only one data chunk in a RealMedia file; however, for extremely large files, there may be multiple data chunks. The following pseudostructure describes the Data chunk header: 
Data_Chunk_Header
{
  UINT32     object_id;
  UINT32     size;
  UINT16      object_version;

  if (object_version == 0)
  {
    UINT32    num_packets; 
    UINT32    next_data_header;
  }
}
The Data Chunk Header contains the following fields: 
object_id The unique object ID for the Data Chunk Header ('DATA'). The size of this member is 32 bits. size The size of the Data Chunk in bytes. The size includes the size of the header plus the size of all the packets in the data chunk. The size of this member is 32 bits. object_version The version of the Data Chunk Header object. The size of this member is 16 bits. num_packets Number of packets in the data chunk. This member is present on all Data Chunk Header objects with an object_version of 0 (zero). The size of this member is 32 bits. next_data_header Offset from start of file to the next data chunk. A non-zero value refers to the file offset of the next data chunk. A value of zero means there are no more data chunks in this file. This field is not typically used. This member is present on all Data Chunk Header objects with an object_version of 0 (zero). The size of this member is 32 bits. 
Data Packet Header 
    Following a data chunk header is num_packet data packets. These packets can all be from the same stream, or packets from different streams can follow one another. These packets, whether from the same stream or from different streams, should have an increasing value of timestamp. That is, the timestamp of a packet should be greater than or equal to the timestamp of the previous packet in the file. 
The following pseudo-structure describes the details of the packet: 
Media_Packet_Header
{
  UINT16                object_version;

  if ((object_version == 0) || (object_version == 1))
  {
    UINT16        length;
    UINT16        stream_number;
    UINT32        timestamp;
    if (object_version == 0)
    {
      UINT8        packet_group;
      UINT8        flags;
    }
    else if (object_version == 1)
    {
      UINT16        asm_rule;
      UINT8          asm_flags;
    }

    UINT8[length]        data;
  }
  else
  {
    StreamDone();
  }
}
The Media Packet Header contains the following fields: 
object_version The version of the Media Packet Header object. The size of this member is 16 bits. length The length of the packet in bytes. This member is present on all Media Packet Header objects with an object_version of 0 (zero) or 1. The size of this member is 16 bits. stream_number The 16-bit alias used to associate data packets with their associated Media Properties Header. This member is present on all Media Packet Header objects with an object_version of 0 (zero) or 1. The size of this member is 16 bits. timeStamp The time stamp of the packet in milliseconds This member is present on all Media Packet Header objects with an object_version of 0 (zero) or 1. The size of this member is 32 bits. packet_group The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero). This member is present on all Media Packet Header objects with an object_version of 0 (zero). The size of this member is 8 bits. flags Flags describing the properties of the packet. The following flags are defined: HX_RELIABLE_FLAG 
If this flag is set, the packet is delivered reliably. 
HX_KEYFRAME_FLAG 
If this flag is set, the packet is part of a key frame or in some way marks a boundary in your data stream. 
This member is present on all Media Packet Header objects with an object_version of 0 (zero). The size of this member is 8 bits. 
asm_rule The ASM rule assigned to this packet. Only present if object_version equals 1. The size of this member is 16 bits. asm_flags Contains HX_ flags that dictate stream switching points. Only present if object_version equals 1. The size of this member is 8 bits. data The application-specific media data. This member is present on all Media Packet Header objects with an object_version of 0 (zero) or 1. The size of this member is variable. 
Index Section 
    The index section of the RealMedia file consists of a Index Chunk Header that describes the contents of the index section, followed by a series of index records. Note that the size field of the Index Chunk Header is the size of the entire index chunk, including the index records. 
Index Section Header 
    The Index Chunk Header marks the start of the index chunk. There is usually one index chunk per stream in a RealMedia file. The following pseudo-structure describes the Index chunk header. 
Index_Chunk_Header
{
  u_int32     object_id;
  u_int32     size;
  u_int16      object_version
 ;

  if (object_version == 0)
  {
    u_int32     num_indices;
    u_int16     stream_number;
    u_int32     next_index_header;
  }
}
The Index Chunk Header contains the following fields: 
object_id The unique object ID for the Index Chunk Header ("INDX"). The size of this member is 32 bits. size The size of the Index Chunk in bytes. The size of this member is 32 bits. object_version The version of the Index Chunk Header object. The size of this member is 16 bits. num_indices Number of index records in the index chunk. This member is present on all Index Chunk Header objects with an object_version of 0 (zero). The size of this member is 32 bits stream_number The stream number for which the index records in this index chunk are associated. This member is present on all Index Chunk Header objects with an object_version of 0 (zero). The size of this member is 16 bits. next_index_header Offset from start of file to the next index chunk. This member enables RealMedia file format readers to find all the index chunks quickly. A value of zero for this member indicates there are no more index headers in this file. This member is present on all Index Chunk Header objects with an object_version of 0 (zero). The size of this member is 32 bits. 
Index Record 
    The index section of a RealMedia file consists of a series of index record objects. Each index record contains information for quickly finding a packet of a particular time stamp for a physical stream. The following pseudo-structure describes the details of each index record: 
IndexRecord
{
  UINT16   object_version;

  if (object_version == 0)
  {
    u_int32  timestamp;
    u_int32  offset;
    u_int32   packet_count_for_this_packet;
  }
}
An Index Record contains the following fields: 
object_version The version of the Index Record object. The size of this member is 16 bits. timestamp The time stamp (in milliseconds) associated with this record. This member is present on all Index Record objects with an object_version of 0 (zero). The size of this member is 32 bits. offset The offset from the start of the file at which this packet can be found. This member is present on all Index Record objects with an object_version of 0 (zero). The size of this member is 32 bits. packet_count_for_this_packet The packet number of the packet for this record. This is the same number of packets that would have been seen had the file been played from the beginning to this point. This member is present on all Index Record objects with an object_version of 0 (zero). The size of this member is 32 bits. 
Metadata Section 
    The metadata section of the RealMedia file consists of a tag containing a set of named metadata properties that describe the media file. These properties can be text, integers, or any binary data. The tag is preceded by a header that identifies the size of the entire metadata section. Following the tag, the footer identifies the size of the tag. Since the metadata section is found at the end of the file, the footer can be used to expedite seeking backwards. At the end of the metadata section, and the file itself, is an ID3v1 tag. 
Metadata Section Header 
    The Metadata Section Header marks the start of the metadata section. There is one metadata section in a RealMedia file and it is expected to be at the end of the file. The following structure describes the Metadata section header: 
MetadataSectionHeader
{
  u_int32        object_id;
  u_int32        size;
}
The Metadata Section Header contains the following fields: 
object_id The unique object ID for the Metadata Section Header ("RMMD"). The size of this member is 32 bits. size The size of the full metadata section in bytes. The size of this member is 32 bits. 
Metadata Tag 
    The metadata tag of a RealMedia file consists of a series of properties. The properties are represented as a tree hierarchy with one unnamed root property. Each property contains a type and value, as well as multiple (optional) sub-properties. The following structure describes the details of the metadata tag: 
MetadataTag
{
  u_int32        object_id;
  u_int32        object_version;
  u_int8[]        properties;
}
The Metadata Tag contains the following fields: 
object_id The unique object ID for the Metadata Tag ("RJMD"). The size of this member is 32 bits. object_version The version of the Metadata Tag. The size of this member is 32 bits. properties[] The MetadataProperty structure that makes up the metadata tag (see "Metadata Property Structure" for more details). As mentioned above, the properties will be represented as one unnamed root metadata property with multiple sub-properties, each with their own optional sub-properties. These will be nested, as in a tree. 
Metadata Property Structure 
The following sample describes the details of the MetadataProperty structure: 
MetadataProperty
{
  u_int32        size;
  u_int32        type;
  u_int32        flags;
  u_int32        value_offset;
  u_int32        subproperties_offset;
  u_int32        num_subproperties;
  u_int32        name_length;
  u_int8[name_length]    name;
  u_int32        value_length;
  u_int8[value_length]    value;
  PropListEntry[num_subproperties]    subproperties_list;
  MetadataProperty[num_subproperties]    subproperties;
}
The MetadataProperty structure contains the following fields: 
size The size of the MetadataProperty structure in bytes. The size of this member is 32 bits. type The type of the value data. The data in the value array can be one of the following types: MPT_TEXT 
The value is string data. 
MPT_TEXTLIST 
The value is a separated list of strings, separator specified as sub-property/type descriptor. 
MPT_FLAG 
The value is a boolean flageither 1 byte or 4 bytes, check size value. 
MPT_ULONG 
The value is a four-byte integer. 
MPT_BINARY 
The value is a byte stream. 
MPT_URL 
The value is string data. 
MPT_DATE 
The value is a string representation of the date in the form: YYYYmmDDHHMMSS (m = month, M = minutes). 
MPT_FILENAME 
The value is string data. 
MPT_GROUPING 
This property has subproperties, but its own value is empty. 
MPT_REFERENCE 
The value is a large buffer of data, use sub-properties/type descriptors to identify mime-type. 
The size of this member is 32 bits. 
flags Flags describing the property. The following flags are defined these can be used in combination: MPT_READONLY 
Read only, cannot be modified. 
MPT_PRIVATE 
Private, do not expose to users. 
MPT_TYPE_DESCRIPTOR 
Type descriptor used to further define type of value. 
The size of this member is 32 bits. 
value_offset The offset to the value_length , relative to the beginning of the MetadataProperty structure. The size of this member is 32 bits. subproperties_offset The offset to the subproperties_list , relative to the beginning of the MetadataProperty structure. The size of this member is 32 bits. num_subproperties The number of subproperties for this MetadataProperty structure. The size of this member is 32 bits. name_length The length of the name data, including the null-terminator. The size of this member is 32 bits. name[] The name of the property (string data). The size of this member is designated by name_length . value_length The length of the value data. The size of this member is 32 bits. value[] The value of the property (data depends on the type specified for the property). The size of this member is designated by value_length . subproperties_list[] The list of PropListEntry structures. The PropListEntry structure identifies the offset for each property (see "PropListEntry Structure" for more details. The size of this member is num_subproperties * sizeof(PropListEntry). subproperties[] The sub-properties. Each sub-property is a MetadataProperty structure with its own size, name, value, sub-properties, and so on. The size of this member is variable. 
PropListEntry Structure 
The following sample describes the details of the PropListEntry structure: 
PropListEntry
{
  u_int32        offset;
  u_int32        num_props_for_name;
}
The PropListEntry structure contains the following fields: 
offset The offset for this indexed sub-property, relative to the beginning of the containing MetadataProperty . The size of this member is 32 bits. num_props_for_name The number of sub-properties that share the same name. For example, a lyrics property could have multiple versions as differentiated by the language sub-property type descriptor. The size of this member is 32 bits. 
Metadata Section Footer 
The metadata section footer marks the end of the metadata section of a RealMedia file. The metadata section footer contains the size of the metadata tag. Since the metadata section is at the end of the file, the section footer lies a fixed offset of 140 bytes from the end of the file. The size of the metadata tag enables a file reader to quickly locate the beginning of the metadata tag relative to the end of the file. The following structure describes the Metadata section footer. 
MetadataSectionFooter
{
  u_int32        object_id;
  u_int32        object_version;
  u_int32        size;
}
The MetadataSectionFooter contains the following fields: 
object_id The unique object ID for the Metadata Section Footer ("RMJE"). The size of this member is 32 bits. object_version The version of the metadata tag. The size of this member is 32 bits. size The size of the preceding metadata tag. The size of this member is 32 bits. 
ID3v1 Tag 
The ID3v1 Tag is at the end of the metadata section and is expected to be at the end of the entire file. It is a fixed size128 bytesand begins with the characters "TAG". Futher information about the informal ID3v1 standard can be found at http://id3.org/id3v1.html . 
What is ID3 (v1)?
The audio format MPEG layer I, layer II and layer III (MP3) has no native way of saving information about the contents, except for some simple yes/no parameters like "private", "copyrighted" and "original home" (meaning this is the original file and not a copy). A solution to this problem was introduced with the program "Studio3" by Eric Kemp alias NamkraD in 1996. By adding a small chunk of extra data in the end of the file one could get the MP3 file to carry information about the audio and not just the audio itself. 

The placement of the tag, as the data was called, was probably chosen as there were little chance that it should disturb decoders. In order to make it easy to detect a fixed size of 128 bytes was chosen. The tag has the following layout (as hinted by the scheme to the right): 
Internal layout of an ID3v1 tagged file. 

Song Title 
30 characters 
Artist 
30 characters 
Album 
30 characters 
Year 
4 characters 
Comment 
30 characters 
Genre 
1 byte 
If you one sum the the size of all these fields we see that 30+30+30+4+30+1 equals 125 bytes and not 128 bytes. The missing three bytes can be found at the very beginning of the tag, before the song title. These three bytes are always "TAG" and is the identification that this is indeed a ID3 tag. The easiest way to find a ID3v1/1.1 tag is to look for the word "TAG" 128 bytes from the end of a file. 
As all artists doesn't have a 30 character name it is said that if there is some bytes left after the information is entered in the field, those bytes should be fille with the binary value 0. You might also think that you cannot write that much in the genre field, being one byte big, but it is more clever than that. The byte value you enter in the genre field corresponds to a value in a predefined list. The list that Eric Kemp created had 80 entries, ranging from 0 to 79. 
What is ID3v1.1?
ID3v1 may well be easy to implement for programmers, but it sure is frustrating for those with their own, creative ideas. Since the ID3v1 tag had a fixed size and no space marked "Reserved for future use", there isn't really room for that much improvement, if you want to maintain compatibility with existing software. 

One who found a way out was Michael Mutschler who made a quite clever improvement on ID3v1. Since all non-filled fields must be padded with zeroed bytes its a good assumption that all ID3v1 readers will stop reading the field when they encounter a zeroed byte. If the second last byte of a field is zeroed and the last one isn't we have an extra byte to fill with information. As the comments field is to short to write anything useful in the ID3v1.1 standard declares that this field should be 28 characters, that the next byte always should be zero and that the last byte before the genre byte should contain which track on the CD this music comes from. 
Internal layout of an ID3v1.1 tagged file.