From nobody Sun Feb 26 18:42:56 2023 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D536C151B16 for ; Sun, 26 Feb 2023 18:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCTuS9bl1iQl for ; Sun, 26 Feb 2023 18:42:50 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E458C14F721 for ; Sun, 26 Feb 2023 18:42:50 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id x20-20020a17090a8a9400b00233ba727724so10458217pjn.1 for ; Sun, 26 Feb 2023 18:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=BuBezTGja85O5Ig9o6l/a7jlXQh3HKdcdWMMjzsNoSQ=; b=Fu+wmoqeuXsH6G8IgWXx5GMlT8XJw+mANE5b44IoreAJVTQ14RGqAlQKZJfnxlPT/C n4kWnPYz9OB1AZKPn9m9rJ4HMDywSVujDfQ8bGCw/l9boboTjAhOKQ+/1s0L9/xPm7yk QZXa+eXZpTJDbJFN5cYo3lR9tdckSiSZSglQuCIf/C8nuImiLF2mVsee9nV22vGpMk+c a2+gKtPdEZb1BuS038n4LWZPQQzlKjqo8lhaHL/PBd5azJ5Ulyah1WPQamsutXQyUxjN vwBhnDtXfCW4GCXBMeX1/4cbFyQ1HkdwF0XW0pMiY07de/XN5r2/MFWogLFEbxVet5sV o9yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BuBezTGja85O5Ig9o6l/a7jlXQh3HKdcdWMMjzsNoSQ=; b=TV3OMKQJCdBNwjChKLpyprp3vPFDZwUYRNgjVGrAOhlmbr9Ql6cjxptF7IrQsHmzNw aehKW5hJ4yeVTUlLQik1vCiVU0qVyRlimuw/KfedPI7Vr8TTzMKt3ffGMtnr0IVu8CXQ 3Ap5rpJNz61LotW9ITyIAeYlDRt6Z1+0WjNQFUg3IY4voQMYxrgp2zIkiuOwtfiMP9tI d1H2q/tFG2YzX8YGCUwPDg7mkhW+T8rS5Da8ylCnKrcnLXLjoe4LJEEZPG2lvn9uSbC+ uYY8pRTEbVBNTGi6Ty08N75TJIzfHM+0/9MBkQ2Vna2Qvo6Uk9jQnJ0xSE3youF/J/pd zbsg== X-Gm-Message-State: AO0yUKXCXwKukorWhLiDOAxZ3vxWi2Z53sxlv/x29nmEObqTSfiDq7lG yYXKQJiVHLiNy8aETM5sX5wcv8xerXwaxvh1G+GjBn8Pc5S5Kg== X-Google-Smtp-Source: AK7set98PxnbcTDs3NqTccSoXTqHcn9qR2Kk9qalIs/l3u0NAPUaBpWY6+fQ8qqLCPR+Az+rmY2Lcm/ObUk6xjZ+ir0= X-Received: by 2002:a17:90a:dd8d:b0:230:3b84:9169 with SMTP id l13-20020a17090add8d00b002303b849169mr4108174pjv.2.1677465768953; Sun, 26 Feb 2023 18:42:48 -0800 (PST) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Sun, 26 Feb 2023 20:42:21 -0600 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000480d7705f5a56f73" Archived-At: Subject: [Cellar] My notes on https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/ X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2023 02:42:55 -0000 --000000000000480d7705f5a56f73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Cellar, I'm still working my way through https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/. I still need to read the Appendices, but I wanted to pass along my notes so far. In general, I like the document. I do have questions, especially about the use of BCP14 terminology, and some suggestions for readability, but this should get discussion started. I expect to have the reviews of the appendices done by tomorrow at close of business, my time. Best, Spencer ----------- I have a couple of comments on the abstract. Abstract This document defines the Free Lossless Audio Codec (FLAC) format. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals without needing to remove information in doing so (i.e. lossless). I might say, "without losing information in doing so (i.e. lossless)." FLAC is free in the sense that its specification is open, its reference implementation is open- source and it is not encumbered by any known patent. This ^^^^ might all be true, but I'd suggest removing at least "and it is not encumbered by any known patent". The IETF tries not to make statements about whether a technology is encumbered - the first question a reviewer would ask, is "any patent known to whom?", and it would get worse from there. Compared to other lossless (audio) coding formats, FLAC is a format with low complexity and can be coded to and from with little computing resources. Decoding of FLAC has seen many independent implementations on many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic. 1. Introduction The coding methods provided by the FLAC format work best on PCM audio signals of which the samples 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 to compress audio that is not PCM. Given ^^^^, do you need to say this? Is there a meaningful difference between "not suited for" and "cannone be compressed"? Pulse-density modulated audio, e.g. DSD, cannot be compressed by FLAC. 2. Notation and Conventions In this next paragraph, I'd suggest replacing "may be" with "are". "May" tends to be used in describing protocol operations in the IETF, and these are statements of fact. Values expressed as u(n) represent unsigned big-endian integer using n bits. Values expressed as s(n) represent signed big-endian integer using n bits, signed two's complement. n may be expressed as an equation using * (multiplication), / (division), + (addition), or - (subtraction). An inclusive range of the number of bits expressed may be represented with an ellipsis, such as u(m...n). The name of a value followed by an asterisk * indicates zero or more occurrences of the value. The name of a value followed by a plus sign + indicates one or more occurrences of the value. 3. Acknowledgments This section is very nice. We would ordinarily put an acknowledgement section at the end of a document, so, in this case, it would be after IANA Considerations. The RFC Editor folks may ask you to move the URLs in this section to Informative References, and use reference tags to link the people to the work they did. FLAC owes much to the many people who have advanced the audio compression field so freely. For instance: * A. J. Robinson (https://web.archive.org/web/20160315141134/ http://mi.eng.cam.ac.uk/~ajr/) for his work on Shorten; his paper ([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. * S. W. Golomb (https://web.archive.org/web/20040215005354/http://csi.usc.edu/ faculty/golomb.html) and Robert F. Rice; their universal codes are used by FLAC's entropy coder. * N. Levinson and J. Durbin; the reference encoder uses an algorithm developed and refined by them for determining the LPC coefficients from the autocorrelation coefficients. * And of course, Claude Shannon (https://en.wikipedia.org/wiki/ Claude_Shannon) The FLAC format, the FLAC reference implementation and this document were originally developed by Josh Coalson. While many others have contributed since, this original effort is deeply appreciated. 4. Definitions * *Subframe*: An encoded subblock. All subframes within a frame code for the same number of samples. A subframe MAY correspond to I'd suggest "might correspond". a subblock, else it corresponds to either the addition or subtraction of two subblocks, see section on interchannel decorrelation (#interchannel-decorrelation). * *Linear predictor*: a predictor using linear prediction (https://en.wikipedia.org/wiki/Linear_prediction). This is also I'd create a reference for this URL, and include it as Informative. 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 (https://en.wikipedia.org/wiki/ Finite_impulse_response). I'd create a reference for this URL, and include it as Informative. * *Rice code*: A variable-length code (https://en.wikipedia.org/wiki/Variable-length_code) which I'd create a reference for this URL, and include it as Informative. compresses data by making use of the observation that, after using an effective predictor, most residual samples are closer to zero than the original samples, while still allowing for a small part of the samples to be much larger. 5. Conceptual overview Similar to many audio coders, a FLAC file is encoded following the I'd suggest "many other audio coders" (other than FLAC, right?) steps below. On decoding a FLAC file, these steps are undone in reverse order, i.e. from bottom to top. * Blocking (see section on Blocking (#blocking)). The input is split up into many contiguous blocks. With FLAC, the blocks MAY vary in size. The optimal size of the block is usually affected So, what you say is true, but I'd suggest saying "Because FLAC blocks can vary in size, a FLAC decoder MUST be able to decode variable-sized blocks", so that the weak permission of MAY for an encoder is reflected in a strong requirement of MUST for the decoder. I'm assuming this is mandatory for decoders, unless it's OK for decoders to fail to decode conformant FLAC blocks. (if you want to say "MAY vary in size", I won't argue =F0=9F=99=82) by many factors, including the sample rate, spectral characteristics over time, etc. However, as finding the optimal block size arrangement is a rather complex problem, the FLAC format allows for a constant block size throughout a stream as well. * Prediction (see section on Prediction (#prediction)). 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 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 be included in the compressed stream. In case no usable predictor can be found for a certain subblock, the signal is stored instead of compressed Meta-comment - the phrase "in case" appears about 20 times in this document. I think this should be "if", throughout. This may be super clear to those skilled in the art, but I wonder if it would be clearer if it said, "the uncompressed signal is stored and the next stage is skipped" and the next stage is skipped. * Residual Coding (See section on Residual Coding (#residual- coding)). 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) MUST be coded Is this "MUST" a statement of reality ("if you don't code the error losslessly, the signal cannot be decoded without losing information"), or an actual requirement for the implementation? If the latter, perhaps "MUST be coded losslessly in order to recover the original signal without loss". 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. 5.1. Blocking The size used for blocking the audio data has a direct effect on the compression ratio. If the block size is too small, the resulting large number of frames mean that excess bits will be wasted 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, and a maximum block size of 65535 samples. This range covers the optimal size for all of the audio data FLAC supports. Is there a reference that could be included for the last statement here? ^ 5.3. Prediction A FLAC encoder is free in selecting which method is used to model the input, with the following exceptions: * 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 MUST NOT be used, My experience has been that if you're saying "this is a bad idea", it's better to explain the consequences ("using a constant subframe when the input signal is not constant, will result in very compact and inaccurate decoded streams"). If you're saying "MUST NOT be used", a decoder MUST detect that you're violating a MUST requirement, and the decoder's behavior would be undefined. Which are you saying? * When an encoder is unable to find a fixed or linear predictor of which all residual samples are representable in 32-bit signed integers as stated in section coded residual (#coded-residual), a verbatim subframe MUST be used. I have a similar comment here: are you saying "this is what a wise encoder would do", or are you saying "the decoder MUST detect that the encoder is violating a MUST protocol requirement and . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 16. Informative References [HPL-1999-144] Hans, M. and RW. Schafer, "Lossless Compression of Digital Audio", DOI 10.1109/79.939834, November 1999, . [IEC.60908.1999] International Electrotechnical Commission, "Audio recording - Compact disc digital audio system", IEC International standard 60908 second edition, 1999. [ISRC-handbook] "International Standard Recording Code (ISRC) Handbook, 4th edition", 2021, . [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, DOI 10.17487/RFC3533, May 2003, . [RFC5334] Goncalves, I., Pfeiffer, S., and C. Montgomery, "Ogg Media Types", RFC 5334, DOI 10.17487/RFC5334, September 2008, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [robinson-tr156] Robinson, T., "SHORTEN: Simple lossless and near-lossless waveform compression", December 1994, . --000000000000480d7705f5a56f73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Cellar,

I'm still working my w= ay through=C2=A0https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/. I s= till need to read the Appendices, but I wanted to pass along my notes so fa= r.=C2=A0

In general, I like the document. I do hav= e questions, especially about the use of BCP14 terminology, and some sugges= tions for readability, but this should=C2=A0get discussion started.=C2=A0

I expect to have the reviews of the appendices done= by tomorrow at close of business, my time.

Best,<= /div>

Spencer
-----------

I have a coupl= e of comments on the abstract.


Abstract


=C2=A0=C2=A0=C2=A0This = document defines the Free Lossless Audio Codec (FLAC) format.

=C2=A0=C2= =A0=C2=A0FLAC is designed to reduce the amount of computer storage space

= =C2=A0=C2=A0=C2=A0needed to store digital audio signals without needing to = remove

=C2=A0=C2=A0=C2=A0information in doing so (i.e. lossless).=C2=A0= =C2=A0


I might say, "without losing information in doing so (i.e= . lossless)."


=C2=A0=C2=A0=C2=A0FLAC is free in the sense=

=C2= =A0=C2=A0=C2=A0that its specification is open, its reference implementation= is open-

=C2=A0=C2=A0=C2=A0source and it is not encumbered by any known = patent.=C2=A0=C2=A0


This ^^^^ might all be true, but I'd suggest = removing at least "and it is not encumbered by any known patent".= The IETF tries not to make statements about whether a technology is encumb= ered - the first question a reviewer would ask, is "any patent known t= o whom?", and it would get worse from there.=C2=A0


=C2=A0=C2=A0= =C2=A0Compared to

=C2=A0=C2=A0=C2=A0other lossless (audio) coding formats= , FLAC is a format with low

=C2=A0=C2=A0=C2=A0complexity and can be coded= to and from with little computing

=C2=A0=C2=A0=C2=A0resources.=C2=A0 Dec= oding of FLAC has seen many independent

=C2=A0=C2=A0=C2=A0implementations= on many different platforms, and both encoding and

=C2=A0=C2=A0=C2=A0d= ecoding can be implemented without needing floating-point

=C2=A0=C2=A0= =C2=A0arithmetic.


1.=C2=A0 Introduction


=C2=A0=C2=A0=C2=A0The c= oding methods provided by the FLAC format work best on PCM audio

=

= =C2=A0= =C2=A0=C2=A0signals of which the samples have a signed representation and a= re

=C2=A0=C2=A0=C2=A0centered around zero.=C2=A0 Audio signals in which s= amples have an

=C2=A0=C2=A0=C2=A0unsigned representation must be transfor= med to a signed

=C2=A0=C2=A0=C2=A0representation as described in this doc= ument in order to achieve

=C2=A0=C2=A0=C2=A0reasonable compression.=C2=A0= The FLAC format is not suited to compress

=C2=A0=C2=A0=C2=A0audio that= is not PCM.=C2=A0=C2=A0


Given ^^^^, do you need to say this? Is ther= e a meaningful difference between "not suited for" and "cann= one be compressed"?=C2=A0


=C2=A0=C2=A0=C2=A0Pulse-density modula= ted audio, e.g.=C2=A0 DSD,

=C2=A0=C2=A0=C2=A0cannot be compressed by FLAC= .


2.=C2=A0 Notation and Conventions


In this next paragraph, I&#= 39;d suggest replacing "may be" with "are". "May&q= uot; tends to be used in describing protocol operations in the IETF, and th= ese are statements of fact.=C2=A0


=C2=A0=C2=A0=C2=A0Values expressed = as u(n) represent unsigned big-endian integer using

=C2=A0=C2=A0=C2=A0n= bits.=C2=A0 Values expressed as s(n) represent signed big-endian integer

=C2=A0=C2=A0=C2=A0using n bits, signed two's complement. n may be expr= essed as an

=C2=A0=C2=A0=C2=A0equation using * (multiplication), / (divis= ion), + (addition), or -

=C2=A0=C2=A0=C2=A0(subtraction).=C2=A0 An inclus= ive range of the number of bits expressed

=C2=A0=C2=A0=C2=A0may be repres= ented with an ellipsis, such as u(m...n).=C2=A0 The name of a

=C2=A0=C2= =A0=C2=A0value followed by an asterisk * indicates zero or more occurrences= of

=C2=A0=C2=A0=C2=A0the value.=C2=A0 The name of a value followed by a = plus sign + indicates

=C2=A0=C2=A0=C2=A0one or more occurrences of the va= lue.


3.=C2=A0 Acknowledgments


This section is very nice. We wou= ld ordinarily put an acknowledgement section at the end of a document, so, = in this case, it would be after IANA Considerations.=C2=A0


The RFC Ed= itor folks may ask you to move the URLs in this section to Informative Refe= rences, and use reference tags to link the people to the work they did.=C2= =A0


=C2=A0=C2=A0=C2=A0FLAC owes much to the many people who have adva= nced the audio

=C2=A0=C2=A0=C2=A0compression field so freely.=C2=A0 For i= nstance:


=C2=A0=C2=A0=C2=A0*=C2=A0 A.=C2=A0 J.=C2=A0 Robinson (https://web.archive.org/w= eb/20160315141134/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://mi.eng.cam.ac.uk/~ajr/) for his work= on Shorten; his paper

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0([robinson-tr1= 56]) is a good starting point on some of the basic

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0methods used by FLAC.=C2=A0 FLAC trivially extends and impro= ves the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fixed predictors, LPC coeffic= ient quantization, and Rice coding

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0us= ed in Shorten.

=C2=A0=C2=A0=C2=A0*=C2=A0 S.=C2=A0 W.=C2=A0 Golomb<= /p>

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(https://web.archive.org/web/2004021500535= 4/http://csi.usc.edu/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0faculty/gol= omb.html) and Robert F.=C2=A0 Rice; their universal codes

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0are used by FLAC's entropy coder.

=C2=A0=C2= =A0=C2=A0*=C2=A0 N.=C2=A0 Levinson and J.=C2=A0 Durbin; the reference encod= er uses an

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0algorithm developed and re= fined by them for determining the LPC

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0coefficients from the autocorrelation coefficients.

=C2=A0=C2=A0=C2=A0= *=C2=A0 And of course, Claude Shannon (https://en.wikipedia.org/wiki/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Claude_Shannon)


=C2=A0=C2=A0=C2=A0The FLAC format, the FLAC ref= erence implementation and this document

=C2=A0=C2=A0=C2=A0were originally= developed by Josh Coalson.=C2=A0 While many others have

=C2=A0=C2=A0= =C2=A0contributed since, this original effort is deeply appreciated.=


= 4.=C2=A0 Definitions


=C2=A0=C2=A0=C2=A0*=C2=A0 *Subframe*: An encoded= subblock.=C2=A0 All subframes within a frame

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0code for the same number of samples.=C2=A0 A subframe MAY correspo= nd to


I'd suggest "might correspond".


=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0a subblock, else it corresponds to either the ad= dition or

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0subtraction of two subblock= s, see section on interchannel

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0decorr= elation (#interchannel-decorrelation).


=C2=A0=C2=A0=C2=A0*=C2=A0 *L= inear predictor*: a predictor using linear prediction

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0(https://en.wikipedia.org/wiki/Linear_prediction).=C2=A0 This is als= o


I'd create a reference for this URL, and include it as Informat= ive.=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0called *linear predict= ive coding (LPC)*. With a linear predictor

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0each prediction is a linear combination of past samples, hence the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0name.=C2=A0 A linear predictor has a= causal discrete-time finite

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0impulse = response (https://en.wikipedia.o= rg/wiki/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Finite_impulse_response)= .


I'd create a reference for this URL, and include it as Informat= ive.=C2=A0


=C2=A0=C2=A0=C2=A0*=C2=A0 *Rice code*: A variable-length c= ode

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(https://en.wikipedia.org/wiki/Variable-lengt= h_code) which


I'd create a reference for this URL, and includ= e it as Informative.=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0compre= sses data by making use of the observation that, after using

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0an effective predictor, most residual samples are c= loser to zero

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0than the original sampl= es, while still allowing for a small part

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0of the samples to be much larger.


5.=C2=A0 Conceptual overview=


=C2=A0=C2=A0=C2=A0Similar to many audio coders, a FLAC file is encod= ed following the


I'd suggest "many other audio coders" = (other than FLAC, right?)


=C2=A0=C2=A0=C2=A0steps below.=C2=A0 On dec= oding a FLAC file, these steps are undone in

=C2=A0=C2=A0=C2=A0reverse or= der, i.e. from bottom to top.


=C2=A0=C2=A0=C2=A0*=C2=A0 Blocking (see= section on Blocking (#blocking)).=C2=A0 The input is

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0split up into many contiguous blocks.=C2=A0 With FLAC, th= e blocks MAY

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0vary in size.=C2=A0 The = optimal size of the block is usually affected


So, what you say is tru= e, but I'd suggest saying "Because FLAC blocks can vary in size, a= FLAC decoder MUST be able to decode variable-sized blocks", so that t= he weak permission of MAY for an encoder is reflected in a strong requireme= nt of MUST for the decoder. I'm assuming this is mandatory for decoders= , unless it's OK for decoders to fail to decode conformant FLAC blocks.=


(if you want to say "MAY vary in size", I won't argue = =F0=9F=99=82)


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0by many factors, in= cluding the sample rate, spectral

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cha= racteristics over time, etc.=C2=A0 However, as finding the optimal

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0block size arrangement is a rather complex pr= oblem, the FLAC

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0format allows for a c= onstant block size throughout a stream as

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0well.


=C2=A0=C2=A0=C2=A0*=C2=A0 Prediction (see section on Pred= iction (#prediction)).=C2=A0 To remove

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0redundancy in a signal, a predictor is stored for each subblock or

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0its transformation as formed in the previo= us step.=C2=A0 A predictor

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0consists o= f a simple mathematical description that can be used, as

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0the name implies, to predict a certain sample from = the samples

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0that preceded it.=C2=A0 A= s this prediction is rarely exact, the error

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0of this prediction is passed to the next stage.=C2=A0 The predicto= r of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0each subblock is completely inde= pendent from other subblocks.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Since t= he methods of prediction are known to both the encoder and

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0decoder, only the parameters of the predictor need = be included in

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the compressed stream.= =C2=A0 In case no usable predictor can be found

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0for a certain subblock, the signal is stored instead of compres= sed


Meta-comment - the phrase "in case" appears about 20 ti= mes in this document. I think this should be "if", throughout.=C2= =A0


This may be super clear to those skilled in the art, but I wonder= if it would be clearer if it said, "the uncompressed signal is stored= and the next stage is skipped"


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0and the next stage is skipped.


=C2=A0=C2=A0=C2=A0*=C2=A0 Residu= al Coding (See section on Residual Coding (#residual-

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0coding)).=C2=A0 As the predictor does not describe the si= gnal exactly,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the difference between = the original signal and the predicted

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0signal (called the error or residual signal) MUST be coded

Is this= "MUST" a statement of reality ("if you don't code the e= rror losslessly, the signal cannot be decoded without losing information&qu= ot;), or an actual requirement for the implementation?=C2=A0


=

= If the l= atter, perhaps "MUST be coded losslessly in order to recover the origi= nal signal without loss".=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0losslessly.=C2=A0 If the predictor is effective, the residual signal<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0us= es Rice coding, a subset of Golomb coding, with either 4-bit or

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:"Courier New";color:rgb(= 0,0,0);background-color:transparent;font-variant-numeric:normal;font-varian= t-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A05-bit parameters to code the residual signal.


5.1.=C2=A0 Blocking


=C2=A0=C2=A0=C2=A0The size used for blocking = the audio data has a direct effect on the

=C2=A0=C2=A0=C2=A0compression r= atio.=C2=A0 If the block size is too small, the resulting

=C2=A0=C2=A0= =C2=A0large number of frames mean that excess bits will be wasted on frame<= /span>

=C2=A0=C2=A0=C2=A0signal may vary so much that the enc= oder will be unable to find a

=C2=A0=C2=A0=C2=A0good predictor.=C2=A0 In = order to simplify encoder/decoder design, FLAC

=C2=A0=C2=A0=C2=A0imposes = a minimum block size of 16 samples, and a maximum block size

=C2=A0=C2=A0= =C2=A0of 65535 samples.=C2=A0 This range covers the optimal size for all of= the

=C2=A0=C2=A0=C2=A0audio data FLAC supports.


Is there a referen= ce that could be included for the last statement here? ^


5.3.=C2=A0 P= rediction


=C2=A0=C2=A0=C2=A0A FLAC encoder is free in selecting which= method is used to model the

=C2=A0=C2=A0=C2=A0input, with the following = exceptions:


=C2=A0=C2=A0=C2=A0*=C2=A0 When the samples that need to b= e stored do not all have the same

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0val= ue (i.e. the signal is not constant), a constant subframe MUST

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0NOT be used,


My experience has been that = if you're saying "this is a bad idea", it's better to exp= lain the consequences ("using a constant subframe when the input signa= l is not constant, will result in very compact and inaccurate decoded strea= ms"). If you're saying "MUST NOT be used", a decoder MUS= T detect that you're violating a MUST requirement, and the decoder'= s behavior would be undefined.=C2=A0


Which are you saying?=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0which all residual = samples are representable in 32-bit signed

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0integers as stated in section coded residual (#coded-residual), a<= /span>

I have a similar comment here: are you saying "this is what a wise en= coder would do", or are you saying "the decoder MUST detect that = the encoder is violating a MUST protocol requirement and <do something, = perhaps just discarding the subframe"?


=C2=A0=C2=A0=C2=A0For mor= e information on fixed and linear predictors, see

=C2=A0=C2=A0=C2=A0[HPL-= 1999-144] and [robinson-tr156].


5.4.=C2=A0 Residual Coding

=

=C2= =A0=C2=A0=C2=A0In case a subframe uses a predictor to approximate the audio= signal,

=C2=A0=C2=A0=C2=A0a residual needs to be stored to 'correct&= #39; the approximation to the


I'd suggest "is stored".<= /span>


=C2=A0=C2=A0=C2=A0exact value.=C2=A0 When an effective predictor is u= sed, the average

=C2=A0=C2=A0=C2=A0numerical value of the residual sample= s is smaller than that of the

=C2=A0=C2=A0=C2=A0samples before prediction= .=C2=A0 While having smaller values on average,

=C2=A0=C2=A0=C2=A0it is p= ossible a few 'outlier' residual samples are much larger than

=C2= =A0=C2=A0=C2=A0any of the original samples.=C2=A0 Sometimes these outliers = even exceed

=C2=A0=C2=A0=C2=A0the range the bit depth of the original aud= io offers.


=C2=A0=C2=A0=C2=A0Quite often the optimal Rice parameter v= aries over the course of a

=C2=A0=C2=A0=C2=A0subframe.=C2=A0 To accommoda= te this, the residual can be split up into

=C2=A0=C2=A0=C2=A0partitions= , where each partition has its own Rice parameter.=C2=A0 To keep

=

= =C2=A0= =C2=A0=C2=A0overhead and complexity low, the number of partitions used in a=

=C2=A0=C2=A0=C2=A0subframe is limited to powers of two.


I'd su= ggest "MUST be a power of two".=C2=A0


6.=C2=A0 Format pri= nciples


=C2=A0=C2=A0=C2=A0FLAC has no format version information, but= it does contain reserved

=C2=A0=C2=A0=C2=A0space in several places.=C2= =A0 Future versions of the format MAY use this

=C2=A0=C2=A0=C2=A0reserved= space safely without breaking the format of older streams.

=C2=A0=C2=A0= =C2=A0Older decoders MAY choose to abort decoding or skip data encoded with=

=C2=A0=C2=A0=C2=A0newer methods.=C2=A0 Apart from reserved patterns, the= format specifies


I'd suggest "data encoded using methods th= ey do not recognize".=C2=A0


=C2=A0=C2=A0=C2=A0invalid patterns i= n certain places, meaning that the patterns MUST

=C2=A0=C2=A0=C2=A0NOT ap= pear in any valid bitstream, in any prior, present, or future

=C2=A0=C2= =A0=C2=A0versions of the format.=C2=A0 These invalid patterns are usually u= sed to

=C2=A0=C2=A0=C2=A0make the synchronization mechanism more robust.<= /span>


I need some help here, please. I searched the document for occurrence= s of the word "invalid", and found three or four occurrences in t= ables that said something like "this value is invalid", and one o= r two more that said "these values are invalid", in text, not in = tables.=C2=A0


Are those occurrences the patterns that you're refe= rencing in "the patterns MUST NOT appear in any valid bitstream, in an= y prior, present, or future versions of the format"?


In any even= t, it would be helpful to the reader if you had a table that said "the= se are patterns are invalid", and if it makes sense to include a forwa= rd reference to someplace in the document that explains where each pattern = might occur, that would also be helpful.=C2=A0


A separate comment - I= 'd suggest "in any future version of the format". You can'= ;t have a MUST requirement that controls what's happened in the past. I= s this document describing the present version of the format?=C2=A0<= /p>

= =C2=A0=C2=A0=C2=A0All numbers used in a FLAC bitstream MUST be integers, th= ere are no

=C2=A0=C2=A0=C2=A0floating-point representations.=C2=A0 All nu= mbers MUST be big-endian

=C2=A0=C2=A0=C2=A0coded, except the field length= used in Vorbis comments, which MUST be

=C2=A0=C2=A0=C2=A0little-endian c= oded.=C2=A0 All numbers MUST be unsigned except linear

=C2=A0=C2=A0=C2=A0= predictor coefficients, the linear prediction shift and numbers which

=C2= =A0=C2=A0=C2=A0directly represent samples, which MUST be signed.=C2=A0 None= of these

=C2=A0=C2=A0=C2=A0restrictions apply to application metadata bl= ocks or to Vorbis

=C2=A0=C2=A0=C2=A0comment field contents.

These ^= ^^^ MUSTs aren't really MUSTs. They are "MUST, except when". = Does it make sense to have a decoder check for them, and take action when t= hey are violated? Or are these statements of fact ("All numbers will b= e big-endian encoded, except the field length used in Vorbis comments, whic= h will be little-endian coded.")


Also - this is the first occurr= ence of "Vorbis" in the document. Could you add a reference for t= his?


7.=C2=A0 Format lay-out


=C2=A0=C2=A0=C2=A0Since a decoder = MAY start decoding in the middle of a stream, there

=C2=A0=C2=A0=C2=A0M= UST be a method to determine the start of a frame.=C2=A0 A 15-bit sync


=C2= =A0=C2=A0=C2=A0code begins each frame.=C2=A0 The sync code will not appear = anywhere else

=C2=A0=C2=A0=C2=A0in the frame header.=C2=A0 However, since= it MAY appear in the subframes,

=C2=A0=C2=A0=C2=A0the decoder has two ot= her ways of ensuring a correct sync.=C2=A0 The first

=C2=A0=C2=A0=C2=A0i= s to check that the rest of the frame header contains no invalid

=

= =C2=A0= =C2=A0=C2=A0data.=C2=A0 Even this is not foolproof since valid header patte= rns can

=C2=A0=C2=A0=C2=A0still occur within the subframes.=C2=A0 The dec= oder's final check is to

=C2=A0=C2=A0=C2=A0generate an 8-bit CRC of t= he frame header and compare this to the CRC

=C2=A0=C2=A0=C2=A0stored at = the end of the frame header.


=C2=A0=C2=A0=C2=A0Also, since a decoder = MAY start decoding at an arbitrary frame in the

=C2=A0=C2=A0=C2=A0stream,= each frame header MUST contain some basic information about

=C2=A0=C2=A0= =C2=A0the stream because the decoder MAY not have access to the STREAMINFO<= /span>


Same suggestion as before - these are statements of fact. I'd sug= gest "In order to allow a decoder to start decoding at an arbitrary fr= ame in the stream, each frame header contains some basic information about = the stream, in the event that the decoder does not have access to the STREA= MINFO metadata block at the start of the stream."


=C2=A0=C2=A0= =C2=A0metadata block at the start of the stream.=C2=A0 This information inc= ludes

=C2=A0=C2=A0=C2=A0sample rate, bits per sample, number of channels,= etc.=C2=A0 Since the

=C2=A0=C2=A0=C2=A0frame header is pure overhead, it= has a direct effect on the

=C2=A0=C2=A0=C2=A0compression ratio.=C2=A0 To= keep the frame header as small as possible,

=C2=A0=C2=A0=C2=A0FLAC uses = lookup tables for the most commonly used values for frame

=C2=A0=C2=A0= =C2=A0properties.=C2=A0 When a certain property has a value that is not cov= ered

=C2=A0=C2=A0=C2=A0by the lookup table, the decoder is directed to fi= nd the value of

=C2=A0=C2=A0=C2=A0that property (for example the sample r= ate) at the end of the frame

=C2=A0=C2=A0=C2=A0header or in the streaminf= o metadata block.=C2=A0 In case a frame header

=C2=A0=C2=A0=C2=A0refers t= o the streaminfo metadata block, the file is not

=C2=A0=C2=A0=C2=A0's= treamable', see section format subset (#format-subset) for details.

= =C2=A0=C2=A0=C2=A0In this way, the file is streamable and the frame header = size small

=C2=A0=C2=A0=C2=A0for all of the most common forms of audio da= ta.


8.=C2=A0 Format subset


=C2=A0=C2=A0=C2=A0*=C2=A0 The sample= rate bits (#sample-rate-bits) in the frame header MUST

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0be 0b0001-0b1110, i.e. the frame header MUST NOT refer= to the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0streaminfo metadata block to = find the sample rate.

=C2=A0=C2=A0=C2=A0*=C2=A0 The bits depth bits (#bit= -depth-bits) in the frame header MUST be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A00b001-0b111, i.e. the frame header MUST NOT refer to the

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0streaminfo metadata block to find the bit depth.=


On these two bullets ^^^^, is "to find" the best wording? = I wonder if these bullets should say "to describe" instead.=C2=A0=


9.2.=C2=A0 Streaminfo


=C2=A0=C2=A0=C2=A0The minimum block size= is excluding the last block of a FLAC file,

=C2=A0=C2=A0=C2=A0which may = be smaller.=C2=A0 If the minimum block size is equal to the

=C2=A0=C2=A0= =C2=A0maximum block size, the file contains a fixed block size stream.

= =C2=A0=C2=A0=C2=A0Note that in case of a stream with a variable block size,= the actual

=C2=A0=C2=A0=C2=A0maximum block size MAY be smaller than the = maximum block size listed

=C2=A0=C2=A0=C2=A0in the streaminfo block, and = the actual smallest block size excluding

=C2=A0=C2=A0=C2=A0the last block= MAY be larger than the minimum block size listed in

=C2=A0=C2=A0=C2=A0t= he streaminfo block.=C2=A0 This is because the encoder has to write these

=C2=A0=C2=A0=C2=A0fields before receiving any input audio data, and cannot= know

=C2=A0=C2=A0=C2=A0beforehand what block sizes it will use, only bet= ween what bounds

=C2=A0=C2=A0=C2=A0these will be chosen.


^^^^ This = explanation seems important enough to make it clearer. If I understand corr= ectly, these aren't "minimum and maximum block sizes", they&#= 39;re "minimum and maximum block size bounds". Would it be useful= , and not excessively painful, to make that terminology change?

<= br>

=C2= =A0=C2=A0=C2=A0The MD5 signature is made by performing an MD5 transformatio= n on the

=C2=A0=C2=A0=C2=A0samples of all channels interleaved, represent= ed in signed, little-

=C2=A0=C2=A0=C2=A0endian form.=C2=A0 This interleav= ing is on a per-sample basis, so for a

=C2=A0=C2=A0=C2=A0stereo file this= means first the first sample of the first channel,

=C2=A0=C2=A0=C2=A0t= hen the first sample of the second channel, then the second sample

=C2=A0= =C2=A0=C2=A0of the first channel etc.=C2=A0 Before performing the MD5 trans= formation,


This text ^^^^ is accurate, but I can't understand it = without reading it out loud, with appropriate pauses. Would a picture of th= e samples being interleaved before the MD5 transformation help?=C2=A0


=C2=A0=C2=A0=C2=A0all samples must be byte-aligned.=C2=A0 So, in case the = bit depth is not a

=C2=A0=C2=A0=C2=A0whole number of bytes, additional ze= ro bits are inserted at the most-

=C2=A0=C2=A0=C2=A0significant position = until each sample representation is a whole

=C2=A0=C2=A0=C2=A0number of = bytes.


9.4.=C2=A0 Application


=C2=A0=C2=A0=C2=A0The application= metadata block is for use by third-party

=C2=A0=C2=A0=C2=A0applications.= =C2=A0 The only mandatory field is a 32-bit identifier, much

=C2=A0=C2=A0= =C2=A0like a FourCC but not restricted to ASCII characters.=C2=A0 An ID reg= istry


"FourCC" isn't defined in the document, but is th= ere a reference that you could include?=C2=A0


=C2=A0=C2=A0=C2=A0is be= ing maintained at https://xiph.or= g/flac/id.html

=C2=A0=C2=A0=C2=A0(https://xiph.org/flac/id.html).


9.6.=C2=A0 Vorbis comment<= /span>


=C2=A0=C2=A0=C2=A0Note that the Vorbis comment as used in Vorbis allo= ws for on the

=C2=A0=C2=A0=C2=A0order of 2^64 bytes of data whereas the F= LAC metadata block is

=C2=A0=C2=A0=C2=A0limited to 2^24 bytes.=C2=A0 Give= n the stated purpose of Vorbis comments,

=C2=A0=C2=A0=C2=A0i.e. human-rea= dable textual information, this limit is unlikely to be


My suggestion= would be "the FLAC metadata limit is unlikely to be restrictive"= .


=C2=A0=C2=A0=C2=A0restrictive.=C2=A0 Also note that the 32-bit fiel= d lengths are coded

=C2=A0=C2=A0=C2=A0little-endian, as opposed to the us= ual big-endian coding of fixed-

=C2=A0=C2=A0=C2=A0length integers in the = rest of the FLAC format.


9.6.2.=C2=A0 Channel mask


=C2=A0=C2=A0= =C2=A0Besides fields containing information about the work itself, one

= =C2=A0=C2=A0=C2=A0field is defined for technical reasons, of which the fiel= d name is

=C2=A0=C2=A0=C2=A0WAVEFORMATEXTENSIBLE_CHANNEL_MASK.=C2=A0 This= field contains information

=C2=A0=C2=A0=C2=A0on which channels the file = contains.=C2=A0 Use of this field is

=C2=A0=C2=A0=C2=A0RECOMMENDED in cas= e these differ from the channels defined in the

=C2=A0=C2=A0=C2=A0section= channels bits (#channels-bits).


I have a question here - if this fie= ld doesn't match the section channel bits, which one is assumed to be c= orrect? I would have guessed that if the channel mask is present, it is ass= umed to be correct, but I am guessing.=C2=A0


9.7.=C2=A0 Cuesheet


=C2=A0=C2=A0=C2=A0right-padded with NUL characters.=C2=A0 = For CD-DA, this is a thirteen

=C2=A0=C2=A0=C2=A0digit number, followed by= 115 NUL bytes.


Why is this ^^^^ a SHOULD? Is this for legacy support= , or support of incorrect implementations, or something else?

9.7.1.= =C2=A0 Cuesheet track


=C2=A0=C2=A0=C2=A0A track number of 0 is not al= lowed to avoid conflicting with the CD-


I would suggest "is not= allowed, because the CD-DA spec reserves this for the lead-in".


=C2=A0=C2=A0=C2=A0DA spec, which reserves this for the lead-in.=C2=A0 For = CD-DA the number

=C2=A0=C2=A0=C2=A0MUST be 1-99, or 170 for the lead-out;= for non-CD-DA, the track

=C2=A0=C2=A0=C2=A0number MUST be 255 for the le= ad-out.=C2=A0 It is RECOMMENDED to start with

=C2=A0=C2=A0=C2=A0track 1 a= nd increase sequentially.=C2=A0 Track numbers MUST be unique

=C2=A0=C2=A0= =C2=A0within a cuesheet.


9.8.=C2=A0 Picture


=C2=A0=C2=A0=C2=A0T= he following table contains all defined picture types.=C2=A0 Values other

=C2=A0=C2=A0=C2=A0than those listed in the table are reserved and SHOULD N= OT be used.


If values other than those listed in the table are used, = what if anything should the decoder do? Is there a MUST requirement that a = decoder must check for the SHOULD NOT values, and handle them appropriately= , or simply not crash?


=C2=A0=C2=A0=C2=A0There MAY only be one each o= f picture type 1 and 2 in a file.=C2=A0 In

=C2=A0=C2=A0=C2=A0general pr= actice, many FLAC playback devices and software display the

=C2=A0=C2=A0= =C2=A0contents of a picture metadata block with picture type 3 (front

=C2= =A0=C2=A0=C2=A0cover) during playback, if present.


10.1.2.=C2=A0 Samp= le rate bits


=C2=A0=C2=A0=C2=A0The next 4 bits, referred to as the sa= mple rate bits, contain the

=C2=A0=C2=A0=C2=A0sample rate of the audio ac= cording to the following table.=C2=A0 In case

=C2=A0=C2=A0=C2=A0the sampl= e rate bits code for an uncommon sample rate, this is stored

=C2=A0=C2=A0= =C2=A0after the uncommon block size or after the coded number in case no


Nit: I'd suggest "if no uncommon block size was used". I = see other occurrences of "in case" in the document, so I'll a= sk that you look at those occurrences as well.=C2=A0


=C2=A0=C2=A0= =C2=A0uncommon block size was used.=C2=A0 See section uncommon sample rate<= /span>

10.1.3.=C2=A0 Channels b= its


=C2=A0=C2=A0=C2=A0The next 4 bits (the first 4 bits of the fourth= byte of each frame),


"(the first 4 bits of the fourth byte of e= ach frame)" seems very helpful. Would it make sense to add this guidan= ce at the beginning of each of the sections that begin with "the next = 4 bits"?


=C2=A0=C2=A0=C2=A0referred to as the channels bits, cod= e for both the number of

=C2=A0=C2=A0=C2=A0channels of the audio as well = as any stereo decorrelation used

=C2=A0=C2=A0=C2=A0according to the follo= wing table.


10.1.4.=C2=A0 Bit depth bits


=C2=A0=C2=A0=C2=A0The = next 3 bits code for the bit depth of the audio according to the

=

= =C2=A0= =C2=A0=C2=A0following table.


Is this saying "The next 3 bits enc= ode the bit depth"?


10.2.2.=C2=A0 Wasted bits per sample<= /p>

= =C2=A0=C2=A0=C2=A0The wasted bits-per-sample flag in a subframe header is s= et to 1 if a

=C2=A0=C2=A0=C2=A0certain number of least-significant bits o= f all samples in the


I'm confused - what is the "certain num= ber"? Is this (I'm guessing) a number that might vary between audi= o file types?


=C2=A0=C2=A0=C2=A0current subframe are zero.=C2=A0 If t= his is the case, the number of wasted

=C2=A0=C2=A0=C2=A0bits-per-sample (= k) minus 1 follows the flag in an unary encoding.

=C2=A0=C2=A0=C2=A0For e= xample, if k is 3, 0b001 follows.=C2=A0 If k =3D 0, the wasted bits-=

=C2= =A0=C2=A0=C2=A0per-sample flag is 0 and no unary coded k follows.

=C2= =A0=C2=A0=C2=A0In case k is not equal to 0, samples are coded ignoring k le= ast-

=C2=A0=C2=A0=C2=A0significant bits.=C2=A0 For example, if the preced= ing frame header

=C2=A0=C2=A0=C2=A0specified a sample size of 16 bits per= sample and k is 3, samples in

=C2=A0=C2=A0=C2=A0the subframe are coded a= s 13 bits per sample.=C2=A0 A decoder MUST add k

=C2=A0=C2=A0=C2=A0least-= significant zero bits by shifting left (padding) after decoding

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:"Courier New";color:rgb(= 0,0,0);background-color:transparent;font-variant-numeric:normal;font-varian= t-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2= =A0=C2=A0a subframe sample.=C2=A0 In case the frame has left/side, right/si= de or

=C2=A0=C2=A0=C2=A0mid/side stereo, padding MUST happen to a sample = before it is used to


Is this "a decoder MUST perform padding bef= ore constructing a left or right sample"?


=C2=A0=C2=A0=C2=A0reco= nstruct a left or right sample.


10.2.5.=C2=A0 Fixed predictor subfram= e


=C2=A0=C2=A0=C2=A0As a predictor makes use of samples preceding the= sample that is

=C2=A0=C2=A0=C2=A0predicted, it can only be used when eno= ugh such samples are known.


I'd suggest "enough samples"= ; here.


=C2=A0=C2=A0=C2=A0As each subframe in FLAC is coded completel= y independent, the first


I'd suggest "coded completely indep= endently".=C2=A0


=C2=A0=C2=A0=C2=A0few samples in each subframe = cannot be predicted.=C2=A0 Therefore, a

=C2=A0=C2=A0=C2=A0number of so-ca= lled warm-up samples equal to the predictor order is

=C2=A0=C2=A0=C2=A0s= tored.=C2=A0 These are stored unencoded, bypassing the predictor and=

=C2= =A0=C2=A0=C2=A0residual coding stage.=C2=A0 See section on Constant subfram= e (#constant-

=C2=A0=C2=A0=C2=A0subframe) on how samples are stored unenc= oded.=C2=A0 The table below

=C2=A0=C2=A0=C2=A0defines how a fixed predict= or subframe appears in the bitstream.


=C2=A0=C2=A0=C2=A0To encode a s= ignal with a fixed predictor, each sample has the

=C2=A0=C2=A0=C2=A0corre= sponding prediction subtracted and sent to the residual coder.

=C2=A0=C2= =A0=C2=A0To decode a signal with a fixed predictor, first the residual has = to

=C2=A0=C2=A0=C2=A0be decoded, after which for each sample the predicti= on can be added.


I'd suggest "the residual is decoded, and t= hen the prediction can be added for each sample".=C2=A0


=

= I have t= he same comment about Section 10.2.6 below.


=C2=A0=C2=A0=C2=A0This me= ans that decoding MUST be a sequential process within a

=C2=A0=C2=A0=C2= =A0subframe, as for each sample, enough fully decoded previous samples

= =C2=A0=C2=A0=C2=A0are needed to calculate the prediction.


10.2.7.3.= =C2=A0 Residual sample value limit


=C2=A0=C2=A0=C2=A0All residual sam= ples values MUST be representable in the range

=C2=A0=C2=A0=C2=A0offered = by a 32-bit integer, signed one's complement.=C2=A0 Equivalently,

=C2= =A0=C2=A0=C2=A0all residual sample values MUST fall in the range offered by= a 32-bit

=C2=A0=C2=A0=C2=A0integer signed two's complement excluding= the most negative possible

=C2=A0=C2=A0=C2=A0value of that range.=C2=A0 = This means residual sample values MUST NOT have

=C2=A0=C2=A0=C2=A0an abso= lute value equal to or larger then 2 to the power 31.=C2=A0 A FLAC

I&= #39;d suggest "equal to, or larger than, 2 to the power 31". You = might also say "larger than 2 ** 31" here, I think.=C2=A0<= /p>

= =C2=A0=C2=A0=C2=A0encoder MUST make sure of this.=C2=A0 In case a FLAC enco= der is, for a

=C2=A0=C2=A0=C2=A0certain subframe, unable to find a suitab= le predictor of which all

=C2=A0=C2=A0=C2=A0residual samples fall within = said range, it MUST default to writing a

=C2=A0=C2=A0=C2=A0verbatim subfr= ame.=C2=A0 The appendix numerical considerations

=C2=A0=C2=A0=C2=A0(#nume= rical-considerations) explains in which circumstances residual

=C2=A0=C2= =A0=C2=A0samples are already implicitly representable in said range and thu= s

=C2=A0=C2=A0=C2=A0an additional check is not needed.


10.3.=C2=A0 = Frame footer


=C2=A0=C2=A0=C2=A0Following the last subframe is the fra= me footer.=C2=A0 If the last

=C2=A0=C2=A0=C2=A0subframe is not byte align= ed (i.e. the bits required to store all

=C2=A0=C2=A0=C2=A0subframes put t= ogether are not divisible by 8), zero bits are added

=C2=A0=C2=A0=C2=A0u= ntil byte alignment is reached.=C2=A0 Following this is a 16-bit CRC,


^^^^ I think this is "Following the last subframe is the frame footer= .=C2=A0 If the last subframe is not byte aligned (i.e. the number of bits r= equired to store all subframes put together is not divisible by 8), zero bi= ts are added until byte alignment is reached."


=C2=A0=C2=A0=C2= =A0initialized with 0, with polynomial x^16 + x^15 + x^2 + x^0.=C2=A0 This<= /span>

=C2=A0=C2=A0=C2=A0sync code.


11.1.=C2=A0 Ogg mapping


=C2=A0=C2=A0=C2=A0In case an audio stream is encoded where audio proper= ties (sample

=C2=A0=C2=A0=C2=A0rate, number of channels or bit depth) cha= nge at some point in the

=C2=A0=C2=A0=C2=A0stream, this should be dealt w= ith by finishing encoding of the

=C2=A0=C2=A0=C2=A0current Ogg stream and= starting a new Ogg stream concatenated to the

=C2=A0=C2=A0=C2=A0previous= one.=C2=A0 This is called chaining in Ogg. See the Ogg

=C2=A0=C2=A0=C2= =A0specification for details.


I know you provided a reference for Ogg= on first use, but suggest repeating it here, for the less careful readers.= =C2=A0


11.3.=C2=A0 ISO Base Media File Format (MP4) mapping

=C2= =A0=C2=A0=C2=A0The full encapsulation definition of FLAC audio in MP4 files= was

=C2=A0=C2=A0=C2=A0deemed too extensive to include in this document.= =C2=A0 A definition

=C2=A0=C2=A0=C2=A0document can be found at

=

= =C2=A0= =C2=A0=C2=A0https://github.com/xiph/flac/blob/master/doc/isoflac.txt

=C2=A0= =C2=A0=C2=A0(https://github.com/xiph/flac/blob/master/doc/isoflac.txt) This


This might be clearer if it said "The definitions document is sum= marized here."


=C2=A0=C2=A0=C2=A0document is summarized here.


13.=C2=A0 Security Considerations


=C2=A0=C2=A0=C2=A0Implementatio= ns of the FLAC codec need to take appropriate security

=C2=A0=C2=A0=C2=A0= considerations into account.=C2=A0 Those related to denial of service are

=C2=A0=C2=A0=C2=A0outlined in Section 2.1 of [RFC4732].=C2=A0 It is extrem= ely important for

=C2=A0=C2=A0=C2=A0the decoder to be robust against mali= cious payloads.=C2=A0 Malicious

=C2=A0=C2=A0=C2=A0payloads MUST NOT cause= the decoder to overrun its allocated memory

=C2=A0=C2=A0=C2=A0or to take= an excessive amount of resources to decode.=C2=A0 An overrun in

=

I un= derstand the use of the word "malicious" here, but would it be co= rrect to say "payloads that do not conform to this specification MUST = NOT cause ..."? It seems that the problem is that the payload might ca= use unsuspicious implementations to misbehave, from a security perspective,= not that the payload is **intended** to cause unsuspicious implementations= to misbehave.=C2=A0


=C2=A0=C2=A0=C2=A0allocated memory could lead to= arbitrary code execution by an

=C2=A0=C2=A0=C2=A0attacker.=C2=A0 The sam= e applies to the encoder, even though problems in

=C2=A0=C2=A0=C2=A0encod= ers are typically rarer.=C2=A0 Malicious audio streams MUST NOT cause

=C2= =A0=C2=A0=C2=A0the encoder to misbehave because this would allow an attacke= r to

=C2=A0=C2=A0=C2=A0attack transcoding gateways.


=C2=A0=C2=A0= =C2=A0As with all compression algorithms, both encoding and decoding can

= =C2=A0=C2=A0=C2=A0produce an output much larger than the input.=C2=A0 In ca= se of decoding,

=C2=A0=C2=A0=C2=A0the most extreme possible case of this = is a frame with eight constant

=C2=A0=C2=A0=C2=A0subframes of block size = 65535 and coding for 32-bit PCM.=C2=A0 This frame

=C2=A0=C2=A0=C2=A0is on= ly 49 byte in size, but codes for more than 2 megabyte of

=C2=A0=C2=A0= =C2=A0uncompressed PCM data.=C2=A0 For encoding, it is possible to have an = even

=C2=A0=C2=A0=C2=A0larger size increase, although such behavior is ge= nerally considered

=C2=A0=C2=A0=C2=A0faulty.=C2=A0 This happens if the en= coder chooses a rice parameter that

=C2=A0=C2=A0=C2=A0does not fit with t= he residual that has to be encoded.=C2=A0 In such a

=C2=A0=C2=A0=C2=A0c= ase, very long unary coded symbols can appear, in the most extreme

=C2=A0= =C2=A0=C2=A0case more than 4 gigabyte per sample.=C2=A0 It is RECOMMENDED d= ecoder and


"RECOMMENDED" is a BCP14 synonym for "SHOUL= D". Are there any reasons that decoder and encoder implementations oug= ht not take these precautions? If not, I'd suggest MUST, but this might= be better as "Decoder and encoder implementors are advised to take pr= ecautions".


=C2=A0=C2=A0=C2=A0encoder implementations take preca= utions to prevent excessive

=C2=A0=C2=A0=C2=A0resource utilization in suc= h cases.


=C2=A0=C2=A0=C2=A0When metadata is handled, it is RECOMMENDE= D to either thoroughly test

=C2=A0=C2=A0=C2=A0handling of extreme cases o= r impose reasonable limits beyond the


Again, is there a reason why im= plementors ought not to do these things? If not, I'd suggest MUST, or a= lternatively "implementors are advised", as in the previous comme= nt.=C2=A0


=C2=A0=C2=A0=C2=A0limits of this specification document.=C2= =A0 For example, a single Vorbis

=C2=A0=C2=A0=C2=A0comment metadata block= can contain millions of valid fields.=C2=A0 It is

=C2=A0=C2=A0=C2=A0unli= kely such a limit is ever reached except in a potentially

=C2=A0=C2=A0= =C2=A0malicious file.=C2=A0 Likewise the media type and description of a pi= cture

=C2=A0=C2=A0=C2=A0metadata block can be millions of characters long= , despite there

=C2=A0=C2=A0=C2=A0being no reasonable use of such content= s.=C2=A0 One possible use case for

=C2=A0=C2=A0=C2=A0very long character = strings is in lyrics, which can be stored in

=C2=A0=C2=A0=C2=A0Vorbis com= ment metadata block fields.


=C2=A0=C2=A0=C2=A0Various kinds of metada= ta blocks contain length fields or fields

=C2=A0=C2=A0=C2=A0counts.=C2=A0= While reading a block following these lengths or counts, a

=C2=A0=C2=A0= =C2=A0decoder MUST make sure higher-level lengths or counts (most

=C2=A0= =C2=A0=C2=A0importantly the length field of the metadata block itself) are = not

=C2=A0=C2=A0=C2=A0exceeded.=C2=A0 As some of these length fields code= string lengths, memory

=C2=A0=C2=A0=C2=A0for which must be allocated, it= is RECOMMENDED to first verify that


Again, is there a reason impleme= ntations ought not to do this? If not, I'd suggest MUST, or alternative= ly, "implementors are advised".


=C2=A0=C2=A0=C2=A0block is = valid before allocating memory based on its contents.


=C2=A0=C2=A0= =C2=A0Seeking in a FLAC stream that is not in a container relies on the

= =C2=A0=C2=A0=C2=A0coded number in frame headers and optionally a seektable = metadata

=C2=A0=C2=A0=C2=A0block.=C2=A0 It is RECOMMENDED to employ thoro= ugh sanity checks on whether


Again, same comment about RECOMMENDED he= re.=C2=A0


=C2=A0=C2=A0=C2=A0a found coded number or seekpoint is at a= ll possible.=C2=A0 Without these

=C2=A0=C2=A0=C2=A0checks, seeking might = get stuck in an infinite loop when numbers in

=C2=A0=C2=A0=C2=A0frames ar= e non-consecutive or otherwise invalid, which could be used

=C2=A0=C2=A0= =C2=A0in denial of service attacks.


=C2=A0=C2=A0=C2=A0It is RECOMMEND= ED to employ fuzz testing combined with different


Again, same comment= about RECOMMENDED here.


=C2=A0=C2=A0=C2=A0sanitizers on FLAC decoder= s to find security problems.=C2=A0 To improve

=C2=A0=C2=A0=C2=A0efficienc= y of this process, a decoder SHOULD, on decoding, ignore the


=

= Again, s= ame comment about SHOULD here.=C2=A0


=C2=A0=C2=A0=C2=A0results of CRC= checks during fuzz testing.


=C2=A0=C2=A0=C2=A0See the FLAC decoder t= estbench (https://wiki.hydrogenaud= .io/

=C2=A0=C2=A0=C2=A0index.php?title=3DFLAC_decoder_testbench) for = a non-exhaustive list of

=C2=A0=C2=A0=C2=A0FLAC files with extreme config= urations which lead to crashes or

=C2=A0=C2=A0=C2=A0reboots on some known= implementations.


=C2=A0=C2=A0=C2=A0None of the content carried in FL= AC is intended to be executable.


Is this a requirement that decoders = MUST NOT execute it?


14.=C2=A0 IANA Considerations


14.1.=C2=A0 = Media type registration


=C2=A0=C2=A0=C2=A0The following information s= erves as the registration form for the

=C2=A0=C2=A0=C2=A0"audio/flac= " media type.=C2=A0 This media type is applicable for FLAC

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:"Courier New";color:rgb(= 0,0,0);background-color:transparent;font-variant-numeric:normal;font-varian= t-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2= =A0=C2=A0audio packaged in its native container.=C2=A0 FLAC audio packaged = in

=C2=A0=C2=A0=C2=A0another container will take on the media type of its= container, for

=C2=A0=C2=A0=C2=A0example audio/ogg when packaged in an O= gg container or video/mp4 when

=C2=A0=C2=A0=C2=A0packaged in a MP4 contai= ner alongside a video track.


=C2=A0=C2=A0=C2=A0Type name: audio

=C2= =A0=C2=A0=C2=A0Subtype name: flac

=C2=A0=C2=A0=C2=A0Required parameters: = none

=C2=A0=C2=A0=C2=A0Optional parameters: none

=C2=A0=C2=A0=C2=A0Enco= ding considerations: as per this document

=C2=A0=C2=A0=C2=A0Security cons= iderations: see section 12

=C2=A0=C2=A0=C2=A0Interoperability considerati= ons: no known concerns

=C2=A0=C2=A0=C2=A0Published specification: THISRFC=

=C2=A0=C2=A0=C2=A0Applications that use this media type: ffmpeg, apache,= firefox

=C2=A0=C2=A0=C2=A0Fragment identifier considerations: none

=C2= =A0=C2=A0=C2=A0Additional information:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Depr= ecated alias names for this type: audio/x-flac

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Magic number(s): fLaC

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0File extension(= s): flac

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Macintosh file type code(s): none<= /span>

=C2=A0=C2=A0=C2=A0Intended usage: COMMON

=C2=A0= =C2=A0=C2=A0Restrictions on usage: N/A

=C2=A0=C2=A0=C2=A0Author: IETF CEL= LAR WG

=C2=A0=C2=A0=C2=A0Change controller: IESG

=C2=A0=C2=A0=C2=A0Prov= isional registration? (standards tree only): NO


15.=C2=A0 Normative= References


=C2=A0=C2=A0=C2=A0[I-D.ietf-cellar-matroska]

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Con= tainer Format Specifications", Work in Progress,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Internet-= Draft, draft-ietf-cellar-matroska-14, 1 October

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02022, <https://www.ietf.= org/archive/id/draft-ietf-cellar-

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0matroska-14.txt>.


=C2=A0=C2=A0=C2=A0[RFC2119]=C2=A0 Bradner, S., "Key words for use i= n RFCs to Indicate

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Requirement Levels", BCP 14, RFC 2119,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0DOI 10.17487/RFC2119, March 1997,

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<https://www.rfc-editor.org/info/rfc21= 19>.


=C2=A0=C2=A0=C2=A0[RFC4732]=C2=A0 Handley, M., Ed., Resco= rla, E., Ed., and IAB, "Internet

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Denial-of-Service Consid= erations", RFC 4732,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0DOI 10.17487/RFC4732, December 2006,=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0<https:/= /www.rfc-editor.org/info/rfc4732>.


=C2=A0=C2=A0=C2=A0[RFC8174]= =C2=A0 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A02119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

=

= =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0May 2017, <https:= //www.rfc-editor.org/info/rfc8174>.


16.=C2=A0 Informative Refe= rences


=C2=A0=C2=A0=C2=A0[HPL-1999-144]

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Hans, M. and RW. S= chafer, "Lossless Compression of Digital

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Audio", DOI 1= 0.1109/79.939834, November 1999,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<https://www.hpl.hp.com/techreports/1999/HPL-=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A01999-144.pdf>.


=C2=A0=C2=A0=C2=A0[IEC.60908.1999= ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0International Electrotechnical Commission, "Audio

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0recording - Compact disc digital audio system",

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IEC= International standard 60908 second edition, 1999.


=C2=A0=C2=A0=C2= =A0[ISRC-handbook]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"International Standard Recording Code (= ISRC) Handbook,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A04th edition", 2021, <https://www.ifpi.org/isrc_handbook/>.


=C2=A0=C2=A0=C2=A0[RFC3533]=C2=A0 Pfeiffer, S., "The Ogg Encapsul= ation Format Version 0",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC 3533, DOI 10.17487/RFC3533, M= ay 2003,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0<https://www.rfc-editor.org/info/rfc3533>.


=C2=A0=C2=A0=C2=A0= [RFC5334]=C2=A0 Goncalves, I., Pfeiffer, S., and C. Montgomery, "Ogg M= edia

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Types", RFC 5334, DOI 10.17487/RFC5334, September 20= 08,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0<http= s://www.rfc-editor.org/info/rfc5334>.


=C2=A0=C2=A0=C2=A0[RFC67= 16]=C2=A0 Valin, JM., Vos, K., and T. Terriberry, "Definition of the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,<= /p>

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0September 2012, <https://www.rfc-editor.org/info/rfc6716>.


=C2=A0=C2=A0=C2= =A0[RFC7942]=C2=A0 Sheffer, Y. and A. Farrel, "Improving Awareness of = Running

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Code: The Implementation Status Section", BCP 205= ,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0RFC 7942, DOI 10.17487/RFC7942, July 2016,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= ;https://www.rfc-editor= .org/info/rfc7942>.


=C2=A0=C2=A0=C2=A0[robinson-tr156]<= /p>

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Robinson, T., "SHORTEN: Simple lossless and near-lossless=

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0waveform compression", December 1994,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<https://mi.eng.cam.ac.uk/repor= ts/abstracts/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0robinson_tr156.html>.

--000000000000480d7705f5a56f73--