[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                         Laile L. Di Silvestro (Microsoft)
Expires in 6 months                           Greg Baribault (Microsoft)
                                                   Microsoft Corporation
                                                           June 20, 1999


                       Waveform Audio File Format
                       MIME Sub-type Registration
                       <draft-ema-vpim-wav-00.txt>


Status of this memo:

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also
   distribute working documents as Internet Drafts.

   Internet Drafts are valid for a maximum of six months and may be
   updated, replaced, or obsoleted by other documents at any time.
   It is inappropriate to use Internet Drafts as reference material
   or to cite them other than as a "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   This draft is being discussed by the Electronic Messaging
   Association VPIM work group. To subscribe to the mailing list, send
   a message to EMA Listserv Requests [listserv@listmail.ema.org] with
   the line "subscribe VPIM-L" in the body of the message.




















Di Silvestro, Baribault      Expires 12/20/99                   [Page 1]

Internet Draft                 audio/wav                          4/1/99


Abstract

   This document describes the registration of the MIME sub-type
   audio/wav for Waveform Audio File Format. This audio file format
   is based on RIFF and is defined by Microsoft in the Platform SDK.

1. Introduction
   This document describes the registration of the MIME sub-type
   audio/wav for the encapsulation of toll-quality audio in the
   Waveform Audio File Format. This audio file format is based on
   Resource Interchange File Format (RIFF), and is defined by Microsoft
   in the Platform SDK.

   The MIME subtype "wav" is being defined primarily for use in
   multimedia and voice messaging standards. the Voice Profile for
   Internet Messaging, version 3 [VPIM3] working draft specifies that
   all VPIM version 3 compliant implementations MAY generate
   audio/wav bodyparts and MUST receive audio/wav bodyparts. The VPIM
   version 3 specification further states that all compliant
   implementations MUST support receipt of wav-encapsulated 32KADPCM
   (g.726 ADPCM), BASIC (g.711 mu-law), and MS-GSM (Microsoft g.610
   GSM) encoded audio.

   Because the Waveform Audio File format is not well-defined and has
   not undergone a process of standardization, this document briefly
   defines the format that will be supported by VPIM version 3. For
   more detailed information, refer to the specification.

   This document does not obsolete the informational draft RFC 2361
   [WAVE] which describes audio/vnd.wav. Whereas RFC 2361 describes
   a mechanism for indicating a codec registered in the wav or avi
   vendor tree registries, this document proposes a standard for
   specifying wav-encapsulated audio content in a MIME stream.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [REQ].


2. WAV Definition

   Waveform Audio File Format is a file format for the storing of
   audio data in data chunks according to the Resource Interchange File
   Format (RIFF). Although the Waveform format is described in detail
   in xxxxxxx, lack of standardization and a proliferation of
   interpretations and enhancements make the format difficult to
   implement and support in an interoperable fashion. This document
   seeks to rectify the situation by defining the Waveform Audio
   File Format features that MUST be inplemented and supported for
   conformance with the proposed VPIM version 3 standard.



Di Silvestro, Baribault      Expires 12/20/99                   [Page 2]

Internet Draft                 audio/wav                          4/1/99

2.1 Data Organization
   Data MUST be stored in 8-bit bytes in little-endian order.
   Multi-byte values MUST be stored with the low-order bytes first,
   and the bits left-justified:

   (lsb = least-significant bit, msb = most-significant bit)

         7  6  5  4  3  2  1  0
       +-----------------------+
 char: | msb               lsb |
       +-----------------------+

         7  6  5  4  3  2  1  0 15 14 13 12 11 10  9  8
       +-----------------------+-----------------------+
short: | msb     byte 0        |       byte 1      lsb |
       +-----------------------+-----------------------+

2.2 File Format
   The Waveform Audio File Format follows the Resource Interchange File
   Format (RIFF) standard in which all data is organized into 'chunks'
   and 'sub-chunks.' Each chunk MUST comprise a 4-byte chunk ID, a
   4-byte length field specifying the size of the data, and the chunk
   data.

   To be compliant with this proposed standard, wav-formatted audio
   data MUST include the following chunks:
        RIFF header chunk: ID = 'RIFF'
        Format chunk:      ID = 'fmt '
        Sound data chunk:  ID = 'data'
        Fact chunk:        ID = 'fact'

   The chunks MAY appear in any order except that the Format chunk
   MUST be placed before the Sound data chunk (but not necessarily
   contiguous to the Sound data chunk). Any additional chunks
   MUST be expected and MAY be ignored.

2.2.1 The RIFF Header Chunk
   The RIFF header corresponds to the outermost chunk. In an audio/wav
   file, it MUST adhere to the following format:

        OFFSET  LENGTH  VALUE   DESCRIPTION
        0       4 bytes 'RIFF'  The file format ID.
        4       4 bytes         Length of the file minus (-) 8 bytes.
        8       4 bytes 'WAVE'  The data format ID.


2.2.2 The Format Chunk
   The Format chunk specifies the characteristics of the audio data
   necessary to decompress it and play it. Each audio/wav file MUST
   include one and only one Format chunk. This chunk MUST include
   the following fields:



Di Silvestro, Baribault      Expires 12/20/99                   [Page 3]

Internet Draft                 audio/wav                          4/1/99

        OFFSET  LENGTH  VALUE   DESCRIPTION
        12      4 bytes 'fmt '  The chunk ID.
        16      4 bytes 32      Length of the chunk excluding the 8
                                bytes for the ID and length.
        20      4 bytes         The codec ID.
        24      4 bytes         The number of channels.
        28      8 bytes         Samples per second.
        36      8 bytes         Average bytes per second.
        44      4 bytes         Block alignment.
        48      4 bytes         Bits per sample.

   Codec ID: The codec ID indicates what codec was used to compress
   the audio data. Three codecs are supported by the proposed VPIM
   version 3 standard, and one of them SHOULD be specified in the
   Codec ID field. The Codec ID field MAY indicate a codec other
   that the three listed below only in situations where it is certain
   that the recipient has the corresponding capabilities.

        CODEC                   ID
        g.711 mu-law            0x0007
        g.610 MS-GSM            0x0031
        g.726 32kADPCM          0x0064

   Number of Channels: To preserve network bandwidth and minimize
   memory requirements, the Format chunk SHOULD specify and the Data
   chunk SHOULD provide only one channel (mono) unless it is certain
   that the recipient supports multi-channel playback.

        CHANNELS                VALUE
        one (mono)              1

   Samples per Second: This field indicates the rate at which the
   audio is to be played (once uncompressed), expressed in sample
   frames per second. The following table specified the samples per
   second that correspond to each VPIM version 3 codec:

        CODEC                   RATE (samples per second)
        g.711 mu-law            8000
        g.610 MS-GSM            8000
        g.726 32kADPCM          8000


   Average Bytes per Second: This field specifies the number of
   bytes that play per second. It provides an indication of
   the buffer size needed to store the audio in order to avoid
   latency. It SHOULD be calculated according to the following
   formula: samples/second * block alignment (rounded up to nearest
   whole number).

        CODEC                   RATE (average bytes per second)
        g.711 mu-law            8000
        g.610 MS-GSM            1625
        g.726 32kADPCM          4000

Di Silvestro, Baribault      Expires 12/20/99                   [Page 4]

Internet Draft                 audio/wav                          4/1/99

   Block Alignment: This field indicates the size of a sample frame
   in bytes. It SHOULD be calculated according to the following
   formula: number of channels * (bits per sample / 8)

        CODEC                   SIZE
        g.711 mu-law            1
        g.610 MS-GSM            65
        g.726 32kADPCM          2
              since there are 4 bits per sample, the frames will not
              align on one byte.  It is customary to add silence bits
              (oxF) to the end of the sample to make the frame end on
              a byte boundary.

   Bits per Sample: This field specifies the bit resolution of a
   sample point.

        CODEC                   BITS (bits per sample)
        g.711 mu-law            8
        g.610 MS-GSM            0
              data immediately followed by: 0x40 0x01
        g.726 32kADPCM          4

2.2.3 The Data Chunk
   The Data chunk contains the compressed audio data. This chunk
   MUST be preceded (though not immediately) by the Format chunk.
   The Data chunk MUST adhere to the following format:

        OFFSET  LENGTH  VALUE   DESCRIPTION
        52      4 bytes 'data'  The chunk ID.
        56      4 bytes         Length of the data
                                (chunk size minus (-) 8 bytes.
        60                      The compressed audio.

2.2.4 The Fact Chunk
   All audio/wav files MUST include a Fact chunk as they contain
   compressed data. The Fact chunk MUSt contain one field indicating
   the size (in sample points) of the audio data after decompression.
   The Fact chunk MUST adhere to the following format:

        OFFSET  LENGTH  VALUE   DESCRIPTION
                4 bytes 'fact'  The chunk ID.
                4 bytes  8      Chunk size minus (-) 8 bytes.
                8 bytes         Sample length.











Di Silvestro, Baribault      Expires 12/20/99                   [Page 5]

Internet Draft                 audio/wav                          4/1/99

3. MIME Definition

3.1 audio/wav

   [Specification] describes a file format for the encapsulation of
   raw and compressed audio data. This Waveform Audio File Format (WAVE)
   is based on the Resource Interchange File Format specification
   developed by Microsoft and IBM in 1991. The WAVE format organizes
   audio data and the information needed to decompress and play it in
   chunks.

   The MIME sub-type audio/WAV is defined to hold binary audio data
   encoded in 32 kbit/s ADPCM (g.726), mu-law (g.711), or MS-GSM
   (g.610), and encapsulated in the WAVE format. The content transfer
   encoding is typically either binary or base64.

3.2 VPIM Usage

   The audio/wav sub-type is a component of the proposed VPIM version
   3 specification [VPIM3]. In this context, the Content-Description
   headers is used to succinctly describe the contents of the audio
   body.

   All VPIM Version 3 systems MUST be capable of receiving audio
   encapsulated in a WAVE file format. Sending systems MAY choose to
   send raw audio data or encapsulate it in the WAVE file format. All
   audio data MUST be compressed in one of the VPIM v3 codecs and
   encapsulated according to the guidelines provided in the section
   2.0 of this document.

   Refer to the VPIM Specifcation for proper usage.

3.3 Relation to RFC 2361

   RFC 2361, "WAVE and AVI Codec Registries," is an informational
   draft describing IANA namespaces for codecs registered in
   Microsoft's WAVE and AVI registries. Such codecs may be described
   in the following format: audio/vnd.wave; codec = [codec ID].
   This format is not suited to the description of a wave file as
   defined in this document, as it does not indicate the format
   standard that audio/wav must adhere to for interoperability
   between messaging systems. On desktop-oriented messaging systems,
   audio/wav (rather than audio/vnd.wave) is the defacto standard.











Di Silvestro, Baribault      Expires 12/20/99                   [Page 6]

Internet Draft                 audio/wav                          4/1/99

4.  IANA Registration

   To: ietf-types@iana.org
   Subject: Registration of MIME media type audio/wav

   MIME media type name: audio
   MIME subtype name: wav

   Required parameters: none
   Optional parameters: codec = [codec id]

   Encoding considerations:
      Binary or Base-64 generally preferred

   Security considerations:
      There are no known security risks with the sending or
      playing of audio data. Wav-encapsulated audio data is
      typically interpreted only by a codec supported by a
      wav audio player. Unintended information introduced into
      the data stream will result in noise.

   Interoperability considerations:

   Published specification:
      None

   Applications which use this media type:
      Multimedia and voice messaging applications

   Additional information:
     Magic number(s): ?
     File extension(s): .wav
     Macintosh File Type Code(s):  WAVE

   Person & email address to contact for further information:

     Laile L. Di Silvestro
     lailed@microsoft.com

     Greg Baribault
     gregbari@microsoft.com

   Intended usage: COMMON

   Author/Change controller:
     Laile L. Di Silvestro
     Greg Baribault







Di Silvestro, Baribault      Expires 12/20/99                   [Page 7]

Internet Draft                 audio/wav                          4/1/99

5. Authors' Addresses

   Laile L. Di Silvestro
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052
   lailed@microsoft.com

   Greg Baribault
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052
   gregbari@microsoft.com


6. References

   [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital
          Transmission Systems, Terminal Equipment - 40, 32, 24,16
          kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).

   [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
           Mail Extensions (MIME) Part Four: Registration Procedures",
           RFC 2048, November 1996.

   [VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911,
           February 1996.

   [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
           Mail - version 2", RFC 2421, September 1998.

   [VPIM3] Vaudreuil, Greg, "Voice Profile for Internet Mail, Version
           2", Work In Progress, <draft-ema-VPIMv3-00.txt>,
           December 1998.

   [REQ]   Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

   [WAVE]  Fleischman, E., "WAVE and AVI Codec Registries", RFC 2361,
           June 1998.














Di Silvestro, Baribault      Expires 12/20/99                   [Page 8]

Internet Draft                 audio/wav                          4/1/99

7.  Full Copyright Statement
   Copyright (C) The Internet Society (1999).  All Rights Reserved.
   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,
   copied, published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright notice
   and this paragraph are included on all such copies and derivative
   works.  However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the
   Internet Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards process
   must be followed, or as required to translate it into languages
   other than English.
   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.

   Microsoft hereby grants to the IETF, a perpetual, nonexclusive,
   non-sublicensable, non assignable, royalty-free, world-wide right
   and license under any Microsoft copyrights in this contribution to
   copy, publish and distribute the contribution, as well as a right
   and license of the same scope to any derivative works prepared by
   the IETF and based on, or incorporating all or part of the
   contribution.
   Microsoft further agrees that, upon adoption of this contribution
   as an Internet Standard, Microsoft will grant to any party a
   royalty-free license on other reasonable and non-discriminatory
   terms under applicable Microsoft intellectual property rights to
   implement and use the technology proposed in this contribution for
   the purpose of supporting the Internet Standard.  Microsoft
   expressly reserves all other rights it may have in the material and
   subject matter of this contribution.
   Microsoft expressly disclaims any and all warranties regarding this
   contribution including any warranty that (a) this contribution does
   not violate the rights of others, (b) the owners, if any, of other
   rights in this contribution have been informed of the rights and
   permissions granted to IETF herein, and (c) any required
   authorizations from such owners have been obtained.
   This document and the information contained herein is provided on
   an "AS IS" basis and MICROSOFT DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
   OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.
   IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY INCLUDING
   THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS
   OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY
   INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES WHETHER
   UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY
   OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT,
   WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF
   SUCH DAMAGES.

Di Silvestro, Baribault      Expires 12/20/99                   [Page 9]

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/