home *** CD-ROM | disk | FTP | other *** search
/ Encyclopedia of Graphics File Formats Companion / GFF_CD.ISO / formats / msriff / spec / ms_riff.txt < prev    next >
Text File  |  1994-06-01  |  59KB  |  1,514 lines
  1. Microsoft Multimedia Standards Update
  2.      
  3. New Multimedia Data Types and Data Techniques
  4.      
  5. July 29, 1992
  6. Revision: 1.0.97
  7.      
  8.      
  9. Information in this document is subject to change without notice and does
  10. not represent a commitment on the part of Microsoft Corporation.
  11. The software described in this document is furnished under license
  12. agreement or nondisclosure agreement.  The software may be used or
  13. copied only in the accordance with the terms of the agreement.  It is
  14. against the law to copy the software on any medium except as specifically
  15. allowed in the license or nondisclosure agreement.
  16.      
  17. No part of this document may be reproduced or transmitted in any form or 
  18. by any means, electronic or mechanical, including photocopying
  19. and recording, for any purpose without the express written permission of
  20. Microsoft Corporation.
  21.      
  22. This standards update is for informational purposes only.  MICROSOFT MAKES
  23. NO WARRANTIES, EXPRESSED OR IMPLIED IN THIS STANDARDS UPDATE.
  24.     
  25. Microsoft, MS, MS-DOS, XENIX and the Microsoft logo are registered
  26. trademarks and Windows is a trademark of Microsoft Corporation.
  27. Other trade names mentioned herein are trademarks of their respective
  28. manufacturers.
  29.      
  30. Copyright 1992, Microsoft Corporation.  All Rights Reserved.
  31.      
  32.      
  33. Table of Contents
  34.     
  35. Overview                                      3
  36. Where to Look for Information                 3
  37. Intended Audience                             3
  38. Versions of this Document                     4
  39. Questions?                                    4
  40. New Chunks                                    5
  41. Display Chunk                                 5
  42. JUNK (Filler) Chunk                           5
  43. PAD (Filler) Chunk                            5
  44. Wave RIFF form sub-Chunks                     7
  45. Fact Chunk                                    7
  46. Cue Points Chunk                              7
  47. Examples of File Position Values              8
  48. Playlist Chunk                                9
  49. Associated Data Chunk                        10
  50. Label and Note Information                   10
  51. Text with Data Length Information            11
  52. New Forms                                    11
  53. New WAVE Types                               12
  54. Fact Chunk                                   12
  55. EXTWAVEFORMAT                                12
  56. Microsoft ADPCM                              13
  57. Fact Chunk                                   13
  58. WAVE Format Header                           13
  59. Block                                        14
  60. Data                                         14
  61. Padding                                      15
  62. ADPCM Algorithm                              15
  63. Decoding                                     15
  64. Encoding                                     16
  65. Sample C Code                                17
  66. CVSD Wave Type                               18
  67. Fact Chunk                                   18
  68. WAVE Format Header                           18
  69. CCITT Standard Companded Wave Types          19
  70. Fact Chunk                                   19
  71. WAVE Format Header                           19
  72. OKI ADPCM Wave Types                         20
  73. Fact Chunk                                   20
  74. WAVE Format Header                           20
  75. DVI ADPCM Wave Type                          21
  76. Fact Chunk                                   21
  77. WAVE Format Header                           21
  78. Digispeech Wave Types                        22
  79. Fact Chunk                                   22
  80. WAVE Format Header                           22
  81. Unknown Wave Type                            23
  82. Fact Chunk                                   23
  83. WAVE Format Header                           23
  84. DIB File Additions                           24
  85. RGB555 and RGB565 DIB Formats                24
  86. BITMAPINFOHEADER Structure
  87.    for RGB555 and RGB565 DIBs                24
  88. RGB555 and RGB565 Pixel Encoding             25
  89. RIFF Clipboard Formats                       26
  90. CF_RIFF                                      26
  91. CF_WAVE                                      26
  92. Registered Clipboard Formats                 26
  93. Encoding Language of Text                    27
  94. Country Codes                                27
  95. Language and Dialect Codes                   28
  96.      
  97.      
  98. Overview
  99.      
  100. This standards update presents new and updated information for dealing with
  101. multimedia data under Microsoft Windows.  This document is also available 
  102. as part of the Multimedia Developer Registration Kit.
  103.  
  104. The MDRK is used to register multimedia data and ids as well as new MCI
  105. command sets.  This document is the result of companies requesting and 
  106. registering new data types.  This document builds on the standard
  107. RIFF documentation that is contained in:
  108.      
  109.      1. The Multimedia Development Kit (MDK) 1.0 Programmer's Reference
  110.  
  111.      2. The Windows 3.1 Software Development Kit (SDK)'s Multimedia
  112.                Programmer's Reference
  113.  
  114.      3. The Multimedia Programmer's Reference book from Microsoft Press
  115.      
  116. The RIFF file format is a standard published as a joint design document by
  117. IBM and Microsoft.  This standards document is Multimedia Programming 
  118. Interface and Data Specifications 1.0 published in August 1991.  The 
  119. first draft of this document was issued in November, 1990.  This 
  120. IBM/Microsoft document is available from the sources listed below.
  121.      
  122. This standards update assumes that the reader has read the concepts defined
  123. in these documents.
  124.      
  125. New RIFF file forms and chunks are defined in this document.  The new RIFF 
  126. forms and chunks defined here have been registered with Microsoft.  If you 
  127. want to register your own RIFF forms and chunks, please request a Multimedia 
  128. Developer Registration Kit by call (206) 936-8644 or writing to:
  129.      
  130.      Microsoft
  131.      Multimedia Product Management
  132.      One Microsoft Way
  133.      Redmond, WA 98052-6399
  134.      FAX: (206) 93MSFAX
  135.      
  136. In addition, techniques for dealing with multimedia data in the system,
  137. such as clipboard data, are defined in this document.
  138.      
  139.      
  140. Where to Look for Information
  141.      
  142. Current versions of this document as well as other technical update and
  143. technical notes and sample code are available from:
  144.      
  145.      1. CompuServe WINSDK forum
  146.      
  147.      2. Microsoft Multimedia BBS at (206) 936-4082 in the files library in 
  148.      the specs section in the RIFFNEW.ZIP file.  Sample code is available in 
  149.      the samples section and technical notes are available in the technote 
  150.      section.  BBS modem settings are 9600 baud, no parity, 8 data bits, 
  151.      1 stop bit.
  152.      
  153.      3. Via anonymous FTP on ftp.uu.net in the vendors\microsoft\multimedia
  154.      directory.  Sample code is in the samples directory and technical notes 
  155.      are in the technote directory.
  156.      
  157.      4.   Current versions of any document may be ordered (currently free) by
  158.      calling (206) 936-8644.
  159.      
  160.      
  161. Intended Audience
  162.      
  163. This document should be read by "multimedia producers" (as defined in the 
  164. Multimedia Authoring Guide) as well as programmers using all types of tools.  
  165. You should read this document after reading the base RIFF file format 
  166. definitions.
  167.      
  168.      
  169. Versions of this Document
  170.      
  171. This document is continually being updated and expanded.  Eventually the
  172. information presented in this document will be placed in the standard 
  173. reference for the RIFF and multimedia data standards from Microsoft, such 
  174. as the Multimedia Programmer's Reference from MS-Press.
  175.      
  176. When referring to standards defined in this document, please refer to the 
  177. data and version number printed on the cover page.
  178.      
  179. Versions of this document with the same version number are just expanded
  180. additions of the same information.  However, when the version number 
  181. changes, the information contained in the previous version will be moved 
  182. to the standard reference locations for RIFF and multimedia data standards.
  183.      
  184. Questions?
  185.      
  186. If you have questions, requests, or problems with this technical update,
  187. you should send your question to the address above.
  188.      
  189.      
  190. New Chunks
  191.      
  192. These new chunks have been defined for use in any RIFF form.
  193.      
  194.      
  195. Display Chunk
  196.      
  197. Added:    05/01/92
  198. Author:   Microsoft
  199.      
  200. A DISP chunk contains easily rendered and displayable objects associated
  201. with an instance of a more complex object in a RIFF form (e.g. sound file, 
  202. AVI movie).
  203.      
  204. A DISP chunk is defined as follows:
  205.      
  206. <DISP_ck>  ->  DISP( <type> <data> )
  207.      
  208. <type> is a DWORD (32 bit unsigned quantity in Intel format) that
  209. identifies <data> as one of the standard Windows clipboard formats 
  210. (CF_METAFILE, CF_DIB, CF_TEXT, etc.) as defined in windows.h.
  211.      
  212. The DISP chunk should be used as a direct child of the RIFF chunk so that
  213. any RIFF aware application can find it.  There can be multiple DISP chunks 
  214. with each containing different types of displayable data, but all 
  215. representative of the same object.  The DISP chunks should be stored
  216. in the file in order of preference (just as in the clipboard).
  217.      
  218. The DISP chunk is especially beneficial when representing OLE data within
  219. an application.  For example, when pasting a wave file into Excel, the 
  220. creating application can use the DISP chunk to associate an icon and a text 
  221. description to represent the embedded wave file.  This text should be
  222. short so that it can be easily displayed in menu bars and under icons.
  223.      
  224. Note: do not use a CF_TEXT for a description of the data.  Bibliographic
  225. data chunks will be added to support the standard MARC (Machine Readable 
  226. Cataloging) data.
  227.      
  228.      
  229. JUNK (Filler) Chunk
  230.      
  231. Added:    05/01/92
  232. Author:   IBM, Microsoft
  233.  
  234. A JUNK chunk represents , filler or outdated information. It contains no
  235. relevant data; it is a space filler of arbitrary size. The JUNK chunk is 
  236. defined as follows:
  237.      
  238. <JUNK chunk> ▌ JUNK( <filler> )
  239.      
  240. where <filler> contains random data.
  241.      
  242.      
  243. PAD (Filler) Chunk
  244.      
  245. Added:    07/15/92
  246. Author:   Microsoft
  247.  
  248. A PAD chunk represents padding. It contains no relevant data; it is a space
  249. filler of arbitrary size.  When duplicating the file, the copier should 
  250. maintain the padding of the PAD chunk.  Specifically, if the PAD chunk makes 
  251. the next chunk align on a 2K boundary in the physical file, then this 
  252. alignment should be preserved even if the size of the PAD chunk must change.  
  253. The PAD chunk is defined as follows:
  254.      
  255. <PAD chunk> ▌ PAD( <filler> )
  256.      
  257. where <filler> contains random data.
  258.      
  259.      
  260. Wave RIFF form sub-Chunks
  261.      
  262. Added:    05/01/92
  263. Author:   Microsoft, IBM
  264.      
  265. Most of the information in this section comes directly from the IBM/Microsoft 
  266. RIFF standard document.
  267.      
  268. The WAVE form is defined as follows. Programs must expect (and ignore) any
  269. unknown chunks encountered, as with all RIFF forms. However, <'fmt'-ck> 
  270. must always occur before <wave-data>, and both of these chunks are mandatory in a WAVE file.
  271.      
  272. <WAVE-form> ▌
  273.      RIFF( 'WAVE'   
  274.                <'fmt'-ck>                         // Format
  275.                [<fact-ck>]                        // Fact chunk
  276.                [<cue-ck>]                         // Cue points
  277.                [<playlist-ck>]                    // Playlist
  278.                [<assoc-data-list>]      // Associated data list
  279.                <wave-data>     )                  // Wave data
  280.      
  281. The WAVE chunks are described in the following sections.
  282.      
  283.      
  284. Fact Chunk
  285.      
  286. The <fact-ck>  stores file dependent information about the contents of the
  287. WAVE file. This chunk is defined as follows:
  288.      
  289. <fact-ck>  ->  fact( <dwSampleLength:DWORD> )
  290.      
  291. <dwSampleLength> represents the length of the data in samples.  The
  292. <nSamplesPerSec> field from the wave format header is used in conjunction 
  293. with the <dwSampleLength> field to determine the length of the data in seconds.
  294.      
  295. The fact chunk is required for all new WAVE formats. The chunk is not
  296. required for the standard WAVE_FORMAT_PCM files.
  297.      
  298. The fact chunk will be expanded to include any other information required
  299. by future WAVE formats. Added fields will appear following the <dwSampleLength> 
  300. field.  Applications can use the chunk size field to determine which fields 
  301. are present.
  302.      
  303.      
  304. Cue Points Chunk
  305.      
  306. The <cue-ck> cue-points chunk identifies a series of positions in the
  307. waveform data stream. The <cue-ck> is defined as follows:
  308.      
  309. <cue-ck> ▌          cue(      <dwCuePoints:DWORD>      // Count of cue points
  310.                                    <cue-point>... )    // Cue-point
  311. table
  312.      
  313. <cue-point> ▌       struct {
  314.                               DWORD  dwName; 
  315.                               DWORD  dwPosition;
  316.                               FOURCC fccChunk;
  317.                                    DWORD  dwChunkStart;
  318.                                    DWORD  dwBlockStart;     
  319.                                    DWORD  dwSampleOffset;
  320.                               }
  321.  
  322. The <cue-point> fields are as follows:
  323.      
  324.      Field               Description
  325.      
  326.      dwName              Specifies the cue point name. Each <cue-point> record
  327.                          must have a unique dwName field.
  328.      
  329.      dwPosition          Specifies the sample position of the cue point. This is
  330.                          the sequential sample number within the play order. See
  331.                          "Playlist Chunk," later in this document, for a
  332.                          discussion of the play order.
  333.      
  334.      fccChunk            Specifies the name or chunk ID of the chunk containing
  335.                          the cue point.
  336.      
  337.      dwChunkStart        Specifies the position of the start of the data chunk
  338.                          containing the cue point.  This should be zero if there
  339.                          is only one chunk containing data (as is currently
  340.                          always the case).
  341.      
  342.      dwBlockStart        Specifies the position of the start of the block
  343.                          containing the position.  This is the byte offset from
  344.                          the start of the data section of the chunk, not the
  345.                          chunk's FOURCC.
  346.      
  347.      dwSampleOffset      Specifies the sample offset of the cue point relative
  348.                          to the start of the block.
  349.      
  350.      
  351. Examples of File Position Values
  352.      
  353. The following table describes the <cue-point> field values for a WAVE file
  354. containing a single data chunk:
  355.      
  356.      Cue Point Location  Field          Value
  357.      
  358.      Within PCM data     fccChunk       FOURCC value `data'.
  359.      
  360.                          dwChunkStart   Zero value.
  361.      
  362.                          dwBlockStart   File position of the sample (nBlockAlign
  363.                                         aligned bytes) relative to the start of
  364.                                         the data section of the `data' chunk
  365.                                         (not the FOURCC).
  366.      
  367.                          dwSampleOffset Sample position of the cue point
  368.                                         relative to the start of the `data'
  369.                                         chunk.
  370.      
  371.      In all other `data' fccChunk       FOURCC value `data'.
  372.      chunks
  373.      
  374.                          dwChunkStart   Zero value.
  375.      
  376.                          dwBlockStart   File position of the enclosing block
  377.                                         relative to the start of the data
  378.                                         section of the `data' chunk (not the
  379.                                         FOURCC). The software can begin the      
  380.                                         decompression at this point.
  381.      
  382.                          dwSampleOffset Sample position of the cue point
  383.                                         relative to the start of the block.
  384.      
  385.      
  386. Playlist Chunk
  387.      
  388. The <playlist-ck> playlist chunk specifies a play order for a series of cue
  389. points. The <playlist-ck> is defined as follows:
  390.      
  391. <playlist-ck> ▌          plst(
  392.                               <dwSegments:DWORD>  // Count of play segments
  393.                               <play-segment>... ) // Play-segment table
  394.      
  395. <play-segment> ▌         struct {
  396.                                    DWORD dwName;
  397.                                    DWORD dwLength;
  398.                                    DWORD dwLoops;
  399.                               }
  400.      
  401. The <play-segment> fields are as follows:
  402.      
  403.      Field          Description
  404.      
  405.      dwName         Specifies the cue point name. This value must match one of
  406.                     the names listed in the <cue-ck> cue-point table.
  407.      
  408.      dwLength       Specifies the length of the section in samples.
  409.      
  410.      dwLoops        Specifies the number of times to play the section.
  411.      
  412.      
  413. Associated Data Chunk
  414.      
  415. The <assoc-data-list> associated data list provides the ability to attach
  416. information like labels to sections of the waveform data stream. The 
  417. <assoc-data-list> is defined as follows:
  418.      
  419. <assoc-data-list> ▌      LIST(     'adtl'
  420.                                            <labl-ck>   // Label
  421.                                            <note-ck>   // Note
  422.                                            <ltxt-ck> } // Text with data length
  423.      
  424. <labl-ck> ▌                   labl(   <dwName:DWORD>
  425.                                            <data:ZSTR> )
  426.      
  427. <note-ck> ▌                   note(     <dwName:DWORD>
  428.                                              <data:ZSTR> )  
  429.      
  430. <ltxt-ck> ▌                   ltxt(     <dwName:DWORD> 
  431.                                              <dwSampleLength:DWORD>   
  432.                                              <dwPurpose:DWORD>
  433.                                              <wCountry:WORD>
  434.                                              <wLanguage:WORD>
  435.                                              <wDialect:WORD>
  436.                                              <wCodePage:WORD>
  437.                                              <data:BYTE>... )
  438.      
  439.      
  440. Label and Note Information
  441.    
  442. The `labl' and `note' chunks have similar fields. The `labl' chunk contains
  443. a label, or title, to associate with a cue point. The ænoteÆ chunk contain
  444. s comment text for a cue point. The fields are as follows:
  445.      
  446.      Field          Description
  447.      
  448.      dwName         Specifies the cue point name.  This value must match one of
  449.                     the names listed in the <cue-ck> cue-point table.
  450.      
  451.      data           Specifies a NULL-terminated string containing a text label
  452.                     (for the `labl' chunk) or comment text (for the `note'
  453.                     chunk).
  454.      
  455.      
  456. Text with Data Length Information
  457.      
  458. The "ltxt" chunk contains text that is associated with a data segment of
  459. specific length. The chunk fields are as follows:
  460.      
  461.      Field          Description
  462.      
  463.      dwName         Specifies the cue point name.  This value must match one of
  464.                     the names listed in the <cue-ck> cue-point table.
  465.      
  466.      dwSampleLength Specifies the number of samples in the segment of waveform
  467.                     data.
  468.      
  469.      dwPurpose      Specifies the type or purpose of the text. For example,
  470.                     <dwPurpose> can specify a FOURCC code like `scrp' for script
  471.                     text or `capt' for close-caption text.
  472.      
  473.      wCountry       Specifies the country code for the text. See "Country Codes"
  474.                     for a current list of country codes.
  475.      
  476.      wLanguage,     Specify the language and dialect codes for the text. See
  477.      wDialect       "Language and Dialect Codes" for a current list of language
  478.                     and dialect codes.
  479.      
  480.      wCodePage      Specifies the code page for the text.
  481.      
  482.      
  483. New Forms
  484.      
  485. Currently None
  486.      
  487.      
  488. New WAVE Types
  489.      
  490. All newly defined WAVE types must contain both a fact chunk and an extended
  491. wave format description within the 'fmt' chunk. RIFF WAVE files of type 
  492. WAVE_FORMAT_PCM need not have the extra chunk nor the extended wave format
  493. description.
  494.      
  495. Fact Chunk
  496.  
  497. This chunk stores file dependent information about the contents of the WAVE
  498. file. It currently specifies the length of the file in samples.
  499.      
  500. EXTWAVEFORMAT
  501.      
  502. The extended wave format structure is used to defined all non-PCM format
  503. wave data, and is described as follows in the include file mmreg.h:
  504.      
  505. /* general extended waveform format structure */
  506. /* Use this for all NON PCM formats */
  507. /* (information common to all formats) */
  508.  
  509. typedef struct waveformat_extended_tag {
  510.     WORD    wFormatTag;        /* format type */
  511.     WORD    nChannels;         /* number of channels (i.e. mono, stereo...)
  512.  
  513. */
  514.     DWORD   nSamplesPerSec;    /* sample rate */
  515.     DWORD   nAvgBytesPerSec;   /* for buffer estimation */
  516.     WORD    nBlockAlign;       /* block size of data */
  517.     WORD    wBitsPerSample;    /* Number of bits per sample of mono data */
  518.     WORD    cbSize;        /* The count in bytes of the extra size */
  519.                            /* SPECIFY TOTAL OR EXTRA */
  520. } WAVEFORMATEX;
  521.     
  522.      
  523.      wFormatTag          Defines the type of WAVE file.
  524.      
  525.      nChannels           Number of channels in the wave, 1 for mono, 2 for
  526.                          stereo
  527.      
  528.      nSamplesPerSec      Frequency of the sample rate of the wave file. This
  529.                          should be 11025, 22050, or 44100.  Other sample rates
  530.                          are allowed, but not encouraged.  This rate is
  531.                          also used by the sample size entry in the fact chunk to
  532.                          determine the length in time of the data.
  533.      
  534.      nAvgBytesPerSec     Average data rate.
  535.      
  536.                          Playback software can estimate the buffer size using
  537.                          the <nAvgBytesPerSec> value.
  538.      
  539.      nBlockAlign         The block alignment (in bytes) of the data in <data-
  540.                          ck>.
  541.      
  542.                          Playback software needs to process a multiple of
  543.                          <nBlockAlign> bytes of data at a time, so that the 
  544.                         value of <nBlockAlign> can be used for buffer alignment.
  545.      
  546.      wBitsPerSample      This is the number of bits per sample per channel data.
  547.                          Each channel is assumed to have the same sample
  548.                          resolution.  If this field is not needed, then
  549.                          it should be set to zero.
  550.      
  551.      cbExtraSize         The size in bytes of the extra information in the WAVE
  552.                          format header.
  553.      
  554.      
  555.      #define   WAVE_FORMAT_UNKNOWN      (0x0000)
  556.      #define   WAVE_FORMAT_ADPCM        (0x0002)
  557.      #define   WAVE_FORMAT_IBM_CVSD     (0x0005)
  558.      #define   WAVE_FORMAT_ALAW         (0x0006)
  559.      #define   WAVE_FORMAT_MULAW        (0x0007)
  560.      #define   WAVE_FORMAT_OKI_ADPCM    (0x0010)
  561.      #define   WAVE_FORMAT_DIGISTD      (0x0015)
  562.      #define   WAVE_FORMAT_DIGIFIX      (0x0016)
  563.      
  564.      
  565. Microsoft ADPCM
  566.      
  567. Added     05/01/92
  568. Author:   Microsoft
  569.      
  570. Fact Chunk
  571.      
  572. This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM.  It
  573. stores file dependent information about the contents of the WAVE data. It 
  574. currently specifies the time length of the data in samples.
  575.      
  576. WAVE Format Header
  577.      
  578.      #define   WAVE_FORMAT_ADPCM        (0x0002)
  579.      
  580.      typedef struct adpcmcoef_tag {
  581.      int  iCoef1;
  582.      int  iCoef2;
  583.      } ADPCMCOEFSET;
  584.      
  585.      typedef struct adpcmwaveformat_tag {
  586.      EXTWAVEFORMAT  ewf;
  587.      WORD      nSamplesPerBlock;
  588.      WORD      nNumCoef;
  589.      ADPCMCOEFSET   aCoeff[nNumCoef];
  590.      } ADPCMWAVEFORMAT;
  591.      
  592.      
  593.      wFormatTag          This must be set to WAVE_FORMAT_ADPCM.
  594.      
  595.      nChannels           Number of channels in the wave, 1 for mono, 2 for
  596.                          stereo.
  597.      
  598.      nSamplesPerSec      Frequency of the sample rate of the wave file. This
  599.                          should be 11025, 22050, or 44100.  Other sample rates
  600.                          are allowed, but not encouraged.
  601.      
  602.      nAvgBytesPerSec     Average data rate.  ((nSamplesperSec /
  603.                          nSamplesPerBlock) * nBlockAlign).
  604.      
  605.                          Playback software can estimate the buffer size using
  606.                          the <nAvgBytesPerSec> value.
  607.      
  608.      nBlockAlign         The block alignment (in bytes) of the data in <data-
  609.                          ck>.
  610.      
  611.                               nSamplesPerSec x Channels     nBlockAlign
  612.      
  613.                                    8k                            256
  614.                                    11k                           256
  615.                                    22k                           512
  616.                                    44k                           1024
  617.                          
  618.                          Playback software needs to process a multiple of
  619.                          <nBlockAlign> bytes of data at a time, so that the
  620.                          value of <nBlockAlign> can be used for buffer
  621.                          alignment.
  622.      
  623.      wBitsPerSample      This is the number of bits per sample of ADPCM.
  624.                          Currently only 4 bits per sample is defined.  Other
  625.                          values are reserved.
  626.      
  627.      cbExtraSize         The size in bytes of the entire WAVE format chunk.
  628.      
  629.                          For the standard WAVE_FORMAT_ADPCM this is 32.  If
  630.                          extra coefficients are added, then this value will
  631.                          increase.
  632.      
  633.      nSamplesPerBlock    Count of number of samples per block.
  634.      
  635.                          (((nBlockAlign - (7 * nChannels)) * 8) /
  636.                          (wBitsPerSample * nChannels)) + 2.
  637.      
  638.      nNumCoef            Count of the number of coefficient sets defined in
  639.                          aCoef.
  640.      
  641.      aCoeff              These are the coefficients used by the wave to play.
  642.                          They may be interpreted as fixed point 8.8 signed
  643.                          values. Currently there are 7 preset coefficient sets.
  644.                          They must appear in the following order.
  645.      
  646.                               Coef Set       Coef1          Coef2
  647.      
  648.                                    0         256            0
  649.                                    1         512            -256
  650.                                    2         0              0
  651.                                    3         192            64
  652.                                    4         240            0
  653.                                    5         460            -208
  654.                                    6         392            -232
  655.      
  656.                          Note that if even only 1 coefficient set was used to
  657.                          encode the file then all coefficient sets are still
  658.                          included.  More coefficients may be added by the
  659.                          encoding software, but the first 7  must always be the
  660.                          same.
  661.      
  662. Note: 8.8 signed values can be divided by 256 to obtain the integer portion
  663. of the value.
  664.      
  665.      
  666. Block
  667.      
  668. The block has three parts, the header, data, and padding. The three
  669. together are <nBlockAlign> bytes.
  670.      
  671.      typedef struct adpcmblockheader_tag {
  672.           BYTE           bPredictor[nChannels];
  673.           int            iDelta[nChannels];
  674.           int            iSamp1[nChannels];
  675.           int            iSamp2[nChannels];
  676.      } ADPCMBLOCKHEADER;
  677.      
  678.      Field          Description
  679.      
  680.      bPredictor     Index into the aCoef array to define the predictor used to
  681.                     encode this block.
  682.      
  683.      iDelta         Initial Delta value to use.
  684.      
  685.      iSamp1         The second sample value of the block.  When decoding this
  686.                     will be used as the previous sample to start decoding with.
  687.      
  688.      iSamp2         The first sample value of the block.  When decoding this
  689.                     will be used as the previous' previous sample to start
  690.                     decoding with.
  691.      
  692.      
  693. Data           
  694.      
  695. The data is a bit string parsed in groups of (wBitsPerSample * nChannels).
  696.      
  697. For the case of  Mono Voice ADPCM (wBitsPerSample = 4, nChannels = 1) we
  698. have:
  699.      
  700. <Byte1> <Byte2>...<ByteN> ...<Byte((nSamplesPerBlock-2)/2)>
  701.  
  702. where <ByteN> has <High Order Bit ... Low OrderBit> or < (Sample 2N + 2)
  703.      (Sample 2N + 3)>
  704.      <ByteN> =  ((4 bit error delta for sample (2 * N) + 2) << 4)
  705.      | (4 bit error delta for sample (2 * N) + 3)
  706.      
  707. For the case of  Stereo Voice ADPCM (wBitsPerSample = 4, nChannels = 2) we
  708. have:
  709.      
  710.      <Byte1> <Byte2>...<ByteN> ...<Byte(nSamplesPerBlock-2)>
  711.  
  712. where <ByteN> has <High Order Bit ... Low OrderBit> or
  713.      < (Left Channel of Sample N + 2) (Right Channel of Sample N + 2)>
  714.      <ByteN> =  ((4 bit error delta for left channel of sample N
  715.      + 2) << 4)  |  (4 bit error delta for right channel of sample N + 2)
  716.      
  717.      
  718. Padding
  719.      
  720. Bit Padding is used to round off the block to an exact byte length.
  721. The size of the padding (in bits):
  722.      
  723. ((nBlockAlign - (7 * nChannels)) * 8)   -
  724.      (((nSamplesPerBlock - 2) * nChannels) * wBitsPerSample)
  725.      
  726. The padding does not store any data and should be made zero.
  727.      
  728.      
  729. ADPCM Algorithm
  730.      
  731. Each channel of the ADPCM file can be encoded/decoded independently.
  732. However this should not destroy phase and amplitude information since each 
  733. channel will track the original.   Since the channels are encoded/decoded 
  734. independently, this document is written as if only one channel is being 
  735. decoded.   Since the channels are interleaved, multiple channels may be 
  736. encoded/decoded in parallel using independent local storage and temporaries.
  737.      
  738. Note that the process for encoding/decoding one block  is  independent from
  739. the process for the next block.  Therefore the process is described for one 
  740. block only, and may be repeated for other blocks. While some optimizations 
  741. may relate the process for one block to another, in theory they are still 
  742. independent.
  743.      
  744. Note that in the description below the number designation appended to iSamp
  745. (i.e. iSamp1 and iSamp2) refers to the placement of the sample in relation 
  746. to the current one being decoded.  Thus when you are decoding sample N, 
  747. iSamp1 would be sample N - 1 and iSamp2 would be sample N - 2.  Coef1 is 
  748. the coefficient for iSamp1 and Coef2 is the coefficient for iSamp2.  This 
  749. numbering is identical to that used in the block and format descriptions above.
  750.      
  751. A sample application will be provided to convert a RIFF waveform file to
  752. and from ADPCM and PCM formats.
  753.      
  754. Decoding
  755.      
  756. First the predictor coefficients are determined by using the bPredictor
  757. field of  block header.  This value is an index into the aCoef array in the 
  758. file header.
  759.  
  760.           bPredictor = GETBYTE
  761.      
  762. The initial iDelta is also taken from the block header.
  763.  
  764.           iDelta = GETWORD
  765.      
  766. Then the first two samples are taken from block header.  (They are stored
  767. as 16 bit PCM data as iSamp1 and iSamp2.  iSamp2 is the first sample of 
  768. the block, iSamp1 is the second sample.)
  769.  
  770.           iSamp1= GETINT
  771.           iSamp2 = GETINT
  772.      
  773. After taking this initial data from the block header, the process of
  774. decoding the rest of the block may begin.  It can be done in the following 
  775. manner:
  776.      
  777. While there are more samples in the block to decode:
  778. Predict the next sample from the previous two samples.
  779.  
  780.           lPredSamp =  ((iSamp1 * iCoef1) + (iSamp2 *iCoef2)) /
  781.  
  782. FIXED_POINT_COEF_BASE
  783.  
  784. Get the 4 bit signed error delta.
  785.  
  786.           (iErrorDelta = GETNIBBLE)
  787.  
  788. Add the 'error in prediction' to the predicted next sample and prevent
  789. over/underflow errors.
  790.  
  791.           (lNewSamp =  lPredSample + (iDelta * iErrorDelta)
  792.           if lNewSample too large, make it the maximum allowable size.
  793.           if lNewSample too small, make it the minimum allowable size.
  794.  
  795. Output the new sample.
  796.  
  797.           OUTPUT( lNewSamp )
  798.  
  799. Adjust the quantization step size used to calculate the 'error in
  800. prediction'.
  801.  
  802.           iDelta = iDelta * AdaptionTable[ iErrorDelta] /
  803.  
  804. FIXED_POINT_ADAPTION_BASE
  805.  
  806.           if iDelta too small, make it the minimum allowable size.
  807.  
  808. Update the record of previous samples.
  809.  
  810.           iSamp2 = iSamp1;
  811.           iSamp1 = lNewSample.
  812.      
  813. Encoding
  814.      
  815. For each block, the encoding process can be done through the following
  816. steps. (for each channel)
  817.      
  818.      Determine the predictor to use for the block.
  819.      Determine the initial iDelta for the block.
  820.      Write out the block header.
  821.      Encode and write out the data.
  822.      
  823. The predictor to use for each block can be determined in many ways.
  824.  
  825.      1. A static predictor for all files.
  826.  
  827.      2. The block can be encoded with each possible predictor.  Then the
  828.      predictor that gave the least error can be chosen.  The least error 
  829.      can be determined from:
  830.     
  831.           1. Sum of squares of differences. (from compressed/decompressed to  
  832.                original data)
  833.           2. The least average absolute difference.
  834.           3. The least average iDelta
  835.    
  836.      3. The predictor that has the smallest initial iDelta can be chosen.
  837.      (This is an approximation of method 2.3)
  838.  
  839.      4. Statistics from either the previous or current block.  (e.g. a linear
  840.      combination of  the first 5 samples of a block that corresponds to the 
  841.      average predicted error.)
  842.      
  843. The starting iDelta for each block can also be determined in a couple of
  844. ways.
  845.  
  846.      1. One way is to always start off with the same initial iDelta.
  847.  
  848.      2. Another way is to use the iDelta from the end of the previous block.
  849.      (Note that for the first block an initial value must then be chosen.)
  850.  
  851.      3. The initial iDelta may also be determined from the first few samples
  852.      of the block. (iDelta generally fluctuates around the value that makes 
  853.      the absolute value of the encoded output about half the maximum absolute 
  854.      value of the encoded output. (For 4 bit error deltas the maximum 
  855.      absolute value is 8.  This means the initial iDelta should be set 
  856.      so that the first output is around 4.)
  857.  
  858.      4. Finally the initial iDelta for this block may be determined from the
  859.      last few samples of the last block.  (Note that for the first block an 
  860.      initial value must then be chosen.)
  861.      
  862. Note that different choices for predictor and initial iDelta will result in
  863. different audio quality.
  864.      
  865. Once the predictor and starting quantization values are chosen, the block
  866. header may be written out.
  867.  
  868. First the choice of predictor is written out. (For each channel.)
  869.  
  870. Then the initial iDelta (quantization scale) is written out. (For each
  871. channel.)
  872.  
  873. Then the 16 bit PCM value of the second sample is written out. (iSamp1)
  874. (For each channel.)
  875.  
  876. Finally the 16 bit PCM value of the first sample is written out.  (iSamp2)
  877. (For each channel.)
  878.      
  879. Then the rest of the block may be encoded. (Note that the first encoded
  880. value will be for the 3rd sample in the block since the first two are 
  881. contained in the header.)
  882.      
  883. While there are more samples in the block to decode:
  884.      
  885. Predict the next sample from the previous two samples.
  886.  
  887.           lPredSamp =  ((iSamp1 * iCoef1) + (iSamp2 *iCoef2))
  888.                     / FIXED_POINT_COEF_BASE
  889.  
  890. The 4 bit signed error delta is produced and overflow/underflow is
  891. prevented..
  892.  
  893.           iErrorDelta =  (Sample(n) - lPredSamp) / iDelta
  894.           if iErrorDelta is too large, make it the maximum allowable size.
  895.           if iErrorDelta is too small, make it the minimum allowable size.
  896.  
  897. Then the nibble iErrorDelta is written out.
  898.  
  899.           PutNIBBLE( iErrorDelta )
  900.  
  901. Add the 'error in prediction' to the predicted next sample and prevent
  902. over/underflow errors.
  903.  
  904.           (lNewSamp =  lPredSample + (iDelta * iErrorDelta)
  905.           if lNewSample too large, make it the maximum allowable size.
  906.           if lNewSample too small, make it the minimum allowable size.
  907.  
  908. Adjust the quantization step size used to calculate the 'error in
  909. prediction'.
  910.  
  911.      iDelta = iDelta * AdaptionTable[ iErrorDelta] /
  912.  
  913. FIXED_POINT_ADAPTION_BASE
  914.  
  915.      if iDelta too small, make it the minimum allowable size.
  916.  
  917. Update the record of previous samples.
  918.  
  919.           iSamp2 = iSamp1;
  920.           iSamp1 = lNewSample.
  921.      
  922.      
  923. Sample C Code
  924.      
  925. Sample C Code is contained in the file msadpcm.c, which is available with
  926. this document in electronic form and separately.  See the Overview section 
  927. for how to obtain this sample code.
  928.      
  929.      
  930. CVSD Wave Type
  931.      
  932. Added     07/21/92
  933. Author:   Digispeech
  934.      
  935.      
  936. Fact Chunk
  937.      
  938. This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM.  It
  939. stores file dependent information about the contents of the WAVE data. It 
  940. currently specifies the time length of the data in samples.
  941.      
  942. WAVE Format Header
  943.      
  944. #define   WAVE_FORMAT_IBM_CVSD          (0x0005)
  945.      
  946.      
  947.      wFormatTag          This must be set to  WAVE_FORMAT_IBM_CVSD
  948.      
  949.      nChannels           Number of channels in the wave, 1 for mono, 2 for
  950.                          stereo...
  951.      
  952.      nSamplesPerSec      Frequency the source was sampled at.  See chart below.
  953.      
  954.      nAvgBytesPerSec     Average data rate.   See chart below.  (One of  1800,
  955.                          2400, 3000, 3600, 4200, or 4800)
  956.      
  957.                          Playback software can estimate the buffer size using
  958.                          the <nAvgBytesPerSec> value.
  959.      
  960.      nBlockAlign         Set to 2048 to provide efficient caching of file from
  961.                          CD-ROM.
  962.      
  963.                          Playback software needs to process a multiple of
  964.                          <nBlockAlign> bytes of data at a time, so that the
  965.                          value of <nBlockAlign> can be used for buffer
  966.                          alignment.
  967.      
  968.      wBitsPerSample      This is the number of bits per sample of data.  This is
  969.                          always 1 for CVSD.
  970.      
  971.      cbExtraSize         The size in bytes of the rest of the wave format
  972.                          header. This is zero for CVSD.
  973.      
  974. The Digispeech CVSD compression format is compatible with the IBM PS/2
  975. Speech Adapter, which uses a Motorola MC3418 for CVSD modulation.  
  976. The Motorola chip uses only one algorithm which can work at variable 
  977. sampling clock rates.  The CVSD algorithm compresses each input audio 
  978. sample to 1 bit.  An acceptable quality of sound is achieved using high 
  979. sampling rates.  The Digispeech DS201 adapter supports six CVSD sampling
  980. frequencies, which are being used by most software using the IBM PS/2 
  981. Speech Adapter:
  982.      
  983.      Sample Rate    Bytes/Second
  984.      
  985.      14,400Hz       1800 Bytes
  986.      
  987.      19,200Hz       2400 Bytes
  988.      
  989.      24,000Hz       3000 Bytes
  990.      
  991.      28,800Hz       3600 Bytes
  992.      
  993.      33,600Hz       4200 Bytes
  994.      
  995.      38,400Hz       4800 Bytes
  996.      
  997. The CVSD format is a compression scheme which has been used by IBM and is
  998. supported by the IBM PS/2 Speech Adapter card.  Digispeech also has a 
  999. card that uses this compression scheme.  It is not Digispeech's policy 
  1000. to disclose any of these algorithms to any third party vendor.
  1001.      
  1002.      
  1003. CCITT Standard Companded Wave Types
  1004.      
  1005. Added:    05/22/92
  1006. Author:   Microsoft, Digispeech, Vocaltec, Artisoft
  1007.      
  1008. Fact Chunk
  1009.      
  1010. This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM.  It
  1011. stores file dependent information about the contents of the WAVE data. 
  1012. It currently specifies the time length of the data in samples.
  1013.      
  1014. WAVE Format Header
  1015.      
  1016. #define   WAVE_FORMAT_ALAW         (0x0006)
  1017. #define   WAVE_FORMAT_MULAW        (0x0007)
  1018.      
  1019.      
  1020.      wFormatTag          This must be set to one of  WAVE_FORMAT_ALAW,
  1021.                          WAVE_FORMAT_MULAW
  1022.      
  1023.      nChannels           Number of channels in the wave, 1 for mono, 2 for
  1024.                          stereo...
  1025.      
  1026.      nSamplesPerSec      Frequency of the wave file. (8000, 11025, 22050,
  1027.                          44100).
  1028.      
  1029.      nAvgBytesPerSec     Average data rate.
  1030.      
  1031.                          Playback software can estimate the buffer size using
  1032.                          the <nAvgBytesPerSec> value.
  1033.      
  1034.      nBlockAlign         Size of the blocks in bytes.
  1035.      
  1036.                          Playback software needs to process a multiple of
  1037.                          <nBlockAlign> bytes of data at a time, so that the
  1038.                          value of <nBlockAlign> can be used for buffer
  1039.                          alignment.
  1040.      
  1041.      wBitsPerSample      This is the number of bits per sample of data.  (This
  1042.                          is 8 for all the companded formats.)
  1043.      
  1044.      cbExtraSize         The size in bytes of the extra information in the
  1045.                          extended  WAVE 'fmt' header.  This should be zero.
  1046.      
  1047. See the CCITT G.711 specification for details of the data format.
  1048. This is a CCITT (International Telegraph and Telephone Consultative
  1049. Committee) specification.  Their address is:
  1050.      
  1051.      Palais des Nations
  1052.      CH-1211 Geneva 10, Switzerland
  1053.      Phone: 22 7305111
  1054.      
  1055.      
  1056. OKI ADPCM Wave Types
  1057.      
  1058. Added: 05/22/92
  1059. Author: DigiSpeech, Vocaltec, Wang
  1060.      
  1061. Fact Chunk
  1062.      
  1063. This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM.  It
  1064. stores file dependent information about the contents of the WAVE data. It 
  1065. currently specifies the time length of the data in samples.
  1066.      
  1067. WAVE Format Header
  1068.    
  1069. #define   WAVE_FORMAT_OKI_ADPCM         (0x0010)
  1070.      
  1071. typedef struct oki_adpcmwaveformat_tag {
  1072.      EXTWAVEFORMAT  ewf;
  1073.      WORD wPole;
  1074. } OKIADPCMWAVEFORMAT;
  1075.      
  1076.      
  1077.      wFormatTag          This must be set to WAVE_FORMAT_OKI_ADPCM
  1078.      
  1079.      nChannels           Number of channels in the wave, 1 for mono, 2 for
  1080.                          stereo.
  1081.      
  1082.      nSamplesPerSec      Frequency the sample rate of the wave file. (8000,
  1083.                          11025, 22050, 44100).
  1084.      
  1085.      nAvgBytesPerSec     Average data rate.
  1086.      
  1087.                          Playback software can estimate the buffer size using
  1088.                          the <nAvgBytesPerSec> value.
  1089.      
  1090.      nBlockAlign         This is dependent upon the number of bits per sample.
  1091.      
  1092.                            wBitsPerSample         nChannels      nBlockAlign     
  1093.      
  1094.                               3                        1              3
  1095.                               3                        2              6
  1096.                               4                        1              1
  1097.                               4                        2              1
  1098.      
  1099.                          Playback software needs to process a multiple of
  1100.                          <nBlockAlign> bytes of data at a time, so that the
  1101.                          value of <nBlockAlign> can be used for buffer
  1102.                          alignment.
  1103.      
  1104.      wBitsPerSample      This is the number of bits per sample of data.  (OKI
  1105.                          can be 3 or 4)
  1106.      
  1107.      cbExtraSize         The size in bytes of the extra information in the
  1108.                          extended  WAVE 'fmt' header.  This should be 2.
  1109.      
  1110.      wPole               High frequency emphasis value
  1111.      
  1112.      
  1113. This format is created and read by the OKI APDCM chip set.  This chip set
  1114. is used by a number of
  1115. card manufacturers.
  1116.      
  1117.      
  1118. DVI ADPCM Wave Type
  1119.      
  1120. Added: Pending
  1121. Author: Microsoft, Intel
  1122.      
  1123. This definition is pending and is not yet final.  Do not use this definition.
  1124.      
  1125.      Fact Chunk
  1126.      
  1127.      This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM.  It
  1128.      stores file
  1129.      dependent information about the contents of the WAVE data. It currently
  1130.      specifies the time length
  1131.      of the data in samples.
  1132.      
  1133. WAVE Format Header
  1134.      
  1135. #define   WAVE_FORMAT_DVI_ADPCM         (0x0011)
  1136.      
  1137. typedef struct dvi_adpcmwaveformat_tag {
  1138.      EXTWAVEFORMAT  ewf;
  1139.      WORD wPole;
  1140. } DVIADPCMWAVEFORMAT;
  1141.      
  1142.      
  1143.      wFormatTag          This must be set to WAVE_FORMAT_DVI_ADPCM.
  1144.      
  1145.      nChannels           Number of channels in the wave, 1 for mono, 2 for
  1146.                          stereo...
  1147.      
  1148.      nSamplesPerSec      Frequency the wave file. (8000, 11025, 22050, 44100).
  1149.      
  1150.      nAvgBytesPerSec     Average data rate.
  1151.      
  1152.                          Playback software can estimate the buffer size using
  1153.                          the <nAvgBytesPerSec> value.
  1154.      
  1155.      nBlockAlign         This is dependent upon the number of bits per sample.
  1156.      
  1157.                            wBitsPerSample    nChannels      nBlockAlign
  1158.                               
  1159.                               3                   1              3
  1160.                               3                   2              6
  1161.                               4                   1              1
  1162.                               4                   2              1
  1163.      
  1164.                          Playback software needs to process a multiple of
  1165.                          <nBlockAlign> bytes of data at a time, so that the
  1166.                          value of <nBlockAlign> can be used for buffer
  1167.                          alignment.
  1168.      
  1169.      wBitsPerSample      This is the number of bits per sample of data.  (DVI is
  1170.                          4)
  1171.      
  1172.      cbExtraSize         The size in bytes of the extra information in the
  1173.                          extended  WAVE 'fmt' header.  This should be 2.
  1174.      
  1175.      wPole               High frequency emphasis value.
  1176.      
  1177.      
  1178. Digispeech Wave Types
  1179.      
  1180. Added:    05/22/92
  1181. Author:   Digispeech
  1182.      
  1183. Fact Chunk
  1184.      
  1185. This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM.  It
  1186. stores file dependent information about the contents of the WAVE data. 
  1187. It currently specifies the time length of the data in samples.
  1188.      
  1189. WAVE Format Header
  1190.      
  1191. #define   WAVE_FORMAT_DIGISTD      (0x0015)
  1192. #define   WAVE_FORMAT_DIGIFIX      (0x0016)
  1193.      
  1194.      
  1195.      wFormatTag          This must be set to  either WAVE_FORMAT_DIGISTD or
  1196.                          WAVE_FORMAT_DIGIFIX.
  1197.      
  1198.      nChannels           Number of channels in the wave. (1 for mono)
  1199.      
  1200.      nSamplesPerSec      Frequency the sample rate of the wave file. (8000).
  1201.                          This value is also used by the fact chunk to determine
  1202.                          the length in time units of the date.
  1203.      
  1204.      nAvgBytesPerSec     Average data rate.  (1100 for DIGISTD or 1625 for
  1205.                          DigiFix)
  1206.      
  1207.                          Playback software can estimate the buffer size using
  1208.                          the <nAvgBytesPerSec> value.
  1209.      
  1210.      nBlockAlign         Block Alignment of 2 for DIGISTD and 26 for DigiFix.
  1211.      
  1212.                          Playback software needs to process a multiple of
  1213.                          <nBlockAlign> bytes of data at a time, so that the
  1214.                          value of <nBlockAlign> can be used for buffer
  1215.                          alignment.
  1216.      
  1217.      wBitsPerSample      This is the number of bits per sample of data.
  1218.      
  1219.      cbExtraSize         The size in bytes of the extra information in the
  1220.                          extended  WAVE 'fmt' header.  This should be 2.
  1221.      
  1222. The definition of the data contained in the Digistd and DigiFix formats are
  1223. considered proprietary information of Digispeech.  They can be contacted at:
  1224.      
  1225.      Digispeech, Inc.
  1226.      2464 Embarcadero Way
  1227.      Palo Alto, CA 94303
  1228.      
  1229. The DIGISTD is a format used in a compression technique developed by
  1230. Digispeech, Inc.  DIGISTD format provides good speech quality with average 
  1231. rate of about 1100 bytes/second.  The blocks (or buffers) in this format 
  1232. cannot be cyclically repeated.
  1233.      
  1234. The DigiFix is a format used in a compression technique developed by
  1235. Digispeech, Inc.  DigiFix format provides good speech quality (similar 
  1236. to DIGISTD) with average rate of exactly 1625 bytes/second.  This format 
  1237. uses blocks of 26 bytes long.
  1238.      
  1239.      
  1240. Unknown Wave Type
  1241.      
  1242. Added:    05/01/92
  1243. Author:   Microsoft
  1244.      
  1245. Fact Chunk
  1246.      
  1247. This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM.  It
  1248. stores file dependent information about the contents of the WAVE data. 
  1249. It currently specifies the time length of the data in samples.
  1250.      
  1251. WAVE Format Header
  1252.      
  1253. This format type should be used during development of a new type.  This
  1254. type should only be used internally at a company during development 
  1255. before the new WAVE type is registered.
  1256.      
  1257. #define   WAVE_FORMAT_UNKNOWN      (0x0000)
  1258.      
  1259.      
  1260.      wFormatTag     This must be set to WAVE_FORMAT_UNKNOWN.
  1261.      
  1262.      nChannels      Number of channels in the wave.(1 for mono)
  1263.      
  1264.      nSamplesPerSec Frequency the of the sample rate of wave file.
  1265.      
  1266.      nAvgBytesPerSec     Average data rate.
  1267.      
  1268.                     Playback software can estimate the buffer size using the     
  1269.                     <nAvgBytesPerSec> value.
  1270.      
  1271.      nBlockAlign    Block Alignment of for the data.
  1272.      
  1273.                     Playback software needs to process a multiple of
  1274.                     <nBlockAlign> bytes of data at a time, so that the value of
  1275.                     <nBlockAlign> can be used for buffer
  1276.                     alignment.
  1277.      
  1278.      wBitsPerSample This is the number of bits per sample of data.
  1279.      
  1280.      cbExtraSize    The size in bytes of the extra information in the extended
  1281.                     WAVE 'fmt' header.
  1282.      
  1283.      
  1284. DIB File Additions
  1285.      
  1286. These are new biCompression types for the DIB and RDIB file formats.
  1287.      
  1288. These new DIB data formats can be passed to any Windows device driver by
  1289. passing the correct BITMAPINFOHEADER structure when using RGB555 and 
  1290. RGB565 formats.  RGB555 and RGB565 DIB Formats
  1291.      
  1292. Efficient utilization of the new video modes provided by new video cards
  1293. requires a new format to accommodate 16-bit RGB DIBs. Standard 8-bit 
  1294. DIBs (256 colors) use a color table to encode the color information. The 
  1295. new 16-bit RGB DIBs do not have a color table, but encode the color
  1296. information directly into the 16 bits representing each pixel. There are
  1297. two types of 16-bit RGB DIBs:
  1298.  
  1299.      *    RGB555 - 32K colors using five bits each for red, green, and blue.
  1300.  
  1301.      *    RGB565 - 64K colors using five bits each for red and blue, and six
  1302.      bits for green.
  1303.      
  1304. BITMAPINFOHEADER Structure for RGB555 and RGB565 DIBs
  1305.  
  1306. The following table shows how to set up the fields of the BITMAPINFOHEADER
  1307. structure for RGB555 and RGB565 DIBs:
  1308.      
  1309.      Field          Description
  1310.      
  1311.      biSize         Size in bytes of the BITMAPINFOHEADER structure.
  1312.      
  1313.      biWidth        Width of the bitmap in pixels.
  1314.      
  1315.      biHeight       Height of the bitmap in pixels.
  1316.      
  1317.      biPlanes       Set to 1.
  1318.      
  1319.      biBitCount     Set to 16.
  1320.      
  1321.      biCompression  For RGB555, set to 0 (BI_RGB). For RGB565, set to the four-
  1322.                     character code `R565'.
  1323.      
  1324.      biSizeImage    Size in bytes of the image.
  1325.      
  1326.      biXPelsPerMeter     Horizontal resolution in pixels per meter.
  1327.      
  1328.      biYPelsPerMeter     Vertical resolution in pixels per meter.
  1329.      
  1330.      biClrUsed      Set to 0.
  1331.      
  1332.      biClrImportant Set to 0.
  1333.      
  1334. The following code fragment shows how to create the four-character code
  1335. required in the biCompression field for RGB565 DIBs:
  1336.      
  1337.      #include <mmsystem.h>
  1338.      ...
  1339.      
  1340.      bmih.biCompression = mmioFOURCC(æRÆ, æ5Æ, æ6Æ, æ5Æ);
  1341.      
  1342.      
  1343.      
  1344. RGB555 and RGB565 Pixel Encoding
  1345.      
  1346. The following diagrams illustrate the pixel encoding for RGB555 and RGB565
  1347. DIBs:
  1348.  
  1349. Pixel Encoding for RGB555 DIB
  1350.      
  1351.      XRRR RRGG GGGB BBBB
  1352.    15                   0
  1353.      
  1354.      
  1355. Pixel Encoding for RGB565 DIB
  1356.      
  1357.      RRRR RGGG GGGB BBBB
  1358.    15                   0
  1359.      
  1360.      
  1361. RIFF Clipboard Formats
  1362.      
  1363. CF_RIFF
  1364.      
  1365. Windows 3.1 defines a new clipboard format, CF_RIFF, that allows any RIFF
  1366. form to be encoded into the clipboard.
  1367.      
  1368. CF_WAVE
  1369.      
  1370. Windows 3.1 defines a new clipboard format, CF_WAVE, that allows any RIFF
  1371. form of type WAVE to be encoded into the clipboard.
  1372.      
  1373. Registered Clipboard Formats
  1374.      
  1375. Because the only way to tell the form of RIFF clipboard data is to read it,
  1376. an application cannot know if it wants to read the CF_RIFF format or not 
  1377. without getting the data and parsing it.  Usually it just wants to look 
  1378. at the form type to determine if it is interested in the data that it
  1379. contained in the clipboard.
  1380.      
  1381. In addition, encoding multiple forms involves a complicated compound RIFF
  1382. file.
  1383.      
  1384. To overcome these problems, Microsoft has defined a standard way to
  1385. register RIFF clipboard formats.  The application should call the Windows API
  1386. RegisterClipboardFormat with a string that specifies the RIFF form of the 
  1387. type that the application is interested.  The string should be constructed 
  1388. as follows:
  1389.      
  1390.      RIFF <FORM>[[' '| u | l][' '| u | l][' '| u | l][' '| u | l]]
  1391.      
  1392. where <form> is the FOURCC of the form, including spaces.  The registration
  1393. is case insensitive, so form types that have different cases must be uniquely 
  1394. registered.  This is accomplished by adding designations of the case of 
  1395. the FOURCC when the <form> is not all upper-case.
  1396.      
  1397. If any of the characters in the <form> are lower-case, then the entire
  1398. <form> must be represented by case designations.  Case is designated 
  1399. by appending four characters that represent the case of each character 
  1400. in the <form>.  The designations are 'u' for uppercase, 'l' for lower-case, 
  1401. and ' ' for space.  All non-alphabetics should be represented as spaces.
  1402.      
  1403. For example, the form 'Isp ' would be registered as "RIFF Isp ull ".  The
  1404. first character is upper case and therefore the designation character is 
  1405. 'u'.  The next two characters are lower-case and therefore the designation 
  1406. characters are both 'l'.  The last character is a non-alpha and the
  1407. designation is therefore a space.  As another example, 'L245' would be
  1408. registered as "RIFF L245 U   "
  1409.      
  1410. The CF_RIFF and CF_WAVE formats should still be created in the clipboard in
  1411. addition to any registered clipboard formats.
  1412.      
  1413.     
  1414. Encoding Language of Text
  1415.      
  1416. The following fields and values should be used when the encoding of text's
  1417. language is important.
  1418.  
  1419.      Country Codes
  1420.  
  1421. Use one of the following country codes in the wCountryCode field:
  1422.      
  1423.      Country Code   Country
  1424.      
  1425.      000            None (ignore this field)
  1426.      001            USA
  1427.      002            Canada
  1428.      003            Latin America
  1429.      030            Greece
  1430.      031            Netherlands
  1431.      032            Belgium
  1432.      033            France
  1433.      034            Spain
  1434.      039            Italy
  1435.      041            Switzerland
  1436.      043            Austria
  1437.      044            United Kingdom
  1438.      045            Denmark
  1439.      046            Sweden
  1440.      047            Norway
  1441.      049            West Germany
  1442.      052            Mexico
  1443.      055            Brazil
  1444.      061            Australia
  1445.      064            New Zealand
  1446.      081            Japan
  1447.      082            Korea
  1448.      086            People's Republic of China
  1449.      088            Taiwan
  1450.      090            Turkey
  1451.      351            Portugal
  1452.      352            Luxembourg
  1453.      354            Iceland
  1454.      358            Finland
  1455.      
  1456.      
  1457. Language and Dialect Codes
  1458.  
  1459. Specify one of the following pairs of language-code and dialect-code values
  1460. in the wLanguage and wDialect fields:
  1461.      
  1462.      Language Code  Dialect Code   Language
  1463.      
  1464.      0                   0              None (ignore these fields)
  1465.      1                   1              Arabic
  1466.      2                   1              Bulgarian
  1467.      3                   1              Catalan
  1468.      4                   1              Traditional Chinese
  1469.      4                   2              Simplified Chinese
  1470.      5                   1              Czech
  1471.      6                   1              Danish
  1472.      7                   1              German
  1473.      7                   2              Swiss German
  1474.      8                   1              Greek
  1475.      9                   1              US English
  1476.      9                   2              UK English
  1477.      10                  1              Spanish
  1478.      10                  2              Spanish Mexican
  1479.      11                  1              Finnish
  1480.      12                  1              French
  1481.      12                  2              Belgian French 
  1482.      12                  3              Canadian French
  1483.      12                  4              Swiss French
  1484.      13                  1              Hebrew
  1485.      14                  1              Hungarian
  1486.      15                  1              Icelandic
  1487.      16                  1              Italian
  1488.      16                  2              Swiss Italian
  1489.      17                  1              Japanese
  1490.      18                  1              Korean
  1491.      19                  1              Dutch
  1492.      19                  2              Belgian Dutch
  1493.      20                  1              Norwegian - Bokmal
  1494.      20                  2              Norwegian - Nynorsk
  1495.      21                  1              Polish
  1496.      22                  1              Brazilian Portuguese
  1497.      22                  2              Portuguese
  1498.      23                  1              Rhaeto-Romanic
  1499.      24                  1              Romanian
  1500.      25                  1              Russian
  1501.      26                  1              Serbo-Croatian (Latin)
  1502.      26                  2              Serbo-Croatian (Cyrillic)
  1503.      27                  1              Slovak
  1504.      28                  1              Albanian
  1505.      29                  1              Swedish
  1506.      30                  1              Thai
  1507.      31                  1              Turkish
  1508.      32                  1              Urdu
  1509.      33                  1              Bahasa
  1510.      
  1511.      
  1512.      
  1513.      
  1514.