Re: [Cellar] purpose of FLAC RFC --- vs xiph.org

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

Op do 19 okt 2023 om 20:22 schreef Michael Richardson <[e-mail]>:
>
>
> Roman, in his AD review, asks why we did not take over the xiph.org
> ID registry at: https://xiph.org/flac/id.html
>
> Well.  I thought it was because while we are detailing FLAC in a Matroska
> container in sufficient detail in an RFC, appropriate for use in archiving,
> we were not intending to take over maintenance of FLAC itself.
> (For instance, you can also put FLAC into an OGG container, or an MP4 container)
>
> https://xiph.org/flac/format.html actually seems to disagree with me though.
>

I maintain the FLAC project and website currently, so I've added those
pointers to the draft, as I think it is much more thorough.

>
> * community FLAC might continue to evolve
> * the archival/RFC version might be a useful subset of what's possible
>

People can always try something new with it, which could lead to
divergence, as with any format. However, as you said before, whether
or not a standard is one to take seriously is dependent on how many
people actually follow it. I could write a new document describing
backwards-incompatible changes to MP3, but no one would seriously
consider that, given MP3's widespread use. Sure, FLAC is not as
popular as MP3, but there is quite a lot of hardware/software support.

As I see it, there have been no forces trying to change the FLAC
format since 2007 except this working group. During the working group
last call, I've notified the Xiph IRC and got quite a bit of response,
all helpful, not a single comment opposing this. I've contacted Josh
Coalson, the original author, who was very happy with this document
and spotted a few mistakes. I've contacted hydrogenaud.io, a large
active community with a lot of developers, and once again no
opposition. For the changes that have been made to the format, I've
submitted patches to ffmpeg and merged patches for libFLAC, and found
no ill will.

All in all, I don't think Xiph really claims any 'ownership'. Also,
the FLAC format has seen pretty much no evolution since 2007, and I
don't think there is reason to assume it will see some in the future.
Especially since there is already a lot of hardware out there
supporting FLAC as it is today. Also, not all features described in
the spec are at all used, so there still is room for improvement
without changing the spec.

> Maybe I'm wrong, and the FLAC community wants the RFC to be the basis for all
> future work.  In which case, taking over that application ID table would be
> appropriate.  But, there are then other IANA tables that we need:
> * Table 2
> * Table 8
> * Table 13
>

I don't think those need an IANA registry. To me, it would make more
sense to have those tables updated with a new RFC if the need would
ever arise, because there are much more things in the spec that would
be needed for future expansion besides those tables.

For example, consider that someone would want to extend FLAC to be
able to carry floating point data. You might need a new metadata block
type for that (table 2) but you would also need to use one of the
reserved bits in the frame header to be able to extend the frame
header with new data. Maybe for such an extension one would need to
work out a whole new kind of subframes. But then again, such an
extension would not make sense, because of the widespread support FLAC
has as it is now.

Also, considering table 8: that table has been around for 20 years and
I haven't ever seen anyone wanting to add something to it. Adding
anything would also make the FLAC spec deviate from the ID3v2 spec it
was derived from.

Kind regards,

Martijn van Beurden