On 28-Sep-99 Scott Manley wrote:
> WEll... dual channel stereo modes might be trivially paralelisable....
> Dunno about anything else.
> Scott Manley (aka Szyzyg) /------ _@/ Mail -----\
>> By the way, it would be a great idea to make LAME being able to run
>> on all processors of SMP system. But, I guess, such an idea would
>> require the rewriting of the code from scratch. I don't think Mark
>> would be excited with this idea ;)
I spent a little bit of time with the old mp3enc from Fhg trying to work
out a method for parallelizing which *wasn't* about parallelizing the code
itself (obviously i don't have the fhg code to look at :).
See www.uq.net.au/~zzmcheng for a short discussion on what i tried.
Basically it is:
1.Split up the file to be encoded into N parts (where N is the number
of processes you want to run)
2.Encode these files with your mp3 encoder of choice (simply run N copies
of the encoder)
3.Join the N mp3 files back together.
It mostly works. Mp3 players are smart enough to resync on small errors and so
you can simply "cat" two mp3's together and they'll play back.
The main troubles
- the bit reservoir would need to be unused at the end of each part.
- various buffers would need to be sync'd with the previous part, which
means each part would depend on the previous part. sort of defeating the
purpose a little. e.g. if you split the file in two parts, to encode the
second part you'd have to start filling the buffers with data to make sure the
mdct/window/fft/etc buffers were in sync with the end of the first part.
it may be a matter of just starting the second encode a multiple of the
syncsize or frame size after the first encode.
Summary:
this method works but puts an audible click in the mp3 file (which i
presume to be because of mis-synced buffers).
later
mike
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
