[要約] RFC 4695は、MIDIデータをRTPペイロードとして転送するためのフォーマットを定義しています。このRFCの目的は、MIDIデータのリアルタイムなストリーミングを可能にすることです。
Network Working Group J. Lazzaro
Request for Comments: 4695 J. Wawrzynek
Category: Standards Track UC Berkeley
November 2006
RTP Payload Format for MIDI
MIDIのRTPペイロード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
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.
このメモは、MIDI（楽器デジタルインターフェイス）コマンド言語のリアルタイムトランスポートプロトコル（RTP）ペイロード形式について説明しています。フォーマットは、MIDI 1.0 DINケーブルに合法的に表示される可能性のあるすべてのコマンドをエンコードします。この形式は、インタラクティブなアプリケーション（ネットワークミュージカルパフォーマンスなど）やコンテンツ配信アプリケーション（ファイルストリーミングなど）に適しています。この形式は、ユニキャストおよびマルチキャストUDPおよびTCPで使用でき、パケット損失からの優雅な回復のためのツールを定義します。MIDIレンダリング方法を含むストリームの動作は、セッションのセットアップ中にカスタマイズされる場合があります。この形式は、MPEG4-Genericフォーマットのモードとしても機能し、一般的なMIDIのMPEG 4オーディオオブジェクトタイプ、ダウンロード可能なサウンドレベル2、および構造化オーディオをサポートします。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Bitfield Conventions .......................................6
2. Packet Format ...................................................6
2.1. RTP Header .................................................7
2.2. MIDI Payload ..............................................11
3. MIDI Command Section ...........................................12
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 .........................37
11.1.1. Repository Request for "audio/rtp-midi" ...........40
11.2. mpeg4-generic Media Type Registration ....................41
11.2.1. Repository Request for Mode rtp-midi for
mpeg4-generic .....................................44
11.3. asc Media Type Registration ..............................46
A. The Recovery Journal Channel Chapters ..........................48
A.1. Recovery Journal Definitions ..............................48
A.2. Chapter P: MIDI Program Change ............................52
A.3. Chapter C: MIDI Control Change ............................53
A.3.1. Log Inclusion Rules ................................54
A.3.2. Controller Log Format ..............................55
A.3.3. Log List Coding Rules ..............................57
A.3.4. The Parameter System ...............................60
A.4. Chapter M: MIDI Parameter System ..........................62
A.4.1. Log Inclusion Rules ................................64
A.4.2. Log Coding Rules ...................................65
A.4.2.1. The Value Tool .............................67
A.4.2.2. The Count Tool .............................70
A.5. Chapter W: MIDI Pitch Wheel ...............................71
A.6. Chapter N: MIDI NoteOff and NoteOn ........................71
A.6.1. Header Structure ...................................73
A.6.2. Note Structures ....................................74
A.7. Chapter E: MIDI Note Command Extras .......................75
A.7.1. Note Log Format ....................................76
A.7.2. Log Inclusion Rules ................................76
A.8. Chapter T: MIDI Channel Aftertouch ........................77
A.9. Chapter A: MIDI Poly Aftertouch ...........................78
B. The Recovery Journal System Chapters ...........................79
B.1. System Chapter D: Simple System Commands ..................79
B.1.1. Undefined System Commands ..........................80
B.2. System Chapter V: Active Sense Command ....................83
B.3. System Chapter Q: Sequencer State Commands ................83
B.3.1. Non-compliant Sequencers ...........................85
B.4. System Chapter F: MIDI Time Code Tape Position ............86
B.4.1. Partial Frames .....................................88
B.5. System Chapter X: System Exclusive ........................89
B.5.1. Chapter Format .....................................90
B.5.2. Log Inclusion Semantics ............................92
B.5.3. TCOUNT and COUNT Fields ............................95
C. Session Configuration Tools ....................................95
C.1. Configuration Tools: Stream Subsetting ....................97
C.2. Configuration Tools: The Journalling System ..............101
C.2.1. The j_sec Parameter ...............................102
C.2.2. The j_update Parameter ............................103
C.2.2.1. The anchor Sending Policy .................104
C.2.2.2. The closed-loop Sending Policy ............104
C.2.2.3. The open-loop Sending Policy ..............108
C.2.3. Recovery Journal Chapter Inclusion Parameters .....110
C.3. Configuration Tools: Timestamp Semantics .................115
C.3.1. The comex Algorithm ...............................115
C.3.2. The async Algorithm ...............................116
C.3.3. The buffer Algorithm ..............................117
C.4. Configuration Tools: Packet Timing Tools .................118
C.4.1. Packet Duration Tools .............................119
C.4.2. The guardtime Parameter ...........................120
C.5. Configuration Tools: Stream Description ..................121
C.6. Configuration Tools: MIDI Rendering ......................128
C.6.1. The multimode Parameter ...........................129
C.6.2. Renderer Specification ............................129
C.6.3. Renderer Initialization ...........................131
C.6.4. MIDI Channel Mapping ..............................133
C.6.4.1. The smf_info Parameter ....................134
C.6.4.2. The smf_inline, smf_url, and smf_cid
Parameters ................................136
C.6.4.3. The chanmask Parameter ....................136
C.6.5. The audio/asc Media Type ..........................137
C.7. Interoperability .........................................139
C.7.1. MIDI Content Streaming Applications ...............139
C.7.2. MIDI Network Musical Performance Applications .....142
D. Parameter Syntax Definitions ..................................150
E. A MIDI Overview for Networking Specialists ....................156
E.1. Commands Types ...........................................159
E.2. Running Status ...........................................159
E.3. Command Timing ...........................................160
E.4. AudioSpecificConfig Templates for MMA Renderers ..........160
References .......................................................165
Normative References .............................................165
Informative References ...........................................166
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, 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は、スピリットとテレフォニーに似たアプリケーションである楽器のインタラクティブなリモートコントロールに使用されます。Webページでは、一般的なMIDI標準[MIDI]を使用してレンダリングされた標準MIDIファイル（SMFS、[MIDI]）は、オーディオストリーミングの低帯域幅代替品を提供します。
This memo is 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 may occur.
このメモは、単純な前提によって動機付けられています。MIDIパフォーマンスをIETFセッションツールによって管理されるRTPストリームとして送信できる場合、MIDIおよびIETFアプリケーションドメインのハイブリダイゼーションが発生する可能性があります。
For example, interoperable MIDI networking may 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 may begin to use MIDI for low-bitrate audio coding, perhaps in conjunction with normative sound synthesis methods [MPEGSA].
たとえば、相互運用可能なMIDIネットワーキングは、さまざまな物理的な場所にあるミュージシャンのグループがネットワークを介して対話して、同じ部屋[NMP]にある場合にパフォーマンスを発揮するネットワークミュージックパフォーマンスアプリケーションを促進する場合があります。2番目の例として、ストリーミングコミュニティは、おそらく規範的なサウンド統合法[MPEGSA]と組み合わせて、低ビトレートオーディオコーディングにMIDIを使用し始める可能性があります。
To enable MIDI applications to use RTP, this memo defines an RTP payload format and its media type. Sections 2-5 and Appendices A-B define the RTP payload format. Section 6 and Appendices C-D define the media types identifying the payload format, the parameters needed for configuration, and how the parameters are utilized in SDP.
MIDIアプリケーションがRTPを使用できるようにするために、このメモは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).
付録Cには、上記のアプリケーションの例の相互運用性ガイドラインも含まれています：SIPを使用したネットワーク音楽パフォーマンス（付録C.7.2）とRTSPを使用したコンテンツストリーミング（付録C.7.1）。
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のもう1つの潜在的なアプリケーションエリアは、プロのオーディオ機器と電子楽器の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] provides informative guidance on algorithms. Supplemental information may be found in related conference publications [NMP] [GRAME].
このメモは、MIDIペイロード形式の構文とセマンティクスを規範的に定義します。ただし、このメモは、パケットを送信および受信するためのアルゴリズムを定義していません。補助文書[RFC4696]は、アルゴリズムに関する有益なガイダンスを提供します。補足情報は、関連する会議出版物[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-Genericストリーム」というフレーズは、MPEG4-Genericメディアタイプ（モードRTP-MIDI）を使用してMPEG 4環境[RFC3640]で動作するストリームを指します。セクション6では、この区別について詳しく説明します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"BCP 14、RFC 2119 [RFC2119]に記載されているとおりに解釈されます。
In this document, the packet bitfields that share a common name often have identical semantics. As most of these bitfields appear in Appendices A-B, we define the common bitfield names in Appendix A.1.
このドキュメントでは、共通名を共有するパケットビットフィールドには、多くの場合、同一のセマンティクスがあります。これらのビットフィールドのほとんどが付録A-Bに表示されるため、付録A.1に共通のビットフィールド名を定義します。
However, a few of these common names also appear in the main text of this document. For convenience, we list these definitions 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 長さフィールド。長さのすべてのフィールド（レンとは異なる）コードは、それを含む構造内のオクテットの数をコードします。構造に長さフィールドが含まれている場合、レシーバーは、構造の内部形式に関する知識を使用するのではなく、解析中に構造を通過する長さフィールド値を使用する必要があります。
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ペイロード形式は、MIDIコマンドストリーム（16 Voiceチャネルシステム）をRTPストリームにマッピングします。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など）にマッピングされます。リアルタイムストリーミングプロトコル（RTSP、[RFC2326]）のインターリーブモードは、[RFC4571]と同様に、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フィールドがある場合、Mビットを1に設定する必要があり、それ以外の場合は0に設定する必要があります。MPEG4-GENERICストリームの場合、すべてのパケットに対してMビットを1に設定する必要があります（[RFC3640]に準拠するため）。
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つ（Modulo 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秒異なる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ノートンが、コンテンツ著者が望んでいたものとは異なるタイミングでレンダリングされたときに発生する音色の変化によるものです。クロックレートの量子化。オーディオレンダリング（ステージ照明制御を制御するMIDIストリームなど）に運命づけられていないRTP 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 less than 32 KHz.
オーディオにレンダリングされる予定のRTP MIDIストリームの場合、クロックレートは、プロのオーディオアプリケーションまたは消費者オーディオ配布で一般的に使用されるレートから選択する必要があります。この執筆時点では、これらの料金には32 kHz、44.1 kHz、48 kHz、64 kHz、88.2 kHz、96 kHz、176.4 kHz、および192 kHzが含まれます。RTP MIDIセッションが、32 kHz以上のクロックレートを持つ別の（非MIDI）RTPオーディオストリームを含む同期メディアセッションの一部である場合、RTP MIDIストリームは、その他のオーディオストリーム。ただし、RTP MIDIストリームをオーディオにレンダリングする運命にある場合、RTP MIDIストリームは、この2番目のストリームのクロックレートが32 kHz未満であっても、32 kHz未満のクロックレートを使用してはなりません。
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).
したがって、2つのシーケンシャルRTPパケットのタイムスタンプは同一であるか、2番目のパケットが最初のパケットよりも任意に大きいタイムスタンプを持っている場合があります（Modulo 2^32）。セクション3は、GuardTimeパラメーターと同様に、2つの順次RTPパケットのRTPタイムスタンプに追加の制限を掲載しています（付録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タイムスタンプからMIDIコマンドセクションの最後のコマンドタイムスタンプを差し引くことによって計算されます（Modulo 2^32）。パケットのMIDIコマンドセクションのMIDIリストが空の場合、パケットでコードされたメディア時間は0 msです。付録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 Voice Channels Systems）のデータをエンコードします。
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ストリームを最大1つ送信できます。[RFC4566]のペイロードタイプ数の動的バインディングにより、パーティーがRTP MIDIペイロード形式に多くのペイロードタイプ番号をマップできることを思い出してください。したがって、パーティーは、単一のRTPセッションで多くのRTP MIDIストリームを送信する場合があります。RTPセッションで2つのパーティ間で通信し、ペイロードタイプを共有するストリームのペア（ユニキャストまたはマルチキャスト）は、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値も個別かつランダムに選択されます。受信者は、RTCP送信者レポートにエンコードされたCNAMEフィールドを使用して、[RFC3550]で説明されているように、SSRC衝突を検出して、SSRC衝突を検出します。
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 Programmer 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セッションで送信する必要があります。たとえば、マルチメディアセッションでオーディオに1つのMIDIストリームと2番目の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ストリームに単一のMIDI名スペース（16音声チャネルシステム）を分割するようにします。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ストリームがMIDI名スペースを共有する場合、すべてのストリームは同じSSRC値を使用する必要があり、同じランダムに選択されたRTPタイムスタンプの初期化値を使用する必要があります。
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名スペースを共有するストリームを識別し、レシーバーがソースMIDIコマンドストリームを正確に再構築することができます（RTPタイムスタンプを使用して2つのストリームからコマンドをインターリーブすることにより）。衝突によるSSRCの変更が両方のストリームに反映されるように、送信者が注意する必要があります。レシーバーは、リンクされたストリームに関連付けられたRTCP CNAMEフィールドを定期的に調べて、想定されるリンクが合法であり、別の送信者によるSSRC衝突の結果ではないことを確認する必要があります。
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セッションで送信されるのが有利な場合があります。たとえば、2つのストリームには、RTPセッションレベルの属性（SendonlyやRecvonly属性など）に異なる値が必要になる場合があります。2番目の例として、異なるコンピューターで発生するマルチメディアセッションで2つのユニキャストストリームを送信するには、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 may be configured in a multicast topology, which use 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-5 and Appendices A-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は、ジャーナルセクションのデフォルト形式であるRecovery Journalを定義します。ここでは、これらのペイロードセクションが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.
ストリームのジャーナリング方法はセッションの開始時に設定されており、その後変更してはなりません。ストリームは、Recovery 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など）を使用するストリームは、Recovery Journalを使用することにデフォルトです。信頼できる輸送（TCPなど）を使用するストリームは、ジャーナルを使用しないようにデフォルトです。付録C.2.1は、これらのデフォルトをオーバーライドするためのセッション構成ツールを定義しています。あらゆる種類の輸送について、送信者は連続したシーケンス番号を持つRTPパケットストリームを送信する必要があります（Modulo 2^16）。
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.
ストリームがRecoveryジャーナルを使用する場合、ストリーム内のすべてのペイロードにはジャーナルセクションを含める必要があります。ストリームがジャーナリングを使用しない場合、ジャーナルセクションはストリームペイロードに表示されてはなりません。ストリームが代替ジャーナル形式を使用する場合、ジャーナル形式の仕様はインクルージョンポリシーを定義します。
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 size exceeds 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コントロールプロトコル（RTCP、[RFC3550]）フィードバックを使用して、RTP MIDIパケットサイズを管理します。さらに、セクション3.2および付録B.5.2は、MIDIシステム専用（0xF0）コマンドをコードするパケットのサイズを管理するための特定のツールを提供します。付録C.5では、密なMIDI名スペースをいくつかのUDPストリームに分割するために使用できるセッション構成ツール（それぞれがセクション2.1に従って異なるRTPセッションで送信）を定義して、ペイロードがMTUに快適に適合するようにします。別のオプションは、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.
ヘッダーフィールドレンは、ヘッダーに続くMIDIリストのオクテットの数をコードします。ヘッダーフラグBが0の場合、ヘッダーの長さは1オクターで、レンは4ビットフィールドで、最大MIDIリストの長さは15オクテットです。
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オクターで、レンは12ビットフィールドで、最大MIDIリストの4095オクテットをサポートします。LENはネットワークバイトの順序でコーディングされています（Big-Endian）：最初のヘッダーOctetコードに表示される4ビットのレンは、12ビットLEN値の最も重要な4ビットです。
A LEN value of 0 is legal, and it codes an empty MIDI list.
0のレン値は合法であり、空の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 = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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リストは完全なMIDIコマンド（図3のMIDIコマンド0フィールドでコーディングされた）で始まります。zが0の場合、Delta Time 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リスト構造は、オプションで、それぞれがMIDIコマンドKフィールドでコード化された追加の完全なMIDIコマンドのリストをエンコードすることもできます。追加の各コマンドの前には、コマンドのデルタ時間をコーディングするデルタタイムKフィールドが必要です。セクション3.2の「コマンドフィールドコードComplete 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 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フィールドにエンコードされていた）なしで、単一のデルタ時間（Delta Time 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リストコマンドのタイムスタンプをエンコードする方法について説明します。コマンドタイムスタンプは、RTPパケットヘッダータイムスタンプと同じユニットを持っています（セクション2.1および[RFC3550]で説明）。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 Delta Time構文は、MIDIファイルDelta Time Syntax [MIDI]の変更された形式です。RTP Midi Delta Timesは、1〜4個のOctetフィールドを使用して、32ビットの非署名整数をエンコードします。図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からKです。Octet Delta Times。
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).
パケット内のすべてのコマンドタイムスタンプは、ストリーム内の次のパケットのRTPタイムスタンプ以下でなければなりません（Modulo 2^32）。
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パケットヘッダーでエンコードされた後の瞬間から始まり、最終的なコマンドタイムスタンプが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リストの「Delta Time 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).
さらに、RTP MIDIパケットをコーディングして、ストリーム内の期間がMIDIコマンドがないことを表現することができます。ヘッダーのRTPタイムスタンプは、ボイド時間の開始をコーディングします。このパケットのMIDIリストは、ボイド時間の終わりをコーディングした「Delta Time 0」フィールドで構成されます。MIDIリストには他のフィールドは存在しません（セクション3の前文も明示的に合法になった構文構造）。
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つのタイムスタンプの違いは、コマンドの実行間の時間遅延を示します。この違いはゼロである可能性があり、同時実行をコーディングします。このメモでは、このタイムスタンプの解釈を「comex」（コマンド実行）セマンティクスと呼びます。Comexセマンティクスを付録C.3に正式に定義します。
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.
SMFSがファイルに保存されている各MIDIコマンドのタイムスタンプをコードするため、タイムスタンプのCOMEX解釈は標準MIDIファイル（SMF）をRTP MIDIストリームにトランスコードするのに適しています。メトリックタイムマーカーを使用するSMFをトランスコードするには、SMFテンポマップ（SMFでメタイベントとしてエンコード）を使用して、メトリックSMFタイムスタンプユニットを秒ベースのRTPタイムスタンプユニットに変換します。
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ストリームにRAWセンサーデータを直接コーディングしている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解釈は、通常、暗黙のコマンドタイミング（MIDI 1.0 DINケーブルなど）をRTP MIDIストリームに使用するMIDIソースをトランスコードするための最良のタイムスタンプ解釈ではありません。付録C.3は、COMEXセマンティクスの代替案を定義し、ストリームのタイムスタンプ解釈セマンティクスを選択するためのセッション構成ツールについて説明します。
One-Octet Delta Time:
One-Octet Delta Time：
Encoded form: 0ddddddd Decoded form: 00000000 00000000 00000000 0ddddddd
エンコードフォーム：0DDDDDDDデコードフォーム：00000000000000000000000DDDDDDD
Two-Octet Delta Time:
2オクテットのデルタ時間：
Encoded form: 1ccccccc 0ddddddd Decoded form: 00000000 00000000 00cccccc cddddddd
エンコードフォーム：1CCCCCC 0DDDDDDDデコードフォーム：000000000000000000CCCCCCDDDDDDD
Three-Octet Delta Time:
3オクテットのデルタ時間：
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 00000000 000bbbbb bbcccccc cddddddd
エンコードフォーム：1bbbbbbbb 1ccccccc 0dddddddd decoded form：00000000 000bbbbb bbcccccccddddddd
Four-Octet Delta Time:
4-OCTETデルタ時間：
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
エンコードフォーム：1AAAAAAAA 1BBBBBBBB 1CCCCCC 0DDDDDDDデコードフォーム：0000AAAA AAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
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コマンドタイプの1つをコードします。標準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チャネルコマンドには、ステータスOctetを含める必要があります。[MIDI]で定義されているように、[ステータスコーディングの実行も、リスト内のすべての後続のMIDIチャネルコマンドに使用できます。[MIDI]と同様に、システムコモンとシステムの排他的なメッセージ（0xf0 ... 0xf7）が実行中のステータス状態をキャンセルしますが、システムのリアルタイムメッセージ（0xf8 ... 0xff）は実行中のステータス状態に影響しません。MIDIリストのすべてのシステムコマンドには、ステータスOctetを含める必要があります。
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ソースデータストリームの対応するコマンドには、ステータスOctetがない場合があります（この場合、ソースは実行状態を使用してコマンドをコーディングします）。MIDIリストの最初のチャネルコマンドのステータスオクテットがソースデータストリームに表示されない場合、P（Phantom）ヘッダービットは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リストにはステータスOctetを含める必要があります。
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コマンドフィールドは、正確に1つの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リストに表示されます。システムリアルタイムコマンドのDelta Timeは、システムのリアルタイムコマンド配置を元の組み込み位置にエンコードするコマンドタイムスタンプを作成する必要があります。
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 System Exclusive（SYSEX）コマンドをエンコードするための2つの方法が提供されています。Sysexコマンドは、MIDIコマンドフィールドFerbatim：A 0xf0 Octetでエンコードされ、その後に任意の数のデータオクテットが続き、その後0xf7オクターが続きます。
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.
あるいは、Sysexコマンドを複数のセグメントとしてエンコードすることもできます。コマンドは、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コマンドをセグメント化するには、最初にデータOctetリストを2人以上のサブリストに分割します。最後のサブリストは空である可能性があります（つまり、オクテットが含まれていません）。他のすべてのサブリストには、少なくとも1つのデータOctetが含まれている必要があります。セグメンテーションを完了するには、図5で定義されているステータスオクテットを、最初、最後、および「中間」のサブリストの頭と尾に追加します。図6は、Sysexコマンドのセグメンテーションの例を示しています。
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に示す「キャンセル」サブリストを送信することにより、進行中のセグメント化された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コマンド送信をキャンセルする方法がなければ、送信者は、送信前に各Sysexコマンドを検証するために、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でSysexコマンドがキャンセルされる可能性があるという事実を認識します。これらのレシーバーは、MIDIリストのシステムキャンセルを検出し、Sysexコマンドを一度も受け取ったことがないかのように動作する必要があります。
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-AWAREシステムはRTP MIDIストリームを受信し、MIDI DINケーブル（またはそのエミュレーション）にトランスコードします。キャンセルサブリストを受け取ると、RTP-MIDI-AWAREトランスコダーは、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ケーブルプロトコルは「進行中のSysexをキャンセルする」セマンティクスを直接コードすることはできません。ただし、MIDI DINケーブルレシーバーは、完全なコマンドが到着した後、SYSEX処理を開始します。受信者は、コマンド（最初の数オクテットでコーディングされた）を認識しているかどうかを確認し、その後、コマンドが正しい長さであるかどうかを確認します。したがって、実際には、トランスコダーは、0xf7を（早期に）sysexコマンドに（早期に）終了することにより、sysexコマンドをキャンセルできます。レシーバーは誤ったコマンドの長さを検出し、コマンドを破棄します。
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コマンド以外のコマンドは、Sysexコマンドセグメント間に表示されてはなりません（付録C.1は、このデフォルトを変更する構成ツールを定義し、他のコマンドタイプをセグメント間に表示するように定義します）。Sysexコマンドのコマンドセグメントが2つ以上の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:
MIDI 1.0 DINケーブルに携帯されているSysexコマンドは、「Dropped 0xF7」構造[MIDI]を使用する場合があります。このコーディング方法では、0xf7オクテットはSysexコマンドの最後から削除され、次のMIDIコマンドのステータスオクテットはSysexコマンドを終了し、次のコマンドを開始するように機能します。この構造をペイロード形式でエンコードするには、次の手順に従ってください。
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コマンドの最後に「Dropped」0xf7 Octetを挿入して、標準のシステム構文を形成します。
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を将来使用するために留保します。デフォルトでは、未定義のコマンドは、MIDIリストのMIDIコマンドフィールドに表示されてはなりません。ただし、0xf5オクテットを除き、「Dropped 0xf7」構造とSysexが「キャンセル」サブリストで使用する0xf4オクテットをコーディングするために使用します。
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実装に表示される場合があります。これらのコマンドをモデル化するために、コマンドは0xf4または0xf5ステータスオクテットから始まり、その後ゼロ以上のデータオクテットで始まり、その後に0xf7ステータスのゼロ以上が続くと仮定します。コマンドをエンコードするには、送信者は最初にコマンドからトレーリングされた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 "middle" or "last" sublist of a segmented SysEx commands (Figure 5) under certain packet loss conditions.
注意測定としてモデルにトレーリングオクテットを含めることに注意してください：そのようなコマンドが未定義のシステム共通コマンドの非準拠の使用で表示された場合、トレーリングオクテットを削除しなかったコマンドのRTP MIDIエンコードは、特定のパケット損失条件下でのセグメント化されたシステムコマンド（図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.
Recovery Journalは、信頼性の低い輸送のためのデフォルトの回復力ツールです。このセクションでは、送信者と受信者がRecovery Journalシステムで果たす役割を規範的に定義します。
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コマンドストリームでの単一の失われたコマンドは、レンダリングされたパフォーマンスにアーティファクトを生成する場合があります。レンダリングアーティファクトを2つのカテゴリに通常分類します。
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 一時的なアーティファクト。一時的なアーティファクトは、パフォーマンスに即時が短期間の不具合を生成します。たとえば、Lost Noteon（0x9）コマンドは過渡的なアーティファクトを生成します。1つのノートは再生できませんが、アーティファクトはそのメモの終わりを超えて拡張されません。
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 無期限のアーティファクト。無期限のアーティファクトは、レンダリングされたパフォーマンスに長期にわたるエラーをもたらします。たとえば、Lost NoteOff（0x8）コマンドは、無期限のアーティファクトを生成する場合があります。LostNoteoffコマンドによって終了するはずだったメモは、無期限に維持される場合があります。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.
Recovery Journal Systemの目的は、Recovery Journal Mandateを満たすことです。
The recovery journal system does not use packet retransmission to satisfy this mandate. Instead, each packet includes a special section, called the recovery journal.
Recovery Journal Systemは、この任務を満たすためにパケットの再送信を使用しません。代わりに、各パケットには、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 packet and the checkpoint history.
Recovery Journalは、チェックポイントパケットと呼ばれる以前のパケットに戻るストリームの履歴をコーディングします。ジャーナルのカバレッジの範囲は、チェックポイント履歴と呼ばれます。Recovery Journalは、チェックポイント履歴に任意の数のパケットを失うことから回復するために必要な情報をコーディングします。付録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.
受信機がパケットの損失を検出すると、ストリームの履歴に関する独自の知識を、損失イベントを終了するパケットのRecovery Journalでコード化された履歴情報と比較します。過去のこれら2つのバージョンの違いに注目することにより、レシーバーは、MIDIコマンドを実行してストリームを修復することにより、レンダリングされたパフォーマンスのすべての無期限のアーティファクトを一時的なアーティファクトに変換することができます。
We now state the normative role for senders in the recovery journal system.
現在、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_updateを使用して、送信者は指定されたポリシーを使用する必要があります。
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-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を選択した後、送信者はRecovery Journalを作成します。デフォルトでは、このジャーナルは、セクション5の規範的セマンティクスに準拠し、このメモの付録A-Bに準拠する必要があります。付録C.2.3では、回復ジャーナルの規範的セマンティクスを変更するパラメーターを定義します。セッションの説明がこれらのパラメーターを使用する場合、送信者によって作成されたジャーナルは、変更されたセマンティクスに準拠する必要があります。
Next, we state the normative role for receivers in the recovery journal system.
次に、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. Depending on the application, the sender, the receivers, and other parties may take part in creating or approving the session description.
次に、Recovery Journal Systemのセッション説明の作成者の規範的役割を述べます。アプリケーションに応じて、送信者、受信機、およびその他の当事者は、セッションの説明の作成または承認に参加できます。
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.
デフォルトのクローズドループ送信ポリシーとデフォルトのRecovery Journalセマンティクスを指定するセッションの説明は、Recovery Journalのマンデートを満たします。ただし、これらのデフォルトの動作は、すべてのセッションに適していない場合があります。セッションの説明の作成者が付録C.2で定義されているパラメーターを使用してこれらのデフォルトをオーバーライドする場合、作成者はパラメーターがRecovery Journal Mandateを満たすシステムを定義することを確認する必要があります。
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-B complete the bitfield definition of the recovery journal.
このセクションでは、Recovery Journalの構造を紹介し、Recovery Journal HeadersのBitfieldsを定義します。付録A-B Recovery JournalのBitfield定義を完了します。
The recovery journal has a three-level structure:
Recovery Journalには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 systems commands (system journal).
o チャネルおよびシステムジャーナルヘッダー。これらのヘッダーは、単一の音声チャンネル（チャンネルジャーナル）またはすべてのシステムコマンド（System Journal）に対して回復情報をエンコードします。
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 journals 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は、Recovery Journalのトップレベル構造を示しています。回復ジャーナルは、3オクテットのヘッダーで構成され、その後、オプションのシステムジャーナル（図7のS-Journalというラベル）とチャンネルジャーナルのオプションのリストが続きます。図8は、Recovery Journalヘッダー形式を示しています。
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に設定されている場合、Recovery Journal Headerに直接続くシステムジャーナルはRecovery Journalに表示されます。
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に設定されている場合、Recovery Journalは（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チャネルは、（せいぜい）Recovery Journalの1つのチャンネルジャーナルで表現できます。チャンネルジャーナルは、Recovery Journalに昇順のチャネル番号順序で表示する必要があります。
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の両方がゼロの場合、Recovery Journalには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（シングルパケット損失）ビットは、Recovery Journal Headerを含むほとんどのRecovery Journal構造に表示されます。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).
Hビットは、ストリーム内のMIDIチャネルが、拡張された第Cエンコーディングを使用するように構成されているかどうかを示します（付録A.3.3）。
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ヘッダーフィールドは、このジャーナルのチェックポイントパケットのシーケンス番号をネットワークバイト順序でコードします（Big-Endian）。チェックポイントパケットの選択は、ジャーナルのチェックポイント履歴の深さを設定します（付録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フィールドが1つ以下の場合、以前にストリームで受信した最高のRTPシーケンス番号よりも低い場合の損失イベントをカバーします（Modulo 2^16）。
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オクテットヘッダー、続いてチャネル章と呼ばれるリーフ要素のリストを示しています。チャンネルジャーナルは、4ビットChanヘッダーフィールドによってコード化されたMIDIチャネルの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ビットの長さフィールドは、チャンネルジャーナルの長さをコードします。長さフィールドのセマンティクスは、Recovery Journal全体で均一であり、付録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:
チャンネルジャーナルヘッダーの3番目のオクテットは、チャンネルジャーナルの目次（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）o第C章：MIDIコントロールの変更（0xb）o第M章：MIDIパラメーターシステム（0xbの一部）o第w章：MIDIピッチホイール（0xe）o第n章：MIDIノートオフ（0x8）、Noteon（0x9）o第E章：MIDIノートコマンドエクストラ（0x8、0x9）o第T章：MIDIチャンネルAfterTouch（0xD）o第a章：MIDIポリアフタータッチ（0xA）
Chapters appear in a list following the header, in order of their appearance in the TOC. Appendices A.2-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-9各章のビットフィールド形式を説明し、章のタイプがRecovery Journalに表示されなければならない条件を定義します。チャンネルに章の種類が必要な場合は、関連するチャネルジャーナルがRecovery Journalに表示する必要があります。
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).
Hビットは、MIDIチャネルのコントローラー番号が、拡張された第Cエンコーディングを使用するように構成されているかどうかを示します（付録A.3.3）。
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エンコーディングを使用しません。このデフォルトの場合、Recovery Journalのチャネルのすべてのチャネルジャーナルヘッダー、ストリーム内のすべてのパケットについて、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 Systems command:
図10は、System Journalの構造：2-OCTETヘッダー、次にシステムの章のリストを示しています。各チャプターは、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: MTC Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01) o Chapter X: System Exclusive (all other 0xF0)
o 第D章：Song Select（0xf3）、Tune Request（0xf6）、Reset（0xff）、未定義のシステムコマンド（0xf4、0xf5、0xf9、0xfd）o第5章：アクティブセンス（0xfe）o章Q：シーケンサー状態（0xf2、0xf8、0xf9、0xfa、0xfb、0xfc）o第f：MTCテープポジション（0xf1、0xf0 0x7f 0xcc 0x01 0x01）o第X章：システム専用（他のすべての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では、システムの章のビットフィールド形式について説明し、章の種類がRecovery Journalに表示されなければならない条件を定義します。Recovery Journalにシステムの章のタイプが必要な場合は、システムジャーナルがRecovery Journalに表示される必要があります。
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の使用と呼んでいます。ネゴシエートされた使用の1つの例は、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の使用を「宣言的使用法」と呼びます。宣言的使用法の1つの例は、このメモの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-Generic（セクション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.
以下のセッションの説明では、単キャストUDP RTPセッション（メディア（ "m ="）行）を定義します。その唯一のペイロードタイプ（96）は、最小限のRTP MIDIストリームにマッピングされます。
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
V = 0 O = Lazzaro 2520644554 2838152170 in ip4 first.example.net s =例t = 0 0 m = audio 5004 rtp/avp 96 c = in ip4 192.0.2.94 a = rtpmap：96 rtp-midi/44100
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 Hz）は、RTPタイムスタンプヘッダーフィールドのスケーリングを設定します（セクション2.1、および[RFC3550]を参照）。
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など）を使用している場合、Recovery Journalシステムが使用されており、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. ストリームがRecovery Journalシステムを使用する場合、Recovery Journal Systemはデフォルトの送信ポリシーとデフォルトジャーナルセマンティクス（セクション4）を使用します。
3. In the MIDI command section of the payload, command timestamps use the default "comex" semantics (Section 3).
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).
4. 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は、2番目のストリームのチャネル1と同じMIDIチャネルを参照しません（付録C.5を参照してください。最小限のRTP-MIDIストリームの独立性についての議論のために）。
6. The rendering method for the stream is not specified. What the receiver "does" with a minimal native MIDI stream is "out of 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 in 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セッションはデフォルトでsendrecv（パーティがMIDIを送信および受信）し、RTSPが管理するRTPセッションはデフォルトでrecvonly（サーバー送信およびクライアントが受信します）です。
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, 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デバイスが2つのMIDIケーブル（最初のデバイスからMIDIを2番目のデバイスのMIDIにルーティングする1つのケーブルルーティング、最初のデバイスからMIDIにMIDIをルーティングする2番目のケーブルルーティングMIDIとクロス接続されている場合に発生することに対応します。2番目のデバイスから）。この「関連性」をセクション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対多数のフォワードパスと多くの逆パスを提供することとは別に、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:
MPEG4-Generic [RFC3640] RTP MIDIストリームは、MPEG 4オーディオオブジェクトタイプを使用してMIDIをオーディオにレンダリングします。3つのオーディオオブジェクトタイプは、MIDI入力を受け入れます。
o General MIDI (Audio Object Type ID 15), based on the General MIDI rendering standard [MIDI].
o 一般的なMIDIレンダリング標準[MIDI]に基づく一般的なMIDI（オーディオオブジェクトタイプID 15）。
o Wavetable Synthesis (Audio Object Type ID 14), based on the Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2].
o ダウンロード可能なサウンドレベル2（DLS 2）レンダリング標準[DLS2]に基づいた、波状合成（オーディオオブジェクトタイプID 14）。
o Main Synthetic (Audio Object Type ID 13), based on Structured Audio and the programming language SAOL [MPEGSA].
o 構造化されたオーディオとプログラミング言語Saol [MPEGSA]に基づいた主な合成（オーディオオブジェクトタイプID 13）。
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-Genericストリームの主要なサービスは、アクセスユニット（AUS）をコーディングすることです。MPEG4-Generic RTP MIDI AUを、このメモのセクション2.1の図1に示すMIDIペイロードとして定義します。
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.
正確に1つのRTP MIDI AUを1つのMPEG4-GENERIC RTP MIDIパケットにマッピングする必要があります。RTP PacketにいくつかのAUを配置するためのMPEG4-Genericオプションは、RTP MIDIで使用してはなりません。断片化およびインターリービングAUSのMPEG4-GENERICオプションは、RTP MIDIで使用してはなりません。MPEG4-Generic 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.
以下のセッションの説明は、単弾キャストUDP RTPセッション（メディア（ "m ="）ラインを介して）を定義します。その唯一のペイロードタイプ（96）は、最小限のmpeg4-generic rtp midiストリームにマッピングされます。この例では、合成プロファイル @レベル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:DB80::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=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の単一行で構成されています。）
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 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.
FMTP属性ラインは、すべてのMPEG4-Genericセッションの説明[RFC3640]で必要な4つのパラメーター（StreamType、Mode、Profile-Revel-ID、およびConfig）をコーディングします。RTP MIDIストリームの場合、StreamTypeパラメーターは5に設定する必要があり、「モード」パラメーターは「RTP-MIDI」に設定する必要があり、「プロファイルレベルID」パラメーターはMPEG-4プロファイルレベルに設定する必要があります。ストリーム。合成プロファイルの場合、法的プロファイルレベルID値は11、12、および13で、MPEG適合テストで定義されているように、低（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セッションの説明では、構成値は、ストリームのAudipecificConfigデータブロック[MPEGAUDIO]の16進コード[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 leading config string nibbles "7A" yield the 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ビットをオーディオオブジェクトタイプをコーディングする符号なし整数として解釈することにより、セッションのレンダリングアルゴリズムを決定します。上記の例では、主要な構成文字列ニブル「7a」は、オーディオオブジェクトタイプ15（一般MIDI）を生成します。付録E.4では、上記のセッションの説明で構成文字列値を導き出します。派生の出発点は、[mpegsa]および[mpegaudio]で定義されている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-Genericパラメーターを除き、パラメーターを使用してストリームをカスタマイズしないため、ストリームは「最小」であると考えています。セクション6.1では、特性の番号付きリストとして、最小限のネイティブストリームの動作について説明します。そのリストの項目1-4は、最小限のMPEG4-Genericストリームについても説明していますが、項目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-Genericストリームが表示される場合、各ストリームは、構成パラメーター値でコーディングされたオーディオオブジェクトタイプの独立したインスタンスを使用します。
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 Size (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-GENERICストリームは、AudioSpecificConfigをインライン16進定数としてエンコードします。セッションの説明がUDPを介して送信される場合、基礎となるネットワークの最大透過サイズ（MTU）内で大きなaudipecificconfigブロックを輸送することは不可能かもしれません（イーサネットの場合、MTUは1500オクテットです）。場合によっては、audipecificconfigブロックは、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ストリームの方向性デフォルト、SendRecv MIDIチャネルの使用法、およびMIDI 1.0 DINマルチキャストネットワークに関するセクション6.1のコメントも、MPEG4-Generic 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セッションでは、各パーティのセッションの説明は、MPEG4-Genericパラメーター（必要なStreamType、Mode、Profile-Level-ID、および構成パラメーターを含む）の同一の値を使用する必要があります。結果として、各パーティは、同一に構成されたMPEG 4オーディオオブジェクトタイプを使用して、MIDIコマンドをオーディオにレンダリングします。付録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-2, and support several types of services:
パラメーターは、セクション6.1-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 1.0 DINケーブルに表示される合法的なMIDIコマンドはすべて、RTP MIDIストリームに表示される場合があります。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_SECおよびJ_UPDATEパラメーターは、ジャーナルセクションの使用を構成します。CH_DEFAULT、CH_NEVER、およびCH_ANCHORパラメーターは、Recovery Journalの章のセマンティクスを構成します。これらのパラメーターは、付録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
o MIDIコマンドタイムスタンプセマンティクス。TSMode、Octpos、Mperiod、およびLinateのパラメーターは、MIDIコマンドセクションのタイムスタンプのセマンティクスをカスタマイズします。これらのパラメーターにより、RTP MIDIは、MIDI 1.0 DINケーブルの暗黙的な時間コーディングを正確にエンコードすることができます。これらのパラメーターは、付録C.3で説明し、セクション6.1にリストされ、セクション6.2で参照されているデフォルトのストリーム動作3をオーバーライドします。
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で説明されており、セクション6.1にリストされ、セクション6.2で参照されているデフォルトのストリーム動作4をオーバーライドします。
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に記載されています。MusicPortパラメーターは、セクション6.1および6.2のデフォルトのストリーム動作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.
o MIDIレンダリング。いくつかのパラメーターは、ストリームの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).
付録C.7では、2つのRTP MIDIアプリケーション領域の相互運用性ガイドラインを指定します。RTSP（付録C.7.1）を使用したコンテンツストリーミングとSIPを使用したネットワークミュージカルパフォーマンス（付録C.7.2）。
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_SECおよびJ_UPDATEパラメーターの新しいトークン値は、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.
o 未定義のコマンド。[MIDI]将来の使用のための4 MIDIシステムコマンド（0xf4、0xf5、0xf9、0xfd）。[MIDI]の更新が予約されたコマンドを定義する場合、IETF標準トラックドキュメントを定義して、コマンドの回復力のサポートを提供する場合があります。
Opaque LEGAL fields appear in System Chapter D for this purpose (Appendix B.1.1).
不透明な法的分野は、この目的のためにシステム章Dに登場します（付録B.1.1）。
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] applies 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プロファイルドキュメントのセキュリティに関する考慮事項セクションを注意深く読み取る必要があります。また、実装者は、[RFC3550]および[RFC3551]で説明されているセキュリティ問題に対処するRTPプロファイルである、安全なリアルタイム輸送プロトコル（SRTP、[RFC3711]）を確認する必要があります。
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]のセキュリティに関する考慮事項セクションは、可能な認証メカニズムの概要を提供します。RTP MIDIセッションの説明は、セッションの説明が付録Cで説明されているパラメーターを使用して初期化データをコーディングできるため、認証を使用する必要があります。攻撃者が偽の初期化データをセッションの説明に挿入すると、セッションを破損したり、クライアント攻撃を強要したりできます。
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では、2つの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, Nicolas Falquet, Dominique Fober, Philippe Gentric, Michael Godfrey, Chris Grigg, Todd Hager, Michel Jullian, Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer, Colin Perkins, Charlie Richmond, Herbie Robinson, Larry Rowe, Eric Scheirer, Dave Singer, Martijn Sipkema, William Stewart, Kent Terry, 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.
Kurt B、Cynthia Bruyns、Steve Casners、Paul Davis、Robin Davies、Joanne Dow、Tobias Erichsen、Nicolas Falquet、Dominique Fober、など、ネットワーキング、メディア圧縮、コンピューターミュージックコミュニティのメンバーに感謝します。フィリップ・ゲントリック、マイケル・ゴッドフリー、クリス・グリッグ、トッド・ヘイガー、ミシェル・ジュリアン、フィル・カー、ヤング・クウォン・リム、ジェシカ・リトル、ヤン・ファン・デル・ミーアー、コリン・パーキンス、チャーリー・リッチモンド、ハービー・ロビンソン、ラリー・ロウ、エリック・シラー、デイブ・シンガー、マルティイジュンSipkema、William Stewart、Kent Terry、Magnus Westerlund、Tom White、Jim Wright、Doug Wyatt、Giorgio Zoia。また、ドン・ブッホラ、クリス・チャフ、リチャード・デュダ、ダン・エリス、エイドリアン・フリード、ベン・ゴールド、ジャロン・ラニエ、ロジャー・リン、リチャード・リヨンなど、仕事のコンテキストを作成してくれたサンフランシスコベイエリアの音楽とオーディオコミュニティのメンバーにも感謝します。、Dana Massie、Max Mathews、Keith McMillen、Carver Mead、Nelson Morgan、Tom Oberheim、Malcolm Slaney、Dave Smith、Julius Smith、David Wessel、Matt Wright。
This section makes a series of requests to IANA. The IANA has completed registration/assignments of the below requests.
このセクションは、IANAへの一連のリクエストを行います。IANAは、以下のリクエストの登録/割り当てを完了しました。
The sub-sections that follow hold the actual, detailed requests. All registrations in this section are in the IETF tree and follow the rules of [RFC4288] and [RFC3555], as appropriate.
以下のサブセクションには、実際の詳細なリクエストが保持されます。このセクションのすべての登録はIETFツリーにあり、必要に応じて[RFC4288]および[RFC3555]のルールに従います。
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.
セクション11.1では、新しいメディアタイプ「Audio/RTP-MIDI」の登録をリクエストします。このリクエストとペアになっているのは、「Audio/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.
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-Generic」の「モード」パラメーター値要求とペアリングされることは、「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.
セクション11.3では、新しいメディアタイプ「Audio/ASC」の登録をリクエストします。このリクエストに関連付けられているリポジトリリクエストはありません。
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, below.
このセクションでは、「オーディオ」メディアタイプの「RTP-MIDI」サブタイプの登録をリクエストします。以下の「オプションのパラメーター」セクションにリストされているパラメーターの登録を要求します（「非拡張可能なパラメーター」と「拡張可能なパラメーター」リストの両方）。また、「拡張可能なパラメーター」のリポジトリの作成をリクエストします。このリクエストの詳細は、以下のセクション11.1.1に表示されます。
Media type name:
メディアタイプ名：
audio
オーディオ
Subtype name:
サブタイプ名：
rtp-midi
rtp-midi
Required parameters:
必要なパラメーター：
rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1 for usage details.
レート：RTPタイムスタンプ時計レート。使用状況の詳細については、セクション2.1および6.1を参照してください。
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. 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を参照してください。ガードタイム：使用法の詳細については、付録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.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_SEC：使用法の詳細については、付録C.2.1を参照してください。リポジトリの詳細については、セクション11.1.1を参照してください。j_update：使用法の詳細については、付録C.2.2を参照してください。リポジトリの詳細については、セクション11.1.1を参照してください。レンダリング：使用法の詳細については、付録C.6を参照してください。リポジトリの詳細については、セクション11.1.1を参照してください。サブレンダー：使用状況の詳細については、付録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.
このタイプは、RTPを介したMIDIストリームのリアルタイム転送に対してのみ定義されます。RTP-MIDIの保存されたファイルセマンティクスは、将来定義される場合があります。
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.
このメモと[MIDI]は、規範的仕様として機能します。さらに、参考文献[NMP]、[Grame]、および[RFC4696]は、非規範的な実装ガイダンスを提供します。
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 bit-rate music coding.
MIDIコントローラーピアノキーボードやMIDIオーディオシンセサイザーなどのオーディオコンテンツ作成ハードウェア。音楽シーケンサー、デジタルオーディオワークステーション、ソフトシンセサイザーなどのオーディオコンテンツ作成ソフトウェア。MIDIアプリケーションプログラマーインターフェイスのネットワークサポートのためのコンピューターオペレーティングシステム。コンテンツ配信サーバーと端末は、このメディアタイプを使用して、低価格の音楽コーディングに使用できます。
Additional information:
追加情報：
None.
なし。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
意図された使用法：
COMMON.
一般。
Author:
著者：
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
Change Controller：
IETF Audio/Video Transport Working Group delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループは、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_SEC：
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_update：
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 text in 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で定義されています。「null」：このメモの付録C.6で定義されています。
subrender:
サブレンダー：
Registrations for this repository MUST include a specification of the usage of the proposed value. See text Appendix C.6.2 for details (the paragraph that begins "Other subrender token ...").
このリポジトリの登録には、提案された値の使用法の仕様を含める必要があります。詳細については、テキスト付録C.6.2を参照してください（「他のサブレンダートークン...」から始まる段落）。
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 text in 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-Generic」メディアタイプの「モード」パラメーターの「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, below.
Media type name:
メディアタイプ名：
audio
オーディオ
Subtype name:
サブタイプ名：
mpeg4-generic
MPEG4-Generic
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.
[モード]パラメーターは[RFC3640]で必要です。[RFC3640]は、「モード」のリポジトリを要求するため、モードの新しい値が追加されるようにします。値「rtp-midi」を「モード」リポジトリに追加することを要求します。
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では、MPEG4-Genericパラメーターレートが必要なパラメーターです。レートRTPタイムスタンプクロックレートを指定します。モードrtp-midiのレートの使用の詳細については、セクション2.1および6.2を参照してください。
Optional parameters:
オプションのパラメーター：
We request registration of the following parameters for use in mode rtp-midi for mpeg4-generic.
MPEG4-GenericのモードRTP-MIDIで使用するための次のパラメーターの登録をリクエストします。
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.
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を参照してください。ガードタイム：使用法の詳細については、付録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: 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.
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_SEC：使用法の詳細については、付録C.2.1を参照してください。リポジトリの詳細については、セクション11.2.1を参照してください。j_update：使用法の詳細については、付録C.2.2を参照してください。リポジトリの詳細については、セクション11.2.1を参照してください。レンダリング：使用法の詳細については、付録C.6を参照してください。リポジトリの詳細については、セクション11.2.1を参照してください。サブレンダー：使用状況の詳細については、付録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.
Modio/MPEG4-Generic RTPストリームのリアルタイムトランスファーのみが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.
マーカービット（セクション2.1）を除き、Audio/RTP-MIDIおよびAudio/MPEG4-Generic（モードRTP-MIDI）のパケット形式は同一です。フォーマットの使用は異なります：Audio/MPEG4-GenericはMPEG作業用であり、Audio/RTP-Midiは他のすべての作業用です。
Published specification:
公開された仕様：
This memo, [MIDI], and [MPEGSA] are the normative references. In addition, references [NMP], [GRAME], and [RFC4696] provide non-normative implementation guidance.
このメモ、[MIDI]、および[MPEGSA]は規範的な参照です。さらに、参考文献[NMP]、[Grame]、および[RFC4696]は、非規範的な実装ガイダンスを提供します。
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:
詳細については、連絡先への個人およびメールアドレス：
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
意図された使用法：
COMMON.
一般。
Author:
著者：
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
Change Controller：
IETF Audio/Video Transport Working Group delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループは、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-GENERICサブタイプのモードRTP-MIDIの場合、次のパラメーター（セクション11.2の「拡張可能なパラメーター」としてリストされているパラメーター）の拡張機能のリポジトリの作成をリクエストします。
j_sec:
J_SEC：
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_update：
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 text in 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で定義されています。「null」：このメモの付録C.6で定義されています。
subrender:
サブレンダー：
Registrations for this repository MUST include a specification of the usage of the proposed value. See text 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 ("Registrations for mpeg4-generic subrender values ...").
このリポジトリの登録には、提案された値の使用法の仕様を含める必要があります。詳細については、テキストの付録C.6.2を参照してください（「他のサブレンダートークン...」とその後の段落を開始する段落）。付録C.6.2のテキストには、MPEG4-Genericのサブレンダー登録に関する制限が含まれていることに注意してください（「MPEG4-Genericサブレンダー値の登録...」）。
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 text in 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」を「オーディオ」メディアタイプのサブタイプとして登録します。このサブタイプを登録して、MPEG4-Generic Mode RTP-MIDIで使用される場合、MPEG4-Genericメディアタイプ[RFC3640]の「config」パラメーターのリモート転送をサポートします（上記の付録11.2に登録）。「Audio/ASC」を使用して、このドキュメントのセクション6.2および付録C.6.5の構成パラメーターを設定するメカニックについて説明します。
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]など）で定義されたリポジトリへの追加ではないことに注意してください。また、この「Audio/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.
データオブジェクトのネイティブ形式はバイナリデータで、オクテットの境界にゼロパッドされます。
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.
このタイプは、データオブジェクト（保存されたファイル）転送に対してのみ定義されます。このタイプの最も一般的なトランスポートは、HTTPと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].
Audio/ASCデータオブジェクトは、[mpegaudio]で規範的に定義されているAudipecificconfigバイナリデータ構造です。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
MPEG 4 Audio servers and terminals that support audio/mpeg4-generic RTP streams for mode rtp-midi.
モードRTP-MIDIのオーディオ/MPEG4-GENERIC RTPストリームをサポートするMPEG 4オーディオサーバーと端子。
Additional information:
追加情報：
None.
なし。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
意図された使用法：
COMMON.
一般。
Author:
著者：
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
Change Controller：
IETF Audio/Video Transport Working Group delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
A. The Recovery Journal Channel Chapters
A. Recovery Journalチャネルの章
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).
この付録では、セクション5（ジャーナルヘッダー構造）のリカバリジャーナルビットフィールドの説明で使用される用語とコーディングイディオム、付録A.2からA.9（チャネルジャーナル章）、付録B.1からB.5（System Journalの章）。
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.
Recovery Journalは、シーケンス番号I（ "Packet I"）を備えたRTPパケットのジャーナルセクションに存在し、トップレベルの回復ジャーナルヘッダーのチェックポイントパケットSeqnumフィールドは、シーケンス番号Cを持つ以前のパケットを指していると想定しています。例外は、自己参照c = iの場合です）。特に明記しない限り、アルゴリズムは、16ビットシーケンス番号の計算にModulo 2^16算術を使用し、Modulo 2^32 32ビット拡張シーケンス番号の計算に算術を使用すると想定されます。
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.
Recovery Journal System全体にいくつかのビットフィールドコーディングイディオムが表示され、一貫したセマンティクスがあります。ほとんどの回復ジャーナル要素は、「S」（シングルパケット損失）ビットから始まります。S BITは、単一のパケットを失うという一般的なケースで、Recovery Journalの階層を効率的に解析するのに役立つように設計されています。
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ビットは1に設定する必要があります。ただし、パケットIの回復ジャーナル要素がパケットI -1のMIDIコマンドセクションに保存されているコマンドに関するデータをエンコードする場合、例外が適用されます。Recovery Journal要素は0に設定する必要があります。回復ジャーナル要素のSビットが0に設定されている場合、トップレベルの回復を含む、0に設定されたSビットも含むすべての高レベルの回復ジャーナル要素が必要です。ジャーナルヘッダー。
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 長さフィールド。長さのすべてのフィールド（レンとは異なる）コードは、それを含む構造内のオクテットの数をコードします。構造に長さフィールドが含まれている場合、レシーバーは、構造の内部形式に関する知識を使用するのではなく、解析中に構造を通過する長さフィールド値を使用する必要があります。
We now define normative terms used to describe recovery journal semantics.
現在、Recovery Journalセマンティクスを説明するために使用される規範的用語を定義します。
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 チェックポイント履歴。Recovery Journalのチェックポイント履歴は、パケットCのMIDIコマンドセクションをI -1から連結したものです。パケットI -1のMIDIコマンドセクションの最終コマンドは、最新のコマンドと見なされます。パケットCのMIDIコマンドセクションの最初のコマンドは、最も古いコマンドです。コマンドxがコマンドyよりも最近ではない場合、xは「yの前」と見なされます。コマンドのないチェックポイント履歴は空であると見なされます。チェックポイント履歴には、パケットIのMIDIコマンドセクション（Recovery Journalを含むパケット）が含まれることはありません。したがって、C == Iの場合、チェックポイント履歴は定義上空です。
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, and so the session history of the first packet in the session is empty by definition.
o セッション履歴。Recovery Journalのセッション履歴は、セッションの最初のパケットからPacket I -1までのMIDIコマンドセクションの連結です。CommandRemencyとHistoryの空虚の定義は、チェックポイントの歴史のそれらに従います。セッション履歴には、パケット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パケットに表示される場合、未完成のコマンドが発生します。たとえば、Sysexコマンドが3つのセグメントとしてコード化され、パケットKのセグメント1、パケットK 1のセグメント2、パケットK 2のセグメント3の場合、パケット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システムイネーブル（0x09 0x03 0xf7）、一般的なMIDIシステム障害（0xf0 0x7e 0xccccccccccx09 0x09 0x09 0x09、dlsをオンにします（0xf0 0x7e 0xcc 0x0a 0x01 0xf7）、dlsをオフにします（0xf0 0x7e 0xcc 0x0a 0x02 0xf7）。サブレンダーパラメータートークン値（付録C.6.2）およびIETF標準トラックドキュメントの登録は、追加のRSコマンドを指定する場合があります。
o Active commands. Active command 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アクティブコマンド。nアクティブコマンドは、セッション履歴の次のコマンドのいずれか以前に表示されないMIDIコマンドです。MIDIコントロール変更番号123-127（すべてのメモがセマンティクスオフ）または120（すべてサウンドオフ）、および任意のリセット状態コマンド。
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.
o Cアクティブコマンド。C-Activeコマンドは、セッション履歴の次のコマンドのいずれかの前に表示されないMIDIコマンドです。MIDIコントロール変更番号121（すべてのコントローラーをリセット）およびリセット状態コマンド。
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 最も古い最初の注文ルール。いくつかのRecovery Journalの章には、各要素がセッション履歴に表示される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 Names (RPN) system and the Non-Registered Parameter Names (NRPN) system each provides 16,384 parameters.
o パラメーターシステム。0-127コントローラー番号スペースを拡張するために、16,384パラメーターの2セットを提供するMIDI機能。登録されたパラメーター名（RPN）システムと非登録パラメーター名（NRPN）システムには、それぞれ16,384個のパラメーターが提供されます。
o Parameter system transaction. The value of RPNs and NRPNs 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 NRPNs, controller numbers 101 and 100 for RPNs). 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 (MSB value 0x7F, LSB value 0x7F).
o パラメーターシステムトランザクション。RPNとNRPNの値は、パラメーターシステムトランザクションを形成する一連の制御変更コマンドによって変更されます。標準的なトランザクションは、パラメーター番号（NRPNの場合はコントローラー番号99および98、RPNSのコントローラー番号101および100）を設定する2つの制御変更コマンドから始まります。トランザクションは、任意の数のデータ入力（コントローラー番号6および38）、データ増分（コントローラー番号96）、およびデータの減少（コントローラー番号97）を制御するコマンドを制御してパラメーター値を設定して続きます。トランザクションは、NULLパラメーター（MSB値0x7F、LSB値0x7F）を指定する（99、98）または（101、100）制御変更コマンドの2番目のペアで終了します。
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.
それほど一般的ではないが、A（99、98）または（101、100）コントロール変更ペアのMSB（99または101）または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（すべてのコントローラーのリセット）のコントロール変更（0xB）[RP015]です。
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）の場合、セッション履歴の初期MSB（99または101）の制御チェンジコマンドに従うと少なくとも1つのトランザクションコマンドがフォローしている場合、トランザクションが開始されると見なされます。トランザクションの完了は、その「開始」ステータスを無効にしません。
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 (Chapter D, Appendix B.1) and the Active Sense command (Chapter V, Appendix B.2). 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).
o セッション履歴リファレンスカウント。いくつかのRecovery Journalの章には、セッション履歴に表示されるタイプのコマンドの総数をコードする参照カウントフィールドが含まれています。例には、リセットおよびチューンリクエストコマンドログ（第D章、付録B.1）とアクティブセンスコマンド（第5章、付録B.2）が含まれます。損失イベントが検出されると、参照カウントフィールドに、ジャーナルの参照カウントと独自の参照カウントを比較することにより、コマンドのインスタンスが失われたかどうかを受信者に推測できます。したがって、失われたコマンドの数を知ることが無関係であるコマンドタイプであっても、参照カウントフィールドは理にかなっています（上記のすべての例コマンドに当てはまるように）。
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.
付録A.2からA.9およびB.1からB.5の章の定義は、デフォルトの回復ジャーナルの動作を反映しています。付録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コマンドに関する情報のみをエンコードすることに注意してください。付録A.2からA.9のMIDIコマンドへのすべての参照は、「このチャネルに表示される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 -Chapter 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ビットです。プログラムフィールドは、セッション履歴における最新のアクティブプログラム変更コマンドのデータ値を示します。デフォルトでは、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のアクティブコントロール変更（0xB）コマンドが表示される場合、Bビットは1に設定する必要があり、銀行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のコントロール変更コマンド（すべてのコントローラーをリセット）の場合、Bank-MSBフィールドによってコーディングされたコントロール変更コマンドとプログラムフィールドによってコード化されたプログラム変更コマンドの間の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 effect 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]は、すべてのコントローラーがコントローラー番号0（Bank Select MSB）および32（銀行選択LSB）の値をリセットしないことを指定することに注意してください。したがって、Xビットは、失われたプログラム変更コマンドから回復するときに、受信機が銀行LSBおよび銀行とMSBの値をどのように使用するかに影響しません。Xビットは、コントローラー番号0および32が非標準的な方法で使用される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 -Chapter 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.
この章は、1-OCTETヘッダーで構成され、その後に2-OCTETコントローラーログの可変長リストが続きます。リストには、少なくとも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つ以上のコントローラーログが表示されることを要求する場合、Chapter Cを含める必要があります。
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）を使用して14ビットコントローラー値を送信し、最小の有意なバイト（LSB、コントローラー番号32-63、98、100）を制御するコマンド[MIDI]を送信する場合があります[MIDI]。
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番号の最新のアクティブコントロール変更コマンドのコントローラーログを省略できます。このLSB値は無関係です。ただし、MIDIソースがコントローラー番号ペアに14ビットセマンティクスを使用していることが送信者が確信していない場合、この例外を適用してはなりません。一部のMIDIソースは、14ビットコントローラーセマンティクスを無視し、LSBコントローラー番号を独立した7ビットコントローラーとして使用することに注意してください。
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.
o コントローラー番号0のアクティブコントロール変更コマンド0（銀行選択MSB）または32（銀行選択LSB）がチェックポイント履歴に表示され、コマンドインスタンスも章PのバンクMSBおよび銀行LSBフィールドでコーディングされている場合（付録A.2）、Chapter 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 いくつかのコントローラー番号ペアは、相互に排他的であると定義されています。コントローラー番号124（Omni Off）および125（Omni on）は、コントローラー番号126（モノ）と127（ポリ）と同様に相互に排他的なペアを形成します。
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.
Checkpoint Historyにアクティブコントロールが相互に排他的なペアの一方または両方のメンバーのコマンドを変更する場合、チェックポイント履歴のペアの最新コマンドのコントローラー番号のログは、コントローラーリストに表示する必要があります。ただし、リストは、ペアの他の数値の最新のアクティブコマンドのコントローラーログを省略する場合があります。
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]が[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の例外ルールを定義しています。
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 -Chapter 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 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に設定されている場合、ログは値ツールを使用します。値ツールは、値/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.
ToggleまたはCountツールをコーディングするために、少し設定されています。これらのツールは、個別のアクションをコードするコントローラーに最適です。図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ビットが0に設定されている場合、ログはトグルツールを使用します。ログは、tビットが1に設定されている場合、カウントツールを使用します。
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フィールドは、ログによってコード化されたコマンドによって引き起こされるトグルまで、セッション履歴の制御チェンジコマンドによるトグルの総数（OFF-> ONおよびON-> OFF）をコードします。トグルカウントには、コントローラー番号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).
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.
ダンパーペダル（Sustain）コントローラーは、スイッチコントローラーのバリューツールに対するトグルツールの利点を示しています。ピアノアプリケーションでよく使用されるように、「オン」状態のコントローラーは、メモを共鳴させますが、「オフ」状態はすぐに沈黙を湿らせます。「ON-> OFF-> ON」シーケンスで「OFF」コマンドを失うと、沈黙が減っていたはずの音が鳴ります。トグルツールを使用すると、レシーバーがこの「失われた」オフコマンドを検出できますが、値ツールは検出できません。
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.
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.
In this section, we describe the organization of controller logs in the Chapter C log list.
このセクションでは、Chapter 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]).
ただし、コマンドはいくつかのツールタイプ（したがって、それぞれ異なるツールを使用して複数のログ）によってコーディングされる場合があります。この手法は、非ゼロデータOctet（[DLS2]で説明されているセマンティクスを使用）で使用すると、コントローラー番号84（Portamento Control）またはコントローラー番号121（すべてのコントローラーをリセット）など、複雑なセマンティクスを持つコントローラーの回復パフォーマンスを改善する可能性があります。
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.
Chapter 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.
この方法でコントロール変更コマンドを使用するアプリケーション領域をサポートするために、Chapter Cを構成して、コントローラー番号のいくつかのコントロール変更コマンドに関する情報をエンコードするように構成されている場合があります。「Enhanced」という用語を使用して、このエンコード方法を説明します。これについては、以下に説明します。
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では、Recovery Journalヘッダー（図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.
o コントローラー番号のnコマンドがリストにエンコードされている場合、コマンドはセッション履歴のコントローラー番号の最新コマンドでなければなりません。たとえば、n = 2の場合、送信者は最新のコマンドと最新のコマンドと3番目の最新コマンドではなく、最新のコマンドと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 = 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, a value tool log either 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, a toggle tool log either 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.
損失イベントの後、受信機はChapter 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.
このようにして、レシーバーはコマンドを2回実行せずに、失われたコマンドのみを実行することができます。単一のパケット損失から回復している間、レシーバーはリスト内のs = 1ログをスキップする場合があります。これは、拡張されたコントローラー番号の最初のs = 0ログは常にカウントツールログであるためです。
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 its 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, if both count and value logs appear for the command.
最後に、ロータリーエンコーダーの一部のアプリケーションでは、エンコードを拡張することなく優れたユーザーエクスペリエンスが可能になる可能性があることに注意してください。これらのアプリケーションは、回復後の回転エンコードストリームと比較的低いパケット損失によって駆動されるエンコード位置の視覚的フィードバックによって区別されます。これらのドメインでは、ログリストがコマンドにカウントと値ログの両方が表示される場合、ログリストが最新のコマンドのみをエンコードする場合、回転エンコーダーでは回復パフォーマンスが許容される場合があります。
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 Number (RPN) or Non-Registered Parameter Number (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 Number (RPN) LSB (100) o Registered Parameter Number (RPN) MSB (101)
o データ入力MSB（6）oデータ入力LSB（38）oデータ増分（96）oデータDECREMENT（97）o非登録パラメーター番号（NRPN）LSB（98）o非登録パラメーター番号（NRPN）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.
パラメーターシステムトランザクションの一部であるコントロールチェンジコマンドは、Chapter C Controllerログでコーディングしてはなりません。代わりに、これらのコマンドは、付録A.4で定義されているMIDIパラメーターの章である第M章でコード化されています。
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.
代わりに、コントローラーはChapter C Controllerログでコーディングされています。コントローラーログは、付録A.3.2およびA.3.3に記載されているコーディングルールに従います。付録A.3.1で定義されているペアリングされたLSBおよびMSBコントローラーのコーディングのルールは、第C章でコード化されている場合、ペア（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のアクティブコントロール変更コマンドがチェックポイント履歴に表示され、これらのコマンドが汎用コントローラーとして使用される場合、これらのコントローラー番号の最新の汎用コマンドインスタンスは、エントリのエントリとして表示する必要があります。Chapter 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送信者は、ストリーム内のコマンドの配置に注目することにより、これらのコントローラー番号の各コントロール変更コマンドの役割を推定し、必要に応じてChapter CまたはChapter 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 RPNまたはNRPNパラメーター番号コードを設定するセッション履歴の最新のアクティブ制御変更コマンド（NULLパラメーター（MSB値0x7F、LSB値0x7F）、または
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 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の標準コントローラー割り当てを使用しているため、RTP MIDI送信者は、これらのコントローラーがパラメーターシステムコントローラーとして機能すると仮定する必要があります。目的の方法。
Readers may wish to review the Appendix A.1 definitions for "C-active", "parameter system", "parameter system transaction", and "initiated parameter system transaction" before reading this appendix.
読者は、この付録を読む前に、「C-Active」、「パラメーターシステム」、「パラメーターシステムトランザクション」、および「開始されたパラメーターシステムトランザクション」の付録A.1定義を確認したい場合があります。
Chapter M protects parameter system transactions for Registered Parameter Number (RPN) and Non-Registered Parameter Number (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ビット保留値とそれに関連する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
チャネルジャーナルには、チェックポイント履歴のパラメーターシステムトランザクションに関与する最新のCアクティブ制御変更コマンドが
o an RPN MSB (101) or NRPN MSB (99) controller, or 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 RPN MSB（101）またはNRPN MSB（99）コントローラー、または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.
このルールは、部分的に送信されたパラメーター番号とnullパラメーター番号の損失保護を提供します。
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に設定する必要があります。）章Mヘッダーに従う必要があります。それ以外の場合、Pヘッダービットを0に設定する必要があり、保留中のフィールドとQビットは第M章に表示されてはなりません。
If PENDING codes an NRPN MSB, the Q bit MUST be set to 1. If PENDING codes an RPN MSB, the Q bit MUST be set to 0.
保留中のNRPN MSBをコードする場合、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.
o C-Activeパラメーターシステムトランザクション制御の変更コマンドがセッション履歴に表示されない場合、Eビットは0に設定する必要があります。
o If the P header bit is set to 1, the E bit MUST be set to 0.
o Pヘッダービットが1に設定されている場合、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.1).
リスト内のすべてのパラメーターログで共有されるu、w、およびzヘッダービットコードプロパティ。これらのプロパティが設定されている場合、パラメーターログは効率が向上してコーディングされる場合があります（A.4.1でどのように説明しますか）。
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.
デフォルトでは、u、w、zビットは0に設定する必要があります。リストコードrpnパラメーターのすべてのパラメーターログの場合、uビットは1に設定できます。ビットは1に設定できます。リスト内のすべてのRPNおよびNRPNログのパラメーター番号が0-127の範囲にある場合（したがってMSB値は0です）、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-Activeセマンティクスが前の段落に表示されることに注意してください。
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章では、eヘッダービット（図A.4.1）とログリストの順序付けルールを使用して、nullパラメーターセマンティクスをコーディングします。
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-active」セマンティクスではなく、「c active」セマンティクスではなく）が前の段落に表示されることに注意してください。ただし、以下のルールは、C-Activeセマンティクスを使用します。これは、トランザクションシステム自体の保護に関係しているため、[RP015]は、すべてのコントローラーがリセットして進行中のトランザクションを閉鎖することを指定するためです。
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
ほとんどの場合、CH_NEVERパラメーターに割り当てられたRPNおよびNRPNパラメーターのパラメーターログ（付録C.2.3）は、リストから省略できます。例外が適用されます
o the log codes the most recent initiated transaction in the session history, and
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ヘッダーのEヘッダービット（図A.4.1）は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制御チェンジコマンドを正しく解釈できるようにします。
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 NRPNs) or 101 and 100 (for RPNs).
ログはヘッダーから始まり、そのデフォルトサイズ（図A.4.2に示すように）は3オクテットです。Qヘッダービットが0に設定されている場合、ログはRPNパラメーターをエンコードします。q = 1の場合、logはnrpnパラメーターをエンコードします。7ビットPNUM-MSBおよびPNUM-LSBフィールドは、パラメーター番号をコードし、コントローラー99および98（NRPNSの場合）または101および100（RPNSの場合）のコントロール変更コマンドデータ値を反映しています。
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-2 define the fields associated with each TOC header bit.
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.
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）。この場合、送信者は、j、k、l、m、およびn tocビットを0に設定し、フィールドなしのパラメーターログをコーディングすることを選択できます。
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を参照）。ログの目的は、レシーバーが損失イベントに続く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 Appendices 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 Appendices 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）またはカウント（t）ツールを使用する場合、vとtが設定されることに注意してください。したがって、j = k = l = m = 0の場合でもvは設定され、n = 0であってもtが設定される場合があります。
In many cases, all parameters coded in the log list are of one type (RPN and NRPN), and all parameter numbers lie in the range 0-127. As described in Appendix A.4.1, 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).
多くの場合、ログリストにコード化されたすべてのパラメーターは1つのタイプ（RPNおよびNRPN）であり、すべてのパラメーター番号は0〜127の範囲にあります。付録A.4.1で説明したように、送信者は、トップレベルの章Mヘッダービットzを1（制限範囲をコーディングする）を設定し、uまたはwビットを1に設定する（パラメータータイプをコーディングする）ことにより、この条件に合図する場合があります。。
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のいずれかの場合、パラメーターログリストのすべてのログは変更されたヘッダー形式を使用する必要があります。この変更は、図A.4.2に示されているビットフィールドのビット8-15を削除し、2-OCTETヘッダーを生成します。削除されたPNUM-MSBおよびQフィールドの値は、U、W、およびZビット値から推測される場合があります。
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-エントリー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ビットエントリ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.
エントリ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のアクティブコントロール変更コマンドがチェックポイント履歴に表示される場合、エントリ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-エントリー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ビットエントリ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によってコード化されたコマンドがセッション履歴のコントローラー121（すべてのコントローラーをリセット）の最新の制御変更コマンドに先行する場合、xビットを1に設定する必要があります。それ以外の場合、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.
原則として、Valueツールを使用するパラメーターログには、コントローラー番号38のアクティブコントロール変更コマンドがチェックポイント履歴に表示される場合、エントリLSBフィールドを含める必要があります。ただし、エントリLSBに関連するコントロール変更コマンドの前に、コントローラー番号6（データ入力MSB）のコントロール変更コマンドの前に、エントリ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-Buttonフィールド
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.
14ビットAボタンフィールドは、ログパラメーターのトランザクションに表示されるセッション履歴のコントローラー番号96および97（データ増分とデータの減少）のアクティブコントロール変更コマンドの数のカウントをコードします。
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-Buttonフィールド
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.
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.
A-ButtonとC-Buttonの両方で、コントローラー番号6（データ入力MSB）または38（データ入力LSB）のコントロール変更コマンドに先行する場合、データの増加とデータの減少制御の変更コマンドはカウントされません。セッション履歴のログパラメーター。
The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers, and the G bit associated 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 add or subtract, 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を追加し、各適格なデータDECREMENTコマンドの1を減算します。各追加または減算後、カウントの大きさを16383に制限します。Gビットはカウントの符号をコードし、AボタンまたはCボタンフィールドはカウントの大きさをコードします。
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.
A-Buttonフィールドの場合、最新の適格なデータ増分またはデータDectrent Commandがセッション履歴のコントローラー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ビット）は省略できます。ログ。
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
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.
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（すべてのコントローラーをリセット）の最新のコントロール変更コマンドに先行する場合、カウントフィールドに関連付けられたXビットは1に設定する必要があります。。
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.
トランザクションカウントはModulo 128を実行します。トランザクションカウントはセッションの開始時に0に設定され、リセット状態コマンド（付録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.
カウントツールを使用するパラメーターログには、チェックポイント履歴にトランザクションカウント（Modulo 128）を増加させるアクティブコマンドが表示される場合、カウントフィールドを含める必要があります。
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.
Checkpoint HistoryにCアクティブMIDIピッチホイール（0xE）コマンドが表示される場合、チャンネルジャーナルには第4章が含まれている必要があります。図A.5.1は、第4章の形式を示しています。
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 -Chapter 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.
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).
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.
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.
この付録では、速度がゼロの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.
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ノート（0x9）またはノートオフ（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オクセットのヘッダーで構成されており、その後に次のデータ構造の少なくとも1つが続きます。
o A list of note logs to code NoteOn commands. o A NoteOff bitfield structure to code NoteOff commands.
o コードノートンコマンドへのノートログのリスト。oノートオフビットフィールド構造コードノートオフコマンド。
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に、ノートログセマンティクスとノートオフビットフィールドセマンティクスを定義します。
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.
チェックポイント履歴の1つ以上のnアクティブノートンまたはノートオフコマンドがノート番号を参照する場合、ノート番号はノートログリストまたはノートオフビットフィールド構造のいずれかでコーディングする必要があります。
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.
Note Log Listには、最新のチェックポイント履歴がnアクティブノートソンコマンドにあるすべてのノート番号のエントリを含める必要があります。ノートオフビットフィールド構造には、最新のチェックポイント履歴の外観がnアクティブノートオフコマンドにあるすべてのノート番号に設定されたビットを含める必要があります。
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.
すべてのノートログとノートオフビットフィールドセットビットは、セッション履歴のノート番号への最新のnアクティブノートンまたはノートオフの参照をコーディングする必要があります。
The note log list MUST obey the oldest-first ordering rule (defined in Appendix A.1).
ノートログリストは、最も古い最初の注文ルール（付録A.1で定義）に従う必要があります。
The header for Chapter N, shown in Figure A.6.2, codes the size of the note list and bitfield structures.
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.
7ビットの整数値であるLenフィールドは、メモリストに2オクテットノートログ数をコードします。Zeroは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ビットの低いフィールドとハイフィールドは、ノートログリストに続くオフビットのオクテットの数をコードします。低および高は、署名されていない整数値です。低い場合、この章には（高い - 低い1）オフビットのオクテットがあります。値ペア（低= 15、high = 0）および（low = 15、high = 1）コード空のノートオフビットフィールド構造（つまり、オフビットオクテットなし）。その他の（低>高）値ペアは、ヘッダーに表示されてはなりません。
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ビットは、ノートオフビットフィールド構造のSビット機能（付録A.1）を提供します。デフォルトでは、Bビットを1に設定する必要があります。ただし、前のパケットのMIDIコマンドセクション（パケットI -1、付録A.1で定義されているIを含む）がチャンネルのノートオフコマンド、Bビットが含まれている場合0に設定する必要があります。Bビットが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.
Figure A.6.3 shows the 2-octet note log structure.
図A.6.3は、2-OCTETノートログ構造を示しています。
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ビットノートナムフィールドは、ログのメモ番号をコードします。ノート番号は、メモリストの複数のメモログで表されないでください。
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ビット速度フィールドは、セッション履歴のノート番号の最新のnアクティブノートソンコマンドの速度値をコードします。付録A.7で説明したように、特定のメモ番号の複数のオーバーラップノートは、第E章を使用してコード化できます。
VELOCITY is never zero; NoteOn commands with zero velocity are coded as NoteOff commands in the NoteOff bitfield structure.
速度は決してゼロではありません。速度がゼロのNoteOnコマンドは、NoteOffビットフィールド構造のノートオフコマンドとしてコード化されます。
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.
Note Logは、Noteonコマンドの実行時間をコーディングしません。ただし、Yビットは、Noteonの実行時間について送信者からのヒントをコードします。yビットは、ノートログから回収されたノートンコマンドを再生（y = 1）またはスキップ（y = 0）することを推奨します。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は、章の最後にあるオフビットオクテットのリストとして、ノートオフビットフィールド構造を示しています。ノートオフオフビットオクテットコード8連続MIDIノート番号のノートオフ情報。最も重要なビットが最低のノート番号を表します。最初のオフビットの最も重要なビットOctetは、ノート番号8*lowをコードします。最後のオフビットの最も重要なビットOctetは、Note番号8*Highをコードします。
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.
設定されたビットは、メモ番号のノートオフコマンドをコードします。ノートオフビットフィールド構造の最も効率的なコーディングでは、構造の最初と最後のオクテットには少なくとも1つのセットビットが含まれています。第n章はノートオフ速度データをコードしないことに注意してください。
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.
一般的なケースでは、Recovery Journalは、コントローラー64（Damper Pedal（Sustain））のNoteoffコマンドの相対的な配置とChange Controlコマンドをコーディングしないことに注意してください。多くの場合、損失イベントを処理するレシーバーは、ストリームの履歴からこの相対的な配置を推測する可能性があり、したがって、ペダルによってノートオフメモが維持されているかどうかを判断する場合があります。そのような決定が不可能な場合、ペダルをサイレンシングペダルの側面に誤り、誤って持続したノートが不快な（一時的ではありますが）アーティファクトが生成される可能性があるため、受信機は維持されます。
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のリリース速度値を持つノートオフコマンドと見なされます。
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ノート（0x9）およびNoteoff（0x8）コマンド機能に関する回復情報をエンコードしてください。受信機は、介入ノートオフなしのノート番号にいくつかのメモコマンドが表示されるストリームの一時的なアーティファクトを削減するために章Eを使用します。また、受信機は第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.
この章は、1-OCTETヘッダーで構成され、その後に2-OCTETノートログの可変長リストが続きます。付録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で定義）に従う必要があります。
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ビットノートナムフィールドでコードされた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アクティブノートオフコマンドのリリース速度値をコードします。
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 appear 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ビットカウント/ベルフィールドは、カウントの符号なし整数表現をコードします。カウントが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）が表示されるたびにカウントが0にリセットされ、MIDI制御がコントローラー番号123-127のコマンドを変更するたびに（すべてのメモがオフセマンティクス）または120（すべてが120）セッション履歴に表示されます。
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アクティブノートソンまたはノートオフコマンドが64以外のリリース速度値を持つノートオフコマンドである場合、vビットが1に設定されているノートログは、メモの第1章に表示する必要があります。番号。
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アクティブノートンまたはノートオフコマンドがノートオフコマンドであり、ノート番号の参照カウントが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アクティブノートソンまたはノートオフコマンドがノートソンコマンドであり、ノート番号の参照カウントが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.
せいぜい、2つのノートログには、v bitが0に設定されている1つのログと、vビットが1に設定されている1つのログが表示されます。
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 BITが1に設定されているログは、128ログの制限に達するために第1章からドロップする必要があります。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 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チャネルAfterTouch（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 -Chapter 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-actuchコマンドがアクティビティのメモにリンクされているという仮定でnアクティブな制限を定義します。したがって、nアクティブではないチャネルアフタータッチコマンドは古く、ストリームの修復に使用しないでください。
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).
この章は、1-OCTETヘッダーで構成され、その後に2-OCTETノートログの可変長リストが続きます。ノート番号の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フィールドは、リスト内のメモログの数をマイナスします。図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-章Aノートログ
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ビットノートナムフィールドでコーディングされた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).
原則として、xビットは0に設定する必要があります。ただし、セッション履歴の次のコマンドの1つの前にログによってコード化されたコードが表示される場合は、xビットを1に設定する必要があります。MIDIコントロール変更番号123-127（セマンティクスからすべてのメモを備えた数字）または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にリセットすることを宣言しているため、第5章のCアクチブ制限を定義します（付録A.5の最後の説明を参照してください。完全な根拠）。
B. The Recovery Journal System Chapters
B. Recovery Journal Systemの章
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.
システムジャーナルには、アクティブなMIDIリセット（0xFF）、MIDIチューンリクエスト（0xF6）、MIDI Song Select（0xf3）、未定義のMIDIシステム共通（0xf4および0xf5）、または未定義のMIDIシステムリアルタイム（0xf9および0xf9および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-OCTETヘッダーで構成され、その後に1つ以上のコマンドログが続きます。ヘッダーフラグビットは、リセット（b = 1）、チューンリクエスト（g = 1）、song select（h = 1）、未定義システム共通0xf4（j = 1）、未定義システム共通0xf5（k（k）のコマンドログの存在を示します。= 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-OCTETコマンドログ形式を示しています。
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.
Checkpoint履歴にアクティブリセットコマンドが表示される場合、第D章はリセットコマンドログを含める必要があります。7ビットカウントフィールドは、セッション履歴に存在するリセットコマンドの総数（Modulo 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.
CheckPoint履歴にアクティブなTune Requestコマンドが表示されている場合、第D章はTune Requestコマンドログを含める必要があります。7ビットカウントフィールドは、セッション履歴に存在するチューンリクエストコマンドの総数（Modulo 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.
これらのコマンドでは、カウントフィールドは参照カウントとして機能します。詳細については、付録A.1の「セッション履歴リファレンスカウント」の定義を参照してください。
Figure B.1.3 shows the 1-octet command log format for the Song Select command.
図B.1.3は、Song Selectコマンドの1-OCTETコマンドログ形式を示しています。
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.
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.
Chapter D 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）、値フィールド（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.
ここで、カウント、価値、および法的分野を使用するためのデフォルトのルールを定義します。付録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に設定されている場合、コマンドログにはカウントフィールドを含める必要があります。8ビットカウントフィールドは、セッション履歴に存在するlog（0xf4または0xf5）によってコードされたタイプのコマンドの総数をModulo 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に設定されている場合、コマンドログには値フィールドを含める必要があります。変数長値フィールドは、セッション履歴でログ（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.
法的分野は将来の使用のために予約されています。[MIDI]の更新が0xf4または0xf5コマンドを定義する場合、IETF標準トラックドキュメントが法的分野を定義する場合があります。そのようなドキュメントが表示されるまで、送信者は法的分野を使用してはなりません。レシーバーは長さフィールドを使用して法的分野をスキップする必要があります。新しい0xf4または0xf5コマンドのセマンティクスが、カウントおよび値フィールドを使用してパケット損失から保護できなかった場合、法的分野は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.
Chapter D 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.
ここで、カウントおよび法律分野を使用するためのデフォルトのルールを定義します。付録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。デフォルトでは、コマンドログにカウントフィールドが存在する必要があります。
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 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.
法的分野は将来の使用のために予約されています。[MIDI]の更新が0xF9または0xFDコマンドを定義する場合、IETF標準トラックドキュメントは、コマンドを保護するために法的分野を定義する場合があります。そのようなドキュメントが表示されるまで、送信者は法的分野を使用してはなりません。レシーバーは長さフィールドを使用して法的分野をスキップする必要があります。新しい0xf9または0xfdコマンドのセマンティクスがカウントフィールドを使用してパケット損失から保護できなかった場合、法的分野は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シーケンサーシステムの回復力ツールについて説明します。
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 Active Sense（0xfe）コマンドがチェックポイント履歴に表示される場合は、第5章を含める必要があります。図B.2.1は、第5章の形式を示しています。
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ビットカウントフィールドは、セッション履歴に存在するアクティブセンスコマンドの総数（Modulo 128）をコードします。カウントフィールドは参照カウントとして機能します。詳細については、付録A.1の「セッション履歴リファレンスカウント」の定義を参照してください。
This appendix describes Chapter Q, the system chapter for the MIDI sequencer commands.
この付録では、MIDIシーケンサーコマンドのシステム章である章Qについて説明します。
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.
システムジャーナルには、アクティブなMIDIソングポジションポインター（0xF2）、MIDIクロック（0xF8）、MIDIスタート（0xFA）、MIDI続行（0xFB）、またはMIDI STOP（0xFC）コマンドがチェックポイント履歴に表示される場合、第Qを含む必要があります。この付録で定義されているルールが、コマンドの外観のために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ビットの時刻表フィールド（t = 1）の存在を信号します。3ビットのトップヘッダーフィールドは、時計や時刻と同様に、署名されていない整数として解釈されます。付録B.3.1のタイムトールフィールドについて説明します。
Chapter Q encodes the most recent state of the sequencer system. Receivers use the chapter to re-synchronize 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.
第章では、シーケンサーシステムの最新の状態をエンコードします。受信者は、パケット損失エピソードの後にシーケンサーを再同期させるためにこの章を使用します。Chapter Fieldsは、シーケンサーのオン/オフ状態、曲の現在の位置、およびダウンビートをエンコードします。
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ビットを1に設定する必要があります。アクティブストップが最近表示された場合、またはアクティブスタートがない場合、またはセッション履歴に停止するか、続行コマンドが表示される必要があります。0に設定します。
The C header flag, the TOP header field, and the CLOCK field act to code the current position in the sequence:
Cヘッダーフラグ、トップヘッダーフィールド、およびクロックフィールドは、シーケンスの現在の位置をコーディングするために行動します。
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ビットのトップヘッダーフィールドと16ビットクロックフィールドを組み合わせて、19ビットの符号なし数量65536*トップクロックを形成します。この値は、MIDIクロックの単位（四半期ごとに24クロック）、Modulo 524288の単位で曲の位置をエンコードします。SongPosition Pointerコマンドによってコード化される可能性のある曲の位置値は98303クロック（17ビットでコーディングされる場合があることに注意してください。）、そしてその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.
n = 0とn = 1の条件の両方で、C、TOP、およびCLOCKフィールドを現在の曲の位置をコーディングするように設定する必要があります。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、トップ、およびクロックフィールドによってコーディングされた曲の位置を修飾するように動作します。
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 = 1）または次の（続行、clock）ペア（n = 0）が動作し、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 = 1）または次の（継続、clock）ペア（n = 0）は、曲の位置でコーディングされた曲のポイントを再生するように動作します。曲の位置は増加しません。
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の場合の例を構築することもできます。stopコマンドの後に停止コマンドが続くと、q = 0、d = 0、n = 0、top = 0を設定することにより、qで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コマンドは、セッション履歴のContinueコマンドよりも最近発生し、C = 1、TOP = 0、CLOCK = 0 Song Positionエンコードを使用する必要があります。
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ヘッダービットを0に設定する必要があります。付録C.2.3で説明するセッション構成ツールを使用して、Timetoolsコーディングを選択できます。
Figure B.3.2 shows the format of the 24-bit TIMETOOLS field.
図b.3.2は、24ビットの時刻表フィールドの形式を示しています。
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ビットの署名のない整数量です。時間コードは、上部、時計、Cフィールドによってコードされた曲の位置の添加剤補正項をコードします。時間はネットワークバイトの順序でコーディングされます（Big-Endian）。
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クロックの単位に変換し、65536*のトップクロック（C = 1を仮定）に追加することにより、正しい曲の位置を計算します。あるいは、レシーバーは65536*トップクロックをミリ秒（C = 1を仮定）に変換し、時間に追加することができます。付録B. 3で定義されているダウンビート（Dヘッダービット）セマンティクスは、修正された曲の位置に適用されます。
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.
この付録では、MIDI Timeコード（MTC）コマンドのシステム章であるChapter Fについて説明します。読者は、この付録を読む前に、「完成/未完成のコマンド」の付録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）またはアクティブな完成システム排他的（ユニバーサルリアルタイム）MTCフルフレームコマンド（F0 7F CC 01 01 HR MN SC FR F7）がチェックポイントの履歴に表示される場合、第F章Fを含める必要があります。それ以外の場合、System Journalには章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 re-synchronize the MTC system after a packet loss episode.
第F章では、セッション履歴でコード化された最近のMTCテープポジションに関する情報を保持しています。受信者は、パケット損失エピソードの後、章Fを使用してMTCシステムを再同期します。
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).
第1章は、図b.4.1に示す順序で、1オクセットのヘッダーといくつかのオプションのフィールドが続きます。CおよびPヘッダービットは、目次（TOC）を形成し、32ビット完全フィールド（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.
Qヘッダービットは、完全なフィールド形式に関する情報をコードします。Chapter Fに完全なフィールドが含まれていない場合、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は、ポイントフィールドが部分フィールドの内容に関する情報をどのようにコードするかを定義しています。章Fに部分的なフィールドが含まれていない場合、ポイントは7（d = 0の場合）または0（d = 1の場合）に設定する必要があります。
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.
Chapter Fは、チェックポイント履歴にアクティブな完成したフルフレームコマンドが表示される場合、またはフレーム値のエンコードを完了するアクティブなクォーターフレームコマンドがチェックポイント履歴に表示される場合、完全なフィールドを含める必要があります。
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.
完全なフィールドは、セッション履歴に表示される最新のアクティブな完全なMTCフレーム値をエンコードします。このフレーム値は、一連の8つのアクティブクォーターフレームコマンド（フォワードテープの動きの場合は0xf1 0x0n〜0xf1 0x7n、逆テープの動きのために0xf1 0x7n〜0x0n 0x0n）の形を取得するか、アクティブな完成したフルフレームコマンドの形をとることがあります。
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].
完全なフィールドがクォーターフレームコマンドシリーズをエンコードする場合、Qヘッダービットを1に設定する必要があり、完全なフィールドには図B.4.2に示す形式が必要です。4ビットフィールドMT0からMT7コードは、メッセージタイプ0の四半期フレームコマンドのデータ（低い）をメッセージタイプ7 [MIDI]からコードします。これらのニブルは、[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-完全なフィールド形式、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.
この使用法では、完全なフィールドでエンコードされたフレーム値は、フレーム値が0xf1 0x0nから0xf1 0x7nコマンドシーケンスをコードする場合、2フレーム（四半期フレームコマンドでエンコードされたフレーム値に対して）でオフセットする必要があります。このオフセットは、フォワードテープの動きのためにエンコードする四半期フレームの2フレームのレイテンシを補正します。フレーム値が0xf1 0x7nから0xf1 0x0n四半期フレームコマンドシーケンスをコードする場合、オフセットは適用されません。
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 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に設定する必要があり、完全なフィールドには図B.4.3に示す形式が必要です。HR、MN、SC、およびFRフィールドは、フルフレームコマンドのHR、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-完全なフィールド形式、Q = 0
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未満の中間メッセージタイプに連続的に増分するか、メッセージタイプ7で開始し、0を超える中間メッセージタイプに連続的に減少する必要があります。このパターンに従わないコマンドシーケンスは、部分的なフレーム値に関連付けられていません。
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.
第fは、MTCフレーム値データをエンコードするチェックポイント履歴の最新のアクティブコマンドが、部分フレーム値に関連付けられたクォーターフレームコマンドである場合、部分フィールドを含める必要があります。それ以外の場合、第F章には部分的なフィールドを含めてはなりません。
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.
部分的なフレーム値は、四半期のフレームコマンドシーケンスのデータ（低い）ニブルで構成されています。部分フィールドは、図B.4.2に示す形式を使用して、部分フレーム値をコードします。クォーターフレームコマンドに関連付けられていないメッセージタイプフィールドは、0に設定する必要があります。
The POINT header field indicates the Message Type fields in the PARTIAL field 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.
ポイントヘッダーフィールドは、部分フィールドコード有効なデータのメッセージタイプフィールドを示します。p = 1の場合、ポイントフィールドは、セッション履歴における最新のアクティブクォーターフレームコマンドのデータ値の上部ニブルの下部3ビットによって形成された符号なし整数値をエンコードする必要があります。d = 0およびp = 1の場合、ポイントは0〜6の範囲の値を取る必要があります。d = 1およびp = 1の場合、ポイントは範囲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の場合、包括的範囲のMTフィールド（図B.4.2）は、ポイント値を含む0から部分的なフレーム値をエンコードします。d = 1の場合、包括的範囲のMTフィールドは7からポイント値を含めて部分的なフレーム値をエンコードします。完全なフィールドエンコーディングとは異なり、送信者は部分的にエンコードされた部分的なフレーム値に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 = 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.
デフォルトのセマンティクスの場合、回復ジャーナルに第fが含まれている場合、セッション履歴が四半期フレームとフルフレームコマンドのリーガル[MIDI]シリーズをコードする場合、章には常に完全または部分フィールドが含まれています（および両方のフィールドが含まれる場合があります）。したがって、1オクテットの章F（c = p = 0）は、セッション履歴に違法コマンドシーケンスの存在を常にコードします（ある条件下では、c = 1、p = 0条件も違法な存在をコーディングする場合があります。コマンドシーケンス）。違法なコマンドシーケンス条件は本質的に一時的であり、通常、4分の1のフレームコマンドシーケンスが中間メッセージタイプで始まったことを示しています。
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.
この付録では、MIDI System Exclusive（Sysex）コマンド（0xF0）のシステム章である第X章について説明します。読者は、この付録を読む前に、「完成/未完成のコマンド」の付録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章は、1つ以上のコマンドログのリストで構成されています。リストの各ログは、セッション履歴に表示される特定の完成または未完成の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'thリストログの長さを考えると、（n 1） 'thリストログの存在は、システムジャーナルヘッダーの長さフィールドから推測できます（メインテキストのセクション5の図10）。ログリストは、最も古い最初の注文ルールに従う必要があります（付録A.1で定義）。
Figure B.5.1 shows the bitfield format for the Chapter X command log.
図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コマンドログは、1オクテットヘッダーで構成され、その後、オプションのTCount、Count、First、およびData Fieldsが続きます。
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-OCTET TCountフィールドがログに表示されます。Cが1に設定されている場合、1-OCTETカウントフィールドがログに表示されます。fが1に設定されている場合、ログに可変長さの最初のフィールドが表示されます。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 F7" construction, and an STA value of 3 codes all other finished commands. Section 3.2 in the main text describes cancelled and "dropped F7" commands.
STAフィールドは、ログによってコードされたコマンドのステータスをコーディングします。2ビットSTA値は、署名されていない整数として解釈されます。STAが0の場合、ログは未完成のコマンドをコードします。ゼロ以外のSTA値は、完成したコマンドの異なるクラスをコードします。1のSTA値は、キャンセルされたコマンドをコードし、2のSTA値は「dropped f7」構造を使用するコマンドをコードし、他のすべての完成コードコード3のSTA値。メインテキストのセクション3.2では、キャンセルされた「F7のドロップ」コマンドについて説明しています。
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ビットはログ自体を指します。最初のログに関連付けられた「ファントム」ビットの値は、次のルールで定義されます。
o If the list codes one log, the phantom S-bit value is the same as the Chapter X S-bit value.
o リストが1つのログをコードする場合、Phantom S-bit値は章x s-bit値と同じです。
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ビット値は、リスト内の最初と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.
One-Octet FIRST value:
One-Octetの最初の値：
Encoded form: 0ddddddd Decoded form: 00000000 00000000 00000000 0ddddddd
エンコードフォーム：0DDDDDDDデコードフォーム：00000000000000000000000DDDDDDD
Two-Octet FIRST value:
2オクテットの最初の値：
Encoded form: 1ccccccc 0ddddddd Decoded form: 00000000 00000000 00cccccc cddddddd
エンコードフォーム：1CCCCCC 0DDDDDDDデコードフォーム：000000000000000000CCCCCCDDDDDDD
Three-Octet FIRST value:
3オクテットの最初の値：
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 00000000 000bbbbb bbcccccc cddddddd
エンコードフォーム：1bbbbbbbb 1ccccccc 0dddddddd decoded form：00000000 000bbbbb bbcccccccddddddd
Four-Octet FIRST value:
4-OCTETの最初の値：
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
エンコードフォーム：1AAAAAAAA 1BBBBBBBB 1CCCCCC 0DDDDDDDデコードフォーム：0000AAAA AAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
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の場合は存在）は、ログによってコードされたsysexコマンドのデータオクテットの変更されたバージョンをエンコードします。ステータスオクテットは、データフィールドでコーディングしてはなりません。
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月（最初）1） 'sysexコマンドのデータオクテットから始まり、セッション履歴に表示されるコマンドの後続のすべてのデータオクテットを含めます。上記の説明の「コマンド」という単語は、特定のMIDIリストSysexコマンドセグメントではなく、Source 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.
データフィールドの長さは、各オクテットの最も重要なビットを使用して、暗黙的にコード化されます。データフィールドの最終オクテットの最も重要なビットは、1に設定する必要があります。他のすべてのデータオクテットの最も重要なビットは0に設定する必要があります。MIDIデータOctetは定義上0です。この長さコーディングの変更とは別に、データフィールドは、エンコードするすべてのデータオクテットの逐語的なコピーをエンコードします。
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つのツールを提供しています。「Remency」ツールと「リスト」ツールです。ツール定義では、コマンドの「システムタイプ」の概念を使用しています。これを定義しています。
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".
MTCフルフレームコマンドを除くセッション内の各sysexコマンドインスタンスには、「システムタイプ」があると言われています。タイプは平等比較で使用されます。セッションの2つのシステムコマンドは、「同じシステムタイプ」または「異なるシステムタイプ」を持っていると言われています。
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コマンドインスタンスの特定のセットが同じシステムタイプを持っていることを宣言しています。例外でカバーされていないコマンドは、単純なルールに従います。以下に例外をリストします。
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.
o 同じコマンドの2つのインスタンスが、同じ「パラメーター」の値を設定または報告している場合、同じタイプを持っています。この例外の実装には、Sysexコマンドの形式とセマンティクスに関する特定の知識が必要です。実際には、送信者の実装は、特定のクラスのコマンド（[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.
この「Sysex Type」のこの定義を使用して、Xの「Remency」ツールと「リスト」ツールを定義します。
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章のログリストは、チェックポイント履歴に表示されるすべての完成または未完成のアクティブなシステムコマンドの損失によって引き起こされる無期限のアーティファクトからレンダリングされたMIDIパフォーマンスを保護するのに十分な情報をコーディングする必要があります（完成したMTCフルフレームコマンドを除く。第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.
Remencyツールを使用して特定の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.
原則として、リストまたはRemencyツールで必要なログには、ログに関連付けられたSysexコマンドインスタンスのチェックポイント履歴に表示されるすべてのデータオクテットをコードするデータフィールドを含める必要があります。最初のフィールドは、この要件を最小限に抑えるデータフィールドを構成するために使用できます。
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で定義）。キャンセルされたコマンドに関連付けられた必要なコマンドログは、データフィールドなしでコーディングされる場合があります。ただし、データがログに表示される場合、データはログに関連付けられたコマンドのチェックポイント履歴に表示されるすべてのデータオクテットをコーディングする必要があります。
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.
このセクションの前のテキストで定義されているように、デフォルトでは、チェックポイント履歴に表示されるすべての完成または未完成のアクティブなSysexコマンド（完成したMTCフルフレームコマンドを除く）は、リストツールまたはRemencyツールによって保護する必要があります。
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が得られます。たとえば、SysexコマンドセグメントをMIDIソースによって配信するとすぐにSysexコマンドセグメントを送信することにより、送信者が10,000データオクテットを備えたSysexコマンドを「オンザフライ」に「udp On The Fly」にトランスコードし始めると想像してください。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.
この状況では、送信者がSysexコマンドの閉ループ送信ポリシーを使用している場合、RTPパケットサイズは常にストリームを失速させることでキャップされる場合があります。ストリームストールでは、パケットが最大サイズに達すると、送信者は、レシーバーフィードバックが第X章のトリミングを許可するまで、空でないMIDIコマンドセクションの新しいパケットの送信を控えます。付録C.1）で定義されているツールを使用した構成中、送信者はSysexセグメントストリームを失速させることができますが、MIDIリストの他のコマンドをコーディングし続けます。
Stalls are a workable but sub-optimal 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名スペースを送信するためのツールを提供しています。送信者は、これらのツールを使用して、MIDIソースを低遅延のUDP RTPストリーム（チャネルコマンドと短いSysexコマンドの場合）および信頼できる[RFC4571] TCPストリーム（バルクDATAシステムコマンド用）にマッピングできます。CM_UNUSEDおよびCM_USEDパラメーター（付録C.1）を使用して、Sysexコマンドパーティションの性質を通知することができます。TCPが信頼できるため、RTP MIDI TCPストリームはRecovery Journalを使用しません。短いSysexコマンドの伝送遅延を最小限に抑えるために、送信者はUDPストリーム上のすべてのSysexコマンドのセグメント伝送を開始し、長いコマンドのUDP送信（セクション3.2で説明したツールを使用）をキャンセルし、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 選択的保護。ストリーム内のすべてのSysexコマンドにジャーナル保護は必要ない場合があります。CH_NEVERパラメーター（付録C.2）を使用して、どのSYSEXコマンドが第X章から除外されているかを通知できます。
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フィールドは、ログによってコード化された（完成または未完成）コマンドの後、セッション履歴に表示されるログによってコードされるサイセックスタイプのsysexコマンドの総数をコードします。
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フィールドは、セッション履歴に表示されるSysexコマンドの総数をコードします。これは、CH_NEVERパラメーター（付録C.2）を介して第X章から除外されたコマンドを除外します。ログはセッション履歴に入ります。
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のコマンドカウントは、modulo-256算術を使用します。MTCフルフレームコマンドインスタンス（付録B.4）は、Canceledコマンド（セクション3.2）と同様に、TCountとカウントの定義が包含を必要とする場合、コマンドカウントに含まれています。
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.
送信者は、TCountとカウントフィールドを使用してアイデンティティを追跡し、（TCountの場合）コマンドインスタンスのシーケンス位置を追跡します。ログによってコード化されたコマンドタイプを保護するためにIDまたはシーケンス情報が必要な場合、送信者はTCountまたはカウントフィールドを使用する必要があります。
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.
送信者がセッションでカウントフィールドを使用する場合、ストリーム内のすべての章xの最終コマンドログは、カウントフィールドをコーディングする必要があります。このルールにより、受信機はパケット損失後にカウント値を再同期させることができます。
C. Session Configuration Tools
C.セッション構成ツール
In Sections 6.1-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-2では、最小限のネイティブおよびMPEG4-GENERIC 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_Sec、J_Update）について説明しています。
o Appendix C.3 describes MIDI command timestamp semantics (linerate, mperiod, octpos, tsmode).
o 付録C.3では、MIDIコマンドタイムスタンプセマンティクス（Linate、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、Inline、Multimode、Render、Rinit、Subrender、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ストリームに追加機能（「機能」）を追加します。付録C.7では、これらの機能を使用して、RTSP（付録C.7.1）を使用したコンテンツストリーミングとSIP（付録C.7.2）を使用したネットワークミュージカルパフォーマンスの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ストリーム（すべての当事者が送信および受信）を使用することが困難になります。たとえば、2パーティのネットワークミュージカルパフォーマンスアプリケーションは、各ホストのレンダラーをカスタマイズして、ホストのCPUパフォーマンス[NMP]に合わせてカスタマイズする場合があります。
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.
1つのSendRecvストリームの代わりに、2つのRTP MIDIストリーム（1つのSendonly、1つのRecvonly）を使用することにより、この問題を解決します。2つのストリームのデータフローは、異なるレンダラーを使用するように構成された受信機を制御するために反対方向に移動します。付録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プロトコルはセッション中にパラメーターの変更を順調に処理しません。これは、セッションが開始された後に簡単に変更されないヘビー級またはステートフルな構成を記述しているためです。したがって、当事者は、セッション中のパラメーターの変更要求が他の当事者によって受け入れられることを期待すべきではありません。ただし、実装者は、処理が容易なセッション内パラメーターの変更をサポートする必要があります（たとえば、付録C.4で定義されているGuardTimeパラメーター）、セッション管理プロトコル（そのパラメーターの変更に対するリクエストを受け入れることができます（セッション管理プロトコル）（たとえば、SIP [RFC3264]）の再勤務者。
Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC4234]) 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、[RFC4234]）を定義しています。セクション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は、MPEG4-Genericレンダラーを初期化するための保存されたオブジェクトであるメディアタイプ「Audio/ASC」を定義しています。付録C.6で説明したように、オーディオ/ASCメディアタイプは「RINIT」パラメーターに割り当てられ、デフォルトのMPEG4-Generic Rendererの初期化データオブジェクトを指定します。RTPストリームセマンティクスは、「Audio/ASC」で定義されていないことに注意してください。したがって、「ASC」サブタイプは、セッションの説明のRTPMAP行に表示されてはなりません。
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コマンドを除外することにより、このデフォルトの条件を変更する2つのパラメーター（CM_UNUSEDおよびCM_USED）を定義します。たとえば、マルチメディアセッションでMIDI名スペースを2つのRTP 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.
Stream Subsetting Systemを初期化するには、パラメーターリストに表示される実際の割り当てを処理する前に、CM_UNUSEDおよびCM_USEDへの「暗黙の」割り当てが処理されます。システム共通の未定義のコマンド（0xf4、0xf5）とシステムのリアルタイムの未定義コマンド（0xf9、0xfd）は、暗黙的にCM_Unuseに割り当てられます。他のすべてのコマンドタイプは、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）の割り当ては、メインテキストのセクション3.2で定義されているSysexセグメントでの0xf4および0xf5の特別な使用ではなく、MIDIソースコマンドストリームのこれらのコマンドの使用に適用されることに注意してください。
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コマンドタイプを指定します。コマンドタイプリストは、1つ以上の文字の連結シーケンス（abcfghjkmnpqtvwxyz）です。文字は次のコマンドタイプをコードします。
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, 0xF9, 0xFA, 0xFB, 0xFC) o T: Channel Aftertouch (0xD) o V: System Active Sense (0xFE) o W: Pitch Wheel (0xE) o X: SysEx (0xF0) o Y: System Real-Time Undefined (0xF9) o Z: System Real-Time Undefined (0xFD)
o
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.
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が割り当てられている場合、標準コントローラーの割り当てのコントローラー番号のコントロール変更（0xB）コマンドがMIDIリストにまだ表示される可能性があることに注意してください。説明については、パラメーターシステムコントローラー番号の「汎用」使用に関する議論については、付録A.3.4を参照してください。
In the text below, rules that apply to "MIDI voice channel commands" also apply to the letter M.
以下のテキストでは、「MIDI Voice Channel Commands」に適用されるルールも文字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 Voiceチャネルコマンドの場合、チャネルリストは、パラメーターが適用される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、q、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 sysexがサブリストを「キャンセル」する桁0（メインテキストのセクション3.2）が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
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).
o
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を含めてはなりません。また、桁2と3の両方の数字を含めてはなりません。コマンドタイプXの場合、上記の数字以外のチャネルリスト番号は無視されます。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 Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the parameter applies. The number range 0-16383 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 corresponds to NRPN 16383).
コマンドタイプM（パラメーターシステム）の場合、フィールドリストは、登録されたパラメーター番号（RPN）とパラメーターが適用される非登録パラメーター番号（NRPN）をコーディングします。数範囲0-16383はRPNSを指定し、数範囲16384-32767はNRPNSを指定します（16384はNRPN 0、32767に対応してNRPN 16383に対応）。
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（poly aftertouch）の場合、フィールドリストはパラメーターが適用されるノート番号をコーディングします。
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（システム共通の未定義）の場合、フィールドリストは1桁で構成されており、コマンドオクテットに続くデータオクテットの数を指定します。
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（sysex）の場合、フィールドリストは、sysexコマンドに表示される可能性のあるデータオクテットの数をコードします。したがって、フィールドリスト0-255は255以下のデータオクテットを持つSysexコマンドを指定します。フィールドリスト256-4294967295は255を超えるデータオクテットを持つSysexコマンドを指定しますが、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>] "__"
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コマンドのクラスを定義します。コマンドクラスは、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>は、コマンドのデータオクテットを定義し、ドット分離された（ "。"）1つ以上の16進定数（「7f」など）またはダッシュ分離された16進範囲（ "01-など）のリストとして定義します。1f "）。アンダースコア（ "_"）各<hlist>を分離します。Double-UnderScores（ "__"）は、データOctetリストを描写します。
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.
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:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-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 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).
セッションの説明は、クロックアプリケーションで使用するためのストリームを構成します。すべての音声チャネルは、MIDIタイムコード（コマンドタイプf、およびCM_USEDに割り当てられた文字列によって一致するフルフレームSysexコマンド）に使用されるものを除くすべてのシステムコマンドと同様に、すべて使用されていません。）、およびシステムリセット（コマンドタイプB）。
In this appendix, we define the payload format parameters that configure stream journalling and the recovery journal system.
この付録では、Stream Journallingと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_SECパラメーター（付録C.2.1）は、ストリームのジャーナリング方法を設定します。j_updateパラメーター（付録C.2.2）は、ストリームのリカバリジャーナル送信ポリシーを設定します。付録C.2.2は、Recovery Journal Systemの送信ポリシーも定義しています。
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-B.
付録C.2.3は、Recovery Journalセマンティクスを変更するいくつかのパラメーターを定義しています。これらのパラメーターは、セクション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_SECパラメーターの変更を禁止します。
A related requirement, defined in the appendix sections 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.
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など）を使用するストリームは、Recovery Journalを使用することにデフォルトです。信頼できる輸送（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.
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_SECパラメーターは、信頼できるデータグラム配信を提供することが知られているローカルネットワーク上の2つのホスト間を移動するUDPストリームの「なし」に設定される場合があります。
The session description below configures a UDP stream that does not use the recovery journal:
以下のセッションの説明は、Recovery Journalを使用しないUDPストリームを構成します。
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
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_SECパラメーターの新しいシンボリック値を定義して、形式の使用を通知する必要があります。
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.
当事者は、Recovery Journal Mandateに違反するJ_SEC値を受け入れてはなりません（詳細については、セクション4を参照）。セッションの説明が受信者に不明なJ_SEC値を使用する場合、受信者は説明を受け入れてはなりません。
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).
セッションがセッション管理ツール（RTSP、[RFC2326]など）が「宣言的な使用」目的に使用するセッション管理ツール（RTSP、[RFC2326]など）が管理すると、特別なJ_SECの問題が発生します（詳細については、セクション6の前文を参照）。これらのセッション管理ツールの場合、SDPはセッションの輸送の詳細（UDPやTCPなど）をコーディングしません。代わりに、サーバーとクライアントは、他の手段（RTSP、セットアップ方法の場合）を介してトランスポートの詳細を交渉します。
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_SECパラメーターの使用は賢明ではない場合があります。この場合、セッションの説明は、付録C.2の残りの部分で定義されたパラメーターを使用してジャーナリングシステムを構成する必要がありますが、J_SECを使用してジャーナリングステータスを設定する必要はありません。J_SECがセッションの説明に表示されない場合、ジャーナリング方法を選択するためのデフォルトの方法が有効であることを思い出してください（信頼できる輸送のためのジャーナル、信頼できない輸送のためのRecovery Journal）。
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_SECパラメーターを使用する必要があります。
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 sub-sections 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_updateパラメーターを使用して、このデフォルトをオーバーライドできます。
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 session descriptions that use the j_update parameter.
j_updateの3つのシンボリック値「アンカー」を定義して、ストリームがアンカー送信ポリシー「オープンループ」を使用して、ストリームがオープンループ送信ポリシーを使用し、「閉ループ」を使用することを示して、ストリームが閉ループ送信ポリシーを使用していることを示します。j_updateパラメーターを使用する例のセッションの説明については、付録C.2.3を参照してください。
Parties MUST NOT accept a j_update value that violates the recovery journal mandate (Section 4).
当事者は、Recovery Journal Mandate（セクション4）に違反するJ_UPDATE値を受け入れてはなりません。
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標準トラックドキュメントは、Recovery Journalシステムの追加の送信ポリシーを定義する場合があります。これらのドキュメントは、j_updateパラメーターの新しいシンボリック値を定義して、新しいポリシーの使用を通知する必要があります。セッションの説明が受信者に不明なj_update値を使用する場合、受信者は説明を受け入れてはなりません。
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.
アンカーポリシーでは、送信者はストリーム内の最初のパケットを、ストリーム内のすべてのパケットのチェックポイントパケットとして使用します。アンカーポリシーは、チェックポイントの履歴が常にストリーム全体をカバーするため、Recovery Journal Mandate（セクション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]）または受信者から送信者へのその他のフィードバックの使用は必要ありません。リカバリージャーナルは常にストリームの歴史全体をカバーしているため、送信者は、受信したストリームがアーティファクトから自由に始まることを保証するために特別なアクションをとる必要はありません。チェックポイントパケットが変更されないため、受信機はチェックポイントパケットの変化するアイデンティティを追跡する責任から解放されます。
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を参照）。密集したストリームの場合、閉ループまたはオープンループポリシーがより適切かもしれません。
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.
閉ループポリシーは、Recovery Journalシステムのデフォルトポリシーです。ストリーム内の各パケットについて、ポリシーにより、送信者は、Recovery Journalのマンデートを満たす可能性のある最小のチェックポイント履歴を選択できます。チェックポイントの履歴が小さいため、一般に小規模な回復ジャーナルが得られるため、閉ループポリシーは、アンカーポリシーと比較して、ストリームの帯域幅を減らします。
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 closed loop sending policy, unless another feedback mechanism has been agreed upon.
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 occur.
セクション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パケットを準備しているため、送信者はストリームのR> = 0レシーバーを認識しています。送信者は、受信機から送信者に送信されたペアのストリームからの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から少なくとも1つのフィードバックレポートを受け取った場合、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(), 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、1 <= k <= r、ここでm（k）> =（n -1）を拡張シーケンス番号nを持つチェックポイントパケットを選択する必要があります。ここで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レポートを受信するまで、Recovery Journal Chapter 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 of 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 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.
この問題に対処するために、クローズドループポリシーは、受信者が送信者が受信機を認識していないストリームにアクセスできるセッションに参加している場合、レシーバーはそのレンダリングされたMIDIパフォーマンスが保証しないようにアクションを実行する必要があると述べています。無期限のアーティファクトが含まれています。これらの保護は必然的に不完全になります。たとえば、レシーバーは、MIDIノートオフコマンドの紛失によるスタックノートの取り扱いに関して、覆われていない損失イベントのためにチェックポイントパケットSeqnumを監視し、「注意の側面に誤り」Recovery Journalのチャネルボリューム初期化データ。
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 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 concern 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.
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.
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 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).
ある時点で、送信者は、ストリームの帯域幅を制限するために行動を起こす必要がある場合があります。このポイントに到達するずっと前に、RTP MIDIのほとんどの想定された使用で、[RFC3550]で定義されているSSRCタイムアウトメカニズムは、セッションから非協力レシーバーを削除します（クローズドループポリシーは特別な送信者を提案または要求しないことに注意してください。このセクションで前述したRに関連する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タイムアウトを早期に呼び出す必要があると述べています。
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.
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）フィードバックを使用して各チェックポイントパケットを選択します。受信者がSSRCのタイムアウトを排除する追加情報を持っていない場合（RTCPレポートなどのRTCPレポートなど、RTPストリームに関するRTCPレシーバーレポートなど、受信機が送信者にマルチリキャストしている）。タイムアウト。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. 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.
最後に、閉ループポリシーは、マルチキャストトランスポートを使用するRTP/RTCPセッションでの使用に適していることに注意してください。ただし、閉ループポリシーの側面は、多数の参加者とのセッションに適していません。送信者は、各受信機kのIDとM（k）の値を追跡する必要があるため、受信機の数と直線的にスケーリングします。RTCPレポート間隔のバックオフがm（k）値の完全な更新の割合を遅くするため、平均回復ジャーナルサイズは受信機の数とは無関係ではありません。バックオフアルゴリズムは、セクション4で定義されている規範的送信者および受信者行動の実装によって使用される補助状態の量を増やす可能性もあります。
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.
たとえば、発見された損失イベントの後、レシーバーは、すべてのアクティブなノートンコマンドのノートオフコマンドを実行することにより、損失イベント中に発生した可能性のあるノートオフ（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.
オープンループポリシーでは、セッション説明の作成者は、CH_ANCHORパラメーター（付録C.2.3で定義されている）を使用して、無期限のアーティファクトから回復不可能なMIDIコマンドタイプを保護するか、CM_UNUSEDパラメーターを使用する必要があります（付録Cで定義する必要があります。1）ストリームからコマンドタイプを除外する。これらのオプションは、発見された損失イベント中にアーティファクトからコマンドタイプを保護するように機能します。
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.
オープンループポリシーは、送信者に特定の制約を課しません。ただし、ネットワークの遅延と損失の特性を考慮して、発信者がチェックポイント履歴のサイズを管理して、明らかに損失がまれに発生することを保証する場合、オープンループポリシーは最適に機能します。また、各チェックポイントパケットの変更が発見されていない損失のリスクが発生するため、送信者はジャーナルのサイズを縮小する場合にのみチェックポイントを移動する必要があります。
The recovery journal chapter definitions (Appendices A-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.
Recovery Journalの章の定義（付録A-B）は、Recovery Journalに章が表示されなければならない条件下で指定します。ほとんどの場合、定義では、チェックポイント履歴に特定のコマンドが表示された場合、特定の章タイプが復旧ジャーナルに表示されてコマンドを保護する必要があると述べています。
In this section, we describe the chapter inclusion parameters. These parameters modify the conditions under which a chapter appears 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.
当事者は、Recovery Journal Mandate（セクション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 (Appendix A.4.1-2 defines 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.
o ch_never。CH_NEVERパラメーターに割り当てられた章は、Recovery Journalに表示されてはなりません（付録A.4.1-2は、第M章のこの規則の例外を定義しています）。ジャーナルからの章の除外を通知するために、章によってコード化されたコマンドがCM_UNUSEDに割り当てられていても、CH_NEVERへの割り当てを行う必要があります。このルールは、いくつかの章でコーディングされる可能性のあるコマンドタイプの処理を簡素化します。
o ch_default. A chapter assigned to the ch_default parameter MUST follow the default semantics for the chapter, as defined in Appendices A-B.
o ch_default。CH_DEFAULTパラメーターに割り当てられた章は、付録A-Bで定義されているように、章のデフォルトのセマンティクスに従う必要があります。
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.
o ch_anchor。CH_ANCHORに割り当てられた章は、デフォルトの章のセマンティクスの変更されたバージョンに従う必要があります。変更されたセマンティクスでは、チェックポイント履歴へのすべての参照はセッション履歴への参照に置き換えられ、チェックポイントパケットへのすべての参照は、ストリームで送信された最初のパケットへの参照に置き換えられます。
Parameter assignments obey the following syntax (see Appendix D for ABNF):
<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 sub-chapter types (BGHJKYZ) of System Chapter D.
章リストには、パラメーターが適用されるチャネルまたはシステムの章を指定します。章リストは、章の種類（ACDEFMNPQTVWX）に対応する1つ以上の文字の連結シーケンスです。さらに、リストには、システム第D章のサブチャプタータイプ（Bghjkyz）の1つ以上の文字が含まれている場合があります。
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 systems chapters may be configured to have special semantics. Configuration occurs by specifying a channel list for the systems channel, using the coding described below (note that MIDI Systems commands do not have a "channel", and thus the original purpose of the channel list does not apply to systems 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 systems chapter.
いくつかのシステム章には、特別なセマンティクスがあるように構成されている場合があります。構成は、以下のコーディングを使用して、システムチャネルのチャネルリストを指定することによって発生します（MIDIシステムコマンドには「チャネル」がないことに注意してください。したがって、チャネルリストの元の目的はシステムの章には適用されません）。以下のテキストの「桁n」という式は、システムの章のチャネルリストにnを「チャネル」に含めることを指します。
For the J and K Chapter D sub-chapters (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の第1章サブチャプター（未定義のシステム共通）の場合、パラメーターが関連するコマンドログの法的分野（付録B.1の図B.1.4）に適用される桁0コード、桁1はコードをコードします。パラメーターは、コマンドログの値フィールドに適用され、パラメーターがコマンドログのカウントフィールドに適用される桁2コード。
For the Y and Z Chapter D sub-chapters (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の第1章サブチャプター（未定義システムのリアルタイム）の場合、パラメーターが関連するコマンドログの法的フィールド（付録B.1の図B.1.5）および桁1の法的フィールドに適用される数字0コード1パラメーターがコマンドログのカウントフィールドに適用されるコード。
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.
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.
Chapter Cの場合、フィールドリストは0〜255の範囲の値を引き受ける場合があります。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).
コントローラー番号の章Cエンコーディング方法を構成するために行われた割り当ては、CH_NEVER ACTへの割り当てとして、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.
Chapter Cフィールドリストは、特定のコントローラー番号の強化されたエンコードステータスに関する矛盾する情報をエンコードしてはなりません。たとえば、値0と128は両方ともフィールドリストによってコーディングされてはなりません。
For Chapter M, the field list codes the Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the parameter applies. The number range 0-16383 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 corresponds to NRPN 16383).
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章の場合、パラメーターがe章に適用される桁0は、v bitが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章の場合、フィールドリストは、この章でコーディングされているSysexコマンドに表示される可能性のあるデータオクテットの数をコーディングします。したがって、フィールドリスト0-255は255以下のデータオクテットを持つSysexコマンドを指定します。フィールドリスト256-4294967295は255を超えるデータオクテットを持つSysexコマンドを指定しますが、255以下のデータオクテットのコマンドを除外し、フィールドリスト0はすべてを除外します。コマンド。
A secondary parameter assignment syntax customizes Chapter X (see Appendix D for complete ABNF):
二次パラメーター割り当ての構文は、第X章をカスタマイズします（完全なABNFについては付録Dを参照）：
<parameter> = "__" <h-list> ["_" <h-list>] "__"
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のコーディングが割り当てられたパラメーターのセマンティクスに従うChapter 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>は、コマンドのデータオクテットを定義し、ドット分離された（ "。"）1つ以上の16進定数（「7f」など）またはダッシュ分離された16進範囲（ "01-など）のリストとして定義します。1f "）。アンダースコア（ "_"）各<hlist>を分離します。Double-UnderScores（ "__"）は、データOctetリストを描写します。
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.
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:DB80::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.)
（A = FMTP行は、メモのフォーマット制限に対応するためにページに適合するようにラップされています。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_updateパラメーターは、ストリームがオープンループポリシーを使用するとコードします。ほとんどの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、11、12、および13以外のMIDIチャネルの第n章は、（デフォルト）CH_DEFAULTセマンティクスを使用して、Recovery Journalに表示される場合があります。実際には、この割り当てパターンは、除外されたチャネルに使用される回復力のあるレンダリング方法に関する知識を反映しています。
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 Chapter C割り当ての順序付けは、リストされているコントローラー番号のCH_NEVER割り当てをオーバーライドすることに注意してください（7および64）。
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.
CM_UNUSEDへのコマンドタイプXの割り当ては、ストリームからほとんどのSYSEEXコマンドを除外します。セカンダリ割り当ての構文を使用して、一般的なMIDIシステムオン/オフコマンドとマスターボリュームとバランスコマンドの例外が作成されます。CM_USEDの割り当ては例外をコードし、CH_ANCHORの割り当ては、これらのコマンドが第X章で保護されている方法をコードします。
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
The parameter "tsmode" specifies the timestamp semantics for a stream. The parameter takes on one of three token values: "comex", "async", or "buffer".
The default "comex" value specifies that timestamps code the execution time for a command (Appendix C.3.1) and supports the accurate transcoding 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.
Ancillary parameters MAY follow tsmode in a media description. We define these parameters in Appendices C.3.2-3 below.
補助的なパラメーターは、メディアの説明でTSModeに従うことができます。これらのパラメーターを、以下の付録C.3.2-3に定義します。
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.
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.
SMFSがファイルに保存されている各MIDIコマンドのタイムスタンプをコードするため、タイムスタンプのCOMEX解釈は標準MIDIファイル（SMF、[MIDI]）をRTP MIDIストリームにトランスコードするのに適しています。メトリックタイムマーカーを使用するSMFをトランスコードするには、SMFテンポマップ（SMFでメタイベントとしてエンコード）を使用して、メトリックSMFタイムスタンプユニットを秒ベースのRTPタイムスタンプユニットに変換します。
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コントローラーデザイン（ピアノキーボード、ドラムパッドなど）は、タイムスタンプの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の解釈は、2つのコマンド間のタイムスタンプのオフセットがソースパフォーマンスのタイミングを反映していることを宣言しています。
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 (Section 6.1-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-2）は、この不正確な問題を修正できないことに注意してください。以下のセクションでは、MIDI 1.0 DINケーブルのタイミングと他のMIDI到着時間ソースに適した2つの代替タイムスタンプ解釈（「ASYNC」と「バッファ」）について説明します。
The "octpos", "linerate", and "mperiod" ancillary parameters (defined below) SHOULD NOT be used with comex.
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.
「async」tsmode値は、MIDI到着時間ソースの非同期サンプリングを指定します。非同期サンプリングでは、ソースからオクテットが受信された瞬間に、壁1杯の時間値でラベル付けされます。時間値には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にトークン値が「last」を持っている場合、タイムスタンプはコマンドの最後のオクテットの時間値をコードします。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).
Octposセマンティクスは、RTP MIDIパケットに表示されるように、到着時間の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).
「Linated」補助パラメーターは、サンプリングするMIDIソースの透過媒体上の1つのMIDIオクテットのタイムパン（MIDI 1.0 DINケーブルなど）を定義します。パラメーターにはナノ秒単位があり、積分値を引き受けます。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:
ここで、Asyncアルゴリズムのセッション説明例を示します。MIDI 1.0 DINケーブルソースをRTPにトランスコードしている送信者を考えてみましょう。送信者は、ソースのすべての入っているオクテットに時間値を割り当てるコンピューティングプラットフォームで実行され、送信者は時間値を使用して各コマンドの最初のオクテットに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
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.1 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.1で定義されている「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 sub-command 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:
ここで、バッファアルゴリズムのセッション説明例を示します。MIDI 1.0 DINケーブルソースをRTPにトランスコードしている送信者を考えてみましょう。送信者は、受領時にソースデータをバッファに配置するコンピューティングプラットフォームで実行されます。送信者は、バッファーを1秒間に1000回投票し、バッファーからすべての完全なコマンドを抽出し、コマンドをRTPパケットに配置します。このセッションの説明では、トランスコーディングについて説明します。
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:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=sendonly
a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; 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値は、RTPMAP属性（44100 Hz）で指定されたクロックレートを1000 Hzバッファーサンプリングレートで除算し、最寄りの整数に丸めて導出されます。実際のサンプリング期間は名目上のMperioD値と正確に一致しない可能性があるため、コマンドタイムスタンプは44の正確な倍数によって増加しない場合があります。
In this appendix, we describe session configuration tools for customizing the temporal behavior of MIDI stream packets.
この付録では、MIDIストリームパケットの時間的動作をカスタマイズするためのセッション構成ツールについて説明します。
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.
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.
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.
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:
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 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.
V = 0 O = Lazzaro 2520644554 2838152170 in ip4 first.example.net s =例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セッション属性ptimeおよびmaxptime [rfc4566]を使用してRTP MIDIストリームを構成しないでください。セッションは、PTIMEの代わりにrtp_ptimeを使用する必要があり、maxptimeの代わりにrtp_maxptimeを使用する必要があります。RTP MIDIは、PTIMEとMAXPTIMEの0 MS値が[RFC3264]によって禁止されているが、RTP MIDIの特定のアプリケーションに不可欠であるため、メディア時間構成の独自のパラメーターを定義します。
See the Appendix C.7 examples for additional discussion about using rtp_ptime and rtp_maxptime for session configuration.
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.
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 on-line 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パケットと遅い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」を使用して、メディアセッションの最小送信レートを設定する場合があります。GuardTimeに割り当てられた値は、RTPタイムスタンプユニットで表される2つのシーケンシャルパケット間の最大分離時間をコードします。
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.
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.
Sender実装の輻輳制御要件（セクション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:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0
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.
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.
o パーティーが2つのRTP MIDIストリーム（AとB）を送信する場合、ストリーム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.
o さまざまなRTPセッション、または同じRTPセッションでさまざまなRTPセッションで送信されたストリームは、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.
o MusicPortパラメーター。このパラメーターには、0〜4294967295の間の非陰性整数値が割り当てられます。これは、ペイロードタイプのFMTPラインに表示されます。
o The FID grouping attribute [RFC3388] signals that several RTP sessions in a multimedia session are using the musicport parameter to express an inter-session relationship.
o FIDグループ属性[RFC3388]は、マルチメディアセッションのいくつかの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パラメーターに同じ整数値が割り当てられているペイロードタイプがいくつかある場合、これらのペイロードタイプを使用したストリームは「ID関係」（同じペイロードタイプを使用するストリームを含む）を共有します。アイデンティティ関係のストリームは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セッションでID関係を共有する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.
マルチメディアセッションに、音楽ポートパラメーターにシーケンシャル値が割り当てられているペイロードタイプがいくつかある場合（つまり、i、i 1、... i k）、ペイロードタイプを使用したストリームは「秩序化された関係」を共有します。たとえば、ペイロードタイプAがMusicPortに2を割り当て、ペイロードタイプBは3をMusicPortに割り当て、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スペースを形成します。たとえば、Stream AのMusicPort値は2で、Stream BのMusicPort値は3の場合、Stream 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 [RFC3388].
o マルチメディアセッションのいくつかのRTPセッションからのストリームがMusicPortパラメーターを使用する場合、RTPセッションは[RFC3388]で定義された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 秩序化またはID関係には、ネイティブRTP MIDIストリームとMPEG4-GENERIC 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 Recovery Journal Mandateに違反するアイデンティティ関係を構築することが可能です（たとえば、ストリームAの音声チャネルのNoteonsを送信し、Stream Bの同じ音声チャネルのNoteoffsを送信します）。当事者は、この欠陥を示すセッションの説明を生成（または受け入れる）してはなりません。
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ストリームを含む関係に適用されます。この場合、1つのSendonlyセッションと1つの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-Genericストリームの両方で機能します。付録C.6ツールを使用するMPEG4-Genericストリームは、すべての「構成」パラメーターを空の文字列（ ""）に設定する必要があります。
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-Genericストリームの場合、レンダラーの仕様は、レンダラー構成文字列との関係に1つの「構成」パラメーターと、空の文字列（ ""）に他のすべての構成パラメーターを設定することで実行できます。
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.
送信者は、レンダリングされたMIDIパフォーマンスに無期限のアーティファクトが含まれていないように、名前空間を分割する必要があります（セクション4で定義されています）。この責任は、さまざまなストリームレイテンシが無期限のアーティファクトを生成する可能性があるため、すべてのストリームが信頼できる輸送の上に送信されたとしても保持されます。たとえば、2つのTCPストリームにわたってパフォーマンス分割でスタックされたノートが発生する場合があります。1つのストリームでNoteonコマンドが送信され、Noteoffコマンドが他のストリームに送信されます。
Senders MUST NOT split a Registered Parameter Name (RPN) or Non-Registered Parameter Name (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.
送信者は、複数のID関係セッション全体に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 Systems commands may be more complicated for sessions that extensively use System Exclusive.
Voice Channelコマンドを安全に分割する簡単な方法は、特定の音声チャネルのすべてのMIDIコマンドを同じセッションに配置することです。MIDI Systemsコマンドの安全な分割は、システム専用を広範囲に使用するセッションでは、より複雑になる場合があります。
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 [RFC3388] signal an inter-session relationship. The "group" and "mid" attribute lines implement this grouping mechanism.
セクション2.1では、同じMIDI名空間をターゲットとするストリームのルールを定義していることを思い出してください。上記の例に実装されているこれらのルールは、各ストリームが個別のRTPセッションに存在すること、および[RFC3388]で定義されているグループ化メカニズムがセッション間関係を示すことを要求します。「グループ」と「Mid」属性行は、このグループ化メカニズムを実装します。
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レンダラーを駆動するアイデンティティ関係で2つのストリームを使用し、それぞれ異なるトランスポートタイプを持つ。1つのストリームはUDPを使用し、リアルタイムメッセージに専念します。2番目のストリームはTCP [RFC4571]を使用し、Sysexバルクデータメッセージに使用されます。
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-Genericストリームが順序付けられた関係を形成して、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:DB80::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.)
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.
2つのセッションのシーケンシャルミュージックポート値は、秩序ある関係を確立します。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ストリーム（1つのRecvonly、1つはSendonly）を示しています。各ストリームは異なるRTPセッションに存在します（SendonlyとRecvonlyが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」セマンティクスを信号するために、2つのストリームはMusicPortを同じ値に割り当てます（12）。このセクションで前述したように、さまざまな関係者によって送信されるアイデンティティ関係ストリームのペアは、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構成の主な利点は、各パーティが受信するストリームのプロパティをカスタマイズできることです。上記の例では、各ストリームは、各パーティのレンダリングアルゴリズムをカスタマイズできる独自の「構成」文字列を定義します（実際、この例に示す特定の文字列は同一です。
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":
「レンダリング」パラメーターは、ストリームのレンダリング方法を指定します。パラメーターには、トップレベルのレンダリングクラスを通知するトークン値が割り当てられます。このメモは、レンダリングの4つのトークン値を定義します：「不明」、「合成」、「API」、および「null」：
o An "unknown" renderer is a renderer whose nature is unspecified. It is the default renderer for native RTP MIDI streams.
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-Generic RTP MIDIストリームのデフォルトレンダラーです。
o An "api" renderer presents the command stream to applications via an Application Programmer Interface (API).
o 「API」レンダラーは、アプリケーションプログラマーインターフェイス（API）を介してコマンドストリームをアプリケーションに提示します。
o The "null" renderer discards the MIDI stream.
o 「null」レンダラーは、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).
「null」レンダリング価値は、オファー/回答の交渉中に特別な役割を果たします[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に登録される場合があります。トークン値は、付録Dで定義されているレンダリングトークンのABNFに接着する必要があります。登録には、「合成」および「API」レンダリング値の付録C.6に表示される仕様と同様のパラメーター値の使用法の完全な仕様を含める必要があります。。当事者に当事者に知られていないレンダリングトークン値を使用するセッションの説明が提供された場合、当事者はレンダラーを受け入れてはなりません。オプションには、レンダラー（「null」値を使用）、ペイロードタイプ、メディアストリーム、またはセッションの説明を拒否することが含まれます。
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-Genericストリームでレンダリングパラメーターを使用することには、特別なルールが適用されます。これらのルールを付録C.6.5に定義します。
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つのトークン値を定義します：「1つ」と「すべて」：
o The default "one" value requests rendering by exactly one of the listed renderers.
o デフォルトの「One」値は、リストされているレンダラーの1つによるレンダリングを要求します。
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つ以上のレンダリングパラメーターを含むパラメーターリストが含まれている場合、「Answer」は、すべての未選択レンダラーのレンダリングパラメーターを「null」に設定する必要があります。
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.
サブレンダーパラメーターがレンダラー定義に使用されている場合、パラメーターリストのレンダリングパラメーターの直後に表示する必要があります。最大で1つのサブレンダーパラメーターがレンダラー定義に表示される場合があります。
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-Generic）にデフォルトのレンダラーの使用を指定します。ネイティブRTP MIDIストリームのデフォルトのレンダラーは、その性質が不特定のレンダリング装置です（詳細については、セクション6.1のポイント6を参照）。MPEG4-Generic RTP MIDIストリームのデフォルトレンダラーは、ID番号が13、14、または15のMPEG 4オーディオオブジェクトタイプです（詳細についてはセクション6.2を参照）。
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.
他のサブレンダートークン値は、IANAに登録される場合があります。ここで、サブレンダーの値を登録するためのガイドラインについて説明します。
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.
サブレンダー値は、特定のストリームタイプ（ネイティブまたはMPEG4-Generic）および特定のレンダリング値（「null」および「nowns」を除く）に登録されます。MPEG4-Genericサブレンダー値の登録は、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).
「render = synthetic」レンダラーの場合、サブレンダーバリュー登録は、MIDIストリームをオーディオに変換するための正確な方法を指定します（または、ステージ照明などのビデオまたはコントロールアクションに）。標準化されたレンダラーの場合、この仕様は通常、RTP-MIDI固有の情報によって補足される標準文書へのポインターです。商用製品およびオープンソースプロジェクトの場合、この仕様は通常、RTP MIDIストリームに製品またはプロジェクトソフトウェアをインターフェースするための指示の形をとります。「レンダリング=合成」登録は、レンダラーに追加のリセット状態コマンドを指定する場合があります（付録A.1）。
A "render=api" subrender value registration specifies how an RTP MIDI stream interfaces with an API (Application Programmers Interface). This specification is usually a pointer to programmer's documentation for the API, perhaps supplemented by RTP-MIDI-specific information.
「Render = API」サブレンダー値登録は、RTP MIDIストリームがAPI（アプリケーションプログラマーインターフェイス）をインターフェースする方法を指定します。この仕様は通常、APIのプログラマーのドキュメントへのポインターであり、おそらくRTP-MIDI固有の情報で補足されます。
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に定義されているコーディングツールを使用して、パラメーターリスト（Verbatimまたは参照により）にエンコードできます。初期化データオブジェクトには、登録された[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.).
「render = synthetic」レンダラーの場合、データオブジェクトは通常、レンダラーの初期化データをエンコードします（サンプルファイル、合成パッチパラメーター、残響室のインパルス応答など）。
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).
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").
サブレンダー値登録は、サブレンダーの直後にパラメーターリストに表示される追加のパラメーターを指定する場合があります。これらのパラメーター名は、将来のRTP MIDIパラメーター名（たとえば、サブレンダー値「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.
当事者に、サブレンダーの価値が当事者に知られていないレンダラーを使用するセッションの説明が提供された場合、当事者はレンダラーを受け入れてはなりません。オプションには、レンダラー（「null」値を使用）、ペイロードタイプ、メディアストリーム、またはセッションの説明を拒否することが含まれます。
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）を認識する必要があり、レンダラーがリセット状態コマンドの存在（または損失）のために無期限のアーティファクトを経験しないことを保証する必要があります。
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」パラメーターが「サブレンダー」パラメーターの直後にパラメーターリストに表示する必要があります。レンダラーパラメーターリストにサブレンダーパラメーターが含まれていない場合（付録C.6.2の「デフォルト」のセマンティクスを想起）、「Render」パラメーターの直後に「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".
RTP MIDIは、パラメーターリストのレンダラーの初期化データオブジェクトをエンコードするためのいくつかのパラメーターをサポートしています：「インライン」、「URL」、および「CID」。
If the "inline", "url", and/or "cid" parameters are used by a renderer, these parameters MUST immediately follow the "rinit" parameter.
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" or "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 a HyperText Transport Protocol URL (HTTP, [RFC2616]). HTTP MAY be used over TCP or MAY be used over a secure network transport, such as the method described in [RFC2818]. The media type/subtype for the data object SHOULD be specified in the appropriate HTTP transport header.
「URL」パラメーターには、データオブジェクトの均一なリソースロケーター（URL）の二重引用文字列表現が割り当てられます。文字列は、ハイパーテキストトランスポートプロトコルURL（HTTP、[RFC2616]）を指定する必要があります。HTTPは、[RFC2818]で説明されている方法など、TCPを介して使用されるか、安全なネットワーク輸送で使用される場合があります。データオブジェクトのメディアタイプ/サブタイプは、適切なHTTPトランスポートヘッダーで指定する必要があります。
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.
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パラメーターに従ってはなりません。受信者は、CIDパラメーターの存在を、URLデータオブジェクトのキャッシュコピーを使用しても安全であることを示すものとして解釈します。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).
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.
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] [RFC4289].
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 "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ノート情報をエンコードできるため、オーディオパフォーマンスを完了することもできます。これらのオブジェクトは、「オーディオ」メディアタイプを使用して登録する必要があります。これにより、オブジェクトは、編集ツールをサポートするために、ストアアンドフォワードレンダリングおよび「アプリケーション」メディアタイプにも使用できます。ノートストレージのない初期化オブジェクト、または非Audioレンダラーの初期化オブジェクトは、「アプリケーション」メディアタイプにのみ登録する必要があります。
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, below).
セッションの説明では、セッションの各レンダラーに互換性のある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 sub-sections below.
パラメーターリストが複数のレンダラーを定義し、「すべて」トークン値をマルチモードパラメーターに割り当てると、同じ名前のスペースが各レンダラーに表示されます。ただし、「Chanmask」パラメーターを使用して、選択した音声チャネルを各レンダラーにマスクすることができます。以下のサブセクションで「チャンマスク」およびその他のMIDI管理パラメーターを定義します。
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パラメーターは、レンダラーデータオブジェクトにカプセル化されたSMFSの使用を定義します（ある場合）。SMF_INFOパラメーターは、SMF_INLINE、SMF_URL、およびSMF_CIDパラメーターでコード化されたSMFSの使用も定義します（付録C.6.4.2で定義）。
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」、および「ID」：
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.
o SMFをレンダリングする必要がある「SDP_START」値コード、およびセッションの説明の受け入れ時にレンダリングを開始する必要があること。受信者がSMF_INFOパラメーターをSDP_STARTに使用するレンダラーを使用したセッション説明を提供し、レシーバーがレンダリングSMFSをサポートしていない場合、受信者は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 current state of the devices (patch memory contents, etc.).
o 「ID」値は、SMFSがレンダラーのIDをコードすることを示します。値は、「不明な」レンダラーで使用することを目的としています（付録C.6プリアンブルを参照）。SMFでコード化されたMIDIコマンドは本質的に情報に基づいており、オーディオプレゼンテーションのためにレンダラーに提示してはなりません。典型的な用途では、SMFはSysex Identity Replyコマンド（[MIDI]で定義されているF0 7E NN 06 02）を使用してデバイスを識別し、デバイス固有のSysexコマンドを使用してデバイスの現在の状態（パッチメモリ内容などを記述します。。）。
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に登録される場合があります。トークン値は、付録Dで定義されているレンダリングトークンのABNFに接着する必要があります。登録には、「SDP_START」と「ID」のこの付録に表示される仕様と同様のパラメーター使用量の完全な仕様を含める必要があります。
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.
セッションの説明内のSMFSと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は「1番目」、「2番目」などです）、次のルールを使用します。
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.).
o レンダラーが単一のデータオブジェクトを使用する場合、オブジェクトの内部構造内のSMFSの外観の順序がSMFSの順序を定義します（オブジェクトの初期のSMFは「最初」です。オブジェクトの次のSMFは「2番目」です。等。）。
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
o If SMFs are encoded in data objects parameters and in the parameters defined in C.6.4.2, the relative order of the data object parameters and 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がデータオブジェクトパラメーターとc.6.4.2で定義されているパラメーターでエンコードされている場合、パラメーターリストのデータオブジェクトパラメーターとc.6.4.2パラメーターの相対順序はSMFSの相対順序を設定します（パラメーターでエンコードされたSMFSリストの前半に表示されるのは、リストの後半に表示されるパラメーターで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.
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は、1つのMIDIネームスペース（16 Voice Channels Systems）をエンコードすることに注意してください。したがって、SMFのいくつかのMIDI名スペースを指定するためにデバイス名SMFメタイベントの使用は、SDP_STARTではサポートされていません。
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で定義されている方法でSMFSを使用することを希望する場合があります。
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名スペース順序を定義します。
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（単一のストリームまたはID関係の場合）または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.
レシーバーにチャンマスクパラメーターを使用するレンダラーを使用したセッション説明が提供され、レシーバーがチャンマスクパラメーターのセマンティクスを実装していない場合、レシーバーはチャンマスクパラメーター値に「1」のみが含まれない限り、レンダラーを受け入れてはなりません。
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]).
付録11.3では、オーディオ/ASCメディアタイプを登録します。Audio/ASCのデータオブジェクトは、MPEG4-Genericストリームの初期化に使用されるAudipecificConfigデータブロックのバイナリエンコードです（セクション6.2および[MPEGAUDIO]）。
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-GENERICパラメーターリストは、レンダラー構成のオーディオ/ASCメディアタイプを使用して、レンダリング、サブレンダー、およびRINITパラメーターを使用できます。MPEG4-Genericパラメーターリストでこれらのパラメーターを使用することには、いくつかの制限が適用されます。
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-GENERICメディアの説明では、空の文字列（ ""）をMPEG4-Generic "Config"パラメーターに割り当てる必要があります。StreamType、モード、およびプロファイルレベルIDパラメーターの使用は、セクション6.2の規範テキストに従う必要があります。
o Sessions that use identity or ordered relationships MUST follow the mpeg4-generic configuration restrictions in Appendix C.5.
o ID関係または順序付けられた関係を使用するセッションは、付録C.5のMPEG4-Generic構成制限に従う必要があります。
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 レンダリングパラメーターは、MPEG4-Generic 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".
o サブレンダーパラメーターが存在する場合、レンダリングパラメーターをすぐに実行する必要があり、トークン値「デフォルト」を割り当てるか、MPEG4-GENERIC RTP MIDIストリームで使用するためにIANAリポジトリにサブレンダー値を割り当てる必要があります。サブレンダーパラメーターの割り当ては、レンダラー構成から除外される場合があります。その場合、サブレンダーの暗黙の値は「デフォルト」のデフォルト値です。
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 C.6.2-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パラメーターに値「Audio/ASC」を割り当てる必要があり、AudioSpecificConfigデータオブジェクトを使用してaudioSpecificConfigデータオブジェクトをエンコードする必要があります。c.6.2-3で定義されているメカニズム。AudiospecificConfigデータは、セクション6.2でMPEG4-Genericで使用するために定義されたMPEG 4オーディオオブジェクトタイプの1つをエンコードする必要があります。サブレンダー値が「デフォルト」以外の場合は、レンダラーで「Audio/ASC」の使用に関する情報については、サブレンダー登録を参照してください。
o If the render parameter is assigned the value "null" or "unknown", the data object MAY be omitted.
o レンダリングパラメーターに値「null」または「不明」が割り当てられている場合、データオブジェクトは省略できます。
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 ネイティブストリームは、「オーディオ/ASC」をRINITに割り当ててはなりません。オーディオ/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.
o オーディオ/ASCメディアタイプは、保存されたオブジェクトタイプを定義します。RTPストリームのセマンティクスを定義しません。したがって、Audio/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-Generic General MidiストリームのAudipecificConfigブロックをコーディングします。付録E.4のインラインパラメーターに割り当てられた値を導き出します。「デフォルト」のサブレンダートークン値は、パラメーターリストにサブレンダーパラメーターがないことによって暗示されます。
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の単一行で構成されています。）
The session description below uses the url parameter to code the AudioSpecificConfig block for the same General MIDI stream:
以下のセッションの説明では、URLパラメーターを使用して、同じ一般的なMIDIストリームのAudipecificConfigブロックをコーディングします。
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の単一行で構成されています。）
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コンテンツストリーミングアプリケーション。RTP MIDIは、RTSPベースのコンテンツストリーミングサーバーに追加されるため、視聴者は他のストリーム（ビデオ、オーディオ）と同期してMIDIパフォーマンス（指定されたクライアント側レンダラーによって生成）を経験する可能性があります。
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 functionality 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.
このセクションで扱うアプリケーションは、MIDIが使用する潜在的なRTPの網羅的なリストではありません。IETF内または他の組織内で、他のアプリケーションのフレームワークドキュメントが開発されると予想されます。このメモのメインテキストのセクション1で、RTP 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 URLを使用してラジオチャネルをホストするRTSPサーバーに連絡する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.).
これらの例は、オーディオコンテンツの視聴者への配布を説明していることに注意してください。この付録の相互運用性ガイドラインは、プロフェッショナル環境（レコーディングスタジオ、パフォーマンス段階など）で使用するための生のMIDIコマンドストリームの送信などのアプリケーションではなく、この性質のRTP 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 describsメソッドを介して、または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.
ほとんどの場合、サーバーの相互運用性の責任は、クライアントの機能に関する情報がない場合、「リファレンス」セッションの説明の制限に関して、サーバーがパフォーマンスを提供するという点で説明されています。参照セッションは、クライアントがセッションを表示できるオッズを最大化する「最も低い一般的な分母」セッションです。サーバーがクライアントの機能を認識している場合、サーバーは無料の返信でクライアントにカスタマイズされたセッション説明を無料で提供できます。
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.
クライアントは、閉ループまたはアンカー送信ポリシーで回復ジャーナルを使用するUnicast 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ストリームを、Recovery Journalと閉ループまたはアンカー送信ポリシーを使用するユニキャストストリームとして送信する必要があります。サーバーは、クライアントのレンダリングタスクを簡素化するために、参照セッションの説明でストリームサブセットと章の包含パラメーターを使用する必要があります。拡張された第Cエンコードのサーバーサポートはオプションです。
Clients and servers MUST support the use of RTSP interleaved mode (a method for interleaving RTP onto the RTSP TCP transport).
クライアントとサーバーは、RTSPインターリーブモード（RTPをRTSP TCPトランスポートにインターリーズする方法）の使用をサポートする必要があります。
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 either all code the same temporal duration (non-normative example: 50 ms packets) or that code 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.
サーバーは、メディアサーバーが従来のオーディオストリームを送信するのと同じように、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.
データオブジェクト（「インライン」のパラメーター値によってエンコードされているように）をサポートするクライアントは、サイズが300オクテットを超える可能性があるため、URLとCIDパラメーターをサポートする必要があるため、RTSPに加えてHTTPプロトコルを実装する必要があります。
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 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 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-Generic 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セッションはレンダリングとサブレンダー（付録C.6.2）を使用して、RTSPコンテンツストリーミングマルチメディアセッションの完全なレンダリングシステムを指定できます。
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.
サーバーは、参照セッションの説明でSMF_INFOパラメーターのSDP_START値を使用してはなりません。この使用では、クライアントが標準のMIDIファイルを解析およびレンダリングできる必要があるためです。
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-Generic Mode RTP-MIDI General Midi（GM）セッションをサポートする必要があります。この要件は、コンテンツプロバイダーがターゲットにするための「最も低い一般的な分母」レンダリングシステムを提供します。この要件は、非GMレンダラー（DLS 2や構造化されたオーディオなど）の実装者が2番目のレンダリングエンジンを追加することを強制しないことに注意してください。代わりに、クライアントは、GM機器セットを実装する一連の音声パッチを含め、MPEG4-Generic 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 for normative applications it is an inappropriate choice. Servers using General MIDI as a "lowest common denominator" renderer SHOULD use Universal Real-Time SysEx MIP message [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
クライアントはそれをサポートする必要があるため、サーバーは参照セッションの説明のレンダラーとして一般的なMIDIを使用することをお勧めします。規範的アプリケーションにとっては不適切な選択であるため、参照レンダラーとしてMIDI将軍は必要ありません。一般的なMIDIを「最も低い一般的な分母」レンダラーとして使用するサーバーは、ユニバーサルリアルタイムSysex MIPメッセージ[SPMIDI]を使用して、ポリフォニー制限されたクライアントに声の優先順位を伝える必要があります。
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 (NMP), 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.
この付録セクションでは、インタラクティブSIPアプリケーションでRTP MIDIストリームを使用するための相互運用性ガイドラインを定義します。私たちの主な関心は、ネットワークミュージカルパフォーマンス（NMP）をサポートすることです。ここでは、さまざまな場所にあるミュージシャンがネットワーク上で同じ部屋にいるかのように相互作用します。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アプリケーションの目標はテレプレゼンスであることに注意してください。当事者は、同じ部屋にいる場合に聞くものに近いオーディオを聞く必要があります。この付録の相互運用性ガイドラインは、プロフェッショナル環境（レコーディングスタジオ、パフォーマンス段階など）で使用するための生のMIDIコマンドストリームの送信などのアプリケーションではなく、この性質のRTP 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.
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 using different applications might not yield a common session configuration.
SIPでは、オファー/回答プロトコル[RFC3264]を使用して、当事者がセッションの詳細を交渉できます。ただし、RTP MIDIには非常に多くのパラメーターがあるため、異なるアプリケーションを使用して2つの当事者間の「ブラインド」交渉は、共通のセッション構成が得られない場合があります。
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.
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.
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ストリームのUnicast UDP輸送をサポートする必要があります。これらのストリームは、閉ループまたはアンカー送信ポリシーを備えたRecovery Journalを使用する必要があります。これらのストリームは、Stream SubsettingとChapter Inclusionパラメーターを使用して、Stream（Sendonlyストリーム用）に送信されるMIDIコマンドのタイプを宣言するか、システム専用コマンドのサイズ制限を含む（Recvonlyストリーム用）処理される必要があります。強化された第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.
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".
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.
当事者は、rtp_ptimeおよびrtp_maxptime値0からrtp_ptimeおよびrtp_maxptime値を100ミリ秒コードします。したがって、受信機はプレイアウトバッファーを実装できる必要があります。
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. Implementers 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]を参照する必要があります。5ミリ秒から5000ミリ秒までの時間の間、当事者は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 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 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（セクション6.2およびc.6.5）のMPEG4-Generic RTP MIDIストリームを指定することです。レンダリングシステムの所有者（標準化されたものと独自の両方）がレンダラーのサブレンダー値を登録すると予想しています。IANA登録が発生すると、ネイティブRTP MIDIセッションはレンダリングとサブレンダー（付録C.6.2）を使用して、SIPネットワークミュージカルパフォーマンスマルチメディアセッションの完全なレンダリングシステムを指定できます。
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 message [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
すべての当事者は、当事者のハードウェア機能によって制限されたポリフォニーで、MIDI（GM）セッション将軍（GM）セッションをサポートする必要があります。この要件は、「最も低い一般的な分母」レンダリングシステムを提供します。これは、実用的な相互運用性が非常に困難です。GMを使用する場合、当事者はユニバーサルリアルタイムSysex MIPメッセージ[SPMIDI]を使用して、ポリフォニーに制限されたクライアントに声の優先順位を伝える必要があります。
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-Genericセッション、DLS 2、または構造化されたオーディオの場合）の実装者に2番目のレンダリングエンジンを追加させないことに注意してください。代わりに、クライアントは、GM機器セットを実装する一連の音声パッチを含め、MPEG4-Generic 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セッションでいくつかのRTP MIDIストリームを送信できるように、オファーはメディアラインに複数のペイロードタイプをリストすることにより、セッション説明のオプションとしていくつかのレンダラーを提示してはなりません。
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.
We use SHOULD instead of MUST in the first sentence in the paragraph above, because this technique does not work in all situations (example: 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-GenericレンダラーとネイティブRTP MIDIレンダラーの両方をオプションとして提供したいと考えています）。この場合、オファーは、回答者がセッションの説明を受け入れるまで、それぞれが単一のレンダラーを提供する一連のセッションの説明を提示する必要があります。
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 HTTP protocol. 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、Subrender、Rinit、およびインラインパラメーターをサポートする必要があります。データオブジェクト（「インライン」のパラメーター値によってエンコードされているように）が300オクテットを超える可能性があるレンダラーをサポートするパーティは、URLとCIDパラメーターをサポートする必要があるため、HTTPプロトコルを実装する必要があります。MPEG4-GENERICでは、一般的な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, a second for the remote party.
これまでのところ、私たちの議論は、レンダラーを駆動するMIDIフローがセッションの説明で説明されているネットワークフローであると想定しています。NMPアプリケーションでは、この仮定には2つのレンダリングエンジンが必要になります。1つはパーティーがローカルに使用するための1つ、リモートパーティーの2つ目です。
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 channels, the application MUST ensure that appropriate MIDI merging occurs at the input to the renderer.
実際には、アプリケーションは両方の当事者に単一のレンダリングエンジンを共有させることを望んでいる場合があります。この場合、セッションの説明は仮想SendRecvセッションを使用する必要があり、Stream SubsettingとChapter Inclusionパラメーターを使用して、MIDIチャンネルがパーティーで使用することを目的としているかを割り当てる必要があります。2つの当事者が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 (next page). 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の単一行で構成されています。）
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).
セッションの説明では、2つのMIDIストリームが定義されています。「ファースト」がパフォーマンスを受信するレコボンリーストリームと、「ファースト」がパフォーマンスを送信するために使用するSendonlyストリームです。Recvonlyポート番号は、IP4アドレス192.0.2.94で「最初」がRTP（16112）およびRTCP（16113）メディアを受け取ることを望んでいるポートをエンコードします。Sendonlyポート番号は、「最初」がストリームのRTCPを受け取ることを望んでいるポート（16115）をエンコードします。
The musicport parameters code that the two streams share and identity relationship and thus form a virtual sendrecv stream.
MusicPortパラメーターは、2つのストリームが共有され、アイデンティティの関係を共有し、したがって仮想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.
両方のストリームは、一般的なMIDIレンダラーを指定するMPEG4-GENERIC RTP MIDIストリームです。Recvonlyストリームが音声コマンドのみにMIDIチャンネル1を使用し、Sendonlyストリームが音声コマンドに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.)
（A = FMTP行は、メモのフォーマット制限に対応するためにページに適合するようにラップされています。それらはSDPの単一行で構成されています。）
The owner line (o=) identifies the session owner as "second".
所有者行（O =）は、セッション所有者を「2番目」と識別します。
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) and the RTP (5004 and 5006) and RTCP (5005 and 5007) have been changed by "second" to match its transport wishes.
両方のメディアストリームのポート番号はゼロではありません。したがって、「2番目」がセッションの説明を受け入れました。オファーの「Sendonly」とマークされたストリームは、回答の「Recvonly」とマークされており、その逆も同様であり、「セッション」が保持しているセッションの異なるビューをコーディングします。IP4番号（192.0.2.105）とRTP（5004および5006）とRTCP（5005および5007）は、輸送の願いに合わせて「2番目」によって変更されました。
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.
さらに、「2番目」がいくつかのパラメーターの変更を加えました。SendonlyストリームのRTP_Maxptimeはコード2 ms（クロック単位で441）に変更され、RecvonlyストリームのGuardtimeは2倍になりました。これらのパラメーターの変更は、相互運用可能な関係者が実装する必要がある機能を要求するため、「2番目」が「最初の」が彼らに従うことができるという自信を持ってこれらの変更を行うことができます。
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, [RFC4234]). 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:
この付録では、Backus-Naur形式の拡張されたRTP MIDIメディア型パラメーターの構文を定義します（ABNF、[RFC4234]）。これらのパラメーターをSDPで使用する場合、すべてのパラメーターがRTP MIDIメディアの説明の単一のFMTP属性行に表示する必要があります。MPEG4-GENERIC RTP MIDIストリームの場合、この行にはMPEG4-Genericパラメーターも含まれている必要があります（セクション6.2で説明した使用法）。FMTP属性行を定義できます（[RFC3640]後）：
;
; SDP fmtp line definition
;
fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF
where <token> codes the RTP payload type. Note that white space MUST NOT appear between the "a=fmtp:" and the RTP payload type.
ここで、<token>はRTPペイロードタイプをコードします。「a = fmtp：」とRTPペイロードタイプの間に空白が表示されないことに注意してください。
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.
次に、付録Cで定義されているパラメーターの構文を定義します。定義は、<param-assign>トークンのインクリメンタルアセンブリの形をとっています。セクション6.2で説明したMPEG4-Genericパラメーターの構文については、[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-assign =/ ("cm_used=" (([channel-list] command-type
[f-list]) / sysex-data))
; ; Parameters defined in Appendix C.2
;;付録C.2で定義されているパラメーター
param-assign =/ ("j_sec=" ("none" / "recj" / *ietf-extension))
param-assign =/ ("j_update=" ("anchor" / "closed-loop" /
"open-loop" / *ietf-extension))
param-assign =/ ("ch_default=" (([channel-list] chapter-list
[f-list]) / sysex-data))
param-assign =/ ("ch_never=" (([channel-list] chapter-list
[f-list]) / sysex-data))
param-assign =/ ("ch_anchor=" (([channel-list] chapter-list
[f-list]) / sysex-data))
; ; Parameters defined in Appendix C.3
;;付録C.3で定義されているパラメーター
param-assign =/ ("tsmode=" ("comex" / "async" / "buffer"))
param-assign =/ ("linerate=" nonzero-four-octet)
param-assign =/（ "linerate =" nonzero-four-octet）
param-assign =/ ("octpos=" ("first" / "last"))
param-assign =/ ("mperiod=" nonzero-four-octet)
param-assign =/（ "mperiod =" nonzero-four-octet）
; ; Parameter defined in Appendix C.4
;;付録C. 4で定義されているパラメーター
param-assign =/ ("guardtime=" nonzero-four-octet)
param-assign =/（ "guardtime =" nonzero-four-octet）
param-assign =/ ("rtp_ptime=" four-octet)
param-assign =/（ "rtp_ptime =" four-octet）
param-assign =/ ("rtp_maxptime=" four-octet)
param-assign =/（ "rtp_maxptime =" four-octet）
; ; Parameters defined in Appendix C.5
;;付録C.5で定義されているパラメーター
param-assign =/ ("musicport=" four-octet)
param-assign =/（ "musicport =" four-octet）
; ; Parameters defined in Appendix C.6
;;付録C.6で定義されているパラメーター
param-assign =/ ("chanmask=" ( 1*( 16( "0" / "1" ) )))
param-assign =/ ("cid=" double-quote cid-block double-quote)
param-assign =/（ "cid =" double-quote cid-block double-quote）
param-assign =/ ("inline=" double-quote base-64-block double-quote)
param-assign =/（ "inline =" double-quote base-64-block double-quote）
param-assign =/ ("multimode=" ("all" / "one"))
param-assign =/ ("render=" ("synthetic" / "api" / "null" /
"unknown" / *extension))
param-assign =/ ("rinit=" mime-type "/" mime-subtype)
param-assign =/（ "rinit =" mime-type "/" mime-subtype）
param-assign =/ ("smf_cid=" double-quote cid-block double-quote)
param-assign =/（ "smf_cid =" double-quote cid-block double-quote）
param-assign =/ ("smf_info=" ("ignore" / "identity" /
"sdp_start" / *extension))
param-assign =/ ("smf_inline=" double-quote base-64-block double-quote)
param-assign =/（ "smf_inline =" double-quote base-64-block double-quote）
param-assign =/ ("smf_url=" double-quote uri-element double-quote)
param-assign =/（ "smf_url =" double-quote uri-element double-quote）
param-assign =/ ("subrender=" ("default" / *extension))
param-assign =/ ("url=" double-quote uri-element double-quote)
param-assign =/（ "url =" double-quote uri-element double-quote）
;
; list definitions for the cm_ command-type
;
command-type = command-part1 command-part2 command-part3
command-type = command-part1 command-part2 command-part3
command-part1 = (*1"A") (*1"B") (*1"C") (*1"F") (*1"G") (*1"H")
command-part2 = (*1"J") (*1"K") (*1"M") (*1"N") (*1"P") (*1"Q")
command-part3 = (*1"T") (*1"V") (*1"W") (*1"X") (*1"Y") (*1"Z")
;
; list definitions for the ch_ chapter-list
;
chapter-list = ch-part1 ch-part2 ch-part3
ch-part1 = (*1"A") (*1"B") (*1"C") (*1"D") (*1"E") (*1"F") (*1"G")
ch-part2 = (*1"H") (*1"J") (*1"K") (*1"M") (*1"N") (*1"P") (*1"Q")
ch-part3 = (*1"T") (*1"V") (*1"W") (*1"X") (*1"Y") (*1"Z")
;
; list definitions for the ch_ channel-list
;
channel-list = midi-chan-element *("." midi-chan-element)
midi-chan-element = midi-chan / midi-chan-range
midi-chan-range = midi-chan "-" midi-chan
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-chan = %d0-15
;
; list definitions for the ch_ field list (f-list)
;
f-list = midi-field-element *("." midi-field-element)
midi-field-element = midi-field / midi-field-range
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-field = four-octet
;
; large range accommodates Chapter M
; RPN (0-16383) and NRPN (16384-32767)
; parameters, and Chapter X octet sizes.
;
; definitions for ch_ sysex-data
;
sysex-data = "__" h-list *("_" h-list) "__"
h-list = hex-field-element *("." hex-field-element)
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 = 2("0" / "1" / "2"/ "3" / "4" /
"5" / "6" / "7" / "8" / "9" /
"A" / "B" / "C" / "D" / "E" / "F")
;
; rewritten version of hex-octet in [RFC2045]
; (page 23).
; note that a-f are not permitted, only A-F.
; hex-octet values MUST NOT exceed 7F.
;
; definitions for rinit parameter
;
mime-type = "audio" / "application"
mime-subtype = token
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.
;
; definitions for base64 encoding
; copied from [RFC4566]
base-64-block = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/"
; A-Z, a-z, 0-9, "+" and "/"
;
; generic rules
;
ietf-extension = token
;
; ietf-extension may only be defined in
; standards-track RFCs.
extension = token
;
; extension may be defined by filing
; a registration with IANA.
four-octet = %d0-4294967295
; unsigned encoding of 32-bits
nonzero-four-octet = %d1-4294967295
; unsigned encoding of 32-bits, ex-zero
uri-element = URI-reference ; as defined in [RFC3986]
uri-element = uri-reference;[RFC3986]で定義されている
double-quote = %x22
; the double-quote (") character
;ダブルクォート（ "）文字
token = 1*token-char
; copied from [RFC4566]
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
%x30-39 / %x41-5A / %x5E-7E
; copied from [RFC4566]
cid-block = 1*cid-char
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
; double-quote and the non-email safe () <>
; note that "cid" defined above ensures that
; cid-block is enclosed with double-quotes
; external references ; URI-reference: from [RFC3986]
;外部参照;uri-reference：[rfc3986]から
; ; 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-Generic RTPペイロード[RFC3640]は、使用中のMPEGストリームのタイプを信号する「モード」パラメーターを定義します。以下のABNFルールを使用して、新しいモード値「RTP-MIDI」を追加します。
;
; mpeg4-generic mode parameter extension
;
mode =/ "rtp-midi"
; as described in Section 6.2 of this memo
E. A MIDI Overview for Networking Specialists
E.ネットワーキングスペシャリストの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コマンドのシーケンスとしてエンコードすることにより、音楽のパフォーマンスを表しています。この高レベルの音楽表現はコンパクトですが、壊れやすいです。
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コマンド内のビットフィールドには、通常の構造と専門的な目的があります。たとえば、最初のコマンドOctet（OpCodeフィールド）の上部ニブルは、コマンドタイプをコードします。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 Realtime 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システムメッセージ
Figure 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. Systems commands perform functions that usually affect all voice channels, such as System Reset (0xFF).
図E.1およびE.2は、MIDIコマンドファミリーを示しています。コマンドには3つの主要なクラスがあります：音声コマンド（範囲0x8〜0xeのオペコードフィールド値）、システム共通コマンド（opcodeフィールド0xf、コマンド0xf0〜0xf7）、およびシステムリアルタイムコマンド（opcodeフィールド0xf、コマンド0xf8 x0xff）。音声コマンドは、作曲の各音色の音楽ジェスチャーをコードします。システムコマンドは、通常、システムリセット（0xff）などのすべての音声チャネルに影響を与える関数を実行します。
Voice commands execute 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.
音声コマンドの例として、Noteonコマンド（OpCode 0x9）を考えてみましょう。バイナリは1001cccc 0nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnです。このコマンドは、MIDIチャンネルCCCCの音符の開始を示しています。メモには、ノート番号nnnnnnnによってコード化されたピッチと、ノート速度aaaaaaaaでコードされた開始振幅があります。
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.
その他の音声コマンドは、ノートの終わり（NoteOff、OpCode 0x8）を通知し、特定の音色をMIDIチャネル（PCHANGE、OPCODE 0XC）にマッピングするか、音色の品質（他のすべての音声コマンド）を変調するパラメーターの値を設定します。ほとんどの音声チャネルコマンドの正確な意味は、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）など、ストリーム内のさまざまなグローバルタスクを実行します。タイムコードクォーターフレームコマンド）、およびデバイス固有のデータの通信（システム専用メッセージ）。
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コマンドビットフィールドは特別な構造を共有します。最初のオクテットの主要なビットは1に設定され、その後のすべてのオクテットの主要なビットは0に設定されます。この構造は、ランニングステータス[MIDI]と呼ばれるデータ圧縮システムをサポートします。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音声コマンドの最初のオクテットと同一である場合、削除される場合があります。このルールは、Notoffoffコマンドとしてnull 3番目のオクテットを使用したNoteonコマンドを検討するための規則と組み合わせて、コマンドごとに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.
実行ステータスコーディングは、音声コマンドにのみ使用されます。Streamでのシステム共通メッセージの存在は、次の音声コマンドの実行状態モードをキャンセルします。ただし、システムのリアルタイムメッセージでは、実行中のステータスモードをキャンセルしません。
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コマンドセットは、MIDI 1.0 DINケーブル[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ファイル（SMFS、[MIDI]）は、音楽パフォーマンスの統計用に最適化されたデルタエンコードスキームを使用して、各MIDIコマンドに明示的なタイムスタンプを追加します。SMFタイムスタンプは、通常、楽譜のメトリック表記を使用してタイミングをコーディングします。SMFメタイベントは、ファイルにテンポマップを追加するために使用されるため、スコアビートがレンダリング中に正確に秒単位に変換される可能性があります。
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では、セッションの説明にAudipecificConfigデータブロックが含まれる方法を説明して、MPEG4-GENERIC RTP MIDIストリームのMIDIレンダリングアルゴリズムを指定する方法について説明します。
The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. StructuredAudioSpecificConfig, a key data structure coded in AudioSpecificConfig, is defined in [MPEGSA].
audiospecificconfigのビットフィールド形式は[mpegaudio]で定義されています。audiospecificconfigでコード化された重要なデータ構造であるStructuredOudioSpecificConfigは、[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 renderers that may be specified in AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 (DLS 2, [DLS2]).
構造化されたオーディオレンダラーを指定したい実装者にとって、[MPEGSA]と[MPEGAUDIO]を完全に理解することが不可欠です。ただし、多くの実装者は、レンダリングオプションを、AudiospecificConfig：General Midi（GM、[MIDI]）およびダウンロード可能なサウンド2（DLS 2、[DLS2]）で指定できる2つのMIDI Manufacturers Association Renderersに制限します。
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レンダラーのAudipecificConfigビットフィールドフォーマットを以下に再現します。私たちはこれらのビットフィールドを慎重にチェックし、それらが正しいと信じています。ただし、以下の資料は有益であり、[mpegaudio]と[mpegsa]がaudipecificconfigの規範的定義であることを強調しています。
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-GENERICセッションの説明は、「構成」パラメーターに割り当てられる16進文字列（[rfc3640]で形式が[rfc3640]で定義されている）としてaudipecificconfigバイナリビットフィールドをエンコードします。付録C.6.3で説明したように、レンダリングパラメーターを使用するセッションの説明は、audipecificconfigバイナリビットフィールドを「インライン」パラメーターに割り当てられたbase64エンコード文字列として、または「URL」パラメーターに割り当てられたHTTP URLの本文でエンコードします。。
Below, we show a simplified binary AudioSpecificConfig bitfield format, suitable for sending and receiving GM and DLS 2 data:
以下に、GMおよびDLS 2データの送信と受信に適した、単純化されたバイナリAudiopificconfigビットフィールド形式を示します。
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-単純化されたaudipecificconfig
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-Generic RTP MIDIストリームで使用する法的価値は、「15」（一般MIDI）、「14」（DLS 2）、および「13」（構造化されたオーディオ）です。したがって、3つのMPEG4-GENERICレンダラーすべてをサポートしないレシーバーは、セッションの説明でコードされた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
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ビットチャネルフィールドは、レンダラーのオーディオチャネルの数を指定します。値0x1〜0x5は、1〜5のオーディオチャネルを指定します。値0x6は5 1サラウンドサウンドを指定し、値0x7は7 1サラウンドサウンドを指定します。セッションの説明のRTPMAP行がこれらの形式のいずれかを指定する場合、チャネルは対応する値に設定する必要があります。それ以外の場合、チャネルは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.
チャネルフィールドの後に、1つ以上のバイナリファイルデータブロックのリストが続きます。3ビットSACNKフィールド（[MPEGSA]で定義されているクラス構造のchunk_typeフィールド）は、各データブロックのタイプを指定します。
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_BLKフィールドには、図E.5に示されている形式があります：SMFまたはRIFFファイルのバイト数をコーディングする32-ビット符号なし整数値（file_len）に続いてファイルデータをコーディングするFile_lenバイトが続きます。
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 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.
いくつかのファイルがチャネルフィールドに従うことができることに注意してください。図E.3の「1」定数フィールドは、別のファイルの存在をコードします。「0」定数フィールドは、リストの最後をコードします。図E.3の最後の「0」ビットは、特別なコーディングツールがないことをコードします（詳細については[Mpegaudio]を参照）。これらのツールを使用していない送信者は、この「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.
構造化されたaudipecificconfigビットフィールド構造には、1つのfile_blkの存在が必要です。DLS 2のMPEG4-Generic RTP MIDI使用の場合、File_BlksはリフファイルまたはSMFファイルをコードする必要があります。MPEG4-GENERIC RTP MIDI一般MIDIの使用の場合、File_BlksはSMFファイルをコードする必要があります。デフォルトでは、このSMFは無視されます（付録C.6.4.1）。このデフォルトのケースでは、GM structuredOUDISISPECIFICCONFIG BITFILKは、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セッションの例で使用する構造的audipecificconfigを導き出します。図E.3を参照すると、GM、ATOYPE = 15の場合は、44,100 Hzのサンプルレート（freqIDX = 4）を使用し、モノ（チャネル= 1）であることに注意してください。GMの場合、図E.6（26バイトファイル）に示すSMFを使用して、単一のSMFがエンコードされています（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
<Track Chunk> = <chunk type> <length> <delta-time> <end-event>
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の例で使用されているaudipecificconfig
Expressing this bitfield as an ASCII hexadecimal string yields:
このビットフィールドをASCII 16進の文字列として表現すると、
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:
この文字列は、このメモの最小MPEG4-GENERIC一般MIDIの例の「config」パラメーターに割り当てられます（セクション6.2の例など）。この文字列をbase64 [rfc2045]で表現すると、
egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA
egoaaaaatvrozaaaaaaaaaaaabagbnvhjraaaabgd/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 Manufacturers Association。「完全な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.、Frederick、R。、およびV. Jacobson、「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] van der Meer、J.、Mackie、D.、Swaminathan、V.、Singer、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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[DLS2] MIDI Manufacturers Association. "The MIDI Downloadable Sounds Specification", v98.2, 1998.
[DLS2] MIDIメーカー協会。「MIDIダウンロード可能なサウンド仕様」、v98.2、1998。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、McGrew、D.、Naslund、M.、Carrara、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3388] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「セッション説明プロトコル（SDP）のメディアラインのグループ化」、RFC 3388、2002年12月。
[RP015] MIDI Manufacturers Association. "Recommended Practice 015 (RP-015): Response to Reset All Controllers", 11/98.
[RP015] MIDIメーカー協会。「推奨されるプラクティス015（RP-015）：すべてのコントローラーへのリセットへの応答」11/98。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555] Casner、S。およびP. Hoschka、「RTPペイロードフォーマットのMIMEタイプ登録」、RFC 3555、2003年7月。
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] Lazzaro、J。およびJ. Wawrzynek。「ネットワークミュージカルパフォーマンスのケース」、第11回ネットワークおよびオペレーティングシステムのデジタルオーディオおよびビデオのサポート（NossDav 2001）2001年6月25〜26日、ポートジェファーソン、ニューヨーク。
[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.
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、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, IEEE, Sept. 1990.
[Alf] Clark、D。D.およびD. L. Tennenhouse。「新世代のプロトコルに対する建築上の考慮事項」、コミュニケーションアーキテクチャとプロトコルに関するSigcommシンポジウム（フィラデルフィア、ペンシルベニア州）、pp。200--208、IEEE、1990年9月。
[RFC4696] Lazzaro, J. and J. Wawrzynek, "An Implementation Guide for RTP MIDI", RFC 4696, November 2006.
[RFC4696] Lazzaro、J。およびJ. Wawrzynek、「RTP MIDIの実装ガイド」、RFC 4696、2006年11月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC4289] Freed、N。およびJ. Klensin、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、BCP 13、RFC 4289、2005年12月。
[RFC4571] Lazzaro, J. "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571] Lazzaro、J。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony MIDI, Specification and Device Profiles", Document Version 1.0a, 2002.
[SPMIDI] MIDI Manufacturers Association。「スケーラブルポリフォニーミディ、仕様およびデバイスプロファイル」、ドキュメントバージョン1.0A、2002。
[LCP] Apple Computer. "Logic 7 Dedicated Control Surface Support", Appendix B. Product manual available from www.apple.com.
[LCP] Appleコンピューター。「Logic 7専用の制御表面サポート」、付録B. www.apple.comから入手できる製品マニュアル。
Authors' Addresses
著者のアドレス
John Lazzaro (corresponding author) UC Berkeley CS Division 315 Soda Hall Berkeley CA 94720-1776
ジョン・ラザロ（対応する著者）UCバークレーCS部門315ソーダホールバークレーCA 94720-1776
EMail: lazzaro@cs.berkeley.edu
John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley CA 94720-1776
John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley CA 94720-1776
EMail: johnw@cs.berkeley.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。