[vorbis-dev] RE: File Formats history [was WAVE Format info

[Chris Wolf]

>WAVE and AVI are little-endian variants of IFF that MS/IBM originally 
>called RIFF.
>
>http://www.saettler.com/RIFFMCI/riffmci.html
>

Thank you.  This is the definitive specification I've been searching for. The reason I didn't
find it sooner is that all the pseudo-specs that point to it were referencing the RTF 
version of the file ("RIFFMCI.RTF").

Unfortunately, this document does not mention the extended "fmt" chunk types,
which would lead some people to believe that "fmt" chunks can only be 16 bytes.

On the other hand, this document was created in 1991, as evidenced by the following 
references:

http://ulita.ms.mff.cuni.cz/pub/techdoc/formats/Riffmci.txt
http://aixdoc.physik.uni-augsburg.de/doc_link/en_US/a_doc_lib/ultimdia/ultiprgd/RIFFFileAcc.htm

An important thing to note is that this document (riffmci) establishes the fact that Microsoft
uses 'C' data structures and typedefs to document file formats

To quote from that document:

>A structure defined using C syntax. This can be used instead of a sequence of labels if a C header 
>(include) file is available that defines the structure. The label used to refer to the structure should be
>the same as the structure's typedef name. 
>
>Wherever possible, the types used in the structure should be the types listed in the following section, 
>"Atomic Labels," because these types are more portable than C types such as int. The structure fields 
>are assumed to be present in the file in the order given, with no padding or forced alignment.

Notice the last sentence of this quotation; this clearly indicates that they are intending
to use structures to specify file layout. Also, the phrase "no padding or forced alignment" indicates
that such use of 'C' data structures is a machine portable representation.

In addition, this document has a table of "atomic labels" (corresponding to typedefs)
of primitive data types used to document the field names of chunk definitions,
which unambiguously specifies the primitive types in terms of their size and endianness.

In other words, this is a completely portable way to specify the file format.

Now the issue of extended "fmt" chunks.  Having established the fact that Microsoft uses
'C' data structures to specify portable file formats, the documentation I posted earlier
introduces the WAVEFORMATEX structure which documents a new "fmt" chunk which
is of size 18 bytes -- a valid size for "fmt" chunks. (we should not be emitting an invalid
chunk warning)

Fortunately, there is a document called RIFFNEW.doc, which Vitaly posted earlier, also supports this.
It can be gotten from:
http://support.microsoft.com/support/kb/articles/Q120/2/53.asp

It has a self extracting archive called "mdrk.exe" (containing RIFFNEW.DOC), 
which some of the pseudo-specs point to.

This document is dated April, 1994.  This explains why some of the pseudo-specs
claim that a "fmt" chunk must be 16 bytes -- they are based on the 1991 document,
while other pseudo-specs might mention the newer "fmt" chunk definitions -- they are
referencing the 1994 document, and perhaps even newer documentation, such
as:

http://www.microsoft.com/HWDEV/audio/multichaud.htm
(as posted by Stan)
which introduces a 36 byte "fmt" chunk called WAVEFORMATEXTENDED
this reference is dated August 1999, so I would assume that not many pseudo-specs
would be mentioning it.

So taking these three referrences (riffmci, riffnew and the above documentation
of WAVEFORMATEXTENDED, from Microsoft) together, I think we have as complete
a specification one could wish for.

Chris Wolf

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.