Full Version: Mpc & Smp
I just want to know if we could see an "SMP compatible" encoder in near future ??
IMO mppenc is already so fast on a single-processor machine that if you're ripping a CD, it's hard to keep up with it.
But if you're encoding wavefiles on your hard drive, or if you have a really fast CD reader, there's a simple solution: start two encoding sessions!
EAC lets you set how many encoding threads you want, so I set that to two on my SMP machine, and that means if, for some strange reason, EAC finishes ripping a track before mppenc finished compressing the last one, a second mppenc will pop up.
If you have, say, 3GB of wavefiles, just start two sessions of a batch encoder (you may need to make two copies of the program in separate directories if the program is batchfile-based) and put 1.5GB in one encoder, 1.5GB in the other.
These strategies work very well, and they work for any encoder... I do this with vbLamer, RazorLame, PsyTelDrop, and MPCDrop (or whatever those cool programs are called), so it's hard for me to justify the need for an SMP-capable encoder.
But if you're encoding wavefiles on your hard drive, or if you have a really fast CD reader, there's a simple solution: start two encoding sessions!
EAC lets you set how many encoding threads you want, so I set that to two on my SMP machine, and that means if, for some strange reason, EAC finishes ripping a track before mppenc finished compressing the last one, a second mppenc will pop up.
If you have, say, 3GB of wavefiles, just start two sessions of a batch encoder (you may need to make two copies of the program in separate directories if the program is batchfile-based) and put 1.5GB in one encoder, 1.5GB in the other.
These strategies work very well, and they work for any encoder... I do this with vbLamer, RazorLame, PsyTelDrop, and MPCDrop (or whatever those cool programs are called), so it's hard for me to justify the need for an SMP-capable encoder.
Thank you for your solutions, i asked bcoz don't know how to set EAC to launch 2 encoding at same time.
My computer is a bit old & slow in single mode (2 PII 400mhz), but of course i know the Mpc encoding is faster than Lame & ogg.
However, most of the time i rip from the cd.
My computer is a bit old & slow in single mode (2 PII 400mhz), but of course i know the Mpc encoding is faster than Lame & ogg.
However, most of the time i rip from the cd.
I can't quite tell from the text of your post whether you still need to know how to launch multiple encoders from EAC, or if you've already figured it out. But here it is anyway:
1. Start EAC, go to the EAC menu and choose EAC Options... (first choice).
2. Go to the third options tab, Tools.
3. The fifth checkbox asks "On extraction, start external compressors queued in the background". Check this, and then in the field right below it, tell it to use 2 simultaneous external compressor threads.
That's it!
1. Start EAC, go to the EAC menu and choose EAC Options... (first choice).
2. Go to the third options tab, Tools.
3. The fifth checkbox asks "On extraction, start external compressors queued in the background". Check this, and then in the field right below it, tell it to use 2 simultaneous external compressor threads.
That's it!
QUOTE
Originally posted by SometimesWarrior
EAC lets you set how many encoding threads you want, so I set that to two on my SMP machine, and that means if, for some strange reason, EAC finishes ripping a track before mppenc finished compressing the last one, a second mppenc will pop up.
EAC lets you set how many encoding threads you want, so I set that to two on my SMP machine, and that means if, for some strange reason, EAC finishes ripping a track before mppenc finished compressing the last one, a second mppenc will pop up.
Not only does this work well for SMP machines, but this helps speed up the ripping process on my single processor machine. I don't get spectacularly fast rips, usually about 5X, but I get about 12X encoding. Before I switched to this two process setup my machine would rip a track, then sit and wait for the encoding process to finish. Now it starts ripping the next track while the encoding is going on. It means a slight drop in speed for both the encoding and ripping, but it's more than balanced by the simultaneous work now being done. And in the rare event that it opens two encoding threads at once, the overall speed increase still balances things out.
G
QUOTE
Originally posted by gdougherty
And in the rare event that it opens two encoding threads at once, the overall speed increase still balances things out.
I think if you set the box to one simultaneous thread instead of two, it achieves what you want but doesn't ever open two encoders. The important thing to do is make sure the "On extraction, start external compressors queued in the background" box is checked; after that, setting the number of threads just tells EAC the maximum number of encoders you want running at once (the thread count doesn't include EAC itself).
And in the rare event that it opens two encoding threads at once, the overall speed increase still balances things out.
I used that setup for my older (single-processor) machine, and even if I had other stuff processing, causing the encoder to lag well behind the ripper, EAC simply queued up all the encodes needed, so my processor would always be at 100% utilization (unless there was nothing left to encode). At the same time, EAC never stopped ripping. It's really a wonderful tool.
QUOTE
Originally posted by Skymarshal_nico
I just want to know if we could see an \"SMP compatible\" encoder in near future ??
I just want to know if we could see an \"SMP compatible\" encoder in near future ??
"compatible" is a buzz word. Don't use it.
mppenc will very likely never SMP, because
- in the worst case this makes the encoder slower (SMP != faster),
because load balancing is very difficult.
- the program much more difficult, more difficult to tune
- realtime is reached, so there's no need to support SMP
- writting a wrapper which always call 2 or 3 instances of
mppenc is much easier, more flexible and faster.
Hi everybody !
First of all, thank you all !
Especially SometimesWarrior who answers me clearly (im a bit ashamed bcoz the setting was very easy to found;) ) and Frank Klemm who gives me his position about SMP (by the way, maybe i should use "SMP compliant" instead, but my english is not perfect
).
That was my very first post on this forum and it seems to have certain success (more than 230views :eek: ), hope it helped lot of people !
C u all and thank again !
First of all, thank you all !
Especially SometimesWarrior who answers me clearly (im a bit ashamed bcoz the setting was very easy to found;) ) and Frank Klemm who gives me his position about SMP (by the way, maybe i should use "SMP compliant" instead, but my english is not perfect
).
That was my very first post on this forum and it seems to have certain success (more than 230views :eek: ), hope it helped lot of people !
C u all and thank again !
QUOTE
Originally posted by Frank Klemm
\"compatible\" is a buzz word. Don't use it.
mppenc will very likely never SMP, because
- in the worst case this makes the encoder slower (SMP != faster),
because load balancing is very difficult.
- the program much more difficult, more difficult to tune
- realtime is reached, so there's no need to support SMP
- writting a wrapper which always call 2 or 3 instances of
mppenc is much easier, more flexible and faster.
\"compatible\" is a buzz word. Don't use it.
mppenc will very likely never SMP, because
- in the worst case this makes the encoder slower (SMP != faster),
because load balancing is very difficult.
- the program much more difficult, more difficult to tune
- realtime is reached, so there's no need to support SMP
- writting a wrapper which always call 2 or 3 instances of
mppenc is much easier, more flexible and faster.
I'd agree here. What might be more helpful is a batchenc or something that supported multiple encoding threads for those with dual CPU systems converting large sets of wav files into musepack. Disk ripping is already fast enough, and EAC does what's needed with supporting multiple threads during the rip process.
G
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.