[要約] 要約： RFC 5584は、Adaptive TRansform Acoustic Coding（ATRAC）ファミリーのためのRTPペイロード形式に関する規格です。 目的： ATRACファミリーの音声コーデックを使用するためのRTPペイロード形式を定義し、インターネット上での音声通信の品質を向上させることを目指しています。
Network Working Group M. Hatanaka
Request for Comments: 5584 J. Matsumoto
Category: Standards Track Sony Corporation
July 2009
RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family
Adaptive Transform Acoustic Coding（ATRAC）ファミリーのRTPペイロード形式
Abstract
概要
This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming.
このドキュメントでは、CodecsのAdaptive Transform Audio Coding（ATRAC）ファミリでエンコードされたオーディオデータの効率的かつ柔軟な輸送のためのRTPペイロード形式について説明します。CodecsのATRACファミリの最近の機能強化は、複数のチャネルを使用した高品質のオーディオコーディングをサポートしています。このドキュメントに示されているRTPペイロード形式には、データの断片化、基本冗長性測定、およびスケーラブルストリーミングのバリエーションのサポートも含まれています。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Codec-Specific Details ..........................................3
4. RTP Packetization and Transport of ATRAC-Family Streams .........4
4.1. ATRAC Frames ...............................................4
4.2. Concatenation of Frames ....................................4
4.3. Frame Fragmentation ........................................4
4.4. Transmission of Redundant Frames ...........................4
4.5. Scalable Lossless Streaming (High-Speed Transfer Mode) .....5
4.5.1. Scalable Multiplexed Streaming ......................5
4.5.2. Scalable Multi-Session Streaming ....................5
5. Payload Format ..................................................6
5.1. Global Structure of Payload Format .........................6
5.2. Usage of RTP Header Fields .................................7
5.3. RTP Payload Structure ......................................8
5.3.1. Usage of ATRAC Header Section .......................8
5.3.2. Usage of ATRAC Frames Section .......................9
6. Packetization Examples .........................................12
6.1. Example Multi-Frame Packet ................................12
6.2. Example Fragmented ATRAC Frame ............................13
7. Payload Format Parameters ......................................14
7.1. ATRAC3 Media Type Registration ............................14
7.2. ATRAC-X Media Type Registration ...........................16
7.3. ATRAC Advanced Lossless Media Type Registration ...........18
7.4. Channel Mapping Configuration Table .......................20
7.5. Mapping Media Type Parameters into SDP ....................21
7.5.1. For Media Subtype ATRAC3 ...........................21
7.5.2. For Media Subtype ATRAC-X ..........................21
7.5.3. For Media Subtype ATRAC Advanced Lossless ..........22
7.6. Offer/Answer Model Considerations .........................22
7.6.1. For All Three Media Subtypes .......................22
7.6.2. For Media Subtype ATRAC3 ...........................23
7.6.3. For Media Subtype ATRAC-X ..........................23
7.6.4. For Media Subtype ATRAC Advanced Lossless ..........23
7.7. Usage of Declarative SDP ..................................24
7.8. Example SDP Session Descriptions ..........................24
7.9. Example Offer/Answer Exchange .............................26
8. IANA Considerations ............................................28
9. Security Considerations ........................................28
10. Considerations on Correct Decoding ............................28
10.1. Verification of the Packets ..............................28
10.2. Validity Checking of the Packets .........................29
11. References ....................................................29
11.1. Normative References .....................................29
11.2. Informative References ...................................30
The ATRAC family of perceptual audio codecs is designed to address numerous needs for high-quality, low-bit-rate audio transfer. ATRAC technology can be found in many consumer and professional products and applications, including MD players, CD players, voice recorders, and mobile phones.
知覚オーディオコーデックのATRACファミリは、高品質の低ビットレートのオーディオ転送の多くのニーズに対処するように設計されています。ATRACテクノロジーは、MDプレーヤー、CDプレーヤー、音声レコーダー、携帯電話など、多くの消費者および専門的な製品やアプリケーションで見つけることができます。
Recent advances in ATRAC technology allow for multiple channels of audio to be encoded in customizable groupings. This should allow for future expansions in scaled streaming to provide the greatest flexibility in streaming any one of the ATRAC family member codecs; however, this payload format does not distinguish between the codecs on a packet level.
ATRACテクノロジーの最近の進歩により、複数の音声チャネルをカスタマイズ可能なグループ化でエンコードすることができます。これにより、Scaledストリーミングの将来の拡張が可能になり、ATRACファミリーメンバーのコーデックのいずれかをストリーミングする際の最大の柔軟性が得られます。ただし、このペイロード形式では、パケットレベルのコーデックを区別しません。
This simplified payload format contains only the basic information needed to disassemble a packet of ATRAC audio in order to decode it. There is also basic support for fragmentation and redundancy.
この簡素化されたペイロード形式には、ATRACオーディオのパケットを分解するために必要な基本情報のみが含まれています。断片化と冗長性に対する基本的なサポートもあります。
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 RFC 2119 [4].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [4]に記載されているように解釈される。
Early versions of the ATRAC codec handled only two channels of audio at 44.1 kHz sampling frequency, with typical bit-rates between 66 kbps and 132 kbps. The latest version allows for a maximum of 8 channels of audio, up to 96 kHz in sampling frequency, and a lossless encoding option that can be transmitted in either a scalable (also known as High-Speed Transfer mode) or standard (aka Standard mode) format. The feasible bit-rate range has also expanded, allowing from a low of 8 kbps up to 1400 kbps in lossy encoding modes.
ATRACコーデックの初期バージョンは、44.1 kHzサンプリング周波数で2つのチャネルのオーディオのみを処理し、典型的なビットレートは66 kbpsから132 kbpsでした。最新バージョンでは、最大8チャネルのオーディオ、サンプリング周波数が最大96 kHz、スケーラブル（高速転送モードとも呼ばれる）または標準（別名標準モード）で送信できるロスレスエンコードオプションが可能になります。） フォーマット。実行可能なビットレート範囲も拡張されており、損失のあるエンコーディングモードでは8 kbpsの最低1400 kbpsから1400 kbpsまで可能になりました。
Depending on the version of ATRAC used, the sample-frame size is either 512, 1024, or 2048 samples. While the lossy and Standard mode lossless formats are encoded as sequential single audio frames, High-Speed Transfer mode lossless data comprises two layers -- a lossy base layer and an enhancement layer.
使用するATRACのバージョンに応じて、サンプルフレームサイズは512、1024、または2048サンプルです。LosyおよびStandard Modeのロスレスフォーマットはシーケンシャルシングルオーディオフレームとしてエンコードされていますが、高速転送モードのロスレスデータは2つのレイヤーで構成されています。
Although streaming of multi-channel audio is supported depending on the ATRAC version used, all encoded audio for a given time period is contained within a single frame. Therefore, there is no interleaving nor splitting of audio data on a per-channel basis with which to be concerned.
マルチチャネルオーディオのストリーミングは使用されるATRACバージョンに応じてサポートされていますが、特定の期間のすべてのエンコードされたオーディオは、単一のフレーム内に含まれています。したがって、懸念するチャネルごとのベースでオーディオデータのインターリーブや分割はありません。
For transportation of compressed audio data, ATRAC uses the concept of frames. ATRAC frames are the smallest data unit for which timing information is attributed. Frames are octet-aligned by definition.
圧縮オーディオデータの輸送には、ATRACはフレームの概念を使用します。ATRACフレームは、タイミング情報が起因する最小のデータユニットです。フレームは、定義によりオクテットに整列されています。
It is often possible to carry multiple frames in one RTP packet. This can be useful in audio, where on a LAN with a 1500-byte MTU, an average of 7 complete 64 kbps ATRAC frames could be carried in a single RTP packet, as each ATRAC frame would be approximately 200 bytes. ATRAC frames may be of fixed or variable length. To facilitate parsing in the case of multiple frames in one RTP packet, the size of each frame is made known to the receiver by carrying "in-band" the frame size for each contained frame in an RTP packet. However, to simplify the implementation of RTP receivers, it is required that when multiple frames are carried in an RTP packet, each frame MUST be complete, i.e., the number of frames in an RTP packet MUST be integral.
多くの場合、1つのRTPパケットに複数のフレームを運ぶことができます。これは、1500バイトのMTUを搭載したLANでは、各ATRACフレームが約200バイトになるため、1つのRTPパケットで平均7つの完全な64 kbps ATRACフレームを運ぶことができるオーディオで役立ちます。ATRACフレームは、固定または可変の長さである場合があります。1つのRTPパケット内の複数のフレームの場合の解析を容易にするために、各フレームのサイズは、RTPパケットに含まれる各フレームのフレームサイズを「インバンド」することにより、受信機に知られています。ただし、RTP受信機の実装を簡素化するには、複数のフレームがRTPパケットで運ばれる場合、各フレームが完了する必要がある必要があります。つまり、RTPパケットのフレーム数は積分する必要があります。
The ATRAC codec can handle very large frames. As most IP networks have significantly smaller MTU sizes than the frame sizes ATRAC can handle, this payload format allows for the fragmentation of an ATRAC frame over multiple RTP packets. However, to simplify the implementation of RTP receivers, an RTP packet MUST carry either one or more complete ATRAC frames or a single fragment of one ATRAC frame. In other words, RTP packets MUST NOT contain fragments of multiple ATRAC frames and MUST NOT contain a mix of complete and fragmented frames.
ATRACコーデックは、非常に大きなフレームを処理できます。ほとんどのIPネットワークは、ATRACが処理できるフレームサイズよりもMTUサイズが大幅に小さくなるため、このペイロード形式により、複数のRTPパケットでATRACフレームの断片化が可能になります。ただし、RTP受信機の実装を簡素化するには、RTPパケットは、1つ以上の完全なATRACフレームまたは1つのATRACフレームの単一のフラグメントのいずれかを運ぶ必要があります。言い換えれば、RTPパケットは複数のATRACフレームのフラグメントを含めてはならず、完全な断片化されたフレームと断片化されたフレームの組み合わせを含めてはなりません。
As RTP does not guarantee reliable transmission, receipt of data is not assured. Loss of a packet can result in a "decoding gap" at the receiver. One method to remedy this problem is to allow time-shifted copies of ATRAC frames to be sent along with current data. For a modest cost in latency and implementation complexity, error resiliency to packet loss can be achieved. For further details, see Section 5.3.2.1 and [12].
RTPは信頼できる送信を保証しないため、データの受領は保証されません。パケットを失うと、受信機に「デコードギャップ」が発生する可能性があります。この問題を改善する1つの方法は、ATRACフレームのタイムシフトコピーを現在のデータとともに送信できるようにすることです。遅延と実装の複雑さの控えめなコストの場合、パケット損失に対するエラーの回復力を達成できます。詳細については、セクション5.3.2.1および[12]を参照してください。
As ATRAC supports a variation on scalable encoding, this payload format provides a mechanism for transmitting essential data (also referred to as the base layer) with its enhancement data in two ways -- multiplexed through one session or separated over two sessions.
ATRACはスケーラブルエンコーディングのバリエーションをサポートするため、このペイロード形式は、1つのセッションで多重化されるか、2つのセッションで分離された2つの方法で、その拡張データを含む重要なデータ（基本レイヤーとも呼ばれる）を送信するためのメカニズムを提供します。
In either method, only the base layer is essential in producing audio data. The enhancement layer carries the remaining audio data needed to decode lossless audio data. So in situations of limited bandwidth, the sender may choose not to transmit enhancement data yet still provide a client with enough data to generate lossily-encoded audio through the base layer.
どちらの方法でも、オーディオデータの生成には基本層のみが不可欠です。拡張レイヤーには、ロスレスオーディオデータをデコードするために必要な残りのオーディオデータが搭載されています。したがって、限られた帯域幅の状況では、送信者は、拡張データを送信しないことを選択することができますが、それでも基本レイヤーを介して損失とエンコードされたオーディオを生成するのに十分なデータをクライアントに提供することができます。
In multiplexed streaming, the base layer and enhancement layer are coupled together in each packet, utilizing only one session as illustrated in Figure 1.
多重化されたストリーミングでは、図1に示すように1つのセッションのみを使用して、各パケットに基本層と強化層が結合されます。
The packet MUST begin with the base layer, and the two layer types MUST interleave if both of the layers exist in a packet (only base or enhancement is included in a packet at the beginning of a streaming, or during the fragmentation).
パケットはベースレイヤーから開始する必要があり、2つのレイヤータイプは両方のレイヤーがパケットに存在する場合はインターリーブする必要があります（ベースまたは強化のみが、ストリーミングの開始時またはフラグメンテーション中にパケットに含まれます）。
+----------------+ +----------------+ +----------------+
|Base|Enhancement|--|Base|Enhancement|--|Base|Enhancement| ...
+----------------+ +----------------+ +----------------+
N N+1 N+2 : Packet
Figure 1. Multiplexed Structure
図1.多重化された構造
In multi-session streaming, the base layer and enhancement layer are sent over two separate sessions, allowing clients with certain bandwidth limitations to receive just the base layer for decoding as illustrated in Figure 2.
マルチセッションストリーミングでは、基本層と拡張レイヤーが2つの別々のセッションで送信され、特定の帯域幅の制限があるクライアントが図2に示すようにデコード用のベースレイヤーのみを受け取ることができます。
In this case, it is REQUIRED to determine which sessions are paired together in receiver side. For paired base and enhancement layer sessions, the CNAME bindings in the RTP Control Protocol (RTCP) session MUST be applied using the same CNAME to ensure correct mapping to the RTP source.
この場合、受信機側でどのセッションが組み合わされているかを判断する必要があります。ペアのベースおよび拡張レイヤーセッションの場合、RTPコントロールプロトコル（RTCP）セッションのCNAMEバインディングを同じCNAMEを使用して適用して、RTPソースへの正しいマッピングを確保する必要があります。
While there may be alternative methods for synchronization of the layers, the timestamp SHOULD be used for synchronizing the base layer with its enhancement. The two sessions MUST be synchronized using the information in RTCP SR packets to align the RTP timestamps.
レイヤーの同期のための代替方法があるかもしれませんが、タイムスタンプは、基本層をその強化と同期するために使用する必要があります。RTPタイムスタンプを整列させるには、RTCP SRパケットの情報を使用して2つのセッションを同期する必要があります。
If the enhancement layer's session data cannot arrive until the presentation time, the decoder MUST decode the base layer session's data only, ignoring the enhancement layer's data.
拡張レイヤーのセッションデータがプレゼンテーション時間まで到着できない場合、デコーダーは拡張レイヤーのデータを無視して、ベースレイヤーセッションのデータのみをデコードする必要があります。
Session 1:
+------+ +------+ +------+ +------+
| Base |--| Base |--| Base |--| Base | ...
+------+ +------+ +------+ +------+
N N+1 N+2 N+3 : Packet
Session 2:
+-------------+ +-------------+ +-------------+
| Enhancement |--| Enhancement |--| Enhancement | ...
+-------------+ +-------------+ +-------------+
N N+1 N+2 : Packet
Figure 2. Multi-Session Streaming
図2.マルチセッションストリーミング
The structure of ATRAC Payload is illustrated in Figure 3. The RTP payload following the RTP header contains two octet-aligned data sections.
ATRACペイロードの構造を図3に示します。RTPヘッダーに続くRTPペイロードには、2つのOctetに並ぶデータセクションが含まれています。
+------+--------------+-----------------------------+
|RTP | ATRAC Header | ATRAC Frames Section |
|Header| Section | (including redundant data) |
+------+--------------+-----------------------------+
< ---------------- RTP Packet Payload ------------- >
Figure 3. Structure of RTP Payload of ATRAC Family
図3. ATRACファミリのRTPペイロードの構造
The first data section is the ATRAC Header, containing just one header with information for the whole packet. The second section is where the encoded ATRAC frames are stored. This may contain either a single fragment of one ATRAC frame or one or more complete ATRAC frames. The ATRAC Frames Section MUST NOT be empty. When using the redundancy mechanism described in Section 5.3.2.1, the redundant frame data can be included in this section and timestamp MUST be set to the oldest redundant frame's timestamp.
最初のデータセクションはATRACヘッダーで、パケット全体の情報が1つのヘッダーのみが含まれています。2番目のセクションは、エンコードされたATRACフレームが保存される場所です。これには、1つのATRACフレームの単一のフラグメントまたは1つ以上の完全なATRACフレームが含まれる場合があります。ATRACフレームセクションは空でなければなりません。セクション5.3.2.1で説明した冗長機構を使用する場合、冗長なフレームデータをこのセクションに含めることができ、タイムスタンプは最も古い冗長フレームのタイムスタンプに設定する必要があります。
To benefit from ATRAC's High-Speed Transfer mode lossless encoding capability, the RTP payload can be split across two sessions, with one transmitting an essential base layer and the other transmitting enhancement data. However, in either case, the above structure still applies.
ATRACの高速転送モードロスレスエンコード機能の恩恵を受けるために、RTPペイロードは2つのセッションで分割でき、1つは必須ベースレイヤーを送信し、もう1つは送信する拡張データを送信できます。ただし、どちらの場合でも、上記の構造は引き続き適用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. RTP Standard Header Part
図4. RTP標準ヘッダー部品
The structure of the RTP Standard Header Part is illustrated in Figure 4.
RTP標準ヘッダー部品の構造を図4に示します。
Version(V): 2 bits Set to 2.
バージョン（v）：2に設定された2ビット。
Padding(P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end, which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit (see [1]).
パディング（P）：パディングビットが設定されている場合、パケットには、ペイロードの一部ではない1つ以上の追加のパディングオクテットが含まれています。パディングの最後のオクテットには、それ自体を含めて無視するべきパディングオクテットの数のカウントが含まれています。パディングは、固定ブロックサイズを備えた一部の暗号化アルゴリズムによって、または低層プロトコルデータユニットにいくつかのRTPパケットを運ぶために必要になる場合があります（[1]を参照）。
Extension(X): 1 bit Defined by the RTP profile used.
拡張機能（x）：使用されたRTPプロファイルによって定義された1ビット。
CSRC count(CC): 4 bits See RFC 3550 [1].
CSRCカウント（CC）：4ビットRFC 3550 [1]を参照してください。
Marker (M): 1 bit Set to 1 if the packet is the first packet after a silence period; otherwise, it MUST be set to 0.
マーカー（M）：パケットが沈黙期間後の最初のパケットである場合、1ビット設定1。それ以外の場合は、0に設定する必要があります。
Payload Type (PT): 7 bits The assignment of an RTP payload type for this packet format is outside the scope of this document; it is specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g., using the Session Description Protocol (SDP)).
ペイロードタイプ（PT）：7ビットこのパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。このペイロード形式が使用されるRTPプロファイルによって指定されているか、動的に帯域外に合図されます（たとえば、セッション説明プロトコル（SDP）を使用）。
sequence number: 16 bits A sequential number for the RTP packet. It ranges from 0 to 65535 and repeats itself periodically.
シーケンス番号：16ビットRTPパケットのシーケンシャル番号。0から65535の範囲で、定期的に繰り返されます。
Timestamp: 32 bits A timestamp representing the sampling time of the first sample of the first ATRAC frame in the current RTP packet. When using SDP, the clock rate of the RTP timestamp MUST be expressed using the "rtpmap" attribute. For ATRAC3 and ATRAC Advanced Lossless, the RTP timestamp rate MUST be 44100 Hz. For ATRAC-X, the RTP timestamp rate is 44100 Hz or 48000 Hz, and it will be selected by out-of-band signaling.
タイムスタンプ：32ビット現在のRTPパケットの最初のATRACフレームの最初のサンプルのサンプリング時間を表すタイムスタンプ。SDPを使用する場合、RTPタイムスタンプのクロックレートを「RTPMAP」属性を使用して表す必要があります。ATRAC3およびATRAC Advanced Losslessの場合、RTPタイムスタンプレートは44100 Hzでなければなりません。ATRAC-Xの場合、RTPタイムスタンプレートは44100 Hzまたは48000 Hzであり、帯域外シグナリングによって選択されます。
SSRC: 32 bits See RFC 3550 [1].
SSRC：32ビットRFC 3550 [1]を参照してください。
CSRC list: 0 to 15 items, 32 bits each See RFC 3550 [1].
CSRCリスト：0〜15項目、32ビットそれぞれRFC 3550 [1]を参照してください。
The ATRAC header section has the fixed length of one byte as illustrated in Figure 5.
ATRACヘッダーセクションの図5に示すように、1バイトの固定長があります。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|FrgNo|NFrames|
+-+-+-+-+-+-+-+-+
Figure 5. ATRAC RTP Header
図5. ATRAC RTPヘッダー
Continuation Flag (C) : 1 bit The packet that corresponds to the last part of the audio frame data in a fragmentation MUST have this bit set to 0; otherwise, it's set to 1.
継続フラグ（c）：1ビットフラグメンテーション内のオーディオフレームデータの最後の部分に対応するパケットは、このビットを0に設定する必要があります。それ以外の場合は、1に設定されています。
Fragment Number (FrgNo): 3 bits In the event of data fragmentation, this value is one for the first packet, and increases sequentially for the remaining fragmented data packets. This value MUST be zero for an unfragmented frame. (Note: 3 bits is sufficient to avoid Fragment Number rollover given the current maximum supported bit-rate in the ATRAC specification. If that changes, the choice of 3 bits for the Fragment Number should be revisited.)
フラグメント番号（FRGNO）：3ビットデータフラグメンテーションの場合、この値は最初のパケットの1つであり、残りの断片化されたデータパケットの順次増加します。この値は、フレーミングされていないフレームの場合はゼロでなければなりません。（注：ATRAC仕様で現在の最大サポートされているビットレートを考慮して、フラグメント数のロールオーバーを回避するのに3ビットで十分です。その変更があれば、フラグメント数の3ビットの選択を再検討する必要があります。）
Number of Frames (NFrames): 4 bits The number of audio frames in this packet are field value + 1. This allows for a maximum of 16 ATRAC-encoded audio frames per packet, with 0 indicating one audio frame. Each audio frame MUST be complete in the packet if fragmentation is not applied. In the case of fragmentation, the data for only one audio frame is allowed to be fragmented, and this value MUST be 0.
フレーム数（NFRAME）：4ビットこのパケットのオーディオフレームの数はフィールド値1です。これにより、パケットごとに最大16のATRACエンコードオーディオフレームが可能になり、0が1つのオーディオフレームを示します。フラグメンテーションが適用されない場合、各オーディオフレームはパケットで完了する必要があります。断片化の場合、1つのオーディオフレームのみのデータを断片化することが許可されており、この値は0でなければなりません。
The ATRAC Frames Section contains an integer number of complete ATRAC frames or a single fragment of one ATRAC frame, as illustrated in Figure 6. Each ATRAC frame is preceded by a one-bit flag indicating the layer type and a Block Length field indicating the size in bytes of the ATRAC frame. If more than one ATRAC frame is present, then the frames are concatenated into a contiguous string of bit-flag, Block Length, and ATRAC frame in order of their frame number. This section MUST NOT be empty.
ATRACフレームセクションには、図6に示すように、整数数の完全なATRACフレームまたは1つのATRACフレームの単一のフラグメントが含まれています。各ATRACフレームの前には、サイズを示すレイヤータイプとブロック長のフィールドを示す1ビットフラグが前にあります。ATRACフレームのバイト。複数のATRACフレームが存在する場合、フレームは、フレーム番号の順に、ビットフラグ、ブロック長、およびATRACフレームの連続的な文字列に連結されます。このセクションは空であってはなりません。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Block Length | ATRAC frame |...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. ATRAC Frame Section Format
図6. ATRACフレームセクション形式
Layer Type Flag (E): 1 bit Set to 1 if the corresponding ATRAC frame is from an enhancement layer. 0 indicates a base layer encoded frame.
レイヤータイプフラグ（e）：対応するATRACフレームが拡張レイヤーからの場合、1ビット設定1に設定されます。0は、ベースレイヤーエンコードされたフレームを示します。
Block length: 15 bits The byte length of encoded audio data for the following frame. This is so that in the case of fragmentation, if only a subsequent packet is received, decoding can still occur. 15 bits allows for a maximum block length of 32,767 bytes.
ブロックの長さ：15ビット次のフレームのエンコードされたオーディオデータのバイトの長さを15ビットします。これは、断片化の場合、後続のパケットのみを受信した場合でも、デコードが発生する可能性があります。15ビットでは、最大ブロック長32,767バイトが可能になります。
ATRAC frame: The encoded ATRAC audio data.
ATRACフレーム：エンコードされたATRACオーディオデータ。
This payload format provides a rudimentary scheme to compensate for occasional packet loss. As every packet's timestamp corresponds to the first audio frame regardless of whether or not it is redundant, and because we know how many frames of audio each packet encapsulates, if two successive packets are successfully transmitted, we can calculate the number of redundant frames being sent. The result gives the client a sense of how the server is responding to RTCP reports and warns it to expand its buffer size if necessary. As an example of using the Redundant Data, refer to Figures 7 and 8.
このペイロード形式は、時折のパケットの損失を補うための初歩的なスキームを提供します。すべてのパケットのタイムスタンプは冗長かどうかに関係なく最初のオーディオフレームに対応するため、各パケットがカプセル化するオーディオのフレームの数がわかっているため、2つの連続したパケットが正常に送信された場合、送信される冗長フレームの数を計算できます。その結果、クライアントは、サーバーがRTCPレポートにどのように応答しているかについての感覚を与え、必要に応じてバッファサイズを拡張するよう警告します。冗長データを使用する例として、図7および8を参照してください。
In this example, the server has determined that for the next few packets, it should send the last two frames from the previous packet due to recent RTCP reports. Thus, between packets N and N+1, there is a redundancy of two frames (of which the client may choose to dispose). The benefit arises when packets N+2 and N+3 do not arrive at all, after which eventually packet N+4 arrives with successive necessary audio frame data.
この例では、サーバーは、次のいくつかのパケットについて、最近のRTCPレポートのために以前のパケットから最後の2つのフレームを送信する必要があると判断しました。したがって、パケットnとn 1の間には、2つのフレームの冗長性があります（クライアントが処分することを選択できます）。パケットn 2とn 3がまったく到達しない場合に利点が生じ、その後、最終的にパケットn 4が必要なオーディオフレームデータを連続して到着します。
[Sender]
[送信者]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0
|-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024
|-Fr2-|-Fr3-|-Fr4-| Packet: N+2, TS=2048
|-Fr3-|-Fr4-|-Fr5-| Packet: N+3, TS=3072
|-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096
-----------> Packet "N+2" and "N+3" not arrived ------------->
[Receiver]
[受信者]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0
|-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024
|-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096
The receiver can decode from FR4 to Fr6 by using Packet "N+4" data even if the packet loss of "N+2" and "N+3" has occurred.
「N 2」と「N 3」のパケット損失が発生した場合でも、パケット「N 4」データを使用して、FR4からFR6にDecodeできます。
Figure 7. Redundant Example
図7.冗長な例
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (= start sample time of Fr1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 3 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) ATRAC frame (Fr1) data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) ATRAC frame (Fr2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | ATRAC frame (Fr3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Packet Structure Example with Redundant Data (Case of Packet "N+1")
図8.冗長データを備えたパケット構造の例（パケット "n 1"のケース）
Each RTP packet MUST contain either an integer number of ATRAC-encoded audio frames (with a maximum of 16) or one ATRAC frame fragment. In the former case, as many complete ATRAC frames as can fit in a single path-MTU SHOULD be placed in an RTP packet. However, if even a single ATRAC frame will not fit into a complete RTP packet, the ATRAC frame MUST be fragmented.
各RTPパケットには、整数数のATRACエンコードオーディオフレーム（最大16）または1つのATRACフレームフラグメントのいずれかを含める必要があります。前者の場合、単一のPath-MTUに収まるように多くの完全なATRACフレームをRTPパケットに配置する必要があります。ただし、1つのATRACフレームでも完全なRTPパケットに収まらない場合は、ATRACフレームを断片化する必要があります。
The start of a fragmented frame gets placed in its own RTP packet with its Continuation bit (C) set to one, and its Fragment Number (FragNo) set to one. As the frame must be the only one in the packet, the Number of Frames field is zero. Subsequent packets are to contain the remaining fragmented frame data, with the Fragment Number increasing sequentially and the Continuation bit (C) consistently set to one. As subsequent packets do not contain any new frames, the Number of Frames field MUST be ignored. The last packet of fragmented data MUST have the Continuation bit (C) set to zero.
断片化されたフレームの開始は、継続ビット（c）が1に設定され、フラグメント数（fragno）が1に設定された独自のRTPパケットに配置されます。フレームはパケットの唯一のものでなければならないため、フレームフィールドの数はゼロです。後続のパケットには、残りの断片化されたフレームデータが含まれ、フラグメント数が連続的に増加し、継続ビット（c）が一貫して1に設定されます。後続のパケットには新しいフレームが含まれていないため、フレームフィールドの数は無視する必要があります。断片化されたデータの最後のパケットには、継続ビット（c）がゼロに設定されている必要があります。
Packets containing related fragmented frames MUST have identical timestamps. Thus, while the Continuous bit and Fragment Number fields indicate fragmentation and a means to reorder the packets, the timestamp can be used to determine which packets go together.
関連する断片化されたフレームを含むパケットには、同一のタイムスタンプが必要です。したがって、連続ビットとフラグメント番号フィールドはフラグメンテーションとパケットを再注文する手段を示していますが、タイムスタンプを使用してどのパケットが一緒に行くかを判断できます。
Multiple encoded audio frames are combined into one packet. Note how, for this example, only base layer frames are sent redundantly, but are followed by interleaved base layer and enhancement layer frames as illustrated in Figure 9.
複数のエンコードされたオーディオフレームが1つのパケットに結合されます。この例では、基本層フレームのみが冗長に送信されますが、図9に示すように、インターリーブベースレイヤーと強化層フレームが続く方法に注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 5 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) base layer frame 1 data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) base layer frame 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | base layer frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |1| Block Length | enhancement frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | base layer frame 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |1| Block Length | enhancement frame 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Example Multi-Frame Packet
図9.マルチフレームパケットの例
The encoded audio data frame is split over three RTP packets as illustrated in Figure 10. The following points are highlighted in the example below:
エンコードされたオーディオデータフレームは、図10に示すように、3つのRTPパケットに分割されます。次のポイントを以下の例で強調表示します。
o transition from one to zero of the Continuation bit (C)
o 継続ビットの1からゼロへの移行（c）
o sequential increase in the Fragment Number
o フラグメント数の連続的な増加
Packet 1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 1 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 2 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...more enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet 3:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 3 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...the last of the enhancement data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Example Fragmented ATRAC Frame
図10.断片化されたATRACフレームの例
Certain parameters will need to be defined before ATRAC-family-encoded content can be streamed. Other optional parameters may also be defined to take advantage of specific features relevant to certain ATRAC versions. Parameters for ATRAC3, ATRAC-X, and ATRAC Advanced Lossless are defined here as part of the media subtype registration process. A mapping of these parameters into the Session Description Protocol (SDP) (RFC 4566) [2] is also provided for applications that utilize SDP. These registrations use the template defined in RFC 4288 [5] and follow RFC 4855 [6].
ATRAC-Familyエンコードコンテンツをストリーミングする前に、特定のパラメーターを定義する必要があります。特定のATRACバージョンに関連する特定の機能を活用するために、他のオプションのパラメーターを定義することもできます。ATRAC3、ATRAC-X、およびATRAC Advanced Losslessのパラメーターは、メディアサブタイプ登録プロセスの一部としてここで定義されています。セッション説明プロトコル（SDP）（RFC 4566）[2]へのこれらのパラメーターのマッピングは、SDPを利用するアプリケーションにも提供されています。これらの登録は、RFC 4288 [5]で定義されているテンプレートを使用し、RFC 4855 [6]に従います。
The data format and parameters are specified for real-time transport in RTP.
データ形式とパラメーターは、RTPでのリアルタイムトランスポートに指定されています。
The media subtype for the Adaptive TRansform Codec version 3 (ATRAC3) uses the template defined in RFC 4855 [6].
Adaptive Transform Codecバージョン3（ATRAC3）のメディアサブタイプは、RFC 4855 [6]で定義されたテンプレートを使用します。
Note, any unknown parameter MUST be ignored by the receiver.
注意してください。未知のパラメーターは、受信機によって無視する必要があります。
Type name: audio
タイプ名：オーディオ
Subtype name: ATRAC3 Required parameters:
サブタイプ名：ATRAC3必要パラメーター：
rate: Represents the sampling frequency in Hz of the original audio data. Permissible value is 44100 only.
レート：元のオーディオデータのHzのサンプリング周波数を表します。許容値は44100のみです。
baseLayer: Indicates the encoded bit-rate in kbps for the audio data to be streamed. Permissible values are 66, 105, and 132.
BASELAYER：オーディオデータがストリーミングするためのKBPSのエンコードされたビットレートを示します。許容値は66、105、および132です。
Optional parameters:
オプションのパラメーター：
ptime: See RFC 4566 [2].
PTIME：RFC 4566 [2]を参照してください。
maxptime: See RFC 4566 [2]. The frame length of ATRAC3 is 1024/44100 = 23.22...(ms), and fractional value may not be applicable for the SDP definition.
Maxptime：RFC 4566 [2]を参照してください。ATRAC3のフレーム長は1024/44100 = 23.22 ...（MS）であり、SDP定義には分数値が適用できない場合があります。
So the value of the parameter MUST be a multiple of 24 (ms) considering safe transmission.
したがって、パラメーターの値は、安全な伝送を考慮した24（MS）の倍数でなければなりません。
If this parameter is not present, the sender MAY encapsulate a maximum of 6 encoded frames into one RTP packet, in streaming of ATRAC3.
このパラメーターが存在しない場合、送信者は、ATRAC3のストリーミングで、最大6つのエンコードされたフレームを1つのRTPパケットにカプセル化する場合があります。
maxRedundantFrames: The maximum number of redundant frames that may be sent during a session in any given packet under the redundant framing mechanism detailed in the document. Allowed values are integers in the range of 0 to 15, inclusive. If this parameter is not used, a default of 15 MUST be assumed.
MaxRedUndantFrames：ドキュメントに詳述されている冗長フレーミングメカニズムの下で、特定のパケットでセッション中に送信される可能性のある冗長フレームの最大数。許可された値は、0〜15の範囲の整数です。このパラメーターが使用されていない場合、デフォルトの15を想定する必要があります。
Encoding considerations: This media type is framed and contains binary data.
考慮事項のエンコーディング：このメディアタイプはフレーム化されており、バイナリデータが含まれています。
Security considerations: This media type does not carry active content. See Section 9 of this document.
セキュリティ上の考慮事項：このメディアタイプには、アクティブなコンテンツが含まれていません。このドキュメントのセクション9を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: ATRAC3 Standard Specification [9]
公開された仕様：ATRAC3標準仕様[9]
Applications that use this media type: Audio and video streaming and conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオおよびビデオストリーミングおよび会議ツール。
Additional information: none
Magic number(s): none
File extension(s): 'at3', 'aa3', and 'omg'
Macintosh file type code(s): none
Person and email address to contact for further information:
Mitsuyuki Hatanaka
Jun Matsumoto
actech@jp.sony.com
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用に関する制限：このメディアタイプはRTPフレーミングに依存するため、RTPを介した転送に対してのみ定義されます。
Author: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
著者：hatuyuki jun matsumoto actech@jp.sony.com
Change controller: IETF AVT WG delegated from the IESG
Change Controller：IESGから委任されたIETF AVT WG
The media subtype for the Adaptive TRansform Codec version X (ATRAC-X) uses the template defined in RFC 4855 [6].
Adaptive Transform CodecバージョンX（ATRAC-X）のメディアサブタイプは、RFC 4855 [6]で定義されたテンプレートを使用します。
Note, any unknown parameter MUST be ignored by the receiver.
注意してください。未知のパラメーターは、受信機によって無視する必要があります。
Type name: audio
タイプ名：オーディオ
Subtype name: ATRAC-X
サブタイプ名：ATRAC-X
Required parameters:
必要なパラメーター：
rate: Represents the sampling frequency in Hz of the original audio data. Permissible values are 44100 and 48000.
レート：元のオーディオデータのHzのサンプリング周波数を表します。許容値は44100および48000です。
baseLayer: Indicates the encoded bit-rate in kbps for the audio data to be streamed. Permissible values are 32, 48, 64, 96, 128, 160, 192, 256, 320, and 352.
BASELAYER：オーディオデータがストリーミングするためのKBPSのエンコードされたビットレートを示します。許容値は32、48、64、96、128、160、192、256、320、および352です。
channelID: Indicates the number of channels and channel layout according to the table1 in Section 7.4. Note that this layout is different from that proposed in RFC 3551 [3]. However, as channelID = 0 defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used. Permissible values are 0, 1, 2, 3, 4, 5, 6, 7.
Channelid：セクション7.4のTable1に従って、チャネルの数とチャネルレイアウトの数を示します。このレイアウトは、RFC 3551 [3]で提案されているレイアウトとは異なることに注意してください。ただし、ChanneID = 0が曖昧なチャネルレイアウトを定義するため、[3]のセクション4.1で定義されているチャネルマッピングを使用できます。許容値は0、1、2、3、4、5、6、7です。
Optional parameters:
オプションのパラメーター：
ptime: See RFC 4566 [2].
PTIME：RFC 4566 [2]を参照してください。
maxptime: See RFC 4566 [2]. The frame length of ATRAC-X is 2048/44100 = 46.44...(ms) or 2048/48000 = 42.67...(ms), but fractional value may not be applicable for the SDP definition. So the value of the parameter MUST be a multiple of 47 (ms) or 43 (ms) considering safe transmission.
Maxptime：RFC 4566 [2]を参照してください。ATRAC-Xのフレーム長は2048/44100 = 46.44 ...（MS）または2048/48000 = 42.67 ...（MS）ですが、SDP定義には分数値が適用できない場合があります。したがって、パラメーターの値は、安全な伝送を考慮して、47（MS）または43（MS）の倍数でなければなりません。
If this parameter is not present, the sender MAY encapsulate a maximum of 16 encoded frames into one RTP packet, in streaming of ATRAC-X.
このパラメーターが存在しない場合、送信者は、ATRAC-Xのストリーミングで、最大16のエンコードフレームを1つのRTPパケットにカプセル化することができます。
maxRedundantFrames: The maximum number of redundant frames that may be sent during a session in any given packet under the redundant framing mechanism detailed in the document. Allowed values are integers in the range 0 to 15, inclusive. If this parameter is not used, a default of 15 MUST be assumed.
MaxRedUndantFrames：ドキュメントに詳述されている冗長フレーミングメカニズムの下で、特定のパケットでセッション中に送信される可能性のある冗長フレームの最大数。許可された値は、0〜15の範囲の整数です。このパラメーターが使用されていない場合、デフォルトの15を想定する必要があります。
delayMode: Indicates a desire to use low-delay features, in which case the decoder will process received data accordingly based on this value. Permissible values are 2 and 4.
DelayMode：低遅延の機能を使用したいという要望を示します。その場合、デコーダーはこの値に基づいて受信したデータを処理します。許容値は2および4です。
Encoding considerations: This media type is framed and contains binary data.
考慮事項のエンコーディング：このメディアタイプはフレーム化されており、バイナリデータが含まれています。
Security considerations: This media type does not carry active content. See Section 9 of this document.
セキュリティ上の考慮事項：このメディアタイプには、アクティブなコンテンツが含まれていません。このドキュメントのセクション9を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: ATRAC-X Standard Specification [10]
公開された仕様：ATRAC-X標準仕様[10]
Applications that use this media type: Audio and video streaming and conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオおよびビデオストリーミングおよび会議ツール。
Additional information: none
追加情報：なし
Magic number(s): none
File extension(s): 'atx', 'aa3', and 'omg'
Macintosh file type code(s): none
Person and email address to contact for further information: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
詳細については、連絡先の人とメールアドレス：hatuyuki hatanaka jun matsumoto actech@jp.sony.com
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用に関する制限：このメディアタイプはRTPフレーミングに依存するため、RTPを介した転送に対してのみ定義されます。
Author: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
著者：hatuyuki jun matsumoto actech@jp.sony.com
Change controller: IETF AVT WG delegated from the IESG
Change Controller：IESGから委任されたIETF AVT WG
The media subtype for the Adaptive TRansform Codec Lossless version (ATRAC Advanced Lossless) uses the template defined in RFC 4855 [6].
Adaptive Transform Codec Losslessバージョン（ATRAC Advanced Lossless）のメディアサブタイプは、RFC 4855で定義されているテンプレートを使用します[6]。
Note, any unknown parameter MUST be ignored by the receiver.
注意してください。未知のパラメーターは、受信機によって無視する必要があります。
Type name: audio
タイプ名：オーディオ
Subtype name: ATRAC-ADVANCED-LOSSLESS
サブタイプ名：ATRAC-Advanced-Lossless
Required parameters:
必要なパラメーター：
rate: Represents the sampling frequency in Hz of the original audio data. Permissible value is 44100 only for High-Speed Transfer mode. Any value of 24000, 32000, 44100, 48000, 64000, 88200, 96000, 176400, and 192000 can be used for Standard mode.
レート：元のオーディオデータのHzのサンプリング周波数を表します。許容値は、高速転送モードでのみ44100です。24000、32000、44100、48000、64000、88200、96000、176400、および192000の値は標準モードに使用できます。
baseLayer: Indicates the encoded bit-rate in kbps for the base layer in High-Speed Transfer mode lossless encodings.
BASELAYER：高速転送モードのロスレスエンコーディングの基本層のKBPSのエンコードされたビットレートを示します。
For Standard lossless mode, this value MUST be 0.
標準のロスレスモードの場合、この値は0でなければなりません。
The Permissible values for ATRAC3 baselayer are 66, 105, and 132. For ATRAC-X baselayer, they are 32, 48, 64, 96, 128, 160, 192, 256, 320, and 352.
ATRAC3ベースレイヤーの許容値は66、105、および132です。ATRAC-Xベースレイヤーの場合、32、48、64、96、128、160、192、256、320、および352です。
blockLength: Indicates the block length. In High-Speed Transfer mode, the value of 1024 and 2048 is used for ATRAC3 based and ATRAC-X based ATRAC Advanced Lossless streaming, respectively.
BlockLength：ブロック長を示します。高速転送モードでは、1024と2048の値は、それぞれATRAC3ベースのATRACベースのATRAC Advanced Losslessストリーミングに使用されます。
Any value of 512, 1024, and 2048 can be used for Standard mode.
512、1024、および2048の任意の値は、標準モードに使用できます。
channelID: Indicates the number of channels and channel layout according to the table1 in Section 7.4. Note that this layout is different from that proposed in RFC 3551 [3]. However, as channelID = 0 defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used in this case. Permissible values are 0, 1, 2, 3, 4, 5, 6, 7.
Channelid：セクション7.4のTable1に従って、チャネルの数とチャネルレイアウトの数を示します。このレイアウトは、RFC 3551 [3]で提案されているレイアウトとは異なることに注意してください。ただし、ChanneID = 0が曖昧なチャネルレイアウトを定義するため、[3]のセクション4.1で定義されているチャネルマッピングをこの場合に使用できます。許容値は0、1、2、3、4、5、6、7です。
ptime: See RFC 4566 [2].
PTIME：RFC 4566 [2]を参照してください。
maxptime: See RFC 4566 [2]. In streaming of ATRAC Advanced Lossless, multiple frames cannot be transmitted in a single RTP packet, as the frame size is large. So it SHOULD be regarded as the time of one encoded frame in both of the sender and the receiver side. The frame length of ATRAC Advanced Lossless is 512/44100 = 11.6...(ms), 1024/44100 = 23.22...(ms), or 2048/44100 = 46.44...(ms), but fractional value may not be applicable for the SDP definition. So the value of the parameter MUST be 12(ms), 24(ms), or 47(ms) considering safe transmission.
Maxptime：RFC 4566 [2]を参照してください。ATRAC Advanced Losslessのストリーミングでは、フレームサイズが大きいため、単一のRTPパケットで複数のフレームを送信することはできません。したがって、送信者とレシーバー側の両方で1つのエンコードされたフレームの時間と見なす必要があります。ATRAC Advanced Losslessのフレーム長は512/44100 = 11.6 ...（MS）、1024/44100 = 23.22 ...（MS）、または2048/44100 = 46.44 ...（MS）ですが、分数値はそうではない場合がありますSDP定義に適用できます。したがって、パラメーターの値は、安全な伝送を考慮して、12（MS）、24（MS）、または47（MS）でなければなりません。
Encoding considerations: This media type is framed and contains binary data.
考慮事項のエンコーディング：このメディアタイプはフレーム化されており、バイナリデータが含まれています。
Security considerations: This media type does not carry active content. See Section 9 of this document.
セキュリティ上の考慮事項：このメディアタイプには、アクティブなコンテンツが含まれていません。このドキュメントのセクション9を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: ATRAC Advanced Lossless Standard Specification [11]
公開された仕様：ATRAC Advanced Lossless標準仕様[11]
Applications that use this media type: Audio and video streaming and conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオおよびビデオストリーミングおよび会議ツール。
Additional information: none
追加情報：なし
Magic number(s): none
File extension(s): 'aal', 'aa3', and 'omg'
Macintosh file type code(s): none
Person and email address to contact for further information:
詳細については、人とメールアドレスをお問い合わせください。
Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
hatuyuki hatanaka jun matsumoto actech@jp.sony.com
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用に関する制限：このメディアタイプはRTPフレーミングに依存するため、RTPを介した転送に対してのみ定義されます。
Author: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
著者：hatuyuki jun matsumoto actech@jp.sony.com
Change controller: IETF AVT WG delegated from the IESG
Change Controller：IESGから委任されたIETF AVT WG
Table 1 explains the mapping between the channelID as passed during SDP negotiations, and the speaker mapping the value represents.
表1は、SDP交渉中に渡されたChannelIDのマッピングと、値のマッピングを表すスピーカーのマッピングを説明しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channelID | Number of | Default Speaker |
| | Channels | Mapping |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | max 64 | undefined |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 2 | front: left, right |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | front: left, right |
| | | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 4 | front: left, right |
| | | front: center |
| | | rear: surround |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 6+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | rear: center |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 7+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | side: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 1. Channel Configuration
表1.チャネル構成
The information carried in the Media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [2], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the ATRAC family of codecs, the following mapping rules according to the ATRAC codec apply.
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[2]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。SDPを使用してコーデックのATRACファミリーを採用するセッションを指定する場合、ATRACコーデックの適用に従って次のマッピングルールが適用されます。
o The Media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The Media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. ATRAC3 supports only mono or stereo signals, so a corresponding number of channels (0 or 1) MUST also be specified in this attribute.
o メディアサブタイプ（ペイロード形式名）は、エンコーディング名としてSDP "a = rtpmap"になります。ATRAC3はモノまたはステレオ信号のみをサポートするため、対応する数のチャネル（0または1）もこの属性で指定する必要があります。
o The "baseLayer" parameter goes in SDP "a=fmtp". This parameter MUST be present. "maxRedundantFrames" may follow, but if no value is transmitted, the receiver SHOULD assume a default value of "15".
o 「ベースライヤー」パラメーターは、SDP「A = FMTP」に入ります。このパラメーターが存在する必要があります。「maxredundantframes」は続く場合がありますが、値が送信されない場合、受信者はデフォルト値「15」を想定する必要があります。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
o The Media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The Media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. This SHOULD be followed by the "sampleRate" (as the RTP clock rate), and then the actual number of channels regardless of the channelID parameter.
o メディアサブタイプ（ペイロード形式名）は、エンコーディング名としてSDP "a = rtpmap"になります。これに続いて、「samplerate」（RTPクロックレートとして）、およびChannelidパラメーターに関係なく実際のチャネルの数が続きます。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the Media type string as a semicolon-separated list of parameter=value pairs. The "baseLayer" parameter MUST be the first entry on this line. The "channelID" parameter MUST be the next entry. The receiver MUST assume a default value of "15" for "maxRedundantFrames".
o 残りのパラメーターは、Parameter = valueペアのセミコロン分離リストとしてメディアタイプの文字列から直接コピーすることにより、SDP "a = fmtp"属性になります。「ベースレイヤー」パラメーターは、この行の最初のエントリでなければなりません。「ChannelID」パラメーターは次のエントリでなければなりません。レシーバーは、「maxredundantframes」の「15」のデフォルト値を想定する必要があります。
o The Media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The Media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. This MUST be followed by the "sampleRate" (as the RTP clock rate), and then the actual number of channels regardless of the channelID parameter.
o メディアサブタイプ（ペイロード形式名）は、エンコーディング名としてSDP "a = rtpmap"になります。これに続いて、「samplerate」（RTPクロックレートとして）、およびChannelidパラメーターに関係なく実際のチャネル数を使用する必要があります。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the Media type string as a semicolon-separated list of parameter=value pairs.
o 残りのパラメーターは、Parameter = valueペアのセミコロン分離リストとしてメディアタイプの文字列から直接コピーすることにより、SDP "a = fmtp"属性になります。
On this line, the parameters "baseLayer" and "blockLength" MUST be present in this order.
この行では、この順序で「ベースレイヤー」と「ブロック長さ」が存在する必要があります。
The value of "blockLength" MUST be one of 1024 and 2048, for using ATRAC3 and ATRAC-X as baselayer, respectively. If "baseLayer=0" (means standard mode), "blockLength" MUST be one of either 512, 1024, or 2048. The "channelID" parameter MUST be the next entry . The receiver MUST assume a default value of "15" for "maxRedundantFrames".
「BlockLength」の値は、それぞれBaseLayerとしてATRAC3とATRAC-Xを使用するために、1024および2048の1つでなければなりません。「BaseLayer = 0」（標準モードを意味する）の場合、「ブロック長」は512、1024、または2048のいずれかのいずれかでなければなりません。「Channelid」パラメーターは次のエントリでなければなりません。レシーバーは、「maxredundantframes」の「15」のデフォルト値を想定する必要があります。
Some options for encoding and decoding ATRAC audio data will require either or both of the sender and receiver complying with certain specifications. In order to establish an interoperable transmission framework, an Offer/Answer negotiation in SDP MUST observe the following considerations. (See [14].)
ATRACオーディオデータをエンコードおよびデコードするためのいくつかのオプションには、特定の仕様に準拠した送信者と受信機のいずれかまたは両方が必要です。相互運用可能な送信フレームワークを確立するために、SDPのオファー/回答の交渉は、次の考慮事項を遵守する必要があります。（[14]を参照。）
o Each combination of the RTP payload transport format configuration parameters (baseLayer and blockLength, sampleRate, channelID) is unique in its bit-pattern and not compatible with any other combination. When creating an offer in an application desiring to use the more advanced features (sample rates above 44100 kHz, more than two channels), the offerer SHOULD also offer a payload type containing only the lowest set of necessary requirements. If multiple configurations are of interest to the application, they may all be offered.
o RTPペイロードトランスポートフォーマット構成パラメーター（ベースレイヤーとブロック長、サンプル、Channelid）の各組み合わせは、そのビットパターンで一意であり、他の組み合わせと互換性がありません。より高度な機能（44100 kHzを超えるサンプルレート、2つ以上のチャネル）を使用したいアプリケーションでオファーを作成する場合、提供者は、必要な要件の最低セットのみを含むペイロードタイプを提供する必要があります。複数の構成がアプリケーションにとって興味深い場合、それらはすべて提供される場合があります。
o The parameters "maxptime" and "ptime" will in most cases not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP Offer/Answer handling of the "ptime" parameter is described in RFC 3264. The "maxptime" parameter MUST be handled in the same way.
o パラメーター「Maxptime」と「PTIME」は、ほとんどの場合、相互運用性に影響しません。ただし、パラメーターの設定は、アプリケーションのパフォーマンスに影響を与える可能性があります。「PTIME」パラメーターのSDPオファー/回答処理は、RFC 3264で説明されています。「MaxPtime」パラメーターも同じ方法で処理する必要があります。
o In response to an offer, downgraded subsets of "baseLayer" are possible. However, for best performance, we suggest the answer contain the highest possible values offered.
o オファーに応じて、「ベースレイヤー」の格下げされたサブセットが可能です。ただし、最高のパフォーマンスのために、答えには提供される最高の値が含まれることをお勧めします。
o In response to an offer, downgraded subsets of "sampleRate", "baseLayer", and "channelID" are possible. For best performance, an answer MUST NOT contain any values requiring further capabilities than the offer contains, but it SHOULD provide values as close as possible to those in the offer.
o 申し出に応えて、「サンプル」、「ベースレイヤー」、および「チャネル語」の格下げサブセットが可能です。最高のパフォーマンスのために、回答には、オファーに含まれるよりもさらなる機能を必要とする値を含めることはできませんが、オファーのものに可能な限り近い値を提供する必要があります。
o The "maxRedundantFrames" is a suggested minimum. This value MAY be increased in an answer (with a maximum of 15), but MUST NOT be reduced.
o 「maxredundantframes」は最低額です。この値は、回答（最大15の）で増加する可能性がありますが、減らさないでください。
o The optional parameter "delayMode" is non-negotiable. If the Answerer cannot comply with the offered value, the session MUST be deemed inoperable.
o オプションのパラメーター「DelayMode」は交渉できません。応答者が提供された価値を遵守できない場合、セッションは動作不能と見なされなければなりません。
o In response to an offer, downgraded subsets of "sampleRate", "baseLayer", and "channelID" are possible. For best performance, an answer MUST NOT contain any values requiring further capabilities than the offer contains, but it SHOULD provide values as close as possible to those in the offer.
o 申し出に応えて、「サンプル」、「ベースレイヤー」、および「チャネル語」の格下げサブセットが可能です。最高のパフォーマンスのために、回答には、オファーに含まれるよりもさらなる機能を必要とする値を含めることはできませんが、オファーのものに可能な限り近い値を提供する必要があります。
o There are no requirements when negotiating "blockLength", other than that both parties must be in agreement.
o 「BlockLength」を交渉する際には、両当事者が同意しなければならないことを除いて、要件はありません。
o The "maxRedundantFrames" is a suggested minimum. This value MAY be increased in an answer (with a maximum of 15), but MUST NOT be reduced.
o 「maxredundantframes」は最低額です。この値は、回答（最大15の）で増加する可能性がありますが、減らさないでください。
o For transmission of scalable multi-session streaming of ATRAC Advanced Lossless content, the attributes of media stream identification, group information, and decoding dependency between base layer stream and enhancement layer stream MUST be signaled in SDP by the Offer/Answer model. In this case, the attribute of
o ATRAC高度なロスレスコンテンツのスケーラブルなマルチセッションストリーミングの送信のために、メディアストリーム識別、グループ情報、およびベースレイヤーストリームと拡張層のストリーム間の依存関係の属性は、SDPでオファー/回答モデルによってシグナルを受信する必要があります。この場合、の属性
"group", "mid", and "depend" followed by the appropriate parameter MUST be used in SDP [7] [8] in order to indicate layered coding dependency. The attribute of "group" followed by "DDP" parameter is used for indicating the relationship between the base and the enhancement layer stream with decoding dependency. Each stream is identified by "mid" attribute, and the dependency of enhancement layer stream is defined by the "depend" attribute, as the enhancement layer is only useful when the base layer is available. Examples for signaling ATRAC Advanced Lossless decoding dependency are described in Sections 7.8 and 7.9.
「グループ」、「MID」、および「依存」に続いて、層状のコーディング依存性を示すために、SDP [7] [8]で適切なパラメーターを使用する必要があります。「グループ」とそれに続く「DDP」パラメーターの属性は、デコード依存関係を備えたベースと拡張層ストリームの関係を示すために使用されます。各ストリームは「Mid」属性によって識別され、拡張層ストリームの依存性は「依存」属性によって定義されます。これは、拡張層がベースレイヤーが使用可能な場合にのみ役立つためです。シグナリングATRAC Advanced Lossless Decoding依存関係の例は、セクション7.8および7.9で説明されています。
In declarative usage, like SDP in Real-Time Streaming Protocol (RTSP) [15] or Session Announcement Protocol (SAP) [16], the parameters MUST be interpreted as follows:
宣言的使用法では、リアルタイムストリーミングプロトコル（RTSP）[15]またはセッションアナウンスプロトコル（SAP）[16]のSDPなど、パラメーターは次のように解釈する必要があります。
o The payload format configuration parameters (baseLayer, sampleRate, channelID) are all declarative and a participant MUST use the configuration(s) provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types SHOULD be kept small.
o ペイロード形式の構成パラメーター（ベースレイヤー、サンプル、Channelid）はすべて宣言的であり、参加者はセッションに提供される構成を使用する必要があります。複数のRTPペイロードタイプを宣言することにより、必要に応じて複数の構成を提供できます。ただし、タイプの数は小さくする必要があります。
o Any "maxptime" and "ptime" values SHOULD be selected with care to ensure that the session's participants can achieve reasonable performance.
o セッションの参加者が合理的なパフォーマンスを達成できるようにするために、「最大」および「PTIME」値を注意して選択する必要があります。
o The attribute of "mid", "group", and "depend" MUST be used for indicating the relationship and dependency of the base layer and the enhancement layer in scalable multi-session streaming of ATRAC ADVANCED LOSSLESS content, as described in Sections 7.6, 7.8, and 7.9.
o セクション7.6で説明されているように、「MID」、「グループ」、および「依存」の属性は、基本層の関係と依存性と拡張層のスケーラブルなマルチセッションストリーミングの強化層を示すために使用する必要があります。7.8、および7.9。
Example usage of ATRAC-X with stereo at 44100 Hz:
44100 Hzのステレオを使用したATRAC-Xの使用例：
v=0 o=atrac 2465317890 2465317890 IN IP4 service.example.com s=ATRAC-X Streaming c=IN IP4 192.0.2.1/127 t=3409539540 3409543140 m=audio 49120 RTP/AVP 99 a=rtpmap:99 ATRAC-X/44100/2 a=fmtp:99 baseLayer=128; channelID=2; delayMode=2 a=maxptime:47 Example usage of ATRAC-X with 5.1 setup at 48000 Hz:
V = 0 O = ATRAC 2465317890 2465317890 IN IP4 Service.example.com S = ATRAC-XストリーミングC = IN IP4 192.0.2.1/127 T = 3409539540 3409543140 M = Audio 49120 RTP/AVP 99 A = RTPMAP：99 A = RTPMAP：/44100/2 A = FMTP：99 BaseLayer = 128;Channeid = 2;delaymode = 2 a = maxptime：47の例48000 Hzで5.1セットアップを使用したATRAC-Xの使用例：
v=0
o=atrac 2465317890 2465317890 IN IP4 service.example.com
s=ATRAC-X 5.1ch Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49120 RTP/AVP 99
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5
a=maxptime:43
Example usage of ATRAC-Advanced-Lossless in multiplexed High-Speed Transfer mode:
多重化された高速転送モードでのATRACアドバンスロスレスの使用例：
v=0
o=atrac 2465317890 2465317890 IN IP4 service.example.com
s=AAL Multiplexed Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2
a=maxptime:47
Example usage of ATRAC-Advanced-Lossless in multi-session High-Speed Transfer mode. In this case, the base layer and the enhancement layer stream are identified by L1 and L2, respectively, and L2 depends on L1 in decoding.
マルチセッション高速転送モードでのATRACアドバンスロスレスの使用例。この場合、基本層と拡張層の流れはそれぞれL1とL2によって識別され、L2はデコードのL1に依存します。
v=0 o=atrac 2465317890 2465317890 IN IP4 service.example.com s=AAL Multi Session Streaming c=IN IP4 192.0.2.1/127 t=3409539540 3409543140 a=group:DDP L1 L2 m=audio 49200 RTP/AVP 96 a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2 a=maxptime:47 a=mid:L1 m=audio 49202 RTP/AVP 97 a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2 a=maxptime:47 a=mid:L2 a=depend:97 lay L1:96 Example usage of ATRAC-Advanced-Lossless in Standard mode:
V = 0 O = ATRAC 2465317890 2465317890 IN IP4 Service.example.com S = AAL Multi Session Streaming C = In IP4 192.0.2.1/127 T = 3409539540 3409543140 A =グループ= RTPMAP：96 ATRAC-ADVANCER-LOSSLESS/44100/2 A = FMTP：96 BaseLayer = 128;BlockLength = 2048;Channelid = 2 a = maxptime：47 a = mid：l1 m = audio 49202 rtp/avp 97 a = rtpmap：97 ATRAC-ADVANCE-LOSSLESS/44100/2 A = FMTP：97 BASELAYER = 0;BlockLength = 2048;ChannelId = 2 a = maxptime：47 a = mid：l2 a =依存：97 lay l1：96標準モードでのATRACアドバンスロスレスの使用例：
m=audio 49200 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=1024; channelID=2
a=maxptime:24
The following Offer/Answer example shows how a desire to stream multi-channel content is turned down by the receiver, who answers with only the ability to receive stereo content:
次のオファー/回答の例は、マルチチャネルコンテンツをストリーミングしたいという欲求が、ステレオコンテンツを受信する機能だけで回答するレシーバーによってどのように削除されるかを示しています。
Offer:
オファー：
m=audio 49170 RTP/AVP 98 99
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=320; channelID=5
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=160; channelID=2
Answer:
答え：
m=audio 49170 RTP/AVP 99
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=160; channelID=2
The following Offer/Answer example shows the receiver answering with a selection of supported parameters:
次のオファー/回答の例は、サポートされているパラメーターの選択を使用して受信機が応答することを示しています。
Offer:
オファー：
m=audio 49170 RTP/AVP 97 98 99
a=rtpmap:97 ATRAC-X/44100/2
a=fmtp:97 baseLayer=128; channelID=2
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=128; channelID=5
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5
Answer:
答え：
m=audio 49170 RTP/AVP 97 98 a=rtpmap:97 ATRAC-X/44100/2 a=fmtp:97 baseLayer=128; channelID=2 a=rtpmap:98 ATRAC-X/44100/6 a=fmtp:98 baseLayer=128; channelID=5 The following Offer/Answer example shows an exchange in trying to resolve using ATRAC-Advanced-Lossless. The offer contains three options: multi-session High-Speed Transfer mode, multiplexed High-Speed Transfer mode, and Standard mode.
M =オーディオ49170 RTP/AVP 97 98 A = RTPMAP：97 ATRAC-X/44100/2 A = FMTP：97 BaseLayer = 128;ChanneId = 2 a = rtpmap：98 ATRAC-X/44100/6 A = FMTP：98 BaseLayer = 128;Channeid = 5次のオファー/回答の例は、ATRACがadvanced-losslessを使用して解決しようとする交換を示しています。このオファーには、マルチセッション高速転送モード、多重化された高速転送モード、標準モードの3つのオプションが含まれています。
Offer:
オファー：
// Multi-session High-Speed Transfer mode, L1 and L2 correspond to the base layer and the enhancement layer, respectively, and L2 depends on L1 in decoding.
//マルチセッション高速転送モード、L1とL2はそれぞれ塩基層と拡張層に対応し、L2はデコードのL1に依存します。
a=group:DDP L1 L2
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=132; blockLength=1024; channelID=2
a=maxptime:24
a=mid:L1
m=audio 49202 RTP/AVP 97
a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:24
a=mid:L2
a=depend:97 lay L1:96
// Multiplexed High-Speed Transfer mode
m=audio 49200 RTP/AVP 98
a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:98 baseLayer=256; blockLength=2048; channelID=2
a=maxptime:47
// Standard mode
m=audio 49200 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:47
Answer:
答え：
a=group:DDP L1 L2
m=audio 49200 RTP/AVP 94
a=rtpmap:94 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:94 baseLayer=132; blockLength=1024; channelID=2
a=maxptime:24
a=mid:L1
m=audio 49202 RTP/AVP 95
a=rtpmap:95 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:95 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:24
a=mid:L2
a=depend:95 lay L1:94
Note that the names of payload format (encoding) and Media subtypes are case-insensitive in both places. Similarly, parameter names are case-insensitive both in Media types and in the default mapping to the SDP a=fmtp attribute.
ペイロード形式（エンコード）とメディアサブタイプの名前は、両方の場所でケースに依存しないことに注意してください。同様に、パラメーター名は、メディアタイプとデフォルトのマッピングの両方で、SDP A = FMTP属性の両方でケース非感受性です。
Three new Media subtypes, audio/ATRAC3, audio/ATRAC-X, and audio/ATRAC-ADVANCED-LOSSLESS, have been registered (see Section 7).
3つの新しいメディアサブタイプ、オーディオ/ATRAC3、Audio/ATRAC-X、およびAudio/ATRAC-Advanced-Losslessが登録されています（セクション7を参照）。
The payload format as described in this document is subject to the security considerations defined in RFC 3550 [1] and any applicable profile, for example, RFC 3551 [3]. Also, the security of Media type registration MUST be taken into account as described in Section 5 of RFC 4855 [6].
このドキュメントで説明されているペイロード形式は、RFC 3550 [1]で定義されているセキュリティ上の考慮事項と、たとえばRFC 3551 [3]などの該当するプロファイルの対象となります。また、RFC 4855 [6]のセクション5で説明されているように、メディアタイプの登録のセキュリティを考慮する必要があります。
The payload for ATRAC family consists solely of compressed audio data to be decoded and presented as sound, and the standard specifications of ATRAC3, ATRAC-X, and ATRAC Advanced Lossless [9] [10] [11] strictly define the bit stream syntax and the buffer model in decoder side for each codec. So they can not carry "active content" that could impose malicious side effects upon the receiver, and they do not cause any problem of illegal resource consumption in receiver side, as far as the bit streams are conforming to their standard specifications.
ATRACファミリのペイロードは、デコードおよびサウンドとして提示される圧縮オーディオデータのみで構成され、ATRAC3、ATRAC-X、およびATRAC Advanced Losslessの標準仕様[9] [10] [11]は、ビットストリームSyntaxと各コーデックのデコーダー側のバッファモデル。そのため、レシーバーに悪意のある副作用を課す「アクティブなコンテンツ」を運ぶことができず、ビットストリームが標準仕様に準拠している限り、レシーバー側に違法な資源消費の問題を引き起こすことはありません。
This payload format does not implement any security mechanisms of its own. Confidentiality, integrity protection, and authentication have to be provided by a mechanism external to this payload format, e.g., SRTP RFC 3711 [13].
このペイロード形式は、独自のセキュリティメカニズムを実装していません。機密性、整合性保護、および認証は、このペイロード形式の外部のメカニズム、たとえばSRTP RFC 3711 [13]によって提供する必要があります。
Verification of the received encoded audio packets MUST be performed so as to ensure correct decoding of the packets. As a most primitive implementation, the comparison of the packet size and payload length can be taken into account. If the UDP packet length is longer than the RTP packet length, the packet can be accepted, but the extra bytes MUST be ignored. In case of receiving a shorter UDP packet or improperly encoded packets, the packets MUST be discarded.
受信したエンコードされたオーディオパケットの検証は、パケットの正しいデコードを確保するために実行する必要があります。最も原始的な実装として、パケットサイズとペイロード長の比較を考慮することができます。UDPパケットの長さがRTPパケットの長さよりも長い場合、パケットを受け入れることができますが、追加のバイトは無視する必要があります。短いUDPパケットまたは不適切にエンコードされたパケットを受信した場合、パケットを破棄する必要があります。
Also, validity checking of the received audio packets MUST be performed. It can be carried out by the decoding process, as the ATRAC format is designed so that the validity of data frames can be determined by decoding the algorithm. The required decoder response to a malformed frame is to discard the malformed data and conceal the errors in the audio output until a valid frame is detected and decoded. This is expected to prevent crashes and other abnormal decoder behavior in response to errors or attacks.
また、受信したオーディオパケットの有効チェックを実行する必要があります。ATRAC形式は、アルゴリズムをデコードすることでデータフレームの有効性を決定できるように設計されているため、デコードプロセスによって実行できます。不正なフレームに対する必要なデコーダー応答は、不正なデータを破棄し、有効なフレームが検出されてデコードされるまでオーディオ出力のエラーを隠すことです。これは、エラーや攻撃に応じて、クラッシュやその他の異常なデコーダーの動作を防ぐことが期待されています。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[3] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[5] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[6] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[6] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[7] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[7] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「セッション説明プロトコル（SDP）のメディアラインのグループ化」、RFC 3388、2002年12月。
[8] Schierl, T., and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[8] Schierl、T。、およびS. Wenger、「セッション説明プロトコル（SDP）の依存関係を解読するシグナリング」、RFC 5583、2009年7月。
[9] ATRAC3 Standard Specification ver.1.1, Sony Corporation, 2003.
[9] ATRAC3標準仕様Ver.1.1、Sony Corporation、2003年。
[10] ATRAC-X Standard Specification ver.1.2, Sony Corporation, 2004.
[10] ATRAC-X標準仕様Ver.1.2、Sony Corporation、2004年。
[11] ATRAC Advanced Lossless Standard Specification ver.1.1, Sony Corporation, 2007.
[11] ATRAC Advanced Lossless標準仕様Ver.1.1、Sony Corporation、2007年。
[12] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[12] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTPペイロードデータ」、RFC 2198、1997年9月。
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[13] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[14] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[15] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[16] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[16] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
Authors' Addresses
著者のアドレス
Mitsuyuki Hatanaka Sony Corporation, Japan 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
田中林ソニーコーポレーション、日本1-7-1コナン港ku東京108-0075日本
EMail: actech@jp.sony.com
Jun Matsumoto Sony Corporation, Japan 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
Matsumoto Sony Corporation、日本1-7-1 Konan Minato-Ku Tokyo 108-0075日本
EMail: actech@jp.sony.com