Internet Draft: The Audio/QCP Media Type and File Format    H. GarudadriDocument: draft-garudadri-qcp-00.txt                          R. GellensExpires: August 2003                                            Qualcomm                                                        23 February 2003                        The Audio/QCP Media Type and File Format        Status of this Memo        This document is an Internet-Draft and is in full conformance with    all provisions of Section 10 of RFC2026.        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 draft documents 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 "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>.        Copyright Notice        Copyright (C) The Internet Society (2003).  All Rights Reserved.        Abstract        RFC 2658 specifies the streaming format for QCELP 13K vocoder, but    did not specify the storage format for QCELP 13K vocoder.  Many    implementations have been using the qcp file format for exchanging    QCELP 13K data and EVRC data. (For example, Eudora, QuickTime and    CDMA 2000 handsets).  This document specifies the qcp fileformat and    registers the audio/qcp MIME media type.  This format has parameters    to support QCELP 13K and EVRC data.  Note that this is different    from the EVRC storage format specified in    draft-ietf-avt-evrc-smv-03.txt (for EVRC and SMV vocoders).Garudadri                  [Page 1]                  Expires August 2003Internet Draft  The Audio/QCP Media Type and File Format  February 2003    1.  Conventions Used in this Document . . . . . . . . . . . . . .  2    2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2    3.  QCP FILE FORMAT . . . . . . . . . . . . . . . . . . . . . . .  2      3.1.  RIFF subchunks . . . . . . . . . . . . . . . . . . . . .   2      3.2.  General view of qcp subchunks . . . . . . . . . . . . . .  3      3.3.  Detailed view of qcp subchunks . . . . . . . . . . . . .   4      3.4.  Optional Chunks . . . . . . . . . . . . . . . . . . . . .  6    4.  READING A QCP FILE . . . . . . . . . . . . . . . . . . . . .   7    5.  WRITING A QCP FILE  . . . . . . . . . . . . . . . . . . . . .  8    6.  Registration of Media Type Audio/qcp . . . . . . . . . . . .   8    7.  Security Considerations . . . . . . . . . . . . . . . . . . .  9    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9    9.  Normative References  . . . . . . . . . . . . . . . . . . . . 10     10.  Authors Address  . . . . . . . . . . . . . . . . . . . . .  10      Intellectual Property Statement . . . . . . . . . . . . . . . . 10      Full Copyright Statement . . . . . . . . . . . . . . . . . . .  11    1.  Conventions Used in this Document        The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD    NOT", and "MAY" in this document are to be interpreted as described    in "Key words for use in RFCs to Indicate Requirement Levels"    [KEYWORDS].    2.  Introduction        This document specifies a format for storage of [QCELP] 13K and    [EVRC] vocoder packets in files which may residing on network    elements (e.g., media servers, Mulimedia Messaging System (MMS)    centers, etc.) and third-generation (3G) handsets or be transmitted    via email or other mechanisms.  The vocoder packets read from a file    may be streamed using [QCELP] or delivered to an [EVRC] or [QCELP]    13K decoder.    3.  QCP FILE FORMAT        The QCP file format uses the RIFF (Resource Interchange File Format)    specification.  It contains:    o   RIFF chunk with the identifying code QLCM        o   Chunks within the RIFF chunk:                o    Three required chunks fmt, vrat, and data                o    Four optional chunks labl, offs, cnfg, and text        The RIFF (Resource Interchange File Format) specification is    published in [TBD].    Garudadri                  [Page 2]                  Expires August 2003Internet Draft  The Audio/QCP Media Type and File Format  February 20033.1.  RIFF subchunks        In this section, various RIFF subchunks are described.        fmt:  This subchunk is of type "Format".  It defines which speech    codec is being used.  Both QCELP 13K and EVRC are supported.  This    is a required chunk.        vrat:  This subchunk is of type "variable-rate".  It is used to    determine whether the data chunk is comprised of variable-rate or    fixed-rate packets, and to determine the size of the data chunk in    numbers of packets.  This information can be used to determine the    length of the data chunk in seconds without reading the whole file    in the case of variable-rate packets.  This is a required chunk.        data:  This subchunk contains the packetized speech data, generatd    by the speech codec.  This is a required chunk.  Note:  The size of    the data chunk MUST be word (16-bits) aligned.  If the data chunk    happens to be of an odd size, then a zero pad byte MUST be added at    the end to make it word aligned.        labl:  This subchunk is of type "Label".  It is used for generic    storage for applications use.  This is an optional chunk.        Offs:  This subchunk contains byte offsets into data chunk in (t *    100 ms) increments.  This is useful for fast-forward and rewind    features for files containing variable rate packets.  This is an    optional chunk.        cnfg:  This is of type "File configuration".  It contains    configuration information about the file that an application may    need to know.  This is an optional chunk.        text:  This subchunk is used to for any generic storage for    applications use.  This is an optional chunk.        All data is in little-endian format, and all structs are padding    neutral, that is, they have no padding.  The chunks are word (16    bits) aligned.    3.2.  General view of qcp subchunks        <QLCM-form>    RIFF( 'QLCM'        <format chunk 'fmt'>                       // required        [<variable rate chunk - 'vrat'>]           // required        [<label chunk 'labl'>]                     // optional        [<offsets in increments chunk - 'offs'>]   // optionalGarudadri                  [Page 3]                  Expires August 2003Internet Draft  The Audio/QCP Media Type and File Format  February 2003        <codec packet data chunk - 'data'>         // required        [<configuration chunk - 'cnfg'>]           // optional        [<text chunk - 'text'>]                    //  optional    )    3.3.  Detailed view of qcp subchunks        RIFF 'QLCM' {        BYTE[4] id    = {'R', 'I', 'F', 'F'}        UINT32 size   = size of RIFF chunk excluding id and size        BYTE[4]       = {'Q', 'L', 'C', 'M'}            <format chunk - 'fmt '>  {            BYTE[4] id     = {'f', 'm', 't', ' '}            UINT32 size    = size of 'fmt ' subchunk excluding id and                             size            BYTE mjv       = major version of this format (see note 1)            BYTE mnv       = minor version of this format (see note 1)            struct type_qpl_info {                struct GUID {                    UINT32    Data1;                    UINT16    Data2;                    UINT16    Data3;                    BYTE      Data4[ 8 ];                } = Id;                          // unique ID of this                                                 //    codec                UINT16    Version;               // version # of the                                                 //    codec                BYTE      Name[80];              // proper name of the                                                 //    codec                UINT16    avgBitsPerSec;         // avg bps of the                                                 //    codec                UINT16    bytesPerPacket;        // size of a packet in                                                 //    bytes (max rate)                                                 // including header                                                 //    byte for that                                                 //    packet                UINT16    samplesPerBlock;       // size of a block in                                                 //    samples                                                 // encoder encodes one                                                 //    block into one                                                 //    packet                                                 // decoder decodes one                                                 //    packet into one                                                 //    block                UINT16    samplesPerSec;         // sps of input needed                                                 //    for the encoder                                                 // and output from theGarudadri                  [Page 4]                  Expires August 2003Internet Draft  The Audio/QCP Media Type and File Format  February 2003                                                 //    decoder                UINT16    bitsPerSample;         // bits per sample of                                                 //    the above                    // contains rate header format info                struct type_qpl_variable_rate {                    UINT32    numOfRates;         // # of rates                    // high byte = rate, low byte = size of following                    // packet                    UINT16    bytesPerPacket[8];                 } = variableRate;                    UINT32    reserved[5];            // reserved            } = codec info        }            <variable rate chunk - 'vrat'> {            BYTE[4]   id         = {'v', 'r', 'a', 't'}            UINT32    size       = size of 'vrat' subchunk excluding                                   id and size            UINT32    variableRate;                // if ( == 0 ) packet data is fixed rate                 // else if ( < 0xFFFF0000 ) variable rate            UINT32    sizeInPackets;                // the data chunk size in packets        }            [<label chunk - 'labl'>]                // see Optional chunks            [<offsets in increments chunk - 'offs'>]                // see Optional chunks            <codec packet data chunk - 'data'> {            BYTE[4] id    = {'d', 'a', 't', 'a'}            UINT32 size   = size of 'data' subchunk excluding id and                            size            BYTE[ ]       = actual packet data (see note 2)        }            [<configuration chunk - 'cnfg'>] // see Optional chunks            [<text chunk - 'text'>]          // see Optional chunks    }Garudadri                  [Page 5]                  Expires August 2003Internet Draft  The Audio/QCP Media Type and File Format  February 2003    Note 1:  The current format version is (major = 1, minor = 0)        Note 2:     If ( variableRate of 'vrat' == 0 OR 'vrat' doesn't exist ) then        BYTE[bytesPerPacket] = packet1        BYTE[bytesPerPacket] = packet2                *                *                *    else if ( variableRate of 'vrat' < 0xFFFF0000 ) then        packet1 {            BYTE = rate            BYTE[ LOBYTE(variableRate.bytesPerPacket[n]) ] where                n = index to bytesPerPacket            array that contains the rate in the high byte of                bytesPerPacket.        }        packet2 {            BYTE  = rate            BYTE[ LOBYTE(variableRate.bytesPerPacket[n]) ] where                n = index to bytesPerPacket            array that contains the rate in the high byte of                bytesPerPacket.        }                *                *                *        Note 3:  The fmt chunk MUST appear before the data chunk.        3.4.  Optional Chunks        Positioning of the optional chunks is as follows:        o    The position of the labl chunk MUST follow the vrat chunk.        o    The offs chunk MAY be positioned anywhere after the lablvrat    chunk.        o    The cnfg and text chunks MAY appear anywhere.        o    The optional chunks cannot be subchunks of other chunks.        <label chunk - 'labl'> {        BYTE[4]  id        = {'l', 'a', 'b', 'l'}        UINT32   size      = size of 'labl' subchunk excluding id and                             size        BYTE[48]           = generic storage for applications' use;Garudadri                  [Page 6]                  Expires August 2003