Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC RFC update (Read 1491 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC RFC update

Some of you may know that the FLAC format is in the process of being formally specified by the IETF as a so-called RFC. 17 months ago I shared here that the working group considered the document finished and issued a working group last call. This resulted in a lot of comments and subsequently improvements. After that, the document was read and commented on by various IETF people, which took a while.

Today I got the message that the document has been formally approved. The announcement is here. This means the people in charge (the Internet Engineering Steering Group or IESG) have read the document, suggested changes and finally approved the document. Yay!

However, FLAC isn't described by an official RFC just yet. The current draft will be sent to the RFC Production Center, where an editor will review the document and adjust tone, spelling and grammar for it to read like any other RFC. Looking at the current queue (where Matroska, the ".mkv" container format, is too!) this will probably take a few months up to maybe half a year.

So, I just wanted to share that news with you all. It is not really big news or anything, but I am glad all the technical stuff has been agreed upon and approved.
Music: sounds arranged such that they construct feelings.

Re: FLAC RFC update

Reply #1 –
That's great to hear ktf  :)

Re: FLAC RFC update

Reply #2 –
Great news!  Thank you and all members of the work group :)
.halverhahn

Re: FLAC RFC update

Reply #3 –
@ktf, what does it mean for the rest of us?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: FLAC RFC update

Reply #4 –
Joining the choir here!

If I am to speculate about the reasons for FLAC's success, I have a hunch that it was not only about being the right FOSS at the right time, but also an openly available specification.

Re: FLAC RFC update

Reply #5 –
Quote from: Kraeved on
@ktf, what does it mean for the rest of us?

That depends on who and what you are.

As @cid42 mentioned in the previous thread, it makes coding a fresh, independent FLAC decoder a whole lot easier. The document also contains a lot of helpful insights that might make new implementations more compatible. The accompanying test files make validation of a new implementation much easier. So, the direct benefits are for implementers.

For users, this implies an indirect benefit: better implentations to use.

For long term storage (archiving institutions) it is reassurance that the format won't fade into oblivion at some point, because it is specified in a rather official, open, free-access document that can be copied and even stored alongside the content, and is not defined solely by its implementations (that might only work on ancient, fragile hardware at some point) or some expensive spec that nobody buys and thus could be inaccessible in the future.
Music: sounds arranged such that they construct feelings.

Re: FLAC RFC update

Reply #6 –
To follow-up on that, IETF guards their published RFCs - warts'n'all! - to the extent that even if typos are discovered, there is quite some process to even get a "verified" stamp on the "uh-oh": https://www.rfc-editor.org/errata_search.php?eid=1579 . 
To the outside world, that is a safety net against hurried changes - like, whatever consequences might otherwise incur by way of a (brain)fart from Elon Musk sniffing a new weed strain. Or another unpublished version of the dreaded ".doc format". Not saying that anyone in the power to do that to the FLAC spec would do so - but by RFC status you can take the IETF's word that any changes will go through a thorough process. Not merely relying on some developer's word for it.


I do have a kinda "formalistic" follow-up question, the IETF has evolved over the years:
FLAC is not infrastructure in the same way as a transfer protocol is, so ... where does the IETF's "scope of interest" in FLAC end? At files/streams (to be) served over the internet?
(Surely a private archive might appreciate several of the same objectives as users of an online archive, but that is not my question.)

Re: FLAC RFC update

Reply #7 –
Quote from: Porcus on
I do have a kinda "formalistic" follow-up question, the IETF has evolved over the years:
FLAC is not infrastructure in the same way as a transfer protocol is, so ... where does the IETF's "scope of interest" in FLAC end? At files/streams (to be) served over the internet?
(Surely a private archive might appreciate several of the same objectives as users of an online archive, but that is not my question.)
Since flac is the most sold lossless format out there the IETF may want to guarantee customers can use their purchase in the future without much knowledge like transcoding.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC RFC update

Reply #8 –
Quote from: Porcus on
where does the IETF's "scope of interest" in FLAC end? At files/streams (to be) served over the internet?
The IETF consists of working groups. Each working group has a charter which defines the scope. The charter of the CELLAR working group is here. As you can see, the charter is not related to the internet at all. I don't know how the working group came to be, because it was formed in 2015 and I only joined in 2021.
Music: sounds arranged such that they construct feelings.

Re: FLAC RFC update

Reply #9 –
Clicking myself from that document up, I think I found pretty much the answer:
Codecs are specifically mentioned within the scope of the "Applications and Real-Time Area", which the CELLAR working group belongs to.
It doesn't exactly say who was responsible for wording the scope that way, but the Area Directors are the Internet Engineering Steering Group members.
And, the IESG itself is responsible for what drafts are going on the "Standards track" - thus apparently: for what works are "on-topic" for the "Standards" status.

Re: FLAC RFC update

Reply #10 –
Will IETF start cranking out FLAC variants of the software?
EZ CD Audio Converter / FLAC or WavPack

Re: FLAC RFC update

Reply #11 –
No ... IETF doesn't write mail server software, though they specify the standards for e-mail.
(Oh my how many mail servers violate those!)

Re: FLAC RFC update

Reply #12 –
Ok.
EZ CD Audio Converter / FLAC or WavPack