Movatterモバイル変換

Network Working Group                                     J. SalsmanRequest for Comments: 2586                             H. AlvestrandCategory: Informational                                      UNINETT                                                            May 1999The Audio/L16 MIME content typeStatus of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.1.  Introduction   This document defines the audio/L16 MIME type, a reasonable quality   audio format for use in Internet applications.   Possible application areas include E-mail, Web served content, file   upload in Web forms, and more.2.  The need for the Audio/L16 MIME type   The set of IETF standard MIME types for audio is small; it consists   of only the audio/basic and audio/32kadpcm types, which have a   sampling rate of 8000 samples/second.   Rates below 11025 may obscure consonant information, even for   single-voice speech.  Common compressions, such as LPC, are known to   be microphone-dependant and lossy.  Thus far all IETF MIME Audio   types either default to 8000 samples per second or use LPC.   In order for advanced speech recognition and related educational   applications to make use of internet transports (such asRFC 1867   file uploading) which use MIME typing, higher standards are required.   This type repairs that lack by registering a very simple MIME type   that allows higher rate, linear-encoded audio with multiple channels.   This is an IESG approved MIME type, and its definition is therefore   published as an RFC.Salsman                      Informational                      [Page 1]

RFC 2586            The Audio/L16 MIME content type             May 1999   Please note that there are many other Audio types described inRFC1890 [1] which IANA may wish to formally register; this one, of all   of them, seems to be most immediately needed.  This document may also   serve as a template for further registrations of these audio types.3.  The definition of Audio/L16   Audio/L16 is based on the well know audio format "L16" described inRFC 1890 section 4.4.8 for use with RTP transport.  L16 denotes   uncompressed audio data, using 16-bit signed representation in twos-   complement notation and network byte order.  (Fromsection 4.4.8 of   RFC 1890)   It may be parametrized by varying the sample rate and the number of   channels; the parameters are given on the MIME type header.   In order to promote interoperability, only a few rate values are   standardized here. Other values may NOT be used except by bilateral   agreement.   If multiple audio channels are used, channels are numbered left-to-   right, starting at one. Samples are put into the data stream from   each channel in succession; information from lower-numbered channels   precedes that from higher-numbered channels.   For more than two channels, the convention followed by the AIFF-C   audio interchange format should be followed [1], using the following   notation:      l    left      r    right      c    center      S    surround      F    front      R    rear      channels    description                 channel                                  1     2     3     4     5     6      ___________________________________________________________      2           stereo          l     r      3                           l     r     c      4           quadrophonic    Fl    Fr    Rl    Rr      4                           l     c     r     S      5                           Fl    Fr    Fc    Sl    Sr      6                           l     lc    c     r     rc    S   (FromRFC 1890 section 4.1)Salsman                      Informational                      [Page 2]

RFC 2586            The Audio/L16 MIME content type             May 19994.  IANA registration form for Audio/L16   MIME media type name : Audio   MIME subtype name : L16   Required parameters        rate: number of samples per second -- Permissible values for        rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and        48000 samples per second.   Optional parameters        channels: how many audio streams are interleaved -- defaults        to 1; stereo would be 2, etc.  Interleaving takes place        between individual two-byte samples.   Encoding considerations        Audio data is binary data, and must be encoded for non-binary        transport; the Base64 encoding is suitable for Email.  Note        that audio data does not compress easily using lossless        compression.   Security considerations        Audio data is believed to offer no security risks.   Interoperability considerations        This type is compatible with the encoding used in the WAV        (Microsoft Windows RIFF) and Apple AIFF union types, and with        the public domain "sox" and "rateconv" programs.   Published specificationRFC 2586   Applications which use this media        The public domain "sox" and "rateconv" programs accept this        type.        1. Magic number(s) : None        2. File extension(s) : WAV L16        3. Macintosh file type code : AIFF   Person to contact for further information        1. Name : James Salsman        2. E-mail : jps-L16@bovik.org   Intended usage        CommonSalsman                      Informational                      [Page 3]

RFC 2586            The Audio/L16 MIME content type             May 1999        It is expected that many audio and speech applications will use        this type.  Already the most popular platforms provide this type        with the rate=11025 parameter referred to as "radio quality        speech."   Author/Change controller        James Salsman5.  Security considerations   The audio data is believed to offer no security risks.   Note thatRFC 1890 permits an application to choose to play a single   channel from a multichannel tranmission; an attacker who knows that   two different users will pick different channels could concievably   construct some confusing messages; this, however, is ridiculous.   This type is perfect for hiding data using steganography.6.  References   [1]  Schulzrinne, H., "RTP Profile for Audio and Video Conferences        with Minimal Control",RFC 1890, January 1996.7.  Authors' Addresses   James Salsman   575 S. Rengstorff Avenue   Mountain View, CA  94040-1982 US   EMail: James@bovik.org   Harald Tveit Alvestrand   UNINETT   N-7034 TRONDHEIM   NORWAY   Phone: +47 73 59 70 94   EMail: Harald.T.Alvestrand@uninett.noSalsman                      Informational                      [Page 4]

RFC 2586            The Audio/L16 MIME content type             May 19998.  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.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Salsman                      Informational                      [Page 5]