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

[Lorenzo]

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).

Lorenzo

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