Internet Engineering Task Force (IETF) J. Lazzaro
Request for Comments: 6295 J. Wawrzynek
Obsoletes: 4695 UC Berkeley
Category: Standards Track June 2011
ISSN: 2070-1721
RTP Payload Format for MIDI
Abstract
抽象
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695.
このメモは、MIDI（楽器のディジタルインタフェース）コマンド言語のためのリアルタイムトランスポートプロトコル（RTP）ペイロード形式について説明します。フォーマットは、法的にMIDI 1.0 DINケーブルに表示される可能性のあるすべてのコマンドを符号化します。フォーマットは、対話型（例えば、ネットワーク音楽パフォーマンスなど）アプリケーションと（例えば、ファイル・ストリーミングのような）コンテンツ配信アプリケーションに適しています。フォーマットは、ユニキャストとマルチキャストUDPおよびTCP上で使用することができる、そしてそれは、パケットロスからの優雅な回復のためのツールを定義します。 MIDIのレンダリング方法を含むストリームの動作は、セッションセットアップ中に、カスタマイズすることができます。フォーマットは、一般的なMIDI、ダウンロード可能なサウンドレベル2、および構造化されたオーディオ用MPEG 4オーディオオブジェクトの種類をサポートするために、mpeg4-ジェネリック形式のモードとして機能します。この文書はRFC 4695を廃止します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6295.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6295で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................6
1.2. Bitfield Conventions .......................................6
2. Packet Format ...................................................6
2.1. RTP Header .................................................7
2.2. MIDI Payload ..............................................11
3. MIDI Command Section ...........................................13
3.1. Timestamps ................................................14
3.2. Command Coding ............................................16
4. The Recovery Journal System ....................................22
5. Recovery Journal Format ........................................24
6. Session Description Protocol ...................................28
6.1. Session Descriptions for Native Streams ...................29
6.2. Session Descriptions for mpeg4-generic Streams ............30
6.3. Parameters ................................................33
7. Extensibility ..................................................34
8. Congestion Control .............................................35
9. Security Considerations ........................................35
10. Acknowledgements ..............................................36
11. IANA Considerations ...........................................37
11.1. rtp-midi Media Type Registration .........................38
11.1.1. Repository Request for audio/rtp-midi .............40
11.2. mpeg4-generic Media Type Registration ....................42
11.2.1. Repository Request for Mode rtp-midi for
mpeg4-generic .....................................44
11.3. asc Media Type Registration ..............................46
12. Changes from RFC 4695 .........................................48
Appendix A. The Recovery Journal Channel Chapters .................52
A.1. Recovery Journal Definitions ..............................52
A.2. Chapter P: MIDI Program Change ............................56
A.3. Chapter C: MIDI Control Change ............................57
A.3.1. Log Inclusion Rules ................................58
A.3.2. Controller Log Format ..............................59
A.3.3. Log List Coding Rules ..............................61
A.3.4. The Parameter System ...............................64
A.4. Chapter M: MIDI Parameter System ..........................66
A.4.1. Log Inclusion Rules ................................68
A.4.2. Log Coding Rules ...................................69
A.4.2.1. The Value Tool ..............................71
A.4.2.2. The Count Tool ..............................74
A.5. Chapter W: MIDI Pitch Wheel ...............................74
A.6. Chapter N: MIDI NoteOff and NoteOn ........................75
A.6.1. Header Structure ...................................77
A.6.2. Note Structures ....................................78
A.7. Chapter E: MIDI Note Command Extras .......................79
A.7.1. Note Log Format ....................................80
A.7.2. Log Inclusion Rules ................................80
A.8. Chapter T: MIDI Channel Aftertouch ........................81
A.9. Chapter A: MIDI Poly Aftertouch ..........................82
Appendix B. The Recovery Journal System Chapters ..................83
B.1. System Chapter D: Simple System Commands ..................83
B.1.1. Undefined System Commands .....................84
B.2. System Chapter V: Active Sense Command ....................87
B.3. System Chapter Q: Sequencer State Commands ................87
B.3.1. Non-Compliant Sequencers ......................89
B.4. System Chapter F: MIDI Time Code Tape Position ............90
B.4.1. Partial Frames ....................................93
B.5. System Chapter X: System Exclusive ........................94
B.5.1. Chapter Format ................................94
B.5.2. Log Inclusion Semantics .......................96
B.5.3. TCOUNT and COUNT Fields .......................99
Appendix C. Session Configuration Tools ....... ..................100
C.1. Configuration Tools: Stream Subsetting ...................101
C.2. Configuration Tools: The Journalling System ..............106
C.2.1. The j_sec Parameter ...............................106
C.2.2. The j_update Parameter ............................107
C.2.2.1. The anchor Sending Policy ..................108
C.2.2.2. The closed-loop Sending Policy .............109
C.2.2.3. The open-loop Sending Policy ...............113
C.2.3. Recovery Journal Chapter Inclusion Parameters .....114
C.3. Configuration Tools: Timestamp Semantics .................119
C.3.1. The comex Algorithm ...............................120
C.3.2. The async Algorithm ...............................121
C.3.3. The buffer Algorithm ..............................122
C.4. Configuration Tools: Packet Timing Tools .................123
C.4.1. Packet Duration Tools .............................123
C.4.2. The guardtime Parameter ...........................124
C.5. Configuration Tools: Stream Description ..................125
C.6. Configuration Tools: MIDI Rendering ......................131
C.6.1. The multimode Parameter ...........................132
C.6.2. Renderer Specification ............................133
C.6.3. Renderer Initialization ...........................135
C.6.4. MIDI Channel Mapping ..............................137
C.6.4.1. The smf_info Parameter .....................138
C.6.4.2. The smf_inline, smf_url, and smf_cid
Parameters .................................140
C.6.4.3. The chanmask Parameter .....................140
C.6.5. The audio/asc Media Type ..........................141
C.7. Interoperability .........................................143
C.7.1. MIDI Content-Streaming Applications ...............144
C.7.2. MIDI Network Musical Performance Applications .....147
Appendix D. Parameter Syntax Definitions .... ....................153
Appendix E. A MIDI Overview for Networking Specialists ...........160
E.1. Commands Types ...........................................162
E.2. Running Status ...........................................163
E.3. Command Timing ...........................................163
E.4. AudioSpecificConfig Templates for MMA Renderers ..........164
References .......................................................169
Normative References ..........................................169
Informative References ........................................170
This document obsoletes [RFC4695].
この文書では、[RFC4695]を廃止します。
The Internet Engineering Task Force (IETF) has developed a set of focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261] [RFC2326]). These tools can be combined in different ways to support a variety of real-time applications over Internet Protocol (IP) networks.
インターネットエンジニアリングタスクフォース（IETF）は、マルチメディアネットワークのための集中ツールのセットを開発しました（[RFC3550] [RFC4566] [RFC3261] [RFC2326]）。これらのツールは、インターネットプロトコル（IP）ネットワーク上でリアルタイムアプリケーションの多様性をサポートするためのさまざまな方法で組み合わせることができます。
For example, a telephony application might use the Session Initiation Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would include negotiations to agree on a common audio codec [RFC3264]. Negotiations would use the Session Description Protocol (SDP, [RFC4566]) to describe candidate codecs.
例えば、電話アプリケーションは、電話をセットアップするために、セッション開始プロトコル（SIP、[RFC3261]）を使用する場合があります。コールセットアップは一般的なオーディオコーデック[RFC3264]に同意する交渉が含まれるであろう。交渉は候補コーデックを記述するためにセッション記述プロトコル（SDP、[RFC4566]）を使用します。
After a call is set up, audio data would flow between the parties using the Real Time Protocol (RTP, [RFC3550]) under any applicable profile (for example, the Audio/Visual Profile (AVP, [RFC3551])). The tools used in this telephony example (SIP, SDP, and RTP) might be combined in a different way to support a content-streaming application, perhaps in conjunction with other tools, such as the Real Time Streaming Protocol (RTSP, [RFC2326]).
呼が設定された後、オーディオデータは、該当するプロファイル（例えば、オーディオ/ビジュアルプロファイル（AVP、[RFC3551]））の下でリアルタイムプロトコル（RTP、[RFC3550]）を使用して、当事者間を流れます。この電話の例（SIP、SDP、およびRTP）で使用されるツールは、恐らくこのようなリアルタイムストリーミングプロトコル（RTSP、[RFC2326]などの他のツールと組み合わせて、コンテンツストリーミングアプリケーションをサポートするために、別の方法で結合されるかもしれません）。
The MIDI (Musical Instrument Digital Interface) command language [MIDI] is widely used in musical applications that are analogous to the examples described above. On stage and in the recording studio, MIDI is used for the interactive remote control of musical instruments, an application similar in spirit to telephony. On web pages, Standard MIDI Files (SMFs, [MIDI]) rendered using the General MIDI standard [MIDI] provide a low-bandwidth substitute for audio streaming.
MIDI（楽器デジタルインタフェース）コマンド言語[MIDI]は広く、上述した例に類似する音楽アプリケーションで使用されています。ステージ上に記録スタジオで、MIDI楽器、電話と精神に同様のアプリケーションの対話式遠隔制御のために使用されます。ウェブページでは、スタンダードMIDIファイル（SMFは、[MIDI]）は、一般的なMIDI標準[MIDI]を使用してレンダリングオーディオストリーミングのための低帯域幅の代替を提供します。
[RFC4695] was motivated by a simple premise: if MIDI performances could be sent as RTP streams that are managed by IETF session tools, a hybridization of the MIDI and IETF application domains might occur.
[RFC4695]は、単純な前提によって動機づけられた：MIDIの演奏は、IETFセッションツールで管理されているRTPストリームとして送信することができれば、MIDIやIETFアプリケーションドメインのハイブリダイゼーションが発生する可能性があります。
For example, interoperable MIDI networking might foster network music performance applications, in which a group of musicians located at different physical locations interact over a network to perform as they would if they were located in the same room [NMP]. As a second example, the streaming community might begin to use MIDI for low-bitrate audio coding, perhaps in conjunction with normative sound-synthesis methods [MPEGSA].
たとえば、相互運用可能なMIDIネットワーキングは、異なる物理的な場所に位置ミュージシャンのグループは、彼らが同じ部屋[NMP]に位置していたかのように実行するために、ネットワーク上でやりとりするネットワーク演奏アプリケーションを、育成することがあります。第2の例として、ストリーミング・コミュニティは、おそらく規範音声合成方法[MPEGSA]と連動して、低ビットレートオーディオ符号化のためにMIDIを使用することを始めるかもしれません。
Five years after [RFC4695], these applications have not yet reached the mainstream. However, experiments in academia and industry continue. This memo, which obsoletes [RFC4695] and fixes minor errata (see Section 12), has been written in service of these experiments.
[RFC4695] 5年後には、これらのアプリケーションは、まだ主流に達していません。しかし、学界や産業界における実験が継続します。 [RFC4695]を廃止し、マイナー正誤表を修正するこのメモは、（セクション12を参照）、これらの実験のサービスに書き込まれています。
To enable MIDI applications to use RTP, this memo defines an RTP payload format and its media type. Sections 2-5 and Appendices A and B define the RTP payload format. Section 6 and Appendices C and D define the media types identifying the payload format, the parameters needed for configuration, and the utilization of the parameters in SDP.
RTPを使用するMIDIアプリケーションを可能にするために、このメモはRTPペイロードフォーマットとメディアタイプを定義します。セクション2-5および付録A及びBは、RTPペイロードフォーマットを定義します。セクション6及び付録C及びDは、ペイロード形式、設定に必要なパラメータ、およびSDPのパラメータの利用を特定のメディアタイプを定義します。
Appendix C also includes interoperability guidelines for the example applications described above: network musical performance using SIP (Appendix C.7.2) and content streaming using RTSP (Appendix C.7.1).
RTSP（付録C.7.1）を使用してSIP（付録C.7.2）を使用して演奏をネットワークおよびコンテンツストリーミング：付録Cはまた、相互運用性上述した例の用途のための指針を含みます。
Another potential application area for RTP MIDI is MIDI networking for professional audio equipment and electronic musical instruments. We do not offer interoperability guidelines for this application in this memo. However, RTP MIDI has been designed with stage and studio applications in mind, and we expect that efforts to define a stage and studio framework will rely on RTP MIDI for MIDI transport services.
RTP MIDIのための別の潜在的なアプリケーション領域は、プロオーディオ機器、電子楽器用MIDIネットワークです。私たちは、このメモでは、このアプリケーションの相互運用性ガイドラインを提供していません。しかし、RTP MIDIは念頭に置いて、ステージやスタジオアプリケーションを使用して設計された、と私たちは、ステージやスタジオのフレームワークを定義するための努力は、MIDIの輸送サービスのためのRTP MIDIに頼ることを期待しています。
Some applications may require MIDI media delivery at a certain service quality level (latency, jitter, packet loss, etc.). RTP itself does not provide service guarantees. However, applications may use lower-layer network protocols to configure the quality of the transport services that RTP uses. These protocols may act to reserve network resources for RTP flows [RFC2205] or may simply direct RTP traffic onto a dedicated "media network" in a local installation. Note that RTP and the MIDI payload format do provide tools that applications may use to achieve the best possible real-time performance at a given service level.
一部のアプリケーションでは、特定のサービス品質レベル（遅延、ジッタ、パケット損失など）でMIDIのメディア配信が必要な場合があります。 RTP自体は、サービス保証を提供していません。ただし、アプリケーションは、RTPが使用する輸送サービスの品質を設定するには、下位層のネットワーク・プロトコルを使用することができます。これらのプロトコルは、RTPのための予備ネットワークリソースに作用することができるローカルインストールでは、専用の「メディアネットワーク」に[RFC2205]またはかもしれない単に直接RTPトラフィックが流れています。 RTPとMIDIペイロード形式は、アプリケーションが特定のサービス・レベルで可能な限り最高のリアルタイム性能を達成するために使用することができますツールを提供やることに注意してください。
This memo normatively defines the syntax and semantics of the MIDI payload format. However, this memo does not define algorithms for sending and receiving packets. An ancillary document [RFC4696]
このメモは、規範的にMIDIペイロード形式の構文とセマンティクスを定義します。しかし、このメモは、パケットを送受信するためのアルゴリズムを定義していません。補助的な文書[RFC4696]
provides informative guidance on algorithms. Supplemental information may be found in related conference publications [NMP] [GRAME].
アルゴリズム上の有益なガイダンスを提供します。補足情報は、関連する会議の出版物[NMP] [GRAME]に見出すことができます。
Throughout this memo, the phrase "native stream" refers to a stream that uses the rtp-midi media type. The phrase "mpeg4-generic stream" refers to a stream that uses the mpeg4-generic media type (in mode rtp-midi) to operate in an MPEG 4 environment [RFC3640]. Section 6 describes this distinction in detail.
このメモを通じて、語句「ネイティブストリームは、」RTP-MIDIメディアタイプを使用してストリームを参照します。語句「MPEG4-ジェネリックストリームが」MPEG 4環境[RFC3640]で動作する（モードRTP-MIDI IN）MPEG4-ジェネリックメディアタイプを使用してストリームを指します。第6節は、詳細にこの区別を説明しています。
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Several bitfield coding idioms are used in this document. As most of these idioms only appear in Appendices A and B, we define them in Appendix A.1.
イディオムを符号化するいくつかのビットフィールドは、このドキュメントで使用されています。これらのイディオムのほとんどが唯一の付録AとBに表示されるように、我々は、付録A.1でそれらを定義します。
However, a few of these idioms also appear in the main text of this document. For convenience, we describe them below:
しかし、これらのイディオムのいくつかはまた、この文書の本文に表示されます。便宜上、我々はそれらを下に説明します。
o R flag bit. R flag bits are reserved for future use. Senders MUST set R bits to 0. Receivers MUST ignore R bit values.
O Rフラグビット。 Rフラグビットは将来の使用のために予約されています。送信者は、Rビット値を無視しなければならない0レシーバにRビットを設定しなければなりません。
o LENGTH field. All fields named LENGTH (as distinct from LEN) code the number of octets in the structure that contains it, including the header it resides in and all hierarchical levels below it. If a structure contains a LENGTH field, a receiver MUST use the LENGTH field value to advance past the structure during parsing, rather than use knowledge about the internal format of the structure.
OのLENGTHフィールド。 （LENとは異なり）の長さを指定されたすべてのフィールドがヘッダ内に存在し、その下のすべての階層レベルを含む、それを含む構造におけるオクテットの数コード。構造は、長さフィールドが含まれている場合、受信機は、解析中に構造体を越えて前進するLENGTHフィールド値を使用するのではなく、構造体の内部フォーマットについての知識を使用しなければなりません。
In this section, we introduce the format of RTP MIDI packets. The description includes some background information on RTP for the benefit of MIDI implementors new to IETF tools. Implementors should consult [RFC3550] for an authoritative description of RTP.
このセクションでは、RTP MIDIパケットのフォーマットをご紹介します。説明はIETFツールに新しいMIDI実装者の利益のためにRTP上のいくつかの背景情報を含んでいます。実装者はRTPの権威については、[RFC3550]を相談してください。
This memo assumes that the reader is familiar with MIDI syntax and semantics. Appendix E provides a MIDI overview, at a level of detail sufficient to understand most of this memo. Implementors should consult [MIDI] for an authoritative description of MIDI.
このメモは、読者がMIDIの構文およびセマンティクスに精通していることを前提としています。付録Eは、このメモのほとんどを理解するのに十分な詳細レベルで、MIDIの概要を説明します。実装者は、MIDIの権威については、[MIDI]を相談してください。
The MIDI payload format maps a MIDI command stream (16 voice channels + systems) onto an RTP stream. An RTP media stream is a sequence of logical packets that share a common format. Each packet consists of two parts: the RTP header and the MIDI payload. Figure 1 shows this format (vertical space delineates the header and payload).
MIDIペイロードフォーマットは、RTPストリームにMIDIコマンドストリーム（16音声チャンネル+システム）をマッピングします。 RTPメディアストリームは、共通フォーマットを共有する論理パケットのシーケンスです。 RTPヘッダとMIDIペイロード：各パケットは、2つの部分から構成されています。図1は、この形式を（垂直スペースは、ヘッダとペイロードを描く）を示します。
We describe RTP packets as "logical" packets to highlight the fact that RTP itself is not a network-layer protocol. Instead, RTP packets are mapped onto network protocols (such as unicast UDP, multicast UDP, or TCP) by an application [ALF]. The interleaved mode of the Real Time Streaming Protocol (RTSP, [RFC2326]) is an example of an RTP mapping to TCP transport, as is [RFC4571].
私たちは、RTP自体は、ネットワーク層のプロトコルではないという事実を強調するために「論理的」パケットとしてRTPパケットを説明します。代わりに、RTPパケットは、アプリケーション[ALF]によって（例えば、ユニキャストUDP、マルチキャストUDPまたはTCPのような）ネットワークプロトコルにマッピングされます。 [RFC4571]はそのままリアルタイムストリーミングプロトコル（RTSP、[RFC2326]）のインターリーブモードは、TCPトランスポートにRTPマッピングの一例です。
[RFC3550] provides a complete description of the RTP header fields. In this section, we clarify the role of a few RTP header fields for MIDI applications. All fields are coded in network byte order (big-endian).
[RFC3550]は、RTPヘッダフィールドの完全な説明を提供します。このセクションでは、MIDIアプリケーションのためのいくつかのRTPヘッダフィールドの役割を明確にします。すべてのフィールドはネットワークバイトオーダー（ビッグエンディアン）でコード化されています。
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 |P|X| CC |M| PT | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI command section ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Journal section ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 -- Packet Format
図1 - パケットフォーマット
The behavior of the 1-bit M field depends on the media type of the stream. For native streams, the M bit MUST be set to 1 if the MIDI command section has a non-zero LEN field and MUST be set to 0 otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for all packets (to conform to [RFC3640]).
1ビットMフィールドの動作は、ストリームのメディアタイプに依存します。 MIDI指令部が非ゼロLENフィールドを有しており、それ以外の場合は0に設定する必要がある場合、ネイティブストリームに対して、Mビットが1に設定しなければなりません。 MPEG4-ジェネリックストリームの場合、Mビット（[RFC3640]に適合するように）すべてのパケットのために1に設定しなければなりません。
In an RTP MIDI stream, the 16-bit sequence number field is initialized to a randomly chosen value and is incremented by one (modulo 2^16) for each packet sent in the stream. A related quantity, the 32-bit extended packet sequence number, may be computed by tracking rollovers of the 16-bit sequence number. Note that different receivers of the same stream may compute different extended packet sequence numbers, depending on when the receiver joined the session.
RTP MIDIストリームにおいて、16ビットのシーケンス番号フィールドは、ランダムに選択された値に初期化され、ストリームで送信されたパケットごとに1（モジュロ2 ^ 16）だけインクリメントされます。関連量、32ビットの拡張パケットシーケンス番号は、16ビットのシーケンス番号のロールオーバーを追跡することによって計算することができます。同じストリームの異なる受信機は、受信機がセッションに参加したときに応じて、異なる拡張パケットシーケンス番号を計算することができることに留意されたいです。
The 32-bit timestamp field sets the base timestamp value for the packet. The payload codes MIDI command timing relative to this value. The timestamp units are set by the clock rate parameter. For example, if the clock rate has a value of 44100 Hz, two packets whose base timestamp values differ by 2 seconds have RTP timestamp fields that differ by 88200.
32ビットのタイムスタンプフィールドは、パケットのためのベースのタイムスタンプ値を設定します。この値に相対的なタイミングペイロードコードMIDIコマンド。タイムスタンプユニットは、クロック・レート・パラメータで設定されています。クロック速度は44100 [Hz]の値を有する場合、例えば、そのベースタイムスタンプ値2秒だけ異なる二つのパケットは88200によって異なるRTPタイムスタンプフィールドを有します。
Note that the clock rate parameter is not encoded within each RTP MIDI packet. A receiver of an RTP MIDI stream becomes aware of the clock rate as part of the session setup process. For example, if a session management tool uses the Session Description Protocol (SDP, [RFC4566]) to describe a media session, the clock rate parameter is set using the rtpmap attribute. We show examples of session setup in Section 6.
クロック・レート・パラメータは、各RTP MIDIパケット内にコードされていないことに注意してください。 RTP MIDIストリームの受信機は、セッションセットアッププロセスの一環として、クロック・レートに気付きました。セッション管理ツールは、メディアセッションを記述するために、セッション記述プロトコル（SDP、[RFC4566]）を使用している場合、例えば、クロック・レート・パラメータはrtpmap属性を使用して設定されています。私たちは、第6節では、セッション設定の例を示しました。
For RTP MIDI streams destined to be rendered into audio, the clock rate SHOULD be an audio sample rate of 32 KHz or higher. This recommendation is due to the sensitivity of human musical perception to small timing errors in musical note sequences and due to the timbral changes that occur when two near-simultaneous MIDI NoteOns are rendered with a different timing than that desired by the content author due to clock rate quantization. RTP MIDI streams that are not destined for audio rendering (such as MIDI streams that control stage lighting) MAY use a lower clock rate but SHOULD use a clock rate high enough to avoid timing artifacts in the application.
オーディオにレンダリングされる運命RTP MIDIストリームのために、クロックレートが32 kHz以上のオーディオサンプルレートであるべきです。この勧告は、2つの近同時MIDIのNoteOnsクロックによるコンテンツ作成者によって所望のものとは異なるタイミングでレンダリングされるときに発生する音色変化に音符配列および小さなタイミング誤差に対するヒト音楽知覚の感度に起因していますレート量子化。オーディオレンダリング宛てされていないRTP MIDIストリーム（MIDIその制御段照明ストリームなど）は、より低いクロックレートを使用することができるが、アプリケーション内のアーチファクトタイミングを回避するのに十分に高いクロックレートを使用すべきです。
For RTP MIDI streams destined to be rendered into audio, the clock rate SHOULD be chosen from rates in common use in professional audio applications or in consumer audio distribution. At the time of this writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a part of a synchronized media session that includes another (non-MIDI) RTP audio stream with a clock rate of 32 KHz or higher, the RTP MIDI stream SHOULD use a clock rate that matches the clock rate of the other audio stream. However, if the RTP MIDI stream is destined to be rendered into audio, the RTP MIDI stream SHOULD NOT use a clock rate lower than 32 KHz, even if this second stream has a clock rate lower than 32 KHz.
オーディオにレンダリングされる運命RTP MIDIストリームの場合、クロック・レートは、プロフェッショナルオーディオアプリケーションや民生用オーディオ分布の一般的な使用料金から選択する必要があります。これを書いている時点で、これらのレートは、32キロヘルツ、44.1キロヘルツ、48キロヘルツ、64キロヘルツ、88.2キロヘルツ、96キロヘルツ、176.4キロヘルツ、192キロヘルツを含みます。 RTP MIDIセッションが32 kHz以上のクロック速度を有する別の（非MIDI）を含む同期したメディアセッションRTPオーディオストリームの一部である場合、RTP MIDIストリームは、のクロック速度に一致するクロックレートを使用すべきです他のオーディオストリーム。 RTP MIDIストリームがオーディオにレンダリングすることが運命づけられている場合は、RTP MIDIストリームは、この第2のストリームは32キロヘルツより低いクロックレートであっても、32キロヘルツより低いクロックレートを使用しないでください。
Timestamps of consecutive packets do not necessarily increment at a fixed rate because RTP MIDI packets are not necessarily sent at a fixed rate. The degree of packet transmission regularity reflects the underlying application dynamics. Interactive applications may vary the packet-sending rate to track the gestural rate of a human performer, whereas content-streaming applications may send packets at a fixed rate.
RTP MIDIパケットは、必ずしも一定のレートで送信されていないため、連続したパケットのタイムスタンプは、必ずしも一定の割合で増加しません。パケット送信の規則性の程度は、基礎となるアプリケーションのダイナミクスを反映しています。対話型アプリケーションは、コンテンツのストリーミングアプリケーションが固定レートでパケットを送信することができる一方で、人間の演奏者の身振り速度を追跡するためにパケット送信速度を変えることができます。
Therefore, the timestamps for two sequential RTP packets may be identical, or the second packet may have a timestamp arbitrarily larger than the first packet (modulo 2^32). Section 3 places additional restrictions on the RTP timestamps for two sequential RTP packets, as does the guardtime parameter (Appendix C.4.2).
したがって、二つの連続RTPパケットのタイムスタンプは、同一であってもよいし、第2のパケットが最初のパケット（モジュロ2 ^ 32）よりも大きい任意のタイムスタンプを有することができます。第2シーケンシャルRTPパケットのRTPタイムスタンプの3ヶ所追加制限、guardtimeパラメータがそうであるように（付録C.4.2）。
We use the term "media time" to denote the temporal duration of the media coded by an RTP packet. The media time coded by a packet is computed by subtracting the last command timestamp in the MIDI command section from the RTP timestamp (modulo 2^32). If the MIDI list of the MIDI command section of a packet is empty, the media time coded by the packet is 0 ms. Appendix C.4.1 discusses media time issues in detail.
私たちは、RTPパケットで符号化されたメディアの持続時間を示すために、「メディア時間を」という用語を使用します。パケットによって符号化されたメディア時間は、RTPタイムスタンプ（モジュロ2 ^ 32）からMIDIコマンドセクションの最後のコマンドのタイムスタンプを減算することにより計算されます。パケットのMIDIコマンドセクションのMIDIリストが空の場合は、パケットで符号化されたメディア時間は0ミリ秒です。付録C.4.1は詳細にメディア時間の問題について説明します。
We now define RTP session semantics, in the context of sessions specified using the Session Description Protocol [RFC4566]. A session description media line ("m=") specifies an RTP session. An RTP session has an independent space of 2^32 synchronization sources. Synchronization source identifiers are coded in the SSRC header field of RTP session packets. The payload types that may appear in the PT header field of RTP session packets are listed at the end of the media line.
私たちは今、セッション記述プロトコル[RFC4566]を使用して、指定されたセッションのコンテキストで、RTPセッションの意味を定義します。セッション記述メディア・ライン（「M =」）は、RTPセッションを指定します。 RTPセッションは、2 ^ 32の同期ソースの独立したスペースがあります。同期ソース識別子は、RTPセッションのパケットのSSRCヘッダフィールドに符号化されます。 RTPセッションのパケットのPTヘッダフィールドに現れるかもしれペイロードタイプは、メディア行の末尾に記載されています。
Several RTP MIDI streams may appear in an RTP session. Each stream is distinguished by a unique SSRC value and has a unique sequence number and RTP timestamp space. Multiple streams in the RTP session may be sent by a single party. Multiple parties may send streams in the RTP session. An RTP MIDI stream encodes data for a single MIDI command name space (16 voice channels + systems).
いくつかのRTP MIDIストリームは、RTPセッションで表示されることがあります。各ストリームは、ユニークなSSRC値で区別し、固有のシーケンス番号とRTPタイムスタンプスペースがあります。 RTPセッション内の複数のストリームは、単一の当事者によって送信されることがあります。複数の関係者は、RTPセッションでストリームを送信することができます。 RTP MIDIストリームは、単一のMIDIコマンド名空間（16音声チャンネル+システム）のためのデータを符号化します。
Streams in an RTP session may use different payload types or they may use the same payload type. However, each party may send, at most, one RTP MIDI stream for each payload type mapped to an RTP MIDI payload format in an RTP session. Recall that dynamic binding of payload type numbers in [RFC4566] lets a party map many payload type numbers to the RTP MIDI payload format; thus, a party may send many RTP MIDI streams in a single RTP session. Pairs of streams (unicast or multicast) that communicate between two parties in an RTP session and that share a payload type have the same association as a MIDI cable pair that cross-connects two devices in a MIDI 1.0 DIN network.
RTPセッション内のストリームは、異なるペイロード・タイプを使用してもよく、またはそれらは同じペイロードタイプを使用することができます。ただし、各当事者は、最大で、RTPセッションにおけるRTP MIDIペイロード形式にマッピングされた各ペイロードタイプのための1つのRTP MIDIストリームを送信することができます。 [RFC4566]でペイロードタイプ番号の結合がダイナミックにRTP MIDIペイロード形式にパーティーのマップ多くのペイロードタイプ番号をすることができます思い出してください。したがって、当事者は、単一のRTPセッションで多くのRTP MIDIストリームを送信することができます。 RTPセッションとその共有ペイロードタイプに二者間の通信ストリーム（ユニキャストまたはマルチキャスト）の対は、MIDI 1.0 DINのネットワーク内の2つのデバイスをクロスコネクトすることをMIDIケーブル対と同じ関連性を有しています。
The RTP session architecture described above is efficient in its use of network ports, as one RTP session (using a port pair per party) supports the transport of many MIDI name spaces (16 MIDI channels + systems). We define tools for grouping and labelling MIDI name spaces across streams and sessions in Appendix C.5 of this memo.
上記RTPセッションアーキテクチャは、1つのRTPセッション（パーティあたりポートペアを使用して）のような多くのMIDI名前空間の輸送（16 MIDIチャンネル+システム）をサポートし、ネットワークポートの使用において効率的です。私たちは、このメモの付録C.5内のストリームとセッション間のグループ化とラベリングMIDI名前空間のためのツールを定義します。
The RTP header timestamps for each stream in an RTP session have separately and randomly chosen initialization values. Receivers use the timing fields encoded in the RTP Control Protocol (RTCP, [RFC3550]) sender reports to synchronize the streams sent by a party. The SSRC values for each stream in an RTP session are also separately and randomly chosen, as described in [RFC3550]. Receivers use the CNAME field encoded in RTCP sender reports to verify that streams were sent by the same party and to detect SSRC collisions, as described in [RFC3550].
RTPセッションにおける各ストリームのRTPヘッダのタイムスタンプは、別々に、ランダムに選択された初期値を有します。レシーバは、当事者によって送信されるストリームを同期させるためにRTP制御プロトコル（RTCP、[RFC3550]）送信者レポートでエンコードされたタイミングフィールドを使用しています。 [RFC3550]で説明されるようにRTPセッションにおける各ストリームのSSRC値は、また、別々にランダムに選択されます。 [RFC3550]で説明されるように受信機は、ストリームが同一の当事者によって送信されたことを確認するとSSRC衝突を検出するためにRTCP送信者レポートにエンコードされたCNAMEフィールドを使用します。
In some applications, a receiver renders MIDI commands into audio (or into control actions, such as the rewind of a tape deck or the dimming of stage lights). In other applications, a receiver presents a MIDI stream to software programs via an Application Programming Interface (API). Appendix C.6 defines session configuration tools to specify what receivers should do with a MIDI command stream.
いくつかの用途では、受信機は、MIDIオーディオにコマンド（又は、テープデッキの巻き戻しまたはステージライトの調光等の制御動作、に）レンダリングします。他のアプリケーションでは、受信機は、アプリケーション・プログラミング・インターフェース（API）を介してソフトウェアプログラムにMIDIストリームを提示します。付録C.6は、受信機はMIDIコマンドストリームに何をすべきかを指定するには、セッション構成ツールを定義します。
If a multimedia session uses different RTP MIDI streams to send different classes of media, the streams MUST be sent over different RTP sessions. For example, if a multimedia session uses one MIDI stream for audio and a second MIDI stream to control a lighting system, the audio and lighting streams MUST be sent over different RTP sessions, each with its own media line.
マルチメディアセッションは、異なるRTP MIDIはメディアの異なるクラスを送信するためにストリームを使用している場合、ストリームは異なるRTPセッションを介して送らなければなりません。マルチメディアセッションは、オーディオ及び照明システムを制御するための第2のMIDIストリームのための1つのMIDIストリームを使用する場合、例えば、オーディオ及び照明ストリームは、それぞれが独自のメディア行と、異なるRTPセッションを介して送信されなければなりません。
Session description tools defined in Appendix C.5 let a sending party split a single MIDI name space (16 voice channels + systems) over several RTP MIDI streams. Split transport of a MIDI command stream is a delicate task because correct command stream reconstruction by a receiver depends on exact timing synchronization across the streams.
付録C.5で定義されたセッション記述ツールRTP MIDIストリームのいくつかの上に（16個の音声チャンネル+システム）送信側は、単一のMIDI名前空間を分割してみましょう。受信機による正しいコマンドストリームの再構築は、ストリーム間で正確なタイミング同期に依存するため、MIDIコマンドストリームの分割輸送はデリケートな作業です。
To support split name spaces, we define the following requirements:
分割名前空間をサポートするために、我々は次の要件を定義します。
o A party MUST NOT send several RTP MIDI streams that share a MIDI name space in the same RTP session. Instead, each stream MUST be sent from a different RTP session.
Oパーティーは同じRTPセッションでMIDIの名前空間を共有する複数のRTP MIDIストリームを送ってはいけません。代わりに、各ストリームは異なるRTPセッションから送らなければなりません。
o If several RTP MIDI streams sent by a party share a MIDI name space, all streams MUST use the same SSRC value and MUST use the same randomly chosen RTP timestamp initialization value.
OいくつかのRTP MIDIストリームた場合は、すべてのストリームが同じSSRC値を使用しなければならないし、同じランダムに選ばれたRTPタイムスタンプの初期値を使用しなければならない、パーティの共有によってMIDI名前空間を送りました。
These rules let a receiver identify streams that share a MIDI name space (by matching SSRC values) and also let a receiver accurately reconstruct the source MIDI command stream (by using RTP timestamps to interleave commands from the two streams). Care MUST be taken by senders to ensure that SSRC changes due to collisions are reflected in both streams. Receivers MUST regularly examine the RTCP CNAME fields associated with the linked streams to ensure that the assumed link is legitimate and not the result of an SSRC collision by another sender.
これらのルールは、受信機が（SSRC値を照合することによって）MIDI名前空間を共有ストリームを識別し、受信機が正確に（二つの流れからのコマンドをインターリーブするRTPタイムスタンプを使用して）ソースMIDIコマンドストリームを再構成させてみましょう。ケアは、衝突によるSSRC変化は両方のストリームに反映されることを確実にするために送信者によって取られなければなりません。レシーバは、定期的に想定したリンクは、別の送信者SSRC衝突の結果正当とされていないことを確認するためにリンクされたストリームに関連付けられたRTCP CNAMEフィールドを調べる必要があります。
Except for the special cases described above, a party may send many RTP MIDI streams in the same session. However, it is sometimes advantageous for two RTP MIDI streams to be sent over different RTP sessions. For example, two streams may need different values for RTP session-level attributes (such as the sendonly and recvonly attributes). As a second example, two RTP sessions may be needed to send two unicast streams in a multimedia session that originate on different computers (with different IP numbers). Two RTP sessions are needed in this case because transport addresses are specified on the RTP-session or multimedia-session level, not on a payload type level.
上記の特別な場合を除き、当事者は、同じセッションで多くのRTP MIDIストリームを送信することができます。しかし、2つのRTP MIDIは異なるRTPセッションを介して送信されるストリームの時には有利です。例えば、二つの流れは、（sendonlyのがrecvonly属性など）RTPセッションレベル属性の異なる値を必要とするかもしれません。第二の例として、2つのRTPセッションは、（異なるIP番号で）別のコンピュータに発信マルチメディアセッション内の2つのユニキャストストリームを送信するために必要とされるかもしれません。トランスポート・アドレスはRTPセッションまたはマルチメディア・セッションレベルではなく、ペイロードタイプレベルで指定されているので、二つのRTPセッションは、この場合に必要とされています。
On a final note, in some uses of MIDI, parties send bidirectional traffic to conduct transactions (such as file exchange). These commands were designed to work over MIDI 1.0 DIN cable networks and may be configured in a multicast topology, which uses pure "party-line" signalling. Thus, if a multimedia session ensures a multicast connection between all parties, bidirectional MIDI commands will work without additional support from the RTP MIDI payload format.
最後のノートでは、MIDIのいくつかの用途では、当事者は（そのようなファイル交換など）の取引を行うために双方向のトラフィックを送信します。これらのコマンドはMIDI 1.0 DINケーブルネットワーク上で動作するように設計された、純粋な「パーティライン」のシグナルを使用して、マルチキャストトポロジに構成することができます。マルチメディアセッションは、すべての関係者の間でマルチキャスト接続を確保している場合このように、双方向のMIDIコマンドがRTP MIDIペイロード形式からの追加支援なしで動作します。
The payload (Figure 1) MUST begin with the MIDI command section. The MIDI command section codes a (possibly empty) list of timestamped MIDI commands and provides the essential service of the payload format.
ペイロード（図1）は、MIDIコマンドセクションで開始しなければなりません。 MIDI命令部コードタイムスタンプMIDIコマンドの（おそらく空の）リストは、ペイロードフォーマットの本質的なサービスを提供します。
The payload MAY also contain a journal section. The journal section provides resiliency by coding the recent history of the stream. A flag in the MIDI command section codes the presence of a journal section in the payload.
ペイロードはジャーナル部をも含むかもしれません。ジャーナル部は、ストリームの最近の履歴を符号化することにより耐障害性を提供します。 MIDI命令部コード内のフラグペイロードにおけるジャーナル部が存在します。
Section 3 defines the MIDI command section. Sections 4 and 5 and Appendices A and B define the recovery journal, the default format for the journal section. Here, we describe how these payload sections operate in a stream in an RTP session.
第3節では、MIDIコマンドのセクションを定義します。セクション4と5と付録A及びBは、ジャーナル部のためのデフォルトの書式を回復ジャーナルを定義します。ここでは、これらのペイロード部分はRTPセッションでストリームで操作方法を説明します。
The journalling method for a stream is set at the start of a session and MUST NOT be changed thereafter. A stream may be set to use the recovery journal, to use an alternative journal format (none are defined in this memo), or not to use a journal.
ストリームのジャーナリング方法は、セッションの開始時に設定され、その後、変更してはなりません。ストリームは、（いずれもこのメモで定義されていない）別のジャーナル形式を使用する、回復ジャーナルを使用するように設定してもよいし、ジャーナルを使用しません。
The default journalling method of a stream is inferred from its transport type. Streams that use unreliable transport (such as UDP) default to using the recovery journal. Streams that use reliable transport (such as TCP) default to not using a journal. Appendix C.2.1 defines session configuration tools for overriding these defaults. For all types of transport, a sender MUST transmit an RTP packet stream with consecutive sequence numbers (modulo 2^16).
ストリームのデフォルトのジャーナリング方法は、そのトランスポート・タイプから推測されます。回復ジャーナルを使用して信頼性のない（UDPなど）の輸送デフォルトを使用するストリーム。ジャーナルを使用しないように（TCPのような）信頼性の高いトランスポートデフォルトを使用するストリーム。付録C.2.1は、これらのデフォルトを上書きするためにセッション構成ツールを定義します。輸送のすべてのタイプのために、送信側が連続したシーケンス番号（モジュロ2 ^ 16）とRTPパケットストリームを送信しなければなりません。
If a stream uses the recovery journal, every payload in the stream MUST include a journal section. If a stream does not use journalling, a journal section MUST NOT appear in a stream payload. If a stream uses an alternative journal format, the specification for the journal format defines an inclusion policy.
ストリームが回復ジャーナルを使用している場合は、ストリーム内のすべてのペイロードはジャーナル部を含まなければなりません。ストリームがジャーナリングを使用しない場合は、ジャーナル部は、ストリームペイロードに現れてはいけません。ストリームは、代替ジャーナル・フォーマットを使用する場合、ジャーナルフォーマットの仕様は、封入ポリシーを定義します。
If a stream is sent over UDP transport, the Maximum Transmission Unit (MTU) of the underlying network limits the practical size of the payload section (for example, an Ethernet MTU is 1500 octets) for applications where predictable and minimal packet transmission latency is critical. A sender SHOULD NOT create RTP MIDI UDP packets whose sizes exceed the MTU of the underlying network. Instead, the sender SHOULD take steps to keep the maximum packet size under the MTU limit.
ストリームがUDPトランスポートを介して送信される場合、基礎となるネットワークの最大送信単位（MTU）は、ペイロード部の実際の大きさを制限する（例えば、イーサネット（登録商標）MTUが1500個のオクテットで）予測可能と最小パケット伝送遅延が重要である用途のために。送信者は、サイズが基盤となるネットワークのMTUを超えたRTP MIDIのUDPパケットを作成しないでください。代わりに、送信者は、MTUの制限の下で最大パケットサイズを維持するための措置をとるべきです。
These steps may take many forms. The default closed-loop recovery journal sending policy (defined in Appendix C.2.2.2) uses RTP Control Protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size. In addition, Section 3.2 and Appendix B.5.2 provide specific tools for managing the size of packets that code MIDI System Exclusive (0xF0) commands. Appendix C.5 defines session configuration tools that may be used to split a dense MIDI name space into several UDP streams (each sent in a different RTP session, per Section 2.1) so that the payload fits comfortably into an MTU. Another option is to use TCP. Section 4.3 of [RFC4696] provides non-normative advice for packet size management.
これらの手順は、多くの形態をとることができます。 （付録C.2.2.2で定義された）デフォルトの閉ループ回復ジャーナル送信ポリシーはRTP MIDIパケットサイズを管理するために、RTP制御プロトコル（RTCP、[RFC3550]）フィードバックを使用しています。また、3.2節および付録B.5.2は、コードMIDIシステムエクスクルーシブ（0xF0が）コマンドパケットのサイズを管理するための具体的なツールを提供しています。付録C.5は、ペイロードがMTUに快適にフィットするように、いくつかのUDPストリーム（2.1節ごとに異なるRTPセッションで送信された各）に稠密MIDI名前空間を分割するために使用することができるセッション構成ツールを定義します。別のオプションは、TCPを使用することです。 [RFC4696]のセクション4.3には、パケットサイズ管理のための非規範的なアドバイスを提供します。
Figure 2 shows the format of the MIDI command section.
図2は、MIDIコマンドセクションのフォーマットを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|J|Z|P|LEN... | MIDI list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 -- MIDI Command Section
図2 - MIDIコマンドセクション
The MIDI command section begins with a variable-length header.
MIDI指令部は、可変長ヘッダで始まります。
The header field LEN codes the number of octets in the MIDI list that follow the header. If the header flag B is 0, the header is one octet long, and LEN is a 4-bit field, supporting a maximum MIDI list length of 15 octets.
ヘッダフィールドLENコードヘッダに従っMIDIリストにおけるオクテットの数。ヘッダフラグBが0の場合、ヘッダは、1つのオクテットの長さであり、LENは、15オクテットの最大MIDIリストの長さをサポートする、4ビットのフィールドです。
If B is 1, the header is two octets long, and LEN is a 12-bit field, supporting a maximum MIDI list length of 4095 octets. LEN is coded in network byte order (big-endian): the 4 bits of LEN that appear in the first header octet code the most significant 4 bits of the 12-bit LEN value.
Bが1の場合、ヘッダは2つのオクテットの長さであり、LENは4095オクテットの最大MIDIリストの長さをサポートする、12ビットのフィールドです。 12ビットのLEN値の最上位4ビットを第一のヘッダオクテットコードに表示さLENの4ビット：LENは、ネットワークバイト順（ビッグエンディアン）で符号化されます。
A LEN value of 0 is legal, and it codes an empty MIDI list.
0のLEN値は合法であり、それをコード空のMIDIリスト。
If the J header bit is set to 1, a journal section MUST appear after the MIDI command section in the payload. If the J header bit is set to 0, the payload MUST NOT contain a journal section.
Jヘッダビットが1に設定されている場合、ジャーナル部は、ペイロード内のMIDIコマンドセクションの後に現れなければなりません。 Jヘッダビットが0に設定されている場合、ペイロードはジャーナル部を含んではなりません。
We define the semantics of the P header bit in Section 3.2.
我々は、セクション3.2でPヘッダービットの意味を定義します。
If the LEN header field is nonzero, the MIDI list has the structure shown in Figure 3.
LENヘッダフィールドが非ゼロであれば、MIDIリストは、図3に示す構造を有しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 0 (1-4 octets long, or 0 octets if Z = 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 0 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 1 (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 1 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time N (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command N (0 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 -- MIDI List Structure
図3 - MIDIリスト構造
If the header flag Z is 1, the MIDI list begins with a complete MIDI command (coded in the MIDI Command 0 field in Figure 3) preceded by a delta time (coded in the Delta Time 0 field). If Z is 0, the Delta Time 0 field is not present in the MIDI list, and the command coded in the MIDI Command 0 field has an implicit delta time of 0.
ヘッダフラグZが1である場合、MIDIリスト（デルタタイム0のフィールドに符号化された）デルタ時間が先行する（図3のMIDIコマンド0フィールドに符号化された）完全なMIDIコマンドで始まります。 Zが0の場合、デルタ時間0フィールドはMIDIリストに存在しない、とMIDIコマンド0フィールドにコード化されたコマンドが0の暗黙のデルタ時間を持っています。
The MIDI list structure may also optionally encode a list of N additional complete MIDI commands, each coded in a MIDI Command K field. Each additional command MUST be preceded by a Delta Time K field, which codes the command's delta time. We discuss exceptions to the "command fields code complete MIDI commands" rule in Section 3.2.
MIDIリスト構造はまた、必要に応じてN個の追加完全なMIDIコマンド、MIDIコマンドKフィールドに符号化されたそれぞれのリストをコードすることができます。各追加のコマンドは、コード、コマンドのデルタ時間、デルタ時間Kフィールドが先行されなければなりません。私たちは、3.2節の「コマンドのフィールドコードの完全なMIDIコマンド」ルールの例外を議論します。
The final MIDI command field (i.e., the MIDI Command N field, shown in Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list MAY consist of a single delta time (encoded in the Delta Time 0 field) without an associated command (which would have been encoded in the MIDI Command 0 field). These rules enable MIDI coding features that are explained in Section 3.1. We delay the explanations because an understanding of RTP MIDI timestamps is necessary to describe the features.
MIDIリストの最後のMIDIコマンドフィールド（図3に示されている、すなわち、MIDIコマンドNフィールドは、）空であってもよいです。また、MIDIリスト（MIDIコマンド0フィールドに符号化されていたであろう）に関連するコマンドなし（デルタ時間0フィールドで符号化された）単一のデルタ時間から構成されてもよいです。これらのルールは、3.1節で説明されているMIDIコーディング機能を有効にします。 RTP MIDIタイムスタンプの理解は機能を説明する必要があるので、私たちは説明を遅らせます。
In this section, we describe how RTP MIDI encodes a timestamp for each MIDI list command. Command timestamps have the same units as RTP packet header timestamps (described in Section 2.1 and [RFC3550]). Recall that RTP timestamps have units of seconds, whose scaling is set during session configuration (see Section 6.1 and [RFC4566]).
このセクションでは、RTP MIDIは、各MIDI listコマンドのタイムスタンプをコード化する方法について説明します。コマンドタイムスタンプは（セクション2.1と[RFC3550]に記載されている）RTPパケットヘッダのタイムスタンプと同じ単位を有します。 RTPタイムスタンプは、スケーリングセッション構成（6.1節および[RFC4566]を参照）の間に設定されている秒の単位を持っていることを思い出してください。
As shown in Figure 3, the MIDI list encodes time using a compact delta time format. The RTP MIDI delta time syntax is a modified form of the MIDI File delta time syntax [MIDI]. RTP MIDI delta times use 1-4 octet fields to encode 32-bit unsigned integers. Figure 4 shows the encoded and decoded forms of delta times. Note that delta time values may be legally encoded in multiple formats; for example, there are four legal ways to encode the zero delta time (0x00, 0x8000, 0x808000, 0x80808000).
図3に示すように、MIDIリストは、コンパクトなデルタ時間形式を使用して時間をコードします。 RTP MIDIデルタ時間構文は、MIDIファイルデルタ時間構文[MIDI]の修正された形です。 RTP MIDIデルタ時間は、32ビット符号なし整数を符号化するために1-4オクテットフィールドを使用します。図4は、デルタ時間の符号化及び復号化の形態を示しています。デルタ時間値が合法的に複数のフォーマットで符号化されてもよいことに留意されたいです。例えば、ゼロのデルタ時間（0x00で、0x8000の、0x808000、0x80808000）をコードする4つの法的方法があります。
RTP MIDI uses delta times to encode a timestamp for each MIDI command. The timestamp for MIDI Command K is the summation (modulo 2^32) of the RTP timestamp and decoded delta times 0 through K. This cumulative coding technique, borrowed from MIDI File delta time coding, is efficient because it reduces the number of multi-octet delta times.
RTP MIDIは、各MIDIコマンドのタイムスタンプをエンコードするためにデルタ時間を使用しています。 MIDIコマンドKのタイムスタンプは、RTPタイムスタンプの総和（モジュロ2 ^ 32）であり、それはマルチの数を減少させるため、デルタ時間をK. 0から復号MIDIファイルデルタタイムコードから借りこの累積的な符号化技術は、効率的ですオクテットデルタ時間。
All command timestamps in a packet MUST be less than or equal to the RTP timestamp of the next packet in the stream (modulo 2^32).
パケット内のすべてのコマンドのタイムスタンプは、以下の流れ（モジュロ2 ^ 32）の次のパケットのRTPタイムスタンプに等しくなければなりません。
This restriction ensures that a particular RTP MIDI packet in a stream is uniquely responsible for encoding time, starting at the moment after the RTP timestamp encoded in the RTP packet header and ending at the moment before the final command timestamp encoded in the MIDI list. The "moment before" and "moment after" qualifiers acknowledge the "less than or equal" semantics (as opposed to "strictly less than") in the sentence above this paragraph.
この制限は、ストリーム内の特定のRTP MIDIパケットがRTPパケットヘッダ内に符号化されたRTPタイムスタンプの後の瞬間に開始し、MIDIリストに符号化された最後のコマンドのタイムスタンプ前の瞬間に終わる時間を符号化するための一意に責任があることを保証します。修飾子はこの段落上記の文では、「以下」意味論（「より厳密に小さい」とは対照的に）を認める「の後に瞬間」と「前の瞬間」。
Note that it is possible to "pad" the end of an RTP MIDI packet with time that is guaranteed to be void of MIDI commands, by setting the "Delta Time N" field of the MIDI list to the end of the void time and by omitting its corresponding "MIDI Command N" field (a syntactic construction the preamble of Section 3 expressly made legal).
ボイド時間の終わりにMIDIリストの「デルタ時間N」フィールドを設定し、で、それはコマンドMIDIの空隙であることが保証された時間で「パッド」RTP MIDIパケットの終了をすることが可能であることに注意してくださいそれに対応する「MIDIコマンドN」フィールド（第3のプリアンブルが明示法的作られた構文の建設）を省略します。
In addition, it is possible to code an RTP MIDI packet to express that a period of time in the stream is void of MIDI commands. The RTP timestamp in the header would code the start of the void time. The MIDI list of this packet would consist of a "Delta Time 0" field that coded the end of the void time. No other fields would be present in the MIDI list (a syntactic construction the preamble of Section 3 also expressly made legal).
また、ストリームにおける時間の期間はMIDIコマンドの空隙であることを表現するためにRTP MIDIパケットを符号化することが可能です。ヘッダ内のRTPタイムスタンプは、ボイド時間の開始をコーディングします。このパケットのMIDIリストは、ボイド時間の終わりにコード化された「デルタ時間0」のフィールドで構成されます。他のフィールドは（構文的な建設も明確に法的作られた第3節の前文）MIDIリストに存在しないであろう。
By default, a command timestamp indicates the execution time for the command. The difference between two timestamps indicates the time delay between the execution of the commands. This difference may be zero, coding simultaneous execution. In this memo, we refer to this interpretation of timestamps as "comex" (COMmand EXecution) semantics. We formally define comex semantics in Appendix C.3.
デフォルトでは、コマンドのタイムスタンプは、コマンドの実行時間を示します。 2つのタイムスタンプの違いは、コマンドの実行の間の時間遅延を示しています。この違いは、同時実行をコーディング、0であってもよいです。このメモでは、私たちは、「COMEX」（コマンド実行）セマンティクスとしてタイムスタンプのこの解釈を参照してください。私たちは、正式には付録C.3でCOMEX意味を定義します。
The comex interpretation of timestamps works well for transcoding a Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a timestamp for each MIDI command stored in the file. To transcode an SMF that uses metric time markers, use the SMF tempo map (encoded in the SMF as meta-events) to convert metric SMF timestamp units into seconds-based RTP timestamp units.
タイムスタンプのCOMEX解釈のSMFコードファイルに格納された各MIDIコマンドのタイムスタンプとして、RTP MIDIストリームに標準MIDIファイル（SMF）をトランスコードするためにうまく働きます。メートル時間マーカーを使用してSMFをトランスコードするために、秒ベースのRTPタイムスタンプユニットにメトリックSMFタイムスタンプの単位を変換する（メタイベントとしてSMFに符号化）SMFのテンポマップを使用します。
The comex interpretation also works well for MIDI hardware controllers that are coding raw sensor data directly onto an RTP MIDI stream. Note that this controller design is preferable to a design that converts raw sensor data into a MIDI 1.0 cable command stream and then transcodes the stream onto an RTP MIDI stream.
COMEX解釈はまた、RTP MIDIストリームに直接生のセンサデータをコーディングしているMIDIのハードウェアコントローラに適しています。このコントローラ設計はMIDI 1.0ケーブルコマンドストリームに生のセンサデータを変換した後、RTP MIDIストリームにストリームをトランスコード設計することが好ましいことに留意されたいです。
The comex interpretation of timestamps is usually not the best timestamp interpretation for transcoding a MIDI source that uses implicit command timing (such as MIDI 1.0 DIN cables) into an RTP MIDI stream. Appendix C.3 defines alternatives to comex semantics and describes session configuration tools for selecting the timestamp interpretation semantics for a stream.
タイムスタンプのCOMEX解釈は通常、RTP MIDIストリームに（例えばMIDI 1.0 DINケーブルなど）暗黙コマンドのタイミングを使用するMIDIソースをトランスコードするための最良のタイムスタンプの解釈ではありません。付録C.3は、COMEXのセマンティクスに代わるものを定義し、ストリームのためのタイムスタンプ解釈セマンティクスを選択するためのセッション構成ツールについて説明します。
One-Octet Delta Time:
1オクテットデルタ時間：
Encoded form: 0ddddddd Decoded form: 00000000 00000000 00000000 0ddddddd
エンコード形式：00000000 00000000 00000000 0ddddddd：デコードフォームを0ddddddd
Two-Octet Delta Time:
2オクテットデルタ時間：
Encoded form: 1ccccccc 0ddddddd Decoded form: 00000000 00000000 00cccccc cddddddd
エンコード形式：00000000 00000000 00cccccc cddddddd：1cccccccは、復号されたフォームを0ddddddd
Three-Octet Delta Time:
三オクテットデルタ時間：
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 00000000 000bbbbb bbcccccc cddddddd
エンコード形式：1bbbbbbb 1ccccccc 0dddddddデコード形式：00000000 000bbbbb bbccccccのcddddddd
Four-Octet Delta Time:
4オクテットデルタ時間：
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
エンコード形式：1aaaaaaa 1bbbbbbb 1ccccccc 0dddddddデコード形式：0000aaaa aaabbbbb bbcccccc cddddddd
Figure 4 -- Decoding Delta Time Formats
図4 - デコードデルタ時刻の書式
Each non-empty MIDI Command field in the MIDI list codes one of the MIDI command types that may legally appear on a MIDI 1.0 DIN cable. Standard MIDI File meta-events do not fit this definition and MUST NOT appear in the MIDI list. As a rule, each MIDI Command field codes a complete command, in the binary command format defined in [MIDI]. In the remainder of this section, we describe exceptions to this rule.
MIDIリストのコード内の各非空のMIDIコマンドのフィールド法的MIDI 1.0 DINケーブルに表示されることがありMIDIコマンドタイプのいずれか。スタンダードMIDIファイルのメタイベントは、この定義に適合しないとMIDIリストに現れてはいけません。原則として、各MIDIコマンドのフィールドコード[MIDI]で定義されたバイナリ命令形式の完全なコマンド、。このセクションの残りの部分では、我々は、この規則の例外について説明します。
The first MIDI channel command in the MIDI list MUST include a status octet. Running status coding, as defined in [MIDI], MAY be used for all subsequent MIDI channel commands in the list. As in [MIDI], System Common and System Exclusive messages (0xF0 ... 0xF7) cancel the running status state, but System Real-Time messages (0xF8 ... 0xFF) do not affect the running status state. All system commands in the MIDI list MUST include a status octet.
MIDIリストの最初のMIDIチャンネルコマンドは状態八重奏を含まなければなりません。ステータスコード化を実行すると、[MIDI]で定義されるように、リスト内の後続のすべてのMIDIチャンネルのコマンドのために使用されるかもしれません。 [MIDI]のように、システムコモン、システム・エクスクルーシブ・メッセージは、（0xF0が... 0xF7）を実行しているステータス状態を解除するが、システムリアルタイムメッセージ（0xF8 ...は0xFF）が実行されているステータス状態には影響を与えません。 MIDIリストのすべてのシステムコマンドは状態八重奏を含まなければなりません。
As we note above, the first channel command in the MIDI list MUST include a status octet. However, the corresponding command in the original MIDI source data stream might not have a status octet (in this case, the source would be coding the command using running status). If the status octet of the first channel command in the MIDI list does not appear in the source data stream, the P (phantom) header bit MUST be set to 1. In all other cases, the P bit MUST be set to 0.
我々は上記の注意として、MIDIリストの最初のチャネルコマンドは状態八重奏を含まなければなりません。しかし、元のMIDIソース・データ・ストリームに対応するコマンドがステータスオクテットを持っていないかもしれない（この場合、ソースは、実行中の状態を使用してコマンドをコーディングするであろう）。 MIDIリストの最初のチャネルコマンドのステータスオクテットがソース・データ・ストリームに表示されない場合、P（ファントム）ヘッダビットは、他のすべての場合において1に設定しなければなりません、Pビットが0に設定しなければなりません。
Note that the P bit describes the MIDI source data stream, not the MIDI list encoding; regardless of the state of the P bit, the MIDI list MUST include the status octet.
PビットがMIDIソース・データ・ストリームではなく、MIDIリスト符号化を記述していることに注意してください。かかわらず、Pビットの状態の、MIDIリストは状態八重奏を含まなければなりません。
As receivers MUST be able to decode running status, sender implementors should feel free to use running status to improve bandwidth efficiency. However, senders SHOULD NOT introduce timing jitter into an existing MIDI command stream through an inappropriate use or removal of running status coding. This warning primarily applies to senders whose RTP MIDI streams may be transcoded onto a MIDI 1.0 DIN cable [MIDI] by the receiver: both the timestamps and the command coding (running status or not) must comply with the physical restrictions of implicit time coding over a slow serial line.
受信機が運転状態をデコードできなければならないとして、送信側の実装は、帯域幅の効率を改善するために、実行中のステータスを使用して自由に感じるはずです。ただし、送信者は、ステータスコード化を実行しているの不適切な使用または除去することにより、既存のMIDIコマンドストリームにタイミングジッタを導入すべきではありません。暗黙時間にわたってコーディングの物理的制限に従わなければならないタイムスタンプとコマンドコーディング（ステータスを実行していない）の両方：この警告は、主に、そのRTP MIDIストリームを受信することによってMIDI 1.0 DINケーブル[MIDI]にトランスコードすることができる送信者に適用されます遅いシリアルライン。
On a MIDI 1.0 DIN cable [MIDI], a System Real-Time command may be embedded inside of another "host" MIDI command. This syntactic construction is not supported in the payload format: a MIDI Command field in the MIDI list codes exactly one MIDI command (partially or completely).
MIDI 1.0 DINケーブル[MIDI]で、システムのリアルタイムコマンドは、別の「ホスト」MIDIコマンドの内部に埋め込まれていてもよいです。正確に一つのMIDIコマンド（部分的または完全に）MIDIリストコードにMIDIコマンド・フィールド：この構文構造は、ペイロード形式でサポートされていません。
To encode an embedded System Real-Time command, senders MUST extract the command from its host and code it in the MIDI list as a separate command. The host command and System Real-Time command SHOULD appear in the same MIDI list. The delta time of the System Real-Time command SHOULD result in a command timestamp that encodes the System Real-Time command placement in its original embedded position.
組込みシステムのリアルタイムコマンドを符号化するために、送信者は、そのホストからのコマンドを抽出し、別のコマンドとしてMIDIリストでそれをコード化しなければなりません。ホスト・コマンドとシステムリアルタイムコマンドは、同じMIDIリストに表示されます。システムリアルタイムコマンドのデルタ時間は、元の埋め込み位置でのシステムのリアルタイムコマンドの配置を符号化するコマンドのタイムスタンプを生じるはずです。
Two methods are provided for encoding MIDI System Exclusive (SysEx) commands in the MIDI list. A SysEx command may be encoded in a MIDI Command field verbatim: a 0xF0 octet, followed by an arbitrary number of data octets, followed by a 0xF7 octet.
二つの方法がMIDIリストにMIDIシステムエクスクルーシブ（システムエクスクルーシブ）コマンドを符号化するために設けられています。 0xF0がオクテット、データオクテットの任意の数、続い0xF7オクテット続く：のSysExコマンドはそのままMIDIコマンドフィールドに符号化されてもよいです。
Alternatively, a SysEx command may be encoded as multiple segments. The command is divided into two or more SysEx command segments; each segment is encoded in its own MIDI Command field in the MIDI list.
代替的に、システムエクスクルーシブコマンドは、複数のセグメントとして符号化することができます。コマンドは、2つの以上のSysExコマンドセグメントに分割されます。各セグメントは、MIDIリストに独自のMIDIコマンドフィールドに符号化されます。
The payload format supports segmentation in order to encode SysEx commands that encode information in the temporal pattern of data octets. By encoding these commands as a series of segments, each data octet may be associated with a distinct delta time. Segmentation also supports the coding of large SysEx commands across several packets.
ペイロード・フォーマットは、データオクテットの時間的パターンで情報をエンコードするのSysExコマンドを符号化するためにセグメンテーションをサポートします。一連のセグメントとして、これらのコマンドを符号化することによって、各データオクテットは、異なるデルタ時間に関連付けることができます。セグメンテーションはまた、いくつかのパケット間で大規模なシステムエクスクルーシブコマンドのコーディングをサポートしています。
To segment a SysEx command, first partition its data octet list into two or more sublists. The last sublist MAY be empty (i.e., contain no octets); all other sublists MUST contain at least one data octet. To complete the segmentation, add the status octets defined in Figure 5 to the head and tail of the first, last, and any "middle" sublists. Figure 6 shows example segmentations of a SysEx command.
二つ以上のサブリストに分割のSysExコマンド、最初のパーティションのデータオクテットリストに。最後のサブリストが空であってもよい（すなわち、何オクテットを含みません）。他のすべてのサブリストは、少なくとも1つのデータオクテットを含まなければなりません。セグメンテーションを完了するには、最初の最後、および任意の「ミドル」サブリストの先頭と末尾に、図5で定義されたステータスオクテットを追加します。図6は、システムエクスクルーシブコマンドの例のセグメント化を示します。
A sender MAY cancel a segmented SysEx command transmission that is in progress by sending the "cancel" sublist shown in Figure 5. A "cancel" sublist MAY follow a "first" or "middle" sublist in the transmission but MUST NOT follow a "last" sublist. The cancel MUST be empty (thus, 0xF7 0xF4 is the only legal cancel sublist).
送信者は、図5（a）に示す「キャンセル」サブリストは、サブリストは、送信の「第1」または「中」のサブリストに従うことができるが、「フォローしてはいけません「キャンセル」送信することによって、進行中のセグメント化されたSysExコマンド送信を取り消すことができます最後の」サブリスト。キャンセル（従って、0xF7 0xF4のみ合法キャンセルサブリストである）空でなければなりません。
The cancellation feature is needed because Appendix C.1 defines configuration tools that let session parties exclude certain SysEx commands in the stream. Senders that transcode a MIDI source onto an RTP MIDI stream under these constraints have the responsibility of excluding undesired commands from the RTP MIDI stream.
付録C.1は、セッションの当事者は、ストリーム内の特定のSysExコマンドを除外してみましょう設定ツールを定義するためのキャンセル機能が必要とされています。これらの制約の下でRTP MIDIストリームにMIDIソースをトランスコード送信者は、RTP MIDIストリームから望ましくないコマンドを排除する責任があります。
The cancellation feature lets a sender start the transmission of a command before the MIDI source has sent the entire command. If a sender determines that the command whose transmission is in progress should not appear on the RTP stream, it cancels the command. Without a method for cancelling a SysEx command transmission, senders would be forced to use a high-latency store-and-forward approach to transcoding SysEx commands onto RTP MIDI packets, in order to validate each SysEx command before transmission.
キャンセル機能は、MIDIソースが全体のコマンドを送信した前に、送信者がコマンドの送信を開始することができます。送信者は、その伝送進行中のコマンドは、RTPストリームに表示されてはならないと判断した場合には、コマンドをキャンセルします。システムエクスクルーシブコマンド送信をキャンセルする方法がなければ、送信者は、トランスコーディングシステムエクスクルーシブを送信する前に、それぞれのSysExコマンドを検証するために、RTP MIDIパケットにコマンドに高遅延ストアアンドフォワード手法を使用することを余儀なくされるであろう。
The recommended receiver reaction to a cancellation depends on the capabilities of the receiver. For example, a sound synthesizer that is directly parsing RTP MIDI packets and rendering them to audio will be aware of the fact that SysEx commands may be cancelled in RTP MIDI. These receivers SHOULD detect a SysEx cancellation in the MIDI list and act as if they had never received the SysEx command.
キャンセルに推奨レシーバー反応は、受信機の能力に依存します。例えば、直接オーディオにそれらをRTP MIDIパケットを解析し、レンダリングされた音シンセサイザは、システムエクスクルーシブコマンドはRTP MIDIでキャンセルすることができるという事実に気付くであろう。これらの受信機はMIDIリストにシステムエクスクルーシブキャンセルを検出して、システムエクスクルーシブコマンドを受信したことがなかったかのように行動しなければなりません。
As a second example, a synthesizer may be receiving MIDI data from an RTP MIDI stream via a MIDI DIN cable (or a software API emulation of a MIDI DIN cable). In this case, an RTP-MIDI-aware system receives the RTP MIDI stream and transcodes it onto the MIDI DIN cable (or its emulation). Upon the receipt of the cancel sublist, the RTP-MIDI-aware transcoder might have already sent the first part of the SysEx command on the MIDI DIN cable to the receiver.
第2の例として、シンセサイザはMIDI DINケーブル（またはMIDI DINケーブルのソフトウェアAPIエミュレーション）を介してRTP MIDIストリームからMIDIデータを受信することができます。この場合には、RTP-MIDI対応のシステムは、RTP MIDIストリームを受信し、MIDI DINケーブル（またはそのエミュレーション）にそれをトランスコードします。キャンセルサブリストを受信すると、RTP-MIDI対応のトランスコーダは、既に受信機にMIDI DINケーブル上のSysExコマンドの最初の部分を送信している場合があります。
Unfortunately, the MIDI DIN cable protocol cannot directly code "cancel SysEx in progress" semantics. However, MIDI DIN cable receivers begin SysEx processing after the complete command arrives. The receiver checks to see if it recognizes the command (coded in the first few octets) and then checks to see if the command is the correct length. Thus, in practice, a transcoder can cancel a SysEx command by sending an 0xF7 to (prematurely) end the SysEx command -- the receiver will detect the incorrect command length and discard the command.
残念ながら、MIDI DINケーブルプロトコルは、直接コードの意味を「進行中のシステムエクスクルーシブを取り消す」ことができません。完全なコマンドが到着した後ただし、MIDI DINケーブル受信機は、システムエクスクルーシブ処理を開始します。受信機は、（最初の数オクテットで符号化された）コマンドを認識し、コマンドが正しい長さであるかどうかをチェックしているかどうかをチェック。受信機は、誤ったコマンドの長さを検出し、コマンドを廃棄する - このように、実際には、トランスコーダは、（途中）のSysExコマンドを終了する0xF7を送信することによって、システムエクスクルーシブコマンドを取り消すことができます。
Appendix C.1 defines configuration tools that may be used to prohibit SysEx command cancellation.
付録C.1はのSysExコマンドのキャンセルを禁止するために使用することができる構成ツールを定義します。
The relative ordering of SysEx command segments in a MIDI list must match the relative ordering of the sublists in the original SysEx command. By default, commands other than System Real-Time MIDI commands MUST NOT appear between SysEx command segments (Appendix C.1 defines configuration tools to change this default to let other commands types appear between segments). If the command segments of a SysEx command are placed in the MIDI lists of two or more RTP packets, the segment ordering rules apply to the concatenation of all affected MIDI lists.
MIDIリスト内のSysExコマンドセグメントの相対的な順序は、オリジナルのSysExコマンドにおけるサブリストの相対的な順序と一致する必要があります。デフォルトでは、システムのリアルタイムMIDIコマンドは（付録C.1は、他のコマンドタイプは、セグメント間に表示させるために、このデフォルトを変更するには、設定ツールを定義する）のSysExコマンドセグメント間に現れてはなりません以外のコマンド。システムエクスクルーシブコマンドのコマンドセグメントが二つ以上のRTPパケットのMIDIリストに配置されている場合、セグメントの順序付けルールは、影響を受けるすべてのMIDIリストの連結に適用されます。
-----------------------------------------------------------
| Sublist Position | Head Status Octet | Tail Status Octet |
|-----------------------------------------------------------|
| first | 0xF0 | 0xF0 |
|-----------------------------------------------------------|
| middle | 0xF7 | 0xF0 |
|-----------------------------------------------------------|
| last | 0xF7 | 0xF7 |
|-----------------------------------------------------------|
| cancel | 0xF7 | 0xF4 |
-----------------------------------------------------------
Figure 5 -- Command Segmentation Status Octets
図5 - コマンドセグメンテーションステータスオクテット
[MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair to appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no semantic meaning in MIDI apart from cancelling running status.
[MIDI]はMIDI 1.0 DINケーブルに表示する（0xF0が、0xF7）ペアの一部ではない0xF7オクテットを可能にします。不対0xF7オクテットは離れて実行している状態を解除するからMIDIにはセマンティックな意味を持っていません。
Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI Command section. We impose this restriction to avoid interference with the command segmentation coding defined in Figure 5.
不対0xF7オクテットは、MIDIコマンドセクションのMIDIリストに現れてはいけません。我々は、図5で定義されたコマンド分割符号化との干渉を避けるために、この制限を課します。
SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped 0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is dropped from the end of the SysEx command, and the status octet of the next MIDI command acts both to terminate the SysEx command and start the next command. To encode this construction in the payload format, follow these steps:
SysExコマンドはMIDI 1.0 DINケーブルは、建設[MIDI]「0xF7を落とした」を使用することで運ば。この符号化方式では、0xF7オクテットは、システムエクスクルーシブコマンドの端から削除され、次のMIDIコマンドのステータスオクテットは、システムエクスクルーシブのコマンドを終了し、次のコマンドを開始するために、両方の役割を果たす。ペイロード形式でこの構造を符号化するために、次の手順を実行します。
o Determine the appropriate delta times for the SysEx command and the command that follows the SysEx command.
OのSysExコマンドとのSysExコマンドを次のコマンドに適切なデルタ時間を決定します。
o Insert the "dropped" 0xF7 octet at the end of the SysEx command to form the standard SysEx syntax.
O規格のSysEx構文を形成するためのSysExコマンドの最後に0xF7オクテットを「ドロップ」を挿入します。
o Code both commands into the MIDI list using the rules above.
Oコードは、上記のルールを使用してMIDIリストにコマンドの両方。
o Replace the 0xF7 octet that terminates the verbatim SysEx encoding or the last segment of the segmented SysEx encoding with a 0xF5 octet. This substitution informs the receiver of the original "dropped 0xF7" coding.
O逐語的システムエクスクルーシブ符号化または0xF5オクテットを有するセグメント化されたシステムエクスクルーシブエンコードの最後のセグメントを終了0xF7オクテットを交換します。この置換は、元の受信者に通知コーディング「0xF7を落としました」。
[MIDI] reserves the undefined System Common commands 0xF4 and 0xF5 and the undefined System Real-Time commands 0xF9 and 0xFD for future use. By default, undefined commands MUST NOT appear in a MIDI Command field in the MIDI list, with the exception of the 0xF5 octets used to code the "dropped 0xF7" construction and the 0xF4 octets used by SysEx "cancel" sublists.
[MIDI]は一般的には0xF4と0xF5とリアルタイムは将来の使用のために0xF9と0xFDでコマンド未定義のシステムコマンド未定義のシステムが留保します。デフォルトでは、未定義のコマンドをコード化するために使用される0xF5オクテットを除いて、MIDIリストでMIDIコマンド]フィールドに現れてはならない建設やサブリストの「キャンセル」のSysExが使用する0xF4オクテット「0xF7を落としました」。
During session configuration, a stream may be customized to transport undefined commands (Appendix C.1). For this case, we now define how senders encode undefined commands in the MIDI list.
セッション構成中に、ストリームは、未定義のコマンド（付録C.1）を輸送するためにカスタマイズされてもよいです。このような場合のために、我々は今、送信者がMIDIリストに未定義のコマンドを符号化する方法を定義します。
An undefined System Real-Time command MUST be coded using the System Real-Time rules.
未定義のシステムリアルタイムコマンドは、システムのリアルタイムのルールを使用して符号化されなければなりません。
If the undefined System Common commands are put to use in a future version of [MIDI], the command will begin with an 0xF4 or 0xF5 status octet, followed by an arbitrary number of data octets (i.e., zero or more data bytes). To encode these commands, senders MUST terminate the command with an 0xF7 octet and place the modified command into the MIDI Command field.
未定義のシステム共通のコマンドが[MIDI]の将来のバージョンで使用するように置かれている場合、コマンドは、データオクテットの任意の数（即ち、ゼロ又はそれ以上のデータバイト）に続いて、0xF4または0xF5ステータスオクテットで始まります。これらのコマンドをエンコードするには、送信者が0xF7のオクテットでコマンドを終了し、MIDIコマンド]フィールドに変更コマンドを置かなければなりません。
Unfortunately, non-compliant uses of the undefined System Common commands may appear in MIDI implementations. To model these commands, we assume that the command begins with an 0xF4 or 0xF5 status octet, followed by zero or more data octets, followed by zero or more trailing 0xF7 status octets. To encode the command, senders MUST first remove all trailing 0xF7 status octets from the command. Then, senders MUST terminate the command with an 0xF7 octet and place the modified command into the MIDI Command field.
残念ながら、未定義のシステム共通コマンドの非準拠の用途は、MIDIインプリメンテーションで表示されることがあります。これらのコマンドをモデル化するために、我々は、コマンドがゼロ以上の末尾の0xF7ステータスオクテットに続くゼロ以上のデータオクテット、続い0xF4または0xF5状態八重奏、で始まることを前提としています。コマンドを符号化するために、送信者は、最初のコマンドからすべての末尾の0xF7ステータスオクテットを削除する必要があります。次に、送信者は0xF7オクテットでコマンドを終了し、MIDIコマンド]フィールドに変更コマンドを置かなければなりません。
Note that we include the trailing octets in our model as a cautionary measure: if such commands appeared in a non-compliant use of an undefined System Common command, an RTP MIDI encoding of the command that did not remove trailing octets could be mistaken for an encoding of the "middle" or "last" sublist of a segmented SysEx command (Figure 5) under certain packet loss conditions.
私たちは警戒措置として我々のモデルでは、末尾のオクテットを含んでいることに注意してください：そのようなコマンドは、未定義のシステム共通コマンドの非準拠の使用に登場した場合、末尾のオクテットを削除しなかったコマンドのRTP MIDIエンコーディングはと誤解することができ「中」又はセグメント化されたSysExコマンドの「最後」のサブリスト（図5）は、特定のパケット損失条件下でのエンコード。
Original SysEx command:
オリジナルのSysExコマンド：
0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7
0xF0が0x01の0x02の0x03の0x04の0x05を0x06の0x07の0x08の0xF7
A two-segment segmentation:
2セグメントの分割：
0xF0 0x01 0x02 0x03 0x04 0xF0
0xF0が0x01の0x02の0x03の0x04の0xF0が
0xF7 0x05 0x06 0x07 0x08 0xF7
0xF7 0x05を0x06の0x07の0x08の0xF7
A different two-segment segmentation:
異なる2セグメントの分割：
0xF0 0x01 0xF0
0xF0が0x01での0xF0
0xF7 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7
0xF7 0x02の0x03の0x04を0x05を0x06の0x07の0x08の0xF7
A three-segment segmentation:
3セグメント分割：
0xF0 0x01 0x02 0xF0
0xF0 0x01を0x02での0xF0
0xF7 0x03 0x04 0xF0
0xF7 0x03を0x04の0xF0が
0xF7 0x05 0x06 0x07 0x08 0xF7
0xF7 0x05を0x06の0x07の0x08の0xF7
The segmentation with the largest number of segments:
セグメントの最大数に分割：
0xF0 0x01 0xF0
0xF0が0x01での0xF0
0xF7 0x02 0xF0
0xF7 0x02での0xF0
0xF7 0x03 0xF0
0xF7 0x03のの0xF0
0xF7 0x04 0xF0
0xF7 0x04のの0xF0
0xF7 0x05 0xF0
0xF7 0x05での0xF0
0xF7 0x06 0xF0
0xF7 0x06での0xF0
0xF7 0x07 0xF0
0xF7 0x07のの0xF0
0xF7 0x08 0xF0
0xF7 0x08のの0xF0
0xF7 0xF7
0xF7 0xF7
Figure 6 -- Example Segmentations
図6 - 例セグメンテーション
The recovery journal is the default resiliency tool for unreliable transport. In this section, we normatively define the roles that senders and receivers play in the recovery journal system.
回復ジャーナルは、信頼性の低いトランスポートのデフォルトの弾力性ツールです。このセクションでは、規範的に送信側と受信側が回復ジャーナルシステムにおいて果たす役割を定義します。
MIDI is a fragile code. A single lost command in a MIDI command stream may produce an artifact in the rendered performance. We normatively classify rendering artifacts into two categories:
MIDIは、脆弱なコードです。 MIDIコマンドストリームにおける単一の失われたコマンドは、レンダリング性能アーチファクトを生成することができます。私たちは、規範的に二つのカテゴリーに成果物をレンダリング分類します：
o Transient artifacts. Transient artifacts produce immediate but short-term glitches in the performance. For example, a lost NoteOn (0x9) command produces a transient artifact: one note fails to play, but the artifact does not extend beyond the end of that note.
一時アーティファクトO。過渡アーティファクトは、パフォーマンスに即時が、短期的なグリッチを生成します。 1冊のノートが再生するために失敗しますが、アーティファクトは、そのノートの終わりを超えて拡張しません：たとえば、失われたNoteOn（0x9）コマンドは一時アーティファクトを生成します。
o Indefinite artifacts. Indefinite artifacts produce long-lasting errors in the rendered performance. For example, a lost NoteOff (0x8) command may produce an indefinite artifact: the note that should have been ended by the lost NoteOff command may sustain indefinitely. As a second example, the loss of a Control Change (0xB) command for controller number 7 (Channel Volume) may produce an indefinite artifact: after the loss, all notes on the channel may play too softly or too loudly.
O不定アーティファクト。無期限のアーティファクトは、レンダリングパフォーマンスの長期的なエラーが発生します。無期限に維持することができる失わNoteOffコマンドによって終了されていなければならない注：例えば、失わNoteOff（0x8という）コマンドが不定アーチファクトを生成することができます。第2の例として、コントローラ番号7（チャネル容量）のためのコントロールチェンジ（0xB）コマンドの損失が不定アーチファクトを生成することができる：損失の後、チャネル上のすべてのノートがあまりにも柔らかく、またはあまりにも大声でプレイしてもよいです。
The purpose of the recovery journal system is to satisfy the recovery journal mandate: the MIDI performance rendered from an RTP MIDI stream sent over unreliable transport MUST NOT contain indefinite artifacts.
無期限の成果物を含んではならない信頼性の低いトランスポートを介して送信されるRTP MIDIストリームからレンダリングされたMIDI演奏：回復ジャーナルシステムの目的は回復ジャーナル命令を満たすことです。
The recovery journal system does not use packet retransmission to satisfy this mandate. Instead, each packet includes a special section called the recovery journal.
回復ジャーナルシステムは、この使命を満たすために、パケットの再送を使用していません。代わりに、各パケットは回復ジャーナルと呼ばれる特別なセクションが含まれています。
The recovery journal codes the history of the stream back to an earlier packet called the checkpoint packet. The range of coverage for the journal is called the checkpoint history. The recovery journal codes the information necessary to recover from the loss of an arbitrary number of packets in the checkpoint history. Appendix A.1 normatively defines the checkpoint history.
回復ジャーナルコードバックチェックポイントパケットと呼ばれる以前のパケットへのストリームの歴史。ジャーナルのカバレッジの範囲は、チェックポイントの歴史と呼ばれています。回復ジャーナル・コードのチェックポイントの歴史の中でパケットの任意の数の損失から回復するために必要な情報。付録A.1は、規範的にチェックポイント歴史を定義します。
When a receiver detects a packet loss, it compares its own knowledge about the history of the stream with the history information coded in the recovery journal of the packet that ends the loss event. By noting the differences in these two versions of the past, a receiver is able to transform all indefinite artifacts in the rendered performance into transient artifacts by executing MIDI commands to repair the stream.
受信機は、パケットロスを検出すると、損失イベントを終了し、パケットの回復ジャーナルでコード化された履歴情報を持つストリームの歴史について、自身の知識を比較します。過去の2つのバージョンの違いに注目することによって、受信機は、MIDIストリームを修復するためのコマンド実行することにより、過渡的アーティファクトにレンダリング性能はすべて無期限のアーティファクトを変換することができます。
We now state the normative role for senders in the recovery journal system.
私たちは今、回復ジャーナルシステムにおける送信者のための規範的な役割を述べます。
Senders prepare a recovery journal for every packet in the stream. In doing so, senders choose the checkpoint packet identity for the journal. Senders make this choice by applying a sending policy. Appendix C.2.2 normatively defines three sending policies: "closed-loop", "open-loop", and "anchor".
送信者は、ストリーム内のすべてのパケットの回復ジャーナルを準備します。そうすることで、送信者は、ジャーナルのためのチェックポイントのパケットIDを選択します。送信者は送信ポリシーを適用することによって、この選択を行います。 「クローズド・ループ」、「オープンループ」、および「アンカー」：付録C.2.2は、規範的に3つの送信ポリシーを定義します。
By default, senders MUST use the closed-loop sending policy. If the session description overrides this default policy by using the parameter j_update defined in Appendix C.2.2, senders MUST use the specified policy.
デフォルトでは、送信者は、閉ループ送信ポリシーを使用しなければなりません。セッション記述は、付録C.2.2に定義されたパラメータj_アップデートを使用して、このデフォルトポリシーをオーバーライドする場合、送信者が指定したポリシーを使用しなければなりません。
After choosing the checkpoint packet identity for a packet, the sender creates the recovery journal. By default, this journal MUST conform to the normative semantics in Section 5 and Appendices A and B in this memo. In Appendix C.2.3, we define parameters that modify the normative semantics for recovery journals. If the session description uses these parameters, the journal created by the sender MUST conform to the modified semantics.
パケットのためのチェックポイントのパケットIDを選択した後、送信者は回復ジャーナルを作成します。デフォルトでは、この雑誌は、このメモでは第5節および付録AとBで規範的意味論に従わなければなりません。付録C.2.3では、我々は回復ジャーナルのための規範的な意味論を変更するパラメータを定義します。セッション記述は、これらのパラメータを使用している場合は、送信者が作成したジャーナルは変更のセマンティクスに従わなければなりません。
Next, we state the normative role for receivers in the recovery journal system.
次に、我々は回復ジャーナルシステムにおける受信機のための規範的な役割を述べます。
A receiver MUST detect each RTP sequence number break in a stream. If the sequence number break is due to a packet loss event (as defined in [RFC3550]), the receiver MUST repair all indefinite artifacts in the rendered MIDI performance caused by the loss. If the sequence number break is due to an out-of-order packet (as defined in [RFC3550]), the receiver MUST NOT take actions that introduce indefinite artifacts (ignoring the out-of-order packet is a safe option).
受信機は、ストリーム内の各RTPシーケンス番号ブレークを検出しなければなりません。シーケンス番号ブレーク（[RFC3550]で定義されるように）、パケット損失イベントに起因している場合、受信機は、損失によるレンダリングMIDI性能の全て不定アーティファクトを修復する必要があります。シーケンス番号のブレーク（[RFC3550]で定義されている）アウトオブオーダーパケットによるものである場合、受信機は不定アーティファクトを（アウトオブオーダーパケットを無視することは安全なオプションである）を導入措置をとるなりません。
Receivers take special precautions when entering or exiting a session. A receiver MUST process the first received packet in a stream as if it were a packet that ends a loss event. Upon exiting a session, a receiver MUST ensure that the rendered MIDI performance does not end with indefinite artifacts.
入力するか、セッションの終了時に受信機は、特別な予防措置をとります。それは、損失イベントを終了パケットであるかのように、受信機は、ストリーム内の最初の受信されたパケットを処理しなければなりません。セッションの終了時に、受信機は、レンダリングされたMIDI性能が不定アーティファクトで終わっていないことを確認しなければなりません。
Receivers are under no obligation to perform indefinite artifact repairs at the moment a packet arrives. A receiver that uses a playout buffer may choose to wait until the moment of rendering before processing the recovery journal, as the "lost" packet may be a late packet that arrives in time to use.
受信機は、パケットが到着した瞬間に、不定アーティファクトの修理を行うための義務はありません。再生バッファを使用する受信機は、「失われた」パケットが使用する時間に到着した後半のパケットであってもよいように、回復ジャーナルを処理する前に、レンダリングの瞬間まで待つことを選択することがあります。
Next, we state the normative role for the creator of the session description in the recovery journal system. The sender, the receivers, and other parties may take part in creating or approving the session description, depending on the application.
次に、我々は回復ジャーナルシステムにおけるセッション記述の作成者のための規範的な役割を述べます。送信者、受信者、および他の当事者は、用途に応じて、セッション記述の作成や承認に参加することがあります。
A session description that specifies the default closed-loop sending policy and the default recovery journal semantics satisfies the recovery journal mandate. However, these default behaviors may not be appropriate for all sessions. If the creators of a session description use the parameters defined in Appendix C.2 to override these defaults, the creators MUST ensure that the parameters define a system that satisfies the recovery journal mandate.
ポリシーとデフォルトの回復ジャーナル意味論を送信するデフォルトの閉ループを指定するセッション記述は回復ジャーナル命令を満たします。しかし、これらのデフォルトの動作は、すべてのセッションのために適切でないかもしれません。セッション記述の作成者がこれらのデフォルトを上書きするために、付録C.2で定義されたパラメータを使用する場合、作成者は、パラメータは回復ジャーナル命令を満たすシステムを定義していることを確認しなければなりません。
Finally, we note that this memo does not specify sender or receiver recovery journal algorithms. Implementations are free to use any algorithm that conforms to the requirements in this section. The non-normative [RFC4696] discusses sender and receiver algorithm design.
最後に、私たちは、このメモは、送信者または受信者の回復ジャーナルアルゴリズムを指定していないことに注意してください。実装は、このセクションの要件に準拠して任意のアルゴリズムを自由に使用できます。非標準[RFC4696]は、送信側と受信側アルゴリズムの設計について説明します。
This section introduces the structure of the recovery journal and defines the bitfields of recovery journal headers. Appendices A and B complete the bitfield definition of the recovery journal.
このセクションでは、回復ジャーナルの構造を紹介し、回復ジャーナルヘッダのビットフィールドを定義します。付録AとBは回復ジャーナルのビットフィールドの定義を完了します。
The recovery journal has a three-level structure:
回復ジャーナルは3レベルの構造を有します：
o Top-level header.
Oトップ・レベル・ヘッダ。
o Channel and system journal headers. These headers encode recovery information for a single voice channel (channel journal) or for all system commands (system journal).
Oチャネルおよびシステム・ジャーナルヘッダ。これらのヘッダは、単一の音声チャネル（チャネルジャーナル）またはすべてのシステム・コマンド（システム・ジャーナル）の回復情報を符号化します。
o Chapters. Chapters describe recovery information for a single MIDI command type.
Oの章。章では、単一のMIDIコマンドタイプのためのリカバリ情報を記述する。
Figure 7 shows the top-level structure of the recovery journal. The recovery journal consists of a 3-octet header followed by an optional system journal (labeled S-journal in Figure 7) and an optional list of channel journals. Figure 8 shows the recovery journal header format.
図7は、回復ジャーナルのトップレベル構造を示しています。回復ジャーナルは、（図7にS-ジャーナル標識された）任意のシステムジャーナル続く3オクテットのヘッダとチャネルジャーナルのオプションリストから成ります。図8は、回復ジャーナル・ヘッダ・フォーマットを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery journal header | S-journal ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel journals ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 -- Top-Level Recovery Journal Format
図7 - トップレベルのリカバリ・ジャーナル・フォーマット
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 -- Recovery Journal Header
図8 - 回復ジャーナルヘッダ
If the Y header bit is set to 1, the system journal appears in the recovery journal, directly following the recovery journal header.
Yヘッダビットが1に設定されている場合、システムジャーナルを直接回復ジャーナルヘッダに続く、回復ジャーナルに現れます。
If the A header bit is set to 1, the recovery journal ends with a list of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header field is interpreted as an unsigned integer).
ヘッダビットが1に設定されている場合、回復ジャーナルは（TOTCHAN + 1）チャネルジャーナル（4ビットTOTCHANヘッダフィールドは符号なし整数として解釈される）のリストで終わります。
A MIDI channel MAY be represented by (at most) one channel journal in a recovery journal. Channel journals MUST appear in the recovery journal in ascending channel-number order.
MIDIチャンネルは回復ジャーナルに（最大で）1つのチャネルジャーナルで表すことができます。チャンネルジャーナルはチャンネル番号の昇順に回復ジャーナルに現れなければなりません。
If A and Y are both zero, the recovery journal only contains its 3-octet header and is considered to be an "empty" journal.
AおよびYが両方ともゼロである場合、回復ジャーナルは、その3オクテットのヘッダを含み、「空」のジャーナルであると考えられます。
The S (single-packet loss) bit appears in most recovery journal structures, including the recovery journal header. The S bit helps receivers efficiently parse the recovery journal in the common case of the loss of a single packet. Appendix A.1 defines S-bit semantics.
S（シングルパケット損失）ビットは回復ジャーナルヘッダを含むほとんどの回復ジャーナル構造で表示されます。 Sビットは、受信機が効率的に単一のパケットの損失の一般的な場合には回復ジャーナルを解析するのに役立ちます。付録A.1は、Sビットの意味を定義します。
The H bit indicates if MIDI channels in the stream have been configured to use the enhanced Chapter C encoding (Appendix A.3.3).
ストリーム内のMIDIチャンネルが向上章Cの符号化（付録A.3.3）を使用するように構成されている場合はHビットは示します。
By default, the payload format does not use enhanced Chapter C encoding. In this default case, the H bit MUST be set to 0 for all packets in the stream.
デフォルトでは、ペイロード形式は、高められた章Cコード化を使用していません。このデフォルトの場合、Hのビットは、ストリーム内のすべてのパケットのために0に設定しなければなりません。
If the stream has been configured so that controller numbers for one or more MIDI channels use enhanced Chapter C encoding, the H bit MUST be set to 1 in all packets in the stream. In Appendix C.2.3, we show how to configure a stream to use enhanced Chapter C encoding.
ストリームが設定されている場合は、1つのまたは複数のMIDIチャンネルのためのそのコントローラ番号が向上章Cの符号化を使用して、Hビットは、ストリーム内のすべてのパケットに1に設定しなければなりません。付録C.2.3では、私たちは、高められた章Cコード化を使用するようにストリームを構成する方法を示しています。
The 16-bit Checkpoint Packet Seqnum header field codes the sequence number of the checkpoint packet for this journal, in network byte order (big-endian). The choice of the checkpoint packet sets the depth of the checkpoint history for the journal (defined in Appendix A.1).
16ビットのチェックポイントパケットSEQNUMヘッダフィールドコードネットワークバイト順（ビッグエンディアン）で、このジャーナルのためのチェックポイントのパケットのシーケンス番号。チェックポイントパケットの選択は、（付録A.1で定義された）ジャーナルのためのチェックポイント歴史の深さを設定します。
Receivers may use the Checkpoint Packet Seqnum field of the packet that ends a loss event to verify that the journal checkpoint history covers the entire loss event. The checkpoint history covers the loss event if the Checkpoint Packet Seqnum field is less than or equal to one plus the highest RTP sequence number previously received on the stream (modulo 2^16).
レシーバは、ジャーナルチェックポイント歴史が全体の損失のイベントをカバーすることを確認するために、損失イベントを終了し、パケットのチェックポイントパケットSEQNUMフィールドを使用することができます。チェックポイントパケットSEQNUMフィールドは以下プラスワン以前にストリーム（モジュロ2 ^ 16）で受信された最高のRTPシーケンス番号に等しい場合、チェックポイント履歴は、損失イベントをカバーします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CHAN |H| LENGTH |P|C|M|W|N|E|T|A| Chapters ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 -- Channel Journal Format
図9 - チャンネルジャーナルのフォーマット
Figure 9 shows the structure of a channel journal: a 3-octet header followed by a list of leaf elements called channel chapters. A channel journal encodes information about MIDI commands on the MIDI channel coded by the 4-bit CHAN header field. Note that CHAN uses the same bit encoding as the channel nibble in MIDI Channel Messages (the cccc field in Figure E.1 of Appendix E).
図9は、チャンネルジャーナルの構造を示す：3オクテットのヘッダはチャネルチャプターと呼ばれるリーフ要素のリストが続きます。チャンネルジャーナルは、MIDIに関する情報は、4ビットCHANヘッダーフィールドにより符号化されたMIDIチャンネルのコマンドコードします。 CHANはMIDIチャンネルメッセージ（付録Eの図E.1にCCCCフィールド）におけるチャネルニブルと同じビットエンコーディングを使用することに注意してください。
The 10-bit LENGTH field codes the length of the channel journal. The semantics for LENGTH fields are uniform throughout the recovery journal and are defined in Appendix A.1.
10ビット長のフィールドコードチャネルジャーナルの長さ。 LENGTHフィールドのセマンティクスは回復ジャーナル全体に均一であり、付録A.1で定義されています。
The third octet of the channel journal header is the Table of Contents (TOC) of the channel journal. The TOC is a set of bits that encode the presence of a chapter in the journal. Each chapter contains information about a certain class of MIDI channel command:
チャネルジャーナルヘッダの第三のオクテットは、チャネルジャーナルの目次（TOC）の表です。 TOCは、ジャーナルの章の存在をコードビットの集合です。各章には、MIDIチャンネルコマンドの特定のクラスに関する情報が含まれています。
o Chapter P: MIDI Program Change (0xC) o Chapter C: MIDI Control Change (0xB) o Chapter M: MIDI Parameter System (part of 0xB) o Chapter W: MIDI Pitch Wheel (0xE) o Chapter N: MIDI NoteOff (0x8), NoteOn (0x9) o Chapter E: MIDI Note Command Extras (0x8, 0x9) o Chapter T: MIDI Channel Aftertouch (0xD) o Chapter A: MIDI Poly Aftertouch (0xA)
O章P：MIDIプログラムチェンジ（から0xC）章C O：章M O MIDIコントロールチェンジ（0xB）：MIDIパラメータシステム（0xBの一部）章W O：MIDIピッチホイール（から0xE）章N O：MIDI NoteOff（0x8の）、NoteOn章E O（0x9）：MIDIコマンドエクストラ章T O（0x8の、0x9の）注意：MIDIチャンネル・アフタータッチ章A O（0xDの）：MIDIポリアフタータッチ（0xAが）
Chapters appear in a list following the header, in order of their appearance in the TOC. Appendices A.2-A.9 describe the bitfield format for each chapter and define the conditions under which a chapter type MUST appear in the recovery journal. If any chapter types are required for a channel, an associated channel journal MUST appear in the recovery journal.
章では、TOCでの出現順に、ヘッダを次の一覧に表示されます。 A.2-A.9は、各章のためのビットフィールドのフォーマットを記述し、章タイプが回復ジャーナルに現れなければならない条件を定義します付録。任意のチャプタータイプがチャネルのために必要とされる場合は、関連するチャネルジャーナルは回復ジャーナルに現れなければなりません。
The H bit indicates if controller numbers on a MIDI channel have been configured to use the enhanced Chapter C encoding (Appendix A.3.3).
MIDIチャンネル上のコントローラ番号が向上章Cの符号化（付録A.3.3）を使用するように構成されている場合はHビットは示します。
By default, controller numbers on a MIDI channel do not use enhanced Chapter C encoding. In this default case, the H bit MUST be set to 0 for all channel journal headers for the channel in the recovery journal, for all packets in the stream.
デフォルトでは、MIDIチャンネル上のコントローラ番号が高められた章Cコード化を使用しないでください。このデフォルトの場合、Hのビットは、ストリーム内のすべてのパケットに対して、回復ジャーナル内のチャネルのためのすべてのチャネルジャーナルヘッダを0に設定しなければなりません。
However, if at least one controller number for a MIDI channel has been configured to use the enhanced Chapter C encoding, the H bit for its channel journal MUST be set to 1, for all packets in the stream.
MIDIチャンネルのための少なくとも1つのコントローラ番号が向上章Cの符号化を使用するように構成されている場合は、そのチャンネルジャーナルのためのHビットストリーム内のすべてのパケットのために、1に設定しなければなりません。
In Appendix C.2.3, we show how to configure a controller number to use enhanced Chapter C encoding.
付録C.2.3では、私たちは、高められた章Cコード化を使用するように、コントローラ番号を設定する方法を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|V|Q|F|X| LENGTH | System chapters ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 -- System Journal Format
図10 - システムジャーナルのフォーマット
Figure 10 shows the structure of the system journal: a 2-octet header followed by a list of system chapters. Each chapter codes information about a specific class of MIDI system commands:
システムチャプタのリストが続く2オクテットのヘッダ：図10は、システムジャーナルの構造を示しています。各章のコードMIDIシステムコマンドの特定のクラスについての情報を：
o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset (0xFF), undefined system commands (0xF4, 0xF5, 0xF9, 0xFD) o Chapter V: Active Sense (0xFE) o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC) o Chapter F: MIDI Time Code (MTC) Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01) o Chapter X: System Exclusive (all other 0xF0)
O章D：ソング・セレクト（0xF3）、チューン・リクエスト（0xF6）、リセット（0xFFで）、未定義のシステムコマンド（0xF4、0xF5、0xF9、0xFDで）章V O：アクティブ・センシング（0xFEの）章Q O：シーケンサ状態（0xF2 、0xF8、0xF9、0xFA、章F O 0xFB、0xFC）：MIDIタイムコード（MTC）テープ位置（0xF1、章X Oの0xF0 0x7Fを0xcc 0x01を0x01を）：システム・エクスクルーシブ（他のすべての0xF0）
The 10-bit LENGTH field codes the size of the system journal and conforms to semantics described in Appendix A.1.
10ビット長のフィールドコードシステムジャーナルのサイズおよび付録A.1に記載の意味論に従います。
The D, V, Q, F, and X header bits form a Table of Contents (TOC) for the system journal. A TOC bit that is set to 1 codes the presence of a chapter in the journal. Chapters appear in a list following the header, in the order of their appearance in the TOC.
D、V、Q、F、およびXヘッダビットは、システムジャーナルの目次（TOC）を形成します。 1つの符号ジャーナルの章の存在のために設定されているTOCビット。章では、TOCでの出現順に、ヘッダを次の一覧に表示されます。
Appendix B describes the bitfield format for the system chapters and defines the conditions under which a chapter type MUST appear in the recovery journal. If any system chapter type is required to appear in the recovery journal, the system journal MUST appear in the recovery journal.
付録Bには、システムの章のためのビットフィールドのフォーマットを記述し、章タイプが回復ジャーナルに現れなければならない条件を定義します。任意のシステム章タイプが回復ジャーナルに表示されるように要求された場合は、システムジャーナルは回復ジャーナルに現れなければなりません。
RTP does not perform session management. Instead, RTP works together with session management tools, such as the Session Initiation Protocol (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP, [RFC2326]).
RTPは、セッション管理を行いません。代わりに、RTPは、セッション開始プロトコル（SIP、[RFC3261]）と、リアルタイムストリーミングプロトコル（RTSP、[RFC2326]）として、セッション管理ツールと連携して動作します。
RTP payload formats define media type parameters for use in session management (for example, this memo defines rtp-midi as the media type for native RTP MIDI streams).
RTPペイロードフォーマットは、セッション管理で使用するためのメディアタイプパラメータを定義する（例えば、このメモは、ネイティブRTP MIDIストリームのメディア種別としてRTP-MIDIを定義します）。
In most cases, session management tools use the media type parameters via another standard, the Session Description Protocol (SDP, [RFC4566]).
ほとんどの場合、セッション管理ツールは、他の標準、セッション記述プロトコル（SDP、[RFC4566]）を介してメディアタイプパラメータを使用します。
SDP is a textual format for specifying session descriptions. Session descriptions specify the network transport and media encoding for RTP sessions. Session management tools coordinate the exchange of session descriptions between participants ("parties").
SDPは、セッション記述を指定するためのテキスト形式です。セッション記述は、RTPセッションのためのネットワーク・トランスポートとメディアエンコーディングを指定します。セッション管理ツールの参加者（「関係者」）との間にセッション記述の交換をコーディネート。
Some session management tools use SDP to negotiate details of media transport (network addresses, ports, etc.). We refer to this use of SDP as "negotiated usage". One example of negotiated usage is the Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as used by SIP.
いくつかのセッション管理ツールは、メディアトランスポートの詳細（ネットワークアドレス、ポートなど）を交渉するSDPを使用しています。私たちは「交渉し、使用」としてSDPのこの使用を参照してください。ネゴシエートされた使用の一例は、SIPによって使用されるようなオファー/アンサープロトコル（[RFC3264]とこのメモの付録C.7.2）です。
Other session management tools use SDP to declare the media encoding for the session but use other techniques to negotiate network transport. We refer to this use of SDP as "declarative usage". One example of declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in this memo).
他のセッション管理ツールは、セッションのためのメディアエンコーディングを宣言するためにSDPを使用しますが、ネットワーク・トランスポートを交渉するために他の技術を使用しています。私たちは、「宣言型の使用」としてSDPのこの使用を参照してください。宣言的使用の一例は、RTSP（このメモで[RFC2326]および付録C.7.1）です。
Below, we show session description examples for native (Section 6.1) and mpeg4-generic (Section 6.2) streams. In Section 6.3, we introduce session configuration tools that may be used to customize streams.
以下に、我々は（6.1節）とmpeg4-ジェネリック（セクション6.2）はストリームネイティブのためのセッション記述例を示しています。 6.3節では、ストリームをカスタマイズするために使用することができるセッション構成ツールを紹介します。
The session description below defines a unicast UDP RTP session (via a media ("m=") line) whose sole payload type (96) is mapped to a minimal native RTP MIDI stream.
以下セッション記述は、その唯一のペイロードタイプ（96）最小ネイティブRTP MIDIストリームにマッピングされる（メディア（「M =」）ラインを介して）ユニキャストUDP RTPセッションを定義します。
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100
96 RTP-MIDI / 44100：IP4 first.example.net S =例、T = 0、M = IP4 192.0.2.94 INオーディオ5004 RTP / AVP 96個のC = = rtpmap IN V = 0 0 =ラザロ2520644554 2838152170
The rtpmap attribute line uses the rtp-midi media type to specify an RTP MIDI native stream. The clock rate specified on the rtpmap line (in the example above, 44100 Hz) sets the scaling for the RTP timestamp header field (see Section 2.1 and also [RFC3550]).
rtpmap属性ラインは、RTP MIDIネイティブのストリームを指定するには、RTP-MIDIメディアタイプを使用しています。 rtpmapの（上記の例では、44100ヘルツ）行に指定されたクロックレートは、（セクション2.1、また[RFC3550]を参照）RTPタイムスタンプヘッダフィールドのスケーリングを設定します。
Note that this document does not specify a default clock rate value for RTP MIDI. When RTP MIDI is used with SDP, parties MUST use the rtpmap line to communicate the clock rate. Guidance for selecting the RTP MIDI clock rate value appears in Section 2.1.
このドキュメントはRTP MIDIのデフォルトのクロック・レート値を指定していないことに注意してください。 RTP MIDIがSDPで使用される場合、当事者は、クロック・レートを通信するrtpmapラインを使用しなければなりません。 RTP MIDIクロックレート値を選択するための指針は、セクション2.1に表示されます。
We consider the RTP MIDI stream shown above to be "minimal" because the session description does not customize the stream with parameters. Without such customization, a native RTP MIDI stream has these characteristics:
私たちは、セッション記述は、パラメータを持つストリームをカスタマイズしていないため、上に示したRTP MIDIストリームは「最小限」であると考えています。このようなカスタマイズがなければ、ネイティブのRTP MIDIストリームは次の特性があります。
1. If the stream uses unreliable transport (unicast UDP, multicast UDP, etc.), the recovery journal system is in use, and the RTP payload contains both the MIDI command section and the journal section. If the stream uses reliable transport (such as TCP), the stream does not use journalling, and the payload contains only the MIDI command section (Section 2.2).
1.ストリームが信頼できないトランスポート（ユニキャストUDP、マルチキャストUDPなど）を使用している場合は、回復ジャーナルシステムが使用され、RTPペイロードは、MIDI命令部とジャーナル部の両方が含まれています。ストリームが（TCPのような）信頼性の高いトランスポートを使用している場合は、ストリームは、ジャーナリングを使用していない、とペイロードはMIDIコマンドセクション（セクション2.2）が含まれています。
2. If the stream uses the recovery journal system, the recovery journal system uses the default sending policy and the default journal semantics (Section 4).
2.ストリームが回復ジャーナルシステムを使用している場合は、回復ジャーナルシステムは、ポリシーと、デフォルトのジャーナル意味論（第4節）を送信するデフォルトを使用しています。
3. In the MIDI command section of the payload, command timestamps use the default comex semantics (Section 3).
ペイロードのMIDIコマンドセクションで、[コマンドのタイムスタンプは、デフォルトのCOMEX意味論（第3節）を使用します。
4. The recommended temporal duration ("media time") of an RTP packet ranges from 0 to 200 ms, and the RTP timestamp difference between sequential packets in the stream may be arbitrarily large (Section 2.1).
前記RTPパケットの推奨持続時間（「メディア時間」）は、0から200ミリ秒の範囲であり、ストリーム内のシーケンシャル・パケット間のRTPタイムスタンプの差は（セクション2.1）任意に大きくすることができます。
5. If more than one minimal rtp-midi stream appears in a session, the MIDI name spaces for these streams are independent: channel 1 in the first stream does not reference the same MIDI channel as channel 1 in the second stream (see Appendix C.5 for a discussion of the independence of minimal rtp-midi streams).
5つ以上の最小RTP-MIDIストリームがセッションに表示されている場合、これらのストリームのMIDI名前空間は独立して：最初のストリームにおけるチャンネル1は、第二の流れにチャンネル1と同じMIDIチャンネルを参照していない（付録Cを参照してください最小限のRTP-MIDIストリームの独立性の議論については0.5）。
6. The rendering method for the stream is not specified. What the receiver "does" with a minimal native MIDI stream is out of the scope of this memo. For example, in content creation environments, a user may manually configure client software to render the stream with a specific software package.
6.ストリームのレンダリング方法が指定されていません。どのような受信機は、最小限のネイティブMIDIストリームで「ないこと」、このメモの範囲外です。例えば、コンテンツ作成環境では、ユーザーが手動で特定のソフトウェアパッケージを使用してストリームをレンダリングするためにクライアントソフトウェアを設定することができます。
As is standard in RTP, RTP sessions managed by SIP are sendrecv by default (parties send and receive MIDI), and RTP sessions managed by RTSP are recvonly by default (server sends and client receives).
RTPの標準と同様に、SIPによって管理されるRTPセッションは、（当事者は、送信とMIDIを受信）、およびRTSPによって管理されるRTPセッションが（サーバーが送信し、クライアントが受け取る）デフォルトであるがrecvonlyデフォルトでSENDRECVされています。
In sendrecv RTP MIDI sessions for the session description shown above, the 16 voice channel + systems MIDI name space is unique for each sender. Thus, in a two-party session, the voice channel 0 sent by one party is distinct from the voice channel 0 sent by the other party.
上に示したセッション記述のためのsendrecv RTP MIDIセッションでは、16の音声チャンネル+システムのMIDI名前空間は、各送信者に対してユニークです。したがって、2つのパーティセッションで、一方の当事者によって送信された音声チャンネル0は、他の当事者によって送信された音声チャンネル0から区別されます。
This behavior corresponds to what occurs when two MIDI 1.0 DIN devices are cross-connected with two MIDI cables (one cable routing MIDI Out from the first device into MIDI In of the second device and a second cable routing MIDI In from the first device into MIDI Out of the second device). We define this "association" formally in Section 2.1.
2つのMIDI 1.0 DINデバイスがMIDIに第一の装置からMIDIでルーティング2本のMIDIケーブル（一方のケーブルが第二の装置のMIDIでに第1の装置と第2のケーブルからMIDIアウトルーティングと相互接続されている場合、この現象が発生したものに相当します第二の装置のうち）。我々は正式に2.1節では、この「関連性」を定義します。
MIDI 1.0 DIN networks may be configured in a "party-line" multicast topology. For these networks, the MIDI protocol itself provides tools for addressing specific devices in transactions on a multicast network and for device discovery. Thus, apart from providing a 1-to-many forward path and a many-to-1 reverse path, IETF protocols do not need to provide any special support for MIDI multicast networking.
MIDI 1.0 DINネットワークは、「パーティライン」マルチキャストトポロジに構成することができます。これらのネットワークでは、MIDIプロトコル自体は、マルチキャストネットワーク上の取引における特定のデバイスに対処するため、デバイスの発見のためのツールを提供します。このように、離れて1対多のフォワードパスと多対1逆の経路を提供するから、IETFプロトコルは、MIDIマルチキャストネットワークのための特別なサポートを提供する必要はありません。
An mpeg4-generic [RFC3640] RTP MIDI stream uses an MPEG 4 Audio Object Type to render MIDI into audio. Three Audio Object Types accept MIDI input: o General MIDI (Audio Object Type ID 15), based on the General MIDI rendering standard [MIDI].
mpeg4-ジェネリック[RFC3640] RTP MIDIストリームは、オーディオにMIDIをレンダリングするためにMPEG 4オーディオオブジェクトの型を使用しています。 3つのオーディオオブジェクトの種類は、MIDI入力を受け付ける：一般的なMIDIに基づく一般的なMIDI（オーディオオブジェクトタイプID 15）、O規格[MIDI]をレンダリングします。
o Wavetable Synthesis (Audio Object Type ID 14), based on the Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2].
Oウェーブテーブル合成ダウンロード可能なサウンドレベル2（DLS 2）に基づいて（オーディオオブジェクトタイプID 14）は、標準[DLS2]レンダリング。
o Main Synthetic (Audio Object Type ID 13), based on Structured Audio and the programming language SAOL [MPEGSA]. The name of the language (SAOL) is an acronym that expands to Structured Audio Orechestra Language.
構造化オーディオプログラミング言語SAOL [MPEGSA]に基づいて、Oメイン合成（オーディオオブジェクトタイプID 13）。言語（SAOL）の名前は、構造化されたオーディオOrechestra言語への拡大の頭字語です。
The primary service of an mpeg4-generic stream is to code Access Units (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI payload shown in Figure 1 of Section 2.1 of this memo: a MIDI command section optionally followed by a journal section.
mpeg4-ジェネリックストリームの主なサービスは、アクセスユニット（AU）コーディングすることです。必要に応じてジャーナル部に続いてMIDIコマンドセクション：我々は、このメモのセクション2.1の図1に示したMIDIペイロードとしてmpeg4-ジェネリックRTP MIDI AUを定義します。
Exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP MIDI packet. The mpeg4-generic options for placing several AUs in an RTP packet MUST NOT be used with RTP MIDI. The mpeg4-generic options for fragmenting and interleaving AUs MUST NOT be used with RTP MIDI. The mpeg4-generic RTP packet payload (Figure 1 in [RFC3640]) MUST contain empty AU Header and Auxiliary sections. These rules yield mpeg4-generic packets that are structurally identical to native RTP MIDI packets, an essential property for the correct operation of the payload format.
正確に一つのRTP MIDI AUは1 mpeg4-ジェネリックRTP MIDIパケットにマッピングする必要があります。 RTPパケットに複数のAUを配置するためのmpeg4-ジェネリックオプションはRTP MIDIを使用してはいけません。 AUを断片化し、インタリーブするmpeg4-ジェネリックオプションはRTP MIDIを使用してはいけません。 mpeg4-ジェネリックRTPパケットペイロード（[RFC3640]で図1）が空AUヘッダ及び補助部を含まなければなりません。これらのルールは、ネイティブのRTP MIDIパケット、ペイロード形式の正しい操作のための本質的な特性と構造的に同一であり、mpeg4-ジェネリックパケットを生成します。
The session description that follows defines a unicast UDP RTP session (via a media ("m=") line) whose sole payload type (96) is mapped to a minimal mpeg4-generic RTP MIDI stream. This example uses the General MIDI Audio Object Type under Synthesis Profile @ Level 2.
次のセッション記述は、その唯一のペイロードタイプ（96）最小mpeg4-ジェネリックRTP MIDIストリームにマッピングされる（メディア（「M =」）ラインを介して）ユニキャストUDP RTPセッションを定義します。この例では、合成プロファイル@レベル2の下で一般的なMIDIオーディオオブジェクトの型を使用しています。
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB8::7F2E:172A:1E24 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; config=7A0A0000001A4D546864000000060000000100604D54726B0000 000600FF2F000
V = 0 0 = IP6 INラザロ2520644554 2838152170 first.example.net S =例、T = 0、M = IP6 2001年オーディオ5004 RTP / AVP 96個のC =を：DB8 :: 7F2E：172A：1E24 A = rtpmap：96 MPEG4 -generic / 44100 =のfmtp：96 streamtype = 5。モード= RTP-MIDI。プロファイルレベルID = 12。コンフィグ= 7A0A0000001A4D546864000000060000000100604D54726B0000 000600FF2F000
(The a=fmtp line has been wrapped to fit the page to accommodate memo formatting restrictions; it comprises a single line in SDP.)
（A =のfmtpラインは、メモの書式の制限に対応するために、ページに収まるようにラップされています。それはSDP内の1行を含みます。）
The fmtp attribute line codes the four parameters (streamtype, mode, profile-level-id, and config) that are required in all mpeg4-generic session descriptions [RFC3640]. For RTP MIDI streams, the streamtype
fmtp属性線コード全mpeg4-ジェネリックセッション記述[RFC3640]で必要とされる4つのパラメータ（streamtype、モード、プロファイルレベルID、および設定）。 RTP MIDIストリーム、streamtype用
parameter MUST be set to 5, the mode parameter MUST be set to rtp-midi, and the profile-level-id parameter MUST be set to the MPEG-4 Profile Level for the stream. For the Synthesis Profile, legal profile-level-id values are 11, 12, and 13, coding low (11), medium (12), or high (13) decoder computational complexity, as defined by MPEG conformance tests.
パラメータが5に設定しなければなりません、モードパラメータは、RTP-MIDIに設定する必要があり、プロファイルレベル-idパラメータは、ストリームのMPEG-4プロファイル・レベルに設定しなければなりません。 MPEG適合性試験によって定義されるように合成プロファイルの、法的プロファイルレベルIDの値は、11、12、及び13、（11）低符号化、媒体（12）、または高（13）デコーダ計算複雑です。
In a minimal RTP MIDI session description, the config value MUST be a hexadecimal encoding [RFC3640] of the AudioSpecificConfig data block [MPEGAUDIO] for the stream. AudioSpecificConfig encodes the Audio Object Type for the stream and also encodes initialization data (SAOL programs, DLS 2 wave tables, etc.). Standard MIDI Files encoded in AudioSpecificConfig in a minimal session description MUST be ignored by the receiver.
最小RTP MIDIセッション記述において、設定値は、ストリームのMPEGAUDIO] AudioSpecificConfigデータブロックの進エンコーディング[RFC3640]でなければなりません。 AudioSpecificConfigストリーム用のオーディオオブジェクトタイプを符号化し、初期化データ（SAOLプログラム、DLS 2波テーブル、等）をコードします。最小のセッション記述にAudioSpecificConfigで符号化標準MIDIファイルは、受信機によって無視されなければなりません。
Receivers determine the rendering algorithm for the session by interpreting the first 5 bits of AudioSpecificConfig as an unsigned integer that codes the Audio Object Type. In our example above, the 5 bits are coded within the first two nibbles ("7A") of the config string. The Audio Object Type coded within "7A" is Audio Object Type 15 (General MIDI). In Appendix E.4, we derive the config string value in the session description shown above; the starting point of the derivation is the MPEG bitstreams defined in [MPEGSA] and [MPEGAUDIO].
受信機は、符号なし整数そのコードオーディオオブジェクトタイプとしてAudioSpecificConfigの最初の5ビットを解釈することによって、セッションのレンダリングアルゴリズムを決定します。上記の例では、5ビットが設定文字列の最初の二つのニブル（「7」）内に符号化されます。 「7A」内コード化されたオーディオオブジェクトの型は、オーディオオブジェクトタイプ15（ジェネラルMIDI）です。付録E.4では、我々は、上記のセッション記述のconfig文字列値を導き出します。導出の出発点は、[MPEGAUDIO]と[MPEGSA]で定義されたMPEGビットストリームです。
We consider the stream to be "minimal" because the session description does not customize the stream through the use of parameters, other than the 4 required mpeg4-generic parameters described above. In Section 6.1, we describe the behavior of a minimal native stream as a numbered list of characteristics. Items 1-4 on that list also describe the minimal mpeg4-generic stream, but items 5 and 6 require restatements, as listed below:
私たちは、セッション記述は、上記の4必要mpeg4-ジェネリックパラメータ以外のパラメータを使用してストリームをカスタマイズしていないため、ストリームは「最小」であると考えています。 6.1節では、特性の番号付きリストとして最小限のネイティブのストリームの挙動を説明します。そのリストの項目1-4も、最小限のmpeg4-ジェネリックストリームを記述しますが、以下に列挙などの項目5と6は、修正再表示が必要です。
5. If more than one minimal mpeg4-generic stream appears in a session, each stream uses an independent instance of the Audio Object Type coded in the config parameter value.
5.複数の最小限のmpeg4-ジェネリックストリームは、セッション中に表示された場合は、各ストリームは、configパラメータ値にコード化されたオーディオオブジェクトタイプの独立したインスタンスを使用しています。
6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig as an inline hexadecimal constant. If a session description is sent over UDP, it may be impossible to transport large AudioSpecificConfig blocks within the Maximum Transmission Unit (MTU) of the underlying network (for Ethernet, the MTU is 1500 octets). In some cases, the AudioSpecificConfig block may exceed the maximum size of the UDP packet itself.
6.最小MPEG4-ジェネリックストリームインライン進定数としてAudioSpecificConfigをコードします。セッション記述は、UDPを介して送信される場合、基礎となるネットワークの最大送信単位（MTU）（イーサネットのために、MTUが1500オクテットである）内に大AudioSpecificConfigブロックを輸送することが不可能であってもよいです。いくつかの場合において、AudioSpecificConfigブロックはUDPパケット自体の最大サイズを超えてもよいです。
The comments in Section 6.1 on SIP and RTSP stream directional defaults, sendrecv MIDI channel usage, and MIDI 1.0 DIN multicast networks also apply to mpeg4-generic RTP MIDI sessions.
SIPとRTSPストリーム指向のデフォルトのセクション6.1にコメント、SENDRECV MIDIチャンネルの使用状況、およびMIDI 1.0 DINマルチキャストネットワークもmpeg4-ジェネリックRTP MIDIセッションに適用されます。
In sendrecv sessions, each party's session description MUST use identical values for the mpeg4-generic parameters (including the required streamtype, mode, profile-level-id, and config parameters). As a consequence, each party uses an identically configured MPEG 4 Audio Object Type to render MIDI commands into audio. The preamble to Appendix C discusses a way to create "virtual sendrecv" sessions that do not have this restriction.
SENDRECVセッションでは、各当事者のセッション記述（必須streamtype、モード、プロファイルレベルID、および構成パラメータを含む）MPEG4-ジェネリックパラメータの同じ値を使用しなければなりません。その結果、各当事者は、MIDI、オーディオにコマンドをレンダリングするように同一構成のMPEG 4オーディオオブジェクトの型を使用しています。付録Cの前文には、この制限はありません「仮想のsendrecv」セッションを作成する方法について説明します。
This section introduces parameters for session configuration for RTP MIDI streams. In session descriptions, parameters modify the semantics of a payload type. Parameters are specified on an fmtp attribute line. See the session description example in Section 6.2 for an example of a fmtp attribute line.
このセクションでは、RTP MIDIストリームのセッション構成のためのパラメータを導入しています。セッションの説明では、パラメータは、ペイロードタイプのセマンティクスを変更します。パラメータはのfmtp属性ラインで指定されています。 fmtp属性ラインの例については、セクション6.2でのセッション記述の例を参照してください。
The parameters add features to the minimal streams described in Sections 6.1 and 6.2 and support several types of services:
パラメータは、セクション6.1と6.2で説明した最小限のストリームに機能を追加し、サービスのいくつかのタイプをサポートしています。
o Stream subsetting. By default, all MIDI commands that are legal to appear on a MIDI 1.0 DIN cable may appear in an RTP MIDI stream. The cm_unused parameter overrides this default by prohibiting certain commands from appearing in the stream. The cm_used parameter is used in conjunction with cm_unused to simplify the specification of complex exclusion rules. We describe cm_unused and cm_used in Appendix C.1.
Oストリームをサブセット化。デフォルトでは、法定されている全てのMIDIコマンドがRTP MIDIストリームに表示される場合がありますMIDI 1.0 DINケーブル上に表示します。 cm_unusedパラメータは、ストリームに表示され、特定のコマンドを禁止することで、このデフォルトを上書きします。 cm_usedパラメータは、複雑な除外ルールの仕様を簡素化するためにcm_unusedと組み合わせて使用されます。私たちは、付録C.1にcm_unusedとcm_usedについて説明します。
o Journal customization. The j_sec and j_update parameters configure the use of the journal section. The ch_default, ch_never, and ch_anchor parameters configure the semantics of the recovery journal chapters. These parameters are described in Appendix C.2 and override the default stream behaviors 1 and 2 (listed in Section 6.1 and referenced in Section 6.2).
Oジャーナルのカスタマイズ。 j_秒とj_アップデートパラメタは、ジャーナル部の使用を設定します。 ch_default、ch_never、およびch_anchorパラメータは回復ジャーナル章のセマンティクスを設定します。これらのパラメータは、付録C.2に記載されており、（6.1節に記載されていて、セクション6.2で参照）、デフォルトのストリームの行動1と2を無効にしています。
o MIDI command timestamp semantics. The tsmode, octpos, mperiod, and linerate parameters customize the semantics of timestamps in the MIDI command section. These parameters let RTP MIDI accurately encode the implicit time coding of MIDI 1.0 DIN cables. These parameters are described in Appendix C.3 and override default stream behavior 3 (listed in Section 6.1 and referenced in Section 6.2).
MIDIコマンドのタイムスタンプのセマンティクスO。 tsmode、octpos、mperiod、および回線レートパラメータは、MIDIコマンドセクションでタイムスタンプのセマンティクスをカスタマイズします。これらのパラメータは、RTP MIDIが正確にMIDI 1.0 DINケーブルの暗黙の時間コーディングをエンコードしてみましょう。これらのパラメータは、付録C.3に記載されており、オーバーライドデフォルトストリーム振舞い3（セクション6.1に記載されていて、セクション6.2で参照します）。
o Media time. The rtp_ptime and rtp_maxptime parameters define the temporal duration ("media time") of an RTP MIDI packet. The guardtime parameter sets the minimum sending rate of stream packets. These parameters are described in Appendix C.4 and override default stream behavior 4 (listed in Section 6.1 and referenced in Section 6.2).
Oメディア時間。 rtp_ptimeとrtp_maxptimeパラメータは、RTP MIDIパケットの持続時間（「メディア時間」）を定義します。 guardtimeパラメータは、ストリームパケットのレートを送信する最小を設定します。これらのパラメータは、付録C.4に記載されており、オーバーライドデフォルトストリーム振舞い4（セクション6.1に記載されていて、セクション6.2で参照します）。
o Stream description. The musicport parameter labels the MIDI name space of RTP streams in a multimedia session. Musicport is described in Appendix C.5. The musicport parameter overrides default stream behavior 5 (in Sections 6.1 and 6.2).
Oストリーム記述。 musicportパラメタは、RTPのMIDI名前空間は、マルチメディアセッションでストリームラベル。 Musicportは、付録C.5に記載されています。 （セクション6.1および6.2で）musicportパラメータのオーバーライドデフォルトストリーム振舞い5。
o MIDI rendering. Several parameters specify the MIDI rendering method of a stream. These parameters are described in Appendix C.6 and override default stream behavior 6 (in Sections 6.1 and 6.2).
MIDIのレンダリングO。いくつかのパラメータは、ストリームのMIDIのレンダリング方法を指定します。これらのパラメータは、付録C.6に記載されており、オーバーライドデフォルトストリーム振舞い6（セクション6.1および6.2で）されています。
In Appendix C.7, we specify interoperability guidelines for two RTP MIDI application areas: content streaming using RTSP (Appendix C.7.1) and network musical performance using SIP (Appendix C.7.2).
RTSP（付録C.7.1）を使用してコンテンツのストリーミングをし、SIP（付録C.7.2）を使用して演奏をネットワーク：付録C.7では、我々は2つのRTP MIDIの応用分野のための相互運用性ガイドラインを指定します。
The payload format defined in this memo exclusively encodes all commands that may legally appear on a MIDI 1.0 DIN cable.
このメモで定義されたペイロードフォーマットは、もっぱら合法的にMIDI 1.0 DINケーブルに表示される可能性のあるすべてのコマンドを符号化します。
Many worthy uses of MIDI over RTP do not fall within the narrow scope of the payload format. For example, the payload format does not support the direct transport of Standard MIDI File (SMF) meta-event and metric timing data. As a second example, the payload format does not define transport tools for user-defined commands (apart from tools to support System Exclusive commands [MIDI]).
RTPを超えるMIDIの多くの価値がある用途は、ペイロードフォーマットの狭い範囲内に入りません。例えば、ペイロード・フォーマットは、標準MIDIファイル（SMF）メタイベントとメトリックタイミングデータの直接転送をサポートしていません。第2の例として、ペイロード・フォーマットは、（システムエクスクルーシブコマンドをサポートするためのツールとは別に[MIDI]）ユーザ定義コマンドの輸送ツールを定義していません。
The payload format does not provide an extension mechanism to support new features of this nature, by design. Instead, we encourage the development of new payload formats for specialized musical applications. The IETF session management tools [RFC3264] [RFC2326] support codec negotiation, to facilitate the use of new payload formats in a backward-compatible way.
ペイロード形式は、設計によって、この種の新機能をサポートするための拡張メカニズムを提供していません。代わりに、我々は専門の音楽アプリケーション用の新しいペイロードフォーマットの開発を奨励します。 IETFセッション管理ツール[RFC3264] [RFC2326]の下位互換性の方法で新しいペイロードフォーマットの使用を容易にするために、コーデックネゴシエーションをサポートしています。
However, the payload format does provide several extensibility tools, which we list below:
しかし、ペイロード形式は、我々は以下のリストのいくつかの拡張ツールを提供します：
o Journalling. As described in Appendix C.2, new token values for the j_sec and j_update parameters may be defined in IETF Standards-Track documents. This mechanism supports the design of new journal formats and the definition of new journal sending policies.
Oジャーナリング。付録C.2で説明したように、j_秒とj_アップデートパラメータのための新しいトークン値は、IETF標準化過程文書で定義されていてもよいです。このメカニズムは、新しいジャーナルフォーマットの設計と新しいジャーナル送信ポリシーの定義をサポートしています。
o Rendering. The payload format may be extended to support new MIDI renderers (Appendix C.6.2). Certain general aspects of the RTP MIDI rendering process may also be extended, via the definition of new token values for the render (Appendix C.6) and smf_info (Appendix C.6.4.1) parameters.
Oレンダリング。ペイロード形式は、新しいMIDIレンダラー（付録C.6.2）をサポートするように拡張することができます。 RTP MIDIのレンダリングプロセスのいくつかの一般的な側面はまた、新しいレンダリング（付録C.6）のトークン値とsmf_info（付録C.6.4.1）パラメータの定義を経て、延長することができます。
o Undefined commands. [MIDI] reserves 4 MIDI system commands for future use (0xF4, 0xF5, 0xF9, 0xFD). If updates to [MIDI] define the reserved commands, IETF Standards-Track documents may be defined to provide resiliency support for the commands. Opaque LEGAL fields appear in System Chapter D for this purpose (Appendix B.1.1).
未定義のコマンドO。 [MIDI]埋蔵4 MIDIシステムは（0xF4、0xF5、0xF9、0xFDで）将来の使用のためのコマンド。 [MIDI]への更新は、予約コマンドを定義する場合は、IETF標準化過程文書は、コマンドの弾力性のサポートを提供するように定義することができます。不透明な法的フィールドは、この目的（付録B.1.1）のためのシステム章Dに表示されます。
A final form of extensibility involves the inclusion of the payload format in framework documents. Framework documents describe how to combine protocols to form a platform for interoperable applications. For example, a stage and studio framework might define how to use SIP [RFC3261], RTSP [RFC2326], SDP [RFC4566], and RTP [RFC3550] to support media networking for professional audio equipment and electronic musical instruments.
拡張の最終形態は、フレームワーク文書のペイロードフォーマットを含めることを含みます。枠組み文書は、相互運用可能なアプリケーションのためのプラットフォームを形成するためのプロトコルを結合する方法について説明します。例えば、ステージやスタジオフレームワークは、プロオーディオ機器、電子楽器のためのネットワークメディアをサポートするために、SIP [RFC3261]、RTSP [RFC2326]、SDP [RFC4566]、およびRTP [RFC3550]を使用する方法を定義することができます。
The RTP congestion control requirements defined in [RFC3550] apply to RTP MIDI sessions, and implementors should carefully read the congestion control section in [RFC3550]. As noted in [RFC3550], all transport protocols used on the Internet need to address congestion control in some way, and RTP is not an exception.
[RFC3550]で定義されたRTP輻輳制御要件はRTP MIDIセッションに適用され、実装者は慎重に[RFC3550]での輻輳制御セクションをお読みください。 [RFC3550]で述べたように、インターネット上で使用されるすべてのトランスポートプロトコルは、何らかの方法で輻輳制御に対処する必要があり、RTPは例外ではありません。
In addition, the congestion control requirements defined in [RFC3551] apply to RTP MIDI sessions run under applicable profiles. The basic congestion control requirement defined in [RFC3551] is that RTP sessions that use UDP transport should monitor packet loss (via RTCP or other means) to ensure that the RTP stream competes fairly with TCP flows that share the network.
また、[RFC3551]で定義された輻輳制御要件が適用されるプロファイルの下で実行RTP MIDIセッションに適用されます。 [RFC3551]で定義された基本的な輻輳制御要件は、UDPトランスポートを使用するRTPセッションは、RTPストリームがネットワークを共有するTCPフローとかなり競合することを確実にするために（RTCPまたは他の手段を介して）パケット損失を監視しなければならないということです。
Finally, RTP MIDI has congestion control issues that are unique for an audio RTP payload format. In applications such as network musical performance [NMP], the packet rate is linked to the gestural rate of a human performer. Senders MUST monitor the MIDI command source for patterns that result in excessive packet rates and take actions during RTP transcoding to reduce the RTP packet rate. [RFC4696] offers implementation guidance on this issue.
最後に、RTP MIDIはオーディオRTPペイロード形式のために一意である輻輳制御の問題があります。そのようなネットワークの音楽パフォーマンス[NMP]のような用途では、パケットレートは、人間の演奏者の身振り速度に連結されています。送信者は、過度のパケット速度をもたらすパターンのMIDIコマンドソースを監視し、RTPパケットレートを減らすためにRTPトランスコーディング中に行動を取る必要があります。 [RFC4696]はこの問題に関する実装のガイダンスを提供しています。
Implementors should carefully read the Security Considerations sections of the RTP [RFC3550], AVP [RFC3551], and other RTP profile documents, as the issues discussed in these sections directly apply to RTP MIDI streams. Implementors should also review the Secure Real-time Transport Protocol (SRTP, [RFC3711]), an RTP profile that addresses the security issues discussed in [RFC3550] and [RFC3551].
これらのセクションで説明する問題は、直接RTP MIDIストリームに適用される実装者は慎重に、RTP [RFC3550]、AVP [RFC3551]、および他のRTPプロファイル文書のセキュリティの考慮事項のセクションをお読みください。実装者はまた、セキュアリアルタイムトランスポートプロトコル（SRTP、[RFC3711]）、[RFC3550]と[RFC3551]で説明したセキュリティ問題に対処RTPプロファイルを確認してください。
Here, we discuss security issues that are unique to the RTP MIDI payload format.
ここでは、RTP MIDIペイロード形式に固有なセキュリティの問題を議論します。
When using RTP MIDI, authentication of incoming RTP and RTCP packets is RECOMMENDED. Per-packet authentication may be provided by SRTP or by other means. Without the use of authentication, attackers could forge MIDI commands into an ongoing stream, damaging speakers and eardrums. An attacker could also craft RTP and RTCP packets to exploit known bugs in the client and take effective control of a client machine.
RTP MIDI、入ってくるRTPとRTCPパケットの認証を使用する場合に推奨されます。パケットごとの認証は、SRTPによって、または他の手段によって提供されてもよいです。認証を使用せずに、MIDIを偽造可能性があり、攻撃者は、スピーカーと鼓膜を損傷し、継続的な流れの中にコマンド。攻撃者は、クライアントでの既知のバグを悪用し、クライアントマシンの効果的な制御を取るためにRTPとRTCPパケットを作成する可能性があります。
Session management tools (such as SIP [RFC3261]) SHOULD use authentication during the transport of all session descriptions containing RTP MIDI media streams. For SIP, the Security Considerations section in [RFC3261] provides an overview of possible authentication mechanisms. RTP MIDI session descriptions should use authentication because the session descriptions may code initialization data using the parameters described in Appendix C. If an attacker inserts bogus initialization data into a session description, he can corrupt the session or forge an client attack.
セッション管理ツール（例えばSIP [RFC3261]などの）RTP MIDIメディアストリームを含むすべてのセッション記述の輸送中に認証を使用すべきです。 SIP、[RFC3261]でのセキュリティの考慮事項セクションの可能な認証メカニズムの概要を提供します。セッション記述は、攻撃者がセッション記述、彼が破損する可能性がありセッションに偽の初期化データを挿入したり、クライアントの攻撃を偽造した場合、付録Cで説明するパラメータを使用して初期化データをコードすることができるので、RTP MIDIセッション記述は、認証を使用する必要があります。
Session descriptions may also code renderer initialization data by reference, via the url (Appendix C.6.3) and smf_url (Appendix C.6.4.2) parameters. If the coded URL is spoofed, both session and client are open to attack, even if the session description itself is authenticated. Therefore, URLs specified in url and smf_url parameters SHOULD use [RFC2818].
セッション記述は、URL（付録C.6.3）とsmf_url（付録C.6.4.2）パラメータを介して、参照によってコードレンダラーの初期化データを、またしてもよいです。コード化されたURLが詐称されている場合は、セッションとクライアントの両方は、セッション記述自体が認証されていても、攻撃に開放されています。したがって、URLとsmf_urlパラメータで指定されたURLは、[RFC2818]を使用すべきです。
Section 2.1 allows streams sent by a party in two RTP sessions to have the same SSRC value and the same RTP timestamp initialization value, under certain circumstances. Normally, these values are randomly chosen for each stream in a session, to make plaintext guessing harder to do if the payloads are encrypted. Thus, Section 2.1 weakens this aspect of RTP security.
セクション2.1は、二つのRTPセッションにおいてパーティによって送信されたストリームは、特定の状況下で同じSSRC値と同じRTPタイムスタンプの初期値を有することを可能にします。通常、これらの値はランダムにペイロードが暗号化されている場合は行うことが困難推測平文にするために、セッション内の各ストリームのために選択されています。このように、2.1節ではRTPのセキュリティのこの側面を弱めます。
We thank the networking, media compression, and computer music community members who have commented or contributed to the effort, including Kurt B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, Tobias Erichsen, Roni Even, Nicolas Falquet, Adrian Farrel, Dominique Fober, Philippe Gentric, Michael Godfrey, Chris Grigg, Todd Hager, Alfred Hoenes, Russ Housley, Michel Jullian, Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer, Alexey Melnikov, Colin Perkins, Charlie Richmond, Herbie Robinson, Dan Romascanu, Larry Rowe, Eric Scheirer, Dave Singer, Martijn Sipkema, Robert Sparks, William Stewart, Kent Terry, Sean Turner, Magnus Westerlund, Tom White, Jim Wright, Doug Wyatt, and Giorgio Zoia. We also thank the members of the San Francisco Bay Area music and audio community for creating the context for the work, including Don Buchla, Chris Chafe, Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron Lanier, Roger Linn, Richard Lyon, Dana Massie, Max Mathews, Keith McMillen, Carver Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave Smith, Julius Smith, David Wessel, and Matt Wright.
私たちは、クルト・B、シンシアBruyns、スティーブCasner、ポール・デイビス、ロビン・デイヴィス、ジョアン・ダウ、トビアス・エリクセン、ロニでも、ニコラスFalquet含む努力にコメントしたり貢献してきたネットワーク、メディア圧縮、およびコンピュータ音楽のコミュニティのメンバーに感謝しますエードリアンファレル、ドミニクFober、フィリップGentric、マイケル・ゴッドフリー、クリス・グリッグ、トッド・ヘイガー、アルフレッドHoenes、ラスHousley、ミシェルJullian、フィル・カー、ヤング・クォン・リム、ジェシカ・リトル、ヤンファン・デル・ミーア、アレクセイ・メルニコフ、コリンパーキンス、チャーリーリッチモンド、ハービー・ロビンソン、ダンRomascanu、ラリー・ロウ、エリックScheirer、デイブ・シンガー、マルタインSipkema、ロバートスパークス、ウィリアム・スチュワート、ケントテリー、ショーン・ターナー、マグヌスウェスター、トム・ホワイト、ジム・ライト、ダグ・ワイアット、そしてジョルジオZoia。また、ドン・バックラ、クリス・擦れ、リチャード・ドゥダ、ダン・エリス、エイドリアン・フリード、ベン・ゴールド、ジャロン・ラニアー、ロジャー・リン、リチャード・リヨンを含め、仕事のためのコンテキストを作成するためのサンフランシスコのベイエリアの音楽やオーディオのコミュニティのメンバーに感謝します、ダナ・マッシー、マックス・マシューズ、キース・マクミラン、カーバー・ミード、ネルソン・モーガン、トム・オーバーハイム、マルコム・スレイニー、デイブ・スミス、ジュリアス・スミス、デヴィッド・ヴェッセル、そしてマット・ライト。
The bulk of this section is a verbatim reproduction of the IANA considerations that appear in Section 11 of [RFC4695]. Preceding this reproduction, we list several issues concerning this memo that are related to the IANA considerations, as follows:
このセクションの大部分は、[RFC4695]のセクション11に表示されるIANAの考慮の逐語的再生です。次のようにこの再現に先立ち、我々は、IANAの考慮に関連するこのメモに関するいくつかの問題について説明します：
o All existing IANA references to [RFC4695] have been deleted, and replaced with references to this memo. In addition, a reference to this memo has been added to the audio/mpeg4-generic MIME type registration.
O [RFC4695]へのすべての既存のIANAの参照が削除され、このメモへの参照に置き換えられています。また、このメモへの参照は、オーディオ/ MPEG4-ジェネリックMIMEタイプ登録に追加されています。
o In Section 11.3, a sentence has been added to the Encoding Considerations asc Media Type Registration: "Disk files that store this data object use the file extension ".acn"".
「」「このデータオブジェクトを格納するディスク・ファイルは、ファイル拡張子を使用する」.acn：11.3節中のO、文はエンコーディングの考慮事項ASCメディアタイプ登録に追加されました。
The reproduction of the [RFC4695] IANA considerations section appears directly below.
[RFC4695] IANAの考慮セクションの再生は直接の下に表示されます。
This section makes a series of requests to IANA. The IANA has completed registration/assignments of the below requests.
このセクションでは、IANAへの一連の要求を行います。 IANAは以下の要求の登録/割り当てを完了しました。
The subsections that follow hold the actual, detailed requests. All registrations in this section are in the IETF tree and follow the rules of [RFC4288] and [RFC4855], as appropriate.
以下のサブセクションでは、実際、詳細な要求を保持します。このセクションのすべての登録はIETFツリーにあり、必要に応じて、[RFC4288]と[RFC4855]の規則に従ってください。
In Section 11.1, we request the registration of a new media type: audio/rtp-midi. Paired with this request is a request for a repository for new values for several parameters associated with audio/rtp-midi. We request this repository in Section 11.1.1.
オーディオ/ RTP-MIDI：11.1で、私たちは、新しいメディアタイプの登録を要求します。この要求とペアにすることは、オーディオ/ RTP-MIDIに関連したいくつかのパラメータの新しい値のためのリポジトリの要求です。私たちは、セクション11.1.1でこのリポジトリを要求します。
In Section 11.2, we request the registration of a new value (rtp-midi) for the mode parameter of the mpeg4-generic media type. The mpeg4-generic media type is defined in [RFC3640], and [RFC3640] defines a repository for the mode parameter. However, we believe we are the first to request the registration of a mode value, so we believe the registry for mode has not yet been created by IANA.
11.2節では、我々はmpeg4-ジェネリックメディアタイプのモードパラメータの新しい値（RTP-MIDI）の登録を要求します。 MPEG4-ジェネリックメディアタイプは、[RFC3640]で定義され、そして[RFC3640]はモードパラメータのリポジトリを定義します。しかし、我々はモード値の登録を要求する最初のものであると考えているので、我々はモードのレジストリはまだIANAによって作成されていないと信じています。
Paired with our mode parameter value request for mpeg4-generic is a request for a repository for new values for several parameters we have defined for use with the rtp-midi mode value. We request this repository in Section 11.2.1.
mpeg4-ジェネリックのための私達のモードパラメータ値要求とペアにすることは、我々は、RTP-MIDIモードの値で使用するために定義されているいくつかのパラメータの新しい値のためのリポジトリの要求です。私たちは、11.2.1項では、このリポジトリを要求します。
In Section 11.3, we request the registration of a new media type: audio/asc. No repository request is associated with this request.
オーディオ/ ASC：11.3で、私たちは、新しいメディアタイプの登録を要求します。いいえリポジトリの要求は、この要求に関連付けられていません。
This section requests the registration of the rtp-midi subtype for the audio media type. We request the registration of the parameters listed in the "optional parameters" section below (both the "non-extensible parameters" and the "extensible parameters" lists). We also request the creation of repositories for the "extensible parameters"; the details of this request appear in Section 11.1.1.
このセクションでは、オーディオメディアタイプのためのRTP-MIDIサブタイプの登録を要求します。我々は、以下の「オプションのパラメータ」セクション（共に「非拡張可能パラメータ」および「拡張可能なパラメータ」リスト）にリストされたパラメータの登録を要求します。我々はまた、「拡張可能なパラメータ」のためのリポジトリの作成を要求します。この要求の内容は、11.1.1項に表示されます。
Media type name:
メディアタイプ名：
audio
オーディオ
Subtype name:
サブタイプ名：
rtp-midi
RTP午後
Required parameters:
必須パラメータ：
rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1
for usage details.
Optional parameters:
オプションのパラメータ：
Non-extensible parameters:
非拡張可能なパラメータ：
ch_anchor: See Appendix C.2.3 for usage details. ch_default: See Appendix C.2.3 for usage details. ch_never: See Appendix C.2.3 for usage details. cm_unused: See Appendix C.1 for usage details. cm_used: See Appendix C.1 for usage details. chanmask: See Appendix C.6.4.3 for usage details. cid: See Appendix C.6.3 for usage details. guardtime: See Appendix C.4.2 for usage details. inline: See Appendix C.6.3 for usage details. linerate: See Appendix C.3 for usage details. mperiod: See Appendix C.3 for usage details. multimode: See Appendix C.6.1 for usage details. musicport: See Appendix C.5 for usage details. octpos: See Appendix C.3 for usage details.
ch_anchor：使用方法の詳細については、付録C.2.3を参照してください。 ch_default：使用方法の詳細については、付録C.2.3を参照してください。 ch_never：使用方法の詳細については、付録C.2.3を参照してください。 cm_unused：使用方法の詳細については、付録C.1を参照してください。 cm_used：使用方法の詳細については、付録C.1を参照してください。 chanmask：使用方法の詳細については、付録C.6.4.3を参照してください。 CID：使用方法の詳細については、付録C.6.3を参照してください。 guardtime：使用方法の詳細については、付録C.4.2を参照してください。インライン：使用方法の詳細については、付録C.6.3を参照してください。回線レート：使用方法の詳細については、付録C.3を参照してください。 mperiod：使用方法詳細については、付録C.3を参照してください。マルチモード：使用方法の詳細については、付録C.6.1を参照してください。 musicport：使用方法の詳細については、付録C.5を参照してください。 octpos：使用方法の詳細については、付録C.3を参照してください。
rinit: See Appendix C.6.3 for usage details. rtp_maxptime: See Appendix C.4.1 for usage details. rtp_ptime: See Appendix C.4.1 for usage details. smf_cid: See Appendix C.6.4.2 for usage details. smf_inline: See Appendix C.6.4.2 for usage details. smf_url: See Appendix C.6.4.2 for usage details. tsmode: See Appendix C.3 for usage details. url: See Appendix C.6.3 for usage details.
RINIT：使用方法の詳細については、付録C.6.3を参照してください。 rtp_maxptime：使用方法の詳細については、付録C.4.1を参照してください。 rtp_ptime：使用方法の詳細については、付録C.4.1を参照してください。 smf_cid：使用方法については、付録C.6.4.2を参照のこと。 smf_inline：使用方法の詳細については、付録C.6.4.2を参照してください。 smf_url：使用方法の詳細については、付録C.6.4.2を参照してください。 tsmode：使用方法の詳細については、付録C.3を参照してください。 URL：使用方法の詳細は、付録C.6.3を参照のこと。
Extensible parameters:
拡張可能なパラメータ：
j_sec: See Appendix C.2.1 for usage details. See Section 11.1.1 for repository details. j_update: See Appendix C.2.2 for usage details. See Section 11.1.1 for repository details. render: See Appendix C.6 for usage details. See Section 11.1.1 for repository details. subrender: See Appendix C.6.2 for usage details. See Section 11.1.1 for repository details. smf_info: See Appendix C.6.4.1 for usage details. See Section 11.1.1 for repository details.
j_秒：使用方法の詳細については、付録C.2.1を参照してください。リポジトリの詳細については、11.1.1項を参照してください。 j_アップデート：使用方法の詳細については、付録C.2.2を参照してください。リポジトリの詳細については、11.1.1項を参照してください。レンダリング：使用方法の詳細については、付録C.6を参照してください。リポジトリの詳細については、11.1.1項を参照してください。 subrender：使用方法の詳細については、付録C.6.2を参照してください。リポジトリの詳細については、11.1.1項を参照してください。 smf_info：使用方法の詳細については、付録C.6.4.1を参照してください。リポジトリの詳細については、11.1.1項を参照してください。
Encoding considerations:
エンコードの考慮事項：
The format for this type is framed and binary.
このタイプの形式は入り、バイナリです。
Restrictions on usage:
使用に関する制限事項：
This type is only defined for real-time transfers of MIDI
streams via RTP. Stored-file semantics for rtp-midi may
be defined in the future.
Security considerations:
セキュリティの考慮事項：
See Section 9 of this memo.
このメモのセクション9を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
None.
無し。
Published specification:
公開された仕様：
This memo and [MIDI] serve as the normative specification. In
addition, references [NMP], [GRAME], and [RFC4696] provide
non-normative implementation guidance.
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Audio content-creation hardware, such as MIDI controller piano
keyboards and MIDI audio synthesizers. Audio content-creation
software, such as music sequencers, digital audio workstations,
and soft synthesizers. Computer operating systems, for network
support of MIDI Application Programmer Interfaces. Content
distribution servers and terminals may use this media type for
low bitrate music coding.
Additional information:
追加情報：
None.
無し。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン・ラザロ<lazzaro@cs.berkeley.edu>
Intended usage:
意図している用法：
COMMON.
一般。
Author:
著者：
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン・ラザロ<lazzaro@cs.berkeley.edu>
Change controller:
コントローラを変更します。
IETF Audio/Video Transport Working Group delegated
from the IESG.
For the rtp-midi subtype, we request the creation of repositories for extensions to the following parameters (which are those listed as "extensible parameters" in Section 11.1).
RTP-MIDIサブタイプについては、我々は（セクション11.1で、「拡張可能なパラメータ」として記載されたものです）、次のパラメータへの拡張のためのリポジトリの作成を要求します。
j_sec:
j_秒：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.1 of this memo describes appropriate registrations for this repository.
このリポジトリの登録は唯一のIETF標準化過程の文書を経由して発生することがあります。このメモの付録C.2.1はこのリポジトリに適切な登録を説明しています。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"none": Defined in Appendix C.2.1 of this memo. "recj": Defined in Appendix C.2.1 of this memo.
「なし」：このメモの付録C.2.1に定義されます。 「recj」：このメモの付録C.2.1に定義されます。
j_update:
j_アップデート：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.2 of this memo describes appropriate registrations for this repository.
このリポジトリの登録は唯一のIETF標準化過程の文書を経由して発生することがあります。このメモの付録C.2.2はこのリポジトリに適切な登録を説明しています。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"anchor": Defined in Appendix C.2.2 of this memo. "open-loop": Defined in Appendix C.2.2 of this memo. "closed-loop": Defined in Appendix C.2.2 of this memo.
「アンカー」：このメモの付録C.2.2に定義されます。 「オープンループ」：このメモの付録C.2.2に定義されます。 「クローズドループ」：このメモの付録C.2.2に定義されます。
render:
レンダリング：
Registrations for this repository MUST include a specification of the usage of the proposed value. See the preamble of Appendix C.6 for details (the paragraph that begins "Other render token ...").
このリポジトリのための登録は、提案値の使用の仕様を含まなければなりません。詳細については、付録C.6のプリアンブル（始まる段落「その他のトークンレンダリングを...」）を参照してください。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"unknown": Defined in Appendix C.6 of this memo. "synthetic": Defined in Appendix C.6 of this memo. "api": Defined in Appendix C.6 of this memo. "null": Defined in Appendix C.6 of this memo.
「不明」：このメモの付録C.6に定義されます。 「合成」：このメモの付録C.6に定義されます。 「API」：このメモの付録C.6に定義されます。 「ヌル」：このメモの付録C.6に定義されます。
subrender:
サブレンダラー：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.2 for details (the paragraph that begins "Other subrender token ...").
このリポジトリのための登録は、提案値の使用の仕様を含まなければなりません。詳細については、付録C.6.2（「その他のsubrenderトークンを...」から始まる段落）を参照してください。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"default": Defined in Appendix C.6.2 of this memo.
「デフォルト」：このメモの付録C.6.2に定義されます。
smf_info:
smf_info：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.4.1 for details (the paragraph that begins "Other smf_info token ...").
このリポジトリのための登録は、提案値の使用の仕様を含まなければなりません。詳細については、付録C.6.4.1（「その他smf_infoトークン...」から始まる段落）を参照してください。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"ignore": Defined in Appendix C.6.4.1 of this memo. "sdp_start": Defined in Appendix C.6.4.1 of this memo. "identity": Defined in Appendix C.6.4.1 of this memo.
「無視」：このメモの付録C.6.4.1で定義されます。 「sdp_start」：このメモの付録C.6.4.1で定義されます。 「アイデンティティ」：このメモの付録C.6.4.1で定義されます。
This section requests the registration of the rtp-midi value for the mode parameter of the mpeg4-generic media type. The mpeg4-generic media type is defined in [RFC3640], and [RFC3640] defines a repository for the mode parameter. We are registering mode rtp-midi to support the MPEG Audio codecs [MPEGSA] that use MIDI.
このセクションでは、MPEG4-ジェネリックメディアタイプのモードパラメータのためのRTP-MIDI値の登録を要求します。 MPEG4-ジェネリックメディアタイプは、[RFC3640]で定義され、そして[RFC3640]はモードパラメータのリポジトリを定義します。私たちは、MIDIを使っMPEGオーディオコーデック[MPEGSA]をサポートするためのモードRTP-MIDIを登録されています。
In conjunction with this registration request, we request the registration of the parameters listed in the "optional parameters" section below (both the "non-extensible parameters" and the "extensible parameters" lists). We also request the creation of repositories for the "extensible parameters"; the details of this request appear in Appendix 11.2.1.
この登録要求に関連して、我々は、（「非拡張可能パラメータ」の両方と「拡張可能なパラメータ」リスト）は、以下の「オプションパラメータ」に記載されたパラメータの登録を要求します。我々はまた、「拡張可能なパラメータ」のためのリポジトリの作成を要求します。この要求の詳細は、付録11.2.1に表示されます。
Media type name:
メディアタイプ名：
audio
オーディオ
Subtype name:
サブタイプ名：
mpeg4-generic
mpeg4-ジェネリック
Required parameters:
必須パラメータ：
The mode parameter is required by [RFC3640]. [RFC3640]
requests a repository for mode so that new values for mode
may be added. We request that the value rtp-midi be
added to the mode repository.
In mode rtp-midi, the mpeg4-generic parameter rate is a required parameter. Rate specifies the RTP timestamp clock rate. See Sections 2.1 and 6.2 for usage details of rate in mode rtp-midi.
モードRTP-MIDI IN、mpeg4-ジェネリックパラメータ率は必須パラメータです。レートは、RTPタイムスタンプのクロックレートを指定します。モードRTP-MIDI IN率の使用方法の詳細については、セクション2.1と6.2を参照してください。
Optional parameters:
オプションのパラメータ：
We request registration of the following parameters
for use in mode rtp-midi for mpeg4-generic.
Non-extensible parameters:
非拡張可能なパラメータ：
ch_anchor: See Appendix C.2.3 for usage details. ch_default: See Appendix C.2.3 for usage details. ch_never: See Appendix C.2.3 for usage details. cm_unused: See Appendix C.1 for usage details. cm_used: See Appendix C.1 for usage details. chanmask: See Appendix C.6.4.3 for usage details. cid: See Appendix C.6.3 for usage details. guardtime: See Appendix C.4.2 for usage details. inline: See Appendix C.6.3 for usage details. linerate: See Appendix C.3 for usage details. mperiod: See Appendix C.3 for usage details. multimode: See Appendix C.6.1 for usage details. musicport: See Appendix C.5 for usage details. octpos: See Appendix C.3 for usage details. rinit: See Appendix C.6.3 for usage details. rtp_maxptime: See Appendix C.4.1 for usage details. rtp_ptime: See Appendix C.4.1 for usage details. smf_cid: See Appendix C.6.4.2 for usage details. smf_inline: See Appendix C.6.4.2 for usage details. smf_url: See Appendix C.6.4.2 for usage details. tsmode: See Appendix C.3 for usage details. url: See Appendix C.6.3 for usage details.
ch_anchor：使用方法の詳細については、付録C.2.3を参照してください。 ch_default：使用方法の詳細については、付録C.2.3を参照してください。 ch_never：使用方法の詳細については、付録C.2.3を参照してください。 cm_unused：使用方法の詳細については、付録C.1を参照してください。 cm_used：使用方法の詳細については、付録C.1を参照してください。 chanmask：使用方法の詳細については、付録C.6.4.3を参照してください。 CID：使用方法の詳細については、付録C.6.3を参照してください。 guardtime：使用方法の詳細については、付録C.4.2を参照してください。インライン：使用方法の詳細については、付録C.6.3を参照してください。回線レート：使用方法の詳細については、付録C.3を参照してください。 mperiod：使用方法の詳細については、付録C.3を参照してください。マルチモード：使用方法の詳細については、付録C.6.1を参照してください。 musicport：使用方法の詳細については、付録C.5を参照してください。 octpos：使用方法の詳細については、付録C.3を参照してください。 RINIT：使用方法の詳細については、付録C.6.3を参照してください。 rtp_maxptime：使用方法の詳細については、付録C.4.1を参照してください。 rtp_ptime：使用方法の詳細については、付録C.4.1を参照してください。 smf_cid：使用方法の詳細については、付録C.6.4.2を参照してください。 smf_inline：使用方法の詳細については、付録C.6.4.2を参照してください。 smf_url：使用方法の詳細については、付録C.6.4.2を参照してください。 tsmode：使用方法の詳細については、付録C.3を参照してください。 URL：使用方法の詳細については、付録C.6.3を参照してください。
Extensible parameters:
拡張可能なパラメータ：
j_sec: See Appendix C.2.1 for usage details. See Section 11.2.1 for repository details. j_update: See Appendix C.2.2 for usage details. See Section 11.2.1 for repository details. render: See Appendix C.6 for usage details. See Section 11.2.1 for repository details. subrender: See Appendix C.6.2 for usage details. See Section 11.2.1 for repository details. smf_info: See Appendix C.6.4.1 for usage details. See Section 11.2.1 for repository details.
j_秒：使用方法の詳細については、付録C.2.1を参照してください。リポジトリの詳細については、11.2.1項を参照してください。 j_アップデート：使用方法の詳細については、付録C.2.2を参照してください。リポジトリの詳細については、11.2.1項を参照してください。レンダリング：使用方法の詳細については、付録C.6を参照してください。リポジトリの詳細については、11.2.1項を参照してください。 subrender：使用方法の詳細については、付録C.6.2を参照してください。リポジトリの詳細については、11.2.1項を参照してください。 smf_info：使用方法の詳細については、付録C.6.4.1を参照してください。リポジトリの詳細については、11.2.1項を参照してください。
Encoding considerations:
エンコードの考慮事項：
The format for this type is framed and binary.
このタイプの形式は入り、バイナリです。
Restrictions on usage:
使用に関する制限事項：
Only defined for real-time transfers of audio/mpeg4-generic
RTP streams with mode=rtp-midi.
Security considerations:
セキュリティの考慮事項：
See Section 9 of this memo.
このメモのセクション9を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
Except for the marker bit (Section 2.1), the packet formats
for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi)
are identical. The formats differ in use: audio/mpeg4-generic
is for MPEG work, and audio/rtp-midi is for all other work.
Published specification:
公開された仕様：
This memo, [MIDI], and [MPEGSA] are the normative references.
In addition, [NMP], [GRAME], and [RFC4696] provide
non-normative implementation guidance.
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
MPEG 4 servers and terminals that support [MPEGSA].
【MPEGSA]サポートMPEG 4台のサーバと端末。
Additional information:
追加情報：
None.
無し。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン・ラザロ<lazzaro@cs.berkeley.edu>
Intended usage:
意図している用法：
COMMON.
一般。
Author:
著者：
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン・ラザロ<lazzaro@cs.berkeley.edu>
Change controller:
コントローラを変更します。
IETF Audio/Video Transport Working Group delegated
from the IESG.
For mode rtp-midi of the mpeg4-generic subtype, we request the creation of repositories for extensions to the following parameters (which are those listed as "extensible parameters" in Section 11.2).
mpeg4-ジェネリックサブタイプのモードRTP-MIDIについては、我々は（セクション11.2で、「拡張可能なパラメータ」として記載されたものです）、次のパラメータへの拡張のためのリポジトリの作成を要求します。
j_sec:
j_秒：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.1 of this memo describes appropriate registrations for this repository.
このリポジトリの登録は唯一のIETF標準化過程の文書を経由して発生することがあります。このメモの付録C.2.1はこのリポジトリに適切な登録を説明しています。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"none": Defined in Appendix C.2.1 of this memo. "recj": Defined in Appendix C.2.1 of this memo.
「なし」：このメモの付録C.2.1に定義されます。 「recj」：このメモの付録C.2.1に定義されます。
j_update:
j_アップデート：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.2 of this memo describes appropriate registrations for this repository.
このリポジトリの登録は唯一のIETF標準化過程の文書を経由して発生することがあります。このメモの付録C.2.2はこのリポジトリに適切な登録を説明しています。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"anchor": Defined in Appendix C.2.2 of this memo. "open-loop": Defined in Appendix C.2.2 of this memo. "closed-loop": Defined in Appendix C.2.2 of this memo.
「アンカー」：このメモの付録C.2.2に定義されます。 「オープンループ」：このメモの付録C.2.2に定義されます。 「クローズドループ」：このメモの付録C.2.2に定義されます。
render:
レンダリング：
Registrations for this repository MUST include a specification of the usage of the proposed value. See the preamble of Appendix C.6 for details (the paragraph that begins "Other render token ...").
このリポジトリのための登録は、提案値の使用の仕様を含まなければなりません。詳細については、付録C.6のプリアンブル（始まる段落「その他のトークンレンダリングを...」）を参照してください。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"unknown": Defined in Appendix C.6 of this memo. "synthetic": Defined in Appendix C.6 of this memo. "null": Defined in Appendix C.6 of this memo.
「不明」：このメモの付録C.6に定義されます。 「合成」：このメモの付録C.6に定義されます。 「ヌル」：このメモの付録C.6に定義されます。
subrender:
サブレンダラー：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.2 for details (the paragraph that begins "Other subrender token ..." and subsequent paragraphs). Note that the text in Appendix C.6.2 contains restrictions on subrender registrations for mpeg4-generic (the sentence that begins "Registrations for mpeg4-generic subrender values ...").
このリポジトリのための登録は、提案値の使用の仕様を含まなければなりません。詳細については、付録C.6.2（「その他のsubrenderトークン...」とそれに続く段落を開始しますパラグラフ）を参照してください。付録C.6.2内のテキストがmpeg4-ジェネリックのためのsubrender登録の制限が含まれていることに注意してください（始まる文「mpeg4-ジェネリックのsubrender値の登録を...」）。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"default": Defined in Appendix C.6.2 of this memo.
「デフォルト」：このメモの付録C.6.2に定義されます。
smf_info:
smf_info：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.4.1 for details (the paragraph that begins "Other smf_info token ...").
このリポジトリのための登録は、提案値の使用の仕様を含まなければなりません。詳細については、付録C.6.4.1（「その他smf_infoトークン...」から始まる段落）を参照してください。
Initial values for this repository appear below:
このリポジトリの初期値は以下の表示されます。
"ignore": Defined in Appendix C.6.4.1 of this memo. "sdp_start": Defined in Appendix C.6.4.1 of this memo. "identity": Defined in Appendix C.6.4.1 of this memo.
「無視」：このメモの付録C.6.4.1で定義されます。 「sdp_start」：このメモの付録C.6.4.1で定義されます。 「アイデンティティ」：このメモの付録C.6.4.1で定義されます。
This section registers asc as a subtype for the audio media type. We register this subtype to support the remote transfer of the "config" parameter of the mpeg4-generic media type [RFC3640] when it is used with mpeg4-generic mode rtp-midi (registered in Appendix 11.2 above). We explain the mechanics of using audio/asc to set the config parameter in Section 6.2 and Appendix C.6.5 of this document.
このセクションでは、オーディオメディアタイプのサブタイプとしてASCを登録します。我々は、それが（上記付録11.2に登録）mpeg4-ジェネリックモードRTP-MIDIと共に使用されるMPEG4-ジェネリックメディアタイプ[RFC3640]の「設定」パラメータのリモート転送をサポートするために、このサブタイプを登録します。私たちは、6.2節と、このドキュメントの付録C.6.5にconfigパラメータを設定するために、オーディオ/ ASCを使用しての仕組みを説明します。
Note that this registration is a new subtype registration and is not an addition to a repository defined by MPEG-related memos (such as [RFC3640]). Also, note that this request for audio/asc does not register parameters and does not request the creation of a repository.
この登録は、新しいサブタイプの登録であり、MPEG-関連メモによって定義されたリポジトリに加えないことに留意されたい（例えば、[RFC3640]など）。また、オーディオ/ ASCのためのこの要求は、パラメータを登録しないと、リポジトリの作成を要求しないことに注意してください。
Media type name:
メディアタイプ名：
audio
オーディオ
Subtype name:
サブタイプ名：
asc
ASC
Required parameters:
必須パラメータ：
None.
無し。
Optional parameters:
オプションのパラメータ：
None.
無し。
Encoding considerations:
エンコードの考慮事項：
The native form of the data object is binary data,
zero-padded to an octet boundary. Disk files that
store this data object use the file extension ".acn".
Restrictions on usage:
使用に関する制限事項：
This type is only defined for data object (stored file)
transfer. The most common transports for the type are
HTTP and SMTP.
Security considerations:
セキュリティの考慮事項：
See Section 9 of this memo.
このメモのセクション9を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
None.
無し。
Published specification:
公開された仕様：
The audio/asc data object is the AudioSpecificConfig
binary data structure, which is normatively defined in
[MPEGAUDIO].
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
MPEG 4 Audio servers and terminals that support
audio/mpeg4-generic RTP streams for mode rtp-midi.
Additional information:
追加情報：
None.
無し。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン・ラザロ<lazzaro@cs.berkeley.edu>
Intended usage:
意図している用法：
COMMON.
一般。
Author:
著者：
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン・ラザロ<lazzaro@cs.berkeley.edu>
Change controller:
コントローラを変更します。
IETF Audio/Video Transport Working Group delegated
from the IESG.
This document fixes errors found in RFC 4695 by reviewers. We thank Alfred Hoenes, Roni Even, and Alexey Melnikov for reporting the errors. To our knowledge, there are no interoperability issues associated with the errors that are fixed by this document. In this section, we list the error fixes.
この文書は、審査によってRFC 4695で見つかったエラーを修正します。我々は、エラーを報告するためにアルフレッドHoenes、ロニでも、とアレクセイメルニコフに感謝します。我々の知る限りでは、この文書で固定されているエラーに関連した相互運用性の問題はありません。このセクションでは、エラーの修正を一覧表示します。
In Section 3 of RFC 4695, the bitfield format shown in Figure 3 is inconsistent with the normative text that (correctly) describes the bitfield. Specifically, Figure 3 in RFC 4695 incorrectly states the dependence of the Delta Time 0 field on the Z header bit. Figure 3 in this document corrects this error. To our knowledge, this error did not result in incorrect implementations of RFC 4695.
RFC 4695のセクション3において、図3に示すビットフィールドのフォーマットは（正しく）ビットフィールドを記述する規定テキストと一致しません。具体的には、RFC 4695で図3は、誤っZヘッダビットにデルタタイム0フィールドの依存性を述べています。この文書に記載されている図3に、このエラーを修正します。我々の知る限りでは、このエラーは、RFC 4695の間違った実装には至りませんでした。
The remaining errors are in Appendices C and D and concern session configuration parameters. The numbered list ((1) through (11)) below describes these errors in detail, in order of appearance in the document. To our knowledge, there are no interoperability issues associated with these errors, as implementation activity has so far focused on an application domain that does not use SDP for session management.
残りのエラーは、付録CおよびDと懸念セッション設定パラメータです。 （（11）から（1））番号付きリストは、以下の文書に出現順に、詳細にはこれらのエラーを記述する。実装活動は、これまでのセッション管理のためのSDPを使用していないアプリケーションドメインに焦点を当てているように、私たちの知る限りでは、これらのエラーに関連した相互運用性の問題は、存在しません。
(1) In Appendices C.1 and C.2.3 of RFC 4695, an ABNF rule related to System Chapter X is incorrectly defined as:
（1）付録C.1及びRFC 4695のC.2.3において、システム章Xに関連ABNF規則が誤って次のように定義されます。
<parameter> = "__" <h-list> ["_" <h-list>] "__"
<パラメータ> = "__" <H-リスト> [ "_" <H-リスト> "__"
The correct version of this rule is:
このルールの正しいバージョンは次のとおりです。
<parameter> = "__" <h-list> *( "_" <h-list> ) "__"
<パラメータ> = "__" <H-リスト> *（ "_" <H-リスト>） "__"
(2) In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned to the url parameter are not stated clearly. URIs assigned to url MUST specify either HTTP or HTTP over TLS transport protocols.
（2）RFC 4695の付録C.6.3に、URIは明記されていないURLパラメータに割り当てることを許可さ。 URLに割り当てられたURIはTLSトランスポートプロトコル上でHTTPまたはHTTPのいずれかを指定しなければなりません。
In Appendix C.7.1 and C.7.2 of RFC 4695, the transport interoperability requirements for the url parameter are not stated clearly. For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS is OPTIONAL.
RFC 4695の付録C.7.1およびC.7.2では、urlパラメータのための輸送相互運用性の要件が明記されていません。 C.7.1とC.7.2の両方のために、HTTPは必須であり、TLSを超えるHTTPはオプションです。
(3) In Appendix C.6.5, the filename extension ".acn" has been defined for use with AudioSpecificConfig.
（3）付録C.6.5は、ファイル拡張子「.acn」はAudioSpecificConfigで使用するために定義されています。
(4) Both fmtp lines in both session description examples in Appendix C.7.2 of RFC 4695 contain instances of the same syntax error (a missing ";" at a line wrap after a cm_used assignment).
（4）RFC 4695の付録C.7.2の両方のセッション記述例でのfmtp線の両方が同じ構文エラーのインスタンスを含む（欠落を「;」cm_used割り当て後の行ラップで）。
(5) In the session description examples in Appendix C.5, C.6, and C.7 of RFC 4695, the parameter assignment
（5）RFC 4695の付録C.5、C.6およびC.7におけるセッション記述例では、パラメータの割り当て
rinit="audio/asc";
鼻炎は= "オーディオ/ ASC"
is incorrect. The correct parameter assignment appears below:
間違っています。正しいパラメータの割り当ては下記に表示されます。
rinit=audio/asc;
鼻炎=オーディオ/ ASC。
Note that this error also appears in the session descriptions shown in Figures 1 and 2 of the informative RFC 4696. We are not aware of existing implementations that use the rinit parameter, and so the incorrect examples in RFC 4695 and RFC 4696 should not cause interoperability problems.
このエラーはまた、我々はRINITパラメータを使用する既存の実装を認識していない、ので、RFC 4695およびRFC 4696に誤った例では、相互運用性が発生することはありません有益RFC 4696.の図1と図2に示したセッション記述に表示されていることに注意してください問題。
(6) In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules are in error and should be replaced with "ietf-extension". Likewise, all uses of "*extension" are in error and should be replaced with "extension". This bug incorrectly lets the null token be assigned to the j_sec, j_update, render, smf_info, and subrender parameters.
（6）RFC 4695の付録Dにおいて、ルールにおける「* IETF拡張」のすべての使用はエラーであり、「IETF延長」に置き換えなければなりません。同様に、「*拡張」のすべての使用は誤っていると、「拡張子」に置き換えてください。このバグは間違ってnullのトークンがj_秒、j_アップデート、レンダリング、smf_info、とのsubrenderパラメータに割り当てることができます。
(7) In Appendix D of RFC 4695, the definitions of <command-type> and <chapter-rules> incorrectly allow lowercase letters to appear in these strings. The correct definitions of these rules appear below:
（7）RFC 4695の付録Dにおいて、<コマンドタイプ>と<チャプタールール>の定義が間違って小文字はこれらの文字列に表示されることを可能にします。これらのルールの正しい定義は、以下の表示されます。
command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
コマンドタイプ= [A] [B] [C] [F] [G]、[H] [J] [K] [M] [N] [P] [Q] [T] [V] [W] [ X] [Y] [Z]
chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
チャプターリスト= [A] [B] [C] [D] [E]、[F]、[G]、[H] [J] [K] [M] [N] [P] [Q] [T] [ V] [W] [X] [Y] [Z]
A = %x41 B = %x42 C = %x43 D = %x44 E = %x45 F = %x46 G = %x47
=％のX41のB =％X42 C =％X43 D =％のX44 E =％X45 F =％X46 G =％X47
H = %x48 J = %x4A K = %x4B M = %x4D N = %x4E P = %x50 Q = %x51 T = %x54 V = %x56 W = %x57 X = %x58 Y = %x59 Z = %x5A
H =％のX48 J =％のX4AのK =％x4B M =％x4D N =％x4E P =％X50 Q =％X51 T =％X54 V =％のX56 W =％X57 X =％のX58 Y =％X59 Z = ％のX5A
(8) In Appendix D of RFC 4695, the definitions of <nonzero-four-octet>, <four-octet>, and <midi-chan> are incorrect. The correct definitions of these rules appear below:
（8）RFC 4695の付録Dにおいて、<非ゼロ4オクテット>、<4オクテット>、および<MIDIちゃん>の定義が正しくありません。これらのルールの正しい定義は、以下の表示されます。
nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) / (%x31-33 9(DIGIT)) / ("4" %x30-31 8(DIGIT)) / ("42" %x30-38 7(DIGIT)) / ("429" %x30-33 6(DIGIT)) / ("4294" %x30-38 5(DIGIT)) / ("42949" %x30-35 4(DIGIT)) / ("429496" %x30-36 3(DIGIT)) / ("4294967" %x30-31 2(DIGIT)) / ("42949672" %x30-38 (DIGIT)) / ("429496729" %x30-34)
非ゼロ4オクテット=（NZ-DIGIT 0 * 8（DIGIT））/（％x31-33 9（DIGIT））/（ "4" ％x30-31 8（DIGIT））/（ "42" ％x30- 38 7（DIGIT））/（ "429" ％x30-33 6（DIGIT））/（ "4294" ％x30-38 5（DIGIT））/（ "42949" ％x30-35 4（DIGIT））/（ "429496" ％x30-36 3（DIGIT））/（ "4294967" ％x30-31 2（DIGIT））/（ "42949672" ％のx30-38（DIGIT））/（ "429496729" ％のx30-34）
four-octet = "0" / nonzero-four-octet midi-chan = DIGIT / ("1" %x30-35)
4オクテット= "0" /非ゼロ4オクテットのMIDIちゃん= DIGIT /（ "1" ％のx30-35）
DIGIT = %x30-39 NZ-DIGIT = %x31-39
DIGIT =％x30-39 NZ-DIGIT =％x31-39
(9) In Appendix D of RFC4695, the rule <hex-octet> is incorrect. The correct definition of this rule appears below.
（9）RFC4695の付録Dにおいて、ルール<ヘキサオクテット>が正しくありません。このルールの正しい定義を以下に示します。
hex-octet = %x30-37 U-HEXDIG U-HEXDIG = DIGIT / A / B / C / D / E / F
ヘキサオクテット=％x30-37 U-HEXDIG U-HEXDIG = DIGIT / A / B / C / D / E / F
; DIGIT as defined in (6) above ; A, B, C, D, E, F as defined in (5) above
;上記（6）で定義されるようにDIGIT。 、B、C、D、E、F（5）上記で定義され
(10) In Appendix D, the <mime-subtype> rule now points to the <subtype-name> rule in [RFC4288].
（10）付録Dにおいて、<MIMEサブタイプ>ルールが[RFC4288]の<サブタイプ名>にルールを指します。
(11) In Appendix D of RFC4695, the rules <base64-unit> and <base64-pad> are defined unclearly. The rewritten rules appear below:
RFC4695の付録D（11）、ルールは、<base64でユニット>と<base64でパッド>不鮮明に定義されています。書き換え規則は、以下の表示されます。
base64-unit = 4(base64-char) base64-pad = (2(base64-char) "==") / (3(base64-char) "=")
BASE64ユニット= 4（base64でCHAR）BASE64パッド=（2（base64でチャー） "=="）/（3（base64でチャー） "="）
Appendix A. The Recovery Journal Channel Chapters
付録A.ザ・リカバリー・ジャーナルチャンネル章
A.1. Recovery Journal Definitions
A.1。回復ジャーナルの定義
This appendix defines the terminology and the coding idioms that are used in the recovery journal bitfield descriptions in Section 5 (journal header structure), Appendices A.2 to A.9 (channel journal chapters), and Appendices B.1 to B.5 (system journal chapters).
この付録では、用語を定義し、回復ジャーナルに使用される符号化イディオムはB.5に、セクション5（ジャーナル・ヘッダ構造）A.9に、付録A.2（チャネルジャーナル章）、および付録B.1の記述をビットフィールド（システムジャーナル章）。
We assume that the recovery journal resides in the journal section of an RTP packet with sequence number I ("packet I") and that the Checkpoint Packet Seqnum field in the top-level recovery journal header refers to a previous packet with sequence number C (an exception is the self-referential C = I case). Unless stated otherwise, algorithms are assumed to use modulo 2^16 arithmetic for calculations on 16-bit sequence numbers and modulo 2^32 arithmetic for calculations on 32-bit extended sequence numbers.
我々は、I（「パケットI」）回復ジャーナルシーケンス番号を有するRTPパケットのジャーナル部に存在すると仮定し、トップレベルの回復ジャーナルヘッダーのチェックポイントパケットSEQNUMフィールドは、（シーケンス番号Cと前のパケットを指すこと例外は）自己参照C = Iの場合です。特に明記しない限り、アルゴリズムは、16ビットのシーケンス番号と32ビットの拡張シーケンス番号の計算のためにモジュロ2 ^ 32演算で計算するためにモジュロ2 ^ 16の演算を使用することが想定されます。
Several bitfield coding idioms appear throughout the recovery journal system with consistent semantics. Most recovery journal elements begin with an "S" (Single-packet loss) bit. S bits are designed to help receivers efficiently parse through the recovery journal hierarchy in the common case of the loss of a single packet.
いくつかのビットフィールドのコーディングのイディオムは、一貫性のセマンティクスを持つ回復ジャーナルシステム全体に表示されます。ほとんどの回復ジャーナル要素は、「S」（シングルパケット損失）ビットで始まります。 Sビットは、受信機が効率的に単一のパケットの損失の一般的な場合には回復ジャーナル階層を解析に役立つように設計されています。
As a rule, S bits MUST be set to 1. However, an exception applies if a recovery journal element in packet I encodes data about a command stored in the MIDI command section of packet I - 1. In this case, the S bit of the recovery journal element MUST be set to 0. If a recovery journal element has its S bit set to 0, all higher-level recovery journal elements that contain it MUST also have S bits that are set to 0, including the top-level recovery journal header.
原則として、Sビットはパケットの回復ジャーナル要素がIパケットのMIDIコマンド部に格納されたコマンドに関するデータを符号化した場合、例外が適用され、しかし1に設定しなければなりませんI - この場合には1、のSビット回復ジャーナル要素が0に設定され、そのSビットがある場合は回復ジャーナル要素は、それを含むすべての上位レベルの回復ジャーナル要素は、トップレベルの回復を含む0に設定されるSビットを、またなければならず、0に設定しなければなりませんジャーナルヘッダ。
Other consistent bitfield coding idioms are described below:
その他の一貫性のあるビットフィールドのコーディングイディオムは以下の通りであります：
o R flag bit. R flag bits are reserved for future use. Senders MUST set R bits to 0. Receivers MUST ignore R bit values.
O Rフラグビット。 Rフラグビットは将来の使用のために予約されています。送信者は、Rビット値を無視しなければならない0レシーバにRビットを設定しなければなりません。
o LENGTH field. All fields named LENGTH (as distinct from LEN) code the number of octets in the structure that contains it, including the header it resides in and all hierarchical levels below it. If a structure contains a LENGTH field, a receiver MUST use the LENGTH field value to advance past the structure during parsing, rather than use knowledge about the internal format of the structure.
OのLENGTHフィールド。 （LENとは異なり）の長さを指定されたすべてのフィールドがヘッダ内に存在し、その下のすべての階層レベルを含む、それを含む構造におけるオクテットの数コード。構造は、長さフィールドが含まれている場合、受信機は、解析中に構造体を越えて前進するLENGTHフィールド値を使用するのではなく、構造体の内部フォーマットについての知識を使用しなければなりません。
We now define normative terms used to describe recovery journal semantics.
私たちは今、回復ジャーナル意味論を記述するために使用される規範的な用語を定義します。
o Checkpoint history. The checkpoint history of a recovery journal is the concatenation of the MIDI command sections of packets C through I - 1. The final command in the MIDI command section for packet I - 1 is considered the most recent command; the first command in the MIDI command section for packet C is the oldest command. If command X is less recent than command Y, X is considered to be "before Y". A checkpoint history with no commands is considered to be empty. The checkpoint history never contains the MIDI command section of packet I (the packet containing the recovery journal), so if C == I, the checkpoint history is empty by definition.
Oチェックポイント履歴。回復ジャーナルのチェックポイント歴史がIを介してパケットのCのMIDIコマンドセクションを連結したものです - パケットのMIDIコマンドセクション1.最後のコマンドI - 1最新のコマンドと考えられています。パケットCのためのMIDIコマンドセクションの最初のコマンドは、最も古いコマンドです。コマンドXコマンドY未満最近のものである場合、Xは「Yの前に」であると考えられています。コマンドのないチェックポイント歴史が空であると考えられています。 C == I、チェックポイント歴史が定義では空であるかのように、チェックポイントの歴史は、パケットI（回復ジャーナルを含むパケット）のMIDIコマンドのセクションが含まれていません。
o Session history. The session history of a recovery journal is the concatenation of MIDI command sections from the first packet of the session up to packet I - 1. The definitions of command recency and history emptiness follow those in the checkpoint history. The session history never contains the MIDI command section of packet I, so the session history of the first packet in the session is empty by definition.
Oセッション履歴。コマンドの新しさと歴史の空虚の1の定義チェックポイント歴史の中で、それらに従ってください - パケットIまで回復ジャーナルのセッション履歴は、セッションの最初のパケットからのMIDIコマンドのセクションを連結したものです。セッション履歴は決してパケットIのMIDIコマンドのセクションが含まれていないので、セッションの最初のパケットのセッション履歴は、定義では空です。
o Finished/unfinished commands. If all octets of a MIDI command appear in the session history, the command is defined as being finished. If some but not all octets of a command appear in the session history, the command is defined as being unfinished. Unfinished commands occur if segments of a SysEx command appear in several RTP packets. For example, if a SysEx command is coded as 3 segments, with segment 1 in packet K, segment 2 in packet K + 1, and segment 3 in packet K + 2, the session histories for packets K + 1 and K + 2 contain unfinished versions of the command. A session history contains a finished version of a cancelled SysEx command if the history contains the cancel sublist for the command.
O完成/未完成のコマンド。 MIDIコマンドのすべてのオクテットがセッション履歴に表示された場合は、コマンドが終了していると定義されます。コマンドの一部ではなく、すべてのオクテットがセッション履歴に表示された場合、コマンドは未完成であると定義されます。 SysExコマンドのセグメントは、いくつかのRTPパケットに表示された場合に未完成のコマンドが発生します。システムエクスクルーシブコマンドは、パケットkのパケットK、パケットk + 1におけるセグメント2、セグメント3、セグメント1と、3つのセグメントとして符号化される場合、例えば、+ 2、パケットのセッション履歴は、K + 1、K + 2が含まれていますコマンドの未完成バージョン。歴史は、コマンドのキャンセルサブリストが含まれている場合、セッション履歴はキャンセルのSysExコマンドの完成版が含まれています。
o Reset State commands. Reset State (RS) commands reset renderers to an initialized "powerup" condition. The RS commands are System Reset (0xFF), General MIDI System Enable (0xF0 0x7E 0xcc 0x09 0x01 0xF7), General MIDI 2 System Enable (0xF0 0x7E 0xcc 0x09 0x03 0xF7), General MIDI System Disable (0xF0 0x7E 0xcc 0x09 0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 0x01 0xF7), and Turn DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7). Registrations of subrender parameter token values (Appendix C.6.2) and IETF Standards-Track documents MAY specify additional RS commands.
O状態コマンドをリセットします。状態（RS）が初期化された「パワーアップ」状態にリセットレンダラーコマンドリセットします。 RSコマンドシステムリセット（0xFFで）されている、一般的なMIDIシステムの有効化（0xF0が0x7Eを0xcc 0x09の0x01の0xF7）、一般的なMIDI 2システムイネーブル（0xF0が0x7Eを0xcc 0x09の0x03の0xF7）、一般的なMIDIシステムの無効化（0xF0が0x7Eを0xcc 0x09の0x00の0xF7）、 DLSオンに（0xF0が0x7Eを0xccの0x0A 0x01の0xF7）を回し、そして（0xF0が0x7Eを0xccの0x0A 0x02の0xF7）DLSをオフにしてください。 subrenderパラメータトークン値（付録C.6.2）とIETF標準化過程文書の登録は、追加のRSコマンドを指定するかもしれません。
o Active commands. Active commands are MIDI commands that do not appear before a Reset State command in the session history.
アクティブコマンドO。アクティブコマンドは、セッション履歴でリセット状態コマンドの前に表示されていないMIDIコマンドです。
o N-active commands. N-active commands are MIDI commands that do not appear before one of the following commands in the session history: MIDI Control Change numbers 123-127 (numbers with All Notes Off semantics) or 120 (All Sound Off), and any Reset State command.
O N-アクティブコマンド。 MIDIコントロールチェンジ番号123-127（すべてのノートとの数字の意味オフ）または120（オール・サウンド・オフ）、および任意のリセット状態コマンド：N-アクティブコマンドは、セッションの歴史の中で、次のいずれかのコマンドの前に表示されていないMIDIコマンドです。
o C-active commands. C-active commands are MIDI commands that do not appear before one of the following commands in the session history: MIDI Control Change number 121 (Reset All Controllers) and any Reset State command.
C-アクティブコマンドO。 MIDIコントロールチェンジ番号121（リセット・オール・コントローラー）と、任意のリセット状態コマンド：C-アクティブコマンドは、セッションの歴史の中で、次のいずれかのコマンドの前に表示されていないMIDIコマンドです。
o Oldest-first ordering rule. Several recovery journal chapters contain a list of elements, where each element is associated with a MIDI command that appears in the session history. In most cases, the chapter definition requires that list elements be ordered in accordance with the "oldest-first ordering rule". Below, we normatively define this rule.
O古い-最初の発注ルール。いくつかの回復ジャーナル章では、各要素は、セッション履歴に表示されたMIDIコマンドに関連付けられている要素のリストが含まれています。ほとんどの場合、章の定義は、リストの要素は、「最も古い最初の注文規則」に従って注文されている必要があります。以下に、私たちは、規範的にこのルールを定義します。
Elements associated with the most recent command in the session history coded in the list MUST appear at the end of the list.
リストにコード化されたセッションの歴史の中で最も最近のコマンドに関連する要素は、リストの最後に表示されなければなりません。
Elements associated with the oldest command in the session history coded in the list MUST appear at the start of the list.
リストにコード化されたセッションの歴史の中で最も古いコマンドに関連する要素は、リストの先頭に表示される必要があります。
All other list elements MUST be arranged with respect to these boundary elements, to produce a list ordering that strictly reflects the relative session history recency of the commands coded by the elements in the list.
他のすべてのリスト要素は、厳密にリスト内の要素によって符号化されたコマンドの相対セッション履歴期限を反映リストの順序を生成するために、これらの境界要素に対して配置しなければなりません。
o Parameter system. A MIDI feature that provides two sets of 16,384 parameters to expand the 0-127 controller number space. The Registered Parameter Numbers (RPN) system and the Non-Registered Parameter Numbers (NRPN) system each provide 16,384 parameters.
Oパラメータシステム。 0-127コントローラ番号空間を拡大し16,384のパラメータの二組を提供するMIDI機能。登録パラメータ番号（RPN）システムと非登録パラメータ番号（NRPN）システムそれぞれ16,384パラメータを提供します。
o Parameter system transaction. RPN and NRPN values are changed by a series of Control Change commands that form a parameter system transaction. A canonical transaction begins with two Control Change commands to set the parameter number (controller numbers 99 and 98 for NRPN parameters, controller numbers 101 and 100 for RPN parameters). The transaction continues with an arbitrary number of Data Entry (controller numbers 6 and 38), Data Increment (controller number 96), and Data Decrement (controller number 97) Control Change commands to set the parameter value. The transaction ends with a second pair of (99, 98) or (101, 100) Control Change commands that specify the null parameter (Most Significant Bit (MSB) value 0x7F, Least Significant Bit (LSB) value 0x7F).
Oパラメータシステムトランザクション。 RPNとNRPNの値は、パラメータのシステムトランザクションを構成するコントロールチェンジの一連のコマンドによって変更されています。正規のトランザクションは、2つの制御を変更することから始まるパラメータ番号（コントローラ番号99とNRPNパラメータ98、コントローラ番号101とRPNパラメータの100）を設定するためのコマンド。トランザクションは、データ入力（コントローラ番号6及び38）、データインクリメント（コントローラ番号96）、およびデータデクリメント（コントローラ番号97）コントロールチェンジの任意の数に続くパラメータ値を設定するコマンド。トランザクションは、コントロールチェンジはそれがヌルパラメータ（最上位ビット（MSB）の値0x7Fの最下位ビット（LSB）値から0x7F）を指定するコマンド（99、98）又は（101、100）の第二の対で終了します。
Several variants of the canonical transaction sequence are possible. Most commonly, the terminal pair of (99, 98) or (101, 100) Control Change commands may specify a parameter other than the null parameter. In this case, the command pair terminates the first transaction and starts a second transaction. The command pair is considered to be a part of both transactions. This variant is legal and recommended in [MIDI]. We refer to this variant as a "type 1 variant".
標準的なトランザクションシーケンスのいくつかの変形が可能です。最も一般的には、コントロールチェンジコマンド（99、98）又は（101、100）の端子対はnullパラメータ以外のパラメータを指定することができます。この場合、コマンドのペアは最初のトランザクションを終了し、第2のトランザクションを開始します。コマンド対が両方のトランザクションの一部であると考えられます。この亜種は、法的および[MIDI]にお勧めです。私たちは、「タイプ1変異体」としてこのバリアントを参照してください。
Less commonly, the MSB (99 or 101) or LSB (98 or 100) command of a (99, 98) or (101, 100) Control Change pair may be omitted.
あまり一般的ではないが、MSB（99または101）または（99、98）又は（101、100）のLSB（98または100）コマンドコントロールチェンジ対は省略されてもよいです。
If the MSB command is omitted, the transaction uses the MSB value of the most recent C-active Control Change command for controller number 99 or 101 that appears in the session history. We refer to this variant as a "type 2 variant".
MSBコマンドが省略された場合、トランザクションは、セッション履歴に表示されるコントローラ番号99または101の最新のC-アクティブコントロールチェンジコマンドのMSB値を使用しています。私たちは、「2型変異体」としてこのバリアントを参照してください。
If the LSB command is omitted, the LSB value 0x00 is assumed. We refer to this variant as a "type 3 variant". The type 2 and type 3 variants are defined as legal but are not recommended in [MIDI].
LSBコマンドが省略された場合、LSB値は0x00が想定されます。私たちは、「タイプ3バリアント」としてこのバリアントを参照してください。タイプ2とタイプ3の変異体は、法律上のように定義されているが[MIDI]で推奨されていません。
System Real-Time commands may appear at any point during a transaction (even between octets of individual commands in the transaction). More generally, [MIDI] does not forbid the appearance of unrelated MIDI commands during an open transaction. As a rule, these commands are considered to be "outside" the transaction and do not affect the status of the transaction in any way. Exceptions to this rule are commands whose semantics act to terminate transactions: Reset State commands and Control Change (0xB) for controller number 121 (Reset All Controllers) [RP015].
システムリアルタイムコマンドが（でもトランザクション内の個々のコマンドのオクテット間）取引中の任意の時点で表示されることがあります。より一般的には、[MIDI]は開いているトランザクションの間に無関係なMIDIコマンドの外観を禁止しません。原則として、これらのコマンドは、「外」取引とみなされ、どのような方法でトランザクションの状態には影響を与えません。この規則の例外は、そのセマンティクストランザクションを終了するように作用するコマンドである：コントローラ番号121（すべてのコントローラをリセット）RP015]の状態コマンド及びコントロールチェンジ（0xB）をリセットします。
o Initiated parameter system transaction. A canonical parameter system transaction whose (99, 98) or (101, 100) initial Control Change command pair appears in the session history is considered to be an initiated parameter system transaction. This definition also holds for type 1 variants. For type 2 variants (dropped MSB), a transaction whose initial LSB Control Change command appears in the session history is an initiated transaction. For type 3 variants (dropped LSB), a transaction is considered to be initiated if at least one transaction command follows the initial MSB (99 or 101) Control Change command in the session history. The completion of a transaction does not nullify its "initiated" status.
Oパラメータシステムトランザクションを開始しました。その標準的なパラメータシステムのトランザクション（99、98）または（101、100）最初のコントロールチェンジコマンドのペアはセッション履歴が開始パラメータシステムトランザクションと見なされるに表示されます。この定義は、タイプ1変異体を保持しています。タイプ2の変種（MSBを落とし）については、その最初のLSBコントロールチェンジコマンドは、セッション履歴に表示されるトランザクションが開始されたトランザクションです。タイプ3バリアント（LSBドロップ）の場合、トランザクションは、少なくとも1つのトランザクションコマンドがセッション歴史の中で最初のMSB（99または101）コントロールチェンジコマンドを次の場合に開始されると考えられます。トランザクションの完了は、そのステータスを「開始」を無効にしません。
o Session history reference counts. Several recovery journal chapters include a reference count field, which codes the total number of commands of a type that appear in the session history. Examples include the Reset and Tune Request command logs (Appendix
Oセッション履歴の参照カウント。いくつかの回復ジャーナル章では、セッション履歴に表示されるタイプのコマンドのコード総数を参照カウントフィールドが含まれます。例としては、リセットとチューンRequestコマンドログ（付録を含めます
B.1, "System Chapter D") and the Active Sense command (Appendix B.2, "System Chapter V"). Upon the detection of a loss event, reference count fields let a receiver deduce if any instances of the command have been lost, by comparing the journal reference count with its own reference count. Thus, a reference count field makes sense, even for command types in which knowing the NUMBER of lost commands is irrelevant (as is true with all of the example commands mentioned above).
B.1、 "システム章D"）とActiveセンスコマンド（付録B.2、 "システム章V"）。損失事象を検出すると、参照カウントフィールドには、コマンドのすべてのインスタンスは、独自の参照カウントしてジャーナル参照カウントを比較することで、失われている場合、受信機は推測してみましょう。したがって、参照カウントフィールドは、失われたコマンドの数を知ることさえのコマンドタイプのため、理にかなっている（上記の例のコマンドの全てと真であるように）無関係です。
The chapter definitions in Appendices A.2 to A.9 and B.1 to B.5 reflect the default recovery journal behavior. The ch_default, ch_never, and ch_anchor parameters modify these definitions, as described in Appendix C.2.3.
B.5にA.9とB.1に付録A.2の章の定義は、デフォルトの回復ジャーナルの挙動を反映しています。付録C.2.3で説明したようにch_default、ch_never、およびch_anchorパラメータは、これらの定義を変更します。
The chapter definitions specify if data MUST be present in the journal. Senders MAY also include non-required data in the journal. This optional data MUST comply with the normative chapter definition. For example, if a chapter definition states that a field codes data from the most recent active command in the session history, the sender MUST NOT code inactive commands or older commands in the field.
データがジャーナルに存在しなければならない場合章の定義を指定します。送信者はまた、ジャーナル内の非必要なデータを含むことができます。このオプションのデータは、規範的な章の定義を遵守しなければなりません。例えば、章の定義は、セッション履歴の最新のアクティブコマンドからのフィールドコードデータは、送信者がフィールドに非アクティブなコマンドや古いコマンドをコーディングしてはならないと述べている場合。
Finally, we note that a channel journal only encodes information about MIDI commands appearing on the MIDI channel the journal protects. All references to MIDI commands in Appendices A.2 to A.9 should be read as "MIDI commands appearing on this channel".
最後に、我々はチャンネルジャーナルは唯一のジャーナルが保護するMIDIチャンネルに登場するコマンドのMIDIの情報を符号化することに注意してください。 MIDIへのすべての参照A.9に付録A.2にコマンドが「このチャンネルに登場するMIDIコマンド」として読まれるべきです。
A.2. Chapter P: MIDI Program Change
A.2。章P：MIDIプログラムチェンジ
A channel journal MUST contain Chapter P if an active Program Change (0xC) command appears in the checkpoint history. Figure A.2.1 shows the format for Chapter P.
アクティブプログラムチェンジ（から0xC）コマンドがチェックポイント歴史に現れるならチャンネルジャーナルは章Pを含まなければなりません。図A.2.1章P.のためのフォーマットを示し
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PROGRAM |B| BANK-MSB |X| BANK-LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.2.1 -- Chapter P Format
図A.2.1 - 章Pのフォーマット
The chapter has a fixed size of 24 bits. The PROGRAM field indicates the data value of the most recent active Program Change command in the session history. By default, the B, BANK-MSB, X, and BANK-LSB fields MUST be set to 0. Below, we define exceptions to this default condition.
章では、24ビットの固定サイズを有します。 PROGRAMフィールドには、セッションの歴史の中で最も最近の活発なプログラム・チェンジ・コマンドのデータ値を示します。デフォルトでは、B、BANK-MSB、X、及びBANK-LSBフィールドは以下を0に設定しなければならない、我々はこのデフォルト状態の例外を定義します。
If an active Control Change (0xB) command for controller number 0 (Bank Select MSB) appears before the Program Change command in the session history, the B bit MUST be set to 1, and the BANK-MSB field MUST code the data value of the Control Change command.
コントローラ番号0（バンクセレクトMSB）のアクティブコントロールチェンジ（0xB）コマンドは、セッションの歴史の中でプログラムチェンジコマンドの前に表示された場合、Bビットが1に設定しなければならない、とBANK-MSBフィールドは、データ値をコード化しなければなりませんコントロールチェンジコマンド。
If B is set to 1, the BANK-LSB field MUST code the data value of the most recent Control Change command for controller number 32 (Bank Select LSB) that preceded the Program Change command coded in the PROGRAM field and followed the Control Change command coded in the BANK-MSB field. If no such Control Change command exists, the BANK-LSB field MUST be set to 0.
Bが1に設定されている場合、BANK-LSBフィールドは、プログラムフィールドに符号化されたプログラムチェンジコマンドを先行し、制御変更命令に従っコントローラ番号32（バンクセレクトLSB）の最新の制御変更命令のデータ値を符号化しなければなりませんBANK-MSBフィールドにコード化されました。そのようなコントロールチェンジコマンドが存在しない場合は、BANK-LSBフィールドが0に設定しなければなりません。
If B is set to 1 and if a Control Change command for controller number 121 (Reset All Controllers) appears in the MIDI stream between the Control Change command coded by the BANK-MSB field and the Program Change command coded by the PROGRAM field, the X bit MUST be set to 1.
Bを1にし、場合設定されている場合、コントローラ番号121（すべてのコントローラをリセット）するためのコントロールチェンジコマンドはバンクMSBフィールドとPROGRAMフィールドによって符号化されたプログラムチェンジコマンドにより符号化されたコントロールチェンジコマンドとの間のMIDIストリームに表示され、 Xビットが1に設定しなければなりません。
Note that [RP015] specifies that Reset All Controllers does not reset the values of controller numbers 0 (Bank Select MSB) and 32 (Bank Select LSB). Thus, the X bit does not affect how receivers will use the BANK-LSB and BANK-MSB values when recovering from a lost Program Change command. The X bit serves to aid recovery in MIDI applications where controller numbers 0 and 32 are used in a non-standard way.
[RP015は]（バンクセレクトLSB）それはコントローラ番号0（バンクセレクトMSB）と32の値をリセットしないリセット・オール・コントローラー指定することに注意してください。このように、Xビットが失われたプログラムチェンジコマンドから回復するとき受信機はBANK-LSBとBANK-MSBの値を使用する方法には影響しません。 Xビットは、コントローラ番号0及び32は、非標準的な方法で使用されているMIDIアプリケーションの回復を助けるのに役立ちます。
A.3. Chapter C: MIDI Control Change
A.3。章C：MIDIコントロールチェンジ
Figure A.3.1 shows the format for Chapter C.
図A.3.1章Cのフォーマットを示し
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| VALUE/ALT | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.3.1 -- Chapter C Format
図A.3.1 - 章Cフォーマット
The chapter consists of a 1-octet header followed by a variable-length list of 2-octet controller logs. The list MUST contain at least one controller log. The 7-bit LEN field codes the number of controller logs in the list, minus one. We define the semantics of the controller log fields in Appendix A.3.2.
章では、2オクテットの制御ログの可変長リストが続く1オクテットのヘッダから成ります。リストには、少なくとも1つのコントローラログを含まなければなりません。 7ビットLENフィールドコードリスト内のコントローラログの数、マイナス1。私たちは、付録A.3.2内のコントローラログフィールドの意味を定義します。
A channel journal MUST contain Chapter C if the rules defined in this appendix require that one or more controller logs appear in the list.
この付録で定義されたルールは、1件のまたは複数のコントローラのログがリストに表示されていることが必要な場合はチャンネルジャーナルは章Cを含まなければなりません。
A.3.1. Log Inclusion Rules
A.3.1。包含ルールをログに記録
A controller log encodes information about a particular Control Change command in the session history.
コントローラログは、セッション履歴内の特定のコントロールチェンジコマンドに関する情報を符号化します。
In the default use of the payload format, list logs MUST encode information about the most recent active command in the session history for a controller number. Logs encoding earlier commands MUST NOT appear in the list.
ペイロード形式のデフォルトの使用では、リストのログは、コントローラ番号のセッションの歴史の中で最も最近のアクティブコマンドに関する情報を符号化しなければなりません。以前のコマンドをコードするログは、リストに表示されてはなりません。
Also, as a rule, the list MUST contain a log for the most recent active command for a controller number that appears in the checkpoint history. Below, we define exceptions to this rule:
また、原則として、リストには、チェックポイントの履歴に表示されるコントローラ番号のための最新のアクティブなコマンドのログを含まなければなりません。以下では、この規則の例外を定義します。
o MIDI streams may transmit 14-bit controller values using paired Most Significant Byte (MSB, controller numbers 0-31, 99, 101) and Least Significant Byte (LSB, controller numbers 32-63, 98, 100) Control Change commands [MIDI].
O MIDIストリームは、一対の最上位バイト（MSB、コントローラ番号0-31、99、101）、最下位バイト（LSB、コントローラ番号32-63、98、100）コントロールチェンジコマンド[MIDIを使用して、14ビットの制御値を送信してもよいです。 ]。
If the most recent active Control Change command in the session history for a 14-bit controller pair uses the MSB number, Chapter C MAY omit the controller log for the most recent active Control Change command for the associated LSB number, as the command ordering makes this LSB value irrelevant. However, this exception MUST NOT be applied if the sender is not certain that the MIDI source uses 14-bit semantics for the controller number pair. Note that some MIDI sources ignore 14-bit controller semantics and use the LSB controller numbers as independent 7-bit controllers.
14ビットコントローラのペアのためのセッションの歴史の中で最も最近のアクティブコントロールチェンジコマンドはMSB番号を使用している場合は、コマンドが作るを注文すると、章Cは、関連するLSB番号の最新のアクティブコントロールチェンジコマンドのコントローラーログを省略してもよい（MAY）このLSB無関係値。送信者がMIDIソースはコントローラ番号ペアの14ビット・セマンティクスを使用することは確かではない場合は、この例外が適用されてはいけません。いくつかのMIDIソースは14ビットコントローラのセマンティクスを無視して、独立した7ビットコントローラとLSBコントローラ番号を使用することに注意してください。
o If active Control Change commands for controller numbers 0 (Bank Select MSB) or 32 (Bank Select LSB) appear in the checkpoint history and if the command instances are also coded in the BANK-MSB and BANK-LSB fields of the Chapter P (Appendix A.2), Chapter C MAY omit the controller logs for the commands.
アクティブコントロールチェンジはコントローラ番号0（バンクセレクトMSB）または32（バンクセレクトLSB）するためのコマンドならばOチェックポイント歴史に表示され、コマンドのインスタンスはまた、BANK-MSBと章PのBANK-LSBフィールド（でコーディングされている場合付録A.2）、章Cは、コマンドのために、コントローラのログを省略することができます。
o Several controller number pairs are defined to be mutually exclusive. Controller numbers 124 (Omni Off) and 125 (Omni On) form a mutually exclusive pair, as do controller numbers 126 (Mono) and 127 (Poly).
Oいくつかのコントローラ番号対は相互に排他的であると定義されます。コントローラ番号126（モノ）と127（ポリ）がそうであるように、コントローラ番号124（オムニオフ）と125（オムニON）は、相互に排他的な対を形成します。
If active Control Change commands for one or both members of a mutually exclusive pair appear in the checkpoint history, a log for the controller number of the most recent command for the pair in the checkpoint history MUST appear in the controller list. However, the list MAY omit the controller log for the most recent active command for the other number in the pair.
アクティブコントロールチェンジは、いずれかのコマンドまたは相互に排他的なペアの両方のメンバーがチェックポイント歴史に表示された場合は、チェックポイントの歴史の中でペアのための最新のコマンドのコントローラ番号のログは、コントローラのリストに表示されなければなりません。しかし、リストはペアの他の数のための最新のアクティブなコマンドのためのコントローラのログを省略することができます。
If active Control Change commands for one or both members of a mutually exclusive pair appear in the session history, and if a log for the controller number of the most recent command for the pair does not appear in the controller list, a log for the most recent command for the other number of the pair MUST NOT appear in the controller list.
アクティブコントロールチェンジは、いずれかのコマンドまたはほとんどのログ、相互に排他的なペアの両方のメンバーは、セッション履歴に表示され、ペアのための最新のコマンドのコントローラ番号のログは、コントローラの一覧に表示されない場合場合ペアの他の数の最近のコマンドは、コントローラのリストに表示されてはなりません。
o If an active Control Change command for controller number 121 (Reset All Controllers) appears in the session history, the controller list MAY omit logs for Control Change commands that precede the Reset All Controllers command in the session history, under certain conditions.
Oコントローラ番号121（リセット・オール・コントローラー）のセッション履歴に表示され、コントローラ一覧のアクティブコントロールチェンジコマンドは、一定の条件の下で、すべてのコントローラは、セッション履歴内のコマンドのリセットの前にコントロール・チェンジ・コマンドのログを省略する可能性がある場合。
Namely, a log MAY be omitted if the sender is certain that a command stream follows the Reset All Controllers semantics defined in [RP015] and if the log codes a controller number for which [RP015] specifies a reset value.
送信者がコマンドストリームがリセット値を指定する[RP015]のリセット[RP015]で定義されたすべてのコントローラのセマンティクスとログコードと、コントローラ番号に従うことが確実である場合、すなわち、ログを省略してもよいです。
For example, [RP015] specifies that controller number 1 (Modulation Wheel) is reset to the value 0, and thus a controller log for Modulation Wheel MAY be omitted from the controller log list. In contrast, [RP015] specifies that controller number 7 (Channel Volume) is not reset, and thus a controller log for Channel Volume MUST NOT be omitted from the controller log list.
例えば、[RP015は、コントローラ番号1（モジュレーションホイール）が値0にリセットされ、従って、モジュレーションホイールのコントローラログは、コントローラログリストから省略することができることを指定します。対照的に、[RP015は、コントローラ番号7（チャンネル・ボリューム）がリセットされないことを指定し、従って、チャンネルボリューム用のコントローラログは、コントローラログリストから省略してはいけません。
o Appendix A.3.4 defines exception rules for the MIDI Parameter System controller numbers 6, 38, and 96-101.
O付録A.3.4はMIDIパラメータシステムコントローラ番号6、38、および96-101の例外ルールを定義します。
A.3.2. Controller Log Format
A.3.2。コントローラのログフォーマット
Figure A.3.2 shows the controller log structure of Chapter C.
図A.3.2章Cのコントローラログ構造を示します
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |A| VALUE/ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.3.2 -- Chapter C Controller Log
図A.3.2 - 章Cコントローラのログ
The 7-bit NUMBER field identifies the controller number of the coded command. The 7-bit VALUE/ALT field codes recovery information for the command. The A bit sets the format of the VALUE/ALT field.
7ビット数フィールドは、符号化されたコマンドのコントローラ番号を識別する。コマンドのための7ビット値/ ALTフィールドコード回復情報。 AビットがVALUE / ALTフィールドのフォーマットを設定します。
A log encodes recovery information using one of the following tools: the value tool, the toggle tool, or the count tool.
値ツール、トグルツール、またはカウントツール：ログには、次のいずれかのツールを使用してリカバリ情報を符号化します。
A log uses the value tool if the A bit is set to 0. The value tool codes the 7-bit data value of a command in the VALUE/ALT field. The value tool works best for controllers that code a continuous quantity, such as number 1 (Modulation Wheel).
ログは、Aビットが0に設定されている場合、値のツールを使用して値のツールコードVALUE / ALTフィールドにコマンドの7ビットのデータ値。値のツールは、コードような番号1（モジュレーションホイール）などの連続量、コントローラに最適です。
The A bit is set to 1 to code the toggle or count tool. These tools work best for controllers that code discrete actions. Figure A.3.3 shows the controller log for these tools.
ビットがトグルまたはカウントツールを符号化するために1に設定されています。これらのツールは、コードの個別の行動コントローラのための最高の仕事します。図A.3.3は、これらのツールのためのコントローラのログを示しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |1|T| ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.3.3 -- Controller Log for ALT Tools
図A.3.3 - ALTツールのコントローラのログ
A log uses the toggle tool if the T bit is set to 0. A log uses the count tool if the T bit is set to 1. Both methods use the 6-bit ALT field as an unsigned integer.
TビットはTビットが両方の方法は、符号なし整数として6ビットのALTフィールドを使用し1に設定されている場合、ログカウントツールを使用して0に設定されている場合、ログは、トグルツールを使用します。
The toggle tool works best for controllers that act as on/off switches, such as 64 (Damper Pedal (Sustain)). These controllers code the "off" state with control values 0-63 and the "on" state with 64-127.
トグルツールは、64のようにオン/オフスイッチ、（ダンパー・ペダル（サスティン）を）行動コントローラのために最も適しています。これらのコントローラコード制御値0-63と「オフ」状態と64-127と「オン」状態。
For the toggle tool, the ALT field codes the total number of toggles (off->on and on->off) due to Control Change commands in the session history, up to and including a toggle caused by the command coded by the log. The toggle count includes toggles caused by Control Change commands for controller number 121 (Reset All Controllers).
トグルツール、ALTのフィールドコードのために起因するコントロールチェンジにトグルの総数は（オフ>に及びオン>オフ）ログで符号化コマンドによって引き起こされるトグルなどの、最大、セッション履歴に命令します。トグル計数は、コントロール変化によるトグルはコントローラ番号121（すべてのコントローラをリセット）するためのコマンドを含んでいます。
Toggle counting is performed modulo 64. The toggle count is reset at the start of a session and whenever a Reset State command (Appendix A.1) appears in the session history. When these reset events occur, the toggle count for a controller is set to 0 (for controllers whose default value is 0-63) or 1 (for controllers whose default value is 64-127).
トグルカウントがモジュロ64を行っているトグル数は、セッションの開始時にリセットされ、リセット状態コマンド（付録A.1）は、セッション履歴に表示されたときに。これらのリセットイベントが発生した場合、コントローラのトグル回数がまたは1（デフォルト値64-127であるコントローラの場合）（そのデフォルト値は0〜63であり、コントローラの）0に設定されています。
The Damper Pedal (Sustain) controller illustrates the benefits of the toggle tool over the value tool for switch controllers. As often used in piano applications, the "on" state of the controller lets notes resonate, while the "off" state immediately damps notes to silence. The loss of the "off" command in an "on->off->on" sequence results in ringing notes that should have been damped silent. The toggle tool lets receivers detect this lost "off" command, but the value tool does not.
ダンパーペダル（サスティン）コントローラは、スイッチコントローラの値のツール上トグルツールの利点を示します。できるだけ頻繁にピアノの用途で使用される、コントローラの状態「に」「オフ」状態はすぐに沈黙にメモを減衰させる一方でノートは、共振することができます。サイレント減衰されている必要がありリンギングノートのシーケンス結果「のオン>オフ>」で「オフ」コマンドの損失。トグルツールは、受信機は、これが「オフ」コマンドを失ったが、値のツールにはない検出することができます。
The count tool is conceptually similar to the toggle tool. For the count tool, the ALT field codes the total number of Control Change commands in the session history, up to and including the command coded by the log. Command counting is performed modulo 64. The command count is set to 0 at the start of the session and is reset to 0 whenever a Reset State command (Appendix A.1) appears in the session history.
カウントツールは、トグルツールと概念的に類似しています。カウントツールに関しては、コントロールチェンジのALTのフィールドコードの合計数は、ログによってコード化されたコマンドを含むまで、セッション履歴でコマンド。コマンド・カウントは、セッションの開始時にコマンドカウントが0に設定されているモジュロ64を行い、リセット状態コマンド（付録A.1）は、セッション履歴に表示されたときに0にリセットされます。
Because the count tool ignores the data value, it is a good match for controllers whose controller value is ignored, such as number 123 (All Notes Off). More generally, the count tool may be used to code a (modulo 64) identification number for a command.
カウントツールは、データ値を無視しているため、そのような番号123のようなコントローラ値は無視されるコントローラ、（オール・ノート・オフ）のために良い試合です。より一般的には、カウントツールは、コマンドの（モジュロ64）識別番号を符号化するために使用されてもよいです。
A.3.3. Log List Coding Rules
A.3.3。ログリストコーディングルール
In this section, we describe the organization of controller logs in the Chapter C log list.
このセクションでは、章のCログリスト内のコントローラログの編成について説明します。
A log encodes information about a particular Control Change command in the session history. In most cases, a command SHOULD be coded by a single tool (and, thus, a single log). If a number is coded with a single tool and this tool is the count tool, recovery Control Change commands generated by a receiver SHOULD use the default control value for the controller.
ログは、セッション履歴内の特定のコントロールチェンジコマンドに関する情報を符号化します。ほとんどの場合、コマンドは、単一のツール（及び、従って、単一のログ）によって符号化されるべきです。番号は単一のツールを用いて符号化し、このツールは、カウントツールですされている場合は、受信機によって生成された回復コントロールチェンジコマンドは、コントローラのデフォルト制御値を使用する必要があります。
However, a command MAY be coded by several tool types (and, thus, several logs, each using a different tool). This technique may improve recovery performance for controllers with complex semantics, such as controller number 84 (Portamento Control) or controller number 121 (Reset All Controllers) when used with a non-zero data octet (with the semantics described in [DLS2]).
しかし、コマンドが（したがって、いくつかのログ、異なるツールを使用して各）いくつかのツールの種類によって符号化されてもよいです。この技術は、コントローラ番号84（ポルタメント対照）またはコントローラ番号121（すべてのコントローラをリセット）（[DLS2]に記載の意味論を持つ）非ゼロのデータオクテットで使用した場合のような複雑なセマンティクスを持つコントローラの回復性能を向上させることができます。
If a command is encoded by multiple tools, the logs MUST be placed in the list in the following order: count tool log (if any), followed by value tool log (if any), followed by toggle tool log (if any).
トグルツールのログ（もしあれば）に続く値ツールのログ（もしあれば）、続いカウントツールのログ（もしあれば）、：コマンドは、複数のツールによってコードされている場合は、ログは次の順序でリストに置かなければなりません。
The Chapter C log list MUST obey the oldest-first ordering rule (defined in Appendix A.1). Note that this ordering preserves the information necessary for the recovery of 14-bit controller values without precluding the use of MSB and LSB controller pairs as independent 7-bit controllers.
章Cログリストは、（付録A.1で定義されている）最古-最初の発注ルールに従わなければなりません。この順序付けは、独立した7ビットコントローラのようMSBとLSBコントローラペアの使用を排除することなく、14ビット制御値の回復に必要な情報を保存することに留意されたいです。
In the default use of the payload format, all logs that appear in the list for a controller number encode information about one Control Change command -- namely, the most recent active Control Change command in the session history for the number.
ペイロード形式のデフォルトの使用では、コントローラ番号エンコード情報について1コントロールチェンジコマンドのリストに表示されたすべてのログ - すなわち、多数のセッションの歴史の中で最も最近のアクティブコントロールチェンジコマンド。
This coding scheme provides good recovery performance for the standard uses of Control Change commands defined in [MIDI]. However, not all MIDI applications restrict the use of Control Change commands to those defined in [MIDI].
この符号化方式は、[MIDI]で定義されたコントロール・チェンジ・コマンドの標準用途のための良好な回復性能を提供します。しかし、すべてのMIDIアプリケーションは、コントロールチェンジの使用は[MIDI]で定義されたものにコマンドを制限しません。
For example, consider the common MIDI encoding of rotary encoders ("infinite" rotation knobs). The mixing console MIDI convention defined in [LCP] codes the position of rotary encoders as a series of Control Change commands. Each command encodes a relative change of knob position from the last update (expressed as a clockwise or counter-clockwise knob-turning angle).
例えば、ロータリーエンコーダ（「無限の」回転ノブ）の一般的なMIDI符号化を考えます。 [LCP]コードにコントロールチェンジの一連のコマンドとしてロータリエンコーダの位置を定義ミキシングコンソールMIDI規則。各コマンドは、（時計回りまたは反時計回りノブ回転角として表される）最後の更新からノブの位置の相対変化をコードします。
As the knob position is encoded incrementally over a series of Control Change commands, the best recovery performance is obtained if the log list encodes all Control Change commands for encoder controller numbers that appear in the checkpoint history, not only the most recent command.
ノブの位置がコントロールチェンジの一連のコマンドの上にインクリメンタルに符号化されているとおり、ログリストは、コントロールチェンジがチェックポイント歴史だけでなく、最新のコマンドで表示されるエンコーダコントローラ番号のコマンドすべてをコードする場合、最高の回復性能が得られます。
To support application areas that use Control Change commands in this way, Chapter C may be configured to encode information about several Control Change commands for a controller number. We use the term "enhanced" to describe this encoding method, which we describe below.
コントロールチェンジは、このようにコマンドを使用する応用分野をサポートするために、章Cは、いくつかのコントロールチェンジは、コントローラ番号のコマンドに関する情報を符号化するように構成されてもよいです。我々は、以下の記述、この符号化方法を記述するために「強化」という用語を使用します。
In Appendix C.2.3, we show how to configure a stream to use enhanced Chapter C encoding for specific controller numbers. In Section 5 in the main text, we show how the H bits in the recovery journal header (Figure 8) and in the channel journal header (Figure 9) indicate the use of enhanced Chapter C encoding.
付録C.2.3では、我々は特定のコントローラ番号に高められた章Cコード化を使用するようにストリームを構成する方法を示しています。本文中5章では、我々は、回復ジャーナルヘッダ（図8）において、チャネルジャーナル・ヘッダ（図9）におけるHビットが向上章Cの符号化の使用を示す方法を示します。
Here, we define how to encode a Chapter C log list that uses the enhanced encoding method.
ここでは、強化された符号化方式を使用して章Cログリストをエンコードする方法を定義します。
Senders that use the enhanced encoding method for a controller number MUST obey the rules below. These rules let a receiver determine which logs in the list correspond to lost commands. Note that these rules override the exceptions listed in Appendix A.3.1.
コントローラ番号の拡張符号化方式を使用する送信者は、以下の規則に従わなければなりません。これらのルールは、受信機が失われたコマンドに対応して、リストにログインするかを決定しましょう。これらのルールは、付録A.3.1に記載されている例外をオーバーライドすることに注意してください。
o If N commands for a controller number are encoded in the list, the commands MUST be the N most recent commands for the controller number in the session history. For example, for N = 2, the sender MUST encode the most recent command and the second most recent command, not the most recent command and the third most recent command.
Nがリストにエンコードされているコントローラ番号ためのコマンド場合は、O、コマンドは、セッション履歴のコントローラ番号のN最新のコマンドでなければなりません。例えば、N = 2の場合、送信者は、最新のコマンドと第二最新のコマンドではなく、最新のコマンドと第三の最新のコマンドを符号化しなければなりません。
o If a controller number uses enhanced encoding, the encoding of the least recent command for the controller number in the log list MUST include a count tool log. In addition, if commands are encoded for the controller number whose logs have S bits set to 0, the encoding of the least recent command with S = 0 logs MUST include a count tool log.
コントローラ番号は、強化されたエンコーディングを使用している場合は、O、ログリスト内のコントローラ番号の最も古い命令のエンコーディングは、カウントツールのログを含まなければなりません。コマンドは、そのログを0に設定Sビットを有するコントローラ番号にエンコードされている場合に加えて、S = 0のログとの少なくとも最近コマンドの符号化は、カウントツールのログを含まなければなりません。
The count tool is OPTIONAL for the other commands for the controller number encoded in the list, as a receiver is able to efficiently deduce the count tool value for these commands for both single-packet and multi-packet loss events.
受信機が効率的に単一パケットとマルチパケット損失イベントの両方のために、これらのコマンドのカウントツールの値を推定することができるようにカウントツールは、リスト内の符号化されたコントローラ番号のための他のコマンドのためのオプションです。
o The use of the value and toggle tools MUST be identical for all commands for a controller number encoded in the list. For example, either a value tool log MUST appear for all commands for the controller number coded in the list or, alternatively, value tool logs for the controller number MUST NOT appear in the list. Likewise, either a toggle tool log MUST appear for all commands for the controller number coded in the list or, alternatively, toggle tool logs for the controller number MUST NOT appear in the list.
O値とトグルツールの使用は、リスト内の符号化されたコントローラ番号のためのすべてのコマンドのために同じでなければなりません。例えば、値のツールログのいずれか、または、代替的に、コントローラ番号の値ツールログがリストに表示されてはいけませんリスト内の符号化されたコントローラ番号のためのすべてのコマンドのために表示されなければなりません。同様に、いずれかのトグルツールのログは、コントローラ番号のトグルツールのログがリストに表示されてはならない、あるいは、リストでコーディングやコントローラ番号のためのすべてのコマンドのために表示される必要があります。
o If a command is encoded by multiple tools, the logs MUST be placed in the list in the following order: count tool log (if any), followed by value tool log (if any), followed by toggle tool log (if any).
トグルツールのログ（もしあれば）、続いて、（もしあれば）の値のツールログ続いて、カウントツールログ（もしあれば）：コマンドは、複数のツールによってコードされている場合は、O、ログは次の順序でリストに配置する必要があります。
These rules permit a receiver recovering from a packet loss to use the count tool log to match the commands encoded in the list with its own history of the stream, as we describe below. Note that the text below describes a non-normative algorithm; receivers are free to use any algorithm to match its history with the log list.
これらのルールは、我々は以下説明するように、ストリームの独自の歴史を持つリストでエンコードされたコマンドと一致するようにカウントツールのログを使用して、パケット損失から回復受信を許可します。下のテキストは、非規範的アルゴリズムを記述していることに注意してください。受信機は、ログリストとその歴史を一致させるために任意のアルゴリズムを自由に使用できます。
In a typical implementation of the enhanced encoding method, a receiver computes and stores count, value, and toggle tool data field values for the most recent Control Change command it has received for a controller number.
拡張符号化方法の典型的な実装では、受信機が計算し、格納し、それはコントローラ番号に対して受信した最新の制御変更命令のために、値、およびトグルツールデータフィールド値を数えます。
After a loss event, a receiver parses the Chapter C list and processes list logs for a controller number that uses enhanced encoding as follows.
損失イベントの後、受信機は、章Cリストを解析し、次のように強化されたエンコーディングを使用し、コントローラ番号のリストログを処理します。
The receiver compares the count tool ALT field for the least recent command for the controller number in the list against its stored count data for the controller number to determine if recovery is necessary for the command coded in the list. The value and toggle tool logs (if any) that directly follow the count tool log are associated with this least recent command.
受信機は、回復がリスト内に符号化されたコマンドのために必要であるかどうかを決定するコントローラ番号のために記憶されたカウントデータに対するリスト内のコントローラ番号の最も古いコマンドのカウントツールALTフィールドを比較します。直接カウントツールのログを追跡値とトグルツールのログは、（もしあれば）、この少なくとも最近のコマンドに関連付けられています。
To check more recent commands for the controller, the receiver detects additional value and/or toggle tool logs for the controller number in the list and infers count tool data for the command coded by these logs. This inferred data is used to determine if recovery is necessary for the command coded by the value and/or toggle tool logs.
コントローラのためのより新しいコマンドを確認するには、受信機は、リスト内のコントローラ番号のための付加価値および/またはトグルツールのログを検出し、これらのログで符号化されたコマンドのカウントツールのデータを推測します。この推論されたデータは回復値及び/又はトグルツールログによってコード化されたコマンドのために必要であるかどうかを決定するために使用されます。
In this way, a receiver is able to execute only lost commands, without executing a command twice. While recovering from a single packet loss, a receiver may skip through S = 1 logs in the list, as the first S = 0 log for an enhanced controller number is always a count tool log.
このように、受信機は、二回のコマンドを実行せず、唯一の失われたコマンドを実行することができます。単一のパケット損失から回復しつつ拡張コントローラ番号の最初のS = 0ログは常にカウントツールのログであるとして、受信機は、リスト内のS = 1つのログをスキップしてもよいです。
Note that the requirements in Appendix C.2.2.2 for protective sender and receiver actions during session startup for multicast operation are of particular importance for enhanced encoding, as receivers need to initialize their count tool data structures with recovery journal data in order to match commands correctly after a loss event.
受信機はコマンドを合わせるために回復ジャーナルデータとそのカウントツールのデータ構造を初期化する必要があるとして、マルチキャスト操作のためのセッション起動時に保護送信者と受信者のアクションの付録C.2.2.2における要件は、強化されたエンコーディングのために特に重要であることに注意してください正しく損失イベントの後。
Finally, we note in passing that in some applications of rotary encoders, a good user experience may be possible without the use of enhanced encoding. These applications are distinguished by visual feedback of encoding position that is driven by the post-recovery rotary encoding stream and relatively low packet loss. In these domains, recovery performance may be acceptable for rotary encoders if the log list encodes only the most recent command and if both count and value logs appear for the command.
最後に、私たちは、ロータリーエンコーダの一部のアプリケーションでは、優れたユーザーエクスペリエンスを向上させるのエンコードを使用せずに可能であることは渡すに注意してください。これらのアプリケーションは、回復後ロータリー符号化ストリームと、比較的低いパケット損失によって駆動された符号化位置の視覚的なフィードバックによって区別されます。両方の数と値ログがコマンドのために表示された場合にログリストのみが最新のコマンドをエンコードした場合、これらのドメインでは、回復性能は、ロータリエンコーダのために許容可能です。
A.3.4. The Parameter System
A.3.4。パラメータシステム
Readers may wish to review the Appendix A.1 definitions of "parameter system", "parameter system transaction", and "initiated parameter system transaction" before reading this section.
読者は、このセクションを読む前に、「パラメータシステム」、「パラメータシステムトランザクション」、および「開始パラメータシステムのトランザクション」の付録A.1定義を見直しすることを望むかもしれません。
Parameter system transactions update a MIDI Registered Parameter Numbers (RPN) or Non-Registered Parameter Numbers (NRPN) value. A parameter system transaction is a sequence of Control Change commands that may use the following controllers numbers:
パラメータシステムトランザクションはMIDI登録パラメータ番号（RPN）または非登録パラメータ番号（NRPN）の値を更新します。パラメータシステムトランザクションは、以下のコントローラ番号を使用してコントロールチェンジコマンドのシーケンスです：
o Data Entry MSB (6) o Data Entry LSB (38) o Data Increment (96) o Data Decrement (97) o Non-Registered Parameter Number (NRPN) LSB (98) o Non-Registered Parameter Number (NRPN) MSB (99) o Registered Parameter Numbers (RPN) LSB (100) o Registered Parameter Numbers (RPN) MSB (101)
（6）データデクリメント（97）O非登録パラメータ番号（NRPN）LSB（98）O非登録パラメータ番号（NRPN）MSB（Oデータインクリメント（96）OデータエントリーLSB（38）O Oデータ・エントリーMSB 99）O登録パラメータ番号（RPN）LSB（100）O登録パラメータ番号（RPN）MSB（101）
Control Change commands that are a part of a parameter system transaction MUST NOT be coded in Chapter C controller logs. Instead, these commands are coded in Chapter M, the MIDI Parameter chapter defined in Appendix A.4.
パラメータシステムトランザクションの一部であるコントロールチェンジコマンドは、章Cコントローラログにコード化されてはなりません。代わりに、これらのコマンドは章M、付録A.4で定義されたMIDIパラメータの章でコード化されています。
However, Control Change commands that use the listed controllers as general-purpose controllers (i.e., outside of a parameter system transaction) MUST NOT be coded in Chapter M.
しかし、（すなわち、パラメータシステムトランザクションの外側）汎用コントローラとして記載されているコントローラを使用するコントロールチェンジコマンド章M.で符号化してはいけません
Instead, the controllers are coded in Chapter C controller logs. The controller logs follow the coding rules stated in Appendix A.3.2 and A.3.3. The rules for coding paired LSB and MSB controllers, as defined in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and (101, 100) when coded in Chapter C.
代わりに、コントローラは章Cコントローラのログでコード化されています。コントローラログは、付録A.3.2及びA.3.3に記載されたコーディング規則に従ってください。章C.で符号化されたときに、付録A.3.1で定義されるように、一対のLSBとMSBコントローラを符号化するための規則は、対（6、38）、（99、98）、及び（101、100）に適用します
If active Control Change commands for controller numbers 6, 38, or 96-101 appear in the checkpoint history, and these commands are used as general-purpose controllers, the most recent general-purpose command instance for these controller numbers MUST appear as entries in the Chapter C controller list.
アクティブコントロールチェンジはコントローラ番号6のためのコマンド場合は、38、または96から101には、チェックポイントの履歴に表示され、これらのコマンドは、汎用コントローラとして使用され、これらのコントローラ番号の最新の汎用コマンドインスタンスは、内のエントリとして表示されなければなりません。章Cコントローラのリスト。
MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as parameter-system controllers and general-purpose controllers in the same stream. An RTP MIDI sender MUST deduce the role of each Control Change command for these controller numbers by noting the placement of the command in the stream and MUST use this information to code the command in Chapter C or Chapter M, as appropriate.
MIDI構文は同じストリームにパラメータシステムコントローラと、汎用コントローラとしてコントローラ6、38、96、及び97を使用するためのソースを可能にします。 RTP MIDIの送信者は、ストリーム内のコマンドの配置に注目することによって、これらのコントローラ番号の各コントロールチェンジコマンドの役割を推定しなければならないし、必要に応じて、章Cまたは章Mでコマンドをコーディングするために、この情報を使用しなければなりません。
Specifically, active Control Change commands for controllers 6, 38, 96, and 97 act in a general-purpose way when
具体的には、アクティブコントロールチェンジには、コントローラ6、38、96のためのコマンド、及び汎用方法ときに97アクト
o no active Control Change commands that set an RPN or NRPN parameter number appear in the session history, or
O RPNやNRPNパラメータ番号を設定し、アクティブなコントロールチェンジコマンドは、セッション履歴に表示されていない、または
o the most recent active Control Change commands in the session history that set an RPN or NRPN parameter number code the null parameter (MSB value 0x7F, LSB value 0x7F), or
O最新のアクティブなコントロールチェンジは、nullパラメータ（MSB値0x7Fを、LSB値から0x7F）、またはRPNやNRPNパラメータ番号コードを設定するセッション履歴にコマンド
o a Control Change command for controller number 121 (Reset All Controllers) appears more recently in the session history than all active Control Change commands that set an RPN or NRPN parameter number (see [RP015] for details).
Oコントローラ番号121のためのコントロールチェンジコマンドはRPNやNRPNパラメータ番号を設定し、すべてのアクティブなコントロールチェンジコマンドよりもセッション履歴で、最近で表示されます（すべてのコントローラをリセット）（詳細については、[RP015]を参照）。
Finally, we note that a MIDI source that follows the recommendations of [MIDI] exclusively uses numbers 98-101 as parameter system controllers. Alternatively, a MIDI source may exclusively use 98-101 as general-purpose controllers and lose the ability to perform parameter system transactions in a stream.
最後に、我々は[MIDI]の勧告を次のMIDIソースが独占的パラメータシステムコントローラとして番号98から101を使用することに注意してください。また、MIDIの源は、もっぱら汎用コントローラとして98-101を使用して、ストリーム内のパラメータシステムのトランザクションを実行する能力を失う可能性があります。
In the language of [MIDI], the general-purpose use of controllers 98-101 constitutes a non-standard controller assignment. As most real-world MIDI sources use the standard controller assignment for controller numbers 98-101, an RTP MIDI sender SHOULD assume these controllers act as parameter system controllers, unless it knows that a MIDI source uses controller numbers 98-101 in a general-purpose way.
[MIDI]の言語では、コントローラ98から101の汎用用途には、非標準のコントローラの割り当てを構成しています。最も現実世界のMIDIソースはコントローラ番号98-101のための標準コントローラの割り当てを使用するとして、それはMIDIソースが一般 - で、コントローラ番号98から101を使用していることを知っている場合を除き、RTP MIDIの送信者は、これらのコントローラは、パラメータのシステムコントローラとして動作すると仮定すべきです目的の方法。
A.4. Chapter M: MIDI Parameter System
A.4。章M：MIDIパラメータシステム
Readers may wish to review the Appendix A.1 definitions for "C-active commands", "parameter system", "parameter system transaction", and "initiated parameter system transaction" before reading this appendix.
読者は、この付録を読む前に、「C-アクティブコマンド」、「パラメータシステム」、「パラメータシステムトランザクション」、および「開始パラメータシステムトランザクション」については、付録A.1定義を確認することが望まれます。
Chapter M protects parameter system transactions for Registered Parameter Numbers (RPN) and Non-Registered Parameter Numbers (NRPN) values. Figure A.4.1 shows the format for Chapter M.
章Mは、登録パラメータ番号（RPN）及び非登録パラメータ番号（NRPN）の値のパラメータシステムのトランザクションを保護します。図A.4.1章M.ためのフォーマットを示します
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|E|U|W|Z| LENGTH |Q| PENDING | Log list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.1 -- Top-Level Chapter M Format
図A.4.1 - トップレベル章M・フォーマット
Chapter M begins with a 2-octet header. If the P header bit is set to 1, a 1-octet field follows the header, coding the 7-bit PENDING value and its associated Q bit.
章Mは2オクテットのヘッダから始まります。 Pヘッダービットが1に設定されている場合、1オクテットフィールドは7ビットのPENDING値及びそれに関連するQビットをコーディング、ヘッダの後に続きます。
The 10-bit LENGTH field codes the size of Chapter M and conforms to semantics described in Appendix A.1.
10ビット長のフィールドコード章Mの大きさおよび付録A.1に記載の意味論に従います。
Chapter M ends with a list of zero or more variable-length parameter logs. Appendix A.4.2 defines the bitfield format of a parameter log. Appendix A.4.1 defines the inclusion semantics of the log list.
章Mはゼロ以上の可変長パラメータログのリストで終わります。付録A.4.2は、パラメータ、ログのビットフィールドのフォーマットを定義します。付録A.4.1は、ログリストの包含セマンティクスを定義します。
A channel journal MUST contain Chapter M if the rules defined in Appendix A.4.1 require that one or more parameter logs appear in the list.
付録A.4.1で定義されたルールは、1つまたは複数のパラメータのログがリストに表示されていることが必要な場合はチャンネルジャーナルは章Mを含まなければなりません。
A channel journal also MUST contain Chapter M if the most recent C-active Control Change command involved in a parameter system transaction in the checkpoint history is o an RPN MSB (101) or NRPN MSB (99) controller, or
チェックポイント歴史にパラメータシステムトランザクションに関与する最も最近のC-アクティブコントロールチェンジコマンドはRPN MSB（101）またはNRPN MSB（99）コントローラOであり、または場合はチャンネルジャーナルは章もMを含まなければなりません
o an RPN LSB (100) or NRPN LSB (98) controller that completes the coding of the null parameter (MSB value 0x7F, LSB value 0x7F).
O nullパラメータ（MSB値0x7Fを、LSB値から0x7F）の符号化を完了するRPN LSB（100）またはNRPN LSB（98）コントローラ。
This rule provides loss protection for partially transmitted parameter numbers and for the null parameter numbers.
この規則は、部分的に送信されたパラメータ番号のヌルパラメータ番号の損失の保護を提供します。
If the most recent C-active Control Change command involved in a parameter system transaction in the session history is for the RPN MSB or NRPN MSB controller, the P header bit MUST be set to 1, and the PENDING field (and its associated Q bit) MUST follow the Chapter M header. Otherwise, the P header bit MUST be set to 0, and the PENDING field and Q bit MUST NOT appear in Chapter M.
セッション履歴内のパラメータシステムのトランザクションに関与する最新のC-アクティブ制御変更命令がRPN MSBまたはNRPN MSB制御するためのものである場合、Pヘッダービットを1にセット、および保留中のフィールド（およびその関連Qビットなければなりません）チャプターMヘッダに従わなければなりません。そうでなければ、Pヘッダービットが0に設定しなければなりません、および保留中のフィールドとQビット章Mに現れてはいけません
If PENDING codes an NRPN MSB controller, the Q bit MUST be set to 1. If PENDING codes an RPN MSB controller, the Q bit MUST be set to 0.
NRPN MSB制御コードをPENDING場合コードをRPN MSBコントローラPENDING、Qビットを0に設定する必要がある場合は、Qビットが1に設定されなければなりません。
The E header bit codes the current transaction state of the MIDI stream. If E = 1, an initiated transaction is in progress. Below, we define the rules for setting the E header bit:
EヘッダービットコードMIDIストリームの現在のトランザクションの状態。 E = 1の場合、開始されたトランザクションが進行中です。以下に、我々はEヘッダービットを設定するためのルールを定義します。
o If no C-active parameter system transaction Control Change commands appear in the session history, the E bit MUST be set to 0.
何のC-アクティブパラメータシステムのトランザクション制御変更コマンドは、セッション履歴に表示されない場合は、O、Eビットが0に設定しなければなりません。
o If the P header bit is set to 1, the E bit MUST be set to 0.
Pヘッダービットが1に設定されている場合は、O、Eビットが0に設定しなければなりません。
o If the most recent C-active parameter system transaction Control Change command in the session history is for the NRPN LSB or RPN LSB controller number and if this command acts to complete the coding of the null parameter (MSB value 0x7F, LSB value 0x7F), the E bit MUST be set to 0.
Oセッションの歴史の中で最も最近のC-アクティブパラメータシステムのトランザクションコントロールチェンジコマンドはNRPN LSBまたはRPN LSBコントローラ番号のためとされている場合、このコマンドの行為はnullパラメータのコーディングを完了した場合（MSB値0x7Fを、LSB値0x7Fの） 、Eビットが0に設定しなければなりません。
o Otherwise, an initiated transaction is in progress, and the E bit MUST be set to 1.
Oそれ以外の場合は、開始したトランザクションが進行中であり、Eビットが1に設定しなければなりません。
The U, W, and Z header bits code properties that are shared by all parameter logs in the list. If these properties are set, parameter logs may be coded with improved efficiency (we explain how in A.4.2).
リスト内のすべてのパラメータのログによって共有されるU、W、及びZヘッダビットコードのプロパティ。これらのプロパティが設定されている場合、パラメータログは（我々はA.4.2に方法を説明）改良された効率で符号化されてもよいです。
By default, the U, W, and Z bits MUST be set to 0. If all parameter logs in the list code RPN parameters, the U bit MAY be set to 1. If all parameter logs in the list code NRPN parameters, the W bit MAY be set to 1. If the parameter numbers of all RPN and NRPN logs in the list lie in the range 0-127 (and thus have an MSB value of 0), the Z bit MAY be set to 1.
リストコードRPNパラメータの全てのパラメータログは、Uビットが1に設定される可能性がある場合、デフォルトでは、U、W、およびZビットが0に設定する必要がある場合、リストコードNRPNパラメータの全てのパラメータログ、W範囲0〜127でリスト位置にあるすべてのRPNとNRPNログのパラメータ番号が（したがって0のMSB値を有する）場合、ビットは1に設定されてもよく、Zビットが1に設定されるかもしれません。
Note that C-active semantics appear in the preceding paragraphs because [RP015] specifies that pending Parameter System transactions are closed by a Control Change command for controller number 121 (Reset All Controllers).
【RP015]が保留中のパラメータシステムトランザクションは、コントローラ番号121（すべてのコントローラをリセット）するための制御変更命令によって閉鎖されることを指定するので、C-活性セマンティクスは前の段落で表示されることに注意してください。
A.4.1. Log Inclusion Rules
A.4.1。包含ルールをログに記録
Parameter logs code recovery information for a specific RPN or NRPN parameter.
パラメータは、特定のRPNやNRPNパラメータのコード回復情報をログに記録します。
A parameter log MUST appear in the list if an active Control Change command that forms a part of an initiated transaction for the parameter appears in the checkpoint history.
パラメータに開始されたトランザクションの一部を構成するアクティブコントロールチェンジコマンドがチェックポイント歴史に現れる場合、パラメータのログがリストに表示されなければなりません。
An exception to this rule applies if the checkpoint history only contains transaction Control Change commands for controller numbers 98-101 that act to terminate the transaction. In this case, a log for the parameter MAY be omitted from the list.
チェックポイント歴史が唯一のトランザクションコントロールチェンジは、トランザクションを終了するように作用するコントローラ番号98-101のためのコマンドが含まれている場合は、この規則の例外が適用されます。この場合、パラメータのログはリストから省略されるかもしれません。
A log MAY appear in the list if an active Control Change command that forms a part of an initiated transaction for the parameter appears in the session history. Otherwise, a log for the parameter MUST NOT appear in the list.
パラメータに開始されたトランザクションの一部を構成するアクティブコントロールチェンジコマンドは、セッション履歴に表示された場合、ログがリストに表示されることがあります。それ以外の場合は、パラメータのログがリストに現れてはいけません。
Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the log list.
同じRPNやNRPNパラメータの複数のログは、ログリストに現れてはいけません。
The parameter log list MUST obey the oldest-first ordering rule (defined in Appendix A.1), with the phrase "parameter transaction" replacing the word "command" in the rule definition.
パラメータログリストは、フレーズ「パラメータのトランザクションは、」ルール定義で単語「コマンド」を置き換えると、（付録A.1で定義されている）最古-最初の発注ルールに従わなければなりません。
Parameter logs associated with the RPN or NRPN null parameter (LSB = 0x7F, MSB = 0x7F) MUST NOT appear in the log list. Chapter M uses the E header bit (Figure A.4.1) and the log list ordering rules to code null parameter semantics.
RPNやNRPN nullパラメータに関連するパラメータのログは、（LSB = 0x7Fを、MSB = 0x7Fのは）ログリストに現れてはいけません。章Mはnullパラメータの意味を符号化するためにEヘッダビット（図A.4.1）とログリストの順序付け規則を使用します。
Note that "active" semantics (rather than "C-active" semantics) appear in the preceding paragraphs because [RP015] specifies that pending Parameter System transactions are not reset by a Control Change command for controller number 121 (Reset All Controllers). However, the rule that follows uses C-active semantics because it concerns the protection of the transaction system itself, and [RP015] specifies that Reset All Controllers acts to close a transaction in progress.
【RP015]が保留中のパラメータシステムトランザクションはコントローラ番号121（すべてのコントローラをリセット）するための制御変更命令によってリセットされないことを指定しているため（むしろ「C-アクティブ」セマンティクスより）「アクティブ」セマンティクスは、前の段落で表示されることに注意してください。それは取引システム自体の保護に関係し、[RP015]はそれがすべてのコントローラーをリセット指定進行中のトランザクションを閉じるように作用するので、しかし、次のルールは、C-アクティブなセマンティクスを使用しています。
In most cases, parameter logs for RPN and NRPN parameters that are assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted from the list. An exception applies if o the log codes the most recent initiated transaction in the session history, and
ほとんどの場合、ch_neverパラメータに割り当てられているRPNとNRPNパラメータ（付録C.2.3）のパラメータログはリストから省略されるかもしれません。例外は、セッションの歴史の中で最も最近開始されたトランザクションログoコードならば適用され、
o a C-active command that forms a part of the transaction appears in the checkpoint history, and
Oトランザクションの一部を構成するC-アクティブコマンドがチェックポイント歴史に表示され、
o the E header bit for the top-level Chapter M header (Figure A.4.1) is set to 1.
OトップレベルチャプターMヘッダ（図A.4.1）はEヘッダービットが1に設定されています。
In this case, a log for the parameter MUST appear in the list. This log informs receivers recovering from a loss that a transaction is in progress so that the receiver is able to correctly interpret RPN or NRPN Control Change commands that follow the loss event.
この場合、パラメータのログがリストに表示されなければなりません。このログは、受信機が正しく損失イベントに続くRPNやNRPNコントロールチェンジコマンドを解釈することができるようにトランザクションが進行中であることを損失から回復受信機に通知します。
A.4.2. Log Coding Rules
A.4.2。コーディングルールをログに記録
Figure A.4.2 shows the parameter log structure of Chapter M.
図A.4.2章M.のパラメータログ構造を示します
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.2 -- Parameter Log Format
図A.4.2 - パラメータログ形式
The log begins with a header, whose default size (as shown in Figure A.4.2) is 3 octets. If the Q header bit is set to 0, the log encodes an RPN parameter. If Q = 1, the log encodes an NRPN parameter. The 7-bit PNUM-MSB and PNUM-LSB fields code the parameter number and reflect the Control Change command data values for controllers 99 and 98 (for NRPN parameters) or 101 and 100 (for RPN parameters).
ログは、そのデフォルトサイズ（図A.4.2に示すように）3つのオクテットであるヘッダで始まります。 Qヘッダービットが0に設定されている場合、ログはRPNパラメータを符号化します。 Q = 1の場合、ログはNRPNパラメータを符号化します。 7ビットPNUM-MSBとPNUM-LSBフィールドコードパラメータ数と、コントローラ99と（RPNパラメータの）（NRPNパラメータの）98または101および100のためのコントロールチェンジコマンドデータ値を反映します。
The J, K, L, M, and N header bits form a Table of Contents (TOC) for the log and signal the presence of fixed-sized fields that follow the header. A header bit that is set to 1 codes the presence of a field in the log. The ordering of fields in the log follows the ordering of the header bits in the TOC. Appendices A.4.2.1 and A.4.2.2 define the fields associated with each TOC header bit.
J、K、L、M、およびNヘッダビットは、ログの目次（TOC）を形成し、ヘッダに従っ固定サイズフィールドの存在を知らせます。 1つの符号ログ内のフィールドの存在のために設定されているヘッダ・ビット。ログ内のフィールドの順序は、TOC内のヘッダのビットの順序に従います。付録A.4.2.1及びA.4.2.2各TOCヘッダビットに関連付けられたフィールドを定義しています。
The T and V header bits code information about the parameter log but are not part of the TOC. A set T or V bit does not signal the presence of any parameter log field.
パラメータログ約TおよびVのヘッダビットコード情報が、TOCの一部ではありません。集合TまたはVビットは、任意のパラメータのログフィールドの存在を通知しません。
If the rules in Appendix A.4.1 state that a log for a given parameter MUST appear in Chapter M, the log MUST code sufficient information to protect the parameter from the loss of active parameter transaction Control Change commands in the checkpoint history.
与えられたパラメータのログは章Mに現れなければならない付録A.4.1状態でのルールは、ログがアクティブなパラメータトランザクションコントロールチェンジの損失からパラメータを保護するのに十分な情報をコード化しなければならない場合は、チェックポイント歴史にコマンド。
This rule does not apply if the parameter coded by the log is assigned to the ch_never parameter (Appendix C.2.3). In this case, senders MAY choose to set the J, K, L, M, and N TOC bits to 0, coding a parameter log with no fields.
ログによってコード化されたパラメータがch_neverパラメータ（付録C.2.3）に割り当てられている場合、このルールは適用されません。この場合、送信者は、フィールドのないパラメータログコード、0にJ、K、L、M、およびN TOCビットを設定することを選ぶかもしれ。
Note that logs to protect parameters that are assigned to ch_never are REQUIRED under certain conditions (see Appendix A.4.1). The purpose of the log is to inform receivers recovering from a loss that a transaction is in progress so that the receiver is able to correctly interpret RPN or NRPN Control Change commands that follow the loss event.
（付録A.4.1を参照）ch_neverに割り当てられたパラメータを保護するために、ログが一定の条件の下で要求されていることに注意してください。ログの目的は、受信機が正しく損失イベントに続くRPNやNRPNコントロールチェンジコマンドを解釈することができるようにトランザクションが進行中であることを損失から回復受信機に通知することです。
Parameter logs provide two tools for parameter protection: the value tool and the count tool. Depending on the semantics of the parameter, senders may use either tool, both tools, or neither tool to protect a given parameter.
値ツールとカウントツール：パラメータのログは、パラメータ保護のための2つのツールを提供しています。パラメータの意味論によっては、送信者がツール、両方のツール、または指定されたパラメータを保護するために、どちらのツールのいずれかを使用することができます。
The value tool codes information a receiver may use to determine the current value of an RPN or NRPN parameter. If a parameter log uses the value tool, the V header bit MUST be set to 1, and the semantics defined in Appendix A.4.2.1 for setting the J, K, L, and M TOC bits MUST be followed. If a parameter log does not use the value tool, the V bit MUST be set to 0, and the J, K, L, and M TOC bits MUST also be set to 0.
値工具コード情報は、受信機は、RPNまたはNRPNパラメータの現在の値を決定するために使用することができます。パラメータログ値のツールを使用する場合、Vヘッダビットが1に設定しなければなりません、そしてJ、K、L、及びM TOCビットを設定については、付録A.4.2.1で定義された意味論に従わなければなりません。パラメータログ値のツールを使用していない場合は、Vビットが0に設定しなければなりません、そしてJ、K、L、及びM TOCビットも0に設定しなければなりません。
The count tool codes the number of transactions for an RPN or NRPN parameter. If a parameter log uses the count tool, the T header bit MUST be set to 1, and the semantics defined in Appendix A.4.2.2 for setting the N TOC bit MUST be followed. If a parameter log does not use the count tool, the T bit and the N TOC bit MUST be set to 0.
カウントツールコードRPNやNRPNパラメータのためのトランザクションの数。パラメータログカウントツールを使用している場合、Tヘッダービットを1に設定しなければなりません、そしてN TOCビットを設定については、付録A.4.2.2で定義された意味論に従わなければなりません。パラメータのログがカウントツールを使用していない場合は、TビットとN TOCビットが0に設定しなければなりません。
Note that V and T are set if the sender uses value (V) or count (T) tool for the log on an ongoing basis. Thus, V may be set even if J = K = L = M = 0, and T may be set even if N = 0.
そのVに注意し、送信者が継続的にログの値（V）またはカウント（T）ツールを使用している場合Tが設定されています。 J = K = Lが= M = 0、Tは場合でもN = 0を設定することができる場合したがって、Vも設定することができます。
In many cases, all parameters coded in the log list are of one type (RPN parameters or NRPN parameters), and all parameter numbers lie in the range 0-127. As described in Appendix A.4, senders MAY signal this condition by setting the top-level Chapter M header bit Z to 1 (to code the restricted range) and by setting the U or W bit to 1 (to code the parameter type).
多くの場合、ログリストで符号化されたすべてのパラメータは、一種類（RPNパラメータまたはNRPNパラメータ）であり、すべてのパラメータ番号は、範囲0~127にあります。付録A.4に記載されているように、送信者は、（制限された範囲を符号化するために、1）トップレベルチャプターMヘッダビットZを設定することにより、1にU又はWビットを設定することによって、この状態をシグナリングすることができる（パラメータの型をコーディングします） 。
If the top-level Chapter M header codes Z = 1 and either U = 1 or W = 1, all logs in the parameter log list MUST use a modified header format. This modification deletes bits 8-15 of the bitfield shown in Figure A.4.2 to yield a 2-octet header. The values of the deleted PNUM-MSB and Q fields may be inferred from the U, W, and Z bit values.
トップレベルチャプターMヘッダコードZ = 1、U = 1のいずれか、またはW = 1の場合、パラメータ・ログ・リスト内のすべてのログが変更されたヘッダー形式を使用しなければなりません。この修飾は、2オクテットのヘッダを生成するために、図A.4.2に示すビットビットフィールドの8-15を削除します。削除PNUM-MSBおよびQフィールドの値は、U、W、およびZビット値から推測することができます。
A.4.2.1. The Value Tool
A.4.2.1。バリューツール
The value tool uses several fields to track the value of an RPN or NRPN parameter.
値ツールは、RPNやNRPNパラメータの値を追跡するために、いくつかのフィールドを使用しています。
The J TOC bit codes the presence of the octet shown in Figure A.4.3 in the field list.
J TOCビットコードフィールドリストの図A.4.3に示すオクテットが存在します。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-MSB |
+-+-+-+-+-+-+-+-+
Figure A.4.3 -- ENTRY-MSB Field
図A.4.3 - ENTRY-MSBフィールド
The 7-bit ENTRY-MSB field codes the data value of the most recent active Control Change command for controller number 6 (Data Entry MSB) in the session history that appears in a transaction for the log parameter.
7ビットのENTRY-MSBフィールドコードログパラメータのトランザクションに表示されたセッションの歴史の中でコントローラ番号6（データ・エントリーMSB）の最新のアクティブコントロールチェンジコマンドのデータ値。
The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes the most recent Control Change command for controller 121 (Reset All Controllers) in the session history. Otherwise, the X bit MUST be set to 0.
ENTRY-MSBで符号化されたコマンドがセッション履歴内のコントローラ121の最新の制御変更命令を（すべてのコントローラをリセットする）前にある場合Xビットが1に設定しなければなりません。それ以外の場合は、Xビットは0に設定しなければなりません。
A parameter log that uses the value tool MUST include the ENTRY-MSB field if an active Control Change command for controller number 6 appears in the checkpoint history.
コントローラ番号6のアクティブコントロールチェンジコマンドがチェックポイント歴史に表示された場合ENTRY-MSBフィールドを含まなければならない値のツールを使用して、パラメータログ。
Note that [RP015] specifies that Control Change commands for controller 121 (Reset All Controllers) do not reset RPN and NRPN values, and thus the X bit would not play a recovery role for MIDI systems that comply with [RP015].
[RP015]はコントロールチェンジは、コントローラ121に対するコマンドように指定していることに注意してください（リセット・オール・コントローラー）RPNとNRPN値をリセットしていないため、Xビットは[RP015]に準拠MIDIシステムの回復の役割を果たしていないでしょう。
However, certain renderers (such as DLS 2 [DLS2]) specify that certain RPN values are reset for some uses of Reset All Controllers. The X bit (and other bitfield features of this nature in this appendix) plays a role in recovery for renderers of this type.
しかしながら、（例えばDLS 2 [DLS2]のような）特定のレンダラは、特定RPN値は、すべてのコントローラのリセットのいくつかの用途のためにリセットされるように指定します。 Xビット（この付録では、この性質の他のビットフィールドの機能）は、このタイプのレンダラーの回復における役割を果たしています。
The K TOC bit codes the presence of the octet shown in Figure A.4.4 in the field list.
K TOCビットコードフィールドリストの図A.4.4に示すオクテットが存在します。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-LSB |
+-+-+-+-+-+-+-+-+
Figure A.4.4 -- ENTRY-LSB Field
図A.4.4 - ENTRY-LSBフィールド
The 7-bit ENTRY-LSB field codes the data value of the most recent active Control Change command for controller number 38 (Data Entry LSB) in the session history that appears in a transaction for the log parameter.
7ビットのENTRY-LSBフィールドコードログパラメータのトランザクションに表示されたセッションの歴史の中でコントローラ番号38（データ・エントリーLSB）の最新のアクティブコントロールチェンジコマンドのデータ値。
The X bit MUST be set to 1 if the command coded by ENTRY-LSB precedes the most recent Control Change command for controller 121 (Reset All Controllers) in the session history. Otherwise, the X bit MUST be set to 0.
コマンドは、ENTRY-LSBにより符号化された場合のXビットが1に設定しなければなりませんセッション履歴に（すべてのコントローラをリセット）制御部121の最新の制御変更命令に先行します。それ以外の場合は、Xビットは0に設定しなければなりません。
As a rule, a parameter log that uses the value tool MUST include the ENTRY-LSB field if an active Control Change command for controller number 38 appears in the checkpoint history. However, the ENTRY-LSB field MUST NOT appear in a parameter log if the Control Change command associated with the ENTRY-LSB precedes a Control Change command for controller number 6 (Data Entry MSB) that appears in a transaction for the log parameter in the session history.
チェックポイント歴史のコントローラ番号38が表示されますのためのアクティブコントロールチェンジコマンド場合は原則として、値のツールを使用して、パラメータ・ログには、ENTRY-LSBフィールドを含まなければなりません。 ENTRY-LSBに関連付けられているコントロールチェンジのコマンドは、ログパラメータのトランザクションに表示されるコントローラ番号6（データ・エントリーMSB）のためのコントロール・チェンジ・コマンドの前にいる場合ただし、ENTRY-LSBフィールドは、パラメータログに表示されてはなりませんセッション履歴。
The L TOC bit codes the presence of the octets shown in Figure A.4.5 in the field list.
L TOCビットコードフィールドリストに図A.4.5に示すオクテットの存在。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|X| A-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.5 -- A-BUTTON Field
図A.4.5 - Aボタンフィールド
The 14-bit A-BUTTON field codes a count of the number of active Control Change commands for controller numbers 96 and 97 (Data Increment and Data Decrement) in the session history that appear in a transaction for the log parameter.
ログパラメータのトランザクションに表示されるセッション履歴内のアクティブコントロールチェンジの数のカウントは、コントローラ番号96と97のコマンド14ビットAボタンフィールドコード（データインクリメント及びデクリメントデータ）。
The M TOC bit codes the presence of the octets shown in Figure A.4.6 in the field list.
M TOCビットコードフィールドリストの図A.4.6に示すオクテットの存在。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R| C-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.6 -- C-BUTTON Field
図A.4.6 - Cボタンフィールド
The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except that Data Increment and Data Decrement Control Change commands that precede the most recent Control Change command for controller 121 (Reset All Controllers) in the session history are not counted.
14ビットのC-BUTTONフィールドは、セッション履歴に（リセット・オール・コントローラー）、コントローラ121の最新のコントロールチェンジコマンドの前にあるデータの増分とデータデクリメントコントロールチェンジコマンドはカウントされませんを除いて、-BUTTONと同じ意味を持っています。
For both A-BUTTON and C-BUTTON, Data Increment and Data Decrement Control Change commands are not counted if they precede Control Changes commands for controller numbers 6 (Data Entry MSB) or 38 (Data Entry LSB) that appear in a transaction for the log parameter in the session history.
彼らはコントロールチェンジをするためのトランザクションに表示されるコントローラ番号6（データ・エントリーMSB）または38（データ入力LSB）ためのコマンド先行場合AボタンとCボタンの両方のために、データインクリメントおよびデータデクリメントコントロールチェンジコマンドはカウントされませんセッション履歴にパラメータを記録します。
The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers, and the G bit associated with the field codes the sign of the integer (G = 0 for positive or zero, G = 1 for negative).
AボタンとCボタンフィールドは符号なし整数として解釈され、そしてフィールドコードの整数の符号に関連付けられたGビット（正またはゼロのためにG = 0、G = 1、負の場合）。
To compute and code the count value, initialize the count value to 0, add 1 for each qualifying Data Increment command, and subtract 1 for each qualifying Data Decrement command. After each addition or subtraction, limit the count magnitude to 16383. The G bit codes the sign of the count, and the A-BUTTON or C-BUTTON field codes the count magnitude.
計算し、コードカウント値を0にカウント値を初期化し、各適格データインクリメントコマンドに1を追加し、各適格データデクリメントコマンドの1を減算します。各加算または減算した後、Gビットの符号数の符号、およびAボタンまたはCボタンのフィールドコードカウントの大きさを16383までカウントの大きさを制限します。
For the A-BUTTON field, if the most recent qualified Data Increment or Data Decrement command precedes the most recent Control Change command for controller 121 (Reset All Controllers) in the session history, the X bit associated with A-BUTTON field MUST be set to 1. Otherwise, the X bit MUST be set to 0.
最新の修飾データインクリメントまたはDataデクリメントコマンドは、コントローラ121の最新のコントロールチェンジコマンドを先行した場合A-BUTTON分野では、セッションの歴史の中で（リセット・オール・コントローラー）、ボタン・フィールドに関連付けられているXビットを設定しなければなりませんそれ以外の場合は1に、Xビットは0に設定しなければなりません。
A parameter log that uses the value tool MUST include the A-BUTTON and C-BUTTON fields if an active Control Change command for controller numbers 96 or 97 appears in the checkpoint history. However, to improve coding efficiency, this rule has several exceptions:
コントローラ番号チェックポイント歴史の中で96または97が表示さのためにアクティブ制御変更命令場合、値のツールを使用して、パラメータ・ログは、AボタンとCボタンフィールドを含まなければなりません。しかし、符号化効率を向上させるために、このルールは、いくつかの例外があります。
o If the log includes the A-BUTTON field, and if the X bit of the A-BUTTON field is set to 1, the C-BUTTON field (and its associated R and G bits) MAY be omitted from the log.
Oログは、Aボタン・フィールドを含み、AボタンフィールドのXビットが1に設定されている場合、Cボタンのフィールド（およびその関連するRとGビット）をログから省略されるかもしれません場合。
o If the log includes the A-BUTTON field, and if the A-BUTTON and C-BUTTON fields (and their associated G bits) code identical values, the C-BUTTON field (and its associated R and G bits) MAY be omitted from the log.
Oログは、Aボタンフィールドが含まれている場合、およびAボタンとCボタンフィールド（およびそれらに関連するGビット）コード同じ値、Cボタンのフィールド（およびその関連するRとGビット）は省略されるかもしれ場合ログから。
A.4.2.2. The Count Tool
A.4.2.2。カウントツール
The count tool tracks the number of transactions for an RPN or NRPN parameter. The N TOC bit codes the presence of the octet shown in Figure A.4.7 in the field list.
カウントツールは、RPNやNRPNパラメータのためのトランザクションの数を追跡します。 N TOCビットコードフィールドリストの図A.4.7に示すオクテットが存在します。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| COUNT |
+-+-+-+-+-+-+-+-+
Figure A.4.7 -- COUNT Field
図A.4.7 - COUNTフィールド
The 7-bit COUNT codes the number of initiated transactions for the log parameter that appear in the session history. Initiated transactions are counted if they contain one or more active Control Change commands, including commands for controllers 98-101 that initiate the parameter transaction.
7ビットのCOUNTコードセッション履歴に表示されるログパラメータに開始されたトランザクションの数。彼らは、パラメータトランザクションを開始し、コントローラ98から101のためのコマンドを含む1つの以上のアクティブコントロールチェンジコマンドを、含まれている場合、開始されたトランザクションがカウントされます。
If the most recent counted transaction precedes the most recent Control Change command for controller 121 (Reset All Controllers) in the session history, the X bit associated with the COUNT field MUST be set to 1. Otherwise, the X bit MUST be set to 0.
最新のカウントのトランザクションがセッション履歴に（リセット・オール・コントローラー）、コントローラ121の最新のコントロールチェンジコマンドを先行した場合、COUNTフィールドに関連付けられているXビットはそうでない場合は1に設定しなければならない、Xビットは0に設定しなければなりません。
Transaction counting is performed modulo 128. The transaction count is set to 0 at the start of a session and is reset to 0 whenever a Reset State command (Appendix A.1) appears in the session history.
トランザクションカウントは、セッションの開始時にトランザクション・カウントが0に設定されているモジュロ128を行い、リセット状態コマンド（付録A.1）は、セッション履歴に表示されたときに0にリセットされます。
A parameter log that uses the count tool MUST include the COUNT field if an active command that increments the transaction count (modulo 128) appears in the checkpoint history.
トランザクション数（モジュロ128）をインクリメントし、アクティブコマンドがチェックポイント歴史に表示されている場合COUNTフィールドを含まなければならないカウントツールを使用して、パラメータログ。
A.5. Chapter W: MIDI Pitch Wheel
A.5。章W：MIDIピッチホイール
A channel journal MUST contain Chapter W if a C-active MIDI Pitch Wheel (0xE) command appears in the checkpoint history. Figure A.5.1 shows the format for Chapter W.
C-アクティブMIDIピッチホイール（から0xE）コマンドがチェックポイント歴史に現れるならチャンネルジャーナルは章Wを含まなければなりません。図A.5.1章W.のためのフォーマットを示し
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| FIRST |R| SECOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.5.1 -- Chapter W Format
図A.5.1 - 章Wフォーマット
The chapter has a fixed size of 16 bits. The FIRST and SECOND fields are the 7-bit values of the first and second data octets of the most recent active Pitch Wheel command in the session history.
章では、16ビットの固定サイズを有します。 1番目と2番目のフィールドは、セッションの歴史の中で最も最近の活発なピッチホイール命令の第1および第2のデータオクテットの7ビットの値です。
Note that Chapter W encodes C-active commands and thus does not encode active commands that are not C-active (see the second-to-last paragraph of Appendix A.1 for an explanation of chapter inclusion text in this regard).
章Wは（この点で章包含テキストの説明は、付録A.1の最後から2番目の段落を参照）C-アクティブコマンドをコードし、従ってC-アクティブでないアクティブコマンドをコードしないことに留意されたいです。
Chapter W does not encode "active but not C-active" commands because [RP015] declares that Control Change commands for controller number 121 (Reset All Controllers) act to reset the Pitch Wheel value to 0. If Chapter W encoded "active but not C-active" commands, a repair operation following a Reset All Controllers command could incorrectly repair the stream with a stale Pitch Wheel value.
【RP015は】コントロールチェンジはコントローラ番号121のためのコマンドことを宣言するので章W「はアクティブではなく、C-アクティブ」がコマンドコードしない（すべてのコントローラをリセット）章W「は、アクティブコードされるが、そうでない場合0にピッチホイール値をリセットするように作用しますC-アクティブ」コマンドは、リセットすべてのコントローラコマンドを以下の修復操作を誤って古いピッチホイール値を持つストリームを修復することができます。
A.6. Chapter N: MIDI NoteOff and NoteOn
A.6。章N：MIDI NoteOffとNoteOn
In this appendix, we consider NoteOn commands with zero velocity to be NoteOff commands. Readers may wish to review the Appendix A.1 definition of "N-active commands" before reading this appendix.
この付録では、我々は、ゼロ速度でNoteOnコマンドはコマンドNoteOffであると考えています。読者は、この付録を読む前に、「N-アクティブコマンド」の付録A.1定義を確認することが望まれます。
Chapter N completely protects note commands in streams that alternate between NoteOn and NoteOff commands for a particular note number. However, in rare applications, multiple overlapping NoteOn commands may appear for a note number. Chapter E, described in Appendix A.7, augments Chapter N to completely protect these streams.
章Nは完全にNoteOnとNoteOff間の代替は、特定のノートナンバためのコマンドストリームにおけるノートコマンドを保護します。しかし、まれなアプリケーションでは、複数の重複NoteOnコマンドは、ノート番号のために表示されることがあります。付録A.7で説明した章Eは、完全にこれらのストリームを保護するために章Nを強化します。
A channel journal MUST contain Chapter N if an N-active MIDI NoteOn (0x9) or NoteOff (0x8) command appears in the checkpoint history. Figure A.6.1 shows the format for Chapter N.
N-アクティブMIDI NoteOn（0x9）またはNoteOff（0x8の）コマンドがチェックポイント歴史に現れるならチャンネルジャーナルは章Nを含まなければなりません。図A.6.1章N.のフォーマットを示してい
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OFFBITS | OFFBITS | .... | OFFBITS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.1 -- Chapter N Format
図A.6.1 - 章Nのフォーマット
Chapter N consists of a 2-octet header followed by at least one of the following data structures:
章Nは、次のデータ構造のうちの少なくとも一方が続く2オクテットのヘッダから成ります。
o A list of note logs to code NoteOn commands. o A NoteOff bitfield structure to code NoteOff commands.
Oノートログのリストは、NoteOnコマンドをコーディングします。 O NoteOffビットフィールド構造は、コマンドNoteOffコーディングします。
We define the header bitfield semantics in Appendix A.6.1. We define the note log semantics and the NoteOff bitfield semantics in Appendix A.6.2.
私たちは、付録A.6.1のヘッダービットフィールドのセマンティクスを定義します。私たちは、ノートログのセマンティクスと付録A.6.2でNoteOffビットフィールドのセマンティクスを定義します。
If one or more N-active NoteOn or NoteOff commands in the checkpoint history reference a note number, the note number MUST be coded in either the note log list or the NoteOff bitfield structure.
一つ以上のN-活性NoteOnまたはNoteOffは、チェックポイント履歴参照してノートナンバを指示する場合、ノートナンバは、ノートログリストまたはNoteOffビットフィールド構造のいずれかで符号化されなければなりません。
The note log list MUST contain an entry for all note numbers whose most recent checkpoint history appearance is in an N-active NoteOn command. The NoteOff bitfield structure MUST contain a set bit for all note numbers whose most recent checkpoint history appearance is in an N-active NoteOff command.
ノートログリストは、最新のチェックポイント歴史外観N-アクティブNoteOnコマンドであるすべてのノート番号のエントリを含める必要があります。 NoteOffビットフィールドの構造は、最新のチェックポイント履歴外観すべてのノート番号の設定ビットを含まなければならないN-アクティブNoteOffコマンドです。
A note number MUST NOT be coded in both structures.
ノート番号は、両方の構造でコーディングされてはなりません。
All note logs and NoteOff bitfield set bits MUST code the most recent N-active NoteOn or NoteOff reference to a note number in the session history.
すべてのノートログとNoteOffビットフィールド設定されたビットは、セッションの歴史の中でノートナンバーに最も最近のN-アクティブNoteOnかNoteOff参照をコード化しなければなりません。
The note log list MUST obey the oldest-first ordering rule (defined in Appendix A.1).
ノートログリストは、（付録A.1で定義されている）最古-最初の発注ルールに従わなければなりません。
A.6.1. Header Structure
A.6.1。ヘッダ構造
The header for Chapter N, shown in Figure A.6.2, codes the size of the note list and bitfield structures.
図A.6.2に示す章Nのヘッダ、コードメモリストのサイズとビットフィールド構造。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.2 -- Chapter N Header
図A.6.2 - 章Nヘッダー
The LEN field, a 7-bit integer value, codes the number of 2-octet note logs in the note list. Zero is a valid value for LEN and codes an empty note list.
LENフィールド、7ビットの整数値を、コードメモリストの2オクテットのノートログの数。ゼロはLENとコードの空のノートリストの有効な値です。
The 4-bit LOW and HIGH fields code the number of OFFBITS octets that follow the note log list. LOW and HIGH are unsigned integer values. If LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the chapter. The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH = 1) code an empty NoteOff bitfield structure (i.e., no OFFBITS octets). Other (LOW > HIGH) value pairs MUST NOT appear in the header.
4ビットのLOWとHIGHフィールドコードノートログリストに従ってくださいOFFBITSオクテットの数。 LOWとHIGHは、符号なし整数値です。 LOW <= HIGH場合は、（HIGH - LOW + 1）がある章のオクテットをOFFBITS。値ペア（= 0 LOW = 15、HIGH）及び（LOW = 15、HIGH = 1）コード空NoteOffビットフィールド構造（すなわち、無OFFBITSオクテット）。その他（LOW> HIGH）と値のペアは、ヘッダーに現れてはいけません。
The B bit provides S-bit functionality (Appendix A.1) for the NoteOff bitfield structure. By default, the B bit MUST be set to 1. However, if the MIDI command section of the previous packet (packet I - 1, with I as defined in Appendix A.1) includes a NoteOff command for the channel, the B bit MUST be set to 0. If the B bit is set to 0, the higher-level recovery journal elements that contain Chapter N MUST have S bits that are set to 0, including the top-level journal header.
BビットはNoteOffビットフィールド構造のためのSビットの機能（付録A.1）を提供します。チャネル、BビットのためのNoteOffコマンドを含む - 前のパケットのMIDI命令部（1、Iと付録A.1で定義されたパケットは、I）場合、デフォルトで、Bビットが、しかし1に設定しなければなりませんBビットが0に設定されている場合は0に設定しなければなりません、章Nを含む高レベル回復ジャーナル要素は、トップレベルのジャーナルヘッダを含む0に設定されるSビットを有していなければなりません。
The LEN value of 127 codes a note list length of 127 or 128 note logs, depending on the values of LOW and HIGH. If LEN = 127, LOW = 15, and HIGH = 0, the note list holds 128 note logs, and the NoteOff bitfield structure is empty. For other values of LOW and HIGH, LEN = 127 codes that the note list contains 127 note logs. In this case, the chapter has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <= HIGH and has no OFFBITS octets if LOW = 15 and HIGH = 1.
127のコードのLEN値LOWとHIGHの値に応じて127のまたは128ノートログのメモリストの長さ、。 LOW LEN = 127、= 15、HIGH = 0の場合、ノートのリストは128のノートのログを保持し、NoteOffビットフィールド構造は空です。 LOWとHIGH、ノートリストは127件のノートログが含まれていLEN = 127コードの他の値について。 （ - LOW + 1 HIGH）NoteOff OFFBITSオクテット低IF <= HIGHおよびLOW = 15、HIGH = 1であれば何OFFBITSオクテットを有していないこの場合、章有します。
A.6.2. Note Structures
A.6.2。注構造
Figure A.6.3 shows the 2-octet note log structure.
図A.6.3は2オクテットノートログ構造を示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.3 -- Chapter N Note Log
図A.6.3 - 章N注ログ
The 7-bit NOTENUM field codes the note number for the log. A note number MUST NOT be represented by multiple note logs in the note list.
7ビットNOTENUMフィールドコードログのノートナンバー。ノート番号は、ノートリストに複数のノートログで表現してはなりません。
The 7-bit VELOCITY field codes the velocity value for the most recent N-active NoteOn command for the note number in the session history. Multiple overlapping NoteOns for a given note number may be coded using Chapter E, as discussed in Appendix A.7.
7ビットVELOCITYフィールドコードセッションの歴史の中でノートナンバーのための最も最近のN-アクティブNoteOnコマンドの速度値。付録A.7で説明したように与えられたノートナンバーのための複数の重複NoteOnsは、チャプターEを用いて符号化することができます。
VELOCITY is never zero; NoteOn commands with zero velocity are coded as NoteOff commands in the NoteOff bitfield structure.
VELOCITYはゼロになることはありません。 NoteOffがNoteOffビットフィールド構造にコマンドとしてゼロ速度でNoteOnコマンドが符号化されます。
The note log does not code the execution time of the NoteOn command. However, the Y bit codes a hint from the sender about the NoteOn execution time. The Y bit codes a recommendation to play (Y = 1) or skip (Y = 0) the NoteOn command recovered from the note log. See Section 4.2 of [RFC4696] for non-normative guidance on the use of the Y bit.
ノートログはNoteOnコマンドの実行時間をコーディングしていません。しかし、YビットコードNoteOn実行時間についての送信者からのヒント。 Yビットコード（Y = 1）を再生したりスキップする勧告（Y = 0）注ログから回収NoteOnコマンド。 Yビットの使用上の非規範的なガイダンスについては、[RFC4696]のセクション4.2を参照してください。
Figure A.6.1 shows the NoteOff bitfield structure as the list of OFFBITS octets at the end of the chapter. A NoteOff OFFBITS octet codes NoteOff information for eight consecutive MIDI note numbers, with the most significant bit representing the lowest note number. The most significant bit of the first OFFBITS octet codes the note number 8*LOW; the most significant bit of the last OFFBITS octet codes the note number 8*HIGH.
図A.6.1は、章の終わりにOFFBITSオクテットのリストとしてNoteOffビットフィールドの構造を示しています。最低音の数を表す最上位ビットと8つの連続したMIDIノート番号の情報、NoteOff NoteOff OFFBITSオクテットコード。第OFFBITSオクテットコードの最上位ビットノート番号8 * LOW。ノートナンバー8 * HIGH最後OFFBITSオクテットコードの最上位ビット。
A set bit codes a NoteOff command for the note number. In the most efficient coding for the NoteOff bitfield structure, the first and last octets of the structure contain at least one set bit. Note that Chapter N does not code NoteOff velocity data.
セットビットコードノート番号のNoteOffコマンド。 NoteOffビットフィールド構造のための最も効率的な符号化では、構造の最初と最後のオクテットは、少なくとも一組のビットが含まれています。章Nは、速度データNoteOffコーディングしていないことに注意してください。
Note that in the general case, the recovery journal does not code the relative placement of a NoteOff command and a Change Control command for controller 64 (Damper Pedal (Sustain)). In many cases, a receiver processing a loss event may deduce this relative placement from the history of the stream and thus determine if a NoteOff note is sustained by the pedal. If such a determination is not possible, receivers SHOULD err on the side of silencing pedal sustains, as erroneously sustained notes may produce unpleasant (albeit transient) artifacts.
一般的な場合には、回復ジャーナルがNoteOffコマンドの相対的な配置とコントローラ64（ダンパーペダル（サスティン））の変更制御コマンドをコーディングしないことに注意してください。多くの場合、損失イベントを処理する受信機は、ストリームの履歴から、この相対的な配置を推定し、従ってNoteOffノートがペダルによって維持されるかどうかを決定してもよいです。そのような判断ができない場合、受信機はペダルサステインサイレンシングの側に誤るべきである、などの誤っ持続ノートは、アーチファクト（一過性にもかかわらず）不快生成することができます。
A.7. Chapter E: MIDI Note Command Extras
A.7。章E：MIDIノート・コマンド・エクストラ
Readers may wish to review the Appendix A.1 definition of "N-active commands" before reading this appendix. In this appendix, a NoteOn command with a velocity of 0 is considered to be a NoteOff command with a release velocity value of 64.
読者は、この付録を読む前に、「N-アクティブコマンド」の付録A.1定義を確認することが望まれます。この付録では、0の速度でNoteOnコマンドは、64の放出速度値とNoteOffコマンドであると考えられます。
Chapter E encodes recovery information about MIDI NoteOn (0x9) and NoteOff (0x8) command features that rarely appear in MIDI streams. Receivers use Chapter E to reduce transient artifacts for streams where several NoteOn commands appear for a note number without an intervening NoteOff. Receivers also use Chapter E to reduce transient artifacts for streams that use NoteOff release velocity. Chapter E supplements the note information coded in Chapter N (Appendix A.6).
章Eは、MIDIストリームにめったに現れないMIDI NoteOn（0x9）とNoteOff（0x8の）コマンドの機能についての復旧情報を符号化します。受信機は、いくつかのNoteOnコマンドが介在NoteOffずにノート番号は表示されたストリームのための過渡的なアーティファクトを低減するために章Eを使用します。受信機はまた、リリースベロシティNoteOff使用したストリームのための過渡的なアーティファクトを低減するために章Eを使用します。章E章N（付録A.6）でコード化されたノート情報を補足するものです。
Figure A.7.1 shows the format for Chapter E.
図A.7.1章E.のフォーマットを示しています
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NOTENUM |V| COUNT/VEL |S| NOTENUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| COUNT/VEL | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.7.1 -- Chapter E Format
図A.7.1 - 章Eフォーマット
The chapter consists of a 1-octet header followed by a variable-length list of 2-octet note logs. Appendix A.7.1 defines the bitfield format for a note log.
章では、2オクテットのノートログの可変長リストが続く1オクテットのヘッダから成ります。付録A.7.1は、ノートログのビットフィールドのフォーマットを定義します。
The log list MUST contain at least one note log. The 7-bit LEN header field codes the number of note logs in the list, minus one. A channel journal MUST contain Chapter E if the rules defined in this appendix require that one or more note logs appear in the list. The note log list MUST obey the oldest-first ordering rule (defined in Appendix A.1).
ログリストには、少なくとも1つの音符のログを含まなければなりません。 7ビットLENヘッダフィールドコードリストでのノートログの数から1を引きました。この付録で定義されたルールは、1件のまたは複数のノートログがリストに表示されていることが必要な場合はチャンネルジャーナルは章Eを含まなければなりません。ノートログリストは、（付録A.1で定義されている）最古-最初の発注ルールに従わなければなりません。
A.7.1. Note Log Format
A.7.1。ログ形式に注意してください。
Figure A.7.2 reproduces the note log structure of Chapter E.
図A.7.2章E.のノートログ構造を再現します
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |V| COUNT/VEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.7.2 -- Chapter E Note Log
図A.7.2 - 章Eノートログイン
A note log codes information about the MIDI note number coded by the 7-bit NOTENUM field. The nature of the information depends on the value of the V flag bit.
7ビットNOTENUMフィールドで符号化されたMIDIノートナンバーに関するメモログコード情報。情報の性質は、Vフラグビットの値に依存します。
If the V bit is set to 1, the COUNT/VEL field codes the release velocity value for the most recent N-active NoteOff command for the note number that appears in the session history.
Vビットが1に設定されている場合は、COUNT / VELフィールドコードセッション履歴に表示されたノート・ナンバーの最も最近のN-アクティブNoteOffコマンドのリリースベロシティ値。
If the V bit is set to 0, the COUNT/VEL field codes a reference count of the number of NoteOn and NoteOff commands for the note number that appears in the session history.
Vビットが0に設定されている場合は、COUNT / VELフィールドコードNoteOnとNoteOffの数の参照カウントは、セッション履歴に表示されるノート番号ためのコマンド。
The reference count is set to 0 at the start of the session. NoteOn commands increment the count by 1. NoteOff commands decrement the count by 1. However, a decrement that generates a negative count value is not performed.
参照カウントは、セッションの開始時に0に設定されています。 NoteOnコマンドは、1 NoteOffコマンドでカウントをインクリメント負のカウント値を生成デクリメントが行われていない、しかし、1により、カウントをデクリメント。
If the reference count is in the range 0-126, the 7-bit COUNT/VEL field codes an unsigned integer representation of the count. If the count is greater than or equal to 127, COUNT/VEL is set to 127.
参照カウントが0から126の範囲、7ビットのCOUNT / VELフィールドコード数の符号なし整数表現である場合。カウントがより大きい又は127に等しい場合、COUNT / VELは127に設定されています。
By default, the count is reset to 0 whenever a Reset State command (Appendix A.1) appears in the session history and whenever MIDI Control Change commands for controller numbers 123-127 (numbers with All Notes Off semantics) or 120 (All Sound Off) appear in the session history.
リセット状態コマンド（付録A.1）は、セッション履歴に表示され、いつMIDIコントロールチェンジはコントローラ番号123-127（すべてのノートとの数字の意味オフ）または120（すべてのサウンドのためのコマンドをいつでもデフォルトでは、カウントが0にリセットされますオフ）セッション履歴に表示されます。
A.7.2. Log Inclusion Rules
A.7.2。包含ルールをログに記録
If the most recent N-active NoteOn or NoteOff command for a note number in the checkpoint history is a NoteOff command with a release velocity value other than 64, a note log whose V bit is set to 1 MUST appear in Chapter E for the note number.
チェックポイント歴史の中でノートナンバーのための最も最近のN-アクティブNoteOnかNoteOffコマンドが64以外の解除速度値とNoteOffコマンドの場合、そのVビットを1に設定されているノート・ログには、ノートの章Eに現れなければなりません数。
If the most recent N-active NoteOn or NoteOff command for a note number in the checkpoint history is a NoteOff command, and if the reference count for the note number is greater than 0, a note log whose V bit is set to 0 MUST appear in Chapter E for the note number.
チェックポイント歴史の中でノートナンバーのための最も最近のN-アクティブNoteOnかNoteOffコマンドは、NoteOffコマンドで、ノート番号の参照カウントが0より大きい場合、そのVビット0に設定されているノートログが表示されなければならない場合章Eにおけるノートナンバーについて。
If the most recent N-active NoteOn or NoteOff command for a note number in the checkpoint history is a NoteOn command, and if the reference count for the note number is greater than 1, a note log whose V bit is set to 0 MUST appear in Chapter E for the note number.
チェックポイント歴史の中でノートナンバーのための最も最近のN-アクティブNoteOnかNoteOffコマンドがNoteOnコマンドで、ノート番号の参照カウントが1より大きい場合、そのVビット0に設定されているノートログが表示されなければならない場合章Eにおけるノートナンバーについて。
At most, two note logs MAY appear in Chapter E for a note number: one log whose V bit is set to 0 and one log whose V bit is set to 1.
そのVビットそのVビット1にセットされ、0と1のログに設定されている1つのログ：せいぜい、2つのノートログは、ノート番号の章Eに表示されることがあります。
Chapter E codes a maximum of 128 note logs. If the log inclusion rules yield more than 128 REQUIRED logs, note logs whose V bit is set to 1 MUST be dropped from Chapter E in order to reach the 128-log limit. Note logs whose V bit is set to 0 MUST NOT be dropped.
章Eコード128のノートログの最大。ログ包含ルールが128の以上必要なログを得た場合、そのVビット1に設定されている音符ログ128ログ限界に到達するために章Eから削除されなければなりません。そのVビット0に設定されているノート・ログが破棄されてはなりません。
Most MIDI streams do not use NoteOn and NoteOff commands in ways that would trigger the log inclusion rules. For these streams, Chapter E would never be REQUIRED to appear in a channel journal.
ほとんどのMIDIストリームはNoteOnを使用していないとNoteOffは、ログ包含ルールをトリガーする方法でコマンド。これらのストリームについては、章Eは、チャンネルジャーナルに表示されるために必要とされることはないだろう。
The ch_never parameter (Appendix C.2.3) may be used to configure the log inclusion rules for Chapter E.
ch_neverパラメータ（付録C.2.3）は章E.のログ包含ルールを構成するために使用することができます
A.8. Chapter T: MIDI Channel Aftertouch
A.8。章T：MIDIチャンネル・アフタータッチ
A channel journal MUST contain Chapter T if an N-active and C-active MIDI Channel Aftertouch (0xD) command appears in the checkpoint history. Figure A.8.1 shows the format for Chapter T.
N-アクティブおよびC-アクティブMIDIチャンネル・アフタータッチ（0xDの）コマンドがチェックポイント歴史に現れるならチャンネルジャーナルは章Tを含まなければなりません。図A.8.1章T.のフォーマットを示しています
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| PRESSURE |
+-+-+-+-+-+-+-+-+
Figure A.8.1 -- Chapter T Format
図A.8.1 - 章Tのフォーマット
The chapter has a fixed size of 8 bits. The 7-bit PRESSURE field holds the pressure value of the most recent N-active and C-active Channel Aftertouch command in the session history.
章では、8ビットの固定サイズを有します。 7ビットの圧力場は、最新のN-アクティブおよびセッションの歴史の中でC-アクティブチャンネル・アフタータッチコマンドの圧力値を保持しています。
Chapter T only encodes commands that are C-active and N-active. We define a C-active restriction because [RP015] declares that a Control Change command for controller 121 (Reset All Controllers) acts to reset the channel pressure to 0 (see the discussion at the end of Appendix A.5 for a more complete rationale).
章Tは、C-活性及びN-アクティブであるコマンドを符号化します。 【RP015は、コントローラ121の制御変更コマンド（すべてのコントローラをリセット）0チャンネル圧力をリセットするように作用することを宣言しているため、我々はC-アクティブ制限を定義する（より完全な理論的根拠は、付録A.5の端部での議論を参照の）。
We define an N-active restriction on the assumption that aftertouch commands are linked to note activity, and thus Channel Aftertouch commands that are not N-active are stale and should not be used to repair a stream.
私たちは、アフタータッチコマンドが活動を注意することがリンクされていることを前提としたN-アクティブ制限を定義し、従ってN-アクティブでないチャンネル・アフタータッチコマンドは陳腐で、ストリームを修復するために使用すべきではありません。
A.9. Chapter A: MIDI Poly Aftertouch
A.9。第A章：MIDIポリアフタータッチ
A channel journal MUST contain Chapter A if a C-active Poly Aftertouch (0xA) command appears in the checkpoint history. Figure A.9.1 shows the format for Chapter A.
C-アクティブポリアフタータッチ（0xAが）コマンドがチェックポイント歴史に現れるならチャンネルジャーナルは章Aを含まなければなりません。図A.9.1章Aの形式を示し
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NOTENUM |X| PRESSURE |S| NOTENUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| PRESSURE | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.9.1 -- Chapter A Format
図A.9.1 - 章Aフォーマット
The chapter consists of a 1-octet header followed by a variable-length list of 2-octet note logs. A note log MUST appear for a note number if a C-active Poly Aftertouch command for the note number appears in the checkpoint history. A note number MUST NOT be represented by multiple note logs in the note list. The note log list MUST obey the oldest-first ordering rule (defined in Appendix A.1).
章では、2オクテットのノートログの可変長リストが続く1オクテットのヘッダから成ります。ノート番号のC-アクティブポリアフタータッチコマンドがチェックポイント歴史に表示された場合はログには、ノート番号は表示されなければなりません。ノート番号は、ノートリストに複数のノートログで表現してはなりません。ノートログリストは、（付録A.1で定義されている）最古-最初の発注ルールに従わなければなりません。
The 7-bit LEN field codes the number of note logs in the list, minus one. Figure A.9.2 reproduces the note log structure of Chapter A.
7ビットのLENフィールドコードリストでノートログの数、マイナス1。図A.9.2章Aのノートログ構造を再現します
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |X| PRESSURE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.9.2 -- Chapter A Note Log
図A.9.2 - 章注ログ
The 7-bit PRESSURE field codes the pressure value of the most recent C-active Poly Aftertouch command in the session history for the MIDI note number coded in the 7-bit NOTENUM field.
7ビット圧力フィールドコード7ビットNOTENUMフィールドに符号化されたMIDIノート番号のセッション履歴内の最新のC-活性ポリアフタータッチコマンドの圧力値。
As a rule, the X bit MUST be set to 0. However, the X bit MUST be set to 1 if the command coded by the log appears before one of the following commands in the session history: MIDI Control Change numbers 123-127 (numbers with All Notes Off semantics) or 120 (All Sound Off).
MIDIコントロールチェンジ番号123-127（：原則として、Xビットはログによってコード化されたコマンドは、セッションの歴史の中で、次のいずれかのコマンドの前に表示された場合は、Xビットが1に設定しなければならなく0に設定しなければなりません。セマンティクスオフオールノートと数字）または120（オール・サウンド・オフ）。
We define C-active restrictions for Chapter A because [RP015] declares that a Control Change command for controller 121 (Reset All Controllers) acts to reset the polyphonic pressure to 0 (see the discussion at the end of Appendix A.5 for a more complete rationale).
【RP015は、コントローラ121の制御変更コマンド（すべてのコントローラのリセット）を0にポリフォニック圧力をリセットするように作用することを宣言しているため、我々は章AのC-アクティブ制限を定義する（詳細については、付録A.5の終わりに議論を参照完全な根拠）。
Appendix B. The Recovery Journal System Chapters
付録B.ザ・回復ジャーナルシステムの章
B.1. System Chapter D: Simple System Commands
B.1。システム章D：シンプルなシステムコマンド
The system journal MUST contain Chapter D if an active MIDI Reset (0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined MIDI System Common (0xF4 and 0xF5), or undefined MIDI System Real-Time (0xF9 and 0xFD) command appears in the checkpoint history.
システムジャーナルは章Dを含んでいなければならない場合は、アクティブMIDIリセット（は0xFF）、MIDIチューン・リクエスト（0xF6）、MIDIソング・セレクト（0xF3）、未定義のMIDIシステム共通（0xF4と0xF5）、または未定義のMIDIシステムリアルタイム（0xF9と0xFDで）コマンドがチェックポイント歴史に表示されます。
Figure B.1.1 shows the variable-length format for Chapter D.
図B.1.1章Dの可変長フォーマットを示します
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|B|G|H|J|K|Y|Z| Command logs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.1 -- System Chapter D Format
図B.1.1 - システム章Dフォーマット
The chapter consists of a 1-octet header followed by one or more command logs. Header flag bits indicate the presence of command logs for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1), undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K = 1), undefined System Real-Time 0xF9 (Y = 1), or undefined System Real-Time 0xFD (Z = 1) commands.
章では、一つ以上のコマンドログに続く1オクテットのヘッダから成ります。ヘッダのフラグビットをリセットするためのコマンドログの存在を示す（B = 1）、チューン・リクエスト（= 1 G）、ソング・セレクト（H = 1）、K未定義システム共通0xF4（J = 1）、未定義のシステム共通0xF5（ = 1）、未定義のシステムリアルタイム0xF9（Y = 1）、または不定システムリアルタイム0xFDでは（Z = 1）コマンド。
Command logs appear in a list following the header, in the order that the flag bits appear in the header.
コマンドログはフラグビットがヘッダに表示される順序で、ヘッダを次の一覧に表示されます。
Figure B.1.2 shows the 1-octet command log format for the Reset and Tune Request commands.
図B.1.2がリセットされ、チューニング要求コマンド用の1オクテットのコマンドログフォーマットを示します。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+
Figure B.1.2 -- Command Log for Reset and Tune Request
図B.1.2 - リセットやチューンの要求のためのコマンドログ
Chapter D MUST contain the Reset command log if an active Reset command appears in the checkpoint history. The 7-bit COUNT field codes the total number of Reset commands (modulo 128) present in the session history.
アクティブリセットコマンドがチェックポイント歴史に現れるなら章Dは、リセットコマンドログを含まなければなりません。 7ビットのCOUNTフィールドコードセッション履歴内に存在するリセットコマンド（モジュロ128）の総数。
Chapter D MUST contain the Tune Request command log if an active Tune Request command appears in the checkpoint history. The 7-bit COUNT field codes the total number of Tune Request commands (modulo 128) present in the session history.
アクティブチューン要求コマンドがチェックポイント歴史に現れるなら章Dは、チューン・リクエスト・コマンドログを含まなければなりません。 7ビットのCOUNTフィールドコードセッション履歴内に存在するチューン要求コマンドの総数（モジュロ128）。
For these commands, the COUNT field acts as a reference count. See the definition of "session history reference counts" in Appendix A.1 for more information.
これらのコマンドについては、COUNTフィールドは、参照カウントとして機能します。詳細については、付録A.1の「セッション履歴参照カウント」の定義を参照してください。
Figure B.1.3 shows the 1-octet command log format for the Song Select command.
図B.1.3は、ソング・セレクトコマンドの1オクテットのコマンドログフォーマットを示しています。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| VALUE |
+-+-+-+-+-+-+-+-+
Figure B.1.3 -- Song Select Command Log Format
図B.1.3 - ソング・セレクトコマンドログのフォーマット
Chapter D MUST contain the Song Select command log if an active Song Select command appears in the checkpoint history. The 7-bit VALUE field codes the song number of the most recent active Song Select command in the session history.
アクティブソング・セレクトコマンドがチェックポイント歴史に現れるなら章Dは、ソング・セレクトのコマンドログを含まなければなりません。 7ビットのVALUEフィールドコードセッションの歴史の中で最も最近の活発なソング・セレクトコマンドの曲番号。
B.1.1. Undefined System Commands
B.1.1。未定義のシステムコマンド
In this section, we define the Chapter D command logs for the undefined system commands. [MIDI] reserves the undefined system commands 0xF4, 0xF5, 0xF9, and 0xFD for future use. At the time of this writing, any MIDI command stream that uses these commands is non-compliant with [MIDI]. However, future versions of [MIDI] may define these commands, and a few products do use these commands in a non-compliant manner.
このセクションでは、未定義のシステムコマンドの章Dコマンドのログを定義します。 [MIDI]は未定義のシステムは、将来の使用のため0xF4、0xF5、0xF9と0xFDでのコマンド留保します。この記事の執筆時点では、これらのコマンドを使用して任意のMIDIコマンドストリームは、[MIDI]と非対応です。ただし、[MIDI]の将来のバージョンでは、これらのコマンドを定義することができ、そしていくつかの製品は、非準拠した方法でこれらのコマンドを使用して行います。
Figure B.1.4 shows the variable-length command log format for the undefined System Common commands (0xF4 and 0xF5).
図B.1.4は未定義システム共通コマンド（0xF4と0xF5）のための可変長コマンドログフォーマットを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|V|L|DSZ| LENGTH | COUNT | VALUE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEGAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.4 -- Undefined System Common Command Log Format
図B.1.4 - 不定システム共通のコマンドログフォーマット
The command log codes a single command type (0xF4 or 0xF5, not both). Chapter D MUST contain a command log if an active 0xF4 command appears in the checkpoint history and MUST contain an independent command log if an active 0xF5 command appears in the checkpoint history.
コマンドログコード、単一のコマンドタイプ（0xF4または0xF5、両方ではありません）。アクティブ0xF4コマンドがチェックポイント歴史に表示され、アクティブ0xF5コマンドがチェックポイント歴史に現れるなら独立したコマンドログを含まなければならない場合章Dは、コマンドログを含まなければなりません。
A Chapter D Undefined System Common command log consists of a two-octet header followed by a variable number of data fields. Header flag bits indicate the presence of the COUNT field (C = 1), the VALUE field (V = 1), and the LEGAL field (L = 1). The 10-bit LENGTH field codes the size of the command log and conforms to semantics described in Appendix A.1.
章D不定システム共通コマンドログがデータフィールドの可変数続く2オクテットのヘッダから成ります。ヘッダのフラグビットは、カウントフィールド（C = 1）の存在下、VALUEフィールド（V = 1）、および法的フィールド（L = 1）を示します。 10ビット長のフィールドコードコマンドログのサイズおよび付録A.1に記載の意味論に従います。
The 2-bit DSZ field codes the number of data octets in the command instance that appears most recently in the session history. If DSZ = 0-2, the command has 0-2 data octets. If DSZ = 3, the command has 3 or more command data octets.
2ビットのDSZフィールドコードセッションの歴史の中で最も最近表示されたコマンドインスタンス内のデータオクテットの数。 DSZは0-2 =場合、コマンドは0-2のデータオクテットを持っています。 DSZ = 3場合、コマンドは3つの以上のコマンドデータオクテットを持っています。
We now define the default rules for the use of the COUNT, VALUE, and LEGAL fields. The session configuration tools defined in Appendix C.2.3 may be used to override this behavior.
私たちは今、COUNT、VALUE、および法的フィールドの使用のためのデフォルトのルールを定義します。付録C.2.3に定義されたセッション構成ツールは、この動作を上書きするために使用することができます。
By default, if the DSZ field is set to 0, the command log MUST include the COUNT field. The 8-bit COUNT field codes the total number of commands of the type coded by the log (0xF4 or 0xF5) present in the session history, modulo 256.
DSZフィールドが0に設定されている場合、デフォルトでは、コマンドログはCOUNTフィールドを含まなければなりません。 8ビットのカウントフィールドコードセッション履歴内に存在するログ（0xF4または0xF5）、モジュロ256で符号化されたタイプのコマンドの総数。
By default, if the DSZ field is set to 1-3, the command log MUST include the VALUE field. The variable-length VALUE field codes a verbatim copy the data octets for the most recent use of the command type coded by the log (0xF4 or 0xF5) in the session history. The most significant bit of the final data octet MUST be set to 1, and the most significant bit of all other data octets MUST be set to 0.
DSZフィールドが1-3に設定されている場合、デフォルトでは、コマンドログは、VALUEフィールドを含まなければなりません。可変長VALUEフィールドコード逐語的なコピーセッション履歴内のログ（0xF4または0xF5）で符号化されたコマンドタイプの最新の使用のためのデータオクテット。最終的なデータオクテットの最上位ビットが1に設定しなければなりません、そして他のすべてのデータオクテットの最上位ビットが0に設定しなければなりません。
The LEGAL field is reserved for future use. If an update to [MIDI] defines the 0xF4 or 0xF5 command, an IETF Standards-Track document may define the LEGAL field. Until such a document appears, senders MUST NOT use the LEGAL field, and receivers MUST use the LENGTH field to skip over the LEGAL field. The LEGAL field would be defined by the IETF if the semantics of the new 0xF4 or 0xF5 command could not be protected from packet loss via the use of the COUNT and VALUE fields.
LEGALフィールドは将来の使用のために予約されています。 [MIDI]の更新が0xF4または0xF5コマンドを定義する場合、IETF標準トラック文書は、法的フィールドを定義することができます。そのような文書が表示されるまで、送信者は、法的フィールドを使用してはならない、とレシーバは、法的フィールドをスキップするLENGTHフィールドを使用しなければなりません。新しい0xF4または0xF5コマンドのセマンティクスはCOUNTとVALUEフィールドの使用を介してパケット損失から保護することができなかった場合は法的分野は、IETFによって定義されます。
Figure B.1.5 shows the variable-length command log format for the undefined System Real-Time commands (0xF9 and 0xFD).
図B.1.5は未定義システムリアルタイムコマンド（0xF9と0xFDで）のための可変長コマンドログフォーマットを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|L| LENGTH | COUNT | LEGAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.5 -- Undefined System Real-Time Command Log Format
図B.1.5 - 不定システムリアルタイムコマンドログフォーマット
The command log codes a single command type (0xF9 or 0xFD, not both). Chapter D MUST contain a command log if an active 0xF9 command appears in the checkpoint history and MUST contain an independent command log if an active 0xFD command appears in the checkpoint history.
コマンドログコード、単一のコマンドタイプ（0xF9または0xFDで、両方ではありません）。アクティブ0xF9コマンドがチェックポイント歴史に表示され、アクティブ0xFDでコマンドがチェックポイント歴史に現れるなら独立したコマンドログを含まなければならない場合章Dは、コマンドログを含まなければなりません。
A Chapter D Undefined System Real-Time command log consists of a one-octet header followed by a variable number of data fields. Header flag bits indicate the presence of the COUNT field (C = 1) and the LEGAL field (L = 1). The 5-bit LENGTH field codes the size of the command log and conforms to semantics described in Appendix A.1.
章D不定システムのリアルタイムコマンドログがデータフィールドの可変数続く1オクテットのヘッダから成ります。ヘッダのフラグビットは、カウントフィールド（C = 1）と法的フィールド（L = 1）の存在を示します。 5ビット長のフィールドコードコマンドログのサイズおよび付録A.1に記載の意味論に従います。
We now define the default rules for the use of the COUNT and LEGAL fields. The session configuration tools defined in Appendix C.2.3 may be used to override this behavior.
私たちは今、COUNTおよび法的フィールドの使用のためのデフォルトのルールを定義します。付録C.2.3に定義されたセッション構成ツールは、この動作を上書きするために使用することができます。
The 8-bit COUNT field codes the total number of commands of the type coded by the log present in the session history, modulo 256. By default, the COUNT field MUST be present in the command log.
8ビットのカウントフィールドコードは、セッション履歴内のログに存在することにより符号化されたタイプのコマンドの合計数は、デフォルトでモジュロ256は、COUNTフィールドは、コマンドログ内に存在していなければなりません。
The LEGAL field is reserved for future use. If an update to [MIDI] defines the 0xF9 or 0xFD command, an IETF Standards-Track document may define the LEGAL field to protect the command. Until such a document appears, senders MUST NOT use the LEGAL field, and receivers
LEGALフィールドは将来の使用のために予約されています。 [MIDI]へのアップデートが0xF9か0xFDでコマンドを定義している場合は、IETF標準化過程文書は、コマンドを保護する法的フィールドを定義することがあります。そのような文書が表示されるまで、送信者は、法的フィールドを使用して、受信機はならない（MUST NOT）
MUST use the LENGTH field to skip over the LEGAL field. The LEGAL field would be defined by the IETF if the semantics of the new 0xF9 or 0xFD command could not be protected from packet loss via the use of the COUNT field.
LEGALフィールドをスキップするLENGTHフィールドを使用しなければなりません。新しい0xF9か0xFDでコマンドのセマンティクスはCOUNTフィールドの使用を介して、パケット損失から保護することができなかった場合は法的分野は、IETFによって定義されます。
Finally, we note that some non-standard uses of the undefined System Real-Time commands act to implement non-compliant variants of the MIDI sequencer system. In Appendix B.3.1, we describe resiliency tools for the MIDI sequencer system that provide some protection in this case.
最後に、我々は未定義のシステムリアルタイムコマンドのいくつかの非標準的な用途は、MIDIシーケンサシステムの非準拠の変種を実装するように作用することに注意してください。付録B.3.1では、我々は、この場合には、いくつかの保護を提供するMIDIシーケンサシステムの耐障害性ツールについて説明します。
B.2. System Chapter V: Active Sense Command
B.2。システムの第V章：アクティブセンスコマンド
The system journal MUST contain Chapter V if an active MIDI Active Sense (0xFE) command appears in the checkpoint history. Figure B.2.1 shows the format for Chapter V.
アクティブなMIDIアクティブセンシング（0xFEの）コマンドがチェックポイント歴史に現れるなら、システムジャーナルは、第V章を含まなければなりません。図B.2.1は章V.のためのフォーマットを示し
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+
Figure B.2.1 -- System Chapter V Format
図B.2.1 - システム章Vフォーマット
The 7-bit COUNT field codes the total number of Active Sense commands (modulo 128) present in the session history. The COUNT field acts as a reference count. See the definition of "session history reference counts" in Appendix A.1 for more information.
7ビットのCOUNTフィールドコードセッション履歴中に存在する活性センスコマンド（モジュロ128）の総数。 COUNTフィールドは、参照カウントとして機能します。詳細については、付録A.1の「セッション履歴参照カウント」の定義を参照してください。
B.3. System Chapter Q: Sequencer State Commands
B.3。システム章Q：シーケンサ状態コマンド
This appendix describes Chapter Q, the system chapter for the MIDI sequencer commands.
この付録では章Q、MIDIシーケンサのコマンドのためのシステムの章を説明しています。
The system journal MUST contain Chapter Q if an active MIDI Song Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI Continue (0xFB), or MIDI Stop (0xFC) command appears in the checkpoint history and if the rules defined in this appendix require a change in the Chapter Q bitfield contents because of the command appearance.
システムジャーナルは含まれていなければならない章QアクティブMIDIソングポジションポインター（0xF2）は、MIDIクロック（0xF8）、MIDIスタート（0xFA）、MIDI続行（0xFB）、またはMIDIストップ（0xFC）コマンドがチェックポイント歴史にしている場合表示された場合この付録で定義されたルールがあるため、コマンド出現の章Qビットフィールドの内容の変更を必要としています。
Figure B.3.1 shows the variable-length format for Chapter Q.
図B.3.1章Q.ための可変長フォーマットを示します
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|N|D|C|T| TOP | CLOCK | TIMETOOLS ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.3.1 -- System Chapter Q Format
図B.3.1 - システム章Qフォーマット
Chapter Q consists of a 1-octet header followed by several optional fields, in the order shown in Figure B.3.1.
章Qは、図B.3.1に示すために、いくつかのオプションフィールド、続いて1オクテットのヘッダから成ります。
Header flag bits signal the presence of the 16-bit CLOCK field (C = 1) and the 24-bit TIMETOOLS field (T = 1). The 3-bit TOP header field is interpreted as an unsigned integer, as are CLOCK and TIMETOOLS. We describe the TIMETOOLS field in Appendix B.3.1.
ヘッダのフラグビットは、16ビット・クロック・フィールド（C = 1）と24ビットのTIMETOOLSフィールド（T = 1）の存在を知らせます。 CLOCKとTIMETOOLSあるとして3ビットのTOPヘッダフィールドは、符号なし整数として解釈されます。私たちは、付録B.3.1にTIMETOOLSフィールドについて説明します。
Chapter Q encodes the most recent state of the sequencer system. Receivers use the chapter to resynchronize the sequencer after a packet loss episode. Chapter fields encode the on/off state of the sequencer, the current position in the song, and the downbeat.
章Qシーケンサシステムの最新の状態を符号化します。レシーバは、パケット損失のエピソードの後にシーケンサーを再同期するために章を使用しています。章フィールドは、シーケンサ、曲中の現在位置、およびダウンビートのオン/オフ状態を符号化します。
The N header bit encodes the relative occurrence of the Start, Stop, and Continue commands in the session history. If an active Start or Continue command appears most recently, the N bit MUST be set to 1. If an active Stop appears most recently, or if no active Start, Stop, or Continue commands appear in the session history, the N bit MUST be set to 0.
Nヘッダビットはスタート、ストップの相対的な発生を符号化し、セッション履歴内のコマンドを続けます。アクティブ起動した場合やアクティブな停止が最近現れ、またはアクティブなスタート、ストップ、または続行コマンドは、セッション履歴に表示されない場合は、Nビットがなければならない場合、コマンドは最近、Nビットは1に設定する必要があります表示され続けます0に設定します。
The C header flag, the TOP header field, and the CLOCK field act to code the current position in the sequence:
Cヘッダフラグ、TOPヘッダフィールド、およびクロックフィールド作用は、シーケンス内の現在の位置を符号化します。
o If C = 1, the 3-bit TOP header field and the 16-bit CLOCK field are combined to form the 19-bit unsigned quantity 65536*TOP + CLOCK. This value encodes the song position in units of MIDI Clocks (24 clocks per quarter note), modulo 524288. Note that the maximum song position value that may be coded by the Song Position Pointer command is 98303 clocks (which may be coded with 17 bits) and that MIDI-coded songs are generally constructed to avoid durations longer than this value. However, the 19-bit size may be useful for real-time applications, such as a drum machine MIDI output that is sending clock commands for long periods of time.
O、C = 1の場合、3ビットのTOPヘッダフィールドと、16ビット・クロック・フィールドは19ビット符号無し量65536 * TOP + CLOCKを形成するために結合されます。この値は、歌のMIDIクロック単位での位置（4分音符あたり24のクロック）、モジュロソング・ポジション・ポインタ命令によって符号化することができる最大曲位置の値は17ビットで符号化することができる98303のクロック（あると524288.注意をコード）とMIDIコード化された曲は、一般的にこの値より長い期間を避けるように構成されています。しかし、19ビットのサイズは、長時間のクロックコマンドを送信しているドラム・マシンのMIDI出力などのリアルタイムアプリケーションに有用であり得ます。
o If C = 0, the song position is the start of the song. The C = 0 position is identical to the position coded by C = 1, TOP = 0, and CLOCK = 0, for the case where the song position is less than 524288 MIDI clocks. In certain situations (defined later in this section), normative text may require the C = 0 or the C = 1, TOP = 0, CLOCK = 0 encoding of the start of the song.
O C = 0の場合、歌の位置は、曲の始まりです。 C = 0の位置は、ソングポジション未満524288のMIDIクロックの場合のC = 1、TOP = 0、およびCLOCK = 0で符号化された位置と同一です。 （この節の後半で定義された）特定の状況では、規範的なテキストは、C = 0又はC = 1、TOP = 0、曲の開始のCLOCK = 0符号化を必要とするかもしれません。
The C, TOP, and CLOCK fields MUST be set to code the current song position, for both N = 0 and N = 1 conditions. If C = 0, the TOP field MUST be set to 0. See [MIDI] for a precise definition of a song position.
C、TOP、およびクロック・フィールドは両方ともN = 0、N = 1つの条件のために、現在の曲の位置を符号化するために設定しなければなりません。 C = 0の場合、トップフィールド曲位置の正確な定義のために0を参照[MIDI]に設定しなければなりません。
The D header bit encodes information about the downbeat and acts to qualify the song position coded by the C, TOP, and CLOCK fields.
Dヘッダービットは、ダウンビートの情報を符号化し、C、TOP、クロックフィールドで符号化曲位置を修飾するように作用します。
If the D bit is set to 1, the song position represents the most recent position in the sequence that has played. If D = 1, the next Clock command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to increment the song position by one clock and to play the updated position.
Dビットが1に設定されている場合は、ソングポジションは果たしているシーケンス内の最新の位置を表しています。 D = 1の場合、次のクロックコマンド（N = 0であれば）、1クロックで曲の位置をインクリメントすると、更新された位置を再生するように作用する（N = 1の場合）、または次のペア（、時計続行）を。
If the D bit is set to 0, the song position represents a position in the sequence that has not yet been played. If D = 0, the next Clock command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to play the point in the song coded by the song position. The song position is not incremented.
Dビットが0に設定されている場合、曲の位置がまだ再生されていない配列中の位置を表します。 D = 0の場合、次のクロックコマンド（N = 0の場合）ソング位置によって符号化された曲のポイントを再生するように作用する（N = 1の場合）又は次のペア（クロック続行）を。ソングポジションがインクリメントされていません。
An example of a stream that uses D = 0 coding is one whose most recent sequence command is a Start or Song Position Pointer command (both N = 1 conditions). However, it is also possible to construct examples where D = 0 and N = 0. A Start command immediately followed by a Stop command is coded in Chapter Q by setting C = 0, D = 0, N = 0, TOP = 0.
D = 0の符号化を使用してストリームの例は、その最新のシーケンスコマンドを起動又はソングポジションポインターコマンド（N = 1つの条件の両方）であるものです。しかし、D = 0、N = 0 Aスタート直ちに停止コマンドに続くコマンドの例を構成することも可能であるが、C = 0、D = 0、N = 0、TOP = 0を設定することによって章Qで符号化されます。
If N = 1 (coding Start or Continue), D = 0 (coding that the downbeat has yet to be played), and the song position is at the start of the song, the C = 0 song position encoding MUST be used if a Start command occurs more recently than a Continue command in the session history, and the C = 1, TOP = 0, CLOCK = 0 song position encoding MUST be used if a Continue command occurs more recently than a Start command in the session history.
N = 1（スタートコードまたは続行）場合、D = 0は（ダウンビートが再生されるように、まだ持っていることをコーディング）、及びソング位置が曲の先頭である場合、C = 0曲位置符号化を使用しなければなりません続行コマンドは、セッション履歴でStartコマンドよりも多くの最近発生した場合に起動し、コマンドは、セッション履歴にコマンドを続けてより多くの最近発生し、C = 1、TOP = 0、CLOCK = 0ソングポジションエンコーディングを使用しなければなりません。
B.3.1. Non-Compliant Sequencers
B.3.1。非準拠シーケンサ
The Chapter Q description in this appendix assumes that the sequencer system counts off time with Clock commands, as mandated in [MIDI]. However, a few non-compliant products do not use Clock commands to count off time, but instead use non-standard methods.
この付録の章Qの記述は[MIDI]に義務付けられシーケンサシステムは、クロックコマンドとの時間をオフにカウントしていることを前提としています。しかし、いくつかの非準拠の製品は、時計は時間をオフにカウントするためにコマンドを使用していないが、代わりに非標準的な方法を使用します。
Chapter Q uses the TIMETOOLS field to provide resiliency support for these non-standard products. By default, the TIMETOOLS field MUST NOT appear in Chapter Q, and the T header bit MUST be set to 0. The session configuration tools described in Appendix C.2.3 may be used to select TIMETOOLS coding.
章Qは、これらの非標準製品の弾力性のサポートを提供するために、TIMETOOLSフィールドを使用しています。デフォルトによって、TIMETOOLSフィールド章Qに現れてはいけません、そしてTヘッダビットは、付録C.2.3に記載のセッション設定ツールはコーディングTIMETOOLSを選択するために使用することができる0に設定しなければなりません。
Figure B.3.2 shows the format of the 24-bit TIMETOOLS field.
図B.3.2は、24ビットTIMETOOLSフィールドのフォーマットを示しています。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.3.2 -- TIMETOOLS Format
図B.3.2 - TIMETOOLSのフォーマット
The TIME field is a 24-bit unsigned integer quantity, with units of milliseconds. TIME codes an additive correction term for the song position coded by the TOP, CLOCK, and C fields. TIME is coded in network byte order (big-endian).
時間フィールドは、ミリ秒単位で、24ビットの符号なし整数の量です。タイムコードTOP、CLOCK、及びCフィールドで符号化された歌の位置のための添加剤補正項。 TIMEは、ネットワークバイトオーダー（ビッグエンディアン）でコード化されます。
A receiver computes the correct song position by converting TIME into units of MIDI clocks and adding it to 65536*TOP + CLOCK (assuming C = 1). Alternatively, a receiver may convert 65536*TOP + CLOCK into milliseconds (assuming C = 1) and add it to TIME. The downbeat (D header bit) semantics defined in Appendix B.3 apply to the corrected song position.
受信機は、MIDIクロックの単位に時間を変換し、* TOP + CLOCK（C = 1と仮定して）65536にそれを追加することによって、正しい曲位置を算出します。あるいは、受信機は、（C = 1を仮定する）ミリ秒に65536 *のTOP + CLOCKを変換してTIMEに追加してもよいです。付録B.3で定義されたダウンビート（Dヘッダービット）セマンティクスを補正ソング位置に適用します。
B.4. System Chapter F: MIDI Time Code Tape Position
B.4。システム章F：MIDIタイムコードテープ位置
This appendix describes Chapter F, the system chapter for the MIDI Time Code (MTC) commands. Readers may wish to review the Appendix A.1 definition of "finished/unfinished commands" before reading this appendix.
この付録では、章F、MIDIタイムコード（MTC）コマンドのためのシステムの章を説明しています。読者は、この付録を読む前に、「完成/未完成コマンド」の付録A.1定義を確認することが望まれます。
The system journal MUST contain Chapter F if an active System Common Quarter Frame command (0xF1) or an active finished System Exclusive (Universal Real Time) MTC Full Frame command (F0 7F cc 01 01 hr mn sc fr F7) appears in the checkpoint history. Otherwise, the system journal MUST NOT contain Chapter F.
システムジャーナルは、アクティブなシステム共通四半期フレームコマンド（0xF1）場合章Fを含まなければならないか、アクティブに仕上がっシステムエクスクルーシブ（ユニバーサル・リアルタイム）MTCフルフレームコマンド（F7 FR F0 7Fのcc 01 01時間のMN SCは）チェックポイント履歴に表示されます。それ以外の場合は、システムジャーナルは章F.を含めることはできません
Figure B.4.1 shows the variable-length format for Chapter F.
図B.4.1章F.ための可変長フォーマットを示します
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|P|Q|D|POINT| COMPLETE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PARTIAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+
Figure B.4.1 -- System Chapter F Format
図B.4.1 - システム章Fのフォーマット
Chapter F holds information about recent MTC tape positions coded in the session history. Receivers use Chapter F to resynchronize the MTC system after a packet loss episode.
章Fは、セッション履歴にコード化された最近のMTCテープ位置に関する情報を保持しています。レシーバは、パケット損失のエピソードの後にMTCシステムを再同期する章Fを使用しています。
Chapter F consists of a 1-octet header followed by several optional fields, in the order shown in Figure B.4.1. The C and P header bits form a Table of Contents (TOC) and signal the presence of the 32-bit COMPLETE field (C = 1) and the 32-bit PARTIAL field (P = 1).
章Fは、図B.4.1に示すために、いくつかのオプションフィールド、続いて1オクテットのヘッダから成ります。 C及びPヘッダビットは目次（TOC）を形成し、32ビットのフィールドCOMPLETE（C = 1）と32ビットの部分フィールド（P = 1）の存在を知らせます。
The Q header bit codes information about the COMPLETE field format. If Chapter F does not contain a COMPLETE field, Q MUST be set to 0.
COMPLETEフィールド形式についてQヘッダービットコード情報。章FはCOMPLETEフィールドが含まれていない場合、Qは0に設定しなければなりません。
The D header bit codes the tape movement direction. If the tape is moving forward, or if the tape direction is indeterminate, the D bit MUST be set to 0. If the tape is moving in the reverse direction, the D bit MUST be set to 1. In most cases, the ordering of commands in the session history clearly defines the tape direction. However, a few command sequences have an indeterminate direction (such as a session history consisting of one Full Frame command).
Dヘッダービットコードテープ移動方向。テープが前方に移動している、またはテープの方向が不確定である場合にテープが逆方向に移動している場合、Dビットが0に設定する必要がある場合、Dビットは、ほとんどの場合、1の順序を設定しなければなりませんセッション履歴内のコマンドは明らかに、テープの方向を定義します。しかし、いくつかのコマンド・シーケンスは、（1つのフルフレームコマンドからなるセッション履歴など）不確定な方向性を持っています。
The 3-bit POINT header field is interpreted as an unsigned integer. Appendix B.4.1 defines how the POINT field codes information about the contents of the PARTIAL field. If Chapter F does not contain a PARTIAL field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1).
3ビットポイントヘッダフィールドは符号なし整数として解釈されます。付録B.4.1はPARTIALフィールドの内容についてどのようにPOINTフィールドコード情報を定義します。章Fは、部分フィールドが含まれていない場合（D = 0の場合）または0（D = 1の場合）、POINTは7に設定しなければなりません。
Chapter F MUST include the COMPLETE field if an active finished Full Frame command appears in the checkpoint history or if an active Quarter Frame command that completes the encoding of a frame value appears in the checkpoint history.
フレーム値のエンコーディングを完了し、アクティブ・クォーターフレームコマンドがチェックポイント歴史に表示されている場合、アクティブ完成フルフレームのコマンドがチェックポイント歴史に現れる場合、または章FはCOMPLETEフィールドを含まなければなりません。
The COMPLETE field encodes the most recent active complete MTC frame value that appears in the session history. This frame value may take the form of a series of 8 active Quarter Frame commands (0xF1 0x0n through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1 0x0n for reverse tape movement) or may take the form of an active finished Full Frame command.
COMPLETEフィールドは、セッション履歴に表示される最新のアクティブな完全なMTCフレーム値を符号化します。このフレーム値は、（逆方向テープ移動用0xF1の0x0n介して前進テープ運動、0xF1 0x7n用0xF1の0x7n介して0xF1 0x0n）8つのアクティブクォーターフレーム一連のコマンドの形態をとることができる、または活性完成フルフレームコマンドの形態をとることができます。
If the COMPLETE field encodes a Quarter Frame command series, the Q header bit MUST be set to 1, and the COMPLETE field MUST have the format shown in Figure B.4.2. The 4-bit fields MT0 through MT7 code the data (lower) nibble for the Quarter Frame commands for Message Type 0 through Message Type 7 [MIDI]. These nibbles encode a complete frame value, in addition to fields reserved for future use by [MIDI].
COMPLETEフィールドが1/4フレームコマンドのシリーズをコードする場合、Qヘッダービットが1に設定しなければなりません、そしてCOMPLETEフィールドは、図B.4.2に示すようなフォーマットを持たなければなりません。 MT7コードを介して4ビットのフィールドMT0メッセージタイプ7 [MIDI]を介して、メッセージ・タイプ0クォーターフレームコマンドのデータ（下位）ニブル。これらのニブルは、[MIDI]で将来の使用のために予約フィールドに加えて、完全なフレーム値を符号化します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT0 | MT1 | MT2 | MT3 | MT4 | MT5 | MT6 | MT7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.4.2 -- COMPLETE Field Format, Q = 1
図B.4.2 - COMPLETEフィールドのフォーマット、Q = 1
In this usage, the frame value encoded in the COMPLETE field MUST be offset by 2 frames (relative to the frame value encoded in the Quarter Frame commands) if the frame value codes a 0xF1 0x0n through 0xF1 0x7n command sequence. This offset compensates for the two-frame latency of the Quarter Frame encoding for forward tape movement. No offset is applied if the frame value codes a 0xF1 0x7n through 0xF1 0x0n Quarter Frame command sequence.
この使用法では、COMPLETEフィールドに符号化されたフレームの値が0xF1 0x7nコマンドシーケンスを介してフレーム値コード0xF1 0x0n IF（クォーターフレームコマンドに符号化されたフレームの値に対して）2つのフレームによって相殺されなければなりません。これは、順方向テープ運動のためクォーターフレーム符号化の2フレームの待ち時間を補償するオフセット。 0xF1 0x0nクォーターフレームコマンドシーケンスを0xF1の0x7nフレーム値コード場合に適用されないオフセットなし。
The most recent active complete MTC frame value may alternatively be encoded by an active finished Full Frame command. In this case, the Q header bit MUST be set to 0, and the COMPLETE field MUST have the format shown in Figure B.4.3. The HR, MN, SC, and FR fields correspond to the hr, mn, sc, and fr data octets of the Full Frame command.
最新のアクティブな完全なMTCフレーム値は、代わりにアクティブ完成フルフレームコマンドによって符号化することができます。この場合、Qヘッダービットが0に設定しなければなりません、そしてCOMPLETEフィールドは、図B.4.3に示すようなフォーマットを持たなければなりません。 HR、MN、SC、およびFRフィールドは時間、MN、SC、およびフルフレームコマンドのFRデータオクテットに対応しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HR | MN | SC | FR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.4.3 -- COMPLETE Field Format, Q = 0
図B.4.3 - COMPLETEフィールドのフォーマット、Q = 0
B.4.1. Partial Frames
B.4.1。部分的なフレーム
The most recent active session history command that encodes MTC frame value data may be a Quarter Frame command other than a forward-moving 0xF1 0x7n command (which completes a frame value for forward tape movement) or a reverse-moving 0xF1 0x1n command (which completes a frame value for reverse tape movement).
MTCフレーム値データを符号化する最新のアクティブ・セッション履歴コマンドが完了した前方移動0xF1 0x7n（順方向テープ移動用のフレーム値を終了）コマンドまたは逆移動0xF1の0x1nコマンド以外のクォーターフレームコマンド（であってもよいです後進テープ運動のためのフレーム値）。
We consider this type of Quarter Frame command to be associated with a partial frame value. The Quarter Frame sequence that defines a partial frame value MUST either start at Message Type 0 and increment contiguously to an intermediate Message Type less than 7 or start at Message Type 7 and decrement contiguously to an intermediate Message type greater than 0. A Quarter Frame command sequence that does not follow this pattern is not associated with a partial frame value.
当社は四半期フレームコマンドのこのタイプは、部分的なフレーム値に関連付けられると考えています。部分フレーム値を定義クォーターフレームシーケンスは、メッセージタイプ0で開始し、中間メッセージタイプに連続7未満をインクリメントまたは0より大きい中間メッセージタイプクォーターフレームコマンドに隣接メッセージタイプ7とデクリメントで開始しなければならないのいずれかでこのパターンに従っていない配列は、部分フレーム値に関連付けられていません。
Chapter F MUST include a PARTIAL field if the most recent active command in the checkpoint history that encodes MTC frame value data is a Quarter Frame command that is associated with a partial frame value. Otherwise, Chapter F MUST NOT include a PARTIAL field.
MTCフレーム値データを符号化し、チェックポイントの歴史の中で最も最近のアクティブコマンドが部分フレーム値に関連付けられている四半期フレームコマンドであれば章FはPARTIALフィールドを含まなければなりません。それ以外の場合は、章FはPARTIAL分野を含んではいけません。
The partial frame value consists of the data (lower) nibbles of the Quarter Frame command sequence. The PARTIAL field codes the partial frame value, using the format shown in Figure B.4.2. Message Type fields that are not associated with a Quarter Frame command MUST be set to 0.
部分フレーム値がクォーターフレームコマンドシーケンスのデータ（下位）ニブルから構成されています。 PARTIALフィールドコード図B.4.2に示すフォーマットを用いて部分的フレーム値、。四半期フレームコマンドに関連付けられていないメッセージタイプフィールドは0に設定しなければなりません。
The POINT header field identifies the Message Type fields in the PARTIAL field that code valid data. If P = 1, the POINT field MUST encode the unsigned integer value formed by the lower 3 bits of the upper nibble of the data value of the most recent active Quarter Frame command in the session history. If D = 0 and P = 1, POINT MUST take on a value in the range 0-6. If D = 1 and P = 1, POINT MUST take on a value in the range 1-7.
POINTヘッダフィールドは、部分フィールドにメッセージタイプフィールドそのコードの有効なデータを識別する。 P = 1の場合、ポイントフィールドは、セッションの歴史の中で最も最近アクティブクォーターフレームコマンドのデータ値の上位ニブルの下位3ビットにより形成された符号なし整数値を符号化しなければなりません。 D = 0およびP = 1の場合、POINTは範囲0~6内の値でなければなりません。 D = 1、P = 1の場合、POINTは範囲1~7内の値でなければなりません。
If D = 0, MT fields (Figure B.4.2) in the inclusive range from 0 up to and including the POINT value encode the partial frame value. If D = 1, MT fields in the inclusive range from 7 down to and including the POINT value encode the partial frame value. Note that, unlike the COMPLETE field encoding, senders MUST NOT add a 2-frame offset to the partial frame value encoded in PARTIAL.
D = 0の場合、0からポイント値までを含む包括的な範囲のMTフィールド（図B.4.2）は、部分フレーム値を符号化します。 D = 1の場合、7からポイント値を含むダウン包含範囲内のMTフィールドは、部分フレーム値を符号化します。 COMPLETEフィールド符号化とは異なり、送信者がPARTIALで符号化部分フレーム値にオフセット2フレームを追加しないでなければならないことに注意してください。
For the default semantics, if a recovery journal contains Chapter F and if the session history codes a legal [MIDI] series of Quarter Frame and Full Frame commands, the chapter always contains a COMPLETE or a PARTIAL field (and may contain both fields). Thus, a one-octet Chapter F (C = P = 0) always codes the presence of an illegal command sequence in the session history (under some conditions, the C = 1, P
デフォルトのセマンティクスについては、回復ジャーナル章Fが含まれている場合は、セッション履歴コード場合四半期フレームとフルフレームコマンドの法定[MIDI]シリーズは、章では、常に完全または部分的なフィールドが含まれています（と両方のフィールドを含んでいてもよいです）。したがって、1オクテット章F（C = P = 0）は常にコードいくつかの条件下でセッション履歴（C = 1、Pにおける不正コマンド配列の存在
= 0 condition may also code the presence of an illegal command sequence). The illegal command sequence conditions are transient in nature and usually indicate that a Quarter Frame command sequence began with an intermediate Message Type.
= 0の条件も）不正コマンド配列の存在をコードすることができます。違法なコマンドシーケンス条件は、本質的に一過性であり、通常四半期フレームコマンド・シーケンスは、中間メッセージタイプから始まったことを示しています。
B.5. System Chapter X: System Exclusive
B.5。システム章X：システム・エクスクルーシブ
This appendix describes Chapter X, the system chapter for MIDI System Exclusive (SysEx) commands (0xF0). Readers may wish to review the Appendix A.1 definition of "finished/unfinished commands" before reading this appendix.
この付録では、章X、MIDIシステムエクスクルーシブ（システムエクスクルーシブ）コマンド（0xF0が）のためのシステムの章を説明します。読者は、この付録を読む前に、「完成/未完成コマンド」の付録A.1定義を確認することが望まれます。
Chapter X consists of a list of one or more command logs. Each log in the list codes information about a specific finished or unfinished SysEx command that appears in the session history. The system journal MUST contain Chapter X if the rules defined in Appendix B.5.2 require that one or more logs appear in the list.
章Xは、一つ以上のコマンドログのリストで構成されます。各セッションの履歴に表示される具体的な完成または未完成のSysExコマンドのリストコード情報でログインします。付録B.5.2で定義されたルールは、1つまたは複数のログがリストに表示されていることが必要な場合は、システムジャーナルは章Xを含まなければなりません。
The log list is not preceded by a header. Instead, each log implicitly encodes its own length. Given the length of the N'th list log, the presence of the (N+1)'th list log may be inferred from the LENGTH field of the system journal header (Figure 10 in Section 5 of the main text). The log list MUST obey the oldest-first ordering rule (defined in Appendix A.1).
ログリストは、ヘッダによって先行されていません。代わりに、各ログは、暗黙のうちに、独自の長さを符号化します。 N番目のリストのログの長さを考慮すると、リストのログ番目（N + 1）の存在は、「システム・ジャーナル・ヘッダ（メインテキストのセクション5において、図10）の長さフィールドから推測することができます。ログリストは、（付録A.1で定義されている）最古-最初の発注ルールに従わなければなりません。
B.5.1. Chapter Format
B.5.1。章のフォーマット
Figure B.5.1 shows the bitfield format for the Chapter X command logs.
図B.5.1章Xコマンドログのビットフィールドのフォーマットを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|T|C|F|D|L|STA| TCOUNT | COUNT | FIRST ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.5.1 -- Chapter X Command Log Format
図B.5.1 - 章Xコマンドログフォーマット
A Chapter X command log consists of a 1-octet header followed by the optional TCOUNT, COUNT, FIRST, and DATA fields.
章Xコマンドログは、まず任意TCOUNT続く1オクテットのヘッダ、COUNT、及びデータフィールドで構成されています。
The T, C, F, and D header bits act as a Table of Contents (TOC) for the log. If T is set to 1, the 1-octet TCOUNT field appears in the log. If C is set to 1, the 1-octet COUNT field appears in the log. If F is set to 1, the variable-length FIRST field appears in the log. If D is set to 1, the variable-length DATA field appears in the log.
T、C、F、およびDヘッダービットはログの目次（TOC）のテーブルとして作用します。 Tが1に設定されている場合は、1オクテットのTCOUNTフィールドがログに表示されます。 Cが1に設定されている場合は、1オクテットのCOUNTフィールドがログに表示されます。 Fが1に設定されている場合は、可変長FIRSTフィールドがログに表示されます。 Dが1に設定されている場合は、可変長のデータフィールドがログに表示されます。
The L header bit sets the coding tool for the log. We define the log coding tools in Appendix B.5.2.
Lヘッダービットは、ログ用の符号化ツールを設定します。私たちは、付録B.5.2のツールをコーディングログを定義します。
The STA field codes the status of the command coded by the log. The 2-bit STA value is interpreted as an unsigned integer. If STA is 0, the log codes an unfinished command. Non-zero STA values code different classes of finished commands. An STA value of 1 codes a cancelled command, an STA value of 2 codes a command that uses the "dropped 0xF7" construction, and an STA value of 3 codes all other finished commands. Section 3.2 in the main text describes cancelled and "dropped 0xF7" commands.
STAフィールドコードログで符号化されたコマンドのステータス。 2ビットのSTA値は符号なし整数として解釈されます。 STAは0、ログコード未完成のコマンドである場合。非ゼロSTAは、完成したコマンドのコードの異なるクラスの値。 1つの符号キャンセルコマンドのSTA値、2つのコード建設「0xF7を落とし」、及び3つのコードの他のすべての完成したコマンドのSTA値を使用するコマンドのSTA値。本文中のセクション3.2はキャンセルとコマンド「0xF7を落とした」について説明します。
The S bit (Appendix A.1) of the first log in the list acts as the S bit for Chapter X. For the other logs in the list, the S bit refers to the log itself. The value of the "phantom" S bit associated with the first log is defined by the following rules:
リスト内の最初のログのSビット（付録A.1）は、リスト内の他のログについて章XのSビットとして作用し、Sビットは自身ログを指します。最初のログに関連付けられた「ファントム」Sビットの値は、次の規則によって定義されます。
o If the list codes one log, the phantom S-bit value is the same as the Chapter X S-bit value.
リストコードのログ場合、O、ファントムSビットの値は、章X Sビットの値と同じです。
o If the list codes multiple logs, the phantom S-bit value is the logical OR of the S-bit value of the first and second command logs in the list.
リストコード複数のログ場合、O、ファントムSビットの値は、論理ORリストにおける第1および第2のコマンドログのSビットの値です。
In all other respects, the S bit follows the semantics defined in Appendix A.1.
他のすべての点では、Sビットは、付録A.1で定義された意味論に従います。
The FIRST field (present if F = 1) encodes a variable-length unsigned integer value that sets the coverage of the DATA field.
（F = 1であれば本）最初のフィールドは、データフィールドの有効範囲を設定する可変長符号なし整数値を符号化します。
The FIRST field (present if F = 1) encodes a variable-length unsigned integer value that specifies which SysEx data bytes are encoded in the DATA field of the log. The FIRST field consists of an octet whose most significant bit is set to 0, optionally preceded by one or more octets whose most significant bit is set to 1. The algorithm shown in Figure B.5.2 decodes this format into an unsigned integer to yield the value dec(FIRST). FIRST uses a variable-length encoding because dec(FIRST) references a data octet in a SysEx command, and a SysEx command may contain an arbitrary number of data octets.
最初のフィールド（現在F = 1の場合）のデータバイトがログのデータフィールドに符号化されたシステムエクスクルーシブ指定可変長符号なし整数値を符号化します。最初のフィールドは、その最上位ビットが0に設定され、必要に応じて、その最上位ビットを1に設定されている図B.5.2に示すアルゴリズムを生成する符号なし整数にこのフォーマットをデコードする一つまたはそれ以上のオクテットが先行オクテットで構成されてい値12月（FIRST）。 DECは（FIRST）システムエクスクルーシブコマンドでデータオクテットを参照し、システムエクスクルーシブコマンドがデータオクテットの任意の数を含んでいてもよいため、最初は、可変長符号化を使用します。
One-Octet FIRST value:
1オクテットFIRST値：
Encoded form: 0ddddddd Decoded form: 00000000 00000000 00000000 0ddddddd
エンコード形式：00000000 00000000 00000000 0ddddddd：デコードフォームを0ddddddd
Two-Octet FIRST value:
2オクテットFIRST値：
Encoded form: 1ccccccc 0ddddddd Decoded form: 00000000 00000000 00cccccc cddddddd
エンコード形式：00000000 00000000 00cccccc cddddddd：1cccccccは、復号されたフォームを0ddddddd
Three-Octet FIRST value:
三オクテットFIRST値：
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 00000000 000bbbbb bbcccccc cddddddd
エンコード形式：1bbbbbbb 1ccccccc 0dddddddデコード形式：00000000 000bbbbb bbccccccのcddddddd
Four-Octet FIRST value:
4オクテットFIRST値：
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
エンコード形式：1aaaaaaa 1bbbbbbb 1ccccccc 0dddddddデコード形式：0000aaaa aaabbbbb bbcccccc cddddddd
Figure B.5.2 -- Decoding FIRST Field Formats
図B.5.2 - デコード最初のフィールドのフォーマット
The DATA field (present if D = 1) encodes a modified version of the data octets of the SysEx command coded by the log. Status octets MUST NOT be coded in the DATA field.
データフィールドは、（D = 1が存在する場合）、ログによってコードシステムエクスクルーシブコマンドのデータオクテットの改変バージョンをコードします。ステータスオクテットがデータフィールドにコード化されてはなりません。
If F = 0, the DATA field begins with the first data octet of the SysEx command and includes all subsequent data octets for the command that appear in the session history. If F = 1, the DATA field begins with the (dec(FIRST) + 1)'th data octet of the SysEx command and includes all subsequent data octets for the command that appear in the session history. Note that the word "command" in the descriptions above refers to the original SysEx command as it appears in the source MIDI data stream, not to a particular MIDI list SysEx command segment.
F = 0の場合、データフィールドはのSysExコマンドの最初のデータオクテットで始まり、セッション履歴に表示されるコマンドのすべての後続のデータオクテットを含んでいます。 F = 1の場合、データフィールドはシステムエクスクルーシブコマンドのデータオクテット目（12月（FIRST）+ 1） 'で始まり、セッション履歴に表示されるコマンドのすべての後続のデータオクテットを含んでいます。そうでない特定のMIDIリストのSysExコマンドセグメントに、ソースMIDIデータ・ストリームに表示される説明で単語「コマンド」は、上記オリジナルのSysExコマンドをいいます。
The length of the DATA field is coded implicitly, using the most significant bit of each octet. The most significant bit of the final octet of the DATA field MUST be set to 1. The most significant bit of all other DATA octets MUST be set to 0. This coding method relies on the fact that the most significant bit of a MIDI data octet is 0 by definition. Apart from this length-coding modification, the DATA field encodes a verbatim copy of all data octets it encodes.
データフィールドの長さは、各オクテットの最上位ビットを使用して、暗黙的に符号化されます。データフィールドの最終オクテットの最上位ビットは、他のすべてのデータのオクテットの最上位ビットは、この符号化方式は、MIDIデータのオクテットの最上位ビット事実に依存する0に設定しなければならなく1に設定しなければなりません。定義によって0です。これとは別に、長さコーディング修正から、DATAフィールドは、それがコードするすべてのデータのオクテットの逐語的なコピーをコードしています。
B.5.2. Log Inclusion Semantics
B.5.2。インクルージョンのセマンティクスをログに記録
Chapter X offers two tools to protect SysEx commands: the "recency" tool and the "list" tool. The tool definitions use the concept of the "SysEx type" of a command, which we now define.
「新しさ」ツールと「リスト」ツール：章XはのSysExコマンドを保護するために2つのツールを提供しています。ツールの定義は、私たちが今定義するコマンド、の「システムエクスクルーシブタイプ」の概念を使用します。
Each SysEx command instance in a session, excepting MTC Full Frame commands, is said to have a "SysEx type". Types are used in equality comparisons: two SysEx commands in a session are said to have "the same SysEx type" or "different SysEx types".
セッション内の各のSysExコマンドインスタンスは、MTCフルフレームのコマンドを除いて、「システムエクスクルーシブタイプ」を持っていると言われています。タイプは等価比較に使用されます。セッション中2つのSysExコマンドは「同じのSysExタイプ」または「異なるのSysExタイプ」を持っていると言われています。
If efficiency is not a concern, a sender may follow a simple typing rule: every SysEx command in the session history has a different SysEx type, and thus no two commands in the session have the same type.
効率が懸念されていない場合、送信者は、簡単なタイピングの規則に従うことができる：セッション履歴内のすべてのSysExコマンドが異なるのSysExタイプを持っているので、セッションには2つのコマンドは同じ型を持っていません。
To improve efficiency, senders MAY implement exceptions to this rule. These exceptions declare that certain sets of SysEx command instances have the same SysEx type. Any command not covered by an exception follows the simple rule. We list exceptions below:
効率を向上させるために、送信者は、この規則の例外を実施することができます。これらの例外はのSysExコマンドインスタンスの特定のセットが同じのSysExタイプを持っていることを宣言します。例外によってカバーされていない任意のコマンドは、単純なルールに従います。私たちは、以下の例外を一覧表示します：
o All commands with identical data octet fields (same number of data octets, same value for each data octet) have the same type. This rule MUST be applied to all SysEx commands in the session or not at all. Note that the implementation of this exception requires no sender knowledge of the format and semantics of the SysEx commands in the stream, merely the ability to count and compare octets.
O同一のデータオクテットフィールド（データオクテットの同じ数、各データオクテットと同じ値）を持つすべてのコマンドは、同じタイプを有します。この規則は、セッション内のすべてのSysExコマンドに適用されるか、全くされなければなりません。この例外の実装は、ストリーム内のSysExコマンドの形式と意味のない送信者の知識、オクテットをカウントし、比較するだけで能力を必要としないことに注意してください。
o Two instances of the same command whose semantics set or report the value of the same "parameter" have the same type. The implementation of this exception requires specific knowledge of the format and semantics of SysEx commands. In practice, a sender implementation chooses to support this exception for certain classes of commands (such as the Universal System Exclusive commands defined in [MIDI]). If a sender supports this exception for a particular command in a class (for example, the Universal Real Time System Exclusive message for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [MIDI]), it MUST support the exception to all instances of this particular command in the session.
セマンティクス設定または同じ「パラメータ」の値を報告し、同じコマンドの2つのインスタンスO同じ型を持っています。この例外の実装は、システムエクスクルーシブコマンドの形式と意味論の具体的な知識が必要です。実際には、送信側の実装は、（[MIDI]で定義されたユニバーサル・システム・エクスクルーシブ・コマンドのような）コマンドの特定のクラスに対してこの例外をサポートすることを選択しました。送信者は、クラス内の特定のコマンド（例えば、マスターボリュームのためのユニバーサル・リアルタイム・システム・エクスクルーシブメッセージ、F0 F7のCC 04 01 VV VV F7、[MIDI]で定義された）のためにこの例外をサポートしている場合、それは例外をサポートしなければなりませんセッション中にこの特定のコマンドのすべてのインスタンス。
We now use this definition of "SysEx type" to define the "recency" tool and the "list" tool for Chapter X.
現在章X用の「新しさ」ツールと「リスト」ツールを定義するには、「システムエクスクルーシブタイプ」のこの定義を使用します
By default, the Chapter X log list MUST code sufficient information to protect the rendered MIDI performance from indefinite artifacts caused by the loss of all finished or unfinished active SysEx commands that appear in the checkpoint history (excluding finished MTC Full Frame commands, which are coded in Chapter F (Appendix B.4)).
デフォルトでは、章Xログリストは、（符号化され、完成MTCフルフレームのコマンドを除くチェックポイント履歴に表示されるすべての完成または未完成のアクティブのSysExコマンドの損失による無期限のアーティファクトからレンダリングされたMIDIのパフォーマンスを保護するために十分な情報をコード化しなければなりません章F中（付録B.4））。
To protect a command of a specific SysEx type with the recency tool, senders MUST code a log in the log list for the most recent finished active instance of the SysEx type that appears in the checkpoint history. Additionally, if an unfinished active instance of the SysEx type appears in the checkpoint history, senders MUST code a log in the log list for the unfinished command instance. The L header bit of both command logs MUST be set to 0.
最新性ツールを使用して、特定のSysExタイプのコマンドを保護するために、送信者は、チェックポイントの履歴に表示されたSysExタイプの最も最近の完成アクティブなインスタンスのログリスト内のログをコーディングする必要があります。 SysExタイプの未完成のアクティブなインスタンスがチェックポイント歴史に表示された場合また、送信者は、未完成のコマンドインスタンスのログリスト内のログをコーディングする必要があります。両方のコマンドログのLヘッダービットが0に設定しなければなりません。
To protect a command of a specific SysEx type with the list tool, senders MUST code a log in the Chapter X log list for each finished or unfinished active instance of the SysEx type that appears in the checkpoint history. The L header bit of list tool command logs MUST be set to 1.
リストツールを使用して、特定のSysExタイプのコマンドを保護するために、送信者は、チェックポイントの履歴に表示されたSysExタイプの各完成または未完成のアクティブなインスタンスの章Xログリスト内のログをコーディングする必要があります。リストツールコマンドログのLヘッダービットが1に設定しなければなりません。
As a rule, a log REQUIRED by the list or recency tool MUST include a DATA field that codes all data octets that appear in the checkpoint history for the SysEx command instance associated with the log. The FIRST field MAY be used to configure a DATA field that minimally meets this requirement.
原則として、リストまたは新しツールによって必要なログは、ログに関連付けられているのSysExコマンドインスタンスのためのチェックポイント歴史に現れるコードのすべてのデータのオクテットそのデータフィールドを含まなければなりません。最初のフィールドは最低限、この要件を満たしているDATAフィールドを設定するために使用されるかもしれません。
An exception to this rule applies to cancelled commands (defined in Section 3.2). REQUIRED command logs associated with cancelled commands MAY be coded with no DATA field. However, if DATA appears in the log, DATA MUST code all data octets that appear in the checkpoint history for the command associated with the log.
この規則の例外は、キャンセルコマンド（3.2節で定義される）に適用されます。キャンセルコマンドに関連付けられている必要なコマンドログは無DATAフィールドを符号化することができます。データがログに記録された場合は、データをログに関連付けられているコマンドのチェックポイント履歴に表示されるすべてのデータオクテットをコード化しなければなりません。
As defined by the preceding text in this section, by default all finished or unfinished active SysEx commands that appear in the checkpoint history (excluding finished MTC Full Frame commands) MUST be protected by the list tool or the recency tool.
このセクションの前のテキストで定義されているように、デフォルトでは（完成MTCフルフレームのコマンドを除く）チェックポイント歴史に現れるすべての完成または未完成のアクティブのSysExコマンドは、リストツールまたは最新性ツールによって保護しなければなりません。
For some MIDI source streams, this default yields a Chapter X whose size is too large. For example, imagine that a sender begins to transcode a SysEx command with 10,000 data octets onto a UDP RTP stream "on the fly", by sending SysEx command segments as soon as data octets are delivered by the MIDI source. After 1000 octets have been sent, the expansion of Chapter X yields an RTP packet that is too large to fit in the Maximum Transmission Unit (MTU) for the stream.
いくつかのMIDIソースストリームの場合、このデフォルトでは、サイズが大きすぎる章Xを生成します。例えば、送信者は、すぐにデータオクテットは、MIDIソースによって提供されているとしてのSysExコマンドセグメントを送信することにより、「オンザフライ」UDP RTPストリームに万個のデータオクテットとのSysExコマンドをトランスコードし始めていることを想像してみてください。 1000個のオクテットが送信された後、章Xの拡張は、ストリームの最大伝送ユニット（MTU）に収まる大きすぎるRTPパケットを生成します。
In this situation, if a sender uses the closed-loop sending policy for SysEx commands, the RTP packet size may always be capped by stalling the stream. In a stream stall, once the packet reaches a maximum size, the sender refrains from sending new packets with non-empty MIDI Command Sections until receiver feedback permits the trimming of Chapter X. If the stream permits arbitrary commands to appear between SysEx segments (selectable during configuration using the tools defined in Appendix C.1), the sender may stall the SysEx segment stream but continue to code other commands in the MIDI list.
送信者がシステムエクスクルーシブコマンドの閉ループ送信ポリシーを使用する場合は、このような状況では、RTPパケットのサイズは常にストリームをストールでキャップすることができます。ストリームストールに、ストリームは、システムエクスクルーシブセグメント間に表示される任意のコマンドを許可する場合、受信機フィードバック章Xのトリミングを可能にするまで、パケットは、空でないMIDIコマンドセクションと新しいパケットを送信することから、送信者控えるを最大サイズに到達すると（選択付録C.1で定義されているツール）を使用して、コンフィギュレーション時に、送信者は、システムエクスクルーシブの分割ストリームを失速が、MIDIリストに他のコマンドをコーディングし続けることができます。
Stalls are a workable but suboptimal solution to Chapter X size issues. As an alternative to stalls, senders SHOULD take preemptive action during session configuration to reduce the anticipated size of Chapter X, using the methods described below:
ストールは、章Xサイズの問題に実行可能しかし、次善の解決策です。屋台の代替として、送信者は、以下に記載する方法を用いて、章Xの予想サイズを小さくするために、セッションの設定時に先制行動を取る必要があります。
o Partitioned transport. Appendix C.5 provides tools for sending a MIDI name space over several RTP streams. Senders may use these tools to map a MIDI source into a low-latency UDP RTP stream (for channel commands and short SysEx commands) and a reliable [RFC4571] TCP stream (for bulk-data SysEx commands). The cm_unused and cm_used parameters (Appendix C.1) may be used to communicate the nature of the SysEx command partition. As TCP is reliable, the RTP MIDI TCP stream would not use the recovery journal. To minimize transmission latency for short SysEx commands, senders may begin segmental transmission for all SysEx commands over the UDP stream and then cancel the UDP transmission of long commands (using tools described in Section 3.2) and resend the commands over the TCP stream.
O輸送を分配しました。付録C.5は、いくつかのRTPストリーム上のMIDI名前空間を送信するためのツールを提供します。送信者は、（チャネルコマンドと短いシステムエクスクルーシブコマンド用）低レイテンシUDP RTPストリームおよび信頼[RFC4571]（バルクデータのSysExコマンドの）TCPストリームにMIDIソースをマッピングするためにこれらのツールを使用してもよいです。 cm_unusedとcm_usedパラメータ（付録C.1）は、システムエクスクルーシブコマンドパーティションの性質を伝えるために使用されてもよいです。 TCPは信頼性があるとして、RTP MIDI TCPストリームは回復ジャーナルを使用することはありません。短いのSysExコマンドの送信待ち時間を最小限に抑えるために、送信者はUDPストリーム上のすべてのSysExコマンドの分節送信を開始してから（3.2節で説明するツールを使用して）長いコマンドのUDP送信をキャンセルし、TCPストリーム上でコマンドを再送信することができます。
o Selective protection. Journal protection may not be necessary for all SysEx commands in a stream. The ch_never parameter (Appendix C.2) may be used to communicate which SysEx commands are excluded from Chapter X.
O選択的保護。ジャーナル保護は、ストリーム内のすべてのシステムエクスクルーシブコマンドのために必要ではないかもしれません。 ch_neverパラメータ（付録C.2）は、章Xから除外されたシステムエクスクルーシブコマンド通信するために使用することができます
B.5.3. TCOUNT and COUNT Fields
B.5.3。 TCOUNTとCOUNTフィールド
If the T header bit is set to 1, the 8-bit TCOUNT field appears in the command log. If the C header bit is set to 1, the 8-bit COUNT field appears in the command log. TCOUNT and COUNT are interpreted as unsigned integers.
Tヘッダービットが1に設定されている場合、8ビットのTCOUNTフィールドは、コマンドログに表示されます。 Cヘッダビットが1に設定されている場合、8ビット・カウント・フィールドは、コマンドログに表示されます。 TCOUNTとCOUNTは、符号なし整数として解釈されています。
The TCOUNT field codes the total number of SysEx commands of the SysEx type coded by the log that appear in the session history at the moment after the (finished or unfinished) command coded by the log enters the session history.
TCOUNTフィールドコードログによってコード化された（完成または未完成）コマンドは、セッション履歴に入った後、現時点でセッション履歴に表示されるログで符号化されたシステムエクスクルーシブのタイプのシステムエクスクルーシブコマンドの総数。
The COUNT field codes the total number of SysEx commands that appear in the session history, excluding commands that are excluded from Chapter X via the ch_never parameter (Appendix C.2) at the moment after the (finished or unfinished) command coded by the log enters the session history.
COUNTフィールドコードログで符号化された（完成または未完成）コマンドの後の時点でch_neverパラメータ（付録C.2）を介し章Xから除外されたコマンドを除くセッション履歴に表示されたSysExコマンドの総数を、セッション履歴に入ります。
Command counting for TCOUNT and COUNT uses modulo-256 arithmetic. MTC Full Frame command instances (Appendix B.4) are included in command counting if the TCOUNT and COUNT definitions warrant their inclusion, as are cancelled commands (Section 3.2).
TCOUNTとCOUNTのために数えるコマンドは、モジュロ256演算を使用しています。 TCOUNTとCOUNT定義が取り消されたコマンド（3.2節）であるとして、その含有を保証する場合はMTCフルフレームコマンドインスタンス（付録B.4）を数えるコマンドに含まれています。
Senders use the TCOUNT and COUNT fields to track the identity and (for TCOUNT) the sequence position of a command instance. Senders MUST use the TCOUNT or COUNT fields if identity or sequence information is necessary to protect the command type coded by the log.
送信者は、ID及びコマンドインスタンスの配列位置（TCOUNTため）を追跡するためにTCOUNTとCOUNTフィールドを使用します。同一性または配列情報がログによってコード化されたコマンドの種類を保護するために必要であれば送信者はTCOUNTまたはCOUNTフィールドを使用しなければなりません。
If a sender uses the COUNT field in a session, the final command log in every Chapter X in the stream MUST code the COUNT field. This rule lets receivers resynchronize the COUNT value after a packet loss.
送信者がセッションにCOUNTフィールドを使用している場合は、ストリーム内のすべての章Xの最後のコマンドログはCOUNTフィールドをコーディングする必要があります。このルールは、受信機がパケット損失の後COUNT値を再同期することができます。
Appendix C. Session Configuration Tools
付録C.セッション設定ツール
In Sections 6.1 and 6.2 of the main text, we show session descriptions for minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack the flexibility to support some applications. In this appendix, we describe how to customize stream behavior through the use of the payload format parameters.
セクション6.1および本文の6.2では、我々は最小限のネイティブとmpeg4-ジェネリックRTP MIDIストリームのセッション記述を示しています。最小限のストリームは、いくつかのアプリケーションをサポートするための柔軟性を欠いています。この付録では、我々は、ペイロードフォーマットパラメータを使用してストリームの動作をカスタマイズする方法について説明します。
The appendix begins with 6 sections, each devoted to parameters that affect a particular aspect of stream behavior:
付録6つのセクション、ストリーム動作の特定の態様に影響を与えるパラメータにそれぞれ専念することから始まります。
o Appendix C.1 describes the stream subsetting system (cm_unused and cm_used).
O付録C.1は、ストリームのサブセット化システム（cm_unusedとcm_used）について説明します。
o Appendix C.2 describes the journalling system (ch_anchor, ch_default, ch_never, j_sec, j_update).
O付録C.2は、ジャーナリングシステム（ch_anchor、ch_default、ch_never、j_秒、j_アップデート）について説明します。
o Appendix C.3 describes MIDI command timestamp semantics (linerate, mperiod, octpos, tsmode).
O付録C.3は、MIDIコマンドのタイムスタンプの意味（回線レート、mperiod、octpos、tsmode）について説明します。
o Appendix C.4 describes the temporal duration ("media time") of an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime).
O付録C.4はRTP MIDIパケット（guardtime、rtp_maxptime、rtp_ptime）の持続時間（ "メディア時間"）を記述する。
o Appendix C.5 concerns stream description (musicport).
O付録C.5は、ストリーム記述（musicportを）に関するものです。
o Appendix C.6 describes MIDI rendering (chanmask, cid, inline, multimode, render, rinit, subrender, smf_cid, smf_info, smf_inline, smf_url, url).
O付録C.6は、MIDIのレンダリング（chanmask、CID、インライン、マルチモード、レンダリング、RINIT、サブレンダラー、smf_cid、smf_info、smf_inline、smf_url、URL）を記述する。
The parameters listed above may optionally appear in session descriptions of RTP MIDI streams. If these parameters are used in an SDP session description, the parameters appear on an fmtp attribute line. This attribute line applies to the payload type associated with the fmtp line.
上記のパラメータは、必要に応じてRTP MIDIストリームのセッション記述に表示されてもよいです。これらのパラメータはSDPセッション記述に使用されている場合は、パラメータはのfmtp属性ラインに表示されます。この属性ラインはのfmtpラインに関連付けられたペイロードタイプに適用されます。
The parameters listed above add extra functionality ("features") to minimal RTP MIDI streams. In Appendix C.7, we show how to use these features to support two classes of applications: content streaming using RTSP (Appendix C.7.1) and network musical performance using SIP (Appendix C.7.2).
上記のパラメータは、最小限のRTP MIDIストリームに特別な機能（「機能」）を追加します。 RTSPを使用してコンテンツのストリーミング（付録C.7.1）とSIP（付録C.7.2）を使用して演奏をネットワーク：付録C.7では、我々は、アプリケーションの2つのクラスをサポートするために、これらの機能を使用する方法を示しています。
The participants in a multimedia session MUST share a common view of all of the RTP MIDI streams that appear in an RTP session, as defined by a single media (m=) line. In some RTP MIDI applications, the "common view" restriction makes it difficult to use sendrecv streams (all parties send and receive), as each party has its own requirements. For example, a two-party network musical performance application may wish to customize the renderer on each host to match the CPU performance of the host [NMP].
マルチメディアセッションの参加者は、単一のメディア（M =）ラインによって定義されるように、RTPセッションで表示されるRTP MIDIストリームの全ての共通ビューを共有しなければなりません。いくつかのRTP MIDIアプリケーションでは、「共通ビュー」の制限は、各当事者は、独自の要件を持っているとして、それが難しい、（すべての当事者が送信および受信）のsendrecvストリームを使用することができます。例えば、二者のネットワーク音楽パフォーマンス・アプリケーションは、ホスト[NMP]のCPU性能と一致するように、各ホスト上でレンダリングをカスタマイズすることを望むかもしれません。
We solve this problem by using two RTP MIDI streams -- one sendonly, one recvonly -- in lieu of one sendrecv stream. The data flows in the two streams travel in opposite directions to control receivers configured to use different renderers. In the third example in Appendix C.5, we show how the musicport parameter may be used to define virtual sendrecv streams.
sendonlyの1、1がrecvonly - - 1つのsendrecvストリームの代わりにを我々は2つのRTP MIDIストリームを使用することによって、この問題を解決します。二つのストリーム内のデータフローは、異なるレンダラを使用するように構成された受信機を制御するために、反対方向に移動します。付録C.5における第3の例では、我々はmusicportパラメータは、仮想のsendrecvストリームを定義するために使用することができる方法を示します。
As a general rule, the RTP MIDI protocol does not handle parameter changes during a session well because the parameters describe heavyweight or stateful configuration that is not easily changed once a session has begun. Thus, parties SHOULD NOT expect that parameter change requests during a session will be accepted by other parties. However, implementors SHOULD support in-session parameter changes that are easy to handle (for example, the guardtime parameter defined in Appendix C.4) and SHOULD be capable of accepting requests for changes of those parameters, as received by its session management protocol (for example, re-offers in SIP [RFC3264]).
パラメータが簡単に一度に変更されていないセッションが始まったヘビー級またはステートフル設定を記述するための一般的なルールとして、RTP MIDIプロトコルはよくセッション中にパラメータの変更を処理しません。したがって、当事者は、セッション中のパラメータ変更要求が他の当事者によって受け入れられることを期待すべきではありません。しかし（、実装者は、取り扱いが容易であるにセッションパラメータの変更をサポートするべきである（例えば、guardtimeパラメータは、付録C.4で定義されている）、そのセッション管理プロトコルによって受信されるように、これらのパラメータの変更の要求を受け入れることができなければなりません例えば、SIPに再オファー[RFC3264]）。
Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC5234]) syntax for the payload parameters. Section 11 provides information to the Internet Assigned Numbers Authority (IANA) on the media types and parameters defined in this document.
付録Dは、ペイロードパラメータの増補バッカス - ナウアフォーム（ABNF、[RFC5234]）構文を定義します。セクション11は、この文書で定義されたメディアタイプとパラメータのインターネット割り当て番号機関（IANA）に情報を提供します。
Appendix C.6.5 defines the media type audio/asc, a stored object for initializing mpeg4-generic renderers. As described in Appendix C.6, the audio/asc media type is assigned to the rinit parameter to specify an initialization data object for the default mpeg4-generic renderer. Note that RTP stream semantics are not defined for audio/asc. Therefore, the asc subtype MUST NOT appear on the rtpmap line of a session description.
付録C.6.5は、メディアタイプオーディオ/ ASC、MPEG4-ジェネリックレンダラーを初期化するための格納されたオブジェクトを定義します。付録C.6で説明したように、オーディオ/ ascのメディアタイプはデフォルトmpeg4-ジェネリックレンダラーの初期化データオブジェクトを指定するには、RINITパラメータに割り当てられます。 RTPストリームのセマンティクスは、オーディオ/ ascのために定義されていないことに注意してください。したがって、ASCサブタイプは、セッション記述のrtpmap行に表示されてはなりません。
C.1. Configuration Tools: Stream Subsetting
C.1。コンフィギュレーションツール：ストリームのサブセット
As defined in Section 3.2 in the main text, the MIDI list of an RTP MIDI packet may encode any MIDI command that may legally appear on a MIDI 1.0 DIN cable.
本文中のセクション3.2で定義されているように、RTP MIDIパケットのMIDIリストは、法的にMIDI 1.0 DINケーブルに表示されることがあります任意のMIDIコマンドをコードすることができます。
In this appendix, we define two parameters (cm_unused and cm_used) that modify this default condition by excluding certain types of MIDI commands from the MIDI list of all packets in a stream. For example, if a multimedia session partitions a MIDI name space into two RTP MIDI streams, the parameters may be used to define which commands appear in each stream.
この付録では、我々は、それが特定のMIDIの種類のストリーム内のすべてのパケットのMIDIリストからコマンドを除外することで、このデフォルト条件を変更する（cm_unusedとcm_used）2つのパラメータを定義します。例えば、二つのRTP MIDIストリームにマルチメディアセッションパーティションMIDI名前空間場合は、パラメータは、各ストリームに表示されるコマンドを定義するために使用することができます。
In this appendix, we define a simple language for specifying MIDI command types. If a command type is assigned to cm_unused, the commands coded by the string MUST NOT appear in the MIDI list. If a command type is assigned to cm_used, the commands coded by the string MAY appear in the MIDI list.
この付録では、我々は、MIDIコマンドタイプを指定するためのシンプルな言語を定義します。コマンドタイプがcm_unusedに割り当てられている場合は、文字列で符号化されたコマンドはMIDIリストに現れてはいけません。コマンドタイプがcm_usedに割り当てられている場合は、文字列で符号化されたコマンドはMIDIリストに表示されることがあります。
The parameter list may code multiple assignments to cm_used and cm_unused. Assignments have a cumulative effect and are applied in the order of appearance in the parameter list. A later assignment of a command type to the same parameter expands the scope of the earlier assignment. A later assignment of a command type to the opposite parameter cancels (partially or completely) the effect of an earlier assignment.
パラメータリストはcm_usedする複数の割り当てをコーディングしてcm_unusedことがあります。割り当ては、累積効果を持ち、パラメータリスト内の出現順に適用されます。同じパラメータへのコマンドタイプの後の割り当ては、以前の割り当ての範囲を拡大します。反対パラメータへのコマンドタイプの後割当は、（部分的にまたは完全に）以前の割り当ての効果を打ち消します。
To initialize the stream subsetting system, "implicit" assignments to cm_unused and cm_used are processed before processing the actual assignments that appear in the parameter list. The System Common undefined commands (0xF4, 0xF5) and the System Real-Time Undefined commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All other command types are implicitly assigned to cm_used.
ストリームのサブセット化システムを初期化するには、「暗黙の」割り当てがcm_unusedとcm_usedするパラメータリストに表示される実際の割り当てを処理する前に処理されます。 cm_unusedにシステム共通未定義のコマンド（0xF4、0xF5）とシステムリアルタイム未定義のコマンド（0xF9、0xFDでは）暗黙的に割り当てられています。他のすべてのコマンドタイプは、暗黙的にcm_usedするために割り当てられています。
Note that the implicit assignments code the default behavior of an RTP MIDI stream as defined in Section 3.2 in the main text (namely, that all commands that may legally appear on a MIDI 1.0 DIN cable may appear in the stream). Also, note that assignments of the System Common undefined commands (0xF4, 0xF5) apply to the use of these commands in the MIDI source command stream, not the special use of 0xF4 and 0xF5 in SysEx segment encoding defined in Section 3.2 in the main text.
暗黙の代入コードメインテキストで、セクション3.2で定義されたRTP MIDIストリームのデフォルトの動作は、（つまり、法的にMIDI 1.0 DINケーブルに表示されることがあり、すべてのコマンドがストリームに表示されることが）あることに注意してください。また、システム共通の割り当てはコマンド（0xF4、0xF5）MIDIソースコマンドストリームではなく、本文中に3.2節で定義されたシステムエクスクルーシブセグメントのエンコーディングで0xF4と0xF5の特別な使用におけるこれらのコマンドの使用に適用さを未定義ことに注意してください。
As a rule, parameter assignments obey the following syntax (see Appendix D for ABNF):
原則として、パラメータの割り当ては（ABNFのための付録Dを参照）、次の構文に従います。
<parameter> = [channel list]<command-type list>[field list]
<パラメータ> = [チャンネルリスト] <コマンドタイプのリスト> [フィールドリスト]
The command-type list is mandatory; the channel and field lists are optional.
コマンド型リストは必須です。チャネルとフィールドのリストはオプションです。
The command-type list specifies the MIDI command types for which the parameter applies. The command-type list is a concatenated sequence of one or more of the letters (ABCFGHJKMNPQTVWXYZ). The letters code the following command types:
コマンドタイプのリストは、パラメータが適用されるMIDIコマンドの種類を指定します。コマンドタイプのリストは、文字（ABCFGHJKMNPQTVWXYZ）のうちの1つまたは複数の連結された配列です。手紙には、次のコマンドの種類をコーディング：
o A: Poly Aftertouch (0xA) o B: System Reset (0xFF) o C: Control Change (0xB) o F: System Time Code (0xF1) o G: System Tune Request (0xF6) o H: System Song Select (0xF3) o J: System Common Undefined (0xF4) o K: System Common Undefined (0xF5) o N: NoteOff (0x8), NoteOn (0x9) o P: Program Change (0xC) o Q: System Sequencer (0xF2, 0xF8, 0xFA, 0xFB, 0xFC) o T: Channel Aftertouch (0xD) o V: System Active Sense (0xFE) o W: Pitch Wheel (0xE) o X: SysEx (0xF0, 0xF7) o Y: System Real-Time Undefined (0xF9) o Z: System Real-Time Undefined (0xFD)
B Oポリアフタータッチ（0xAが）：システム・リセット（0xFFで）C（O）システムソング・セレクト（0xF3：H Oシステムチューニング要求（0xF6）：コントロールチェンジ（0xB）O F：システムタイムコード（0xF1）O G、O ）J（O）システムの一般的な不定（0xF4）O K：システム共通不定（0xF5）N O：NoteOff（0x8という）、NoteOn（0x9）P O：プログラムチェンジ（から0xC）OのQ：システムシーケンサー（0xF2、0xF8、0xFA 、0xFB、0xFC）O T：V Oチャンネル・アフタータッチ（0xDの）：W Oシステムアクティブセンス（0xFEの）：ピッチホイール（から0xE）O X：システムリアルタイム未定義（0xF9）：Y OのSysEx（0xF0が、0xF7） O Z：システムリアルタイム未定義（0xFDで）
In addition to the letters above, the letter M may also appear in the command-type list. The letter M refers to the MIDI parameter system (see definition in Appendix A.1 and in [MIDI]). An assignment of M to cm_unused codes that no RPN or NRPN transactions may appear in the MIDI list.
上記の手紙に加えて、文字Mは、コマンドタイプのリストに表示されることがあります。文字Mは、（付録A.1および[MIDI]で定義を参照）MIDIパラメータシステムを指します。 Mの割り当てにはRPNやNRPN取引がMIDIリストに表示されないかもしれないコードをcm_unusedします。
Note that if cm_unused is assigned the letter M, Control Change (0xB) commands for the controller numbers in the standard controller assignment might still appear in the MIDI list. For an explanation, see Appendix A.3.4 for a discussion of the "general-purpose" use of parameter system controller numbers.
cm_unusedが文字Mが割り当てられている場合、標準コントローラ割り当てコントローラ番号はまだMIDIリストに表示される場合がありますため、コントロールチェンジ（0xB）コマンドことに注意してください。説明については、パラメータシステムコントローラ番号の「汎用」の使用に関する議論については、付録A.3.4を参照してください。
In the text below, rules that apply to "MIDI voice channel commands" also apply to the letter M.
以下の文章では、「MIDI音声チャネルコマンド」に適用される規則も手紙M.に適用されます
The letters in the command-type list MUST be uppercase and MUST appear in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that appear in the list MUST be ignored.
コマンドタイプ]リストの文字は大文字でなければなりませんし、アルファベット順に表示されなければなりません。リストに表示されます（ABCFGHJKMNPQTVWXYZ）以外の文字は無視しなければなりません。
For MIDI voice channel commands, the channel list specifies the MIDI channels for which the parameter applies. If no channel list is provided, the parameter applies to all MIDI channels (0-15). The channel list takes the form of a list of channel numbers (0 through 15) and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the channel list.
MIDI音声チャネルコマンドについては、チャンネルリストは、パラメータを適用するMIDIチャンネルを指定します。何のチャンネルリストが提供されていない場合、パラメータは、すべてのMIDIチャンネル（0-15）に適用されます。チャンネルリストは、チャンネル番号（0〜15）とダッシュで区切られたチャンネル番号の範囲（すなわち、0-5、8-12、等）のリストの形態をとります。チャンネルリストのドット（すなわち、「」文字）別個の要素。
Recall that system commands do not have a MIDI channel associated with them. Thus, for most command-type letters that code system commands (B, F, G, H, J, K, Q, V, Y, and Z), the channel list is ignored.
システムコマンドは、それらに関連付けられているMIDIチャンネルを持っていないことを思い出してください。したがって、コードシステムコマンド（B、F、G、H、J、K、Q、V、Y、及びZ）最もコマンドタイプの文字のために、チャンネルリストは無視されます。
For the command-type letter X, the appearance of certain numbers in the channel list codes special semantics.
コマンド型文字X、チャンネルリストのコードの特別な意味論で特定の番号の出現のために。
o The digit 0 codes that SysEx "cancel" sublists (Section 3.2 in the main text) MUST NOT appear in the MIDI list.
Oシステムエクスクルーシブは、「キャンセル」サブリスト（メインテキスト内のセクション3.2）の数字0コードは、MIDIリストに現れてはいけません。
o The digit 1 codes that cancel sublists MAY appear in the MIDI list (the default condition).
Oサブリストをキャンセル桁1つのコードは、MIDIリスト（デフォルトの状態）で表示されることがあります。
o The digit 2 codes that commands other than System Real-Time MIDI commands MUST NOT appear between SysEx command segments in the MIDI list (the default condition).
桁oをシステムのリアルタイムMIDIコマンド以外のコマンドは2つのコードはMIDIリスト（デフォルトの状態）でのSysExコマンドセグメント間に現れてはなりません。
o The digit 3 codes that any MIDI command type may appear between SysEx command segments in the MIDI list, with the exception of the segmented encoding of a second SysEx command (verbatim SysEx commands are OK).
任意のMIDIコマンドの種類が第二のSysExコマンドのセグメント化された符号化を除いて、MIDIリスト内のSysExコマンドセグメント間に表示されることが数字3つのコードO（逐語のSysExコマンドはOKです）。
For command-type X, the channel list MUST NOT contain both digits 0 and 1, and it MUST NOT contain both digits 2 and 3. For command-type X, channel list numbers other than the numbers defined above are ignored. If X does not have a channel list, the semantics marked "the default condition" in the list above apply.
上記で定義された番号以外のチャンネルリスト番号は無視され、コマンドタイプXのため、チャンネルリストは、数字0と1の両方を含んではならない、それは、コマンド型Xの桁2と3の両方を含んではなりません。 Xは、チャンネルリストを持っていない場合、セマンティクスは、上記が適用リストの「デフォルトの状態」とマークされました。
The syntax for field lists in a parameter assignment follows the syntax for channel lists. If no field list is provided, the parameter applies to all controller or note numbers.
パラメータ割り付けのフィールドリストの構文は、チャンネルリストの構文に従います。何のフィールドリストが提供されていない場合、パラメータは、すべてのコントローラやノート番号に適用されます。
For command-type C (Control Change), the field list codes the controller numbers (0-255) for which the parameter applies.
コマンドタイプC（コントロールチェンジ）、パラメータが適用されるフィールドリスト符号コントローラ番号（0〜255）のために。
For command-type M (Parameter System), the field list codes the RPN and NRPN controller numbers for which the parameter applies. The number range 0-16383 specifies RPN controllers, the number range 16384-32767 specifies NRPN controllers (16384 corresponds to NRPN controller number 0, 32767 corresponds to NRPN controller number 16383).
コマンドタイプM（パラメータシステム）のために、フィールドリストコードパラメータが適用されるRPNとNRPNコントローラ番号。数値範囲0から16383までの番号範囲16384から32767は、（NRPNコントローラ番号0、32767は、NRPNコントローラ番号16383に対応する16384相当）NRPNコントローラを指定し、RPNコントローラを指定します。
For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the field list codes the note numbers for which the parameter applies.
コマンドタイプN（NoteOnとNoteOff）とA（ポリアフタータッチ）、フィールド・リスト・コードパラメータが適用されるノート番号について。
For command-types J and K (System Common Undefined), the field list consists of a single digit, which specifies the number of data octets that follow the command octet.
コマンドタイプJおよびK（システム共通不定）のために、フィールドリストは、コマンドオクテットに従うデータオクテットの数を指定する単一の数字からなります。
For command-type X (SysEx), the field list codes the number of data octets that may appear in a SysEx command. Thus, the field list 0-255 specifies SysEx commands with 255 or fewer data octets; the field list 256-4294967295 specifies SysEx commands with more than 255 data octets but excludes commands with 255 or fewer data octets; and the field list 0 excludes all commands.
コマンドタイプX（システムエクスクルーシブ）のため、フィールドリストコードシステムエクスクルーシブコマンドで表示されることがデータオクテットの数。このように、フィールドリスト0-255は、システムエクスクルーシブが255個の以下のデータオクテットでコマンドを指定します。フィールドリスト256から4294967295は、システムエクスクルーシブが255を超えるデータオクテットとコマンドが、255個の以下のデータオクテットでコマンドを除外指定します。そしてフィールドリスト0は、すべてのコマンドを除外します。
A secondary parameter-assignment syntax customizes command-type X (see Appendix D for complete ABNF):
二次パラメーター割り当て構文は、コマンドタイプXを（完全ABNF付録Dを参照）をカスタマイズします。
<parameter> = "__" <h-list> *( "_" <h-list> ) "__"
<パラメータ> = "__" <H-リスト> *（ "_" <H-リスト>） "__"
The assignment defines the class of SysEx commands that obeys the semantics of the assigned parameter. The command class is specified by listing the permitted values of the first N data octets that follow the SysEx 0xF0 command octet. Any SysEx command whose first N data octets match the list is a member of the class.
割り当ては、割り当てられたパラメータの意味論に従うのSysExコマンドのクラスを定義します。コマンド・クラスは、システムエクスクルーシブの0xF0コマンドオクテットをたどる最初のN個のデータオクテットの許容値をリストで指定されています。その最初のN個のデータオクテットリストと一致する任意のSysExコマンドは、クラスのメンバーです。
Each <h-list> defines a data octet of the command as a dot-separated (".") list of one or more hexadecimal constants (such as "7F") or dash-separated hexadecimal ranges (such as "01-1F"). Underscores ("_") separate each <h-list>. Double-underscores ("__") delineate the data octet list.
各<H-list>は、ドットで区切られた（「」）（例えば、 『7F』など）は、1つまたは複数の16進定数のリストまたは（例えば01-1F」などのダッシュで区切ら進範囲としてコマンドのデータオクテットを定義します「）。アンダースコア（ "_"）は各<H-list>の分離します。ダブルアンダースコア（「__」）データオクテットリストを描きます。
Using this syntax, each assignment specifies a single SysEx command class. Session descriptions may use several assignments to cm_used and cm_unused to specify complex behaviors.
この構文を使用して、それぞれの割り当ては、単一のSysExコマンドクラスを指定します。セッション記述はcm_usedするためにいくつかの割り当てを使用し、複雑な振る舞いを指定するcm_unusedことがあります。
The example session description below illustrates the use of the stream subsetting parameters:
以下の例セッション記述は、ストリーム・サブセット・パラメータの使用を示します。
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB8::7F2E:172A:1E24 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__
DB8 :: 7F2E：172A：1E24 A = rtpmap：96 RTP IP6 first.example.net S =例、T = 0、M = IP6 2001年オーディオ5004 RTP / AVP 96個のC = IN V = 0 0 =ラザロ2520644554 2838152170 -midi / 44100 A =のfmtp：96 cm_unused = ACGHJKNMPTVWXYZ。 cm_used = __ 7F_00-7F_01_01__
The session description configures the stream for use in clock applications. All voice channels are unused, as are all system commands except those used for MIDI Time Code (command-type F and the
セッション記述は、クロック用途に使用するためのストリームを設定します。 MIDIタイムコード（コマンドタイプFとするために使用されるものを除くすべてのシステムコマンドがあるように、すべての音声チャネルは、未使用です
Full Frame SysEx command that is matched by the string assigned to cm_used), the System Sequencer commands (command-type Q), and System Reset (command-type B).
cm_usedに割り当てられた文字列に一致しているフルフレームのSysExコマンド）は、システムのシーケンサは、コマンドタイプQ）、およびシステム・リセット（コマンドタイプB）（コマンド。
C.2. Configuration Tools: The Journalling System
C.2。コンフィギュレーションツール：ジャーナリングシステム
In this appendix, we define the payload format parameters that configure stream journalling and the recovery journal system.
この付録では、我々は、ストリームジャーナリングと回復ジャーナルシステムを構成するペイロード形式のパラメータを定義します。
The j_sec parameter (Appendix C.2.1) sets the journalling method for the stream. The j_update parameter (Appendix C.2.2) sets the recovery journal sending policy for the stream. Appendix C.2.2 also defines the sending policies of the recovery journal system.
j_秒パラメータ（付録C.2.1）は、ストリームのジャーナリング方法を設定します。 j_アップデートパラメタ（付録C.2.2）は、ストリームのポリシーを送信回復ジャーナルを設定します。付録C.2.2も回復ジャーナルシステムの送信ポリシーを定義します。
Appendix C.2.3 defines several parameters that modify the recovery journal semantics. These parameters change the default recovery journal semantics as defined in Section 5 and Appendices A and B.
付録C.2.3は回復ジャーナル意味論を修正するいくつかのパラメータを定義します。第5節および付録AとBで定義されたこれらのパラメータは、デフォルトの回復ジャーナル意味論を変更します
The journalling method for a stream is set at the start of a session and MUST NOT be changed thereafter. This requirement forbids changes to the j_sec parameter once a session has begun.
ストリームのジャーナリング方法は、セッションの開始時に設定され、その後、変更してはなりません。セッションが始まった後は、この要件はj_秒のパラメータの変更を禁止します。
A related requirement, defined in the appendices below, forbids the acceptance of parameter values that would violate the recovery journal mandate. In many cases, a change in one of the parameters defined in this appendix during an ongoing session would result in a violation of the recovery journal mandate for an implementation; in this case, the parameter change MUST NOT be accepted.
下記の付録に定義された関連する要件は、回復ジャーナル命令に違反するパラメータ値の受け入れを禁止します。多くの場合、進行中のセッション中にこの付録で定義されたパラメータの一つの変化は、実装のための回復ジャーナル命令に違反してしまいます。この場合には、パラメータ変更を受け入れてはなりません。
C.2.1. The j_sec Parameter
C.2.1。 j_秒パラメータ
Section 2.2 defines the default journalling method for a stream. Streams that use unreliable transport (such as UDP) default to using the recovery journal. Streams that use reliable transport (such as TCP) default to not using a journal.
2.2節では、ストリームのデフォルトのジャーナリングの方法を定義します。回復ジャーナルを使用して信頼性のない（UDPなど）の輸送デフォルトを使用するストリーム。ジャーナルを使用しないように（TCPのような）信頼性の高いトランスポートデフォルトを使用するストリーム。
The parameter j_sec may be used to override this default. This memo defines two symbolic values for j_sec: "none", to indicate that all stream payloads MUST NOT contain a journal section, and "recj", to indicate that all stream payloads MUST contain a journal section that uses the recovery journal format.
このデフォルトを上書きするために使用することができるj_秒パラメータ。すべてのストリームのペイロードは、すべてのストリームペイロードが回復ジャーナル形式を使用してジャーナル部を含まなければならないことを示すために、ジャーナル部、および「recj」を含んではならないことを示すために、「なし」：このメモはj_秒のための2つの記号の値を定義します。
For example, the j_sec parameter might be set to "none" for a UDP stream that travels between two hosts on a local network that is known to provide reliable datagram delivery.
例えば、j_秒パラメーターは、信頼性の高いデータグラム配信を提供することが知られているローカルネットワーク上の2つのホスト間を移動UDPストリームのための「なし」に設定されるかもしれません。
The session description below configures a UDP stream that does not use the recovery journal: v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 j_sec=none
以下セッション記述は、回復ジャーナルを使用しないUDPストリームを構成：IP4 first.example.net S =例、T = 0、M = IP4 INオーディオ5004 RTP / AVP 96個のC = INをV = 0 0 =ラザロ2520644554 2838152170 192.0.2.94 = rtpmap：96 RTP-MIDI / 44100 =のfmtp：96 j_秒=なし
Other IETF Standards-Track documents may define alternative journal formats. These documents MUST define new symbolic values for the j_sec parameter to signal the use of the format.
他のIETF標準化過程文書は、代替ジャーナルフォーマットを定義することもできます。これらの文書は、フォーマットの使用を合図するj_秒パラメータの新しいシンボル値を定義しなければなりません。
Parties MUST NOT accept a j_sec value that violates the recovery journal mandate (see Section 4 for details). If a session description uses a j_sec value unknown to the recipient, the recipient MUST NOT accept the description.
締約国は回復ジャーナル命令を（詳細はセクション4を参照）に違反j_秒値を受け入れてはいけません。セッション記述が受信者に未知のj_秒値を使用している場合、受信者は説明を受け入れてはいけません。
Special j_sec issues arise when sessions are managed by session management tools (like RTSP, [RFC2326]) that use SDP for "declarative usage" purposes (see the preamble of Section 6 for details). For these session management tools, SDP does not code transport details (such as UDP or TCP) for the session. Instead, server and client negotiate transport details via other means (for RTSP, the SETUP method).
セッションが（詳細については、第6節の前文を参照）、「宣言型の使用」の目的のためにSDPを使用する（RTSP、[RFC2326]のような）セッション管理ツールで管理されている場合には、特別なj_秒の問題が発生します。これらのセッション管理ツールでは、SDPは、セッションのために（たとえば、UDPやTCPなど）の輸送の詳細をコーディングしていません。代わりに、サーバとクライアントは（RTSP、SETUPメソッドのため）他の手段を介して輸送の詳細を交渉します。
In this scenario, the use of the j_sec parameter may be ill-advised, as the creator of the session description may not yet know the transport type for the session. In this case, the session description SHOULD configure the journalling system using the parameters defined in the remainder of Appendix C.2, but it SHOULD NOT use j_sec to set the journalling status. Recall that if j_sec does not appear in the session description, the default method for choosing the journalling method is in effect (no journal for reliable transport, recovery journal for unreliable transport).
セッション記述の作成者がまだセッションのトランスポート・タイプを知らないかもしれないとして、このシナリオでは、j_秒のパラメータの使用は、無分別することができます。この場合、セッション記述は、付録C.2の残りの部分で定義されたパラメータを使用して、ジャーナル・システムを設定する必要があり、それはジャーナリング状態を設定するためにj_秒使用しないでください。 j_秒のセッション記述に表示されない場合は、ジャーナリング方法を選択するためのデフォルトの方法は、（信頼できる輸送のための雑誌、信頼性の低い輸送のための回復ジャーナル）有効でないことを思い出してください。
However, in declarative usage situations where the creator of the session description knows that journalling is always required or never required, the session description SHOULD use the j_sec parameter.
しかし、セッション記述の作成者がジャーナルは常に必要ではないか、決して必要であることを知っている、宣言の利用状況では、セッション記述はj_秒のパラメータを使用すべきです。
C.2.2. The j_update Parameter
C.2.2。 j_アップデートパラメータ
In Section 4, we use the term "sending policy" to describe the method a sender uses to choose the checkpoint packet identity for each recovery journal in a stream. In the subsections that follow, we normatively define three sending policies: anchor, closed-loop, and open-loop.
第4節では、送信者は、ストリーム内の各回復ジャーナルのためのチェックポイントのパケットIDを選択するために使用する方法を記述するために、「政策を送る」という用語を使用します。アンカー、閉ループ、開ループ：以下のサブセクションでは、我々は、規範的に3つの送信ポリシーを定義します。
As stated in Section 4, the default sending policy for a stream is the closed-loop policy. The j_update parameter may be used to override this default.
第4節で述べたように、ストリームのポリシーを送信デフォルトでは、閉ループ方針です。 j_アップデートパラメータは、このデフォルトを上書きするために使用することができます。
We define three symbolic values for j_update: "anchor", to indicate that the stream uses the anchor sending policy, "open-loop", to indicate that the stream uses the open-loop sending policy, and "closed-loop", to indicate that the stream uses the closed-loop sending policy. See Appendix C.2.3 for examples of session descriptions that use the j_update parameter.
ストリームがオープンループ送信ポリシーを使用していることを示すために、「ループを開く」、および「クローズド・ループ」に、ストリームは、ポリシーを送るアンカーを使用することを示すために、「アンカー」：私たちはj_アップデートのための3つの記号値を定義しますストリームがクローズドループ送信ポリシーを使用していることを示しています。 j_アップデートパラメータを使用したセッション記述の例については、付録C.2.3を参照してください。
Parties MUST NOT accept a j_update value that violates the recovery journal mandate (Section 4).
締約国は回復ジャーナル命令（第4節）に違反j_アップデート値を受け入れてはいけません。
Other IETF Standards-Track documents may define additional sending policies for the recovery journal system. These documents MUST define new symbolic values for the j_update parameter to signal the use of the new policy. If a session description uses a j_update value unknown to the recipient, the recipient MUST NOT accept the description.
他のIETF標準化過程文書は回復ジャーナルシステムのための追加の送信ポリシーを定義することができます。これらの文書は、新しいポリシーの使用を合図するj_アップデートのパラメータの新しいシンボル値を定義しなければなりません。セッション記述が受信者に未知のj_アップデート値を使用している場合、受信者は説明を受け入れてはいけません。
C.2.2.1. The anchor Sending Policy
C.2.2.1。アンカーの送信ポリシー
In the anchor policy, the sender uses the first packet in the stream as the checkpoint packet for all packets in the stream. The anchor policy satisfies the recovery journal mandate (Section 4), as the checkpoint history always covers the entire stream.
アンカーポリシーでは、送信者は、ストリーム内のすべてのパケットのためのチェックポイントパケットストリーム内の最初のパケットを使用しています。チェックポイント歴史は常にストリーム全体をカバーとしてアンカーポリシーは、回復ジャーナル命令（セクション4）を満たします。
The anchor policy does not require the use of the RTP Control Protocol (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do not need to take special actions to ensure that received streams start up free of artifacts, as the recovery journal always covers the entire history of the stream. Receivers are relieved of the responsibility of tracking the changing identity of the checkpoint packet, because the checkpoint packet never changes.
アンカーポリシーは、受信側から送信側へのRTP制御プロトコル（RTCP、[RFC3550]）、または他のフィードバックの使用を必要としません。回復ジャーナルは常にストリームの歴史全体をカバーして送信者は、その受信されたストリームは、成果物の自由な起動を保証するために特別なアクションを取る必要はありません。チェックポイントパケットが変わることはありませんので、レシーバは、チェックポイントパケットの変更IDを追跡する責任から解放されています。
The main drawback of the anchor policy is bandwidth efficiency. Because the checkpoint history covers the entire stream, the size of the recovery journals produced by this policy usually exceeds the journal size of alternative policies. For single-channel MIDI data streams, the bandwidth overhead of the anchor policy is often acceptable (see Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop policies may be more appropriate.
アンカー政策の主な欠点は、帯域幅の効率です。チェックポイント歴史がストリーム全体をカバーしているため、このポリシーによって生成回復ジャーナルのサイズは、通常、代替政策のジャーナルサイズを超えています。シングルチャンネルのMIDIデータストリームのために、アンカーポリシーの帯域幅オーバヘッドは（[NMP]の付録A.4を参照）、多くの場合、許容可能です。稠密ストリームの場合、閉ループまたは開ループポリシーがより適切であり得ます。
C.2.2.2. The closed-loop Sending Policy
C.2.2.2。閉ループ送信ポリシー
The closed-loop policy is the default policy of the recovery journal system. For each packet in the stream, the policy lets senders choose the smallest possible checkpoint history that satisfies the recovery journal mandate. As smaller checkpoint histories generally yield smaller recovery journals, the closed-loop policy reduces the bandwidth of a stream, relative to the anchor policy.
閉ループ方針は回復ジャーナルシステムのデフォルトのポリシーです。ストリームの各パケットについて、ポリシーは送信者が回復ジャーナル命令を満たす可能な最小のチェックポイント履歴を選択することができます。小さいチェックポイント履歴は、一般的に小さい回復ジャーナルをもたらすとして、クローズド・ループ・ポリシーは、アンカー政策に対するストリームの帯域幅を低減します。
The closed-loop policy relies on feedback from receiver to sender. The policy assumes that a receiver periodically informs the sender of the highest sequence number it has seen so far in the stream, coded in the 32-bit extension format defined in [RFC3550]. For RTCP, receivers transmit this information in the Extended Highest Sequence Number Received (EHSNR) field of Receiver Reports. RTCP Sender or Receiver Reports MUST be sent by any participant in a session with the closed-loop sending policy, unless another feedback mechanism has been agreed upon.
クローズド・ループ・ポリシーは、送信側に受信機からのフィードバックに依存しています。ポリシーは、受信機が定期的に[RFC3550]で定義された32ビットの拡張フォーマットで符号化され、それがストリームにこれまで見てきた最高のシーケンス番号の送信者に通知することを想定しています。 RTCPのために、受信機は、レシーバレポート（EHSNR）フィールドの受信拡張シーケンス番号が最大で、この情報を送信します。別のフィードバック機構が合意されていない限り、RTCPの送信者または受信者レポートは、閉ループ送信ポリシーとのセッション中に任意の参加者によって送らなければなりません。
The sender may safely use receiver sequence number feedback to guide checkpoint history management because Section 4 requires that receivers repair indefinite artifacts whenever a packet loss event occurs.
第4節は、パケット損失イベントが発生するたびに受信機が無期限のアーティファクトを修復する必要があるため、送信者は、安全にチェックポイント履歴管理を導くために、受信シーケンス番号のフィードバックを使用することができます。
We now normatively define the closed-loop policy. At the moment a sender prepares an RTP packet for transmission, the sender is aware of R >= 0 receivers for the stream. Senders may become aware of a receiver via RTCP traffic from the receiver, via RTP packets from a paired stream sent by the receiver to the sender, via messages from a session management tool, or by other means. As receivers join and leave a session, the value of R changes.
私たちは今、規範的に閉ループポリシーを定義します。送信者が送信用のRTPパケットを準備する現時点では、送信者はストリームのための> = 0のレシーバRを認識しています。送信者は、セッション管理ツールからのメッセージを介して、または他の手段によって、送信側に受信機によって送信された一対のストリームからRTPパケットを介して、受信機からのRTCPトラフィックを介して受信機に気づくことができます。受信機が参加し、セッションを残すように、Rの値が変更されます。
Each known receiver k (1 <= k <= R) is associated with a 32-bit extended packet sequence number M(k), where the extension reflects the sequence number rollover count of the sender.
既知の各受信K（1 <= K <= R）エクステンションは、送信元のシーケンス番号ロールオーバ・カウントを反映する32ビットの拡張パケットシーケンス番号M（k）は、関連付けられています。
If the sender has received at least one feedback report from receiver k, M(k) is the most recent report of the highest RTP packet sequence number seen by the receiver, normalized to reflect the rollover count of the sender.
送信者が受信機kから少なくとも一つのフィードバックレポートを受信した場合には、M（k）は、送信者のロールオーバー回数を反映するために正規化された受信機で見た最高のRTPパケットのシーケンス番号の最も最近の報告です。
If the sender has not received a feedback report from the receiver, M(k) is the extended sequence number of the last packet the sender transmitted before it became aware of the receiver. If the sender became aware of this receiver before it sent the first packet in the stream, M(k) is the extended sequence number of the first packet in the stream.
送信側は受信側からのフィードバックレポートを受信していない場合には、M（k）は、それが受信機を意識するようになりました前に、送信者が送信した最後のパケットの拡張シーケンス番号です。それはストリームの最初のパケットを送信する前に、送信者はこの受信を知った場合、M（k）は、ストリームの最初のパケットの拡張シーケンス番号です。
Given this definition of M(k), we now state the closed-loop policy. When preparing a new packet for transmission, a sender MUST choose a checkpoint packet with extended sequence number N, such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict sender behavior in the R == 0 (no known receivers) case.
M（k）のこの定義を考えると、我々は今、閉ループ方針を述べます。送信のための新たなパケットを調製する場合、送信者は、拡張シーケンス番号Nとチェックポイントのパケットを選択する必要があり、そのようなM（K）> =（N - 1）その全てのkについて、1 <= K <= R、R> = 1.ポリシーは、R == 0（なし既知の受信機）場合には、送信者の行動を制限しません。
Under the closed-loop policy as defined above, a sender may transmit packets whose checkpoint history is shorter than the session history (as defined in Appendix A.1). In this event, a new receiver that joins the stream may experience indefinite artifacts.
閉ループ方針の下、上記で定義のように、送信者は、そのチェックポイント歴史（付録A.1で定義されている）セッション履歴より短いパケットを送信してもよいです。このイベントでは、ストリームに参加する新しい受信機は、無期限のアーチファクトが発生することがあります。
For example, if a Control Change (0xB) command for Channel Volume (controller number 7) was sent early in a stream, and later a new receiver joins the session, the closed-loop policy may permit all packets sent to the new receiver to use a checkpoint history that does not include the Channel Volume Control Change command. As a result, the new receiver experiences an indefinite artifact and plays all notes on a channel too loudly or too softly.
例えば、チャンネル・ボリューム（コントローラ番号7）のためのコントロールチェンジ（0xB）コマンドは、初期のストリームで送信された場合、以降の新しい受信機がセッションに参加し、閉ループ方針は、新しい受信機に送信されたすべてのパケットを許可することができますチャンネルボリュームコントロールチェンジのコマンドが含まれていないチェックポイント履歴を使用。その結果、新しい受信機は、無期限のアーティファクトを経験し、あまりにも大声またはあまりにも柔らかくチャネル上のすべてのノートを果たしています。
To address this issue, the closed-loop policy states that whenever a sender becomes aware of a new receiver, the sender MUST determine if the receiver would be subject to indefinite artifacts under the closed-loop policy. If so, the sender MUST ensure that the receiver starts the session free of indefinite artifacts. For example, to solve the Channel Volume issue described above, the sender may code the current state of the Channel Volume controller numbers in the recovery journal Chapter C, until it receives the first RTCP RR report that signals that a packet containing this Chapter C has been received.
この問題に対処するために、閉ループ方針は、送信者が新しい受信機に気付いたときに受信機は、閉ループ方針の下で無期限のアーティファクトの対象となる場合は、送信者が判断しなければならないと述べています。その場合は、送信者は受信機が不定人工物の自由なセッションを開始することを保証しなければなりません。それは、この章Cを含むパケットを有することを知らせる最初のRTCP RR報告を受信するまで、例えば、上述したチャンネルボリューム問題を解決するために、送信者は、回復ジャーナル章Cにおけるチャネルボリュームコントローラ番号の現在の状態を符号化することができます受信されました。
In satisfying this requirement, senders MAY infer the initial MIDI state of the receiver from the session description. For example, the stream example in Section 6.2 has the initial state defined in [MIDI] for General MIDI.
この要件を満たすには、送信者は、セッション記述から、受信機の初期MIDI状態を推論することができます。たとえば、6.2節でのストリームの例では、一般的なMIDIのための[MIDI]で定義された初期状態を持っています。
In a unicast RTP session, a receiver may safely assume that the sender is aware of its presence as a receiver from the first packet sent in the RTP stream. However, in other types of RTP sessions (multicast, conference focus, RTP translator/mixer), a receiver is often not able to determine if the sender is initially aware of its presence as a receiver.
ユニキャストRTPセッションでは、受信機が安全に送信者がRTPストリーム内で送られた最初のパケットから受信機としてその存在を認識していると仮定することができます。送信側が受信側としてその存在を最初に認識している場合は、RTPセッション（マルチキャスト、会議フォーカス、RTPトランスレータ/ミキサー）の他のタイプでは、受信機は、多くの場合、判断することができません。
To address this issue, the closed-loop policy states that if a receiver participates in a session where it may have access to a stream whose sender is not aware of the receiver, the receiver MUST take actions to ensure that its rendered MIDI performance does not contain indefinite artifacts. These protections will be necessarily incomplete. For example, a receiver may monitor the Checkpoint
この問題に対処するには、クローズド・ループ・ポリシーは、受信機は、それは、送信者、受信機を認識していないストリームへのアクセスを有することができるセッションに参加した場合、受信機はそのレンダリングされたMIDI性能がないことを確実にするために行動を取る必要があること無期限の成果物が含まれています。これらの保護は必ずしも不完全になります。例えば、受信機は、チェックポイントを監視することができます
Packet Seqnum for uncovered loss events and "err on the side of caution" with respect to handling stuck notes due to lost MIDI NoteOff commands, but the receiver is not able to compensate for the lack of Channel Volume initialization data in the recovery journal.
パケットむき出しの損失イベントのSEQNUM及び取扱いに関して「注意の側に誤るは」失われたMIDI NoteOffコマンドにメモを突っ込んが、受信機は回復ジャーナルでチャンネルボリュームの初期化データの不足を補うことができません。
The receiver MUST NOT discontinue these protective actions until it is certain that the sender is aware of its presence. If a receiver is not able to ascertain sender awareness, the receiver MUST continue these protective actions for the duration of the session.
送信者がその存在を認識していることは確かであるまで、受信機は、これらの保護措置を中止してはなりません。受信機は、送信者の意識を把握することができない場合、受信機は、セッションの間、これらの保護措置を継続する必要があります。
Note that in a multicast session where all parties are expected to send and receive, the reception of RTCP receiver reports from the sender about the RTP stream a receiver is multicasting back is evidence of the sender's awareness that the RTP stream multicast by the sender is being monitored by the receiver. Receivers may also obtain sender awareness evidence from session management tools, or by other means. In practice, ongoing observation of the Checkpoint Packet Seqnum to determine if the sender is taking actions to prevent loss events for a receiver is a good indication of sender awareness, as is the sudden appearance of recovery journal chapters with numerous Control Change controller data that was not foreshadowed by recent commands coded in the MIDI list shortly after sending an RTCP RR.
すべての当事者は、送信および受信することが期待されているマルチキャストセッションでは、RTPについての送信者からのRTCPレシーバレポートの受信は、受信機が戻ってマルチキャストされるストリームことに注意してください送信者によるRTPストリームのマルチキャストがされていることを、送信者の意識の証拠であります受信機によって監視。レシーバは、セッション管理ツールから、または他の手段によって、送信者の意識の証拠を得ることができます。た数多くのコントロールチェンジコントローラデータと回復ジャーナル章の突然の出現があるとして、実際には、送信者が受信機のために損失イベントを防ぐために行動を取っているかどうかを判断するためのチェックポイントパケットSEQNUMの継続的な観察は、送信者の意識の良い指標でありますまもなくRTCPのRRを送信した後にMIDIリストにコード化された新しいコマンドによって予示ありません。
The final set of normative closed-loop policy requirements concerns how senders and receivers handle unplanned disruptions of RTCP feedback from a receiver to a sender. By "unplanned", we refer to disruptions that are not due to the signalled termination of an RTP stream, via an RTCP BYE or via session management tools.
送信側と受信側が送信側に受信機からRTCPフィードバックの無計画な中断を処理する方法規範閉ループポリシー要件の懸念の最終セット。 「予定外」とは、RTCP BYEを介して、またはセッション管理ツールを使用して、RTPストリームの合図終了によるものではない混乱を参照してください。
As defined earlier in this section, the closed-loop policy states that a sender MUST choose a checkpoint packet with extended sequence number N, such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. If the sender has received at least one feedback report from receiver k, M(k) is the most recent report of the highest RTP packet sequence number seen by the receiver, normalized to reflect the rollover count of the sender.
すべてのkについて、1 <= K <= - 以前、このセクションで定義されるように、閉ループポリシーは、送信者は、M（K）> =（1 N）は、拡張シーケンス番号Nとチェックポイントのパケットを選択しなければならないと述べていますのロールオーバー数を反映するように正規化された送信者が受信kから少なくとも一つのフィードバックレポートを受信した場合、R> = 1、M（k）は、受信機によって見られる最高のRTPパケットのシーケンス番号の最も最近の報告であるR、送り主。
If this receiver k stops sending feedback to the sender, the M(k) value used by the sender reflects the last feedback report from the receiver. As time progresses without feedback from receiver k, this fixed M(k) value forces the sender to increase the size of the checkpoint history and thus increases the bandwidth of the stream.
この受信機kは、送信者へのフィードバックの送信を停止した場合、送信者が使用するM（k）の値は、受信機からの最後のフィードバックレポートを反映しています。時間は、受信機kからのフィードバックなしに進行するように、この固定されたM（k）の値は、チェックポイントの履歴のサイズを増加させるために、送信者を強制し、従って、ストリームの帯域幅を増加させます。
At some point, the sender may need to take action in order to limit the bandwidth of the stream. In most envisioned uses of RTP MIDI, long before this point is reached, the SSRC time-out mechanism defined in [RFC3550] will remove the uncooperative receiver from the
ある時点で、送信者はストリームの帯域幅を制限するために行動を取る必要があるかもしれません。 RTP MIDIの最も想定される用途では、この点に到達するずっと前に、SSRCタイムアウトメカニズムは[RFC3550]で定義されたから非協調レシーバを削除します
session (note that the closed-loop policy does not suggest or require any special sender behavior upon an SSRC time-out, other than the sender actions related to changing R, described earlier in this section).
セッション（クローズド・ループ・ポリシーは、以前、このセクションで説明したRの変化に関連した送信者のアクション以外のSSRCタイムアウト時に特別な送信者の挙動を、示唆または必要としないことに注意してください）。
However, in rare situations, the bandwidth of the stream (due to a lack of feedback reports from the sender) may become too large to continue sending the stream to the receiver before the SSRC time-out occurs for the receiver. In this case, the closed-loop policy states that the sender should invoke the SSRC time-out for the receiver early.
しかし、まれな状況では、（原因送信者からのフィードバックレポートの不足）ストリームの帯域幅は、SSRCタイムアウトが受信機のために発生する前に受信機にストリームの送信を継続するには大きすぎることがあります。この場合、閉ループ方針は、送信者が早期に受信用SSRCタイムアウトを呼び出す必要があると述べています。
We now discuss receiver responsibilities in the case of unplanned disruptions of RTCP feedback from receiver to sender.
私たちは今、受信機から送信者にRTCPフィードバックの予定外の中断の場合には受信機の責任を議論します。
In the unicast case, if a sender invokes the SSRC time-out mechanism for a receiver, the receiver stops receiving packets from the sender. The sender behavior imposed by the guardtime parameter (Appendix C.4.2) lets the receiver conclude that an SSRC time-out has occurred in a reasonable time period.
送信側が受信のためにSSRCタイムアウト機構を呼び出す場合は、ユニキャストの場合に、受信機は、送信者からのパケットの受信を停止します。 guardtimeパラメータ（付録C.4.2）によって課された送信者の行動は、受信機がSSRCタイムアウトが合理的な期間内に発生していると結論することができます。
In this case of a time-out, a receiver MUST keep sending RTCP feedback, in order to re-establish the RTP flow from the sender. Unless the receiver expects a prompt recovery of the RTP flow, the receiver MUST take actions to ensure that the rendered MIDI performance does not exhibit "very long transient artifacts" (for example, by silencing NoteOns to prevent stuck notes) while awaiting reconnection of the flow.
タイムアウトのこの場合、受信側は送信側からのRTPの流れを再確立するためには、RTCPのフィードバックを送信し続けなければなりません。受信機はRTPフローの迅速な回復を期待していない限りの再接続を待つ間、受信機は、（例えば、スタックノートを防ぐためにNoteOnsをサイレンシングによって）レンダリングされたMIDI性能は「非常に長い過渡アーティファクト」を示さないことを確実にするための行動を取る必要がありますフロー。
In the multicast case, if a sender invokes the SSRC time-out mechanism for a receiver, the receiver may continue to receive packets, but the sender will no longer be using the M(k) feedback from the receiver to choose each checkpoint packet. If the receiver does not have additional information that precludes an SSRC time-out (such as RTCP Receiver Reports from the sender about an RTP stream the receiver is multicasting back to the sender), the receiver MUST monitor the Checkpoint Packet Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, the receiver MUST follow the instructions for SSRC time-outs described for the unicast case above.
送信者が受信機のSSRCタイムアウト機構を呼び出す場合、マルチキャスト場合、受信機は、パケットを受信し続けることができるが、送信者はもはや、各チェックポイントのパケットを選択するために受信機からのM（k）のフィードバックを使用していないであろう。受信機は（RTPは、受信者が送信者に戻ってマルチキャストされるストリームに関する送信者からそのようなRTCPレシーバレポートとして）SSRCタイムアウトを排除する追加の情報を持っていない場合、受信機は、SSRCを検出するためのチェックポイントパケットSEQNUMを監視する必要がありますタイムアウト。 SSRCタイムアウトが検出された場合、受信機は、上記ユニキャスト場合について説明SSRCタイムアウトするための命令に従わなければなりません。
Finally, we note that the closed-loop policy is suitable for use in RTP/RTCP sessions that use multicast transport. However, aspects of the closed-loop policy do not scale well to sessions with large numbers of participants. The sender state scales linearly with the number of receivers, as the sender needs to track the identity and M(k) value for each receiver k. The average recovery journal size is not independent of the number of receivers, as the RTCP reporting interval backoff slows down the rate of a full update of M(k) values.
最後に、我々は、閉ループポリシーは、マルチキャストトランスポートを使用するRTP / RTCPセッションでの使用に適していることに注意してください。しかし、閉ループ政策の側面は、参加者の大規模な番号を持つセッションにうまくスケールしません。送信側は、各受信機kのアイデンティティおよびM（k）の値を追跡する必要があるように送信者状態は、受信機の数と共に直線的に比例します。平均回復ジャーナルサイズがRTCP間隔バックオフ報告として、M（k）の値の完全な更新の速度が遅くなり、受信機の数とは無関係ではありません。
The backoff algorithm may also increase the amount of ancillary state used by implementations of the normative sender and receiver behaviors defined in Section 4.
バックオフアルゴリズムは、セクション4で定義された規範送信側と受信側の動作の実装によって使用される補助的な状態の量を増加させることができます。
C.2.2.3. The open-loop Sending Policy
C.2.2.3。開ループ送信ポリシー
The open-loop policy is suitable for sessions that are not able to implement the receiver-to-sender feedback required by the closed-loop policy and that are also not able to use the anchor policy because of bandwidth constraints.
開ループポリシーは、閉ループ方針及びそのためにも、帯域幅の制約のアンカーポリシーを使用することができませんで必要とされる受信機に送信者のフィードバックを実装することができないセッションに適しています。
The open-loop policy does not place constraints on how a sender chooses the checkpoint packet for each packet in the stream. In the absence of such constraints, a receiver may find that the recovery journal in the packet that ends a loss event has a checkpoint history that does not cover the entire loss event. We refer to loss events of this type as uncovered loss events.
オープン・ループ・ポリシーは、送信者は、ストリーム内の各パケットのためのチェックポイントのパケットを選択する方法に制約を課しません。このような制約がない場合には、受信機は、損失イベントを終了し、パケットの回復ジャーナルは、全体の損失事象をカバーしていないチェックポイント歴史を持っていることがあります。私たちは、むき出しの損失イベントとして、この種の損失イベントを参照してください。
To ensure that uncovered loss events do not compromise the recovery journal mandate, the open-loop policy assigns specific recovery tasks to senders, receivers, and the creators of session descriptions. The underlying premise of the open-loop policy is that the indefinite artifacts produced during uncovered loss events fall into two classes.
むき出しの損失事象が回復ジャーナル命令を損なわないことを保証するために、開ループポリシーには、送信者、受信者、およびセッション記述の創造者に具体的な復旧作業を割り当てます。オープンループ政策の根本的な前提は、むき出しの損失イベント中に生成不定アーティファクトを2つのクラスに入ることです。
One class of artifacts is recoverable indefinite artifacts. Receivers are able to repair recoverable artifacts that occur during an uncovered loss event without intervention from the sender, at the potential cost of unpleasant transient artifacts.
成果物の1つのクラスは、回復不定人工物です。レシーバは、不快な過渡成果物の潜在的なコストで、送信者からの介入なしにむき出しの損失イベント中に発生した回復可能なアーティファクトを修復することができます。
For example, after an uncovered loss event, receivers are able to repair indefinite artifacts due to NoteOff (0x8) commands that may have occurred during the loss event, by executing NoteOff commands for all active NoteOns commands. This action causes a transient artifact (a sudden silent period in the performance) but ensures that no stuck notes sound indefinitely. We refer to MIDI commands that are amenable to repair in this fashion as recoverable MIDI commands.
例えば、むき出しの損失事象の後、受信機は、原因すべてのアクティブなNoteOnsコマンド用のコマンドをNoteOff実行することにより、損失イベント中に発生したNoteOff（0x8という）コマンドに不定アーティファクトを修復することができます。このアクションは、一過性のアーティファクト（性能が突然無音区間）を引き起こすが、何のスタックノートが無期限に聞こえるしないことを保証します。私たちは、回復可能なMIDIコマンドとして、この方法で修復されやすいですMIDIコマンドを参照してください。
A second class of artifacts is unrecoverable indefinite artifacts. If this class of artifact occurs during an uncovered loss event, the receiver is not able to repair the stream.
成果物の第二のクラスは、回復不可能な不定のアーチファクトです。アーティファクトのこのクラスはむき出しの損失イベント中に発生した場合、受信機は、ストリームを修復することができません。
For example, after an uncovered loss event, receivers are not able to repair indefinite artifacts due to Control Change (0xB) Channel Volume (controller number 7) commands that have occurred during the loss event. A repair is impossible because the receiver has no way of determining the data value of a lost Channel Volume command. We refer to MIDI commands that are fragile in this way as unrecoverable MIDI commands.
例えば、むき出しの損失事象の後、受信機は起因損失イベント中に発生したコントロールチェンジ（0xB）チャンネルボリューム（コントローラ番号7）コマンドに不定アーティファクトを修復することができません。受信機が失われたチャンネルボリュームコマンドのデータ値を決定する方法がないので、修復は不可能です。私たちは、回復不能なMIDIコマンドとして、このように壊れやすいMIDIコマンドを参照してください。
The open-loop policy does not specify how to partition the MIDI command set into recoverable and unrecoverable commands. Instead, it assumes that the creators of the session descriptions are able to come to agreement on a suitable recoverable/unrecoverable MIDI command partition for an application.
オープンループ政策は回復し、回復不能なコマンドに設定されたMIDIコマンドを分割する方法を指定しません。代わりに、それはセッション記述の作成者は、アプリケーションに適した回収可能/回復不能なMIDIコマンドパーティション上の合意に来ることができていることを前提としています。
Given these definitions, we now state the normative requirements for the open-loop policy.
これらの定義を考えると、我々は今、オープンループポリシーの規範的要件を述べます。
In the open-loop policy, the creators of the session description MUST use the ch_anchor parameter (defined in Appendix C.2.3) to protect all unrecoverable MIDI command types from indefinite artifacts or alternatively MUST use the cm_unused parameter (defined in Appendix C.1) to exclude the command types from the stream. These options act to shield command types from artifacts during an uncovered loss event.
開ループポリシーでは、セッション記述の作成者は、不定のアーティファクトからすべての回復不能なMIDIコマンドの種類を保護するために（付録C.2.3に定義される）ch_anchorパラメータを使用する必要があり、または代替的に、付録C.1で定義された（cm_unusedパラメータを使用する必要があります）ストリームからのコマンドタイプを除外します。これらのオプションは、むき出しの損失イベント中にアーティファクトからのコマンドタイプをシールドするように作用します。
In the open-loop policy, receivers MUST examine the Checkpoint Packet Seqnum field of the recovery journal header after every loss event, to check if the loss event is an uncovered loss event. Section 5 shows how to perform this check. If an uncovered loss event has occurred, a receiver MUST perform indefinite artifact recovery for all MIDI command types that are not shielded by ch_anchor and cm_unused parameter assignments in the session description.
オープンループポリシーでは、受信機は、損失事象がむき出しの損失出来事であるかどうかを確認するために、すべての損失事象の後に回復ジャーナルヘッダーのチェックポイントパケットSEQNUMフィールドを調べる必要があります。第5節では、このチェックを実行する方法を示しています。むき出しの損失イベントが発生した場合、受信機は、セッション記述にch_anchorとcm_unusedパラメータの割り当てによって遮蔽されていないすべてのMIDIコマンドタイプの不定アーチファクトの回復を実行しなければなりません。
The open-loop policy does not place specific constraints on the sender. However, the open-loop policy works best if the sender manages the size of the checkpoint history to ensure that uncovered losses occur infrequently, by taking into account the delay and loss characteristics of the network. Also, as each checkpoint packet change incurs the risk of an uncovered loss, senders should only move the checkpoint if it reduces the size of the journal.
オープン・ループ・ポリシーは、送信者に特定の制約を課すものではありません。送信者は、アカウントにネットワークの遅延や損失特性を取ることによって、むき出しの損失が頻繁には発生しないことを確認するためにチェックポイント歴史のサイズを管理している場合しかし、オープンループポリシーが最適です。各チェックポイントパケット変更がむき出しの損失のリスクを負うとして、それはジャーナルのサイズを小さくする場合にも、送信者にのみチェックポイントを移動する必要があります。
C.2.3. Recovery Journal Chapter Inclusion Parameters
C.2.3。回復ジャーナル章インクルージョンパラメータ
The recovery journal chapter definitions (Appendices A and B) specify under what conditions a chapter MUST appear in the recovery journal. In most cases, the definition states that if a certain command appears in the checkpoint history, a certain chapter type MUST appear in the recovery journal to protect the command.
回復ジャーナル章の定義（付録AおよびB）は、章では、回復ジャーナルに表示される必要がありますどのような条件の下で指定します。ほとんどの場合、定義は、特定のコマンドがチェックポイント歴史に表示されている場合、特定の章タイプはコマンドを保護するために回復ジャーナルに現れなければならないと述べています。
In this section, we describe the chapter inclusion parameters. These parameters modify the conditions under which a chapter appears in the journal. These parameters are essential to the use of the open-loop policy (Appendix C.2.2.3) and may also be used to simplify implementations of the closed-loop (Appendix C.2.2.2) and anchor (Appendix C.2.2.1) policies.
このセクションでは、我々は章包含パラメータについて説明します。これらのパラメータは、章では、ジャーナルに表示される条件を変更します。これらのパラメータは、開ループポリシー（付録C.2.2.3）の使用に不可欠であり、また、閉ループ（付録C.2.2.2）及びアンカー（付録C.2.2の実装を簡素化するために使用されてもよいです。 1）政策。
Each parameter represents a type of chapter inclusion semantics. An assignment to a parameter declares which chapters (or chapter subsets) obey the inclusion semantics. We describe the assignment syntax for these parameters later in this section.
各パラメータは章包含セマンティクスの種類を表します。パラメータの割り当てが包含セマンティクスに従うどの章（チャプターサブセット）を宣言する。私たちは、このセクションの後半では、これらのパラメータの割り当ての構文について説明します。
A party MUST NOT accept chapter inclusion parameter values that violate the recovery journal mandate (Section 4). All assignments of the subsetting parameters (cm_used and cm_unused) MUST precede the first assignment of a chapter inclusion parameter in the parameter list.
当事者は回復ジャーナル命令（第4節）に違反章包含パラメータ値を受け入れてはいけません。 （cm_usedとcm_unused）サブセットパラメータのすべての割り当ては、パラメータリストのチャプタ包含パラメーターの最初の割り当てに先行しなければなりません。
Below, we normatively define the semantics of the chapter inclusion parameters. For clarity, we define the action of parameters on complete chapters. If a parameter is assigned a subset of a chapter, the definition applies only to the chapter subset.
以下に、私たちは、規範的に章包含パラメータの意味を定義します。明確にするために、我々は完全な章のパラメータのアクションを定義します。パラメータは章のサブセットを割り当てられている場合、定義は章のサブセットにのみ適用されます。
o ch_never. A chapter assigned to the ch_never parameter MUST NOT appear in the recovery journal (Appendices A.4.1 and A.4.2 define exceptions to this rule for Chapter M). To signal the exclusion of a chapter from the journal, an assignment to ch_never MUST be made, even if the commands coded by the chapter are assigned to cm_unused. This rule simplifies the handling of commands types that may be coded in several chapters.
ch_never O。 ch_neverパラメータに割り当てられた章では、回復ジャーナルに現れてはならない（付録A.4.1及びA.4.2章Mのために、このルールに例外を定義します）。ジャーナルからの章の除外を知らせるために、ch_neverへの割り当てはcm_unusedの章で符号化されたコマンドが割り当てられている場合であっても、しなければなりません。この規則は、いくつかの章でコード化することができるコマンドの種類の取り扱いを簡素化します。
o ch_default. A chapter assigned to the ch_default parameter MUST follow the default semantics for the chapter, as defined in Appendices A and B.
ch_default O。付録AとBで定義されているch_defaultパラメータに割り当てられた章では、章のデフォルトのセマンティクスに従わなければなりません。
o ch_anchor. A chapter assigned to the ch_anchor MUST obey a modified version of the default chapter semantics. In the modified semantics, all references to the checkpoint history are replaced with references to the session history, and all references to the checkpoint packet are replaced with references to the first packet sent in the stream.
ch_anchor O。 ch_anchorに割り当てられた章では、デフォルトの章の意味論の修正版に従わなければなりません。修正セマンティクスでは、チェックポイント歴史へのすべての参照は、セッション履歴への参照に置き換えられ、およびチェックポイントパケットへのすべての参照は、ストリームで送信された最初のパケットへの参照に置き換えられます。
Parameter assignments obey the following syntax (see Appendix D for ABNF):
パラメータの割り当ては（ABNFのための付録Dを参照）、次の構文に従います。
<parameter> = [channel list]<chapter list>[field list]
<パラメータ> = [チャンネルリスト] <チャプタリスト> [フィールドリスト]
The chapter list is mandatory; the channel and field lists are optional. Multiple assignments to parameters have a cumulative effect and are applied in the order of parameter appearance in a media description.
チャプタリストは必須です。チャネルとフィールドのリストはオプションです。パラメータに複数の割り当ては、累積効果を持ち、メディア記述におけるパラメータ出現の順序で適用されます。
To determine the semantics of a list of chapter inclusion parameter assignments, we begin by assuming an implicit assignment of all channel and system chapters to the ch_default parameter, with the default values for the channel list and field list for each chapter that are defined below.
章包含パラメータの割り当てのリストのセマンティクスを決定するために、我々は、以下に定義される各章のためのチャンネルリストとフィールドリストのデフォルト値を用いて、ch_defaultパラメータにすべてのチャネル及びシステム章の暗黙的な割り当てを想定し始めます。
We then interpret the semantics of the actual parameter assignments, using the rules below.
私たちは、その後、以下の規則を使用して、実際のパラメータの割り当ての意味を解釈します。
A later assignment of a chapter to the same parameter expands the scope of the earlier assignment. In most cases, a later assignment of a chapter to a different parameter cancels (partially or completely) the effect of an earlier assignment.
同じパラメータの章の後の割り当ては、以前の割り当ての範囲を拡大します。ほとんどの場合、異なるパラメータの章の後の割り当ては、（部分的にまたは完全に）以前の割り当ての効果を打ち消します。
The chapter list specifies the channel or system chapters for which the parameter applies. The chapter list is a concatenated sequence of one or more of the letters corresponding to the chapter types (ACDEFMNPQTVWX). In addition, the list may contain one or more of the letters for the subchapter types (BGHJKYZ) of System Chapter D.
チャプタリストは、パラメータが適用されるチャネルまたはシステムのチャプターを指定します。チャプタリストチャプタタイプ（ACDEFMNPQTVWX）に対応する文字のうちの1つまたは複数の連結された配列です。また、リストには、システム章D.のサブチャプターの種類の文字（BGHJKYZ）の一つ以上を含むことができ
The letters in a chapter list MUST be uppercase and MUST appear in alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that appear in the chapter list MUST be ignored.
チャプタリスト内の文字は大文字でなければなりませんし、アルファベット順に表示されなければなりません。チャプタリストに表示されます（ABCDEFGHJKMNPQTVWXYZ）以外の文字は無視しなければなりません。
The channel list specifies the channel journals for which this parameter applies; if no channel list is provided, the parameter applies to all channel journals. The channel list takes the form of a list of channel numbers (0 through 15) and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the channel list.
チャンネルリストは、このパラメータが適用されるチャネルジャーナルを指定します。何のチャンネルリストが提供されていない場合、パラメータは、すべてのチャネルの雑誌に適用されます。チャンネルリストは、チャンネル番号（0〜15）とダッシュで区切られたチャンネル番号の範囲（すなわち、0-5、8-12、等）のリストの形態をとります。チャンネルリストのドット（すなわち、「」文字）別個の要素。
Several of the system chapters may be configured to have special semantics. Configuration occurs by specifying a channel list for the system channel, using the coding described below. (Note that MIDI system commands do not have a "channel" and thus the original purpose of the channel list does not apply to system chapters). The expression "the digit N" in the text below refers to the inclusion of N as a "channel" in the channel list for a system chapter.
システムの章のいくつかは、特別な意味を持つように構成することができます。構成は、以下に記載の符号化を使用して、システムのチャネルのチャネルリストを指定することによって起こります。 （MIDIシステムコマンドは、「チャンネル」を持っていないので、チャンネルリストの本来の目的は、システムの章には適用されないことに注意してください）。以下のテキストで表現「桁N」は、システムの章のためのチャンネルリスト内の「チャネル」としてNを含むことを意味します。
For the J and K Chapter D subchapters (undefined System Common), the digit 0 codes that the parameter applies to the LEGAL field of the associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes that the parameter applies to the VALUE field of the command log, and the digit 2 codes that the parameter applies to the COUNT field of the command log.
J及びK章Dの節（不定システム共通）パラメータは、関連するコマンドログ（付録B.1の図B.1.4）の法的分野に適用される数字0コード、数字1コードパラメータのコマンドログのVALUEフィールド、パラメータは、コマンドログのCOUNTフィールドに適用桁2のコードに適用されます。
For the Y and Z Chapter D subchapters (undefined System Real-Time), the digit 0 codes that the parameter applies to the LEGAL field of the associated command log (Figure B.1.5 of Appendix B.1) and the digit 1 codes that the parameter applies to the COUNT field of the command log.
Y及びZ章Dの節（不定システムリアルタイム）、パラメータが関連付けられているコマンドログの法的分野に適用される数字0コード（付録B.1の図B.1.5）および桁1コードについてそのパラメータは、コマンドログのCOUNTフィールドに適用されます。
For Chapter Q (Sequencer State Commands), the digit 0 codes that the parameter applies to the default Chapter Q definition, which forbids the TIME field. The digit 1 codes that the parameter applies to the optional Chapter Q definition, which supports the TIME field.
章Q（シーケンサー州立コマンド）、パラメータはTIMEフィールドを禁じデフォルト章Qの定義に当てはまる数字0コードについて。パラメータはTIMEフィールドをサポートし、オプションの章Qの定義に当てはまる数字1つのコード。
The syntax for field lists follows the syntax for channel lists. If no field list is provided, the parameter applies to all controller or note numbers. For Chapter C, if no field list is provided, the controller numbers do not use enhanced Chapter C encoding (Appendix A.3.3).
フィールドリストの構文は、チャンネルリストの構文に従います。何のフィールドリストが提供されていない場合、パラメータは、すべてのコントローラやノート番号に適用されます。何のフィールドリストが提供されていない場合章Cについては、コントローラ番号が高められた章Cコード化（付録A.3.3）を使用しないでください。
For Chapter C, the field list may take on values in the range 0 to 255. A field value X in the range 0-127 refers to a controller number X and indicates that the controller number does not use enhanced Chapter C encoding. A field value X in the range 128-255 refers to a controller number "X minus 128" and indicates the controller number does use the enhanced Chapter C encoding.
章C、フィールドリストは、255の範囲0の値をとることができるための範囲0〜127のフィールド値Xは、コントローラ番号Xを参照し、コントローラ番号が向上章Cの符号化を使用しないことを示しています。範囲128-255のフィールド値Xは、コントローラ番号「Xマイナス128」を参照して、高められた章Cの符号化を使用しないコントローラ番号を示しています。
Assignments made to configure the Chapter C encoding method for a controller number MUST be made to the ch_default or ch_anchor parameters, as assignments to ch_never act to exclude the number from the recovery journal (and thus the indicated encoding method is irrelevant).
割り当てが回復ジャーナルの数を除外する行為をch_neverするために、コントローラ番号の章Cの符号化方法を構成するために作られた割り当ては、ch_defaultまたはch_anchorパラメータに対してなされなければならない（従って、指示された符号化方式は無関係です）。
A Chapter C field list MUST NOT encode conflicting information about the enhanced encoding status of a particular controller number. For example, values 0 and 128 MUST NOT both be coded by a field list.
章Cのフィールドリストは、特定のコントローラ番号の拡張符号化状態に関する矛盾する情報を符号化してはいけません。例えば、0と128の両方がフィールドリストで符号化されてはいけません値。
For Chapter M, the field list codes the RPN and NRPN controller numbers for which the parameter applies. The number range 0-16383 specifies RPN controller numbers, the number range 16384-32767 specifies NRPN controller numbers (16384 corresponds to NRPN controller number 0, 32767 corresponds to NRPN controller number 16383).
章Mの場合は、フィールドリストのコードRPNとNRPNコントローラ番号パラメータが適用されます。数値範囲0から16383までの番号範囲16384から32767が（16384は、NRPNコントローラ番号0に対応32767は、NRPNコントローラ番号16383に対応）NRPNコントローラ番号を指定し、RPNコントローラ番号を指定します。
For Chapters N and A, the field list codes the note numbers for which the parameter applies. The note number range specified for Chapter N also applies to Chapter E.
章NとAのために、フィールドリストのコードパラメータが適用されるノート番号。章Nに指定したノート番号の範囲はまた、章E.に適用されます
For Chapter E, the digit 0 codes that the parameter applies to Chapter E note logs whose V bit is set to 0, and the digit 1 codes that the parameter applies to note logs whose V bit is set to 1.
章E、パラメータは、そのVビット0に設定されている章Eノートログに適用される数字0のコード、およびパラメータは、そのVビット1に設定されているログを注意することが当てはまる数字1コードについて。
For Chapter X, the field list codes the number of data octets that may appear in a SysEx command that is coded in the chapter. Thus, the field list 0-255 specifies SysEx commands with 255 or fewer data octets, the field list 256-4294967295 specifies SysEx commands with more than 255 data octets but excludes commands with 255 or fewer data octets, and the field list 0 excludes all commands.
章Xの場合、フィールドリストのコードの章でコード化されたシステムエクスクルーシブコマンドで表示されることがあり、データのオクテットの数。このように、フィールドリスト0-255は、システムエクスクルーシブが255個の以下のデータオクテットでコマンドを指定し、フィールドリスト256から4294967295はすべて0除外をシステムエクスクルーシブが255以上のデータオクテットとコマンドが、255個の以下のデータオクテットでコマンドを除外指定し、フィールドリストコマンド。
A secondary parameter assignment syntax customizes Chapter X (see Appendix D for complete ABNF):
二次パラメータ割り当ての構文は、章Xを（完全なABNFのための付録Dを参照してください）カスタマイズ：
<parameter> = "__" <h-list> *( "_" <h-list> ) "__"
<パラメータ> = "__" <H-リスト> *（ "_" <H-リスト>） "__"
The assignment defines a class of SysEx commands whose Chapter X coding obeys the semantics of the assigned parameter. The command class is specified by listing the permitted values of the first N data octets that follow the SysEx 0xF0 command octet. Any SysEx command whose first N data octets match the list is a member of the class.
割り当ては、章Xコーディング割り当てられたパラメータの意味論に従うのSysExコマンドのクラスを定義します。コマンド・クラスは、システムエクスクルーシブの0xF0コマンドオクテットをたどる最初のN個のデータオクテットの許容値をリストで指定されています。その最初のN個のデータオクテットリストと一致する任意のSysExコマンドは、クラスのメンバーです。
Each <h-list> defines a data octet of the command as a dot-separated (".") list of one or more hexadecimal constants (such as "7F") or dash-separated hexadecimal ranges (such as "01-1F"). Underscores ("_") separate each <h-list>. Double-underscores ("__") delineate the data octet list.
各<H-list>は、ドットで区切られた（「」）（例えば、 『7F』など）は、1つまたは複数の16進定数のリストまたは（例えば01-1F」などのダッシュで区切ら進範囲としてコマンドのデータオクテットを定義します「）。アンダースコア（ "_"）は各<H-list>の分離します。ダブルアンダースコア（「__」）データオクテットリストを描きます。
Using this syntax, each assignment specifies a single SysEx command class. Session descriptions may use several assignments to the same (or different) parameters to specify complex Chapter X behaviors. The ordering behavior of multiple assignments follows the guidelines for chapter parameter assignments described earlier in this section.
この構文を使用して、それぞれの割り当ては、単一のSysExコマンドクラスを指定します。セッション記述は、複雑な章Xの動作を指定するには、同じ（または異なる）のパラメータにいくつかの割り当てを使用することができます。複数の割り当ての順序の動作は、このセクションで前述した章パラメータの割り当てのためのガイドラインに従います。
The example session description below illustrates the use of the chapter inclusion parameters:
例えば、セッション記述は、以下の章包含パラメータの使用を示します。
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ;
cm_used=__7E_00-7F_09_01.02.03__;
cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64;
ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N;
ch_anchor=P; ch_anchor=C7.64;
ch_anchor=__7E_00-7F_09_01.02.03__;
ch_anchor=__7F_00-7F_04_01.02__ (The a=fmtp line has been wrapped to fit the page to accommodate memo
formatting restrictions; it comprises a single line in SDP.)
The j_update parameter codes that the stream uses the open-loop policy. Most MIDI command-types are assigned to cm_unused and thus do not appear in the stream. As a consequence, the assignments to the first ch_never parameter reflect that most chapters are not in use.
ストリームがオープンループポリシーを使用していますj_アップデートパラメタコード。ほとんどのMIDIコマンドタイプがストリームに表示されませんので、cm_unusedするために割り当てられています。その結果、最初のch_neverパラメータへの割り当ては、ほとんどの章では、使用されていないことを反映しています。
Chapter N for several MIDI channels is assigned to ch_never. Chapter N for MIDI channels other than 4, 11, 12, and 13 may appear in the recovery journal, using the (default) ch_default semantics. In practice, this assignment pattern would reflect knowledge about a resilient rendering method in use for the excluded channels.
複数のMIDIチャンネルのための章Nはch_neverするために割り当てられています。章4以外のMIDIチャンネルのN、11、12、および13は、（デフォルト）ch_defaultのセマンティクスを使用して、回復ジャーナルに表示される場合があります。実際には、この割り当てパターンは除外チャンネルで使用されている弾力性のレンダリング方法についての知識を反映することになります。
The MIDI Program Change command and several MIDI Control Change controller numbers are assigned to ch_anchor. Note that the ordering of the ch_anchor Chapter C assignment after the ch_never command acts to override the ch_never assignment for the listed controller numbers (7 and 64).
MIDIプログラムチェンジコマンドといくつかのMIDIコントロールチェンジコントローラ番号がch_anchorに割り当てられています。 ch_neverコマンド作用後ch_anchor章Cの割り当ての順序が記載されているコントローラ番号（7及び64）のためのch_never割り当てを上書きすることに留意されたいです。
The assignment of command-type X to cm_unused excludes most SysEx commands from the stream. Exceptions are made for General MIDI System On/Off commands and for the Master Volume and Balance commands, via the use of the secondary assignment syntax. The cm_used assignment codes the exception, and the ch_anchor assignment codes how these commands are protected in Chapter X.
コマンド型Xの割り当てはストリームから除外ほとんどのSysExコマンドをcm_unusedします。例外は、二次割り当て構文を使用することにより、コマンドの一般的なMIDIシステムのオン/オフのためのマスターボリュームとバランスのコマンドのために作られています。 cm_used割り当てコード例外、およびこれらのコマンドは、章Xに保護されていますかch_anchor割り当てコード
C.3. Configuration Tools: Timestamp Semantics
C.3。コンフィギュレーションツール：タイムスタンプセマンティクス
The MIDI command section of the payload format consists of a list of commands, each with an associated timestamp. The semantics of command timestamps may be set during session configuration using the parameters we describe in this section.
ペイロード形式のMIDIコマンド部はコマンド、関連するタイムスタンプを有する各々のリストからなります。コマンドのタイムスタンプのセマンティクスは、我々は、このセクションで説明したパラメータを使用して、セッションの構成時に設定することができます。
The parameter tsmode specifies the timestamp semantics for a stream. The parameter takes on one of three token values: "comex", "async", or "buffer".
パラメータtsmodeは、ストリームのタイムスタンプのセマンティクスを指定します。パラメータは3つのトークンの値のいずれかになります：「COMEX」、「非同期」、または「バッファ」。
The default "comex" value specifies that timestamps code the execution time for a command (Appendix C.3.1) and supports the accurate transcoding of Standard MIDI Files (SMFs, [MIDI]). The "comex" value is also RECOMMENDED for new MIDI user-interface controller designs. The "async" value specifies an asynchronous timestamp sampling algorithm for time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of-arrival sources.
デフォルトの「COMEX」値は、そのタイムスタンプのコードにコマンドの実行時間（付録C.3.1）を指定すると、スタンダードMIDIファイル（SMFは、[MIDI]）の正確なトランスコーディングをサポートしています。 「COMEX」値は、新しいMIDIユーザインタフェースコントローラの設計用に推奨されています。 「非同期」の値は、到着時刻源（付録C.3.2）の非同期タイムスタンプサンプリングアルゴリズムを指定します。 「緩衝液」の値は、到着時刻ソースの同期タイムスタンプサンプリングアルゴリズム（付録C.3.3）を指定します。
Ancillary parameters MAY follow tsmode in a media description. We define these parameters in Appendices C.3.2 and C.3.3.
補助的なパラメータは、メディア記述にtsmodeに従うことができます。私たちは、付録C.3.2およびC.3.3でのこれらのパラメータを定義します。
C.3.1. The comex Algorithm
C.3.1。 COMEXアルゴリズム
The default "comex" (COMmand EXecution) tsmode value specifies the execution time for the command. With comex, the difference between two timestamps indicates the time delay between the execution of the commands. This difference may be zero, coding simultaneous execution.
デフォルトでは、「COMEX」（コマンド実行）tsmode値は、コマンドの実行時間を指定します。 COMEXと、2つのタイムスタンプの違いは、コマンドの実行の間の時間遅延を示しています。この違いは、同時実行をコーディング、0であってもよいです。
The comex interpretation of timestamps works well for transcoding a Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a timestamp for each MIDI command stored in the file. To transcode an SMF that uses metric time markers, use the SMF tempo map (encoded in the SMF as meta-events) to convert metric SMF timestamp units into seconds-based RTP timestamp units.
タイムスタンプのCOMEX解釈のSMFコードファイルに格納された各MIDIコマンドのタイムスタンプとして、RTP MIDIストリームに標準MIDIファイル（SMF、[MIDI]）をトランスコードに適しています。メートル時間マーカーを使用してSMFをトランスコードするために、秒ベースのRTPタイムスタンプユニットにメトリックSMFタイムスタンプの単位を変換する（メタイベントとしてSMFに符号化）SMFのテンポマップを使用します。
New MIDI controller designs (piano keyboard, drum pads, etc.) that support RTP MIDI and that have direct access to sensor data SHOULD use comex interpretation for timestamps so that simultaneous gestural events may be accurately coded by RTP MIDI.
RTP MIDIをサポートし、新しいMIDIコントローラーの設計（ピアノ、キーボード、ドラムパッドなど）は同時ジェスチャーイベントが正確にRTP MIDIで符号化することができるように、データは、タイムスタンプのためのCOMEX解釈を使用すべきであるセンサーに直接アクセスすることができます。
Comex is a poor choice for transcoding MIDI 1.0 DIN cables [MIDI], for a reason that we will now explain. A MIDI DIN cable is an asynchronous serial protocol (320 microseconds per MIDI byte). MIDI commands on a DIN cable are not tagged with timestamps. Instead, MIDI DIN receivers infer command timing from the time of arrival of the bytes. Thus, two two-byte MIDI commands that occur at a source simultaneously are encoded on a MIDI 1.0 DIN cable with a 640 microsecond time offset. A MIDI DIN receiver is unable to tell if this time offset existed in the source performance or is an artifact of the serial speed of the cable. However, the RTP MIDI comex interpretation of timestamps declares that a timestamp offset between two commands reflects the timing of the source performance.
COMEXは、私たちが今、説明します理由は、トランスコーディングMIDI 1.0 DINケーブル[MIDI]、貧しい人々のための選択肢です。 MIDI DINケーブルは非同期シリアルプロトコル（MIDIバイト当たり320マイクロ秒）です。 DINケーブルのMIDIコマンドは、タイムスタンプでタグ付けされていません。代わりに、MIDI DIN受信機は、バイトの到着時刻からコマンドタイミングを推測します。したがって、同時にソースで発生する2つの2バイトMIDIコマンドは、オフセット640マイクロ秒の時間でMIDI 1.0 DINケーブル上に符号化されます。 MIDI DIN受信機は、この時間オフセットは、ソースのパフォーマンスに存在していたか、ケーブルのシリアルスピードの人工物であれば伝えることができません。しかし、タイムスタンプのRTP MIDI COMEX解釈は二つのコマンド間のオフセットのタイムスタンプは、元のパフォーマンスのタイミングを反映していることを宣言します。
This semantic mismatch is the reason that comex is a poor choice for transcoding MIDI DIN cables. Note that the choice of the RTP timestamp rate (Sections 6.1 and 6.2 in the main text) cannot fix this inaccuracy issue. In the sections that follow, we describe two alternative timestamp interpretations ("async" and "buffer") that are a better match to MIDI 1.0 DIN cable timing and to other MIDI time-of-arrival sources.
このセマンティック不一致は、COMEXのトランスコーディングMIDI DINケーブルのお粗末な選択であることの理由です。 RTPタイムスタンプ率（セクション6.1および本文中6.2）の選択は、この不正確さの問題を修正することができないことに注意してください。以下のセクションでは、我々は、MIDI 1.0 DINケーブルタイミングと他のMIDI到着時間ソースに良好に一致している二つの代替タイムスタンプ解釈（「非同期」と「バッファ」）を記述する。
The octpos, linerate, and mperiod ancillary parameters (defined below) SHOULD NOT be used with comex.
タコ、解放、及び期間の補助パラメータ（以下に定義）は、COMEXには使用できません。
C.3.2. The async Algorithm
C.3.2。非同期アルゴリズム
The "async" tsmode value specifies the asynchronous sampling of a MIDI time-of-arrival source. In asynchronous sampling, the moment an octet is received from a source, it is labelled with a wall-clock time value. The time value has RTP timestamp units.
「非同期」tsmode値はMIDI到着時刻ソースの非同期サンプリングを指定します。非同期サンプリングにおいて、オクテットはソースから受信される瞬間は、それがウォールクロック時間値で標識されます。時間値は、RTPタイムスタンプの単位を有します。
The octpos ancillary parameter defines how RTP command timestamps are derived from octet time values. If octpos has the token value "first", a timestamp codes the time value of the first octet of the command. If octpos has the token value "last", a timestamp codes the time value of the last octet of the command. If the octpos parameter does not appear in the media description, the sender does not know which octet of the command the timestamp references (for example, the sender may be relying on an operating system service that does not specify this information).
octpos補助的なパラメータは、RTPコマンドのタイムスタンプはオクテット時間値から導出されている方法を定義します。 octposは、「最初の」トークン値、タイムスタンプコードコマンドの最初のオクテットの時間的価値を持っている場合。 octposは、コマンドの最後のオクテットの時間的価値、「最後の」タイムスタンプコードをトークン値を持っている場合。 octposパラメータはメディア記述に表示されない場合、送信者は、（例えば、送信者がこの情報を指定していないオペレーティングシステムサービスに依存することがある。）そのコマンドのオクテットのタイムスタンプの参照を知りません。
The octpos semantics refer to the first or last octet of a command as it appears on a time-of-arrival MIDI source, not as it appears in an RTP MIDI packet. This distinction is significant because the RTP coding may contain octets that are not present in the source. For example, the status octet of the first MIDI command in a packet may have been added to the MIDI stream during transcoding to comply with the RTP MIDI running status requirements (Section 3.2).
それは到着時間MIDIソースに表示されるoctposセマンティクスは、それがRTP MIDIパケットに表示されていないとして、コマンドの最初または最後のオクテットを参照してください。 RTPコーディングがソースに存在しないオクテットを含んでよいので、この区別は重要です。例えば、パケットの最初のMIDIコマンドのステータスオクテットはRTP MIDI実行状態要求（セクション3.2）に準拠するトランスコーディング中にMIDIストリームに追加されていてもよいです。
The linerate ancillary parameter defines the timespan of one MIDI octet on the transmission medium of the MIDI source to be sampled (such as a MIDI 1.0 DIN cable). The parameter has units of nanoseconds and takes on integral values. For MIDI 1.0 DIN cables, the correct linerate value is 320000 (this value is also the default value for the parameter).
回線レートの補助パラメータは、（例えばMIDI 1.0 DINケーブルなど）をサンプリングするMIDIソースの伝送媒体上の1つのMIDIオクテットのタイムスパンを定義します。パラメータは、ナノ秒の単位を持っており、整数値をとります。 MIDI 1.0 DINケーブルの場合は、正しい回線レート値（この値は、パラメータのデフォルト値です）320000です。
We now show a session description example for the async algorithm. Consider a sender that is transcoding a MIDI 1.0 DIN cable source into RTP. The sender runs on a computing platform that assigns time values to every incoming octet of the source, and the sender uses the time values to label the first octet of each command in the RTP packet. This session description describes the transcoding:
私たちは今、非同期アルゴリズムのためのセッション記述例を示しています。 RTPへのMIDI 1.0 DINケーブルソースをトランスコードされた送信者を考えてみましょう。送信者は、ソースのすべての着信オクテットまでの時間値を割り当てるコンピューティング・プラットフォーム上で実行され、送信者がRTPパケットに各コマンドの最初のオクテットを標識するために時間値を使用します。このセッション記述は、トランスコーディングについて説明します。
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100 a=sendonly a=fmtp:96 tsmode=async; linerate=320000; octpos=first
96 RTP-MIDI / 44100 A = sendonlyの：IP4 first.example.net S =例、T = 0、M = IP4 192.0.2.94 INオーディオ5004 RTP / AVP 96個のC =を= rtpmap IN V = 0 0 =ラザロ2520644554 2838152170 =のfmtp：96 tsmode =非同期。回線レート= 320000; octpos =最初の
C.3.3. The buffer Algorithm
C.3.3。バッファアルゴリズム
The "buffer" tsmode value specifies the synchronous sampling of a MIDI time-of-arrival source.
「バッファー」tsmode値はMIDI到着時刻ソースの同期サンプリングを指定します。
In synchronous sampling, octets received from a source are placed in a holding buffer upon arrival. At periodic intervals, the RTP sender examines the buffer. The sender removes complete commands from the buffer and codes those commands in an RTP packet. The command timestamp codes the moment of buffer examination, expressed in RTP timestamp units. Note that several commands may have the same timestamp value.
同期サンプリングでは、ソースから受信したオクテットは到着時に保持バッファに置かれます。定期的な間隔で、RTPの送信者は、バッファを調べます。送信者は、RTPパケット内のバッファとコードそれらのコマンドをコマンドから完全に削除されます。コマンドのタイムスタンプコードバッファ検査のモーメントは、RTPタイムスタンプ単位で表さ。いくつかのコマンドは、同じタイムスタンプ値を有することができることに注意してください。
The mperiod ancillary parameter defines the nominal periodic sampling interval. The parameter takes on positive integral values and has RTP timestamp units.
mperiod補助的なパラメータは、名目上の定期的なサンプリング間隔を定義します。パラメータは正の整数値をとると、RTPタイムスタンプの単位を有します。
The octpos ancillary parameter, defined in Appendix C.3.2 for asynchronous sampling, plays a different role in synchronous sampling. In synchronous sampling, the parameter specifies the timestamp semantics of a command whose octets span several sampling periods.
非同期サンプリングについては、付録C.3.2に定義されてoctpos補助的なパラメータは、同期サンプリングで異なる役割を果たしています。同期サンプリングでは、パラメータはオクテットいくつかのサンプリング周期にまたがるコマンドのタイムスタンプのセマンティクスを指定します。
If octpos has the token value "first", the timestamp reflects the arrival period of the first octet of the command. If octpos has the token value "last", the timestamp reflects the arrival period of the last octet of the command. The octpos semantics refer to the first or last octet of the command as it appears on a time-of-arrival source, not as it appears in the RTP packet.
octposは、「最初の」トークン値を持っている場合、タイムスタンプはコマンドの最初のオクテットの到着時間を反映しています。 octposが「最後」トークン値を持っている場合、タイムスタンプはコマンドの最後のオクテットの到着時間を反映しています。それは到着時刻ソースに表示されるoctposセマンティクスは、RTPパケットに表示されていないとして、コマンドの最初または最後のオクテットを参照してください。
If the octpos parameter does not appear in the media description, the timestamp MAY reflect the arrival period of any octet of the command; senders use this option to signal a lack of knowledge about the timing details of the buffering process at subcommand granularity.
octposパラメータはメディア記述に表示されない場合、タイムスタンプはコマンドの任意のオクテットの到着時間を反映することができます。送信者は、サブコマンドの粒度でバッファリング処理のタイミングの詳細についての知識の欠如を知らせるために、このオプションを使用します。
We now show a session description example for the buffer algorithm. Consider a sender that is transcoding a MIDI 1.0 DIN cable source into RTP. The sender runs on a computing platform that places source data into a buffer upon receipt. The sender polls the buffer 1000 times a second, extracts all complete commands from the buffer, and places the commands in an RTP packet. This session description describes the transcoding: v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB8::7F2E:172A:1E24 a=rtpmap:96 rtp-midi/44100 a=sendonly a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44
現在のバッファアルゴリズムのためのセッション記述例を示しています。 RTPへのMIDI 1.0 DINケーブルソースをトランスコードされた送信者を考えてみましょう。送信者は受信時にバッファへのソースデータを置くコンピューティング・プラットフォーム上で動作します。送信者をポーリングバッファ1000倍目は、バッファからすべての完全なコマンドを抽出し、RTPパケット内のコマンドを配置します。このセッション記述は、トランスコーディングを説明：IP6 IN V = 0 0 =ラザロ2520644554 2838152170 first.example.net S = T例IP6 2001年= 0、M =オーディオ5004 RTP / AVP 96個のC =を：DB8 :: 7F2E：172A： 1E24 = rtpmap：96 RTP-MIDI / 44100 = sendonlyの=のfmtp：96 tsmode =バッファと回線レート= 320000; octpos =最後。 mperiod = 44
The mperiod value of 44 is derived by dividing the clock rate specified by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate and rounding to the nearest integer. Command timestamps might not increment by exact multiples of 44, as the actual sampling period might not precisely match the nominal mperiod value.
44のmperiod値は、1000Hzのバッファサンプリングレートによってrtpmap属性（44100ヘルツ）で指定されたクロックレートを分割し、最も近い整数に丸めることによって導出されます。コマンドのタイムスタンプを正確に公称mperiod値と一致しない場合があり、実際のサンプリング周期として、44の正確な倍数ずつ増加しないことがあります。
C.4. Configuration Tools: Packet Timing Tools
C.4。コンフィギュレーションツール：パケットタイミングツール
In this appendix, we describe session configuration tools for customizing the temporal behavior of MIDI stream packets.
この付録では、我々は、MIDIストリームパケットの時間的挙動をカスタマイズするためのセッション構成ツールについて説明します。
C.4.1. Packet Duration Tools
C.4.1。パケット持続時間ツール
Senders control the granularity of a stream by setting the temporal duration ("media time") of the packets in the stream. Short media times (20 ms or less) often imply an interactive session. Longer media times (100 ms or more) usually indicate a content-streaming session. The RTP AVP profile [RFC3551] recommends audio packet media times in a range from 0 to 200 ms.
送信者は、ストリーム内のパケットの持続時間（「メディア時間」）を設定することにより、ストリームの粒度を制御します。ショートメディア回（20ms以下）は、多くの場合、対話型セッションを意味します。長いメディア回（100 ms以上）は、通常、コンテンツストリーミングセッションを示しています。 RTP AVPプロファイル[RFC3551]は0から200ミリ秒の範囲でオーディオパケットメディア時間をお勧めします。
By default, an RTP receiver dynamically senses the media time of packets in a stream and chooses the length of its playout buffer to match the stream. A receiver typically sizes its playout buffer to fit several audio packets and adjusts the buffer length to reflect the network jitter and the sender timing fidelity.
デフォルトでは、RTP受信機は、動的ストリーム内のパケットのメディア時間を感知し、ストリームに一致するように、その再生バッファの長さを選択します。受信機は、典型的には、いくつかのオーディオパケットに合うようにその再生バッファのサイズとネットワークジッタと送信タイミングの忠実度を反映するために、バッファの長さを調整します。
Alternatively, the packet media time may be statically set during session configuration. Session descriptions MAY use the RTP MIDI parameter rtp_ptime to set the recommended media time for a packet. Session descriptions MAY also use the RTP MIDI parameter rtp_maxptime to set the maximum media time for a packet permitted in a stream. Both parameters MAY be used together to configure a stream.
また、パケットメディア時間は、静的セッションの構成時に設定することができます。セッション記述は、パケットのための推奨メディア時間を設定するには、RTP MIDIパラメタrtp_ptimeを使用するかもしれません。セッション記述は、ストリームで許可パケットの最大のメディア時間を設定するには、RTP MIDIパラメタrtp_maxptimeを使用するかもしれません。両方のパラメータは、ストリームを構成するために一緒に使用されるかもしれません。
The values assigned to the rtp_ptime and rtp_maxptime parameters have the units of the RTP timestamp for the stream, as set by the rtpmap attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of a stream to 44100 Hz, a maximum packet media time of 10 ms is coded by setting rtp_maxptime=441. As stated in the Appendix C preamble, the senders and receivers of a stream MUST agree on common values for rtp_ptime and rtp_maxptime if the parameters appear in the media description for the stream.
rtpmap属性（6.1節を参照）によって設定されるようにrtp_ptimeとrtp_maxptimeパラメータに割り当てられた値は、ストリームのためのRTPタイムスタンプの単位を持っています。 rtpmapが44100ヘルツのストリームのクロック速度を設定する場合したがって、10ミリ秒の最大パケットメディア時間はrtp_maxptime = 441を設定して符号化されます。付録Cの前文に述べたようにパラメータは、ストリームのメディア記述に表示された場合、ストリームの送信側と受信側はrtp_ptimeとrtp_maxptimeのための共通の値に同意しなければなりません。
0 ms is a reasonable media time value for MIDI packets and is often used in low-latency interactive applications. In a packet with a 0 ms media time, all commands execute at the instant they are coded by the packet timestamp. The session description below configures all packets in the stream to have 0 ms media time:
0ミリ秒は、MIDIのパケットのための合理的なメディア時間値であり、多くの場合、低レイテンシの対話型アプリケーションで使用されています。 0ミリ秒のメディア時間を有するパケットは、すべてのコマンドは、それらが、パケットのタイムスタンプにより符号化された瞬間に実行されます。以下のセッション記述は、ストリーム内のすべてのパケットが0ミリ秒のメディア時間を持つように設定します。
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 rtp_ptime=0; rtp_maxptime=0
96 RTP-MIDI / 44100 A =のfmtp：IP4 first.example.net S =例、T = 0、M = IP4 192.0.2.94 INオーディオ5004 RTP / AVP 96個のC =を= rtpmap IN V = 0 0 =ラザロ2520644554 2838152170 ：96 rtp_ptime = 0。 rtp_maxptime = 0
The session attributes ptime and maxptime [RFC4566] MUST NOT be used to configure an RTP MIDI stream. Sessions MUST use rtp_ptime in lieu of ptime and MUST use rtp_maxptime in lieu of maxptime. RTP MIDI defines its own parameters for media time configuration because 0 ms values for ptime and maxptime are forbidden by [RFC3264] but are essential for certain applications of RTP MIDI.
セッションは、PTIMEとmaxptime [RFC4566]はRTP MIDIストリームを構成するために使用してはいけません属性。セッションはPTIMEの代わりにrtp_ptimeを使用しなければならないとmaxptimeの代わりにrtp_maxptimeを使用しなければなりません。 PTIMEとmaxptime 0ミリ秒の値は[RFC3264]で禁止が、RTP MIDIの特定の用途のために不可欠されているので、RTP MIDIメディア時間設定のための独自のパラメータを定義します。
See the Appendix C.7 examples for additional discussion about using rtp_ptime and rtp_maxptime for session configuration.
セッション構成のためrtp_ptimeとrtp_maxptimeの使用に関する追加説明については、付録C.7の例を参照してください。
C.4.2. The guardtime Parameter
C.4.2。 guardtimeパラメータ
RTP permits a sender to stop sending audio packets for an arbitrary period of time during a session. When sending resumes, the RTP sequence number series continues unbroken, and the RTP timestamp value reflects the media time silence gap.
RTPは、セッション中に任意の時間のためのオーディオパケットの送信を停止するために、送信者を許可します。履歴書を送信する場合、RTPシーケンス番号シリーズは切れ目のない継続、及びRTPタイムスタンプの値は、メディア時間無音ギャップを反映しています。
This RTP feature has its roots in telephony, but it is also well-matched to interactive MIDI sessions, as players may fall silent for several seconds during (or between) songs.
このRTP機能は、電話でそのルーツを持っていますが、プレイヤーは（または間）曲中に数秒間沈黙落ちることとして、それは、また、インタラクティブなMIDIセッションによくマッチしています。
Certain MIDI applications benefit from a slight enhancement to this RTP feature. In interactive applications, receivers may use online network models to guide heuristics for handling lost and late RTP packets. These models may work poorly if a sender ceases packet transmission for long periods of time.
特定のMIDIアプリケーションでは、このRTP機能にわずかな強化の恩恵を受ける。インタラクティブなアプリケーションでは、受信機は、失われたと後期RTPパケットを処理するための経験則を導くために、オンラインネットワークモデルを使用することができます。送信者が長期間のパケットの送信を中止する場合は、これらのモデルは、十分に機能しないことがあります。
Session descriptions may use the parameter guardtime to set a minimum sending rate for a media session. The value assigned to guardtime codes the maximum separation time between two sequential packets, as expressed in RTP timestamp units.
セッション記述は、メディアセッションの最小送信レートを設定するには、パラメータguardtimeを使用することができます。 RTPタイムスタンプ単位で表されるように、二つの連続するパケットの間にコードを最大分離時間をguardtimeに割り当てられた値。
Typical guardtime values are 500-2000 ms. This value range is not a normative bound, and parties SHOULD be prepared to process values outside this range.
典型的なguardtime値は500から2000ミリ秒です。この値の範囲は結合規範的ではなく、当事者は、この範囲外の値を処理するために準備されるべきです。
The congestion control requirements for sender implementations (described in Section 8 and [RFC3550]) take precedence over the guardtime parameter. Thus, if the guardtime parameter requests a minimum sending rate, but sending at this rate would violate the congestion control requirements, senders MUST ignore the guardtime parameter value. In this case, senders SHOULD use the lowest minimum sending rate that satisfies the congestion control requirements.
（セクション8と[RFC3550]に記載されている）送信者実装のための輻輳制御要件はguardtimeパラメータよりも優先されます。 guardtimeパラメータは、最小レートを送信しますが、輻輳制御の要件に違反するこのレートで送信を要求した場合このように、送信者はguardtimeパラメータの値を無視しなければなりません。この場合、送信者は、輻輳制御要件を満たす最低の最小送信レートを使用すべきです。
Below, we show a session description that uses the guardtime parameter.
以下に、我々はguardtimeパラメータを使用してセッション記述を示しています。
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB8::7F2E:172A:1E24 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0
DB8 :: 7F2E：172A：1E24 A = rtpmap：96 RTP IP6 first.example.net S =例、T = 0、M = IP6 2001年オーディオ5004 RTP / AVP 96個のC = IN V = 0 0 =ラザロ2520644554 2838152170 -midi / 44100 =のfmtp：96 guardtime = 44100。 rtp_ptime = 0; rtp_maxptime = 0
C.5. Configuration Tools: Stream Description
C.5。コンフィギュレーションツール：ストリーム説明
As we discussed in Section 2.1, a party may send several RTP MIDI streams in the same RTP session, and several RTP sessions that carry MIDI may appear in a multimedia session.
我々は2.1節で述べたように、パーティには、いくつかのRTP MIDIが同じRTPセッションでストリーム、およびMIDIを運ぶいくつかのRTPセッションがマルチメディアセッションに表示される場合があります送信してもよいです。
By default, the MIDI name space (16 channels + systems) of each RTP stream sent by a party in a multimedia session is independent. By independent, we mean three distinct things:
デフォルトでは、マルチメディアセッションでのパーティによって送信される各RTPストリームのMIDI名前スペース（16チャンネル+システム）が独立しています。独立したことで、我々は、3つの異なるものを意味します：
o If a party sends two RTP MIDI streams (A and B), MIDI voice channel 0 in stream A is a different "channel 0" than MIDI voice channel 0 in stream B.
当事者は、2つのRTP MIDIストリーム（AおよびB）を送信する場合は、O、ストリームAにおけるMIDI音声チャンネル0は、ストリームBにおけるMIDI音声チャンネル0とは異なる「チャネル0」であります
o MIDI voice channel 0 in stream B is not considered to be "channel 16" of a 32-channel MIDI voice channel space whose "channel 0" is channel 0 of stream A.
OストリームBにおけるMIDI音声チャネル0は「チャネル0」のストリームAのチャネル0の32チャンネルMIDI音声チャネル空間の「チャネル16」であるとは考えられません
o Streams sent by different parties over different RTP sessions, or over the same RTP session but with different payload type numbers, do not share the association that is shared by a MIDI cable pair that cross-connects two devices in a MIDI 1.0 DIN network. By default, this association is only held by streams sent by different parties in the same RTP session that use the same payload type number.
異なるRTPセッション上、または同一のRTPセッションを介して異なるペイロードタイプ番号と異なるパーティによって送信されたストリームO、MIDI 1.0 DINのネットワーク内の2つのデバイスを相互接続するMIDIケーブル対によって共有されているアソシエーションを共有しません。デフォルトでは、この関連付けは、同じペイロードタイプ番号を使用し、同じRTPセッションにおいて異なるパーティによって送信されたストリームに保持されています。
In this appendix, we show how to express that specific RTP MIDI streams in a multimedia session are not independent but instead are related in one of the three ways defined above. We use two tools to express these relations:
この付録では、我々は特定のRTP MIDIは、マルチメディアセッション中にストリームすることを表現するためには独立していないが、代わりに上記で定義された3つの方法のいずれかで関連している方法を示しています。私たちは、これらの関係を表現するために2つのツールを使用します。
o The musicport parameter. This parameter is assigned a non-negative integer value between 0 and 4294967295. It appears in the fmtp lines of payload types.
musicportパラメータO。このパラメータは、それがペイロードタイプのfmtp線に表示され、0から4294967295の間の非負の整数値が割り当てられます。
o The FID grouping attribute [RFC5888] signals that several RTP sessions in a multimedia session are using the musicport parameter to express an inter-session relationship.
FIDグループ属性[RFC5888] oをマルチメディアセッション内のいくつかのRTPセッションがインターセッションの関係を表現するためにmusicportパラメータを使用していることを知らせます。
If a multimedia session has several payload types whose musicport parameters are assigned the same integer value, streams using these payload types share an "identity relationship" (including streams that use the same payload type). Streams in an identity relationship share two properties:
マルチメディアセッションは、そのmusicportパラメータ同じ整数値を割り当てられているいくつかのペイロードタイプを有する場合、これらのペイロードタイプを使用して、ストリーム（同じペイロードタイプを使用してストリームを含む）「アイデンティティ関係を共有」。アイデンティティ関係のシェアで2つのプロパティをストリーム：
o Identity relationship streams sent by the same party target the same MIDI name space. Thus, if streams A and B share an identity relationship, voice channel 0 in stream A is the same "channel 0" as voice channel 0 in stream B.
O同じパーティによって送られたアイデンティティ関係ストリームが同じMIDI名前空間をターゲットにしています。ストリームA及びBは、同一関係を共有する場合したがって、ストリームAにおける音声チャネル0は、ストリームBの音声チャネル0と同じ「チャネル0」であります
o Pairs of identity relationship streams that are sent by different parties share the association that is shared by a MIDI cable pair that cross-connects two devices in a MIDI 1.0 DIN network.
O異なるパーティによって送信されたアイデンティティ関係ストリームの対は、MIDI 1.0 DINのネットワーク内の2つのデバイスを相互接続するMIDIケーブル対によって共有されているアソシエーションを共有します。
A party MUST NOT send two RTP MIDI streams that share an identity relationship in the same RTP session. Instead, each stream MUST be in a separate RTP session. As explained in Section 2.1, this restriction is necessary to support the RTP MIDI method for the synchronization of streams that share a MIDI name space.
パーティーは同じRTPセッションにおけるアイデンティティ関係を共有する2つのRTP MIDIストリームを送ってはいけません。代わりに、各ストリームは、別々のRTPセッションでなければなりません。セクション2.1で説明したように、この制限は、MIDI名前空間を共有ストリームの同期のためのRTP MIDIメソッドをサポートする必要があります。
If a multimedia session has several payload types whose musicport parameters are assigned sequential values (i.e., i, i+1, ... i+k), the streams using the payload types share an "ordered relationship". For example, if payload type A assigns 2 to musicport and payload type B assigns 3 to musicport, A and B are in an ordered relationship.
マルチメディアセッションは、そのmusicportパラメータ連続した値を割り当てられているいくつかのペイロードタイプを有する場合（即ち、I、I + 1、...、I + K）、ペイロードタイプを使用してストリームが「順序付け関係を共有」。ペイロードタイプAはmusicportに3を割り当てmusicportペイロードタイプBに2を割り当てた場合、例えば、A及びBは、順序付けられた関係にあります。
Streams in an ordered relationship that are sent by the same party are considered by renderers to form a single larger MIDI space. For example, if stream A has a musicport value of 2 and stream B has a musicport value of 3, MIDI voice channel 0 in stream B is considered to be voice channel 16 in the larger MIDI space formed by the relationship. Note that it is possible for streams to participate in both an identity relationship and an ordered relationship.
同じ当事者によって送信された注文関係のストリームは、単一の大きなMIDI空間を形成するためにレンダラーによって考えられています。ストリームA 2のmusicport値とストリームBは3のmusicport値を有している場合、例えば、ストリームBにおけるMIDI音声チャンネル0の関係によって形成されるより大きなMIDI空間における音声チャネル16であると考えられます。ストリームがアイデンティティ関係と注文した関係の両方に参加することが可能であることに注意してください。
We now state several rules for using musicport:
私たちは今、musicportを使用するためのいくつかのルールを述べます：
o If streams from several RTP sessions in a multimedia session use the musicport parameter, the RTP sessions MUST be grouped using the FID grouping attribute defined in [RFC5888].
マルチメディアセッション内のいくつかのRTPセッションからストリームがmusicportパラメータを使用する場合、O、RTPセッションは[RFC5888]で定義されたFIDグルーピング属性を使用してグループ化されなければなりません。
o An ordered or identity relationship MUST NOT contain both native RTP MIDI streams and mpeg4-generic RTP MIDI streams. An exception applies if a relationship consists of sendonly and recvonly (but not sendrecv) streams. In this case, the sendonly streams MUST NOT contain both types of streams, and the recvonly streams MUST NOT contain both types of streams.
O命じまたはアイデンティティ関係はネイティブのRTP MIDIストリームとmpeg4-ジェネリックRTP MIDIストリームの両方を含めることはできません。関係がsendonlyでがrecvonly（しかしSENDRECVない）ストリームで構成されている場合は例外が適用されます。この場合、sendonlyのストリームは、ストリームの両方のタイプを含めることはできません、がrecvonlyストリームは、ストリームの両方のタイプを含めることはできません。
o It is possible to construct identity relationships that violate the recovery journal mandate (for example, sending NoteOns for a voice channel on stream A and NoteOffs for the same voice channel on stream B). Parties MUST NOT generate (or accept) session descriptions that exhibit this flaw.
O回復ジャーナル命令（例えば、ストリームBの同じ音声チャネル用のストリームAとNoteOffs上の音声チャネルのためのNoteOnsを送信）に違反アイデンティティ関係を構築することが可能です。締約国は、この欠陥を示すセッション記述を生成する（または受け入れ）してはなりません。
o Other payload formats MAY define musicport media type parameters. Formats would define these parameters so that their sessions could be bundled into RTP MIDI name spaces. The parameter definitions MUST be compatible with the musicport semantics defined in this appendix.
O他のペイロードフォーマットはmusicportメディアタイプのパラメータを定義することができます。そのセッションがRTP MIDI名前空間にバンドルすることができるようにフォーマットは、これらのパラメータを定義します。パラメータの定義は、この付録で定義されてmusicportセマンティクスと互換性がなければなりません。
As a rule, at most one payload type in a relationship may specify a MIDI renderer. An exception to the rule applies to relationships that contain sendonly and recvonly streams but no sendrecv streams. In this case, one sendonly session and one recvonly session may each define a renderer.
原則として、関係の中で最も1つのペイロードタイプは、MIDIレンダラーを指定することもできます。規則の例外は、sendonlyで含まれている関係がrecvonlyの流れが、なしのsendrecvストリームに適用されます。この場合、一方のsendonlyのセッションと一つがrecvonlyセッションは、各レンダラを定義することができます。
Renderer specification in a relationship may be done using the tools described in Appendix C.6. These tools work for both native streams and mpeg4-generic streams. An mpeg4-generic stream that uses the Appendix C.6 tools MUST set all "config" parameters to the empty string ("").
関係のレンダラー仕様は、付録C.6で説明するツールを使用して行うことができます。これらのツールは、ネイティブのストリームとmpeg4-ジェネリックストリームの両方のために働きます。付録C.6ツールを使用していますmpeg4-ジェネリックストリームが空の文字列（「」）に、すべての「設定」のパラメータを設定しなければなりません。
Alternatively, for mpeg4-generic streams, renderer specification may be done by setting one "config" parameter in the relationship to the renderer configuration string and all other config parameters to the empty string ("").
あるいは、MPEG4-ジェネリックストリームについてレンダラ仕様はレンダラ構成文字列と空の文字列（「」）へのすべての他の設定パラメータに関係で一つの「設定」のパラメータを設定することによって行うことができます。
We now define sender and receiver rules that apply when a party sends several streams that target the same MIDI name space.
私たちは今、当事者が同じMIDI名前空間を対象と複数のストリームを送信するときに適用送信者と受信者のルールを定義します。
Senders MAY use the subsetting parameters (Appendix C.1) to predefine the partitioning of commands between streams, or they MAY use a dynamic partitioning strategy.
送信者は、ストリーム間のコマンドの分配を事前定義するサブセットパラメータ（付録C.1）を使用することができる、またはそれらは動的分割戦略を使用するかもしれません。
Receivers that merge identity relationship streams into a single MIDI command stream MUST maintain the structural integrity of the MIDI commands coded in each stream during the merging process, in the same way that software that merges traditional MIDI 1.0 DIN cable flows is responsible for creating a merged command flow compatible with [MIDI].
アイデンティティの関係は、単一のMIDIコマンドストリームにストリームをマージレシーバは、伝統的なMIDI 1.0 DINケーブルが流れマージソフトウェアがマージされたを作成するための責任があるのと同じように、マージ処理中に各ストリームにコード化されたMIDIコマンドの構造的完全性を維持しなければなりません[MIDI]と互換性のあるコマンドの流れ。
Senders MUST partition the name space so that the rendered MIDI performance does not contain indefinite artifacts (as defined in Section 4). This responsibility holds even if all streams are sent over reliable transport, as different stream latencies may yield indefinite artifacts. For example, stuck notes may occur in a performance split over two TCP streams, if NoteOn commands are sent on one stream and NoteOff commands are sent on the other.
（セクション4で定義されるように）レンダリングされたMIDI性能は無期限の成果物が含まれないように送信者には、名前空間を分割しなければなりません。この責任は、異なるストリームの待ち時間が無期限のアーティファクトをもたらす可能性として、すべてのストリームは、信頼性の高いトランスポートを介して送信された場合でも保持しています。例えば、NoteOnコマンドは、他の上で送信されている1つのストリームにし、コマンドNoteOff送信された場合の注意事項は、2基のTCPストリーム上でパフォーマンス分割で発生する可能性が立ち往生。
Senders MUST NOT split a Registered Parameter Numbers (RPN) or Non-Registered Parameter Numbers (NRPN) transaction appearing on a MIDI channel across multiple identity relationship sessions. Receivers MUST assume that the RPN/NRPN transactions that appear on different identity relationship sessions are independent and MUST preserve transactional integrity during the MIDI merge.
送信者は、複数のアイデンティティ関係セッション間でMIDIチャンネルに登場する登録パラメータ番号（RPN）または未登録のパラメータ番号（NRPN）トランザクションを分割してはなりません。レシーバは異なるアイデンティティ関係セッションに表示されるRPN / NRPNの取引は独立しており、MIDIマージ中にトランザクションの整合性を維持しなければならないと仮定しなければなりません。
A simple way to safely partition voice channel commands is to place all MIDI commands for a particular voice channel into the same session. Safe partitioning of MIDI system commands may be more complicated for sessions that extensively use System Exclusive.
安全に音声チャネルコマンドを分割する簡単な方法は、すべてのMIDIは、同じセッションに特定の音声チャンネルのためにコマンドを配置することです。 MIDIシステムコマンドの安全なパーティショニングは、広範囲にシステムエクスクルーシブを使用するセッションのために、より複雑になることがあります。
We now show several session description examples that use the musicport parameter.
現在musicportパラメータを使用して、いくつかのセッション記述例を示しています。
Our first session description example shows two RTP MIDI streams that drive the same General MIDI decoder. The sender partitions MIDI commands between the streams dynamically. The musicport values indicate that the streams share an identity relationship.
私たちの最初のセッション記述の例では、同じ一般的なMIDIデコーダをドライブ2つのRTP MIDIストリームを示しています。 MIDIを動的ストリーム間のコマンド送信元のパーティション。 musicport値はストリームがアイデンティティ関係を共有することを示しています。
v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 5004 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100
a=mid:1
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12
m=audio 5006 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100
a=mid:2
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; musicport=12
(The a=fmtp lines have been wrapped to fit the page to accommodate memo formatting restrictions; they comprise single lines in SDP.)
（A =のfmtpラインが制限をフォーマットするメモに対応するために、ページに収まるようにラップされています。彼らは、SDP内の単一の行を含みます。）
Recall that Section 2.1 defines rules for streams that target the same MIDI name space. Those rules, implemented in the example above, require that each stream resides in a separate RTP session and that the grouping mechanisms defined in [RFC5888] signal an inter-session relationship. The "group" and "mid" attribute lines implement this grouping mechanism.
2.1は、同じMIDI名前空間を対象ストリームのためのルールを定義するセクションを思い出してください。上記の例で実装これらのルールは、各ストリームは別々のRTPセッションに存在し、[RFC5888]で定義されたグループ化機構はインターセッション関係を通知することをすることを必要とします。 「グループ」と「中期」属性行は、このグループ化メカニズムを実装します。
A variant on this example, whose session description is not shown, would use two streams in an identity relationship driving the same MIDI renderer, each with a different transport type. One stream would use UDP and would be dedicated to real-time messages. A second stream would use TCP [RFC4571] and would be used for SysEx bulk data messages.
そのセッション記述は示されていないこの例で変異体は、異なるトランスポート・タイプと同じMIDIレンダラを駆動する同一の関係で二つの流れ、それぞれを使用します。一つのストリームは、UDPを使うでしょうし、リアルタイムのメッセージに捧げられます。第二の流れは、TCP [RFC4571]を使用すると、システムエクスクルーシブバルクデータメッセージのために使用されるであろう。
In the next example, two mpeg4-generic streams form an ordered relationship to drive a Structured Audio decoder with 32 MIDI voice channels. Both streams reside in the same RTP session.
次の例では、2つのMPEG4-ジェネリックストリームは32個のMIDI音声チャネルで構成オーディオデコーダを駆動するように命じた関係を形成します。両方のストリームは、同じRTPセッションに存在します。
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5006 RTP/AVP 96 97
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=5
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=6; render=synthetic;
rinit=audio/asc;
url="http://example.com/cardinal.asc";
cid="azsldkaslkdjqpwojdkmsldkfpe"
(The a=fmtp lines have been wrapped to fit the page to accommodate memo formatting restrictions; they comprise single lines in SDP.)
（A =のfmtpラインが制限をフォーマットするメモに対応するために、ページに収まるようにラップされています。彼らは、SDP内の単一の行を含みます。）
The sequential musicport values for the two sessions establish the ordered relationship. The musicport=5 session maps to Structured Audio extended channels range 0-15; the musicport=6 session maps to Structured Audio extended channels range 16-31.
二つのセッションのためのシーケンシャルmusicport値は、注文した関係を確立します。構造化されたオーディオ拡張チャンネルへのmusicport = 5つのセッション地図は0-15の範囲。構造化されたオーディオ拡張チャンネルへのmusicport = 6セッション地図は16-31の範囲です。
Both config strings are empty. The configuration data is specified by parameters that appear in the fmtp line of the second media description. We define this configuration method in Appendix C.6.
どちらの設定文字列は空です。構成データは、第2のメディア記述のfmtpラインに表示されるパラメータで指定されています。私たちは、付録C.6でこの設定方法を定義します。
The next example shows two RTP MIDI streams (one recvonly, one sendonly) that form a "virtual sendrecv" session. Each stream resides in a different RTP session (a requirement because sendonly and recvonly are RTP session attributes).
次の例では、「仮想のsendrecv」セッションを形成する2基のRTP MIDIストリーム（一方がrecvonly、sendonlyのいずれか）を示しています。 （sendonlyのがrecvonly RTPセッション属性があるため、要件）各ストリームは、異なるRTPセッションに存在します。
v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 5004 RTP/AVP 96
a=sendonly
a=rtpmap:96 mpeg4-generic/44100
a=mid:1
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12
m=audio 5006 RTP/AVP 96
a=recvonly
a=rtpmap:96 mpeg4-generic/44100
a=mid:2
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12
(The a=fmtp lines have been wrapped to fit the page to accommodate memo formatting restrictions; they comprise single lines in SDP.)
（A =のfmtpラインが制限をフォーマットするメモに対応するために、ページに収まるようにラップされています。彼らは、SDP内の単一の行を含みます。）
To signal the "virtual sendrecv" semantics, the two streams assign musicport to the same value (12). As defined earlier in this section, pairs of identity relationship streams that are sent by different parties share the association that is shared by a MIDI cable pair that cross-connects two devices in a MIDI 1.0 network. We use the term "virtual sendrecv" because streams sent by different parties in a true sendrecv session also have this property.
「仮想のsendrecv」セマンティクスを知らせるために、二つの流れは同じ値（12）にmusicportを割り当てます。以前、このセクションで定義されるように、異なるパーティによって送信されたアイデンティティ関係ストリームの対はMIDI 1.0ネットワーク内の2つのデバイスを相互接続するMIDIケーブル対によって共有されているアソシエーションを共有します。本当のsendrecvセッションで異なる当事者によって送信されたストリームはまた、この性質を持っているので、我々は、用語「仮想のsendrecv」を使用します。
As discussed in the preamble to Appendix C, the primary advantage of the virtual sendrecv configuration is that each party can customize the property of the stream it receives. In the example above, each stream defines its own "config" string that could customize the rendering algorithm for each party (in fact, the particular strings shown in this example are identical, because General MIDI is not a configurable MPEG 4 renderer).
付録Cの前文で説明したように、仮想のsendrecv構成の主な利点は、各当事者は、それが受信するストリームのプロパティをカスタマイズすることができるということです。上記の例では、各ストリームは、各当事者のためにレンダリングアルゴリズムをカスタマイズすることができ、独自の「設定」の文字列を定義します（ジェネラルMIDIは設定MPEG 4レンダラではありませんので、実際には、この例に示される特定の文字列が同一です）。
C.6. Configuration Tools: MIDI Rendering
C.6。コンフィギュレーションツール：MIDIレンダリング
This appendix defines the session configuration tools for rendering.
この付録では、レンダリングのためのセッション構成ツールを定義します。
The render parameter specifies a rendering method for a stream. The parameter is assigned a token value that signals the top-level rendering class. This memo defines four token values for render: "unknown", "synthetic", "api", and "null": o An "unknown" renderer is a renderer whose nature is unspecified. It is the default renderer for native RTP MIDI streams.
レンダリングパラメータは、ストリームのレンダリング方法を指定します。パラメータは、トップレベルのレンダリング・クラスを通知トークン値が割り当てられます。 「不明」、「合成」、「API」、および「ヌル」：このメモは4つのトークンレンダリングのための値を定義し、「不明」レンダラは、その性質上、不特定であるレンダラはO。これは、ネイティブのRTP MIDIストリームのためのデフォルトのレンダリングです。
o A "synthetic" renderer transforms the MIDI stream into audio output (or sometimes into stage lighting changes or other actions). It is the default renderer for mpeg4-generic RTP MIDI streams.
O「合成」レンダラーは（ステージ照明の変化または他の行動に又は時々）オーディオ出力へMIDIストリームを変換します。それはmpeg4-ジェネリックRTP MIDIストリームのためのデフォルトのレンダリングです。
o An "api" renderer presents the command stream to applications via an Application Programming Interface (API).
O「API」レンダラは、アプリケーション・プログラミング・インタフェース（API）を介してアプリケーションにコマンドストリームを提示します。
o The "null" renderer discards the MIDI stream.
O「ヌル」レンダラーはMIDIストリームを破棄する。
The "null" render value plays special roles during Offer/Answer negotiations [RFC3264]. A party uses the "null" value in an answer to reject an offered renderer. Note that rejecting a renderer is independent from rejecting a payload type (coded by removing the payload type from a media line) and rejecting a media stream (coded by zeroing the port of a media line that uses the renderer).
「ヌル」値をレンダリングするには、オファー/回答交渉[RFC3264]の間に特別な役割を果たしています。当事者が提供レンダラを拒否するような答えに「ヌル」値を使用しています。レンダラーを拒絶する（メディア・ラインからのペイロードタイプを除去することにより、符号化された）ペイロードタイプを拒絶し、（レンダラを使用するメディア・ラインのポートをゼロにすることによって符号化された）メディアストリームを拒絶から独立であることに留意されたいです。
Other render token values MAY be registered with IANA. The token value MUST adhere to the ABNF for render tokens defined in Appendix D. Registrations MUST include a complete specification of parameter value usage, similar in depth to the specifications that appear throughout Appendix C.6 for "synthetic" and "api" render values. If a party is offered a session description that uses a render token value that is not known to the party, the party MUST NOT accept the renderer. Options include rejecting the renderer (using the "null" value), the payload type, the media stream, or the session description.
その他には、トークンの値はIANAに登録されてレンダリングします。 「合成」と「API」値をレンダリングするための付録C.6を通して見える仕様深さで同様のパラメータ値の使用の完全な仕様を含まなければなりません付録D.登録で定義されたトークンをレンダリングするためのトークン値はABNFに従わなければなりません。当事者が当事者に知られていないトークン値をレンダリング使用するセッション記述を提供している場合、当事者はレンダラを受け入れてはいけません。オプション（「ヌル」値を使用して）レンダリングを拒絶する、ペイロードタイプ、メディア・ストリーム、またはセッション記述を含みます。
Other parameters MAY follow a render parameter in a parameter list. The additional parameters act to define the exact nature of the renderer. For example, the subrender parameter (defined in Appendix C.6.2) specifies the exact nature of the renderer.
他のパラメータは、パラメータ・リストのレンダリングパラメータに従うことができます。追加のパラメータは、レンダラーの正確な性質を定義するように作用します。例えば、（付録C.6.2に定義された）サブレンダラーパラメータは、レンダラーの正確な性質を指定します。
Special rules apply to using the render parameter in an mpeg4-generic stream. We define these rules in Appendix C.6.5.
特別な規則はmpeg4-ジェネリックストリームでレンダリングパラメータを使用してに適用されます。私たちは、付録C.6.5にこれらのルールを定義します。
C.6.1. The multimode Parameter
C.6.1。マルチモード・パラメータ
A media description MAY contain several render parameters. By default, if a parameter list includes several render parameters, a receiver MUST choose exactly one renderer from the list to render the stream. The multimode parameter may be used to override this default. We define two token values for multimode: "one" and "all".
メディア記述には、いくつかのパラメータをレンダリング含むかもしれません。パラメータリストは、いくつかのパラメータをレンダリング含まれている場合、デフォルトで、受信機は、ストリームをレンダリングするために、リストから正確に一つのレンダラを選択する必要があります。マルチモード・パラメータは、このデフォルトを上書きするために使用することができます。 「1」と「すべて」：私たちは、マルチモードのための2つのトークンの値を定義します。
o The default "one" value requests rendering by exactly one of the listed renderers.
記載されているレンダラーの正確に一つでデフォルトのレンダリング「1」の値を要求O。
o The "all" value requests the synchronized rendering of the RTP MIDI stream by all listed renderers, if possible.
可能であればO「すべての」値は、リストされたすべてのレンダラーによってRTP MIDIストリームの同期レンダリングを要求します。
If the multimode parameter appears in a parameter list, it MUST appear before the first render parameter assignment.
マルチパラメータは、パラメータリストに表示されている場合、最初のパラメータの割り当てをレンダリングする前に、それが現れなければなりません。
Render parameters appear in the parameter list in order of decreasing priority. A receiver MAY use the priority ordering to decide which renderer(s) to retain in a session.
レンダリングパラメータは、優先度の高い順にパラメータリストに表示されます。受信機はセッションに保持するためにどのレンダラ（単数または複数）を決定する優先順位を使用するかもしれません。
If the "offer" in an Offer/Answer-style negotiation [RFC3264] contains a parameter list with one or more render parameters, the "answer" MUST set the render parameters of all unchosen renderers to "null".
オファーで「提供」/回答形式の交渉[RFC3264]は、1つまたは複数のパラメータをレンダリングすると、パラメータのリストが含まれている場合は、「答えは」「ヌル」に、すべてのunchosenレンダラーのレンダリングパラメータを設定しなければなりません。
C.6.2. Renderer Specification
C.6.2。レンダラ仕様
The render parameter (Appendix C.6 preamble) specifies, in a broad sense, what a renderer does with a MIDI stream. In this appendix, we describe the subrender parameter. The token value assigned to subrender defines the exact nature of the renderer. Thus, render and subrender combine to define a renderer, in the same way as MIME types and MIME subtypes combine to define a type of media [RFC2045].
レンダリングパラメータ（付録C.6プリアンブル）はレンダラがMIDIストリームで何をするか、広い意味では、指定します。この付録では、我々は、サブレンダラーのパラメータを記述します。サブレンダラーに割り当てられたトークン値は、レンダラーの正確な性質を定義します。したがって、MIMEタイプとMIMEサブタイプは、メディア[RFC2045]のタイプを定義するために組み合わせと同様に、レンダラを定義するために組み合わせるレンダリングとサブレンダラー。
If the subrender parameter is used for a renderer definition, it MUST appear immediately after the render parameter in the parameter list. At most, one subrender parameter may appear in a renderer definition.
subrenderパラメータがレンダラー定義に使用されている場合は、パラメータ・リストのレンダリングパラメータの直後に現れなければなりません。せいぜい、1つのsubrenderパラメータは、レンダラの定義に表示される場合があります。
This document defines one value for subrender: the value "default". The "default" token specifies the use of the default renderer for the stream type (native or mpeg4-generic). The default renderer for native RTP MIDI streams is a renderer whose nature is unspecified (see point 6 in Section 6.1 for details). The default renderer for mpeg4-generic RTP MIDI streams is an MPEG 4 Audio Object Type whose ID number is 13, 14, or 15 (see Section 6.2 for details).
値が「デフォルト」：この文書は、サブレンダラーのための1つの値を定義します。 「デフォルト」のトークンは、ストリームタイプ（ネイティブまたはMPEG4-ジェネリック）のためのデフォルトのレンダリングを使用することを指定します。ネイティブのRTP MIDIストリームのデフォルトのレンダラは、その性質上（詳細については、6.1節のポイント6を参照）指定されていないレンダラです。 mpeg4-ジェネリックRTP MIDIのデフォルトレンダラストリームそのID番号（詳細はセクション6.2を参照）13、14、または15であるMPEG 4オーディオオブジェクトタイプです。
If a renderer definition does not use the subrender parameter, the value "default" is assumed for subrender.
レンダラの定義は、サブレンダラーのパラメータを使用しない場合は、値「デフォルト」は、サブレンダラーのために想定されます。
Other subrender token values may be registered with IANA. We now discuss guidelines for registering subrender values.
その他のsubrenderトークンの値はIANAに登録することができます。現在のsubrender値を登録するためのガイドラインについて説明します。
A subrender value is registered for a specific stream type (native or mpeg4-generic) and a specific render value (excluding "null" and "unknown"). Registrations for mpeg4-generic subrender values are restricted to new MPEG 4 Audio Object Types that accept MIDI input. The syntax of the token MUST adhere to the token definition in Appendix D.
subrender値は、（「ヌル」と「不明」を除く）の値をレンダリングする特定のストリームタイプ（ネイティブまたはMPEG4-ジェネリック）と特定のために登録されています。 mpeg4-ジェネリックのsubrender値のための登録は、MIDI入力を受け付ける新しいMPEG 4オーディオオブジェクトの種類に制限されています。トークンの構文は、付録D内のトークンの定義に準拠する必要があります
For "render=synthetic" renderers, a subrender value registration specifies an exact method for transforming the MIDI stream into audio (or sometimes into video or control actions, such as stage lighting). For standardized renderers, this specification is usually a pointer to a standards document, perhaps supplemented by RTP-MIDI-specific information. For commercial products and open-source projects, this specification usually takes the form of instructions for interfacing the RTP MIDI stream with the product or project software. A "render=synthetic" registration MAY specify additional Reset State commands for the renderer (Appendix A.1).
「=レンダリング合成」レンダラは、サブレンダラー値の登録はオーディオにMIDIストリームを変換するための正確な方法を指定する（または時にはそのような舞台照明などのビデオまたは制御アクションに）。標準化されたレンダラーのために、この仕様は通常、おそらくRTP-MIDI固有の情報で補足基準文書へのポインタです。商用製品とオープンソースのプロジェクトでは、この仕様は通常、製品やプロジェクトのソフトウェアとRTP MIDIストリームを接続するための命令の形態をとります。 「=レンダリング合成」の登録は、レンダラ（付録A.1）のための追加のリセット状態コマンドを指定するかもしれません。
A "render=api" subrender value registration specifies how an RTP MIDI stream interfaces with an API. This specification is usually a pointer to programmer's documentation for the API, perhaps supplemented by RTP-MIDI-specific information.
「レンダリング= API」のsubrender値の登録は、APIでどのようにRTP MIDIストリームのインタフェースを指定します。この仕様は通常、おそらくRTP-MIDI固有の情報によって補完APIのプログラマのドキュメントへのポインタです。
A subrender registration MAY specify an initialization file (referred to in this document as an initialization data object) for the stream. The initialization data object MAY be encoded in the parameter list (verbatim or by reference) using the coding tools defined in Appendix C.6.3. An initialization data object MUST have a registered [RFC4288] media type and subtype [RFC2045].
サブレンダラー登録はストリームに対する（初期化データオブジェクトとして、この文書で言及）初期化ファイルを指定するかもしれません。初期化データ・オブジェクトは、付録C.6.3に規定された符号化ツールを使用して、パラメータリスト（逐語的または参照によって）で符号化することができます。初期化データ・オブジェクトは、登録され[RFC4288]メディアタイプとサブタイプ[RFC2045]を持たなければなりません。
For "render=synthetic" renderers, the data object usually encodes initialization data for the renderer (sample files, synthesis patch parameters, reverberation room impulse responses, etc.).
「=レンダリング合成」レンダラのために、データ・オブジェクトは、通常、レンダラーの初期化データ（サンプルファイル、合成パッチパラメータ、残響室内インパルス応答、等）をコードします。
For "render=api" renderers, the data object usually encodes data about the stream used by the API (for example, for an RTP MIDI stream generated by a piano keyboard controller, the manufacturer and model number of the keyboard, for use in GUI presentation).
「レンダリング= API」レンダラーのために、データオブジェクトは、通常、GUIで使用するための、ピアノキーボードコントローラ、キーボードの製造元とモデル番号によって生成されたRTP MIDIストリームのため（例えば、APIによって使用されるストリームに関するデータを符号化しますプレゼンテーション）。
Usually, only one initialization object is encoded for a renderer. If a renderer uses multiple data objects, the correct receiver interpretation of multiple data objects MUST be defined in the subrender registration.
通常、一つだけ初期化オブジェクトは、レンダリングのためにエンコードされます。レンダラは、複数のデータオブジェクトを使用している場合、複数のデータ・オブジェクトの正しい受信の解釈は、サブレンダラー登録で定義されなければなりません。
A subrender value registration may also specify additional parameters, to appear in the parameter list immediately after subrender. These parameter names MUST begin with the subrender value followed by an underscore ("_") to avoid name space collisions with future RTP MIDI parameter names (for example, a parameter "foo_bar" defined for subrender value "foo").
subrender値登録もすぐのsubrender後にパラメータリストに表示されるように、追加のパラメータを指定することもできます。これらのパラメータ名は、将来のRTP MIDIパラメータ名と名前空間の衝突を避けるために、アンダースコア（「_」）に続いてのsubrender値で開始する必要があります（例えば、サブレンダラー値「foo」というために定義されたパラメータ「foo_barは」）。
We now specify guidelines for interpreting the subrender parameter during session configuration.
現在のセッションの設定時に、サブレンダラーのパラメータを解釈するためのガイドラインを指定します。
If a party is offered a session description that uses a renderer whose subrender value is not known to the party, the party MUST NOT accept the renderer. Options include rejecting the renderer (using the "null" value), the payload type, the media stream, or the session description.
当事者は、サブレンダラー値当事者に知られていないレンダラを使用してセッション記述を提供している場合、当事者はレンダラを受け入れてはいけません。オプション（「ヌル」値を使用して）レンダリングを拒絶する、ペイロードタイプ、メディア・ストリーム、またはセッション記述を含みます。
Receivers MUST be aware of the Reset State commands (Appendix A.1) for the renderer specified by the subrender parameter and MUST insure that the renderer does not experience indefinite artifacts due to the presence (or the loss) of a Reset State command.
レシーバは、サブレンダラーのパラメータで指定されたレンダラのためのリセット状態コマンド（付録A.1）を認識する必要がありますし、レンダラーが原因リセット状態コマンドの存在（または損失）に無期限のアーティファクトを経験していないことを保証しなければなりません。
C.6.3. Renderer Initialization
C.6.3。レンダラーの初期化
If the renderer for a stream uses an initialization data object, an rinit parameter MUST appear in the parameter list immediately after the subrender parameter. If the renderer parameter list does not include a subrender parameter (recall the semantics for "default" in Appendix C.6.2), the rinit parameter MUST appear immediately after the render parameter.
ストリームのレンダラが初期化データオブジェクトを使用している場合は、RINITパラメータは、直ちにのsubrenderパラメータの後にパラメータのリストに表示されなければなりません。レンダラのパラメータリストは、サブレンダラーのパラメータが含まれていない場合（付録C.6.2で「デフォルト」の意味を思い出して）、RINITパラメータは、レンダリングパラメータの直後に現れなければなりません。
The value assigned to the rinit parameter MUST be the media type/subtype [RFC2045] for the initialization data object. If an initialization object type is registered with several media types, including audio, the assignment to rinit MUST use the audio media type.
RINITパラメータに割り当てられた値は、初期化データオブジェクトのメディアタイプ/サブタイプ[RFC2045]でなければなりません。初期化オブジェクトタイプがオーディオを含むいくつかのメディアタイプに登録されている場合、RINITへの代入は、音声メディアタイプを使用しなければなりません。
RTP MIDI supports several parameters for encoding initialization data objects for renderers in the parameter list: inline, url, and cid.
インライン、URL、およびCID：RTP MIDIは、パラメータリスト内のレンダラーの初期化データオブジェクトを符号化するためのいくつかのパラメータをサポートしています。
If the inline, url, and/or cid parameters are used by a renderer, these parameters MUST immediately follow the rinit parameter.
インライン、URL、および/またはCIDパラメータは、レンダラで使用されている場合は、これらのパラメータは、直ちにRINITパラメータに従わなければなりません。
If a url parameter appears for a renderer, an inline parameter MUST NOT appear. If an inline parameter appears for a renderer, a url parameter MUST NOT appear. However, neither url nor inline is required to appear. If neither url or inline parameters follow rinit, the cid parameter MUST follow rinit.
URLパラメータは、レンダラのために表示された場合は、インラインパラメータが表示されてはなりません。インラインパラメータはレンダラのために表示された場合は、urlパラメータが表示されてはなりません。しかし、どちらのURLもインラインで表示されるために必要とされます。どちらのURLまたはインラインパラメータがRINITに従った場合は、CIDパラメータはRINITに従わなければなりません。
The inline parameter supports the inline encoding of the data object. The parameter is assigned a double-quoted Base64 [RFC2045] encoding of the binary data object, with no line breaks. Appendix E.4 shows an example that constructs an inline parameter value.
インラインパラメータは、データオブジェクトのインラインのエンコーディングをサポートしています。パラメータはない改行と、バイナリデータオブジェクトの二重引用符で囲まれたBase64で[RFC2045]エンコードが割り当てられます。付録E.4インラインパラメータ値を構成する例を示しています。
The url parameter is assigned a double-quoted string representation of a Uniform Resource Locator (URL) for the data object. The string MUST specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or an HTTP over TLS URI (HTTPS, [RFC2818]). The media type/subtype for the data object SHOULD be specified in the appropriate HTTP or HTTPS transport header.
urlパラメータは、データオブジェクトのためのURL（Uniform Resource Locator）の二重引用符で囲まれた文字列表現を割り当てられています。文字列は、ハイパーテキスト転送プロトコルURI（HTTP、[RFC2616]）またはTLS URI上HTTP（HTTPS、[RFC2818]）のいずれかを指定しなければなりません。データオブジェクトのメディアタイプ/サブタイプは、適切なHTTPまたはHTTPSトランスポート・ヘッダで指定してください。
The cid parameter supports data object caching. The parameter is assigned a double-quoted string value that encodes a globally unique identifier for the data object.
CIDパラメータは、データオブジェクトのキャッシュをサポートしています。パラメータは、データオブジェクトのグローバル一意識別子をエンコードし、二重引用符で囲まれた文字列値が割り当てられます。
A cid parameter MAY immediately follow an inline parameter, in which case the cid identifier value MUST be associated with the inline data object.
CIDパラメータは、直ちにCID識別子の値がインライン・データ・オブジェクトに関連付けられている必要があり、その場合、インラインパラメータを、従うことができます。
If a url parameter is present, and if the data object for the URL is expected to be unchanged for the life of the URL, a cid parameter MAY immediately follow the url parameter. The cid identifier value MUST be associated with the data object for the URL. A cid parameter assigned to the same identifier value SHOULD be specified following the data object type/subtype in the appropriate HTTP transport header.
URLパラメータが存在する場合、およびURLのデータ・オブジェクトがURLの生活のために変わらないことが予想される場合は、CIDパラメータが、すぐにURLパラメータに従うことができます。 CID識別子の値は、URLのデータオブジェクトに関連付けられなければなりません。同じ識別子値に割り当てられたCIDパラメータは、適切なHTTPトランスポート・ヘッダ内のデータ・オブジェクト・タイプ/サブタイプ次指定する必要があります。
If a url parameter is present, and if the data object for the URL is expected to change during the life of the URL, a cid parameter MUST NOT follow the url parameter. A receiver interprets the presence of a cid parameter as an indication that it is safe to use a cached copy of the url data object; the absence of a cid parameter is an indication that it is not safe to use a cached copy, as it may change.
urlパラメータが存在する場合、およびURLのデータ・オブジェクトがURLの生活中に変化することが予想される場合は、CIDパラメータがURLパラメータに従ってはなりません。受信機は、URLデータオブジェクトのキャッシュされたコピーを使用しても安全であることを示すものとして、CIDパラメータの存在を解釈します。 CIDパラメータが存在しない場合は、変更される可能性として、キャッシュされたコピーを使用しても安全ではないことを示しています。
Finally, the cid parameter MAY be used without the inline and url parameters. In this case, the identifier references a local or distributed catalog of data objects.
最後に、CIDパラメータは、インラインとURLパラメータをすることなく使用することができます。この場合、識別子は、データオブジェクトのローカルまたは分散カタログを参照します。
In most cases, only one data object is coded in the parameter list for each renderer. For example, the default renderer for mpeg4-generic streams uses a single data object (see Appendix C.6.5 for example usage).
ほとんどの場合、唯一つのデータオブジェクトは、各レンダラのためのパラメータリストに符号化されます。例えば、mpeg4-ジェネリックストリームのデフォルトのレンダリングは（使用例については、付録C.6.5を参照）を単一のデータ・オブジェクトを使用しています。
However, a subrender registration MAY permit the use of multiple data objects for a renderer. If multiple data objects are encoded for a renderer, each object encoding begins with an rinit parameter followed by inline, url, and/or cid parameters.
しかし、サブレンダラーの登録はレンダラのために複数のデータ・オブジェクトの使用を許可することができます。複数のデータオブジェクトをレンダリングするために符号化される場合、各オブジェクト符号化は、インライン、URL、および/またはCIDパラメータ続いRINITパラメータから始まります。
Initialization data objects MAY encapsulate a Standard MIDI File (SMF). By default, the SMFs that are encapsulated in a data object MUST be ignored by an RTP MIDI receiver. We define parameters to override this default in Appendix C.6.4.
初期化データオブジェクトは、スタンダードMIDIファイル（SMF）をカプセル化することができます。デフォルトでは、データ・オブジェクト内にカプセル化されるのSMFは、RTP MIDI受信機によって無視されなければなりません。私たちは、付録C.6.4で、このデフォルトを上書きするためのパラメータを定義します。
To end this section, we offer guidelines for registering media types for initialization data objects. These guidelines are in addition to the information in [RFC4288].
このセクションを終了するには、我々は、初期化データ・オブジェクトのメディアタイプを登録するためのガイドラインを提供します。これらのガイドラインは、[RFC4288]に記載されている情報に加えています。
Some initialization data objects are also capable of encoding MIDI note information and thus complete audio performances. These objects SHOULD be registered using the audio media type (so that the objects may also be used for store-and-forward rendering) and the "application" media type (to support editing tools). Initialization objects without note storage, or initialization objects for non-audio renderers, SHOULD be registered only for an "application" media type.
いくつかの初期化データオブジェクトは、MIDIノート情報、したがって、完全なオーディオパフォーマンスをコードすることができます。これらのオブジェクトは、（オブジェクトもストアアンドフォワードレンダリングのために使用することができるようにするため）および「アプリケーション」メディアタイプが（編集ツールをサポートするために）オーディオメディアタイプを使用して登録する必要があります。非オーディオレンダラーのための紙幣保管せずに初期化オブジェクト、または初期化オブジェクトは、唯一の「アプリケーション」メディアタイプのために登録する必要があります。
C.6.4. MIDI Channel Mapping
C.6.4。 MIDIチャンネルのマッピング
In this appendix, we specify how to map MIDI name spaces (16 voice channels + systems) onto a renderer.
この付録では、我々は、レンダラにMIDI名前空間（16の音声チャンネル+システム）をマッピングする方法を指定します。
In the general case:
一般的なケースでは：
o A session may define an ordered relationship (Appendix C.5) that presents more than one MIDI name space to a renderer.
Oセッションは、レンダラに複数のMIDI名前空間を提示命じ関係（付録C.5）を定義することができます。
o A renderer may accept an arbitrary number of MIDI name spaces, or it may expect a specific number of MIDI name spaces.
Oレンダラは、MIDI名前空間の任意の数を受け入れることができる、又はそれは、MIDI名前空間の特定の数を期待することができます。
A session description SHOULD provide a compatible MIDI name space to each renderer in the session. If a receiver detects that a session description has too many or too few MIDI name spaces for a renderer, MIDI data from extra stream name spaces MUST be discarded, and extra renderer name spaces MUST NOT be driven with MIDI data (except as described in Appendix C.6.4.1).
セッション記述は、セッション内の各レンダラに互換性のあるMIDIの名前空間を提供する必要があります。受信機はセッション記述がレンダラのためにあまりにも多くのか、少なすぎるMIDI名前空間を持っていることを検出した場合には、余分なストリームの名前空間からのMIDIデータを捨てなければなりませんし、余分なレンダラの名前空間は、付録に記載されている場合を除き（MIDIデータで駆動してはなりませんC.6.4.1）。
If a parameter list defines several renderers and assigns the "all" token value to the multimode parameter, the same name space is presented to each renderer. However, the chanmask parameter may be used to mask out selected voice channels to each renderer. We define chanmask and other MIDI management parameters in the subsections below.
パラメータリストには、いくつかのレンダラーを定義し、マルチモードパラメータを「すべて」トークン値を代入した場合は、同じ名前空間は、各レンダラに提示されます。しかし、chanmaskパラメータは、各レンダラの選択された音声チャネルをマスクするために使用することができます。私たちは、以下のサブセクションでchanmaskと他のMIDI管理パラメータを定義します。
C.6.4.1. The smf_info Parameter
C.6.4.1。 smf_infoパラメータ
The smf_info parameter defines the use of the SMFs encapsulated in renderer data objects (if any). The smf_info parameter also defines the use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters (defined in Appendix C.6.4.2).
smf_infoパラメータは、レンダラ・データ・オブジェクト（もしあれば）の中にカプセル化のSMFの使用を規定します。 smf_infoパラメータも（付録C.6.4.2で定義されている）smf_inline、smf_urlで符号化のSMFの使用、及びsmf_cidパラメータを定義します。
The smf_info parameter describes the render parameter that most recently precedes it in the parameter list. The smf_info parameter MUST NOT appear in parameter lists that do not use the render parameter and MUST NOT appear before the first use of render in the parameter list.
smf_infoパラメータは、最近パラメータリストでそれを先行するレンダリングパラメータを記述します。 smf_infoパラメータは、レンダリングパラメータを使用しないと、パラメータ・リストのレンダリングの最初の使用の前に現れてはならないパラメータリストに現れてはいけません。
We define three token values for smf_info: "ignore", "sdp_start", and "identity":
私たちは、smf_infoための3つのトークンの値を定義します、「無視する」「sdp_start」、および「アイデンティティ」：
o The "ignore" value indicates that the SMFs MUST be discarded. This behavior is the default SMF-rendering behavior.
O「無視」値は、SMFには捨てなければなりませんことを示しています。この動作は、デフォルトのSMF-レンダリング動作です。
o The "sdp_start" value codes that SMFs MUST be rendered and that the rendering MUST begin upon the acceptance of the session description. If a receiver is offered a session description with a renderer that uses an smf_info parameter set to "sdp_start" and if the receiver does not support rendering SMFs, the receiver MUST NOT accept the renderer associated with the smf_info parameter. Options include rejecting the renderer (by setting the render parameter to "null"), the payload type, the media stream, or the entire session description.
SMFがレンダリングされ、レンダリングがセッション記述を受け付けると開始しなければならないことをしなければならない「sdp_start」値oコード。受信機は、「sdp_start」に設定smf_infoパラメータを使用して、受信機はSMFをレンダリングサポートしていない場合、受信機はsmf_infoパラメータに関連付けられているレンダラを受け入れてはいけませんレンダラとのセッション記述を提供している場合。オプションには、ペイロードタイプ、メディアストリーム、または全体のセッション記述（レンダリングパラメータに「NULL」を設定することによって）レンダリングを拒絶することを含みます。
o The "identity" value indicates that the SMFs code the identity of the renderer. The value is meant for use with the "unknown" renderer (see Appendix C.6 preamble). The MIDI commands coded in the SMF are informational in nature and MUST NOT be presented to a renderer for audio presentation. In typical use, the SMF would use SysEx Identity Reply commands (F0 7E nn 06 02, as defined in [MIDI]) to identify devices and use device-specific SysEx commands to describe the current state of the devices (patch memory contents, etc.).
「同一性」値oをのSMFは、レンダラの識別を符号化することを示しています。値は「不明」レンダラ（付録C.6プリアンブルを参照）で使用するためのものです。 SMFでコード化されたMIDIコマンドは、自然の中での情報であり、オーディオプレゼンテーションのためのレンダラに提示してはなりません。典型的な使用では、SMFは、デバイスを識別し、デバイス固有のシステムエクスクルーシブを使用する（[MIDI]で定義されるように、06 02 F0 7E NN）コマンドを返信システムエクスクルーシブアイデンティティを使用するデバイス（パッチメモリ内容等の現在の状態を記述するためのコマンド。）。
Other smf_info token values MAY be registered with IANA. The token value MUST adhere to the ABNF for render tokens defined in Appendix D. Registrations MUST include a complete specification of parameter usage, similar in depth to the specifications that appear in this appendix for "sdp_start" and "identity".
その他smf_infoトークン値は、IANAに登録されるかもしれません。 「sdp_start」と「アイデンティティ」については、この付録に表示されます仕様と深さで同様のパラメータの使用法の完全な仕様を含まなければなりません付録D.登録で定義されたトークンをレンダリングするためのトークン値はABNFに従わなければなりません。
If a party is offered a session description that uses an smf_info parameter value that is not known to the party, the party MUST NOT accept the renderer associated with the smf_info parameter. Options include rejecting the renderer, the payload type, the media stream, or the entire session description.
当事者が当事者に知られていないsmf_infoパラメータ値を使用してセッション記述を提供している場合、当事者はsmf_infoパラメータに関連付けられているレンダラを受け入れてはいけません。オプションは、レンダラー、ペイロードタイプ、メディアストリーム、または全体のセッション記述を拒絶含みます。
We now define the rendering semantics for the "sdp_start" token value in detail.
私たちは今、詳細に「sdp_start」トークン値のためのレンダリングのセマンティクスを定義します。
The SMFs and RTP MIDI streams in a session description share the same MIDI name space(s). In the simple case of a single RTP MIDI stream and a single SMF, the SMF MIDI commands and RTP MIDI commands are merged into a single name space and presented to the renderer. The indefinite artifact responsibilities for merged MIDI streams defined in Appendix C.5 also apply to merging RTP and SMF MIDI data.
SMFとRTP MIDIは、セッション記述を共有し、同じMIDI名前空間（複数可）をストリーム。単一RTP MIDIストリームおよび単一SMFの単純なケースでは、SMF MIDIコマンドとRTP MIDIコマンドは、単一の名前空間にマージされ、レンダラに提示します。付録C.5で定義されているマージされたMIDIストリームの不定アーティファクトの責任もRTPとSMF MIDIデータをマージに適用されます。
If a payload type codes multiple SMFs, the SMF name spaces are presented as an ordered entity to the renderer. To determine the ordering of SMFs for a renderer (which SMF is "first", which is "second", etc.), use the following rules:
ペイロードタイプコードの場合は、複数のSMF、SMFの名前空間は、レンダラに注文したエンティティとして提示されています。 （「第二」のSMFは、「最初」である、など）レンダラのためのSMFの順序を決定するために、以下のルールを使用します。
o If the renderer uses a single data object, the order of appearance of the SMFs in the object's internal structure defines the order of the SMFs (the earliest SMF in the object is "first", the next SMF in the object is "second", etc.).
レンダラは、単一のデータ・オブジェクトを使用する場合、オブジェクトの内部構造内のSMFの出現順序がのSMFの順序を定義する（オブジェクト内の最古のSMFは、「最初の」はO、オブジェクト内の次のSMFは「秒」であります、など）。
o If multiple data objects are encoded for a renderer, the appearance of each data object in the parameter list sets the relative order of the SMFs encoded in each data object (SMFs encoded in parameters that appear earlier in the list are ordered before SMFs encoded in parameters that appear later in the list).
複数のデータオブジェクトをレンダリングするために符号化される場合、O、パラメータリスト内の各データオブジェクトの外観に符号化のSMFの前に順序付けされた各データ・オブジェクト（以前のリストに表示されたパラメータに符号化のSMFに符号化のSMFの相対的な順序を設定します後でリストで表示されるパラメータ）。
o If SMFs are encoded in data objects parameters and in the parameters defined in Appendix C.6.4.2, the relative order of the data object parameters and Appendix C.6.4.2 parameters in the parameter list sets the relative order of SMFs (SMFs encoded in parameters that appear earlier in the list are ordered before SMFs in parameters that appear later in the list).
OのSMFをデータで符号化されている場合のSMF（パラメータオブジェクトおよび付録C.6.4.2で定義されたパラメータで、パラメータリスト内のデータ・オブジェクト・パラメータおよび付録C.6.4.2パラメータの相対的な順序は、のSMFの相対的な順序を設定します以前のリストに表示されるパラメータでエンコード）は、後にリストに表示されるパラメータでのSMFの前に並べられます。
Given this ordering of SMFs, we now define the mapping of SMFs to renderer name spaces. The SMF that appears first for a renderer maps to the first renderer name space. The SMF that appears second for a renderer maps to the second renderer name space, etc. If the associated RTP MIDI streams also form an ordered relationship, the first SMF is merged with the first name space of the relationship, the second SMF is merged to the second name space of the relationship, etc.
SMFのこの順序付けを考えると、我々は今、名前空間をレンダラにのSMFのマッピングを定義します。レンダラのために最初に表示されSMFは最初のレンダラー名前空間にマッピングされます。関連するRTP MIDIも注文した関係を形成ストリームた場合は、最初のSMFは関係の最初のネームスペースとマージされ、第二SMFがにマージされるなど二レンダラー名前空間へのレンダラマップに表示されます第二SMF関係などの第二の名前空間
Unless the streams and the SMFs both use MIDI Time Code, the time offset between SMF and stream data is unspecified. This restriction limits the use of SMFs to applications where synchronization is not critical, such as the transport of System Exclusive commands for renderer initialization or human-SMF interactivity.
ストリームとのSMFが両方のMIDIタイムコード、SMFとストリームとの間の時間オフセットを使用しない限り、データは不定です。この制限は、同期は、システムエクスクルーシブの輸送は、レンダラーの初期化またはヒトSMF対話するためのコマンドとして、重要ではなく、アプリケーションへのSMFの使用を制限します。
Finally, we note that each SMF in the sdp_start discussion above encodes exactly one MIDI name space (16 voice channels + systems). Thus, the use of the Device Name SMF meta event to specify several MIDI name spaces in an SMF is not supported for sdp_start.
最後に、我々は、上記のsdp_startの議論の各SMFは正確に一つのMIDI名前スペース（16個の音声チャンネル+システム）をコードしていることに注意してください。このように、SMFにいくつかのMIDI名前空間を指定するには、デバイス名SMFメタイベントの使用はsdp_startはサポートされていません。
C.6.4.2. The smf_inline, smf_url, and smf_cid Parameters
C.6.4.2。 smf_inline、smf_url、およびsmf_cidパラメータ
In some applications, the renderer data object may not encapsulate SMFs, but an application may wish to use SMFs in the manner defined in Appendix C.6.4.1.
一部のアプリケーションでは、レンダラーのデータオブジェクトは、のSMFをカプセル化しないかもしれませんが、アプリケーションは、付録C.6.4.1で定義された方法でのSMFを使用することをお勧めします。
The smf_inline, smf_url, and smf_cid parameters address this situation. These parameters use the syntax and semantics of the inline, url, and cid parameters defined in Appendix C.6.3, except that the encoded data object is an SMF.
smf_inline、smf_url、およびsmf_cidパラメータは、この状況に対処します。これらのパラメータは、符号化されたデータオブジェクトがSMFであることを除いて、付録C.6.3に定義された構文とインライン、URLのセマンティクス、およびCIDパラメータを使用します。
The smf_inline, smf_url, and smf_cid parameters belong to the render parameter that most recently precedes it in the session description. The smf_inline, smf_url, and smf_cid parameters MUST NOT appear in parameter lists that do not use the render parameter and MUST NOT appear before the first use of render in the parameter list. If several smf_inline, smf_url, or smf_cid parameters appear for a renderer, the order of the parameters defines the SMF name space ordering.
smf_inline、smf_url、およびsmf_cidパラメータは、最も最近のセッション記述で、それより前にレンダリングパラメータに属します。 smf_inline、smf_url、およびsmf_cidパラメータは、レンダリングパラメータを使用しないと、パラメータ・リストのレンダリングの最初の使用の前に現れてはならないパラメータリストに現れてはいけません。いくつかのsmf_inline、smf_url、またはsmf_cidパラメータはレンダラのために表示された場合は、パラメータの順序は、SMF名前空間の順序を定義します。
C.6.4.3. The chanmask Parameter
C.6.4.3。 chanmaskパラメータ
The chanmask parameter instructs the renderer to ignore all MIDI voice commands for certain channel numbers. The parameter value is a concatenated string of "1" and "0" digits. Each string position maps to a MIDI voice channel number (system channels may not be masked). A "1" instructs the renderer to process the voice channel; a "0" instructs the renderer to ignore the voice channel.
chanmaskパラメータは、特定のチャネル番号のすべてのMIDI音声コマンドを無視するレンダラを指示します。パラメータ値が「1」と「0」の数字を連結した文字列です。各列位置はMIDI音声チャンネル番号（システムチャネルをマスクしなくてもよい）にマッピングします。 「1」は、音声チャネルを処理するようにレンダラに命令します。 「0」は、音声チャネルを無視するレンダラを指示します。
The string length of the chanmask parameter value MUST be 16 (for a single stream or an identity relationship) or a multiple of 16 (for an ordered relationship).
chanmaskパラメータ値の文字列の長さは、16の倍数（単一ストリームまたはアイデンティティ関係のために）16（順序付けられた関係のため）でなければなりません。
The chanmask parameter describes the render parameter that most recently precedes it in the session description; chanmask MUST NOT appear in parameter lists that do not use the render parameter and MUST NOT appear before the first use of render in the parameter list.
chanmaskパラメータは、最も最近のセッション記述で、それに先立つレンダリングパラメータを記述します。 chanmaskは、レンダリングパラメータを使用しないと、パラメータ・リストのレンダリングの最初の使用の前に現れてはならないパラメータリストに現れてはいけません。
The chanmask parameter describes the final MIDI name spaces presented to the renderer. The SMF and stream components of the MIDI name spaces may not be independently masked.
chanmaskパラメータは、レンダラに提示最終MIDI名前空間について説明します。 MIDI名前空間のSMFとストリームのコンポーネントは、独立してマスクされない場合があります。
If a receiver is offered a session description with a renderer that uses the chanmask parameter, and if the receiver does not implement the semantics of the chanmask parameter, the receiver MUST NOT accept the renderer unless the chanmask parameter value contains only "1"s.
受信機は、chanmaskパラメータを使用し、受信機はchanmaskパラメータのセマンティクスを実装していない場合chanmaskパラメータ値のみが「1」が含まれていない限り、受信機はレンダラを受け入れてはいけませんレンダラとのセッション記述を提供している場合。
C.6.5. The audio/asc Media Type
C.6.5。オーディオ/ ASCのメディアタイプ
In Appendix 11.3, we register the audio/asc media type. The data object for audio/asc is a binary encoding of the AudioSpecificConfig data block used to initialize mpeg4-generic streams (Section 6.2 and [MPEGAUDIO]). Disk files that store this data object use the file extension ".acn".
付録11.3で、私たちは、オーディオ/ ASCのメディアタイプを登録します。オーディオ/ ASCのデータオブジェクトは、MPEG4-ジェネリックストリーム（セクション6.2および[MPEGAUDIO]）を初期化するために使用AudioSpecificConfigデータブロックのバイナリ符号化です。このデータオブジェクトを格納するディスク・ファイルは、ファイル拡張子「.acn」を使用します。
An mpeg4-generic parameter list MAY use the render, subrender, and rinit parameters with the audio/asc media type for renderer configuration. Several restrictions apply to the use of these parameters in mpeg4-generic parameter lists:
mpeg4-ジェネリックパラメータリストはレンダラの設定のためのオーディオ/ ASCメディアタイプをレンダリングし、サブレンダラー、およびRINITパラメータを使用することができます。いくつかの制限がmpeg4-ジェネリックパラメータリストでこれらのパラメータの使用に適用されます。
o An mpeg4-generic media description that uses the render parameter MUST assign the empty string ("") to the mpeg4-generic "config" parameter. The use of the streamtype, mode, and profile-level-id parameters MUST follow the normative text in Section 6.2.
レンダリングパラメータを使用していますO mpeg4-ジェネリックメディア記述は、設定「パラメータ「mpeg4-ジェネリックに（」）」空の文字列を割り当てる必要があります。 streamtype、モード、プロファイルレベルIDパラメータを使用することは、セクション6.2に規定テキストに従わなければなりません。
o Sessions that use identity or ordered relationships MUST follow the mpeg4-generic configuration restrictions in Appendix C.5.
Oアイデンティティまたは注文した関係を使用するセッションは、付録C.5でmpeg4-ジェネリック設定の制限に従わなければなりません。
o The render parameter MUST be assigned the value "synthetic", "unknown", "null", or a render value that has been added to the IANA repository for use with mpeg4-generic RTP MIDI streams. The "api" token value for render MUST NOT be used.
Oレンダリングパラメータは、値「合成」、「不明」、「NULL」が割り当てられなければならない、またはMPEG4-ジェネリックRTP MIDIストリームと共に使用するためのIANAリポジトリに追加された値をレンダリングします。レンダリングのための「API」トークン値を使用してはいけません。
o If a subrender parameter is present, it MUST immediately follow the render parameter, and it MUST be assigned the token value "default" or assigned a subrender value added to the IANA repository for use with mpeg4-generic RTP MIDI streams. A subrender parameter assignment may be left out of the renderer configuration, in which case the implied value of subrender is the default value of "default".
subrenderパラメータが存在する場合は、O、すぐにパラメータをレンダリング従わなければならない、そしてそれはトークン値「デフォルト」が割り当てられるかmpeg4-ジェネリックRTP MIDIストリームで使用するためにIANAリポジトリに追加のsubrender値を割り当てなければなりません。サブレンダラーパラメータの割り当ては、サブレンダラーの暗黙の値が「デフォルト」のデフォルト値である場合には、レンダラの構成から除外することができます。
o If the render parameter is assigned the value "synthetic" and the subrender parameter has the value "default" (assigned or implied), the rinit parameter MUST be assigned the value audio/asc, and an AudioSpecificConfig data object MUST be encoded using the mechanisms defined in Appendices C.6.2 and C.6.3. The AudioSpecificConfig data MUST encode one of the MPEG 4 Audio Object Types defined for use with mpeg4-generic in Section 6.2. If the subrender value is other than "default", refer to the subrender registration for information on the use of audio/asc with the renderer.
レンダリングパラメータが「合成」の値を割り当てられ、サブレンダラーパラメータが値「デフォルト」（割り当てまたは暗示）している場合、O、RINITパラメータは、値のオーディオ/ ASCが割り当てられている必要があり、そしてAudioSpecificConfigデータオブジェクトを使用して符号化されなければなりません付録C.6.2およびC.6.3で定義されたメカニズム。 AudioSpecificConfigデータがMPEG4-汎用セクション6.2においてで使用するために定義されたMPEG 4オーディオオブジェクトタイプのいずれかをコード化しなければなりません。 subrender値が「デフォルト」以外の場合は、レンダラとオーディオ/ ASCの使用に関する情報については、サブレンダラーの登録を参照してください。
o If the render parameter is assigned the value "null" or "unknown", the data object MAY be omitted.
レンダリングパラメータが値「ヌル」または「不明」が割り当てられている場合は、O、データオブジェクトは省略されるかもしれません。
Several general restrictions apply to the use of the audio/asc media type in RTP MIDI:
いくつかの一般的な制限は、RTP MIDIのオーディオ/ ASCメディアタイプの使用に適用されます。
o A native stream MUST NOT assign audio/asc to rinit. The audio/asc media type is not intended to be a general-purpose container for rendering systems outside of MPEG usage.
ネイティブのストリームoをRINITするオーディオ/ ASCを割り当ててはなりません。オーディオ/ ASCメディアタイプは、MPEGの使用の外システムをレンダリングするための汎用コンテナであることを意図するものではありません。
o The audio/asc media type defines a stored object type; it does not define semantics for RTP streams. Thus, audio/asc MUST NOT appear on an rtpmap line of a session description.
オーディオ/ ASCメディアタイプが格納されたオブジェクトタイプを定義し、O。それは、RTPストリームのセマンティクスを定義していません。このように、オーディオ/ ASCは、セッション記述のrtpmap行に表示されてはなりません。
Below, we show session description examples for audio/asc. The session description below uses the inline parameter to code the AudioSpecificConfig block for a mpeg4-generic General MIDI stream. We derive the value assigned to the inline parameter in Appendix E.4. The subrender token value of "default" is implied by the absence of the subrender parameter in the parameter list.
以下では、オーディオ/ ascのためのセッション記述例を示しています。セッション記述は以下のmpeg4-ジェネリック一般的なMIDIストリームのAudioSpecificConfigブロックをコーディングするインラインパラメータを使用しています。私たちは、付録E.4のインラインパラメータに割り当てられた値を導き出します。 「デフォルト」のサブレンダラートークン値は、パラメータリスト内のsubrenderパラメータの欠如によって暗示されます。
v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; render=synthetic; rinit=audio/asc;
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
(The a=fmtp line has been wrapped to fit the page to accommodate memo formatting restrictions; it comprises a single line in SDP.)
（A =のfmtpラインは、メモの書式の制限に対応するために、ページに収まるようにラップされています。それはSDP内の1行を含みます。）
The session description below uses the url parameter to code the AudioSpecificConfig block for the same General MIDI stream:
以下のセッション記述は、同じ一般的なMIDIストリームのAudioSpecificConfigブロックをコーディングするURLパラメータを使用しています。
v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; render=synthetic; rinit=audio/asc;
url="http://example.net/oski.asc";
cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"
(The a=fmtp line has been wrapped to fit the page to accommodate memo formatting restrictions; it comprises a single line in SDP.)
（A =のfmtpラインは、メモの書式の制限に対応するために、ページに収まるようにラップされています。それはSDP内の1行を含みます。）
C.7. Interoperability
C.7。相互運用性
In this appendix, we define interoperability guidelines for two application areas:
この付録では、我々は2つのアプリケーション分野のための相互運用性のガイドラインを定義します。
o MIDI content-streaming applications. RTP MIDI is added to RTSP-based content-streaming servers so that viewers may experience MIDI performances (produced by a specified client-side renderer) in synchronization with other streams (video, audio).
O MIDIコンテンツストリーミングアプリケーション。視聴者が他のストリーム（ビデオ、オーディオ）に同期して（指定されたクライアント側レンダラーによって生成される）MIDI演奏を体験することができるようにRTP MIDIは、RTSPベースのコンテンツストリーミングサーバに追加されます。
o Long-distance network musical performance applications. RTP MIDI is added to SIP-based voice chat or videoconferencing programs, as an alternative, or as an addition, to audio and/or video RTP streams.
O長距離ネットワークのミュージカル・パフォーマンス・アプリケーションに最適です。 RTP MIDIは、代替として、SIPベースの音声チャットやビデオ会議のプログラムに追加された、またはそれに加えて、オーディオおよび/またはビデオにRTPストリーム。
For each application, we define a core set of functionalities that all implementations MUST implement.
各アプリケーションのために、我々は、すべての実装が実装しなければならない機能のコアセットを定義します。
The applications we address in this section are not an exhaustive list of potential RTP MIDI uses. We expect framework documents for other applications to be developed, within the IETF or within other organizations. We discuss other potential application areas for RTP MIDI in Section 1 of the main text of this memo.
私たちは、このセクションで対処するアプリケーションは、RTP MIDIが使用する可能性の完全なリストではありません。私たちは、他のアプリケーションのためのフレームワーク文書はIETF内または他の組織の中に、開発されることを期待しています。私たちは、このメモの本文の第1節でRTP MIDIのための他の潜在的な応用分野を議論します。
C.7.1. MIDI Content-Streaming Applications
C.7.1。 MIDIのコンテンツストリーミングアプリケーション
In content-streaming applications, a user invokes an RTSP client to initiate a request to an RTSP server to view a multimedia session. For example, clicking on a web page link for an Internet Radio channel launches an RTSP client that uses the link's RTSP URL to contact the RTSP server hosting the radio channel.
コンテンツストリーミングアプリケーションでは、ユーザーは、マルチメディアセッションを表示するには、RTSPサーバに要求を開始するRTSPクライアントを起動します。例えば、インターネットラジオチャンネルのためのWebページのリンクをクリックすると、無線チャネルをホスティングするRTSPサーバに接続するためのリンクのRTSPのURLを使用するRTSPクライアントを起動します。
The content may be pre-recorded (for example, on-demand replay of yesterday's football game) or "live" (for example, football game coverage as it occurs), but in either case, the user is usually an "audience member" as opposed to a "participant" (as the user would be in telephony).
コンテンツが予め記録しておくことができる（例えば、オンデマンド昨日のサッカーの試合のリプレイ）または「ライブ」（例えば、サッカーの試合の報道は、それが発生したとして）、いずれの場合も、ユーザーは通常、「聴衆」であります（ユーザーが電話になるように）「参加者」とは対照的です。
Note that these examples describe the distribution of audio content to an audience member. The interoperability guidelines in this appendix address RTP MIDI applications of this nature, not applications such as the transmission of raw MIDI command streams for use in a professional environment (recording studio, performance stage, etc.).
これらの例は聴衆にオーディオコンテンツの配信を記述することに注意してください。このような性質のこの付録アドレスRTP MIDIアプリケーションではなく、このような専門的な環境（など、レコーディングスタジオ、パフォーマンスステージ）での使用のための生のMIDIコマンドストリームの伝送などのアプリケーションにおける相互運用性のガイドライン。
In an RTSP session, a client accesses a session description that is "declared" by the server, either via the RTSP DESCRIBE method or via other means such as HTTP or email. The session description defines the session from the perspective of the client. For example, if a media line in the session description contains a non-zero port number, it encodes the server's preference for the client's port numbers for RTP and RTCP reception. Once media flow begins, the server sends an RTP MIDI stream to the client, which renders it for presentation, perhaps in synchrony with video or other audio streams.
RTSPセッションでは、クライアントは、サーバによって、いずれかのRTSPを経由する方法を記述したり、HTTPや電子メールなどの他の手段を介して「宣言」されたセッション記述にアクセスします。セッション記述は、クライアントの視点からのセッションを定義します。セッション記述におけるメディア行が非ゼロポート番号が含まれている場合、例えば、それは、RTP及びRTCP受信のためのクライアントのポート番号のサーバの好みをコードします。メディアフローが開始されると、サーバーは、おそらくビデオまたは他のオーディオストリームと同期して、プレゼンテーションのためにそれをレンダリングするクライアントにRTP MIDIストリームを送信します。
We now define the interoperability text for content-streaming RTSP applications.
現在、コンテンツストリーミングRTSPアプリケーションのための相互運用性のテキストを定義します。
In most cases, server interoperability responsibilities are described in terms of limits on the "reference" session description a server provides for a performance if it has no information about the capabilities of the client. The reference session is a "lowest common denominator" session that maximizes the odds that a client will be able to view the session. If a server is aware of the capabilities of the client, the server is free to provide a session description customized for the client in the DESCRIBE reply.
ほとんどの場合、サーバーの相互運用性の責任は、それがクライアントの機能に関する情報がありません場合は、サーバーのパフォーマンスを提供し、「参照」セッション記述の制限の観点から説明されています。参照セッションは、クライアントがセッションを表示することができますオッズを最大化する「最小公分母」セッションです。サーバはクライアントの能力を認識している場合、サーバーはDESCRIBE応答でクライアントのためにカスタマイズされたセッション記述を提供して自由です。
Clients MUST support unicast UDP RTP MIDI streams that use the recovery journal with the closed-loop or the anchor sending policies. Clients MUST be able to interpret stream subsetting and chapter inclusion parameters in the session description that qualify the sending policies. Client support of enhanced Chapter C encoding is OPTIONAL.
クライアントは、閉ループまたはポリシーを送信するアンカーに回復ジャーナルを使用するユニキャストUDP RTP MIDIストリームをサポートしなければなりません。クライアントが送信したポリシーを修飾セッション記述でストリームのサブセットと章含めるパラメータを解釈できなければなりません。高められた章Cコード化のクライアントのサポートはオプションです。
The reference session description offered by a server MUST send all RTP MIDI UDP streams as unicast streams that use the recovery journal and the closed-loop or anchor sending policies. Servers SHOULD use the stream subsetting and chapter inclusion parameters in the reference session description to simplify the rendering task of the client. Server support of enhanced Chapter C encoding is OPTIONAL.
サーバーによって提供される参照セッション記述は、すべてのRTP MIDI UDPは回復ジャーナルと閉ループまたはアンカー送付方針を使用するユニキャストストリームとしてストリームを送らなければなりません。サーバーは、クライアントのレンダリングタスクを簡素化するために、参照セッション記述でストリームのサブセットと章含めるパラメータを使用すべきです。高められた章Cコード化のサーバーのサポートはオプションです。
Clients and servers MUST support the use of RTSP interleaved mode (a method for interleaving RTP onto the RTSP TCP transport).
クライアントとサーバーは、RTSP、インターリーブモード（RTSP TCP輸送にRTPをインターリーブするための方法）の使用をサポートしなければなりません。
Clients MUST be able to interpret the timestamp semantics signalled by the "comex" value of the tsmode parameter (i.e., the timestamp semantics of Standard MIDI Files [MIDI]). Servers MUST use the "comex" value for the tsmode parameter in the reference session description.
クライアントはtsmodeパラメータの「COMEX」値によってシグナリングタイムスタンプセマンティクスを解釈できなければならない（すなわち、スタンダードMIDIファイルのタイムスタンプ意味論[MIDI]）。サーバーは、参照セッション記述でtsmodeパラメータの「COMEX」の値を使用しなければなりません。
Clients MUST be able to process an RTP MIDI stream whose packets encode an arbitrary temporal duration ("media time"). Thus, in practice, clients MUST implement a MIDI playout buffer. Clients MUST NOT depend on the presence of rtp_ptime, rtp_maxtime, and guardtime parameters in the session description in order to process packets, but they SHOULD be able to use these parameters to improve packet processing.
クライアントは、そのパケットの任意の持続時間（「メディア時間」）をコードするRTP MIDIストリームを処理できなければなりません。したがって、実際には、クライアントは、MIDIの再生バッファを実装しなければなりません。クライアントは、パケットを処理するために、セッション記述でrtp_ptime、rtp_maxtime、およびguardtimeパラメータの存在に依存してはなりませんが、彼らは、パケット処理を改善するために、これらのパラメータを使用することができるはずです。
Servers SHOULD strive to send RTP MIDI streams in the same way media servers send conventional audio streams: a sequence of packets that all code either the same temporal duration (non-normative example: 50 ms packets) or one of an integral number of temporal durations (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms packets). Servers SHOULD encode information about the packetization method in the rtp_ptime and rtp_maxtime parameters in the session description.
または時間期間の整数のいずれかのすべてのコードのいずれかで同じ持続時間（50ミリ秒のパケット非規範的実施例）パケットのシーケンス：サーバはRTP MIDIメディアサーバーは、従来のオーディオストリームを送信するのと同じ方法でストリームを送信するために努力すべきです（非規範的実施例：50ミリ秒、100ミリ秒、250ミリ秒、又は500ミリ秒のパケット）。サーバは、セッション記述におけるrtp_ptimeとrtp_maxtimeパラメータのパケット化方法に関する情報を符号化するべきです。
Clients MUST be able to examine the render and subrender parameter to determine if a multimedia session uses a renderer it supports. Clients MUST be able to interpret the default "one" value of the multimode parameter to identify supported renderers from a list of renderer descriptions. Clients MUST be able to interpret the musicport parameter to the degree that it is relevant to the renderers it supports. Clients MUST be able to interpret the chanmask parameter.
クライアントは、マルチメディアセッションは、それがサポートしているレンダラを使用するかどうかを判断するためにレンダリングして、サブレンダラーのパラメータを調べることができなければなりません。クライアントは、レンダラ記述のリストからサポートレンダラーを識別するために、マルチモード・パラメータのデフォルトの「1」の値を解釈できなければなりません。クライアントは、それがサポートしているレンダラーに関連する度にmusicportパラメータを解釈できなければなりません。クライアントはchanmaskパラメータを解釈できなければなりません。
Clients supporting renderers whose data object (as encoded by a parameter value for inline) could exceed 300 octets in size MUST support the url and cid parameters and thus must implement the HTTP protocol in addition to RTSP. HTTP over TLS [RFC2818] support for data objects is OPTIONAL.
データオブジェクト（インラインのパラメータ値によってコードされる）サイズが300個のオクテットを超える可能性がURLおよびCIDパラメータをサポートしなければならないので、RTSPに加えて、HTTPプロトコルを実装しなければならないレンダラをサポートするクライアント。 HTTPは、TLS上で[RFC2818]は、データオブジェクトのサポートはオプションです。
Servers MUST specify complete rendering systems for RTP MIDI streams. Note that a minimal RTP MIDI native stream does not meet this requirement (Section 6.1), as the rendering method for such streams is "not specified".
サーバはRTP MIDIストリームのための完全なレンダリング・システムを指定しなければなりません。そのような流れのためのレンダリング方法は、「指定されていない」とされ、最小限のRTP MIDIネイティブストリームは、この要件（6.1節）を満たしていないことに注意してください。
At the time of writing this memo, the only way for servers to specify a complete rendering system is to specify an mpeg4-generic RTP MIDI stream in mode rtp-midi (Section 6.2 and Appendix C.6.5). As a consequence, the only rendering systems that may be presently used are General MIDI [MIDI], DLS 2 [DLS2], or Structured Audio [MPEGSA]. Note that the maximum inline value for General MIDI is well under 300 octets (and thus clients need not support the url parameter) and that the maximum inline values for DLS 2 and Structured Audio may be much larger than 300 octets (and thus clients MUST support the url parameter).
このメモを書いている時点で、サーバは完全なレンダリングシステムを指定するための唯一の方法は、モードRTP-MIDI（セクション6.2および付録C.6.5）にmpeg4-ジェネリックRTP MIDIストリームを指定することです。その結果、現在使用することができる唯一のレンダリングシステムは、一般的なMIDI [MIDI]、DLS 2 [DLS2]、または構造化されたオーディオ[MPEGSA]です。一般的なMIDIの最大インライン値がうまく下に300個のオクテットであることに注意してください（したがって、クライアントがURLパラメータをサポートする必要はありません）とDLS 2およびストラクチャード・オーディオの最大インライン値が300オクテットよりもはるかに大きくてもよいこと（したがって、クライアントがサポートしなければなりませんurlパラメータ）。
We anticipate that the owners of rendering systems (both standardized and proprietary) will register subrender parameters for their renderers. Once registration occurs, native RTP MIDI sessions may use render and subrender (Appendix C.6.2) to specify complete rendering systems for RTSP content-streaming multimedia sessions.
我々は（標準化と独自の両方）のレンダリングシステムの所有者は彼らのレンダラーのために、サブレンダラーのパラメータを登録することを期待しています。登録が発生すると、ネイティブのRTP MIDIセッションはRTSPコンテンツのストリーミングマルチメディアセッションのための完全なレンダリング・システムを指定するためにレンダリングし、サブレンダラー（付録C.6.2）使用することができます。
Servers MUST NOT use the sdp_start value for the smf_info parameter in the reference session description, as this use would require that clients be able to parse and render Standard MIDI Files.
この使用は、クライアントがスタンダードMIDIファイルを解析し、レンダリングすることができることを必要とするであろうとサーバーは、参照セッション記述でsmf_infoパラメータのsdp_start値を使用してはなりません。
Clients MUST support mpeg4-generic mode rtp-midi General MIDI (GM) sessions, at a polyphony limited by the hardware capabilities of the client. This requirement provides a "lowest common denominator" rendering system for content providers to target. Note that this requirement does not force implementors of a non-GM renderer (such as DLS 2 or Structured Audio) to add a second rendering engine. Instead, a client may satisfy the requirement by including a set of voice patches that implement the GM instrument set and using this emulation for mpeg4-generic GM sessions.
クライアントは、クライアントのハードウェアの能力によって制限ポリフォニーで、mpeg4-ジェネリックモードRTP-MIDIジェネラルMIDI（GM）セッションをサポートしなければなりません。この要件は、コンテンツプロバイダが対象とするため、「最小公分母」レンダリングシステムを提供します。この要件は、第二のレンダリングエンジンを追加するために、非GMレンダラ（のようなDLS 2または構造化されたオーディオ）の実装を強制しないことに注意してください。代わりに、クライアントは、GMの楽器セットを実装音声パッチのセットを含むとmpeg4-ジェネリックGMのセッションのために、このエミュレーションを使用して要件を満たすことがあります。
It is RECOMMENDED that servers use General MIDI as the renderer for the reference session description because clients are REQUIRED to support it. We do not require General MIDI as the reference renderer because it is an inappropriate choice for normative applications.
クライアントがそれをサポートする必要があるため、サーバが参照セッション記述のレンダラーとして一般的なMIDIを使用することをお勧めします。それは規範的な用途には不適切な選択であるので、我々は、参照レンダラとして一般的なMIDIを必要としません。
Servers using General MIDI as a "lowest common denominator" renderer SHOULD use Universal Real-Time SysEx Maximum Instantaneous Polyphony (MIP) messages [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
「最小公分母」として一般的なMIDIを使用してサーバーはレンダラはポリフォニー限定のクライアントへの声の優先順位を伝達するために、[SPMIDI]ユニバーサル・リアルタイム・システムエクスクルーシブ瞬間最大同時発音数（MIP）のメッセージを使用すべきです。
C.7.2. MIDI Network Musical Performance Applications
C.7.2。 MIDIネットワーク演奏アプリケーション
In Internet telephony and videoconferencing applications, parties interact over an IP network as they would face-to-face. Good user experiences require low end-to-end audio latency and tight audiovisual synchronization (for "lip-sync"). The Session Initiation Protocol (SIP, [RFC3261]) is used for session management.
彼らは対面と同じようにインターネット電話やビデオ会議アプリケーションでは、当事者は、IPネットワーク上で対話します。優れたユーザーエクスペリエンスは、（「リップシンク」のための）低エンドツーエンドの音声遅延とタイトな視聴覚同期させる必要があります。セッション開始プロトコル（SIPは、[RFC3261]）セッション管理のために使用されます。
In this appendix section, we define interoperability guidelines for using RTP MIDI streams in interactive SIP applications. Our primary interest is supporting Network Musical Performances (NMPs), where musicians in different locations interact over the network as if they were in the same room. See [NMP] for background information on NMP, and see [RFC4696] for a discussion of low-latency RTP MIDI implementation techniques for NMP.
この付録のセクションでは、私たちはRTP MIDIを使用するための相互運用性のガイドラインを定義するには、インタラクティブなSIPアプリケーションでストリーム。当社の主要な関心は、彼らが同じ部屋にいたかのように、異なる場所でのミュージシャンは、ネットワークを介して相互に作用ネットワークの演奏（NMPS）を支援しています。 NMPの背景情報については、[NMP]参照、およびNMPのための低遅延RTP MIDI実装技術の議論のために[RFC4696]を参照。
Note that the goal of NMP applications is telepresence: the parties should hear audio that is close to what they would hear if they were in the same room. The interoperability guidelines in this appendix address RTP MIDI applications of this nature, not applications such as the transmission of raw MIDI command streams for use in a professional environment (recording studio, performance stage, etc.).
当事者は、彼らが同じ部屋にいた場合、彼らは聞くものに近い音声を聞く必要があります：NMPアプリケーションの目標は、テレプレゼンスであることに注意してください。このような性質のこの付録アドレスRTP MIDIアプリケーションではなく、このような専門的な環境（など、レコーディングスタジオ、パフォーマンスステージ）での使用のための生のMIDIコマンドストリームの伝送などのアプリケーションにおける相互運用性のガイドライン。
We focus on session management for two-party unicast sessions that specify a renderer for RTP MIDI streams. Within this limited scope, the guidelines defined here are sufficient to let applications interoperate. We define the REQUIRED capabilities of RTP MIDI senders and receivers in NMP sessions and define how session descriptions exchanged are used to set up network musical performance sessions.
私たちはRTP MIDIストリームのレンダラーを指定する2つのパーティのユニキャストセッションのセッション管理に焦点を当てています。この限られた範囲内では、ここで定義されたガイドラインは、アプリケーションが相互運用聞かせするのに十分です。私たちは、ネットワークのミュージカルパフォーマンスセッションを設定するために使用されているNMPセッションでRTP MIDIの送信者と受信者の必要な機能を定義して、セッション記述を交換する方法を定義します。
SIP lets parties negotiate details of the session using the Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many parameters that "blind" negotiations between two parties might not yield a common session configuration.
SIPは、当事者がオファー/回答プロトコル[RFC3264]を使用してセッションの詳細を交渉することができます。しかし、RTP MIDIは二者間の「ブラインド」の交渉が共通のセッション構成が得られない場合がありますので、多くのパラメータがあります。
Thus, we now define a set of capabilities that NMP parties MUST support. Session description offers whose options lie outside the envelope of REQUIRED party behavior risk negotiation failure. We also define session description idioms that the RTP MIDI part of an offer MUST follow in order to structure the offer for simpler analysis.
このように、我々は今、NMPの当事者がサポートしなければならない機能のセットを定義します。セッション記述は、そのオプションREQUIREDパーティの行動のリスク交渉失敗のエンベロープの外側に位置しています。我々はまた、オファーのRTP MIDI部分はシンプルな分析のためのオファーを構築するために従わなければならないセッション記述イディオムを定義します。
We use the term "offerer" for the party making a SIP offer and "answerer" for the party answering the offer. Finally, we note that unless it is qualified by the adjective "sender" or "receiver", a statement that a party MUST support X implies that it MUST support X for both sending and receiving.
我々は提供に答えるパーティーのためにSIPの提供と「回答」を作るパーティーのために用語「オファー側」を使用します。最後に、我々はそれが形容詞「送信者」または「受信機」、当事者はXをサポートしなければならないことを声明で修飾されていない限り、それは両方の送信と受信のためにXをサポートしなければならないことを意味することに注意してください。
If an offerer wishes to define a "sendrecv" RTP MIDI stream, it may use a true sendrecv session or the "virtual sendrecv" construction described in the preamble to Appendix C and in Appendix C.5. A true sendrecv session indicates that the offerer wishes to participate in a session where both parties use identically configured renderers. A virtual sendrecv session indicates that the offerer is willing to participate in a session where the two parties may be using different renderer configurations. Thus, parties MUST be prepared to see both real and virtual sendrecv sessions in an offer.
オファーが「のsendrecv」RTP MIDIストリームを定義したい場合、それは本当のsendrecvセッションまたは付録Cおよび付録C.5プリアンブルに記載された「仮想のsendrecv」構造を使用してもよいです。本当のsendrecvセッションは、オファーが両当事者が同じ設定にレンダラーを使用したセッションに参加することを望んでいることを示しています。仮想のsendrecvセッションは申出は、2人の当事者が異なるレンダラ構成を使用することができるセッションに参加する意思があることを示しています。したがって、当事者は、提供中の両方の現実と仮想のsendrecvセッションを確認するために準備しなければなりません。
Parties MUST support unicast UDP transport of RTP MIDI streams. These streams MUST use the recovery journal with the closed-loop or anchor sending policies. These streams MUST use the stream subsetting and chapter inclusion parameters to declare the types of MIDI commands that will be sent on the stream (for sendonly streams) or will be processed (for recvonly streams), including the size limits on System Exclusive commands. Support of enhanced Chapter C encoding is OPTIONAL.
締約国はRTP MIDIストリームのユニキャストUDPトランスポートをサポートしなければなりません。これらのストリームは、閉ループまたはアンカー送付方針に回復ジャーナルを使用しなければなりません。これらのストリームは、システムエクスクルーシブコマンドにサイズ制限を含む（がrecvonlyストリーム用）（sendonlyのストリームの）ストリーム上で送信されるか、処理されるMIDIコマンドのタイプを宣言するストリームのサブセットとチャプタ包含パラメータを使用しなければなりません。高められた章Cコード化のサポートはオプションです。
Note that both TCP and multicast UDP support are OPTIONAL. We make TCP OPTIONAL because we expect NMP renderers to rely on data objects (signalled by rinit and associated parameters) for initialization at the start of the session and only to use System Exclusive commands for interactive control during the session. These interactive commands are small enough to be protected via the recovery journal mechanism of RTP MIDI UDP streams.
TCPおよびUDPマルチキャストのサポートの両方がオプションであることに注意してください。我々はNMPレンダラーは、セッションの開始時に初期化（RINITと関連するパラメータによって合図）データオブジェクトに依存するだけでシステムエクスクルーシブは、セッション中に対話制御用コマンドを使用することを期待ので、私たちはTCPをオプションに。これらの対話型のコマンドは、RTP MIDI UDPストリームの回復ジャーナル機構を介して保護されるのに十分小さいです。
We now discuss timestamps, packet timing, and packet-sending algorithms.
私たちは今、タイムスタンプ、パケットタイミング、およびパケット送信のアルゴリズムを議論します。
Recall that the tsmode parameter controls the semantics of command timestamps in the MIDI list of RTP packets.
tsmodeパラメータは、RTPパケットのMIDIリストにコマンドのタイムスタンプのセマンティクスを制御していることを思い出してください。
Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96 kHz. Parties MUST support streams using the "comex", "async", and "buffer" tsmode values. Recvonly offers MUST offer the default "comex".
当事者は44.1kHzで、48キロヘルツ、88.2キロヘルツ、96キロヘルツのクロック・レートをサポートしなければなりません。当事者は、「COMEX」、「非同期」を使用してストリームをサポートし、tsmode値を「バッファ」しなければなりません。 RECVONLY申し出は、デフォルトの「COMEX」を提供しなければなりません。
Parties MUST support a wide range of packet temporal durations: from rtp_ptime and rtp_maxptime values of 0, to rtp_ptime and rtp_maxptime values that code 100 ms. Thus, receivers MUST be able to implement a playout buffer.
、0のrtp_ptimeとrtp_maxptime値からrtp_ptimeするとrtp_maxptime値コード100 MS：当事者は、パケット時間期間の広い範囲をサポートしなければなりません。したがって、受信機は、再生バッファを実装することができなければなりません。
Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime values that support the latency that users would expect in the application, subject to bandwidth constraints. As senders MUST abide by values set for these parameters in a session description, a receiver SHOULD use these values to size its playout buffer to produce the lowest reliable latency for a session. Implementors should refer to [RFC4696] for information on packet-sending algorithms for latency-sensitive applications. Parties MUST be able to implement the semantics of the guardtime parameter for times from 5 ms to 5000 ms.
オファーと回答は、ユーザーが、アプリケーションに帯域幅の制約を受けるを期待するの待ち時間をサポートrtp_ptime、rtp_maxptime、およびguardtime値を提示しなければなりません。送信者は、セッション記述において、これらのパラメータに設定された値を遵守しなければならないので、受信機は、セッションの最低信頼レイテンシを生成する大きさに、その再生バッファをこれらの値を使用すべきです。実装者は、レイテンシに敏感なアプリケーションのためのパケット送信アルゴリズムについては、[RFC4696]を参照されたいです。締約国は5000ミリ秒に5ミリから回guardtimeパラメータのセマンティクスを実装することができなければなりません。
We now discuss the use of the render parameter.
私たちは今、レンダリングパラメータの使用について説明します。
Sessions MUST specify complete rendering systems for all RTP MIDI streams. Note that a minimal RTP MIDI native stream does not meet this requirement (Section 6.1), as the rendering method for such streams is "not specified".
セッションは、すべてのRTP MIDIストリームのための完全なレンダリング・システムを指定しなければなりません。そのような流れのためのレンダリング方法は、「指定されていない」とされ、最小限のRTP MIDIネイティブストリームは、この要件（6.1節）を満たしていないことに注意してください。
At the time of this writing, the only way for parties to specify a complete rendering system is to specify an mpeg4-generic RTP MIDI stream in mode rtp-midi (Section 6.2 and Appendix C.6.5). We anticipate that the owners of rendering systems (both standardized and proprietary) will register subrender values for their renderers. Once IANA registration occurs, native RTP MIDI sessions may use render and subrender (Appendix C.6.2) to specify complete rendering systems for SIP network musical performance multimedia sessions.
この記事の執筆時点では、完全なレンダリング・システムを指定するには、当事者のための唯一の方法は、モードRTP-MIDI IN mpeg4-ジェネリックRTP MIDIストリーム（セクション6.2および付録C.6.5）を指定することです。我々は（標準化と独自の両方）のレンダリングシステムの所有者は彼らのレンダラーのために、サブレンダラーの値を登録することを期待しています。 IANA登録が発生すると、ネイティブのRTP MIDIセッションは、SIPネットワークのミュージカル・パフォーマンス・マルチメディアセッションのための完全なレンダリング・システムを指定するためにレンダリングし、サブレンダラー（付録C.6.2）使用することができます。
All parties MUST support General MIDI (GM) sessions at a polyphony limited by the hardware capabilities of the party. This requirement provides a "lowest common denominator" rendering system, without which practical interoperability will be quite difficult. When using GM, parties SHOULD use Universal Real-Time SysEx MIP messages [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
すべての当事者は、パーティのハードウェアの能力によって制限ポリフォニーでジェネラルMIDI（GM）セッションをサポートしなければなりません。この要件は、実用的な相互運用性は非常に難しいだろうそれなし「最小公分母」レンダリングシステムを提供します。 GMを使用する場合、当事者はポリフォニー限定のクライアントへの声の優先順位を伝達するために、[SPMIDI]ユニバーサル・リアルタイムのSysEx MIPメッセージを使用すべきです。
Note that this requirement does not force implementors of a non-GM renderer (for mpeg4-generic sessions, DLS 2, or Structured Audio) to add a second rendering engine. Instead, a client may satisfy the requirement by including a set of voice patches that implement the GM instrument set and using this emulation for mpeg4-generic GM sessions. We require GM support so that an offerer that wishes to maximize interoperability may do so by offering GM if its preferred renderer is not accepted by the answerer.
この要件は、第二のレンダリングエンジンを追加するために、非GM（mpeg4-ジェネリックセッションのために、DLS 2、または構造化されたオーディオ）レンダラの実装を強制しないことに注意してください。代わりに、クライアントは、GMの楽器セットを実装音声パッチのセットを含むとmpeg4-ジェネリックGMのセッションのために、このエミュレーションを使用して要件を満たすことがあります。その好ましいレンダラーが回答によって受け入れられない場合は、相互運用性を最大化することを希望するオファー側はGMを提供することによってそれを行うことができるように我々はGMのサポートを必要とします。
Offerers MUST NOT present several renderers as options in a session description by listing several payload types on a media line, as Section 2.1 uses this construct to let a party send several RTP MIDI streams in the same RTP session.
2.1節は、当事者が、いくつかのRTP MIDIが同じRTPセッション中にストリームを送信できるように、この構文を使用して申し出人は、メディアライン上のいくつかのペイロードタイプをリストすることにより、セッション記述のオプションとして、いくつかのレンダラーを提示してはなりません。
Instead, an offerer wishing to present rendering options SHOULD offer a single payload type that offers several renderers. In this construct, the parameter list codes a list of render parameters (each followed by its support parameters). As discussed in Appendix C.6.1, the order of renderers in the list declares the offerer's preference. The "unknown" and "null" values MUST NOT appear in the offer. The answer MUST set all render values except the desired renderer to "null". Thus, "unknown" MUST NOT appear in the answer.
代わりに、レンダリングオプションを提示したいの申し出人は、いくつかのレンダラを提供する、単一のペイロードタイプを提供する必要があります。この構築物において、パラメータリストのコードレンダリングパラメータ（各々は、そのサポート・パラメータが続く）のリスト。付録C.6.1で説明したように、リスト内のレンダラーの順序は、オファー側の好みを宣言します。 「不明」と「ヌル」値は、提供に現れてはいけません。答えは、すべてが希望レンダラに「ヌル」以外の値をレンダリング設定しなければなりません。このように、「不明」の答えに現れてはいけません。
We use SHOULD instead of MUST in the first sentence in the paragraph above because this technique does not work in all situations (for example, if an offerer wishes to offer both mpeg4-generic renderers and native RTP MIDI renderers as options). In this case, the offerer MUST present a series of session descriptions, each offering a single renderer, until the answerer accepts a session description.
（オファー側がオプションとしてmpeg4-ジェネリックレンダラーとネイティブのRTP MIDIレンダラーの両方を提供することを希望する場合、たとえば）この技術はすべての状況では動作しませんので、我々はSHOULDの代わりに、上記の段落の最初の文でMUSTを使用します。回答がセッション記述を受け付けるまでは、この場合、提供者は、各々が単一のレンダラを提供し、セッション記述のシリーズを提示しなければなりません。
Parties MUST support the musicport, chanmask, subrender, rinit, and inline parameters. Parties supporting renderers whose data object (as encoded by a parameter value for inline) could exceed 300 octets in size MUST support the url and cid parameters and thus must implement the HTTP protocol. HTTP over TLS [RFC2818] support for data objects is OPTIONAL. Note that in mpeg4-generic, General MIDI data objects cannot exceed 300 octets, but DLS 2 and Structured Audio data objects may. Support for the other rendering parameters (smf_cif, smf_info, smf_inline, smf_url) is OPTIONAL.
締約国はmusicport、chanmask、サブレンダラー、RINIT、およびインラインパラメータをサポートしなければなりません。データオブジェクト（インラインのパラメータ値によってコードされる）サイズが300個のオクテットを超える可能性がURLおよびCIDパラメータをサポートしなければならないので、HTTPプロトコルを実装しなければならないレンダラを支持する当事者。 HTTPは、TLS上で[RFC2818]は、データオブジェクトのサポートはオプションです。 mpeg4-ジェネリックでは、一般的なMIDIデータオブジェクトが300個のオクテットを超えることができないことに注意してください、しかし、DLS 2と構造化オーディオデータオブジェクトは、があります。他のレンダリングパラメータ（smf_cif、smf_info、smf_inline、smf_url）のためのサポートはオプションです。
Thus far in this document, our discussion has assumed that the only MIDI flows that drive a renderer are the network flows described in the session description. In NMP applications, this assumption would require two rendering engines: one for local use by a party and a second for the remote party.
これまでのところ、この文書では、我々の議論は、レンダラを駆動のみMIDIフローは、ネットワークがセッションの説明に記載流れていることを前提としています。当事者によるローカルでの使用のための1と相手のための第二：NMPのアプリケーションでは、この仮定は、二つのレンダリングエンジンを必要とします。
In practice, applications may wish to have both parties share a single rendering engine. In this case, the session description MUST use a virtual sendrecv session and MUST use the stream subsetting and chapter inclusion parameters to allocate which MIDI channels are intended for use by a party. If two parties are sharing a MIDI channel, the application MUST ensure that appropriate MIDI merging occurs at the input to the renderer.
実際には、アプリケーションでは、両当事者は、単一のレンダリングエンジンを共有することを望む場合があります。この場合、セッション記述は、仮想のsendrecvセッションを使用しなければならないし、MIDIチャンネルがパーティによる使用のために意図されている割り当てるストリームのサブセットとチャプタ包含パラメータを使用しなければなりません。両当事者は、MIDIチャンネルを共有している場合、アプリケーションが適切なMIDIのマージはレンダラへの入力で発生することを保証しなければなりません。
We now discuss the use of (non-MIDI) audio streams in the session.
私たちは今、セッション中（非MIDI）オーディオストリームの使用を議論します。
Audio streams may be used for two purposes: as a "talkback" channel for parties to converse or as a way to conduct a performance that includes MIDI and audio channels. In the latter case, offers MUST use sample rates and the packet temporal durations for the audio and MIDI streams that support low-latency synchronized rendering.
オーディオストリームは2つの目的のために使用することができる。当事者が会話するための「トークバック」チャンネルとして、またはMIDIとオーディオチャンネルが含まれてパフォーマンスを行うための方法として。後者の場合、申し出は、低遅延同期レンダリングをサポートし、オーディオとMIDIストリームのためのサンプル・レートとパケット時間的期間を使用しなければなりません。
We now show an example of an offer/answer exchange in a network musical performance application.
私たちは今、ネットワークミュージカル・パフォーマンス・アプリケーションでのオファー/アンサー交換の一例を示しています。
Below, we show an offer that complies with the interoperability text in this appendix section.
以下に、私たちは、この付録のセクションでの相互運用性のテキストに準拠プランを示しています。
v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 16112 RTP/AVP 96
a=recvonly
a=mid:1
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW;
cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2;
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123;
ch_default=2M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit=audio/asc;
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
m=audio 16114 RTP/AVP 96
a=sendonly
a=mid:2
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW;
cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2;
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123;
ch_default=1M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit=audio/asc;
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
(The a=fmtp lines have been wrapped to fit the page to accommodate memo formatting restrictions; it comprises a single line in SDP.)
（A =のfmtpラインが制限をフォーマットするメモに対応するために、ページに収まるようにラップされている、それはSDP内の1行を含みます。）
The owner line (o=) identifies the session owner as "first".
所有者回線（= O）は、「第一」、セッション所有者を識別する。
The session description defines two MIDI streams: a recvonly stream on which "first" receives a performance and a sendonly stream that "first" uses to send a performance. The recvonly port number encodes the ports on which "first" wishes to receive RTP (16112) and RTCP (16113) media at IP4 address 192.0.2.94. The sendonly port number encodes the port on which "first" wishes to receive RTCP for the stream (16115).
「最初の」性能と「最初の」パフォーマンスを送信するために使用することがsendonlyのストリームを受信したがrecvonlyストリーム：セッション記述には2つのMIDIストリームを定義します。 recvonlyでポート番号のポートをコードする「最初の」はIP4アドレス192.0.2.94でRTP（16112）及びRTCP（16113）メディアを受信することを望みます。 sendonlyのポート番号は「最初」のポートをコードストリーム（16115）のためにRTCPを受信することを望みます。
The musicport parameters code that the two streams share an identity relationship and thus form a virtual sendrecv stream.
二つの流れは、このように同一の関係を共有し、musicportパラメータコードは、仮想のsendrecvストリームを形成します。
Both streams are mpeg4-generic RTP MIDI streams that specify a General MIDI renderer. The stream subsetting parameters code that the recvonly stream uses MIDI channel 1 exclusively for voice commands and that the sendonly stream uses MIDI channel 2 exclusively for voice commands. This mapping permits the application software to share a single renderer for local and remote performers.
両方のストリームはmpeg4-ジェネリックRTP MIDIはそれが一般的なMIDIレンダラーを指定するストリームです。がrecvonlyストリームは音声コマンドのためにとsendonlyの流れという専用のMIDIチャンネル1を使用してストリームサブセットのパラメータコードは、音声コマンド専用のMIDIチャンネル2を使用しています。このマッピングは、ローカルおよびリモートのパフォーマーのための単一のレンダラを共有するためのアプリケーションソフトウェアを許可します。
We now show the answer to the offer.
現在のオファーに対する答えを示しています。
v=0
o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.105
m=audio 5004 RTP/AVP 96
a=sendonly
a=mid:1
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW;
cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2;
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123;
ch_default=2M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=882; guardtime=44100;
musicport=1; render=synthetic; rinit=audio/asc;
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
m=audio 5006 RTP/AVP 96
a=recvonly
a=mid:2
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW;
cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2;
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123;
ch_default=1M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=88200;
musicport=1; render=synthetic; rinit=audio/asc;
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" (The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP.)
The owner line (o=) identifies the session owner as "second".
所有者回線（= O）は、「第二」、セッション所有者を識別する。
The port numbers for both media streams are non-zero; thus, "second" has accepted the session description. The stream marked "sendonly" in the offer is marked "recvonly" in the answer and vice versa, coding the different view of the session held by "session". The IP4 number (192.0.2.105), RTP (5004 and 5006), and RTCP (5005 and 5007) have been changed by "second" to match its transport wishes.
両方のメディアストリームのポート番号が非ゼロです。このように、「第二」セッション記述を受け入れました。ストリームは「sendonlyで」提供の「セッション」で開催されたセッションの別のビューをコーディング、解答とその逆に「recvonlyで」マークされているマーク。 IP4番号（192.0.2.105）、RTP（5004及び5006）、及びRTCP（5005及び5007）は、トランスポート希望と一致するように、 "第二" により変更されています。
In addition, "second" has made several parameter changes: rtp_maxptime for the sendonly stream has been changed to code 2 ms (441 in clock units), and the guardtime for the recvonly stream has been doubled. As these parameter modifications request capabilities that are REQUIRED to be implemented by interoperable parties, "second" can make these changes with confidence that "first" can abide by them.
sendonlyの流れのためのrtp_maxptimeコード2つのMS（クロック単位で441）に変更されている、がrecvonlyストリームに対するguardtimeが倍増されている。また、「第二」いくつかのパラメータの変更を行いました。相互運用性の当事者によって実装される必要があるこれらのパラメータの変更要求機能として、「第二」「第一」はそれらを遵守できるという自信を持ってこれらの変更を行うことができます。
Appendix D. Parameter Syntax Definitions
付録D.パラメータ構文の定義
In this appendix, we define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form (ABNF, [RFC5234]). When using these parameters with SDP, all parameters MUST appear on a single fmtp attribute line of an RTP MIDI media description. For mpeg4-generic RTP MIDI streams, this line MUST also include any mpeg4-generic parameters (usage described in Section 6.2). An fmtp attribute line may be defined (after [RFC3640]) as:
この付録では、我々は、拡張バッカス記法（ABNF、[RFC5234]）でRTP MIDIメディアタイプパラメータの構文を定義します。 SDPでこれらのパラメータを使用する場合は、すべてのパラメータは、RTP MIDIメディア記述の単一のfmtp属性の行に表示されなければなりません。 mpeg4-ジェネリックRTP MIDIストリームのために、この行は、（セクション6.2で説明し使用）任意MPEG4-汎用パラメータを含まなければなりません。 fmtp属性行は、AS（[RFC3640]の後に）定義することができます。
;
; SDP fmtp line definition
;
fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF
fmtp = "A =のfmtp：" トークンSP PARAM-割り当てる0 *（ ";" SPのPARAMアサイン）CRLF
where <token> codes the RTP payload type. Note that white space MUST NOT appear between the "a=fmtp:" and the RTP payload type.
ここで、<トークン>コードRTPペイロードタイプ。 RTPペイロードタイプ：ホワイトスペースは「A =のfmtp」の間に表示さいけないことに注意してください。
We now define the syntax of the parameters defined in Appendix C. The definition takes the form of the incremental assembly of the <param-assign> token. See [RFC3640] for the syntax of the mpeg4-generic parameters discussed in Section 6.2.
現在の定義は、トークンの<param-割り当て>の増分アセンブリの形を取り、付録C.で定義されたパラメータの構文を定義します。 6.2節で述べたmpeg4-ジェネリックパラメータの構文については、[RFC3640]を参照してください。
;
;
; top-level definition for all parameters
;
;
；
; ; Parameters defined in Appendix C.1
; ;付録C.1で定義されたパラメータ
param-assign = ("cm_unused=" (([channel-list] command-type [f-list]) / sysex-data))
PARAMアサイン=（ "cm_unused ="（（[チャンネルリスト]コマンド型[F-リスト]）/システムエクスクルーシブデータ））
param-assign =/ ("cm_used=" (([channel-list] command-type [f-list]) / sysex-data))
PARAMアサイン= /（ "cm_used ="（（[チャンネルリスト]コマンド型[F-リスト]）/システムエクスクルーシブデータ））
; ; Parameters defined in Appendix C.2
; ;付録C.2で定義されたパラメータ
param-assign =/ ("j_sec=" ("none" / "recj" / ietf-extension))
PARAMアサイン= /（ "j_秒="（ "なし" / "recj" / IETF-拡張））
param-assign =/ ("j_update=" ("anchor" / "closed-loop" / "open-loop" / ietf-extension))
PARAMアサイン= /（ "j_アップデート="（ "アンカー" / "閉ループ" / "オープンループ" / IETF-拡張））
param-assign =/ ("ch_default=" (([channel-list] chapter-list [f-list]) / sysex-data))
PARAMアサイン= /（「デフォルト=」（（[チャンネルリスト]チャプターリスト〔のリスト]）/システムエクスクルーシブデータ））
param-assign =/ ("ch_never=" (([channel-list] chapter-list [f-list]) / sysex-data))
PARAMアサイン= /（ "ch_never ="（（[チャンネルリスト]チャプターリスト[F-リスト]）/システムエクスクルーシブデータ））
param-assign =/ ("ch_anchor=" (([channel-list] chapter-list [f-list]) / sysex-data))
PARAMアサイン= /（ "CHアンカー="（（[チャンネルリスト]チャプターリスト〔のリスト]）/システムエクスクルーシブデータ））
; ; Parameters defined in Appendix C.3
; ;付録C.3で定義されたパラメータ
param-assign =/ ("tsmode=" ("comex" / "async" / "buffer"))
PARAMアサイン= /（ "tsmode ="（ "COMEX" / "非同期" / "バッファ"））
param-assign =/ ("linerate=" nonzero-four-octet)
PARAMアサイン= /（「回線レート=」非ゼロ4オクテット）
param-assign =/ ("octpos=" ("first" / "last"))
PARAMアサイン= /（ "octpos ="）（ "第一" / "最後"）
param-assign =/ ("mperiod=" nonzero-four-octet)
PARAMアサイン= /（「mperiod =」非ゼロ4オクテット）
; ; Parameter defined in Appendix C.4
; ;付録C.4で定義されたパラメータ
param-assign =/ ("guardtime=" nonzero-four-octet)
PARAMアサイン= /（「guardtime =」非ゼロ4オクテット）
param-assign =/ ("rtp_ptime=" four-octet)
PARAMアサイン= /（ "rtp_ptime =" 4オクテット）
param-assign =/ ("rtp_maxptime=" four-octet)
PARAMアサイン= /（ "rtp_maxptime =" 4オクテット）
; ; Parameters defined in Appendix C.5
; ;付録C.5で定義されたパラメータ
param-assign =/ ("musicport=" four-octet)
PARAMアサイン= /（ "musicport =" 4オクテット）
; ; Parameters defined in Appendix C.6
; ;付録C.6で定義されたパラメータ
param-assign =/ ("chanmask=" 1*( 16(BIT) ))
PARAMアサイン= /（ "chanmask =" 1 *（16（BIT）））
param-assign =/ ("cid=" DQUOTE cid-block DQUOTE)
PARAMアサイン= /（ "CID =" DQUOTE CIDブロックDQUOTE）
param-assign =/ ("inline=" DQUOTE base-64-block DQUOTE)
PARAMアサイン= /（ "インライン=" DQUOTEベース64ブロックDQUOTE）
param-assign =/ ("multimode=" ("all" / "one"))
PARAMアサイン= /（ "マルチ="（ "全て" / "1"））
param-assign =/ ("render=" ("synthetic" / "api" / "null" / "unknown" / extension))
PARAMアサイン= /（ "レンダリング="（ "合成" / "API" / "NULL" / "未知" /伸長））
param-assign =/ ("rinit=" mime-type "/" mime-subtype)
PARAMアサイン= /（ "RINIT =" MIMEタイプ "/" MIMEサブタイプ）
param-assign =/ ("smf_cid=" DQUOTE cid-block DQUOTE)
PARAMアサイン= /（ "smf_cid =" DQUOTE CIDブロックDQUOTE）
param-assign =/ ("smf_info=" ("ignore" / "identity" / "sdp_start" / extension))
PARAMアサイン= /（ "smf_info ="（ "無視する" / "同一性" / "sdp_start" /伸長））
param-assign =/ ("smf_inline=" DQUOTE base-64-block DQUOTE)
PARAMアサイン= /（ "smf_inline =" DQUOTEベース64ブロックDQUOTE）
param-assign =/ ("smf_url=" DQUOTE uri-element DQUOTE)
PARAMアサイン= /（ "smf_url =" DQUOTE URI-要素DQUOTE）
param-assign =/ ("subrender=" ("default" / extension))
PARAMアサイン= /（ "サブレンダラー="（ "デフォルト" /伸長））
param-assign =/ ("url=" DQUOTE uri-element DQUOTE)
PARAMアサイン= /（ "URL =" DQUOTEのuri要素DQUOTE）
;
; list definitions for the cm_ command-type
;
command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
コマンドタイプ= [A] [B] [C] [F] [G]、[H] [J] [K] [M] [N] [P] [Q] [T] [V] [W] [ X] [Y] [Z]
;
; list definitions for the ch_ chapter-list
;
chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
チャプターリスト= [A] [B] [C] [D] [E]、[F]、[G]、[H] [J] [K] [M] [N] [P] [Q] [T] [ V] [W] [X] [Y] [Z]
;
; list definitions for the channel-list (used in ch_* / cm_* params)
;
channel-list = midi-chan-element *("." midi-chan-element)
チャンネルリスト= MIDIちゃん要素*（「」MIDIちゃん要素）
midi-chan-element = midi-chan / midi-chan-range
MIDIちゃんちゃん要素=ミディ/ミディチャンレンジ
midi-chan-range = midi-chan "-" midi-chan ; ; Decimal value of left midi-chan ; MUST be strictly less than ; decimal value of right midi-chan.
MIDIチャンレンジ= MIDIちゃん「 - 」MIDIちゃん。 ;左ミディちゃんの10進値。より厳密に小さくなければなりません。右ミディちゃんの10進数値です。
midi-chan = DIGIT / ("1" %x30-35) ; "0" .. "15"
MIDIちゃん= DIGIT /（ "1" ％のx30-35）。 "0" .. "15"
;
; list definitions for the ch_ field list (f-list)
;
f-list = midi-field-element *("." midi-field-element)
F-リスト=ミディフィールド要素*（ "" ミディフィールド要素）
midi-field-element = midi-field / midi-field-range
MIDIフィールド要素= MIDIフィールド/ MIDI視野範囲
midi-field-range = midi-field "-" midi-field ; ; Decimal value of left midi-field ; MUST be strictly less than ; decimal value of right midi-field.
ミディ・フィールド・レンジ=ミディフィールド " - " MIDI-フィールド; ;左ミディフィールドの10進値。より厳密に小さくなければなりません。右ミディフィールドの10進数値です。
midi-field = four-octet ; ; Large range accommodates Chapter M ; RPN (0-16383), NRPN (16384-32767) ; parameters, and Chapter X octet sizes.
ミディ・フィールド= 4オクテット; ;大規模な範囲は章Mを収納します。 RPN（0から16383）、NRPN（16384から32767）。パラメータ、および章Xオクテットのサイズ。
;
; definitions for ch_ sysex-data
;
sysex-data = "__" h-list *("_" h-list) "__"
システムエクスクルーシブデータ= "__" H-リスト*（ "_" H-リスト） "__"
h-list = hex-field-element *("." hex-field-element)
H-リスト=ヘキサフィールド要素*（ "" ヘキサフィールド要素）
hex-field-element = hex-octet / hex-field-range hex-field-range = hex-octet "-" hex-octet ; ; Hexadecimal value of left hex-octet ; MUST be strictly less than hexadecimal ; value of right hex-octet.
ヘキサフィールド要素=ヘキサオクテット/ヘキサフィールドレンジヘキサフィールドレンジ=ヘキサオクテット「 - 」六角オクテット。 ;左進オクテットの進数値。進数より厳密に小さくなければなりません。右進オクテットの値。
hex-octet = %x30-37 U-HEXDIG ; ; Rewritten special case of hex-octet in ; [RFC2045] (page 23). ; Note that a-f are not permitted, only A-F. ; hex-octet values MUST NOT exceed 0x7F.
ヘキサオクテット=％x30-37 U-HEXDIG。 ;進オクテット内の特殊なケースを書き直します。 [RFC2045]（23ページ）。 ; -Fは、専用Fを許可されないことに留意されたいです。 ;進オクテットの値が0x7Fのを超えてはなりません。
;
; definitions for rinit parameter
;
mime-type = "audio" / "application"
MIMEタイプ=「オーディオ」/「アプリケーション」
mime-subtype = subtype-name
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.
;
; subtype-name is defined in [RFC4288],
; Section 4.2.
;
; Definitions for base64 encoding
; copied from [RFC4566]
; changes from [RFC4566] to improve automatic syntax checking.
;
base-64-block = *base64-unit [base64-pad]
BASE64ブロック= * BASE64ユニット[BASE64パッド]
base64-unit = 4(base64-char)
BASE64ユニット= 4（base64でCHAR）
base64-pad = (2(base64-char) "==") / (3(base64-char) "=")
Bsi64ランク=（2（Bsi64個） "=="）/（3（Bsi64個） "="）
base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/" ; A-Z, a-z, 0-9, "+" and "/"
base64でチャー=％x41-5A /％x61-7A /％x30-39 / "+" / "/"。 -Z、Z、0-9、 "+" と "/"
;
; generic rules
;
ietf-extension = token ; ; may only be defined in Standards-Track RFCs
IETF拡張=トークン。 ;唯一の標準化過程のRFCで定義することができ
extension = token ; ; may be defined ; by filing a registration with IANA
拡張子=トークン。 ;定義されてもよいです。 IANAに登録を提出することにより、
nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) / (%x31-33 9(DIGIT)) / ("4" %x30-31 8(DIGIT)) / ("42" %x30-38 7(DIGIT)) / ("429" %x30-33 6(DIGIT)) / ("4294" %x30-38 5(DIGIT)) / ("42949" %x30-35 4(DIGIT)) / ("429496" %x30-36 3(DIGIT)) / ("4294967" %x30-31 2(DIGIT)) / ("42949672" %x30-38 (DIGIT)) / ("429496729" %x30-34) ; ; unsigned encoding of non-zero 32-bit value: ; 1 .. 4294967295
非ゼロ4オクテット=（NZ-DIGIT 0 * 8（DIGIT））/（％x31-33 9（DIGIT））/（ "4" ％x30-31 8（DIGIT））/（ "42" ％x30- 38 7（DIGIT））/（ "429" ％x30-33 6（DIGIT））/（ "4294" ％x30-38 5（DIGIT））/（ "42949" ％x30-35 4（DIGIT））/（ "429496" ％x30-36 3（DIGIT））/（ "4294967" ％x30-31 2（DIGIT））/（ "42949672" ％のx30-38（DIGIT））/（ "429496729" ％のx30-34）。 ;非ゼロの32ビット値の符号なしエンコード; 1 ... 4294967295
four-octet = "0" / nonzero-four-octet ; ; unsigned encoding of 32-bit value: ; 0 .. 4294967295
4オクテット=「0」/非ゼロ4オクテット。 ; 32ビット値の符号なしエンコード; 0 .. 4294967295
uri-element = URI-reference ; as defined in [RFC3986]
URI-要素= URI参照。 [RFC3986]で定義されるように
token = 1*token-char ; copied from [RFC4566]
トークン= 1 *トークンチャー。 [RFC4566]からコピー
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E ; copied from [RFC4566]
トークンチャー=％X21 /％x23-27 /％X2A-2B /％x2D-2E /％x30-39 /％x41-5A /％x5E-7E。 [RFC4566]からコピー
cid-block = 1*cid-char
CID-ブロック= 1 *のCID-チャー
cid-char = token-char cid-char =/ "@" cid-char =/ "," cid-char =/ ";" cid-char =/ ":" cid-char =/ "\" cid-char =/ "/" cid-char =/ "[" cid-char =/ "]" cid-char =/ "?" cid-char =/ "=" ; ; - Add back in the tspecials [RFC2045], except ; for DQUOTE and the non-email safe ( ) < >. ; - Note that the definitions above ensure that ; cid-block is always enclosed with DQUOTEs.
CID-CHAR =トークンのchar CID-CHAR = / "@" CID-CHAR = / "" CID-CHAR = / ";" CID-CHAR = / "：" CID-CHAR = / "\" CID-CHAR = / "/" CID-CHAR = / "[" CID-CHAR = / "]" CID-CHAR = / "？" CID-チャー= / "="。 ; - 除いて、バックtspecials [RFC2045]で追加します。 DQUOTE用と非電子メールの安全（）<>。 ; - 定義が上記のことを確認していることに注意してください。 CID-ブロックは常にDQUOTEsで囲まれています。
A = %x41 ; Uppercase-only letters used above. B = %x42 C = %x43 D = %x44 E = %x45 F = %x46 G = %x47 H = %x48 J = %x4A K = %x4B M = %x4D N = %x4E P = %x50 Q = %x51 T = %x54 V = %x56 W = %x57 X = %x58 Y = %x59 Z = %x5A
=％のX41。大文字のみの文字が上記使用します。 B =％X42 C =％X43 D =％のX44 E =％X45 F =％X46 G =％X47 H =％X48 J =％のX4AのK =％x4B M =％x4D N =％x4E P =％X50 Q = ％X51 T =％のX54 V =％のX56 W =％X57 X =％のX58 Y =％X59 Z =％X5A
NZ-DIGIT = %x31-39 ; non-zero decimal digit
NZ-DIGIT =％x31-39。ゼロ以外の十進数
U-HEXDIG = DIGIT / A / B / C / D / E / F ; variant of HEXDIG [RFC5234] : ; hexadecimal digit using uppercase A-F only
U-HEXDIG = DIGIT / A / B / C / D / E / F。 HEXDIG [RFC5234]の変異体。進数字のみ大文字のA-Fを使用して
; The rules below are from the Core Rules from [RFC5234].
;以下の規則は[RFC5234]からコアルールからのものです。
BIT = "0" / "1"
BIT = "0" / "1"
DQUOTE = %x22 ; " (Double Quote)
DQUOTE =％X22。 "（二重引用符）
DIGIT = %x30-39 ; 0-9
DIGIT =％x30-39。 0-9
; external references ; URI-reference: from [RFC3986]
;外部参照; URI参照：[RFC3986]から
; subtype-name: from [RFC4288]
;サブタイプ名：[RFC4288]から
; ; End of ABNF
; ; ABNFの終わり
The mpeg4-generic RTP payload [RFC3640] defines a mode parameter that signals the type of MPEG stream in use. We add a new mode value, rtp-midi, using the ABNF rule below:
mpeg4-ジェネリックRTPペイロード[RFC3640]は使用中のMPEGストリームのタイプを通知モードパラメータを定義します。私たちは、以下のABNF規則を使用して、新しいモード値、RTP-MIDIを追加します。
;
; mpeg4-generic mode parameter extension
;
mode =/ "rtp-midi" ; as described in Section 6.2 of this memo
モード= / "RTP-MIDI"。このメモのセクション6.2で説明したように
Appendix E. A MIDI Overview for Networking Specialists
ネットワークスペシャリストのための付録E. A MIDIの概要
This appendix presents an overview of the MIDI standard for the benefit of networking specialists new to musical applications. Implementors should consult [MIDI] for a normative description of MIDI.
この付録では、音楽のアプリケーションへの新しいネットワークの専門家の利益のためにMIDI規格の概要を説明します。実装者は、MIDIの規範的な説明については、[MIDI]を相談してください。
Musicians make music by performing a controlled sequence of physical movements. For example, a pianist plays by coordinating a series of key presses, key releases, and pedal actions. MIDI represents a musical performance by encoding these physical gestures as a sequence of MIDI commands. This high-level musical representation is compact but fragile: one lost command may be catastrophic to the performance.
ミュージシャンは、物理的な運動の制御シーケンスを実行することによって、音楽を作ります。例えば、ピアニストは、キーを押すと、キーのリリース、およびペダル一連のアクションを調整することによって果たしています。 MIDIは、MIDIコマンドのシーケンスとしてこれらの物理的なジェスチャーを符号化することによって演奏を表します。この高レベルの音楽表現は、コンパクトが、壊れやすい：1つの失われたコマンドは、パフォーマンスへの壊滅的かもしれません。
MIDI commands have much in common with the machine instructions of a microprocessor. MIDI commands are defined as binary elements. Bitfields within a MIDI command have a regular structure and a specialized purpose. For example, the upper nibble of the first command octet (the opcode field) codes the command type. MIDI commands may consist of an arbitrary number of complete octets, but most MIDI commands are 1, 2, or 3 octets in length.
MIDIコマンドは、マイクロプロセッサの機械語命令と多くの共通点を持っています。 MIDIコマンドはバイナリの要素として定義されています。 MIDIコマンド内のビットフィールドは、規則的な構造や、特殊な目的を持っています。例えば、最初のコマンドオクテット（オペコードフィールド）コード、コマンドタイプの上位ニブル。 MIDIコマンドは、完全なオクテットの任意の数からなっていてもよいが、ほとんどのMIDIコマンドの長さは1、2、または3オクテットです。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Channel Voice Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NoteOff (end a note) | 1000cccc 0nnnnnnn 0vvvvvvv |
|-------------------------------------------------------------|
| NoteOn (start a note) | 1001cccc 0nnnnnnn 0vvvvvvv |
|-------------------------------------------------------------|
| PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa |
|-------------------------------------------------------------|
| CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| PChange (Program Change) | 1100cccc 0ppppppp |
|-------------------------------------------------------------|
| CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa |
|-------------------------------------------------------------|
| PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy |
-------------------------------------------------------------
Figure E.1 -- MIDI Channel Messages
図E.1 - MIDIチャンネルメッセージ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Common Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Exclusive | 11110000, followed by a |
| | list of 0xxxxxx octets, |
| | followed by 11110111 |
|-------------------------------------------------------------|
| MIDI Time Code Quarter Frame | 11110001 0xxxxxxx |
|-------------------------------------------------------------|
| Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| Song Select | 11110011 0xxxxxxx |
|-------------------------------------------------------------|
| Undefined | 11110100 |
|-------------------------------------------------------------|
| Undefined | 11110101 |
|-------------------------------------------------------------|
| Tune Request | 11110110 |
|-------------------------------------------------------------|
| System Exclusive End Marker | 11110111 |
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Real-Time Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Clock | 11111000 |
|-------------------------------------------------------------|
| Undefined | 11111001 |
|-------------------------------------------------------------|
| Start | 11111010 |
|-------------------------------------------------------------|
| Continue | 11111011 |
|-------------------------------------------------------------|
| Stop | 11111100 |
|-------------------------------------------------------------|
| Undefined | 11111101 |
|-------------------------------------------------------------|
| Active Sense | 11111110 |
|-------------------------------------------------------------|
| System Reset | 11111111 |
-------------------------------------------------------------
Figure E.2 -- MIDI System Messages
図E.2 - MIDIシステムメッセージ
Figures E.1 and E.2 show the MIDI command family. There are three major classes of commands: voice commands (opcode field values in the range 0x8 through 0xE), System Common commands (opcode field 0xF, commands 0xF0 through 0xF7), and System Real-Time commands (opcode field 0xF, commands 0xF8 through 0xFF). Voice commands code the musical gestures for each timbre in a composition. System commands perform functions that usually affect all voice channels, such as System Reset (0xFF).
図E.1及びE.2は、MIDIコマンドファミリを示しています。そこのコマンドの三つの主要なクラスである：音声コマンド（から0xEまでの範囲の0x8というにおけるオペコードフィールド値）、システム共通コマンド（opcodeフィールド0xFの、0xF7経由の0xF0コマンドは）、およびシステムリアルタイムによる0xF8コマンド、（opcodeフィールド0xFのコマンド0xFF）。音声は、組成物中の各音色のコードを音楽ジェスチャーを指示します。システムコマンドは、通常、システムリセット（0xFFで）など、すべての音声チャネルに影響を与える機能を実行します。
E.1. Commands Types
E.1。コマンドの種類
A voice command executes on one of 16 MIDI channels, as coded by its 4-bit channel field (field cccc in Figure E.1). In most applications, notes for different timbres are assigned to different channels. To support applications that require more than 16 channels, MIDI systems use several MIDI command streams in parallel to yield 32, 48, or 64 MIDI channels.
その4ビットのチャネル・フィールド（図E.1のフィールドCCCC）によって符号化され、音声コマンドは、16 MIDIチャンネルのいずれかを実行します。ほとんどのアプリケーションでは、異なる音色のためのノートは、異なるチャネルに割り当てられています。 16個の以上のチャネルを必要とするアプリケーションをサポートするために、MIDIシステムは、32、48、又は64 MIDIチャンネルを生成するために並列にいくつかのMIDIコマンドストリームを使用します。
As an example of a voice command, consider a NoteOn command (opcode 0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This command signals the start of a musical note on MIDI channel cccc. The note has a pitch coded by the note number nnnnnnn, and an onset amplitude coded by note velocity aaaaaaa.
音声コマンドの一例として、1001cccc 0nnnnnnn 0aaaaaaaバイナリ符号化と、NoteOn命令（オペコード0x9）を考えます。このコマンドは、MIDIチャンネルCCCC上の音符の開始を知らせます。ノートは、ノートナンバNNNNNNNにより符号化ピッチ、ノート速度AAAAAAAによって符号化されたオンセット振幅を有します。
Other voice commands signal the end of notes (NoteOff, opcode 0x8), map a specific timbre to a MIDI channel (PChange, opcode 0xC), or set the value of parameters that modulate the timbral quality (all other voice commands). The exact meaning of most voice channel commands depends on the rendering algorithms the MIDI receiver uses to generate sound. In most applications, a MIDI sender has a model (in some sense) of the rendering method used by the receiver.
他の音声コマンドは、MIDIチャンネル（PChange、オペコードから0xC）に特異的な音色をマッピングし、ノート（NoteOff、オペコード0x8という）の終了を知らせる、または音色品質（他のすべての音声コマンド）を調節するパラメータの値を設定します。ほとんどの音声チャネルコマンドの正確な意味は、MIDIの受信機が音を生成するために使用する描画アルゴリズムに依存します。ほとんどのアプリケーションでは、MIDIの送信者は受信機で使用されるレンダリング法の（ある意味で）のモデルを持っています。
System commands perform a variety of global tasks in the stream, including "sequencer" playback control of pre-recorded MIDI commands (the Song Position Pointer, Song Select, Clock, Start, Continue, and Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame command), and the communication of device-specific data (the System Exclusive messages).
システムコマンドは、事前に記録されたMIDIは（ソングポジションポインター、ソング・セレクト、クロック、スタート、続行、および停止メッセージ）、SMPTEタイムコード（MIDIコマンドの「シーケンサー」の再生制御を含む、ストリーム内のグローバルなさまざまなタスクを実行しますタイムコード四半期フレームコマンド）、およびデバイス固有のデータの通信（システムエクスクルーシブメッセージ）。
E.2. Running Status
E.2。実行ステータス
All MIDI command bitfields share a special structure: the leading bit of the first octet is set to 1, and the leading bit of all subsequent octets is set to 0. This structure supports a data compression system, called running status [MIDI], that improves the coding efficiency of MIDI.
すべてのMIDIコマンドのビットフィールドは、特殊な構造を共有する：こと、ステータスを[MIDI]を実行していると呼ばれる、この構造は、データ圧縮システムをサポートする最初のオクテットの先頭ビットが1に設定され、それ以降のすべてのオクテットの先頭ビットが0に設定されます。 MIDIの符号化効率を向上させます。
In running status coding, the first octet of a MIDI voice command may be dropped if it is identical to the first octet of the previous MIDI voice command. This rule, in combination with a convention to consider NoteOn commands with a null third octet as NoteOff commands, supports the coding of note sequences using two octets per command.
それは、以前のMIDI音声コマンドの最初のオクテットと同じ場合、ステータスコード化を実行するには、MIDI音声コマンドの最初のオクテットをドロップすることがあります。この規則は、NoteOnはコマンドNoteOffとしてnull 3番目のオクテットでコマンドを考慮すべき大会との組み合わせで、コマンドごとに2つのオクテットを使用して、ノートシーケンスのコーディングをサポートしています。
Running status coding is only used for voice commands. The presence of a System Common message in the stream cancels running status mode for the next voice command. However, System Real-Time messages do not cancel running status mode.
ステータスコード化を実行すると、音声コマンドのためにのみ使用されます。ストリームにおけるシステム共通メッセージの存在は、次の音声コマンドに対するステータス・モードを実行しているキャンセル。しかし、システムリアルタイムメッセージは、ステータスモードを実行しているキャンセルしないでください。
E.3. Command Timing
E.3。コマンドのタイミング
The bitfield formats in Figures E.1 and E.2 do not encode the execution time for a command. Timing information is not a part of the MIDI command syntax itself; different applications of the MIDI command language use different methods to encode timing.
図E.1及びE.2におけるビットフィールドの形式は、コマンドの実行時間をコードしません。タイミング情報MIDIコマンドの構文自体の一部ではありません。 MIDIコマンド言語の異なるアプリケーションでは、タイミングをエンコードするためにさまざまな方法を使用しています。
For example, the MIDI command set acts as the transport layer for MIDI 1.0 DIN cables [MIDI]. MIDI cables are short asynchronous serial lines that facilitate the remote operation of musical instruments and audio equipment. Timestamps are not sent over a MIDI 1.0 DIN cable. Instead, the standard uses an implicit "time of arrival" code. Receivers execute MIDI commands at the moment of arrival.
例えば、MIDI 1.0 DINケーブル[MIDI]のトランスポート層としてMIDIコマンドセット作用します。 MIDIケーブルは楽器や音響機器の遠隔操作を容易にする短い非同期シリアルラインです。タイムスタンプはMIDI 1.0 DINケーブルを介して送信されません。代わりに、標準のコード暗黙の「到着時間」を使用しています。レシーバはMIDI到着の瞬間にコマンドを実行します。
In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for representing complete musical performances, add an explicit timestamp to each MIDI command, using a delta encoding scheme that is optimized for statistics of musical performance. SMF timestamps usually code timing using the metric notation of a musical score. SMF meta-events are used to add a tempo map to the file so that score beats may be accurately converted into units of seconds during rendering.
対照的に、スタンダードMIDIファイル（SMFを、[MIDI]）、完全な演奏を表現するためのファイルフォーマットは、演奏の統計のために最適化された差分符号化方式を使用して、各MIDIコマンドに明示的なタイムスタンプを追加します。 SMFは、通常、楽譜のメトリック表記法を使用してコードのタイミングをタイムスタンプ。 SMFメタイベントは、スコアビートが正確にレンダリング中に秒の単位に変換することができるように、ファイルにテンポマップを追加するために使用されています。
E.4. AudioSpecificConfig Templates for MMA Renderers
E.4。 MMAレンダラのためAudioSpecificConfigテンプレート
In Section 6.2 and Appendix C.6.5, we describe how session descriptions include an AudioSpecificConfig data block to specify a MIDI rendering algorithm for mpeg4-generic RTP MIDI streams.
セクション6.2および付録C.6.5では、私たちは、セッション記述がmpeg4-ジェネリックRTP MIDIストリームのためのMIDIのレンダリングアルゴリズムを指定するには、AudioSpecificConfigデータブロックを含める方法について説明します。
The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. StructuredAudioSpecificConfig, a key data structure coded in AudioSpecificConfig, is defined in [MPEGSA].
AudioSpecificConfigのビットフィールドのフォーマットは、[MPEGAUDIO]で定義されています。 StructuredAudioSpecificConfig、AudioSpecificConfigで符号化されたキーデータ構造は、[MPEGSA]で定義されています。
For implementors wishing to specify Structured Audio renderers, a full understanding of [MPEGSA] and [MPEGAUDIO] is essential. However, many implementors will limit their rendering options to the two MIDI Manufacturers Association (MMA) renderers that may be specified in AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 (DLS 2, [DLS2]).
構造化されたオーディオレンダラを指定したい実装については、[MPEGAUDIO]と[MPEGSA]の完全な理解が不可欠です。一般的なMIDI（GM、[MIDI]）およびダウンロードサウンド2（DLS 2、[DLS2]）：しかし、多くの実装は、2つのMIDI製造者協会AudioSpecificConfigで指定することができる（MMA）レンダラーへのレンダリングオプションを制限します。
To aid these implementors, we reproduce the AudioSpecificConfig bitfield formats for a GM renderer and a DLS 2 renderer below. We have checked these bitfields carefully and believe they are correct. However, we stress that the material below is informative and that [MPEGAUDIO] and [MPEGSA] are the normative definitions for AudioSpecificConfig.
これらの実装を支援するために、我々はGMレンダラと、以下のDLS 2レンダラのためAudioSpecificConfigビットフィールド形式を再現します。我々は慎重にこれらのビットフィールドをチェックし、それらが正しいと信じています。しかし、我々は以下の物質が有益で[MPEGAUDIO]ということで、[MPEGSA] AudioSpecificConfigのための規範的な定義であることを強調します。
As described in Section 6.2, a minimal mpeg4-generic session description encodes the AudioSpecificConfig binary bitfield as a hexadecimal string (whose format is defined in [RFC3640]) that is assigned to the "config" parameter. As described in Appendix C.6.3, a session description that uses the render parameter encodes the AudioSpecificConfig binary bitfield as a Base64-encoded string assigned to the inline parameter or in the body of an HTTP URL assigned to the url parameter.
セクション6.2で説明したように、最小のmpeg4-ジェネリックセッション記述は、「設定」のパラメータに割り当てられている（フォーマット[RFC3640]で定義されている）、16進数の文字列としてAudioSpecificConfigバイナリビットフィールドを符号化します。付録C.6.3に記載されているように、レンダリングパラメータを使用してセッション記述は、インラインパラメータまたはURLパラメータに割り当てられたHTTP URLの本体に割り当てられたBase64でエンコードされた文字列としてAudioSpecificConfigバイナリビットフィールドを符号化します。
Below, we show a simplified binary AudioSpecificConfig bitfield format, suitable for sending and receiving GM and DLS 2 data:
以下に、我々はGMとDLS 2のデータの送受信に適した単純化されたバイナリAudioSpecificConfigビットフィールドのフォーマットを、示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AOTYPE |FREQIDX|CHANNEL|SACNK| FILE_BLK 1 (required) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|SACNK| FILE_BLK 2 (optional) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1|SACNK| FILE_BLK N (optional) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| (first "0" bit terminates FILE_BLK list)
+-+-+
Figure E.3 -- Simplified AudioSpecificConfig
図E.3 - 簡体AudioSpecificConfig
The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned integer. The legal values for use with mpeg4-generic RTP MIDI streams are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio). Thus, receivers that do not support all three mpeg4-generic renderers may parse the first 5 bits of an AudioSpecificConfig coded in a session description and reject sessions that specify unsupported renderers.
5ビットのAOTYPEフィールドは、符号なし整数としてオーディオオブジェクトの型を指定します。 mpeg4-ジェネリックRTP MIDIストリームで使用するための有効な値は "15"（一般的なMIDI）、 "14"（DLS 2）、及び "13"（ストラクチャード・オーディオ）です。したがって、すべての3つのMPEG4-ジェネリックレンダラーをサポートしていない受信機はセッション記述で符号化AudioSpecificConfigの最初の5ビットを解析し、サポートされていないレンダラを指定セッションを拒否することができます。
The 4-bit FREQIDX field specifies the sampling rate of the renderer. We show the mapping of FREQIDX values to sampling rates in Figure E.4. Senders MUST specify a sampling frequency that matches the RTP clock rate, if possible; if not, senders MUST specify the escape value. Receivers MUST consult the RTP clock parameter for the true sampling rate if the escape value is specified.
4ビットのFREQIDXフィールドは、レンダラのサンプリングレートを指定します。私たちは、図E.4でのサンプリングレートにFREQIDX値のマッピングを示しています。可能であれば送信者は、RTPクロックレートに一致するサンプリング周波数を指定する必要があります。ない場合は、送信者は、エスケープ値を指定する必要があります。エスケープ値が指定されている場合受信機は、真のサンプリングレートのためのRTPクロックパラメータを参照する必要があります。
FREQIDX Sampling Frequency
FREQIDXサンプリング周波数
0x0 96000 0x1 88200 0x2 64000 0x3 48000 0x4 44100 0x5 32000 0x6 24000 0x7 22050 0x8 16000 0x9 12000 0xa 11025 0xb 8000 0xc reserved 0xd reserved 0xe reserved 0xf escape value
0x0の96000 0x1の88200 0x2の64000 0x3の48000 0x4の44100 0x5 32000 0x6に24000を0x7 22050 0x8の16000 0x9 12000 11025は0xaから0xC 8000 0xbの予約の0xdは、エスケープ値0xFの予約は0xeを予約しました
Figure E.4 -- FreqIdx Encoding
図E.4 - FreqIdxエンコーディング
The 4-bit CHANNEL field specifies the number of audio channels for the renderer. The values 0x1 to 0x5 specify 1 to 5 audio channels; the value 0x6 specifies 5+1 surround sound; and the value 0x7 specifies 7+1 surround sound. If the rtpmap line in the session description specifies one of these formats, CHANNEL MUST be set to the corresponding value. Otherwise, CHANNEL MUST be set to 0x0.
4ビットのCHANNELフィールドは、レンダラのためのオーディオチャンネル数を指定します。 0x5の値は0x1は1〜5のオーディオチャンネルを指定します。値0x6には5 + 1サラウンドサウンドを指定します。そして、値を0x7は7 + 1サラウンドサウンドを指定します。セッション記述のrtpmap線は、これらの形式のいずれかを指定している場合、チャネルは対応する値に設定しなければなりません。それ以外の場合は、CHANNELは0x0に設定しなければなりません。
The CHANNEL field is followed by a list of one or more binary file data blocks. The 3-bit SACNK field (the chunk_type field in class StructuredAudioSpecificConfig, defined in [MPEGSA]) specifies the type of each data block.
CHANNELフィールドは、一つ以上のバイナリファイルのデータブロックのリストが続いています。 （[MPEGSA]で定義されたクラスStructuredAudioSpecificConfigでchunk_typeフィールド）3ビットSACNKフィールドは、各データ・ブロックのタイプを指定します。
For General MIDI, only Standard MIDI Files may appear in the list (SACNK field value 2). For DLS 2, only Standard MIDI Files and DLS 2 RIFF files (SACNK field value 4) may appear. For both of these file types, the FILE_BLK field has the format shown in Figure E.5: a 32-bit unsigned integer value (FILE_LEN) coding the number of bytes in the SMF or RIFF file, followed by FILE_LEN bytes coding the file data.
一般的なMIDIの場合は、スタンダードMIDIファイルのみをリスト（SACNKフィールド値2）に表示される場合があります。 DLS 2の場合は、スタンダードMIDIファイルのみとDLS 2つのRIFFファイル（SACNKフィールド値4）が表示されることがあります。ファイルデータを符号化FILE_LENバイト続いSMFまたはRIFFファイル内のバイトの数を符号化する32ビットの符号なし整数値（FILE_LEN）、これらのファイル形式の両方について、FILE_BLKフィールドは、図E.5に示すフォーマットを有しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_LEN (32-bit, a byte count SMF file or RIFF file) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_DATA (file contents, a list of FILE_LEN bytes) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure E.5 -- The FILE_BLK Field Format
図E.5 - FILE_BLKフィールドのフォーマット
Note that several files may follow the CHANNEL field. The "1" constant fields in Figure E.3 code the presence of another file; the "0" constant field codes the end of the list. The final "0" bit in Figure E.3 codes the absence of special coding tools (see [MPEGAUDIO] for details). Senders not using these tools MUST append this "0" bit; receivers that do not understand these coding tools MUST ignore all data following a "1" in this position.
いくつかのファイルは、CHANNELフィールドに従うことに注意してください。図E.3コード別のファイルの存在下で、「1」定数フィールド。 「0」定数フィールドコードリストの終わり。図E.3コード特殊な符号化ツールが存在しない（詳細については[MPEGAUDIO]参照）の最後の「0」ビット。これらのツールを使用していない送信者は、この「0」ビットを追加しなければなりません。これらの符号化ツールを理解していない受信機は、この位置に「1」以下の全てのデータを無視しなければなりません。
The StructuredAudioSpecificConfig bitfield structure requires the presence of one FILE_BLK. For mpeg4-generic RTP MIDI use of DLS 2, FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic RTP MIDI use of General MIDI, FILE_BLKs MUST code SMF files. By default, this SMF will be ignored (Appendix C.6.4.1). In this default case, a GM StructuredAudioSpecificConfig bitfield SHOULD code a FILE_BLK whose FILE_LEN is 0 and whose FILE_DATA is empty.
StructuredAudioSpecificConfigビットフィールドの構造は、1つFILE_BLKの存在を必要とします。 DLS 2のmpeg4-ジェネリックRTP MIDIの使用のために、FILE_BLKsは、RIFFファイルやSMFファイルをコード化しなければなりません。一般的なMIDIのmpeg4-ジェネリックRTP MIDIの使用のために、FILE_BLKsは、SMFファイルをコード化しなければなりません。デフォルトでは、このSMFは（付録C.6.4.1）無視されます。このデフォルトの場合、GM StructuredAudioSpecificConfigビットフィールドは、そのFILE_LEN 0であり、そのFILE_DATA空であるFILE_BLKを符号化すべきです。
To complete this appendix, we derive the StructuredAudioSpecificConfig that we use in the General MIDI session examples in this memo. Referring to Figure E.3, we note that for GM, AOTYPE = 15. Our examples use a 44,100 Hz sample rate (FREQIDX = 4) and are in mono (CHANNEL = 1). For GM, a single SMF is encoded (SACNK = 2), using the SMF shown in Figure E.6 (a 26 byte file).
この付録を完了するために、我々はこのメモで一般的なMIDIセッションの例で使用StructuredAudioSpecificConfigを導き出します。図E.3を参照すると、我々はGMのために、AOTYPE = 15我々の例は、44,100 Hzのサンプリングレート（FREQIDX = 4）を使用し、モノ（CHANNEL = 1）であることに注意します。 GMのために、単一のSMFは、図E.6に示すSMF（26バイトのファイル）を使用して、（SACNK = 2）に符号化されます。
--------------------------------------------
| MIDI File = <Header Chunk> <Track Chunk> |
--------------------------------------------
<Header Chunk> = <chunk type> <length> <format> <ntrks> <divsn> 4D 54 68 64 00 00 00 06 00 00 00 01 00 60
<ヘッダチャンク> = <チャンクタイプ> <長さ> <フォーマット> <ntrks> <divsn> 4D 54 68 64 00 00 00 06 00 00 00 01 00 60
<Track Chunk> = <chunk type> <length> <delta-time> <end-event> 4D 54 72 6B 00 00 00 04 00 FF 2F 00
<トラックチャンク> = <チャンクタイプ> <長さ> <デルタ時間> <終了イベント> 4D 54 72 6B 00 00 00 04 00 FF 2F 00
Figure E.6 -- SMF File Encoded in the Example
図E.6 - 例でエンコードされたSMFファイル
Placing these constants in binary format into the data structure shown in Figure E.3 yields the constant shown in Figure E.7.
図E.3に示されるデータ構造にバイナリ形式でこれらの定数を配置すると、図E.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1|0 1 0 0|0 0 0 1|0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0|1 0 0 0|0 1 1 0|0 1 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 1|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|0 1 1 1|0 0 1 0|0 1 1 0|1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|1 1 1 1|1 1 1 1|0 0 1 0|1 1 1 1|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|
+-+-+
Figure E.7 -- AudioSpecificConfig Used in GM Examples
図E.7 - GMの例で使用されているAudioSpecificConfig
Expressing this bitfield as an ASCII hexadecimal string yields:
ASCII 16進数の文字列の利回りとして、このビットフィールドを表現します：
7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000
7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000
This string is assigned to the "config" parameter in the minimal mpeg4-generic General MIDI examples in this memo (such as the example in Section 6.2). Expressing this string in Base64 [RFC2045] yields:
この文字列は、（例えば、セクション6.2の例のように）このメモでは、最小限のmpeg4-ジェネリック一般的なMIDIの例では、「設定」のパラメータに割り当てられています。 Base64で[RFC2045]収率でこの文字列を表現します：
egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA
egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD / LwAA
This string is assigned to the inline parameter in the General MIDI example shown in Appendix C.6.5.
この文字列は、付録C.6.5に示す一般的なMIDIの例では、インラインパラメータに割り当てられています。
References
リファレンス
Normative References
引用規格
[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 Detailed Specification", 1996.
[MIDI] MIDI製造者協会。 "コンプリートMIDI 1.0の詳細な仕様書"、1996年。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and P. Gentric, "RTP Payload Format for Transport of MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3640]ファンデミーア、J.、マッキー、D.、スワミナサン、V.、歌手、D.、およびP. Gentric、 "MPEG-4エレメンタリ・ストリームのトランスポートのためのRTPペイロードフォーマット"、RFC 3640、2003年11月。
[MPEGSA] International Standards Organization. "ISO/IEC 14496 MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio), 2001.
[MPEGSA]国際標準化機構。 "ISO / IEC 14496、MPEG-4"、第3部（オーディオ）、サブパート5（構造化オーディオ）、2001。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG-4", Part 3 (Audio), 2001.
[MPEGAUDIO]国際標準化機構。 "ISO 14496 MPEG-4"、第3部（オーディオ）、2001。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[DLS2] MIDI Manufacturers Association. "The MIDI Downloadable Sounds Specification", v98.2, 1998.
[DLS2] MIDI製造者協会。 "MIDIダウンロードサウンド仕様"、v98.2、1998。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]キャマリロ、G.およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）グループ化フレームワーク"、RFC 5888、2010年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RP015] MIDI Manufacturers Association. "Recommended Practice 015 (RP-015): Response to Reset All Controllers", 11/98.
[RP015] MIDI製造者協会。 "実践015（RP-015）推奨：すべてのコントローラーリセットへの対応"、98分の11を。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。
Informative References
参考文献
[NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network Musical Performance", 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) June 25-26, 2001, Port Jefferson, New York.
[NMP]ラザロ、J.およびJ. Wawrzynek。 、ネットワーク上の第11回国際ワークショップとデジタルオーディオとビデオのためのオペレーティングシステムのサポート（NOSSDAV 2001）6月25-26日、2001、ポートジェファーソン、ニューヨークの「ネットワーク演奏用ケース」。
[GRAME] Fober, D., Orlarey, Y., and S. Letz. "Real Time Musical Events Streaming over Internet", Proceedings of the International Conference on WEB Delivering of Music 2001, pages 147-154.
【GRAME] Fober、D.、Orlarey、Y.、およびS. Letz。ミュージック2001年届けるWEB上の「インターネット上でリアルタイムストリーミング音楽会」、国際会議の議事録、ページ147-154。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[ALF] Clark, D.D. and D.L. Tennenhouse. "Architectural Considerations for a New Generation of Protocols", SIGCOMM Symposium on Communications Architectures and Protocols, (Philadelphia, Pennsylvania), pp. 200-208, ACM, Sept. 1990.
[ALF]クラーク、D.D.そして、D.L. Tennenhouse。通信アーキテクチャとプロトコル、（フィラデルフィア、ペンシルベニア州）で、SIGCOMMシンポジウム「プロトコルの新世代のための建築に関する注意事項」、頁200から208、ACM、1990年9月。
[RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for MIDI", RFC 4695, November 2006.
[RFC4695]ラザロ、J.とJ. Wawrzynek、 "MIDIのためのRTPペイロードフォーマット"、RFC 4695、2006年11月。
[RFC4696] Lazzaro, J. and J. Wawrzynek, "An Implementation Guide for RTP MIDI", RFC 4696, November 2006.
[RFC4696]ラザロ、J.とJ. Wawrzynek、 "RTP MIDIインプリメンテーション・ガイド"、RFC 4696、2006年11月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]ラザロ、J.、RFC 4571、2006年7月 "リアルタイム転送プロトコル（RTP）およびRTP制御プロトコルコネクション型トランスポート・オーバー（RTCP）パケットをフレーミング"。
[SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony MIDI, Specification and Device Profiles", Document Version 1.0a, 2002.
[SPMIDI] MIDI製造者協会。 「スケーラブルポリフォニーMIDI、仕様およびデバイスプロファイル」、ドキュメントのバージョン1.0a、2002。
[LCP] Apple Computer. "Logic 7 Dedicated Control Surface Support", Appendix B. Product manual available from www.apple.com.
[LCP]アップルコンピュータ。 「ロジック7専用コントロールサーフェスのサポート」、www.apple.comから入手付録B.製品のマニュアル。
Authors' Addresses
著者のアドレス
John Lazzaro (corresponding author) UC Berkeley CS Division 315 Soda Hall Berkeley, CA 94720-1776 EMail: lazzaro@cs.berkeley.edu
ジョン・ラザロ（相当著者）UCバークレーCS課315ソーダホールバークレー、CA 94720から1776 Eメール：lazzaro@cs.berkeley.edu
John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley, CA 94720-1776 EMail: johnw@cs.berkeley.edu
ジョン・ウォウリネックUCバークレーCS課631ソーダホールバークレー、CA 94720から1776 Eメール：johnw@cs.berkeley.edu