On Tue, May 6, 2008 at 2:39 PM, Brian Willoughby <[EMAIL PROTECTED]> wrote: > > I may be biased because I work with hour-long recordings, but it seems like > the block size would be small compared to the overall file size. In other > words, if you break the encoded file into equal-sized regions, then have > each thread scan its region for the first block header, then it might be > close enough to equal to work. Then again, the output region sizes could > vary greatly, especially if the input dynamics are vastly different from > region to region.
Of course, I don't know what I was thinking; that should work fine. I think I tried something like that in a hackish way but incorrectly dismissed it as I couldn't get it to work and got frustrated, which is almost certainly something I did wrong :) If the output regions do vary significantly, that could be detected and compensated for since we'd know the frame numbers. > I'm also assuming that scanning the entire compressed file for block > offsets would take a while, but again that's probably because I work with > files on the order of a gigabyte in size. Obviously, more people work with > "song" sized FLAC files, but you should at least consider what will happen > with your algorithm when it is presented with a gigabyte of data. Sure, but I intended for the scanning to happen in parallel with the decoding so it would be ok. Of course, the point is moot given that your solution above should work fine. I don't think I've ever worked with a gigabyte-long FLAC file, but I usually work with CD-length FLAC files so rest assured I'm thinking about larger-than-song-sized files. :) -- Frederick Akalin http://www.akalin.cx _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
