On Tue, 28 Jan 2003 16:30:10 +0100 (MET)
> ok sounds logical, thanks for your reply :-)
> I will make last try on the http://lame.sourceforge.net/tech-FAQ.txt
> and lines describing "a possible" way of splicing. Even if som
> redundant encoding has to be done , it may give some speedup.
> -------- CUT FROM FAQ ---------------
> 2. Use VBR and overlapping encodes. For example:
> stream A = encode frames 0-99
> stream B = encode frames 97-200
For this question you better ask the lame development mailinglist
For those at lame-dev: Here's his original mail:
I have a weird question , sorry if I disturb you :-)
But I searched for "parell mp3 encode" and saw your posts in
I'm having a mad idea of encoding one mp3 in several pieces and then
"merge" them into one mp3.
I've done (with a few friends) a little Tasklet engine for pararell
problems using P2P, its simply tail-recursion over a LAN with 1-256
workstations connection running java. http://aortas.sourceforge.net
, its really simple to write a Tasklet , just implent 3 methods split(),merge() , calculate()
they can of course make calls to native c , or shell commands.
The nice thing is that its a kind of "lazy" pararelzing,, (how to
spell that?) ,, A Tasklet splits itself in two and delegates work to
an awaiting workers , this is done recersivly and thus there is no
need to make the "split" at the first moment.
The idea with a encodeTasklet would be that alla instances in the net
hass access to the same complete "song.wav" , and encodes parts of it
and finally when all pieces are finished they are merged. A net of
10 computers would give aprox 10 times speedup. which is fun!!! Since
java is used as "transport" it will be slow if parts are to small.
but lets say divide a song into 10-100 parts , is useful.
(The VBR thing, is it dealing with 1
second or like 10 secounds? , maybee the separatly encoded pieces
could be "merged" just like different VBR "chunks"). I dont know much
about mp3 encode , as you can see :-)
I answered that for a song (A->C) which is split into A->B + B->C you
need to know some things from the encoding of the end of A->B to be able
to start the encoding of B->C.
So just using the existing lame executable with the above mentioned
framework is out of the question.
The dark ages were caused by the Y1K problem.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7