[Flac-dev] Feed decoder from c++ std::stream

[Ben Allison]

Bas -

Have you considered changing the design of your program?  I've worked on a
lot of large multi-codec commercial and consumer applications and I can
attest that FLAC is *not* the only codec or file format API to work in
this kind of manner.  Really, any sort of container-based format, e.g.
MP4, is going to potentially need to make many (potentially random
access!) reads before it can even give you one frame of data back.  In
fact, i think you're going to find that even simple stream-based codecs
like MP3 or ADTS AAC are going to suffer from the same problem as they
have no a priori way of knowing frame sizes without reading at least a few
bytes of header information.  And even if the codec library you use it
designed to "overread" to avoid doing small reads just for the header to
determine size, you still can potentially have times where a read might
not return a decoded audio frame because of data errors in the input, etc.

And no, FLAC is not dead.  The core C library has been stable for quite
some time, so there just hasn't been the need to make changes.  And it's
nearly impossible to make significant improvements in the compression
ratio without sacrificing backwards compatibility with existing versions
of libFLAC (and compatibility with software and devices that have
integrated it).

-Ben Allison

> Well, unless somebody has a brilliant idea, I am giving up on this. I
> don't see how I can do what I wanted to. The slightly hacky way I thought
> would work, was by guaranteeing the read_callback could read at least
> enough data to make process_single() return (ie the buffer should contain
> at least 1 frame or block). But it seems that even when the maximum frame
> size is known, that can never be guaranteed (probably due to sync errors).
> The only solution I can think of is an API change such as proposed here:
> http://sourceforge.net/tracker/?func=detail&aid=2922254&group_id=13478&atid=363478
>
> In the meantime, my program will have slightly limited FLAC capabilities
> and use a separate code path when flac decoding is requested.
>
> PS.: What is the status of the project by the way? I know FLAC is very
> widely supported, and I generally really like the library and the format,
> but the current version is old, and if I'm not mistaken the CVS hasn;t
> been touched in years. Please tell me the project isn't dead.
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>