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 > [email protected] > http://lists.xiph.org/mailman/listinfo/flac-dev > _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
