On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote: > it actually is complicated. the libFLAC api is not suited to a > multithreaded design because the i/o is stream-based, not file- > based. flac(.exe) is the file-based wrapper around libFLAC that > allows it to work on files. the way libFLAC buffers data is also > impossible to parallelize without significantly changing the api.
It seems like buffering (especially compressed) blocks and writing them to the stream in sequence wouldn't be a problem. Is there something in the way the blocking decisions are made that makes it hard to divide the input audio this way? -r _______________________________________________ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
