Hi! I am working on an application that reads audio data from files, and runs it through some user defined filters. The filters basically all derive from some base filter and have methods start(), update() and finish(). The start routine performs any initialization required by the filter, and finish() does the clean up. In between, I simply read the file piece by piece into a buffer using std::ifstream.read(buffer, bufsize), and then call the filters update function with the buffer and the number of bytes read. In this fashion I have implemented a WAV reader, WAV writer, MD5 summer, AccurateRip checker and a FLAC encoder and hope to implement MP3 and Vorbis encoders and any number of audio filters (gain/compression/etc). However, at the moment I'm stuck trying to write a FLAC decoder. It seems that the FLAC::Decoder module is incompatible with this approach as it insists on taking control of the data it receives through its read callback. Is this correct? Does anyone see any obvious way to do this? I have only come up with one (slightly hacky) way to do this, but it requires to know the maximum frame size of the input file, which as I understand it, need not be set in the STREAMINFO, and has no theoretical maximum. So it works now, because I read the input file in 1MB chunks, and I have not come across a file with larger frames, but it is not guaranteed. Any ideas? I hope that was somewhat clear, I'm finding it difficult to explain. Let me know if you need more clarification or some example code. thanks, Bas Timmer
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.
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 >