Re: [Cellar] Éric Vyncke's No Objection on draft-ietf-cellar-flac-12: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Martijn,

I guess that we won’t find a suitable sentence to describe the bitmask. So, let it be, it is not really important, just an eyebrow raiser.

Regards

-éric

From: Martijn van Beurden <[e-mail]>
Date: Monday, 9 October 2023 at 19:49
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-cellar-flac-12: (with COMMENT)
Bonsoir Éric,

Thanks for replying quickly, and considering my answers and questions.

I have attempted to address your comments here:
https://github.com/ietf-wg-cellar/flac-specification/pull/233
Specifically, considering the channel mask, I've split the line up:

> The channel mask consists of flag bits indicating which channels are present. [...] This mask is stored with a hexadecimal representation, preceded by 0x, see the examples below.

Considering the Vorbis reference, there is already an informative
reference labeled "Vorbis". I agree that [Vorbis] isn't clearly a
reference, but that is the way the xml2rfc tool renders it.

Considering the document not specifying metadata field names, I
understand this can be considered hand waving. The problem I have here
is this particular kind of metadata is highly dependent on content.
While the common title/artist/album fits most music use cases, FLAC
can be used for a lot more things. The cellar working group
specifically targets archival of audio in general, which can include
broadcasts, (unedited) recordings and samples. There are even people
using FLAC to compress measurement data that is in no way related to
audio. In those use cases, field names meant for music are unusable.
That is why I think defining standard metadata field names wouldn't
work, no field name is universal and no set will ever be complete.

Kind regards,

Martijn van Beurden

Op ma 9 okt 2023 om 17:33 schreef Eric Vyncke (evyncke) <[e-mail]>:
>
> Goed dag Martijn,
>
>
>
> Thanks for your quick reply, see inline for EVY>
>
>
>
> Regards
>
>
>
> MvG
>
>
>
> -éric
>
>
>
>
>
> From: Martijn van Beurden <[e-mail]>
> Date: Monday, 9 October 2023 at 16:58
> To: Eric Vyncke (evyncke) <[e-mail]>
> Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-cellar-flac-12: (with COMMENT)
>
> Op ma 9 okt 2023 om 13:10 schreef Éric Vyncke via Datatracker
> <[e-mail]>:
> >
> > Thanks for the work done on this codec, while I am not a codex person, I find
> > the text interesting and easy to read.
> >
>
> Many thanks for your comments. I have considered them, please review my replies.
>
> >
> > Please write "Hertz" and not "hertz".
> >
>
> It is customary that SI units are not capitalized when written out,
> not even those named after people. See
> https://www.nist.gov/pml/owm/writing-si-metric-system-units
>
> EVY> learned something today, even in Frenchv it should be written as “hertz”... Getting older !
>
>
> >
> > Section 8.2: I do not think that MD5 is a signature, it is a hash.
> >
>
> Yes, you are right. Signature or fingerprint is a term often used in
> audio context, but that would be confusing/incorrect in IETF context.
> Maybe checksum is a better term (as you already suggest for appendix
> D) as the term hash might suggest a security related application.
>
> >
> > Section 8.6, where is the name 'Vorbis' coming from ?
> >
>
> The second sentence of that section explains where the name comes
> from: "The name Vorbis comment points to the fact that the Vorbis
> codec stores such metadata in almost the same way, see [Vorbis]."
> Vorbis is a lossy audio codec.
>
>
>
> EVY> it still does not explain what ‘Vorbis codec’ is, an informative reference would be welcome
>
>
>
>
>
> >
> > Section 8.6.1, should the MusicBrainz be a *normative* reference ?
> >
>
> No, it should not be. The field names are not standardized by design,
> and the MusicBrainz reference is only a suggestion. In practice, many
> implementations do not follow that suggestion.
>
> EVY> hummm I see what you want to say. This is somehow borderline in a standard track IETF document though. Same as for “most FLAC playback devices and software recognize the following field names”, which is also hand waving.
>
> EVY> Anyway, I am trusting the responsible AD, Murray, on this one.
>
>
> >
> > Section 8.6.2, I cannot parse/understand `The channel mask consists of flag
> > bits indicating which channels are present, stored in a hexadecimal
> > representation preceded by 0x.`
> >
>
> I have pondered this and do not see a way to simplify this sentence. I
> do hope the examples later in the section can augment the parsing of
> that sentence.
>
> EVY> the part that puzzles me is “preceded by 0x” here... Should it be easier to remove “stored in a hexadecimal representation preceded by 0x” ?
>
>
> >
> > Section 8.8, please add a normative reference for ID3v2.
> >
>
> Please elaborate. As far as I know, there is no need to read any ID3v2
> related documents to fully implement this standard. ID3v2 is only
> mentioned as the FLAC picture metadata block is more or less copied
> from it. The document however fully specifies that block. In fact,
> this document explains it in greater detail than any ID3v2 document
> I've ever read.
>
> EVY> then I failed to understand how the image format is encoded
>
>
> >
> > Also, I am unsure
> > whether "MiB" and "GiB" are the usual abbreviations in IETF documents.
> >
>
> I did find MiB in RFCs 8452 and 9106; and GiB in RFCs 7146, 7323, 8452
> and 9106. Not exactly common, but there is a precedent.
>
> EVY> ;-)
>
>
> >
> > Section D.2.9, s/ MD5 sum./ MD5 checksum./ ?
> >
>
> Yes, thank you for the suggestion.
>
> >
> > I find also weird that both authors have no affiliation ;-) But, this is OK.
> >
>
> Almost all work on the FLAC reference implementation and a lot of work
> and review of this document has been done by unpaid
> volunteers/hobbyists/enthusiasts.
>
> EV> and THANK you for your time !
>
>
> Kind regards,
>
> Martijn van Beurden