[Flac-dev] How to handle multiple STREAMINFO blocks?

Lorenzo lornova at gmail.com
Tue Nov 16 02:06:45 PST 2010

In my opinion in a FLAC audio streaming (i.e not in a file,
but something like a web radio) a STREAMINFO should be sent when the
connection is established, and then resent only if at least one of its
fields is changed (e.g when bitrate or block sizes changes).


2010/11/16 Brian Willoughby <brianw at sounds.wa.com>

> It's certainly best to honor what the specification says.  My
> assumption is that a "stream" could also be a continuous broadcast,
> not just a file.  With a hypothetical server streaming FLAC
> bitstreams, I would assume that the most recent STREAMINFO is valid
> until another one comes along.  If you're writing a file player, then
> perhaps you can trust the spec and assume that there will never be
> more than one.  But I suppose it all depends upon which is easier to
> handle in your code.  Some implementations might make it more
> complicated to ignore spurious STREAMINFO blocks.  I'd say do
> whatever is easiest, and bank on files not having more than one anyway.
> Brian Willoughby
> Sound Consulting
> On Nov 16, 2010, at 00:00, Lorenzo wrote:
> > As far as I know one and only one STREAMINFO should be present at
> > the beginning of the file: http://flac.sourceforge.net/format.html
> >
> > "A FLAC bitstream consists of the "fLaC" marker at the beginning of
> > the stream, followed by a mandatory metadata block (called the
> > STREAMINFO block), any number of other metadata blocks, then the
> > audio frames."
> >
> > 2010/11/16 Brian Waters <brianmwaters at gmail.com>
> >> I'm writing a program that plays FLAC files using the libFLAC API's.
> >> Is there a specific way I'm supposed to handle multiple STREAMINFO
> >> metadata blocks?
> >>
> >> For example, should I ignore all but the first, or all but the last?
> >>
> >> The format spec doesn't mention anything.
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20101116/b6eb9c3e/attachment.htm 

More information about the Flac-dev mailing list