[要約] RFC 7845は、OpusオーディオコーデックのためのOggカプセル化に関する仕様です。このRFCの目的は、OpusオーディオデータをOggコンテナに効果的に組み込むための方法を提供することです。
Internet Engineering Task Force (IETF) T. Terriberry
Request for Comments: 7845 Mozilla Corporation
Updates: 5334 R. Lee
Category: Standards Track Voicetronix
ISSN: 2070-1721 R. Giles
Mozilla Corporation
April 2016
Ogg Encapsulation for the Opus Audio Codec
OpusオーディオコーデックのOggカプセル化
Abstract
概要
This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream.
このドキュメントでは、Opusインタラクティブ音声およびオーディオコーデックのOggカプセル化を定義します。これにより、Opus形式でエンコードされたデータをOgg論理ビットストリームに格納できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7845.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7845で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Organization . . . . . . . . . . . . . . . . . . . . . 4
4. Granule Position . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Repairing Gaps in Real-Time Streams . . . . . . . . . . . 7
4.2. Pre-skip . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. PCM Sample Position . . . . . . . . . . . . . . . . . . . 9
4.4. End Trimming . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Restrictions on the Initial Granule Position . . . . . . 10
4.6. Seeking and Pre-roll . . . . . . . . . . . . . . . . . . 11
5. Header Packets . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Identification Header . . . . . . . . . . . . . . . . . . 12
5.1.1. Channel Mapping . . . . . . . . . . . . . . . . . . . 16
5.2. Comment Header . . . . . . . . . . . . . . . . . . . . . 22
5.2.1. Tag Definitions . . . . . . . . . . . . . . . . . . . 25
6. Packet Size Limits . . . . . . . . . . . . . . . . . . . . . 26
7. Encoder Guidelines . . . . . . . . . . . . . . . . . . . . . 27
7.1. LPC Extrapolation . . . . . . . . . . . . . . . . . . . . 28
7.2. Continuous Chaining . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. Content Type . . . . . . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
The IETF Opus codec is a low-latency audio codec optimized for both voice and general-purpose audio. See [RFC6716] for technical details. This document defines the encapsulation of Opus in a continuous, logical Ogg bitstream [RFC3533]. Ogg encapsulation provides Opus with a long-term storage format supporting all of the essential features, including metadata, fast and accurate seeking, corruption detection, recapture after errors, low overhead, and the ability to multiplex Opus with other codecs (including video) with minimal buffering. It also provides a live streamable format capable of delivery over a reliable stream-oriented transport, without requiring all the data (or even the total length of the data) up-front, in a form that is identical to the on-disk storage format.
IETF Opusコーデックは、音声と汎用オーディオの両方に最適化された低遅延のオーディオコーデックです。技術的な詳細については、[RFC6716]を参照してください。このドキュメントは、連続した論理的なOggビットストリーム[RFC3533]でのOpusのカプセル化を定義します。 Oggカプセル化は、メタデータ、高速で正確なシーク、破損検出、エラー後の再キャプチャ、低いオーバーヘッド、Opusを他のコーデック（ビデオを含む）と多重化する機能など、すべての重要な機能をサポートする長期保存形式をOpusに提供します最小限のバッファリング。また、オンディスクストレージ形式と同じ形式で、すべてのデータ（またはデータの全長）を前もって要求することなく、信頼性の高いストリーム指向のトランスポートを介して配信できるライブストリーミング可能な形式も提供します。 。
Ogg bitstreams are made up of a series of "pages", each of which contains data from one or more "packets". Pages are the fundamental unit of multiplexing in an Ogg stream. Each page is associated with a particular logical stream and contains a capture pattern and checksum, flags to mark the beginning and end of the logical stream, and a "granule position" that represents an absolute position in the stream, to aid seeking. A single page can contain up to 65,025 octets of packet data from up to 255 different packets. Packets can be split arbitrarily across pages and continued from one page to the next (allowing packets much larger than would fit on a single page). Each page contains "lacing values" that indicate how the data is partitioned into packets, allowing a demultiplexer (demuxer) to recover the packet boundaries without examining the encoded data. A packet is said to "complete" on a page when the page contains the final lacing value corresponding to that packet.
Oggビットストリームは一連の「ページ」で構成され、各ページには1つ以上の「パケット」からのデータが含まれています。ページは、Oggストリームでの多重化の基本単位です。各ページは特定の論理ストリームに関連付けられており、キャプチャパターンとチェックサム、論理ストリームの開始と終了をマークするフラグ、およびストリーム内の絶対位置を表す「グラニュール位置」を含み、シークを支援します。 1つのページには、最大255の異なるパケットからの最大65,025オクテットのパケットデータを含めることができます。パケットはページ間で任意に分割でき、1つのページから次のページに継続できます（単一のページに収まるよりもはるかに大きいパケットを許可します）。各ページには、データがパケットに分割される方法を示す「レーシング値」が含まれています。これにより、デマルチプレクサー（デマルチプレクサー）は、エンコードされたデータを調べることなくパケットの境界を回復できます。ページにそのパケットに対応する最終のレーシング値が含まれている場合、パケットはページ上で「完了」したといいます。
This encapsulation defines the contents of the packet data, including the necessary headers, the organization of those packets into a logical stream, and the interpretation of the codec-specific granule position field. It does not attempt to describe or specify the existing Ogg container format. Readers unfamiliar with the basic concepts mentioned above are encouraged to review the details in [RFC3533].
このカプセル化は、必要なヘッダー、それらのパケットの論理ストリームへの編成、コーデック固有のグラニュルポジションフィールドの解釈など、パケットデータの内容を定義します。既存のOggコンテナー形式を記述または指定することはありません。上記の基本的な概念に慣れていない読者は、[RFC3533]で詳細を確認することをお勧めします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
An Ogg Opus stream is organized as follows (see Figure 1 for an example).
Ogg Opusストリームは次のように構成されています（例については、図1を参照してください）。
Page 0 Pages 1 ... n Pages (n+1) ...
+------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +--
| | | | | | | | | | | | |
|+----------+| |+-----------------+| |+-------------------+ +-----
|||ID Header|| || Comment Header || ||Audio Data Packet 1| | ...
|+----------+| |+-----------------+| |+-------------------+ +-----
| | | | | | | | | | | | |
+------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +--
^ ^ ^
| | |
| | Mandatory Page Break
| |
| ID header is contained on a single page
|
'Beginning Of Stream'
Figure 1: Example Packet Organization for a Logical Ogg Opus Stream
図1：論理Ogg Opusストリームのパケット構成の例
There are two mandatory header packets. The first packet in the logical Ogg bitstream MUST contain the identification (ID) header, which uniquely identifies a stream as Opus audio. The format of this header is defined in Section 5.1. It is placed alone (without any other packet data) on the first page of the logical Ogg bitstream and completes on that page. This page has its 'beginning of stream' flag set.
2つの必須ヘッダーパケットがあります。論理Oggビットストリームの最初のパケットには、Opusオーディオとしてストリームを一意に識別する識別（ID）ヘッダーが含まれている必要があります。このヘッダーのフォーマットは、セクション5.1で定義されています。論理Oggビットストリームの最初のページに単独で（他のパケットデータなしで）配置され、そのページで完了します。このページには、「ストリームの開始」フラグが設定されています。
The second packet in the logical Ogg bitstream MUST contain the comment header, which contains user-supplied metadata. The format of this header is defined in Section 5.2. It MAY span multiple pages, beginning on the second page of the logical stream. However many pages it spans, the comment header packet MUST finish the page on which it completes.
論理Oggビットストリームの2番目のパケットには、ユーザー指定のメタデータを含むコメントヘッダーが含まれている必要があります。このヘッダーのフォーマットはセクション5.2で定義されています。論理ストリームの2ページ目から始めて、複数のページにわたる場合があります。それがまたがるページがいくつあっても、コメントヘッダーパケットはそれが完了するページを終了しなければなりません。
All subsequent pages are audio data pages, and the Ogg packets they contain are audio data packets. Each audio data packet contains one Opus packet for each of N different streams, where N is typically one for mono or stereo, but MAY be greater than one for multichannel audio. The value N is specified in the ID header (see Section 5.1.1), and is fixed over the entire length of the logical Ogg bitstream.
後続のすべてのページはオーディオデータページであり、それらに含まれるOggパケットはオーディオデータパケットです。各オーディオデータパケットには、N個の異なるストリームごとに1つのOpusパケットが含まれます。Nは通常、モノまたはステレオの場合は1ですが、マルチチャネルオーディオの場合は1より大きくてもかまいません。値NはIDヘッダーで指定され（セクション5.1.1を参照）、論理Oggビットストリームの全長にわたって固定されます。
The first (N - 1) Opus packets, if any, are packed one after another into the Ogg packet, using the self-delimiting framing from Appendix B of [RFC6716]. The remaining Opus packet is packed at the end of the Ogg packet using the regular, undelimited framing from Section 3 of [RFC6716]. All of the Opus packets in a single Ogg packet MUST be constrained to have the same duration. An implementation of this specification SHOULD treat any Opus packet whose duration is different from that of the first Opus packet in an Ogg packet as if it were a malformed Opus packet with an invalid Table Of Contents (TOC) sequence.
最初の（N-1）Opusパケットがある場合は、[RFC6716]の付録Bにある自己区切りのフレーミングを使用して、Oggパケットに次々とパックされます。残りのOpusパケットは、[RFC6716]のセクション3の通常の区切られていないフレーミングを使用して、Oggパケットの最後にパックされます。単一のOggパケット内のすべてのOpusパケットは、同じ継続時間を持つように制約する必要があります。この仕様の実装は、Oggパケットの最初のOpusパケットと持続時間が異なるOpusパケットを、無効な目次（TOC）シーケンスを持つ不正なOpusパケットであるかのように処理する必要があります（SHOULD）。
The TOC sequence at the beginning of each Opus packet indicates the coding mode, audio bandwidth, channel count, duration (frame size), and number of frames per packet, as described in Section 3.1 of [RFC6716]. The coding mode is one of SILK, Hybrid, or Constrained Energy Lapped Transform (CELT). The combination of coding mode, audio bandwidth, and frame size is referred to as the configuration of an Opus packet.
[RFC6716]のセクション3.1で説明されているように、各Opusパケットの最初のTOCシーケンスは、コーディングモード、オーディオ帯域幅、チャネル数、継続時間（フレームサイズ）、およびパケットあたりのフレーム数を示します。コーディングモードは、SILK、ハイブリッド、またはConstrained Energy Lapped Transform（CELT）のいずれかです。コーディングモード、オーディオ帯域幅、およびフレームサイズの組み合わせは、Opusパケットの構成と呼ばれます。
Packets are placed into Ogg pages in order until the end of stream. Audio data packets might span page boundaries. The first audio data page could have the 'continued packet' flag set (indicating the first audio data packet is continued from a previous page) if, for example, it was a live stream joined mid-broadcast, with the headers pasted on the front. If a page has the 'continued packet' flag set and one of the following conditions is also true:
パケットはストリームの終わりまで順番にOggページに配置されます。オーディオデータパケットは、ページの境界にまたがることがあります。たとえば、最初のオーディオデータページは、ライブストリームが途中で結合されたライブストリームであり、ヘッダーが前面に貼り付けられている場合、「継続パケット」フラグセット（最初のオーディオデータパケットが前のページから続くことを示す）を持つことができます。 。ページに「継続パケット」フラグが設定されていて、次のいずれかの条件も当てはまる場合：
o the previous page with packet data does not end in a continued packet (does not end with a lacing value of 255) OR
o パケットデータを含む前のページが継続するパケットで終了しない（255のレーシング値で終了しない）または
o the page sequence numbers are not consecutive,
o ページシーケンス番号が連続していない、
then a demuxer MUST NOT attempt to decode the data for the first packet on the page unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. An implementation MUST treat a zero-octet audio data packet as if it were a malformed Opus packet as described in Section 3.4 of [RFC6716].
次に、デマルチプレクサが欠落している部分にもかかわらずこのデータを解釈できるようにする特別な知識がない限り、デマルチプレクサはページの最初のパケットのデータをデコードしようとしてはなりません。 [RFC6716]のセクション3.4で説明されているように、実装はゼロオクテットのオーディオデータパケットを不正なOpusパケットであるかのように処理する必要があります。
A logical stream ends with a page with the 'end of stream' flag set, but implementations need to be prepared to deal with truncated streams that do not have a page marked 'end of stream'. There is no reason for the final packet on the last page to be a continued packet, i.e., for the final lacing value to be 255. However, demuxers might encounter such streams, possibly as the result of a transfer that did not complete or of corruption. If a packet continues onto a subsequent page (i.e., when the page ends with a lacing value of 255) and one of the following conditions is also true:
論理ストリームは「ストリームの終わり」フラグが設定されたページで終了しますが、「ストリームの終わり」とマークされたページを持たない切り捨てられたストリームを処理できるように実装を準備する必要があります。最後のページの最後のパケットが継続するパケットである理由はありません。つまり、最後のレーシング値が255である必要があります。ただし、デマルチプレクサがこのようなストリームに遭遇する可能性があります。腐敗。パケットが後続のページに続く場合（つまり、ページがレーシング値255で終了する場合）、次の条件のいずれかが当てはまる場合：
o the next page with packet data does not have the 'continued packet' flag set, OR
o パケットデータを含む次のページに「継続パケット」フラグが設定されていない、または
o there is no next page with packet data, OR
o パケットデータを含む次のページがない、または
o the page sequence numbers are not consecutive,
o ページシーケンス番号が連続していない、
then a demuxer MUST NOT attempt to decode the data from that packet unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. There MUST NOT be any more pages in an Opus logical bitstream after a page marked 'end of stream'.
次に、デマルチプレクサは、欠落している部分があってもこのデータを解釈できるようにする特別な知識がない限り、そのパケットからデータをデコードしようとしてはなりません（MUST NOT）。 「ストリームの終わり」とマークされたページの後に、Opus論理ビットストリーム内にこれ以上ページがあってはなりません。
The granule position MUST be zero for the ID header page and the page where the comment header completes. That is, the first page in the logical stream and the last header page before the first audio data page both have a granule position of zero.
IDヘッダーページとコメントヘッダーが完了するページのグラニュール位置はゼロでなければなりません。つまり、論理ストリームの最初のページと最初のオーディオデータページの前の最後のヘッダーページは、どちらもグラニュル位置が0です。
The granule position of an audio data page encodes the total number of PCM samples in the stream up to and including the last fully decodable sample from the last packet completed on that page. The granule position of the first audio data page will usually be larger than zero, as described in Section 4.5.
オーディオデータページのグラニュール位置は、そのページで完了した最後のパケットからの完全にデコード可能な最後のサンプルまでの、ストリーム内のPCMサンプルの総数をエンコードします。セクション4.5で説明するように、最初のオーディオデータページのグラニュール位置は通常、ゼロより大きくなります。
A page that is entirely spanned by a single packet (that completes on a subsequent page) has no granule position, and the granule position field is set to the special value '-1' in two's complement.
（次のページで完了する）単一のパケットによって完全にスパンされるページにはグラニュルポジションがなく、グラニュルポジションフィールドは2の補数で特別な値「-1」に設定されます。
The granule position of an audio data page is in units of PCM audio samples at a fixed rate of 48 kHz (per channel; a stereo stream's granule position does not increment at twice the speed of a mono stream). It is possible to run an Opus decoder at other sampling rates, but all Opus packets encode samples at a sampling rate that evenly divides 48 kHz. Therefore, the value in the granule position field always counts samples assuming a 48 kHz decoding rate, and the rest of this specification makes the same assumption.
オーディオデータページのグラニュール位置は、48 kHzの固定レートでのPCMオーディオサンプルの単位です（チャネルごと;ステレオストリームのグラニュール位置は、モノストリームの2倍の速度では増加しません）。 Opusデコーダーを他のサンプリングレートで実行することは可能ですが、すべてのOpusパケットは48 kHzを均等に分割するサンプリングレートでサンプルをエンコードします。したがって、グラニュルポジションフィールドの値は常に48 kHzのデコードレートを想定してサンプルをカウントし、この仕様の残りの部分では同じ想定を行います。
The duration of an Opus packet as defined in [RFC6716] can be any multiple of 2.5 ms, up to a maximum of 120 ms. This duration is encoded in the TOC sequence at the beginning of each packet. The number of samples returned by a decoder corresponds to this duration exactly, even for the first few packets. For example, a 20 ms packet fed to a decoder running at 48 kHz will always return 960 samples. A demuxer can parse the TOC sequence at the beginning of each Ogg packet to work backwards or forwards from a packet with a known granule position (i.e., the last packet completed on some page) in order to assign granule positions to every packet, or even every individual sample. The one exception is the last page in the stream, as described below.
[RFC6716]で定義されているOpusパケットの持続時間は、2.5 msの倍数で、最大120 msです。この期間は、各パケットの先頭にあるTOCシーケンスでエンコードされます。デコーダーによって返されるサンプルの数は、最初の数パケットでも、この期間に正確に対応します。たとえば、48 kHzで実行されているデコーダーに供給された20 msパケットは、常に960サンプルを返します。デマルチプレクサは、各Oggパケットの先頭でTOCシーケンスを解析して、既知のグラニュルポジションのパケット（つまり、あるページで完了した最後のパケット）から後方または前方に動作して、グラニュルポジションをすべてのパケットに割り当てるか、さらには個々のサンプル。以下に説明するように、1つの例外はストリームの最後のページです。
All other pages with completed packets after the first MUST have a granule position equal to the number of samples contained in packets that complete on that page plus the granule position of the most recent page with completed packets. This guarantees that a demuxer can assign individual packets the same granule position when working forwards as when working backwards. For this to work, there cannot be any gaps.
最初の後にパケットが完了した他のすべてのページは、そのページで完了するパケットに含まれるサンプルの数に、完了したパケットがある最新のページのグラニュール位置を加えたものに等しいグラニュル位置を持つ必要があります。これにより、デマルチプレクサが個々のパケットに、順方向と逆方向で作業するときと同じグラニュール位置を割り当てることができることが保証されます。これが機能するために、ギャップはありません。
In order to support capturing a real-time stream that has lost or not transmitted packets, a multiplexer (muxer) SHOULD emit packets that explicitly request the use of Packet Loss Concealment (PLC) in place of the missing packets. Implementations that fail to do so still MUST NOT increment the granule position for a page by anything other than the number of samples contained in packets that actually complete on that page.
パケットが失われた、または送信されなかったリアルタイムストリームのキャプチャをサポートするために、マルチプレクサ（マルチプレクサ）は、失われたパケットの代わりにパケット損失隠蔽（PLC）の使用を明示的に要求するパケットを送信する必要があります（SHOULD）。それができない実装は、実際にそのページで完了するパケットに含まれているサンプルの数以外の何かによってページのグラニュル位置をインクリメントしてはなりません（MUST NOT）。
Only gaps that are a multiple of 2.5 ms are repairable, as these are the only durations that can be created by packet loss or discontinuous transmission. Muxers need not handle other gap sizes. Creating the necessary packets involves synthesizing a TOC byte (defined in Section 3.1 of [RFC6716]) -- and whatever additional internal framing is needed -- to indicate the packet duration for each stream. The actual length of each missing Opus frame inside the packet is zero bytes, as defined in Section 3.2.1 of [RFC6716].
2.5 msの倍数であるギャップのみが修復可能です。これらは、パケット損失または不連続送信によって作成される唯一の期間であるためです。 Muxerは他のギャップサイズを処理する必要はありません。必要なパケットの作成には、TOCバイト（[RFC6716]のセクション3.1で定義されています）の合成と、各ストリームのパケット持続時間を示すために必要な追加の内部フレーミングが含まれます。 [RFC6716]のセクション3.2.1で定義されているように、パケット内の欠落している各Opusフレームの実際の長さは0バイトです。
Zero-byte frames MAY be packed into packets using any of codes 0, 1, 2, or 3. When successive frames have the same configuration, the higher code packings reduce overhead. Likewise, if the TOC configuration matches, the muxer MAY further combine the empty frames with previous or subsequent nonzero-length frames (using code 2 or variable bitrate (VBR) code 3).
ゼロバイトフレームは、コード0、1、2、または3のいずれかを使用してパケットにパックされる場合があります（MAY）。連続するフレームが同じ構成である場合、コードパッキングが高いほどオーバーヘッドが減少します。同様に、TOC構成が一致する場合、マルチプレクサは空のフレームを前または後続のゼロ以外の長さのフレームとさらに結合できます（コード2または可変ビットレート（VBR）コード3を使用）。
[RFC6716] does not impose any requirements on the PLC, but this section outlines choices that are expected to have a positive influence on most PLC implementations, including the reference implementation. Synthesized TOC sequences SHOULD maintain the same mode, audio bandwidth, channel count, and frame size as the previous packet (if any). This is the simplest and usually the most well- tested case for the PLC to handle and it covers all losses that do not include a configuration switch, as defined in Section 4.5 of [RFC6716].
[RFC6716]はPLCに要件を課していませんが、このセクションでは、リファレンス実装を含むほとんどのPLC実装にプラスの影響を与えると予想される選択について概説します。合成されたTOCシーケンスは、前のパケット（存在する場合）と同じモード、オーディオ帯域幅、チャネル数、およびフレームサイズを維持する必要があります（SHOULD）。これは、PLCが処理する最もシンプルで通常最もよくテストされたケースであり、[RFC6716]のセクション4.5で定義されているように、構成スイッチを含まないすべての損失をカバーします。
When a previous packet is available, keeping the audio bandwidth and channel count the same allows the PLC to provide maximum continuity in the concealment data it generates. However, if the size of the gap is not a multiple of the most recent frame size, then the frame size will have to change for at least some frames. Such changes SHOULD be delayed as long as possible to simplify things for PLC implementations.
以前のパケットが使用可能な場合、オーディオ帯域幅とチャネル数を同じに保つことにより、PLCは生成する隠蔽データに最大の連続性を提供できます。ただし、ギャップのサイズが最新のフレームサイズの倍数でない場合は、少なくとも一部のフレームでフレームサイズを変更する必要があります。このような変更は、PLCの実装を簡略化するために、可能な限り遅延させる必要があります。
As an example, a 95 ms gap could be encoded as nineteen 5 ms frames in two bytes with a single constant bitrate (CBR) code 3 packet. If the previous frame size was 20 ms, using four 20 ms frames followed by three 5 ms frames requires 4 bytes (plus an extra byte of Ogg lacing overhead), but allows the PLC to use its well-tested steady state behavior for as long as possible. The total bitrate of the latter approach, including Ogg overhead, is about 0.4 kbps, so the impact on file size is minimal.
例として、95 msのギャップは、単一の固定ビットレート（CBR）コード3パケットで2バイトの19 5 msフレームとしてエンコードできます。以前のフレームサイズが20ミリ秒の場合、4つの20ミリ秒フレームに続いて3つの5ミリ秒フレームを使用するには、4バイト（および追加のOggレーシングオーバーヘッドのバイト）が必要ですが、PLCは十分にテストされた定常状態の動作を長く使用できますできるだけ。 Oggオーバーヘッドを含む、後者のアプローチの合計ビットレートは約0.4 kbpsであるため、ファイルサイズへの影響は最小限です。
Changing modes is discouraged, since this causes some decoder implementations to reset their PLC state. However, SILK and Hybrid mode frames cannot fill gaps that are not a multiple of 10 ms. If switching to CELT mode is needed to match the gap size, a muxer SHOULD do so at the end of the gap to allow the PLC to function for as long as possible.
一部のデコーダーの実装でPLCの状態がリセットされるため、モードの変更はお勧めしません。ただし、SILKおよびハイブリッドモードフレームは、10 msの倍数ではないギャップを埋めることはできません。ギャップサイズを一致させるためにCELTモードへの切り替えが必要な場合、muxerはギャップの最後で実行して、PLCが可能な限り長く機能できるようにする必要があります。
In the example above, if the previous frame was a 20 ms SILK mode frame, the better solution is to synthesize a packet describing four 20 ms SILK frames, followed by a packet with a single 10 ms SILK frame, and finally a packet with a 5 ms CELT frame, to fill the 95 ms gap. This also requires four bytes to describe the synthesized packet data (two bytes for a CBR code 3 and one byte each for two code 0 packets) but three bytes of Ogg lacing overhead are needed to mark the packet boundaries. At 0.6 kbps, this is still a minimal bitrate impact over a naive, low-quality solution.
上記の例で、前のフレームが20 msのSILKモードフレームであった場合、より良い解決策は、4つの20 msのSILKフレームを記述したパケットを合成し、その後に単一の10 msのSILKフレームを含むパケット、最後に95 msのギャップを埋めるための5 ms CELTフレーム。これには、合成パケットデータを記述するために4バイト（CBRコード3の場合は2バイト、2つのコード0パケットの場合はそれぞれ1バイト）も必要ですが、パケット境界をマークするには3バイトのOggレーシングオーバーヘッドが必要です。 0.6 kbpsでも、これは単純で低品質のソリューションに比べてビットレートへの影響は最小限です。
Since medium-band audio is an option only in the SILK mode, wideband frames SHOULD be generated if switching from that configuration to CELT mode, to ensure that any PLC implementation that does try to migrate state between the modes will be able to preserve all of the available audio bandwidth.
中帯域オーディオはSILKモードでのみオプションであるため、その構成からCELTモードに切り替える場合は、ワイドバンドフレームを生成する必要があります。これにより、モード間で状態を移行しようとするPLC実装がすべてのモードを保持できるようになります。利用可能なオーディオ帯域幅。
There is some amount of latency introduced during the decoding process, to allow for overlap in the CELT mode, stereo mixing in the SILK mode, and resampling. The encoder might have introduced additional latency through its own resampling and analysis (though the exact amount is not specified). Therefore, the first few samples produced by the decoder do not correspond to real input audio, but are instead composed of padding inserted by the encoder to compensate for this latency. These samples need to be stored and decoded, as Opus is an asymptotically convergent predictive codec, meaning the decoded contents of each frame depend on the recent history of decoder inputs. However, a player will want to skip these samples after decoding them.
CELTモードでのオーバーラップ、SILKモードでのステレオミキシング、およびリサンプリングを可能にするために、デコードプロセス中にある程度の遅延が発生します。エンコーダーは、独自のリサンプリングと分析によってレイテンシを追加した可能性があります（正確な量は指定されていません）。したがって、デコーダによって生成された最初の数サンプルは実際の入力オーディオに対応していませんが、代わりにエンコーダによって挿入されたパディングで構成され、このレイテンシを補正しています。 Opusは漸近的に収束する予測コーデックであるため、これらのサンプルを保存してデコードする必要があります。つまり、各フレームのデコードされたコンテンツは、デコーダ入力の最近の履歴に依存します。ただし、プレーヤーは、これらのサンプルをデコードした後にスキップする必要があります。
A 'pre-skip' field in the ID header (see Section 5.1) signals the number of samples that SHOULD be skipped (decoded but discarded) at the beginning of the stream, though some specific applications might have a reason for looking at that data. This amount need not be a multiple of 2.5 ms, MAY be smaller than a single packet, or MAY span the contents of several packets. These samples are not valid audio.
IDヘッダーの「事前スキップ」フィールド（セクション5.1を参照）は、ストリームの先頭でスキップする必要があるサンプル数を示します（デコードされますが破棄されます）。ただし、特定のアプリケーションによっては、そのデータを見る理由がある場合があります。 。この量は、2.5 msの倍数である必要はありません。単一のパケットよりも小さい場合があります。または、複数のパケットのコンテンツにまたがる場合があります。これらのサンプルは有効なオーディオではありません。
For example, if the first Opus frame uses the CELT mode, it will always produce 120 samples of windowed overlap-add data. However, the overlap data is initially all zeros (since there is no prior frame), meaning this cannot, in general, accurately represent the original audio. The SILK mode requires additional delay to account for its analysis and resampling latency. The encoder delays the original audio to avoid this problem.
たとえば、最初のOpusフレームがCELTモードを使用する場合、ウィンドウ処理されたオーバーラップ加算データのサンプルは常に120になります。ただし、オーバーラップデータは最初はすべてゼロです（前のフレームがないため）。これは、通常、元のオーディオを正確に表すことができないことを意味します。 SILKモードでは、その分析とリサンプリング遅延を考慮するために追加の遅延が必要です。エンコーダは、この問題を回避するために元のオーディオを遅延させます。
The 'pre-skip' field MAY also be used to perform sample-accurate cropping of already encoded streams. In this case, a value of at least 3840 samples (80 ms) provides sufficient history to the decoder that it will have converged before the stream's output begins.
「事前スキップ」フィールドは、すでにエンコードされたストリームのサンプル正確なクロッピングを実行するためにも使用できます（MAY）。この場合、少なくとも3840サンプル（80 ms）の値は、ストリームの出力が開始する前に収束する十分な履歴をデコーダーに提供します。
The PCM sample position is determined from the granule position using the following formula:
PCMサンプルの位置は、次の式を使用してグラニュールの位置から決定されます。
'PCM sample position' = 'granule position' - 'pre-skip'
'PCMサンプル位置' = 'グラニュール位置'-'事前スキップ'
For example, if the granule position of the first audio data page is 59,971, and the pre-skip is 11,971, then the PCM sample position of the last decoded sample from that page is 48,000.
たとえば、最初のオーディオデータページのグラニュール位置が59,971で、プレスキップが11,971の場合、そのページから最後にデコードされたサンプルのPCMサンプル位置は48,000です。
This can be converted into a playback time using the following formula:
これは、次の式を使用して再生時間に変換できます。
'PCM sample position'
'playback time' = ---------------------
48000.0
The initial PCM sample position before any samples are played is normally '0'. In this case, the PCM sample position of the first audio sample to be played starts at '1', because it marks the time on the clock _after_ that sample has been played, and a stream that is exactly one second long has a final PCM sample position of '48000', as in the example here.
サンプルが再生される前の最初のPCMサンプル位置は通常「0」です。この場合、最初に再生されるオーディオサンプルのPCMサンプル位置は「1」から始まります。これは、サンプルが再生された後のクロックの時間をマークし、正確に1秒の長さのストリームに最終的なPCMがあるためです。この例のように、「48000」のサンプル位置。
Vorbis streams use a granule position smaller than the number of audio samples contained in the first audio data page to indicate that some of those samples are trimmed from the output (see [Appendix A: Embedding Vorbis into an Ogg stream"">VORBIS-TRIM]). However, to do so, Vorbis requires that the first audio data page contains exactly two packets, in order to allow the decoder to perform PCM position adjustments before needing to return any PCM data. Opus uses the pre-skip mechanism for this purpose instead, since the encoder might introduce more than a single packet's worth of latency, and since very large packets in streams with a very large number of channels might not fit on a single page.
Vorbisストリームは、最初のオーディオデータページに含まれるオーディオサンプルの数よりも小さいグラニュール位置を使用して、それらのサンプルの一部が出力からトリミングされていることを示します（[付録A：VorbisをOggストリームに埋め込む] "> VORBIS-TRIMを参照してください]）。ただし、そのためには、デコーダーがPCMデータを返す前にPCM位置調整を実行できるようにするために、Vorbisは最初のオーディオデータページに正確に2つのパケットを含める必要があります。 Opusは代わりにこの目的でプリスキップメカニズムを使用します。これは、エンコーダーが複数のパケットに相当するレイテンシをもたらす可能性があり、非常に多数のチャネルを持つストリームの非常に大きなパケットが1つのページに収まらない可能性があるためです。
The page with the 'end of stream' flag set MAY have a granule position that indicates the page contains less audio data than would normally be returned by decoding up through the final packet. This is used to end the stream somewhere other than an even frame boundary. The granule position of the most recent audio data page with completed packets is used to make this determination, or '0' is used if there were no previous audio data pages with a completed packet. The difference between these granule positions indicates how many samples to keep after decoding the packets that completed on the final page. The remaining samples are discarded. The number of discarded samples SHOULD be no larger than the number decoded from the last packet.
「ストリームの終わり」フラグが設定されたページには、最終的なパケットをデコードすることによって通常返されるよりも少ないオーディオデータがページに含まれていることを示す細かい位置がある場合があります。これは、ストリームを偶数フレーム境界以外の場所で終了するために使用されます。パケットが完了した最新のオーディオデータページのグラニュール位置を使用してこの決定が行われます。完了したパケットを持つ以前のオーディオデータページがなかった場合は「0」が使用されます。これらのグラニュルの位置の違いは、最終ページで完了したパケットをデコードした後に保持するサンプル数を示しています。残りのサンプルは破棄されます。破棄されたサンプルの数は、最後のパケットからデコードされた数以下でなければなりません。
The granule position of the first audio data page with a completed packet MAY be larger than the number of samples contained in packets that complete on that page. However, it MUST NOT be smaller, unless that page has the 'end of stream' flag set. Allowing a granule position larger than the number of samples allows the beginning of a stream to be cropped or a live stream to be joined without rewriting the granule position of all the remaining pages. This means that the PCM sample position just before the first sample to be played MAY be larger than '0'. Synchronization when multiplexing with other logical streams still uses the PCM sample position relative to '0' to compute sample times. This does not affect the behavior of pre-skip: exactly 'pre-skip' samples SHOULD be skipped from the beginning of the decoded output, even if the initial PCM sample position is greater than zero.
完了したパケットを含む最初のオーディオデータページのグラニュール位置は、そのページで完了するパケットに含まれるサンプルの数よりも大きい場合があります。ただし、そのページに「ストリームの終わり」フラグが設定されていない限り、それより小さくすることはできません。サンプル数よりも大きいグラニュール位置を許可すると、残りのすべてのページのグラニュール位置を書き換えることなく、ストリームの開始をクロップしたり、ライブストリームを結合したりできます。これは、最初に再生されるサンプルの直前のPCMサンプルの位置が「0」より大きい場合があることを意味します。他の論理ストリームと多重化するときの同期は、サンプル時間を計算するために、 '0'に対するPCMサンプル位置を使用します。これは事前スキップの動作には影響しません。たとえ初期のPCMサンプル位置がゼロより大きい場合でも、正確に「事前スキップ」サンプルはデコードされた出力の最初からスキップする必要があります。
On the other hand, a granule position that is smaller than the number of decoded samples prevents a demuxer from working backwards to assign each packet or each individual sample a valid granule position, since granule positions are non-negative. An implementation MUST treat any stream as invalid if the granule position is smaller than the number of samples contained in packets that complete on the first audio data page with a completed packet, unless that page has the 'end of stream' flag set. It MAY defer this action until it decodes the last packet completed on that page.
一方、デコードされたサンプルの数よりも小さいグラニュールの位置は、デマルチプレクサが逆方向に動作して、各パケットまたは各個別のサンプルに有効なグラニュールの位置を割り当てるのを防ぎます。そのページに「ストリームの終わり」フラグが設定されていない限り、グラニュールの位置が、完了したパケットを含む最初のオーディオデータページで完了するパケットに含まれるサンプル数よりも小さい場合、実装はストリームを無効として扱う必要があります。そのページで完了した最後のパケットをデコードするまで、このアクションを延期する場合があります。
If that page has the 'end of stream' flag set, a demuxer MUST treat any stream as invalid if its granule position is smaller than the 'pre-skip' amount. This would indicate that there are more samples to be skipped from the initial decoded output than exist in the stream. If the granule position is smaller than the number of decoded samples produced by the packets that complete on that page, then a demuxer MUST use an initial granule position of '0', and can work forwards from '0' to timestamp individual packets. If the granule position is larger than the number of decoded samples available, then the demuxer MUST still work backwards as described above, even if the 'end of stream' flag is set, to determine the initial granule position, and thus the initial PCM sample position. Both of these will be greater than '0' in this case.
そのページに「ストリームの終了」フラグが設定されている場合、デマルチプレクサは、そのグラニュル位置が「スキップ前」の量よりも小さい場合、ストリームを無効として処理する必要があります。これは、ストリームに存在するよりも多くのサンプルが、最初のデコードされた出力からスキップされることを示します。グラニュールの位置が、そのページで完了するパケットによって生成されたデコード済みサンプルの数よりも小さい場合、デマルチプレクサは「0」の初期グラニュールの位置を使用する必要があり、「0」から順方向に動作して個々のパケットにタイムスタンプを付けることができます。グラニュールの位置が使用可能なデコード済みサンプルの数よりも大きい場合、デマルチプレクサは、「ストリームの終わり」フラグが設定されている場合でも、最初のグラニュールの位置、つまり最初のPCMサンプルを決定するために、上記のように逆方向に動作する必要がありますポジション。この場合、これらの両方が「0」より大きくなります。
Seeking in Ogg files is best performed using a bisection search for a page whose granule position corresponds to a PCM position at or before the seek target. With appropriately weighted bisection, accurate seeking can be performed in just one or two bisections on average, even in multi-gigabyte files. See [SEEKING] for an example of general implementation guidance.
Oggファイルのシークは、グラニュールの位置がシークターゲットまたはその前のPCM位置に対応するページの二分検索を使用して行うのが最適です。適切に重み付けされた二分法を使用すると、数ギガバイトのファイルであっても、平均して1つまたは2つの二分法で正確なシークを実行できます。一般的な実装ガイダンスの例については、[検索]を参照してください。
When seeking within an Ogg Opus stream, an implementation SHOULD start decoding (and discarding the output) at least 3840 samples (80 ms) prior to the seek target in order to ensure that the output audio is correct by the time it reaches the seek target. This "pre-roll" is separate from, and unrelated to, the pre-skip used at the beginning of the stream. If the point 80 ms prior to the seek target comes before the initial PCM sample position, an implementation SHOULD start decoding from the beginning of the stream, applying pre-skip as normal, regardless of whether the pre-skip is larger or smaller than 80 ms, and then continue to discard samples to reach the seek target (if any).
Ogg Opusストリーム内でシークする場合、実装は、シークターゲットに到達するまでに出力オーディオが正しいことを確認するために、シークターゲットの少なくとも3840サンプル（80ミリ秒）前にデコード（および出力の破棄）を開始する必要があります（SHOULD）。 。この「プレロール」は、ストリームの先頭で使用されるプレスキップとは別のものであり、無関係です。シークターゲットの80ミリ秒前のポイントが初期PCMサンプル位置の前にある場合、実装は、プレスキップが80より大きいか小さいかに関係なく、通常のようにプレスキップを適用して、ストリームの先頭からデコードを開始する必要があります（SHOULD）。 ms、その後、サンプルを破棄してシークターゲット（存在する場合）に到達します。
An Ogg Opus logical stream contains exactly two mandatory header packets: an identification header and a comment header.
Ogg Opus論理ストリームには、識別ヘッダーとコメントヘッダーという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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'O' | 'p' | 'u' | 's' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'H' | 'e' | 'a' | 'd' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 | Channel Count | Pre-skip |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Sample Rate (Hz) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Gain (Q7.8 in dB) | Mapping Family| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| |
: Optional Channel Mapping Table... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ID Header Packet
図2：IDヘッダーパケット
The fields in the identification (ID) header have the following meaning:
識別（ID）ヘッダーのフィールドには次の意味があります。
1. Magic Signature:
1. 魔法の署名：
This is an 8-octet (64-bit) field that allows codec identification and is human readable. It contains, in order, the magic numbers:
これは、8オクテット（64ビット）のフィールドであり、コーデックの識別を可能にし、人間が読み取り可能です。順番に、マジックナンバーが含まれています。
0x4F 'O'
0x4F 'O'
0x70 'p'
0x70 'p'
0x75 'u' 0x73 's'
0x75 'u' 0x73 's'
0x48 'H'
0x48 'H'
0x65 'e'
0x65 'e'
0x61 'a'
0x61 'a'
0x64 'd'
0x64 'd'
Starting with "Op" helps distinguish it from audio data packets, as this is an invalid TOC sequence.
これは無効なTOCシーケンスであるため、「Op」で開始すると、オーディオデータパケットとの区別に役立ちます。
2. Version (8 bits, unsigned):
2. バージョン（8ビット、符号なし）：
The version number MUST always be '1' for this version of the encapsulation specification. Implementations SHOULD treat streams where the upper four bits of the version number match that of a recognized specification as backwards compatible with that specification. That is, the version number can be split into "major" and "minor" version sub-fields, with changes to the minor sub-field (in the lower four bits) signaling compatible changes. For example, an implementation of this specification SHOULD accept any stream with a version number of '15' or less, and SHOULD assume any stream with a version number '16' or greater is incompatible. The initial version '1' was chosen to keep implementations from relying on this octet as a null terminator for the "OpusHead" string.
このバージョンのカプセル化仕様では、バージョン番号は常に「1」である必要があります。実装は、バージョン番号の上位4ビットが認識された仕様のそれと一致するストリームを、その仕様との下位互換性があるものとして扱う必要があります（SHOULD）。つまり、バージョン番号を「メジャー」および「マイナー」バージョンのサブフィールドに分割し、（下位4ビットの）マイナーサブフィールドを変更すると、互換性のある変更を通知できます。たとえば、この仕様の実装は、バージョン番号が「15」以下のストリームを受け入れる必要があり（SHOULD）、バージョン番号が「16」以上のストリームは互換性がないと想定する必要があります（SHOULD）。初期バージョン「1」は、実装がこのオクテットを「OpusHead」文字列のnullターミネータとして依存しないようにするために選択されました。
3. Output Channel Count 'C' (8 bits, unsigned):
3. 出力チャネル数 'C'（8ビット、符号なし）：
This is the number of output channels. This might be different than the number of encoded channels, which can change on a packet-by-packet basis. This value MUST NOT be zero. The maximum allowable value depends on the channel mapping family, and might be as large as 255. See Section 5.1.1 for details.
これは出力チャネルの数です。これは、パケットごとに変化する可能性があるエンコードされたチャネルの数とは異なる場合があります。この値はゼロであってはなりません。最大許容値はチャネルマッピングファミリによって異なり、最大255になる場合があります。詳細については、セクション5.1.1を参照してください。
4. Pre-skip (16 bits, unsigned, little endian):
4. プリスキップ（16ビット、符号なし、リトルエンディアン）：
This is the number of samples (at 48 kHz) to discard from the decoder output when starting playback, and also the number to subtract from a page's granule position to calculate its PCM sample position. When cropping the beginning of existing Ogg Opus streams, a pre-skip of at least 3,840 samples (80 ms) is RECOMMENDED to ensure complete convergence in the decoder.
これは、再生の開始時にデコーダー出力から破棄する（48 kHzでの）サンプル数であり、ページのグラニュル位置から差し引いてPCMサンプル位置を計算する数でもあります。既存のOgg Opusストリームの先頭をクロップする場合、デコーダーでの完全な収束を保証するために、少なくとも3,840サンプル（80 ms）の事前スキップが推奨されます。
5. Input Sample Rate (32 bits, unsigned, little endian):
5. 入力サンプルレート（32ビット、符号なし、リトルエンディアン）：
This is the sample rate of the original input (before encoding), in Hz. This field is _not_ the sample rate to use for playback of the encoded data.
これは、元の入力（エンコード前）のサンプルレート（Hz）です。このフィールドは、エンコードされたデータの再生に使用するサンプルレートではありません。
Opus can switch between internal audio bandwidths of 4, 6, 8, 12, and 20 kHz. Each packet in the stream can have a different audio bandwidth. Regardless of the audio bandwidth, the reference decoder supports decoding any stream at a sample rate of 8, 12, 16, 24, or 48 kHz. The original sample rate of the audio passed to the encoder is not preserved by the lossy compression.
Opusは、4、6、8、12、および20 kHzの内部オーディオ帯域幅を切り替えることができます。ストリームの各パケットは、異なるオーディオ帯域幅を持つことができます。オーディオ帯域幅に関係なく、リファレンスデコーダーは、8、12、16、24、または48 kHzのサンプルレートでのストリームのデコードをサポートします。エンコーダに渡されるオーディオの元のサンプルレートは、不可逆圧縮では保持されません。
An Ogg Opus player SHOULD select the playback sample rate according to the following procedure:
Ogg Opusプレーヤーは、次の手順に従って再生サンプルレートを選択する必要があります。
1. If the hardware supports 48 kHz playback, decode at 48 kHz.
1. ハードウェアが48 kHzの再生をサポートしている場合は、48 kHzでデコードします。
2. Otherwise, if the hardware's highest available sample rate is a supported rate, decode at this sample rate.
2. それ以外の場合、ハードウェアの利用可能な最高のサンプルレートがサポートされているレートである場合は、このサンプルレートでデコードします。
3. Otherwise, if the hardware's highest available sample rate is less than 48 kHz, decode at the next higher Opus supported rate above the highest available hardware rate and resample.
3. それ以外の場合、ハードウェアの利用可能な最高のサンプルレートが48 kHz未満の場合は、利用可能な最高のハードウェアレートよりも次に高いOpusサポートレートでデコードし、リサンプリングします。
4. Otherwise, decode at 48 kHz and resample.
4. それ以外の場合は、48 kHzでデコードしてリサンプリングします。
However, the 'input sample rate' field allows the muxer to pass the sample rate of the original input stream as metadata. This is useful when the user requires the output sample rate to match the input sample rate. For example, when not playing the output, an implementation writing PCM format samples to disk might choose to resample the audio back to the original input sample rate to reduce surprise to the user, who might reasonably expect to get back a file with the same sample rate.
ただし、「入力サンプルレート」フィールドを使用すると、マルチプレクサは元の入力ストリームのサンプルレートをメタデータとして渡すことができます。これは、ユーザーが出力サンプルレートを入力サンプルレートと一致させる必要がある場合に役立ちます。たとえば、出力を再生しない場合、PCM形式のサンプルをディスクに書き込む実装は、オーディオを元の入力サンプルレートに再サンプリングして、同じサンプルのファイルを返すことを合理的に期待するユーザーへの驚きを減らすことを選択できます。割合。
A value of zero indicates "unspecified". Muxers SHOULD write the actual input sample rate or zero, but implementations that do something with this field SHOULD take care to behave sanely if given crazy values (e.g., do not actually upsample the output to 10 MHz if requested). Implementations SHOULD support input sample rates between 8 kHz and 192 kHz (inclusive). Rates outside this range MAY be ignored by falling back to the default rate of 48 kHz instead.
ゼロの値は「未指定」を示します。マクサーは実際の入力サンプルレートまたはゼロを書き込む必要があります（SHOULD）が、このフィールドを使用して何かを実行する実装は、異常な値が指定された場合は正常に動作するように注意する必要があります（たとえば、要求された場合に実際に出力を10 MHzにアップサンプリングしないでください）。実装は、8 kHzから192 kHzまでの入力サンプルレートをサポートする必要があります（両端を含む）。この範囲外のレートは、代わりにデフォルトのレートである48 kHzにフォールバックすることで無視される場合があります。
6. Output Gain (16 bits, signed, little endian):
6. 出力ゲイン（16ビット、符号付き、リトルエンディアン）：
This is a gain to be applied when decoding. It is 20*log10 of the factor by which to scale the decoder output to achieve the desired playback volume, stored in a 16-bit, signed, two's complement fixed-point value with 8 fractional bits (i.e., Q7.8 [Q-NOTATION]).
これは、デコード時に適用されるゲインです。これは、デコーダー出力をスケーリングして目的の再生ボリュームを実現するための係数の20 * log10であり、8ビットの小数ビットを使用して16ビットの符号付き2の補数の固定小数点値に格納されます（つまり、Q7.8 [Q-表記]）。
To apply the gain, an implementation could use the following:
ゲインを適用するために、実装では以下を使用できます。
sample *= pow(10, output_gain/(20.0*256))
where 'output_gain' is the raw 16-bit value from the header.
ここで、「output_gain」はヘッダーからの生の16ビット値です。
Players and media frameworks SHOULD apply it by default. If a player chooses to apply any volume adjustment or gain modification, such as the R128_TRACK_GAIN (see Section 5.2), the adjustment MUST be applied in addition to this output gain in order to achieve playback at the normalized volume.
プレーヤーとメディアフレームワークは、デフォルトで適用する必要があります。プレーヤーがR128_TRACK_GAIN（セクション5.2を参照）などのボリューム調整またはゲイン変更の適用を選択した場合、正規化されたボリュームでの再生を実現するには、この出力ゲインに加えて調整を適用する必要があります。
A muxer SHOULD set this field to zero, and instead apply any gain prior to encoding, when this is possible and does not conflict with the user's wishes. A nonzero output gain indicates the gain was adjusted after encoding, or that a user wished to adjust the gain for playback while preserving the ability to recover the original signal amplitude.
マクサーは、このフィールドをゼロに設定する必要があり（SHOULD）、これが可能でユーザーの希望と競合しない場合は、エンコードの前にゲインを適用します。ゼロ以外の出力ゲインは、エンコード後にゲインが調整されたこと、またはユーザーが元の信号振幅を回復する機能を維持しながら、再生用のゲインを調整したかったことを示します。
Although the output gain has enormous range (+/- 128 dB, enough to amplify inaudible sounds to the threshold of physical pain), most applications can only reasonably use a small portion of this range around zero. The large range serves in part to ensure that gain can always be losslessly transferred between OpusHead and R128 gain tags (see below) without saturating.
出力ゲインの範囲は非常に広い（+/- 128 dB、耳に聞こえない音を物理的な痛みのしきい値まで増幅するのに十分）が、ほとんどのアプリケーションでは、この範囲のごく一部のみを使用できます。広い範囲は、飽和することなく、OpusHeadとR128ゲインタグ（下記を参照）の間でゲインを常にロスレスで転送できることを保証するためにも役立ちます。
7. Channel Mapping Family (8 bits, unsigned):
7. チャネルマッピングファミリ（8ビット、符号なし）：
This octet indicates the order and semantic meaning of the output channels.
このオクテットは、出力チャネルの順序と意味の意味を示します。
Each currently specified value of this octet indicates a mapping family, which defines a set of allowed channel counts, and the ordered set of channel names for each allowed channel count. The details are described in Section 5.1.1.
このオクテットの現在指定されている各値は、許可されたチャネルカウントのセットと、許可された各チャネルカウントのチャネル名の順序付けされたセットを定義するマッピングファミリを示します。詳細はセクション5.1.1で説明します。
8. Channel Mapping Table:
8. チャネルマッピングテーブル：
This table defines the mapping from encoded streams to output channels. Its contents are specified in Section 5.1.1.
このテーブルは、エンコードされたストリームから出力チャネルへのマッピングを定義します。その内容はセクション5.1.1で指定されています。
All fields in the ID headers are REQUIRED, except for 'channel mapping table', which MUST be omitted when the channel mapping family is 0, but is REQUIRED otherwise. Implementations SHOULD treat a stream as invalid if it contains an ID header that does not have enough data for these fields, even if it contain a valid 'magic signature'. Future versions of this specification, even backwards-compatible versions, might include additional fields in the ID header. If an ID header has a compatible major version, but a larger minor version, an implementation MUST NOT treat it as invalid for containing additional data not specified here, provided it still completes on the first page.
IDヘッダーのすべてのフィールドは必須です。ただし、「チャネルマッピングテーブル」は除きます。チャネルマッピングファミリーが0の場合は省略する必要がありますが、それ以外の場合は必須です。実装は、有効な「マジックシグネチャ」が含まれている場合でも、これらのフィールドに十分なデータがないIDヘッダーが含まれている場合、ストリームを無効として扱う必要があります。この仕様の将来のバージョンでは、下位互換性のあるバージョンであっても、IDヘッダーに追加のフィールドが含まれる可能性があります。 IDヘッダーに互換性のあるメジャーバージョンがあり、それより大きなマイナーバージョンがある場合、実装は、ここで指定されていない追加データを含むために無効として扱ってはなりません（ただし、最初のページで完了する場合）。
An Ogg Opus stream allows mapping one number of Opus streams (N) to a possibly larger number of decoded channels (M + N) to yet another number of output channels (C), which might be larger or smaller than the number of decoded channels. The order and meaning of these channels are defined by a channel mapping, which consists of the 'channel mapping family' octet and, for channel mapping families other than family 0, a 'channel mapping table', as illustrated in Figure 3.
Ogg Opusストリームを使用すると、1つの数のOpusストリーム（N）をさらに多くのデコードされたチャネル（M + N）に、さらに別の数の出力チャネル（C）にマッピングできます。 。これらのチャネルの順序と意味は、図3に示すように、「チャネルマッピングファミリ」オクテットと、ファミリ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
+-+-+-+-+-+-+-+-+
| Stream Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Coupled Count | Channel Mapping... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Channel Mapping Table
図3：チャネルマッピングテーブル
The fields in the channel mapping table have the following meaning:
チャネルマッピングテーブルのフィールドには、次の意味があります。
1. Stream Count 'N' (8 bits, unsigned):
1. ストリーム数 'N'（8ビット、符号なし）：
This is the total number of streams encoded in each Ogg packet. This value is necessary to correctly parse the packed Opus packets inside an Ogg packet, as described in Section 3. This value MUST NOT be zero, as without at least one Opus packet with a valid TOC sequence, a demuxer cannot recover the duration of an Ogg packet.
これは、各Oggパケットでエンコードされたストリームの総数です。この値は、セクション3で説明されているように、Oggパケット内のパックされたOpusパケットを正しく解析するために必要です。有効なTOCシーケンスを持つ少なくとも1つのOpusパケットがないと、デマルチプレクサは持続時間を回復できません。 Oggパケット。
For channel mapping family 0, this value defaults to 1, and is not coded.
チャネルマッピングファミリ0の場合、この値のデフォルトは1であり、コーディングされていません。
2. Coupled Stream Count 'M' (8 bits, unsigned):
2. 結合ストリーム数 'M'（8ビット、符号なし）：
This is the number of streams whose decoders are to be configured to produce two channels (stereo). This MUST be no larger than the total number of streams, N.
これは、デコーダーが2つのチャネル（ステレオ）を生成するように構成されているストリームの数です。これは、ストリームの総数N以下でなければなりません。
Each packet in an Opus stream has an internal channel count of 1 or 2, which can change from packet to packet. This is selected by the encoder depending on the bitrate and the audio being encoded. The original channel count of the audio passed to the encoder is not necessarily preserved by the lossy compression.
Opusストリームの各パケットの内部チャネル数は1または2で、パケットごとに変化する可能性があります。これは、エンコードされるビットレートとオーディオに応じて、エンコーダによって選択されます。エンコーダに渡されるオーディオの元のチャネル数は、不可逆圧縮によって必ずしも保持されるわけではありません。
Regardless of the internal channel count, any Opus stream can be decoded as mono (a single channel) or stereo (two channels) by appropriate initialization of the decoder. The 'coupled stream count' field indicates that the decoders for the first M Opus streams are to be initialized for stereo (two-channel) output, and the remaining (N - M) decoders are to be initialized for mono (a single channel) only. The total number of decoded channels, (M + N), MUST be no larger than 255, as there is no way to index more channels than that in the channel mapping.
内部チャネルカウントに関係なく、デコーダーを適切に初期化することにより、Opusストリームをモノ（単一チャネル）またはステレオ（2チャネル）としてデコードできます。 「結合ストリーム数」フィールドは、最初のM Opusストリームのデコーダーがステレオ（2チャネル）出力用に初期化され、残りの（N-M）デコーダーがモノラル（単一チャネル）用に初期化されることを示します。のみ。デコードされたチャネルの合計数（M + N）は、チャネルマッピングのチャネルよりも多くのチャネルにインデックスを付ける方法がないため、255以下でなければなりません。
For channel mapping family 0, this value defaults to (C - 1) (i.e., 0 for mono and 1 for stereo), and is not coded.
チャネルマッピングファミリ0の場合、この値のデフォルトは（C-1）（つまり、モノラルの場合は0、ステレオの場合は1）であり、コード化されていません。
3. Channel Mapping (8*C bits):
3. チャネルマッピング（8 * Cビット）：
This contains one octet per output channel, indicating which decoded channel is to be used for each one. Let 'index' be the value of this octet for a particular output channel. This value MUST either be smaller than (M + N) or be the special value 255. If 'index' is less than 2*M, the output MUST be taken from decoding stream ('index'/2) as stereo and selecting the left channel if 'index' is even, and the right channel if 'index' is odd. If 'index' is 2*M or larger, but less than 255, the output MUST be taken from decoding stream ('index' - M) as mono. If 'index' is 255, the corresponding output channel MUST contain pure silence.
これには、出力チャネルごとに1オクテットが含まれ、それぞれに使用されるデコードされたチャネルを示します。 'index'を特定の出力チャネルのこのオクテットの値とします。この値は（M + N）よりも小さいか、特別な値255でなければなりません。「インデックス」が2 * M未満の場合、出力はデコードストリーム（「インデックス」/ 2）からステレオとして取得し、 「インデックス」が偶数の場合は左チャネル、「インデックス」が奇数の場合は右チャネル'index'が2 * M以上で255未満の場合、出力はデコードストリーム（ 'index'-M）からモノとして取得する必要があります。 'index'が255の場合、対応する出力チャネルには純粋な無音が含まれている必要があります。
The number of output channels, C, is not constrained to match the number of decoded channels (M + N). A single index value MAY appear multiple times, i.e., the same decoded channel might be mapped to multiple output channels. Some decoded channels might not be assigned to any output channel, as well.
出力チャネルの数Cは、デコードされたチャネルの数（M + N）と一致するように制限されていません。単一のインデックス値が複数回出現する場合があります。つまり、同じデコードされたチャネルが複数の出力チャネルにマッピングされる場合があります。デコードされたチャネルの中には、出力チャネルに割り当てられていないものもあります。
For channel mapping family 0, the first index defaults to 0, and if C == 2, the second index defaults to 1. Neither index is coded.
チャネルマッピングファミリ0の場合、最初のインデックスはデフォルトで0になり、C == 2の場合、2番目のインデックスはデフォルトで1になります。どちらのインデックスもコーディングされていません。
After producing the output channels, the channel mapping family determines the semantic meaning of each one. There are three defined mapping families in this specification.
出力チャネルを生成した後、チャネルマッピングファミリは各チャネルの意味の意味を決定します。この仕様には、3つの定義済みマッピングファミリがあります。
Allowed numbers of channels: 1 or 2. RTP mapping. This is the same channel interpretation as [RFC7587].
許可されるチャネル数：1または2。RTPマッピング。これは、[RFC7587]と同じチャネル解釈です。
o 1 channel: monophonic (mono).
o 1チャンネル：モノフォニック（モノ）。
o 2 channels: stereo (left, right).
o 2チャネル：ステレオ（左、右）。
Special mapping: This channel mapping family also indicates that the content consists of a single Opus stream that is stereo if and only if C == 2, with stream index 0 mapped to output channel 0 (mono, or left channel) and stream index 1 mapped to output channel 1 (right channel) if stereo. When the 'channel mapping family' octet has this value, the channel mapping table MUST be omitted from the ID header packet.
特別なマッピング：このチャネルマッピングファミリーは、C == 2の場合に限り、ステレオである単一のOpusストリームでコンテンツが構成されることも示します。ストリームインデックス0は、出力チャネル0（モノまたは左チャネル）およびストリームインデックス1にマップされます。ステレオの場合、出力チャネル1（右チャネル）にマッピングされます。 「チャネルマッピングファミリー」オクテットにこの値がある場合、チャネルマッピングテーブルはIDヘッダーパケットから省略されなければなりません（MUST）。
Allowed numbers of channels: 1...8. Vorbis channel order (see below).
許可されるチャネル数：1 ... 8。 Vorbisチャネルの順序（以下を参照）。
Each channel is assigned to a speaker location in a conventional surround arrangement. Specific locations depend on the number of channels, and are given below in order of the corresponding channel indices.
各チャンネルは、従来のサラウンド配置でスピーカーの場所に割り当てられます。特定の場所は、チャネルの数によって異なり、対応するチャネルインデックスの順に以下に示します。
o 1 channel: monophonic (mono).
o 1チャンネル：モノフォニック（モノ）。
o 2 channels: stereo (left, right).
o 2チャネル：ステレオ（左、右）。
o 3 channels: linear surround (left, center, right).
o 3つのチャネル：線形サラウンド（左、中央、右）。
o 4 channels: quadraphonic (front left, front right, rear left, rear right).
o 4チャンネル：4チャンネル（フロント左、フロント右、リア左、リア右）。
o 5 channels: 5.0 surround (front left, front center, front right, rear left, rear right).
o 5チャンネル：5.0サラウンド（フロント左、フロントセンター、フロント右、リア左、リア右）。
o 6 channels: 5.1 surround (front left, front center, front right, rear left, rear right, LFE).
o 6チャンネル：5.1サラウンド（フロント左、フロントセンター、フロント右、リア左、リア右、LFE）。
o 7 channels: 6.1 surround (front left, front center, front right, side left, side right, rear center, LFE).
o 7チャンネル：6.1サラウンド（フロント左、フロントセンター、フロント右、サイド左、サイド右、リアセンター、LFE）。
o 8 channels: 7.1 surround (front left, front center, front right, side left, side right, rear left, rear right, LFE).
o 8チャンネル：7.1サラウンド（フロント左、フロントセンター、フロント右、サイド左、サイド右、リア左、リア右、LFE）。
This set of surround options and speaker location orderings is the same as those used by the Vorbis codec [Section 4.3.9 Output Channel Order"">VORBIS-MAPPING]. The ordering is different from the one used by the WAVE [WAVE-MULTICHANNEL] and Free Lossless Audio Codec (FLAC) [FLAC] formats, so correct ordering requires permutation of the output channels when decoding to or encoding from those formats. "LFE" here refers to a Low Frequency Effects channel, often mapped to a subwoofer with no particular spatial position. Implementations SHOULD identify "side" or "rear" speaker locations with "surround" and "back" as appropriate when interfacing with audio formats or systems that prefer that terminology.
このサラウンドオプションとスピーカーの位置の順序のセットは、Vorbisコーデックで使用されるものと同じです[セクション4.3.9出力チャネルの順序 ""> VORBIS-MAPPING]。順序付けは、WAVE [WAVE-MULTICHANNEL]およびFree Lossless Audio Codec（FLAC）[FLAC]形式で使用される順序とは異なります。そのため、正しい順序付けでは、これらの形式にデコードまたはエンコードするときに、出力チャネルの順列が必要です。ここでの「LFE」とは、特定の空間位置のないサブウーファーにマッピングされることが多い低周波効果チャンネルを指します。実装は、その用語を好むオーディオ形式またはシステムとのインターフェースをとるときに、「サラウンド」と「バック」で「サイド」または「リア」スピーカーの場所を適切に識別する必要があります。
Allowed numbers of channels: 1...255. No defined channel meaning.
許可されるチャネル数：1 ... 255。定義されたチャネルの意味はありません。
Channels are unidentified. General-purpose players SHOULD NOT attempt to play these streams. Offline implementations MAY deinterleave the output into separate PCM files, one per channel. Implementations SHOULD NOT produce output for channels mapped to stream index 255 (pure silence) unless they have no other way to indicate the index of non-silent channels.
チャンネルは未確認です。汎用プレイヤーはこれらのストリームを再生しようとしてはなりません。オフラインの実装では、出力を個別のPCMファイルにデインターリーブできます（チャネルごとに1つ）。実装は、非サイレントチャネルのインデックスを示す他の方法がない限り、ストリームインデックス255（純粋な無音）にマップされたチャネルの出力を生成してはなりません（SHOULD NOT）。
The remaining channel mapping families (2...254) are reserved. A demuxer implementation encountering a reserved 'channel mapping family' value SHOULD act as though the value is 255.
残りのチャネルマッピングファミリ（2 ... 254）は予約されています。予約済みの「チャネルマッピングファミリー」の値に遭遇したデマルチプレクサの実装は、値が255であるかのように動作する必要があります。
An Ogg Opus player MUST support any valid channel mapping with a channel mapping family of 0 or 1, even if the number of channels does not match the physically connected audio hardware. Players SHOULD perform channel mixing to increase or reduce the number of channels as needed.
Ogg Opusプレーヤーは、チャネルの数が物理的に接続されたオーディオハードウェアと一致しない場合でも、0または1のチャネルマッピングファミリーを使用して有効なチャネルマッピングをサポートする必要があります。プレーヤーは、必要に応じてチャンネル数を増減するためにチャンネルミキシングを実行する必要があります。
Implementations MAY use the matrices in Figures 4 through 9 to implement downmixing from multichannel files using channel mapping family 1 (Section 5.1.1.2), which are known to give acceptable results for stereo. Matrices for 3 and 4 channels are normalized so each coefficient row sums to 1 to avoid clipping. For 5 or more channels, they are normalized to 2 as a compromise between clipping and dynamic range reduction.
実装は、図4から9の行列を使用して、ステレオで許容できる結果が得られることが知られているチャネルマッピングファミリ1（セクション5.1.1.2）を使用してマルチチャネルファイルからのダウンミキシングを実装できます。 3および4チャネルの行列は正規化されているため、クリッピングを回避するために、各係数行の合計は1になります。 5つ以上のチャネルの場合、クリッピングとダイナミックレンジの削減の間の妥協点として、それらは2に正規化されます。
In these matrices the front-left and front-right channels are generally passed through directly. When a surround channel is split between both the left and right stereo channels, coefficients are chosen so their squares sum to 1, which helps preserve the perceived intensity. Rear channels are mixed more diffusely or attenuated to maintain focus on the front channels.
これらのマトリックスでは、通常、左前および右前のチャネルが直接通過します。サラウンドチャンネルが左右のステレオチャンネルの両方に分割される場合、係数は2乗の合計が1になるように選択されます。これにより、知覚される強度が維持されます。リアチャンネルは、フロントチャンネルへのフォーカスを維持するために、より拡散して混合または減衰されます。
L output = ( 0.585786 * left + 0.414214 * center )
R output = ( 0.414214 * center + 0.585786 * right )
Exact coefficient values are 1 and 1/sqrt(2), multiplied by 1/(1 + 1/sqrt(2)) for normalization.
正確な係数値は1および1 / sqrt（2）であり、正規化のために1 /（1 + 1 / sqrt（2））が乗算されます。
Figure 4: Stereo Downmix Matrix for the Linear Surround Channel Mapping
図4：線形サラウンドチャンネルマッピングのステレオダウンミックスマトリックス
/ \ / \ / FL \
| L output | | 0.422650 0.000000 0.366025 0.211325 | | FR |
| R output | = | 0.000000 0.422650 0.211325 0.366025 | | RL |
\ / \ / \ RR /
Exact coefficient values are 1, sqrt(3)/2 and 1/2, multiplied by 1/(1 + sqrt(3)/2 + 1/2) for normalization.
正確な係数値は1、sqrt（3）/ 2および1/2であり、正規化のために1 /（1 + sqrt（3）/ 2 + 1/2）が乗算されます。
Figure 5: Stereo Downmix Matrix for the Quadraphonic Channel Mapping
図5：Quadraphonic Channel Mappingのステレオダウンミックスマトリックス
/ FL \
/ \ / \ | FC |
| L | | 0.650802 0.460186 0.000000 0.563611 0.325401 | | FR |
| R | = | 0.000000 0.460186 0.650802 0.325401 0.563611 | | RL |
\ / \ / | RR |
\ /
Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2) for normalization.
正確な係数値は、1、1 / sqrt（2）、sqrt（3）/ 2、1 / 2で、2 /（1 + 1 / sqrt（2）+ sqrt（3）/ 2 + 1/2）を掛けて正規化。
Figure 6: Stereo Downmix Matrix for the 5.0 Surround Mapping
図6：5.0サラウンドマッピングのステレオダウンミックスマトリックス
/FL \
/ \ / \ |FC |
|L| | 0.529067 0.374107 0.000000 0.458186 0.264534 0.374107 | |FR |
|R| = | 0.000000 0.374107 0.529067 0.264534 0.458186 0.374107 | |RL |
\ / \ / |RR |
\LFE/
Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2,
multiplied by 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2 + 1/sqrt(2)) for
normalization.
Figure 7: Stereo Downmix Matrix for the 5.1 Surround Mapping
図7：5.1サラウンドマッピングのステレオダウンミックスマトリックス
/ \
| 0.455310 0.321953 0.000000 0.394310 0.227655 0.278819 0.321953 |
| 0.000000 0.321953 0.455310 0.227655 0.394310 0.278819 0.321953 |
\ /
Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2, 1/2 and sqrt(3)/2/sqrt(2), multiplied by 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2 + sqrt(3)/2/sqrt(2) + 1/sqrt(2)) for normalization. The coefficients are in the same order as in Section 5.1.1.2 and the matrices above.
正確な係数値は1、1 / sqrt（2）、sqrt（3）/ 2、1 / 2およびsqrt（3）/ 2 / sqrt（2）であり、2 /（1 + 1 / sqrt（2）+正規化のためのsqrt（3）/ 2 + 1/2 + sqrt（3）/ 2 / sqrt（2）+ 1 / sqrt（2））。係数は、セクション5.1.1.2および上記の行列と同じ順序です。
Figure 8: Stereo Downmix Matrix for the 6.1 Surround Mapping
図8：6.1サラウンドマッピングのステレオダウンミックスマトリックス
/ \
| .388631 .274804 .000000 .336565 .194316 .336565 .194316 .274804 |
| .000000 .274804 .388631 .194316 .336565 .194316 .336565 .274804 |
\ /
Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by 2/(2 + 2/sqrt(2) + sqrt(3)) for normalization. The coefficients are in the same order as in Section 5.1.1.2 and the matrices above.
正確な係数値は1、1 / sqrt（2）、sqrt（3）/ 2および1/2で、正規化のために2 /（2 + 2 / sqrt（2）+ sqrt（3））を掛けた値です。係数は、セクション5.1.1.2および上記の行列と同じ順序です。
Figure 9: Stereo Downmix Matrix for the 7.1 Surround Mapping
図9：7.1サラウンドマッピングのステレオダウンミックスマトリックス
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'O' | 'p' | 'u' | 's' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'a' | 'g' | 's' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Vendor String... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Comment List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Comment #0 String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: User Comment #0 String... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Comment #1 String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
Figure 10: Comment Header Packet
図10：コメントヘッダーパケット
The comment header consists of a 64-bit 'magic signature' field, followed by data in the same format as the [VORBIS-COMMENT] header used in Ogg Vorbis, except (like Ogg Theora and Speex) the final 'framing bit' specified in the Vorbis specification is not present.
コメントヘッダーは、64ビットの「マジックシグネチャ」フィールドと、その後に指定された最後の「フレーミングビット」を除いて、Ogg Vorbisで使用される[VORBIS-COMMENT]ヘッダーと同じ形式のデータで構成されます。 Vorbis仕様には存在しません。
1. Magic Signature:
1. 魔法の署名：
This is an 8-octet (64-bit) field that allows codec identification and is human readable. It contains, in order, the magic numbers:
これは、8オクテット（64ビット）のフィールドであり、コーデックの識別を可能にし、人間が読み取り可能です。順番に、マジックナンバーが含まれています。
0x4F 'O'
0x4F 'O'
0x70 'p'
0x70 'p'
0x75 'u'
0x75 'u'
0x73 's'
0x73 's'
0x54 'T'
0x54 'T'
0x61 'a'
0x61 'a'
0x67 'g'
0x67 'g'
0x73 's'
0x73 's'
Starting with "Op" helps distinguish it from audio data packets, as this is an invalid TOC sequence.
これは無効なTOCシーケンスであるため、「Op」で開始すると、オーディオデータパケットとの区別に役立ちます。
2. Vendor String Length (32 bits, unsigned, little endian):
2. ベンダー文字列の長さ（32ビット、符号なし、リトルエンディアン）：
This field gives the length of the following vendor string, in octets. It MUST NOT indicate that the vendor string is longer than the rest of the packet.
このフィールドは、次のベンダー文字列の長さをオクテットで示します。ベンダー文字列がパケットの他の部分よりも長いことを示してはなりません。
3. Vendor String (variable length, UTF-8 vector):
3. ベンダー文字列（可変長、UTF-8ベクトル）：
This is a simple human-readable tag for vendor information, encoded as a UTF-8 string [RFC3629]. No terminating null octet is necessary.
これは、UTF-8文字列[RFC3629]としてエンコードされた、ベンダー情報用の人間が読める単純なタグです。終端のnullオクテットは必要ありません。
This tag is intended to identify the codec encoder and encapsulation implementations, for tracing differences in technical behavior. User-facing applications can use the 'ENCODER' user comment tag to identify themselves.
このタグは、技術的な動作の違いを追跡するために、コーデックエンコーダとカプセル化の実装を識別することを目的としています。ユーザー向けのアプリケーションは、 'ENCODER'ユーザーコメントタグを使用して自分自身を識別できます。
4. User Comment List Length (32 bits, unsigned, little endian):
4. ユーザーコメントリストの長さ（32ビット、符号なし、リトルエンディアン）：
This field indicates the number of user-supplied comments. It MAY indicate there are zero user-supplied comments, in which case there are no additional fields in the packet. It MUST NOT indicate that there are so many comments that the comment string lengths would require more data than is available in the rest of the packet.
このフィールドは、ユーザーが入力したコメントの数を示します。ユーザー提供のコメントがないことを示す場合があります。その場合、パケットに追加のフィールドはありません。コメントが多すぎて、パケットの残りの部分で利用できるよりも多くのデータが必要になるコメントがあることを示してはなりません。
5. User Comment #i String Length (32 bits, unsigned, little endian):
5. ユーザーコメント#i文字列の長さ（32ビット、符号なし、リトルエンディアン）：
This field gives the length of the following user comment string, in octets. There is one for each user comment indicated by the 'user comment list length' field. It MUST NOT indicate that the string is longer than the rest of the packet.
このフィールドは、次のユーザーコメント文字列の長さをオクテットで示します。 「ユーザーコメントリストの長さ」フィールドで示されるユーザーコメントごとに1つあります。文字列がパケットの他の部分よりも長いことを示してはなりません。
6. User Comment #i String (variable length, UTF-8 vector):
6. ユーザーコメント#i文字列（可変長、UTF-8ベクトル）：
This field contains a single user comment encoded as a UTF-8 string [RFC3629]. There is one for each user comment indicated by the 'user comment list length' field.
このフィールドには、UTF-8文字列[RFC3629]としてエンコードされた単一のユーザーコメントが含まれます。 「ユーザーコメントリストの長さ」フィールドで示されるユーザーコメントごとに1つあります。
The 'vendor string length' and 'user comment list length' fields are REQUIRED, and implementations SHOULD treat a stream as invalid if it contains a comment header that does not have enough data for these fields, or that does not contain enough data for the corresponding vendor string or user comments they describe. Making this check before allocating the associated memory to contain the data helps prevent a possible Denial-of-Service (DoS) attack from small comment headers that claim to contain strings longer than the entire packet or more user comments than could possibly fit in the packet.
「ベンダー文字列の長さ」と「ユーザーコメントリストの長さ」フィールドは必須であり、実装には、これらのフィールドに十分なデータがないコメントヘッダーが含まれている場合、またはストリームに十分なデータが含まれていないコメントヘッダーが含まれている場合、ストリームを無効として扱う必要があります。それらが説明する対応するベンダー文字列またはユーザーコメントデータを含む関連メモリを割り当てる前にこのチェックを行うと、パケット全体よりも長い文字列や、パケットに収まりきらない可能性のあるより多くのユーザーコメントを含むと主張する小さなコメントヘッダーによるサービス拒否（DoS）攻撃の防止に役立ちます。
Immediately following the user comment list, the comment header MAY contain zero-padding or other binary data that is not specified here. If the least-significant bit of the first byte of this data is 1, then editors SHOULD preserve the contents of this data when updating the tags, but if this bit is 0, all such data MAY be treated as padding, and truncated or discarded as desired. This allows informal experimentation with the format of this binary data until it can be specified later.
ユーザーコメントリストの直後に、コメントヘッダーにゼロパディングまたはここで指定されていないその他のバイナリデータを含めることができます。このデータの最初のバイトの最下位ビットが1の場合、エディターはタグを更新するときにこのデータの内容を保持する必要がありますが、このビットが0の場合、そのようなデータはすべてパディングとして扱われ、切り捨てられるか破棄されます（MAY）。望んだ通りに。これにより、後で指定できるようになるまで、このバイナリデータの形式を非公式に試すことができます。
The comment header can be arbitrarily large and might be spread over a large number of Ogg pages. Implementations MUST avoid attempting to allocate excessive amounts of memory when presented with a very large comment header. To accomplish this, implementations MAY treat a stream as invalid if it has a comment header larger than 125,829,120 octets (120 MB), and MAY ignore individual comments that are not fully contained within the first 61,440 octets of the comment header.
コメントヘッダーは任意に大きくすることができ、多数のOggページにまたがる場合があります。実装は、非常に大きなコメントヘッダーが提示されたときに、過剰な量のメモリを割り当てようとすることを避けなければなりません。これを達成するために、実装は、125,829,120オクテット（120 MB）より大きいコメントヘッダーがある場合、ストリームを無効として扱い、コメントヘッダーの最初の61,440オクテット内に完全に含まれていない個々のコメントを無視してもよい（MAY）。
The user comment strings follow the NAME=value format described by [VORBIS-COMMENT] with the same recommended tag names: ARTIST, TITLE, DATE, ALBUM, and so on.
ユーザーコメント文字列は、[VORBIS-COMMENT]で説明されているNAME = value形式に従い、同じ推奨タグ名（ARTIST、TITLE、DATE、ALBUMなど）を使用します。
Two new comment tags are introduced here:
ここでは、2つの新しいコメントタグが導入されています。
First, an optional gain for track normalization:
まず、トラックの正規化のためのオプションのゲイン：
R128_TRACK_GAIN=-573
R128_TRACK_GAIN = -573
representing the volume shift needed to normalize the track's volume during isolated playback, in random shuffle, and so on. The gain is a Q7.8 fixed-point number in dB, as in the ID header's 'output gain' field. This tag is similar to the REPLAYGAIN_TRACK_GAIN tag in Vorbis [REPLAY-GAIN], except that the normal volume reference is the [EBU-R128] standard.
分離再生中、ランダムシャッフルなどでトラックの音量を正規化するために必要な音量シフトを表します。ゲインは、IDヘッダーの「出力ゲイン」フィールドと同様に、dB単位のQ7.8固定小数点数です。このタグは、通常のボリューム参照が[EBU-R128]標準であることを除いて、Vorbis [REPLAY-GAIN]のREPLAYGAIN_TRACK_GAINタグに似ています。
Second, an optional gain for album normalization:
第二に、アルバムの正規化のためのオプションの利益：
R128_ALBUM_GAIN=111
R128_ALBUM_GAIN = 111
representing the volume shift needed to normalize the overall volume when played as part of a particular collection of tracks. The gain is also a Q7.8 fixed-point number in dB, as in the ID header's 'output gain' field. The values '-573' and '111' given here are just examples.
トラックの特定のコレクションの一部として再生されたときに、全体的なボリュームを正規化するために必要なボリュームシフトを表します。ゲインは、IDヘッダーの「出力ゲイン」フィールドのように、dB単位のQ7.8固定小数点数でもあります。ここに示されている値「-573」と「111」は単なる例です。
An Ogg Opus stream MUST NOT have more than one of each of these tags, and, if present, their values MUST be an integer from -32768 to 32767, inclusive, represented in ASCII as a base 10 number with no whitespace. A leading '+' or '-' character is valid. Leading zeros are also permitted, but the value MUST be represented by no more than 6 characters. Other non-digit characters MUST NOT be present.
Ogg Opusストリームはこれらのタグを複数持つことはできません。また、存在する場合、それらの値は-32768から32767までの整数である必要があり、空白を含まない10進数としてASCIIで表される必要があります。先頭の「+」または「-」文字は有効です。先行ゼロも許可されますが、値は6文字以下で表す必要があります。他の非数字文字は存在してはなりません。
If present, R128_TRACK_GAIN and R128_ALBUM_GAIN MUST correctly represent the R128 normalization gain relative to the 'output gain' field specified in the ID header. If a player chooses to make use of the R128_TRACK_GAIN tag or the R128_ALBUM_GAIN tag, it MUST apply those gains _in addition_ to the 'output gain' value. If a tool modifies the ID header's 'output gain' field, it MUST also update or remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present. A muxer SHOULD place the gain it wants other tools to use by default into the 'output gain' field, and not the comment tag.
存在する場合、R128_TRACK_GAINおよびR128_ALBUM_GAINは、IDヘッダーで指定された「出力ゲイン」フィールドに対するR128正規化ゲインを正しく表す必要があります。プレーヤーがR128_TRACK_GAINタグまたはR128_ALBUM_GAINタグを使用することを選択した場合は、それらのゲインを「出力ゲイン」値に追加して適用する必要があります。ツールがIDヘッダーの「出力ゲイン」フィールドを変更する場合、R128_TRACK_GAINおよびR128_ALBUM_GAINコメントタグが存在する場合、それも更新または削除する必要があります。マクサーは、他のツールがデフォルトで使用するゲインをコメントタグではなく「出力ゲイン」フィールドに配置する必要があります（SHOULD）。
To avoid confusion with multiple normalization schemes, an Opus comment header SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags, unless they are only to be used in some context where there is guaranteed to be no such confusion. [EBU-R128] normalization is preferred to the earlier REPLAYGAIN schemes because of its clear definition and adoption by industry. Peak normalizations are difficult to calculate reliably for lossy codecs because of variation in excursion heights due to decoder differences. In the authors' investigations, they were not applied consistently or broadly enough to merit inclusion here.
複数の正規化スキームとの混同を避けるために、Opusコメントヘッダーには、REPLAYGAIN_TRACK_GAIN、REPLAYGAIN_TRACK_PEAK、REPLAYGAIN_ALBUM_GAIN、またはREPLAYGAIN_ALBUM_PEAKタグのいずれも含めないでください（ただし、これらのタグは、そのような混乱がないことが保証されているコンテキストでのみ使用される場合を除きます）。 [EBU-R128]業界による明確な定義と採用のため、正規化は以前のREPLAYGAINスキームよりも推奨されます。デコーダーの違いによるエクスカーションの高さのばらつきのため、ピークの正規化は、損失の多いコーデックで確実に計算することが困難です。著者の調査では、これらはここに含めるに値するほど一貫してまたは広く適用されていません。
Technically, valid Opus packets can be arbitrarily large due to the padding format, although the amount of non-padding data they can contain is bounded. These packets might be spread over a similarly enormous number of Ogg pages. When encoding, implementations SHOULD limit the use of padding in audio data packets to no more than is necessary to make a VBR stream CBR, unless they have no reasonable way to determine what is necessary. Demuxers SHOULD treat audio data packets as invalid (treat them as if they were malformed Opus packets with an invalid TOC sequence) if they are larger than 61,440 octets per Opus stream, unless they have a specific reason for allowing extra padding. Such packets necessarily contain more padding than needed to make a stream CBR. Demuxers MUST avoid attempting to allocate excessive amounts of memory when presented with a very large packet. Demuxers MAY treat audio data packets as invalid or partially process them if they are larger than 61,440 octets in an Ogg Opus stream with channel mapping families 0 or 1. Demuxers MAY treat audio data packets as invalid or partially process them in any Ogg Opus stream if the packet is larger than 61,440 octets and also larger than 7,680 octets per Opus stream. The presence of an extremely large packet in the stream could indicate a memory exhaustion attack or stream corruption.
技術的には、パディング形式により、有効なOpusパケットは任意に大きくなる可能性がありますが、それらに含まれる非パディングデータの量は制限されます。これらのパケットは、同様に膨大な数のOggページに分散する可能性があります。エンコード時に、実装は、オーディオデータパケットのパディングの使用を、VBRストリームCBRを作成するために必要なものに制限する必要があります（ただし、必要なものを決定する合理的な方法がない場合）。デマルチプレクサは、特別なパディングを許可する特別な理由がない限り、オーディオデータパケットがOpusストリームあたり61,440オクテットより大きい場合、オーディオデータパケットを無効として扱う（無効なTOCシーケンスを持つ不正なOpusパケットであるかのように扱う）必要があります。このようなパケットには、ストリームCBRを作成するために必要なパディングよりも多くのパディングが必ず含まれています。デマルチプレクサは、非常に大きなパケットが提示されたときに、過剰な量のメモリを割り当てようとすることを回避する必要があります。デマルチプレクサは、オーディオデータパケットを無効として扱うか、チャネルマッピングファミリ0または1のOgg Opusストリームで61,440オクテットより大きい場合は部分的に処理する場合があります。デマルチプレクサは、オーディオデータパケットを無効として扱うか、またはOgg Opusストリームで部分的に処理する場合があります（MAY）。パケットは、オーパスストリームごとに61,440オクテットより大きく、7,680オクテットより大きい。ストリームに非常に大きなパケットが存在する場合は、メモリ不足の攻撃またはストリームの破損を示している可能性があります。
In an Ogg Opus stream, the largest possible valid packet that does not use padding has a size of (61,298*N - 2) octets. With 255 streams, this is 15,630,988 octets and can span up to 61,298 Ogg pages, all but one of which will have a granule position of -1. This is, of course, a very extreme packet, consisting of 255 streams, each containing 120 ms of audio encoded as 2.5 ms frames, each frame using the maximum possible number of octets (1275) and stored in the least efficient manner allowed (a VBR code 3 Opus packet). Even in such a packet, most of the data will be zeros as 2.5 ms frames cannot actually use all 1275 octets.
Ogg Opusストリームでは、パディングを使用しない有効な最大パケットのサイズは（61,298 * N-2）オクテットです。 255ストリームの場合、これは15,630,988オクテットで、最大61,298 Oggページに及ぶ可能性があり、そのうち1つを除いてすべて、グラニュル位置が-1になります。これはもちろん、非常に極端なパケットで、255ストリームで構成され、それぞれが2.5 msフレームとしてエンコードされた120 msのオーディオを含み、各フレームは可能な最大オクテット数（1275）を使用し、許容される最も効率の低い方法（a VBRコード3 Opusパケット）。そのようなパケットであっても、2.5ミリ秒のフレームは実際にすべての1275オクテットを使用できないため、ほとんどのデータはゼロになります。
The largest packet consisting of entirely useful data is (15,326*N - 2) octets. This corresponds to 120 ms of audio encoded as 10 ms frames in either SILK or Hybrid mode, but at a data rate of over 1 Mbps, which makes little sense for the quality achieved.
完全に有用なデータで構成される最大のパケットは、（15,326 * N-2）オクテットです。これは、SILKモードまたはハイブリッドモードのいずれかで10 msフレームとしてエンコードされた120 msのオーディオに相当しますが、1 Mbpsを超えるデータレートでは、達成される品質にはほとんど意味がありません。
A more reasonable limit is (7,664*N - 2) octets. This corresponds to 120 ms of audio encoded as 20 ms stereo CELT mode frames, with a total bitrate just under 511 kbps (not counting the Ogg encapsulation overhead). For channel mapping family 1, N = 8 provides a reasonable upper bound, as it allows for each of the 8 possible output channels to be decoded from a separate stereo Opus stream. This gives a size of 61,310 octets, which is rounded up to a multiple of 1,024 octets to yield the audio data packet size of 61,440 octets that any implementation is expected to be able to process successfully.
より妥当な制限は、（7,664 * N-2）オクテットです。これは、20 msのステレオCELTモードフレームとしてエンコードされた120 msのオーディオに対応し、合計ビットレートは511 kbps未満です（Oggカプセル化のオーバーヘッドは含まれません）。チャネルマッピングファミリ1の場合、N = 8は、8つの可能な出力チャネルのそれぞれを個別のステレオOpusストリームからデコードできるため、妥当な上限を提供します。これにより、サイズが61,310オクテットになり、これを1,024オクテットの倍数に切り上げて、実装が正常に処理できると予想される61,440オクテットのオーディオデータパケットサイズを生成します。
When encoding Opus streams, Ogg muxers SHOULD take into account the algorithmic delay of the Opus encoder.
Opusストリームをエンコードするとき、OggマルチプレクサーはOpusエンコーダーのアルゴリズム遅延を考慮に入れるべきです（SHOULD）。
In encoders derived from the reference implementation [RFC6716], the number of samples can be queried with
リファレンス実装[RFC6716]から派生したエンコーダーでは、サンプル数は
opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD(&delay_samples));
To achieve good quality in the very first samples of a stream, implementations MAY use linear predictive coding (LPC) extrapolation to generate at least 120 extra samples at the beginning to avoid the Opus encoder having to encode a discontinuous signal. For more information on linear prediction, see [LINEAR-PREDICTION]. For an input file containing 'length' samples, the implementation SHOULD set the 'pre-skip' header value to (delay_samples + extra_samples), encode at least (length + delay_samples + extra_samples) samples, and set the granule position of the last page to (length + delay_samples + extra_samples). This ensures that the encoded file has the same duration as the original, with no time offset. The best way to pad the end of the stream is to also use LPC extrapolation, but zero-padding is also acceptable.
ストリームの最初のサンプルで良好な品質を達成するために、実装は線形予測コーディング（LPC）外挿を使用して、最初に少なくとも120の追加サンプルを生成し、Opusエンコーダーが不連続な信号をエンコードする必要をなくすことができます。線形予測の詳細については、[LINEAR-PREDICTION]を参照してください。 「長さ」サンプルを含む入力ファイルの場合、実装では、「前スキップ」ヘッダー値を（delay_samples + extra_samples）に設定し、少なくとも（長さ+ delay_samples + extra_samples）サンプルをエンコードして、最後のページのグラニュル位置を設定する必要があります（SHOULD）。 to（length + delay_samples + extra_samples）。これにより、エンコードされたファイルが元のファイルと同じ期間を持ち、時間オフセットがなくなります。ストリームの終わりにパディングする最良の方法は、LPC外挿も使用することですが、ゼロパディングも許容されます。
The first step in LPC extrapolation is to compute linear prediction coefficients [LPC-SAMPLE]. When extending the end of the signal, order-N (typically with N ranging from 8 to 40) LPC analysis is performed on a window near the end of the signal. The last N samples are used as memory to an infinite impulse response (IIR) filter.
LPC外挿の最初のステップは、線形予測係数[LPC-SAMPLE]を計算することです。信号の終わりを拡張する場合、次数N（通常、Nの範囲は8〜40）LPC分析が信号の終わり近くのウィンドウで実行されます。最後のN個のサンプルは、無限インパルス応答（IIR）フィルターへのメモリーとして使用されます。
The filter is then applied on a zero input to extrapolate the end of the signal. Let 'a(k)' be the kth LPC coefficient and 'x(n)' be the nth sample of the signal. Each new sample past the end of the signal is computed as
次に、フィルターをゼロ入力に適用して、信号の終わりを推定します。 'a（k）'をk番目のLPC係数、 'x（n）'を信号のn番目のサンプルとします。信号の終わりを過ぎた新しいサンプルはそれぞれ次のように計算されます。
N
---
x(n) = \ a(k)*x(n - k)
/
---
k = 1
The process is repeated independently for each channel. It is possible to extend the beginning of the signal by applying the same process backward in time. When extending the beginning of the signal, it is best to apply a "fade in" to the extrapolated signal, e.g., by multiplying it by a half-Hanning window [HANNING].
このプロセスは、チャネルごとに独立して繰り返されます。同じプロセスを過去にさかのぼって適用することにより、信号の始まりを拡張することが可能です。信号の先頭を拡張するときは、たとえば、半ハニングウィンドウ[HANNING]を掛けて、外挿された信号に「フェードイン」を適用するのが最適です。
In some applications, such as Internet radio, it is desirable to cut a long stream into smaller chains, e.g., so the comment header can be updated. This can be done simply by separating the input streams into segments and encoding each segment independently. The drawback of this approach is that it creates a small discontinuity at the boundary due to the lossy nature of Opus. A muxer MAY avoid this discontinuity by using the following procedure:
インターネットラジオなどの一部のアプリケーションでは、たとえば、コメントヘッダーを更新できるように、長いストリームを小さなチェーンにカットすることが望ましいです。これは、入力ストリームをセグメントに分離し、各セグメントを個別にエンコードするだけで実行できます。このアプローチの欠点は、オーパスの損失を伴う性質のために、境界で小さな不連続が生じることです。マルチプレクサは、次の手順を使用して、この不連続性を回避できます。
1. Encode the last frame of the first segment as an independent frame by turning off all forms of inter-frame prediction. De-emphasis is allowed.
1. すべての形式のフレーム間予測をオフにして、最初のセグメントの最後のフレームを独立フレームとしてエンコードします。ディエンファシスが許可されています。
2. Set the granule position of the last page to a point near the end of the last frame.
2. 最後のページのグラニュール位置を最後のフレームの終わり近くのポイントに設定します。
3. Begin the second segment with a copy of the last frame of the first segment.
3. 最初のセグメントの最後のフレームのコピーから2番目のセグメントを開始します。
4. Set the 'pre-skip' value of the second stream in such a way as to properly join the two streams.
4. 2つのストリームを適切に結合するような方法で、2番目のストリームの「スキップ前」の値を設定します。
5. Continue the encoding process normally from there, without any reset to the encoder.
5. エンコーダをリセットせずに、そこから通常どおりにエンコードプロセスを続行します。
In encoders derived from the reference implementation, inter-frame prediction can be turned off by calling
参照実装から派生したエンコーダーでは、次の呼び出しにより、フレーム間予測をオフにできます
opus_encoder_ctl(encoder_state, OPUS_SET_PREDICTION_DISABLED(1));
For best results, this implementation requires that prediction be explicitly enabled again before resuming normal encoding, even after a reset.
最良の結果を得るには、この実装では、リセット後でも、通常のエンコーディングを再開する前に、予測を明示的に再度有効にする必要があります。
Implementations of the Opus codec need to take appropriate security considerations into account, as outlined in [RFC4732]. This is just as much a problem for the container as it is for the codec itself. Malicious payloads and/or input streams can be used to attack codec implementations. Implementations MUST NOT overrun their allocated memory nor consume excessive resources when decoding payloads or processing input streams. Although problems in encoding applications are typically rarer, this still applies to a muxer, as vulnerabilities would allow an attacker to attack transcoding gateways.
Opusコーデックの実装では、[RFC4732]で概説されているように、適切なセキュリティの考慮事項を考慮する必要があります。これは、コーデック自体の問題と同様に、コンテナの問題でもあります。悪意のあるペイロードや入力ストリームを使用して、コーデックの実装を攻撃できます。ペイロードのデコード時や入力ストリームの処理時に、実装は割り当てられたメモリをオーバーランさせたり、過剰なリソースを消費してはなりません。エンコーディングアプリケーションの問題は一般的にはまれですが、脆弱性により攻撃者がトランスコーディングゲートウェイを攻撃できるため、これはマルチプレクサにも当てはまります。
Header parsing code contains the most likely area for potential overruns. It is important for implementations to ensure their buffers contain enough data for all of the required fields before attempting to read it (for example, for all of the channel map data in the ID header). Implementations would do well to validate the indices of the channel map, also, to ensure they meet all of the restrictions outlined in Section 5.1.1, in order to avoid attempting to read data from channels that do not exist.
ヘッダー解析コードには、潜在的なオーバーランの可能性が最も高い領域が含まれています。実装では、必要なすべてのフィールドを読み取る前に、それらのバッファーに十分なデータが含まれていることを確認することが重要です（たとえば、IDヘッダーのすべてのチャネルマップデータ）。実装は、チャネルマップのインデックスを検証し、存在しないチャネルからデータを読み取ろうとしないように、セクション5.1.1で概説されているすべての制限を確実に満たすようにすることもできます。
To avoid excessive resource usage, we advise implementations to be especially wary of streams that might cause them to process far more data than was actually transmitted. For example, a relatively small comment header may contain values for the string lengths or user comment list length that imply that it is many gigabytes in size. Even computing the size of the required buffer could overflow a 32-bit integer, and actually attempting to allocate such a buffer before verifying it would be a reasonable size is a bad idea. After reading the user comment list length, implementations might wish to verify that the header contains at least the minimum amount of data for that many comments (4 additional octets per comment, to indicate each has a length of zero) before proceeding any further, again taking care to avoid overflow in these calculations. If allocating an array of pointers to point at these strings, the size of the pointers may be larger than 4 octets, potentially requiring a separate overflow check.
過度のリソース使用を避けるために、実際に送信されたよりもはるかに多くのデータを処理する可能性があるストリームには特に注意するように実装にアドバイスします。たとえば、比較的小さなコメントヘッダーには、文字列の長さまたはユーザーコメントリストの長さの値が含まれている場合があり、これはサイズが数ギガバイトであることを意味します。必要なバッファーのサイズを計算しても32ビット整数がオーバーフローする可能性があり、妥当なサイズであることを確認する前に実際にそのようなバッファーを割り当てようとすることは悪い考えです。ユーザーのコメントリストの長さを読み取った後、実装では、ヘッダーに少なくともその数のコメントの最小量のデータ（コメントごとに4オクテット、それぞれの長さが0であることを示す）が含まれていることを確認してから、さらに続行します。これらの計算でオーバーフローを回避するように注意してください。これらの文字列を指すようにポインターの配列を割り当てる場合、ポインターのサイズは4オクテットより大きくなる可能性があり、別のオーバーフローチェックが必要になる可能性があります。
Another bug in this class we have observed more than once involves the handling of invalid data at the end of a stream. Often, implementations will seek to the end of a stream to locate the last timestamp in order to compute its total duration. If they do not find a valid capture pattern and Ogg page from the desired logical stream, they will back up and try again. If care is not taken to avoid re-scanning data that was already scanned, this search can quickly devolve into something with a complexity that is quadratic in the amount of invalid data.
このクラスのもう1つのバグは、ストリームの最後での無効なデータの処理に関連しています。多くの場合、実装では、ストリームの最後までシークして、その合計期間を計算するために最後のタイムスタンプを見つけます。目的の論理ストリームから有効なキャプチャパターンとOggページが見つからない場合、バックアップしてから再試行します。既にスキャンされたデータの再スキャンを回避するように注意が払われていない場合、この検索は、無効なデータの量が2次である複雑さを持つものにすぐに展開できます。
In general, when seeking, implementations will wish to be cautious about the effects of invalid granule position values and ensure all algorithms will continue to make progress and eventually terminate, even if these are missing or out of order.
一般に、シーク時には、実装は無効なグラニュール位置の値の影響に注意し、これらが欠落しているか、または順序が正しくない場合でも、すべてのアルゴリズムが継続して進行し、最終的に終了するようにします。
Like most other container formats, Ogg Opus streams SHOULD NOT be used with insecure ciphers or cipher modes that are vulnerable to known-plaintext attacks. Elements such as the Ogg page capture pattern and the 'magic signature' fields in the ID header and the comment header all have easily predictable values, in addition to various elements of the codec data itself.
他のほとんどのコンテナ形式と同様に、Ogg Opusストリームは、既知の平文攻撃に対して脆弱な安全でない暗号または暗号モードでは使用しないでください。 Oggページキャプチャパターンや、IDヘッダーとコメントヘッダーの「マジックシグネチャ」フィールドなどの要素はすべて、コーデックデータ自体のさまざまな要素に加えて、簡単に予測できる値を持っています。
An "Ogg Opus file" consists of one or more sequentially multiplexed segments, each containing exactly one Ogg Opus stream. The RECOMMENDED mime-type for Ogg Opus files is "audio/ogg".
「Ogg Opusファイル」は、1つ以上の順次多重化されたセグメントで構成され、各セグメントには1つのOgg Opusストリームが含まれます。 Ogg Opusファイルの推奨されるMIMEタイプは「audio / ogg」です。
If more specificity is desired, one MAY indicate the presence of Opus streams using the codecs parameter defined in [RFC6381] and [RFC5334], e.g.,
より具体的にしたい場合は、[RFC6381]と[RFC5334]で定義されているコーデックパラメータを使用して、Opusストリームの存在を示すことができます。たとえば、
audio/ogg; codecs=opus
for an Ogg Opus file.
Ogg Opusファイルの場合。
The RECOMMENDED filename extension for Ogg Opus files is '.opus'.
Ogg Opusファイルの推奨ファイル名拡張子は「.opus」です。
When Opus is concurrently multiplexed with other streams in an Ogg container, one SHOULD use one of the "audio/ogg", "video/ogg", or "application/ogg" mime-types, as defined in [RFC5334]. Such streams are not strictly "Ogg Opus files" as described above, since they contain more than a single Opus stream per sequentially multiplexed segment, e.g., video or multiple audio tracks. In such cases, the '.opus' filename extension is NOT RECOMMENDED.
[RFC5334]で定義されているように、OpusがOggコンテナー内の他のストリームと同時に多重化される場合、1つは「audio / ogg」、「video / ogg」、または「application / ogg」MIMEタイプのいずれかを使用する必要があります。このようなストリームは、上記のように厳密に「Ogg Opusファイル」ではありません。これは、ビデオや複数のオーディオトラックなど、順次多重化されたセグメントごとに複数のOpusストリームが含まれているためです。そのような場合、「。opus」ファイル名拡張子は推奨されません。
In either case, this document updates [RFC5334] to add "opus" as a codecs parameter value with char[8]: 'OpusHead' as Codec Identifier.
どちらの場合も、このドキュメントは[RFC5334]を更新して、char [8]を含むコーデックパラメータ値として「opus」を追加します：コーデック識別子として「OpusHead」。
Per this document, IANA has updated the "Media Types" registry by adding .opus as a file extension for "audio/ogg" and adding itself as a reference alongside [RFC5334] for "audio/ogg", "video/ogg", and "application/ogg" Media Types.
このドキュメントに従って、IANAは「オーディオタイプ」レジストリを更新し、「オーディオ/ ogg」のファイル拡張子として.opusを追加し、「オーディオ/ ogg」、「ビデオ/ ogg」の[RFC5334]とともにそれ自体を参照として追加しました。および「application / ogg」メディアタイプ。
This document defines a new registry "Opus Channel Mapping Families" to indicate how the semantic meanings of the channels in a multi-channel Opus stream are described. IANA has created a new namespace of "Opus Channel Mapping Families". This registry is listed on the IANA Matrix. Modifications to this registry follow the "Specification Required" registration policy as defined in [RFC5226]. Each registry entry consists of a Channel Mapping Family Number, which is specified in decimal in the range 0 to 255, inclusive, and a Reference (or list of references). Each Reference must point to sufficient documentation to describe what information is coded in the Opus identification header for this channel mapping family, how a demuxer determines the stream count ('N') and coupled stream count ('M') from this information, and how it determines the proper interpretation of each of the decoded channels.
このドキュメントでは、新しいレジストリ「Opus Channel Mapping Families」を定義して、マルチチャネルOpusストリームのチャネルのセマンティックな意味がどのように記述されるかを示します。 IANAは「Opus Channel Mapping Families」の新しい名前空間を作成しました。このレジストリはIANAマトリックスにリストされています。このレジストリへの変更は、[RFC5226]で定義されている「Specification Required」登録ポリシーに従います。各レジストリエントリは、0〜255の範囲で10進数で指定されるチャネルマッピングファミリ番号と、参照（または参照のリスト）で構成されます。各リファレンスは、このチャネルマッピングファミリのOpus識別ヘッダーでコーディングされる情報、デマルチプレクサがこの情報からストリームカウント（ 'N'）および結合ストリームカウント（ 'M'）をどのように決定するかを説明するのに十分なドキュメントを指す必要があります。デコードされた各チャネルの適切な解釈をどのように決定するか。
This document defines three initial assignments for this registry.
このドキュメントでは、このレジストリの3つの初期割り当てを定義しています。
+-------+---------------------------+
| Value | Reference |
+-------+---------------------------+
| 0 | RFC 7845, Section 5.1.1.1 |
| | |
| 1 | RFC 7845, Section 5.1.1.2 |
| | |
| 255 | RFC 7845, Section 5.1.1.3 |
+-------+---------------------------+
The designated expert will determine if the Reference points to a specification that meets the requirements for permanence and ready availability laid out in [RFC5226] and whether it specifies the information described above with sufficient clarity to allow interoperable implementations.
指定された専門家は、リファレンスが[RFC5226]に記載されている永続性と可用性の要件を満たす仕様を指しているかどうか、および相互運用可能な実装を可能にするために十分明確に上記の情報を指定しているかどうかを判断します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, DOI 10.17487/RFC3533, May 2003, <https://www.rfc-editor.org/info/rfc3533>.
[RFC3533] Pfeiffer、S。、「The Ogg Encapsulation Format Version 0 "、RFC 3533、DOI 10.17487 / RFC3533、2003年5月、<https://www.rfc-editor.org/info/rfc3533>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを記述するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<https://www.rfc-editor.org / info / rfc5226>。
[RFC5334] Goncalves, I., Pfeiffer, S., and C. Montgomery, "Ogg Media Types", RFC 5334, DOI 10.17487/RFC5334, September 2008, <https://www.rfc-editor.org/info/rfc5334>.
[RFC5334] Goncalves、I.、Pfeiffer、S。、およびC. Montgomery、「Ogg Media Types」、RFC 5334、DOI 10.17487 / RFC5334、2008年9月、<https://www.rfc-editor.org/info/ rfc5334>。
[RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types", RFC 6381, DOI 10.17487/RFC6381, August 2011, <https://www.rfc-editor.org/info/rfc6381>.
[RFC6381] Gellens、R.、Singer、D。、およびP. Frojdh、「「コーデック」および「プロファイル」パラメータの「バケット」メディアタイプ」、RFC 6381、DOI 10.17487 / RFC6381、2011年8月、<https： //www.rfc-editor.org/info/rfc6381>。
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <https://www.rfc-editor.org/info/rfc6716>.
[RFC6716] Valin、JM。、Vos、K。、およびT. Terriberry、「Definition of the Opus Audio Codec」、RFC 6716、DOI 10.17487 / RFC6716、2012年9月、<https://www.rfc-editor.org / info / rfc6716>。
[EBU-R128] EBU Technical Committee, "Loudness Recommendation EBU R128", August 2011, <https://tech.ebu.ch/loudness>.
[EBU-R128] EBU技術委員会、「ラウドネス推奨EBU R128」、2011年8月、<https://tech.ebu.ch/loudness>。
[VORBIS-COMMENT] Montgomery, C., "Ogg Vorbis I Format Specification: Comment Field and Header Specification", July 2002, <https://www.xiph.org/vorbis/doc/v-comment.html>.
[VORBIS-COMMENT]モンゴメリー、C。、「Ogg Vorbis Iフォーマット仕様：コメントフィールドとヘッダー仕様」、2002年7月、<https://www.xiph.org/vorbis/doc/v-comment.html>。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <https://www.rfc-editor.org/info/rfc4732>.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、Ed。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、DOI 10.17487 / RFC4732、2006年12月、<https：// www。 rfc-editor.org/info/rfc4732>。
[RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, <https://www.rfc-editor.org/info/rfc7587>.
[RFC7587] Spittka、J.、Vos、K。、およびJM。 Valin、「Opus Speech and Audio CodecのRTPペイロード形式」、RFC 7587、DOI 10.17487 / RFC7587、2015年6月、<https://www.rfc-editor.org/info/rfc7587>。
[FLAC] Coalson, J., "FLAC - Free Lossless Audio Codec Format Description", January 2008, <https://xiph.org/flac/format.html>.
[FLAC] Coalson、J。、「FLAC-Free Lossless Audio Codec Format Description」、2008年1月、<https://xiph.org/flac/format.html>。
[HANNING] Wikipedia, "Hann window", February 2016, <https://en.wikipedia.org/w/index.php?title=Window_functio n&oldid=703074467#Hann_.28Hanning.29_window>.
[ハニング]ウィキペディア、「ハンウィンドウ」、2016年2月、<https://en.wikipedia.org/w/index.php?title=Window_functio n＆oldid = 703074467＃Hann_.28Hanning.29_window>。
[LINEAR-PREDICTION] Wikipedia, "Linear Predictive Coding", October 2015, <https://en.wikipedia.org/w/ index.php?title=Linear_predictive_coding&oldid=687498962>.
[LINEAR-PREDICTION] Wikipedia、「Linear Predictive Coding」、2015年10月、<https://en.wikipedia.org/w/ index.php？title = Linear_predictive_coding＆oldid = 687498962>。
[LPC-SAMPLE] Degener, J. and C. Bormann, "Autocorrelation LPC coeff generation algorithm (Vorbis source code)", November 1994, <https://svn.xiph.org/trunk/vorbis/lib/lpc.c>.
[LPC-SAMPLE] Degener、J。およびC. Bormann、「自己相関LPC coeff生成アルゴリズム（Vorbisソースコード）」、1994年11月、<https://svn.xiph.org/trunk/vorbis/lib/lpc.c >。
[Q-NOTATION] Wikipedia, "Q (number format)", December 2015, <https://en.wikipedia.org/w/ index.php?title=Q_%28number_format%29&oldid=697252615>.
[Q-NOTATION]ウィキペディア、「Q（数値形式）」、2015年12月、<https://en.wikipedia.org/w/ index.php？title = Q_％28number_format％29＆oldid = 697252615>。
[REPLAY-GAIN] Parker, C. and M. Leese, "VorbisComment: Replay Gain", June 2009, <https://wiki.xiph.org/VorbisComment#Replay_Gain>.
[REPLAY-GAIN]パーカー、C。およびM.リース、「VorbisComment：Replay Gain」、2009年6月、<https://wiki.xiph.org/VorbisComment#Replay_Gain>。
[SEEKING] Pfeiffer, S., Parker, C., and G. Maxwell, "Granulepos Encoding and How Seeking Really Works", May 2012, <https://wiki.xiph.org/Seeking>.
[シーク] Pfeiffer、S.、Parker、C。、およびG. Maxwell、「Granulepos Encoding and How Seeking Really Works」、2012年5月、<https://wiki.xiph.org/Seeking>。
[VORBIS-MAPPING] Montgomery, C., "The Vorbis I Specification, Section 4.3.9 Output Channel Order", January 2010, <https://www.xiph.org/vorbis/doc/ Vorbis_I_spec.html#x1-810004.3.9>.
[VORBIS-MAPPING]モンゴメリー、C。、「Vorbis I仕様、セクション4.3.9出力チャネルの順序」、2010年1月、<https://www.xiph.org/vorbis/doc/ Vorbis_I_spec.html＃x1-810004.3 .9>。
[VORBIS-TRIM] Montgomery, C., "The Vorbis I Specification, Appendix A: Embedding Vorbis into an Ogg stream", November 2008, <https://xiph.org/vorbis/doc/ Vorbis_I_spec.html#x1-132000A.2>.
[VORBIS-TRIM]モンゴメリー、C。、「Vorbis I仕様、付録A：OggストリームへのVorbisの埋め込み」、2008年11月、<https://xiph.org/vorbis/doc/ Vorbis_I_spec.html＃x1-132000A .2>。
[WAVE-MULTICHANNEL] Microsoft Corporation, "Multiple Channel Audio Data and WAVE Files", March 2007, <https://msdn.microsoft.com/en-us/windows/hardware/ gg463006.aspx>.
[WAVE-MULTICHANNEL] Microsoft Corporation、「Multiple Channel Audio Data and WAVE Files」、2007年3月、<https://msdn.microsoft.com/en-us/windows/hardware/ gg463006.aspx>。
Acknowledgments
謝辞
Thanks to Ben Campbell, Joel M. Halpern, Mark Harris, Greg Maxwell, Christopher "Monty" Montgomery, Jean-Marc Valin, Stephan Wenger, and Mo Zanaty for their valuable contributions to this document. Additional thanks to Andrew D'Addesio, Greg Maxwell, and Vincent Penquerc'h for their feedback based on early implementations.
このドキュメントへの貴重な貢献をしてくれたベンキャンベル、ジョエルM.ハルパーン、マークハリス、グレッグマックスウェル、クリストファー "モンティ"モンゴメリー、ジャンマルクヴァリン、ステファンウェンガー、モーザナティに感謝します。初期の実装に基づくフィードバックについて、Andrew D'Addesio、Greg Maxwell、およびVincent Penquerc'hに感謝します。
Authors' Addresses
著者のアドレス
Timothy B. Terriberry Mozilla Corporation 331 E. Evelyn Ave. Mountain View, CA 94041 United States
Timothy B. Terriberry Mozilla Corporation 331 E. Evelyn Ave. Mountain View、CA 94041アメリカ合衆国
Phone: +1 650 903-0800
Email: tterribe@xiph.org
Ron Lee Voicetronix 246 Pulteney Street, Level 1 Adelaide, SA 5000 Australia
Ron Lee Voicetronix 246 Pulteney Street、Level 1 Adelaide、SA 5000 Australia
Phone: +61 8 8232 9112
Email: ron@debian.org
Ralph Giles Mozilla Corporation 163 West Hastings Street Vancouver, BC V6B 1H5 Canada
Ralph Giles Mozilla Corporation 163 West Hastings StreetバンクーバーBC V6B 1H5カナダ
Phone: +1 778 785 1540
Email: giles@xiph.org