Network Working Group                                     J. Salsman
Request for Comments: 2586                             H. Alvestrand
Category: Informational                                      UNINETT
                                                            May 1999
        
Network Working Group                                     J. Salsman
Request for Comments: 2586                             H. Alvestrand
Category: Informational                                      UNINETT
                                                            May 1999
        

The Audio/L16 MIME content type

音频/L16 MIME内容类型

Status 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.

版权所有(C)互联网协会(1999年)。版权所有。

1. Introduction
1. 介绍

This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications.

本文档定义了audio/L16 MIME类型,这是一种用于Internet应用程序的合理质量音频格式。

Possible application areas include E-mail, Web served content, file upload in Web forms, and more.

可能的应用领域包括电子邮件、Web服务内容、Web表单中的文件上载等。

2. The need for the Audio/L16 MIME type
2. 需要音频/L16 MIME类型

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.

用于音频的IETF标准MIME类型集很小;它只包含audio/basic和audio/32kadpcm类型,采样率为8000个采样/秒。

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.

低于11025的频率可能会模糊辅音信息,即使是单音语音。常见的压缩,如LPC,已知依赖于话筒且有损。到目前为止,所有IETF MIME音频类型要么默认为每秒8000个样本,要么使用LPC。

In order for advanced speech recognition and related educational applications to make use of internet transports (such as RFC 1867 file uploading) which use MIME typing, higher standards are required.

为了使高级语音识别和相关教育应用程序能够利用使用MIME类型的互联网传输(如RFC1867文件上载),需要更高的标准。

This type repairs that lack by registering a very simple MIME type that allows higher rate, linear-encoded audio with multiple channels.

这种类型通过注册一个非常简单的MIME类型来修复这一缺陷,该类型允许使用多个通道进行更高速率的线性编码音频。

This is an IESG approved MIME type, and its definition is therefore published as an RFC.

这是IESG批准的MIME类型,因此其定义发布为RFC。

Please note that there are many other Audio types described in RFC 1890 [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.

请注意,RFC 1890[1]中描述了许多其他音频类型,IANA可能希望正式注册;在所有这些中,这一个似乎是最迫切需要的。本文件也可作为进一步注册这些音频类型的模板。

3. The definition of Audio/L16
3. 音频/L16的定义

Audio/L16 is based on the well know audio format "L16" described in RFC 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. (From section 4.4.8 of RFC 1890)

音频/L16基于RFC 1890第4.4.8节中描述的用于RTP传输的众所周知的音频格式“L16”。L16表示未压缩的音频数据,使用16位符号表示法,以两个补码表示法和网络字节顺序表示。(摘自RFC 1890第4.4.8节)

It may be parametrized by varying the sample rate and the number of channels; the parameters are given on the MIME type header.

It may be parametrized by varying the sample rate and the number of channels; the parameters are given on the MIME type header.translate error, please retry

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:

对于两个以上的频道,应遵循AIFF-C音频交换格式所遵循的约定[1],使用以下符号:

l left r right c center S surround F front R rear

左左右c中心S环绕F前右后

      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
        
      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
        

(From RFC 1890 section 4.1)

(来自RFC 1890第4.1节)

4. IANA registration form for Audio/L16
4. IANA音频/L16注册表

MIME media type name : Audio MIME subtype name : L16

MIME媒体类型名称:音频MIME子类型名称: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.

所需参数速率:每秒采样数--速率的允许值为每秒8000、11025、16000、22050、24000、32000、44100和48000个样本。

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.

可选参数通道:交错的音频流数量——默认为1;立体声将是2,等等。交错发生在单个两字节样本之间。

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.

编码注意事项音频数据是二进制数据,并且必须为非二进制传输进行编码;Base64编码适用于电子邮件。请注意,使用无损压缩时,音频数据不容易压缩。

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.

互操作性注意事项此类型与WAV(Microsoft Windows RIFF)和Apple AIFF联合类型中使用的编码兼容,并与公共域“sox”和“rateconv”程序兼容。

Published specification RFC 2586

已发布规范RFC 2586

Applications which use this media The public domain "sox" and "rateconv" programs accept this type.

在公共域“sox”和“rateconv”程序中使用此媒体的应用程序接受此类型。

1. Magic number(s) : None 2. File extension(s) : WAV L16 3. Macintosh file type code : AIFF

1. 神奇数字:无2。文件扩展名:WAV L16 3。Macintosh文件类型代码:AIFF

Person to contact for further information

有关更多信息,请联系相关人员

1. Name : James Salsman 2. E-mail : jps-L16@bovik.org

1. 姓名:詹姆斯·萨尔斯曼2。电邮:jps-L16@bovik.org

Intended usage Common

预期用途常见

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."

预计许多音频和语音应用程序将使用这种类型。最流行的平台已经为这种类型提供了rate=11025参数,称为“无线电质量语音”

Author/Change controller James Salsman

作者/变更控制员詹姆斯·萨尔斯曼

5. Security considerations
5. 安全考虑

The audio data is believed to offer no security risks.

音频数据被认为没有安全风险。

Note that RFC 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.

注意,RFC1890允许应用程序从多通道传输中选择播放单个通道;如果攻击者知道两个不同的用户将选择不同的通道,则可能会简洁地构造一些令人困惑的消息;然而,这是荒谬的。

This type is perfect for hiding data using steganography.

这种类型非常适合使用隐写术隐藏数据。

6. References
6. 工具书类

[1] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.

[1] Schulzrinne,H.,“具有最小控制的音频和视频会议的RTP配置文件”,RFC 1890,1996年1月。

7. Authors' Addresses
7. 作者地址

James Salsman 575 S. Rengstorff Avenue Mountain View, CA 94040-1982 US

James Salsman 575 S.伦斯托夫大道山景城,加利福尼亚州94040-1982美国

   EMail: James@bovik.org
        
   EMail: James@bovik.org
        

Harald Tveit Alvestrand UNINETT N-7034 TRONDHEIM NORWAY

挪威特隆赫姆哈拉尔德·特维特·阿尔韦斯特兰·尤尼特N-7034

   Phone: +47 73 59 70 94
   EMail: Harald.T.Alvestrand@uninett.no
        
   Phone: +47 73 59 70 94
   EMail: Harald.T.Alvestrand@uninett.no
        
8. Full Copyright Statement
8. 完整版权声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

版权所有(C)互联网协会(1999年)。版权所有。

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.

RFC编辑功能的资金目前由互联网协会提供。