Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mr.X]

So now that the new P4/3.06Ghz chip is out that works like 2 CPU's, I wonder whether there will be new interest in Multi-Threaded encoders that can take advantage of this new power. The only one I know of is Gogo, and on a dual-CPU machine, it flies. The problem is that it's not well-supported and it's behind the times with the version of LAME that it uses.

What I'm wondering is if there's any programmers out there who would be willing to take on the project of updating this encoder and having it use the latest LAME engine? The source code is available, (I think in C++) and all it would take is someone with some programming skill, some time, and a willingness to do it. Perhaps some money could be made too, if the product was advertised.

I feel this could become very important as people start purchasing this new CPU and start asking for software that supports SMP.

Anyone up for the challenge?

-Mr.X

[RemyJ]

I started to take a look at it a few months ago from 2 perspectives:   Updating gogo with the latest lame routines, and updating the latest lame for multi-threading.    Neither looked feasable without spending a few weeks solid just winding through the existing code let alone modifying and testing.

I'd have preferred to make lame multi-threading rather than updating gogo but the problem is that the lame library routines all rely on global structures which is a big no-no.  

One big drawback of either approach is that keeping up with the latest lame improvements will be a big pain.

So, I'm holding out for a parallelized encoding process in MJ9 that will allow multiple lame processes to be running at the same time.  At least this way we can continue to use the latest lame distribution unmodified.

[Mr.X]

I'm holding out for a parallelized encoding process in MJ9 that will allow multiple lame processes to be running at the same time.

That sounds like a reasonable alternative.
The only thing that a method like that might exclude is my dream of an MJ encoder plug-in that does gapless encoding. To use the -nogap switch in LAME requires all the tracks of a gapless album to be sent to lame at once. Would it be possible for more than one thread to encode in that case?

I guess even if it couldn't, at least for normal (gapped) encodings, 2 tracks could be encoded at once, one per CPU sort of thing.

Am I understanding your idea correctly?

-Mr.X

[RemyJ]

That sounds like a reasonable alternative.
The only thing that a method like that might exclude is my dream of an MJ encoder plug-in that does gapless encoding. To use the -nogap switch in LAME requires all the tracks of a gapless album to be sent to lame at once. Would it be possible for more than one thread to encode in that case?

-Mr.X

The gapless thing does present a problem.  I think MJ could still implement it but it would be pretty hard to multi-thread without major work to lame.

I guess even if it couldn't, at least for normal (gapped) encodings, 2 tracks could be encoded at once, one per CPU sort of thing.

Am I understanding your idea correctly?

Yep.  Rip as fast as you can and throw the tracks into a queue to be encoded by a pool of lame processes.  You should be able to configure how many to run in parallel.