Internet Engineering Task Force (IETF) J. Lazzaro
Request for Comments: 6295 J. Wawrzynek
Obsoletes: 4695 UC Berkeley
Category: Standards Track June 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Lazzaro
Request for Comments: 6295 J. Wawrzynek
Obsoletes: 4695 UC Berkeley
Category: Standards Track June 2011
ISSN: 2070-1721
RTP Payload Format for MIDI
MIDI的RTP有效负载格式
Abstract
摘要
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695.
本备忘录描述了MIDI（乐器数字接口）命令语言的实时传输协议（RTP）有效负载格式。该格式对合法出现在MIDI 1.0 DIN电缆上的所有命令进行编码。该格式适用于交互式应用程序（如网络音乐表演）和内容交付应用程序（如文件流）。该格式可以在单播和多播UDP和TCP上使用，它定义了从数据包丢失中进行优雅恢复的工具。在会话设置期间，可以自定义流行为，包括MIDI渲染方法。该格式还可用作mpeg4通用格式的模式，以支持用于一般MIDI、可下载声音级别2和结构化音频的MPEG 4音频对象类型。本文件淘汰RFC 4695。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6295.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6295.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................6
1.2. Bitfield Conventions .......................................6
2. Packet Format ...................................................6
2.1. RTP Header .................................................7
2.2. MIDI Payload ..............................................11
3. MIDI Command Section ...........................................13
3.1. Timestamps ................................................14
3.2. Command Coding ............................................16
4. The Recovery Journal System ....................................22
5. Recovery Journal Format ........................................24
6. Session Description Protocol ...................................28
6.1. Session Descriptions for Native Streams ...................29
6.2. Session Descriptions for mpeg4-generic Streams ............30
6.3. Parameters ................................................33
7. Extensibility ..................................................34
8. Congestion Control .............................................35
9. Security Considerations ........................................35
10. Acknowledgements ..............................................36
11. IANA Considerations ...........................................37
11.1. rtp-midi Media Type Registration .........................38
11.1.1. Repository Request for audio/rtp-midi .............40
11.2. mpeg4-generic Media Type Registration ....................42
11.2.1. Repository Request for Mode rtp-midi for
mpeg4-generic .....................................44
11.3. asc Media Type Registration ..............................46
12. Changes from RFC 4695 .........................................48
Appendix A. The Recovery Journal Channel Chapters .................52
A.1. Recovery Journal Definitions ..............................52
A.2. Chapter P: MIDI Program Change ............................56
A.3. Chapter C: MIDI Control Change ............................57
A.3.1. Log Inclusion Rules ................................58
A.3.2. Controller Log Format ..............................59
A.3.3. Log List Coding Rules ..............................61
A.3.4. The Parameter System ...............................64
A.4. Chapter M: MIDI Parameter System ..........................66
A.4.1. Log Inclusion Rules ................................68
A.4.2. Log Coding Rules ...................................69
A.4.2.1. The Value Tool ..............................71
A.4.2.2. The Count Tool ..............................74
A.5. Chapter W: MIDI Pitch Wheel ...............................74
1. Introduction ....................................................4
1.1. Terminology ................................................6
1.2. Bitfield Conventions .......................................6
2. Packet Format ...................................................6
2.1. RTP Header .................................................7
2.2. MIDI Payload ..............................................11
3. MIDI Command Section ...........................................13
3.1. Timestamps ................................................14
3.2. Command Coding ............................................16
4. The Recovery Journal System ....................................22
5. Recovery Journal Format ........................................24
6. Session Description Protocol ...................................28
6.1. Session Descriptions for Native Streams ...................29
6.2. Session Descriptions for mpeg4-generic Streams ............30
6.3. Parameters ................................................33
7. Extensibility ..................................................34
8. Congestion Control .............................................35
9. Security Considerations ........................................35
10. Acknowledgements ..............................................36
11. IANA Considerations ...........................................37
11.1. rtp-midi Media Type Registration .........................38
11.1.1. Repository Request for audio/rtp-midi .............40
11.2. mpeg4-generic Media Type Registration ....................42
11.2.1. Repository Request for Mode rtp-midi for
mpeg4-generic .....................................44
11.3. asc Media Type Registration ..............................46
12. Changes from RFC 4695 .........................................48
Appendix A. The Recovery Journal Channel Chapters .................52
A.1. Recovery Journal Definitions ..............................52
A.2. Chapter P: MIDI Program Change ............................56
A.3. Chapter C: MIDI Control Change ............................57
A.3.1. Log Inclusion Rules ................................58
A.3.2. Controller Log Format ..............................59
A.3.3. Log List Coding Rules ..............................61
A.3.4. The Parameter System ...............................64
A.4. Chapter M: MIDI Parameter System ..........................66
A.4.1. Log Inclusion Rules ................................68
A.4.2. Log Coding Rules ...................................69
A.4.2.1. The Value Tool ..............................71
A.4.2.2. The Count Tool ..............................74
A.5. Chapter W: MIDI Pitch Wheel ...............................74
A.6. Chapter N: MIDI NoteOff and NoteOn ........................75
A.6.1. Header Structure ...................................77
A.6.2. Note Structures ....................................78
A.7. Chapter E: MIDI Note Command Extras .......................79
A.7.1. Note Log Format ....................................80
A.7.2. Log Inclusion Rules ................................80
A.8. Chapter T: MIDI Channel Aftertouch ........................81
A.9. Chapter A: MIDI Poly Aftertouch ..........................82
Appendix B. The Recovery Journal System Chapters ..................83
B.1. System Chapter D: Simple System Commands ..................83
B.1.1. Undefined System Commands .....................84
B.2. System Chapter V: Active Sense Command ....................87
B.3. System Chapter Q: Sequencer State Commands ................87
B.3.1. Non-Compliant Sequencers ......................89
B.4. System Chapter F: MIDI Time Code Tape Position ............90
B.4.1. Partial Frames ....................................93
B.5. System Chapter X: System Exclusive ........................94
B.5.1. Chapter Format ................................94
B.5.2. Log Inclusion Semantics .......................96
B.5.3. TCOUNT and COUNT Fields .......................99
Appendix C. Session Configuration Tools ....... ..................100
C.1. Configuration Tools: Stream Subsetting ...................101
C.2. Configuration Tools: The Journalling System ..............106
C.2.1. The j_sec Parameter ...............................106
C.2.2. The j_update Parameter ............................107
C.2.2.1. The anchor Sending Policy ..................108
C.2.2.2. The closed-loop Sending Policy .............109
C.2.2.3. The open-loop Sending Policy ...............113
C.2.3. Recovery Journal Chapter Inclusion Parameters .....114
C.3. Configuration Tools: Timestamp Semantics .................119
C.3.1. The comex Algorithm ...............................120
C.3.2. The async Algorithm ...............................121
C.3.3. The buffer Algorithm ..............................122
C.4. Configuration Tools: Packet Timing Tools .................123
C.4.1. Packet Duration Tools .............................123
C.4.2. The guardtime Parameter ...........................124
C.5. Configuration Tools: Stream Description ..................125
C.6. Configuration Tools: MIDI Rendering ......................131
C.6.1. The multimode Parameter ...........................132
C.6.2. Renderer Specification ............................133
C.6.3. Renderer Initialization ...........................135
C.6.4. MIDI Channel Mapping ..............................137
C.6.4.1. The smf_info Parameter .....................138
C.6.4.2. The smf_inline, smf_url, and smf_cid
Parameters .................................140
C.6.4.3. The chanmask Parameter .....................140
C.6.5. The audio/asc Media Type ..........................141
C.7. Interoperability .........................................143
A.6. Chapter N: MIDI NoteOff and NoteOn ........................75
A.6.1. Header Structure ...................................77
A.6.2. Note Structures ....................................78
A.7. Chapter E: MIDI Note Command Extras .......................79
A.7.1. Note Log Format ....................................80
A.7.2. Log Inclusion Rules ................................80
A.8. Chapter T: MIDI Channel Aftertouch ........................81
A.9. Chapter A: MIDI Poly Aftertouch ..........................82
Appendix B. The Recovery Journal System Chapters ..................83
B.1. System Chapter D: Simple System Commands ..................83
B.1.1. Undefined System Commands .....................84
B.2. System Chapter V: Active Sense Command ....................87
B.3. System Chapter Q: Sequencer State Commands ................87
B.3.1. Non-Compliant Sequencers ......................89
B.4. System Chapter F: MIDI Time Code Tape Position ............90
B.4.1. Partial Frames ....................................93
B.5. System Chapter X: System Exclusive ........................94
B.5.1. Chapter Format ................................94
B.5.2. Log Inclusion Semantics .......................96
B.5.3. TCOUNT and COUNT Fields .......................99
Appendix C. Session Configuration Tools ....... ..................100
C.1. Configuration Tools: Stream Subsetting ...................101
C.2. Configuration Tools: The Journalling System ..............106
C.2.1. The j_sec Parameter ...............................106
C.2.2. The j_update Parameter ............................107
C.2.2.1. The anchor Sending Policy ..................108
C.2.2.2. The closed-loop Sending Policy .............109
C.2.2.3. The open-loop Sending Policy ...............113
C.2.3. Recovery Journal Chapter Inclusion Parameters .....114
C.3. Configuration Tools: Timestamp Semantics .................119
C.3.1. The comex Algorithm ...............................120
C.3.2. The async Algorithm ...............................121
C.3.3. The buffer Algorithm ..............................122
C.4. Configuration Tools: Packet Timing Tools .................123
C.4.1. Packet Duration Tools .............................123
C.4.2. The guardtime Parameter ...........................124
C.5. Configuration Tools: Stream Description ..................125
C.6. Configuration Tools: MIDI Rendering ......................131
C.6.1. The multimode Parameter ...........................132
C.6.2. Renderer Specification ............................133
C.6.3. Renderer Initialization ...........................135
C.6.4. MIDI Channel Mapping ..............................137
C.6.4.1. The smf_info Parameter .....................138
C.6.4.2. The smf_inline, smf_url, and smf_cid
Parameters .................................140
C.6.4.3. The chanmask Parameter .....................140
C.6.5. The audio/asc Media Type ..........................141
C.7. Interoperability .........................................143
C.7.1. MIDI Content-Streaming Applications ...............144
C.7.2. MIDI Network Musical Performance Applications .....147
Appendix D. Parameter Syntax Definitions .... ....................153
Appendix E. A MIDI Overview for Networking Specialists ...........160
E.1. Commands Types ...........................................162
E.2. Running Status ...........................................163
E.3. Command Timing ...........................................163
E.4. AudioSpecificConfig Templates for MMA Renderers ..........164
References .......................................................169
Normative References ..........................................169
Informative References ........................................170
C.7.1. MIDI Content-Streaming Applications ...............144
C.7.2. MIDI Network Musical Performance Applications .....147
Appendix D. Parameter Syntax Definitions .... ....................153
Appendix E. A MIDI Overview for Networking Specialists ...........160
E.1. Commands Types ...........................................162
E.2. Running Status ...........................................163
E.3. Command Timing ...........................................163
E.4. AudioSpecificConfig Templates for MMA Renderers ..........164
References .......................................................169
Normative References ..........................................169
Informative References ........................................170
This document obsoletes [RFC4695].
本文件废除了[RFC4695]。
The Internet Engineering Task Force (IETF) has developed a set of focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261] [RFC2326]). These tools can be combined in different ways to support a variety of real-time applications over Internet Protocol (IP) networks.
互联网工程任务组（IETF）开发了一套多媒体网络专用工具（[RFC3550][RFC4566][RFC3261][RFC2326]）。这些工具可以以不同的方式组合在一起，以支持Internet协议（IP）网络上的各种实时应用程序。
For example, a telephony application might use the Session Initiation Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would include negotiations to agree on a common audio codec [RFC3264]. Negotiations would use the Session Description Protocol (SDP, [RFC4566]) to describe candidate codecs.
例如，电话应用程序可以使用会话启动协议（SIP，[RFC3261]）来设置电话呼叫。通话设置包括就通用音频编解码器[RFC3264]进行协商。协商将使用会话描述协议（SDP，[RFC4566]）来描述候选编解码器。
After a call is set up, audio data would flow between the parties using the Real Time Protocol (RTP, [RFC3550]) under any applicable profile (for example, the Audio/Visual Profile (AVP, [RFC3551])). The tools used in this telephony example (SIP, SDP, and RTP) might be combined in a different way to support a content-streaming application, perhaps in conjunction with other tools, such as the Real Time Streaming Protocol (RTSP, [RFC2326]).
建立呼叫后，音频数据将在任何适用的配置文件（例如，音频/视频配置文件（AVP，[RFC3551]）下使用实时协议（RTP，[RFC3550]）在各方之间流动。此电话示例中使用的工具（SIP、SDP和RTP）可以以不同的方式组合以支持内容流应用程序，可能与其他工具结合使用，例如实时流协议（RTSP、[RFC2326]）。
The MIDI (Musical Instrument Digital Interface) command language [MIDI] is widely used in musical applications that are analogous to the examples described above. On stage and in the recording studio, MIDI is used for the interactive remote control of musical instruments, an application similar in spirit to telephony. On web pages, Standard MIDI Files (SMFs, [MIDI]) rendered using the General MIDI standard [MIDI] provide a low-bandwidth substitute for audio streaming.
MIDI（乐器数字接口）命令语言[MIDI]广泛用于类似于上述示例的音乐应用中。在舞台上和录音室中，MIDI用于交互式遥控乐器，这一应用在精神上类似于电话技术。在网页上，使用通用MIDI标准[MIDI]呈现的标准MIDI文件（SMF[MIDI]）提供了音频流的低带宽替代品。
[RFC4695] was motivated by a simple premise: if MIDI performances could be sent as RTP streams that are managed by IETF session tools, a hybridization of the MIDI and IETF application domains might occur.
[RFC4695]的动机很简单：如果MIDI性能可以作为由IETF会话工具管理的RTP流发送，那么MIDI和IETF应用程序域可能会混合。
For example, interoperable MIDI networking might foster network music performance applications, in which a group of musicians located at different physical locations interact over a network to perform as they would if they were located in the same room [NMP]. As a second example, the streaming community might begin to use MIDI for low-bitrate audio coding, perhaps in conjunction with normative sound-synthesis methods [MPEGSA].
例如，可互操作的MIDI网络可能促进网络音乐表演应用，其中位于不同物理位置的一组音乐家通过网络进行交互，就像他们位于同一房间[NMP]中一样进行表演。作为第二个例子，流媒体社区可能开始将MIDI用于低比特率音频编码，可能与标准的声音合成方法[MPEGSA]结合使用。
Five years after [RFC4695], these applications have not yet reached the mainstream. However, experiments in academia and industry continue. This memo, which obsoletes [RFC4695] and fixes minor errata (see Section 12), has been written in service of these experiments.
[RFC4695]发布五年后，这些应用程序尚未进入主流。然而，学术界和工业界的实验仍在继续。本备忘录废除了[RFC4695]并修正了次要的勘误表（见第12节），是为这些实验服务而编写的。
To enable MIDI applications to use RTP, this memo defines an RTP payload format and its media type. Sections 2-5 and Appendices A and B define the RTP payload format. Section 6 and Appendices C and D define the media types identifying the payload format, the parameters needed for configuration, and the utilization of the parameters in SDP.
为了使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的另一个潜在应用领域是专业音频设备和电子乐器的MIDI网络。我们在此备忘录中不提供此应用程序的互操作性指南。然而，RTP MIDI的设计考虑到了舞台和演播室应用程序，我们希望定义舞台和演播室框架的工作将依赖于RTP MIDI的MIDI传输服务。
Some applications may require MIDI media delivery at a certain service quality level (latency, jitter, packet loss, etc.). RTP itself does not provide service guarantees. However, applications may use lower-layer network protocols to configure the quality of the transport services that RTP uses. These protocols may act to reserve network resources for RTP flows [RFC2205] or may simply direct RTP traffic onto a dedicated "media network" in a local installation. Note that RTP and the MIDI payload format do provide tools that applications may use to achieve the best possible real-time performance at a given service level.
某些应用程序可能需要在特定的服务质量级别（延迟、抖动、数据包丢失等）上提供MIDI媒体。RTP本身不提供服务保证。然而，应用程序可以使用较低层的网络协议来配置RTP使用的传输服务的质量。这些协议可以用于为RTP流[RFC2205]保留网络资源，或者可以简单地将RTP流量引导到本地安装中的专用“媒体网络”上。请注意，RTP和MIDI有效负载格式确实提供了一些工具，应用程序可以使用这些工具在给定的服务级别上实现最佳的实时性能。
This memo normatively defines the syntax and semantics of the MIDI payload format. However, this memo does not define algorithms for sending and receiving packets. An ancillary document [RFC4696]
本备忘录规范性地定义了MIDI有效负载格式的语法和语义。然而，本备忘录并未定义发送和接收数据包的算法。辅助文件[RFC4696]
provides informative guidance on algorithms. Supplemental information may be found in related conference publications [NMP] [GRAME].
提供有关算法的信息指导。补充信息可在相关会议出版物[NMP][GRAME]中找到。
Throughout this memo, the phrase "native stream" refers to a stream that uses the rtp-midi media type. The phrase "mpeg4-generic stream" refers to a stream that uses the mpeg4-generic media type (in mode rtp-midi) to operate in an MPEG 4 environment [RFC3640]. Section 6 describes this distinction in detail.
在本备忘录中，短语“本机流”指的是使用rtp midi媒体类型的流。短语“mpeg4通用流”指使用mpeg4通用媒体类型（在模式rtp midi中）在MPEG 4环境中操作的流[RFC3640]。第6节详细描述了这种区别。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Several bitfield coding idioms are used in this document. As most of these idioms only appear in Appendices A and B, we define them in Appendix A.1.
本文档中使用了几种位字段编码习惯用法。由于这些习语大多只出现在附录A和附录B中，我们在附录A.1中对它们进行了定义。
However, a few of these idioms also appear in the main text of this document. For convenience, we describe them below:
然而，其中一些习语也出现在本文的正文中。为方便起见，我们将其描述如下：
o R flag bit. R flag bits are reserved for future use. Senders MUST set R bits to 0. Receivers MUST ignore R bit values.
o R标志位。R标志位保留供将来使用。发件人必须将R位设置为0。接收器必须忽略R位值。
o LENGTH field. All fields named LENGTH (as distinct from LEN) code the number of octets in the structure that contains it, including the header it resides in and all hierarchical levels below it. If a structure contains a LENGTH field, a receiver MUST use the LENGTH field value to advance past the structure during parsing, rather than use knowledge about the internal format of the structure.
o 长度字段。所有名为LENGTH（与LEN不同）的字段编码包含它的结构中的八位字节数，包括它所在的头和它下面的所有层次结构级别。如果一个结构包含一个长度字段，那么接收者必须在解析期间使用长度字段值来超越该结构，而不是使用有关结构内部格式的知识。
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数据包的格式。该描述包括一些关于RTP的背景信息，以利于IETF工具的新MIDI实现者。实施者应参考[RFC3550]了解RTP的权威性描述。
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个语音通道+系统）映射到RTP流。RTP媒体流是共享公共格式的逻辑数据包序列。每个数据包由两部分组成：RTP报头和MIDI有效负载。图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].
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].translate error, please retry
[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标头字段的完整说明。在本节中，我们将阐明几个RTP头字段在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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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通用流，所有数据包的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
在RTP MIDI流中，16位序列号字段初始化为随机选择的值，并为流中发送的每个数据包递增1（模2^16）。相关的
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.
可通过跟踪16位序列号的翻转来计算32位扩展分组序列号的数量。注意，同一流的不同接收机可以计算不同的扩展分组序列号，这取决于接收机何时加入会话。
The 32-bit timestamp field sets the base timestamp value for the packet. The payload codes MIDI command timing relative to this value. The timestamp units are set by the clock rate parameter. For example, if the clock rate has a value of 44100 Hz, two packets whose base timestamp values differ by 2 seconds have RTP timestamp fields that differ by 88200.
32位时间戳字段设置数据包的基本时间戳值。有效负载编码与此值相关的MIDI命令定时。时间戳单位由时钟速率参数设置。例如，如果时钟速率具有44100 Hz的值，则其基本时间戳值相差2秒的两个分组具有相差88200的RTP时间戳字段。
Note that the clock rate parameter is not encoded within each RTP MIDI packet. A receiver of an RTP MIDI stream becomes aware of the clock rate as part of the session setup process. For example, if a session management tool uses the Session Description Protocol (SDP, [RFC4566]) to describe a media session, the clock rate parameter is set using the rtpmap attribute. We show examples of session setup in Section 6.
请注意，时钟速率参数不是在每个RTP MIDI数据包中编码的。作为会话设置过程的一部分，RTP MIDI流的接收器会意识到时钟速率。例如，如果会话管理工具使用会话描述协议（SDP[RFC4566]）来描述媒体会话，则使用rtpmap属性设置时钟速率参数。我们在第6节中展示了会话设置的示例。
For RTP MIDI streams destined to be rendered into audio, the clock rate SHOULD be an audio sample rate of 32 KHz or higher. This recommendation is due to the sensitivity of human musical perception to small timing errors in musical note sequences and due to the timbral changes that occur when two near-simultaneous MIDI NoteOns are rendered with a different timing than that desired by the content author due to clock rate quantization. RTP MIDI streams that are not destined for audio rendering (such as MIDI streams that control stage lighting) MAY use a lower clock rate but SHOULD use a clock rate high enough to avoid timing artifacts in the application.
对于要渲染成音频的RTP MIDI流，时钟频率应为32 KHz或更高的音频采样率。此建议是由于人类音乐感知对音符序列中的小时间误差的敏感性，以及由于时钟速率量化，当两个几乎同时出现的MIDI音符以不同于内容作者所期望的时间呈现时，会发生音色变化。不用于音频渲染的RTP MIDI流（例如控制舞台灯光的MIDI流）可以使用较低的时钟速率，但应该使用足够高的时钟速率，以避免应用程序中的定时伪影。
For RTP MIDI streams destined to be rendered into audio, the clock rate SHOULD be chosen from rates in common use in professional audio applications or in consumer audio distribution. At the time of this writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a part of a synchronized media session that includes another (non-MIDI) RTP audio stream with a clock rate of 32 KHz or higher, the RTP MIDI stream SHOULD use a clock rate that matches the clock rate of the other audio stream. However, if the RTP MIDI stream is destined to be rendered into audio, the RTP MIDI stream SHOULD NOT use a clock rate lower than 32 KHz, even if this second stream has a clock rate lower than 32 KHz.
对于要渲染成音频的RTP MIDI流，时钟速率应从专业音频应用程序或消费者音频分发中常用的速率中选择。在撰写本文时，这些速率包括32 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流不应使用低于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
连续数据包的时间戳不一定以固定速率递增，因为RTP MIDI数据包不一定以固定速率发送。包传输规律性的程度反映了
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.
底层应用程序动态。交互式应用程序可以改变分组发送速率以跟踪人类表演者的手势速率，而内容流应用程序可以以固定速率发送分组。
Therefore, the timestamps for two sequential RTP packets may be identical, or the second packet may have a timestamp arbitrarily larger than the first packet (modulo 2^32). Section 3 places additional restrictions on the RTP timestamps for two sequential RTP packets, as does the guardtime parameter (Appendix C.4.2).
因此，两个连续RTP分组的时间戳可以相同，或者第二分组的时间戳可以任意大于第一分组（模2^32）。第3节对两个连续RTP数据包的RTP时间戳进行了额外限制，正如guardtime参数（附录C.4.2）一样。
We use the term "media time" to denote the temporal duration of the media coded by an RTP packet. The media time coded by a packet is computed by subtracting the last command timestamp in the MIDI command section from the RTP timestamp (modulo 2^32). If the MIDI list of the MIDI command section of a packet is empty, the media time coded by the packet is 0 ms. Appendix C.4.1 discusses media time issues in detail.
我们使用术语“媒体时间”来表示由RTP包编码的媒体的时间持续时间。通过从RTP时间戳（模2^32）中减去MIDI命令部分中的最后一个命令时间戳来计算由数据包编码的媒体时间。如果数据包MIDI命令部分的MIDI列表为空，则数据包编码的媒体时间为0毫秒。附录C.4.1详细讨论了媒体时间问题。
We now define RTP session semantics, in the context of sessions specified using the Session Description Protocol [RFC4566]. A session description media line ("m=") specifies an RTP session. An RTP session has an independent space of 2^32 synchronization sources. Synchronization source identifiers are coded in the SSRC header field of RTP session packets. The payload types that may appear in the PT header field of RTP session packets are listed at the end of the media line.
现在，我们在使用会话描述协议[RFC4566]指定的会话上下文中定义RTP会话语义。会话描述媒体行（“m=”）指定RTP会话。RTP会话有2^32个同步源的独立空间。同步源标识符编码在RTP会话数据包的SSRC头字段中。可能出现在RTP会话分组的PT报头字段中的有效负载类型列在媒体行的末尾。
Several RTP MIDI streams may appear in an RTP session. Each stream is distinguished by a unique SSRC value and has a unique sequence number and RTP timestamp space. Multiple streams in the RTP session may be sent by a single party. Multiple parties may send streams in the RTP session. An RTP MIDI stream encodes data for a single MIDI command name space (16 voice channels + systems).
RTP会话中可能会出现多个RTP MIDI流。每个流由唯一的SSRC值区分，并且具有唯一的序列号和RTP时间戳空间。RTP会话中的多个流可以由一方发送。多方可以在RTP会话中发送流。RTP MIDI流为单个MIDI命令名称空间（16个语音通道+系统）编码数据。
Streams in an RTP session may use different payload types or they may use the same payload type. However, each party may send, at most, one RTP MIDI stream for each payload type mapped to an RTP MIDI payload format in an RTP session. Recall that dynamic binding of payload type numbers in [RFC4566] lets a party map many payload type numbers to the RTP MIDI payload format; thus, a party may send many RTP MIDI streams in a single RTP session. Pairs of streams (unicast or multicast) that communicate between two parties in an RTP session and that share a payload type have the same association as a MIDI cable pair that cross-connects two devices in a MIDI 1.0 DIN network.
RTP会话中的流可以使用不同的有效负载类型，也可以使用相同的有效负载类型。然而，对于RTP会话中映射到RTP MIDI有效负载格式的每个有效负载类型，各方最多可以发送一个RTP MIDI流。回想一下，[RFC4566]中有效负载类型号的动态绑定允许一方将许多有效负载类型号映射到RTP MIDI有效负载格式；因此，一方可以在单个RTP会话中发送多个RTP MIDI流。在RTP会话中双方之间进行通信并共享有效负载类型的流对（单播或多播）与跨连接MIDI 1.0 DIN网络中两个设备的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会话体系结构在使用网络端口方面非常有效，因为一个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]）发送方报告中编码的定时字段来同步一方发送的流。RTP会话中每个流的SSRC值也是单独随机选择的，如[RFC3550]中所述。接收方使用RTCP发送方报告中编码的CNAME字段来验证流是否由同一方发送，并检测SSRC冲突，如[RFC3550]中所述。
In some applications, a receiver renders MIDI commands into audio (or into control actions, such as the rewind of a tape deck or the dimming of stage lights). In other applications, a receiver presents a MIDI stream to software programs via an Application Programming Interface (API). Appendix C.6 defines session configuration tools to specify what receivers should do with a MIDI command stream.
在某些应用程序中，接收器将MIDI命令呈现为音频（或控制动作，如磁带组倒带或舞台灯光变暗）。在其他应用中，接收器通过应用程序编程接口（API）向软件程序提供MIDI流。附录C.6定义了会话配置工具，以指定接收器应如何处理MIDI命令流。
If a multimedia session uses different RTP MIDI streams to send different classes of media, the streams MUST be sent over different RTP sessions. For example, if a multimedia session uses one MIDI stream for audio and a second MIDI stream to control a lighting system, the audio and lighting streams MUST be sent over different RTP sessions, each with its own media line.
如果多媒体会话使用不同的RTP MIDI流发送不同类别的媒体，则流必须通过不同的RTP会话发送。例如，如果多媒体会话使用一个用于音频的MIDI流和第二个用于控制照明系统的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.
这些规则允许接收器识别共享MIDI名称空间的流（通过匹配SSRC值），还允许接收器准确地重构源MIDI命令流（通过使用RTP时间戳来交错来自两个流的命令）。发送方必须注意确保冲突引起的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流。然而，有时通过不同的RTP会话发送两个RTP MIDI流是有利的。例如，两个流可能需要不同的RTP会话级属性值（例如sendonly和RecVoOnly属性）。作为第二个示例，可能需要两个RTP会话来发送源自不同计算机（具有不同IP号）的多媒体会话中的两个单播流。在这种情况下需要两个RTP会话，因为传输地址是在RTP会话或多媒体会话级别上指定的，而不是在有效负载类型级别上指定的。
On a final note, in some uses of MIDI, parties send bidirectional traffic to conduct transactions (such as file exchange). These commands were designed to work over MIDI 1.0 DIN cable networks and may be configured in a multicast topology, which uses pure "party-line" signalling. Thus, if a multimedia session ensures a multicast connection between all parties, bidirectional MIDI commands will work without additional support from the RTP MIDI payload format.
最后，在MIDI的某些使用中，各方发送双向通信来进行事务（如文件交换）。这些命令设计用于在MIDI 1.0 DIN电缆网络上工作，并且可以在多播拓扑中配置，该拓扑使用纯“第三方线路”信令。因此，如果多媒体会话确保各方之间的多播连接，则双向MIDI命令将在没有来自RTP MIDI有效负载格式的额外支持的情况下工作。
The payload (Figure 1) MUST begin with the MIDI command section. The MIDI command section codes a (possibly empty) list of timestamped MIDI commands and provides the essential service of the payload format.
有效负载（图1）必须从MIDI命令部分开始。MIDI命令部分对时间戳MIDI命令列表进行编码（可能为空），并提供有效负载格式的基本服务。
The payload MAY also contain a journal section. The journal section provides resiliency by coding the recent history of the stream. A flag in the MIDI command section codes the presence of a journal section in the payload.
有效载荷还可能包含日志部分。日志部分通过对流的最近历史记录进行编码来提供弹性。MIDI命令部分中的标志对有效负载中是否存在日志部分进行编码。
Section 3 defines the MIDI command section. Sections 4 and 5 and Appendices A and B define the recovery journal, the default format for the journal section. Here, we describe how these payload sections operate in a stream in an RTP session.
第3节定义了MIDI命令部分。第4节和第5节以及附录A和B定义了恢复日志，这是日志部分的默认格式。这里，我们描述这些有效负载部分如何在RTP会话的流中操作。
The journalling method for a stream is set at the start of a session and MUST NOT be changed thereafter. A stream may be set to use the recovery journal, to use an alternative journal format (none are defined in this memo), or not to use a journal.
流的日志记录方法在会话开始时设置，此后不得更改。可以将流设置为使用恢复日志、使用替代日志格式（本备忘录中未定义任何格式）或不使用日志。
The default journalling method of a stream is inferred from its transport type. Streams that use unreliable transport (such as UDP) default to using the recovery journal. Streams that use reliable transport (such as TCP) default to not using a journal. Appendix C.2.1 defines session configuration tools for overriding these defaults. For all types of transport, a sender MUST transmit an RTP packet stream with consecutive sequence numbers (modulo 2^16).
流的默认日志记录方法是从其传输类型推断出来的。使用不可靠传输（如UDP）的流默认使用恢复日志。使用可靠传输（如TCP）的流默认不使用日志。附录C.2.1定义了覆盖这些默认值的会话配置工具。对于所有类型的传输，发送方必须传输具有连续序列号（模2^16）的RTP数据包流。
If a stream uses the recovery journal, every payload in the stream MUST include a journal section. If a stream does not use journalling, a journal section MUST NOT appear in a stream payload. If a stream uses an alternative journal format, the specification for the journal format defines an inclusion policy.
如果流使用恢复日志，则流中的每个有效负载必须包括日志部分。如果流不使用日志记录，则日志部分不得出现在流有效负载中。如果流使用替代日志格式，则日志格式的规范将定义包含策略。
If a stream is sent over UDP transport, the Maximum Transmission Unit (MTU) of the underlying network limits the practical size of the payload section (for example, an Ethernet MTU is 1500 octets) for applications where predictable and minimal packet transmission latency is critical. A sender SHOULD NOT create RTP MIDI UDP packets whose sizes exceed the MTU of the underlying network. Instead, the sender SHOULD take steps to keep the maximum packet size under the MTU limit.
如果流通过UDP传输发送，则底层网络的最大传输单元（MTU）将限制有效负载部分的实际大小（例如，以太网MTU为1500个八位字节），以适用于需要可预测和最小数据包传输延迟的应用。发送方不应创建大小超过基础网络MTU的RTP MIDI UDP数据包。相反，发送方应该采取措施将最大数据包大小保持在MTU限制之下。
These steps may take many forms. The default closed-loop recovery journal sending policy (defined in Appendix C.2.2.2) uses RTP Control Protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size. In addition, Section 3.2 and Appendix B.5.2 provide specific tools for managing the size of packets that code MIDI System Exclusive (0xF0) commands. Appendix C.5 defines session configuration tools that may be used to split a dense MIDI name space into several UDP streams (each sent in a different RTP session, per Section 2.1) so that the payload fits comfortably into an MTU. Another option is to use TCP. Section 4.3 of [RFC4696] provides non-normative advice for packet size management.
这些步骤可能有多种形式。默认闭环恢复日志发送策略（在附录C.2.2.2中定义）使用RTP控制协议（RTCP，[RFC3550]）反馈来管理RTP MIDI数据包大小。此外，第3.2节和附录B.5.2提供了用于管理编码MIDI系统专用（0xF0）命令的数据包大小的特定工具。附录C.5定义了会话配置工具，这些工具可用于将密集MIDI名称空间分割为多个UDP流（根据第2.1节，每个UDP流在不同的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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|J|Z|P|LEN... | MIDI list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 -- MIDI Command Section
图2——MIDI命令部分
The MIDI command section begins with a variable-length header.
MIDI命令部分以可变长度的头开始。
The header field LEN codes the number of octets in the MIDI list that follow the header. If the header flag B is 0, the header is one octet long, and LEN is a 4-bit field, supporting a maximum MIDI list length of 15 octets.
标题字段LEN编码MIDI列表中紧跟标题的八位字节数。如果标头标志B为0，则标头为一个八位字节长，LEN为4位字段，支持最大15个八位字节的MIDI列表长度。
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，则报头为两个八位字节长，LEN为12位字段，支持最大的MIDI列表长度4095个八位字节。LEN按网络字节顺序（big-endian）编码：出现在第一个报头八位字节码中的4位LEN，即12位LEN值的最高有效4位。
A LEN value of 0 is legal, and it codes an empty MIDI list.
LEN值为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.
如果lenheader字段为非零，那么MIDI列表的结构如图3所示。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 0 (1-4 octets long, or 0 octets if Z = 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 0 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 1 (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 1 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time N (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command N (0 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 0 (1-4 octets long, or 0 octets if Z = 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 0 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 1 (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 1 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time N (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command N (0 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 -- MIDI List Structure
图3——MIDI列表结构
If the header flag Z is 1, the MIDI list begins with a complete MIDI command (coded in the MIDI Command 0 field in Figure 3) preceded by a delta time (coded in the Delta Time 0 field). If Z is 0, the Delta Time 0 field is not present in the MIDI list, and the command coded in the MIDI Command 0 field has an implicit delta time of 0.
如果标题标志Z为1，则MIDI列表以完整的MIDI命令（在图3中的MIDI命令0字段中编码）开始，然后是增量时间（在增量时间0字段中编码）。如果Z为0，则MIDI列表中不存在增量时间0字段，并且MIDI命令0字段中编码的命令具有隐式增量时间0。
The MIDI list structure may also optionally encode a list of N additional complete MIDI commands, each coded in a MIDI Command K field. Each additional command MUST be preceded by a Delta Time K field, which codes the command's delta time. We discuss exceptions to the "command fields code complete MIDI commands" rule in Section 3.2.
MIDI列表结构还可以选择性地编码N个附加完整MIDI命令的列表，每个命令在MIDI命令K字段中编码。每个附加命令之前必须有一个增量时间K字段，该字段对命令的增量时间进行编码。我们将在第3.2节中讨论“命令字段代码完整MIDI命令”规则的例外情况。
The final MIDI command field (i.e., the MIDI Command N field, shown in Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list MAY consist of a single delta time (encoded in the Delta Time 0 field) without an associated command (which would have been encoded in the MIDI Command 0 field). These rules enable MIDI coding features that are explained in Section 3.1. We delay the explanations because an understanding of RTP MIDI timestamps is necessary to describe the features.
MIDI列表中的最后一个MIDI命令字段（即MIDI命令N字段，如图3所示）可能为空。此外，MIDI列表可能由单个增量时间（在增量时间0字段中编码）组成，而没有相关命令（在MIDI命令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增量时间语法是MIDI文件增量时间语法[MIDI]的一种修改形式。RTP MIDI增量时间使用1-4个八位字段对32位无符号整数进行编码。图4显示了增量时间的编码和解码形式。注意，增量时间值可以合法地以多种格式编码；例如，有四种合法的方式来编码零增量时间（0x00、0x8000、0x808000、0x808000）。
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时间戳和解码的增量时间0到K的总和（模2^32）。这种从MIDI文件增量时间编码借用的累积编码技术是有效的，因为它减少了多个八位组的增量时间。
All command timestamps in a packet MUST be less than or equal to the RTP timestamp of the next packet in the stream (modulo 2^32).
数据包中的所有命令时间戳必须小于或等于流中下一个数据包的RTP时间戳（模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数据包头中编码的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 Command N”字段（第3节的序言明确规定为合法的语法结构），可以用保证没有MIDI命令的时间“填充”RTP MIDI包的结尾。
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.
默认情况下，命令时间戳指示命令的执行时间。两个时间戳之间的差异表示命令执行之间的时间延迟。此差异可能为零，编码同时执行。在本备忘录中，我们将时间戳的这种解释称为“comex”（命令执行）语义。我们在附录C.3中正式定义了comex语义。
The comex interpretation of timestamps works well for transcoding a Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a timestamp for each MIDI command stored in the file. To transcode an SMF that uses metric time markers, use the SMF tempo map (encoded in the SMF as meta-events) to convert metric SMF timestamp units into seconds-based RTP timestamp units.
comex对时间戳的解释适用于将标准MIDI文件（SMF）转换为RTP MIDI流，因为SMF为文件中存储的每个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流的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电缆）的MIDI源代码转换为RTP MIDI流的最佳时间戳解释。附录C.3定义了comex语义的替代方案，并描述了用于选择流的时间戳解释语义的会话配置工具。
One-Octet Delta Time:
一个八位组增量时间：
Encoded form: 0ddddddd Decoded form: 00000000 00000000 00000000 0ddddddd
编码形式：0DDDDD解码形式：00000000 00000000 00000000 0DDDDD
Two-Octet Delta Time:
两个八位组增量时间：
Encoded form: 1ccccccc 0ddddddd Decoded form: 00000000 00000000 00cccccc cddddddd
编码形式：1CCCCC 0DDDDD解码形式：00000000 00000000 CCCCCC CDDDDD
Three-Octet Delta Time:
三个八位组增量时间：
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 00000000 000bbbbb bbcccccc cddddddd
编码形式：1BBBBBB 1CCCCCC 0DDDDD解码形式：000000000BBBBB BBCCCCC CDDDDD
Four-Octet Delta Time:
四个八位组增量时间：
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
编码形式：1AAAAA 1BBBBBB 1CCCCCC 0DDDDD解码形式：0000aaaa AAABBB BBCCCCC CDDDDD
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
MIDI列表中的每个非空MIDI命令字段对合法出现在MIDI 1.0 DIN电缆上的一种MIDI命令类型进行编码。标准MIDI文件元事件不符合此定义，不能出现在MIDI列表中。通常，每个MIDI命令字段
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]中定义的二进制命令格式对完整命令进行编码。在本节的其余部分中，我们将介绍此规则的例外情况。
The first MIDI channel command in the MIDI list MUST include a status octet. Running status coding, as defined in [MIDI], MAY be used for all subsequent MIDI channel commands in the list. As in [MIDI], System Common and System Exclusive messages (0xF0 ... 0xF7) cancel the running status state, but System Real-Time messages (0xF8 ... 0xFF) do not affect the running status state. All system commands in the MIDI list MUST include a status octet.
MIDI列表中的第一个MIDI通道命令必须包含状态八位字节。[MIDI]中定义的运行状态编码可用于列表中的所有后续MIDI通道命令。与[MIDI]中一样，系统公用和系统专用消息（0xF0…0xF7）取消运行状态，但系统实时消息（0xF8…0xFF）不影响运行状态。MIDI列表中的所有系统命令必须包含状态八位字节。
As we note above, the first channel command in the MIDI list MUST include a status octet. However, the corresponding command in the original MIDI source data stream might not have a status octet (in this case, the source would be coding the command using running status). If the status octet of the first channel command in the MIDI list does not appear in the source data stream, the P (phantom) header bit MUST be set to 1. In all other cases, the P bit MUST be set to 0.
如上所述，MIDI列表中的第一个通道命令必须包含状态八位字节。但是，原始MIDI源数据流中的相应命令可能没有状态八位字节（在这种情况下，源将使用运行状态对命令进行编码）。如果MIDI列表中第一个通道命令的状态八位字节未出现在源数据流中，则P（幻像）头位必须设置为1。在所有其他情况下，P位必须设置为0。
Note that the P bit describes the MIDI source data stream, not the MIDI list encoding; regardless of the state of the P bit, the MIDI list MUST include the status octet.
注意，P位描述MIDI源数据流，而不是MIDI列表编码；无论P位的状态如何，MIDI列表必须包含状态八位字节。
As receivers MUST be able to decode running status, sender implementors should feel free to use running status to improve bandwidth efficiency. However, senders SHOULD NOT introduce timing jitter into an existing MIDI command stream through an inappropriate use or removal of running status coding. This warning primarily applies to senders whose RTP MIDI streams may be transcoded onto a MIDI 1.0 DIN cable [MIDI] by the receiver: both the timestamps and the command coding (running status or not) must comply with the physical restrictions of implicit time coding over a slow serial line.
由于接收者必须能够解码运行状态，发送者实现者应该可以随意使用运行状态来提高带宽效率。但是，发送方不应通过不适当地使用或删除运行状态编码，将定时抖动引入现有MIDI命令流。此警告主要适用于其RTP MIDI流可能被接收器转码到MIDI 1.0 DIN电缆[MIDI]上的发送方：时间戳和命令编码（运行状态与否）都必须符合慢速串行线路上隐式时间编码的物理限制。
On a MIDI 1.0 DIN cable [MIDI], a System Real-Time command may be embedded inside of another "host" MIDI command. This syntactic construction is not supported in the payload format: a MIDI Command field in the MIDI list codes exactly one MIDI command (partially or completely).
在MIDI 1.0 DIN电缆[MIDI]上，系统实时命令可以嵌入另一个“主机”MIDI命令中。有效负载格式不支持这种语法结构：MIDI列表中的MIDI命令字段只编码一个MIDI命令（部分或全部）。
To encode an embedded System Real-Time command, senders MUST extract the command from its host and code it in the MIDI list as a separate command. The host command and System Real-Time command SHOULD appear in the same MIDI list. The delta time of the System Real-Time command SHOULD result in a command timestamp that encodes the System Real-Time command placement in its original embedded position.
要对嵌入式系统实时命令进行编码，发送者必须从其主机提取该命令，并在MIDI列表中将其作为单独的命令进行编码。主机命令和系统实时命令应出现在同一MIDI列表中。系统实时命令的增量时间应产生一个命令时间戳，对系统实时命令在其原始嵌入位置的放置进行编码。
Two methods are provided for encoding MIDI System Exclusive (SysEx) commands in the MIDI list. A SysEx command may be encoded in a MIDI Command field verbatim: a 0xF0 octet, followed by an arbitrary number of data octets, followed by a 0xF7 octet.
提供了两种方法来编码MIDI列表中的MIDI系统独占（SysEx）命令。SysEx命令可以在MIDI命令字段中逐字编码：0xF0八位字节，后跟任意数量的数据八位字节，后跟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命令可以编码为多个段。该命令分为两个或多个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命令进行编码，该命令以数据八位字节的时间模式对信息进行编码。通过将这些命令编码为一系列段，每个数据八位组可以与不同的增量时间相关联。分段还支持跨多个数据包对大型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命令，首先将其数据八位组列表划分为两个或多个子列表。最后一个子列表可能为空（即不包含八位字节）；所有其他子列表必须至少包含一个数据八位字节。为了完成分割，将图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所示的“cancel”子列表来取消正在进行的分段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命令的配置工具。在这些约束条件下将MIDI源代码转换为RTP 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命令转码到RTP MIDI数据包上，以便在传输之前验证每个SysEx命令。
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
建议的接收器对取消的反应取决于接收器的能力。例如，直接解析RTP MIDI数据包并将其呈现为音频的声音合成器将
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中，SysEx命令可能会被取消。这些接收器应该在MIDI列表中检测到SysEx取消，并表现得好像从未收到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.
作为第二示例，合成器可以通过MIDI-DIN电缆（或MIDI-DIN电缆的软件API仿真）从RTP MIDI流接收MIDI数据。在这种情况下，RTP MIDI感知系统接收RTP MIDI流并将其转码到MIDI DIN电缆（或其仿真）上。在收到cancel子列表后，RTP MIDI感知转码器可能已经通过MIDI DIN电缆将SysEx命令的第一部分发送到接收器。
Unfortunately, the MIDI DIN cable protocol cannot directly code "cancel SysEx in progress" semantics. However, MIDI DIN cable receivers begin SysEx processing after the complete command arrives. The receiver checks to see if it recognizes the command (coded in the first few octets) and then checks to see if the command is the correct length. Thus, in practice, a transcoder can cancel a SysEx command by sending an 0xF7 to (prematurely) end the SysEx command -- the receiver will detect the incorrect command length and discard the command.
不幸的是，MIDI DIN电缆协议无法直接编码“cancel SysEx in progress”语义。但是，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命令的命令段放置在两个或多个RTP数据包的MIDI列表中，则段顺序规则适用于所有受影响的MIDI列表的串联。
-----------------------------------------------------------
| Sublist Position | Head Status Octet | Tail Status Octet |
|-----------------------------------------------------------|
| first | 0xF0 | 0xF0 |
|-----------------------------------------------------------|
| middle | 0xF7 | 0xF0 |
|-----------------------------------------------------------|
| last | 0xF7 | 0xF7 |
|-----------------------------------------------------------|
| cancel | 0xF7 | 0xF4 |
-----------------------------------------------------------
-----------------------------------------------------------
| 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]允许不属于（0xF0，0xF7）对的0xF7八位字节出现在MIDI 1.0 DIN电缆上。除了取消运行状态外，未配对的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命令可以使用“DROPED 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命令末尾插入“droped”0xF7八位字节，以形成标准SysEx语法。
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 将终止逐字系统编码的0xF7八位字节或分段系统编码的最后一段替换为0xF5八位字节。此替换通知接收器原始的“删除的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命令字段中，用于编码“删除的0xF7”结构的0xF5八位字节和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 the "middle" or "last" sublist of a segmented SysEx command (Figure 5) under certain packet loss conditions.
请注意，我们在模型中包括了尾随八位字节作为一种警告措施：如果此类命令出现在未定义的系统公共命令的不符合使用中，则未删除尾随八位字节的命令的RTP MIDI编码可能会被误认为是分段SysEx命令的“中间”或“最后”子列表的编码（图5）在某些丢包情况下。
Original SysEx command:
原始SysEx命令：
0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7
0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7
A two-segment segmentation:
两段分割：
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:
不同的两段分割：
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:
A三段分割：
0xF0 0x01 0x02 0xF0
0xF0 0x01 0x02 0xF0
0xF7 0x03 0x04 0xF0
0xF7 0x03 0x04 0xF0
0xF7 0x05 0x06 0x07 0x08 0xF7
0xF7 0x05 0x06 0x07 0x08 0xF7
The segmentation with the largest number of segments:
具有最大分段数的分段：
0xF0 0x01 0xF0
0xF0 0x01 0xF0
0xF7 0x02 0xF0
0xF7 0x02 0xF0
0xF7 0x03 0xF0
0xF7 0x03 0xF0
0xF7 0x04 0xF0
0xF7 0x04 0xF0
0xF7 0x05 0xF0
0xF7 0x05 0xF0
0xF7 0x06 0xF0
0xF7 0x06 0xF0
0xF7 0x07 0xF0
0xF7 0x07 0xF0
0xF7 0x08 0xF0
0xF7 0x08 0xF0
0xF7 0xF7
0xF7 0xF7
Figure 6 -- Example Segmentations
图6——分段示例
The recovery journal is the default resiliency tool for unreliable transport. In this section, we normatively define the roles that senders and receivers play in the recovery journal system.
恢复日志是不可靠传输的默认恢复工具。在本节中，我们规范地定义了发送方和接收方在恢复日志系统中所扮演的角色。
MIDI is a fragile code. A single lost command in a MIDI command stream may produce an artifact in the rendered performance. We normatively classify rendering artifacts into two categories:
MIDI是一个脆弱的代码。MIDI命令流中单个丢失的命令可能会在渲染性能中产生伪影。我们规范地将渲染工件分为两类：
o Transient artifacts. Transient artifacts produce immediate but short-term glitches in the performance. For example, a lost NoteOn (0x9) command produces a transient artifact: one note fails to play, but the artifact does not extend beyond the end of that note.
o 瞬时伪影。瞬态工件会在性能中产生即时但短期的故障。例如，lostnoteon（0x9）命令会产生一个暂时的伪影：一个音符无法播放，但伪影不会延伸到该音符的末尾。
o Indefinite artifacts. Indefinite artifacts produce long-lasting errors in the rendered performance. For example, a lost NoteOff (0x8) command may produce an indefinite artifact: the note that should have been ended by the lost NoteOff command may sustain indefinitely. As a second example, the loss of a Control Change (0xB) command for controller number 7 (Channel Volume) may produce an indefinite artifact: after the loss, all notes on the channel may play too softly or too loudly.
o 不确定的人工制品。不确定的瑕疵会在渲染性能中产生长期错误。例如，lost NoteOff（0x8）命令可能会产生一个不确定的工件：应该由lost NoteOff命令结束的注释可能会无限期地持续。作为第二个示例，控制器编号7（通道音量）的控制更改（0xB）命令丢失可能会产生不确定的伪影：丢失后，通道上的所有音符可能播放得太轻或太大声。
The purpose of the recovery journal system is to satisfy the recovery journal mandate: the MIDI performance rendered from an RTP MIDI stream sent over unreliable transport MUST NOT contain indefinite artifacts.
恢复日志系统的目的是满足恢复日志的要求：通过不可靠传输发送的RTP MIDI流呈现的MIDI性能不得包含不确定的伪影。
The recovery journal system does not use packet retransmission to satisfy this mandate. Instead, each packet includes a special section called the recovery journal.
恢复日志系统不使用数据包重传来满足此要求。相反，每个数据包都包含一个称为恢复日志的特殊部分。
The recovery journal codes the history of the stream back to an earlier packet called the checkpoint packet. The range of coverage for the journal is called the checkpoint history. The recovery journal codes the information necessary to recover from the loss of an arbitrary number of packets in the checkpoint history. Appendix A.1 normatively defines the checkpoint history.
恢复日志将流的历史记录编码回称为检查点数据包的早期数据包。日志的覆盖范围称为检查点历史记录。恢复日志对从检查点历史记录中任意数量的数据包丢失中恢复所需的信息进行编码。附录A.1规范性地定义了检查点历史。
When a receiver detects a packet loss, it compares its own knowledge about the history of the stream with the history information coded in the recovery journal of the packet that ends the loss event. By noting the differences in these two versions of the past, a receiver is able to transform all indefinite artifacts in the rendered performance into transient artifacts by executing MIDI commands to repair the stream.
当接收器检测到数据包丢失时，它将自己关于流历史的知识与结束丢失事件的数据包的恢复日志中编码的历史信息进行比较。通过注意过去这两个版本的差异，接收器能够通过执行MIDI命令修复流，将渲染性能中的所有不确定瑕疵转换为瞬时瑕疵。
We now state the normative role for senders in the recovery journal system.
我们现在说明发件人在恢复日志系统中的规范角色。
Senders prepare a recovery journal for every packet in the stream. In doing so, senders choose the checkpoint packet identity for the journal. Senders make this choice by applying a sending policy. Appendix C.2.2 normatively defines three sending policies: "closed-loop", "open-loop", and "anchor".
发送方为流中的每个数据包准备一个恢复日志。这样，发送者为日志选择检查点数据包标识。发件人通过应用发送策略进行此选择。附录C.2.2规范性地定义了三种发送策略：“闭环”、“开环”和“锚定”。
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 and B in this memo. In Appendix C.2.3, we define parameters that modify the normative semantics for recovery journals. If the session description uses these parameters, the journal created by the sender MUST conform to the modified semantics.
在为数据包选择检查点数据包标识后，发送方将创建恢复日志。默认情况下，本日记账必须符合第5节以及本备忘录附录A和附录B中的规范语义。在附录C.2.3中，我们定义了修改恢复日志规范语义的参数。如果会话描述使用这些参数，则发送方创建的日志必须符合修改后的语义。
Next, we state the normative role for receivers in the recovery journal system.
接下来，我们陈述了接收者在恢复日志系统中的规范角色。
A receiver MUST detect each RTP sequence number break in a stream. If the sequence number break is due to a packet loss event (as defined in [RFC3550]), the receiver MUST repair all indefinite artifacts in the rendered MIDI performance caused by the loss. If the sequence number break is due to an out-of-order packet (as defined in [RFC3550]), the receiver MUST NOT take actions that introduce indefinite artifacts (ignoring the out-of-order packet is a safe option).
接收器必须检测流中的每个RTP序列号中断。如果序列号中断是由于数据包丢失事件（如[RFC3550]中所定义）造成的，则接收器必须修复由丢失引起的渲染MIDI性能中的所有不确定伪影。如果序列号中断是由于无序数据包引起的（如[RFC3550]中所定义），则接收方不得采取引入不确定伪影的操作（忽略无序数据包是一个安全选项）。
Receivers take special precautions when entering or exiting a session. A receiver MUST process the first received packet in a stream as if it were a packet that ends a loss event. Upon exiting a session, a receiver MUST ensure that the rendered MIDI performance does not end with indefinite artifacts.
接收者在进入或退出会话时采取特殊预防措施。接收方必须处理流中第一个接收到的数据包，就像它是结束丢失事件的数据包一样。退出会话时，接收器必须确保渲染的MIDI性能不会以不确定的伪影结束。
Receivers are under no obligation to perform indefinite artifact repairs at the moment a packet arrives. A receiver that uses a playout buffer may choose to wait until the moment of rendering before processing the recovery journal, as the "lost" packet may be a late packet that arrives in time to use.
接收方没有义务在数据包到达时执行不确定的工件修复。使用播放缓冲区的接收器可以选择在处理恢复日志之前等待呈现时刻，因为“丢失”分组可能是及时到达以使用的延迟分组。
Next, we state the normative role for the creator of the session description in the recovery journal system. The sender, the receivers, and other parties may take part in creating or approving the session description, depending on the application.
接下来，我们说明会话描述创建者在恢复日志系统中的规范角色。发送方、接收方和其他方可以根据应用程序参与创建或批准会话描述。
A session description that specifies the default closed-loop sending policy and the default recovery journal semantics satisfies the recovery journal mandate. However, these default behaviors may not be appropriate for all sessions. If the creators of a session description use the parameters defined in Appendix C.2 to override these defaults, the creators MUST ensure that the parameters define a system that satisfies the recovery journal mandate.
指定默认闭环发送策略和默认恢复日志语义的会话描述满足恢复日志要求。但是，这些默认行为可能并不适用于所有会话。如果会话描述的创建者使用附录C.2中定义的参数覆盖这些默认值，则创建者必须确保这些参数定义的系统满足恢复日志的要求。
Finally, we note that this memo does not specify sender or receiver recovery journal algorithms. Implementations are free to use any algorithm that conforms to the requirements in this section. The non-normative [RFC4696] discusses sender and receiver algorithm design.
最后，我们注意到，此备忘录未指定发送方或接收方恢复日志算法。实现可以自由使用符合本节要求的任何算法。非规范[RFC4696]讨论了发送方和接收方的算法设计。
This section introduces the structure of the recovery journal and defines the bitfields of recovery journal headers. Appendices A and B complete the bitfield definition of the recovery journal.
本节介绍恢复日志的结构，并定义恢复日志头的位字段。附录A和B完成了恢复日志的位字段定义。
The recovery journal has a three-level structure:
恢复日志具有三级结构：
o Top-level header.
o 顶层标题。
o Channel and system journal headers. These headers encode recovery information for a single voice channel (channel journal) or for all system commands (system journal).
o 频道和系统日志标题。这些标头对单个语音通道（通道日志）或所有系统命令（系统日志）的恢复信息进行编码。
o Chapters. Chapters describe recovery information for a single MIDI command type.
o 章。章节描述了单个MIDI命令类型的恢复信息。
Figure 7 shows the top-level structure of the recovery journal. The recovery journal consists of a 3-octet header followed by an optional system journal (labeled S-journal in Figure 7) and an optional list of channel journals. Figure 8 shows the recovery journal header format.
图7显示了恢复日志的顶级结构。恢复日志由一个3-octet头、一个可选的系统日志（图7中标记为S-journal）和一个可选的通道日志列表组成。图8显示了恢复日志标题格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery journal header | S-journal ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel journals ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 -- Recovery Journal Header
图8——恢复日志头
If the Y header bit is set to 1, the system journal appears in the recovery journal, directly following the recovery journal header.
如果Y标头位设置为1，系统日志将显示在恢复日志中，紧跟在恢复日志标头之后。
If the A header bit is set to 1, the recovery journal ends with a list of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header field is interpreted as an unsigned integer).
如果A头位设置为1，则恢复日志以（TOTCHAN+1）通道日志列表结束（4位TOTCHAN头字段解释为无符号整数）。
A MIDI channel MAY be represented by (at most) one channel journal in a recovery journal. Channel journals MUST appear in the recovery journal in ascending channel-number order.
MIDI通道在恢复日志中最多可以由一个通道日志表示。通道日志必须以通道编号升序出现在恢复日志中。
If A and Y are both zero, the recovery journal only contains its 3-octet header and is considered to be an "empty" journal.
如果A和Y均为零，则恢复日志仅包含其3个八位字节的头，并被视为“空”日志。
The S (single-packet loss) bit appears in most recovery journal structures, including the recovery journal header. The S bit helps receivers efficiently parse the recovery journal in the common case of the loss of a single packet. Appendix A.1 defines S-bit semantics.
S（单数据包丢失）位出现在大多数恢复日志结构中，包括恢复日志头。S位有助于接收器在单个数据包丢失的常见情况下有效解析恢复日志。附录A.1定义了S位语义。
The H bit indicates if MIDI channels in the stream have been configured to use the enhanced Chapter C encoding (Appendix A.3.3).
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.
如果流已配置为一个或多个MIDI通道的控制器编号使用增强的C章编码，则流中所有数据包的H位必须设置为1。在附录C.2.3中，我们展示了如何配置流以使用增强的C章编码。
The 16-bit Checkpoint Packet Seqnum header field codes the sequence number of the checkpoint packet for this journal, in network byte order (big-endian). The choice of the checkpoint packet sets the depth of the checkpoint history for the journal (defined in Appendix A.1).
16位检查点数据包Seqnum报头字段以网络字节顺序（大端）对该日志的检查点数据包序列号进行编码。检查点数据包的选择为日志设置检查点历史的深度（定义见附录A.1）。
Receivers may use the Checkpoint Packet Seqnum field of the packet that ends a loss event to verify that the journal checkpoint history covers the entire loss event. The checkpoint history covers the loss event if the Checkpoint Packet Seqnum field is less than or equal to one plus the highest RTP sequence number previously received on the stream (modulo 2^16).
接收方可以使用结束丢失事件的数据包的检查点数据包Seqnum字段来验证日志检查点历史记录是否覆盖了整个丢失事件。如果检查点数据包Seqnum字段小于或等于1加上先前在流上接收到的最高RTP序列号（模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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-octet头，后面是一个称为通道章节的叶元素列表。通道日志对由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位长度字段编码通道日志的长度。长度字段的语义在整个恢复日志中是统一的，并在附录A.1中定义。
The third octet of the channel journal header is the Table of Contents (TOC) of the channel journal. The TOC is a set of bits that encode the presence of a chapter in the journal. Each chapter contains information about a certain class of MIDI channel command:
频道日志标题的第三个八位组是频道日志的目录（TOC）。TOC是一组对期刊中章节的存在进行编码的位。每章包含关于某类MIDI通道命令的信息：
o Chapter P: MIDI Program Change (0xC) o Chapter C: MIDI Control Change (0xB)
o 第P章：MIDI程序更改（0xC）o第C章：MIDI控制更改（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 第M章：MIDI参数系统（0xB的一部分）o第W章：MIDI音高轮（0xE）o第N章：MIDI音符关闭（0x8），音符开启（0x9）o第E章：MIDI音符命令附加（0x8，0x9）o第T章：MIDI声道后触（0xD）o第A章：MIDI多声道后触（0xA）
Chapters appear in a list following the header, in order of their appearance in the TOC. Appendices A.2-A.9 describe the bitfield format for each chapter and define the conditions under which a chapter type MUST appear in the recovery journal. If any chapter types are required for a channel, an associated channel journal MUST appear in the recovery journal.
章节按其在TOC中的出现顺序出现在标题后面的列表中。附录A.2-A.9描述了每个章节的位字段格式，并定义了章节类型必须出现在恢复日志中的条件。如果通道需要任何章节类型，则恢复日志中必须出现关联的通道日志。
The H bit indicates if controller numbers on a MIDI channel have been configured to use the enhanced Chapter C encoding (Appendix A.3.3).
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章编码。在此默认情况下，对于流中的所有数据包，恢复日志中通道的所有通道日志头的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通道的至少一个控制器编号已配置为使用增强的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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|V|Q|F|X| LENGTH | System chapters ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 -- System Journal Format
图10——系统日志格式
Figure 10 shows the structure of the system journal: a 2-octet header followed by a list of system chapters. Each chapter codes information about a specific class of MIDI system commands:
图10显示了系统日志的结构：一个2个八位组的标题，后面是一个系统章节列表。每章对特定MIDI系统命令类的信息进行编码：
o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset (0xFF), undefined system commands (0xF4, 0xF5, 0xF9, 0xFD) o Chapter V: Active Sense (0xFE) o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC) o Chapter F: MIDI Time Code (MTC) Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01) o Chapter X: System Exclusive (all other 0xF0)
o 第四章：歌曲选择（0xF3）、调音请求（0xF6）、复位（0xFF）、未定义的系统命令（0xF4、0xF5、0xF9、0xFD）o第五章：主动感知（0xFE）o第Q章：音序器状态（0xF2、0xF8、0xF9、0xFA、0xFB、0xFC）o第F章：MIDI时间码（MTC）磁带位置（0xF1、0xF0、0x7F 0xcc 0x01 0x01）o第十章：系统专用（所有其他0xF0）
The 10-bit LENGTH field codes the size of the system journal and conforms to semantics described in Appendix A.1.
10位长度字段编码系统日志的大小，并符合附录A.1中描述的语义。
The D, V, Q, F, and X header bits form a Table of Contents (TOC) for the system journal. A TOC bit that is set to 1 codes the presence of a chapter in the journal. Chapters appear in a list following the header, in the order of their appearance in the TOC.
D、V、Q、F和X头位构成系统日志的目录（TOC）。设置为1的TOC位对日志中章节的存在进行编码。章节按其在TOC中的出现顺序出现在标题后面的列表中。
Appendix B describes the bitfield format for the system chapters and defines the conditions under which a chapter type MUST appear in the recovery journal. If any system chapter type is required to appear in the recovery journal, the system journal MUST appear in the recovery journal.
附录B描述了系统章节的位字段格式，并定义了章节类型必须出现在恢复日志中的条件。如果需要在恢复日志中显示任何系统章节类型，则系统日志必须显示在恢复日志中。
RTP does not perform session management. Instead, RTP works together with session management tools, such as the Session Initiation Protocol (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP, [RFC2326]).
RTP不执行会话管理。相反，RTP与会话管理工具协同工作，如会话启动协议（SIP，[RFC3261]）和实时流协议（RTSP，[RFC2326]）。
RTP payload formats define media type parameters for use in session management (for example, this memo defines rtp-midi as the media type for native RTP MIDI streams).
RTP有效负载格式定义用于会话管理的媒体类型参数（例如，本备忘录将RTP midi定义为本机RTP midi流的媒体类型）。
In most cases, session management tools use the media type parameters via another standard, the Session Description Protocol (SDP, [RFC4566]).
在大多数情况下，会话管理工具通过另一个标准会话描述协议（SDP，[RFC4566]）使用媒体类型参数。
SDP is a textual format for specifying session descriptions. Session descriptions specify the network transport and media encoding for RTP sessions. Session management tools coordinate the exchange of session descriptions between participants ("parties").
SDP是用于指定会话描述的文本格式。会话描述指定RTP会话的网络传输和媒体编码。会话管理工具协调参与者（“各方”）之间会话描述的交换。
Some session management tools use SDP to negotiate details of media transport (network addresses, ports, etc.). We refer to this use of SDP as "negotiated usage". One example of negotiated usage is the Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as used by SIP.
一些会话管理工具使用SDP协商媒体传输的细节（网络地址、端口等）。我们将SDP的这种使用称为“协商使用”。协商使用的一个例子是SIP使用的要约/应答协议（本备忘录中的[RFC3264]和附录C.7.2）。
Other session management tools use SDP to declare the media encoding for the session but use other techniques to negotiate network transport. We refer to this use of SDP as "declarative usage". One example of declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in this memo).
其他会话管理工具使用SDP声明会话的媒体编码，但使用其他技术协商网络传输。我们将SDP的这种用法称为“声明性用法”。声明性用法的一个例子是RTSP（本备忘录中的[RFC2326]和附录C.7.1）。
Below, we show session description examples for native (Section 6.1) and mpeg4-generic (Section 6.2) streams. In Section 6.3, we introduce session configuration tools that may be used to customize streams.
下面，我们展示本机（第6.1节）和mpeg4通用（第6.2节）流的会话描述示例。在第6.3节中，我们将介绍可用于自定义流的会话配置工具。
The session description below defines a unicast UDP RTP session (via a media ("m=") line) whose sole payload type (96) is mapped to a minimal native RTP MIDI stream.
下面的会话描述定义了一个单播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=Example
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等），则恢复日志系统正在使用，RTP有效负载包含MIDI命令部分和日志部分。如果流使用可靠传输（如TCP），则流不使用日志记录，有效负载仅包含MIDI命令部分（第2.2节）。
2. If the stream uses the recovery journal system, the recovery journal system uses the default sending policy and the default journal semantics (Section 4).
2. 如果流使用恢复日志系统，则恢复日志系统使用默认发送策略和默认日志语义（第4节）。
3. In the MIDI command section of the payload, command timestamps use the default comex semantics (Section 3).
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 ms，并且流中连续分组之间的RTP时间戳差可以任意大（第2.1节）。
5. If more than one minimal rtp-midi stream appears in a session, the MIDI name spaces for these streams are independent: channel 1 in the first stream does not reference the same MIDI channel as channel 1 in the second stream (see Appendix C.5 for a discussion of the independence of minimal rtp-midi streams).
5. 如果会话中出现多个最小rtp midi流，则这些流的midi名称空间是独立的：第一个流中的通道1与第二个流中的通道1不引用相同的midi通道（有关最小rtp midi流独立性的讨论，请参见附录C.5）。
6. The rendering method for the stream is not specified. What the receiver "does" with a minimal native MIDI stream is out of the scope of this memo. For example, in content creation environments, a user may manually configure client software to render the stream with a specific software package.
6. 未指定流的渲染方法。接收器使用最小的本机MIDI流“执行”的操作超出了本备忘录的范围。例如，在内容创建环境中，用户可以手动配置客户端软件以使用特定软件包呈现流。
As is standard in RTP, RTP sessions managed by SIP are sendrecv by default (parties send and receive MIDI), and RTP sessions managed by RTSP are recvonly by default (server sends and client receives).
按照RTP中的标准，由SIP管理的RTP会话默认为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名称空间对于每个发送方都是唯一的。因此，在双方会话中，一方发送的语音信道0不同于另一方发送的语音信道0。
This behavior corresponds to what occurs when two MIDI 1.0 DIN devices are cross-connected with two MIDI cables (one cable routing MIDI Out from the first device into MIDI In of the second device and a second cable routing MIDI In from the first device into MIDI Out of the second device). We define this "association" formally in Section 2.1.
此行为对应于两个MIDI 1.0 DIN设备通过两条MIDI电缆交叉连接时发生的情况（一条电缆将MIDI从第一个设备路由到第二个设备的MIDI In，另一条电缆将MIDI In从第一个设备路由到第二个设备的MIDI In）。我们在第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协议本身提供了在多播网络上的事务中寻址特定设备和设备发现的工具。因此，除了提供一对多转发路径和一对多反向路径之外，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通用[RFC3640]RTP MIDI流使用MPEG 4音频对象类型将MIDI渲染为音频。三种音频对象类型接受MIDI输入：
o General MIDI (Audio Object Type ID 15), based on the General MIDI rendering standard [MIDI].
o 通用MIDI（音频对象类型ID 15），基于通用MIDI渲染标准[MIDI]。
o Wavetable Synthesis (Audio Object Type ID 14), based on the Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2].
o 波形表合成（音频对象类型ID 14），基于可下载的声音级别2（DLS 2）渲染标准[DLS2]。
o Main Synthetic (Audio Object Type ID 13), based on Structured Audio and the programming language SAOL [MPEGSA]. The name of the language (SAOL) is an acronym that expands to Structured Audio Orechestra Language.
o 主合成（音频对象类型ID 13），基于结构化音频和编程语言SAOL[MPEGSA]。语言名称（SAOL）是扩展为结构化音频语言的首字母缩略词。
The primary service of an mpeg4-generic stream is to code Access Units (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI payload shown in Figure 1 of Section 2.1 of this memo: a MIDI command section optionally followed by a journal section.
mpeg4通用流的主要服务是编码访问单元（AU）。我们将mpeg4通用RTP MIDI AU定义为本备忘录第2.1节图1中所示的MIDI有效负载：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.
必须将一个RTP MIDI AU映射到一个mpeg4通用RTP MIDI数据包。用于在RTP数据包中放置多个AU的mpeg4通用选项不得与RTP MIDI一起使用。用于分割和交错AU的mpeg4通用选项不得与RTP MIDI一起使用。mpeg4通用RTP数据包有效负载（RFC3640中的图1）必须包含空的AU报头和辅助部分。这些规则产生的mpeg4通用数据包在结构上与本机RTP MIDI数据包相同，这是有效负载格式正确操作的基本属性。
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通用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:DB8::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0000
000600FF2F000
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0000
000600FF2F000
(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
fmtp属性行对所有mpeg4通用会话描述[RFC3640]中所需的四个参数（streamtype、mode、profile level id和config）进行编码。对于RTP MIDI流，streamtype
parameter MUST be set to 5, the mode parameter MUST be set to rtp-midi, and the profile-level-id parameter MUST be set to the MPEG-4 Profile Level for the stream. For the Synthesis Profile, legal profile-level-id values are 11, 12, and 13, coding low (11), medium (12), or high (13) decoder computational complexity, as defined by MPEG conformance tests.
参数必须设置为5，模式参数必须设置为rtp midi，配置文件级别id参数必须设置为流的MPEG-4配置文件级别。对于合成简档，合法简档级别id值为11、12和13，编码低（11）、中（12）或高（13）解码器计算复杂度，如MPEG一致性测试所定义。
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会话描述中，配置值必须是流的AudioSpecificConfig数据块[MPEGAUDIO]的十六进制编码[RFC3640]。AudioSpecificConfig对流的音频对象类型进行编码，并对初始化数据（SAOL程序、DLS 2波形表等）进行编码。接收器必须忽略在AudioSpecificConfig中以最小会话描述编码的标准MIDI文件。
Receivers determine the rendering algorithm for the session by interpreting the first 5 bits of AudioSpecificConfig as an unsigned integer that codes the Audio Object Type. In our example above, the 5 bits are coded within the first two nibbles ("7A") of the config string. The Audio Object Type coded within "7A" is Audio Object Type 15 (General MIDI). In Appendix E.4, we derive the config string value in the session description shown above; the starting point of the derivation is the MPEG bitstreams defined in [MPEGSA] and [MPEGAUDIO].
接收器通过将AudioSpecificConfig的前5位解释为编码音频对象类型的无符号整数来确定会话的呈现算法。在上面的示例中，5位编码在配置字符串的前两个半字节（“7A”）内。“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通用参数。在第6.1节中，我们将最小本机流的行为描述为特征的编号列表。该列表中的项目1-4也描述了最低mpeg4通用流，但项目5和6需要重述，如下所示：
5. If more than one minimal mpeg4-generic stream appears in a session, each stream uses an independent instance of the Audio Object Type coded in the config parameter value.
5. 如果会话中出现多个最小mpeg4通用流，则每个流使用配置参数值中编码的音频对象类型的独立实例。
6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig as an inline hexadecimal constant. If a session description is sent over UDP, it may be impossible to transport large AudioSpecificConfig blocks within the Maximum Transmission Unit (MTU) of the underlying network (for Ethernet, the MTU is 1500 octets). In some cases, the AudioSpecificConfig block may exceed the maximum size of the UDP packet itself.
6. 最小mpeg4通用流将AudioSpecificConfig编码为内联十六进制常量。如果通过UDP发送会话描述，则可能无法在基础网络的最大传输单元（MTU）内传输大型AudioSpecificConfig块（对于以太网，MTU为1500个八位字节）。在某些情况下，AudioSpecificConfig块可能超过UDP数据包本身的最大大小。
The comments in Section 6.1 on SIP and RTSP stream directional defaults, sendrecv MIDI channel usage, and MIDI 1.0 DIN multicast networks also apply to mpeg4-generic RTP MIDI sessions.
第6.1节中关于SIP和RTSP流方向默认值、sendrecv MIDI通道使用和MIDI 1.0 DIN多播网络的注释也适用于mpeg4通用RTP MIDI会话。
In sendrecv sessions, each party's session description MUST use identical values for the mpeg4-generic parameters (including the required streamtype, mode, profile-level-id, and config parameters). As a consequence, each party uses an identically configured MPEG 4 Audio Object Type to render MIDI commands into audio. The preamble to Appendix C discusses a way to create "virtual sendrecv" sessions that do not have this restriction.
在sendrecv会话中，各方的会话描述必须为mpeg4通用参数（包括所需的流类型、模式、配置文件级别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 and 6.2 and support several types of services:
参数为第6.1节和第6.2节中描述的最小流添加了功能，并支持多种类型的服务：
o Stream subsetting. By default, all MIDI commands that are legal to appear on a MIDI 1.0 DIN cable may appear in an RTP MIDI stream. The cm_unused parameter overrides this default by prohibiting certain commands from appearing in the stream. The cm_used parameter is used in conjunction with cm_unused to simplify the specification of complex exclusion rules. We describe cm_unused and cm_used in Appendix C.1.
o 流子集划分。默认情况下，所有合法出现在MIDI 1.0 DIN电缆上的MIDI命令都可能出现在RTP MIDI流中。cm_unused参数通过禁止某些命令出现在流中来覆盖此默认值。cm_used参数与cm_unused一起使用，以简化复杂排除规则的规范。我们在附录C.1中描述了未使用的cm_和使用的cm_。
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参数配置日志部分的使用。Chu default、Chu never和Chu anchor参数配置恢复日志章节的语义。这些参数在附录C.2中描述，并覆盖默认的流行为1和2（在第6.1节中列出，在第6.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和linerate参数在MIDI命令部分自定义时间戳的语义。这些参数使RTP MIDI能够准确地编码MIDI 1.0 DIN电缆的隐式时间编码。这些参数在附录C.3中描述，并覆盖默认流行为3（在第6.1节中列出，在第6.2节中引用）。
o Media time. The rtp_ptime and rtp_maxptime parameters define the temporal duration ("media time") of an RTP MIDI packet. The guardtime parameter sets the minimum sending rate of stream packets. These parameters are described in Appendix C.4 and override default stream behavior 4 (listed in Section 6.1 and referenced in Section 6.2).
o 媒体时间。rtp_ptime和rtp_maxptime参数定义rtp MIDI数据包的时间持续时间（“媒体时间”）。guardtime参数设置流数据包的最小发送速率。这些参数在附录C.4中描述，并覆盖默认流行为4（在第6.1节中列出，在第6.2节中引用）。
o Stream description. The musicport parameter labels the MIDI name space of RTP streams in a multimedia session. Musicport is described in Appendix C.5. The musicport parameter overrides default stream behavior 5 (in Sections 6.1 and 6.2).
o 流描述。musicport参数标记多媒体会话中RTP流的MIDI名称空间。音乐端口在附录C.5中描述。musicport参数覆盖默认流行为5（在第6.1节和第6.2节中）。
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中，我们为两个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]).
MIDI对RTP的许多有价值的使用并不属于有效负载格式的狭窄范围。例如，有效负载格式不支持直接传输标准MIDI文件（SMF）元事件和度量计时数据。作为第二个示例，有效负载格式没有为用户定义的命令定义传输工具（除了支持系统专用命令[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所述，可在IETF标准跟踪文件中定义j_sec和j_更新参数的新令牌值。此机制支持新日志格式的设计和新日志发送策略的定义。
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_信息（附录C.6.4.1）参数进行扩展。
o Undefined commands. [MIDI] reserves 4 MIDI system commands for future use (0xF4, 0xF5, 0xF9, 0xFD). If updates to [MIDI] define the reserved commands, IETF Standards-Track documents may be defined to provide resiliency support for the commands. Opaque LEGAL fields appear in System Chapter D for this purpose (Appendix B.1.1).
o 未定义的命令。[MIDI]保留4个MIDI系统命令供将来使用（0xF4、0xF5、0xF9、0xFD）。如果对[MIDI]的更新定义了保留命令，则可以定义IETF标准跟踪文档，为命令提供弹性支持。为此，不透明的法律字段出现在系统第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] apply to RTP MIDI sessions run under applicable profiles. The basic congestion control requirement defined in [RFC3551] is that RTP sessions that use UDP transport should monitor packet loss (via RTCP or other means) to ensure that the RTP stream competes fairly with TCP flows that share the network.
此外，[RFC3551]中定义的拥塞控制要求适用于在适用配置文件下运行的RTP MIDI会话。[RFC3551]中定义的基本拥塞控制要求是，使用UDP传输的RTP会话应监控数据包丢失（通过RTCP或其他方式），以确保RTP流与共享网络的TCP流公平竞争。
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[RFC3550]、AVP[RFC3551]和其他RTP概要文件中的安全注意事项部分，因为这些部分中讨论的问题直接适用于RTP MIDI流。实施者还应审查安全实时传输协议（SRTP，[RFC3711]），这是一个RTP配置文件，解决了[RFC3550]和[RFC3551]中讨论的安全问题。
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节允许一方在两个RTP会话中发送的流在某些情况下具有相同的SSRC值和相同的RTP时间戳初始化值。通常，这些值是为会话中的每个流随机选择的，如果有效负载被加密，则很难进行明文猜测。因此，第2.1节削弱了RTP安全性的这一方面。
We thank the networking, media compression, and computer music community members who have commented or contributed to the effort, including Kurt B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, Tobias Erichsen, Roni Even, Nicolas Falquet, Adrian Farrel, Dominique Fober, Philippe Gentric, Michael Godfrey, Chris Grigg, Todd Hager, Alfred Hoenes, Russ Housley, Michel Jullian, Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer, Alexey Melnikov, Colin Perkins, Charlie Richmond, Herbie Robinson, Dan Romascanu, Larry Rowe, Eric Scheirer, Dave Singer, Martijn Sipkema, Robert Sparks, William Stewart, Kent Terry, Sean Turner, Magnus Westerlund, Tom White, Jim Wright, Doug Wyatt, and Giorgio Zoia. We
我们感谢网络、媒体压缩和计算机音乐社区的成员，他们对这项工作发表了评论或做出了贡献，包括Kurt B、Cynthia Bruyns、Steve Casner、Paul Davis、Robin Davies、Joanne Dow、Tobias Erichsen、Roni Even、Nicolas Falket、Adrian Farrel、Dominique Fober、Philippe Gentric、Michael Godfrey、Chris Grigg、，托德·哈格、阿尔弗雷德·霍恩斯、罗斯·霍斯利、米歇尔·朱利安、菲尔·克尔、杨权林、杰西卡·利特尔、扬·范德梅尔、阿列克西·梅尔尼科夫、科林·珀金斯、查理·里士满、赫比·罗宾逊、丹·罗马斯库、拉里·罗、埃里克·谢勒、戴夫·辛格、马蒂金·西普克马、罗伯特·斯帕克斯、威廉·斯图尔特、肯特·特里、肖恩·特纳、马格纳斯·维斯特伦德、汤姆·怀特、，吉姆·赖特、道格·怀亚特和乔治·佐亚。我们
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.
还感谢旧金山湾地区的音乐和音频社区的成员创造工作的背景，包括Don Buchla、Chris Chafe、Richard Duda、Dan Ellis、Adrian Freed、Ben Gold、杰伦·拉尼尔、So、Y、Y、Y、Y、Cavver Mead、NelsSy*、Y.、戴夫·史密斯、朱利叶斯·史密斯、大卫·韦塞尔和马特·赖特。
The bulk of this section is a verbatim reproduction of the IANA considerations that appear in Section 11 of [RFC4695]. Preceding this reproduction, we list several issues concerning this memo that are related to the IANA considerations, as follows:
本节的大部分内容是[RFC4695]第11节中出现的IANA注意事项的逐字复制。在此复制之前，我们列出了与IANA考虑事项相关的本备忘录的几个问题，如下所示：
o All existing IANA references to [RFC4695] have been deleted, and replaced with references to this memo. In addition, a reference to this memo has been added to the audio/mpeg4-generic MIME type registration.
o 所有现有IANA对[RFC4695]的引用均已删除，并替换为对本备忘录的引用。此外，对本备忘录的引用已添加到音频/mpeg4通用MIME类型注册中。
o In Section 11.3, a sentence has been added to the Encoding Considerations asc Media Type Registration: "Disk files that store this data object use the file extension ".acn"".
o 在第11.3节中，编码注意事项asc媒体类型注册中添加了一句话：“存储此数据对象的磁盘文件使用文件扩展名“.acn”。
The reproduction of the [RFC4695] IANA considerations section appears directly below.
[RFC4695]IANA注意事项部分的副本直接显示在下面。
This section makes a series of requests to IANA. The IANA has completed registration/assignments of the below requests.
本节向IANA提出了一系列请求。IANA已完成以下请求的注册/分配。
The subsections that follow hold the actual, detailed requests. All registrations in this section are in the IETF tree and follow the rules of [RFC4288] and [RFC4855], as appropriate.
下面的小节包含实际的、详细的请求。本节中的所有注册都在IETF目录树中，并根据需要遵循[RFC4288]和[RFC4855]的规则。
In Section 11.1, we request the registration of a new media type: audio/rtp-midi. Paired with this request is a request for a repository for new values for several parameters associated with audio/rtp-midi. We request this repository in Section 11.1.1.
在第11.1节中，我们要求注册一种新的媒体类型：音频/rtp midi。与此请求配对的是一个存储库请求，用于存储与音频/rtp midi相关联的几个参数的新值。我们在第11.1.1节中请求此存储库。
In Section 11.2, we request the registration of a new value (rtp-midi) for the mode parameter of the mpeg4-generic media type. The mpeg4-generic media type is defined in [RFC3640], and [RFC3640] defines a repository for the mode parameter. However, we believe we are the first to request the registration of a mode value, so we believe the registry for mode has not yet been created by IANA.
在第11.2节中，我们请求注册mpeg4通用媒体类型的模式参数的新值（rtp midi）。[RFC3640]中定义了mpeg4通用媒体类型，[RFC3640]定义了模式参数的存储库。但是，我们相信我们是第一个请求注册模式值的人，因此我们相信IANA尚未创建模式注册表。
Paired with our mode parameter value request for mpeg4-generic is a request for a repository for new values for several parameters we have defined for use with the rtp-midi mode value. We request this repository in Section 11.2.1.
与我们对mpeg4 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节中，我们要求注册一种新的媒体类型：音频/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.
本节要求注册音频媒体类型的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.
CHU锚：有关使用详情，请参见附录C.2.3。CHU默认值：有关使用详情，请参见附录C.2.3。CHU never：有关使用详情，请参见附录C.2.3。cm_未使用：使用详情见附录C.1。使用的cm_：使用详情见附录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: See Appendix C.6.3 for usage details. rtp_maxptime: See Appendix C.4.1 for usage details. rtp_ptime: See Appendix C.4.1 for usage details. smf_cid: See Appendix C.6.4.2 for usage details. smf_inline: See Appendix C.6.4.2 for usage details. smf_url: See Appendix C.6.4.2 for usage details. tsmode: See Appendix C.3 for usage details. url: See Appendix C.6.3 for usage details.
rinit：使用详情见附录C.6.3。rtp_maxptime：使用详情见附录C.4.1。rtp时间：使用详情见附录C.4.1。smf_cid：使用详情见附录C.6.4.2。smf_内联：使用详情见附录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_更新：使用详情见附录C.2.2。有关存储库的详细信息，请参见第11.1.1节。渲染：有关使用细节，请参见附录C.6。有关存储库的详细信息，请参见第11.1.1节。子渲染：有关使用细节，请参见附录C.6.2。有关存储库的详细信息，请参见第11.1.1节。smf_信息：使用详情见附录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 bitrate music coding.
音频内容创建硬件，如MIDI控制器钢琴键盘和MIDI音频合成器。音频内容创建软件，如音乐定序器、数字音频工作站和软合成器。计算机操作系统，用于网络支持MIDI应用程序编程接口。内容分发服务器和终端可将此媒体类型用于低比特率音乐编码。
Additional information:
其他信息：
None.
没有一个
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
John Lazzaro <lazzaro@cs.berkeley.edu>
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
预期用途：
COMMON.
常见的
Author:
作者：
John Lazzaro <lazzaro@cs.berkeley.edu>
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
更改控制器：
IETF Audio/Video Transport Working Group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
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:
美国证券交易委员会：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.1 of this memo describes appropriate registrations for this repository.
此存储库的注册只能通过IETF标准跟踪文档进行。本备忘录附录C.2.1描述了该存储库的适当注册。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"none": Defined in Appendix C.2.1 of this memo. "recj": Defined in Appendix C.2.1 of this memo.
“无”：定义见本备忘录附录C.2.1。“recj”：定义见本备忘录附录C.2.1。
j_update:
j_更新：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.2 of this memo describes appropriate registrations for this repository.
此存储库的注册只能通过IETF标准跟踪文档进行。本备忘录附录C.2.2描述了该存储库的适当注册。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"anchor": Defined in Appendix C.2.2 of this memo. "open-loop": Defined in Appendix C.2.2 of this memo. "closed-loop": Defined in Appendix C.2.2 of this memo.
“锚定”：定义见本备忘录附录C.2.2。“开环”：定义见本备忘录附录C.2.2。“闭环”：定义见本备忘录附录C.2.2。
render:
提供：
Registrations for this repository MUST include a specification of the usage of the proposed value. See the preamble of Appendix C.6 for details (the paragraph that begins "Other render token ...").
此存储库的注册必须包括建议值的使用说明。有关详细信息，请参见附录C.6的前言（以“其他呈现令牌…”开头的段落）。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"unknown": Defined in Appendix C.6 of this memo. "synthetic": Defined in Appendix C.6 of this memo. "api": Defined in Appendix C.6 of this memo. "null": Defined in Appendix C.6 of this memo.
“未知”：定义见本备忘录附录C.6。“合成”：定义见本备忘录附录C.6。“api”：定义见本备忘录附录C.6。“空”：定义见本备忘录附录C.6。
subrender:
子渲染：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.2 for details (the paragraph that begins "Other subrender token ...").
此存储库的注册必须包括建议值的使用说明。有关详细信息，请参见附录C.6.2（“其他子渲染令牌…”开头的段落）。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"default": Defined in Appendix C.6.2 of this memo.
“默认”：定义见本备忘录附录C.6.2。
smf_info:
smf_信息：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.4.1 for details (the paragraph that begins "Other smf_info token ...").
此存储库的注册必须包括建议值的使用说明。详见附录C.6.4.1（以“其他smf_信息令牌…”开头的段落）。
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_开始”：定义见本备忘录附录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通用媒体类型的mode参数的rtp midi值。[RFC3640]中定义了mpeg4通用媒体类型，[RFC3640]定义了模式参数的存储库。我们正在注册模式rtp midi，以支持使用midi的MPEG音频编解码器[MPEGSA]。
In conjunction with this registration request, we request the registration of the parameters listed in the "optional parameters" section below (both the "non-extensible parameters" and the "extensible parameters" lists). We also request the creation of repositories for the "extensible parameters"; the details of this request appear in Appendix 11.2.1.
结合此注册请求，我们请求注册下面“可选参数”部分中列出的参数（“非可扩展参数”和“可扩展参数”列表）。我们还要求为“可扩展参数”创建存储库；该请求的详细信息见附录11.2.1。
Media type name:
媒体类型名称：
audio
音频
Subtype name:
子类型名称：
mpeg4-generic
mpeg4通用
Required parameters:
所需参数：
The mode parameter is required by [RFC3640]. [RFC3640] requests a repository for mode so that new values for mode may be added. We request that the value rtp-midi be added to the mode repository.
[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通用参数速率是必需的参数。Rate指定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. 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.
CHU锚：有关使用详情，请参见附录C.2.3。CHU默认值：有关使用详情，请参见附录C.2.3。CHU never：有关使用详情，请参见附录C.2.3。cm_未使用：使用详情见附录C.1。使用的cm_：使用详情见附录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时间：使用详情见附录C.4.1。smf_cid：使用详情见附录C.6.4.2。smf_内联：使用详情见附录C.6.4.2。smf_url：使用详情见附录C.6.4.2。tsmode：有关使用详情，请参见附录C.3。url：使用详情见附录C.6.3。
Extensible parameters:
可扩展参数：
j_sec: See Appendix C.2.1 for usage details. See Section 11.2.1 for repository details. j_update: See Appendix C.2.2 for usage details. See Section 11.2.1 for repository details. render: See Appendix C.6 for usage details. See Section 11.2.1 for repository details. subrender: See Appendix C.6.2 for usage details. See Section 11.2.1 for repository details. smf_info: See Appendix C.6.4.1 for usage details. See Section 11.2.1 for repository details.
j_sec：使用详情见附录C.2.1。有关存储库的详细信息，请参见第11.2.1节。j_更新：使用详情见附录C.2.2。有关存储库的详细信息，请参见第11.2.1节。渲染：有关使用细节，请参见附录C.6。有关存储库的详细信息，请参见第11.2.1节。子渲染：有关使用细节，请参见附录C.6.2。有关存储库的详细信息，请参见第11.2.1节。smf_信息：使用详情见附录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.
仅定义用于实时传输音频/mpeg4通用RTP流，模式=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节）外，音频/rtp midi和音频/mpeg4通用（rtp midi模式）的数据包格式相同。格式在使用上有所不同：音频/mpeg4通用用于MPEG工作，音频/rtp midi用于所有其他工作。
Published specification:
已发布的规范：
This memo, [MIDI], and [MPEGSA] are the normative references. In addition, [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>
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
预期用途：
COMMON.
常见的
Author:
作者：
John Lazzaro <lazzaro@cs.berkeley.edu>
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
更改控制器：
IETF Audio/Video Transport Working Group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
For mode rtp-midi of the mpeg4-generic subtype, we request the creation of repositories for extensions to the following parameters (which are those listed as "extensible parameters" in Section 11.2).
对于mpeg4泛型子类型的模式rtp midi，我们请求创建存储库以扩展以下参数（这些参数在第11.2节中列为“可扩展参数”）。
j_sec:
美国证券交易委员会：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.1 of this memo describes appropriate registrations for this repository.
此存储库的注册只能通过IETF标准跟踪文档进行。本备忘录附录C.2.1描述了该存储库的适当注册。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"none": Defined in Appendix C.2.1 of this memo. "recj": Defined in Appendix C.2.1 of this memo.
“无”：定义见本备忘录附录C.2.1。“recj”：定义见本备忘录附录C.2.1。
j_update:
j_更新：
Registrations for this repository may only occur via an IETF Standards-Track document. Appendix C.2.2 of this memo describes appropriate registrations for this repository.
此存储库的注册只能通过IETF标准跟踪文档进行。本备忘录附录C.2.2描述了该存储库的适当注册。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"anchor": Defined in Appendix C.2.2 of this memo. "open-loop": Defined in Appendix C.2.2 of this memo. "closed-loop": Defined in Appendix C.2.2 of this memo.
“锚定”：定义见本备忘录附录C.2.2。“开环”：定义见本备忘录附录C.2.2。“闭环”：定义见本备忘录附录C.2.2。
render:
提供：
Registrations for this repository MUST include a specification of the usage of the proposed value. See the preamble of Appendix C.6 for details (the paragraph that begins "Other render token ...").
此存储库的注册必须包括建议值的使用说明。有关详细信息，请参见附录C.6的前言（以“其他呈现令牌…”开头的段落）。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"unknown": Defined in Appendix C.6 of this memo. "synthetic": Defined in Appendix C.6 of this memo. "null": Defined in Appendix C.6 of this memo.
“未知”：定义见本备忘录附录C.6。“合成”：定义见本备忘录附录C.6。“空”：定义见本备忘录附录C.6。
subrender:
子渲染：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.2 for details (the paragraph that begins "Other subrender token ..." and subsequent paragraphs). Note that the text in Appendix C.6.2 contains restrictions on subrender registrations for mpeg4-generic (the sentence that
此存储库的注册必须包括建议值的使用说明。有关详细信息，请参见附录C.6.2（“其他子渲染令牌…”开头的段落以及后续段落）。请注意，附录C.6.2中的文本包含对mpeg4 generic子渲染器注册的限制（以下句子：
begins "Registrations for mpeg4-generic subrender values ...").
开始“注册mpeg4通用子渲染值…”）。
Initial values for this repository appear below:
此存储库的初始值如下所示：
"default": Defined in Appendix C.6.2 of this memo.
“默认”：定义见本备忘录附录C.6.2。
smf_info:
smf_信息：
Registrations for this repository MUST include a specification of the usage of the proposed value. See Appendix C.6.4.1 for details (the paragraph that begins "Other smf_info token ...").
此存储库的注册必须包括建议值的使用说明。详见附录C.6.4.1（以“其他smf_信息令牌…”开头的段落）。
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_开始”：定义见本备忘录附录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通用媒体类型[RFC3640]的“config”参数在与mpeg4通用模式rtp midi（注册于上述附录11.2）一起使用时的远程传输。我们在本文件第6.2节和附录C.6.5中解释了使用音频/asc设置配置参数的机制。
Note that this registration is a new subtype registration and is not an addition to a repository defined by MPEG-related memos (such as [RFC3640]). Also, note that this request for audio/asc does not register parameters and does not request the creation of a repository.
请注意，此注册是一个新的子类型注册，不是对MPEG相关备忘录（如[RFC3640]）定义的存储库的添加。另外，请注意，此音频/asc请求不注册参数，也不请求创建存储库。
Media type name:
媒体类型名称：
audio
音频
Subtype name:
子类型名称：
asc
asc
Required parameters:
所需参数：
None.
没有一个
Optional parameters:
可选参数：
None.
没有一个
Encoding considerations:
编码注意事项：
The native form of the data object is binary data, zero-padded to an octet boundary. Disk files that store this data object use the file extension ".acn".
数据对象的本机形式是二进制数据，零填充到八位字节边界。存储此数据对象的磁盘文件使用文件扩展名“.acn”。
Restrictions on usage:
使用限制：
This type is only defined for data object (stored file) transfer. The most common transports for the type are HTTP and SMTP.
此类型仅为数据对象（存储文件）传输定义。该类型最常见的传输是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].
音频/asc数据对象是AudioSpecificConfig二进制数据结构，在[MPEGAUDIO]中有规范性定义。
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通用RTP流的MPEG 4音频服务器和终端。
Additional information:
其他信息：
None.
没有一个
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
John Lazzaro <lazzaro@cs.berkeley.edu>
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
预期用途：
COMMON.
常见的
Author:
作者：
John Lazzaro <lazzaro@cs.berkeley.edu>
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
更改控制器：
IETF Audio/Video Transport Working Group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
This document fixes errors found in RFC 4695 by reviewers. We thank Alfred Hoenes, Roni Even, and Alexey Melnikov for reporting the errors. To our knowledge, there are no interoperability issues associated with the errors that are fixed by this document. In this section, we list the error fixes.
本文档修复了审阅者在RFC 4695中发现的错误。我们感谢阿尔弗雷德·霍恩斯、甚至罗尼和阿列克谢·梅尔尼科夫报告了这些错误。据我们所知，不存在与本文档修复的错误相关的互操作性问题。在本节中，我们将列出错误修复。
In Section 3 of RFC 4695, the bitfield format shown in Figure 3 is inconsistent with the normative text that (correctly) describes the bitfield. Specifically, Figure 3 in RFC 4695 incorrectly states the dependence of the Delta Time 0 field on the Z header bit. Figure 3 in this document corrects this error. To our knowledge, this error did not result in incorrect implementations of RFC 4695.
在RFC 4695第3节中，图3所示的位字段格式与（正确）描述位字段的规范性文本不一致。具体而言，RFC 4695中的图3错误地说明了增量时间0字段对Z报头位的依赖性。本文档中的图3更正了此错误。据我们所知，这个错误并没有导致RFC4695的错误实现。
The remaining errors are in Appendices C and D and concern session configuration parameters. The numbered list ((1) through (11)) below describes these errors in detail, in order of appearance in the document. To our knowledge, there are no interoperability issues associated with these errors, as implementation activity has so far focused on an application domain that does not use SDP for session management.
其余错误在附录C和D中，与会话配置参数有关。下面的编号列表（（1）到（11））按照在文档中出现的顺序详细描述了这些错误。据我们所知，不存在与这些错误相关的互操作性问题，因为到目前为止，实施活动的重点是不使用SDP进行会话管理的应用程序域。
(1) In Appendices C.1 and C.2.3 of RFC 4695, an ABNF rule related to System Chapter X is incorrectly defined as:
(1) 在RFC 4695附录C.1和C.2.3中，与系统第X章相关的ABNF规则被错误地定义为：
<parameter> = "__" <h-list> ["_" <h-list>] "__"
<parameter> = "__" <h-list> ["_" <h-list>] "__"
The correct version of this rule is:
此规则的正确版本为：
<parameter> = "__" <h-list> *( "_" <h-list> ) "__"
<parameter> = "__" <h-list> *( "_" <h-list> ) "__"
(2) In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned to the url parameter are not stated clearly. URIs assigned to url MUST specify either HTTP or HTTP over TLS transport protocols.
(2) 在RFC 4695的附录C.6.3中，未明确说明允许分配给url参数的URI。分配给url的URI必须指定HTTP或HTTP over TLS传输协议。
In Appendix C.7.1 and C.7.2 of RFC 4695, the transport interoperability requirements for the url parameter are not stated
在RFC 4695的附录C.7.1和C.7.2中，未说明url参数的传输互操作性要求
clearly. For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS is OPTIONAL.
清晰地对于C.7.1和C.7.2，HTTP是必需的，HTTP over TLS是可选的。
(3) In Appendix C.6.5, the filename extension ".acn" has been defined for use with AudioSpecificConfig.
(3) 在附录C.6.5中，文件扩展名“.acn”已定义用于AudioSpecificConfig。
(4) Both fmtp lines in both session description examples in Appendix C.7.2 of RFC 4695 contain instances of the same syntax error (a missing ";" at a line wrap after a cm_used assignment).
(4) RFC 4695附录C.7.2中两个会话描述示例中的fmtp行都包含相同语法错误的实例（cm_使用的赋值后换行处缺少“；”。
(5) In the session description examples in Appendix C.5, C.6, and C.7 of RFC 4695, the parameter assignment
(5) 在RFC 4695附录C.5、C.6和C.7中的会话描述示例中，参数赋值
rinit="audio/asc";
rinit="audio/asc";
is incorrect. The correct parameter assignment appears below:
这是不正确的。正确的参数分配如下所示：
rinit=audio/asc;
rinit=audio/asc;
Note that this error also appears in the session descriptions shown in Figures 1 and 2 of the informative RFC 4696. We are not aware of existing implementations that use the rinit parameter, and so the incorrect examples in RFC 4695 and RFC 4696 should not cause interoperability problems.
请注意，此错误也出现在信息性RFC 4696的图1和图2中所示的会话描述中。我们不了解使用rinit参数的现有实现，因此RFC 4695和RFC 4696中的错误示例不应导致互操作性问题。
(6) In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules are in error and should be replaced with "ietf-extension". Likewise, all uses of "*extension" are in error and should be replaced with "extension". This bug incorrectly lets the null token be assigned to the j_sec, j_update, render, smf_info, and subrender parameters.
(6) 在RFC 4695的附录D中，规则中所有“*ietf扩展”的使用都是错误的，应替换为“ietf扩展”。同样地，“*extension”的所有用法都是错误的，应替换为“extension”。此错误错误地将空标记分配给j_sec、j_update、render、smf_info和subrender参数。
(7) In Appendix D of RFC 4695, the definitions of <command-type> and <chapter-rules> incorrectly allow lowercase letters to appear in these strings. The correct definitions of these rules appear below:
(7) 在RFC 4695的附录D中，<命令类型>和<章节规则>的定义错误地允许在这些字符串中出现小写字母。这些规则的正确定义如下所示：
command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M]
[N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M]
[N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
[M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
[M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
A = %x41
B = %x42
C = %x43
D = %x44
E = %x45
F = %x46
G = %x47
A = %x41
B = %x42
C = %x43
D = %x44
E = %x45
F = %x46
G = %x47
H = %x48
J = %x4A
K = %x4B
M = %x4D
N = %x4E
P = %x50
Q = %x51
T = %x54
V = %x56
W = %x57
X = %x58
Y = %x59
Z = %x5A
H = %x48
J = %x4A
K = %x4B
M = %x4D
N = %x4E
P = %x50
Q = %x51
T = %x54
V = %x56
W = %x57
X = %x58
Y = %x59
Z = %x5A
(8) In Appendix D of RFC 4695, the definitions of <nonzero-four-octet>, <four-octet>, and <midi-chan> are incorrect. The correct definitions of these rules appear below:
(8) 在RFC 4695的附录D中，<nonzero four octet>、<four octet>和<midi chan>的定义不正确。这些规则的正确定义如下所示：
nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT))
/ (%x31-33 9(DIGIT))
/ ("4" %x30-31 8(DIGIT))
/ ("42" %x30-38 7(DIGIT))
/ ("429" %x30-33 6(DIGIT))
/ ("4294" %x30-38 5(DIGIT))
/ ("42949" %x30-35 4(DIGIT))
/ ("429496" %x30-36 3(DIGIT))
/ ("4294967" %x30-31 2(DIGIT))
/ ("42949672" %x30-38 (DIGIT))
/ ("429496729" %x30-34)
nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT))
/ (%x31-33 9(DIGIT))
/ ("4" %x30-31 8(DIGIT))
/ ("42" %x30-38 7(DIGIT))
/ ("429" %x30-33 6(DIGIT))
/ ("4294" %x30-38 5(DIGIT))
/ ("42949" %x30-35 4(DIGIT))
/ ("429496" %x30-36 3(DIGIT))
/ ("4294967" %x30-31 2(DIGIT))
/ ("42949672" %x30-38 (DIGIT))
/ ("429496729" %x30-34)
four-octet = "0" / nonzero-four-octet
midi-chan = DIGIT / ("1" %x30-35)
four-octet = "0" / nonzero-four-octet
midi-chan = DIGIT / ("1" %x30-35)
DIGIT = %x30-39
NZ-DIGIT = %x31-39
DIGIT = %x30-39
NZ-DIGIT = %x31-39
(9) In Appendix D of RFC4695, the rule <hex-octet> is incorrect. The correct definition of this rule appears below.
(9) 在RFC4695的附录D中，规则<hex-octet>不正确。此规则的正确定义如下所示。
hex-octet = %x30-37 U-HEXDIG
U-HEXDIG = DIGIT / A / B / C / D / E / F
hex-octet = %x30-37 U-HEXDIG
U-HEXDIG = DIGIT / A / B / C / D / E / F
; DIGIT as defined in (6) above ; A, B, C, D, E, F as defined in (5) above
; 上述（6）中定义的数字；A、 B、C、D、E、F，如上文（5）中所定义
(10) In Appendix D, the <mime-subtype> rule now points to the <subtype-name> rule in [RFC4288].
（10） 在附录D中，<mime subtype>规则现在指向[RFC4288]中的<subtype name>规则。
(11) In Appendix D of RFC4695, the rules <base64-unit> and <base64-pad> are defined unclearly. The rewritten rules appear below:
（11） 在RFC4695的附录D中，规则<base64 unit>和<base64 pad>的定义不明确。重写的规则如下所示：
base64-unit = 4(base64-char)
base64-pad = (2(base64-char) "==") / (3(base64-char) "=")
base64-unit = 4(base64-char)
base64-pad = (2(base64-char) "==") / (3(base64-char) "=")
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（系统日志章节）中恢复日志位字段描述中使用的术语和编码习惯用法。
We assume that the recovery journal resides in the journal section of an RTP packet with sequence number I ("packet I") and that the Checkpoint Packet Seqnum field in the top-level recovery journal header refers to a previous packet with sequence number C (an exception is the self-referential C = I case). Unless stated otherwise, algorithms are assumed to use modulo 2^16 arithmetic for calculations on 16-bit sequence numbers and modulo 2^32 arithmetic for calculations on 32-bit extended sequence numbers.
我们假设恢复日志位于序列号为I（“数据包I”）的RTP数据包的日志部分，并且顶级恢复日志头中的检查点数据包Seqnum字段引用序列号为C的前一个数据包（一个例外是自参考C=I情况）。除非另有说明，否则假定算法使用模2^16算法计算16位序列号，并使用模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.
在整个恢复日志系统中，出现了几个具有一致语义的位字段编码习惯用法。大多数恢复日志元素以“S”（单数据包丢失）位开始。S位设计用于在单个数据包丢失的常见情况下，帮助接收方有效解析恢复日志层次结构。
As a rule, S bits MUST be set to 1. However, an exception applies if a recovery journal element in packet I encodes data about a command stored in the MIDI command section of packet I - 1. In this case, the S bit of the recovery journal element MUST be set to 0. If a recovery journal element has its S bit set to 0, all higher-level recovery journal elements that contain it MUST also have S bits that are set to 0, including the top-level recovery journal header.
通常，S位必须设置为1。但是，如果数据包I中的恢复日志元素对数据包I-1的MIDI命令部分中存储的命令的数据进行编码，则会出现异常。在这种情况下，恢复日志元素的S位必须设置为0。如果恢复日志元素的S位设置为0，则包含该元素的所有高级恢复日志元素的S位也必须设置为0，包括顶级恢复日志标头。
Other consistent bitfield coding idioms are described below:
其他一致的位字段编码习惯用法如下所述：
o R flag bit. R flag bits are reserved for future use. Senders MUST set R bits to 0. Receivers MUST ignore R bit values.
o R标志位。R标志位保留供将来使用。发件人必须将R位设置为0。接收器必须忽略R位值。
o LENGTH field. All fields named LENGTH (as distinct from LEN) code the number of octets in the structure that contains it, including the header it resides in and all hierarchical levels below it. If a structure contains a LENGTH field, a receiver MUST use the LENGTH field value to advance past the structure during parsing, rather than use knowledge about the internal format of the structure.
o 长度字段。所有名为LENGTH（与LEN不同）的字段编码包含它的结构中的八位字节数，包括它所在的头和它下面的所有层次结构级别。如果一个结构包含一个长度字段，那么接收者必须在解析期间使用长度字段值来超越该结构，而不是使用有关结构内部格式的知识。
We now define normative terms used to describe recovery journal semantics.
现在，我们定义了用于描述恢复日志语义的规范术语。
o Checkpoint history. The checkpoint history of a recovery journal is the concatenation of the MIDI command sections of packets C through I - 1. The final command in the MIDI command section for packet I - 1 is considered the most recent command; the first command in the MIDI command section for packet C is the oldest command. If command X is less recent than command Y, X is considered to be "before Y". A checkpoint history with no commands is considered to be empty. The checkpoint history never contains the MIDI command section of packet I (the packet containing the recovery journal), so if C == I, the checkpoint history is empty by definition.
o 检查点历史记录。恢复日志的检查点历史记录是数据包C到I-1的MIDI命令部分的串联。包I-1的MIDI命令部分的最后一个命令被认为是最新的命令；包C的MIDI命令部分中的第一个命令是最早的命令。如果命令X比命令Y最近，则X被视为“在Y之前”。没有命令的检查点历史记录被认为是空的。检查点历史记录从不包含数据包I（包含恢复日志的数据包）的MIDI命令部分，因此如果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, so the session history of the first packet in the session is empty by definition.
o 会话历史记录。恢复日志的会话历史是从会话的第一个数据包到数据包I-1的MIDI命令段的串联。命令最近性和历史空性的定义遵循检查点历史中的定义。会话历史从不包含数据包I的MIDI命令部分，因此会话中第一个数据包的会话历史定义为空。
o Finished/unfinished commands. If all octets of a MIDI command appear in the session history, the command is defined as being finished. If some but not all octets of a command appear in the session history, the command is defined as being unfinished. Unfinished commands occur if segments of a SysEx command appear in several RTP packets. For example, if a SysEx command is coded as 3 segments, with segment 1 in packet K, segment 2 in packet K + 1, and segment 3 in packet K + 2, the session histories for packets K + 1 and K + 2 contain unfinished versions of the command. A session history contains a finished version of a cancelled SysEx command if the history contains the cancel sublist for the command.
o 已完成/未完成的命令。如果MIDI命令的所有八位字节都出现在会话历史记录中，则该命令被定义为已完成。如果某个命令的部分但不是全部八位字节出现在会话历史记录中，则该命令被定义为未完成。如果SysEx命令的段出现在多个RTP数据包中，则会出现未完成的命令。例如，如果SysEx命令被编码为3段，其中数据包K中有段1，数据包K+1中有段2，数据包K+2中有段3，则数据包K+1和K+2的会话历史记录包含该命令的未完成版本。如果会话历史记录包含已取消SysEx命令的取消子列表，则会话历史记录包含已取消SysEx命令的完成版本。
o Reset State commands. Reset State (RS) commands reset renderers to an initialized "powerup" condition. The RS commands are System Reset (0xFF), General MIDI System Enable (0xF0 0x7E 0xcc 0x09 0x01 0xF7), General MIDI 2 System Enable (0xF0 0x7E 0xcc 0x09 0x03 0xF7), General MIDI System Disable (0xF0 0x7E 0xcc 0x09 0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 0x01 0xF7), and Turn DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7). Registrations of subrender parameter token values (Appendix C.6.2) and IETF Standards-Track documents MAY specify additional RS commands.
o 重置状态命令。重置状态（RS）命令将渲染器重置为初始化的“通电”状态。RS命令包括系统复位（0xFF）、通用MIDI系统启用（0xF0 0x7E 0xcc 0x09 0x01 0xF7）、通用MIDI 2系统启用（0xF0 0x7E 0xcc 0x09 0x03 0xF7）、通用MIDI系统禁用（0xF0 0x7E 0xcc 0x09 0x00 0xF7）、打开DLS（0xF0 0x7E 0xcc 0x0A 0x01 0xF7）和关闭DLS（0xF0 0x7E 0xcc 0x0A 0x02 0xF7）。子渲染参数标记值（附录C.6.2）和IETF标准跟踪文件的注册可指定其他RS命令。
o Active commands. Active commands are MIDI commands that do not appear before a Reset State command in the session history.
o 活动命令。活动命令是MIDI命令，不会出现在会话历史记录中的重置状态命令之前。
o N-active commands. N-active commands are MIDI commands that do not appear before one of the following commands in the session history: MIDI Control Change numbers 123-127 (numbers with All Notes Off semantics) or 120 (All Sound Off), and any Reset State command.
o N-激活命令。N-active命令是不会出现在会话历史记录中以下命令之一之前的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-active命令。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 最早的第一顺序规则。几个恢复日志章节包含一个元素列表，其中每个元素都与会话历史记录中出现的MIDI命令相关联。在大多数情况下，章节定义要求列表元素按照“最早的优先排序规则”进行排序。下面，我们对该规则进行规范性定义。
Elements associated with the most recent command in the session history coded in the list MUST appear at the end of the list.
与列表中编码的会话历史中最新命令相关联的元素必须显示在列表的末尾。
Elements associated with the oldest command in the session history coded in the list MUST appear at the start of the list.
与列表中编码的会话历史中最早的命令关联的元素必须出现在列表的开头。
All other list elements MUST be arranged with respect to these boundary elements, to produce a list ordering that strictly reflects the relative session history recency of the commands coded by the elements in the list.
所有其他列表元素必须相对于这些边界元素进行排列，以生成严格反映由列表中元素编码的命令的相对会话历史最近性的列表顺序。
o Parameter system. A MIDI feature that provides two sets of 16,384 parameters to expand the 0-127 controller number space. The Registered Parameter Numbers (RPN) system and the Non-Registered Parameter Numbers (NRPN) system each provide 16,384 parameters.
o 参数系统。一种MIDI功能，提供两组16384参数以扩展0-127控制器编号空间。注册参数编号（RPN）系统和非注册参数编号（NRPN）系统分别提供16384个参数。
o Parameter system transaction. RPN and NRPN values are changed by a series of Control Change commands that form a parameter system transaction. A canonical transaction begins with two Control Change commands to set the parameter number (controller numbers 99 and 98 for NRPN parameters, controller numbers 101 and 100 for RPN parameters). The transaction continues with an arbitrary number of Data Entry (controller numbers 6 and 38), Data Increment (controller number 96), and Data Decrement (controller number 97) Control Change commands to set the parameter value. The transaction ends with a second pair of (99, 98) or (101, 100) Control Change commands that specify the null parameter (Most Significant Bit (MSB) value 0x7F, Least Significant Bit (LSB) value 0x7F).
o 参数系统事务。RPN和NRPN值由一系列控制更改命令更改，这些命令构成参数系统事务。规范事务从两个控制更改命令开始，以设置参数编号（控制器编号99和98用于NRPN参数，控制器编号101和100用于RPN参数）。通过任意数量的数据输入（控制器编号6和38）、数据增量（控制器编号96）和数据减量（控制器编号97）控制更改命令来设置参数值，事务将继续进行。事务以第二对（99，98）或（101，100）控制更改命令结束，这些命令指定空参数（最高有效位（MSB）值0x7F，最低有效位（LSB）值0x7F）。
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参数以外的参数。在这种情况下，命令对终止第一个事务并启动第二个事务。命令对被认为是这两个事务的一部分。此变体是合法的，建议在[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.
不太常见的是，（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-active Control Change命令的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）控制更改命令之后至少有一个事务命令，则认为事务已启动。事务的完成不会使其“已启动”状态无效。
o Session history reference counts. Several recovery journal chapters include a reference count field, which codes the total number of commands of a type that appear in the session history. Examples include the Reset and Tune Request command logs (Appendix
o 会话历史记录引用计数。几个恢复日志章节包括引用计数字段，该字段对会话历史记录中出现的某一类型的命令总数进行编码。示例包括重置和调优请求命令日志（附录
B.1, "System Chapter D") and the Active Sense command (Appendix B.2, "System Chapter V"). Upon the detection of a loss event, reference count fields let a receiver deduce if any instances of the command have been lost, by comparing the journal reference count with its own reference count. Thus, a reference count field makes sense, even for command types in which knowing the NUMBER of lost commands is irrelevant (as is true with all of the example commands mentioned above).
B.1，“系统第D章”）和主动感知命令（附录B.2，“系统第V章”）。在检测到丢失事件时，引用计数字段允许接收方通过将日志引用计数与其自身的引用计数进行比较来推断命令的任何实例是否丢失。因此，引用计数字段是有意义的，即使对于不知道丢失命令数量的命令类型也是有意义的（上述所有示例命令都是如此）。
The chapter definitions in Appendices A.2 to A.9 and B.1 to B.5 reflect the default recovery journal behavior. The ch_default, ch_never, and ch_anchor parameters modify these definitions, as described in Appendix C.2.3.
附录A.2至A.9和B.1至B.5中的章节定义反映了默认恢复日记账行为。如附录C.2.3所述，Chu默认、Chu never和Chu 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PROGRAM |B| BANK-MSB |X| BANK-LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.2.1 -- Chapter P Format
图A.2.1——第P章格式
The chapter has a fixed size of 24 bits. The PROGRAM field indicates the data value of the most recent active Program Change command in the session history. By default, the B, BANK-MSB, X, and BANK-LSB fields MUST be set to 0. Below, we define exceptions to this default condition.
章节的固定大小为24位。PROGRAM（程序）字段表示会话历史记录中最近激活的程序更改命令的数据值。默认情况下，B、BANK-MSB、X和BANK-LSB字段必须设置为0。下面，我们定义此默认条件的例外情况。
If an active Control Change (0xB) command for controller number 0 (Bank Select MSB) appears before the Program Change command in the session history, the B bit MUST be set to 1, and the BANK-MSB field MUST code the data value of the Control Change command.
如果在会话历史记录中，控制器编号0（Bank Select MSB）的活动控制更改（0xB）命令出现在程序更改命令之前，则B位必须设置为1，并且Bank-MSB字段必须对控制更改命令的数据值进行编码。
If B is set to 1, the BANK-LSB field MUST code the data value of the most recent Control Change command for controller number 32 (Bank Select LSB) that preceded the Program Change command coded in the PROGRAM field and followed the Control Change command coded in the BANK-MSB field. If no such Control Change command exists, the BANK-LSB field MUST be set to 0.
如果B设置为1，则BANK-LSB字段必须对控制器编号32（BANK Select 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字段编码的控制更改命令和由Program字段编码的程序更改命令之间的MIDI流中，则X位必须设置为1。
Note that [RP015] specifies that Reset All Controllers does not reset the values of controller numbers 0 (Bank Select MSB) and 32 (Bank Select LSB). Thus, the X bit does not affect how receivers will use the BANK-LSB and BANK-MSB values when recovering from a lost Program Change command. The X bit serves to aid recovery in MIDI applications where controller numbers 0 and 32 are used in a non-standard way.
请注意，[RP015]指定重置所有控制器不会重置控制器编号0（组选择MSB）和32（组选择LSB）的值。因此，当从丢失的程序更改命令中恢复时，X位不会影响接收器如何使用BAK-LSB和BAK-MSB值。在以非标准方式使用控制器编号0和32的MIDI应用程序中，X位用于帮助恢复。
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 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| VALUE/ALT | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.3.1 -- Chapter C Format
图A.3.1——第C章格式
The chapter consists of a 1-octet header followed by a variable-length list of 2-octet controller logs. The list MUST contain at least one controller log. The 7-bit LEN field codes the number of controller logs in the list, minus one. We define the semantics of the controller log fields in Appendix A.3.2.
本章由一个1-octet标题和一个2-octet控制器日志的可变长度列表组成。该列表必须至少包含一个控制器日志。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.
如果本附录中定义的规则要求列表中出现一个或多个控制器日志，则通道日志必须包含第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）和最低有效字节（LSB，控制器编号32-63、98、100）控制更改命令[MIDI]传输14位控制器值。
If the most recent active Control Change command in the session history for a 14-bit controller pair uses the MSB number, Chapter C MAY omit the controller log for the most recent active Control Change command for the associated LSB number, as the command ordering makes this LSB value irrelevant. However, this exception MUST NOT be applied if the sender is not certain that the MIDI source uses 14-bit semantics for the controller number pair. Note that some MIDI sources ignore 14-bit controller semantics and use the LSB controller numbers as independent 7-bit controllers.
如果14位控制器对的会话历史记录中的最新活动控制更改命令使用MSB编号，则C章可能会忽略关联LSB编号的最新活动控制更改命令的控制器日志，因为命令顺序使此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（Bank Select MSB）或32（Bank Select LSB）的活动控制更改命令，并且如果命令实例也在第P章（附录A.2）的Bank-MSB和Bank-LSB字段中编码，则第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（全向关闭）和125（全向打开）形成互斥对，控制器编号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.
如果检查点历史记录中出现互斥对的一个或两个成员的活动控制更改命令，则检查点历史记录中该对的最新命令的控制器编号日志必须出现在控制器列表中。但是，该列表可能会忽略该对中其他编号的最新激活命令的控制器日志。
If active Control Change commands for one or both members of a mutually exclusive pair appear in the session history, and if a log for the controller number of the most recent command for the pair does not appear in the controller list, a log for the most recent command for the other number of the pair MUST NOT appear in the controller list.
如果会话历史记录中出现互斥对的一个或两个成员的活动控制更改命令，并且如果该对的最新命令的控制器编号日志未出现在控制器列表中，则该对的其他编号的最新命令的日志不得出现在控制器列表中。
o If an active Control Change command for controller number 121 (Reset All Controllers) appears in the session history, the controller list MAY omit logs for Control Change commands that precede the Reset All Controllers command in the session history, under certain conditions.
o 如果会话历史记录中出现控制器编号121（重置所有控制器）的活动控制更改命令，则在某些情况下，控制器列表可能会忽略会话历史记录中重置所有控制器命令之前的控制更改命令日志。
Namely, a log MAY be omitted if the sender is certain that a command stream follows the Reset All Controllers semantics defined in [RP015] and if the log codes a controller number for which [RP015] specifies a reset value.
也就是说，如果发送方确定命令流遵循[RP015]中定义的“重置所有控制器”语义，并且如果日志对[RP015]指定重置值的控制器编号进行编码，则可以省略日志。
For example, [RP015] specifies that controller number 1 (Modulation Wheel) is reset to the value 0, and thus a controller log for Modulation Wheel MAY be omitted from the controller log list. In contrast, [RP015] specifies that controller number 7 (Channel Volume) is not reset, and thus a controller log for Channel Volume MUST NOT be omitted from the controller log list.
例如，[RP015]指定控制器编号1（调制轮）重置为值0，因此可以从控制器日志列表中省略调制轮的控制器日志。相反，[RP015]指定控制器编号7（通道卷）不会重置，因此通道卷的控制器日志不能从控制器日志列表中省略。
o Appendix A.3.4 defines exception rules for the MIDI Parameter System controller numbers 6, 38, and 96-101.
o 附录A.3.4定义了MIDI参数系统控制器编号6、38和96-101的例外规则。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |A| VALUE/ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.3.2 -- Chapter C Controller Log
图A.3.2——第C章控制器日志
The 7-bit NUMBER field identifies the controller number of the coded command. The 7-bit VALUE/ALT field codes recovery information for the command. The A bit sets the format of the VALUE/ALT field.
7位数字字段标识编码命令的控制器编号。7位VALUE/ALT字段对命令的恢复信息进行编码。A位设置值/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.
将A位设置为1以对切换或计数工具进行编码。这些工具最适用于编写离散动作代码的控制器。图A.3.3显示了这些工具的控制器日志。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |1|T| ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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，则日志使用计数工具。这两种方法都将6位ALT字段用作无符号整数。
The toggle tool works best for controllers that act as on/off switches, such as 64 (Damper Pedal (Sustain)). These controllers code the "off" state with control values 0-63 and the "on" state with 64-127.
切换工具最适合用作开/关开关的控制器，例如64（减振器踏板（保持））。这些控制器用控制值0-63编码“关闭”状态，用64-127编码“打开”状态。
For the toggle tool, the ALT field codes the total number of toggles (off->on and on->off) due to Control Change commands in the session history, up to and including a toggle caused by the command coded by the log. The toggle count includes toggles caused by Control Change commands for controller number 121 (Reset All Controllers).
对于切换工具，ALT字段编码由于会话历史记录中的控制更改命令而进行的切换（关闭->打开和打开->关闭）总数，包括由日志编码的命令引起的切换。切换计数包括控制器编号121（重置所有控制器）的控制更改命令引起的切换。
Toggle counting is performed modulo 64. The toggle count is reset at the start of a session and whenever a Reset State command (Appendix A.1) appears in the session history. When these reset events occur, the toggle count for a controller is set to 0 (for controllers whose default value is 0-63) or 1 (for controllers whose default value is 64-127).
切换计数以64模执行。切换计数在会话开始时以及会话历史记录中出现重置状态命令（附录a.1）时重置。发生这些重置事件时，控制器的切换计数设置为0（对于默认值为0-63的控制器）或1（对于默认值为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.
减震器踏板（保持）控制器说明了切换工具相对于开关控制器的值工具的优点。正如在钢琴应用中经常使用的那样，控制器的“开”状态让音符产生共振，而“关”状态会立即抑制音符，使其静音。在“开->关->开”序列中丢失“关”命令会导致本应被抑制为静音的铃声。切换工具允许接收器检测到丢失的“关闭”命令，但值工具没有。
The count tool is conceptually similar to the toggle tool. For the count tool, the ALT field codes the total number of Control Change commands in the session history, up to and including the command coded by the log. Command counting is performed modulo 64. The command count is set to 0 at the start of the session and is reset to 0 whenever a Reset State command (Appendix A.1) appears in the session history.
计数工具在概念上类似于切换工具。对于计数工具，ALT字段编码会话历史记录中控制更改命令的总数，包括日志编码的命令。命令计数以64模执行。在会话开始时，命令计数被设置为0，并且每当会话历史记录中出现重置状态命令（附录a.1）时，命令计数被重置为0。
Because the count tool ignores the data value, it is a good match for controllers whose controller value is ignored, such as number 123 (All Notes Off). More generally, the count tool may be used to code a (modulo 64) identification number for a command.
由于“计数”工具忽略数据值，因此对于忽略其控制器值的控制器来说，它是一个很好的匹配项，例如数字123（所有注释均已关闭）。更一般地，计数工具可用于为命令编码（模64）标识号。
In this section, we describe the organization of controller logs in the Chapter C log list.
在本节中，我们将在第C章日志列表中描述控制器日志的组织。
A log encodes information about a particular Control Change command in the session history. In most cases, a command SHOULD be coded by a single tool (and, thus, a single log). If a number is coded with a single tool and this tool is the count tool, recovery Control Change commands generated by a receiver SHOULD use the default control value for the controller.
日志对会话历史记录中特定控件更改命令的信息进行编码。在大多数情况下，一个命令应该由一个工具编码（因此，一个日志）。如果使用单个工具对数字进行编码，并且此工具是计数工具，则接收器生成的恢复控制更改命令应使用控制器的默认控制值。
However, a command MAY be coded by several tool types (and, thus, several logs, each using a different tool). This technique may improve recovery performance for controllers with complex semantics, such as controller number 84 (Portamento Control) or controller number 121 (Reset All Controllers) when used with a non-zero data octet (with the semantics described in [DLS2]).
但是，一个命令可以由几种工具类型（因此，还有几种日志，每种日志使用不同的工具）进行编码。此技术可提高具有复杂语义的控制器的恢复性能，例如当与非零数据八位字节（具有[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.
C章日志列表必须遵守最早的首次订购规则（定义见附录A.1）。请注意，此顺序保留恢复14位控制器值所需的信息，而不排除将MSB和LSB控制器对用作独立的7位控制器。
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.
在有效负载格式的默认使用中，控制器编号列表中出现的所有日志都对一个控制更改命令的信息进行编码，即会话历史中该编号的最新活动控制更改命令。
This coding scheme provides good recovery performance for the standard uses of Control Change commands defined in [MIDI]. However, not all MIDI applications restrict the use of Control Change commands to those defined in [MIDI].
此编码方案为[MIDI]中定义的控制更改命令的标准使用提供了良好的恢复性能。但是，并非所有MIDI应用程序都将控制更改命令的使用限制为[MIDI]中定义的命令。
For example, consider the common MIDI encoding of rotary encoders ("infinite" rotation knobs). The mixing console MIDI convention defined in [LCP] codes the position of rotary encoders as a series of Control Change commands. Each command encodes a relative change of knob position from the last update (expressed as a clockwise or counter-clockwise knob-turning angle).
例如，考虑旋转编码器的常见MIDI编码（“无限”旋转旋钮）。[LCP]中定义的混音控制台MIDI约定将旋转编码器的位置编码为一系列控制更改命令。每个命令对上次更新后旋钮位置的相对变化进行编码（表示为顺时针或逆时针旋钮旋转角度）。
As the knob position is encoded incrementally over a series of Control Change commands, the best recovery performance is obtained if the log list encodes all Control Change commands for encoder controller numbers that appear in the checkpoint history, not only the most recent command.
由于旋钮位置是通过一系列控制更改命令递增编码的，因此，如果日志列表对检查点历史记录中出现的编码器控制器编号的所有控制更改命令（而不仅仅是最近的命令）进行编码，则可获得最佳恢复性能。
To support application areas that use Control Change commands in this way, Chapter C may be configured to encode information about several Control Change commands for a controller number. We use the term "enhanced" to describe this encoding method, which we describe below.
为了支持以这种方式使用控制更改命令的应用领域，可以将第C章配置为对控制器编号的多个控制更改命令的信息进行编码。我们使用术语“增强”来描述这种编码方法，我们将在下面描述。
In Appendix C.2.3, we show how to configure a stream to use enhanced Chapter C encoding for specific controller numbers. In Section 5 in the main text, we show how the H bits in the recovery journal header (Figure 8) and in the channel journal header (Figure 9) indicate the use of enhanced Chapter C encoding.
在附录C.2.3中，我们展示了如何配置流，以便对特定控制器编号使用增强的C章编码。在正文的第5节中，我们将展示恢复日志头（图8）和通道日志头（图9）中的H位如何指示使用增强的C章编码。
Here, we define how to encode a Chapter C log list that uses the enhanced encoding method.
在这里，我们定义如何对使用增强编码方法的第C章日志列表进行编码。
Senders that use the enhanced encoding method for a controller number MUST obey the rules below. These rules let a receiver determine which logs in the list correspond to lost commands. Note that these rules override the exceptions listed in Appendix A.3.1.
对控制器编号使用增强编码方法的发件人必须遵守以下规则。这些规则让接收者确定列表中哪些日志对应于丢失的命令。注意，这些规则优先于附录A.3.1中列出的例外情况。
o If N commands for a controller number are encoded in the list, the commands MUST be the N most recent commands for the controller number in the session history. For example, for N = 2, the sender MUST encode the most recent command and the second most recent command, not the most recent command and the third most recent command.
o 如果列表中对控制器编号的N个命令进行了编码，则这些命令必须是会话历史记录中控制器编号的N个最新命令。例如，对于N=2，发送方必须编码最近的命令和第二个最近的命令，而不是最近的命令和第三个最近的命令。
o If a controller number uses enhanced encoding, the encoding of the least recent command for the controller number in the log list MUST include a count tool log. In addition, if commands are
o 如果控制器编号使用增强编码，则日志列表中控制器编号的最新命令的编码必须包括计数工具日志。此外，如果命令是
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.
针对其日志的S位设置为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, either a value tool log MUST appear for all commands for the controller number coded in the list or, alternatively, value tool logs for the controller number MUST NOT appear in the list. Likewise, either a toggle tool log MUST appear for all commands for the controller number coded in the list or, alternatively, toggle tool logs for the controller number MUST NOT appear in the list.
o 对于列表中编码的控制器编号的所有命令，值和切换工具的使用必须相同。例如，对于列表中编码的控制器编号的所有命令，必须显示值工具日志，或者，控制器编号的值工具日志不得显示在列表中。同样，对于列表中编码的控制器编号的所有命令，必须显示切换工具日志，或者，控制器编号的切换工具日志不得显示在列表中。
o If a command is encoded by multiple tools, the logs MUST be placed in the list in the following order: count tool log (if any), followed by value tool log (if any), followed by toggle tool log (if any).
o 如果命令由多个工具编码，则日志必须按以下顺序放置在列表中：计数工具日志（如果有），然后是值工具日志（如果有），然后是切换工具日志（如果有）。
These rules permit a receiver recovering from a packet loss to use the count tool log to match the commands encoded in the list with its own history of the stream, as we describe below. Note that the text below describes a non-normative algorithm; receivers are free to use any algorithm to match its history with the log list.
这些规则允许从数据包丢失中恢复的接收器使用计数工具日志将列表中编码的命令与其自身的流历史相匹配，如下所述。请注意，下文描述了一种非规范性算法；接收者可以自由使用任何算法将其历史与日志列表匹配。
In a typical implementation of the enhanced encoding method, a receiver computes and stores count, value, and toggle tool data field values for the most recent Control Change command it has received for a controller number.
在增强编码方法的典型实现中，接收器计算并存储最近收到的控制器编号控制更改命令的计数、值和切换工具数据字段值。
After a loss event, a receiver parses the Chapter C list and processes list logs for a controller number that uses enhanced encoding as follows.
丢失事件发生后，接收方解析C章列表并处理列表日志，以获取使用增强编码的控制器编号，如下所示。
The receiver compares the count tool ALT field for the least recent command for the controller number in the list against its stored count data for the controller number to determine if recovery is necessary for the command coded in the list. The value and toggle tool logs (if any) that directly follow the count tool log are associated with this least recent command.
接收器将列表中控制器号的最新命令的计数工具ALT字段与其存储的控制器号计数数据进行比较，以确定列表中编码的命令是否需要恢复。直接跟随计数工具日志的值和切换工具日志（如果有）与此最新命令相关联。
To check more recent commands for the controller, the receiver detects additional value and/or toggle tool logs for the controller number in the list and infers count tool data for the command coded by these logs. This inferred data is used to determine if recovery is necessary for the command coded by the value and/or toggle tool logs.
为了检查控制器的最新命令，接收器检测列表中控制器编号的附加值和/或切换工具日志，并推断这些日志编码的命令的计数工具数据。此推断数据用于确定值和/或切换工具日志编码的命令是否需要恢复。
In this way, a receiver is able to execute only lost commands, without executing a command twice. While recovering from a single packet loss, a receiver may skip through S = 1 logs in the list, as the first S = 0 log for an enhanced controller number is always a count tool log.
通过这种方式，接收器只能执行丢失的命令，而无需执行两次命令。当从单个数据包丢失中恢复时，接收器可能会跳过列表中的S=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 their count tool data structures with recovery journal data in order to match commands correctly after a loss event.
请注意，附录C.2.2.2中关于多播操作会话启动期间保护发送方和接收方行动的要求对于增强编码特别重要，因为接收方需要使用恢复日志数据初始化其计数工具数据结构，以便在丢失事件后正确匹配命令。
Finally, we note in passing that in some applications of rotary encoders, a good user experience may be possible without the use of enhanced encoding. These applications are distinguished by visual feedback of encoding position that is driven by the post-recovery rotary encoding stream and relatively low packet loss. In these domains, recovery performance may be acceptable for rotary encoders if the log list encodes only the most recent command and if both count and value logs appear for the command.
最后，我们顺便注意到，在旋转编码器的一些应用中，不使用增强编码就可以获得良好的用户体验。这些应用的区别在于由恢复后旋转编码流驱动的编码位置的视觉反馈和相对较低的分组丢失。在这些域中，如果日志列表仅对最近的命令进行编码，并且如果该命令同时出现计数和值日志，则旋转编码器的恢复性能可能是可接受的。
Readers may wish to review the Appendix A.1 definitions of "parameter system", "parameter system transaction", and "initiated parameter system transaction" before reading this section.
在阅读本节之前，读者可能希望阅读附录A.1“参数系统”、“参数系统交易”和“启动的参数系统交易”的定义。
Parameter system transactions update a MIDI Registered Parameter Numbers (RPN) or Non-Registered Parameter Numbers (NRPN) value. A parameter system transaction is a sequence of Control Change commands that may use the following controllers numbers:
参数系统事务更新MIDI注册参数编号（RPN）或非注册参数编号（NRPN）值。参数系统事务是一系列控制更改命令，可使用以下控制器编号：
o Data Entry MSB (6) o Data Entry LSB (38) o Data Increment (96) o Data Decrement (97) o Non-Registered Parameter Number (NRPN) LSB (98) o Non-Registered Parameter Number (NRPN) MSB (99) o Registered Parameter Numbers (RPN) LSB (100) o Registered Parameter Numbers (RPN) MSB (101)
o 数据项MSB（6）o数据项LSB（38）o数据增量（96）o数据减量（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.
作为参数系统事务一部分的控制更改命令不得在第C章控制器日志中进行编码。相反，这些命令在附录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.
相反，控制器在第C章控制器日志中进行编码。控制器日志遵循附录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的主动控制更改命令出现在检查点历史记录中，并且这些命令用作通用控制器，则这些控制器编号的最新通用命令实例必须作为条目出现在第C章控制器列表中。
MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as parameter-system controllers and general-purpose controllers in the same stream. An RTP MIDI sender MUST deduce the role of each Control Change command for these controller numbers by noting the placement of the command in the stream and MUST use this information to code the command in Chapter C or Chapter M, as appropriate.
MIDI语法允许源代码将控制器6、38、96和97用作同一流中的参数系统控制器和通用控制器。RTP MIDI发送方必须通过记录命令在流中的位置来推断这些控制器编号的每个控制更改命令的作用，并且必须使用此信息在第C章或第M章（视情况而定）中对命令进行编码。
Specifically, active Control Change commands for controllers 6, 38, 96, and 97 act in a general-purpose way when
具体而言，控制器6、38、96和97的主动控制更改命令在以下情况下以通用方式运行：
o no active Control Change commands that set an RPN or NRPN parameter number appear in the session history, or
o 会话历史记录中未出现设置RPN或NRPN参数号的活动控制更改命令，或
o the most recent active Control Change commands in the session history that set an RPN or NRPN parameter number code the null parameter (MSB value 0x7F, LSB value 0x7F), or
o 会话历史记录中设置RPN或NRPN参数编号的最新活动控件更改命令对空参数（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 与设置RPN或NRPN参数号的所有活动控制更改命令相比，用于控制器编号121（重置所有控制器）的控制更改命令最近出现在会话历史记录中（有关详细信息，请参阅[RP015]）。
Finally, we note that a MIDI source that follows the recommendations of [MIDI] exclusively uses numbers 98-101 as parameter system controllers. Alternatively, a MIDI source may exclusively use 98-101 as general-purpose controllers and lose the ability to perform parameter system transactions in a stream.
最后，我们注意到，遵循[MIDI]建议的MIDI源专门使用数字98-101作为参数系统控制器。或者，MIDI源可能专门使用98-101作为通用控制器，并失去在流中执行参数系统事务的能力。
In the language of [MIDI], the general-purpose use of controllers 98-101 constitutes a non-standard controller assignment. As most real-world MIDI sources use the standard controller assignment for controller numbers 98-101, an RTP MIDI sender SHOULD assume these controllers act as parameter system controllers, unless it knows that a MIDI source uses controller numbers 98-101 in a general-purpose way.
在[MIDI]语言中，控制器98-101的通用用途构成非标准控制器分配。由于大多数真实世界的MIDI源对控制器编号98-101使用标准控制器分配，RTP MIDI发送器应假定这些控制器充当参数系统控制器，除非它知道MIDI源以通用方式使用控制器编号98-101。
Readers may wish to review the Appendix A.1 definitions for "C-active commands", "parameter system", "parameter system transaction", and "initiated parameter system transaction" before reading this appendix.
在阅读本附录之前，读者可能希望查看附录A.1“C-激活命令”、“参数系统”、“参数系统事务”和“启动的参数系统事务”的定义。
Chapter M protects parameter system transactions for Registered Parameter Numbers (RPN) and Non-Registered Parameter Numbers (NRPN) values. Figure A.4.1 shows the format for Chapter M.
第M章保护注册参数号（RPN）和非注册参数号（NRPN）值的参数系统事务。图A.4.1显示了第M章的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|E|U|W|Z| LENGTH |Q| PENDING | Log list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-octet头开始。如果P报头位设置为1，报头后面会有一个1-octet字段，对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中定义的规则要求列表中出现一个或多个参数日志，则通道日志必须包含第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-active Control Change命令为
o an RPN MSB (101) or NRPN MSB (99) controller, or
o RPN MSB（101）或NRPN MSB（99）控制器，或
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 完成空参数（MSB值0x7F，LSB值0x7F）编码的RPN LSB（100）或NRPN LSB（98）控制器。
This rule provides loss protection for partially transmitted parameter numbers and for the null parameter numbers.
此规则为部分传输的参数号和空参数号提供丢失保护。
If the most recent C-active Control Change command involved in a parameter system transaction in the session history is for the RPN MSB or NRPN MSB controller, the P header bit MUST be set to 1, and the PENDING field (and its associated Q bit) MUST follow the Chapter M header. Otherwise, the P header bit MUST be set to 0, and the PENDING field and Q bit MUST NOT appear in Chapter M.
如果会话历史记录中参数系统事务中涉及的最新C-active Control Change命令是针对RPN MSB或NRPN MSB控制器的，则P标头位必须设置为1，且挂起字段（及其关联的Q位）必须位于第M章标头之后。否则，P头位必须设置为0，并且挂起字段和Q位不得出现在章节M中。
If PENDING codes an NRPN MSB controller, the Q bit MUST be set to 1. If PENDING codes an RPN MSB controller, the Q bit MUST be set to 0.
如果对NRPN MSB控制器执行挂起代码，则必须将Q位设置为1。如果对RPN MSB控制器执行挂起代码，则必须将Q位设置为0。
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 parameter system transaction Control Change命令，则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-active parameter system transaction Control Change命令用于NRPN LSB或RPN LSB控制器编号，并且如果此命令用于完成空参数（MSB值0x7F，LSB值0x7F）的编码，则E位必须设置为0。
o Otherwise, an initiated transaction is in progress, and the E bit MUST be set to 1.
o 否则，启动的事务正在进行中，E位必须设置为1。
The U, W, and Z header bits code properties that are shared by all parameter logs in the list. If these properties are set, parameter logs may be coded with improved efficiency (we explain how in A.4.2).
列表中所有参数日志共享的U、W和Z头位代码属性。如果设置了这些属性，参数日志的编码效率可能会提高（我们将在A.4.2中解释如何进行编码）。
By default, the U, W, and Z bits MUST be set to 0. If all parameter logs in the list code RPN parameters, the U bit MAY be set to 1. If all parameter logs in the list code NRPN parameters, the W bit MAY be set to 1. If the parameter numbers of all RPN and NRPN logs in the list lie in the range 0-127 (and thus have an MSB value of 0), the Z bit MAY be set to 1.
默认情况下，U、W和Z位必须设置为0。如果所有参数都记录在列表代码RPN参数中，则U位可设置为1。如果所有参数都记录在列表代码NRPN参数中，则W位可设置为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).
请注意，C-active语义出现在前面的段落中，因为[RP015]指定通过控制器编号121（重置所有控制器）的控制更改命令关闭挂起的参数系统事务。
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）和日志列表排序规则对空参数语义进行编码。
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.
注意，前面段落中出现“活动”语义（而不是“C-active”语义），因为[RP015]指定了挂起的参数系统事务不会由控制器编号121的控制更改命令重置（重置所有控制器）。但是，下面的规则使用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
在大多数情况下，分配给Chu never参数（附录C.2.3）的RPN和NRPN参数的参数日志可从列表中省略。例外情况适用于以下情况：
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-active命令出现在检查点历史记录中，并且
o the E header bit for the top-level Chapter M header (Figure A.4.1) is set to 1.
o 顶层章节M标题（图A.4.1）的E标题位设置为1。
In this case, a log for the parameter MUST appear in the list. This log informs receivers recovering from a loss that a transaction is in progress so that the receiver is able to correctly interpret RPN or NRPN Control Change commands that follow the loss event.
在这种情况下，参数的日志必须出现在列表中。此日志通知从丢失中恢复的接收方事务正在进行中，以便接收方能够正确解释丢失事件之后的RPN或NRPN控制更改命令。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.2 -- Parameter Log Format
图A.4.2——参数日志格式
The log begins with a header, whose default size (as shown in Figure A.4.2) is 3 octets. If the Q header bit is set to 0, the log encodes an RPN parameter. If Q = 1, the log encodes an NRPN parameter. The 7-bit PNUM-MSB and PNUM-LSB fields code the parameter number and reflect the Control Change command data values for controllers 99 and 98 (for NRPN parameters) or 101 and 100 (for RPN parameters).
日志以标头开始，其默认大小（如图a.4.2所示）为3个八位字节。如果Q头位设置为0，则日志将对RPN参数进行编码。如果Q=1，则日志编码一个NRPN参数。7位PNUM-MSB和PNUM-LSB字段对参数编号进行编码，并反映控制器99和98（对于NRPN参数）或101和100（对于RPN参数）的控制更改命令数据值。
The J, K, L, M, and N header bits form a Table of Contents (TOC) for the log and signal the presence of fixed-sized fields that follow the header. A header bit that is set to 1 codes the presence of a field in the log. The ordering of fields in the log follows the ordering of the header bits in the TOC. Appendices A.4.2.1 and A.4.2.2 define the fields associated with each TOC header bit.
J、K、L、M和N报头位构成日志的目录（TOC），并表示报头后面有固定大小的字段。设置为1的标题位对日志中是否存在字段进行编码。日志中字段的顺序遵循TOC中标题位的顺序。附录A.4.2.1和A.4.2.2定义了与每个TOC头位相关的字段。
The T and V header bits code information about the parameter log but are not part of the TOC. A set T or V bit does not signal the presence of any parameter log field.
T和V头位编码有关参数日志的信息，但不属于TOC的一部分。设置的T或V位不表示存在任何参数日志字段。
If the rules in Appendix A.4.1 state that a log for a given parameter MUST appear in Chapter M, the log MUST code sufficient information to protect the parameter from the loss of active parameter transaction Control Change commands in the checkpoint history.
如果附录A.4.1中的规则规定，给定参数的日志必须出现在第M章中，则该日志必须编码足够的信息，以保护参数不丢失检查点历史记录中的活动参数事务控制更改命令。
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.
如果日志编码的参数被分配给Chu 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.
请注意，在某些情况下，不需要使用日志来保护分配给CHU的参数（见附录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.
参数日志为参数保护提供了两种工具：值工具和计数工具。根据参数的语义，发送者可以使用任意一种工具、两种工具或两种工具来保护给定参数。
The value tool codes information a receiver may use to determine the current value of an RPN or NRPN parameter. If a parameter log uses the value tool, the V header bit MUST be set to 1, and the semantics defined in Appendix A.4.2.1 for setting the J, K, L, and M TOC bits MUST be followed. If a parameter log does not use the value tool, the V bit MUST be set to 0, and the J, K, L, and M TOC bits MUST also be set to 0.
值工具对接收器用于确定RPN或NRPN参数当前值的信息进行编码。如果参数日志使用值工具，则必须将V头位设置为1，并且必须遵循附录a.4.2.1中定义的用于设置J、K、L和M TOC位的语义。如果参数日志不使用值工具，则V位必须设置为0，J、K、L和M TOC位也必须设置为0。
The count tool codes the number of transactions for an RPN or NRPN parameter. If a parameter log uses the count tool, the T header bit MUST be set to 1, and the semantics defined in Appendix A.4.2.2 for setting the N TOC bit MUST be followed. If a parameter log does not use the count tool, the T bit and the N TOC bit MUST be set to 0.
计数工具对RPN或NRPN参数的事务数进行编码。如果参数日志使用计数工具，则T头位必须设置为1，并且必须遵循附录a.4.2.2中定义的用于设置N TOC位的语义。如果参数日志未使用计数工具，则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.
请注意，如果发送方持续对日志使用value（V）或count（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 parameters or NRPN parameters), and all parameter numbers lie in the range 0-127. As described in Appendix A.4, senders MAY signal this condition by setting the top-level Chapter M header bit Z to 1 (to code the restricted range) and by setting the U or W bit to 1 (to code the parameter type).
在许多情况下，日志列表中编码的所有参数都属于一种类型（RPN参数或NRPN参数），所有参数编号都在0-127之间。如附录A.4所述，发送方可通过将顶层章节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个八位字节的报头。删除的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 |
+-+-+-+-+-+-+-+-+
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位ENTRY-MSB字段对会话历史中出现在日志参数事务中的控制器编号6（数据项MSB）的最新活动控件更改命令的数据值进行编码。
The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes the most recent Control Change command for controller 121 (Reset All Controllers) in the session history. Otherwise, the X bit MUST be set to 0.
如果ENTRY-MSB编码的命令位于会话历史记录中控制器121（重置所有控制器）的最新控制更改命令之前，则X位必须设置为1。否则，X位必须设置为0。
A parameter log that uses the value tool MUST include the ENTRY-MSB field if an active Control Change command for controller number 6 appears in the checkpoint history.
如果检查点历史记录中出现控制器编号6的活动控制更改命令，则使用值工具的参数日志必须包含ENTRY-MSB字段。
Note that [RP015] specifies that Control Change commands for controller 121 (Reset All Controllers) do not reset RPN and NRPN values, and thus the X bit would not play a recovery role for MIDI systems that comply with [RP015].
请注意，[RP015]指定控制器121（重置所有控制器）的控制更改命令不会重置RPN和NRPN值，因此X位不会对符合[RP015]的MIDI系统起恢复作用。
However, certain renderers (such as DLS 2 [DLS2]) specify that certain RPN values are reset for some uses of Reset All Controllers. The X bit (and other bitfield features of this nature in this appendix) plays a role in recovery for renderers of this type.
但是，某些渲染器（如DLS 2[DLS2]）指定某些RPN值会在某些情况下重置，以用于重置所有控制器。X位（以及本附录中的其他此性质的位字段功能）在恢复此类渲染器时起作用。
The K TOC bit codes the presence of the octet shown in Figure A.4.4 in the field list.
K TOC位编码字段列表中图A.4.4所示八位字节的存在。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-LSB |
+-+-+-+-+-+-+-+-+
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位ENTRY-LSB字段编码会话历史中控制器编号38（数据输入LSB）的最新激活控制更改命令的数据值，该命令出现在日志参数的事务中。
The X bit MUST be set to 1 if the command coded by ENTRY-LSB precedes the most recent Control Change command for controller 121 (Reset All Controllers) in the session history. Otherwise, the X bit MUST be set to 0.
如果ENTRY-LSB编码的命令位于会话历史中控制器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.
通常，如果检查点历史记录中出现控制器编号38的活动控制更改命令，则使用值工具的参数日志必须包含ENTRY-LSB字段。但是，如果与ENTRY-LSB关联的控制更改命令位于会话历史记录中日志参数的事务中出现的控制器编号6（数据项MSB）的控制更改命令之前，则ENTRY-LSB字段不得出现在参数日志中。
The L TOC bit codes the presence of the octets shown in Figure A.4.5 in the field list.
L TOC位对字段列表中图A.4.5所示的八位字节进行编码。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|X| A-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|X| A-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.5 -- A-BUTTON Field
图A.4.5——A按钮字段
The 14-bit A-BUTTON field codes a count of the number of active Control Change commands for controller numbers 96 and 97 (Data Increment and Data Decrement) in the session history that appear in a transaction for the log parameter.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R| C-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.6 -- C-BUTTON Field
图A.4.6——C按钮字段
The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except that Data Increment and Data Decrement Control Change commands that precede the most recent Control Change command for controller 121 (Reset All Controllers) in the session history are not counted.
14位C按钮字段的语义与A按钮相同，只是会话历史中控制器121（重置所有控制器）的最新控制更改命令之前的数据增量和数据减量控制更改命令不被计算在内。
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按钮和C按钮，如果数据增量和数据减量控制更改命令位于会话历史记录中日志参数事务中出现的控制器编号6（数据项MSB）或38（数据项LSB）的控制更改命令之前，则不计算数据增量和数据减量控制更改命令。
The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers, and the G bit associated with the field codes the sign of the integer (G = 0 for positive or zero, G = 1 for negative).
A按钮和C按钮字段被解释为无符号整数，与字段关联的G位编码整数的符号（G=0表示正或零，G=1表示负）。
To compute and code the count value, initialize the count value to 0, add 1 for each qualifying Data Increment command, and subtract 1 for each qualifying Data Decrement command. After each addition or subtraction, limit the count magnitude to 16383. The G bit codes the sign of the count, and the A-BUTTON or C-BUTTON field codes the count magnitude.
要计算计数值并对其进行编码，请将计数值初始化为0，为每个符合条件的数据增量命令添加1，并为每个符合条件的数据递减命令减去1。每次加法或减法后，将计数大小限制为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按钮字段，如果会话历史中控制器121（重置所有控制器）的最新控制更改命令（重置所有控制器）之前是最新的限定数据增量或数据减量命令，则与A按钮字段关联的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 |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| COUNT |
+-+-+-+-+-+-+-+-+
Figure A.4.7 -- COUNT Field
图A.4.7——计数字段
The 7-bit COUNT codes the number of initiated transactions for the log parameter that appear in the session history. Initiated transactions are counted if they contain one or more active Control Change commands, including commands for controllers 98-101 that initiate the parameter transaction.
7位计数编码会话历史记录中出现的日志参数的已启动事务数。如果启动的事务包含一个或多个活动的控制更改命令，包括用于启动参数事务的控制器98-101的命令，则对启动的事务进行计数。
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。否则，X位必须设置为0。
Transaction counting is performed modulo 128. The transaction count is set to 0 at the start of a session and is reset to 0 whenever a Reset State command (Appendix A.1) appears in the session history.
事务计数以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.
如果检查点历史记录中出现增加事务计数（模数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.
如果检查点历史记录中出现C-active MIDI Pitch Wheel（0xE）命令，则通道日志必须包含章节W。图A.5.1显示了章节W的格式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| FIRST |R| SECOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| FIRST |R| SECOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.5.1 -- Chapter W Format
图A.5.1——第W章格式
The chapter has a fixed size of 16 bits. The FIRST and SECOND fields are the 7-bit values of the first and second data octets of the most recent active Pitch Wheel command in the session history.
章节的固定大小为16位。第一个和第二个字段是会话历史中最近激活的俯仰轮命令的第一个和第二个数据八位字节的7位值。
Note that Chapter W encodes C-active commands and thus does not encode active commands that are not C-active (see the second-to-last paragraph of Appendix A.1 for an explanation of chapter inclusion text in this regard).
请注意，第W章对C-激活命令进行编码，因此不对非C-激活的激活命令进行编码（参见附录A.1第二段至最后一段，以了解章节包含文本在这方面的解释）。
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.
第W章未对“主动但非C-主动”命令进行编码，因为[RP015]声明控制器编号121（重置所有控制器）的控制更改命令用于将变桨轮值重置为0。如果章节W编码了“激活但非C-激活”命令，则在重置所有控制器命令之后的修复操作可能会错误地修复变桨轮值陈旧的流。
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.
在本附录中，我们考虑No.on速度为零的命令。在阅读本附录之前，读者可能希望阅读附录A.1“N-激活命令”的定义。
Chapter N completely protects note commands in streams that alternate between NoteOn and NoteOff commands for a particular note number. However, in rare applications, multiple overlapping NoteOn commands may appear for a note number. Chapter E, described in Appendix A.7, augments Chapter N to completely protect these streams.
第N章完全保护流中的注释命令，该流在特定注释编号的NoteOn和NoteOff命令之间交替。但是，在极少数应用程序中，注释编号可能会出现多个重叠的NoteOn命令。附录A.7中描述的第E章增加了第N章，以完全保护这些流。
A channel journal MUST contain Chapter N if an N-active MIDI NoteOn (0x9) or NoteOff (0x8) command appears in the checkpoint history. Figure A.6.1 shows the format for Chapter N.
如果检查点历史记录中出现N-active MIDI NoteOn（0x9）或NoteOff（0x8）命令，则通道日志必须包含第N章。图A.6.1显示了第N章的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OFFBITS | OFFBITS | .... | OFFBITS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OFFBITS | OFFBITS | .... | OFFBITS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.1 -- Chapter N Format
图A.6.1——第N章格式
Chapter N consists of a 2-octet header followed by at least one of the following data structures:
第N章包括一个2个八位字节的报头，后面至少有一个以下数据结构：
o A list of note logs to code NoteOn commands. o A NoteOff bitfield structure to code NoteOff commands.
o 用于编写NoteOn命令的注释日志列表。o NoteOff位域结构，用于对NoteOff命令进行编码。
We define the header bitfield semantics in Appendix A.6.1. We define the note log semantics and the NoteOff bitfield semantics in Appendix A.6.2.
我们在附录A.6.1中定义了标题位字段语义。我们在附录A.6.2中定义了注释日志语义和注释关闭位字段语义。
If one or more N-active NoteOn or NoteOff commands in the checkpoint history reference a note number, the note number MUST be coded in either the note log list or the NoteOff bitfield structure.
如果检查点历史记录中的一个或多个N-active NoteOn或NoteOff命令引用注释编号，则必须在注释日志列表或NoteOff位字段结构中对注释编号进行编码。
The note log list MUST contain an entry for all note numbers whose most recent checkpoint history appearance is in an N-active NoteOn command. The NoteOff bitfield structure MUST contain a set bit for all note numbers whose most recent checkpoint history appearance is in an N-active NoteOff command.
注释日志列表必须包含所有注释编号的条目，这些注释编号的最新检查点历史记录出现在N-active NoteOn命令中。NoteOff位字段结构必须包含所有最近检查点历史记录出现在N-active NoteOff命令中的注释编号的设置位。
A note number MUST NOT be coded in both structures.
不得在两种结构中对注释编号进行编码。
All note logs and NoteOff bitfield set bits MUST code the most recent N-active NoteOn or NoteOff reference to a note number in the session history.
所有注释日志和NoteOff位字段设置位必须编码会话历史记录中注释编号的最新N-active NoteOn或NoteOff引用。
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.
图A.6.2所示的第N章标题对注释列表和位字段结构的大小进行了编码。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.2 -- Chapter N Header
图A.6.2——第N章标题
The LEN field, a 7-bit integer value, codes the number of 2-octet note logs in the note list. Zero is a valid value for LEN and codes an empty note list.
LEN字段是一个7位整数值，用于编码注释列表中2个八位字节的注释日志数。零是LEN的有效值，编码为空注释列表。
The 4-bit LOW and HIGH fields code the number of OFFBITS octets that follow the note log list. LOW and HIGH are unsigned integer values. If LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the chapter. The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH = 1) code an empty NoteOff bitfield structure (i.e., no OFFBITS octets). Other (LOW > HIGH) value pairs MUST NOT appear in the header.
4位低位和高位字段编码注释日志列表后面的位外八位字节数。LOW和HIGH是无符号整数值。如果LOW<=HIGH，则本章中有（HIGH-LOW+1）位八位字节。值对（低=15，高=0）和（低=15，高=1）编码一个空的NoteOff位字段结构（即，没有OFFBITS八位字节）。其他（低>高）值对不得出现在标题中。
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。但是，如果上一个数据包（数据包I-1，I如附录A.1中所定义）的MIDI命令部分包括信道的NoteOff命令，则B位必须设置为0。如果B位设置为0，则包含章节N的高级恢复日志元素的S位必须设置为0，包括顶级日志标题。
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.
根据LOW和HIGH的值，LEN值127表示注释列表长度为127或128个注释日志。如果LEN=127，LOW=15，HIGH=0，则注释列表包含128条注释日志，NoteOff位字段结构为空。对于LOW和HIGH的其他值，LEN=127个代码，注释列表包含127个注释日志。在这种情况下，如果低<=高，章节有（高-低+1）注释位八位字节，如果低=15和高=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.3 -- Chapter N Note Log
图A.6.3——第N章注释日志
The 7-bit NOTENUM field codes the note number for the log. A note number MUST NOT be represented by multiple note logs in the note list.
7位NOTENUM字段对日志的注释编号进行编码。注释编号不能由注释列表中的多个注释日志表示。
The 7-bit VELOCITY field codes the velocity value for the most recent N-active NoteOn command for the note number in the session history. Multiple overlapping NoteOns for a given note number may be coded using Chapter E, as discussed in Appendix A.7.
7位速度字段编码会话历史记录中注释编号的最新N-active NoteOn命令的速度值。如附录a.7所述，可使用第E章对给定注释编号的多个重叠注释进行编码。
VELOCITY is never zero; NoteOn commands with zero velocity are coded as NoteOff commands in the NoteOff bitfield structure.
速度永远不为零；速度为零的NoteOn命令在NoteOff位字段结构中编码为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日志不会对NoteOn命令的执行时间进行编码。但是，Y位编码来自发送方的关于NoteOn执行时间的提示。Y位编码建议播放（Y=1）或跳过（Y=0）从注释日志恢复的NoteOn命令。参见[RFC4696]第4.2节，了解Y钻头使用的非规范性指南。
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显示了注释位字段结构，如本章末尾的注释位八位字节列表。NoteOff OFFBITS八位组编码八个连续MIDI音符编号的NoteOff信息，最高有效位表示最低音符编号。第一个OFFBITS八位字节的最高有效位对音符编号8*低进行编码；最后一个OFFBITS八位字节的最高有效位编码为音符编号8*高。
A set bit codes a NoteOff command for the note number. In the most efficient coding for the NoteOff bitfield structure, the first and last octets of the structure contain at least one set bit. Note that Chapter N does not code NoteOff velocity data.
设置位对注释编号的NoteOff命令进行编码。在NoteOff位字段结构的最有效编码中，该结构的第一个和最后一个八位字节包含至少一个集合位。注意，第N章未对注释速度数据进行编码。
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
请注意，在一般情况下，恢复日志不会对控制器64（减振器踏板（保持））的NoteOff命令和Change Control命令的相对位置进行编码。在许多情况下，处理丢失事件的接收器可以推断出这种相对位置
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.
从流的历史记录中，从而确定踏板是否持续发出音符。如果不可能进行这样的确定，则接收器应在静音踏板持续的一侧出错，因为错误持续的音符可能会产生令人不快的（尽管是暂时的）假象。
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.
在阅读本附录之前，读者可能希望阅读附录A.1“N-激活命令”的定义。在本附录中，速度为0的NoteOn命令被视为释放速度值为64的NoteOff命令。
Chapter E encodes recovery information about MIDI NoteOn (0x9) and NoteOff (0x8) command features that rarely appear in MIDI streams. Receivers use Chapter E to reduce transient artifacts for streams where several NoteOn commands appear for a note number without an intervening NoteOff. Receivers also use Chapter E to reduce transient artifacts for streams that use NoteOff release velocity. Chapter E supplements the note information coded in Chapter N (Appendix A.6).
第E章对MIDI流中很少出现的MIDI NoteOn（0x9）和NoteOff（0x8）命令功能的恢复信息进行编码。接收器使用第E章来减少流的瞬态伪影，其中针对一个音符编号出现多个NoteOn命令，而没有中间的NoteOff。接收器还使用第E章来减少使用NoteOff释放速度的流的瞬态伪影。第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 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
日志列表必须至少包含一个注释日志。7位LEN header字段编码列表中注释日志的数量，减去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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |V| COUNT/VEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.7.2 -- Chapter E Note Log
图A.7.2——第E章注释日志
A note log codes information about the MIDI note number coded by the 7-bit NOTENUM field. The nature of the information depends on the value of the V flag bit.
音符日志对有关由7位NOTENUM字段编码的MIDI音符编号的信息进行编码。信息的性质取决于V标志位的值。
If the V bit is set to 1, the COUNT/VEL field codes the release velocity value for the most recent N-active NoteOff command for the note number that appears in the session history.
如果V位设置为1，则COUNT/VEL字段为会话历史记录中出现的注释编号的最新N-active NoteOff命令的释放速度值进行编码。
If the V bit is set to 0, the COUNT/VEL field codes a reference count of the number of NoteOn and NoteOff commands for the note number that appears in the session history.
如果V位设置为0，则COUNT/VEL字段为会话历史记录中出现的注释编号的NoteOn和NoteOff命令编号的参考计数进行编码。
The reference count is set to 0 at the start of the session. NoteOn commands increment the count by 1. NoteOff commands decrement the count by 1. However, a decrement that generates a negative count value is not performed.
会话开始时，引用计数设置为0。NoteOn命令将计数增加1。NoteOff命令将计数减少1。但是，不执行生成负计数值的递减。
If the reference count is in the range 0-126, the 7-bit COUNT/VEL field codes an unsigned integer representation of the count. If the count is greater than or equal to 127, COUNT/VEL is set to 127.
如果引用计数在0-126范围内，则7位count/VEL字段对计数的无符号整数表示进行编码。如果计数大于或等于127，则计数/电平设置为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）时，以及每当会话历史记录中出现控制器编号123-127（带所有注释语义的编号）或120（所有声音关闭）的MIDI控制更改命令时，计数都重置为0。
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-active NoteOn或NoteOff命令是释放速度值不是64的NoteOff命令，则注释编号的E章中必须出现V位设置为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-active NoteOn或NoteOff命令是NoteOff命令，并且注释编号的引用计数大于0，则注释编号的E章中必须出现V位设置为0的注释日志。
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-active NoteOn或NoteOff命令是NoteOn命令，并且注释编号的引用计数大于1，则注释编号的E章中必须出现V位设置为0的注释日志。
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.
对于注释编号，E章中最多可能出现两个注释日志：一个日志的V位设置为0，另一个日志的V位设置为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位设置为1的日志必须从章节E中删除，以达到128个日志限制。注意：不得删除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.
Chu 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-active和C-active MIDI通道后触摸（0xD）命令，则通道日志必须包含章节T。图A.8.1显示了第T章的格式。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| PRESSURE |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| PRESSURE |
+-+-+-+-+-+-+-+-+
Figure A.8.1 -- Chapter T Format
图A.8.1——第T章格式
The chapter has a fixed size of 8 bits. The 7-bit PRESSURE field holds the pressure value of the most recent N-active and C-active Channel Aftertouch command in the session history.
章节的固定大小为8位。7位压力字段保存会话历史中最近的N-active和C-active通道后触摸命令的压力值。
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-active和N-active命令进行编码。我们定义C-主动限制是因为[RP015]声明控制器121（重置所有控制器）的控制更改命令用于将通道压力重置为0（有关更完整的原理，请参阅附录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-active限制，假设后触摸命令链接到note活动，因此非N-active的通道后触摸命令是过时的，不应用于修复流。
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-active Poly PostTouch（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 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-active Poly PostTouch命令，则必须显示注释编号的注释日志。注释编号不能由注释列表中的多个注释日志表示。注释日志列表必须遵守最早的首次订购规则（定义见附录A.1）。
The 7-bit LEN field codes the number of note logs in the list, minus one. Figure A.9.2 reproduces the note log structure of Chapter A.
7位LEN字段编码列表中注释日志的数量，减去1。图A.9.2再现了A章的注释日志结构。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |X| PRESSURE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位压力字段为会话历史中最新的C-active Poly PostTouch命令的压力值编码，该命令用于7位NOTENUM字段中编码的MIDI音符编号。
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。但是，如果由日志编码的命令出现在会话历史记录中以下命令之一之前，则必须将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).
我们在A章中定义了C-active限制，因为[RP015]声明控制器121（重置所有控制器）的控制更改命令用于将复调压力重置为0（有关更完整的原理，请参阅附录A.5末尾的讨论）。
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歌曲选择（0xF3）、未定义的MIDI系统公用（0xF4和0xF5）或未定义的MIDI系统实时（0xF9和0xFD）命令，则系统日志必须包含第D章。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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头和一个或多个命令日志组成。标头标志位表示存在重置（B=1）、调谐请求（G=1）、歌曲选择（H=1）、未定义系统公用0xF4（J=1）、未定义系统公用0xF5（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 |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+
Figure B.1.2 -- Command Log for Reset and Tune Request
图B.1.2——重置和调整请求的命令日志
Chapter D MUST contain the Reset command log if an active Reset command appears in the checkpoint history. The 7-bit COUNT field codes the total number of Reset commands (modulo 128) present in the session history.
如果检查点历史记录中出现激活的重置命令，则第D章必须包含重置命令日志。7位计数字段编码会话历史记录中存在的重置命令总数（模数128）。
Chapter D MUST contain the Tune Request command log if an active Tune Request command appears in the checkpoint history. The 7-bit COUNT field codes the total number of Tune Request commands (modulo 128) present in the session history.
如果检查点历史记录中出现活动的调整请求命令，则第D章必须包含调整请求命令日志。7位计数字段编码会话历史记录中存在的调谐请求命令总数（模数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显示了歌曲选择命令的1-octet命令日志格式。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| VALUE |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| VALUE |
+-+-+-+-+-+-+-+-+
Figure B.1.3 -- Song Select Command Log Format
图B.1.3——歌曲选择命令日志格式
Chapter D MUST contain the Song Select command log if an active Song Select command appears in the checkpoint history. The 7-bit VALUE field codes the song number of the most recent active Song Select command in the session history.
如果检查点历史记录中出现活动的歌曲选择命令，则章节D必须包含歌曲选择命令日志。7位值字段编码会话历史中最近激活的歌曲选择命令的歌曲编号。
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
在本节中，我们将为未定义的系统命令定义第D章命令日志。[MIDI]保留未定义的系统命令0xF4、0xF5、0xF9和0xFD供将来使用。在撰写本文时，使用这些命令的任何MIDI命令流都是
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.
不符合[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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|V|L|DSZ| LENGTH | COUNT | VALUE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEGAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.4 -- Undefined System Common Command Log Format
图B.1.4——未定义的系统通用命令日志格式
The command log codes a single command type (0xF4 or 0xF5, not both). Chapter D MUST contain a command log if an active 0xF4 command appears in the checkpoint history and MUST contain an independent command log if an active 0xF5 command appears in the checkpoint history.
命令日志对单个命令类型（0xF4或0xF5，而不是两者）进行编码。如果检查点历史记录中出现活动0xF4命令，则D章必须包含命令日志；如果检查点历史记录中出现活动0xF5命令，则D章必须包含独立的命令日志。
A Chapter D Undefined System Common command log consists of a two-octet header followed by a variable number of data fields. Header flag bits indicate the presence of the COUNT field (C = 1), the VALUE field (V = 1), and the LEGAL field (L = 1). The 10-bit LENGTH field codes the size of the command log and conforms to semantics described in Appendix A.1.
第D章未定义的系统通用命令日志由两个八位字节头和可变数量的数据字段组成。标头标志位表示存在计数字段（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.
现在，我们为COUNT、VALUE和LEGAL字段的使用定义默认规则。附录C.2.3中定义的会话配置工具可用于覆盖此行为。
By default, if the DSZ field is set to 0, the command log MUST include the COUNT field. The 8-bit COUNT field codes the total number of commands of the type coded by the log (0xF4 or 0xF5) present in the session history, modulo 256.
默认情况下，如果DSZ字段设置为0，则命令日志必须包含COUNT字段。8位计数字段编码会话历史记录中存在的日志（0xF4或0xF5）编码类型的命令总数，模256。
By default, if the DSZ field is set to 1-3, the command log MUST include the VALUE field. The variable-length VALUE field codes a verbatim copy the data octets for the most recent use of the command
默认情况下，如果DSZ字段设置为1-3，则命令日志必须包含值字段。可变长度值字段对最近使用该命令的数据八位字节进行逐字复制编码
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.
键入由会话历史记录中的日志（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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|L| LENGTH | COUNT | LEGAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.5 -- Undefined System Real-Time Command Log Format
图B.1.5——未定义的系统实时命令日志格式
The command log codes a single command type (0xF9 or 0xFD, not both). Chapter D MUST contain a command log if an active 0xF9 command appears in the checkpoint history and MUST contain an independent command log if an active 0xFD command appears in the checkpoint history.
命令日志对单个命令类型（0xF9或0xFD，而不是两者）进行编码。如果检查点历史记录中出现活动0xF9命令，则D章必须包含命令日志；如果检查点历史记录中出现活动0xFD命令，则D章必须包含独立的命令日志。
A Chapter D Undefined System Real-Time command log consists of a one-octet header followed by a variable number of data fields. Header flag bits indicate the presence of the COUNT field (C = 1) and the LEGAL field (L = 1). The 5-bit LENGTH field codes the size of the command log and conforms to semantics described in Appendix A.1.
第D章未定义的系统实时命令日志由一个八位字节头和可变数量的数据字段组成。报头标志位表示存在计数字段（C=1）和合法字段（L=1）。5位长度字段编码命令日志的大小，并符合附录A.1中描述的语义。
We now define the default rules for the use of the COUNT and LEGAL fields. The session configuration tools defined in Appendix C.2.3 may be used to override this behavior.
现在，我们为COUNT和LEGAL字段的使用定义默认规则。附录C.2.3中定义的会话配置工具可用于覆盖此行为。
The 8-bit COUNT field codes the total number of commands of the type coded by the log present in the session history, modulo 256. By default, the COUNT field MUST be present in the command log.
8位计数字段编码会话历史记录中日志编码类型的命令总数，模256。默认情况下，COUNT字段必须出现在命令日志中。
The LEGAL field is reserved for future use. If an update to [MIDI] defines the 0xF9 or 0xFD command, an IETF Standards-Track document may define the LEGAL field to protect the command. Until such a document appears, senders MUST NOT use the LEGAL field, and receivers
法律字段保留供将来使用。如果[MIDI]的更新定义了0xF9或0xFD命令，IETF标准跟踪文档可能会定义法律字段以保护该命令。在此类文档出现之前，发件人不得使用法律字段，收件人不得使用法律字段
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.
必须使用长度字段跳过法律字段。如果新0xF9或0xFD命令的语义无法通过使用COUNT字段防止数据包丢失，则IETF将定义LEGAL字段。
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 sequencer系统的非兼容变体。在附录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活动检测（0xFE）命令，则系统日志必须包含第五章。图B.2.1显示了第五章的格式。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+
Figure B.2.1 -- System Chapter V Format
图B.2.1——系统第五章格式
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位计数字段编码会话历史记录中存在的活动检测命令总数（模数128）。“计数”字段用作引用计数。有关更多信息，请参见附录A.1中“会话历史参考计数”的定义。
This appendix describes Chapter Q, the system chapter for the MIDI sequencer commands.
本附录描述了第Q章，MIDI音序器命令的系统章节。
The system journal MUST contain Chapter Q if an active MIDI Song Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI Continue (0xFB), or MIDI Stop (0xFC) command appears in the checkpoint history and if the rules defined in this appendix require a change in the Chapter Q bitfield contents because of the command appearance.
如果检查点历史记录中出现活动的MIDI乐曲位置指针（0xF2）、MIDI时钟（0xF8）、MIDI开始（0xFA）、MIDI继续（0xFB）或MIDI停止（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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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章由一个1-octet头和几个可选字段组成，顺序如图B.3.1所示。
Header flag bits signal the presence of the 16-bit CLOCK field (C = 1) and the 24-bit TIMETOOLS field (T = 1). The 3-bit TOP header field is interpreted as an unsigned integer, as are CLOCK and TIMETOOLS. We describe the TIMETOOLS field in Appendix B.3.1.
报头标志位表示存在16位时钟字段（C=1）和24位TIMETOOLS字段（T=1）。与CLOCK和TIMETOOLS一样，3位TOP header字段被解释为无符号整数。我们在附录B.3.1中描述了TIMETOOLS字段。
Chapter Q encodes the most recent state of the sequencer system. Receivers use the chapter to resynchronize the sequencer after a packet loss episode. Chapter fields encode the on/off state of the sequencer, the current position in the song, and the downbeat.
第Q章对定序器系统的最新状态进行编码。接收器在丢包事件发生后使用本章重新同步定序器。章节字段编码音序器的开/关状态、歌曲中的当前位置和下拍。
The N header bit encodes the relative occurrence of the Start, Stop, and Continue commands in the session history. If an active Start or Continue command appears most recently, the N bit MUST be set to 1. If an active Stop appears most recently, or if no active Start, Stop, or Continue commands appear in the session history, the N bit MUST be set to 0.
N报头位编码会话历史中开始、停止和继续命令的相对出现次数。如果最近出现激活的Start或Continue命令，则N位必须设置为1。如果最近出现活动停止，或者会话历史记录中未出现活动启动、停止或继续命令，则N位必须设置为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个时钟）为单位对歌曲位置进行编码，模数为524288。请注意，可由song position Pointer命令编码的最大song position值为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，则乐曲位置是乐曲的开始。对于歌曲位置小于524288 MIDI时钟的情况，C=0位置与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、TOP和时钟字段编码的歌曲位置。
If the D bit is set to 1, the song position represents the most recent position in the sequence that has played. If D = 1, the next Clock command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to increment the song position by one clock and to play the updated position.
如果D位设置为1，则乐曲位置表示播放序列中最近的位置。如果D=1，则下一个时钟命令（如果N=1）或下一个（继续，时钟）对（如果N=0）将使乐曲位置增加一个时钟，并播放更新后的位置。
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）或下一个（继续，时钟）对（如果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的示例。在第Q章中，通过设置C=0、D=0、N=0、TOP=0，对紧接着停止命令的启动命令进行编码。
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=1，TOP=0，如果会话历史记录中的Continue命令比Start命令发生得更晚，则必须使用CLOCK=0乐曲位置编码。
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位TIMETOOLS字段的格式。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.3.2 -- TIMETOOLS Format
图B.3.2——TIMETOOLS格式
The TIME field is a 24-bit unsigned integer quantity, with units of milliseconds. TIME codes an additive correction term for the song position coded by the TOP, CLOCK, and C fields. TIME is coded in network byte order (big-endian).
时间字段是以毫秒为单位的24位无符号整数。时间编码由TOP、CLOCK和C字段编码的乐曲位置的加性校正项。时间以网络字节顺序（大端）编码。
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*TOP+时钟（假设C=1）来计算正确的歌曲位置。或者，接收器可以将65536*TOP+时钟转换为毫秒（假设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.
本附录描述了第F章，MIDI时间码（MTC）命令的系统章节。在阅读本附录之前，读者可能希望查看附录A.1“完成/未完成命令”的定义。
The system journal MUST contain Chapter F if an active System Common Quarter Frame command (0xF1) or an active finished System Exclusive (Universal Real Time) MTC Full Frame command (F0 7F cc 01 01 hr mn sc fr F7) appears in the checkpoint history. Otherwise, the system journal MUST NOT contain Chapter F.
如果检查点历史记录中出现活动系统公用四分之一帧命令（0xF1）或活动完成系统专用（通用实时）MTC全帧命令（F0 7F cc 01 hr mn sc fr F7），则系统日志必须包含第F章。否则，系统日志不得包含第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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|P|Q|D|POINT| COMPLETE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PARTIAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+
Figure B.4.1 -- System Chapter F Format
图B.4.1——系统章节F格式
Chapter F holds information about recent MTC tape positions coded in the session history. Receivers use Chapter F to resynchronize the MTC system after a packet loss episode.
第F章包含会话历史记录中编码的最近MTC磁带位置的信息。在丢包事件发生后，接收机使用第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).
第F章由一个1-octet头和几个可选字段组成，顺序如图B.4.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报头位编码有关完整字段格式的信息。如果章节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。在大多数情况下，会话历史记录中命令的顺序清楚地定义了磁带的方向。但是，一些命令序列具有不确定的方向（例如由一个完整帧命令组成的会话历史记录）。
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.
如果检查点历史记录中出现活动完成的完整帧命令，或者如果检查点历史记录中出现完成帧值编码的活动四分之一帧命令，则第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
COMPLETE（完成）字段对会话历史记录中显示的最新活动完整MTC帧值进行编码。此帧值可以采用一系列8个活动四分之一帧命令（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.
通过0xF1 0x7n进行磁带正向移动，0xF1 0x7n通过0xF1 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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帧（相对于在四分之一帧命令中编码的帧值）。该偏移量补偿了四分之一帧编码的两帧延迟，用于向前移动磁带。如果帧值对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 the format shown in Figure B.4.3. The HR, MN, SC, and FR fields correspond to the hr, mn, sc, and fr data octets of the Full Frame command.
最近激活的完整MTC帧值也可以由激活的完成完整帧命令进行编码。在这种情况下，Q报头位必须设置为0，完整字段的格式必须如图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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
如果检查点历史记录中编码MTC帧值数据的最新激活命令是与部分帧值关联的四分之一帧命令，则第F章必须包含部分字段。否则，第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 identifies the Message Type fields in the PARTIAL field that code valid data. If P = 1, the POINT field MUST encode the unsigned integer value formed by the lower 3 bits of the upper nibble of the data value of the most recent active Quarter Frame command in the session history. If D = 0 and P = 1, POINT MUST take on a value in the range 0-6. If D = 1 and P = 1, POINT MUST take on a value in the range 1-7.
POINT header字段标识对有效数据进行编码的部分字段中的消息类型字段。如果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，则0到并包括点值范围内的MT字段（图B.4.2）对部分帧值进行编码。如果D=1，则从7到包括点值的包含范围内的MT字段对部分帧值进行编码。请注意，与完整字段编码不同，发送方不得将2帧偏移量添加到部分编码的部分帧值。
For the default semantics, if a recovery journal contains Chapter F and if the session history codes a legal [MIDI] series of Quarter Frame and Full Frame commands, the chapter always contains a COMPLETE or a PARTIAL field (and may contain both fields). Thus, a one-octet Chapter F (C = P = 0) always codes the presence of an illegal command sequence in the session history (under some conditions, the C = 1, P
对于默认语义，如果恢复日志包含第F章，并且会话历史记录对合法的[MIDI]系列四分之一帧和全帧命令进行编码，则该章始终包含完整或部分字段（可能同时包含这两个字段）。因此，一个八位组的章节F（C=P=0）总是对会话历史中存在的非法命令序列进行编码（在某些情况下，C=1，P
= 0 condition may also code the presence of an illegal command sequence). The illegal command sequence conditions are transient in nature and usually indicate that a Quarter Frame command sequence began with an intermediate Message Type.
=0条件也可能对非法命令序列的存在进行编码）。非法命令序列条件本质上是暂时的，通常表示四分之一帧命令序列以中间消息类型开始。
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系统专用（SysEx）命令（0xF0）的系统章节。在阅读本附录之前，读者可能希望查看附录A.1“完成/未完成命令”的定义。
Chapter X consists of a list of one or more command logs. Each log in the list codes information about a specific finished or unfinished SysEx command that appears in the session history. The system journal MUST contain Chapter X if the rules defined in Appendix B.5.2 require that one or more logs appear in the list.
第十章包括一个或多个命令日志的列表。列表中的每个日志对会话历史记录中显示的特定已完成或未完成SysEx命令的信息进行编码。如果附录B.5.2中定义的规则要求列表中出现一个或多个日志，则系统日志必须包含第X章。
The log list is not preceded by a header. Instead, each log implicitly encodes its own length. Given the length of the N'th list log, the presence of the (N+1)'th list log may be inferred from the LENGTH field of the system journal header (Figure 10 in Section 5 of the main text). The log list MUST obey the oldest-first ordering rule (defined in Appendix A.1).
日志列表前面没有标题。相反，每个日志隐式地编码自己的长度。给定第N个列表日志的长度，可以从系统日志标题的长度字段推断（N+1）个列表日志的存在（正文第5节中的图10）。日志列表必须遵守最早的首次排序规则（定义见附录A.1）。
Figure B.5.1 shows the bitfield format for the Chapter X command logs.
图B.5.1显示了第X章命令日志的位字段格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|T|C|F|D|L|STA| TCOUNT | COUNT | FIRST ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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——第十章命令日志格式
A Chapter X command log consists of a 1-octet header followed by the optional TCOUNT, COUNT, FIRST, and DATA fields.
第十章命令日志由一个1-octet头组成，后跟可选的TCOUNT、COUNT、FIRST和DATA字段。
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 T T计数字段。如果C设置为1，则日志中会显示1个八位字节的计数字段。如果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 0xF7" construction, and an STA value of 3 codes all other finished commands. Section 3.2 in the main text describes cancelled and "dropped 0xF7" commands.
STA字段对日志编码的命令的状态进行编码。2位STA值被解释为无符号整数。如果STA为0，则日志对未完成的命令进行编码。非零STA值对不同类别的已完成命令进行编码。STA值为1表示已取消的命令，STA值为2表示使用“删除的0xF7”结构的命令，STA值为3表示所有其他已完成的命令。正文中的第3.2节描述了已取消和“已删除的0xF7”命令。
The S bit (Appendix A.1) of the first log in the list acts as the S bit for Chapter X. For the other logs in the list, the S bit refers to the log itself. The value of the "phantom" S bit associated with the first log is defined by the following rules:
列表中第一个日志的S位（附录A.1）用作第十章的S位。对于列表中的其他日志，S位指日志本身。与第一个日志关联的“幻象”位的值由以下规则定义：
o If the list codes one log, the phantom S-bit value is the same as the Chapter X S-bit value.
o 如果列表编码一个日志，则幻象S位值与第X章S位值相同。
o If the list codes multiple logs, the phantom S-bit value is the logical OR of the S-bit value of the first and second command logs in the list.
o 如果列表对多个日志进行编码，则幻象S位值是列表中第一个和第二个命令日志的S位值的逻辑OR。
In all other respects, the S bit follows the semantics defined in Appendix A.1.
在所有其他方面，S位遵循附录A.1中定义的语义。
The FIRST field (present if F = 1) encodes a variable-length unsigned integer value that sets the coverage of the DATA field.
第一个字段（如果F=1，则显示）编码设置数据字段覆盖率的可变长度无符号整数值。
The FIRST field (present if F = 1) encodes a variable-length unsigned integer value that specifies which SysEx data bytes are encoded in the DATA field of the log. The FIRST field consists of an octet whose most significant bit is set to 0, optionally preceded by one or more octets whose most significant bit is set to 1. The algorithm shown in Figure B.5.2 decodes this format into an unsigned integer to yield the value dec(FIRST). FIRST uses a variable-length encoding because dec(FIRST) references a data octet in a SysEx command, and a SysEx command may contain an arbitrary number of data octets.
第一个字段（如果F=1，则显示）编码可变长度无符号整数值，该值指定在日志的数据字段中编码哪些SysEx数据字节。第一个字段由一个最高有效位设置为0的八位字节组成，可选地前面有一个或多个最高有效位设置为1的八位字节。图B.5.2所示的算法将此格式解码为无符号整数，以产生值dec（FIRST）。FIRST使用可变长度编码，因为dec（FIRST）引用SysEx命令中的数据八位字节，并且SysEx命令可能包含任意数量的数据八位字节。
One-Octet FIRST value:
一个八位组第一值：
Encoded form: 0ddddddd Decoded form: 00000000 00000000 00000000 0ddddddd
编码形式：0DDDDD解码形式：00000000 00000000 00000000 0DDDDD
Two-Octet FIRST value:
两个八位组的第一个值：
Encoded form: 1ccccccc 0ddddddd Decoded form: 00000000 00000000 00cccccc cddddddd
编码形式：1CCCCC 0DDDDD解码形式：00000000 00000000 CCCCCC CDDDDD
Three-Octet FIRST value:
三个八位组的第一个值：
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 00000000 000bbbbb bbcccccc cddddddd
编码形式：1BBBBBB 1CCCCCC 0DDDDD解码形式：000000000BBBBB BBCCCCC CDDDDD
Four-Octet FIRST value:
四个八位组的第一个值：
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
编码形式：1AAAAA 1BBBBBB 1CCCCCC 0DDDDD解码形式：0000aaaa AAABBB BBCCCCC CDDDDD
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，则数据字段以SysEx命令的（dec（FIRST）+1）第个数据八位字节开始，并包括会话历史记录中出现的该命令的所有后续数据八位字节。请注意，上面描述中的“command”一词指的是源MIDI数据流中出现的原始SysEx命令，而不是特定的MIDI列表SysEx命令段。
The length of the DATA field is coded implicitly, using the most significant bit of each octet. The most significant bit of the final octet of the DATA field MUST be set to 1. The most significant bit of all other DATA octets MUST be set to 0. This coding method relies on the fact that the most significant bit of a MIDI data octet is 0 by definition. Apart from this length-coding modification, the DATA field encodes a verbatim copy of all data octets it encodes.
数据字段的长度使用每个八位字节的最高有效位进行隐式编码。数据字段最后八位字节的最高有效位必须设置为1。所有其他数据八位字节的最高有效位必须设置为0。这种编码方法依赖于这样一个事实：MIDI数据八位字节的最高有效位定义为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.
第十章提供了两种保护SysEx命令的工具：“recenty”工具和“list”工具。工具定义使用命令的“SysEx类型”概念，我们现在定义它。
Each SysEx command instance in a session, excepting MTC Full Frame commands, is said to have a "SysEx type". Types are used in equality
会话中的每个SysEx命令实例（MTC全帧命令除外）都有一个“SysEx类型”。类型在等式中使用
comparisons: two SysEx commands in a session are said to have "the same SysEx type" or "different SysEx types".
比较：一个会话中的两个SysEx命令被称为“相同的SysEx类型”或“不同的SysEx类型”。
If efficiency is not a concern, a sender may follow a simple typing rule: every SysEx command in the session history has a different SysEx type, and thus no two commands in the session have the same type.
如果不考虑效率，发送方可以遵循一个简单的类型规则：会话历史记录中的每个SysEx命令都有不同的SysEx类型，因此会话中没有两个命令具有相同的类型。
To improve efficiency, senders MAY implement exceptions to this rule. These exceptions declare that certain sets of SysEx command instances have the same SysEx type. Any command not covered by an exception follows the simple rule. We list exceptions below:
为了提高效率，发件人可以实施此规则的例外情况。这些异常声明某些SysEx命令实例集具有相同的SysEx类型。任何未包含在异常中的命令都遵循简单规则。我们列出以下例外情况：
o All commands with identical data octet fields (same number of data octets, same value for each data octet) have the same type. This rule MUST be applied to all SysEx commands in the session or not at all. Note that the implementation of this exception requires no sender knowledge of the format and semantics of the SysEx commands in the stream, merely the ability to count and compare octets.
o 具有相同数据八位字节字段（相同数量的数据八位字节，每个数据八位字节的值相同）的所有命令都具有相同的类型。此规则必须应用于会话中的所有SysEx命令，或者根本不应用。请注意，此异常的实现不需要发送方了解流中SysEx命令的格式和语义，只需要能够计算和比较八位字节。
o Two instances of the same command whose semantics set or report the value of the same "parameter" have the same type. The implementation of this exception requires specific knowledge of the format and semantics of SysEx commands. In practice, a sender implementation chooses to support this exception for certain classes of commands (such as the Universal System Exclusive commands defined in [MIDI]). If a sender supports this exception for a particular command in a class (for example, the Universal Real Time System Exclusive message for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [MIDI]), it MUST support the exception to all instances of this particular command in the session.
o 语义设置或报告相同“参数”值的同一命令的两个实例具有相同的类型。此异常的实现需要具体了解SysEx命令的格式和语义。实际上，发送方实现选择对某些命令类（如[MIDI]中定义的通用系统专用命令）支持此异常。如果发送方支持类中特定命令的此异常（例如，[MIDI]中定义的主卷通用实时系统独占消息F0 F7 cc 04 01 vv vv F7），则它必须支持会话中此特定命令的所有实例的异常。
We now use this definition of "SysEx type" to define the "recency" tool and the "list" tool for Chapter X.
我们现在使用“SysEx类型”的这个定义来定义第十章的“最近性”工具和“列表”工具。
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性能不受检查点历史记录中出现的所有已完成或未完成的活动SysEx命令（不包括第F章（附录B.4）中编码的已完成MTC全帧命令）丢失所导致的不确定伪影的影响。
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
要使用Recenty工具保护特定SysEx类型的命令，发送者必须在日志列表中为检查点历史记录中显示的SysEx类型的最近完成的活动实例编写日志。此外，如果检查点历史记录中出现SysEx类型的未完成活动实例，则发送者必须编写登录代码
the log list for the unfinished command instance. The L header bit of both command logs MUST be set to 0.
未完成的命令实例的日志列表。两个命令日志的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类型的命令，发送者必须在第X章日志列表中为检查点历史记录中显示的SysEx类型的每个已完成或未完成活动实例编写日志。列表工具命令日志的L头位必须设置为1。
As a rule, a log REQUIRED by the list or recency tool MUST include a DATA field that codes all data octets that appear in the checkpoint history for the SysEx command instance associated with the log. The FIRST field MAY be used to configure a DATA field that minimally meets this requirement.
通常，“列表”或“最近性”工具所需的日志必须包含一个数据字段，该字段对与日志关联的SysEx命令实例的检查点历史记录中出现的所有数据八位字节进行编码。第一个字段可用于配置至少满足此要求的数据字段。
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完整帧命令）必须由列表工具或最近性工具保护。
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章。例如，假设发送方开始“动态”将包含10000个数据八位字节的SysEx命令转换为UDP RTP流，只要MIDI源提供数据八位字节，就发送SysEx命令段。在发送了1000个八位字节之后，第X章的扩展产生了一个RTP数据包，该数据包太大，无法容纳流的最大传输单元（MTU）。
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数据包大小始终可能会因暂停流而受到限制。在流暂停中，一旦数据包达到最大大小，发送方将禁止发送带有非空MIDI命令部分的新数据包，直到接收方反馈允许修剪第X章。如果数据流允许任意命令出现在SysEx段之间（可在配置期间使用附录C.1中定义的工具进行选择），发送方可能会暂停SysEx段流，但会继续对MIDI列表中的其他命令进行编码。
Stalls are a workable but suboptimal solution to Chapter X size issues. As an alternative to stalls, senders SHOULD take preemptive
对于第十章的规模问题，摊位是一个可行但次优的解决方案。作为摊位的替代方案，发件人应采取先发制人的措施
action during session configuration to reduce the anticipated size of Chapter X, using the methods described below:
在会话配置期间采取措施，使用下述方法减少第十章的预期规模：
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流（用于批量数据SysEx命令）。cm_unused和cm_used参数（附录C.1）可用于传达SysEx命令分区的性质。由于TCP是可靠的，RTP MIDI TCP流不会使用恢复日志。为了最小化短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命令可能都不需要日志保护。Chu never参数（附录C.2）可用于传达第X章中排除的SysEx命令。
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位的T计数器字段。如果C标头位设置为1，则8位计数字段将显示在命令日志中。t计数和计数被解释为无符号整数。
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类型的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.
计数字段编码会话历史记录中出现的SysEx命令总数，不包括在日志编码的（完成或未完成的）命令进入会话历史记录后，通过Chu never参数（附录C.2）从第十章中排除的命令。
Command counting for TCOUNT and COUNT uses modulo-256 arithmetic. MTC Full Frame command instances (Appendix B.4) are included in command counting if the TCOUNT and COUNT definitions warrant their inclusion, as are cancelled commands (Section 3.2).
TCOUNT和COUNT的命令计数使用模256算法。MTC全帧命令实例（附录B.4）包括在命令计数中，前提是t计数和计数定义保证将其包括在内，取消的命令也包括在内（第3.2节）。
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
发件人使用TCOUNT和COUNT字段跟踪命令实例的标识和（对于TCOUNT）序列位置。如果是标识或序列，则发件人必须使用TCOUNT或COUNT字段
information is necessary to protect the command type coded by the log.
需要信息来保护日志编码的命令类型。
If a sender uses the COUNT field in a session, the final command log in every Chapter X in the stream MUST code the COUNT field. This rule lets receivers resynchronize the COUNT value after a packet loss.
如果发送方在会话中使用COUNT字段，则流中每个第X章中的最终命令日志必须对COUNT字段进行编码。此规则允许接收方在数据包丢失后重新同步计数值。
In Sections 6.1 and 6.2 of the main text, we show session descriptions for minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack the flexibility to support some applications. In this appendix, we describe how to customize stream behavior through the use of the payload format parameters.
在正文的第6.1节和第6.2节中，我们展示了最小本机和mpeg4通用RTP MIDI流的会话描述。最小流缺乏支持某些应用程序的灵活性。在本附录中，我们描述了如何通过使用有效负载格式参数来定制流行为。
The appendix begins with 6 sections, each devoted to parameters that affect a particular aspect of stream behavior:
本附录从6个章节开始，每个章节专门讨论影响流行为特定方面的参数：
o Appendix C.1 describes the stream subsetting system (cm_unused and cm_used).
o 附录C.1描述了河流分段系统（未使用cm_和使用cm_）。
o Appendix C.2 describes the journalling system (ch_anchor, ch_default, ch_never, j_sec, j_update).
o 附录C.2描述了日志系统（Chu锚定、Chu默认、Chu从不、j_秒、j_更新）。
o Appendix C.3 describes MIDI command timestamp semantics (linerate, mperiod, octpos, tsmode).
o 附录C.3描述了MIDI命令时间戳语义（linerate、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涉及流描述（音乐端口）。
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渲染（通道掩码、cid、内联、多模式、渲染、rinit、子渲染、smf_cid、smf_信息、smf_内联、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
上面列出的参数为最小的RTP MIDI流添加了额外的功能（“特性”）。在附录C.7中，我们展示了如何使用这些功能来支持两类应用程序：内容流
using RTSP (Appendix C.7.1) and network musical performance using SIP (Appendix C.7.2).
使用RTSP（附录C.7.1）和使用SIP的网络音乐表演（附录C.7.2）。
The participants in a multimedia session MUST share a common view of all of the RTP MIDI streams that appear in an RTP session, as defined by a single media (m=) line. In some RTP MIDI applications, the "common view" restriction makes it difficult to use sendrecv streams (all parties send and receive), as each party has its own requirements. For example, a two-party network musical performance application may wish to customize the renderer on each host to match the CPU performance of the host [NMP].
多媒体会话的参与者必须共享RTP会话中出现的所有RTP MIDI流的公共视图，如单个媒体（m=）行所定义。在一些RTP MIDI应用程序中，“公共视图”限制使使用sendrecv流（所有方发送和接收）变得困难，因为各方都有自己的需求。例如，两方网络音乐表演应用程序可能希望自定义每个主机上的渲染器，以匹配主机[NMP]的CPU性能。
We solve this problem by using two RTP MIDI streams -- one sendonly, one recvonly -- in lieu of one sendrecv stream. The data flows in the two streams travel in opposite directions to control receivers configured to use different renderers. In the third example in Appendix C.5, we show how the musicport parameter may be used to define virtual sendrecv streams.
我们通过使用两个RTP MIDI流（一个sendonly，一个RecVoOnly）代替一个sendrecv流来解决这个问题。两个流中的数据流以相反方向移动，以控制配置为使用不同渲染器的接收器。在附录C.5中的第三个示例中，我们展示了如何使用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, [RFC5234]) syntax for the payload parameters. Section 11 provides information to the Internet Assigned Numbers Authority (IANA) on the media types and parameters defined in this document.
附录D定义了有效载荷参数的扩充巴科斯诺尔形式（ABNF，[RFC5234]）语法。第11节向互联网分配号码管理局（IANA）提供了有关本文件中定义的媒体类型和参数的信息。
Appendix C.6.5 defines the media type audio/asc, a stored object for initializing mpeg4-generic renderers. As described in Appendix C.6, the audio/asc media type is assigned to the rinit parameter to specify an initialization data object for the default mpeg4-generic renderer. Note that RTP stream semantics are not defined for audio/asc. Therefore, the asc subtype MUST NOT appear on the rtpmap line of a session description.
附录C.6.5定义了媒体类型audio/asc，一个用于初始化mpeg4通用渲染器的存储对象。如附录C.6所述，音频/asc媒体类型分配给rinit参数，以指定默认mpeg4通用渲染器的初始化数据对象。请注意，RTP流语义没有为音频/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.
在本附录中，我们定义了两个参数（cm_unused和cm_used），通过从流中所有数据包的MIDI列表中排除某些类型的MIDI命令来修改此默认条件。例如，如果多媒体会话将MIDI名称空间划分为两个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_，则由字符串编码的命令可能会出现在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_和未使用的cm_。指定具有累积效应，并按参数列表中的出现顺序应用。稍后将命令类型指定给同一参数会扩展先前指定的范围。稍后将命令类型指定给相反的参数将取消（部分或完全）先前指定的效果。
To initialize the stream subsetting system, "implicit" assignments to cm_unused and cm_used are processed before processing the actual assignments that appear in the parameter list. The System Common undefined commands (0xF4, 0xF5) and the System Real-Time Undefined commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All other command types are implicitly assigned to cm_used.
要初始化流子集设置系统，在处理参数列表中显示的实际分配之前，将处理对未使用的cm_和已使用的cm_的“隐式”分配。系统通用未定义命令（0xF4、0xF5）和系统实时未定义命令（0xF9、0xFD）隐式分配给cm_unused。所有其他命令类型均隐式指定给所使用的cm_。
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.
请注意，隐式赋值编码RTP MIDI流的默认行为，如正文第3.2节所定义（即，合法出现在MIDI 1.0 DIN电缆上的所有命令都可能出现在流中）。另外，请注意，系统通用未定义命令（0xF4、0xF5）的分配适用于MIDI源命令流中这些命令的使用，而不是正文第3.2节中定义的SysEx段编码中0xF4和0xF5的特殊使用。
As a rule, parameter assignments obey the following syntax (see Appendix D for ABNF):
通常，参数赋值遵循以下语法（ABNF见附录D）：
<parameter> = [channel list]<command-type list>[field list]
<parameter> = [channel list]<command-type list>[field list]
The command-type list is mandatory; the channel and field lists are optional.
命令类型列表为必填项；频道和字段列表是可选的。
The command-type list specifies the MIDI command types for which the parameter applies. The command-type list is a concatenated sequence of one or more of the letters (ABCFGHJKMNPQTVWXYZ). The letters code the following command types:
命令类型列表指定参数适用的MIDI命令类型。命令类型列表是一个或多个字母的串联序列（ABCFGHJKMNPQTVWXYZ）。这些字母对以下命令类型进行编码：
o A: Poly Aftertouch (0xA) o B: System Reset (0xFF) o C: Control Change (0xB) o F: System Time Code (0xF1) o G: System Tune Request (0xF6) o H: System Song Select (0xF3) o J: System Common Undefined (0xF4) o K: System Common Undefined (0xF5) o N: NoteOff (0x8), NoteOn (0x9) o P: Program Change (0xC) o Q: System Sequencer (0xF2, 0xF8, 0xFA, 0xFB, 0xFC) o T: Channel Aftertouch (0xD) o V: System Active Sense (0xFE) o W: Pitch Wheel (0xE) o X: SysEx (0xF0, 0xF7) o Y: System Real-Time Undefined (0xF9) o Z: System Real-Time Undefined (0xFD)
o A:Poly PostTouch（0xA）o B:System Reset（0xFF）o C:Control Change（0xB）o F:System Time Code（0xF1）o G:System Tune Request（0xF6）o H:System Song Select（0xF3）o J:System Common Undefined（0xF4）o K:System Common Undefined（0xF5）o N:NoteOff（0x8）、NoteOn（0x9）o P:Program Change（0xC）o Q:System Sequencer（0xF2、0xF8、0xFA、0xFB、0xFC）输出：通道后触摸（0xD）输出电压：系统主动检测（0xFE）输出：变桨轮（0xE）输出X:SysEx（0xF0、0xF7）输出Y：系统实时未定义（0xF9）输出Z：系统实时未定义（0xFD）
In addition to the letters above, the letter M may also appear in the command-type list. The letter M refers to the MIDI parameter system (see definition in Appendix A.1 and in [MIDI]). An assignment of M to cm_unused codes that no RPN or NRPN transactions may appear in the MIDI list.
除上述字母外，字母M也可能出现在命令类型列表中。字母M表示MIDI参数系统（见附录A.1和[MIDI]中的定义）。将M分配给cm_未使用的代码，在MIDI列表中不能出现RPN或NRPN事务。
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语音频道命令”的规则也适用于字母M。
The letters in the command-type list MUST be uppercase and MUST appear in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that appear in the list MUST be ignored.
命令类型列表中的字母必须为大写，并且必须按字母顺序显示。必须忽略列表中出现的（ABCFGHJKMNPQTVWXYZ）以外的字母。
For MIDI voice channel commands, the channel list specifies the MIDI channels for which the parameter applies. If no channel list is provided, the parameter applies to all MIDI channels (0-15). The channel list takes the form of a list of channel numbers (0 through 15) and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the channel list.
对于MIDI语音通道命令，“通道列表”指定参数适用的MIDI通道。如果未提供通道列表，则该参数适用于所有MIDI通道（0-15）。信道列表采用信道编号列表（0到15）和破折号分隔的信道编号范围（即0-5、8-12等）的形式。点（即“.”字符）分隔通道列表中的元素。
Recall that system commands do not have a MIDI channel associated with them. Thus, for most command-type letters that code system commands (B, F, G, H, J, K, Q, V, Y, and Z), the channel list is ignored.
回想一下，系统命令没有与之关联的MIDI通道。因此，对于编码系统命令的大多数命令类型字母（B、F、G、H、J、K、Q、V、Y和Z），通道列表将被忽略。
For the command-type letter X, the appearance of certain numbers in the channel list codes special semantics.
对于命令类型字母X，通道列表中某些数字的出现编码特殊语义。
o The digit 0 codes that SysEx "cancel" sublists (Section 3.2 in the main text) MUST NOT appear in the MIDI list.
o SysEx“取消”子列表（正文第3.2节）中的数字0代码不得出现在MIDI列表中。
o The digit 1 codes that cancel sublists MAY appear in the MIDI list (the default condition).
o 取消子列表的数字1代码可能出现在MIDI列表中（默认条件）。
o The digit 2 codes that commands other than System Real-Time MIDI commands MUST NOT appear between SysEx command segments in the MIDI list (the default condition).
o 除系统实时MIDI命令以外的命令的数字2代码不得出现在MIDI列表中的SysEx命令段之间（默认条件）。
o The digit 3 codes that any MIDI command type may appear between SysEx command segments in the MIDI list, with the exception of the segmented encoding of a second SysEx command (verbatim SysEx commands are OK).
o 任何MIDI命令类型可能出现在MIDI列表中SysEx命令段之间的数字3代码，第二个SysEx命令的分段编码除外（逐字SysEx命令正常）。
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 RPN and NRPN controller numbers for which the parameter applies. The number range 0-16383 specifies RPN controllers, the number range 16384-32767 specifies NRPN controllers (16384 corresponds to NRPN controller number 0, 32767 corresponds to NRPN controller number 16383).
对于命令类型M（参数系统），字段列表对参数适用的RPN和NRPN控制器编号进行编码。数字范围0-16383指定RPN控制器，数字范围16384-32767指定NRPN控制器（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（系统公共未定义），字段列表由一个数字组成，该数字指定命令八位字节后的数据八位字节数。
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> ) "__"
<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.
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.
Using this syntax, each assignment specifies a single SysEx command class. Session descriptions may use several assignments to cm_used and cm_unused to specify complex behaviors.
使用此语法，每个赋值指定一个SysEx命令类。会话描述可能会使用多个cm_used和cm_unused赋值来指定复杂的行为。
The example session description below illustrates the use of the stream subsetting parameters:
下面的示例会话描述说明了流子集参数的使用：
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__
The session description configures the stream for use in clock applications. All voice channels are unused, as are all system commands except those used for MIDI Time Code (command-type F and the
会话描述配置用于时钟应用程序的流。除了用于MIDI时间码的命令（命令类型F和
Full Frame SysEx command that is matched by the string assigned to cm_used), the System Sequencer commands (command-type Q), and System Reset (command-type B).
与分配给cm_的字符串相匹配的全帧SysEx命令、系统序列器命令（命令类型Q）和系统重置（命令类型B）。
In this appendix, we define the payload format parameters that configure stream journalling and the recovery journal system.
在本附录中，我们定义了配置流日志记录和恢复日志系统的有效负载格式参数。
The j_sec parameter (Appendix C.2.1) sets the journalling method for the stream. The j_update parameter (Appendix C.2.2) sets the recovery journal sending policy for the stream. Appendix C.2.2 also defines the sending policies of the recovery journal system.
j_sec参数（附录C.2.1）设置流的日志记录方法。j_update参数（附录C.2.2）设置流的恢复日志发送策略。附录C.2.2还定义了恢复日志系统的发送策略。
Appendix C.2.3 defines several parameters that modify the recovery journal semantics. These parameters change the default recovery journal semantics as defined in Section 5 and Appendices A and B.
附录C.2.3定义了几个修改恢复日志语义的参数。这些参数更改了第5节以及附录A和B中定义的默认恢复日志语义。
The journalling method for a stream is set at the start of a session and MUST NOT be changed thereafter. This requirement forbids changes to the j_sec parameter once a session has begun.
流的日志记录方法在会话开始时设置，此后不得更改。此要求禁止在会话开始后更改j_sec参数。
A related requirement, defined in the appendices below, forbids the acceptance of parameter values that would violate the recovery journal mandate. In many cases, a change in one of the parameters defined in this appendix during an ongoing session would result in a violation of the recovery journal mandate for an implementation; in this case, the parameter change MUST NOT be accepted.
以下附录中定义的相关要求禁止接受违反恢复日志规定的参数值。在许多情况下，在正在进行的会议期间，本附录中定义的参数之一发生变化，将导致违反《恢复日志》的实施授权；在这种情况下，不得接受参数更改。
Section 2.2 defines the default journalling method for a stream. Streams that use unreliable transport (such as UDP) default to using the recovery journal. Streams that use reliable transport (such as TCP) default to not using a journal.
第2.2节定义了流的默认日志记录方法。使用不可靠传输（如UDP）的流默认使用恢复日志。使用可靠传输（如TCP）的流默认不使用日志。
The parameter j_sec may be used to override this default. This memo defines two symbolic values for j_sec: "none", to indicate that all stream payloads MUST NOT contain a journal section, and "recj", to indicate that all stream payloads MUST contain a journal section that uses the recovery journal format.
参数j_sec可用于覆盖此默认值。本备忘录为j_sec定义了两个符号值：“无”，表示所有流有效负载不得包含日记账部分，“recj”，表示所有流有效负载必须包含使用恢复日记账格式的日记账部分。
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.
例如，对于在本地网络上的两台主机之间传输的UDP流，j_sec参数可能设置为“none”，该本地网络提供可靠的数据报传递。
The session description below configures a UDP stream that does not use the 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
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.
各方不得接受违反恢复日志授权的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]）使用SDP进行“声明性使用”时，会出现特殊的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，那么选择日志记录方法的默认方法将生效（可靠传输无日志，不可靠传输恢复日志）。
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 subsections that follow, we normatively define three sending policies: anchor, closed-loop, and open-loop.
在第4节中，我们使用术语“发送策略”来描述发送方用于为流中的每个恢复日志选择检查点数据包标识的方法。在接下来的小节中，我们规范地定义了三种发送策略：锚定、闭环和开环。
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 of session descriptions that use the j_update parameter.
我们为j_update定义了三个符号值：“锚”，表示流使用锚发送策略，“开环”，表示流使用开环发送策略，“闭环”，表示流使用闭环发送策略。有关使用j_update参数的会话描述示例，请参见附录C.2.3。
Parties MUST NOT accept a j_update value that violates the recovery journal mandate (Section 4).
各方不得接受违反恢复日志授权的j_更新值（第4节）。
Other IETF Standards-Track documents may define additional sending policies for the recovery journal system. These documents MUST define new symbolic values for the j_update parameter to signal the use of the new policy. If a session description uses a j_update value unknown to the recipient, the recipient MUST NOT accept the description.
其他IETF标准跟踪文档可能会为恢复日志系统定义其他发送策略。这些文档必须为j_update参数定义新的符号值，以表示新策略的使用。如果会话描述使用收件人未知的j_更新值，则收件人不得接受该描述。
In the anchor policy, the sender uses the first packet in the stream as the checkpoint packet for all packets in the stream. The anchor policy satisfies the recovery journal mandate (Section 4), as the checkpoint history always covers the entire stream.
在锚定策略中，发送方使用流中的第一个数据包作为流中所有数据包的检查点数据包。锚定策略满足恢复日志要求（第4节），因为检查点历史记录始终覆盖整个流。
The anchor policy does not require the use of the RTP Control Protocol (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do not need to take special actions to ensure that received streams start up free of artifacts, as the recovery journal always covers the entire history of the stream. Receivers are relieved of the responsibility of tracking the changing identity of the checkpoint packet, because the checkpoint packet never changes.
锚定策略不需要使用RTP控制协议（RTCP，[RFC3550]）或从接收方到发送方的其他反馈。由于恢复日志始终覆盖流的整个历史记录，因此发送方不需要采取特殊操作来确保接收到的流启动时没有任何瑕疵。接收者不再负责跟踪检查点数据包不断变化的身份，因为检查点数据包从不变化。
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.
闭环策略是恢复日志系统的默认策略。对于流中的每个数据包，策略允许发送方选择满足恢复日志要求的最小检查点历史记录。由于较小的检查点历史记录通常会产生较小的恢复日志，因此相对于锚定策略，闭环策略会减少流的带宽。
The closed-loop policy relies on feedback from receiver to sender. The policy assumes that a receiver periodically informs the sender of the highest sequence number it has seen so far in the stream, coded in the 32-bit extension format defined in [RFC3550]. For RTCP, receivers transmit this information in the Extended Highest Sequence Number Received (EHSNR) field of Receiver Reports. RTCP Sender or Receiver Reports MUST be sent by any participant in a session with the closed-loop sending policy, unless another feedback mechanism has been agreed upon.
闭环策略依赖于从接收者到发送者的反馈。该策略假设接收方定期通知发送方其在流中看到的最高序列号，该序列号以[RFC3550]中定义的32位扩展格式编码。对于RTCP，接收器在接收器报告的扩展最高接收序列号（EHSNR）字段中发送此信息。RTCP发送方或接收方报告必须由具有闭环发送策略的会话中的任何参与者发送，除非已商定其他反馈机制。
The sender may safely use receiver sequence number feedback to guide checkpoint history management because Section 4 requires that receivers repair indefinite artifacts whenever a packet loss event occurs.
发送方可以安全地使用接收方序列号反馈来指导检查点历史管理，因为第4节要求接收方在发生分组丢失事件时修复不确定的工件。
We now normatively define the closed-loop policy. At the moment a sender prepares an RTP packet for transmission, the sender is aware of R >= 0 receivers for the stream. Senders may become aware of a receiver via RTCP traffic from the receiver, via RTP packets from a paired stream sent by the receiver to the sender, via messages from a session management tool, or by other means. As receivers join and leave a session, the value of R changes.
我们现在规范地定义闭环策略。在发送方准备用于传输的RTP数据包的时刻，发送方知道该流的R>=0个接收机。发送方可以通过来自接收方的RTCP通信、通过来自接收方发送给发送方的成对流的RTP分组、通过来自会话管理工具的消息或通过其他方式来感知接收方。当接收者加入和离开会话时，R的值会发生变化。
Each known receiver k (1 <= k <= R) is associated with a 32-bit extended packet sequence number M(k), where the extension reflects the sequence number rollover count of the sender.
每个已知接收器k（1<=k<=R）与32位扩展包序列号M（k）相关联，其中扩展反映发送器的序列号滚动计数。
If the sender has received at least one feedback report from receiver k, M(k) is the most recent report of the highest RTP packet sequence number seen by the receiver, normalized to reflect the rollover count of the sender.
如果发送方已经从接收方k接收到至少一个反馈报告，则M（k）是接收方看到的最高RTP分组序列号的最新报告，标准化以反映发送方的滚动计数。
If the sender has not received a feedback report from the receiver, M(k) is the extended sequence number of the last packet the sender transmitted before it became aware of the receiver. If the sender became aware of this receiver before it sent the first packet in the stream, M(k) is the extended sequence number of the first packet in the stream.
如果发送方没有收到来自接收方的反馈报告，则M（k）是发送方在意识到接收方之前发送的最后一个数据包的扩展序列号。如果发送方在发送流中的第一个分组之前意识到该接收方，则M（k）是流中第一个分组的扩展序列号。
Given this definition of M(k), we now state the closed-loop policy. When preparing a new packet for transmission, a sender MUST choose a checkpoint packet with extended sequence number N, such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict sender behavior in the R == 0 (no known receivers) case.
给出M（k）的这个定义，我们现在陈述闭环策略。当准备新的分组进行传输时，发送方必须选择具有扩展序列号N的检查点分组，使得M（k）>=（N-1）对于所有k，1<=k<=R，其中R>=1。在R==0（无已知接收者）的情况下，该策略不限制发送者的行为。
Under the closed-loop policy as defined above, a sender may transmit packets whose checkpoint history is shorter than the session history (as defined in Appendix A.1). In this event, a new receiver that joins the stream may experience indefinite artifacts.
在上面定义的闭环策略下，发送方可以发送检查点历史短于会话历史的数据包（如附录a.1所定义）。在这种情况下，加入流的新接收器可能会经历不确定的伪影。
For example, if a Control Change (0xB) command for Channel Volume (controller number 7) was sent early in a stream, and later a new receiver joins the session, the closed-loop policy may permit all packets sent to the new receiver to use a checkpoint history that does not include the Channel Volume Control Change command. As a result, the new receiver experiences an indefinite artifact and plays all notes on a channel too loudly or too softly.
例如，如果在流的早期发送了通道卷（控制器编号7）的控制更改（0xB）命令，并且随后新的接收器加入会话，则闭环策略可允许发送到新接收器的所有数据包使用不包括通道卷控制更改命令的检查点历史记录。结果，新的接收者体验到一种不确定的伪影，并且在一个频道上播放所有音符时声音太大或太轻。
To address this issue, the closed-loop policy states that whenever a sender becomes aware of a new receiver, the sender MUST determine if the receiver would be subject to indefinite artifacts under the closed-loop policy. If so, the sender MUST ensure that the receiver starts the session free of indefinite artifacts. For example, to solve the Channel Volume issue described above, the sender may code the current state of the Channel Volume controller numbers in the recovery journal Chapter C, until it receives the first RTCP RR report that signals that a packet containing this Chapter C has been received.
为了解决这个问题，闭环策略规定，每当发送方意识到新的接收方时，发送方必须确定接收方是否会受到闭环策略下的不确定工件的影响。如果是这样，发送方必须确保接收方启动会话时没有不确定的工件。例如，为了解决上述信道卷问题，发送方可以在恢复日志第C章中对信道卷控制器编号的当前状态进行编码，直到其接收到第一个RTCP RR报告，该报告指示已接收到包含该第C章的分组。
In satisfying this requirement, senders MAY infer the initial MIDI state of the receiver from the session description. For example, the stream example in Section 6.2 has the initial state defined in [MIDI] for General MIDI.
为了满足这一要求，发送方可以从会话描述推断接收方的初始MIDI状态。例如，第6.2节中的流示例具有[MIDI]中为通用MIDI定义的初始状态。
In a unicast RTP session, a receiver may safely assume that the sender is aware of its presence as a receiver from the first packet sent in the RTP stream. However, in other types of RTP sessions (multicast, conference focus, RTP translator/mixer), a receiver is often not able to determine if the sender is initially aware of its presence as a receiver.
在单播RTP会话中，接收机可以安全地假设发送方从RTP流中发送的第一个分组知道其作为接收机的存在。然而，在其他类型的RTP会话（多播、会议焦点、RTP转换器/混合器）中，接收器通常无法确定发送者最初是否意识到其作为接收器的存在。
To address this issue, the closed-loop policy states that if a receiver participates in a session where it may have access to a stream whose sender is not aware of the receiver, the receiver MUST take actions to ensure that its rendered MIDI performance does not contain indefinite artifacts. These protections will be necessarily incomplete. For example, a receiver may monitor the Checkpoint
为了解决这个问题，闭环策略规定，如果接收者参与了一个会话，在该会话中，其可能有权访问发送者不知道接收者的流，则接收者必须采取措施确保其呈现的MIDI性能不包含不确定的伪影。这些保护措施必然是不完整的。例如，接收器可以监视检查点
Packet Seqnum for uncovered loss events and "err on the side of caution" with respect to handling stuck notes due to lost MIDI NoteOff commands, but the receiver is not able to compensate for the lack of Channel Volume initialization data in the recovery journal.
Packet Seqnum，用于未覆盖的丢失事件，以及在处理因丢失MIDI NoteOff命令而卡住的音符时“小心出错”，但接收器无法补偿恢复日志中缺少通道卷初始化数据。
The receiver MUST NOT discontinue these protective actions until it is certain that the sender is aware of its presence. If a receiver is not able to ascertain sender awareness, the receiver MUST continue these protective actions for the duration of the session.
在确定发送方意识到其存在之前，接收方不得停止这些保护措施。如果接收者无法确定发送者的感知，则接收者必须在会话期间继续这些保护操作。
Note that in a multicast session where all parties are expected to send and receive, the reception of RTCP receiver reports from the sender about the RTP stream a receiver is multicasting back is evidence of the sender's awareness that the RTP stream multicast by the sender is being monitored by the receiver. Receivers may also obtain sender awareness evidence from session management tools, or by other means. In practice, ongoing observation of the Checkpoint Packet Seqnum to determine if the sender is taking actions to prevent loss events for a receiver is a good indication of sender awareness, as is the sudden appearance of recovery journal chapters with numerous Control Change controller data that was not foreshadowed by recent commands coded in the MIDI list shortly after sending an RTCP RR.
注意，在期望所有各方发送和接收的多播会话中，接收来自发送方的关于接收方正在多播回的RTP流的RTP接收方报告是发送方意识到接收方正在监控发送方的RTP流多播的证据。接收者还可以从会话管理工具或通过其他方式获得发送者感知证据。实际上，持续观察检查点数据包Seqnum以确定发送方是否正在采取措施防止接收方发生丢失事件是发送方意识的良好指示，正如在发送RTCP RR后不久，恢复日志章节突然出现，其中包含大量控制更改控制器数据，而MIDI列表中编码的最新命令并未预示这些数据。
The final set of normative closed-loop policy requirements concerns how senders and receivers handle unplanned disruptions of RTCP feedback from a receiver to a sender. By "unplanned", we refer to disruptions that are not due to the signalled termination of an RTP stream, via an RTCP BYE or via session management tools.
最后一组规范性闭环策略要求涉及发送方和接收方如何处理从接收方到发送方的RTCP反馈的意外中断。所谓“计划外”，我们指的是不是由于RTP流通过RTCP BYE或通过会话管理工具发出终止信号而造成的中断。
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.
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.
如果此接收器k停止向发送者发送反馈，发送者使用的M（k）值将反映来自接收器的最后一次反馈报告。随着时间的推移，没有来自接收方k的反馈，这个固定的M（k）值迫使发送方增加检查点历史的大小，从而增加流的带宽。
At some point, the sender may need to take action in order to limit the bandwidth of the stream. In most envisioned uses of RTP MIDI, long before this point is reached, the SSRC time-out mechanism defined in [RFC3550] will remove the uncooperative receiver from the
在某个时刻，发送方可能需要采取措施来限制流的带宽。在RTP MIDI的大多数预期用途中，早在达到这一点之前，[RFC3550]中定义的SSRC超时机制就会将不合作接收器从系统中移除
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).
会话（请注意，闭环策略不建议或要求在SSRC超时时有任何特殊的发送方行为，本节前面介绍的与更改R相关的发送方操作除外）。
However, in rare situations, the bandwidth of the stream (due to a lack of feedback reports from the sender) may become too large to continue sending the stream to the receiver before the SSRC time-out occurs for the receiver. In this case, the closed-loop policy states that the sender should invoke the SSRC time-out for the receiver early.
然而，在极少数情况下，流的带宽（由于缺少来自发送方的反馈报告）可能变得太大，以至于在接收机发生SSRC超时之前无法继续向接收机发送流。在这种情况下，闭环策略规定发送方应尽早为接收方调用SSRC超时。
We now discuss receiver responsibilities in the case of unplanned disruptions of RTCP feedback from receiver to sender.
我们现在讨论接收方对发送方的RTCP反馈发生意外中断时的接收方责任。
In the unicast case, if a sender invokes the SSRC time-out mechanism for a receiver, the receiver stops receiving packets from the sender. The sender behavior imposed by the guardtime parameter (Appendix C.4.2) lets the receiver conclude that an SSRC time-out has occurred in a reasonable time period.
在单播情况下，如果发送方为接收方调用SSRC超时机制，接收方将停止从发送方接收数据包。guardtime参数（附录C.4.2）施加的发送方行为让接收方得出结论，SSRC超时发生在合理的时间段内。
In this case of a time-out, a receiver MUST keep sending RTCP feedback, in order to re-establish the RTP flow from the sender. Unless the receiver expects a prompt recovery of the RTP flow, the receiver MUST take actions to ensure that the rendered MIDI performance does not exhibit "very long transient artifacts" (for example, by silencing NoteOns to prevent stuck notes) while awaiting reconnection of the flow.
在这种超时情况下，接收方必须继续发送RTCP反馈，以便从发送方重新建立RTP流。除非接收者期望RTP流立即恢复，否则接收者必须在等待流重新连接时采取措施确保渲染的MIDI性能不会出现“非常长的瞬态伪影”（例如，通过使音符静音以防止卡住的音符）。
In the multicast case, if a sender invokes the SSRC time-out mechanism for a receiver, the receiver may continue to receive packets, but the sender will no longer be using the M(k) feedback from the receiver to choose each checkpoint packet. If the receiver does not have additional information that precludes an SSRC time-out (such as RTCP Receiver Reports from the sender about an RTP stream the receiver is multicasting back to the sender), the receiver MUST monitor the Checkpoint Packet Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, the receiver MUST follow the instructions for SSRC time-outs described for the unicast case above.
在多播情况下，如果发送方为接收方调用SSRC超时机制，则接收方可以继续接收分组，但是发送方将不再使用来自接收方的M（k）反馈来选择每个检查点分组。如果接收器没有阻止SSRC超时的附加信息（例如RTCP接收器从发送方报告接收器正在多播回发送方的RTP流），接收器必须监控检查点数据包Seqnum以检测SSRC超时。如果检测到SSRC超时，则接收器必须遵循针对上述单播情况所述的SSRC超时说明。
Finally, we note that the closed-loop policy is suitable for use in RTP/RTCP sessions that use multicast transport. However, aspects of the closed-loop policy do not scale well to sessions with large numbers of participants. The sender state scales linearly with the number of receivers, as the sender needs to track the identity and M(k) value for each receiver k. The average recovery journal size is not independent of the number of receivers, as the RTCP reporting interval backoff slows down the rate of a full update of M(k) values.
最后，我们注意到闭环策略适用于使用多播传输的RTP/RTCP会话。然而，闭环策略的某些方面不能很好地扩展到有大量参与者的会议。发送方状态随接收方数量线性扩展，因为发送方需要跟踪每个接收方k的标识和M（k）值。平均恢复日志大小与接收器数量无关，因为RTCP报告间隔回退会减慢M（k）值的完全更新速率。
The backoff algorithm may also increase the amount of ancillary state used by implementations of the normative sender and receiver behaviors defined in Section 4.
退避算法还可以增加第4节中定义的标准发送方和接收方行为的实现所使用的辅助状态量。
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.
为确保未发现的丢失事件不会影响恢复日志授权，开环策略会将特定的恢复任务分配给会话描述的发送方、接收方和创建者。开环策略的基本前提是，未发现损失事件期间产生的不确定工件分为两类。
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.
一类工件是可恢复的不确定工件。接收者能够修复在未发现的丢失事件期间发生的可恢复工件，而无需发送者的干预，以不愉快的瞬态工件的潜在成本为代价。
For example, after an uncovered loss event, receivers are able to repair indefinite artifacts due to NoteOff (0x8) commands that may have occurred during the loss event, by executing NoteOff commands for all active NoteOns commands. This action causes a transient artifact (a sudden silent period in the performance) but ensures that no stuck notes sound indefinitely. We refer to MIDI commands that are amenable to repair in this fashion as recoverable MIDI commands.
例如，在未覆盖的丢失事件之后，接收器能够通过对所有活动的NoteOns命令执行NoteOff命令，修复丢失事件期间可能发生的NoteOff（0x8）命令导致的不确定工件。这个动作会导致一个短暂的假象（表演中突然的沉默期），但可以确保没有被卡住的音符无限期地发出声音。我们将适合以这种方式修复的MIDI命令称为可恢复MIDI命令。
A second class of artifacts is unrecoverable indefinite artifacts. If this class of artifact occurs during an uncovered loss event, the receiver is not able to repair the stream.
第二类工件是不可恢复的不确定工件。如果此类伪影发生在未覆盖的丢失事件期间，则接收方无法修复流。
For example, after an uncovered loss event, receivers are not able to repair indefinite artifacts due to Control Change (0xB) Channel Volume (controller number 7) commands that have occurred during the loss event. A repair is impossible because the receiver has no way
例如，在未覆盖的丢失事件之后，由于丢失事件期间发生的控制更改（0xB）通道卷（控制器编号7）命令，接收器无法修复不确定的工件。维修是不可能的，因为接收器没有办法
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.
用于确定丢失通道音量命令的数据值。我们将以这种方式脆弱的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.
在开环策略中，会话描述的创建者必须使用Chu 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节说明了如何执行此检查。如果发生未覆盖的丢失事件，则接收器必须对会话描述中未被Chu anchor和cm_未使用参数分配屏蔽的所有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 and B) specify under what conditions a chapter MUST appear in the recovery journal. In most cases, the definition states that if a certain command appears in the checkpoint history, a certain chapter type MUST appear in the recovery journal to protect the command.
恢复日记账章节定义（附录A和B）规定了在何种条件下，章节必须出现在恢复日记账中。在大多数情况下，该定义指出，如果某个命令出现在检查点历史记录中，则某个章节类型必须出现在恢复日志中，以保护该命令。
In this section, we describe the chapter inclusion parameters. These parameters modify the conditions under which a chapter appears in the journal. These parameters are essential to the use of the open-loop
在本节中，我们将介绍包含参数一章。这些参数修改章节在日记中出现的条件。这些参数对于开环的使用至关重要
policy (Appendix C.2.2.3) and may also be used to simplify implementations of the closed-loop (Appendix C.2.2.2) and anchor (Appendix C.2.2.1) policies.
策略（附录C.2.2.3），也可用于简化闭环（附录C.2.2.2）和锚定（附录C.2.2.1）策略的实施。
Each parameter represents a type of chapter inclusion semantics. An assignment to a parameter declares which chapters (or chapter subsets) obey the inclusion semantics. We describe the assignment syntax for these parameters later in this section.
每个参数表示一种章节包含语义。对参数的赋值声明哪些章节（或章节子集）遵循包含语义。我们将在本节后面介绍这些参数的赋值语法。
A party MUST NOT accept chapter inclusion parameter values that violate the recovery journal mandate (Section 4). All assignments of the subsetting parameters (cm_used and cm_unused) MUST precede the first assignment of a chapter inclusion parameter in the parameter list.
一方不得接受违反恢复日志授权的章节包含参数值（第4节）。子集参数的所有赋值（使用的cm_和未使用的cm_）必须在参数列表中章节包含参数的第一次赋值之前进行。
Below, we normatively define the semantics of the chapter inclusion parameters. For clarity, we define the action of parameters on complete chapters. If a parameter is assigned a subset of a chapter, the definition applies only to the chapter subset.
下面，我们规范性地定义章节包含参数的语义。为了清楚起见，我们定义了参数在完整章节中的作用。如果为参数指定了章节的子集，则定义仅适用于章节子集。
o ch_never. A chapter assigned to the ch_never parameter MUST NOT appear in the recovery journal (Appendices A.4.1 and A.4.2 define exceptions to this rule for Chapter M). To signal the exclusion of a chapter from the journal, an assignment to ch_never MUST be made, even if the commands coded by the chapter are assigned to cm_unused. This rule simplifies the handling of commands types that may be coded in several chapters.
o 邱从不。分配给ch_never参数的章节不得出现在恢复日志中（附录A.4.1和A.4.2为章节M定义了本规则的例外情况）。为了表示将某章从日志中排除，即使该章编码的命令被分配给cm_，也不必向ch_分配。此规则简化了可能在多个章节中编码的命令类型的处理。
o ch_default. A chapter assigned to the ch_default parameter MUST follow the default semantics for the chapter, as defined in Appendices A and B.
o Chu默认。指定给Chu 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 楚锚。指定给Chu锚定的章节必须遵守默认章节语义的修改版本。在修改后的语义中，对检查点历史的所有引用被替换为对会话历史的引用，对检查点数据包的所有引用被替换为对流中发送的第一个数据包的引用。
Parameter assignments obey the following syntax (see Appendix D for ABNF):
参数赋值遵循以下语法（ABNF见附录D）：
<parameter> = [channel list]<chapter list>[field list]
<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.
为了确定章节包含参数分配列表的语义，我们首先假设所有通道和系统章节都隐式分配给Chu default参数，每个章节的通道列表和字段列表的默认值定义如下。
We then interpret the semantics of the actual parameter assignments, using the rules below.
然后，我们使用以下规则解释实际参数赋值的语义。
A later assignment of a chapter to the same parameter expands the scope of the earlier assignment. In most cases, a later assignment of a chapter to a different parameter cancels (partially or completely) the effect of an earlier assignment.
稍后将章节赋值给同一参数会扩展先前赋值的范围。在大多数情况下，将章节稍后指定给不同参数会取消（部分或完全）先前指定的效果。
The chapter list specifies the channel or system chapters for which the parameter applies. The chapter list is a concatenated sequence of one or more of the letters corresponding to the chapter types (ACDEFMNPQTVWX). In addition, the list may contain one or more of the letters for the subchapter types (BGHJKYZ) of System Chapter D.
章节列表指定参数适用的通道或系统章节。章节列表是与章节类型（ACDEFMNPQTVWX）对应的一个或多个字母的串联序列。此外，该列表可能包含系统第D章分章类型（BGHJKYZ）的一个或多个字母。
The letters in a chapter list MUST be uppercase and MUST appear in alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that appear in the chapter list MUST be ignored.
章节列表中的字母必须是大写，并且必须按字母顺序出现。必须忽略章节列表中出现的字母（ABCDEFGHJKMNPQTVWXYZ）以外的其他字母。
The channel list specifies the channel journals for which this parameter applies; if no channel list is provided, the parameter applies to all channel journals. The channel list takes the form of a list of channel numbers (0 through 15) and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the channel list.
频道列表指定此参数适用的频道日记帐；如果未提供频道列表，则该参数适用于所有频道日记帐。信道列表采用信道编号列表（0到15）和破折号分隔的信道编号范围（即0-5、8-12等）的形式。点（即“.”字符）分隔通道列表中的元素。
Several of the system chapters may be configured to have special semantics. Configuration occurs by specifying a channel list for the system channel, using the coding described below. (Note that MIDI system commands do not have a "channel" and thus the original purpose of the channel list does not apply to system chapters). The expression "the digit N" in the text below refers to the inclusion of N as a "channel" in the channel list for a system chapter.
一些系统章节可以配置为具有特殊语义。通过使用下面描述的编码为系统信道指定信道列表来进行配置。（请注意，MIDI系统命令没有“通道”，因此通道列表的原始用途不适用于系统章节）。下文中的“数字N”表示在系统章节的频道列表中包含N作为“频道”。
For the J and K Chapter D subchapters (undefined System Common), the digit 0 codes that the parameter applies to the LEGAL field of the associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes that the parameter applies to the VALUE field of the command log, and the digit 2 codes that the parameter applies to the COUNT field of the command log.
对于J和K章D分章（未定义的系统通用），参数应用于相关命令日志的合法字段的数字0代码（附录B.1图B.1.4），参数应用于命令日志的值字段的数字1代码，以及参数应用于命令日志计数字段的数字2代码。
For the Y and Z Chapter D subchapters (undefined System Real-Time), the digit 0 codes that the parameter applies to the LEGAL field of the associated command log (Figure B.1.5 of Appendix B.1) and the digit 1 codes that the parameter applies to the COUNT field of the command log.
对于Y和Z章D分章（未定义的系统实时），参数应用于相关命令日志（附录B.1图B.1.5）的合法字段的数字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.
对于章节Q（序列器状态命令），参数应用于默认章节Q定义的数字0代码禁止时间字段。数字1表示参数应用于可选章节Q定义的代码，该章节Q定义支持时间字段。
The syntax for field lists follows the syntax for channel lists. If no field list is provided, the parameter applies to all controller or note numbers. For Chapter C, if no field list is provided, the controller numbers do not use enhanced Chapter C encoding (Appendix A.3.3).
字段列表的语法遵循通道列表的语法。如果未提供字段列表，则该参数适用于所有控制器或注释编号。对于C章，如果未提供字段列表，控制器编号不使用增强的C章编码（附录A.3.3）。
For Chapter C, the field list may take on values in the range 0 to 255. A field value X in the range 0-127 refers to a controller number X and indicates that the controller number does not use enhanced Chapter C encoding. A field value X in the range 128-255 refers to a controller number "X minus 128" and indicates the controller number does use the enhanced Chapter C encoding.
对于C章，字段列表的值可能在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章编码方法而进行的分配必须针对CHU默认参数或CHU锚参数，因为对CHU的分配不会将编号从恢复日志中排除（因此，指定的编码方法是无关的）。
A Chapter C field list MUST NOT encode conflicting information about the enhanced encoding status of a particular controller number. For example, values 0 and 128 MUST NOT both be coded by a field list.
C章字段列表不得对特定控制器编号的增强编码状态的冲突信息进行编码。例如，值0和128不能都由字段列表编码。
For Chapter M, the field list codes the RPN and NRPN controller numbers for which the parameter applies. The number range 0-16383 specifies RPN controller numbers, the number range 16384-32767 specifies NRPN controller numbers (16384 corresponds to NRPN controller number 0, 32767 corresponds to NRPN controller number 16383).
对于第M章，字段列表对参数适用的RPN和NRPN控制器编号进行编码。数字范围0-16383指定RPN控制器编号，数字范围16384-32767指定NRPN控制器编号（16384对应于NRPN控制器编号0，32767对应于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，参数应用于V位设置为0的章节E注释日志的数字0代码，以及参数应用于V位设置为1的注释日志的数字1代码。
For Chapter X, the field list codes the number of data octets that may appear in a SysEx command that is coded in the chapter. Thus, the field list 0-255 specifies SysEx commands with 255 or fewer data octets, the field list 256-4294967295 specifies SysEx commands with more than 255 data octets but excludes commands with 255 or fewer data octets, and the field list 0 excludes all commands.
对于第十章，字段列表编码可能出现在本章编码的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):
辅助参数赋值语法定制了第十章（完整ABNF见附录D）：
<parameter> = "__" <h-list> *( "_" <h-list> ) "__"
<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.
赋值定义了一类SysEx命令，其第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.
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.
Using this syntax, each assignment specifies a single SysEx command class. Session descriptions may use several assignments to the same (or different) parameters to specify complex Chapter X behaviors. The ordering behavior of multiple assignments follows the guidelines for chapter parameter assignments described earlier in this section.
使用此语法，每个赋值指定一个SysEx命令类。会话描述可以使用多个相同（或不同）参数的赋值来指定复杂的第十章行为。多个赋值的排序行为遵循本节前面介绍的章节参数赋值准则。
The example session description below illustrates the use of the chapter inclusion parameters:
下面的示例会话描述说明了章节包含参数的使用：
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ;
cm_used=__7E_00-7F_09_01.02.03__;
cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64;
ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N;
ch_anchor=P; ch_anchor=C7.64;
ch_anchor=__7E_00-7F_09_01.02.03__;
ch_anchor=__7F_00-7F_04_01.02__
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ;
cm_used=__7E_00-7F_09_01.02.03__;
cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64;
ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N;
ch_anchor=P; ch_anchor=C7.64;
ch_anchor=__7E_00-7F_09_01.02.03__;
ch_anchor=__7F_00-7F_04_01.02__
(The a=fmtp line has been wrapped to fit the page to accommodate memo formatting restrictions; it comprises a single line in SDP.)
（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_更新流使用开环策略的参数代码。大多数MIDI命令类型被分配给未使用的cm_，因此不会出现在流中。因此，对第一个Chu参数的赋值从不反映大多数章节未被使用。
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章分配给Chu never。除4、11、12和13以外的MIDI通道的第N章可能会出现在恢复日志中，使用（默认）ch_默认语义。在实践中，此分配模式将反映有关用于排除通道的弹性渲染方法的知识。
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控制更改控制器编号分配给Chu anchor。请注意，Chu never命令之后Chu anchor第C章分配的顺序将覆盖所列控制器编号（7和64）的Chu never分配。
The assignment of command-type X to cm_unused excludes most SysEx commands from the stream. Exceptions are made for General MIDI System On/Off commands and for the Master Volume and Balance commands, via the use of the secondary assignment syntax. The cm_used assignment codes the exception, and the ch_anchor assignment codes how these commands are protected in Chapter X.
将命令类型X分配给cm_unused会从流中排除大多数SysEx命令。通过使用辅助分配语法，一般MIDI系统开/关命令以及主音量和平衡命令除外。cm_使用分配代码对异常进行编码，ch_锚定分配代码在第十章中对这些命令的保护方式进行编码。
The MIDI command section of the payload format consists of a list of commands, each with an associated timestamp. The semantics of command timestamps may be set during session configuration using the parameters we describe in this section.
有效负载格式的MIDI命令部分由命令列表组成，每个命令都有一个相关的时间戳。命令时间戳的语义可以在会话配置期间使用我们在本节中描述的参数进行设置。
The parameter tsmode specifies the timestamp semantics for a stream. The parameter takes on one of three token values: "comex", "async", or "buffer".
参数tsmode指定流的时间戳语义。该参数采用三个令牌值之一：“comex”、“异步”或“缓冲区”。
The default "comex" value specifies that timestamps code the execution time for a command (Appendix C.3.1) and supports the accurate transcoding of Standard MIDI Files (SMFs, [MIDI]). The "comex" value is also RECOMMENDED for new MIDI user-interface controller designs. The "async" value specifies an asynchronous timestamp sampling algorithm for time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of-arrival sources.
默认的“comex”值指定时间戳编码命令的执行时间（附录C.3.1），并支持标准MIDI文件（SMF，[MIDI]）的准确转码。对于新的MIDI用户界面控制器设计，也建议使用“comex”值。“async”值指定了到达时间源的异步时间戳采样算法（附录C.3.2）。“缓冲区”值指定了到达时间源的同步时间戳采样算法（附录C.3.3）。
Ancillary parameters MAY follow tsmode in a media description. We define these parameters in Appendices C.3.2 and C.3.3.
辅助参数可以在介质描述中跟随tsmode。我们在附录C.3.2和C.3.3中定义了这些参数。
The default "comex" (COMmand EXecution) tsmode value specifies the execution time for the command. With comex, the difference between two timestamps indicates the time delay between the execution of the commands. This difference may be zero, coding simultaneous execution.
默认的“comex”（命令执行）tsmode值指定命令的执行时间。对于comex，两个时间戳之间的差异表示命令执行之间的时间延迟。此差异可能为零，编码同时执行。
The comex interpretation of timestamps works well for transcoding a Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a timestamp for each MIDI command stored in the file. To transcode an SMF that uses metric time markers, use the SMF tempo map (encoded in the SMF as meta-events) to convert metric SMF timestamp units into seconds-based RTP timestamp units.
comex对时间戳的解释适用于将标准MIDI文件（SMF，[MIDI]）转换为RTP MIDI流，因为SMFs为文件中存储的每个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时间戳解释，以便RTP MIDI可以准确地编码同步手势事件。
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.0DIN电缆[MIDI]来说是一个糟糕的选择，原因我们现在将解释。MIDI DIN电缆是一种异步串行协议（每个MIDI字节320微秒）。DIN电缆上的MIDI命令没有标记时间戳。相反，MIDI DIN接收器从字节到达的时间推断命令时间。因此，在一个源上同时出现的两个双字节MIDI命令在MIDI 1.0 DIN电缆上以640微秒的时间偏移进行编码。MIDI DIN接收器无法分辨此时间偏移是否存在于源性能中，或者是电缆串行速度的伪影。但是，时间戳的RTP MIDI comex解释声明，两个命令之间的时间戳偏移反映源性能的计时。
This semantic mismatch is the reason that comex is a poor choice for transcoding MIDI DIN cables. Note that the choice of the RTP timestamp rate (Sections 6.1 and 6.2 in the main text) cannot fix this inaccuracy issue. In the sections that follow, we describe two alternative timestamp interpretations ("async" and "buffer") that are a better match to MIDI 1.0 DIN cable timing and to other MIDI time-of-arrival sources.
这种语义不匹配是comex在转换MIDI-DIN电缆代码时不是一个好选择的原因。请注意，选择RTP时间戳速率（正文第6.1节和第6.2节）无法解决此不准确问题。在接下来的章节中，我们将介绍两种可选的时间戳解释（“异步”和“缓冲”），它们更好地匹配MIDI 1.0 DIN电缆定时和其他MIDI到达时间源。
The octpos, linerate, and mperiod ancillary parameters (defined below) SHOULD NOT be used with comex.
octpos、linerate和mperiod辅助参数（定义见下文）不应与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到达时间源的异步采样。在异步采样中，从源接收到八位字节的那一刻，就用墙上的时钟时间值来标记八位字节。时间值具有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具有令牌值“first”，则时间戳对命令的第一个八位字节的时间值进行编码。如果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语义指的是在到达时间MIDI源上显示的命令的第一个或最后一个八位字节，而不是RTP MIDI数据包中显示的八位字节。这种区别很重要，因为RTP编码可能包含源中不存在的八位字节。例如，数据包中第一个MIDI命令的状态八位字节可能已在转码期间添加到MIDI流中，以符合RTP MIDI运行状态要求（第3.2节）。
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).
linerate辅助参数定义要采样的MIDI源（如MIDI 1.0 DIN电缆）传输介质上一个MIDI八位字节的时间跨度。该参数以纳秒为单位，并采用整数值。对于MIDI 1.0 DIN电缆，正确的线速率值为320000（该值也是参数的默认值）。
We now show a session description example for the async algorithm. Consider a sender that is transcoding a MIDI 1.0 DIN cable source into RTP. The sender runs on a computing platform that assigns time values to every incoming octet of the source, and the sender uses the time values to label the first octet of each command in the RTP packet. This session description describes the transcoding:
我们现在展示异步算法的会话描述示例。考虑一个发送MIDI 1 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
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数据包中对这些命令进行编码。命令timestamp对缓冲区检查的时刻进行编码，以RTP时间戳单位表示。请注意，多个命令可能具有相同的时间戳值。
The mperiod ancillary parameter defines the nominal periodic sampling interval. The parameter takes on positive integral values and has RTP timestamp units.
mperiod辅助参数定义了标称周期采样间隔。该参数采用正整数值，并具有RTP时间戳单位。
The octpos ancillary parameter, defined in Appendix C.3.2 for asynchronous sampling, plays a different role in synchronous sampling. In synchronous sampling, the parameter specifies the timestamp semantics of a command whose octets span several sampling periods.
附录C.3.2中针对异步采样定义的octpos辅助参数在同步采样中起着不同的作用。在同步采样中，该参数指定八位字节跨越多个采样周期的命令的时间戳语义。
If octpos has the token value "first", the timestamp reflects the arrival period of the first octet of the command. If octpos has the token value "last", the timestamp reflects the arrival period of the last octet of the command. The octpos semantics refer to the first or last octet of the command as it appears on a time-of-arrival source, not as it appears in the RTP packet.
如果octpos具有令牌值“first”，则时间戳反映命令的第一个八位字节的到达周期。如果octpos具有标记值“last”，则时间戳反映命令最后一个八位字节的到达周期。octpos语义是指在到达时间源上显示的命令的第一个或最后一个八位字节，而不是RTP数据包中显示的八位字节。
If the octpos parameter does not appear in the media description, the timestamp MAY reflect the arrival period of any octet of the command; senders use this option to signal a lack of knowledge about the timing details of the buffering process at subcommand granularity.
如果octpos参数没有出现在媒体描述中，则时间戳可以反映命令的任何八位字节的到达周期；发送方使用此选项表示不了解子命令粒度的缓冲过程的计时细节。
We now show a session description example for the buffer algorithm. Consider a sender that is transcoding a MIDI 1.0 DIN cable source into RTP. The sender runs on a computing platform that places source data into a buffer upon receipt. The sender polls the buffer 1000 times a second, extracts all complete commands from the buffer, and places the commands in an RTP packet. This session description describes the transcoding:
现在，我们将展示缓冲区算法的会话描述示例。考虑一个发送MIDI 1 DIN电缆源到RTP的发送器。发送方运行在一个计算平台上，该平台在收到源数据时将其放入缓冲区。发送方每秒轮询缓冲区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:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=sendonly
a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=sendonly
a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44
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.
mperiod值44是通过将rtpmap属性（44100 Hz）指定的时钟频率除以1000 Hz缓冲区采样率并四舍五入到最接近的整数得出的。命令时间戳可能不会以44的精确倍数递增，因为实际采样周期可能与标称mperiod值不完全匹配。
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.
发送方通过设置流中数据包的时间持续时间（“媒体时间”）来控制流的粒度。短媒体时间（20毫秒或更短）通常意味着互动会话。较长的媒体时间（100毫秒或更长）通常表示内容流会话。RTP AVP配置文件[RFC3551]建议音频包媒体时间在0到200毫秒之间。
By default, an RTP receiver dynamically senses the media time of packets in a stream and chooses the length of its playout buffer to match the stream. A receiver typically sizes its playout buffer to fit several audio packets and adjusts the buffer length to reflect the network jitter and the sender timing fidelity.
默认情况下，RTP接收器动态感知流中数据包的媒体时间，并选择其播放缓冲区的长度以匹配流。接收器通常会调整其播放缓冲区的大小，以适合多个音频包，并调整缓冲区长度以反映网络抖动和发送方定时保真度。
Alternatively, the packet media time may be statically set during session configuration. Session descriptions MAY use the RTP MIDI parameter rtp_ptime to set the recommended media time for a packet. Session descriptions MAY also use the RTP MIDI parameter rtp_maxptime to set the maximum media time for a packet permitted in a stream. Both parameters MAY be used together to configure a stream.
或者，可以在会话配置期间静态地设置分组媒体时间。会话描述可以使用RTP MIDI参数RTP_ptime来设置数据包的建议媒体时间。会话描述还可以使用RTP MIDI参数RTP_maxptime来设置流中允许的数据包的最大媒体时间。这两个参数可一起用于配置流。
The values assigned to the rtp_ptime and rtp_maxptime parameters have the units of the RTP timestamp for the stream, as set by the rtpmap attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of a stream to 44100 Hz, a maximum packet media time of 10 ms is coded
分配给rtp_ptime和rtp_maxptime参数的值具有流的rtp时间戳的单位，如rtpmap属性所设置（参见第6.1节）。因此，如果rtpmap将流的时钟速率设置为44100 Hz，则编码10 ms的最大分组媒体时间
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.
通过设置rtp_maxptime=441。如附录C序言所述，如果流的媒体描述中出现参数，则流的发送方和接收方必须就rtp_ptime和rtp_maxptime的通用值达成一致。
0 ms is a reasonable media time value for MIDI packets and is often used in low-latency interactive applications. In a packet with a 0 ms media time, all commands execute at the instant they are coded by the packet timestamp. The session description below configures all packets in the stream to have 0 ms media time:
0毫秒是MIDI数据包的合理媒体时间值，通常用于低延迟交互式应用程序。在媒体时间为0毫秒的数据包中，所有命令都在数据包时间戳编码的瞬间执行。下面的会话描述将流中的所有数据包配置为具有0毫秒的媒体时间：
v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 rtp_ptime=0; rtp_maxptime=0
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.
会话属性ptime和maxptime[RFC4566]不得用于配置RTP MIDI流。会话必须使用rtp_ptime代替ptime，并且必须使用rtp_maxptime代替maxptime。RTP MIDI为媒体时间配置定义了自己的参数，因为[RFC3264]禁止使用ptime和maxptime的0毫秒值，但对于RTP MIDI的某些应用程序来说是必不可少的。
See the Appendix C.7 examples for additional discussion about using rtp_ptime and rtp_maxptime for session configuration.
有关使用rtp_ptime和rtp_maxptime进行会话配置的更多讨论，请参见附录C.7示例。
RTP permits a sender to stop sending audio packets for an arbitrary period of time during a session. When sending resumes, the RTP sequence number series continues unbroken, and the RTP timestamp value reflects the media time silence gap.
RTP允许发送方在会话期间的任意时间段内停止发送音频包。发送恢复时，RTP序列号连续不间断，RTP时间戳值反映媒体静默时间间隔。
This RTP feature has its roots in telephony, but it is also well-matched to interactive MIDI sessions, as players may fall silent for several seconds during (or between) songs.
这种RTP功能起源于电话技术，但它也与交互式MIDI会话非常匹配，因为在播放歌曲期间（或在歌曲之间），玩家可能会沉默几秒钟。
Certain MIDI applications benefit from a slight enhancement to this RTP feature. In interactive applications, receivers may use online network models to guide heuristics for handling lost and late RTP packets. These models may work poorly if a sender ceases packet transmission for long periods of time.
某些MIDI应用程序受益于此RTP功能的轻微增强。在交互式应用中，接收器可以使用在线网络模型来指导处理丢失和延迟RTP数据包的启发式方法。如果发送方长时间停止数据包传输，这些模型可能效果不佳。
Session descriptions may use the parameter guardtime to set a minimum sending rate for a media session. The value assigned to guardtime codes the maximum separation time between two sequential packets, as expressed in RTP timestamp units.
会话描述可以使用参数guardtime设置媒体会话的最小发送速率。分配给guardtime的值表示两个连续数据包之间的最大间隔时间，以RTP时间戳单位表示。
Typical guardtime values are 500-2000 ms. This value range is not a normative bound, and parties SHOULD be prepared to process values outside this range.
典型的guardtime值为500-2000 ms。该值范围不属于标准范围，各方应准备处理该范围以外的值。
The congestion control requirements for sender implementations (described in Section 8 and [RFC3550]) take precedence over the guardtime parameter. Thus, if the guardtime parameter requests a minimum sending rate, but sending at this rate would violate the congestion control requirements, senders MUST ignore the guardtime parameter value. In this case, senders SHOULD use the lowest minimum sending rate that satisfies the congestion control requirements.
发送方实现的拥塞控制要求（如第8节和[RFC3550]所述）优先于guardtime参数。因此，如果guardtime参数请求最小发送速率，但以该速率发送将违反拥塞控制要求，则发送方必须忽略guardtime参数值。在这种情况下，发送方应使用满足拥塞控制要求的最低发送速率。
Below, we show a session description that uses the guardtime parameter.
下面，我们将显示使用guardtime参数的会话描述。
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0
As we discussed in Section 2.1, a party may send several RTP MIDI streams in the same RTP session, and several RTP sessions that carry MIDI may appear in a multimedia session.
正如我们在第2.1节中所讨论的，一方可以在同一RTP会话中发送多个RTP MIDI流，并且多个携带MIDI的RTP会话可能出现在多媒体会话中。
By default, the MIDI name space (16 channels + systems) of each RTP stream sent by a party in a multimedia session is independent. By independent, we mean three distinct things:
默认情况下，一方在多媒体会话中发送的每个RTP流的MIDI名称空间（16个通道+系统）是独立的。所谓独立，我们指的是三件截然不同的事情：
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 如果一方发送两个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不被认为是32通道MIDI语音通道空间的“通道16”，其“通道0”是流a的通道0。
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会话发送但具有不同有效负载类型号的流，不共享MIDI电缆对共享的关联，该电缆对交叉连接MIDI 1.0 DIN网络中的两个设备。默认情况下，此关联仅由同一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流不是独立的，而是以上面定义的三种方式之一相关的。我们使用两种工具来表达这些关系：
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 [RFC5888] signals that several RTP sessions in a multimedia session are using the musicport parameter to express an inter-session relationship.
o FID分组属性[RFC5888]表示多媒体会话中的几个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参数被分配了相同的整数值，则使用这些有效负载类型的流共享“标识关系”（包括使用相同有效负载类型的流）。标识关系中的流共享两个属性：
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电缆对共享的关联，该电缆对交叉连接MIDI 1.0 DIN网络中的两个设备。
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会话中发送共享标识关系的两个RTP MIDI流。相反，每个流必须位于单独的RTP会话中。如第2.1节所述，此限制对于支持RTP MIDI方法以同步共享MIDI名称空间的流是必要的。
If a multimedia session has several payload types whose musicport parameters are assigned sequential values (i.e., i, i+1, ... i+k), the streams using the payload types share an "ordered relationship". For example, if payload type A assigns 2 to musicport and payload type B assigns 3 to musicport, A and B are in an ordered relationship.
如果多媒体会话具有多个有效负载类型，其musicport参数被分配顺序值（即，i，i+1，…i+k），则使用有效负载类型的流共享“有序关系”。例如，如果有效负载类型A将2分配给musicport，而有效负载类型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空间。例如，如果流A的musicport值为2，而流B的musicport值为3，则流B中的MIDI语音通道0被认为是由该关系形成的较大MIDI空间中的语音通道16。请注意，流可以同时参与标识关系和有序关系。
We now state several rules for using musicport:
我们现在陈述了使用musicport的几个规则：
o If streams from several RTP sessions in a multimedia session use the musicport parameter, the RTP sessions MUST be grouped using the FID grouping attribute defined in [RFC5888].
o 如果来自多媒体会话中多个RTP会话的流使用musicport参数，则必须使用[RFC5888]中定义的FID分组属性对RTP会话进行分组。
o An ordered or identity relationship MUST NOT contain both native RTP MIDI streams and mpeg4-generic RTP MIDI streams. An exception applies if a relationship consists of sendonly and recvonly (but not sendrecv) streams. In this case, the sendonly streams MUST NOT contain both types of streams, and the recvonly streams MUST NOT contain both types of streams.
o 有序或标识关系不能同时包含本机RTP MIDI流和mpeg4通用RTP MIDI流。如果关系由sendonly和recvonly（但不是sendrecv）流组成，则会出现例外情况。在这种情况下，sendonly流不能同时包含这两种类型的流，recvonly流不能同时包含这两种类型的流。
o It is possible to construct identity relationships that violate the recovery journal mandate (for example, sending NoteOns for a voice channel on stream A and NoteOffs for the same voice channel on stream B). Parties MUST NOT generate (or accept) session descriptions that exhibit this flaw.
o 可以构造违反恢复日志授权的标识关系（例如，为流a上的语音通道发送便笺，为流B上的同一语音通道发送便笺）。各方不得生成（或接受）显示此缺陷的会话描述。
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.
通常，关系中最多有一种负载类型可以指定MIDI渲染器。该规则的一个例外适用于包含sendonly和recvonly流但不包含sendrecv流的关系。在这种情况下，一个sendonly会话和一个RecvoOnly会话可以分别定义一个渲染器。
Renderer specification in a relationship may be done using the tools described in Appendix C.6. These tools work for both native streams and mpeg4-generic streams. An mpeg4-generic stream that uses the Appendix C.6 tools MUST set all "config" parameters to the empty string ("").
可以使用附录C.6中描述的工具完成关系中的渲染器规范。这些工具适用于本机流和mpeg4通用流。使用附录C.6工具的mpeg4通用流必须将所有“配置”参数设置为空字符串（“”）。
Alternatively, for mpeg4-generic streams, renderer specification may be done by setting one "config" parameter in the relationship to the renderer configuration string and all other config parameters to the empty string ("").
或者，对于mpeg4通用流，可以通过在与呈现器配置字符串的关系中设置一个“config”参数，并将所有其他配置参数设置为空字符串（“”），来完成呈现器规范。
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命令的结构完整性，就像合并传统MIDI 1.0 DIN电缆流的软件负责创建与[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节中所定义）。即使所有流都通过可靠的传输发送，这种责任仍然存在，因为不同的流延迟可能会产生不确定的工件。例如，如果在一个流上发送NoteOn命令，而在另一个流上发送NoteOff命令，则在两个TCP流上的性能拆分中可能会出现卡住的注释。
Senders MUST NOT split a Registered Parameter Numbers (RPN) or Non-Registered Parameter Numbers (NRPN) transaction appearing on a MIDI channel across multiple identity relationship sessions. Receivers MUST assume that the RPN/NRPN transactions that appear on different identity relationship sessions are independent and MUST preserve transactional integrity during the MIDI merge.
发送方不得跨多个身份关系会话拆分MIDI通道上出现的注册参数号（RPN）或非注册参数号（NRPN）事务。接收方必须假设出现在不同身份关系会话上的RPN/NRPN事务是独立的，并且必须在MIDI合并期间保持事务完整性。
A simple way to safely partition voice channel commands is to place all MIDI commands for a particular voice channel into the same session. Safe partitioning of MIDI system commands may be more complicated for sessions that extensively use System Exclusive.
安全划分语音通道命令的一种简单方法是将特定语音通道的所有MIDI命令放在同一会话中。对于广泛使用system Exclusive的会话，MIDI系统命令的安全分区可能更加复杂。
We now show several session description examples that use the musicport parameter.
现在我们展示几个使用musicport参数的会话描述示例。
Our first session description example shows two RTP MIDI streams that drive the same General MIDI decoder. The sender partitions MIDI commands between the streams dynamically. The musicport values indicate that the streams share an identity relationship.
我们的第一个会话描述示例显示了两个RTP MIDI流，它们驱动相同的通用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
v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 5004 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100
a=mid:1
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12
m=audio 5006 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100
a=mid:2
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; musicport=12
(The a=fmtp lines have been wrapped to fit the page to accommodate memo formatting restrictions; they comprise single lines in SDP.)
（a=fmtp行已被包装以适合页面，以适应备忘录格式限制；它们包含SDP中的单行。）
Recall that Section 2.1 defines rules for streams that target the same MIDI name space. Those rules, implemented in the example above, require that each stream resides in a separate RTP session and that the grouping mechanisms defined in [RFC5888] signal an inter-session relationship. The "group" and "mid" attribute lines implement this grouping mechanism.
回想一下，第2.1节定义了针对相同MIDI名称空间的流的规则。上述示例中实现的这些规则要求每个流驻留在单独的RTP会话中，并且[RFC5888]中定义的分组机制发出会话间关系的信号。“group”和“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渲染器，每个流具有不同的传输类型。一个流将使用UDP并专用于实时消息。第二个流将使用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.
在下一个示例中，两个mpeg4通用流形成有序关系，以驱动具有32个MIDI语音通道的结构化音频解码器。两个流驻留在同一个RTP会话中。
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5006 RTP/AVP 96 97
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=5
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=6; render=synthetic;
rinit=audio/asc;
url="http://example.com/cardinal.asc";
cid="azsldkaslkdjqpwojdkmsldkfpe"
v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5006 RTP/AVP 96 97
c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=5
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=6; render=synthetic;
rinit=audio/asc;
url="http://example.com/cardinal.asc";
cid="azsldkaslkdjqpwojdkmsldkfpe"
(The a=fmtp lines have been wrapped to fit the page to accommodate memo formatting restrictions; they comprise single lines in SDP.)
（a=fmtp行已被包装以适合页面，以适应备忘录格式限制；它们包含SDP中的单行。）
The sequential musicport values for the two sessions establish the ordered relationship. The musicport=5 session maps to Structured Audio extended channels range 0-15; the musicport=6 session maps to Structured Audio extended channels range 16-31.
两个会话的顺序musicport值建立有序关系。musicport=5会话映射到0-15范围内的结构化音频扩展频道；musicport=6会话映射到16-31范围内的结构化音频扩展频道。
Both config strings are empty. The configuration data is specified by parameters that appear in the fmtp line of the second media description. We define this configuration method in Appendix C.6.
两个配置字符串都为空。配置数据由出现在第二介质描述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).
下一个示例显示了两个RTP MIDI流（一个RecVoOnly，一个sendonly），它们构成了“虚拟sendrecv”会话。每个流驻留在不同的RTP会话中（这是一个要求，因为sendonly和RecvoOnly是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
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.
为了表示“virtual sendrecv”语义，两个流将musicport分配给相同的值（12）。如本节前面所定义的，由不同方发送的身份关系流对共享MIDI电缆对共享的关联，该电缆对交叉连接MIDI 1.0网络中的两个设备。我们使用术语“virtual sendrecv”，因为在真正的sendrecv会话中由不同方发送的流也具有此属性。
As discussed in the preamble to Appendix C, the primary advantage of the virtual sendrecv configuration is that each party can customize the property of the stream it receives. In the example above, each stream defines its own "config" string that could customize the rendering algorithm for each party (in fact, the particular strings shown in this example are identical, because General MIDI is not a configurable MPEG 4 renderer).
如附录C序言所述，虚拟sendrecv配置的主要优点是各方可以自定义其接收的流的属性。在上面的示例中，每个流定义自己的“配置”字符串，该字符串可以为各方自定义渲染算法（事实上，本示例中显示的特定字符串是相同的，因为通用MIDI不是可配置的MPEG 4渲染器）。
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":
render参数指定流的渲染方法。为该参数指定了一个标记值，该标记值表示顶级渲染类。此备忘录为呈现定义了四个标记值：“未知”、“合成”、“api”和“空”：
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通用RTP MIDI流的默认渲染器。
o An "api" renderer presents the command stream to applications via an Application Programming Interface (API).
o “api”渲染器通过应用程序编程接口（api）将命令流呈现给应用程序。
o The "null" renderer discards the MIDI stream.
o “空”渲染器丢弃MIDI流。
The "null" render value plays special roles during Offer/Answer negotiations [RFC3264]. A party uses the "null" value in an answer to reject an offered renderer. Note that rejecting a renderer is independent from rejecting a payload type (coded by removing the payload type from a media line) and rejecting a media stream (coded by zeroing the port of a media line that uses the renderer).
“null”呈现值在报价/应答协商期间起特殊作用[RFC3264]。参与方在应答中使用“null”值拒绝提供的呈现器。请注意，拒绝呈现程序独立于拒绝有效负载类型（通过从媒体线移除有效负载类型进行编码）和拒绝媒体流（通过将使用呈现程序的媒体线端口归零进行编码）。
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。注册必须包括参数值使用的完整规范，其深度与附录C.6中出现的“合成”和“api”渲染值规范类似。如果向参与方提供的会话描述使用了该参与方不知道的渲染令牌值，则该参与方不得接受渲染器。选项包括拒绝呈现程序（使用“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.
其他参数可能在参数列表中的渲染参数之后。附加参数用于定义渲染器的确切性质。例如，subrender参数（在附录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通用流中使用render参数。我们在附录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".
媒体描述可能包含多个渲染参数。默认情况下，如果参数列表包含多个渲染参数，则接收器必须从列表中选择一个渲染器来渲染流。多模参数可用于替代此默认值。我们为多模定义了两个标记值：“一”和“全部”。
o The default "one" value requests rendering by exactly one of the listed renderers.
o 默认“一”值要求仅由一个列出的渲染器进行渲染。
o The "all" value requests the synchronized rendering of the RTP MIDI stream by all listed renderers, if possible.
o 如果可能，“all”值请求所有列出的渲染器同步渲染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]中的“提供”包含具有一个或多个渲染参数的参数列表，则“应答”必须将所有未关闭渲染器的渲染参数设置为“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].
render参数（附录C.6序言）从广义上指定了渲染器对MIDI流的处理方式。在本附录中，我们将介绍subrender参数。指定给子渲染器的标记值定义渲染器的确切性质。因此，render和subrender组合定义渲染器，就像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.
如果“子渲染”参数用于渲染器定义，则它必须立即出现在“参数”列表中的“渲染”参数之后。渲染器定义中最多只能出现一个子渲染参数。
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).
本文档为subrender定义了一个值：值“default”。“default”标记指定流类型（本机或mpeg4通用）的默认呈现器的使用。本机RTP MIDI流的默认渲染器是其性质未指定的渲染器（有关详细信息，请参阅第6.1节第6点）。mpeg4通用RTP MIDI流的默认呈现器是一种MPEG 4音频对象类型，其ID号为13、14或15（有关详细信息，请参阅第6.2节）。
If a renderer definition does not use the subrender parameter, the value "default" is assumed for subrender.
如果渲染器定义不使用subrender参数，则对子渲染假定值“default”。
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
为特定流类型（本机或mpeg4通用）和特定呈现值（不包括“null”和“未知”）注册子呈现值。mpeg4通用子渲染值的注册为
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.
仅限于接受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流与产品或项目软件接口的说明形式。“render=synthetic”注册可以为渲染器指定其他重置状态命令（附录A.1）。
A "render=api" subrender value registration specifies how an RTP MIDI stream interfaces with an API. This specification is usually a pointer to programmer's documentation for the API, perhaps supplemented by RTP-MIDI-specific information.
“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中定义的编码工具在参数列表中对初始化数据对象进行编码（逐字或通过引用）。初始化数据对象必须具有注册的[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).
对于“render=api”渲染器，数据对象通常对api使用的流的数据进行编码（例如，对于钢琴键盘控制器生成的RTP MIDI流，键盘的制造商和型号，用于GUI演示）。
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").
子渲染值注册还可以指定附加参数，以便在子渲染后立即显示在参数列表中。这些参数名称必须以子渲染值开头，后跟一个下划线（“u”），以避免名称空间与将来的RTP MIDI参数名称发生冲突（例如，为子渲染值“foo”定义的参数“foo\u bar”）。
We now specify guidelines for interpreting the subrender parameter during session configuration.
我们现在指定在会话配置期间解释subrender参数的准则。
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.
接收器必须知道由subrender参数指定的渲染器的重置状态命令（附录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参数必须立即出现在subrender参数之后的参数列表中。如果渲染器参数列表不包含子渲染参数（请回忆附录C.6.2中“default”的语义），则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.
如果渲染器使用内联、url和/或cid参数，则这些参数必须紧跟在rinit参数之后。
If a url parameter appears for a renderer, an inline parameter MUST NOT appear. If an inline parameter appears for a renderer, a url parameter MUST NOT appear. However, neither url nor inline is required to appear. If neither url or inline parameters follow rinit, the cid parameter MUST follow rinit.
如果为渲染器显示url参数，则不能显示内联参数。如果为渲染器显示内联参数，则不得显示url参数。但是，不需要显示url或内联。如果url或内联参数都不在rinit之后，则cid参数必须在rinit之后。
The inline parameter supports the inline encoding of the data object. The parameter is assigned a double-quoted Base64 [RFC2045] encoding of the binary data object, with no line breaks. Appendix E.4 shows an example that constructs an inline parameter value.
inline参数支持数据对象的内联编码。该参数被指定为二进制数据对象的双引号Base64[RFC2045]编码，不带换行符。附录E.4显示了构造内联参数值的示例。
The url parameter is assigned a double-quoted string representation of a Uniform Resource Locator (URL) for the data object. The string MUST specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or an HTTP over TLS URI (HTTPS, [RFC2818]). The media type/subtype for the data object SHOULD be specified in the appropriate HTTP or HTTPS transport header.
url参数被指定为数据对象的统一资源定位器（url）的双引号字符串表示形式。字符串必须指定超文本传输协议URI（HTTP[RFC2616]）或HTTP over TLS URI（HTTPS[RFC2818]）。数据对象的媒体类型/子类型应在相应的HTTP或HTTPS传输头中指定。
The cid parameter supports data object caching. The parameter is assigned a double-quoted string value that encodes a globally unique identifier for the data object.
cid参数支持数据对象缓存。为参数分配了一个双引号字符串值，该值对数据对象的全局唯一标识符进行编码。
A cid parameter MAY immediately follow an inline parameter, in which case the cid identifier value MUST be associated with the inline data object.
cid参数可以紧跟在内联参数之后，在这种情况下，cid标识符值必须与内联数据对象相关联。
If a url parameter is present, and if the data object for the URL is expected to be unchanged for the life of the URL, a cid parameter MAY immediately follow the url parameter. The cid identifier value MUST be associated with the data object for the URL. A cid parameter assigned to the same identifier value SHOULD be specified following the data object type/subtype in the appropriate HTTP transport header.
如果存在url参数，并且url的数据对象预期在url的生命周期内保持不变，则url参数后面可能会立即出现cid参数。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.
最后，可以在不使用内联和url参数的情况下使用cid参数。在这种情况下，标识符引用数据对象的本地或分布式目录。
In most cases, only one data object is coded in the parameter list for each renderer. For example, the default renderer for mpeg4-generic streams uses a single data object (see Appendix C.6.5 for example usage).
在大多数情况下，每个渲染器的参数列表中只编码一个数据对象。例如，mpeg4通用流的默认呈现器使用单个数据对象（示例用法见附录C.6.5）。
However, a subrender registration MAY permit the use of multiple data objects for a renderer. If multiple data objects are encoded for a renderer, each object encoding begins with an rinit parameter followed by inline, url, and/or cid parameters.
但是，子渲染器注册可能允许对渲染器使用多个数据对象。如果为渲染器对多个数据对象进行编码，则每个对象编码都以一个rinit参数开始，后跟内联、url和/或cid参数。
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）。默认情况下，RTP MIDI接收器必须忽略封装在数据对象中的SMF。我们在附录C.6.4中定义了覆盖该默认值的参数。
To end this section, we offer guidelines for registering media types for initialization data objects. These guidelines are in addition to the information in [RFC4288].
为了结束本节，我们提供了为初始化数据对象注册媒体类型的指南。这些指南是对[RFC4288]中信息的补充。
Some initialization data objects are also capable of encoding MIDI note information and thus complete audio performances. These objects SHOULD be registered using the audio media type (so that the objects may also be used for store-and-forward rendering) and the "application" media type (to support editing tools). Initialization objects without note storage, or initialization objects for non-audio renderers, SHOULD be registered only for an "application" media type.
一些初始化数据对象还能够编码MIDI音符信息，从而完成音频性能。这些对象应使用音频媒体类型（以便对象也可用于存储和正向渲染）和“应用程序”媒体类型（以支持编辑工具）进行注册。不带注释存储的初始化对象，或非音频渲染器的初始化对象，应仅为“应用程序”媒体类型注册。
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 会话可以定义一个有序关系（附录C.5），该关系向渲染器呈现多个MIDI名称空间。
o A renderer may accept an arbitrary number of MIDI name spaces, or it may expect a specific number of MIDI name spaces.
o 渲染器可以接受任意数量的MIDI名称空间，也可以期望特定数量的MIDI名称空间。
A session description SHOULD provide a compatible MIDI name space to each renderer in the session. If a receiver detects that a session description has too many or too few MIDI name spaces for a renderer, MIDI data from extra stream name spaces MUST be discarded, and extra renderer name spaces MUST NOT be driven with MIDI data (except as described in Appendix C.6.4.1).
会话描述应为会话中的每个渲染器提供兼容的MIDI名称空间。如果接收器检测到会话描述中渲染器的MIDI名称空间过多或过少，则必须丢弃额外流名称空间中的MIDI数据，并且不得使用MIDI数据驱动额外的渲染器名称空间（附录C.6.4.1中描述的除外）。
If a parameter list defines several renderers and assigns the "all" token value to the multimode parameter, the same name space is presented to each renderer. However, the chanmask parameter may be used to mask out selected voice channels to each renderer. We define chanmask and other MIDI management parameters in the subsections below.
如果参数列表定义了多个渲染器，并将“所有”标记值指定给多模式参数，则每个渲染器都会显示相同的名称空间。但是，chanmask参数可用于屏蔽每个渲染器的选定语音通道。我们在下面的小节中定义chanmask和其他MIDI管理参数。
The smf_info parameter defines the use of the SMFs encapsulated in renderer data objects (if any). The smf_info parameter also defines the use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters (defined in Appendix C.6.4.2).
smf_info参数定义了封装在渲染器数据对象（如果有）中的smf的使用。smf_info参数还定义了smf_内联、smf_url和smf_cid参数（定义见附录C.6.4.2）中编码的smf的使用。
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_信息定义了三个令牌值：“忽略”、“sdp_开始”和“标识”：
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 “sdp_start”值代码表示必须呈现SMFs，并且呈现必须在接受会话描述后开始。如果向接收方提供了会话描述，且呈现器使用的smf_info参数设置为“sdp_start”，并且接收方不支持呈现smf，则接收方不得接受与smf_info参数关联的呈现器。选项包括拒绝渲染器（通过将渲染参数设置为“null”）、负载类型、媒体流或整个会话描述。
o The "identity" value indicates that the SMFs code the identity of the renderer. The value is meant for use with the "unknown" renderer (see Appendix C.6 preamble). The MIDI commands coded in the SMF are informational in nature and MUST NOT be presented to a renderer for audio presentation. In typical use, the SMF would use SysEx Identity Reply commands (F0 7E nn 06 02, as defined in [MIDI]) to identify devices and use device-specific SysEx commands to describe the current state of the devices (patch memory contents, etc.).
o “identity”值表示SMFs代码包含渲染器的标识。该值用于“未知”渲染器（见附录C.6前言）。SMF中编码的MIDI命令本质上是信息性的，不能呈现给呈现器进行音频呈现。在典型使用中，SMF将使用SysEx标识回复命令（F0 7E nn 06 02，如[MIDI]中所定义）来识别设备，并使用特定于设备的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_信息令牌值可向IANA注册。令牌值必须符合附录D中定义的渲染令牌的ABNF。注册必须包括参数使用的完整规范，其深度与本附录中出现的“sdp_开始”和“标识”规范类似。
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_信息参数值的会话描述，则该参与方不得接受与smf_信息参数关联的呈现程序。选项包括拒绝呈现器、负载类型、媒体流或整个会话描述。
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是“第一”，哪个是“第二”，等等），请使用以下规则：
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 如果渲染器使用单个数据对象，则SMF在对象内部结构中的出现顺序将定义SMF的顺序（对象中最早的SMF为“第一”，对象中的下一个SMF为“第二”，等等）。
o If multiple data objects are encoded for a renderer, the appearance of each data object in the parameter list sets the relative order of the SMFs encoded in each data object (SMFs encoded in parameters that appear earlier in the list are ordered before SMFs encoded in parameters that appear later in the list).
o 如果为一个渲染器编码了多个数据对象，则参数列表中每个数据对象的外观将设置每个数据对象中编码的SMF的相对顺序（列表中较早出现的参数中编码的SMF的顺序将先于列表中较晚出现的参数中编码的SMF的顺序）。
o If SMFs are encoded in data objects parameters and in the parameters defined in Appendix C.6.4.2, the relative order of the data object parameters and Appendix C.6.4.2 parameters in the parameter list sets the relative order of SMFs (SMFs encoded in parameters that appear earlier in the list are ordered before SMFs in parameters that appear later in the list).
o 如果SMF编码在数据对象参数和附录C.6.4.2中定义的参数中，则参数列表中数据对象参数和附录C.6.4.2参数的相对顺序设置SMF的相对顺序（列表中较早出现的参数中编码的SMF在列表中较晚出现的参数中排序在SMF之前）。
Given this ordering of SMFs, we now define the mapping of SMFs to renderer name spaces. The SMF that appears first for a renderer maps to the first renderer name space. The SMF that appears second for a renderer maps to the second renderer name space, etc. If the associated RTP MIDI streams also form an ordered relationship, the first SMF is merged with the first name space of the relationship, the second SMF is merged to the second name space of the relationship, etc.
考虑到SMF的这种顺序，我们现在定义SMF到渲染器名称空间的映射。渲染器第一个出现的SMF映射到第一个渲染器名称空间。渲染器第二个出现的SMF映射到第二个渲染器名称空间等。如果关联的RTP MIDI流也形成有序关系，则第一个SMF与关系的第一个名称空间合并，第二个SMF与关系的第二个名称空间合并，等等。
Unless the streams and the SMFs both use MIDI Time Code, the time offset between SMF and stream data is unspecified. This restriction limits the use of SMFs to applications where synchronization is not critical, such as the transport of System Exclusive commands for renderer initialization or human-SMF interactivity.
除非流和SMF都使用MIDI时间码，否则SMF和流数据之间的时间偏移是未指定的。此限制将SMF的使用限制在同步不重要的应用程序中，例如传输用于渲染器初始化或人工SMF交互的系统专用命令。
Finally, we note that each SMF in the sdp_start discussion above encodes exactly one MIDI name space (16 voice channels + systems). Thus, the use of the Device Name SMF meta event to specify several MIDI name spaces in an SMF is not supported for sdp_start.
最后，我们注意到上面sdp_start讨论中的每个SMF只编码一个MIDI名称空间（16个语音通道+系统）。因此，sdp_start不支持使用设备名SMF meta事件在SMF中指定多个MIDI名称空间。
In some applications, the renderer data object may not encapsulate SMFs, but an application may wish to use SMFs in the manner defined in Appendix C.6.4.1.
在某些应用程序中，渲染器数据对象可能不封装SMF，但应用程序可能希望以附录C.6.4.1中定义的方式使用SMF。
The smf_inline, smf_url, and smf_cid parameters address this situation. These parameters use the syntax and semantics of the inline, url, and cid parameters defined in Appendix C.6.3, except that the encoded data object is an SMF.
smf_内联、smf_url和smf_cid参数解决了这种情况。这些参数使用附录C.6.3中定义的内联、url和cid参数的语法和语义，但编码数据对象是SMF除外。
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_内联、smf_url和smf_cid参数属于最近在会话描述中位于其前面的呈现参数。smf_内联、smf_url和smf_cid参数不得出现在不使用渲染参数的参数列表中，也不得出现在参数列表中首次使用渲染之前。如果渲染器中出现多个smf_内联、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（对于单个流或标识关系）或16的倍数（对于有序关系）。
The chanmask parameter describes the render parameter that most recently precedes it in the session description; chanmask MUST NOT appear in parameter lists that do not use the render parameter and MUST NOT appear before the first use of render in the parameter list.
chanmask参数描述了最近在会话描述中位于其前面的渲染参数；chanmask不得出现在不使用渲染参数的参数列表中，也不得出现在参数列表中首次使用渲染之前。
The chanmask parameter describes the final MIDI name spaces presented to the renderer. The SMF and stream components of the MIDI name spaces may not be independently masked.
chanmask参数描述呈现给渲染器的最终MIDI名称空间。MIDI名称空间的SMF和流组件不能单独屏蔽。
If a receiver is offered a session description with a renderer that uses the chanmask parameter, and if the receiver does not implement the semantics of the chanmask parameter, the receiver MUST NOT accept the renderer unless the chanmask parameter value contains only "1"s.
如果向接收者提供使用chanmask参数的呈现器的会话描述，并且如果接收者未实现chanmask参数的语义，则接收者不得接受呈现器，除非chanmask参数值仅包含“1”。
In Appendix 11.3, we register the audio/asc media type. The data object for audio/asc is a binary encoding of the AudioSpecificConfig data block used to initialize mpeg4-generic streams (Section 6.2 and [MPEGAUDIO]). Disk files that store this data object use the file extension ".acn".
在附录11.3中，我们注册了音频/asc媒体类型。音频/asc的数据对象是AudioSpecificConfig数据块的二进制编码，用于初始化mpeg4通用流（第6.2节和[MPEGAUDIO]）。存储此数据对象的磁盘文件使用文件扩展名“.acn”。
An mpeg4-generic parameter list MAY use the render, subrender, and rinit parameters with the audio/asc media type for renderer configuration. Several restrictions apply to the use of these parameters in mpeg4-generic parameter lists:
mpeg4通用参数列表可以将render、subrender和rinit参数与音频/asc媒体类型一起用于渲染器配置。在mpeg4通用参数列表中使用这些参数有几个限制：
o An mpeg4-generic media description that uses the render parameter MUST assign the empty string ("") to the mpeg4-generic "config" parameter. The use of the streamtype, mode, and profile-level-id parameters MUST follow the normative text in Section 6.2.
o 使用render参数的mpeg4通用媒体描述必须将空字符串（“”）指定给mpeg4通用“config”参数。streamtype、mode和profile level id参数的使用必须遵循第6.2节中的规范性文本。
o Sessions that use identity or ordered relationships MUST follow the mpeg4-generic configuration restrictions in Appendix C.5.
o 使用标识或有序关系的会话必须遵循附录C.5中的mpeg4通用配置限制。
o The render parameter MUST be assigned the value "synthetic", "unknown", "null", or a render value that has been added to the IANA repository for use with mpeg4-generic RTP MIDI streams. The "api" token value for render MUST NOT be used.
o 必须为render参数指定值“synthetic”、“unknown”、“null”或已添加到IANA存储库中用于mpeg4通用RTP MIDI流的渲染值。不得使用渲染的“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 如果存在子渲染参数，则它必须紧跟在渲染参数之后，并且必须为其分配标记值“default”，或为其分配添加到IANA存储库的子渲染值，以便与mpeg4通用RTP MIDI流一起使用。子渲染器参数指定可能不在渲染器配置中，在这种情况下，子渲染器的隐含值是默认值“default”。
o If the render parameter is assigned the value "synthetic" and the subrender parameter has the value "default" (assigned or implied), the rinit parameter MUST be assigned the value audio/asc, and an AudioSpecificConfig data object MUST be encoded using the mechanisms defined in Appendices C.6.2 and C.6.3. The AudioSpecificConfig data MUST encode one of the MPEG 4 Audio Object Types defined for use with mpeg4-generic in Section 6.2. If the subrender value is other than "default", refer to the subrender registration for information on the use of audio/asc with the renderer.
o 如果为渲染参数指定了“合成”值，且子渲染参数的值为“默认”（指定或暗示），则必须为rinit参数指定值audio/asc，并且必须使用附录C.6.2和C.6.3中定义的机制对AudioSpecificConfig数据对象进行编码。AudioSpecificConfig数据必须对第6.2节中定义的mpeg4通用音频对象类型之一进行编码。如果“子渲染”值不是“默认值”，请参阅“子渲染注册”以了解有关在渲染器中使用音频/asc的信息。
o If the render parameter is assigned the value "null" or "unknown", the data object MAY be omitted.
o 如果为渲染参数指定了值“null”或“unknown”，则可能会忽略数据对象。
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流的语义。因此，音频/asc不得出现在会话描述的rtpmap行上。
Below, we show session description examples for audio/asc. The session description below uses the inline parameter to code the AudioSpecificConfig block for a mpeg4-generic General MIDI stream. We derive the value assigned to the inline parameter in Appendix E.4. The subrender token value of "default" is implied by the absence of the subrender parameter in the parameter list.
下面，我们展示音频/asc的会话描述示例。下面的会话描述使用内联参数为mpeg4通用MIDI流的AudioSpecificConfig块编码。我们推导了附录E.4中内联参数的赋值。参数列表中不存在subrender参数意味着subrender标记值为“default”。
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"
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流编码AudioSpecificConfig块：
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"
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:
在本附录中，我们定义了两个应用领域的互操作性指南：
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 functionalities that all implementations MUST implement.
对于每个应用程序，我们定义了所有实现都必须实现的一组核心功能。
The applications we address in this section are not an exhaustive list of potential RTP MIDI uses. We expect framework documents for other applications to be developed, within the IETF or within other organizations. We discuss other potential application areas for RTP MIDI in Section 1 of the main text of this memo.
我们在本节中介绍的应用程序并不是潜在RTP MIDI用途的详尽列表。我们希望在IETF或其他组织内开发其他应用程序的框架文档。我们将在本备忘录正文的第1节讨论RTP MIDI的其他潜在应用领域。
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服务器发出请求以查看多媒体会话。例如，单击Internet无线频道的网页链接将启动RTSP客户端，该客户端使用链接的RTSP URL与承载无线频道的RTSP服务器联系。
The content may be pre-recorded (for example, on-demand replay of yesterday's football game) or "live" (for example, football game coverage as it occurs), but in either case, the user is usually an "audience member" as opposed to a "participant" (as the user would be in telephony).
内容可以预先录制（例如，按需重播昨天的足球比赛）或“现场”（例如，足球比赛报道），但在这两种情况下，用户通常是“观众成员”，而不是“参与者”（用户在电话中）。
Note that these examples describe the distribution of audio content to an audience member. The interoperability guidelines in this appendix address RTP MIDI applications of this nature, not applications such as the transmission of raw MIDI command streams for use in a professional environment (recording studio, performance stage, etc.).
请注意，这些示例描述了向观众成员分发音频内容的过程。本附录中的互操作性指南针对这种性质的RTP MIDI应用程序，而不是在专业环境（录音室、演出舞台等）中使用的原始MIDI命令流传输等应用程序。
In an RTSP session, a client accesses a session description that is "declared" by the server, either via the RTSP DESCRIBE method or via other means such as HTTP or email. The session description defines the session from the perspective of the client. For example, if a media line in the session description contains a non-zero port number, it encodes the server's preference for the client's port numbers for RTP and RTCP reception. Once media flow begins, the server sends an RTP MIDI stream to the client, which renders it for presentation, perhaps in synchrony with video or other audio streams.
在RTSP会话中，客户端通过RTSP descripe方法或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
客户端必须支持单播UDP RTP MIDI流，该流使用闭环或锚发送策略的恢复日志。客户必须能够解释流子集和章节
inclusion parameters in the session description that qualify the sending policies. Client support of enhanced Chapter C encoding is OPTIONAL.
会话描述中限定发送策略的包含参数。增强的C章编码的客户端支持是可选的。
The reference session description offered by a server MUST send all RTP MIDI UDP streams as unicast streams that use the recovery journal and the closed-loop or anchor sending policies. Servers SHOULD use the stream subsetting and chapter inclusion parameters in the reference session description to simplify the rendering task of the client. Server support of enhanced Chapter C encoding is OPTIONAL.
服务器提供的参考会话描述必须将所有RTP MIDI UDP流作为使用恢复日志和闭环或锚发送策略的单播流发送。服务器应在参考会话描述中使用流子集和章节包含参数，以简化客户端的呈现任务。增强的C章编码的服务器支持是可选的。
Clients and servers MUST support the use of RTSP interleaved mode (a method for interleaving RTP onto the RTSP TCP transport).
客户端和服务器必须支持使用RTSP交错模式（一种将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 all code either the same temporal duration (non-normative example: 50 ms packets) or one of an integral number of temporal durations (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms packets). Servers SHOULD encode information about the packetization method in the rtp_ptime and rtp_maxtime parameters in the session description.
服务器应努力以媒体服务器发送传统音频流的相同方式发送RTP MIDI流：一系列数据包，所有数据包的编码时间要么相同（非标准示例：50毫秒数据包），要么是整数个时间段（非标准示例：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.
客户端必须能够检查render和subrender参数，以确定多媒体会话是否使用其支持的渲染器。客户端必须能够解释multimode参数的默认“one”值，以便从渲染器描述列表中识别支持的渲染器。客户端必须能够解释musicport参数，使其与所支持的渲染器相关。客户端必须能够解释chanmask参数。
Clients supporting renderers whose data object (as encoded by a parameter value for inline) could exceed 300 octets in size MUST support the url and cid parameters and thus must implement the HTTP protocol in addition to RTSP. HTTP over TLS [RFC2818] support for data objects is OPTIONAL.
支持数据对象（由内联参数值编码）大小可能超过300个八位字节的呈现器的客户端必须支持url和cid参数，因此除了RTSP之外，还必须实现HTTP协议。HTTP over TLS[RFC2818]对数据对象的支持是可选的。
Servers MUST specify complete rendering systems for RTP MIDI streams. Note that a minimal RTP MIDI native stream does not meet this requirement (Section 6.1), as the rendering method for such streams is "not specified".
服务器必须为RTP MIDI流指定完整的呈现系统。请注意，最小RTP MIDI本机流不满足此要求（第6.1节），因为此类流的呈现方法“未指定”。
At the time of writing this memo, the only way for servers to specify a complete rendering system is to specify an mpeg4-generic RTP MIDI stream in mode rtp-midi (Section 6.2 and Appendix C.6.5). As a consequence, the only rendering systems that may be presently used are General MIDI [MIDI], DLS 2 [DLS2], or Structured Audio [MPEGSA]. Note that the maximum inline value for General MIDI is well under 300 octets (and thus clients need not support the url parameter) and that the maximum inline values for DLS 2 and Structured Audio may be much larger than 300 octets (and thus clients MUST support the url parameter).
在编写本备忘录时，服务器指定完整渲染系统的唯一方法是在RTP MIDI模式下指定mpeg4通用RTP MIDI流（第6.2节和附录C.6.5）。因此，目前可能使用的唯一渲染系统是通用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_开始值，因为这种使用要求客户端能够解析和呈现标准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通用模式rtp midi通用midi（GM）会话，其复调受客户端硬件能力的限制。这一要求为内容提供商提供了一个“最低公分母”呈现系统。请注意，此要求并不强制非GM渲染器（如DLS 2或结构化音频）的实现者添加第二个渲染引擎。相反，客户机可以通过包括一组实现GM仪器集的语音补丁并将此仿真用于mpeg4通用GM会话来满足要求。
It is RECOMMENDED that servers use General MIDI as the renderer for the reference session description because clients are REQUIRED to support it. We do not require General MIDI as the reference renderer because it is an inappropriate choice for normative applications.
建议服务器使用通用MIDI作为参考会话描述的呈现器，因为需要客户端支持它。我们不需要通用MIDI作为参考渲染器，因为它不适合标准应用程序。
Servers using General MIDI as a "lowest common denominator" renderer SHOULD use Universal Real-Time SysEx Maximum Instantaneous Polyphony (MIP) messages [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
使用通用MIDI作为“最低公分母”渲染器的服务器应使用通用实时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 (NMPs), where musicians in different locations interact over the network as if they were in the same room. See [NMP] for background information on NMP, and see [RFC4696] for a discussion of low-latency RTP MIDI implementation techniques for NMP.
在本附录部分中，我们定义了在交互式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应用程序的目标是远程临场感：双方应听到接近他们在同一房间时所听到的音频。本附录中的互操作性指南针对这种性质的RTP MIDI应用程序，而不是在专业环境（录音室、演出舞台等）中使用的原始MIDI命令流传输等应用程序。
We focus on session management for two-party unicast sessions that specify a renderer for RTP MIDI streams. Within this limited scope, the guidelines defined here are sufficient to let applications interoperate. We define the REQUIRED capabilities of RTP MIDI senders and receivers in NMP sessions and define how session descriptions exchanged are used to set up network musical performance sessions.
我们重点讨论为RTP MIDI流指定渲染器的两方单播会话的会话管理。在这个有限的范围内，这里定义的准则足以让应用程序进行互操作。我们定义了NMP会话中RTP MIDI发送方和接收方所需的功能，并定义了如何使用交换的会话描述来设置网络音乐表演会话。
SIP lets parties negotiate details of the session using the Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many parameters that "blind" negotiations between two parties might not yield a common session configuration.
SIP允许各方使用提供/应答协议[RFC3264]协商会话细节。然而，RTP MIDI有如此多的参数，以至于双方之间的“盲”协商可能不会产生公共会话配置。
Thus, we now define a set of capabilities that NMP parties MUST support. Session description offers whose options lie outside the envelope of REQUIRED party behavior risk negotiation failure. We also define session description idioms that the RTP MIDI part of an offer MUST follow in order to structure the offer for simpler analysis.
因此，我们现在定义了一组NMP各方必须支持的能力。会话描述提供的选项超出了要求方行为风险协商失败的范围。我们还定义了会话描述习惯用法，提供的RTP MIDI部分必须遵循这些习惯用法，以便对提供进行更简单的分析。
We use the term "offerer" for the party making a SIP offer and "answerer" for the party answering the offer. Finally, we note that unless it is qualified by the adjective "sender" or "receiver", a statement that a party MUST support X implies that it MUST support X for both sending and receiving.
我们对发出SIP要约的一方使用术语“要约人”，对答复要约的一方使用术语“应答人”。最后，我们注意到，除非用形容词“发送方”或“接收方”限定，否则一方当事人必须支持X的陈述意味着它必须支持X的发送和接收。
If an offerer wishes to define a "sendrecv" RTP MIDI stream, it may use a true sendrecv session or the "virtual sendrecv" construction described in the preamble to Appendix C and in Appendix C.5. A true sendrecv session indicates that the offerer wishes to participate in a session where both parties use identically configured renderers. A virtual sendrecv session indicates that the offerer is willing to participate in a session where the two parties may be using different renderer configurations. Thus, parties MUST be prepared to see both real and virtual sendrecv sessions in an offer.
如果报价人希望定义“sendrecv”RTP MIDI流，则可以使用附录C序言和附录C.5中描述的真实sendrecv会话或“虚拟sendrecv”构造。true sendrecv会话表示报价人希望参与双方使用相同配置的渲染器的会话。虚拟sendrecv会话表示报价人愿意参与双方可能使用不同渲染器配置的会话。因此，各方必须准备在报价中看到真实和虚拟的sendrecv会话。
Parties MUST support unicast UDP transport of RTP MIDI streams. These streams MUST use the recovery journal with the closed-loop or anchor sending policies. These streams MUST use the stream subsetting and chapter inclusion parameters to declare the types of MIDI commands that will be sent on the stream (for sendonly streams) or will be processed (for recvonly streams), including the size limits on System Exclusive commands. Support of enhanced Chapter C encoding is OPTIONAL.
各方必须支持RTP MIDI流的单播UDP传输。这些流必须将恢复日志与闭环或锚发送策略一起使用。这些流必须使用流子集和章节包含参数来声明将在流上发送（仅发送流）或将被处理（仅接收流）的MIDI命令类型，包括系统独占命令的大小限制。支持增强的C章编码是可选的。
Note that both TCP and multicast UDP support are OPTIONAL. We make TCP OPTIONAL because we expect NMP renderers to rely on data objects (signalled by rinit and associated parameters) for initialization at the start of the session and only to use System Exclusive commands for interactive control during the session. These interactive commands are small enough to be protected via the recovery journal mechanism of RTP MIDI UDP streams.
请注意，TCP和多播UDP支持都是可选的。我们将TCP设置为可选，因为我们希望NMP渲染器在会话开始时依赖数据对象（由rinit和相关参数发出信号）进行初始化，并且在会话期间仅使用系统独占命令进行交互控制。这些交互命令足够小，可以通过RTP MIDI UDP流的恢复日志机制进行保护。
We now discuss timestamps, packet timing, and packet-sending algorithms.
我们现在讨论时间戳、数据包定时和数据包发送算法。
Recall that the tsmode parameter controls the semantics of command timestamps in the MIDI list of RTP packets.
回想一下，tsmode参数控制RTP数据包MIDI列表中命令时间戳的语义。
Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96 kHz. Parties MUST support streams using the "comex", "async", and "buffer" tsmode values. Recvonly offers MUST offer the default "comex".
各方必须支持44.1 kHz、48 kHz、88.2 kHz和96 kHz的时钟频率。各方必须支持使用“comex”、“async”和“buffer”tsmode值的流。Recvonly报价必须提供默认的“comex”。
Parties MUST support a wide range of packet temporal durations: from rtp_ptime and rtp_maxptime values of 0, to rtp_ptime and rtp_maxptime values that code 100 ms. Thus, receivers MUST be able to implement a playout buffer.
各方必须支持广泛的数据包时间持续时间：从rtp_ptime和rtp_maxptime值0到编码为100毫秒的rtp_ptime和rtp_maxptime值。因此，接收器必须能够实现播放缓冲区。
Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime values that support the latency that users would expect in the application, subject to bandwidth constraints. As senders MUST abide by values set for these parameters in a session description, a receiver SHOULD use these values to size its playout buffer to produce the lowest reliable latency for a session. Implementors should refer to [RFC4696] for information on packet-sending algorithms for latency-sensitive applications. Parties MUST be able to implement the semantics of the guardtime parameter for times from 5 ms to 5000 ms.
报价和应答必须提供rtp_ptime、rtp_maxptime和guardtime值，这些值支持用户在应用程序中预期的延迟，并受带宽限制的影响。由于发送方必须遵守会话描述中为这些参数设置的值，接收方应使用这些值调整其播放缓冲区的大小，以产生会话的最低可靠延迟。实施者应参考[RFC4696]了解延迟敏感应用程序的数据包发送算法的信息。各方必须能够在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 of this writing, the only way for parties to specify a complete rendering system is to specify an mpeg4-generic RTP MIDI stream in mode rtp-midi (Section 6.2 and Appendix C.6.5). We anticipate that the owners of rendering systems (both standardized and proprietary) will register subrender values for their renderers. Once IANA registration occurs, native RTP MIDI sessions may use render and subrender (Appendix C.6.2) to specify complete rendering systems for SIP network musical performance multimedia sessions.
在撰写本文时，各方指定完整渲染系统的唯一方法是在RTP MIDI模式下指定mpeg4通用RTP MIDI流（第6.2节和附录C.6.5）。我们预计渲染系统（标准化和专有）的所有者将为其渲染器注册子渲染值。一旦进行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 messages [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
各方必须支持受各方硬件能力限制的复调通用MIDI（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通用会话、DLS 2或结构化音频）的实现者添加第二个渲染引擎。相反，客户机可以通过包括一组实现GM仪器集的语音补丁并将此仿真用于mpeg4通用GM会话来满足要求。我们需要GM的支持，以便希望最大化互操作性的报价人可以在其首选的渲染器未被应答人接受的情况下通过向GM报价来实现互操作性的最大化。
Offerers MUST NOT present several renderers as options in a session description by listing several payload types on a media line, as Section 2.1 uses this construct to let a party send several RTP MIDI streams in the same RTP session.
报价人不得通过在媒体线路上列出几种有效负载类型，在会话描述中以选项的形式呈现多个渲染器，因为第2.1节使用此结构允许一方在同一RTP会话中发送多个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.
相反，希望提供渲染选项的报价人应提供一种可提供多个渲染器的有效负载类型。在此构造中，“参数列表”对渲染参数列表进行编码（每个参数后面跟着其支持参数）。如附录C.6.1所述，列表中呈现者的顺序表明了报价者的偏好。报价中不得出现“未知”和“空”值。答案必须将除所需渲染器之外的所有渲染值设置为“null”。因此，“未知”不能出现在答案中。
We use SHOULD instead of MUST in the first sentence in the paragraph above because this technique does not work in all situations (for example, if an offerer wishes to offer both mpeg4-generic renderers and native RTP MIDI renderers as options). In this case, the offerer MUST present a series of session descriptions, each offering a single renderer, until the answerer accepts a session description.
我们在上面段落的第一句中使用“应该”而不是“必须”，因为这种技术并不适用于所有情况（例如，如果报价人希望同时提供mpeg4通用渲染器和本地RTP MIDI渲染器作为选项）。在这种情况下，报价人必须提供一系列会话描述，每个会话描述提供一个渲染器，直到应答人接受会话描述。
Parties MUST support the musicport, chanmask, subrender, rinit, and inline parameters. Parties supporting renderers whose data object (as encoded by a parameter value for inline) could exceed 300 octets in size MUST support the url and cid parameters and thus must implement the HTTP protocol. HTTP over TLS [RFC2818] support for data objects is OPTIONAL. Note that in mpeg4-generic, General MIDI data objects cannot exceed 300 octets, but DLS 2 and Structured Audio data objects may. Support for the other rendering parameters (smf_cif, smf_info, smf_inline, smf_url) is OPTIONAL.
各方必须支持musicport、chanmask、subrender、rinit和inline参数。支持数据对象（由内联参数值编码）大小可能超过300个八位字节的呈现器的各方必须支持url和cid参数，因此必须实现HTTP协议。HTTP over TLS[RFC2818]对数据对象的支持是可选的。请注意，在mpeg4通用中，一般MIDI数据对象不能超过300个八位字节，但DLS 2和结构化音频数据对象可能会超过300个八位字节。支持其他渲染参数（smf_cif、smf_info、smf_inline、smf_url）是可选的。
Thus far in this document, our discussion has assumed that the only MIDI flows that drive a renderer are the network flows described in the session description. In NMP applications, this assumption would require two rendering engines: one for local use by a party and a second for the remote party.
到目前为止，在本文档中，我们的讨论假设驱动渲染器的唯一MIDI流是会话描述中描述的网络流。在NMP应用程序中，这种假设需要两个渲染引擎：一个用于本地，另一个用于远程。
In practice, applications may wish to have both parties share a single rendering engine. In this case, the session description MUST use a virtual sendrecv session and MUST use the stream subsetting and chapter inclusion parameters to allocate which MIDI channels are intended for use by a party. If two parties are sharing a MIDI channel, the application MUST ensure that appropriate MIDI merging occurs at the input to the renderer.
实际上，应用程序可能希望双方共享一个渲染引擎。在这种情况下，会话描述必须使用虚拟sendrecv会话，并且必须使用流子集和章节包含参数来分配拟由一方使用的MIDI通道。如果双方共享一个MIDI通道，应用程序必须确保在渲染器的输入端发生适当的MIDI合并。
We now discuss the use of (non-MIDI) audio streams in the session.
现在我们讨论在会话中使用（非MIDI）音频流。
Audio streams may be used for two purposes: as a "talkback" channel for parties to converse or as a way to conduct a performance that includes MIDI and audio channels. In the latter case, offers MUST use sample rates and the packet temporal durations for the audio and MIDI streams that support low-latency synchronized rendering.
音频流可用于两个目的：作为双方对话的“对讲”通道，或作为进行包括MIDI和音频通道的表演的方式。在后一种情况下，对于支持低延迟同步渲染的音频和MIDI流，供应商必须使用采样率和数据包时间持续时间。
We now show an example of an offer/answer exchange in a network musical performance application.
我们现在展示一个在网络音乐表演应用程序中提供/应答交换的示例。
Below, we show an offer that complies with the interoperability text in this appendix section.
下面，我们展示了一个符合本附录部分互操作性文本的报价。
v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 16112 RTP/AVP 96
a=recvonly
a=mid:1
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW;
cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2;
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123;
ch_default=2M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit=audio/asc;
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
m=audio 16114 RTP/AVP 96
a=sendonly
a=mid:2
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW;
cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2;
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123;
ch_default=1M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit=audio/asc;
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
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
会话描述定义了两个MIDI流：“first”用于接收性能的recvonly流和“first”用于发送性能的sendonly流。recvonly端口号对“first”希望接收RTP（16112）和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).
（16113）IP4地址为192.0.2.94的介质。sendonly端口号对“first”希望接收流RTCP的端口进行编码（16115）。
The musicport parameters code that the two streams share an identity relationship and thus form a virtual sendrecv stream.
musicport参数编码两个流共享标识关系，从而形成虚拟sendrecv流。
Both streams are mpeg4-generic RTP MIDI streams that specify a General MIDI renderer. The stream subsetting parameters code that the recvonly stream uses MIDI channel 1 exclusively for voice commands and that the sendonly stream uses MIDI channel 2 exclusively for voice commands. This mapping permits the application software to share a single renderer for local and remote performers.
这两个流都是指定通用MIDI渲染器的mpeg4通用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"
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=）将会话所有者标识为“second”。
The port numbers for both media streams are non-zero; thus, "second" has accepted the session description. The stream marked "sendonly" in the offer is marked "recvonly" in the answer and vice versa, coding the different view of the session held by "session". The IP4 number (192.0.2.105), RTP (5004 and 5006), and RTCP (5005 and 5007) have been changed by "second" to match its transport wishes.
两个媒体流的端口号均为非零；因此，“第二个”接受了会话描述。报价中标记为“sendonly”的流在回答中标记为“RecvoOnly”，反之亦然，对“session”持有的会话的不同视图进行编码。IP4编号（192.0.2.105）、RTP（5004和5006）和RTCP（5005和5007）已更改为“秒”，以符合其运输要求。
In addition, "second" has made several parameter changes: rtp_maxptime for the sendonly stream has been changed to code 2 ms (441 in clock units), and the guardtime for the recvonly stream has been doubled. As these parameter modifications request capabilities that are REQUIRED to be implemented by interoperable parties, "second" can make these changes with confidence that "first" can abide by them.
此外，“second”还对几个参数进行了更改：sendonly流的rtp_maxptime已更改为代码2毫秒（时钟单位为441），RecvoOnly流的保护时间已加倍。由于这些参数修改要求互操作方实现所需的功能，“第二方”可以满怀信心地进行这些更改，“第一方”可以遵守这些更改。
In this appendix, we define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form (ABNF, [RFC5234]). When using these parameters with SDP, all parameters MUST appear on a single fmtp attribute line of an RTP MIDI media description. For mpeg4-generic RTP MIDI streams, this line MUST also include any mpeg4-generic parameters (usage described in Section 6.2). An fmtp attribute line may be defined (after [RFC3640]) as:
在本附录中，我们以扩充的Backus Naur形式（ABNF，[RFC5234]）定义RTP MIDI媒体类型参数的语法。在SDP中使用这些参数时，所有参数必须出现在RTP MIDI媒体描述的单个fmtp属性行上。对于mpeg4通用RTP MIDI流，此行还必须包括任何mpeg4通用参数（使用说明见第6.2节）。fmtp属性行可定义为（在[RFC3640]之后）：
;
; SDP fmtp line definition
;
;
; SDP fmtp line definition
;
fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF
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通用参数的语法，请参见[RFC3640]。
;
;
; top-level definition for all parameters
;
;
;
; 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_unused=" (([channel-list] command-type
[f-list]) / sysex-data))
param-assign =/ ("cm_used=" (([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_sec=" ("none" / "recj" / ietf-extension))
param-assign =/ ("j_update=" ("anchor" / "closed-loop" /
"open-loop" / 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_default=" (([channel-list] chapter-list
[f-list]) / sysex-data))
param-assign =/ ("ch_never=" (([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))
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 =/ ("tsmode=" ("comex" / "async" / "buffer"))
param-assign =/ ("linerate=" nonzero-four-octet)
param-assign =/ ("linerate=" nonzero-four-octet)
param-assign =/ ("octpos=" ("first" / "last"))
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(BIT) ))
param-assign =/ ("chanmask=" 1*( 16(BIT) ))
param-assign =/ ("cid=" DQUOTE cid-block DQUOTE)
param-assign =/ ("cid=" DQUOTE cid-block DQUOTE)
param-assign =/ ("inline=" DQUOTE base-64-block DQUOTE)
param-assign =/ ("inline=" DQUOTE base-64-block DQUOTE)
param-assign =/ ("multimode=" ("all" / "one"))
param-assign =/ ("multimode=" ("all" / "one"))
param-assign =/ ("render=" ("synthetic" / "api" / "null" /
"unknown" / extension))
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=" DQUOTE cid-block DQUOTE)
param-assign =/ ("smf_cid=" DQUOTE cid-block DQUOTE)
param-assign =/ ("smf_info=" ("ignore" / "identity" /
"sdp_start" / extension))
param-assign =/ ("smf_info=" ("ignore" / "identity" /
"sdp_start" / extension))
param-assign =/ ("smf_inline=" DQUOTE base-64-block DQUOTE)
param-assign =/ ("smf_inline=" DQUOTE base-64-block DQUOTE)
param-assign =/ ("smf_url=" DQUOTE uri-element DQUOTE)
param-assign =/ ("smf_url=" DQUOTE uri-element DQUOTE)
param-assign =/ ("subrender=" ("default" / extension))
param-assign =/ ("subrender=" ("default" / extension))
param-assign =/ ("url=" DQUOTE uri-element DQUOTE)
param-assign =/ ("url=" DQUOTE uri-element DQUOTE)
;
; list definitions for the cm_ command-type
;
;
; list definitions for the cm_ command-type
;
command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M]
[N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M]
[N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
;
; list definitions for the ch_ chapter-list
;
;
; list definitions for the ch_ chapter-list
;
chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
[M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
[M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
;
; list definitions for the channel-list (used in ch_* / cm_* params)
;
;
; list definitions for the channel-list (used in ch_* / cm_* params)
;
channel-list = midi-chan-element *("." midi-chan-element)
通道列表=midi通道元素*（“.”midi通道元素）
midi-chan-element = midi-chan / midi-chan-range
midi-chan-element = midi-chan / midi-chan-range
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-range = midi-chan "-" midi-chan
;
; Decimal value of left midi-chan
; MUST be strictly less than
; decimal value of right midi-chan.
midi-chan = DIGIT / ("1" %x30-35) ; "0" .. "15"
midi-chan = DIGIT / ("1" %x30-35) ; "0" .. "15"
;
; list definitions for the ch_ field list (f-list)
;
;
; list definitions for the ch_ field list (f-list)
;
f-list = midi-field-element *("." midi-field-element)
f-list=midi字段元素*（“.”midi字段元素）
midi-field-element = midi-field / midi-field-range
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-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), NRPN (16384-32767)
; parameters, and Chapter X octet sizes.
midi-field = four-octet
;
; Large range accommodates Chapter M
; RPN (0-16383), NRPN (16384-32767)
; parameters, and Chapter X octet sizes.
;
; definitions for ch_ sysex-data
;
;
; definitions for ch_ sysex-data
;
sysex-data = "__" h-list *("_" h-list) "__"
sysex-data = "__" h-list *("_" h-list) "__"
h-list = hex-field-element *("." hex-field-element)
h-list=十六进制字段元素*（“.”十六进制字段元素）
hex-field-element = hex-octet / hex-field-range
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-field-range = hex-octet "-" hex-octet
;
; Hexadecimal value of left hex-octet
; MUST be strictly less than hexadecimal
; value of right hex-octet.
hex-octet = %x30-37 U-HEXDIG
;
; Rewritten special case of hex-octet in
; [RFC2045] (page 23).
; Note that a-f are not permitted, only A-F.
; hex-octet values MUST NOT exceed 0x7F.
hex-octet = %x30-37 U-HEXDIG
;
; Rewritten special case of hex-octet in
; [RFC2045] (page 23).
; Note that a-f are not permitted, only A-F.
; hex-octet values MUST NOT exceed 0x7F.
;
; definitions for rinit parameter
;
;
; definitions for rinit parameter
;
mime-type = "audio" / "application"
mime-type = "audio" / "application"
mime-subtype = subtype-name
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.
;
; subtype-name is defined in [RFC4288],
; Section 4.2.
mime-subtype = subtype-name
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.
;
; subtype-name is defined in [RFC4288],
; Section 4.2.
;
; Definitions for base64 encoding
; copied from [RFC4566]
; changes from [RFC4566] to improve automatic syntax checking.
;
;
; Definitions for base64 encoding
; copied from [RFC4566]
; changes from [RFC4566] to improve automatic syntax checking.
;
base-64-block = *base64-unit [base64-pad]
base-64-block = *base64-unit [base64-pad]
base64-unit = 4(base64-char)
base64单位=4（base64字符）
base64-pad = (2(base64-char) "==") / (3(base64-char) "=")
base64-pad = (2(base64-char) "==") / (3(base64-char) "=")
base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/"
; A-Z, a-z, 0-9, "+" and "/"
base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/"
; A-Z, a-z, 0-9, "+" and "/"
;
; generic rules
;
;
; generic rules
;
ietf-extension = token ; ; may only be defined in Standards-Track RFCs
ietf扩展=令牌；只能在标准跟踪RFC中定义
extension = token
;
; may be defined
; by filing a registration with IANA
extension = token
;
; may be defined
; by filing a registration with IANA
nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT))
/ (%x31-33 9(DIGIT))
/ ("4" %x30-31 8(DIGIT))
/ ("42" %x30-38 7(DIGIT))
/ ("429" %x30-33 6(DIGIT))
/ ("4294" %x30-38 5(DIGIT))
/ ("42949" %x30-35 4(DIGIT))
/ ("429496" %x30-36 3(DIGIT))
/ ("4294967" %x30-31 2(DIGIT))
/ ("42949672" %x30-38 (DIGIT))
/ ("429496729" %x30-34)
;
; unsigned encoding of non-zero 32-bit value:
; 1 .. 4294967295
nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT))
/ (%x31-33 9(DIGIT))
/ ("4" %x30-31 8(DIGIT))
/ ("42" %x30-38 7(DIGIT))
/ ("429" %x30-33 6(DIGIT))
/ ("4294" %x30-38 5(DIGIT))
/ ("42949" %x30-35 4(DIGIT))
/ ("429496" %x30-36 3(DIGIT))
/ ("4294967" %x30-31 2(DIGIT))
/ ("42949672" %x30-38 (DIGIT))
/ ("429496729" %x30-34)
;
; unsigned encoding of non-zero 32-bit value:
; 1 .. 4294967295
four-octet = "0" / nonzero-four-octet
;
; unsigned encoding of 32-bit value:
; 0 .. 4294967295
four-octet = "0" / nonzero-four-octet
;
; unsigned encoding of 32-bit value:
; 0 .. 4294967295
uri-element = URI-reference ; as defined in [RFC3986]
uri元素=uri引用；如[RFC3986]中所定义
token = 1*token-char
; copied from [RFC4566]
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]
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
%x30-39 / %x41-5A / %x5E-7E
; copied from [RFC4566]
cid-block = 1*cid-char
cid-block = 1*cid-char
cid-char = token-char
cid-char =/ "@"
cid-char =/ ","
cid-char =/ ";"
cid-char =/ ":"
cid-char =/ "\"
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 DQUOTE and the non-email safe ( ) < >.
; - Note that the definitions above ensure that
; cid-block is always enclosed with DQUOTEs.
cid-char =/ "["
cid-char =/ "]"
cid-char =/ "?"
cid-char =/ "="
;
; - Add back in the tspecials [RFC2045], except
; for DQUOTE and the non-email safe ( ) < >.
; - Note that the definitions above ensure that
; cid-block is always enclosed with DQUOTEs.
A = %x41 ; Uppercase-only letters used above.
B = %x42
C = %x43
D = %x44
E = %x45
F = %x46
G = %x47
H = %x48
J = %x4A
K = %x4B
M = %x4D
N = %x4E
P = %x50
Q = %x51
T = %x54
V = %x56
W = %x57
X = %x58
Y = %x59
Z = %x5A
A = %x41 ; Uppercase-only letters used above.
B = %x42
C = %x43
D = %x44
E = %x45
F = %x46
G = %x47
H = %x48
J = %x4A
K = %x4B
M = %x4D
N = %x4E
P = %x50
Q = %x51
T = %x54
V = %x56
W = %x57
X = %x58
Y = %x59
Z = %x5A
NZ-DIGIT = %x31-39 ; non-zero decimal digit
NZ-DIGIT = %x31-39 ; non-zero decimal digit
U-HEXDIG = DIGIT / A / B / C / D / E / F
; variant of HEXDIG [RFC5234] :
; hexadecimal digit using uppercase A-F only
U-HEXDIG = DIGIT / A / B / C / D / E / F
; variant of HEXDIG [RFC5234] :
; hexadecimal digit using uppercase A-F only
; The rules below are from the Core Rules from [RFC5234].
; 以下规则来自[RFC5234]的核心规则。
BIT = "0" / "1"
BIT = "0" / "1"
DQUOTE = %x22 ; " (Double Quote)
DQUOTE = %x22 ; " (Double Quote)
DIGIT = %x30-39 ; 0-9
DIGIT = %x30-39 ; 0-9
; external references ; URI-reference: from [RFC3986]
; 外部参照；URI参考：来自[RFC3986]
; subtype-name: from [RFC4288]
; 子类型名称：来自[RFC4288]
; ; End of ABNF
; ; ABNF结束
The mpeg4-generic RTP payload [RFC3640] defines a mode parameter that signals the type of MPEG stream in use. We add a new mode value, rtp-midi, using the ABNF rule below:
mpeg4通用RTP有效负载[RFC3640]定义了一个模式参数，该参数表示正在使用的MPEG流的类型。我们使用以下ABNF规则添加一个新的模式值rtp midi：
;
; mpeg4-generic mode parameter extension
;
;
; mpeg4-generic mode parameter extension
;
mode =/ "rtp-midi" ; as described in Section 6.2 of this memo
模式=/“rtp midi”；如本备忘录第6.2节所述
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命令中的位字段具有规则结构和特殊用途。例如，第一个命令八位字节（操作码字段）的上半字节对命令类型进行编码。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 |
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 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 Common Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Exclusive | 11110000, followed by a |
| | list of 0xxxxxx octets, |
| | followed by 11110111 |
|-------------------------------------------------------------|
| MIDI Time Code Quarter Frame | 11110001 0xxxxxxx |
|-------------------------------------------------------------|
| Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| Song Select | 11110011 0xxxxxxx |
|-------------------------------------------------------------|
| Undefined | 11110100 |
|-------------------------------------------------------------|
| Undefined | 11110101 |
|-------------------------------------------------------------|
| Tune Request | 11110110 |
|-------------------------------------------------------------|
| System Exclusive End Marker | 11110111 |
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Real-Time Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Clock | 11111000 |
|-------------------------------------------------------------|
| Undefined | 11111001 |
|-------------------------------------------------------------|
| Start | 11111010 |
|-------------------------------------------------------------|
| Continue | 11111011 |
|-------------------------------------------------------------|
| Stop | 11111100 |
|-------------------------------------------------------------|
| Undefined | 11111101 |
|-------------------------------------------------------------|
| Active Sense | 11111110 |
|-------------------------------------------------------------|
| System Reset | 11111111 |
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Real-Time Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Clock | 11111000 |
|-------------------------------------------------------------|
| Undefined | 11111001 |
|-------------------------------------------------------------|
| Start | 11111010 |
|-------------------------------------------------------------|
| Continue | 11111011 |
|-------------------------------------------------------------|
| Stop | 11111100 |
|-------------------------------------------------------------|
| Undefined | 11111101 |
|-------------------------------------------------------------|
| Active Sense | 11111110 |
|-------------------------------------------------------------|
| System Reset | 11111111 |
-------------------------------------------------------------
Figure E.2 -- MIDI System Messages
图E.2——MIDI系统消息
Figures E.1 and E.2 show the MIDI command family. There are three major classes of commands: voice commands (opcode field values in the range 0x8 through 0xE), System Common commands (opcode field 0xF, commands 0xF0 through 0xF7), and System Real-Time commands (opcode field 0xF, commands 0xF8 through 0xFF). Voice commands code the musical gestures for each timbre in a composition. System commands perform functions that usually affect all voice channels, such as System Reset (0xFF).
图E.1和E.2显示了MIDI命令系列。有三大类命令：语音命令（范围为0x8到0xE的操作码字段值）、系统通用命令（操作码字段0xF、命令0xF0到0xF7）和系统实时命令（操作码字段0xF、命令0xF8到0xFF）。语音命令对乐曲中每个音色的音乐手势进行编码。系统命令执行通常影响所有语音通道的功能，如系统复位（0xFF）。
A voice command executes on one of 16 MIDI channels, as coded by its 4-bit channel field (field cccc in Figure E.1). In most applications, notes for different timbres are assigned to different channels. To support applications that require more than 16 channels, MIDI systems use several MIDI command streams in parallel to yield 32, 48, or 64 MIDI channels.
语音命令在16个MIDI通道之一上执行，由其4位通道字段（图E.1中的cccc字段）编码。在大多数应用中，不同音色的音符分配给不同的通道。为了支持需要16个以上通道的应用程序，MIDI系统并行使用多个MIDI命令流以产生32、48或64个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.
作为语音命令的一个例子，考虑一个记号命令（操作码0x9），二进制编码1001cccc0nnnnn0aaaaaaa.此命令表示MIDI频道cccc上的音符开始。音符的音调由音符编号nnnnn编码，起始振幅由音符速度aaaaaaa编码。
Other voice commands signal the end of notes (NoteOff, opcode 0x8), map a specific timbre to a MIDI channel (PChange, opcode 0xC), or set the value of parameters that modulate the timbral quality (all other voice commands). The exact meaning of most voice channel commands depends on the rendering algorithms the MIDI receiver uses to generate sound. In most applications, a MIDI sender has a model (in some sense) of the rendering method used by the receiver.
其他语音命令发出音符结束信号（NoteOff，操作码0x8），将特定音色映射到MIDI通道（PChange，操作码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时间码四分之一帧命令）的“sequencer”播放控制，以及设备特定数据的通信（系统将显示独占消息）。
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语音命令的第一个八位字节相同，则可能会删除该八位字节。这个规则结合了一个考虑NOTEN命令的NoCon命令作为空指令的第三个八位字节，它支持每个命令使用两个八位字节编码注释序列。
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.
运行状态编码仅用于语音命令。流中出现系统公用消息将取消下一个语音命令的运行状态模式。但是，系统实时消息不会取消运行状态模式。
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文件（SMF，[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中，我们描述了会话描述如何包含AudioSpecificConfig数据块，以指定mpeg4通用RTP MIDI流的MIDI呈现算法。
The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. StructuredAudioSpecificConfig, a key data structure coded in AudioSpecificConfig, is defined in [MPEGSA].
[MPEGAUDIO]中定义了AudioSpecificConfig的位字段格式。StructureAudioSpecificConfig是在AudioSpecificConfig中编码的关键数据结构，在[MPEGSA]中定义。
For implementors wishing to specify Structured Audio renderers, a full understanding of [MPEGSA] and [MPEGAUDIO] is essential. However, many implementors will limit their rendering options to the two MIDI Manufacturers Association (MMA) renderers that may be specified in AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 (DLS 2, [DLS2]).
对于希望指定结构化音频呈现器的实现者来说，充分理解[MPEGSA]和[MPEGAUDIO]是至关重要的。但是，许多实现者将其呈现选项限制为AudioSpecificConfig中指定的两个MIDI制造商协会（MMA）呈现器：通用MIDI（GM，[MIDI]）和可下载声音2（DLS 2，[DLS2]）。
To aid these implementors, we reproduce the AudioSpecificConfig bitfield formats for a GM renderer and a DLS 2 renderer below. We have checked these bitfields carefully and believe they are correct. However, we stress that the material below is informative and that [MPEGAUDIO] and [MPEGSA] are the normative definitions for AudioSpecificConfig.
为了帮助这些实现者，我们为下面的GM渲染器和DLS 2渲染器复制AudioSpecificConfig位字段格式。我们仔细检查了这些位字段，认为它们是正确的。然而，我们强调以下材料是信息性的，[MPEGAUDIO]和[MPEGSA]是AudioSpecificConfig的规范性定义。
As described in Section 6.2, a minimal mpeg4-generic session description encodes the AudioSpecificConfig binary bitfield as a hexadecimal string (whose format is defined in [RFC3640]) that is assigned to the "config" parameter. As described in Appendix C.6.3, a session description that uses the render parameter encodes the AudioSpecificConfig binary bitfield as a Base64-encoded string assigned to the inline parameter or in the body of an HTTP URL assigned to the url parameter.
如第6.2节所述，最小mpeg4通用会话描述将AudioSpecificConfig二进制位字段编码为分配给“config”参数的十六进制字符串（其格式在[RFC3640]中定义）。如附录C.6.3所述，使用呈现参数的会话描述将AudioSpecificConfig二进制位字段编码为分配给内联参数的Base64编码字符串或分配给URL参数的HTTP URL正文。
Below, we show a simplified binary AudioSpecificConfig bitfield format, suitable for sending and receiving GM and DLS 2 data:
下面，我们展示了一种简化的二进制AudioSpecificConfig位域格式，适用于发送和接收GM和DLS 2数据：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
+-+-+
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——简化音频规格配置
The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned integer. The legal values for use with mpeg4-generic RTP MIDI streams are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio). Thus, receivers that do not support all three mpeg4-generic renderers may parse the first 5 bits of an AudioSpecificConfig coded in a session description and reject sessions that specify unsupported renderers.
5位AOTYPE字段将音频对象类型指定为无符号整数。与mpeg4通用RTP MIDI流一起使用的法定值为“15”（通用MIDI）、“14”（DLS 2）和“13”（结构化音频）。因此，不支持所有三个mpeg4通用呈现器的接收器可能解析会话描述中编码的AudioSpecificConfig的前5位，并拒绝指定不支持呈现器的会话。
The 4-bit FREQIDX field specifies the sampling rate of the renderer. We show the mapping of FREQIDX values to sampling rates in Figure E.4. Senders MUST specify a sampling frequency that matches the RTP clock rate, if possible; if not, senders MUST specify the escape value. Receivers MUST consult the RTP clock parameter for the true sampling rate if the escape value is specified.
4位FREQIDX字段指定渲染器的采样率。我们在图E.4中显示了FREQIDX值到采样率的映射。如果可能，发送方必须指定与RTP时钟频率匹配的采样频率；否则，发件人必须指定转义值。如果指定了逸出值，接收器必须参考RTP时钟参数了解真实采样率。
FREQIDX Sampling Frequency
采样频率
0x0 96000 0x1 88200 0x2 64000 0x3 48000 0x4 44100 0x5 32000 0x6 24000 0x7 22050 0x8 16000 0x9 12000 0xa 11025 0xb 8000 0xc reserved 0xd reserved 0xe reserved 0xf escape value
0x0 96000 0x1 88200 0x2 64000 0x3 48000 0x4 44100 0x5 32000 0x6 24000 0x7 22050 0x8 16000 0x9 12000 0xa 11025 0xb 8000 0xc保留0xd保留0xe保留0xf转义值
Figure E.4 -- FreqIdx Encoding
图E.4——频率IDX编码
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.
通道字段后面是一个或多个二进制文件数据块的列表。3位SACNK字段（类StructureAudioSpecificConfig中的chunk_type字段，在[MPEGSA]中定义）指定每个数据块的类型。
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所示：一个32位无符号整数值（file_LEN）编码SMF或RIFF文件中的字节数，然后是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) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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——文件BLK字段格式
Note that several files may follow the CHANNEL field. The "1" constant fields in Figure E.3 code the presence of another file; the "0" constant field codes the end of the list. The final "0" bit in Figure E.3 codes the absence of special coding tools (see [MPEGAUDIO] for details). Senders not using these tools MUST append this "0" bit; receivers that do not understand these coding tools MUST ignore all data following a "1" in this position.
请注意，通道字段后面可能有多个文件。图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.
StructureAudioSpecificConfig位字段结构要求存在一个文件。对于DLS 2的mpeg4通用RTP MIDI使用，文件块必须编码RIFF文件或SMF文件。对于通用MIDI的mpeg4通用RTP MIDI使用，文件块必须编码SMF文件。默认情况下，此SMF将被忽略（附录C.6.4.1）。在此默认情况下，GM StructureAudioSpecificConfig位字段应编码一个文件BLK，其文件长度为0，文件数据为空。
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会话示例中使用的StructureAudioSpecificConfig。参考图E.3，我们注意到对于GM，AOTYPE=15。我们的示例使用44100 Hz的采样率（FREQIDX=4）和单声道（CHANNEL=1）。对于GM，使用图E.6所示的SMF（26字节文件）对单个SMF进行编码（SACNK=2）。
--------------------------------------------
| MIDI File = <Header Chunk> <Track Chunk> |
--------------------------------------------
--------------------------------------------
| 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
<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
<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|
+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1|0 1 0 0|0 0 0 1|0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0|1 0 0 0|0 1 1 0|0 1 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 1|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|0 1 1 1|0 0 1 0|0 1 1 0|1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|1 1 1 1|1 1 1 1|0 0 1 0|1 1 1 1|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|
+-+-+
Figure E.7 -- AudioSpecificConfig Used in GM Examples
图E.7——GM示例中使用的AudioSpecificConfig
Expressing this bitfield as an ASCII hexadecimal string yields:
将此位字段表示为ASCII十六进制字符串将产生：
7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000
7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000
This string is assigned to the "config" parameter in the minimal mpeg4-generic General MIDI examples in this memo (such as the example in Section 6.2). Expressing this string in Base64 [RFC2045] yields:
此字符串分配给本备忘录中最小mpeg4通用MIDI示例中的“config”参数（如第6.2节中的示例）。在Base64[RFC2045]中表示此字符串会产生：
egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA
Egoaaaaaaatvrozaaaaaaaaaaabagbnvhjraaaabgd/LwAA
This string is assigned to the inline parameter in the General MIDI example shown in Appendix C.6.5.
在附录C.6.5所示的通用MIDI示例中，该字符串被指定给内联参数。
References
工具书类
Normative References
规范性引用文件
[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 Detailed Specification", 1996.
[MIDI]MIDI制造商协会。“完整的MIDI 1.0详细规范”，1996年。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年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 36402003年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：会话描述协议”，RFC4566，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，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[DLS2] MIDI Manufacturers Association. "The MIDI Downloadable Sounds Specification", v98.2, 1998.
[DLS2]MIDI制造商协会。“MIDI可下载声音规范”，1998年第98.2版。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]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 37112004年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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RP015] MIDI Manufacturers Association. "Recommended Practice 015 (RP-015): Response to Reset All Controllers", 11/98.
[RP015]MIDI制造商协会。“推荐实施规程015（RP-015）：重置所有控制器的响应”，1998年11月。
[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月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855]Casner，S.，“RTP有效负载格式的媒体类型注册”，RFC 48552007年2月。
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。“网络音乐表演案例”，2001年6月25日至26日在纽约杰斐逊港举行的第11届数字音频和视频网络和操作系统支持国际研讨会（NOSSDAV 2001）。
[GRAME] Fober, D., Orlarey, Y., and S. Letz. "Real Time Musical Events Streaming over Internet", Proceedings of the International Conference on WEB Delivering of Music 2001, pages 147-154.
福伯，D.，奥拉雷，Y.，和S.莱茨。“网上实时音乐活动”，2001年国际音乐网络传播会议记录，第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：会话启动协议”，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）”，RFC2326，1998年4月。
[ALF] Clark, D.D. and D.L. Tennenhouse. "Architectural Considerations for a New Generation of Protocols", SIGCOMM Symposium on Communications Architectures and Protocols, (Philadelphia, Pennsylvania), pp. 200-208, ACM, Sept. 1990.
克拉克，D.D.和D.L.坦恩豪斯。“新一代协议的架构考虑”，SIGCOMM通信架构和协议研讨会（宾夕法尼亚州费城），第200-208页，ACM，1990年9月。
[RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for MIDI", RFC 4695, November 2006.
[RFC4695]Lazzaro，J.和J.Wawrzynek，“MIDI的RTP有效载荷格式”，RFC 4695，2006年11月。
[RFC4696] Lazzaro, J. and J. Wawrzynek, "An Implementation Guide for RTP MIDI", RFC 4696, November 2006.
[RFC4696]Lazzaro，J.和J.Wawrzynek，“RTP MIDI的实施指南”，RFC 46962006年11月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[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.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，2006年7月。
[SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony MIDI, Specification and Device Profiles", Document Version 1.0a, 2002.
[SPMIDI]MIDI制造商协会。“可伸缩复调MIDI，规范和设备配置文件”，文档版本1.0a，2002年。
[LCP] Apple Computer. "Logic 7 Dedicated Control Surface Support", Appendix B. Product manual available from www.apple.com.
[LCP]苹果电脑。“逻辑7专用控制面支架”，附录B。产品手册可从www.apple.com获得。
Authors' Addresses
作者地址
John Lazzaro (corresponding author) UC Berkeley CS Division 315 Soda Hall Berkeley, CA 94720-1776 EMail: lazzaro@cs.berkeley.edu
约翰·拉扎罗（通讯作者）加利福尼亚州伯克利市苏打大厅315号加州伯克利分校计算机科学部94720-1776电子邮件：lazzaro@cs.berkeley.edu
John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley, CA 94720-1776 EMail: johnw@cs.berkeley.edu
John Wawrzynek加州大学伯克利分校CS分部631 Soda Hall Berkeley，CA 94720-1776电子邮件：johnw@cs.berkeley.edu