[要約] RFC 2586は、オーディオデータのエンコードと転送に使用されるMIMEコンテンツタイプであり、16ビットのリニアPCMデータを表現します。このRFCの目的は、オーディオデータの効率的な転送と相互運用性の向上です。

Network Working Group                                     J. Salsman
Request for Comments: 2586                             H. Alvestrand
Category: Informational                                      UNINETT
                                                            May 1999
        
                    The Audio/L16 MIME content type
        

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.

この文書では、オーディオ/ L16 MIMEタイプ、インターネットアプリケーションで使用するための合理的な品質のオーディオフォーマットを定義します。

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

可能なアプリケーション分野は、Eメール、ウェブコンテンツを提供、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タイプのセットは小さいです。それは8000サンプル/秒のサンプリングレートを持っている唯一のオーディオ/基本的なオーディオ/ 32KADPCM種類で構成されています。

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以下の料金は、1つでも音声通話のために、子音の情報を曖昧にします。例えばLPCのような一般的な圧迫は、マイクロフォン依存性および非可逆であることが知られています。これまでのところ、すべてのIETF MIMEオーディオタイプのいずれかの第二または使用LPCあたり8000個のサンプルにデフォルト。

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タイピングを使用する(例えばRFC 1867のファイルのアップロードなど)のインターネットトランスポートを使用することに関連した教育用アプリケーションのためのためには、より高い基準が求められています。

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はRTP輸送で使用するためのRFC 1890のセクション4.4.8で説明よく知っている音声フォーマット「L16」に基づいています。 L16は、2の補数表記とネットワークバイト順に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.

これは、サンプルレートとチャンネル数を変化させることによってパラメータ化されてもよいです。パラメータは、MIMEタイプヘッダに示されています。

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.

複数のオーディオチャンネルが使用されている場合は、チャンネルは1から始まり、左から右に番号が付けられています。サンプルは、連続して各チャネルからのデータストリームに入れています。低い番号のチャネルからの情報は、より高い番号のチャネルからの先行します。

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

Lは、r右CセンターSサラウンドFフロントR、リアの左

      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のセクション8.2)

4. IANA registration form for Audio/L16
オーディオ/ L16 4. IANA登録フォーム

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となるなどインターリーブは、個々の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組合の種類と、パブリックドメイン「ソックス」と「rateconv」プログラムと互換性があります。

Published specification RFC 2586

公開された仕様のRFC 2586

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

パブリックドメイン「ソックス」と「rateconv」プログラムこのメディアを使用するアプリケーションは、このタイプを受け入れます。

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

Author/Change controller James Salsman

著者/変更コントローラジェームズ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.

RFC 1890は、マルチチャンネルtranmissionから単一チャネルを再生するかを選択するようにアプリケーションを許可することに注意してください。二つの異なるユーザが異なるチャンネルを選ぶことを知っている攻撃者がconcievablyいくつかの混乱を招くメッセージを構築することができ、これは、しかし、ばかげています。

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

ジェームズSalsman 575 S. Rengstorffアベニューマウンテンビュー、カリフォルニア州94040から1982米

EMail: James@bovik.org

メールアドレス:James@bovik.org

Harald Tveit Alvestrand UNINETT N-7034 TRONDHEIM NORWAY

ハラルド・トバイット・アルベストランドUNINETT N-7034トロンハイムノルウェー

Phone: +47 73 59 70 94 EMail: Harald.T.Alvestrand@uninett.no

電話:+47 73 59 70 94 Eメール:Harald.T.Alvestrand@uninett.no

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 Editor機能のための基金は現在、インターネット協会によって提供されます。