Internet Engineering Task Force (IETF) M.Q.C. van Beurden
Request for Comments: 9639
Category: Standards Track A. Weaver
ISSN: 2070-1721 December 2024
This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals. It does this losslessly, i.e., it does so without losing information. FLAC is free in the sense that its specification is open and its reference implementation is open source. Compared to other lossless audio coding formats, FLAC is a format with low complexity and can be encoded and decoded with little computing resources. Decoding of FLAC has been implemented independently for many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic.
このドキュメントでは、無料のロスレスオーディオコーデック（FLAC）形式とそのストリーミング可能なサブセットを定義します。FLACは、デジタルオーディオ信号の保存に必要なコンピューターストレージスペースの量を減らすように設計されています。これは損失がなく、つまり、情報を失うことなくそうします。FLACは、その仕様が開かれており、参照実装がオープンソースであるという意味で無料です。他のロスレスオーディオコーディング形式と比較して、FLACは複雑さが低い形式であり、コンピューティングリソースがほとんどないエンコードおよびデコードできます。FLACのデコードは、多くの異なるプラットフォームに対して独立して実装されており、フローティングポイント算術を必要とせずにエンコードとデコードの両方を実装できます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9639.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9639で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Notation and Conventions
3. Definitions
4. Conceptual Overview
4.1. Blocking
4.2. Interchannel Decorrelation
4.3. Prediction
4.4. Residual Coding
5. Format Principles
6. Format Layout Overview
7. Streamable Subset
8. File-Level Metadata
8.1. Metadata Block Header
8.2. Streaminfo
8.3. Padding
8.4. Application
8.5. Seek Table
8.5.1. Seek Point
8.6. Vorbis Comment
8.6.1. Standard Field Names
8.6.2. Channel Mask
8.7. Cuesheet
8.7.1. Cuesheet Track
8.8. Picture
9. Frame Structure
9.1. Frame Header
9.1.1. Block Size Bits
9.1.2. Sample Rate Bits
9.1.3. Channels Bits
9.1.4. Bit Depth Bits
9.1.5. Coded Number
9.1.6. Uncommon Block Size
9.1.7. Uncommon Sample Rate
9.1.8. Frame Header CRC
9.2. Subframes
9.2.1. Subframe Header
9.2.2. Wasted Bits per Sample
9.2.3. Constant Subframe
9.2.4. Verbatim Subframe
9.2.5. Fixed Predictor Subframe
9.2.6. Linear Predictor Subframe
9.2.7. Coded Residual
9.3. Frame Footer
10. Container Mappings
10.1. Ogg Mapping
10.2. Matroska Mapping
10.3. ISO Base Media File Format (MP4) Mapping
11. Security Considerations
12. IANA Considerations
12.1. Media Type Registration
12.2. FLAC Application Metadata Block IDs Registry
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Numerical Considerations
A.1. Determining the Necessary Data Type Size
A.2. Stereo Decorrelation
A.3. Prediction
A.4. Residual
A.5. Rice Coding
Appendix B. Past Format Changes
B.1. Addition of Blocking Strategy Bit
B.2. Restriction of Encoded Residual Samples
B.3. Addition of 5-Bit Rice Parameters
B.4. Restriction of LPC Shift to Non-negative Values
Appendix C. Interoperability Considerations
C.1. Features outside of the Streamable Subset
C.2. Variable Block Size
C.3. 5-Bit Rice Parameters
C.4. Rice Escape Code
C.5. Uncommon Block Size
C.6. Uncommon Bit Depth
C.7. Multi-Channel Audio and Uncommon Sample Rates
C.8. Changing Audio Properties Mid-Stream
Appendix D. Examples
D.1. Decoding Example 1
D.1.1. Example File 1 in Hexadecimal Representation
D.1.2. Example File 1 in Binary Representation
D.1.3. Signature and Streaminfo
D.1.4. Audio Frames
D.2. Decoding Example 2
D.2.1. Example File 2 in Hexadecimal Representation
D.2.2. Example File 2 in Binary Representation (Only Audio
Frames)
D.2.3. Streaminfo Metadata Block
D.2.4. Seek Table
D.2.5. Vorbis Comment
D.2.6. Padding
D.2.7. First Audio Frame
D.2.8. Second Audio Frame
D.2.9. MD5 Checksum Verification
D.3. Decoding Example 3
D.3.1. Example File 3 in Hexadecimal Representation
D.3.2. Example File 3 in Binary Representation (Only Audio
Frame)
D.3.3. Streaminfo Metadata Block
D.3.4. Audio Frame
Acknowledgments
Authors' Addresses
This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC files and streams can code for pulse-code modulated (PCM) audio with 1 to 8 channels, sample rates from 1 to 1048575 hertz, and bit depths from 4 to 32 bits. Most tools for coding to and decoding from the FLAC format have been optimized for CD-audio, which is PCM audio with 2 channels, a sample rate of 44.1 kHz, and a bit depth of 16 bits.
このドキュメントでは、無料のロスレスオーディオコーデック（FLAC）形式とそのストリーミング可能なサブセットを定義します。FLACファイルとストリームは、1〜8チャンネル、1〜1048575 Hertz、および4〜32ビットのビット深度を備えたパルスコード変調（PCM）オーディオをコーディングできます。FLAC形式のコーディングとデコードのためのほとんどのツールは、2つのチャネル、44.1 kHzのサンプルレート、および16ビットの少し深さを備えたPCMオーディオであるCD-Audio向けに最適化されています。
FLAC is able to achieve lossless compression because samples in audio signals tend to be highly correlated with their close neighbors. In contrast with general-purpose compressors, which often use dictionaries, do run-length coding, or exploit long-term repetition, FLAC removes redundancy solely in the very short term, looking back at 32 samples at most.
FLACは、オーディオ信号のサンプルが近隣の隣人と高度に相関する傾向があるため、ロスレス圧縮を実現できます。しばしば辞書を使用したり、走行長のコーディングをしたり、長期的な繰り返しを活用したりする汎用コンプレッサーとは対照的に、FLACは非常に短期的にのみ冗長性を除去し、せいぜい32のサンプルを振り返ります。
The coding methods provided by the FLAC format work best on PCM audio signals with samples that have a signed representation and are centered around zero. Audio signals in which samples have an unsigned representation must be transformed to a signed representation as described in this document in order to achieve reasonable compression. The FLAC format is not suited for compressing audio that is not PCM.
FLAC形式によって提供されるコーディング方法は、署名された表現があり、ゼロを中心とするサンプルを使用して、PCMオーディオ信号で最適に機能します。合理的な圧縮を実現するために、このドキュメントで説明されているように、サンプルが署名されていない表現を持つオーディオ信号を署名した表現に変換する必要があります。FLAC形式は、PCMではないオーディオを圧縮するのに適していません。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Values expressed as u(n) represent an unsigned big-endian integer using n bits. Values expressed as s(n) represent a signed big-endian integer using n bits, signed two's complement. Where necessary, n is expressed as an equation using * (multiplication), / (division), + (addition), or - (subtraction). An inclusive range of the number of bits expressed is represented with an ellipsis, such as u(m...n).
u（n）として表される値は、nビットを使用して署名されていないビッグエンディアン整数を表します。s（n）として表される値は、nビットを使用して署名されたビッグエンディアンの整数を表し、署名された2の補数を表します。必要に応じて、nは *（乗算）、 /（分割）、 +（追加）、または - （減算）を使用した方程式として表されます。発現するビット数の包括的な範囲は、u（m ... n）などの楕円で表されます。
All shifts mentioned in this document are arithmetic shifts.
このドキュメントに記載されているすべてのシフトは、算術シフトです。
While the FLAC format can store digital audio as well as other digital signals, this document uses terminology specific to digital audio. The use of more generic terminology was deemed less clear, so a reader interested in non-audio use of the FLAC format is expected to make the translation from audio-specific terms to more generic terminology.
FLAC形式はデジタルオーディオと他のデジタル信号を保存できますが、このドキュメントではデジタルオーディオに固有の用語を使用します。より一般的な用語の使用はそれほど明確ではないと見なされたため、FLAC形式の非オーディオ使用に関心のある読者は、オーディオ固有の用語からより一般的な用語への翻訳を行うことが期待されています。
*Lossless compression*:
*ロスレス圧縮*：
Reducing the amount of computer storage space needed to store data without needing to remove or irreversibly alter any of this data in doing so. In other words, decompressing losslessly compressed information returns exactly the original data.
このデータを削除または不可逆的に変更する必要なく、データを保存するために必要なコンピューターストレージスペースの量を減らす。言い換えれば、損失のない圧縮情報を減圧すると、元のデータが正確に返されます。
*Lossy compression*:
*損失のある圧縮*：
Like lossless compression, but instead removing, irreversibly altering, or only approximating information for the purpose of further reducing the amount of computer storage space needed. In other words, decompressing lossy compressed information returns an approximation of the original data.
ロスレス圧縮のように、代わりに、必要なコンピューターストレージスペースの量をさらに削減する目的で、情報を削除、不可逆的に変更、または近似のみに近似します。言い換えれば、損失のある圧縮情報を減圧すると、元のデータの近似が返されます。
*Block*:
*ブロック*：
A (short) section of linear PCM audio with one or more channels.
1つ以上のチャネルを備えた線形PCMオーディオの（短い）セクション。
*Subblock*:
*サブブロック*：
All samples within a corresponding block for one channel. One or more subblocks form a block, and all subblocks in a certain block contain the same number of samples.
1つのチャネルの対応するブロック内のすべてのサンプル。1つ以上のサブブロックがブロックを形成し、特定のブロック内のすべてのサブブロックには同じ数のサンプルが含まれています。
*Frame*:
*フレーム*：
A frame header, one or more subframes, and a frame footer. It encodes the contents of a corresponding block.
フレームヘッダー、1つ以上のサブフレーム、およびフレームフッター。対応するブロックの内容をコードします。
*Subframe*:
*サブフレーム*：
An encoded subblock. All subframes within a frame code for the same number of samples. When interchannel decorrelation is used, a subframe can correspond to either the (per-sample) average of two subblocks or the (per-sample) difference between two subblocks, instead of to a subblock directly; see Section 4.2.
エンコードされたサブブロック。同じ数のサンプルのフレームコード内のすべてのサブフレーム。インターチャネルの切り相関を使用すると、サブフレームは、サブブロックの2つのサブブロックの（サンプルごとの）平均（サンプルごと）の差に直接対応できます。セクション4.2を参照してください。
*Interchannel samples*:
*インターチャネルサンプル*：
A sample count that applies to all channels. For example, one second of 44.1 kHz audio has 44100 interchannel samples, meaning each channel has that number of samples.
すべてのチャネルに適用されるサンプルカウント。たとえば、44.1 KHzオーディオの1秒には44100個のチャネルインターチャネルサンプルがあります。つまり、各チャネルにはその数のサンプルがあります。
*Block size*:
*ブロックサイズ*：
The number of interchannel samples contained in a block or coded in a frame.
ブロックに含まれるか、フレームにコード化されたインターチャネルサンプルの数。
*Bit depth* or *bits per sample*:
*サンプルごとにビット深さ*または*ビット*：
The number of bits used to contain each sample. This MUST be the same for all subblocks in a block but MAY be different for different subframes in a frame because of interchannel decorrelation. (See Section 4.2 for details on interchannel decorrelation.)
各サンプルを含むために使用されるビット数。これは、ブロック内のすべてのサブブロックで同じである必要がありますが、チャネル間の切り相関があるため、フレーム内の異なるサブフレームで異なる場合があります。（インターチャンネルの切り相関の詳細については、セクション4.2を参照してください。）
*Predictor*:
*予測因子*：
A model used to predict samples in an audio signal based on past samples. FLAC uses such predictors to remove redundancy in a signal in order to be able to compress it.
過去のサンプルに基づいてオーディオ信号のサンプルを予測するために使用されるモデル。FLACは、このような予測因子を使用して、信号の冗長性を削除して圧縮できるようにします。
*Linear predictor*:
*線形予測因子*：
A predictor using linear prediction (see [LinearPrediction]). This is also called *linear predictive coding (LPC)*. With a linear predictor, each prediction is a linear combination of past samples (hence the name). A linear predictor has a causal discrete-time finite impulse response (see [FIR]).
線形予測を使用した予測因子（[線形予測]を参照）。これは、 *線形予測コーディング（LPC） *とも呼ばれます。線形予測因子を使用すると、各予測は過去のサンプルの線形結合です（したがって名前）。線形予測因子には、因果的な離散時間有限インパルス応答があります（[FIR]を参照）。
*Fixed predictor*:
*予測因子を修正*：
A linear predictor in which the model parameters are the same across all FLAC files and thus do not need to be stored.
モデルパラメーターがすべてのFLACファイルで同じであるため、保存する必要はない線形予測因子。
*Predictor order*:
*予測因子順序*：
The number of past samples that a predictor uses. For example, a 4th order predictor uses the 4 samples directly preceding a certain sample to predict it. In FLAC, samples used in a predictor are always consecutive and are always the samples directly before the sample that is being predicted.
予測子が使用する過去のサンプルの数。たとえば、4次予測子は、特定のサンプルの直前の4つのサンプルを使用して予測します。FLACでは、予測子で使用されるサンプルは常に連続しており、常に予測されているサンプルの直前のサンプルです。
*Residual*:
*残差*：
The audio signal that remains after a predictor has been subtracted from a subblock. If the predictor has been able to remove redundancy from the signal, the samples of the remaining signal (the *residual samples*) will have, on average, a numerical value closer to zero than the original signal.
予測子がサブブロックから差し引かれた後に残るオーディオ信号。予測子が信号から冗長性を削除できた場合、残りの信号（ *残差サンプル *）のサンプルには、平均して、元の信号よりもゼロに近い数値があります。
*Rice code*:
*稲法*：
A variable-length code (see [VarLengthCode]). It uses a short code for samples close to zero and a progressively longer code for samples further away from zero. This makes use of the observation that residual samples are often close to zero.
変数長コード（[varlengthcode]を参照）。ゼロに近いサンプルには短いコードを使用し、ゼロから遠く離れたサンプルに次第に長いコードを使用します。これにより、残留サンプルはしばしばゼロに近いという観察が利用されます。
*Muxing*:
*マクシング*：
Short for multiplexing. Combining several streams or files into a single stream or file. In the context of this document, muxing specifically refers to embedding a FLAC stream in a container as described in Section 10.
多重化の略。いくつかのストリームまたはファイルを単一のストリームまたはファイルに結合します。このドキュメントのコンテキストでは、Muxingは、セクション10で説明されているように、コンテナにFLACストリームを埋め込むことを特に指します。
Similar to many other audio coders, a FLAC file is encoded following the steps below. To decode a FLAC file, these steps are performed in reverse order, i.e., from bottom to top.
他の多くのオーディオコーダーと同様に、FLACファイルは以下の手順に従ってエンコードされています。FLACファイルをデコードするには、これらの手順は逆の順序で、つまり下から上に実行されます。
1. *Blocking* (see Section 4.1). The input is split up into many contiguous blocks.
1. *ブロック*（セクション4.1を参照）。入力は、多くの連続したブロックに分割されます。
2. *Interchannel Decorrelation* (see Section 4.2). In the case of stereo streams, the FLAC format allows for transforming the left-right signal into a mid-side signal, a left-side signal, or a side-right signal to remove redundancy between channels. Choosing between any of these transformations is done independently for each block.
2. *交換相関関係*（セクション4.2を参照）。ステレオストリームの場合、FLAC形式では、左右信号をミッドサイド信号、左側信号、またはチャネル間の冗長性を除去する側面右信号に変換できます。これらの変換のいずれかを選択することは、各ブロックに対して個別に行われます。
3. *Prediction* (see Section 4.3). To remove redundancy in a signal, a predictor is stored for each subblock or its transformation as formed in the previous step. A predictor consists of a simple mathematical description that can be used, as the name implies, to predict a certain sample from the samples that preceded it. As this prediction is rarely exact, the error of this prediction is passed on to the next stage. The predictor of each subblock is completely independent from other subblocks. Since the methods of prediction are known to both the encoder and decoder, only the parameters of the predictor need to be included in the compressed stream. If no usable predictor can be found for a certain subblock, the signal is stored uncompressed, and the next stage is skipped.
3. *予測*（セクション4.3を参照）。信号の冗長性を削除するために、前のステップで形成された各サブブロックまたはその変換に対して予測子が保存されます。予測因子は、名前が示すように、それに先行するサンプルから特定のサンプルを予測するために使用できる単純な数学的説明で構成されています。この予測はめったに正確ではないため、この予測の誤差は次の段階に渡されます。各サブブロックの予測因子は、他のサブブロックから完全に独立しています。予測の方法はエンコーダーとデコーダーの両方に知られているため、予測子のパラメーターのみを圧縮ストリームに含める必要があります。特定のサブブロックに対して使用可能な予測子が見つからない場合、信号は圧縮されていない保存され、次の段階がスキップされます。
4. *Residual Coding* (see Section 4.4). As the predictor does not describe the signal exactly, the difference between the original signal and the predicted signal (called the error or residual signal) is coded losslessly. If the predictor is effective, the residual signal will require fewer bits per sample than the original signal. FLAC uses Rice coding, a subset of Golomb coding, with either 4-bit or 5-bit parameters to code the residual signal.
4. *残留コーディング*（セクション4.4を参照）。予測子は信号を正確に記述していないため、元の信号と予測信号（エラーまたは残差信号と呼ばれる）の違いは損失を及ぼさないほどコード化されます。予測子が有効な場合、残差信号は元の信号よりもサンプルあたりのビットが少なくなります。FLACは、残差信号をコーディングするために、4ビットまたは5ビットパラメーターを備えたGolombコーディングのサブセットであるRice Codingを使用します。
In addition, FLAC specifies a metadata system (see Section 8) that allows arbitrary information about the stream to be included at the beginning of the stream.
さらに、FLACは、ストリームの開始時にストリームに関する任意の情報を含めるメタデータシステム（セクション8を参照）を指定します。
The block size used for audio data has a direct effect on the compression ratio. If the block size is too small, the resulting large number of frames means that a disproportionate number of bytes will be spent on frame headers. If the block size is too large, the characteristics of the signal may vary so much that the encoder will be unable to find a good predictor. In order to simplify encoder/ decoder design, FLAC imposes a minimum block size of 16 samples, except for the last block, and a maximum block size of 65535 samples. The last block is allowed to be smaller than 16 samples to be able to match the length of the encoded audio without using padding.
オーディオデータに使用されるブロックサイズは、圧縮比に直接的な影響を及ぼします。ブロックサイズが小さすぎる場合、結果として生じる多くのフレームは、フレームヘッダーに不均衡な数のバイト数が使用されることを意味します。ブロックサイズが大きすぎると、信号の特性が大きく異なる場合があるため、エンコーダーは適切な予測因子を見つけることができません。エンコーダー/デコーダー設計を簡素化するために、FLACは、最後のブロックを除き、16のサンプルの最小ブロックサイズと65535サンプルの最大ブロックサイズを課します。最後のブロックは、パディングを使用せずにエンコードされたオーディオの長さを一致させるために、16枚未満のサンプルになります。
While the block size does not have to be constant in a FLAC file, it is often difficult to find the optimal arrangement of block sizes for maximum compression. Because of this, a FLAC stream has explicitly either a constant or variable block size throughout and stores a block number instead of a sample number to slightly improve compression if a stream has a constant block size.
ブロックサイズはFLACファイルで一定である必要はありませんが、最大圧縮のためにブロックサイズの最適な配置を見つけることはしばしば困難です。このため、FLACストリームは、全体に一定または可変ブロックサイズを明示的に備えており、サンプル番号の代わりにブロック番号を保存して、ストリームに一定のブロックサイズがある場合は圧縮をわずかに改善します。
Channels are correlated in many audio files. The FLAC format can exploit this correlation in stereo files by coding an average of all samples in both subblocks (a mid channel) or the difference between all samples in both subblocks (a side channel) instead of directly coding subblocks into subframes. The following combinations are possible:
チャネルは多くのオーディオファイルで相関しています。FLAC形式は、サブブロックをサブフレームに直接コーディングする代わりに、両方のサブブロック（ミッドチャネル）のすべてのサンプルの平均または両方のサブブロック（サイドチャネル）のすべてのサブブロックの平均をコーディングすることにより、ステレオファイルのこの相関を活用できます。次の組み合わせが可能です。
* *Independent*. All channels are coded independently. All non-stereo files MUST be encoded this way.
* *独立した*。すべてのチャネルは独立してコーディングされます。すべての非ステレオファイルはこの方法でエンコードする必要があります。
* *Mid-side*. A left and right subblock are converted to mid and side subframes. To calculate a sample for a mid subframe, the corresponding left and right samples are summed, and the result is shifted right by 1 bit. To calculate a sample for a side subframe, the corresponding right sample is subtracted from the corresponding left sample. On decoding, all mid channel samples have to be shifted left by 1 bit. Also, if a side channel sample is odd, 1 has to be added to the corresponding mid channel sample after it has been shifted left by 1 bit. To reconstruct the left channel, the corresponding samples in the mid and side subframes are added and the result shifted right by 1 bit. For the right channel, the side channel has to be subtracted from the mid channel and the result shifted right by 1 bit.
* *ミッドサイド*。左右のサブブロックは、ミッドサブフレームとサイドサブフレームに変換されます。ミッドサブフレームのサンプルを計算するために、対応する左右のサンプルが合計され、結果は1ビットずつシフトします。サイドサブフレームのサンプルを計算するには、対応する右サンプルが対応する左サンプルから差し引かれます。デコードでは、すべてのミッドチャネルサンプルを1ビット左にシフトする必要があります。また、サイドチャネルサンプルが奇数の場合、1ビットの残りをシフトした後、対応するミッドチャネルサンプルに1を追加する必要があります。左チャネルを再構築するために、中央および側面のサブフレームの対応するサンプルが追加され、結果が1ビット右にシフトしました。右チャネルの場合、サイドチャネルをミッドチャネルから差し引く必要があり、結果は1ビット右にシフトしました。
* *Left-side*. The left subblock is coded, and the left and right subblocks are used to code a side subframe. The side subframe is constructed in the same way as for mid-side. To decode, the right subblock is restored by subtracting the samples in the side subframe from the corresponding samples in the left subframe.
* *左側*。左サブブロックがコード化されており、左右のサブブロックを使用してサイドサブフレームをコーディングします。サイドサブフレームは、ミッドサイドと同じ方法で構築されます。デコードするには、右サブブロックが左サブフレームの対応するサンプルからサイドサブフレームのサンプルを差し引くことで復元されます。
* *Side-right*. The left and right subblocks are used to code a side subframe, and the right subblock is coded. The side subframe is constructed in the same way as for mid-side. To decode, the left subblock is restored by adding the samples in the side subframe to the corresponding samples in the right subframe.
* *side-right*。左右のサブブロックは、サイドサブフレームのコーディングに使用され、右サブブロックがコーディングされています。サイドサブフレームは、ミッドサイドと同じ方法で構築されます。デコードするには、右サブフレームのサンプルを右サブフレームの対応するサンプルに追加することにより、左サブブロックが復元されます。
The side channel needs one extra bit of bit depth, as the subtraction can produce sample values twice as large as the maximum possible in any given bit depth. The mid channel in mid-side stereo does not need one extra bit, as it is shifted right 1 bit. The right shift of the mid channel does not lead to lossy behavior because an odd sample in the mid subframe must always be accompanied by a corresponding odd sample in the side subframe, which means the lost least-significant bit can be restored by taking it from the sample in the side subframe.
サイドチャネルには、減算が任意のビット深度で可能な最大値の2倍のサンプル値を生成できるため、ビットの深さを1つ追加する必要があります。ミッドサイドステレオのミッドチャネルは、1ビットにシフトされているため、追加のビットは必要ありません。ミッドチャネルの正しいシフトは、ミッドサブフレームの奇数サンプルには常にサイドサブフレームに対応する奇数サンプルを添付する必要があるため、損失のある動作につながりません。サイドサブフレームのサンプル。
The FLAC format has four methods for modeling the input signal:
FLAC形式には、入力信号をモデル化する4つの方法があります。
1. *Verbatim*. Samples are stored directly, without any modeling. This method is used for inputs with little correlation. Since the raw signal is not actually passed through the residual coding stage (it is added to the stream "verbatim"), this method is different from using a zero-order fixed predictor.
1. *Verbatim*。サンプルは、モデリングなしで直接保存されます。この方法は、ほとんど相関関係がない入力に使用されます。生の信号は実際には残留コーディング段階を通過しないため（ストリーム「逐語」）、この方法はゼロオーダー固定予測子を使用することとは異なります。
2. *Constant*. A single sample value is stored. This method is used whenever a signal is pure DC ("digital silence"), i.e., a constant value throughout.
2. *絶え間ない*。単一のサンプル値が保存されます。この方法は、信号が純粋なDC（「デジタルサイレンス」）、つまり全体の一定の値である場合はいつでも使用されます。
3. *Fixed predictor*. Samples are predicted with one of five fixed (i.e., predefined) predictors, and the error of this prediction is processed by the residual coder. These fixed predictors are well suited for predicting simple waveforms. Since the predictors are fixed, no predictor coefficients are stored. From a mathematical point of view, the predictors work by extrapolating the signal from the previous samples. The number of previous samples used is equal to the predictor order. For more information, see Section 9.2.5.
3. *予測因子を修正*。サンプルは、5つの固定（つまり、事前定義された）予測因子のいずれかで予測され、この予測の誤差は残差コーダーによって処理されます。これらの固定予測因子は、単純な波形を予測するのに適しています。予測因子は固定されているため、予測係数は保存されません。数学的な観点から、予測因子は以前のサンプルから信号を外挿することにより機能します。以前のサンプルの数は、予測順に等しくなります。詳細については、セクション9.2.5を参照してください。
4. *Linear predictor*. Samples are predicted using past samples and a set of predictor coefficients, and the error of this prediction is processed by the residual coder. Compared to a fixed predictor, using a generic linear predictor adds overhead as predictor coefficients need to be stored. Therefore, this method of prediction is best suited for predicting more complex waveforms, where the added overhead is offset by space savings in the residual coding stage resulting from more accurate prediction. A linear predictor in FLAC has two parameters besides the predictor coefficients and the predictor order: the number of bits with which each coefficient is stored (the coefficient precision) and a prediction right shift. A prediction is formed by taking the sum of multiplying each predictor coefficient with the corresponding past sample and dividing that sum by applying the specified right shift. For more information, see Section 9.2.6.
4. *線形予測因子*。サンプルは、過去のサンプルと一連の予測係数を使用して予測され、この予測の誤差は残差コーダーによって処理されます。固定予測子と比較して、一般的な線形予測因子を使用すると、予測係数を保存する必要があるためオーバーヘッドが追加されます。したがって、この予測の方法は、より正確な予測に起因する残留コーディング段階でのスペースの節約により、より複雑な波形を予測するのに最適です。FLACの線形予測因子には、予測係数と予測因子の順序以外に2つのパラメーターがあります。各係数が保存されるビット数（係数精度）と予測の正しいシフトです。予測は、各予測子係数に対応する過去のサンプルを掛け、指定された右シフトを適用してその合計を分割することによって形成されます。詳細については、セクション9.2.6を参照してください。
A FLAC encoder is free to select any of the above methods to model the input. However, to ensure lossless coding, the following exceptions apply:
FLACエンコーダーは、入力をモデル化するための上記の方法のいずれかを自由に選択できます。ただし、ロスレスコーディングを確保するには、次の例外が適用されます。
* When the samples that need to be stored do not all have the same value (i.e., the signal is not constant), a constant subframe cannot be used.
* 保存する必要があるサンプルがすべて同じ値を持っているわけではない場合（つまり、信号は一定ではありません）、一定のサブフレームを使用できません。
* When an encoder is unable to find a fixed or linear predictor for which all residual samples are representable in 32-bit signed integers as stated in Section 9.2.7, a verbatim subframe is used.
* セクション9.2.7に記載されているように、すべての残差サンプルが32ビットの署名された整数で表される固定または線形予測因子をエンコーダが見つけることができない場合、逐語的なサブフレームが使用されます。
For more information on fixed and linear predictors, see [Lossless-Compression] and [Robinson-TR156].
固定および線形予測因子の詳細については、[ロブンソン-TR156]を参照してください。
If a subframe uses a predictor to approximate the audio signal, a residual is stored to "correct" the approximation to the exact value. When an effective predictor is used, the average numerical value of the residual samples is smaller than that of the samples before prediction. While having smaller values on average, it is possible that a few "outlier" residual samples are much larger than any of the original samples. Sometimes these outliers even exceed the range that the bit depth of the original audio offers.
サブフレームが予測子を使用してオーディオ信号を近似する場合、残差は正確な値の近似を「修正」するように保存されます。効果的な予測因子を使用すると、残差サンプルの平均数値値は、予測前のサンプルの平均値よりも小さくなります。平均して値が小さい一方で、いくつかの「外れ値」残差サンプルが元のサンプルのいずれよりもはるかに大きい可能性があります。これらの外れ値は、元のオーディオのビット深度が提供する範囲を超えることがあります。
To efficiently code such a stream of relatively small numbers with an occasional outlier, Rice coding (a subset of Golomb coding) is used. Depending on how small the numbers are that have to be coded, a Rice parameter is chosen. The numerical value of each residual sample is split into two parts by dividing it by 2^(Rice parameter), creating a quotient and a remainder. The quotient is stored in unary form and the remainder in binary form. If indeed most residual samples are close to zero and a suitable Rice parameter is chosen, this form of coding, with a so-called variable-length code, uses fewer bits than the residual in unencoded form.
比較的少数のこのようなストリームを時折外れ値で効率的にコーディングするには、米コーディング（ゴロンコーディングのサブセット）が使用されます。コード化する必要がある数値がどれだけ少ないかに応じて、イネパラメーターが選択されます。各残差サンプルの数値は、2^（Riceパラメーター）で割ることにより、2つの部分に分割され、商と残りを作成します。商は単位形式で保存され、残りはバイナリ形式で保存されます。実際にほとんどの残留サンプルがゼロに近く、適切なイネパラメーターが選択されている場合、いわゆる可変長コードを使用したこの形式のコーディングは、エンコードされていない形の残差よりも少ないビットを使用します。
As Rice codes can only handle unsigned numbers, signed numbers are zigzag encoded to a so-called folded residual. See Section 9.2.7 for a more thorough explanation.
イネコードは署名されていない数値のみを処理できるため、署名された数値は、いわゆる折り畳まれた残留物にエンコードされたzigzagです。より徹底的な説明については、セクション9.2.7を参照してください。
Quite often, the optimal Rice parameter varies over the course of a subframe. To accommodate this, the residual can be split up into partitions, where each partition has its own Rice parameter. To keep overhead and complexity low, the number of partitions used in a subframe is limited to powers of two.
多くの場合、最適な米パラメーターはサブフレームの過程で変化します。これに対応するために、残差はパーティションに分割できます。各パーティションには独自のイネパラメーターがあります。オーバーヘッドと複雑さを低く保つために、サブフレームで使用されるパーティションの数は2つのパワーに限定されます。
The FLAC format uses two forms of Rice coding, which only differ in the number of bits used for encoding the Rice parameter, either 4 or 5 bits.
FLAC形式では、2つのフォームのイネコーディングを使用します。これは、4ビットまたは5ビットのライスパラメーターをエンコードするために使用されるビットの数のみが異なります。
FLAC has no format version information, but it does contain reserved space in several places. Future versions of the format MAY use this reserved space safely without breaking the format of older streams. Older decoders MAY choose to abort decoding when encountering data that is encoded using methods they do not recognize. Apart from reserved patterns, the format specifies forbidden patterns in certain places, meaning that the patterns MUST NOT appear in any bitstream. They are listed in the following table.
FLACにはフォーマットバージョン情報はありませんが、いくつかの場所に予約スペースが含まれています。フォーマットの将来のバージョンは、古いストリームの形式を破ることなく、この予約スペースを安全に使用する場合があります。古いデコーダーは、認識されていないメソッドを使用してエンコードされたデータに遭遇する場合にデコードを中止することを選択できます。予約されたパターンとは別に、この形式は特定の場所で禁止されたパターンを指定します。つまり、パターンはどのビットストリームにも表示されてはなりません。次の表にリストされています。
+=========================================+=============+
| Description | Reference |
+=========================================+=============+
| Metadata block type 127 | Section 8.1 |
+-----------------------------------------+-------------+
| Minimum and maximum block sizes smaller | Section 8.2 |
| than 16 in streaminfo metadata block | |
+-----------------------------------------+-------------+
| Sample rate bits 0b1111 | Section |
| | 9.1.2 |
+-----------------------------------------+-------------+
| Uncommon block size 65536 | Section |
| | 9.1.6 |
+-----------------------------------------+-------------+
| Predictor coefficient precision bits | Section |
| 0b1111 | 9.2.6 |
+-----------------------------------------+-------------+
| Negative predictor right shift | Section |
| | 9.2.6 |
+-----------------------------------------+-------------+
Table 1
All numbers used in a FLAC bitstream are integers; there are no floating-point representations. All numbers are big-endian coded, except the field lengths used in Vorbis comments (see Section 8.6), which are little-endian coded. This exception for Vorbis comments is to keep as much commonality as possible with Vorbis comments as used by the Vorbis codec (see [Vorbis]). All numbers are unsigned except linear predictor coefficients, the linear prediction shift (see Section 9.2.6), and numbers that directly represent samples, which are signed. None of these restrictions apply to application metadata blocks or to Vorbis comment field contents.
FLACビットストリームで使用されるすべての数値は整数です。浮動小数点表現はありません。すべての数字は、Vorbisのコメントで使用されているフィールドの長さ（セクション8.6を参照）を除き、小さなエンディアンコード化されています。Vorbisコメントのこの例外は、Vorbis Codecで使用されているVorbisコメントと可能な限り多くの共通性を維持することです（[Vorbis]を参照）。すべての数値は、線形予測係数、線形予測シフト（セクション9.2.6を参照）、および署名されたサンプルを直接表す数値を除き、署名されていません。これらの制限はいずれも、アプリケーションメタデータブロックやVorbisコメントフィールドの内容には適用されません。
All samples encoded to and decoded from the FLAC format MUST be in a signed representation.
FLAC形式にエンコードされてデコードされたすべてのサンプルは、署名された表現である必要があります。
There are several ways to convert unsigned sample representations to signed sample representations, but the coding methods provided by the FLAC format work best on samples that have numerical values that are centered around zero, i.e., have no DC offset. In most unsigned audio formats, signals are centered around halfway within the range of the unsigned integer type used. If that is the case, converting sample representations by first copying the number to a signed integer with a sufficient range and then subtracting half of the range of the unsigned integer type results in a signal with samples centered around 0.
署名されていないサンプル表現を署名されたサンプル表現に変換する方法はいくつかありますが、FLAC形式によって提供されるコーディング方法は、ゼロを中心とする数値、つまりDCオフセットを持たないサンプルで最適に機能します。ほとんどの符号なしのオーディオ形式では、信号は使用されている署名されていない整数型の範囲内の中心にあります。その場合、最初に数字を十分な範囲の署名整数にコピーしてサンプル表現を変換し、次に署名されていない整数型の範囲の半分を減算すると、サンプルが0を中心となる信号が得られます。
Unary coding in a FLAC bitstream is done with zero bits terminated with a one bit, e.g., the number 5 is coded unary as 0b000001. This prevents the frame sync code from appearing in unary-coded numbers.
FLACビットストリームでの単位コーディングは、1ビットで終了したゼロビットで行われます。たとえば、ナンバー5は0B000001と統一されます。これにより、フレーム同期コードが単位コーディングされた数字で表示されないようにします。
When a FLAC file contains data that is forbidden or otherwise not valid, decoder behavior is left unspecified. A decoder MAY choose to stop decoding upon encountering such data. Examples of such data include the following:
FLACファイルに禁止されている、または無効なデータが含まれている場合、デコーダーの動作は不特定のままになります。デコーダーは、そのようなデータに遭遇したときにデコードを停止することを選択できます。そのようなデータの例には、以下が含まれます。
* One or more decoded sample values exceed the range offered by the bit depth as coded for that frame. For example, in a frame with a bit depth of 8 bits, any samples not in the inclusive range from -128 to 127 are not valid.
* 1つ以上のデコードされたサンプル値は、そのフレームにコード化されたビット深度によって提供される範囲を超えています。たとえば、8ビットの深さが少しあるフレームでは、-128〜127までの包括的な範囲にないサンプルは無効です。
* The number of wasted bits (see Section 9.2.2) used by a subframe is such that the bit depth of that subframe (see Section 9.2.3 for a description of subframe bit depth) equals zero or is negative.
* サブフレームで使用される無駄なビットの数（セクション9.2.2を参照）は、そのサブフレームのビット深さ（サブフレームビット深度の説明についてはセクション9.2.3を参照）がゼロに等しいか負のものです。
* A frame header Cyclic Redundancy Check (CRC) (see Section 9.1.8) or frame footer CRC (see Section 9.3) does not validate.
* フレームヘッダーサイクリック冗長チェック（CRC）（セクション9.1.8を参照）またはフレームフッターCRC（セクション9.3を参照）は検証しません。
* One of the forbidden bit patterns described in Table 1 is used.
* 表1で説明する禁じられたビットパターンの1つが使用されます。
A FLAC bitstream consists of the fLaC (i.e., 0x664C6143) marker at the beginning of the stream, followed by a mandatory metadata block (called the streaminfo metadata block), any number of other metadata blocks, and then the audio frames.
FLACビットストリームは、ストリームの先頭にFLAC（つまり、0x664C6143）マーカーで構成され、その後、必須のメタデータブロック（Streaminfoメタデータブロックと呼ばれる）、他の任意の数のメタデータブロック、次にオーディオフレームが続きます。
FLAC supports 127 kinds of metadata blocks; currently, 7 kinds are defined in Section 8.
FLACは、127種類のメタデータブロックをサポートしています。現在、7種類はセクション8で定義されています。
The audio data is composed of one or more audio frames. Each frame consists of a frame header that contains a sync code, information about the frame (like the block size, sample rate, and number of channels), and an 8-bit CRC. The frame header also contains either the sample number of the first sample in the frame (for variable block size streams) or the frame number (for fixed block size streams). This allows for fast, sample-accurate seeking to be performed. Following the frame header are encoded subframes, one for each channel. The frame is then zero-padded to a byte boundary and finished with a frame footer containing a checksum for the frame. Each subframe has its own header that specifies how the subframe is encoded.
オーディオデータは、1つ以上のオーディオフレームで構成されています。各フレームは、同期コード、フレームに関する情報（ブロックサイズ、サンプルレート、チャネル数など）、および8ビットCRCを含むフレームヘッダーで構成されています。フレームヘッダーには、フレーム内の最初のサンプルのサンプル番号（可変ブロックサイズストリームの場合）またはフレーム番号（固定ブロックサイズストリームの場合）も含まれます。これにより、迅速でサンプルが順応性の高い探求が可能になります。フォローフレームヘッダーは、各チャネルに1つのエンコードされたサブフレームです。その後、フレームはバイト境界にゼロパッドされ、フレームのチェックサムを含むフレームフッターで仕上げられます。各サブフレームには、サブフレームのエンコード方法を指定する独自のヘッダーがあります。
In order to allow a decoder to start decoding at any place in the stream, each frame starts with a byte-aligned 15-bit sync code. However, since it is not guaranteed that the sync code does not appear elsewhere in the frame, the decoder can check that it synced correctly by parsing the rest of the frame header and validating the frame header CRC.
デコーダーがストリーム内の任意の場所でデコードを開始できるようにするために、各フレームはバイトに並べられた15ビット同期コードで始まります。ただし、同期コードがフレームの他の場所に表示されないことは保証されていないため、デコーダーはフレームヘッダーの残りの部分を解析し、フレームヘッダーCRCを検証することにより正しく同期していることを確認できます。
Furthermore, to allow a decoder to start decoding at any place in the stream even without having received a streaminfo metadata block, each frame header contains some basic information about the stream. This information includes sample rate, bits per sample, number of channels, etc. Since the frame header is overhead, it has a direct effect on the compression ratio. To keep the frame header as small as possible, FLAC uses lookup tables for the most commonly used values for frame properties. When a certain property has a value that is not covered by the lookup table, the decoder is directed to find the value of that property (for example, the sample rate) at the end of the frame header or in the streaminfo metadata block. If a frame header refers to the streaminfo metadata block, the file is not "streamable"; see Section 7 for details. By using lookup tables, the file is streamable and the frame header size is small for the most common forms of audio data.
さらに、Streaminfoメタデータブロックを受け取っていなくても、デコーダーがストリーム内の任意の場所でデコードを開始できるようにするために、各フレームヘッダーにはストリームに関する基本情報が含まれています。この情報には、サンプルレート、サンプルあたりのビット、チャネル数などが含まれます。フレームヘッダーは頭上であるため、圧縮率に直接的な影響があります。フレームヘッダーをできるだけ小さく保つために、FLACはフレームプロパティで最も一般的に使用される値にルックアップテーブルを使用します。特定のプロパティにルックアップテーブルでカバーされていない値がある場合、デコーダーは、フレームヘッダーの端またはstreaminfoメタデータブロックでそのプロパティの値（サンプルレートなど）を見つけるように指示されます。フレームヘッダーがStreaminfoメタデータブロックを指す場合、ファイルは「ストリーミング可能」ではありません。詳細については、セクション7を参照してください。ルックアップテーブルを使用することにより、ファイルはストリーミング可能であり、最も一般的なフォームのオーディオデータに対してフレームヘッダーサイズは小さくなります。
Individual subframes (one for each channel) are coded separately within a frame and appear serially in the stream. In other words, the encoded audio data is NOT channel-interleaved. This reduces decoder complexity at the cost of requiring larger decode buffers. Each subframe has its own header specifying the attributes of the subframe, like prediction method and order, residual coding parameters, etc. Each subframe header is followed by the encoded audio data for that channel.
個々のサブフレーム（各チャネルに1つ）は、フレーム内で個別にコーディングされ、ストリーム内に連続的に表示されます。言い換えれば、エンコードされたオーディオデータはチャネル介入ではありません。これにより、より大きなデコードバッファーを必要とするコストでデコーダーの複雑さが減少します。各サブフレームには、予測方法や順序、残留コーディングパラメーターなど、サブフレームの属性を指定する独自のヘッダーがあります。各サブフレームヘッダーの後に、そのチャネルのエンコードされたオーディオデータが続きます。
The FLAC format specifies a subset of itself as the FLAC streamable subset. The purpose of this is to ensure that any streams encoded according to this subset are truly "streamable", meaning that a decoder that cannot seek within the stream can still pick up in the middle of the stream and start decoding. It also makes hardware decoder implementations more practical by limiting the encoding parameters in such a way that decoder buffer sizes and other resource requirements can be easily determined. The streamable subset makes the following limitations on what MAY be used in the stream:
FLAC形式は、FLACストリーミング可能なサブセットとしてそれ自体のサブセットを指定します。これの目的は、このサブセットに従ってエンコードされたストリームが本当に「ストリーミング可能」であることを確認することです。つまり、ストリーム内で探すことができないデコーダーは、ストリームの中央でピックアップしてデコードを開始できることを意味します。また、デコーダーバッファーサイズやその他のリソース要件を簡単に決定できるように、エンコードパラメーターを制限することにより、ハードウェアデコーダーの実装をより実用的にします。ストリーム可能なサブセットは、ストリームで使用できるものに次の制限を作成します。
* The sample rate bits (see Section 9.1.2) in the frame header MUST be 0b0001-0b1110, i.e., the frame header MUST NOT refer to the streaminfo metadata block to describe the sample rate.
* フレームヘッダーのサンプルレートビット（セクション9.1.2を参照）は0B0001-0B1110でなければなりません。つまり、フレームヘッダーは、サンプルレートを記述するためにStreaminfoメタデータブロックを参照してはなりません。
* The bit depth bits (see Section 9.1.4) in the frame header MUST be 0b001-0b111, i.e., the frame header MUST NOT refer to the streaminfo metadata block to describe the bit depth.
* フレームヘッダーのビット深度ビット（セクション9.1.4を参照）は0B001-0B111でなければなりません。つまり、フレームヘッダーは、ビット深度を記述するためにStreaminfoメタデータブロックを参照してはなりません。
* The stream MUST NOT contain blocks with more than 16384 interchannel samples, i.e., the maximum block size must not be larger than 16384.
* ストリームには、16384を超えるチャンネルサンプルを持つブロックを含めてはなりません。つまり、最大ブロックサイズは16384を超えてはなりません。
* Audio with a sample rate less than or equal to 48000 Hz MUST NOT be contained in blocks with more than 4608 interchannel samples, i.e., the maximum block size used for this audio must not be larger than 4608.
* サンプルレートが48000 Hz以下のオーディオは、4608を超えるチャネルサンプルを備えたブロックに含める必要はありません。つまり、このオーディオに使用される最大ブロックサイズは4608を超えてはなりません。
* Linear prediction subframes (see Section 9.2.6) containing audio with a sample rate less than or equal to 48000 Hz MUST have a predictor order less than or equal to 12, i.e., the subframe type bits in the subframe header (see Section 9.2.1) MUST NOT be 0b101100-0b111111.
* 48000 Hz以下のサンプルレートを含むオーディオを含む線形予測サブフレーム（セクション9.2.6を参照）は、12以下の予測順、つまりサブフレームヘッダーのサブフレームタイプビット（セクション9.2を参照してください。1）0B101100-0B111111にしてはなりません。
* The Rice partition order (see Section 9.2.7) MUST be less than or equal to 8.
* イネの分配順序（セクション9.2.7を参照）は、8以下でなければなりません。
* The channel ordering MUST be equal to one defined in Section 9.1.3, i.e., the FLAC file MUST NOT need a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag to describe the channel ordering. See Section 8.6.2 for details.
* チャネルの順序付けは、セクション9.1.3で定義されているものに等しくなければなりません。つまり、FLACファイルは、チャネルの順序付けを説明するために波形Xtensible_Channel_Maskタグを必要としないはずです。詳細については、セクション8.6.2を参照してください。
At the start of a FLAC file or stream, following the fLaC ASCII file signature, one or more metadata blocks MUST be present before any audio frames appear. The first metadata block MUST be a streaminfo metadata block.
FLACファイルまたはストリームの開始時に、FLAC ASCIIファイルの署名に続いて、オーディオフレームが表示される前に1つ以上のメタデータブロックが存在する必要があります。最初のメタデータブロックは、Streaminfoメタデータブロックでなければなりません。
Each metadata block starts with a 4-byte header. The first bit in this header flags whether a metadata block is the last one. It is 0 when other metadata blocks follow; otherwise, it is 1. The 7 remaining bits of the first header byte contain the type of the metadata block as an unsigned number between 0 and 126, according to the following table. A value of 127 (i.e., 0b1111111) is forbidden. The three bytes that follow code for the size of the metadata block in bytes, excluding the 4 header bytes, as an unsigned number coded big-endian.
各メタデータブロックは、4バイトヘッダーで始まります。このヘッダーの最初のビットは、メタデータブロックが最後のブロックであるかどうかにかかわらず、フラグを立てます。他のメタデータブロックが続く場合は0です。それ以外の場合は、1です。最初のヘッダーバイトの残りの7ビットには、次の表によると、メタデータブロックのタイプが0〜126の間の符号なしの数値として含まれています。127の値（つまり、0B1111111）は禁止されています。メタデータブロックのサイズのコードに従う3バイトは、4つのヘッダーバイトを除く、符号なしの数字をコード化されたビッグエンディアンとして除外します。
+=========+=======================================================+
| Value | Metadata Block Type |
+=========+=======================================================+
| 0 | Streaminfo |
+---------+-------------------------------------------------------+
| 1 | Padding |
+---------+-------------------------------------------------------+
| 2 | Application |
+---------+-------------------------------------------------------+
| 3 | Seek table |
+---------+-------------------------------------------------------+
| 4 | Vorbis comment |
+---------+-------------------------------------------------------+
| 5 | Cuesheet |
+---------+-------------------------------------------------------+
| 6 | Picture |
+---------+-------------------------------------------------------+
| 7 - 126 | Reserved |
+---------+-------------------------------------------------------+
| 127 | Forbidden (to avoid confusion with a frame sync code) |
+---------+-------------------------------------------------------+
Table 2
The streaminfo metadata block has information about the whole stream, such as sample rate, number of channels, total number of samples, etc. It MUST be present as the first metadata block in the stream. Other metadata blocks MAY follow. There MUST be no more than one streaminfo metadata block per FLAC stream.
Streaminfoメタデータブロックには、サンプルレート、チャネルの数、サンプルの総数など、ストリーム全体に関する情報があります。ストリームの最初のメタデータブロックとして存在する必要があります。他のメタデータブロックが続く場合があります。FLACストリームごとにStreaminfoメタデータブロックが1つしかない必要があります。
If the streaminfo metadata block contains incorrect or incomplete information, decoder behavior is left unspecified (i.e., it is up to the decoder implementation). A decoder MAY choose to stop further decoding when the information supplied by the streaminfo metadata block turns out to be incorrect or contains forbidden values. A decoder accepting information from the streaminfo metadata block (most significantly, the maximum frame size, maximum block size, number of audio channels, number of bits per sample, and total number of samples) without doing further checks during decoding of audio frames could be vulnerable to buffer overflows. See also Section 11.
Streaminfoメタデータブロックに誤った情報または不完全な情報が含まれている場合、デコーダーの動作は不特定のままになります（つまり、デコーダーの実装次第です）。Decoderは、Streaminfoメタデータブロックによって提供された情報が正しくないか、禁止された値が含まれていることが判明した場合、さらにデコードを停止することを選択できます。Streaminfoメタデータブロックからの情報を受け入れるデコーダー（最も重要なことは、最大フレームサイズ、最大ブロックサイズ、オーディオチャネル数、サンプルあたりのビット数、およびサンプルの総数）を選択せずに、オーディオフレームのデコード中にさらにチェックすることはできません。バッファオーバーフローに対して脆弱です。セクション11も参照してください。
The following table describes the streaminfo metadata block in order, excluding the metadata block header.
次の表は、メタデータブロックヘッダーを除く、Streaminfoメタデータブロックを順番に説明しています。
+========+=================================================+
| Data | Description |
+========+=================================================+
| u(16) | The minimum block size (in samples) used in the |
| | stream, excluding the last block. |
+--------+-------------------------------------------------+
| u(16) | The maximum block size (in samples) used in the |
| | stream. |
+--------+-------------------------------------------------+
| u(24) | The minimum frame size (in bytes) used in the |
| | stream. A value of 0 signifies that the value |
| | is not known. |
+--------+-------------------------------------------------+
| u(24) | The maximum frame size (in bytes) used in the |
| | stream. A value of 0 signifies that the value |
| | is not known. |
+--------+-------------------------------------------------+
| u(20) | Sample rate in Hz. |
+--------+-------------------------------------------------+
| u(3) | (number of channels)-1. FLAC supports from 1 |
| | to 8 channels. |
+--------+-------------------------------------------------+
| u(5) | (bits per sample)-1. FLAC supports from 4 to |
| | 32 bits per sample. |
+--------+-------------------------------------------------+
| u(36) | Total number of interchannel samples in the |
| | stream. A value of 0 here means the number of |
| | total samples is unknown. |
+--------+-------------------------------------------------+
| u(128) | MD5 checksum of the unencoded audio data. This |
| | allows the decoder to determine if an error |
| | exists in the audio data even when, despite the |
| | error, the bitstream itself is valid. A value |
| | of 0 signifies that the value is not known. |
+--------+-------------------------------------------------+
Table 3
The minimum block size and the maximum block size MUST be in the 16-65535 range. The minimum block size MUST be equal to or less than the maximum block size.
最小ブロックサイズと最大ブロックサイズは、16-65535の範囲でなければなりません。最小ブロックサイズは、最大ブロックサイズ以下でなければなりません。
Any frame but the last one MUST have a block size equal to or greater than the minimum block size and MUST have a block size equal to or less than the maximum block size. The last frame MUST have a block size equal to or less than the maximum block size; it does not have to comply to the minimum block size because the block size of that frame must be able to accommodate the length of the audio data the stream contains.
最後のフレーム以外の任意のフレームには、最小ブロックサイズ以上のブロックサイズが必要であり、最大ブロックサイズ以下のブロックサイズが必要です。最後のフレームには、最大ブロックサイズ以下のブロックサイズが必要です。そのフレームのブロックサイズは、ストリームに含まれるオーディオデータの長さに対応できる必要があるため、最小ブロックサイズに準拠する必要はありません。
If the minimum block size is equal to the maximum block size, the file contains a fixed block size stream, as the minimum block size excludes the last block. Note that in the case of a stream with a variable block size, the actual maximum block size MAY be smaller than the maximum block size listed in the streaminfo metadata block, and the actual smallest block size excluding the last block MAY be larger than the minimum block size listed in the streaminfo metadata block. This is because the encoder has to write these fields before receiving any input audio data and cannot know beforehand what block sizes it will use, only between what bounds the block sizes will be chosen.
最小ブロックサイズが最大ブロックサイズに等しい場合、最小ブロックサイズは最後のブロックを除外するため、ファイルには固定ブロックサイズストリームが含まれます。可変ブロックサイズのストリームの場合、実際の最大ブロックサイズはStreaminfoメタデータブロックにリストされている最大ブロックサイズよりも小さく、最後のブロックを除く実際の最小のブロックサイズは最小値よりも大きい場合があることに注意してください。Streaminfoメタデータブロックにリストされているブロックサイズ。これは、入力オーディオデータを受信する前にエンコーダーがこれらのフィールドを記述する必要があり、使用するブロックサイズを事前に知ることができないためです。
The sample rate MUST NOT be 0 when the FLAC file contains audio. A sample rate of 0 MAY be used when non-audio is represented. This is useful if data is encoded that is not along a time axis or when the sample rate of the data lies outside the range that FLAC can represent in the streaminfo metadata block. If a sample rate of 0 is used, it is recommended to store the meaning of the encoded content in a Vorbis comment field (see Section 8.6) or an application metadata block (see Section 8.4). This document does not define such metadata.
FLACファイルにオーディオが含まれている場合、サンプルレートは0ではありません。非オーディオが表される場合、0のサンプルレートを使用できます。これは、時間軸に沿っていないデータがエンコードされている場合、またはデータのサンプルレートがFLACがStreaminfoメタデータブロックで表すことができる範囲外にある場合に役立ちます。0のサンプルレートを使用する場合は、エンコードされたコンテンツの意味をVorbisコメントフィールド（セクション8.6を参照）またはアプリケーションメタデータブロック（セクション8.4を参照）に保存することをお勧めします。このドキュメントは、そのようなメタデータを定義しません。
The MD5 checksum is computed by applying the MD5 message-digest algorithm in [RFC1321]. The message to this algorithm consists of all the samples of all channels interleaved, represented in signed, little-endian form. This interleaving is on a per-sample basis, so for a stereo file, this means the first sample of the first channel, then the first sample of the second channel, then the second sample of the first channel, etc. Before computing the checksum, all samples must be byte-aligned. If the bit depth is not a whole number of bytes, the value of each sample is sign-extended to the next whole number of bytes.
MD5チェックサムは、[RFC1321]にMD5メッセージダイジェストアルゴリズムを適用することにより計算されます。このアルゴリズムへのメッセージは、署名された小さなエンディアン形式で表されるインターリーブされたすべてのチャネルのすべてのサンプルで構成されています。このインターリーブはサンプルごとにあるため、ステレオファイルの場合、これは最初のチャネルの最初のサンプル、次に2番目のチャネルの最初のサンプル、次に最初のチャネルの2番目のサンプルなどを意味します。、すべてのサンプルをバイトアリーで整列する必要があります。ビットの深さがバイトの整数でない場合、各サンプルの値は、次のバイトの全部に標識拡張されます。
In the case of a 2-channel stream with 6-bit samples, bits will be lined up as follows:
6ビットサンプルを備えた2チャンネルストリームの場合、ビットは次のように並んでいます。
SSAAAAAASSBBBBBBSSCCCCCC
^ ^ ^ ^ ^ ^
| | | | | Bits of 2nd sample of 1st channel
| | | | Sign extension bits of 2nd sample of 2nd channel
| | | Bits of 1st sample of 2nd channel
| | Sign extension bits of 1st sample of 2nd channel
| Bits of 1st sample of 1st channel
Sign extension bits of 1st sample of 1st channel
In the case of a 1-channel stream with 12-bit samples, bits are lined up in little-endian byte order as follows:
12ビットサンプルを備えた1チャンネルストリームの場合、ビットは次のようにリトルエンディアンバイトの順序で並んでいます。
AAAAAAAASSSSAAAABBBBBBBBSSSSBBBB
^ ^ ^ ^ ^ ^
| | | | | Most-significant 4 bits of 2nd sample
| | | | Sign extension bits of 2nd sample
| | | Least-significant 8 bits of 2nd sample
| | Most-significant 4 bits of 1st sample
| Sign extension bits of 1st sample
Least-significant 8 bits of 1st sample
The padding metadata block allows for an arbitrary amount of padding. This block is useful when it is known that metadata will be edited after encoding; the user can instruct the encoder to reserve a padding block of sufficient size so that when metadata is added, it will simply overwrite the padding (which is relatively quick) instead of having to insert it into the existing file (which would normally require rewriting the entire file). There MAY be one or more padding metadata blocks per FLAC stream.
パディングメタデータブロックは、任意の量のパディングを可能にします。このブロックは、メタデータがエンコード後に編集されることがわかっている場合に役立ちます。ユーザーは、メタデータが追加されると、既存のファイルに挿入する代わりにパディング（比較的速い）を単純に上書きするように、エンコーダーに十分なサイズのパディングブロックを予約するように指示できます（通常は、書き換えが必要になります。ファイル全体）。FLACストリームごとに1つ以上のパディングメタデータブロックがある場合があります。
+======+======================================================+
| Data | Description |
+======+======================================================+
| u(n) | n "0" bits (n MUST be a multiple of 8, i.e., a whole |
| | number of bytes, and MAY be zero). n is 8 times the |
| | size described in the metadata block header. |
+------+------------------------------------------------------+
Table 4
The application metadata block is for use by third-party applications. The only mandatory field is a 32-bit application identifier (application ID). Application IDs are registered in the IANA "FLAC Application Metadata Block IDs" registry (see Section 12.2).
アプリケーションメタデータブロックは、サードパーティアプリケーションで使用するためのものです。唯一の必須フィールドは、32ビットアプリケーション識別子（アプリケーションID）です。アプリケーションIDは、IANA「FLACアプリケーションメタデータブロックID」レジストリに登録されています（セクション12.2を参照）。
+=======+===================================================+
| Data | Description |
+=======+===================================================+
| u(32) | Registered application ID. |
+-------+---------------------------------------------------+
| u(n) | Application data (n MUST be a multiple of 8, |
| | i.e., a whole number of bytes). n is 8 times the |
| | size described in the metadata block header minus |
| | the 32 bits already used for the application ID. |
+-------+---------------------------------------------------+
Table 5
The seek table metadata block can be used to store seek points. It is possible to seek to any given sample in a FLAC stream without a seek table, but the delay can be unpredictable since the bitrate may vary widely within a stream. By adding seek points to a stream, this delay can be significantly reduced. There MUST NOT be more than one seek table metadata block in a stream, but the table can have any number of seek points.
シークテーブルメタデータブロックを使用してシークポイントを保存できます。シークテーブルなしでFLACストリーム内の特定のサンプルを探すことは可能ですが、ビットレートはストリーム内で大きく異なるため、遅延は予測不可能になる可能性があります。ストリームにシークポイントを追加することにより、この遅延を大幅に減らすことができます。ストリームには1つ以上のシークテーブルメタデータブロックがありませんが、テーブルには任意の数のシークポイントがあります。
Each seek point takes 18 bytes, so a seek table with 1% resolution within a stream adds less than 2 kilobytes of data. The number of seek points is implied by the size described in the metadata block header, i.e., equal to size / 18. There is also a special "placeholder" seek point that will be ignored by decoders but can be used to reserve space for future seek point insertion.
各シークポイントには18バイトがかかるため、ストリーム内に1％の解像度を持つシークテーブルは、2キロバイト未満のデータを追加します。シークポイントの数は、メタデータブロックヘッダー、つまりサイズ / 18に等しいサイズによって暗示されます。また、デコーダーによって無視されるが、将来のためにスペースを予約するために使用できる特別な「プレースホルダー」シークポイントもあります。ポイント挿入を求めます。
+=============+=============================+
| Data | Description |
+=============+=============================+
| Seek points | Zero or more seek points as |
| | defined in Section 8.5.1. |
+-------------+-----------------------------+
Table 6
A seek table is generally not usable for seeking in a FLAC file embedded in a container (see Section 10), as such containers usually interleave FLAC data with other data and the offsets used in seek points are those of an unmuxed FLAC stream. Also, containers often provide their own seeking methods. However, it is possible to store the seek table in the container along with other metadata when muxing a FLAC file, so this stored seek table can be restored when demuxing the FLAC stream into a standalone FLAC file.
シークテーブルは、通常、コンテナに埋め込まれたFLACファイルを探すために使用できません（セクション10を参照）。そのようなコンテナは通常、FLACデータを他のデータとインターリーブし、シークポイントで使用されるオフセットは不合理なFLACストリームのものです。また、コンテナは多くの場合、独自のシーキング方法を提供します。ただし、FLACファイルをMuxingするときにSeekテーブルを他のメタデータとともにコンテナに保存することができます。そのため、FLACストリームをスタンドアロンFLACファイルに分類するときに、この保存されたシークテーブルを復元できます。
+=======+==========================================================+
| Data | Description |
+=======+==========================================================+
| u(64) | Sample number of the first sample in the target frame or |
| | 0xFFFFFFFFFFFFFFFF for a placeholder point. |
+-------+----------------------------------------------------------+
| u(64) | Offset (in bytes) from the first byte of the first frame |
| | header to the first byte of the target frame's header. |
+-------+----------------------------------------------------------+
| u(16) | Number of samples in the target frame. |
+-------+----------------------------------------------------------+
Table 7
Notes:
注：
* For placeholder points, the second and third field values are undefined.
* プレースホルダーポイントの場合、2番目と3番目のフィールド値は未定義です。
* Seek points within a table MUST be sorted in ascending order by sample number.
* テーブル内のシークポイントは、サンプル番号で昇順でソートする必要があります。
* Seek points within a table MUST be unique by sample number, with the exception of placeholder points.
* テーブル内のシークポイントは、プレースホルダーポイントを除き、サンプル番号で一意でなければなりません。
* The previous two notes imply that there MAY be any number of placeholder points, but they MUST all occur at the end of the table.
* 前の2つのメモは、プレースホルダーポイントの数が存在する可能性があることを意味しますが、それらはすべてテーブルの端で発生する必要があります。
* The sample offsets are those of an unmuxed FLAC stream. The offsets MUST NOT be updated on muxing to reflect the new offsets of FLAC frames in a container.
* サンプルオフセットは、不測のないFLACストリームのオフセットです。オフセットは、コンテナ内のFLACフレームの新しいオフセットを反映するために、マクシングで更新してはなりません。
A Vorbis comment metadata block contains human-readable information coded in UTF-8. The name "Vorbis comment" points to the fact that the Vorbis codec stores such metadata in almost the same way (see [Vorbis]). A Vorbis comment metadata block consists of a vendor string optionally followed by a number of fields, which are pairs of field names and field contents. The vendor string contains the name of the program that generated the file or stream. The fields contain metadata describing various aspects of the contained audio. Many users refer to these fields as "FLAC tags" or simply as "tags". A FLAC file MUST NOT contain more than one Vorbis comment metadata block.
Vorbisコメントメタデータブロックには、UTF-8でコーディングされた人間の読み取り可能な情報が含まれています。「Vorbis Comment」という名前は、Vorbis Codecがそのようなメタデータをほぼ同じ方法で保存するという事実を示しています（[Vorbis]を参照）。Vorbisコメントメタデータブロックは、オプションでフィールド名とフィールドのコンテンツのペアである多くのフィールドがオプションで続くベンダー文字列で構成されています。ベンダー文字列には、ファイルまたはストリームを生成したプログラムの名前が含まれています。フィールドには、含まれるオーディオのさまざまな側面を説明するメタデータが含まれています。多くのユーザーは、これらのフィールドを「FLACタグ」または単に「タグ」と呼んでいます。FLACファイルには、複数のVorbisコメントメタデータブロックを含めることはできません。
In a Vorbis comment metadata block, the metadata block header is directly followed by 4 bytes containing the length in bytes of the vendor string as an unsigned number coded little-endian. The vendor string follows, is UTF-8 coded and is not terminated in any way.
Vorbisコメントメタデータブロックでは、メタデータブロックヘッダーに直接続いて、ベンダー文字列の長さを符号なしの数字のコード化された小さなエンディアンとして含む4バイトが続きます。ベンダー文字列が続き、UTF-8コード化されており、いかなる方法でも終了しません。
Following the vendor string are 4 bytes containing the number of fields that are in the Vorbis comment block, stored as an unsigned number coded little-endian. If this number is non-zero, it is followed by the fields themselves, each of which is stored with a 4-byte length. For each field, the field length in bytes is stored as a 4-byte unsigned number coded little-endian. The field itself follows it. Like the vendor string, the field is UTF-8 coded and not terminated in any way.
ベンダーの文字列に続くのは、署名されていない番号コード化された小さなエンディアンとして保存されているVorbisコメントブロックにあるフィールドの数を含む4バイトです。この数値がゼロ以外の場合、フィールド自体が続き、それぞれが4バイトの長さで保存されます。各フィールドについて、バイト単位のフィールドの長さは、4バイトの符号なしの数字コード付きリトルエンディアンとして保存されます。フィールド自体がそれに続きます。ベンダー文字列のように、フィールドはUTF-8コード化されており、いかなる方法でも終了しません。
Each field consists of a field name and field contents, separated by an = character. The field name MUST only consist of UTF-8 code points U+0020 through U+007E, excluding U+003D, which is the = character. In other words, the field name can contain all printable ASCII characters except the equals sign. The evaluation of the field names MUST be case insensitive, so U+0041 through 0+005A (A-Z) MUST be considered equivalent to U+0061 through U+007A (a-z). The field contents can contain any UTF-8 character.
各フィールドは、AN =文字で区切られたフィールド名とフィールドの内容で構成されています。フィールド名は、U+003Dを除くUTF-8コードポイントU+0020からU+007Eからのみで構成されている必要があります。これは=文字です。言い換えれば、フィールド名には、Equals Signを除くすべての印刷可能なASCII文字を含めることができます。フィールド名の評価は症例ではないため、U+0041から0+005A（A-Z）は、U+0061からU+007A（A-Z）に相当すると見なす必要があります。フィールドの内容には、任意のUTF-8文字を含めることができます。
Note that the Vorbis comment as used in Vorbis allows for 2^64 bytes of data whereas the FLAC metadata block is limited to 2^24 bytes. Given the stated purpose of Vorbis comments, i.e., human-readable textual information, the FLAC metadata block limit is unlikely to be restrictive. Also, note that the 32-bit field lengths are coded little-endian as opposed to the usual big-endian coding of fixed-length integers in the rest of the FLAC format.
Vorbisで使用されているVorbisコメントは、2^64バイトのデータを許可するのに対し、FLACメタデータブロックは2^24バイトに制限されていることに注意してください。Vorbisのコメントの記載されている目的、つまり人間の読み取り可能なテキスト情報を考えると、FLACメタデータブロックの制限は制限されそうにありません。また、32ビットのフィールド長は、FLAC形式の残りの部分での固定整数の通常のビッグエンディアンコーディングとは対照的に、小さなエンディアンとコード化されていることに注意してください。
Only one standard field name is defined: the channel mask field (see Section 8.6.2). No other field names are defined because the applicability of any field name is strongly tied to the content it is associated with. For example, field names that are useful for describing files that contain a single work of music would be unusable when labeling archived broadcasts, recordings of any kind, or a collection of music works. Even when describing a single work of music, different conventions exist depending on the kind of music: orchestral music differs from music by solo artists or bands.
定義されている標準フィールド名は1つだけです。チャネルマスクフィールド（セクション8.6.2を参照）。フィールド名の適用性が関連付けられているコンテンツに強く結び付けられているため、他のフィールド名は定義されていません。たとえば、アーカイブブロードキャスト、あらゆる種類の録音、音楽のコレクションにラベルを付ける場合、音楽の単一の作品を含むファイルを説明するのに役立つフィールド名は使用できません。音楽の単一の作品を説明するときでさえ、音楽の種類に応じて異なるコンベンションが存在します。オーケストラの音楽は、ソロアーティストやバンドの音楽とは異なります。
Despite the fact that no field names are formally defined, there is a general trend among devices and software capable of FLAC playback that are meant to play music. Most of those recognize at least the following field names:
正式に定義されているフィールド名はないという事実にもかかわらず、音楽を再生することを目的としたFLAC再生が可能なデバイスやソフトウェアの間に一般的な傾向があります。それらのほとんどは、少なくとも次のフィールド名を認識しています。
Title:
タイトル：
Name of the current work.
現在の作業の名前。
Artist:
アーティスト：
Name of the artist generally responsible for the current work. For orchestral works, this is usually the composer; otherwise, it is often the performer.
一般的に現在の作品を担当するアーティストの名前。オーケストラの作品にとって、これは通常作曲家です。そうでなければ、それはしばしばパフォーマーです。
Album:
アルバム：
Name of the collection the current work belongs to.
現在の作品が属するコレクションの名前。
For a more comprehensive list of possible field names suited for describing a single work of music in various genres, the list of tags used in the MusicBrainz project is suggested; see [MusicBrainz].
さまざまなジャンルで音楽の単一の作品を説明するのに適したフィールド名のより包括的なリストのリストについては、MusicBrainzプロジェクトで使用されるタグのリストが提案されています。[MusicBrainz]を参照してください。
Besides fields containing information about the work itself, one field is defined for technical reasons: WAVEFORMATEXTENSIBLE_CHANNEL_MASK. This field is used to communicate that the channels in a file differ from the default channels defined in Section 9.1.3. For example, by default, a FLAC file containing two channels is interpreted to contain a left and right channel, but with this field, it is possible to describe different channel contents.
作業自体に関する情報を含むフィールドに加えて、1つのフィールドは、技術的な理由で定義されています：waveformatextensible_channel_mask。このフィールドは、ファイル内のチャネルがセクション9.1.3で定義されているデフォルトチャネルと異なることを通信するために使用されます。たとえば、デフォルトでは、2つのチャネルを含むFLACファイルが左右のチャネルが含まれていると解釈されますが、このフィールドでは、異なるチャネルの内容を記述することができます。
The channel mask consists of flag bits indicating which channels are present. The flags only signal which channels are present, not in which order, so if a file to be encoded has channels that are ordered differently, they have to be reordered. This mask is stored with a hexadecimal representation preceded by 0x; see the examples below. Please note that a file in which the channel order is defined through the WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not streamable (see Section 7), as the field is not found in each frame header. The mask bits can be found in the following table.
チャネルマスクは、どのチャネルが存在するかを示すフラグビットで構成されています。フラグは、どのチャネルが存在するかのみの信号のみであり、どの順序ではないため、エンコードされるファイルに異なる方法で注文されるチャネルがある場合、それらを再注文する必要があります。このマスクは、0xが先行する16進表現で保存されています。以下の例を参照してください。各フレームヘッダーにフィールドが見つからないため、チャネル順序がwaveformatextensible_channel_maskを介して定義されるファイル（セクション7を参照）に注意してください。マスクビットは次の表にあります。
+============+=============================+
| Bit Number | Channel Description |
+============+=============================+
| 0 | Front left |
+------------+-----------------------------+
| 1 | Front right |
+------------+-----------------------------+
| 2 | Front center |
+------------+-----------------------------+
| 3 | Low-frequency effects (LFE) |
+------------+-----------------------------+
| 4 | Back left |
+------------+-----------------------------+
| 5 | Back right |
+------------+-----------------------------+
| 6 | Front left of center |
+------------+-----------------------------+
| 7 | Front right of center |
+------------+-----------------------------+
| 8 | Back center |
+------------+-----------------------------+
| 9 | Side left |
+------------+-----------------------------+
| 10 | Side right |
+------------+-----------------------------+
| 11 | Top center |
+------------+-----------------------------+
| 12 | Top front left |
+------------+-----------------------------+
| 13 | Top front center |
+------------+-----------------------------+
| 14 | Top front right |
+------------+-----------------------------+
| 15 | Top rear left |
+------------+-----------------------------+
| 16 | Top rear center |
+------------+-----------------------------+
| 17 | Top rear right |
+------------+-----------------------------+
Table 8
Following are three examples:
以下は3つの例です。
* A file has a single channel -- an LFE channel. The Vorbis comment field is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x8.
* ファイルには、LFEチャネルという単一のチャネルがあります。Vorbisのコメントフィールドはwaveformatextensible_channel_mask = 0x8です。
* A file has four channels -- front left, front right, top front left, and top front right. The Vorbis comment field is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x5003.
* ファイルには4つのチャネルがあります。左前面、前面、左上、左上、右上右上部。Vorbisのコメントフィールドは波形xtensible_channel_mask = 0x5003です。
* An input has four channels -- back center, top front center, front center, and top rear center in that order. These have to be reordered to front center, back center, top front center, and top rear center. The Vorbis comment field added is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x12104.
* 入力には、その順序でバックセンター、トップフロントセンター、フロントセンター、トップリアセンターの4つのチャネルがあります。これらは、フロントセンター、バックセンター、トップフロントセンター、トップリアセンターに並べ替える必要があります。追加されたVorbisのコメントフィールドは、waveformatextensible_channel_mask = 0x12104です。
WAVEFORMATEXTENSIBLE_CHANNEL_MASK fields MAY be padded with zeros, for example, 0x0008 for a single LFE channel. Parsing of WAVEFORMATEXTENSIBLE_CHANNEL_MASK fields MUST be case-insensitive for both the field name and the field contents.
WaveFormateXtensible_Channel_Maskフィールドには、単一のLFEチャネルで0x0008など、ゼロがパッドで埋められている場合があります。WaveFormateXtensible_Channel_Maskフィールドの解析は、フィールド名とフィールドの内容の両方でケース非感受性でなければなりません。
A WAVEFORMATEXTENSIBLE_CHANNEL_MASK field of 0x0 can be used to indicate that none of the audio channels of a file correlate with speaker positions. This is the case when audio needs to be decoded into speaker positions (e.g., Ambisonics B-format audio) or when a multitrack recording is contained.
0x0の波形Xtensible_channel_maskフィールドを使用して、ファイルのオーディオチャネルがスピーカーの位置と相関していないことを示すことができます。これは、オーディオをスピーカーの位置にデコードする必要がある場合（たとえば、Ambisonics B-Format Audio）、またはマルチトラックの録音が含まれている場合です。
It is possible for a WAVEFORMATEXTENSIBLE_CHANNEL_MASK field to code for fewer channels than are present in the audio. If that is the case, the remaining channels SHOULD NOT be rendered by a playback application unfamiliar with their purpose. For example, the Ambisonics UHJ format is compatible with stereo playback: its first two channels can be played back on stereo equipment, but all four channels together can be decoded into surround sound. For that example, the Vorbis comment field WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x3 would be set, indicating that the first two channels are front left and front right and other channels do not correlate with speaker positions directly.
波形Xtensible_Channel_Maskフィールドが、音声に存在するよりも少ないチャネルをコードすることができます。その場合、残りのチャネルは、目的に不慣れな再生アプリケーションによってレンダリングされるべきではありません。たとえば、Ambisonics UHJ形式はステレオ再生と互換性があります。最初の2つのチャネルはステレオ機器で再生できますが、4つのチャネルはすべて一緒にサラウンドサウンドにデコードできます。その例では、Vorbisのコメントフィールドwaveformatextensible_channel_mask = 0x3が設定され、最初の2つのチャネルが左前面と正面右であり、他のチャネルがスピーカーの位置と直接相関しないことを示します。
If audio channels not assigned to any speaker are contained and decoding to speaker positions is possible, it is recommended to provide metadata on how this decoding should take place in another Vorbis comment field or an application metadata block. This document does not define such metadata.
スピーカーに割り当てられていないオーディオチャネルが含まれており、スピーカーの位置にデコードすることが可能な場合は、別のVorbisコメントフィールドまたはアプリケーションメタデータブロックでこのデコードがどのように行われるかについてメタデータを提供することをお勧めします。このドキュメントは、そのようなメタデータを定義しません。
A cuesheet metadata block can be used either to store the track and index point structure of a Compact Disc Digital Audio (CD-DA) along with its audio or to provide a mechanism to store locations of interest within a FLAC file. Certain aspects of this metadata block come directly from the CD-DA specification (called Red Book), which is standardized as [IEC.60908.1999]. The description below is complete, and further reference to [IEC.60908.1999] is not needed to implement this metadata block.
キューシートメタデータブロックを使用して、コンパクトディスクデジタルオーディオ（CD-DA）のトラックおよびインデックスポイント構造をオーディオとともに保存するか、FLACファイル内に関心のある場所を保存するメカニズムを提供することができます。このメタデータブロックの特定の側面は、[IEC.60908.1999]として標準化されているCD-DA仕様（Red Bookと呼ばれる）から直接届きます。以下の説明は完全であり、このメタデータブロックを実装するために[IEC.60908.1999]へのさらなる参照は必要ありません。
The structure of a cuesheet metadata block is enumerated in the following table.
キューシートメタデータブロックの構造は、次の表に列挙されています。
+============+======================================================+
| Data | Description |
+============+======================================================+
| u(128*8) | Media catalog number in ASCII |
| | printable characters 0x20-0x7E. |
+------------+------------------------------------------------------+
| u(64) | Number of lead-in samples. |
+------------+------------------------------------------------------+
| u(1) | 1 if the cuesheet corresponds to a |
| | CD-DA; else 0. |
+------------+------------------------------------------------------+
| u(7+258*8) | Reserved. All bits MUST be set to |
| | zero. |
+------------+------------------------------------------------------+
| u(8) | Number of tracks in this cuesheet. |
+------------+------------------------------------------------------+
| Cuesheet | A number of structures as specified |
| tracks | in Section 8.7.1 equal to the number |
| | of tracks specified previously. |
+------------+------------------------------------------------------+
Table 9
If the media catalog number is less than 128 bytes long, it is right-padded with 0x00 bytes. For CD-DA, this is a 13-digit number followed by 115 0x00 bytes.
メディアカタログ番号の長さが128バイト未満の場合、0x00バイトで右パッドが付いています。CD-DAの場合、これは13桁の数字に続いて115 0x00バイトです。
The number of lead-in samples has meaning only for CD-DA cuesheets; for other uses, it should be 0. For CD-DA, the lead-in is the TRACK 00 area where the table of contents is stored; more precisely, it is the number of samples from the first sample of the media to the first sample of the first index point of the first track. According to [IEC.60908.1999], the lead-in MUST be silent, and CD grabbing software does not usually store it; additionally, the lead-in MUST be at least two seconds but MAY be longer. For these reasons, the lead-in length is stored here so that the absolute position of the first track can be computed. Note that the lead-in stored here is the number of samples up to the first index point of the first track, not necessarily to INDEX 01 of the first track; even the first track MAY have INDEX 00 data.
リードインサンプルの数は、CD-DAキューシートのみを意味します。他の用途の場合、それは0でなければなりません。CD-DAの場合、リードインは目次が保存されているトラック00エリアです。より正確には、メディアの最初のサンプルから最初のトラックの最初のインデックスポイントの最初のサンプルまでのサンプルの数です。[IEC.60908.1999]によれば、リードインは沈黙している必要があり、CDグラブするソフトウェアは通常保存しません。さらに、リードインは少なくとも2秒でなければなりませんが、長くなる必要があります。これらの理由により、最初のトラックの絶対位置を計算できるように、リードインの長さがここに保存されます。ここに保存されているリードインは、最初のトラックの最初のトラックの最初のインデックスポイントまでのサンプルの数であり、必ずしも最初のトラックの01インデックスではありません。最初のトラックでさえ、インデックス00データがある場合があります。
The number of tracks MUST be at least 1, as a cuesheet block MUST have a lead-out track. For CD-DA, this number MUST be no more than 100 (99 regular tracks and one lead-out track). The lead-out track is always the last track in the cuesheet. For CD-DA, the lead-out track number MUST be 170 as specified by [IEC.60908.1999]; otherwise, it MUST be 255.
キューシートブロックにはリードアウトトラックが必要なため、トラックの数は少なくとも1でなければなりません。CD-DAの場合、この数値は100（99の通常のトラックと1つのリードアウトトラック）を超えている必要があります。リードアウトトラックは、常にキューシートの最後のトラックです。CD-DAの場合、[IEC.60908.1999]で指定されているように、リードアウトトラック番号は170でなければなりません。それ以外の場合は、255でなければなりません。
+=============+=====================================================+
| Data | Description |
+=============+=====================================================+
| u(64) | Track offset of the first index point in |
| | samples, relative to the beginning of the |
| | FLAC audio stream. |
+-------------+-----------------------------------------------------+
| u(8) | Track number. |
+-------------+-----------------------------------------------------+
| u(12*8) | Track ISRC. |
+-------------+-----------------------------------------------------+
| u(1) | The track type: 0 for audio, 1 for non-audio. |
| | This corresponds to the CD-DA Q-channel |
| | control bit 3. |
+-------------+-----------------------------------------------------+
| u(1) | The pre-emphasis flag: 0 for no pre-emphasis, |
| | 1 for pre-emphasis. This corresponds to the |
| | CD-DA Q-channel control bit 5. |
+-------------+-----------------------------------------------------+
| u(6+13*8) | Reserved. All bits MUST be set to zero. |
+-------------+-----------------------------------------------------+
| u(8) | The number of track index points. |
+-------------+-----------------------------------------------------+
| Cuesheet | For all tracks except the lead-out track, a |
| track index | number of structures as specified in |
| points | Section 8.7.1.1 equal to the number of index |
| | points specified previously. |
+-------------+-----------------------------------------------------+
Table 10
Note that the track offset differs from the one in CD-DA, where the track's offset in the table of contents (TOC) is that of the track's INDEX 01 even if there is an INDEX 00. For CD-DA, the track offset MUST be evenly divisible by 588 samples (588 samples = 44100 samples/ s * 1/75 s).
トラックオフセットはCD-DAのものとは異なります。このテーブル（TOC）におけるトラックのオフセットは、インデックス00がある場合でもトラックのインデックス01のものです。CD-DAの場合、トラックオフセットは必要です588サンプル（588サンプル= 44100サンプル/ s * 1/75秒）で均等に分裂します。
A track number of 0 is not allowed because the CD-DA specification reserves this for the lead-in. For CD-DA, the number MUST be 1-99 or 170 for the lead-out; for non-CD-DA, the track number MUST be 255 for the lead-out. It is recommended to start with track 1 and increase sequentially. Track numbers MUST be unique within a cuesheet.
CD-DA仕様がリードイン用にこれを予約するため、トラック番号0は許可されていません。CD-DAの場合、リードアウトの場合、数は1-99または170でなければなりません。非CD-DAの場合、トラック番号はリードアウトの場合は255でなければなりません。トラック1から開始し、順次増加することをお勧めします。トラック番号は、キューシート内で一意でなければなりません。
The track ISRC (International Standard Recording Code) is a 12-digit alphanumeric code; see [ISRC-handbook]. A value of 12 ASCII 0x00 characters MAY be used to denote the absence of an ISRC.
トラックISRC（International Standard Recording Code）は、12桁の英数字コードです。[ISRCハンドブック]を参照してください。12個のASCII 0x00文字の値を使用して、ISRCの欠如を示すことができます。
There MUST be at least one index point in every track in a cuesheet except for the lead-out track, which MUST have zero. For CD-DA, the number of index points MUST NOT be more than 100.
キューシートのすべてのトラックには、リードアウトトラックを除いて、ゼロが必要なものがないことを除いて、少なくとも1つのインデックスポイントが必要です。CD-DAの場合、インデックスポイントの数は100を超えてはなりません。
+========+====================================+
| Data | Description |
+========+====================================+
| u(64) | Offset in samples, relative to the |
| | track offset, of the index point. |
+--------+------------------------------------+
| u(8) | The track index point number. |
+--------+------------------------------------+
| u(3*8) | Reserved. All bits MUST be set to |
| | zero. |
+--------+------------------------------------+
Table 11
For CD-DA, the track index point offset MUST be evenly divisible by 588 samples (588 samples = 44100 samples/s * 1/75 s). Note that the offset is from the beginning of the track, not the beginning of the audio data.
CD-DAの場合、トラックインデックスポイントオフセットは588サンプル（588サンプル= 44100サンプル/s * 1/75秒）で均等に分割できる必要があります。オフセットは、オーディオデータの開始ではなく、トラックの開始からのものであることに注意してください。
For CD-DA, a track index point number of 0 corresponds to the track pre-gap. The first index point in a track MUST have a number of 0 or 1, and subsequently, index point numbers MUST increase by 1. Index point numbers MUST be unique within a track.
CD-DAの場合、トラックインデックスポイント番号0は、トラックのプレギャップに対応します。トラックの最初のインデックスポイントには0または1が多数ある必要があり、その後、インデックスポイント番号が1増加する必要があります。インデックスポイント番号はトラック内で一意でなければなりません。
The picture metadata block contains image data of a picture in some way belonging to the audio contained in the FLAC file. Its format is derived from the Attached Picture (APIC) frame in the ID3v2 specification; see [ID3v2]. However, contrary to the APIC frame in ID3v2, the media type and description are prepended with a 4-byte length field instead of being 0x00 delimited strings. A FLAC file MAY contain one or more picture metadata blocks.
画像メタデータブロックには、FLACファイルに含まれるオーディオに属する何らかの方法で、画像の画像データが含まれています。その形式は、ID3v2仕様の添付画像（APIC）フレームから派生しています。[id3v2]を参照してください。ただし、ID3v2のAPICフレームとは反対に、メディアタイプと説明は、0x00の区切り文字列ではなく、4バイトの長さフィールドで準備されています。FLACファイルには、1つ以上の画像メタデータブロックが含まれる場合があります。
Note that while the length fields for media type, description, and picture data are 4 bytes in length and could code for a size up to 4 GiB in theory, the total metadata block size cannot exceed what can be described by the metadata block header, i.e., 16 MiB.
メディアタイプ、説明、および画像データの長さフィールドの長さは4バイトで、理論的には最大4ギブのサイズをコーディングできますが、メタデータブロックサイズの合計はメタデータブロックヘッダーで説明できるものを超えることはできないことに注意してください。すなわち、16ミブ。
Instead of picture data, the picture metadata block can also contain a URI as described in [RFC3986].
画像データの代わりに、[RFC3986]に記載されているように、画像メタデータブロックにもURIを含めることができます。
The structure of a picture metadata block is enumerated in the following table.
画像メタデータブロックの構造は、次の表に列挙されています。
+========+==========================================================+
| Data | Description |
+========+==========================================================+
| u(32) | The picture type according to Table 13. |
+--------+----------------------------------------------------------+
| u(32) | The length of the media type string in bytes. |
+--------+----------------------------------------------------------+
| u(n*8) | The media type string as specified by [RFC2046], |
| | or the text string --> to signify that the data |
| | part is a URI of the picture instead of the |
| | picture data itself. This field must be in |
| | printable ASCII characters 0x20-0x7E. |
+--------+----------------------------------------------------------+
| u(32) | The length of the description string in bytes. |
+--------+----------------------------------------------------------+
| u(n*8) | The description of the picture in UTF-8. |
+--------+----------------------------------------------------------+
| u(32) | The width of the picture in pixels. |
+--------+----------------------------------------------------------+
| u(32) | The height of the picture in pixels. |
+--------+----------------------------------------------------------+
| u(32) | The color depth of the picture in bits per |
| | pixel. |
+--------+----------------------------------------------------------+
| u(32) | For indexed-color pictures (e.g., GIF), the |
| | number of colors used; 0 for non-indexed |
| | pictures. |
+--------+----------------------------------------------------------+
| u(32) | The length of the picture data in bytes. |
+--------+----------------------------------------------------------+
| u(n*8) | The binary picture data. |
+--------+----------------------------------------------------------+
Table 12
The height, width, color depth, and "number of colors" fields are for informational purposes only. Applications MUST NOT use them in decoding the picture or deciding how to display it, but applications MAY use them to decide whether or not to process a block (e.g., when selecting between different picture blocks) and MAY show them to the user. If a picture has no concept for any of these fields (e.g., vector images may not have a height or width in pixels) or the content of any field is unknown, the affected fields MUST be set to zero.
高さ、幅、色の深さ、「色の数」フィールドは、情報目的のみを目的としています。アプリケーションは、画像のデコードや表示方法の決定にそれらを使用してはなりませんが、アプリケーションはそれらを使用してブロックを処理するかどうか（例：異なる画像ブロック間を選択するとき）を決定し、ユーザーに表示する場合があります。これらのフィールドのいずれかの概念がない場合（たとえば、ベクトル画像にピクセルで高さや幅がない場合があります）、または任意のフィールドの内容が不明である場合、影響を受けるフィールドはゼロに設定する必要があります。
The following table contains all the defined picture types. Values other than those listed in the table are reserved. There MAY only be one each of picture types 1 and 2 in a file. In general practice, many FLAC playback devices and software display the contents of a picture metadata block, if present, with picture type 3 (front cover) during playback.
次の表には、定義されたすべての画像タイプが含まれています。テーブルにリストされている値以外の値は予約されています。ファイルには、それぞれの画像タイプ1と2のみが1つしかありません。一般的には、多くのFLAC再生デバイスとソフトウェアが、再生中に画像タイプ3（フロントカバー）を備えた画像メタデータブロックの内容を表示します。
+=======+=================================================+
| Value | Picture Type |
+=======+=================================================+
| 0 | Other |
+-------+-------------------------------------------------+
| 1 | PNG file icon of 32x32 pixels (see [RFC2083]) |
+-------+-------------------------------------------------+
| 2 | General file icon |
+-------+-------------------------------------------------+
| 3 | Front cover |
+-------+-------------------------------------------------+
| 4 | Back cover |
+-------+-------------------------------------------------+
| 5 | Liner notes page |
+-------+-------------------------------------------------+
| 6 | Media label (e.g., CD, Vinyl or Cassette label) |
+-------+-------------------------------------------------+
| 7 | Lead artist, lead performer, or soloist |
+-------+-------------------------------------------------+
| 8 | Artist or performer |
+-------+-------------------------------------------------+
| 9 | Conductor |
+-------+-------------------------------------------------+
| 10 | Band or orchestra |
+-------+-------------------------------------------------+
| 11 | Composer |
+-------+-------------------------------------------------+
| 12 | Lyricist or text writer |
+-------+-------------------------------------------------+
| 13 | Recording location |
+-------+-------------------------------------------------+
| 14 | During recording |
+-------+-------------------------------------------------+
| 15 | During performance |
+-------+-------------------------------------------------+
| 16 | Movie or video screen capture |
+-------+-------------------------------------------------+
| 17 | A bright colored fish |
+-------+-------------------------------------------------+
| 18 | Illustration |
+-------+-------------------------------------------------+
| 19 | Band or artist logotype |
+-------+-------------------------------------------------+
| 20 | Publisher or studio logotype |
+-------+-------------------------------------------------+
Table 13
The origin and use of value 17 ("A bright colored fish") is unclear. This was copied to maintain compatibility with ID3v2. Applications are discouraged from offering this value to users when embedding a picture.
値17（「明るい色の魚」）の起源と使用は不明です。これは、ID3v2との互換性を維持するためにコピーされました。アプリケーションは、写真を埋め込むときにユーザーにこの価値を提供することを思いとどまらせます。
If a URI (not a picture) is contained in this block, the following points apply:
このブロックにURI（写真ではない）が含まれている場合、次のポイントが適用されます。
* The URI can be in either absolute or relative form. If a URI is in relative form, it is related to the URI of the FLAC content processed.
* URIは、絶対的または相対的な形式になります。URIが相対的な形である場合、それは処理されたFLAC含有量のURIに関連しています。
* Applications MUST obtain explicit user approval to retrieve images via remote protocols and to retrieve local images that are not located in the same directory as the FLAC file being processed.
* アプリケーションは、リモートプロトコルを介して画像を取得し、処理されているFLACファイルと同じディレクトリにないローカル画像を取得するために、明示的なユーザー承認を取得する必要があります。
* Applications supporting linked images MUST handle unavailability of URIs gracefully. They MAY report unavailability to the user.
* リンクされた画像をサポートするアプリケーションは、URIの不可能性を優雅に処理する必要があります。ユーザーに利用不能を報告する場合があります。
* Applications MAY reject processing URIs for any reason, particularly for security or privacy reasons.
* アプリケーションは、特にセキュリティまたはプライバシーの理由により、何らかの理由でURIの処理を拒否する場合があります。
One or more frames follow directly after the last metadata block. Each frame consists of a frame header, one or more subframes, padding zero bits to achieve byte alignment, and a frame footer. The number of subframes in each frame is equal to the number of audio channels.
最後のメタデータブロックの直後に1つ以上のフレームが続きます。各フレームは、フレームヘッダー、1つ以上のサブフレーム、バイトアライメントを実現するためにゼロビットをパディングする、およびフレームフッターで構成されています。各フレームのサブフレームの数は、オーディオチャネルの数に等しくなります。
Each frame header stores the audio sample rate, number of bits per sample, and number of channels independently of the streaminfo metadata block and other frame headers. This was done to permit multicasting of FLAC files, but it also allows these properties to change mid-stream. Because not all environments in which FLAC decoders are used are able to cope with changes to these properties during playback, a decoder MAY choose to stop decoding on such a change. A decoder that does not check for such a change could be vulnerable to buffer overflows. See also Section 11.
各フレームヘッダーは、オーディオサンプルレート、サンプルあたりのビット数、およびStreaminfoメタデータブロックおよびその他のフレームヘッダーとは無関係にチャネルの数を保存します。これは、FLACファイルのマルチキャストを許可するために行われましたが、これらのプロパティが中間ストリームを変更することもできます。FLACデコーダーが使用されるすべての環境が再生中にこれらのプロパティの変更に対処できるわけではないため、デコーダーはそのような変更のデコードを停止することを選択できます。このような変更をチェックしないデコーダーは、バッファーオーバーフローに対して脆弱です。セクション11も参照してください。
Note that storing audio with changing audio properties in FLAC results in various practical problems. For example, these changes of audio properties must happen on a frame boundary or the process will not be lossless. When a variable block size is chosen to accommodate this, note that blocks smaller than 16 samples are not allowed; therefore, it is not possible to store an audio stream in which these properties change within 16 samples of the last change or the start of the file. Also, since the streaminfo metadata block can only accommodate a single set of properties, it is only valid for part of such an audio stream. Instead, it is RECOMMENDED to store an audio stream with changing properties in FLAC encapsulated in a container capable of handling such changes, as these do not suffer from the mentioned limitations. See Section 10 for details.
FLACのオーディオプロパティの変更でオーディオを保存すると、さまざまな実際的な問題が発生することに注意してください。たとえば、これらのオーディオプロパティの変更は、フレームの境界で発生する必要があります。または、プロセスがロスレスではありません。これに対応するために可変ブロックサイズが選択されている場合、16個未満のサンプルが許可されていないことに注意してください。したがって、これらのプロパティが最後の変更またはファイルの開始の16サンプル内で変更されるオーディオストリームを保存することはできません。また、Streaminfoメタデータブロックは単一のプロパティのみにのみ対応できるため、このようなオーディオストリームの一部にのみ有効です。代わりに、このような変更を処理できるコンテナにカプセル化されたFLACのプロパティの変更を伴うオーディオストリームを保存することをお勧めします。詳細については、セクション10を参照してください。
Each frame MUST start on a byte boundary and start with the 15-bit frame sync code 0b111111111111100. Following the sync code is the blocking strategy bit, which MUST NOT change during the audio stream. The blocking strategy bit is 0 for a fixed block size stream or 1 for a variable block size stream. If the blocking strategy is known, a decoder can include this bit when searching for the start of a frame to reduce the possibility of encountering a false positive, as the first two bytes of a frame are either 0xFFF8 for a fixed block size stream or 0xFFF9 for a variable block size stream.
各フレームはバイト境界で開始し、15ビットフレーム同期コード0B111111111111100から開始する必要があります。同期コードに従うことは、ブロッキング戦略ビットです。これは、オーディオストリーム中に変更してはなりません。ブロッキング戦略ビットは、固定ブロックサイズのストリームの場合は0、可変ブロックサイズストリームの場合は1です。ブロッキング戦略がわかっている場合、デコーダーはフレームの開始を検索するときにこのビットを含めることができます。フレームの最初の2バイトは固定ブロックサイズストリームの0xfff8または0xfff9のいずれかであるため、可変ブロックサイズのストリームの場合。
Following the frame sync code and blocking strategy bit are 4 bits (the first 4 bits of the third byte of each frame) referred to as the block size bits. Their value relates to the block size according to the following table, where v is the value of the 4 bits as an unsigned number. If the block size bits code for an uncommon block size, this is stored after the coded number; see Section 9.1.6.
フレームの同期コードとブロッキング戦略ビットに続くのは、ブロックサイズビットと呼ばれる4ビット（各フレームの3番目のバイトの最初の4ビット）です。それらの値は、次の表に従ってブロックサイズに関連しています。ここで、Vは署名されていない数値として4ビットの値です。ブロックサイズが珍しいブロックサイズのコードをビットする場合、これはコード化された数字の後に保存されます。セクション9.1.6を参照してください。
+=================+=============================================+
| Value | Block Size |
+=================+=============================================+
| 0b0000 | Reserved |
+-----------------+---------------------------------------------+
| 0b0001 | 192 |
+-----------------+---------------------------------------------+
| 0b0010 - 0b0101 | 144 * (2^v), i.e., 576, 1152, 2304, or 4608 |
+-----------------+---------------------------------------------+
| 0b0110 | Uncommon block size minus 1, stored as an |
| | 8-bit number |
+-----------------+---------------------------------------------+
| 0b0111 | Uncommon block size minus 1, stored as a |
| | 16-bit number |
+-----------------+---------------------------------------------+
| 0b1000 - 0b1111 | 2^v, i.e., 256, 512, 1024, 2048, 4096, |
| | 8192, 16384, or 32768 |
+-----------------+---------------------------------------------+
Table 14
The next 4 bits (the last 4 bits of the third byte of each frame), referred to as the sample rate bits, contain the sample rate of the audio according to the following table. If the sample rate bits code for an uncommon sample rate, this is stored after the uncommon block size; if no uncommon block size was used, this is stored after the coded number. See Section 9.1.7.
サンプルレートビットと呼ばれる次の4ビット（各フレームの3番目のバイトの最後の4ビット）には、次の表に従ってオーディオのサンプルレートが含まれています。If the sample rate bits code for an uncommon sample rate, this is stored after the uncommon block size;if no uncommon block size was used, this is stored after the coded number.See Section 9.1.7.
+========+==========================================================+
| Value | Sample Rate |
+========+==========================================================+
| 0b0000 | Sample rate only stored in the |
| | streaminfo metadata block |
+--------+----------------------------------------------------------+
| 0b0001 | 88.2 kHz |
+--------+----------------------------------------------------------+
| 0b0010 | 176.4 kHz |
+--------+----------------------------------------------------------+
| 0b0011 | 192 kHz |
+--------+----------------------------------------------------------+
| 0b0100 | 8 kHz |
+--------+----------------------------------------------------------+
| 0b0101 | 16 kHz |
+--------+----------------------------------------------------------+
| 0b0110 | 22.05 kHz |
+--------+----------------------------------------------------------+
| 0b0111 | 24 kHz |
+--------+----------------------------------------------------------+
| 0b1000 | 32 kHz |
+--------+----------------------------------------------------------+
| 0b1001 | 44.1 kHz |
+--------+----------------------------------------------------------+
| 0b1010 | 48 kHz |
+--------+----------------------------------------------------------+
| 0b1011 | 96 kHz |
+--------+----------------------------------------------------------+
| 0b1100 | Uncommon sample rate in kHz, |
| | stored as an 8-bit number |
+--------+----------------------------------------------------------+
| 0b1101 | Uncommon sample rate in Hz, stored |
| | as a 16-bit number |
+--------+----------------------------------------------------------+
| 0b1110 | Uncommon sample rate in Hz divided |
| | by 10, stored as a 16-bit number |
+--------+----------------------------------------------------------+
| 0b1111 | Forbidden |
+--------+----------------------------------------------------------+
Table 15
The next 4 bits (the first 4 bits of the fourth byte of each frame), referred to as the channels bits, contain both the number of channels of the audio as well as any stereo decorrelation used according to the following table.
次の4ビット（各フレームの4番目のバイトの最初の4ビット）は、チャンネルビットと呼ばれ、オーディオのチャネル数と、次の表に従って使用されるステレオ除去の両方を含む。
If a channel layout different than the ones listed in the following table is used, this can be signaled with a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag in a Vorbis comment metadata block; see Section 8.6.2 for details. Note that even when such a different channel layout is specified with a WAVEFORMATEXTENSIBLE_CHANNEL_MASK and the channel ordering in the following table is overridden, the channels bits still contain the actual number of channels coded in the frame. For details on the way left-side, side-right, and mid-side stereo are coded, see Section 4.2.
次の表にリストされているものとは異なるチャネルレイアウトが使用される場合、これはVorbisコメントメタデータブロックに波形Xtensible_Channel_Maskタグで信号を送ることができます。詳細については、セクション8.6.2を参照してください。このような異なるチャネルレイアウトがWaveformatextensible_Channel_Maskで指定されている場合でも、次の表のチャネルの順序付けがオーバーライドされている場合、チャネルビットにはフレームにコードされた実際の数のチャネル数が含まれています。左サイド、サイドライト、およびミッドサイドのステレオの方法の詳細については、セクション4.2を参照してください。
+==========+====================================================+
| Value | Channels |
+==========+====================================================+
| 0b0000 | 1 channel: mono |
+----------+----------------------------------------------------+
| 0b0001 | 2 channels: left, right |
+----------+----------------------------------------------------+
| 0b0010 | 3 channels: left, right, center |
+----------+----------------------------------------------------+
| 0b0011 | 4 channels: front left, front right, back left, |
| | back right |
+----------+----------------------------------------------------+
| 0b0100 | 5 channels: front left, front right, front center, |
| | back/surround left, back/surround right |
+----------+----------------------------------------------------+
| 0b0101 | 6 channels: front left, front right, front center, |
| | LFE, back/surround left, back/surround right |
+----------+----------------------------------------------------+
| 0b0110 | 7 channels: front left, front right, front center, |
| | LFE, back center, side left, side right |
+----------+----------------------------------------------------+
| 0b0111 | 8 channels: front left, front right, front center, |
| | LFE, back left, back right, side left, side right |
+----------+----------------------------------------------------+
| 0b1000 | 2 channels: left, right; stored as left-side |
| | stereo |
+----------+----------------------------------------------------+
| 0b1001 | 2 channels: left, right; stored as side-right |
| | stereo |
+----------+----------------------------------------------------+
| 0b1010 | 2 channels: left, right; stored as mid-side stereo |
+----------+----------------------------------------------------+
| 0b1011 - | Reserved |
| 0b1111 | |
+----------+----------------------------------------------------+
Table 16
The next 3 bits (bits 5, 6, and 7 of each fourth byte of each frame) contain the bit depth of the audio according to the following table. The next bit is reserved and MUST be zero.
次の3ビット（各フレームの各4バイトのビット5、6、および7）には、次の表に従ってオーディオのビット深さが含まれています。次のビットは予約されており、ゼロでなければなりません。
+=======+========================================================+
| Value | Bit Depth |
+=======+========================================================+
| 0b000 | Bit depth only stored in the streaminfo metadata block |
+-------+--------------------------------------------------------+
| 0b001 | 8 bits per sample |
+-------+--------------------------------------------------------+
| 0b010 | 12 bits per sample |
+-------+--------------------------------------------------------+
| 0b011 | Reserved |
+-------+--------------------------------------------------------+
| 0b100 | 16 bits per sample |
+-------+--------------------------------------------------------+
| 0b101 | 20 bits per sample |
+-------+--------------------------------------------------------+
| 0b110 | 24 bits per sample |
+-------+--------------------------------------------------------+
| 0b111 | 32 bits per sample |
+-------+--------------------------------------------------------+
Table 17
Following the reserved bit (starting at the fifth byte of the frame) is either a sample or a frame number, which will be referred to as the coded number. When dealing with variable block size streams, the sample number of the first sample in the frame is encoded. When the file contains a fixed block size stream, the frame number is encoded. See Section 9.1 on the blocking strategy bit, which signals whether a stream is a fixed block size stream or a variable block size stream. See also Appendix B.1.
予約されたビット（フレームの5番目のバイトから始まる）に続くのは、サンプルまたはフレーム番号のいずれかで、コード化された番号と呼ばれます。可変ブロックサイズのストリームを扱うとき、フレーム内の最初のサンプルのサンプル番号がエンコードされます。ファイルに固定ブロックサイズのストリームが含まれている場合、フレーム番号がエンコードされます。ブロッキング戦略ビットのセクション9.1を参照してください。これは、ストリームが固定ブロックサイズのストリームであるか、可変ブロックサイズのストリームであるかを示すものです。付録B.1も参照してください。
The coded number is stored in a variable-length code like UTF-8 as defined in [RFC3629] but extended to a maximum of 36 bits unencoded or 7 bytes encoded.
コード化された数値は、[RFC3629]で定義されているようにUTF-8のような可変長コードに保存されますが、エンコードされていない最大36ビットまたはエンコードされた7バイトに拡張されます。
When a frame number is encoded, the value MUST NOT be larger than what fits a value of 31 bits unencoded or 6 bytes encoded. Please note that as most general purpose UTF-8 encoders and decoders follow [RFC3629], they will not be able to handle these extended codes. Furthermore, while UTF-8 is specifically used to encode characters, FLAC uses it to encode numbers instead. To encode or decode a coded number, follow the procedures in Section 3 of [RFC3629], but instead of using a character number, use a frame or sample number. In addition, use the extended table below instead of the table in Section 3 of [RFC3629].
フレーム番号がエンコードされている場合、値は、エンコードされていない31ビットまたはエンコードされた6バイトの値よりも大きくてはなりません。ほとんどの汎用目的UTF-8エンコーダーとデコーダーが続くため[RFC3629]、これらの拡張コードを処理できないことに注意してください。さらに、UTF-8は特に文字をエンコードするために使用されますが、FLACは代わりに数値をエンコードするために使用します。コード化された番号をエンコードまたはデコードするには、[RFC3629]のセクション3の手順に従ってください。ただし、文字番号を使用する代わりに、フレームまたはサンプル番号を使用します。さらに、[RFC3629]のセクション3の表の代わりに、下の拡張テーブルを使用します。
+============================+=====================================+
| Number Range (Hexadecimal) | Octet Sequence (Binary) |
+============================+=====================================+
| 0000 0000 0000 - | 0xxxxxxx |
| 0000 0000 007F | |
+----------------------------+-------------------------------------+
| 0000 0000 0080 - | 110xxxxx 10xxxxxx |
| 0000 0000 07FF | |
+----------------------------+-------------------------------------+
| 0000 0000 0800 - | 1110xxxx 10xxxxxx 10xxxxxx |
| 0000 0000 FFFF | |
+----------------------------+-------------------------------------+
| 0000 0001 0000 - | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
| 0000 001F FFFF | |
+----------------------------+-------------------------------------+
| 0000 0020 0000 - | 111110xx 10xxxxxx 10xxxxxx 10xxxxxx |
| 0000 03FF FFFF | 10xxxxxx |
+----------------------------+-------------------------------------+
| 0000 0400 0000 - | 1111110x 10xxxxxx 10xxxxxx 10xxxxxx |
| 0000 7FFF FFFF | 10xxxxxx 10xxxxxx |
+----------------------------+-------------------------------------+
| 0000 8000 0000 - | 11111110 10xxxxxx 10xxxxxx 10xxxxxx |
| 000F FFFF FFFF | 10xxxxxx 10xxxxxx 10xxxxxx |
+----------------------------+-------------------------------------+
Table 18
If the coded number is a frame number, it MUST be equal to the number of frames preceding the current frame. If the coded number is a sample number, it MUST be equal to the number of samples preceding the current frame. In a stream where these requirements are not met, seeking is not (reliably) possible.
コード化された番号がフレーム番号の場合、現在のフレームの前のフレームの数に等しくなければなりません。コード化された数値がサンプル番号の場合、現在のフレームの前のサンプルの数に等しくなければなりません。これらの要件が満たされないストリームでは、求めることは（確実に）不可能です。
For example, for a frame that belongs to a variable block size stream and has exactly 51 billion samples preceding it, the coded number is constructed as follows:
たとえば、可変ブロックサイズのストリームに属し、その先に510億のサンプルがあるフレームの場合、コード化された数値は次のように構築されます。
Octets 1-5
0b11111110 0b10101111 0b10011111 0b10110101 0b10100011
^^^^^^ ^^^^^^ ^^^^^^ ^^^^^^
| | | Bits 18-13
| | Bits 24-19
| Bits 30-25
Bits 36-31
Octets 6-7
0b10111000 0b10000000
^^^^^^ ^^^^^^
| Bits 6-1
Bits 12-7
A decoder that relies on the coded number during seeking could be vulnerable to buffer overflows or getting stuck in an infinite loop if it seeks in a stream where the coded numbers are not strictly increasing or are otherwise not valid. See also Section 11.
シーク中にコード化された数値に依存するデコーダーは、コード化された数値が厳密に増加していないか、そうでなければ有効でないストリームで探す場合、バッファーオーバーフローや無限のループに詰まっていることに対して脆弱である可能性があります。セクション11も参照してください。
If the block size bits defined earlier in this section are 0b0110 or 0b0111 (uncommon block size minus 1 stored), the block size minus 1 follows the coded number as either an 8-bit or 16-bit unsigned number coded big-endian. A value of 65535 (corresponding to a block size of 65536) is forbidden and MUST NOT be used, because such a block size cannot be represented in the streaminfo metadata block. A value from 0 up to (and including) 14, which corresponds to a block size from 1 to 15, is only valid for the last frame in a stream and MUST NOT be used for any other frame. See also Section 8.2.
このセクションの前半に定義されたブロックサイズビットが0B0110または0B0111（除外されていない未知のブロックサイズマイナス1保存）の場合、ブロックサイズマイナス1は、コード化された数を8ビットまたは16ビットの符号なしの数字コード化されたビッグエンディアンとして追跡します。65535の値（65536のブロックサイズに対応）は禁止されており、そのようなブロックサイズをStreaminfoメタデータブロックで表すことができないため、使用してはなりません。1から15までのブロックサイズに対応する0から（および含む）14から14までの値は、ストリーム内の最後のフレームに対してのみ有効であり、他のフレームには使用してはなりません。セクション8.2も参照してください。
If the sample rate bits are 0b1100, 0b1101, or 0b1110 (uncommon sample rate stored), the sample rate follows the uncommon block size (or the coded number if no uncommon block size is stored) as either an 8-bit or a 16-bit unsigned number coded big-endian.
サンプルレートビットが0B1100、0B1101、または0B1110（サンプルレートを格納していない）の場合、サンプルレートは、8ビットまたは16-のいずれかとして、CONCOMMONブロックサイズがない場合はコード化された数値を使用していない場合）に従います。ビット署名数字コード化されたビッグエンディアン。
The sample rate MUST NOT be 0 when the subframe contains audio. A sample rate of 0 MAY be used when non-audio is represented. See Section 8.2 for details.
サブフレームにオーディオが含まれている場合、サンプルレートは0ではありません。非オーディオが表される場合、0のサンプルレートを使用できます。詳細については、セクション8.2を参照してください。
Finally, an 8-bit CRC follows the frame/sample number, an uncommon block size, or an uncommon sample rate (depending on whether the latter two are stored). This CRC is initialized with 0 and has the polynomial x^8 + x^2 + x^1 + x^0. This CRC covers the whole frame header before the CRC, including the sync code.
最後に、8ビットCRCは、フレーム/サンプル番号、珍しいブロックサイズ、または珍しいサンプルレートに従います（後者の2つが保存されているかどうかに応じて）。このCRCは0で初期化され、多項式x^8 + x^2 + x^1 + x^0があります。このCRCは、同期コードを含むCRCの前にフレームヘッダー全体をカバーします。
Following the frame header are a number of subframes equal to the number of audio channels. Note that subframes contain a bitstream that does not necessarily have to be a whole number of bytes, so only the first subframe starts at a byte boundary.
フレームヘッダーに従うことは、オーディオチャネルの数に等しい多数のサブフレームがあります。サブフレームには、必ずしもすべてのバイトである必要はないビットストリームが含まれているため、最初のサブフレームのみがバイト境界で始まることに注意してください。
Each subframe starts with a header. The first bit of the header MUST be 0, followed by 6 bits that describe which subframe type is used according to the following table, where v is the value of the 6 bits as an unsigned number.
各サブフレームはヘッダーから始まります。ヘッダーの最初のビットは0でなければなりません。その後、次の表に従って使用されるサブフレームタイプを説明する6ビットが続きます。ここで、vは6ビットの値が符号なし数として値です。
+=====================+===========================================+
| Value | Subframe Type |
+=====================+===========================================+
| 0b000000 | Constant subframe |
+---------------------+-------------------------------------------+
| 0b000001 | Verbatim subframe |
+---------------------+-------------------------------------------+
| 0b000010 - 0b000111 | Reserved |
+---------------------+-------------------------------------------+
| 0b001000 - 0b001100 | Subframe with a fixed predictor of order |
| | v-8; i.e., 0, 1, 2, 3 or 4 |
+---------------------+-------------------------------------------+
| 0b001101 - 0b011111 | Reserved |
+---------------------+-------------------------------------------+
| 0b100000 - 0b111111 | Subframe with a linear predictor of order |
| | v-31; i.e., 1 through 32 (inclusive) |
+---------------------+-------------------------------------------+
Table 19
Following the subframe type bits is a bit that flags whether the subframe uses any wasted bits (see Section 9.2.2). If the flag bit is 0, the subframe doesn't use any wasted bits and the subframe header is complete. If the flag bit is 1, the subframe uses wasted bits and the number of used wasted bits minus 1 appears in unary form, directly following the flag bit.
サブフレームタイプのビットに従うことは、サブフレームが無駄なビットを使用するかどうかにフラグを立てることに少しです（セクション9.2.2を参照）。フラグビットが0の場合、サブフレームは無駄なビットを使用せず、サブフレームヘッダーが完了します。フラグビットが1の場合、サブフレームは無駄なビットを使用し、使用済みビットマイナス1の数は、フラグビットに直接続く統一形式で表示されます。
Most uncompressed audio file formats can only store audio samples with a bit depth that is an integer number of bytes. Samples in which the bit depth is not an integer number of bytes are usually stored in such formats by padding them with least-significant zero bits to a bit depth that is an integer number of bytes. For example, shifting a 14-bit sample right by 2 pads it to a 16-bit sample, which then has two zero least-significant bits. In this specification, these least-significant zero bits are referred to as wasted bits per sample or simply wasted bits. They are wasted in the sense that they contain no information but are stored anyway.
ほとんどの非圧縮オーディオファイル形式は、整数のバイト数である少し深さでオーディオサンプルのみを保存できます。ビット深度が整数数のバイト数ではないサンプルは、通常、整数ゼロビットで整数の深さであるバイト数であるビット深度にパディングすることにより、そのような形式で保存されます。たとえば、14ビットのサンプルを2倍にシフトすると、16ビットのサンプルにパッドを配置し、2つの最小重要なビットがあります。この仕様では、これらの最も重要でないゼロビットは、サンプルごとに無駄なビットまたは単に無駄なビットと呼ばれます。彼らは情報を含んでいないがとにかく保存されているという意味で無駄になります。
The FLAC format can optionally take advantage of these wasted bits by signaling their presence and coding the subframe without them. To do this, the wasted bits per sample flag in a subframe header is set to 1 and the number of wasted bits per sample (k) minus 1 follows the flag in an unary encoding. For example, if k is 3, 0b001 follows. If k = 0, the wasted bits per sample flag is 0 and no unary-coded k follows. In this document, if a subframe header signals a certain number of wasted bits, it is said it "uses" these wasted bits.
FLAC形式は、オプションでこれらの無駄なビットを利用して、それらの存在を通知し、サブフレームを使用せずにコーディングすることにより、これらの無駄なビットを利用できます。これを行うために、サブフレームヘッダーのサンプルフラグごとの無駄なビットは1に設定され、サンプルあたりの無駄なビット数（k）マイナス1は、単位エンコードでフラグに続きます。たとえば、Kが3の場合、0B001が続きます。k = 0の場合、サンプルフラグごとに無駄なビットが0であり、unary-coded kは続きません。このドキュメントでは、サブフレームヘッダーが一定数の無駄なビットを信号する場合、これらの無駄なビットを「使用」すると言われています。
If a subframe uses wasted bits (i.e., k is not equal to 0), samples are coded ignoring k least-significant bits. For example, if a frame not employing stereo decorrelation specifies a sample size of 16 bits per sample in the frame header and k of a subframe is 3, samples in the subframe are coded as 13 bits per sample. For more details, see Section 9.2.3 on how the bit depth of a subframe is calculated. A decoder MUST add k least-significant zero bits by shifting left (padding) after decoding a subframe sample. If the frame has left-side, side-right, or mid-side stereo, a decoder MUST perform padding on the subframes before restoring the channels to left and right. The number of wasted bits per sample MUST be such that the resulting number of bits per sample (of which the calculation is explained in Section 9.2.3) is larger than zero.
サブフレームが無駄なビットを使用している場合（つまり、Kは0に等しくない）、サンプルはKの最も重要なビットを無視してコード化されます。たとえば、ステレオ脱線を使用していないフレームがフレームヘッダーのサンプルあたり16ビットのサンプルサイズを指定し、サブフレームのKのKが3の場合、サブフレームのサンプルはサンプルごとに13ビットとしてコーディングされます。詳細については、サブフレームのビット深さの計算方法については、セクション9.2.3を参照してください。デコーダーは、サブフレームサンプルをデコードした後、左（パディング）をシフトすることにより、Kの最小重要なゼロビットを追加する必要があります。フレームに左側、側面、または中央のステレオがある場合、デコーダーはチャネルを左右に復元する前にサブフレームでパディングを実行する必要があります。サンプルあたりの無駄なビット数は、サンプルあたりのビット数（セクション9.2.3で説明されている）がゼロよりも大きいようにする必要があります。
Besides audio files that have a certain number of wasted bits for the whole file, audio files exist in which the number of wasted bits varies. There are DVD-Audio discs in which blocks of samples have had their least-significant bits selectively zeroed to slightly improve the compression of their otherwise lossless Meridian Lossless Packing codec; see [MLP]. There are also audio processors like lossyWAV (see [lossyWAV]) that zero a number of least-significant bits for a block of samples, increasing the compression in a non-lossless way. Because of this, the number of wasted bits k MAY change between frames and MAY differ between subframes. If the number of wasted bits changes halfway through a subframe (e.g., the first part has 2 wasted bits and the second part has 4 wasted bits), the subframe uses the lowest number of wasted bits; otherwise, non-zero bits would be discarded, and the process would not be lossless.
ファイル全体に一定数の無駄なビットを持つオーディオファイルに加えて、無駄なビットの数が異なるオーディオファイルが存在します。サンプルのブロックが最も重要でないビットを選択的にゼロにして、それ以外の場合は損失のない子午線ロスレスパッキングコーデックの圧縮をわずかに改善するDVD-Audioディスクがあります。[MLP]を参照してください。また、サンプルのブロックで最も重要な少ないビットをゼロでゼロで、損失のない方法で圧縮を増加させる、losywav（[losywav]を参照）などのオーディオプロセッサもあります。このため、無駄なビットkの数はフレーム間で変化し、サブフレーム間で異なる場合があります。無駄なビットの数がサブフレームの途中で変化する場合（たとえば、最初の部分には2つの無駄なビットがあり、2番目の部分には4つのビットが4つあります）、サブフレームは無駄なビットの数が最も少ないです。そうしないと、ゼロ以外のビットが破棄され、プロセスはロスレスになりません。
In a constant subframe, only a single sample is stored. This sample is stored as an integer number coded big-endian, signed two's complement. The number of bits used to store this sample depends on the bit depth of the current subframe. The bit depth of a subframe is equal to the bit depth as coded in the frame header (see Section 9.1.4) minus the number of used wasted bits coded in the subframe header (see Section 9.2.2). If a subframe is a side subframe (see Section 4.2), the bit depth of that subframe is increased by 1 bit.
一定のサブフレームでは、1つのサンプルのみが保存されます。このサンプルは、ビッグエンディアンのコード化された整数番号として保存され、2人の補完に署名されています。このサンプルを保存するために使用されるビットの数は、現在のサブフレームのビット深度に依存します。サブフレームのビット深度は、フレームヘッダーでコード化されたビット深度に等しくなります（セクション9.1.4を参照）は、サブフレームヘッダーでコード化された使用された無駄なビットの数を差し引いて（セクション9.2.2を参照）。サブフレームがサイドサブフレームである場合（セクション4.2を参照）、そのサブフレームのビット深度は1ビット増加します。
A verbatim subframe stores all samples unencoded in sequential order. See Section 9.2.3 on how a sample is stored unencoded. The number of samples that need to be stored in a subframe is provided by the block size in the frame header.
逐語的なサブフレームは、順次順序でエンコードされていないすべてのサンプルを保存します。サンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。サブフレームに保存する必要があるサンプルの数は、フレームヘッダーのブロックサイズによって提供されます。
Five different fixed predictors are defined in the following table, one for each prediction order 0 through 4. The table also contains a derivation that explains the rationale for choosing these fixed predictors.
次の表には、5つの異なる固定予測子が定義されています。1つは予測順序0〜4です。表には、これらの固定予測因子を選択する理論的根拠を説明する派生も含まれています。
+=======+==================================+======================+
| Order | Prediction | Derivation |
+=======+==================================+======================+
| 0 | 0 | N/A |
+-------+----------------------------------+----------------------+
| 1 | a(n-1) | N/A |
+-------+----------------------------------+----------------------+
| 2 | 2 * a(n-1) - a(n-2) | a(n-1) + a'(n-1) |
+-------+----------------------------------+----------------------+
| 3 | 3 * a(n-1) - 3 * a(n-2) + a(n-3) | a(n-1) + a'(n-1) + |
| | | a''(n-1) |
+-------+----------------------------------+----------------------+
| 4 | 4 * a(n-1) - 6 * a(n-2) + 4 * | a(n-1) + a'(n-1) + |
| | a(n-3) - a(n-4) | a''(n-1) + a'''(n-1) |
+-------+----------------------------------+----------------------+
Table 20
Where:
ただし：
* n is the number of the sample being predicted.
* nは予測されるサンプルの数です。
* a(n) is the sample being predicted.
* A（n）は予測されるサンプルです。
* a(n-1) is the sample before the one being predicted.
* A（n-1）は、予測される前のサンプルです。
* a'(n-1) is the difference between the previous sample and the sample before that, i.e., a(n-1) - a(n-2). This is the closest available first-order discrete derivative.
* a '（n-1）は、前のサンプルとその前のサンプルの違い、すなわちa（n-1）-a（n-2）です。これは、最も近い1次離散微分です。
* a''(n-1) is a'(n-1) - a'(n-2) or the closest available second-order discrete derivative.
* a ''（n-1）はa '（n-1） - a'（n-2）または最も近い2次離散微分です。
* a'''(n-1) is a''(n-1) - a''(n-2) or the closest available third-order discrete derivative.
* a '' '（n-1）はa' '（n-1）-a' '（n-2）または最も近い3次離散微分です。
As a predictor makes use of samples preceding the sample that is predicted, it can only be used when enough samples are known. As each subframe in FLAC is coded completely independently, the first few samples in each subframe cannot be predicted. Therefore, a number of so-called warm-up samples equal to the predictor order is stored. These are stored unencoded, bypassing the predictor and residual coding stages. See Section 9.2.3 on how samples are stored unencoded. The table below defines how a fixed predictor subframe appears in the bitstream.
予測子は、予測されるサンプルの前のサンプルを使用するため、十分なサンプルがわかっている場合にのみ使用できます。FLACの各サブフレームは完全に独立してコーディングされるため、各サブフレームの最初の数サンプルは予測できません。したがって、予測順に等しいいわゆるウォームアップサンプルが保存されます。これらは、予測因子と残留コーディング段階をバイパスして、エンコードされていない保存されます。サンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。以下の表は、BitStreamに固定予測サブフレームがどのように表示されるかを定義しています。
+==========+===========================================+
| Data | Description |
+==========+===========================================+
| s(n) | Unencoded warm-up samples (n = subframe's |
| | bits per sample * predictor order). |
+----------+-------------------------------------------+
| Coded | Coded residual as defined in |
| residual | Section 9.2.7 |
+----------+-------------------------------------------+
Table 21
Because fixed predictors are specified, they do not have to be stored. The fixed predictor order, which is stored in the subframe header, specifies which predictor is used.
固定予測子が指定されているため、保存する必要はありません。サブフレームヘッダーに保存されている固定予測順序は、どの予測子が使用されるかを指定します。
To encode a signal with a fixed predictor, each sample has the corresponding prediction subtracted and sent to the residual coder. To decode a signal with a fixed predictor, the residual is decoded, and then the prediction can be added for each sample. This means that decoding is necessarily a sequential process within a subframe, as for each sample, enough fully decoded previous samples are needed to calculate the prediction.
固定予測子を使用して信号をエンコードするために、各サンプルには対応する予測が差し引かれ、残差コーダーに送信されます。固定予測子で信号をデコードするために、残差がデコードされ、各サンプルに予測を追加できます。つまり、デコードは必然的にサブフレーム内の連続プロセスであり、各サンプルと同様に、予測を計算するのに十分な完全にデコードされた以前のサンプルが必要であることを意味します。
For fixed predictor order 0, the prediction is always 0; thus, each residual sample is equal to its corresponding input or decoded sample. The difference between a fixed predictor with order 0 and a verbatim subframe is that a verbatim subframe stores all samples unencoded while a fixed predictor with order 0 has all its samples processed by the residual coder.
固定された予測因子順序0の場合、予測は常に0です。したがって、各残差サンプルは、対応する入力またはデコードされたサンプルに等しくなります。順序0の固定予測子と逐語的なサブフレームの違いは、逐語的なサブフレームがすべてのサンプルをエンコードされていないすべてのサンプルを保存し、注文0の固定予測子にはすべてのサンプルが残差コーダーによって処理されていることです。
The first-order fixed predictor is comparable to how differential pulse-code modulation (DPCM) encoding works, as the resulting residual sample is the difference between the corresponding sample and the sample before it. The higher-order fixed predictors can be understood as polynomials fitted to the previous samples.
一次固定予測子は、結果の残差サンプルが対応するサンプルとその前のサンプルの違いであるため、微分パルスコード変調（DPCM）エンコーディングがどのように機能するかに匹敵します。高次の固定予測因子は、以前のサンプルに適合した多項式として理解できます。
Whereas fixed predictors are well suited for simple signals, using a (non-fixed) linear predictor on more complex signals can improve compression by making the residual samples even smaller. There is a certain trade-off, however, as storing the predictor coefficients takes up space as well.
一方、固定された予測因子は単純な信号に適していますが、より複雑な信号に（固定されていない）線形予測因子を使用すると、残差サンプルをさらに小さくすることで圧縮を改善できます。ただし、予測係数を保存することもスペースを占めるため、特定のトレードオフがあります。
In the FLAC format, a predictor is defined by up to 32 predictor coefficients and a shift. To form a prediction, each coefficient is multiplied by its corresponding past sample, the results are summed, and this sum is then shifted. To encode a signal with a linear predictor, each sample has the corresponding prediction subtracted and sent to the residual coder. To decode a signal with a linear predictor, the residual is decoded, and then the prediction can be added for each sample. This means that decoding MUST be a sequential process within a subframe, as enough decoded samples are needed to calculate the prediction for each sample.
FLAC形式では、予測子は最大32の予測係数とシフトによって定義されます。予測を形成するために、各係数に対応する過去のサンプルを掛け、結果が合計され、この合計がシフトされます。線形予測子を使用して信号をエンコードするために、各サンプルには対応する予測が減算され、残差コーダーに送信されます。線形予測因子で信号をデコードするために、残差がデコードされ、各サンプルに予測を追加できます。つまり、各サンプルの予測を計算するのに十分なデコードされたサンプルが必要であるため、デコードはサブフレーム内の順次プロセスでなければなりません。
The table below defines how a linear predictor subframe appears in the bitstream.
以下の表は、ビットストリームに線形予測サブフレームがどのように表示されるかを定義しています。
+==========+==========================================+
| Data | Description |
+==========+==========================================+
| s(n) | Unencoded warm-up samples (n = |
| | subframe's bits per sample * LPC order). |
+----------+------------------------------------------+
| u(4) | (Predictor coefficient precision in |
| | bits)-1 (Note: 0b1111 is forbidden). |
+----------+------------------------------------------+
| s(5) | Prediction right shift needed in bits. |
+----------+------------------------------------------+
| s(n) | Predictor coefficients (n = predictor |
| | coefficient precision * LPC order). |
+----------+------------------------------------------+
| Coded | Coded residual as defined in |
| residual | Section 9.2.7. |
+----------+------------------------------------------+
Table 22
See Section 9.2.3 on how the warm-up samples are stored unencoded. The predictor coefficients are stored as an integer number coded big-endian, signed two's complement, where the number of bits needed for each coefficient is defined by the predictor coefficient precision. While the prediction right shift is signed two's complement, this number MUST NOT be negative; see Appendix B.4 for an explanation why this is.
ウォームアップサンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。予測係数は、各係数に必要なビット数が予測係数精度によって定義される2つの補数に署名された2つの補数に署名された整数の補体された整数数として保存されます。予測の正しいシフトはTwoの補完に署名されていますが、この数は否定的であってはなりません。これがなぜであるかについては、付録B.4を参照してください。
Please note that the order in which the predictor coefficients appear in the bitstream corresponds to which *past* sample they belong to. In other words, the order of the predictor coefficients is opposite to the chronological order of the samples. So, the first predictor coefficient has to be multiplied with the sample directly before the sample that is being predicted, the second predictor coefficient has to be multiplied with the sample before that, etc.
ビットストリームに予測係数が表示される順序は、それらが属している *過去 *サンプルに対応することに注意してください。言い換えれば、予測係数の順序は、サンプルの時系列の順序とは反対です。したがって、最初の予測係数は、予測されるサンプルの直前にサンプルとの直前に、2番目の予測係数をその前にサンプルに乗算する必要があります。
The first two bits in a coded residual indicate which coding method is used. See the table below.
コード化された残差の最初の2つのビットは、どのコーディング方法が使用されているかを示します。以下の表を参照してください。
+=============+=============================================+
| Value | Description |
+=============+=============================================+
| 0b00 | Partitioned Rice code with 4-bit parameters |
+-------------+---------------------------------------------+
| 0b01 | Partitioned Rice code with 5-bit parameters |
+-------------+---------------------------------------------+
| 0b10 - 0b11 | Reserved |
+-------------+---------------------------------------------+
Table 23
Both defined coding methods work the same way but differ in the number of bits used for Rice parameters. The 4 bits that directly follow the coding method bits form the partition order, which is an unsigned number. The rest of the coded residual consists of 2^(partition order) partitions. For example, if the 4 bits are 0b1000, the partition order is 8, and the residual is split up into 2^8 = 256 partitions.
両方の定義されたコーディングメソッドは同じように機能しますが、イネパラメーターに使用されるビットの数が異なります。コーディングメソッドビットに直接続く4ビットは、パーティション順序を形成します。これは署名されていない数字です。コード化された残りの残りの部分は、2^（パーティションの順序）パーティションで構成されています。たとえば、4ビットが0B1000の場合、パーティション順序は8で、残差は2^8 = 256パーティションに分割されます。
Each partition contains a certain number of residual samples. The number of residual samples in the first partition is equal to (block size >> partition order) - predictor order, i.e., the block size divided by the number of partitions minus the predictor order. In all other partitions, the number of residual samples is equal to (block size >> partition order).
各パーティションには、一定数の残差サンプルが含まれています。最初のパーティションの残差サンプルの数は、（ブロックサイズ>>パーティション順序） - 予測順、つまり、ブロックサイズをパーティションの数を差し引いて予測順に除算します。他のすべてのパーティションでは、残差サンプルの数は（ブロックサイズ>>パーティション順序）に等しくなります。
The partition order MUST be such that the block size is evenly divisible by the number of partitions. This means, for example, that only partition order 0 is allowed for all odd block sizes. The partition order also MUST be such that the (block size >> partition order) is larger than the predictor order. This means, for example, that with a block size of 4096 and a predictor order of 4, the partition order cannot be larger than 9.
パーティションの順序は、ブロックサイズがパーティションの数によって均等に分裂できるようにする必要があります。これは、たとえば、すべての奇数ブロックサイズでパーティション順序0のみが許可されることを意味します。パーティション順序は、（ブロックサイズ>>パーティション順序）が予測順に大きくなるようなものでなければなりません。これは、たとえば、ブロックサイズが4096で、予測因子順序が4の場合、パーティションの順序が9を超えることはできないことを意味します。
Each partition starts with a parameter. If the coded residual of a subframe is one with 4-bit Rice parameters (see Table 23), the first 4 bits of each partition are either a Rice parameter or an escape code. These 4 bits indicate an escape code if they are 0b1111; otherwise, they contain the Rice parameter as an unsigned number. If the coded residual of the current subframe is one with 5-bit Rice parameters, the first 5 bits of each partition indicate an escape code if they are 0b11111; otherwise, they contain the Rice parameter as an unsigned number as well.
各パーティションはパラメーターから始まります。サブフレームのコード化された残差が4ビットライスパラメーターを持つものである場合（表23を参照）、各パーティションの最初の4ビットはイネパラメーターまたはエスケープコードのいずれかです。これらの4ビットは、0B1111の場合、エスケープコードを示します。それ以外の場合、それらは署名のない数字としてイネパラメーターを含みます。現在のサブフレームのコード化された残差が5ビットのイネパラメーターを持つものである場合、各パーティションの最初の5ビットは、0B11111の場合、エスケープコードを示します。それ以外の場合は、署名のない数字としてライスパラメーターも含まれています。
If an escape code was used, the partition does not contain a variable-length Rice-coded residual; rather, it contains a fixed-length unencoded residual. Directly following the escape code are 5 bits containing the number of bits with which each residual sample is stored, as an unsigned number. The residual samples themselves are stored signed two's complement. For example, when a partition is escaped and each residual sample is stored with 3 bits, the number -1 is represented as 0b111.
エスケープコードが使用された場合、パーティションには可変長のイネコードされた残差は含まれていません。むしろ、固定された長さの非エンコード残差が含まれています。エスケープコードの直後には、各残差サンプルが保存されているビット数を符号なしの数として含む5ビットがあります。残留サンプル自体には、署名された2つの補数が保存されます。たとえば、パーティションが脱出され、各残差サンプルが3ビットで保存されると、数値-1は0B111として表されます。
Note that it is possible that the number of bits with which each sample is stored is 0, which means that all residual samples in that partition have a value of 0 and that no bits are used to store the samples. In that case, the partition contains nothing except the escape code and 0b00000.
各サンプルが保存されているビット数は0である可能性があることに注意してください。つまり、そのパーティション内のすべての残差サンプルの値は0であり、サンプルの保存にビットが使用されないことを意味します。その場合、パーティションにはエスケープコードと0B00000以外は何も含まれていません。
If a Rice parameter was provided for a certain partition, that partition contains a Rice-coded residual. The residual samples, which are signed numbers, are represented by unsigned numbers in the Rice code. For positive numbers, the representation is the number doubled. For negative numbers, the representation is the number multiplied by -2 and with 1 subtracted. This representation of signed numbers is also known as zigzag encoding. The zigzag-encoded residual is called the folded residual.
特定のパーティションにイネパラメーターが提供された場合、そのパーティションにはイネコードされた残差が含まれています。署名された番号である残留サンプルは、稲法に署名されていない番号で表されます。正の数の場合、表現は数が2倍になります。負の数の場合、表現は数に-2を掛け、1を引いたものです。署名された数字のこの表現は、Zigzagエンコーディングとしても知られています。ジグザグエンコード残差は、折り畳まれた残差と呼ばれます。
Each folded residual sample is then split into two parts, a most-significant part and a least-significant part. The Rice parameter at the start of each partition determines where that split lies: it is the number of bits in the least-significant part. Each residual sample is then stored by coding the most-significant part as unary, followed by the least-significant part as binary.
次に、折り畳まれた各残差サンプルは、最も重要な部分と重要な部分の2つの部分に分割されます。各パーティションの開始時のイネパラメーターは、その分割がどこにあるかを決定します。これは、最も重要でない部分のビット数です。次に、各残差サンプルは、最も重要な部分を単位としてコーディングし、続いてバイナリとして最も重要でない部分をコーディングすることにより保存されます。
For example, take a partition with Rice parameter 3 containing a folded residual sample with 38 as its value, which is 0b100110 in binary. The most-significant part is 0b100 (4) and is stored in unary form as 0b00001. The least-significant part is 0b110 (6) and is stored as is. The Rice code word is thus 0b00001110. The Rice code words for all residual samples in a partition are stored consecutively.
たとえば、バイナリの0B100110である38の折り畳まれた残差サンプルを含むイネパラメーター3のパーティションを取ります。最も重要な部分は0B100（4）であり、0B00001として単位形式で保存されます。最も重要でない部分は0B110（6）であり、そのまま保存されます。したがって、稲法の単語は0b00001110です。パーティション内のすべての残留サンプルの稲法の単語は、連続して保存されます。
To decode a Rice code word, zero bits must be counted until encountering a one bit, after which a number of bits given by the Rice parameter must be read. The count of zero bits is shifted left by the Rice parameter (i.e., multiplied by 2 raised to the power Rice parameter) and bitwise ORed with (i.e., added to) the read value. This is the folded residual value. An even folded residual value is shifted right 1 bit (i.e., divided by 2) to get the (unfolded) residual value. An odd folded residual value is shifted right 1 bit and then has all bits flipped (1 added to and divided by -2) to get the (unfolded) residual value, subject to negative numbers being signed two's complement on the decoding machine.
稲法の単語を解読するには、ゼロビットを1ビットに遭遇するまでカウントする必要があります。その後、米パラメーターで与えられる多数のビットを読み取る必要があります。ゼロビットのカウントは、ライスパラメーター（つまり、パワーライスパラメーターに上げられた2を掛けます）によって残され、読み取り値とビットワイズオレッド（つまり追加）されます。これは折りたたまれた残差値です。均一な折り畳まれた残留値は、（つまり、2で割って）右にシフトされ、（展開された）残差値を取得します。奇妙な折り畳まれた残留値は1ビット正しくシフトされ、すべてのビットが反転し（1に追加され、-2で割られます）、（展開された）残差値を取得します。
Appendix D shows decoding of a complete coded residual.
付録Dは、完全なコード化された残差のデコードを示しています。
All residual sample values MUST be representable in the range offered by a 32-bit integer, signed one's complement. Equivalently, all residual sample values MUST fall in the range offered by a 32-bit integer signed two's complement, excluding the most negative possible value of that range. This means residual sample values MUST NOT have an absolute value equal to, or larger than, 2 to the power 31. A FLAC encoder MUST make sure of this. If a FLAC encoder is, for a certain subframe, unable to find a suitable predictor for which all residual samples fall within said range, it MUST default to writing a verbatim subframe. Appendix A explains in which circumstances residual samples are already implicitly representable in said range; thus, an additional check is not needed.
すべての残差サンプル値は、32ビットの整数によって提供される範囲で表現できるものでなければなりません。同等に、すべての残差サンプル値は、その範囲の最も負の可能な値を除く、32ビットの整数が署名した2つの補数に提供される範囲に収まる必要があります。これは、残留サンプル値が電力31に等しい、または2より大きい絶対値を持たないことを意味します。FLACエンコーダーはこれを確認する必要があります。FLACエンコーダーが、特定のサブフレームについて、すべての残差サンプルが上記の範囲内に該当する適切な予測因子を見つけることができない場合、逐語的なサブフレームを作成する必要があります。付録Aは、どのような状況で、残留サンプルがすでに上記の範囲で暗黙的に表現できるかを説明しています。したがって、追加のチェックは必要ありません。
The reason for this limit is to ensure that decoders can use 32-bit integers when processing residuals, simplifying decoding. The reason the most negative value of a 32-bit integer signed two's complement is specifically excluded is to prevent decoders from having to implement specific handling of that value, as it cannot be negated within a 32-bit signed integer, and most library routines calculating an absolute value have undefined behavior for processing that value.
この制限の理由は、デコーダーが残差を処理するときに32ビット整数を使用してデコードを簡素化できるようにすることです。32ビット整数の2つの補数に署名された32ビット整数の最も負の値が具体的に除外されている理由は、32ビットの署名された整数とほとんどのライブラリルーチン内で否定できないため、デコーダがその値の特定の処理を実装しないようにすることです。絶対値には、その値を処理するための未定義の動作があります。
Following the last subframe is the frame footer. If the last subframe is not byte aligned (i.e., the number of bits required to store all subframes put together is not divisible by 8), zero bits are added until byte alignment is reached. Following this is a 16-bit CRC, initialized with 0, with the polynomial x^16 + x^15 + x^2 + x^0. This CRC covers the whole frame, excluding the 16-bit CRC but including the sync code.
最後のサブフレームに続くのはフレームフッターです。最後のサブフレームがバイトに合わせられていない場合（つまり、すべてのサブフレームをまとめるために必要なビットの数が8で割り切れません）、バイトアライメントに達するまでゼロビットが追加されます。これに続くのは、0で初期化された16ビットCRCで、多項式x^16 + x^15 + x^2 + x^0で初期化されています。このCRCは、16ビットCRCを除くフレーム全体をカバーしますが、同期コードを含みます。
The FLAC format can be used without any container, as it already provides for the most basic features normally associated with a container. However, the functionality this basic container provides is rather limited, and for more advanced features (such as combining FLAC audio with video), it needs to be encapsulated by a more capable container. This presents a problem: because of these container features, the FLAC format mixes data that belongs to the encoded data (like block size and sample rate) with data that belongs to the container (like checksum and timecode). The choice was made to encapsulate FLAC frames as they are, which means some data will be duplicated and potentially deviating between the FLAC frames and the encapsulating container.
FLAC形式は、コンテナに通常関連付けられている最も基本的な機能を既に提供するため、コンテナなしで使用できます。ただし、この基本的なコンテナが提供する機能はかなり限られており、より高度な機能（FLACオーディオとビデオを組み合わせるなど）の場合、より有能なコンテナによってカプセル化する必要があります。これには問題があります。これらのコンテナ機能のため、FLAC形式は、エンコードされたデータ（ブロックサイズやサンプルレートなど）に属するデータとコンテナ（チェックサムやタイムコードなど）に属するデータを組み合わせます。この選択は、FLACフレームをそのままカプセル化するために行われました。つまり、一部のデータが複製され、FLACフレームとカプセル化コンテナの間で潜在的に逸脱する可能性があります。
As FLAC frames are completely independent of each other, container format features handling dependencies do not need to be used. For example, all FLAC frames embedded in Matroska are marked as keyframes when they are stored in a SimpleBlock, and tracks in an MP4 file containing only FLAC frames do not need a sync sample box.
FLACフレームは互いに完全に独立しているため、コンテナ形式の機能処理依存関係を使用する必要はありません。たとえば、Matroskaに埋め込まれたすべてのFLACフレームは、SimpleBlockに保存されているときにキーフレームとしてマークされ、FLACフレームのみを含むMP4ファイルのトラックには同期サンプルボックスが必要ありません。
The Ogg container format is defined in [RFC3533]. The first packet of a logical bitstream carrying FLAC data is structured according to the following table.
OGGコンテナ形式は[RFC3533]で定義されています。FLACデータを運ぶ論理的なビットストリームの最初のパケットは、次の表に従って構成されています。
+=========+=========================================================+
| Data | Description |
+=========+=========================================================+
| 5 | Bytes 0x7F 0x46 0x4C 0x41 0x43 (as also defined by |
| bytes | [RFC5334]). |
+---------+---------------------------------------------------------+
| 2 | Version number of the FLAC-in-Ogg mapping. These bytes |
| bytes | are 0x01 0x00, meaning version 1.0 of the mapping. |
+---------+---------------------------------------------------------+
| 2 | Number of header packets (excluding the first header |
| bytes | packet) as an unsigned number coded big-endian. |
+---------+---------------------------------------------------------+
| 4 | The fLaC signature. |
| bytes | |
+---------+---------------------------------------------------------+
| 4 | A metadata block header for the streaminfo metadata |
| bytes | block. |
+---------+---------------------------------------------------------+
| 34 | A streaminfo metadata block. |
| bytes | |
+---------+---------------------------------------------------------+
Table 24
The number of header packets MAY be 0, which means the number of packets that follow is unknown. This first packet MUST NOT share a Ogg page with any other packets. This means the first page of a logical stream of FLAC-in-Ogg is always 79 bytes.
ヘッダーパケットの数は0である可能性があります。つまり、続くパケットの数は不明です。この最初のパケットは、OGGページを他のパケットと共有してはなりません。これは、FLAC-IN-GGの論理ストリームの最初のページが常に79バイトであることを意味します。
Following the first packet are one or more header packets, each of which contains a single metadata block. The first of these packets SHOULD be a Vorbis comment metadata block for historic reasons. This is contrary to unencapsulated FLAC streams, where the order of metadata blocks is not important except for the streaminfo metadata block and where a Vorbis comment metadata block is optional.
最初のパケットに続くのは、1つ以上のヘッダーパケットがあり、それぞれには単一のメタデータブロックが含まれています。これらのパケットの最初は、歴史的な理由でVorbisコメントメタデータブロックである必要があります。これは、カプセル化されていないFLACストリームに反します。メタデータブロックの順序は、Streaminfoメタデータブロックを除き、Vorbisコメントメタデータブロックがオプションである場合を除きます。
Following the header packets are audio packets. Each audio packet contains a single FLAC frame. The first audio packet MUST start on a new Ogg page, i.e., the last metadata block MUST finish its page before any audio packets are encapsulated.
ヘッダーパケットに続くのはオーディオパケットです。各オーディオパケットには、単一のFLACフレームが含まれています。最初のオーディオパケットは、新しいOGGページで開始する必要があります。つまり、オーディオパケットがカプセル化される前に、最後のメタデータブロックがページを終了する必要があります。
The granule position of all pages containing header packets MUST be 0. For pages containing audio packets, the granule position is the number of the last sample contained in the last completed packet in the frame. The sample numbering considers interchannel samples. If a page contains no packet end (e.g., when it only contains the start of a large packet that continues on the next page), then the granule position is set to the maximum value possible, i.e., 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF.
ヘッダーパケットを含むすべてのページの顆粒位置は0でなければなりません。オーディオパケットを含むページの場合、顆粒位置は、フレームの最後の完成したパケットに含まれる最後のサンプルの数です。サンプル番号は、チャネルインターチャネルサンプルを考慮します。ページにパケットエンドが含まれていない場合（たとえば、次のページで継続する大きなパケットの開始のみを含む場合）、顆粒位置は可能な最大値に設定されます。つまり、0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff。
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. In other words, the apparent sample number of the first sample in the stream following from the granule position and the audio data MAY be larger than 0. This allows, for example, a server to cast a live stream to several clients that joined at different moments without rewriting the granule position for each client.
完成したパケットを使用した最初のオーディオデータページの顆粒位置は、そのページに完成するパケットに含まれるサンプルの数よりも大きい場合があります。言い換えれば、顆粒位置から続くストリームの最初のサンプルの見かけのサンプル番号とオーディオデータは0より大きくなる可能性があります。これにより、たとえば、異なるものに結合した複数のクライアントにライブストリームをキャストすることができます。各クライアントの顆粒位置を書き換えない瞬間。
If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing encoding of the current Ogg stream and starting a new Ogg stream, concatenated to the previous one. This is called chaining in Ogg. See the Ogg specification [RFC3533] for details.
ストリームのある時点でオーディオプロパティ（サンプルレート、チャネル数、またはビット深度）が変更される場合にオーディオストリームがエンコードされている場合、これは現在のOGGストリームのエンコードを完了し、新しいOGGストリームを開始することで対処する必要があります。前のものに。これはOGGでチェーンと呼ばれます。詳細については、OGG仕様[RFC3533]を参照してください。
The Matroska container format is defined in [RFC9559]. The codec ID (EBML path \Segment\Tracks\TrackEntry\CodecID) assigned to signal tracks carrying FLAC data is A_FLAC in ASCII. All FLAC data before the first audio frame (i.e., the fLaC ASCII signature and all metadata blocks) is stored as CodecPrivate data (EBML path \Segment\Tracks\TrackEntry\CodecPrivate).
マトロスカコンテナ形式は[RFC9559]で定義されています。FLACデータを運ぶ信号トラックに割り当てられたCodec ID（EBML PATH \ Segment \ Tracks \ TrackEntry \ CodeCID）は、ASCIIのA_FLACです。最初のオーディオフレームの前のすべてのFLACデータ（つまり、FLAC ASCII署名およびすべてのメタデータブロック）は、CodecPrivateデータ（EBML Path \ segment \ tracks \ trackentry \ codecprivate）として保存されます。
Each FLAC frame (including all of its subframes) is treated as a single frame in the context of Matroska.
各FLACフレーム（すべてのサブフレームを含む）は、マトロスカのコンテキストで単一のフレームとして扱われます。
If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing the current Matroska segment and starting a new one with the new properties.
ストリームのある時点でオーディオプロパティ（サンプルレート、チャネル数、またはビット深度）が変更される場合にオーディオストリームがエンコードされている場合、これは現在のMatroskaセグメントを完了し、新しいプロパティで新しいものを開始することで対処する必要があります。
The full encapsulation definition of FLAC audio in MP4 files was deemed too extensive to include in this document. A definition document can be found at [FLAC-in-MP4-specification].
MP4ファイルのFLACオーディオの完全なカプセル化定義は、このドキュメントに含めるには広すぎると見なされました。[FLAC-IN-MP4仕様]に定義ドキュメントがあります。
Like any other codec (such as [RFC6716]), FLAC should not be used with insecure ciphers or cipher modes that are vulnerable to known plaintext attacks. Some of the header bits, as well as the padding, are easily predictable.
他のコーデック（[RFC6716]など）と同様に、FLACは、既知のプレーンテキスト攻撃に対して脆弱な不安定な暗号や暗号モードで使用しないでください。ヘッダービットの一部とパディングは、簡単に予測できます。
Implementations of the FLAC codec need to take appropriate security considerations into account. Section 2.1 of [RFC4732] provides general information on DoS attacks on end systems and describes some mitigation strategies. Areas of concern specific to FLAC follow.
FLACコーデックの実装は、適切なセキュリティ上の考慮事項を考慮する必要があります。[RFC4732]のセクション2.1は、ENDシステムに対するDOS攻撃に関する一般的な情報を提供し、いくつかの緩和戦略について説明します。FLACに固有の懸念領域が続きます。
It is extremely important for the decoder to be robust against malformed payloads. Payloads that do not conform to this specification MUST NOT cause the decoder to overrun its allocated memory or take an excessive amount of resources to decode. An overrun in allocated memory could lead to arbitrary code execution by an attacker. The same applies to the encoder, even though problems with encoders are typically rarer. Malformed audio streams MUST NOT cause the encoder to misbehave because this would allow an attacker to attack transcoding gateways.
デコーダーが奇形のペイロードに対して堅牢であることが非常に重要です。この仕様に準拠していないペイロードは、デコーダーが割り当てられたメモリをオーバーランさせたり、過度の量のリソースを取得してデコードしてはなりません。割り当てられたメモリのオーバーランは、攻撃者による任意のコード実行につながる可能性があります。エンコーダーの問題は通常よりまれですが、エンコーダーにも同じことが当てはまります。奇形のオーディオストリームは、攻撃者がトランスコーディングゲートウェイを攻撃できるため、エンコーダーを不正にしてはなりません。
As with all compression algorithms, both encoding and decoding can produce an output much larger than the input. For decoding, the most extreme possible case of this is a frame with eight constant subframes of block size 65535 and coding for 32-bit PCM. This frame is only 49 bytes in size but codes for more than 2 megabytes of uncompressed PCM data. For encoding, it is possible to have an even larger size increase, although such behavior is generally considered faulty. This happens if the encoder chooses a Rice parameter that does not fit with the residual that has to be encoded. In such a case, very long unary-coded symbols can appear (in the most extreme case, more than 4 gigabytes per sample). Decoder and encoder implementors are advised to take precautions to prevent excessive resource utilization in such cases.
すべての圧縮アルゴリズムと同様に、エンコードとデコードの両方が入力よりもはるかに大きい出力を生成する可能性があります。デコードの場合、これの最も極端なケースは、ブロックサイズ65535の8つの一定のサブフレームと32ビットPCMのコーディングを備えたフレームです。このフレームのサイズはわずか49バイトですが、2メガバイト以上の非圧縮PCMデータをコードします。エンコーディングの場合、そのような動作は一般に故障していると考えられていますが、さらに大きくサイズが増加する可能性があります。これは、エンコーダーがエンコードする必要がある残差に適合しないイネパラメーターを選択した場合に発生します。そのような場合、非常に長い単一コードされた記号が表示されます（最も極端な場合、サンプルごとに4ギガバイト以上）。デコーダーとエンコーダーの実装者は、そのような場合に過度のリソースの利用を防ぐために予防策を講じることをお勧めします。
Where metadata is handled, implementors are advised to either thoroughly test the handling of extreme cases or impose reasonable limits beyond the limits of this specification. For example, a single Vorbis comment metadata block can contain millions of valid fields. It is unlikely such a limit is ever reached except in a potentially malicious file. Likewise, the media type and description of a picture metadata block can be millions of characters long, despite there being no reasonable use of such contents. One possible use case for very long character strings is in lyrics, which can be stored in Vorbis comment metadata block fields.
メタデータが処理される場合、実装者は、極端なケースの取り扱いを徹底的にテストするか、この仕様の制限を超えて合理的な制限を課すことをお勧めします。たとえば、単一のVorbisコメントメタデータブロックには、何百万もの有効なフィールドを含めることができます。潜在的に悪意のあるファイルを除いて、このような制限に達する可能性は低いです。同様に、そのようなコンテンツの合理的な使用がないにもかかわらず、画像メタデータブロックのメディアタイプと説明は何百万人もの文字になります。非常に長いキャラクター文字列の可能なユースケースの1つは歌詞で、Vorbisコメントメタデータブロックフィールドに保存できます。
Various kinds of metadata blocks contain length fields or field counts. While reading a block following these lengths or counts, a decoder MUST make sure higher-level lengths or counts (most importantly, the length field of the metadata block itself) are not exceeded. As some of these length fields code string lengths and memory must be allocated for that, parsers MUST first verify that a block is valid before allocating memory based on its contents, except when explicitly instructed to salvage data from a malformed file.
さまざまな種類のメタデータブロックには、長さのフィールドまたはフィールド数が含まれています。これらの長さまたはカウントに続いてブロックを読み取っている間、デコーダーは、より高いレベルの長さまたはカウント（最も重要なことに、メタデータブロック自体の長さフィールド）を超えないことを確認する必要があります。これらの長さのフィールドの一部は、文字列の長さとメモリを割り当てる必要があるため、パーサーはまず、不正なファイルからデータをサルベージするように明示的に指示された場合を除き、その内容に基づいてメモリを割り当てる前にブロックが有効であることを確認する必要があります。
Metadata blocks can also contain references, e.g., the picture metadata block can contain a URI. When following a URI, the security considerations of [RFC3986] apply. Applications MUST obtain explicit user approval to retrieve resources via remote protocols. Following external URIs introduces a tracking risk from on-path observers and the operator of the service hosting the URI. Likewise, the choice of scheme, if it isn't protected like https, could also introduce integrity attacks by an on-path observer. A malicious operator of the service hosting the URI can return arbitrary content that the parser will read. Also, such retrievals can be used in a DDoS attack when the URI points to a potential victim. Therefore, applications need to ask user approval for each retrieval individually, take extra precautions when parsing retrieved data, and cache retrieved resources. Applications MUST obtain explicit user approval to retrieve local resources not located in the same directory as the FLAC file being processed. Since relative URIs are permitted, applications MUST guard against directory traversal attacks and guard against a violation of a same-origin policy if such a policy is being enforced.
メタデータブロックには参照を含めることもできます。たとえば、画像メタデータブロックにはURIを含めることができます。URIに従うと、[RFC3986]のセキュリティ上の考慮事項が適用されます。アプリケーションは、リモートプロトコルを介してリソースを取得するための明示的なユーザー承認を取得する必要があります。外部のURIに続いて、Path ObserversとURIをホストするサービスのオペレーターから追跡リスクを導入します。同様に、スキームの選択は、HTTPSのように保護されていない場合、パスでのオブザーバーによる整合性攻撃を導入することもできます。URIをホストするサービスの悪意のあるオペレーターは、パーサーが読む任意のコンテンツを返すことができます。また、URIが潜在的な犠牲者を指している場合、このような検索はDDOS攻撃で使用できます。したがって、アプリケーションは、各検索のユーザーの承認を個別に承認し、取得したデータを解析するときに追加の予防策を講じ、取得したリソースをキャッシュする必要があります。アプリケーションは、処理されているFLACファイルと同じディレクトリにないローカルリソースを取得するために、明示的なユーザー承認を取得する必要があります。相対的なURIは許可されているため、申請書はディレクトリのトラバーサル攻撃を防ぎ、そのようなポリシーが施行されている場合、同性ポリシーの違反を防ぐ必要があります。
Seeking in a FLAC stream that is not in a container relies on the coded number in frame headers and optionally a seek table metadata block. Parsers MUST employ thorough checks on whether a found coded number or seek point is at all possible, e.g., whether it is within bounds and not directly contradicting any other coded number or seek point that the seeking process relies on. Without these checks, seeking might get stuck in an infinite loop when numbers in frames are non-consecutive or otherwise not valid, which could be used in DoS attacks.
コンテナ内にないFLACストリームでの探索は、フレームヘッダーのコード化された数値に依存しており、オプションではシークテーブルメタデータブロックに依存しています。パーサーは、見つかったコード化された数字またはシークポイントが可能であるかどうかを徹底的なチェックを使用する必要があります。たとえば、それが範囲内であり、他のコード化された数値と直接矛盾しないか、シークプロセスが依存しているポイントを求めています。これらのチェックがなければ、Framesの数値が非継続的または無効である場合、DOS攻撃で使用できる場合、探すことは無限のループで立ち往生する可能性があります。
Implementors are advised to employ fuzz testing combined with different sanitizers on FLAC decoders to find security problems. Ignoring the results of CRC checks improves the efficiency of decoder fuzz testing.
実装者は、セキュリティの問題を見つけるために、FLACデコーダー上のさまざまな消毒剤と組み合わせたファズテストを採用することをお勧めします。CRCチェックの結果を無視すると、デコーダーファズテストの効率が向上します。
See [FLAC-decoder-testbench] for a non-exhaustive list of FLAC files with extreme configurations that lead to crashes or reboots on some known implementations. Besides providing a starting point for security testing, this set of files can also be used to test conformance with this specification.
[FLAC-Decoder-Testbench]を参照して、既知の実装でクラッシュまたは再起動につながる極端な構成を備えたFLACファイルの網羅的ではないリストを参照してください。セキュリティテストの出発点を提供することに加えて、この一連のファイルを使用して、この仕様との適合性をテストすることもできます。
FLAC files may contain executable code, although the FLAC format is not designed for it and it is uncommon. One use case where FLAC is occasionally used to store executable code is when compressing images of mixed-mode CDs, which contain both audio and non-audio data, the non-audio portion of which can contain executable code. In that case, the executable code is stored as if it were audio and is potentially obscured. Of course, it is also possible to store executable code as metadata, for example, as a Vorbis comment with help of a binary-to-text encoding or directly in an application metadata block. Applications MUST NOT execute code contained in FLAC files or present parts of FLAC files as executable code to the user, except when an application has that explicit purpose, e.g., applications reading FLAC files as disc images and presenting it as a virtual disc drive.
FLACファイルには実行可能なコードが含まれている場合がありますが、FLAC形式は設計されておらず、まれです。実行可能性コードの保存にFLACが時々使用される場合の1つのユースケースは、オーディオデータと非オーディオデータの両方を含む混合モードCDの画像を圧縮するときに、実行可能なコードを含むことができます。その場合、実行可能コードはオーディオであるかのように保存され、潜在的に不明瞭になります。もちろん、たとえば、実行可能性コードをメタデータとして保存することもできます。たとえば、バイナリからテキストのエンコードの助けを借りて、またはアプリケーションメタデータブロックに直接vorbisコメントとして保存することもできます。アプリケーションは、FLACファイルに含まれるコードを実行したり、FLACファイルの部分をユーザーに実行可能なコードとして提示したりしてはなりません。たとえば、アプリケーションにFLACファイルをDISC画像として読み取り、仮想ディスクドライブとして提示するアプリケーションがある場合を除きます。
Per this document, IANA has registered one new media type ("audio/ flac") and created a new IANA registry, as described in the subsections below.
このドキュメントに従って、IANAは1つの新しいメディアタイプ（「Audio/ FLAC」）を登録し、以下のサブセクションで説明するように、新しいIANAレジストリを作成しました。
IANA has registered the "audio/flac" media type as follows. This media type is applicable for FLAC audio that is not packaged in a container as described in Section 10. FLAC audio packaged in such a container will take on the media type of that container, for example, "audio/ogg" when packaged in an Ogg container or "video/mp4" when packaged in an MP4 container alongside a video track.
IANAは、次のように「オーディオ/FLAC」メディアタイプを登録しています。このメディアタイプは、セクション10で説明されているようにコンテナにパッケージ化されていないFLACオーディオに適用されます。そのようなコンテナにパッケージ化されたFLACオーディオは、そのコンテナのメディアタイプ、たとえば、「オーディオ/OGG」を使用します。MP4コンテナにビデオトラックと一緒にパッケージ化された場合、OGGコンテナまたは「ビデオ/MP4」。
Type name:
タイプ名：
audio
オーディオ
Subtype name:
サブタイプ名：
flac
FLAC
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
as per RFC 9639
RFC 9639に従って
Security considerations:
セキュリティ上の考慮事項：
See the security considerations in Section 11 of RFC 9639.
RFC 9639のセクション11のセキュリティ上の考慮事項を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
See the descriptions of past format changes in Appendix B of RFC 9639.
RFC 9639の付録Bの過去の形式の変更の説明を参照してください。
Published specification:
公開された仕様：
RFC 9639
RFC 9639
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
FFmpeg, Apache, Firefox
ffmpeg、Apache、Firefox
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
audio/x-flac
オーディオ/X-FLAC
Magic number(s):
マジックナンバー：
fLaC
FLAC
File extension(s):
ファイル拡張子：
flac
FLAC
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Uniform Type Identifier:
均一型識別子：
org.xiph.flac conforms to public.audio
org.xiph.flacはpublic.audioに準拠しています
Windows Clipboard Format Name:
Windows Clipboardフォーマット名：
audio/flac
オーディオ/FLAC
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
IETF CELLAR Working Group (cellar@ietf.org)
IETFセラーワーキンググループ（cellar@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
IETF CELLAR Working Group
IETFセラーワーキンググループ
Change controller:
Change Controller：
Internet Engineering Task Force (iesg@ietf.org)
インターネットエンジニアリングタスクフォース（iesg@ietf.org）
IANA has created a new registry called the "FLAC Application Metadata Block IDs" registry. The values correspond to the 32-bit identifier described in Section 8.4.
IANAは、「FLACアプリケーションメタデータブロックID」レジストリと呼ばれる新しいレジストリを作成しました。値は、セクション8.4で説明されている32ビット識別子に対応しています。
To register a new application ID in this registry, one needs an application ID, a description, an optional reference to a document describing the application ID, and a Change Controller (IETF or email of registrant). The application IDs are allocated according to the "First Come First Served" policy [RFC8126] so that there is no impediment to registering any application IDs the FLAC community encounters, especially if they were used in audio files but were not registered when the audio files were encoded. An application ID can be any 32-bit value but is often composed of 4 ASCII characters that are human-readable.
このレジストリに新しいアプリケーションIDを登録するには、アプリケーションID、説明、アプリケーションIDを説明するドキュメントへのオプションの参照、およびChange Controller（IETFまたは登録者の電子メール）が必要です。アプリケーションIDは、「First Come First」ポリシー[RFC8126]に従って割り当てられます。そのため、特にオーディオファイルで使用されているがオーディオファイルが登録されていない場合、FLACコミュニティの遭遇を登録することに障害がありません。エンコードされました。アプリケーションIDは任意の32ビット値にすることができますが、多くの場合、人間が読み取る可能性のある4つのASCII文字で構成されています。
The initial contents of "FLAC Application Metadata Block IDs" registry are shown in the table below. These initial values were taken from the registration page at xiph.org (see [ID-registration-page]), which is no longer being maintained as it has been replaced by this registry.
「FLACアプリケーションメタデータブロックID」レジストリの初期内容を以下の表に示します。これらの初期値は、xiph.orgの登録ページ（[id-registration-page]を参照）から取得されましたが、このレジストリに置き換えられたため、維持されなくなりました。
+===========+==========+===========+===================+==========+
|Application|ASCII |Description|Reference |Change |
|ID |Rendition | | |Controller|
| |(If | | | |
| |Available)| | | |
+===========+==========+===========+===================+==========+
|0x41544348 |ATCH |FlacFile |[FlacFile], RFC |IETF |
| | | |9639 | |
+-----------+----------+-----------+-------------------+----------+
|0x42534F4C |BSOL |beSolo |RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x42554753 |BUGS |Bugs Player|RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x43756573 |Cues |GoldWave |RFC 9639 |IETF |
| | |cue points | | |
+-----------+----------+-----------+-------------------+----------+
|0x46696361 |Fica |CUE |RFC 9639 |IETF |
| | |Splitter | | |
+-----------+----------+-----------+-------------------+----------+
|0x46746F6C |Ftol |flac-tools |RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x4D4F5442 |MOTB |MOTB |RFC 9639 |IETF |
| | |MetaCzar | | |
+-----------+----------+-----------+-------------------+----------+
|0x4D505345 |MPSE |MP3 Stream |RFC 9639 |IETF |
| | |Editor | | |
+-----------+----------+-----------+-------------------+----------+
|0x4D754D4C |MuML |MusicML: |RFC 9639 |IETF |
| | |Music | | |
| | |Metadata | | |
| | |Language | | |
+-----------+----------+-----------+-------------------+----------+
|0x52494646 |RIFF |Sound |RFC 9639 |IETF |
| | |Devices | | |
| | |RIFF chunk | | |
| | |storage | | |
+-----------+----------+-----------+-------------------+----------+
|0x5346464C |SFFL |Sound Font |RFC 9639 |IETF |
| | |FLAC | | |
+-----------+----------+-----------+-------------------+----------+
|0x534F4E59 |SONY |Sony |RFC 9639 |IETF |
| | |Creative | | |
| | |Software | | |
+-----------+----------+-----------+-------------------+----------+
|0x5351455A |SQEZ |flacsqueeze|RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x54745776 |TtWv |TwistedWave|RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x55495453 |UITS |UITS |RFC 9639 |IETF |
| | |Embedding | | |
| | |tools | | |
+-----------+----------+-----------+-------------------+----------+
|0x61696666 |aiff |FLAC AIFF |[Foreign-metadata],|IETF |
| | |chunk |RFC 9639 | |
| | |storage | | |
+-----------+----------+-----------+-------------------+----------+
|0x696D6167 |imag |flac-image |RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x7065656D |peem |Parseable |RFC 9639 |IETF |
| | |Embedded | | |
| | |Extensible | | |
| | |Metadata | | |
+-----------+----------+-----------+-------------------+----------+
|0x71667374 |qfst |QFLAC |RFC 9639 |IETF |
| | |Studio | | |
+-----------+----------+-----------+-------------------+----------+
|0x72696666 |riff |FLAC RIFF |[Foreign-metadata],|IETF |
| | |chunk |RFC 9639 | |
| | |storage | | |
+-----------+----------+-----------+-------------------+----------+
|0x74756E65 |tune |TagTuner |RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x77363420 |w64 |FLAC Wave64|[Foreign-metadata],|IETF |
| | |chunk |RFC 9639 | |
| | |storage | | |
+-----------+----------+-----------+-------------------+----------+
|0x78626174 |xbat |XBAT |RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
|0x786D6364 |xmcd |xmcd |RFC 9639 |IETF |
+-----------+----------+-----------+-------------------+----------+
Table 25
[ISRC-handbook]
International ISRC Registration Authority, "International
Standard Recording Code (ISRC) Handbook", 4th edition,
2021, <https://www.ifpi.org/isrc_handbook/>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2083] Boutell, T., "PNG (Portable Network Graphics)
Specification Version 1.0", RFC 2083,
DOI 10.17487/RFC2083, March 1997,
<https://www.rfc-editor.org/info/rfc2083>.
[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>.
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533, DOI 10.17487/RFC3533, May 2003,
<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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9559] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media
Container Format Specification", RFC 9559,
DOI 10.17487/RFC9559, October 2024,
<https://www.rfc-editor.org/info/rfc9559>.
[Durbin] Durbin, J., "The Fitting of Time-Series Models", Revue de
l'Institut International de Statistique / Review of the
International Statistical Institute, vol. 28, no. 3, pp.
233-44, DOI 10.2307/1401322, 1960,
<https://www.jstor.org/stable/1401322>.
[FIR] Wikipedia, "Finite impulse response", August 2024,
<https://en.wikipedia.org/w/
index.php?title=Finite_impulse_response&oldid=1240945295>.
[FLAC-decoder-testbench]
"The Free Lossless Audio Codec (FLAC) test files", commit
aa7b0c6, August 2023,
<https://github.com/ietf-wg-cellar/flac-test-files>.
[FLAC-implementation]
"FLAC", <https://xiph.org/flac/>.
[FLAC-in-MP4-specification]
"Encapsulation of FLAC in ISO Base Media File Format",
commit 78d85dd, July 2022,
<https://github.com/xiph/flac/blob/master/doc/
isoflac.txt>.
[FLAC-specification-github]
"The Free Lossless Audio Codec (FLAC) Specification",
<https://github.com/ietf-wg-cellar/flac-specification>.
[FLAC-wiki-interoperability]
"Interoperability considerations", commit 58a06d6,
<https://github.com/ietf-wg-cellar/flac-
specification/wiki/Interoperability-considerations>.
[FlacFile] "FlacFile", Wayback Machine archive, October 2007,
<https://web.archive.org/web/20071023070305/
http://firestuff.org:80/flacfile/>.
[Foreign-metadata]
"Specification of foreign metadata storage in FLAC",
commit 72787c3, November 2023,
<https://github.com/xiph/flac/blob/master/doc/
foreign_metadata_storage.md>.
[ID-registration-page]
Xiph.Org, "ID registry", <https://xiph.org/flac/id.html>.
[ID3v2] Nilsson, M., "ID3 tag version 2.4.0 - Native Frames",
Wayback Machine archive, November 2000,
<https://web.archive.org/web/20220903174949/
https://id3.org/id3v2.4.0-frames>.
[IEC.60908.1999]
International Electrotechnical Commission, "Audio
recording - Compact disc digital audio system",
IEC 60908:1999-02, 1999,
<https://webstore.iec.ch/publication/3885>.
[LinearPrediction]
Wikipedia, "Linear prediction", August 2023,
<https://en.wikipedia.org/w/
index.php?title=Linear_prediction&oldid=1169015573>.
[Lossless-Compression]
Hans, M. and R. W. Schafer, "Lossless compression of
digital audio", IEEE Signal Processing Magazine, vol. 18,
no. 4, pp. 21-32, DOI 10.1109/79.939834, July 2001,
<https://ieeexplore.ieee.org/document/939834>.
[lossyWAV] Hydrogenaudio Knowledgebase, "lossyWAV", July 2021,
<https://wiki.hydrogenaud.io/
index.php?title=LossyWAV&oldid=32877>.
[MLP] Gerzon, M. A., Craven, P. G., Stuart, J. R., Law, M. J.,
and R. J. Wilson, "The MLP Lossless Compression System",
Audio Engineering Society Conference: 17th International
Conference: High-Quality Audio Codin, September 1999,
<https://www.aes.org/e-lib/online/browse.cfm?elib=8082>.
[MusicBrainz]
MusicBrainz, "Tags & Variables", MusicBrainz Picard v2.10
documentation, <https://picard-
docs.musicbrainz.org/en/variables/variables.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>.
[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>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[Rice] Rice, R. F. and J. R. Plaunt, "Adaptive Variable-Length
Coding for Efficient Compression of Spacecraft Television
Data", IEEE Transactions on Communication Technology, vol.
19, no. 6, pp. 889-897, DOI 10.1109/TCOM.1971.1090789,
December 1971,
<https://ieeexplore.ieee.org/document/1090789>.
[Robinson-TR156]
Robinson, T., "SHORTEN: Simple lossless and near-lossless
waveform compression", Cambridge University Engineering
Department Technical Report CUED/F-INFENG/TR.156, December
1994, <https://mi.eng.cam.ac.uk/reports/svr-ftp/auto-pdf/
robinson_tr156.pdf>.
[Shannon] Shannon, C. E., "Communication in the Presence of Noise",
Proceedings of the IRE, vol. 37, no. 1, pp. 10-21,
DOI 10.1109/JRPROC.1949.232969, January 1949,
<https://ieeexplore.ieee.org/document/1697831>.
[VarLengthCode]
Wikipedia, "Variable-length code", April 2024,
<https://en.wikipedia.org/w/index.php?title=Variable-
length_code&oldid=1220260423>.
[Vorbis] Xiph.Org, "Ogg Vorbis I format specification: comment
field and header specification",
<https://xiph.org/vorbis/doc/v-comment.html>.
In order to maintain lossless behavior, all arithmetic used in encoding and decoding sample values must be done with integer data types to eliminate the possibility of introducing rounding errors associated with floating-point arithmetic. Use of floating-point representations in analysis (e.g., finding a good predictor or Rice parameter) is not a concern as long as the process of using the found predictor and Rice parameter to encode audio samples is implemented with only integer math.
ロスレス動作を維持するために、サンプル値のエンコードとデコードで使用されるすべての算術を整数データ型で行う必要があります。分析におけるフローティングポイント表現の使用（例：適切な予測因子またはイネパラメーターを見つける）は、見つかった予測子とイネパラメーターを使用してオーディオサンプルをエンコードするプロセスが整数数学のみで実装されている限り、懸念事項ではありません。
Furthermore, the possibility of integer overflow can be eliminated by using data types that are large enough. Choosing a 64-bit signed data type for all arithmetic involving sample values would make sure the possibility for overflow is eliminated, but usually, smaller data types are chosen for increased performance, especially in embedded devices. This appendix provides guidelines for choosing the appropriate data type for each step of encoding and decoding FLAC files.
さらに、整数オーバーフローの可能性は、十分に大きいデータ型を使用して排除できます。サンプル値を含むすべての算術に対して64ビットの署名されたデータ型を選択すると、オーバーフローの可能性が排除されることを確認しますが、通常、特に埋め込まれたデバイスでは、パフォーマンスの向上のために小さなデータ型が選択されます。この付録は、FLACファイルをエンコードおよびデコードする各ステップに適切なデータ型を選択するためのガイドラインを提供します。
In this appendix, signed data types are signed two's complement.
この付録では、署名されたデータ型が2つの補完に署名されています。
To find the smallest data type size that is guaranteed not to overflow for a certain sequence of arithmetic operations, the combination of values producing the largest possible result should be considered.
一連の算術演算でオーバーフローしないように保証されている最小のデータ型サイズを見つけるには、可能な最大の結果を生成する値の組み合わせを考慮する必要があります。
For example, if two 16-bit signed integers are added, the largest possible result forms if both values are the largest number that can be represented with a 16-bit signed integer. To store the result, a signed integer data type with at least 17 bits is needed. Similarly, when adding 4 of these values, 18 bits are needed; when adding 8, 19 bits are needed, etc. In general, the number of bits necessary when adding numbers together is increased by the log base 2 of the number of values rounded up to the nearest integer. So, when adding 18 unknown values stored in 8-bit signed integers, we need a signed integer data type of at least 13 bits to store the result, as the log base 2 of 18 rounded up is 5.
たとえば、2つの16ビットの署名された整数が追加された場合、両方の値が16ビット署名整数で表すことができる最大の数値である場合、可能な最大の結果形式が追加されます。結果を保存するには、少なくとも17ビットの署名された整数データ型が必要です。同様に、これらの値のうち4つを追加する場合、18ビットが必要です。一般的に、8、19ビットを追加する場合、数値を追加するときに必要なビット数は、最寄りの整数に丸められた値の数のログベース2によって増加します。したがって、8ビットの署名された整数に保存されている18の未知の値を追加すると、結果を保存するために少なくとも13ビットの署名整数データ型が必要です。
When multiplying two numbers, the number of bits needed for the result is the size of the first number plus the size of the second number. For example, if a 16-bit signed integer is multiplied by another 16-bit signed integer, the result needs at least 32 bits to be stored without overflowing. To show this in practice, the largest signed value that can be stored in 4 bits is -8. (-8)*(-8) is 64, which needs at least 8 bits (signed) to store.
2つの数値を掛けると、結果に必要なビット数は、最初の数字のサイズと2番目の数字のサイズです。たとえば、16ビットの署名された整数に別の16ビットの署名整数を掛けている場合、結果はオーバーフローせずに保存するために少なくとも32ビットを必要とします。これを実際に示すために、4ビットで保存できる最大の署名値は-8です。（-8）*（-8）は64で、保存するには少なくとも8ビット（署名）が必要です。
When stereo decorrelation is used, the side channel will have one extra bit of bit depth; see Section 4.2.
Stereoの分離を使用すると、サイドチャネルには少しのビット深度があります。セクション4.2を参照してください。
This means that while 16-bit signed integers have sufficient range to store samples from a fully decoded FLAC frame with a bit depth of 16 bits, the decoding of a side subframe in such a file will need a data type with at least 17 bits to store decoded subframe samples before undoing stereo decorrelation.
これは、16ビットの署名済み整数には、16ビットの少し深さの完全なデコードされたFLACフレームからサンプルを保存するのに十分な範囲があるが、そのようなファイルのサイドサブフレームのデコードには、少なくとも17ビットのデータ型が必要であることを意味します。ステレオ脱線を元に戻す前に、デコードされたサブフレームサンプルを保存します。
Most FLAC decoders store decoded (subframe) samples as 32-bit values, which is sufficient for files with bit depths up to (and including) 31 bits.
ほとんどのFLACデコーダは、デコードされた（サブフレーム）サンプルを32ビット値として保存します。これは、31ビットまでのビット深度（および含有）のファイルに十分です。
A prediction (which is used to calculate the residual on encoding or added to the residual to calculate the sample value on decoding) is formed by multiplying and summing preceding sample values. In order to eliminate the possibility of integer overflow, the combination of preceding sample values and predictor coefficients producing the largest possible value should be considered.
予測（エンコード時に残差を計算するために使用されるか、デコードでサンプル値を計算するために残差に追加されます）は、前のサンプル値を乗算および合計することによって形成されます。整数のオーバーフローの可能性を排除するために、先行するサンプル値と可能な最大の値を生成する予測係数の組み合わせを考慮する必要があります。
To determine the size of the data type needed to calculate either a residual sample (on encoding) or an audio sample value (on decoding) in a fixed predictor subframe, the maximum possible value for these is calculated as described in Appendix A.1 and in the following table. For example, if a frame codes for 16-bit audio and has some form of stereo decorrelation, the subframe coding for the side channel would need 16+1+3 bits if a third-order fixed predictor is used.
固定予測サブフレームの残差サンプル（エンコード時）またはオーディオサンプル値（デコード時）のいずれかを計算するために必要なデータ型のサイズを決定するために、これらの最大値は、付録A.1および説明のように計算されます。次の表に。たとえば、フレームが16ビットオーディオをコードし、何らかの形のステレオ分離を備えている場合、サイドチャネルのサブフレームコーディングには、3次固定予測子が使用される場合は16+1+3ビットが必要です。
+=======+==============================+===============+=======+
| Order | Calculation of Residual | Sample Values | Extra |
| | | Summed | Bits |
+=======+==============================+===============+=======+
| 0 | a(n) | 1 | 0 |
+-------+------------------------------+---------------+-------+
| 1 | a(n) - a(n-1) | 2 | 1 |
+-------+------------------------------+---------------+-------+
| 2 | a(n) - 2 * a(n-1) + a(n-2) | 4 | 2 |
+-------+------------------------------+---------------+-------+
| 3 | a(n) - 3 * a(n-1) + 3 * | 8 | 3 |
| | a(n-2) - a(n-3) | | |
+-------+------------------------------+---------------+-------+
| 4 | a(n) - 4 * a(n-1) + 6 * | 16 | 4 |
| | a(n-2) - 4 * a(n-3) + a(n-4) | | |
+-------+------------------------------+---------------+-------+
Table 26
Where:
ただし：
* n is the number of the sample being predicted.
* nは予測されるサンプルの数です。
* a(n) is the sample being predicted.
* A（n）は予測されるサンプルです。
* a(n-1) is the sample before the one being predicted, a(n-2) is the sample before that, etc.
* A（n-1）は、予測される前のサンプルであり、A（n-2）はその前のサンプルです。
For subframes with a linear predictor, the calculation is a little more complicated. Each prediction is the sum of several multiplications. Each of these multiply a sample value with a predictor coefficient. The extra bits needed can be calculated by adding the predictor coefficient precision (in bits) to the bit depth of the audio samples. To account for the summing of these multiplications, the log base 2 of the predictor order rounded up is added.
線形予測因子を使用したサブフレームの場合、計算はもう少し複雑です。各予測は、いくつかの乗算の合計です。これらのそれぞれは、サンプル値に予測係数を掛けます。必要な追加ビットは、音声サンプルのビット深さに予測係数精度（ビット）を追加することで計算できます。これらの乗算の合計を説明するために、切り上げられた予測順のログベース2が追加されます。
For example, if the sample bit depth of the source is 24, the current subframe encodes a side channel (see Section 4.2), the predictor order is 12, and the predictor coefficient precision is 15 bits, the minimum required size of the used signed integer data type is at least (24 + 1) + 15 + ceil(log2(12)) = 44 bits. As another example, with a side-channel subframe bit depth of 16, a predictor order of 8, and a predictor coefficient precision of 12 bits, the minimum required size of the used signed integer data type is (16 + 1) + 12 + ceil(log2(8)) = 32 bits.
たとえば、ソースのサンプルビット深度が24の場合、現在のサブフレームはサイドチャネルをエンコードし（セクション4.2を参照）、予測順序は12、予測係数精度は15ビットです。整数データ型は、少なくとも（24 + 1） + 15 + CEIL（log2（12））= 44ビットです。別の例として、16のサイドチャネルサブフレームビット深度、8の予測順、および12ビットの予測係数精度がある場合、使用されている署名された整数データ型の最小必要なサイズは（16 + 1） + 12 +ですCEIL（log2（8））= 32ビット。
As stated in Section 9.2.7, an encoder must make sure residual samples are representable by a 32-bit integer, signed two's complement, excluding the most negative value. As in the previous section, it is possible to calculate when residual samples already implicitly fit and when an additional check is needed. This implicit fit is achieved when residuals would fit a theoretical 31-bit signed integer, as that satisfies both of the mentioned criteria. When this implicit fit is not achieved, all residual values must be calculated and checked individually.
セクション9.2.7で述べたように、エンコーダーは、最も負の値を除く、32ビットの整数によって残留サンプルが表現できることを確認する必要があります。前のセクションと同様に、残留サンプルがすでに暗黙的に適合したときと追加のチェックが必要な時期を計算することができます。この暗黙の適合は、上記の両方の基準を満たすため、残差が理論的な31ビット署名整数に適合する場合に達成されます。この暗黙の適合が達成されない場合、すべての残差値を個別に計算してチェックする必要があります。
For the residual of a fixed predictor, the maximum residual sample size was already calculated in the previous section. However, for a linear predictor, the prediction is shifted right by a certain amount. The number of bits needed for the residual is the number of bits calculated in the previous section, reduced by the prediction right shift, and increased by one bit to account for the subtraction of the prediction from the current sample on encoding.
固定予測子の残差については、前のセクションで最大残留サンプルサイズがすでに計算されていました。ただし、線形予測因子の場合、予測は一定の量だけシフトされます。残差に必要なビットの数は、前のセクションで計算されたビットの数であり、予測の正しいシフトによって減少し、エンコーディングに関する現在のサンプルからの予測の減算を説明するために1ビット増加しました。
Taking the last example of the previous section, where 32 bits were needed for the prediction, the required data type size for the residual samples in case of a right shift of 10 bits would be 32 - 10 + 1 = 23 bits, which means it is not necessary to perform the aforementioned check.
予測に32ビットが必要だった前のセクションの最後の例を使用すると、10ビットの正しいシフトの場合に残留サンプルに必要なデータ型サイズは32-10 + 1 = 23ビットです。前述のチェックを実行するために必要ではありません。
As another example, when encoding 32-bit PCM with fixed predictors, all predictor orders must be checked. While the zero-order fixed predictor is guaranteed to have residual samples that fit a 32-bit signed integer, it might produce a residual sample value that is the most negative representable value of that 32-bit signed integer.
別の例として、固定予測子を使用して32ビットPCMをエンコードする場合、すべての予測順序を確認する必要があります。ゼロオーダーの固定予測子は、32ビットの署名整数に適合する残留サンプルを持つことが保証されていますが、その32ビット署名された整数の最も負の表現可能な値である残差サンプル値を生成する可能性があります。
Note that on decoding, while the residual sample values are limited to the aforementioned range, the predictions are not. This means that while the decoding of the residual samples can happen fully in 32-bit signed integers, decoders must be sure to execute the addition of each residual sample to its accompanying prediction with a signed integer data type that is wide enough, as with encoding.
デコード時には、残留サンプル値は前述の範囲に限定されていますが、予測はそうではないことに注意してください。つまり、残差サンプルのデコードは32ビットの署名済み整数で完全に発生する可能性がありますが、デコーダーは、エンコードと同様に、署名済みの整数データタイプを使用して、それぞれの残差サンプルを付随する予測に追加する必要があることを意味します。。
When folding (i.e., zigzag encoding) the residual sample values, no extra bits are needed when the absolute value of each residual sample is first stored in an unsigned data type of the size of the last step, then doubled, and then has one subtracted depending on whether the residual sample was positive or negative. However, many implementations choose to require one extra bit of data type size so zigzag encoding can happen in one step without a cast instead of the procedure described in the previous sentence.
残留サンプル値を折りたたむ（つまり、zigzagエンコード）の場合、各残差サンプルの絶対値が最初に最後のステップのサイズの符号なしデータ型に保存され、次に2倍になり、1つが減算された場合、余分なビットは必要ありません残留サンプルが陽性かマイナスかによって異なります。ただし、多くの実装は、前の文に記載されている手順ではなく、キャストなしで1つのステップでZigzagエンコードが発生する可能性があるため、1つの追加のデータ型サイズを必要とすることを選択します。
This informational appendix documents the changes made to the FLAC format over the years. This information might be of use when encountering FLAC files that were made with software following the format as it was before the changes documented in this appendix.
この情報付録には、長年にわたってFLAC形式に加えられた変更が記録されています。この情報は、この付録に文書化された変更の前に形式に従ってソフトウェアで作成されたFLACファイルに遭遇する場合に使用される場合があります。
The FLAC format was first specified in December 2000, and the bitstream format was considered frozen with the release of FLAC 1.0 (the reference encoder/decoder) in July 2001. Only changes made since this first stable release are considered in this appendix. Changes made to the FLAC streamable subset definition (see Section 7) are not considered.
FLAC形式は2000年12月に最初に指定され、BitStream形式は2001年7月にFLAC 1.0（参照エンコーダ/デコーダー）のリリースで凍結されたと見なされました。この最初の安定したリリースがこの付録で考慮されてから変更された変更のみが行われます。FLACストリーミング可能なサブセット定義（セクション7を参照）に加えられた変更は考慮されません。
Perhaps the largest backwards-incompatible change to the specification was published in July 2007. Before this change, variable block size streams were not explicitly marked as such by a flag bit in the frame header. A decoder had two ways to detect a variable block size stream: by comparing the minimum and maximum block sizes in the streaminfo metadata block (which are equal for a fixed block size stream) or by detecting a change of block size during a stream if a decoder did not receive a streaminfo metadata block, which could not happen at all in theory. As the meaning of the coded number in the frame header depends on whether or not a stream has a variable block size, this presented a problem: the meaning of the coded number could not be reliably determined. To fix this problem, one of the reserved bits was changed to be used as a blocking strategy bit. See also Section 9.1.
おそらく、仕様の最大の後方に取得しやすい変更は2007年7月に公開されました。この変更の前に、フレームヘッダーのフラグビットによって、可変ブロックサイズのストリームがそのように明示的にマークされていませんでした。デコーダーには、可変ブロックサイズのストリームを検出する2つの方法がありました。Streaminfoメタデータブロックの最小ブロックサイズと最大ブロックサイズ（固定ブロックサイズのストリームに等しい）を比較するか、またはストリーム中のブロックサイズの変更を検出することにより、デコーダーは、Streaminfoメタデータブロックを受け取りませんでしたが、理論的にはまったく発生することはできませんでした。フレームヘッダー内のコード化された数値の意味は、ストリームのブロックサイズが可変なかどうかに依存するため、これは問題を提示しました。コード化された数字の意味は確実に決定できませんでした。この問題を修正するために、予約されたビットの1つがブロッキング戦略ビットとして使用されるように変更されました。セクション9.1も参照してください。
Along with the addition of a new flag, the meaning of the block size bits (see Section 9.1.1) was subtly changed. Initially, block size bits patterns 0b0001-0b0101 and 0b1000-0b1111 could only be used for fixed block size streams, while 0b0110 and 0b0111 could be used for both fixed block size and variable block size streams. With this change, these restrictions were lifted, and patterns 0b0001-0b1111 are now used for both variable block size and fixed block size streams.
新しいフラグの追加に加えて、ブロックサイズビットの意味（セクション9.1.1を参照）が微妙に変更されました。最初に、ブロックサイズビットパターン0B0001-0B0101および0B1000-0B1111は固定ブロックサイズのストリームにのみ使用できますが、0B0110と0B0111は、固定ブロックサイズと可変ブロックサイズのストリームの両方に使用できます。この変更により、これらの制限は解除され、パターン0B0001-0B1111は、可変ブロックサイズと固定ブロックサイズのストリームの両方に使用されます。
Another change to the specification was deemed necessary during standardization by the CELLAR Working Group of the IETF. As specified in Section 9.2.7, a limit is imposed on residual samples. This limit was not specified prior to the IETF standardization effort. However, as far as was known to the working group, no FLAC encoder at that time produced FLAC files containing residual samples exceeding this limit. This is mostly because it is very unlikely to encounter residual samples exceeding this limit when encoding 24-bit PCM, and encoding of PCM with higher bit depths was not yet implemented in any known encoder. In fact, these FLAC encoders would produce corrupt files upon being triggered to produce such residual samples, and it is unlikely any non-experimental encoder would ever do so, even when presented with crafted material. Therefore, it was not expected that existing implementations would be rendered non-compliant by this change.
IETFのセラーワーキンググループによる標準化中に、仕様に対する別の変更が必要であるとみなされました。セクション9.2.7で指定されているように、残留サンプルに制限が課されます。この制限は、IETF標準化の取り組みの前に指定されていません。ただし、ワーキンググループに知られている限り、当時のFLACエンコーダーは、この制限を超える残留サンプルを含むFLACファイルを生成しませんでした。これは主に、24ビットPCMをエンコードするときにこの制限を超える残留サンプルに遭遇する可能性が非常に低く、ビット深さの高いPCMのエンコードが既知のエンコーダーにまだ実装されていないためです。実際、これらのFLACエンコーダーは、そのような残留サンプルを生成するようにトリガーされたときに破損したファイルを生成し、作られた素材が提示されたとしても、非実験的エンコーダーがそうすることはほとんどありません。したがって、この変更により、既存の実装が非準拠になるとは予想されていませんでした。
One significant addition to the format was the residual coding method using 5-bit Rice parameters. Prior to publication of this addition in July 2007, a partitioned Rice code with 4-bit Rice parameters was the only residual coding method specified. The range offered by this coding method proved too small when encoding 24-bit PCM; therefore, a second residual coding method was specified that was identical to the first, but with 5-bit Rice parameters.
この形式への重要な追加の1つは、5ビットライスパラメーターを使用した残差コーディング方法でした。2007年7月にこの追加が公開される前に、4ビットの米パラメーターを備えた分割済み稲法が指定された唯一の残留コーディング方法でした。このコーディング方法で提供される範囲は、24ビットPCMをエンコードすると小さすぎることが判明しました。したがって、2番目の残差コーディング方法が指定され、最初の残留コードと5ビットのイネパラメーターを使用しました。
As stated in Section 9.2.6, the predictor right shift is a number signed two's complement, which MUST NOT be negative. This is because shifting a number to the right by a negative amount is undefined behavior in the C programming language standard. The intended behavior was that a positive number would be a right shift and a negative number would be a left shift. The FLAC reference encoder was changed in 2007 to not generate LPC subframes with a negative predictor right shift, as it turned out that the use of such subframes would only very rarely provide any benefit and the decoders that were already widely in use at that point were not able to handle such subframes.
セクション9.2.6で述べたように、予測因子の右シフトは、2人の補完署名数字であり、負のものであってはなりません。これは、マイナス量によって数値を右にシフトすることが、Cプログラミング言語標準で未定義の動作であるためです。意図した動作は、正の数が正しいシフトであり、負の数は左シフトになるということでした。FLACリファレンスエンコーダは2007年に変更され、ネガティブな予測子の右シフトでLPCサブフレームを生成しないように変更されました。そのようなサブフレームの使用は非常にめったに利益を提供しないことが判明し、その時点ですでに広く使用されていたデコーダーはこのようなサブフレームを処理できません。
As documented in Appendix B, there have been some changes and additions to the FLAC format. Additionally, implementation of certain features of the FLAC format took many years, meaning early decoder implementations could not be tested against files with these features. Finally, many lower-quality FLAC decoders only implement just enough features required for playback of the most common FLAC files.
付録Bに文書化されているように、FLAC形式にいくつかの変更と追加がありました。さらに、FLAC形式の特定の機能の実装には何年もかかりました。つまり、これらの機能を備えたファイルに対して初期のデコーダー実装をテストできませんでした。最後に、多くの低品質のFLACデコーダは、最も一般的なFLACファイルの再生に必要な十分な機能のみを実装します。
This appendix provides some considerations for encoder implementations aiming to create highly compatible files. As this topic is one that might change after this document is published, consult [FLAC-wiki-interoperability] for more up-to-date information.
この付録は、互換性の高いファイルを作成することを目的としたエンコーダーの実装に関するいくつかの考慮事項を提供します。このトピックは、このドキュメントが公開された後に変更される可能性のあるトピックであるため、最新情報については[FLAC-Wikiインターパラリティ]を参照してください。
As described in Section 7, FLAC specifies a subset of its capabilities as the FLAC streamable subset. Certain decoders may choose to only decode FLAC files conforming to the limitations imposed by the streamable subset. Therefore, maximum compatibility with decoders is achieved when the limitations of the FLAC streamable subset are followed when creating FLAC files.
セクション7で説明されているように、FLACはその機能のサブセットをFLACストリーミング可能なサブセットとして指定します。特定のデコーダは、ストリーミング可能なサブセットによって課される制限に準拠したFLACファイルのみをデコードすることを選択できます。したがって、FLACファイルを作成するときにFLACストリーミング可能なサブセットの制限が続くと、デコーダーとの最大互換性が達成されます。
Because it is often difficult to find the optimal arrangement of block sizes for maximum compression, most encoders choose to create files with a fixed block size. Because of this, many decoder implementations receive minimal use when handling variable block size streams, and this can reveal bugs or reveal that implementations do not decode them at all. Furthermore, as explained in Appendix B.1, there have been some changes to the way variable block size streams are encoded. Because of this, maximum compatibility with decoders is achieved when FLAC files are created using fixed block size streams.
最大の圧縮のためにブロックサイズの最適な配置を見つけることはしばしば困難であるため、ほとんどのエンコーダは固定ブロックサイズのファイルを作成することを選択します。このため、多くのデコーダーの実装は、可変ブロックサイズのストリームを処理するときに最小限の使用を受けます。これにより、バグが明らかになったり、実装がそれらをデコードしないことを明らかにします。さらに、付録B.1で説明したように、可変ブロックサイズのストリームがエンコードされる方法にいくつかの変更がありました。このため、FLACファイルが固定ブロックサイズのストリームを使用して作成されると、デコーダーとの最大互換性が達成されます。
As the addition of the coding method using 5-bit Rice parameters, as described in Appendix B.3, occurred quite a few years after the FLAC format was first introduced, some early decoders might not be able to decode files containing such Rice parameters. The introduction of this was specifically aimed at improving compression of 24-bit PCM audio, and compression of 16-bit PCM audio only rarely benefits from using 5-bit Rice parameters. Therefore, maximum compatibility with decoders is achieved when FLAC files containing audio with a bit depth of 16 bits or less are created without any use of 5-bit Rice parameters.
付録B.3で説明されているように、5ビットイネパラメーターを使用したコーディング法の追加は、FLAC形式が最初に導入されてから数年後に発生したため、一部の初期デコーダはそのようなイネパラメーターを含むファイルをデコードできない可能性があります。これの導入は、24ビットPCMオーディオの圧縮を改善することを特に目的としており、16ビットPCMオーディオの圧縮は、5ビットライスパラメーターを使用することではめったに有益ではありません。したがって、5ビットライスパラメーターを使用せずに16ビット以下の少し深さのオーディオを含むFLACファイルが作成されると、デコーダーとの最大互換性が達成されます。
Escaped Rice partitions are seldom used, as it turned out their use provides only a very small compression improvement. As many encoders do not use these by default or are not capable of producing them at all, it is likely that many decoder implementations are not able to decode them correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created without any use of escaped Rice partitions.
脱出した米のパーティションはめったに使用されません。それは、それらの使用が非常に小さな圧縮改善のみを提供することが判明したためです。多くのエンコーダーはデフォルトでこれらを使用していないか、まったく生成できないため、多くのデコーダー実装では正しくデコードできない可能性があります。したがって、脱出されたライスパーティションを使用せずにFLACファイルを作成すると、デコーダーとの最大互換性が達成されます。
For unknown reasons, some decoders have chosen to support only common block sizes for all but the last block of a stream. Therefore, maximum compatibility with decoders is achieved when creating FLAC files using common block sizes, as listed in Section 9.1.1, for all but the last block of a stream.
不明な理由で、一部のデコーダーは、ストリームの最後のブロックを除くすべてのすべての一般的なブロックサイズのみをサポートすることを選択しています。したがって、ストリームの最後のブロックを除くすべてのセクション9.1.1にリストされているように、一般的なブロックサイズを使用してFLACファイルを作成するときにデコーダーとの最大互換性が達成されます。
Most audio is stored in bit depths that are a whole number of bytes, e.g., 8, 16, or 24 bits. However, there is audio with different bit depths. A few examples:
ほとんどのオーディオは、たとえば8、16、または24ビットなどのバイトのビット深さで保存されます。ただし、ビットの深さが異なるオーディオがあります。いくつかの例：
* DVD-Audio has the possibility to store 20-bit PCM audio.
* DVD-Audioには、20ビットのPCMオーディオを保存する可能性があります。
* DAT and DV can store 12-bit PCM audio.
* DATとDVは、12ビットPCMオーディオを保存できます。
* NICAM-728 samples at 14 bits, which is companded to 10 bits.
* NICAM-728は14ビットでサンプルされ、10ビットに互換性があります。
* 8-bit µ-law can be losslessly converted to 14-bit (Linear) PCM.
* 8ビットµ-lawは、14ビット（線形）PCMに損失を無効に変換できます。
* 8-bit A-law can be losslessly converted to 13-bit (Linear) PCM.
* 8ビットA-Lawは、13ビット（線形）PCMに損失を無効に変換できます。
The FLAC format can contain these bit depths directly, but because they are uncommon, some decoders are not able to process the resulting files correctly. It is possible to store these formats in a FLAC file with a more common bit depth without sacrificing compression by padding each sample with zero bits to a bit depth that is a whole byte. The FLAC format can efficiently compress these wasted bits. See Section 9.2.2 for details.
FLAC形式にはこれらのビットの深さを直接含めることができますが、それらは珍しいため、一部のデコーダは結果のファイルを正しく処理できません。これらの形式は、各サンプルをゼロビットでパディングして、バイト全体であるビット深度にパディングすることにより、より一般的なビット深度のFLACファイルに保存することができます。FLAC形式は、これらの無駄なビットを効率的に圧縮できます。詳細については、セクション9.2.2を参照してください。
Therefore, maximum compatibility with decoders is achieved when FLAC files are created by padding samples of such audio with zero bits to the bit depth that is the next whole number of bytes.
したがって、次のバイトのビット深さまでビットゼロのビットを持つこのようなオーディオのサンプルをパディングすることによってFLACファイルが作成されると、デコーダーとの最大互換性が達成されます。
In cases where the original signal is already padded, this operation cannot be reversed losslessly without knowing the original bit depth. To leave no ambiguity, the original bit depth needs to be stored, for example, in a Vorbis comment field or by storing the header of the original file. The choice of a suitable method is left to the implementor.
元の信号が既にパッドが付けられている場合、この操作は、元のビットの深さを知らなくても損失を無効にすることはできません。あいまいさを残さないには、元のビット深度を、たとえば、Vorbisのコメントフィールドまたは元のファイルのヘッダーを保存して保存する必要があります。適切な方法の選択は、実装者に任されています。
Besides audio with a "non-whole byte" bit depth, some decoder implementations have chosen to only accept FLAC files coding for PCM audio with a bit depth of 16 bits. Many implementations support bit depths up to 24 bits, but no higher. Consult [FLAC-wiki-interoperability] for more up-to-date information.
「非wholeバイト」ビットの深さを備えたオーディオに加えて、一部のデコーダー実装は、16ビットの深さでPCMオーディオをコーディングするFLACファイルのみを受け入れるように選択されています。多くの実装は、最大24ビットまでのビットの深さをサポートしていますが、高くはありません。最新情報については、[FLAC-Wiki-interoperability]を参照してください。
Many FLAC audio players are unable to render multi-channel audio or audio with an uncommon sample rate. While this is not a concern specific to the FLAC format, it is of note when requiring maximum compatibility with decoders. Unlike the previously mentioned interoperability considerations, this is one where compatibility cannot be improved without sacrificing the lossless nature of the FLAC format.
多くのFLACオーディオプレーヤーは、珍しいサンプルレートでマルチチャネルオーディオまたはオーディオをレンダリングすることができません。これはFLAC形式に固有の懸念ではありませんが、デコーダーとの最大の互換性が必要な場合は注目に値します。前述の相互運用性の考慮事項とは異なり、これはFLAC形式のロスレス性を犠牲にせずに互換性を改善できない場合です。
From a non-exhaustive inquiry, it seems that a non-negligible number of players, especially hardware players, do not support audio with 3 or more channels or sample rates other than those considered common; see Section 9.1.2.
網羅的ではない問い合わせから、非交渉不可能な数のプレーヤー、特にハードウェアプレーヤーは、一般的と見なされるもの以外の3つ以上のチャネルまたはサンプルレートでオーディオをサポートしていないようです。セクション9.1.2を参照してください。
For those players that do support and are able to render multi-channel audio, many do not parse and use the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag (see Section 8.6.2). This is also an interoperability consideration because compatibility cannot be improved without sacrificing the lossless nature of the FLAC format.
サポートし、マルチチャネルオーディオをレンダリングできるプレーヤーの場合、多くは波形Xtensible_channel_maskタグを解析して使用しません（セクション8.6.2を参照）。これは、FLAC形式の損失のない性質を犠牲にせずに互換性を改善できないため、相互運用性の考慮事項でもあります。
Each FLAC frame header stores the audio sample rate, number of bits per sample, and number of channels independently of the streaminfo metadata block and other frame headers. This was done to permit multicasting of FLAC files, but it also allows these properties to change mid-stream. However, many FLAC decoders do not handle such changes, as few other formats are capable of holding such streams and changing playback properties during playback is often not possible without interrupting playback. Also, as explained in Section 9, using this feature of FLAC results in various practical problems.
各FLACフレームヘッダーは、オーディオサンプルレート、サンプルあたりのビット数、およびStreaminfoメタデータブロックおよびその他のフレームヘッダーとは無関係にチャネルの数を保存します。これは、FLACファイルのマルチキャストを許可するために行われましたが、これらのプロパティが中間ストリームを変更することもできます。ただし、多くのFLACデコーダーはそのような変更を処理しません。再生中にそのようなストリームを保持し、再生プロパティを変更することができる他の形式はほとんどないため、再生を中断することなく不可能です。また、セクション9で説明されているように、FLACのこの機能を使用すると、さまざまな実用的な問題が発生します。
However, even when storing an audio stream with changing properties in FLAC encapsulated in a container capable of handling such changes, as recommended in Section 9, many decoders are not able to decode such a stream correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created with a single set of audio properties, in which the properties coded in the streaminfo metadata block (see Section 8.2) and the properties coded in all frame headers (see Section 9.1) are the same. This can be achieved by splitting up an input stream with changing audio properties at the points where these properties change into separate streams or files.
ただし、セクション9で推奨されるように、このような変更を処理できるコンテナにカプセル化されたFLACのプロパティの変更を伴うオーディオストリームを保存する場合でも、多くのデコーダーはそのようなストリームを正しくデコードできません。したがって、FLACファイルが単一のオーディオプロパティセットで作成された場合、Decodersとの最大互換性が達成されます。このプロパティでは、Streaminfoメタデータブロックにコード化されたプロパティ（セクション8.2を参照）と、すべてのフレームヘッダーでコーディングされたプロパティ（セクション9.1を参照）が作成されます。同じ。これは、これらのプロパティが個別のストリームまたはファイルに変更されるポイントで、オーディオプロパティの変更で入力ストリームを分割することで実現できます。
This informational appendix contains short examples of FLAC files that are decoded step by step. These examples provide a more engaging way to understand the FLAC format than the formal specification. The text explaining these examples assumes the reader has at least cursorily read the specification and that the reader refers to the specification for explanation of the terminology used. These examples mostly focus on the layout of several metadata blocks, subframe types, and the implications of certain aspects (e.g., wasted bits and stereo decorrelation) on this layout.
この情報付録には、段階的にデコードされたFLACファイルの短い例が含まれています。これらの例は、正式な仕様よりもFLAC形式を理解するためのより魅力的な方法を提供します。これらの例を説明するテキストは、読者が少なくとも仕様を大まかに読んでおり、読者が使用された用語の説明の仕様を参照していることを前提としています。これらの例は、主に、いくつかのメタデータブロック、サブフレームタイプのレイアウト、およびこのレイアウトの特定の側面（無駄なビットやステレオの切り離関連）の意味に焦点を当てています。
The examples feature files generated by various FLAC encoders. These are presented in hexadecimal or binary format, followed by tables and text referring to various features by their starting bit positions in these representations. Each starting position (shortened to "start" in the tables) is a hexadecimal byte position and a start bit within that byte, separated by a plus sign. Counts for these start at zero. For example, a feature starting at the 3rd bit of the 17th byte is referred to as starting at 0x10+2. The files that are explored in these examples can be found at [FLAC-specification-github].
この例は、さまざまなFLACエンコーダーによって生成されたファイルを機能させます。これらは16進形式またはバイナリ形式で提示され、次にこれらの表現での開始ビット位置によるさまざまな機能を参照するテーブルとテキストが続きます。各開始位置（テーブル内の「開始」に短縮）は、六分位バイトの位置であり、そのバイト内のスタートビットで、プラス記号で区切られています。これらのカウントはゼロで開始します。たとえば、17番目のバイトの3番目のビットから始まる機能は、0x10+2から始まると呼ばれます。これらの例で調査されているファイルは、[FLAC仕様-Github]にあります。
All data in this appendix has been thoroughly verified. However, as this appendix is informational, if any information here conflicts with statements in the formal specification, the latter takes precedence.
この付録のすべてのデータは徹底的に検証されています。ただし、この付録は情報提供であるため、ここでの情報が正式な仕様の声明と矛盾する場合、後者は優先されます。
This very short example FLAC file codes for PCM audio that has two channels, each containing one sample. The focus of this example is on the essential parts of a FLAC file.
この非常に短い例FLACファイルは、2つのチャネルがあり、それぞれに1つのサンプルが含まれているPCMオーディオのコードをコードしています。この例の焦点は、FLACファイルの重要な部分にあります。
00000000: 664c 6143 8000 0022 1000 1000 fLaC..."....
0000000c: 0000 0f00 000f 0ac4 42f0 0000 ........B...
00000018: 0001 3e84 b418 07dc 6903 0758 ..>.....i..X
00000024: 6a3d ad1a 2e0f fff8 6918 0000 j=......i...
00000030: bf03 58fd 0312 8baa 9a ..X......
00000000: 01100110 01001100 01100001 01000011 fLaC
00000004: 10000000 00000000 00000000 00100010 ..."
00000008: 00010000 00000000 00010000 00000000 ....
0000000c: 00000000 00000000 00001111 00000000 ....
00000010: 00000000 00001111 00001010 11000100 ....
00000014: 01000010 11110000 00000000 00000000 B...
00000018: 00000000 00000001 00111110 10000100 ..>.
0000001c: 10110100 00011000 00000111 11011100 ....
00000020: 01101001 00000011 00000111 01011000 i..X
00000024: 01101010 00111101 10101101 00011010 j=..
00000028: 00101110 00001111 11111111 11111000 ....
0000002c: 01101001 00011000 00000000 00000000 i...
00000030: 10111111 00000011 01011000 11111101 ..X.
00000034: 00000011 00010010 10001011 10101010 ....
00000038: 10011010
The first 4 bytes of the file contain the fLaC file signature. Directly following it is a metadata block. The signature and the first metadata block header are broken down in the following table.
ファイルの最初の4バイトには、FLACファイルの署名が含まれています。直接続くのはメタデータブロックです。署名と最初のメタデータブロックヘッダーは、次の表に分解されます。
+========+=========+============+===========================+
| Start | Length | Contents | Description |
+========+=========+============+===========================+
| 0x00+0 | 4 bytes | 0x664C6143 | fLaC |
+--------+---------+------------+---------------------------+
| 0x04+0 | 1 bit | 0b1 | Last metadata block |
+--------+---------+------------+---------------------------+
| 0x04+1 | 7 bits | 0b0000000 | Streaminfo metadata block |
+--------+---------+------------+---------------------------+
| 0x05+0 | 3 bytes | 0x000022 | Length of 34 bytes |
+--------+---------+------------+---------------------------+
Table 27
As the header indicates that this is the last metadata block, the position of the first audio frame can now be calculated as the position of the first byte after the metadata block header + the length of the block, i.e., 8+34 = 42 or 0x2a. Thus, 0x2a indeed contains the frame sync code for fixed block size streams -- 0xfff8.
ヘッダーはこれが最後のメタデータブロックであることを示しているため、最初のオーディオフレームの位置は、メタデータブロックヘッダー +ブロックの長さ、つまり8 + 34 = 42または0x2a。したがって、0x2aには、固定ブロックサイズストリームのフレーム同期コード-0xfff8が含まれています。
The streaminfo metadata block contents are broken down in the following table.
Streaminfoメタデータブロックの内容は、次の表に分解されます。
+========+==========+====================+==========================+
| Start | Length | Contents | Description |
+========+==========+====================+==========================+
| 0x08+0 | 2 bytes | 0x1000 | Min. block size 4096 |
+--------+----------+--------------------+--------------------------+
| 0x0a+0 | 2 bytes | 0x1000 | Max. block size 4096 |
+--------+----------+--------------------+--------------------------+
| 0x0c+0 | 3 bytes | 0x00000f | Min. frame size 15 bytes |
+--------+----------+--------------------+--------------------------+
| 0x0f+0 | 3 bytes | 0x00000f | Max. frame size 15 bytes |
+--------+----------+--------------------+--------------------------+
| 0x12+0 | 20 bits | 0x0ac4, 0b0100 | Sample rate 44100 hertz |
+--------+----------+--------------------+--------------------------+
| 0x14+4 | 3 bits | 0b001 | 2 channels |
+--------+----------+--------------------+--------------------------+
| 0x14+7 | 5 bits | 0b01111 | Sample bit depth 16 |
+--------+----------+--------------------+--------------------------+
| 0x15+4 | 36 bits | 0b0000, 0x00000001 | Total no. of samples 1 |
+--------+----------+--------------------+--------------------------+
| 0x1a | 16 | (...) | MD5 checksum |
| | bytes | | |
+--------+----------+--------------------+--------------------------+
Table 28
The minimum and maximum block sizes are both 4096. This was apparently the block size the encoder planned to use, but as only 1 interchannel sample was provided, no frames with 4096 samples are actually present in this file.
最小および最大ブロックサイズはどちらも4096です。これは明らかにエンコーダーが使用する予定のブロックサイズでしたが、1つのインターチャネルサンプルのみが提供されたため、このファイルには4096サンプルのフレームは実際にはありません。
Note that anywhere a number of samples is mentioned (block size, total number of samples, sample rate), interchannel samples are meant.
多数のサンプルが言及されている場所（ブロックサイズ、サンプルの総数、サンプルレート）、インターチャネルサンプルが意味されることに注意してください。
The MD5 checksum (starting at 0x1a) is 0x3e84 b418 07dc 6903 0758 6a3d ad1a 2e0f. This will be validated after decoding the samples.
MD5チェックサム（0x1aから始まる）は0x3E84 B418 07DC 6903 0758 6A3D AD1A 2E0Fです。これは、サンプルをデコードした後に検証されます。
The frame header starts at position 0x2a and is broken down in the following table.
フレームヘッダーは位置0x2aから始まり、次の表で分解されます。
+========+=========+=================+===================+
| Start | Length | Contents | Description |
+========+=========+=================+===================+
| 0x2a+0 | 15 bits | 0xff, 0b1111100 | Frame sync |
+--------+---------+-----------------+-------------------+
| 0x2b+7 | 1 bit | 0b0 | Blocking strategy |
+--------+---------+-----------------+-------------------+
| 0x2c+0 | 4 bits | 0b0110 | 8-bit block size |
| | | | further down |
+--------+---------+-----------------+-------------------+
| 0x2c+4 | 4 bits | 0b1001 | Sample rate 44.1 |
| | | | kHz |
+--------+---------+-----------------+-------------------+
| 0x2d+0 | 4 bits | 0b0001 | Stereo, no |
| | | | decorrelation |
+--------+---------+-----------------+-------------------+
| 0x2d+4 | 3 bits | 0b100 | Bit depth 16 bits |
+--------+---------+-----------------+-------------------+
| 0x2d+7 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+-----------------+-------------------+
| 0x2e+0 | 1 byte | 0x00 | Frame number 0 |
+--------+---------+-----------------+-------------------+
| 0x2f+0 | 1 byte | 0x00 | Block size 1 |
+--------+---------+-----------------+-------------------+
| 0x30+0 | 1 byte | 0xbf | Frame header CRC |
+--------+---------+-----------------+-------------------+
Table 29
As the stream is a fixed block size stream, the number at 0x2e contains a frame number. Because the value is smaller than 128, only 1 byte is used for the encoding.
ストリームは固定ブロックサイズのストリームであるため、0x2Eの数にはフレーム番号が含まれています。値は128より小さいため、エンコードに使用されるのは1バイトのみです。
At byte 0x31, the first subframe starts, which is broken down in the following table.
BYTE 0x31では、最初のサブフレームが開始されます。これは、次の表で分解されます。
+========+=========+================+=========================+
| Start | Length | Contents | Description |
+========+=========+================+=========================+
| 0x31+0 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+----------------+-------------------------+
| 0x31+1 | 6 bits | 0b000001 | Verbatim subframe |
+--------+---------+----------------+-------------------------+
| 0x31+7 | 1 bit | 0b1 | Wasted bits used |
+--------+---------+----------------+-------------------------+
| 0x32+0 | 2 bits | 0b01 | 2 wasted bits used |
+--------+---------+----------------+-------------------------+
| 0x32+2 | 14 bits | 0b011000, 0xfd | 14-bit unencoded sample |
+--------+---------+----------------+-------------------------+
Table 30
As the wasted bits flag is 1 in this subframe, a unary-coded number follows. Starting at 0x32, we see 0b01, which unary codes for 1, meaning that this subframe uses 2 wasted bits.
このサブフレームの無駄なビットフラグは1であるため、統一コードされた数字が続きます。0x32から、1をコードする0B01が表示されます。つまり、このサブフレームは2つの無駄なビットを使用しています。
As this is a verbatim subframe, the subframe only contains unencoded sample values. With a block size of 1, it contains only a single sample. The bit depth of the audio is 16 bits, but as the subframe header signals the use of 2 wasted bits, only 14 bits are stored. As no stereo decorrelation is used, a bit depth increase for the side channel is not applicable. So, the next 14 bits (starting at position 0x32+2) contain the unencoded sample coded big-endian, signed two's complement. The value reads 0b011000 11111101, or 6397. This value needs to be shifted left by 2 bits to account for the wasted bits. The value is then 0b011000 11111101 00, or 25588.
これは逐語的なサブフレームであるため、サブフレームにはエンコードされていないサンプル値のみが含まれています。ブロックサイズが1の場合、単一のサンプルのみが含まれています。オーディオのビット深度は16ビットですが、サブフレームヘッダーが2つの無駄なビットの使用を通知するため、14ビットのみが保存されます。ステレオの分離は使用されないため、サイドチャネルの深さの増加は適用されません。したがって、次の14ビット（位置0x32+2から始まる）には、エンコードされていないサンプルコード化されたビッグエンディアンが含まれています。値は0B011000 11111101、つまり6397を読み取ります。この値は、無駄なビットを考慮して2ビットを残してシフトする必要があります。値は0B011000 11111101 00、つまり25588です。
The second subframe starts at 0x34 and is broken down in the following table.
2番目のサブフレームは0x34から始まり、次の表で分解されます。
+========+=========+==============+=========================+
| Start | Length | Contents | Description |
+========+=========+==============+=========================+
| 0x34+0 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+--------------+-------------------------+
| 0x34+1 | 6 bits | 0b000001 | Verbatim subframe |
+--------+---------+--------------+-------------------------+
| 0x34+7 | 1 bit | 0b1 | Wasted bits used |
+--------+---------+--------------+-------------------------+
| 0x35+0 | 4 bits | 0b0001 | 4 wasted bits used |
+--------+---------+--------------+-------------------------+
| 0x35+4 | 12 bits | 0b0010, 0x8b | 12-bit unencoded sample |
+--------+---------+--------------+-------------------------+
Table 31
The wasted bits flag is also one, but the unary-coded number that follows it is 4 bits long, indicating the use of 4 wasted bits. This means the sample is stored in 12 bits. The sample value is 0b0010 10001011, or 651. This value now has to be shifted left by 4 bits, i.e., 0b0010 10001011 0000, or 10416.
無駄なビットフラグも1つですが、それに続く単位コードされた数字は4ビットで、4ビットの使用を示しています。これは、サンプルが12ビットで保存されることを意味します。サンプル値は0B0010 10001011、または651です。この値は、4ビット、つまり0B0010 10001011 0000、つまり10416だけシフトする必要があります。
At this point, we would undo stereo decorrelation if that was applicable.
この時点で、それが該当する場合は、ステレオの分離を元に戻します。
As the last subframe ends byte-aligned, no padding bits follow it. The next 2 bytes, starting at 0x38, contain the frame CRC. As this is the only frame in the file, the file ends with the CRC.
最後のサブフレームがバイトアラインで終了すると、パディングビットはそれに続きません。0x38から始まる次の2バイトには、フレームCRCが含まれています。これがファイル内の唯一のフレームであるため、ファイルはCRCで終了します。
To validate the MD5 checksum, we line up the samples interleaved, byte-aligned, little-endian, signed two's complement. The first sample, with value 25588, translates to 0xf463, and the second sample, with value 10416, translates to 0xb028. When computing the MD5 checksum with 0xf463b028 as input, we get the MD5 checksum found in the header, so decoding was lossless.
MD5チェックサムを検証するために、インターリーブ、バイトアリード、リトルエンディアンのサンプルを並べ、2人の補完に署名しました。値25588の最初のサンプルは0xF463に変換され、値10416の2番目のサンプルは0xB028に変換されます。入力として0xF463B028でMD5チェックサムを計算すると、ヘッダーにMD5チェックサムが見つかりますので、デコードはロスレスでした。
This FLAC file is larger than the first example, but still contains very little audio. The focus of this example is on decoding a subframe with a fixed predictor and a coded residual, but it also contains a very short seek table, a Vorbis comment metadata block, and a padding metadata block.
このFLACファイルは最初の例よりも大きいですが、オーディオはほとんど含まれていません。この例の焦点は、固定予測子とコード化された残差を使用したサブフレームのデコードにありますが、非常に短いシークテーブル、Vorbisコメントメタデータブロック、およびパディングメタデータブロックも含まれています。
00000000: 664c 6143 0000 0022 0010 0010 fLaC..."....
0000000c: 0000 1700 0044 0ac4 42f0 0000 .....D..B...
00000018: 0013 d5b0 5649 75e9 8b8d 8b93 ....VIu.....
00000024: 0422 757b 8103 0300 0012 0000 ."u{........
00000030: 0000 0000 0000 0000 0000 0000 ............
0000003c: 0000 0010 0400 003a 2000 0000 .......: ...
00000048: 7265 6665 7265 6e63 6520 6c69 reference li
00000054: 6246 4c41 4320 312e 332e 3320 bFLAC 1.3.3
00000060: 3230 3139 3038 3034 0100 0000 20190804....
0000006c: 0e00 0000 5449 544c 453d d7a9 ....TITLE=..
00000078: d79c d795 d79d 8100 0006 0000 ............
00000084: 0000 0000 fff8 6998 000f 9912 ......i.....
00000090: 0867 0162 3d14 4299 8f5d f70d .g.b=.B..]..
0000009c: 6fe0 0c17 caeb 2100 0ee7 a77a o.....!....z
000000a8: 24a1 590c 1217 b603 097b 784f $.Y......{xO
000000b4: aa9a 33d2 85e0 70ad 5b1b 4851 ..3...p.[.HQ
000000c0: b401 0d99 d2cd 1a68 f1e6 b810 .......h....
000000cc: fff8 6918 0102 a402 c382 c40b ..i.........
000000d8: c14a 03ee 48dd 03b6 7c13 30 .J..H...|.0
00000088: 11111111 11111000 01101001 10011000 ..i.
0000008c: 00000000 00001111 10011001 00010010 ....
00000090: 00001000 01100111 00000001 01100010 .g.b
00000094: 00111101 00010100 01000010 10011001 =.B.
00000098: 10001111 01011101 11110111 00001101 .]..
0000009c: 01101111 11100000 00001100 00010111 o...
000000a0: 11001010 11101011 00100001 00000000 ..!.
000000a4: 00001110 11100111 10100111 01111010 ...z
000000a8: 00100100 10100001 01011001 00001100 $.Y.
000000ac: 00010010 00010111 10110110 00000011 ....
000000b0: 00001001 01111011 01111000 01001111 .{xO
000000b4: 10101010 10011010 00110011 11010010 ..3.
000000b8: 10000101 11100000 01110000 10101101 ..p.
000000bc: 01011011 00011011 01001000 01010001 [.HQ
000000c0: 10110100 00000001 00001101 10011001 ....
000000c4: 11010010 11001101 00011010 01101000 ...h
000000c8: 11110001 11100110 10111000 00010000 ....
000000cc: 11111111 11111000 01101001 00011000 ..i.
000000d0: 00000001 00000010 10100100 00000010 ....
000000d4: 11000011 10000010 11000100 00001011 ....
000000d8: 11000001 01001010 00000011 11101110 .J..
000000dc: 01001000 11011101 00000011 10110110 H...
000000e0: 01111100 00010011 00110000 |.0
Most of the streaminfo metadata block, including its header, is the same as in example 1, so only parts that are different are listed in the following table.
ヘッダーを含むStreaminfoメタデータブロックのほとんどは、例1と同じであるため、次の表に異なる部分のみがリストされています。
+========+=========+============+=============================+
| Start | Length | Contents | Description |
+========+=========+============+=============================+
| 0x04+0 | 1 bit | 0b0 | Not the last metadata block |
+--------+---------+------------+-----------------------------+
| 0x08+0 | 2 bytes | 0x0010 | Min. block size 16 |
+--------+---------+------------+-----------------------------+
| 0x0a+0 | 2 bytes | 0x0010 | Max. block size 16 |
+--------+---------+------------+-----------------------------+
| 0x0c+0 | 3 bytes | 0x000017 | Min. frame size 23 bytes |
+--------+---------+------------+-----------------------------+
| 0x0f+0 | 3 bytes | 0x000044 | Max. frame size 68 bytes |
+--------+---------+------------+-----------------------------+
| 0x15+4 | 36 bits | 0b0000, | Total no. of samples 19 |
| | | 0x00000013 | |
+--------+---------+------------+-----------------------------+
| 0x1a | 16 | (...) | MD5 checksum |
| | bytes | | |
+--------+---------+------------+-----------------------------+
Table 32
This time, the minimum and maximum block sizes are reflected in the file: there is one block of 16 samples, and the last block (which has 3 samples) is not considered for the minimum block size. The MD5 checksum is 0xd5b0 5649 75e9 8b8d 8b93 0422 757b 8103. This will be verified at the end of this example.
今回は、最小および最大ブロックサイズがファイルに反映されます。16個のサンプルのブロックが1つあり、最後のブロック（3つのサンプルがある）は最小ブロックサイズでは考慮されません。MD5チェックサムは0xD5B0 5649 75E9 8B8D 8B93 0422 757B 8103です。これは、この例の最後に検証されます。
The seek table metadata block only holds one entry. It is not really useful here, as it points to the first frame, but it is enough for this example. The seek table metadata block is broken down in the following table.
Seek Table Metadataブロックには、1つのエントリのみが保持されます。最初のフレームを指しているため、ここでは本当に役に立ちませんが、この例には十分です。シークテーブルメタデータブロックは、次の表で分解されます。
+========+========+====================+================+
| Start | Length | Contents | Description |
+========+========+====================+================+
| 0x2a+0 | 1 bit | 0b0 | Not the last |
| | | | metadata block |
+--------+--------+--------------------+----------------+
| 0x2a+1 | 7 bits | 0b0000011 | Seek table |
| | | | metadata block |
+--------+--------+--------------------+----------------+
| 0x2b+0 | 3 | 0x000012 | Length 18 |
| | bytes | | bytes |
+--------+--------+--------------------+----------------+
| 0x2e+0 | 8 | 0x0000000000000000 | Seek point to |
| | bytes | | sample 0 |
+--------+--------+--------------------+----------------+
| 0x36+0 | 8 | 0x0000000000000000 | Seek point to |
| | bytes | | offset 0 |
+--------+--------+--------------------+----------------+
| 0x3e+0 | 2 | 0x0010 | Seek point to |
| | bytes | | block size 16 |
+--------+--------+--------------------+----------------+
Table 33
The Vorbis comment metadata block contains the vendor string and a single comment. It is broken down in the following table.
Vorbisコメントメタデータブロックには、ベンダー文字列と単一のコメントが含まれています。次の表に分解されます。
+========+==========+============+===============================+
| Start | Length | Contents | Description |
+========+==========+============+===============================+
| 0x40+0 | 1 bit | 0b0 | Not the last metadata block |
+--------+----------+------------+-------------------------------+
| 0x40+1 | 7 bits | 0b0000100 | Vorbis comment metadata block |
+--------+----------+------------+-------------------------------+
| 0x41+0 | 3 bytes | 0x00003a | Length 58 bytes |
+--------+----------+------------+-------------------------------+
| 0x44+0 | 4 bytes | 0x20000000 | Vendor string length 32 bytes |
+--------+----------+------------+-------------------------------+
| 0x48+0 | 32 bytes | (...) | Vendor string |
+--------+----------+------------+-------------------------------+
| 0x68+0 | 4 bytes | 0x01000000 | Number of fields 1 |
+--------+----------+------------+-------------------------------+
| 0x6c+0 | 4 bytes | 0x0e000000 | Field length 14 bytes |
+--------+----------+------------+-------------------------------+
| 0x70+0 | 14 bytes | (...) | Field contents |
+--------+----------+------------+-------------------------------+
Table 34
The vendor string is reference libFLAC 1.3.3 20190804, and the field contents of the only field is
ベンダー文字列はリファレンスlibflac 1.3.3 20190804であり、フィールドの唯一のフィールドの内容は
TITLE=שלום
where in direction of reading, the sequence of characters forming the field content is: "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER LAMED, U+05DC), "ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER FINAL MEM, U+05DD).
読み方の方向では、フィールドコンテンツを形成する文字のシーケンスは、「ש」（ヘブライ文字Shin、U+05e9）、「ל」（ヘブライ文字leall、u+05dc）、 "וו"（ヘブライ文字vav、u+05d5）、「ם」（ヘブライ文字最終mem、u+05dd）。
The Vorbis comment field is 14 bytes but only 10 characters in size, because it contains four 2-byte characters.
Vorbisコメントフィールドは14バイトですが、4バイト文字が4つ含まれているため、サイズは10文字のみです。
The last metadata block is a (very short) padding block.
最後のメタデータブロックは、（非常に短い）パディングブロックです。
+========+=========+================+========================+
| Start | Length | Contents | Description |
+========+=========+================+========================+
| 0x7e+0 | 1 bit | 0b1 | Last metadata block |
+--------+---------+----------------+------------------------+
| 0x7e+1 | 7 bits | 0b0000001 | Padding metadata block |
+--------+---------+----------------+------------------------+
| 0x7f+0 | 3 bytes | 0x000006 | Length 6 byte |
+--------+---------+----------------+------------------------+
| 0x82+0 | 6 bytes | 0x000000000000 | Padding bytes |
+--------+---------+----------------+------------------------+
Table 35
The frame header starts at position 0x88 and is broken down in the following table.
フレームヘッダーは位置0x88から始まり、次の表で分解されます。
+========+=========+=================+===================+
| Start | Length | Contents | Description |
+========+=========+=================+===================+
| 0x88+0 | 15 bits | 0xff, 0b1111100 | Frame sync |
+--------+---------+-----------------+-------------------+
| 0x89+7 | 1 bit | 0b0 | Blocking strategy |
+--------+---------+-----------------+-------------------+
| 0x8a+0 | 4 bits | 0b0110 | 8-bit block size |
| | | | further down |
+--------+---------+-----------------+-------------------+
| 0x8a+4 | 4 bits | 0b1001 | Sample rate 44.1 |
| | | | kHz |
+--------+---------+-----------------+-------------------+
| 0x8b+0 | 4 bits | 0b1001 | Side-right stereo |
+--------+---------+-----------------+-------------------+
| 0x8b+4 | 3 bits | 0b100 | Bit depth 16 bit |
+--------+---------+-----------------+-------------------+
| 0x8b+7 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+-----------------+-------------------+
| 0x8c+0 | 1 byte | 0x00 | Frame number 0 |
+--------+---------+-----------------+-------------------+
| 0x8d+0 | 1 byte | 0x0f | Block size 16 |
+--------+---------+-----------------+-------------------+
| 0x8e+0 | 1 byte | 0x99 | Frame header CRC |
+--------+---------+-----------------+-------------------+
Table 36
The first subframe starts at byte 0x8f, and it is broken down in the following table, excluding the coded residual. As this subframe codes for a side channel, the bit depth is increased by 1 bit from 16 bits to 17 bits. This is most clearly present in the unencoded warm-up sample.
最初のサブフレームはBYTE 0x8Fで始まり、コード化された残差を除き、次の表で分解されます。このサブフレームがサイドチャネルをコードするため、ビットの深さは16ビットから17ビットから1ビットから1ビット増加します。これは、エンコードされていないウォームアップサンプルに最も明確に存在します。
+========+=========+=============+===========================+
| Start | Length | Contents | Description |
+========+=========+=============+===========================+
| 0x8f+0 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+-------------+---------------------------+
| 0x8f+1 | 6 bits | 0b001001 | Fixed subframe, 1st order |
+--------+---------+-------------+---------------------------+
| 0x8f+7 | 1 bit | 0b0 | No wasted bits used |
+--------+---------+-------------+---------------------------+
| 0x90+0 | 17 bits | 0x0867, 0b0 | Unencoded warm-up sample |
+--------+---------+-------------+---------------------------+
Table 37
The coded residual is broken down in the following table. All quotients are unary coded, and all remainders are stored unencoded with a number of bits specified by the Rice parameter.
コード化された残差は、次の表に分解されます。すべての商は単位コード化されており、すべての残りは、イネパラメーターによって指定された多数のビットでエンコードされていない保存されます。
+========+========+=================+=================+
| Start | Length | Contents | Description |
+========+========+=================+=================+
| 0x92+1 | 2 bits | 0b00 | Rice code with |
| | | | 4-bit parameter |
+--------+--------+-----------------+-----------------+
| 0x92+3 | 4 bits | 0b0000 | Partition order |
| | | | 0 |
+--------+--------+-----------------+-----------------+
| 0x92+7 | 4 bits | 0b1011 | Rice parameter |
| | | | 11 |
+--------+--------+-----------------+-----------------+
| 0x93+3 | 4 bits | 0b0001 | Quotient 3 |
+--------+--------+-----------------+-----------------+
| 0x93+7 | 11 | 0b00011110100 | Remainder 244 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0x95+2 | 2 bits | 0b01 | Quotient 1 |
+--------+--------+-----------------+-----------------+
| 0x95+4 | 11 | 0b01000100001 | Remainder 545 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0x96+7 | 2 bits | 0b01 | Quotient 1 |
+--------+--------+-----------------+-----------------+
| 0x97+1 | 11 | 0b00110011000 | Remainder 408 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0x98+4 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0x98+5 | 11 | 0b11101011101 | Remainder 1885 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0x9a+0 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0x9a+1 | 11 | 0b11101110000 | Remainder 1904 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0x9b+4 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0x9b+5 | 11 | 0b10101101111 | Remainder 1391 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0x9d+0 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0x9d+1 | 11 | 0b11000000000 | Remainder 1536 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0x9e+4 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0x9e+5 | 11 | 0b10000010111 | Remainder 1047 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xa0+0 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0xa0+1 | 11 | 0b10010101110 | Remainder 1198 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xa1+4 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0xa1+5 | 11 | 0b01100100001 | Remainder 801 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xa3+0 | 13 | 0b0000000000001 | Quotient 12 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xa4+5 | 11 | 0b11011100111 | Remainder 1767 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xa6+0 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0xa6+1 | 11 | 0b01001110111 | Remainder 631 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xa7+4 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0xa7+5 | 11 | 0b01000100100 | Remainder 548 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xa9+0 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0xa9+1 | 11 | 0b01000010101 | Remainder 533 |
| | bits | | |
+--------+--------+-----------------+-----------------+
| 0xaa+4 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+-----------------+-----------------+
| 0xaa+5 | 11 | 0b00100001100 | Remainder 268 |
| | bits | | |
+--------+--------+-----------------+-----------------+
Table 38
At this point, the decoder should know it is done decoding the coded residual, as it received 16 samples: 1 warm-up sample and 15 residual samples. Each residual sample can be calculated from the quotient and remainder and from undoing the zigzag encoding. For example, the value of the first zigzag-encoded residual sample is 3 * 2^11 + 244 = 6388. As this is an even number, the zigzag encoding is undone by dividing by 2; the residual sample value is 3194. This is done for all residual samples in the next table.
この時点で、デコーダーは16のサンプルを受け取ったため、コード化された残差を解読していることを知っている必要があります：1つのウォームアップサンプルと15の残留サンプル。各残差サンプルは、商と残りから、Zigzagエンコーディングを元に戻すことから計算できます。たとえば、最初のジグザグエンコード残差サンプルの値は3 * 2^11 + 244 = 6388です。これは偶数であるため、ジグザグエンコーディングは2で除算することで元に戻されます。残差サンプル値は3194です。これは、次の表のすべての残差サンプルに対して行われます。
+==========+===========+================+=======================+
| Quotient | Remainder | Zigzag Encoded | Residual Sample Value |
+==========+===========+================+=======================+
| 3 | 244 | 6388 | 3194 |
+----------+-----------+----------------+-----------------------+
| 1 | 545 | 2593 | -1297 |
+----------+-----------+----------------+-----------------------+
| 1 | 408 | 2456 | 1228 |
+----------+-----------+----------------+-----------------------+
| 0 | 1885 | 1885 | -943 |
+----------+-----------+----------------+-----------------------+
| 0 | 1904 | 1904 | 952 |
+----------+-----------+----------------+-----------------------+
| 0 | 1391 | 1391 | -696 |
+----------+-----------+----------------+-----------------------+
| 0 | 1536 | 1536 | 768 |
+----------+-----------+----------------+-----------------------+
| 0 | 1047 | 1047 | -524 |
+----------+-----------+----------------+-----------------------+
| 0 | 1198 | 1198 | 599 |
+----------+-----------+----------------+-----------------------+
| 0 | 801 | 801 | -401 |
+----------+-----------+----------------+-----------------------+
| 12 | 1767 | 26343 | -13172 |
+----------+-----------+----------------+-----------------------+
| 0 | 631 | 631 | -316 |
+----------+-----------+----------------+-----------------------+
| 0 | 548 | 548 | 274 |
+----------+-----------+----------------+-----------------------+
| 0 | 533 | 533 | -267 |
+----------+-----------+----------------+-----------------------+
| 0 | 268 | 268 | 134 |
+----------+-----------+----------------+-----------------------+
Table 39
In this case, using a Rice code is more efficient than storing values unencoded. The Rice code (excluding the partition order and parameter) is 199 bits in length. The largest residual value (-13172) would need 15 bits to be stored unencoded, so storing all 15 samples with 15 bits results in a sequence with a length of 225 bits.
この場合、稲法を使用することは、エンコードされていない値を保存するよりも効率的です。稲法（パーティションの順序とパラメーターを除く）の長さは199ビットです。最大の残留値（-13172）は、エンコードなしで15ビットを保存する必要があるため、15ビットの15サンプルすべてを保存すると、長さ225ビットのシーケンスになります。
The next step is using the predictor and the residuals to restore the sample values. As this subframe uses a fixed predictor with order 1, the residual value is added to the value of the previous sample.
次のステップは、予測子と残差を使用してサンプル値を復元することです。このサブフレームは、順序1で固定予測子を使用するため、残差は前のサンプルの値に追加されます。
+===========+==============+
| Residual | Sample Value |
+===========+==============+
| (warm-up) | 4302 |
+-----------+--------------+
| 3194 | 7496 |
+-----------+--------------+
| -1297 | 6199 |
+-----------+--------------+
| 1228 | 7427 |
+-----------+--------------+
| -943 | 6484 |
+-----------+--------------+
| 952 | 7436 |
+-----------+--------------+
| -696 | 6740 |
+-----------+--------------+
| 768 | 7508 |
+-----------+--------------+
| -524 | 6984 |
+-----------+--------------+
| 599 | 7583 |
+-----------+--------------+
| -401 | 7182 |
+-----------+--------------+
| -13172 | -5990 |
+-----------+--------------+
| -316 | -6306 |
+-----------+--------------+
| 274 | -6032 |
+-----------+--------------+
| -267 | -6299 |
+-----------+--------------+
| 134 | -6165 |
+-----------+--------------+
Table 40
With this, the decoding of the first subframe is complete. The decoding of the second subframe is very similar, as it also uses a fixed predictor of order 1. This is left as an exercise for the reader; the results are in the next table. The next step is undoing stereo decorrelation, which is done in the following table. As the stereo decorrelation is side-right, the samples in the right channel come directly from the second subframe, while the samples in the left channel are found by adding the values of both subframes for each sample.
これにより、最初のサブフレームのデコードが完了します。2番目のサブフレームのデコードは、注文1の固定予測因子も使用するため、非常に似ています。これは、読者の演習として残されています。結果は次の表にあります。次のステップは、次の表で行われるステレオ分離を元に戻すことです。ステレオの分離はサイドロイトであるため、右チャネルのサンプルは2番目のサブフレームから直接送られますが、左チャネルのサンプルは、各サンプルの両方のサブフレームの値を追加することで見つかります。
+============+============+========+=======+
| Subframe 1 | Subframe 2 | Left | Right |
+============+============+========+=======+
| 4302 | 6070 | 10372 | 6070 |
+------------+------------+--------+-------+
| 7496 | 10545 | 18041 | 10545 |
+------------+------------+--------+-------+
| 6199 | 8743 | 14942 | 8743 |
+------------+------------+--------+-------+
| 7427 | 10449 | 17876 | 10449 |
+------------+------------+--------+-------+
| 6484 | 9143 | 15627 | 9143 |
+------------+------------+--------+-------+
| 7436 | 10463 | 17899 | 10463 |
+------------+------------+--------+-------+
| 6740 | 9502 | 16242 | 9502 |
+------------+------------+--------+-------+
| 7508 | 10569 | 18077 | 10569 |
+------------+------------+--------+-------+
| 6984 | 9840 | 16824 | 9840 |
+------------+------------+--------+-------+
| 7583 | 10680 | 18263 | 10680 |
+------------+------------+--------+-------+
| 7182 | 10113 | 17295 | 10113 |
+------------+------------+--------+-------+
| -5990 | -8428 | -14418 | -8428 |
+------------+------------+--------+-------+
| -6306 | -8895 | -15201 | -8895 |
+------------+------------+--------+-------+
| -6032 | -8476 | -14508 | -8476 |
+------------+------------+--------+-------+
| -6299 | -8896 | -15195 | -8896 |
+------------+------------+--------+-------+
| -6165 | -8653 | -14818 | -8653 |
+------------+------------+--------+-------+
Table 41
As the second subframe ends byte-aligned, no padding bits follow it. Finally, the last 2 bytes of the frame contain the frame CRC.
2番目のサブフレームがバイトアラインを終了すると、パディングビットはそれに続いていません。最後に、フレームの最後の2バイトにはフレームCRCが含まれています。
The second audio frame is very similar to the frame decoded in the first example, but this time, 3 samples (not 1) are present.
2番目のオーディオフレームは、最初の例でデコードされたフレームに非常に似ていますが、今回は3つのサンプル（1ではない）が存在します。
The frame header starts at position 0xcc and is broken down in the following table.
フレームヘッダーは位置0xccで始まり、次の表で分解されます。
+========+=========+=================+===================+
| Start | Length | Contents | Description |
+========+=========+=================+===================+
| 0xcc+0 | 15 bits | 0xff, 0b1111100 | Frame sync |
+--------+---------+-----------------+-------------------+
| 0xcd+7 | 1 bit | 0b0 | Blocking strategy |
+--------+---------+-----------------+-------------------+
| 0xce+0 | 4 bits | 0b0110 | 8-bit block size |
| | | | further down |
+--------+---------+-----------------+-------------------+
| 0xce+4 | 4 bits | 0b1001 | Sample rate 44.1 |
| | | | kHz |
+--------+---------+-----------------+-------------------+
| 0xcf+0 | 4 bits | 0b0001 | Stereo, no |
| | | | decorrelation |
+--------+---------+-----------------+-------------------+
| 0xcf+4 | 3 bits | 0b100 | Bit depth 16 bits |
+--------+---------+-----------------+-------------------+
| 0xcf+7 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+-----------------+-------------------+
| 0xd0+0 | 1 byte | 0x01 | Frame number 1 |
+--------+---------+-----------------+-------------------+
| 0xd1+0 | 1 byte | 0x02 | Block size 3 |
+--------+---------+-----------------+-------------------+
| 0xd2+0 | 1 byte | 0xa4 | Frame header CRC |
+--------+---------+-----------------+-------------------+
Table 42
The first subframe starts at 0xd3+0 and is broken down in the following table.
最初のサブフレームは0xD3+0から始まり、次の表で分解されます。
+========+=========+==========+=========================+
| Start | Length | Contents | Description |
+========+=========+==========+=========================+
| 0xd3+0 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+----------+-------------------------+
| 0xd3+1 | 6 bits | 0b000001 | Verbatim subframe |
+--------+---------+----------+-------------------------+
| 0xd3+7 | 1 bit | 0b0 | No wasted bits used |
+--------+---------+----------+-------------------------+
| 0xd4+0 | 16 bits | 0xc382 | 16-bit unencoded sample |
+--------+---------+----------+-------------------------+
| 0xd6+0 | 16 bits | 0xc40b | 16-bit unencoded sample |
+--------+---------+----------+-------------------------+
| 0xd8+0 | 16 bits | 0xc14a | 16-bit unencoded sample |
+--------+---------+----------+-------------------------+
Table 43
The second subframe starts at 0xda+0 and is broken down in the following table.
2番目のサブフレームは0xDa+0から始まり、次の表で分解されます。
+========+=========+===================+=========================+
| Start | Length | Contents | Description |
+========+=========+===================+=========================+
| 0xda+0 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+-------------------+-------------------------+
| 0xda+1 | 6 bits | 0b000001 | Verbatim subframe |
+--------+---------+-------------------+-------------------------+
| 0xda+7 | 1 bit | 0b1 | Wasted bits used |
+--------+---------+-------------------+-------------------------+
| 0xdb+0 | 1 bit | 0b1 | 1 wasted bit used |
+--------+---------+-------------------+-------------------------+
| 0xdb+1 | 15 bits | 0b110111001001000 | 15-bit unencoded sample |
+--------+---------+-------------------+-------------------------+
| 0xdd+0 | 15 bits | 0b110111010000001 | 15-bit unencoded sample |
+--------+---------+-------------------+-------------------------+
| 0xde+7 | 15 bits | 0b110110110011111 | 15-bit unencoded sample |
+--------+---------+-------------------+-------------------------+
Table 44
As this subframe uses wasted bits, the 15-bit unencoded samples need to be shifted left by 1 bit. For example, sample 1 is stored as -4536 and becomes -9072 after shifting left 1 bit.
このサブフレームは無駄なビットを使用するため、15ビットの非エンエンコードサンプルを1ビットでシフトする必要があります。たとえば、サンプル1は-4536として保存され、左1ビットをシフトした後に-9072になります。
As the last subframe does not end on byte alignment, 2 padding bits are added before the 2-byte frame CRC, which follows at 0xe1+0.
最後のサブフレームはバイトアラインメントで終了しないため、2バイトフレームCRCの前に2つのパディングビットが追加されます。これは0xe1+0です。
All samples in the file have been decoded, and we can now verify the MD5 checksum. All sample values must be interleaved and stored signed coded little-endian. The result of this follows in groups of 12 samples (i.e., 6 interchannel samples) per line.
ファイル内のすべてのサンプルがデコードされており、MD5チェックサムを確認できるようになりました。すべてのサンプル値はインターリーブし、署名されたコード付きリトルエンディアンを保存する必要があります。これの結果は、1行あたり12のサンプル（つまり、6つのインターチャネルサンプル）のグループになります。
0x8428 B617 7946 3129 5E3A 2722 D445 D128 0B3D B723 EB45 DF28
0x723f 1E25 9D46 4929 B841 7026 5747 B829 8F43 8127 AEC7 14DF
0x9FC4 41DD 54C7 E4DE A5C4 40DD 1EC6 33DE 82C3 90DC 0BC4 02DD
0x4AC1 3EDB
The MD5 checksum of this is indeed the same as the one found in the streaminfo metadata block.
これのMD5チェックサムは、確かにStreaminfoメタデータブロックに見られるものと同じです。
This example is once again a very short FLAC file. The focus of this example is on decoding a subframe with a linear predictor and a coded residual with more than one partition.
この例は、再び非常に短いFLACファイルです。この例の焦点は、線形予測因子と複数のパーティションを備えたコード化された残差を備えたサブフレームをデコードすることです。
00000000: 664c 6143 8000 0022 1000 1000 fLaC..."....
0000000c: 0000 1f00 001f 07d0 0070 0000 .........p..
00000018: 0018 f8f9 e396 f5cb cfc6 dc80 ............
00000024: 7f99 7790 6b32 fff8 6802 0017 ..w.k2..h...
00000030: e944 004f 6f31 3d10 47d2 27cb .D.Oo1=.G.'.
0000003c: 6d09 0831 452b dc28 2222 8057 m..1E+.("".W
00000048: a3 .
0000002a: 11111111 11111000 01101000 00000010 ..h.
0000002e: 00000000 00010111 11101001 01000100 ...D
00000032: 00000000 01001111 01101111 00110001 .Oo1
00000036: 00111101 00010000 01000111 11010010 =.G.
0000003a: 00100111 11001011 01101101 00001001 '.m.
0000003e: 00001000 00110001 01000101 00101011 .1E+
00000042: 11011100 00101000 00100010 00100010 .(""
00000046: 10000000 01010111 10100011 .W.
Most of the streaminfo metadata block, including its header, is the same as in example 1, so only parts that are different are listed in the following table.
ヘッダーを含むStreaminfoメタデータブロックのほとんどは、例1と同じであるため、次の表に異なる部分のみがリストされています。
+========+==========+====================+==========================+
| Start | Length | Contents | Description |
+========+==========+====================+==========================+
| 0x0c+0 | 3 bytes | 0x00001f | Min. frame size 31 bytes |
+--------+----------+--------------------+--------------------------+
| 0x0f+0 | 3 bytes | 0x00001f | Max. frame size 31 bytes |
+--------+----------+--------------------+--------------------------+
| 0x12+0 | 20 bits | 0x07d0, 0x0000 | Sample rate 32000 hertz |
+--------+----------+--------------------+--------------------------+
| 0x14+4 | 3 bits | 0b000 | 1 channel |
+--------+----------+--------------------+--------------------------+
| 0x14+7 | 5 bits | 0b00111 | Sample bit depth 8 bits |
+--------+----------+--------------------+--------------------------+
| 0x15+4 | 36 bits | 0b0000, 0x00000018 | Total no. of samples 24 |
+--------+----------+--------------------+--------------------------+
| 0x1a | 16 | (...) | MD5 checksum |
| | bytes | | |
+--------+----------+--------------------+--------------------------+
Table 45
The frame header starts at position 0x2a and is broken down in the following table.
フレームヘッダーは位置0x2aから始まり、次の表で分解されます。
+========+=========+=================+===================+
| Start | Length | Contents | Description |
+========+=========+=================+===================+
| 0x2a+0 | 15 bits | 0xff, 0b1111100 | Frame sync |
+--------+---------+-----------------+-------------------+
| 0x2b+7 | 1 bit | 0b0 | blocking strategy |
+--------+---------+-----------------+-------------------+
| 0x2c+0 | 4 bits | 0b0110 | 8-bit block size |
| | | | further down |
+--------+---------+-----------------+-------------------+
| 0x2c+4 | 4 bits | 0b1000 | Sample rate 32 |
| | | | kHz |
+--------+---------+-----------------+-------------------+
| 0x2d+0 | 4 bits | 0b0000 | Mono audio (1 |
| | | | channel) |
+--------+---------+-----------------+-------------------+
| 0x2d+4 | 3 bits | 0b001 | Bit depth 8 bits |
+--------+---------+-----------------+-------------------+
| 0x2d+7 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+---------+-----------------+-------------------+
| 0x2e+0 | 1 byte | 0x00 | Frame number 0 |
+--------+---------+-----------------+-------------------+
| 0x2f+0 | 1 byte | 0x17 | Block size 24 |
+--------+---------+-----------------+-------------------+
| 0x30+0 | 1 byte | 0xe9 | Frame header CRC |
+--------+---------+-----------------+-------------------+
Table 46
The first and only subframe starts at byte 0x31. It is broken down in the following table, without the coded residual.
最初の唯一のサブフレームは、BYTE 0x31で始まります。コード化された残差なしで、次の表に分解されます。
+========+========+==========+=====================+
| Start | Length | Contents | Description |
+========+========+==========+=====================+
| 0x31+0 | 1 bit | 0b0 | Mandatory 0 bit |
+--------+--------+----------+---------------------+
| 0x31+1 | 6 bits | 0b100010 | Linear prediction |
| | | | subframe, 3rd order |
+--------+--------+----------+---------------------+
| 0x31+7 | 1 bit | 0b0 | No wasted bits used |
+--------+--------+----------+---------------------+
| 0x32+0 | 8 bits | 0x00 | Unencoded warm-up |
| | | | sample 0 |
+--------+--------+----------+---------------------+
| 0x33+0 | 8 bits | 0x4f | Unencoded warm-up |
| | | | sample 79 |
+--------+--------+----------+---------------------+
| 0x34+0 | 8 bits | 0x6f | Unencoded warm-up |
| | | | sample 111 |
+--------+--------+----------+---------------------+
| 0x35+0 | 4 bits | 0b0011 | Coefficient |
| | | | precision 4 bit |
+--------+--------+----------+---------------------+
| 0x35+4 | 5 bits | 0b00010 | Prediction right |
| | | | shift 2 |
+--------+--------+----------+---------------------+
| 0x36+1 | 4 bits | 0b0111 | Predictor |
| | | | coefficient 7 |
+--------+--------+----------+---------------------+
| 0x36+5 | 4 bits | 0b1010 | Predictor |
| | | | coefficient -6 |
+--------+--------+----------+---------------------+
| 0x37+1 | 4 bits | 0b0010 | Predictor |
| | | | coefficient 2 |
+--------+--------+----------+---------------------+
Table 47
The data stream continues with the coded residual, which is broken down in the following table. Residual partitions 3 and 4 are left as an exercise for the reader.
データストリームは、次の表に分解されているコード化された残差で続きます。残留パーティション3と4は、読者のための演習として残されています。
+========+========+==========+======================================+
| Start | Length | Contents | Description |
+========+========+==========+======================================+
| 0x37+5 | 2 bits | 0b00 | Rice-coded residual, |
| | | | 4-bit parameter |
+--------+--------+----------+--------------------------------------+
| 0x37+7 | 4 bits | 0b0010 | Partition order 2 |
+--------+--------+----------+--------------------------------------+
| 0x38+3 | 4 bits | 0b0011 | Rice parameter 3 |
+--------+--------+----------+--------------------------------------+
| 0x38+7 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+----------+--------------------------------------+
| 0x39+0 | 3 bits | 0b110 | Remainder 6 |
+--------+--------+----------+--------------------------------------+
| 0x39+3 | 1 bit | 0b1 | Quotient 0 |
+--------+--------+----------+--------------------------------------+
| 0x39+4 | 3 bits | 0b001 | Remainder 1 |
+--------+--------+----------+--------------------------------------+
| 0x39+7 | 4 bits | 0b0001 | Quotient 3 |
+--------+--------+----------+--------------------------------------+
| 0x3a+3 | 3 bits | 0b001 | Remainder 1 |
+--------+--------+----------+--------------------------------------+
| 0x3a+6 | 4 bits | 0b1111 | No Rice parameter, |
| | | | escape code |
+--------+--------+----------+--------------------------------------+
| 0x3b+2 | 5 bits | 0b00101 | Partition encoded |
| | | | with 5 bits |
+--------+--------+----------+--------------------------------------+
| 0x3b+7 | 5 bits | 0b10110 | Residual -10 |
+--------+--------+----------+--------------------------------------+
| 0x3c+4 | 5 bits | 0b11010 | Residual -6 |
+--------+--------+----------+--------------------------------------+
| 0x3d+1 | 5 bits | 0b00010 | Residual 2 |
+--------+--------+----------+--------------------------------------+
| 0x3d+6 | 5 bits | 0b01000 | Residual 8 |
+--------+--------+----------+--------------------------------------+
| 0x3e+3 | 5 bits | 0b01000 | Residual 8 |
+--------+--------+----------+--------------------------------------+
| 0x3f+0 | 5 bits | 0b00110 | Residual 6 |
+--------+--------+----------+--------------------------------------+
| 0x3f+5 | 4 bits | 0b0010 | Rice parameter 2 |
+--------+--------+----------+--------------------------------------+
| 0x40+1 | 22 | (...) | Residual partition 3 |
| | bits | | |
+--------+--------+----------+--------------------------------------+
| 0x42+7 | 4 bits | 0b0001 | Rice parameter 1 |
+--------+--------+----------+--------------------------------------+
| 0x43+3 | 23 | (...) | Residual partition 4 |
| | bits | | |
+--------+--------+----------+--------------------------------------+
Table 48
The frame ends with 6 padding bits and a 2-byte frame CRC.
フレームは、6つのパディングビットと2バイトのフレームCRCで終わります。
To decode this subframe, 21 predictions have to be calculated and added to their corresponding residuals. This is a sequential process: as each prediction uses previous samples, it is not possible to start this decoding halfway through a subframe or decode a subframe with parallel threads.
このサブフレームをデコードするには、21の予測を計算し、対応する残差に追加する必要があります。これはシーケンシャルプロセスです。各予測は以前のサンプルを使用するため、サブフレームの途中でこのデコードを開始したり、並列スレッドでサブフレームをデコードすることはできません。
The following table breaks down the calculation for each sample. For example, the predictor without shift value of row 4 is found by applying the predictor with the three warm-up samples: 7*111 - 6*79 + 2*0 = 303. This value is then shifted right by 2 bits: 303 >> 2 = 75. Then, the decoded residual sample is added: 75 + 3 = 78.
次の表は、各サンプルの計算を分解します。たとえば、行4のシフト値のない予測因子は、3つのウォームアップサンプルで予測子を適用することにより見つかります：7*111-6*79 + 2*0 = 303。この値は2ビットの右にシフトされます：303>> 2 =75。その後、デコードされた残留サンプルが追加されます：75 + 3 = 78。
+===========+=====================+===========+==============+
| Residual | Predictor w/o Shift | Predictor | Sample Value |
+===========+=====================+===========+==============+
| (warm-up) | N/A | N/A | 0 |
+-----------+---------------------+-----------+--------------+
| (warm-up) | N/A | N/A | 79 |
+-----------+---------------------+-----------+--------------+
| (warm-up) | N/A | N/A | 111 |
+-----------+---------------------+-----------+--------------+
| 3 | 303 | 75 | 78 |
+-----------+---------------------+-----------+--------------+
| -1 | 38 | 9 | 8 |
+-----------+---------------------+-----------+--------------+
| -13 | -190 | -48 | -61 |
+-----------+---------------------+-----------+--------------+
| -10 | -319 | -80 | -90 |
+-----------+---------------------+-----------+--------------+
| -6 | -248 | -62 | -68 |
+-----------+---------------------+-----------+--------------+
| 2 | -58 | -15 | -13 |
+-----------+---------------------+-----------+--------------+
| 8 | 137 | 34 | 42 |
+-----------+---------------------+-----------+--------------+
| 8 | 236 | 59 | 67 |
+-----------+---------------------+-----------+--------------+
| 6 | 191 | 47 | 53 |
+-----------+---------------------+-----------+--------------+
| 0 | 53 | 13 | 13 |
+-----------+---------------------+-----------+--------------+
| -3 | -93 | -24 | -27 |
+-----------+---------------------+-----------+--------------+
| -5 | -161 | -41 | -46 |
+-----------+---------------------+-----------+--------------+
| -4 | -134 | -34 | -38 |
+-----------+---------------------+-----------+--------------+
| -1 | -44 | -11 | -12 |
+-----------+---------------------+-----------+--------------+
| 1 | 52 | 13 | 14 |
+-----------+---------------------+-----------+--------------+
| 1 | 94 | 23 | 24 |
+-----------+---------------------+-----------+--------------+
| 4 | 60 | 15 | 19 |
+-----------+---------------------+-----------+--------------+
| 2 | 17 | 4 | 6 |
+-----------+---------------------+-----------+--------------+
| 2 | -24 | -6 | -4 |
+-----------+---------------------+-----------+--------------+
| 2 | -26 | -7 | -5 |
+-----------+---------------------+-----------+--------------+
| 0 | 1 | 0 | 0 |
+-----------+---------------------+-----------+--------------+
Table 49
By lining up all these samples, we get the following input for the MD5 checksum calculation process:
これらすべてのサンプルを並べることにより、MD5チェックサム計算プロセスの次の入力が得られます。
0x004F 6F4E 08C3 A6BC F32A 4335 0DE5 D2DA F40E 1813 06FC FB00
This indeed results in the MD5 checksum found in the streaminfo metadata block.
実際、これにより、StreaminfoメタデータブロックにあるMD5チェックサムが発生します。
FLAC owes much to the many people who have advanced the audio compression field so freely. For instance:
FLACは、オーディオ圧縮フィールドを自由に進めた多くの人々に大いに負っています。例えば：
* Tony Robinson: He worked on Shorten, and his paper (see [Robinson-TR156]) is a good starting point on some of the basic methods used by FLAC. FLAC trivially extends and improves the fixed predictors, LPC coefficient quantization, and Rice coding used in Shorten.
* トニー・ロビンソン：彼はショーテンに取り組み、彼の論文（[ロビンソン-TR156を参照]を参照）は、FLACが使用する基本的な方法のいくつかの良い出発点です。FLACは、固定された予測因子、LPC係数量子化、および短縮で使用されるイネコーディングを簡単に拡張および改善します。
* Solomon W. Golomb and Robert F. Rice: Their universal codes are used by FLAC's entropy coder. See [Rice].
* Solomon W. GolombとRobert F. Rice：それらのユニバーサルコードは、FLACのエントロピーコーダーによって使用されています。[米]を参照してください。
* Norman Levinson and James Durbin: The FLAC reference encoder uses an algorithm developed and refined by them for determining the LPC coefficients from the autocorrelation coefficients. See [Durbin]).
* Norman LevinsonとJames Durbin：FLACリファレンスエンコーダーは、自己相関係数からLPC係数を決定するために開発および改良されたアルゴリズムを使用します。[Durbin]を参照してください。
* Claude Shannon: See [Shannon].
* クロード・シャノン：[シャノン]を参照。
The FLAC format, the FLAC reference implementation [FLAC-implementation], and the initial draft version of this document were originally developed by Josh Coalson. While many others have contributed since, this original effort is deeply appreciated.
FLAC形式、FLAC参照実装[FLAC-Implementation]、およびこのドキュメントの最初のドラフトバージョンは、もともとJosh Coalsonによって開発されました。それ以来、他の多くの人が貢献していますが、この当初の努力は深く感謝されています。
Martijn van Beurden
Netherlands
Email: mvanb1@gmail.com
Andrew Weaver
Email: theandrewjw@gmail.com