> - As far as I am aware (yes, I'm fishing for correction here) .mp3 uses
> a strongly predictive coding scheme. I.e. the encoding of a given part
> of the signal depends on what has gone before it. As a result there is
yep.
> no "naive" way you can cut and paste seperately encoded chunks without
> and audible "click". To succeed you'd have to overlap
> the encoded chunks enough to ensure encoding becomes insignificantly
> different across the chunk boundary. I have no idea how far this
> might be but with luck it might only be each "major" frame.
well if you check the web page, i tried 'naively' cutting and pasting them
and it works to some extent. I have experiemented with overlapping and
cutting frames, but I still get some noticeable artifacts. Even with 15
overlapping frames. This 'artifact' is usually a burst of high pitched
sound. I think it may have something to do with the bit reservoir, or
misaligned overlapping buffers from frame to frame.
I'll update the bit on parallelization when i get the chance.
One thing we might think of doing is adapting the ISO code a little to
make this overlap-and-stitch idea more feasible. For example, add a
switch which forces the bit reservoir to not be used for the first 4 and
final 4 frames. The same goes for window_switching. This may help...
> - An alternative might be to split at a much finer grain. E.g. Streaming
> the various stages of signal procesing along a pipeline rather than by
> parameter passing and splitting the DCT buckets between threads. The
> "patch" would leave only fragments of the dist10 code unchanged, but
> really, who cares...
I know almost nothing of real parallel programming. multiple threads and
dependencies and all that stuff just goes over my head. I'm a serial
processing sort of guy :)
later
mike
