[Flac-dev] Proof-of-concept multithreaded FLAC encoder

[Frederick Akalin]

On Tue, May 6, 2008 at 2:39 PM, Brian Willoughby <brianw at sounds.wa.com> 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