Hello,

Is there an overview - in plain English - summarizing the API changes? I 
realize that the github page linked below has the actual code changes, but I 
was hoping for a design overview. I do see comments and discussion, but did not 
readily find any overview. If I missed something, please help me find it.

Without diving in to the source changes, my first question is: Would it be 
possible to leave the existing API as it is, but only add new functions for 
continuous stream decoding? If only new function names are used, then existing 
code will not have to change or be recompiled.

Of course, a deeper question is whether the existing API was already designed 
for continuous (chained) streaming, in which case the changes are more to fix 
bugs or design flaws in the original. I seem to recall that FLAC always 
intended to support continuous streams, but since I never worked with that 
feature I have no idea how well it was implemented, nor whether there were any 
bugs.

Questions such as the above are why I was hoping for an overview. It would be 
nice to see a brief summary of what the original API was (probably) intended to 
support; whether we have changed our expectations or merely found flaws in the 
original design; and what sorts of changes were necessary, and why. It would be 
especially helpful if there was already discussion of the pros and cons of 
adding new functions for the new support, versus altering the API of existing 
functions to enhance existing support to broader use cases.

As always, it's entirely possible that I'm missing something critical, so I 
offer the above as a way to start the conversation - at least for this mailing 
list. Admittedly, I've long been curious how metadata would be handled in a 
continuous stream, such as a 24/7 radio station, but have never looked into the 
details.

Brian

p.s. Are we talking about changes to the .flac file format in any way? ... or 
is this all about changing the streaming input (not file-based input) handling 
to support chained streams?


On Sep 1, 2024, at 12:44 PM, Martijn van Beurden wrote:
> Hi all,
> 
> As some of you may know, the Ogg container is allowed to be 'chained',
> meaning Ogg files or streams can simply be concatenated into a single
> file or stream. This is something the vorbis and opus tools have
> supported for some time, but FLAC hasn't.
> 
> Anyway, there are a few internet radio stations using chained Ogg FLAC
> streams, and I was for a few years getting requests (and some
> rudimentary implementations) to get this implemented. I've taken this
> up the past few weeks and the result is quite a large change to the
> current code base and some API changes.
> 
> Everything works, but as is with any change to the API, I don't know
> whether it is convenient for API users other than the flac command
> line tool. So, I'd like some feedback.
> 
> Proposal is here: https://github.com/xiph/flac/pull/735
> 
> Kind regards, Martijn van Beurden

_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Reply via email to