Re: [Cellar] My notes on https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/

[Martijn van Beurden <[e-mail]>]

Once again hi,

You said 'could you update the working group' but I read 'could you update
the draft'.

I've tried to address all comments as best I could and tried to find
similar issues you might have missed. Additionally I've addressed some
issues that were raised by others and some things I found while working on
the draft.

The document has improved quite a bit thanks to your input and I think it
is ready for the next step.

Kind regards, Martijn van Beurden

Op ma 3 apr 2023 om 16:39 schreef Martijn van Beurden <[e-mail]>:

> Hi Spencer,
>
> There were no comments that needed further clarification.
>
> Please note that there are a few changes/improvements in the new draft not
> related to your review. It might be a good idea to look at the diff at some
> point. Especially the extension of the section coded number might be worth
> taking a look at.
>
> Kind regards,
>
> Martijn van Beurden
>
> Op zo 2 apr 2023 om 23:56 schreef Spencer Dawkins at IETF <
> [e-mail]>:
>
>> Hi, Martjin,
>>
>> Could you update the working group on the status of the FLAC draft? Do
>> you think there are additional shepherd comments that you need
>> clarifications on?
>>
>> Best,
>>
>> Spencer
>>
>> On Tue, Feb 28, 2023, 00:15 Spencer Dawkins at IETF <
>> [e-mail]> wrote:
>>
>>> Hi, again,
>>>
>>> On Sun, Feb 26, 2023 at 8:42 PM Spencer Dawkins at IETF <
>>> [e-mail]> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> "Define 'close of business'", but I finished reading through the
>>> appendices, and looked back at the IANA Considerations section.
>>>
>>> I said in my first set of notes that I like the document, and I like it
>>> more, now that I've had time to reflect on it.
>>>
>>> A large number of my comments are about BCP 14 requirements language, so
>>> please don't think of them as a lot of comments. They were really two or
>>> three comments made multiple times:
>>>
>>>    - Whether a BCP 14 keyword was an interoperability requirement or a
>>>    statement of fact,
>>>    - If a MUST is correct, what a decoder should do if it detects that
>>>    the MUST was not satisfied, and
>>>    - If a SHOULD is correct, why it's not a MUST, and what the decoder
>>>    should do if it's not satisfied.
>>>
>>> I really like all the appendices in this document - they were especially
>>> well-written and seemed helpful.
>>>
>>> I should also mention that I noticed one or two things in the Appendices
>>> that made me wonder about what I'd read in the formal specification, so
>>> added comments that should be addressed in the formal specification.
>>>
>>> Please do ask me questions about anything I seem to be getting wrong or
>>> didn't explain clearly, and remember - the working group participants are
>>> the experts on this technology.
>>>
>>> Best,
>>>
>>> Spencer
>>> ------
>>>
>>> 14.  IANA Considerations
>>>
>>> Could I suggest that you add the following text here?
>>>
>>> "In accordance with the procedures set forth in [RFC4288], this document
>>> registers one new media type, "audio/flac", as defined in the following
>>> section."
>>>
>>> And please do add the reference, of course.
>>>
>>> 14.1.  Media type registration
>>>
>>>    The following information serves as the registration form for the
>>>
>>>    "audio/flac" media type.  This media type is applicable for FLAC
>>>
>>>    audio packaged in its native container.  FLAC audio packaged in
>>>
>>>    another container will take on the media type of its container, for
>>>
>>>    example audio/ogg when packaged in an Ogg container or video/mp4 when
>>>
>>>    packaged in a MP4 container alongside a video track.
>>>
>>> I'd suggest putting a blank line after each line below.
>>>
>>>    Type name: audio
>>>
>>>    Subtype name: flac
>>>
>>>    Required parameters: none
>>>
>>>    Optional parameters: none
>>>
>>>    Encoding considerations: as per this document
>>>
>>> I'd suggest saying "as per THISRFC".
>>>
>>>    Security considerations: see section 12
>>>
>>> I'd suggest saying "see the Security Considerations in section of
>>> THISRFC".
>>>
>>>    Interoperability considerations: no known concerns
>>>
>>> I would have guessed you'd say "see the descriptions of past format
>>> changes in Appendix B of THISRFC".
>>>
>>>    Published specification: THISRFC
>>>
>>>    Applications that use this media type: ffmpeg, apache, firefox
>>>
>>>    Fragment identifier considerations: none
>>>
>>>    Additional information:
>>>
>>>      Deprecated alias names for this type: audio/x-flac
>>>
>>>      Magic number(s): fLaC
>>>
>>>      File extension(s): flac
>>>
>>>      Macintosh file type code(s): none
>>>
>>>    Person & email address to contact for further information: IETF
>>> CELLAR WG
>>>
>>>    Intended usage: COMMON
>>>
>>>    Restrictions on usage: N/A
>>>
>>>    Author: IETF CELLAR WG
>>>
>>>    Change controller: IESG
>>>
>>> Best practice for stating the change controller has varied wildly over
>>> time. My suggestion is to provide this as "Internet Engineering Task Force
>>> (mailto:[e-mail])."
>>>
>>>    Provisional registration? (standards tree only): NO
>>>
>>> Appendix A.  Numerical considerations
>>>
>>>    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 MUST be eliminated
>>>
>>>    by using data types large enough to never overflow.
>>>
>>> I have two observations here. First, I think you can say "can be
>>> eliminated" - this is a statement of fact. Beyond that, all of these
>>> appendices say they are non-normative, so BCP 14 language in explicitly
>>> non-normative (parts of) standards track specifications is likely to
>>> confuse both reviewers and implementers who haven't participated in the
>>> working group.
>>>
>>> Second, I'd suggest saying "using data types large enough to never
>>> overflow in practice".
>>>
>>>    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 section will provide guidelines
>>>
>>>    for choosing the right data type in each step of encoding and
>>>
>>>    decoding FLAC files.
>>>
>>> Appendix C.  Interoperability considerations
>>>
>>>    As documented in appendix past format changes (#past-format-changes),
>>>
>>>    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 a subset of FLAC features
>>>
>>>    required for playback of the most common FLAC files.
>>>
>>> I woke up after reading this sentence, and went back looking through the
>>> document for mentions of FLAC "subset". I don't think that's mentioned
>>> before the end of Section 7, and that's a forward reference to Section 8,
>>> which describes this.
>>>
>>> I'd suggest mentioning in both the Abstract and Introduction that this
>>> specification includes the specification for the complete FLAC format, as
>>> well as the FLAC subset. My apologies for the late mention about this!
>>>
>>>    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 finished,
>>>
>>>    consult this web page (https://github.com/ietf-wg-cellar/flac-
>>>
>>>    specification/wiki/Interoperability-considerations) for more up-to-
>>>
>>>    date information.
>>>
>>> C.1.  Non-subset streams
>>>
>>>    As described in section format subset (#format-subset), FLAC
>>>
>>>    specifies a subset of its capabilities as the Subset format.  Certain
>>>
>>>    decoders may choose to only decode FLAC files conforming to the
>>>
>>>    limitations imposed by the Subset.  Therefore, when maximum
>>>
>>>    compatibility with decoders is desired it is RECOMMENDED to stay
>>>
>>>    within the limitations of the FLAC Subset format.
>>>
>>> This last sentence ^^^^ pretty clearly isn't a BCP 14 RECOMMENDED, it's
>>> a statement of fact. I'd recommend replacing it with something like
>>> "Therefore, maximum compatibility with decoders is achieved when FLAC files
>>> are created using the limited FLAC Subset format."
>>>
>>> C.2.  Variable block size
>>>
>>>    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 suffer from bugs when handling variable block size
>>>
>>>    streams or do not decode them at all.
>>>
>>> This ^^^^ might be clearer as "Because of this many decoder
>>> implementations receive minimal use when handling variable block size
>>> streams, and this can reveal bugs, or reveal that the implementations do
>>> not decode them at all."
>>>
>>>    Furthermore, as is explained
>>>
>>>    in section addition of block size strategy flag (#addition-of-block-
>>>
>>>    size-strategy-flag), there have been some changes to the way variable
>>>
>>>    block size streams were encoded.  Because of this, when maximum
>>>
>>>    compatibility with decoders is desired it is RECOMMENDED to only use
>>>
>>>    fixed block size streams.
>>>
>>> Again, this ^^^^ last sentence is a statement of fact. I'd suggest
>>> something like "Therefore, maximum compatibility with decoders is achieved
>>> when FLAC files are created using fixed block size streams."
>>>
>>> C.3.  5-bit Rice parameter
>>>
>>>    As the addition of the 5-bit Rice parameter as described in section
>>>
>>>    addition of 5-bit Rice parameter (#addition-of-5-bit-rice-parameter)
>>>
>>>    was 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 a 5-bit Rice parameters.
>>>
>>>    Therefore, when maximum compatibility with decoders is desired it is
>>>
>>>    RECOMMENDED to not use 5-bit Rice parameters when encoding audio with
>>>
>>>    a bit depth of 16 bits or lower.
>>>
>>> Again, this ^^^^ last sentence is a statement of fact. I'd suggest
>>> something like "Therefore, maximum compatibility with decoders is achieved
>>> when FLAC files are created using 4-bit Rice parameters when encoding audio
>>> with a bit depth of 16 bits or lower."
>>>
>>> C.4.  Rice escape code
>>>
>>>    Escapes Rice partitions are only seldom used as it turned out their
>>>
>>>    use provides only very small compression improvement.  As many
>>>
>>>    encoders therefore do not use these by default or are not capable of
>>>
>>>    producing them at all, it is likely many decoder implementation are
>>>
>>>    not able to decode them correctly.  Therefore, when maximum
>>>
>>>    compatibility with decoders is desired it is RECOMMENDED to not use
>>>
>>>    escaped Rice partitions.
>>>
>>> :-) Same comment.
>>>
>>> "Therefore, maximum compatibility with decoders is achieved when FLAC
>>> files are created without using escaped Rice partitions."
>>>
>>> C.5.  Uncommon block size
>>>
>>>    For unknown reasons some decoders have chosen to support only common
>>>
>>>    block sizes except for the last block.  Therefore, when maximum
>>>
>>>    compatibility with decoders is desired it is RECOMMENDED to only use
>>>
>>>    common block sizes as listed in section block size bits (#block-size-
>>>
>>>    bits) for all but the last block.
>>>
>>> "Therefore, maximum compatibility with decoders is achieved when FLAC
>>> files are created only using common block sizes as listed in section block
>>> size bits (#block-size-bits) for all but the last block."
>>>
>>> C.6.  Uncommon bit depth
>>>
>>>    Most audio is stored in bit depths that are a whole number of bytes,
>>>
>>>    e.g. 8, 16 or 24 bit.  There is however audio with different bit
>>>
>>>    depths.  A few examples:
>>>
>>>    *  DVD-Audio has the possibility to store 20 bit PCM audio
>>>
>>>    *  DAT and DV can store 12 bit PCM audio
>>>
>>>    *  NICAM-728 samples at 14 bit, which is companded to 10 bit
>>>
>>>    *  8-bit µ (U+00B5)-law can be losslessly converted to 14 bit
>>>
>>>       (Linear) PCM
>>>
>>>    *  8-bit A-law can be losslessly converted to 13 bit (Linear) PCM
>>>
>>>    FLAC can store 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.  FLAC
>>>
>>>    will detect these wasted bits.  This transformation leaves no
>>>
>>>    ambiguity in how it can be reversed and is thus lossless.  See
>>>
>>>    section wasted bits per sample (#wasted-bits-per-sample) for details.
>>>
>>>    Therefore, when maximum compatibility with decoders is required, it
>>>
>>>    is RECOMMENDED to pad samples of such audio with zero bits to the bit
>>>
>>>    depth that is the next whole number of bytes.
>>>
>>> "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."
>>>
>>> Appendix D.  Examples
>>>
>>>    This informational appendix contains short example FLAC files which
>>>
>>>    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
>>>
>>>    cursory read the specification
>>>
>>> I had to look it up ^^^^, but "cursorily" is the adverb form of this
>>> word.
>>>
>>>    and that the reader refers to the
>>>
>>>    specification for explanation of the terminology used.  These
>>>
>>>    examples mostly focus on the lay-out of several metadata blocks and
>>>
>>>    subframe types and the implications of certain aspects (for example
>>>
>>>    wasted bits and stereo decorrelation) on this lay-out.
>>>
>>> I wonder if it is helpful to contrast the examples in this Appendix to
>>> the tests in the FLAC decoder testbench that you mention at the end of the
>>> Security Considerations section.
>>>
>>> D.1.3.  Signature and streaminfo
>>>
>>>    Note that anywhere a number of samples is mentioned (block size,
>>>
>>>    total number of samples, sample rate), interchannel samples are
>>>
>>>    meant.
>>>
>>> Is this ^^^^ always the case? I ask because I didn't see this helpful
>>> guidance anywhere in the formal specification. If it's always the case,
>>> this statement should occur at the right place in the formal specification
>>> (I defer to the authors on where the right place is).
>>>
>>> _______________________________________________
>> Cellar mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cellar
>>
>