INTERACT FORUM
More => Old Versions => Media Center 11 (Development Ended) => Topic started by: GHammer on November 24, 2005, 11:43:42 pm
-
Here's some feedback on the laster build regarding syncing to my iPod Nano:
3. It would also be great if there were an option to set the priority of the LAME encoder processes that are spawned. Since syncing a full 4 GB to my iPod takes quite a few hours (due to the conversion time), the default priority of these processes makes other processes run a lot slower.
Use this setting in MC for your transfers:
--priority 1 -q 0 --vbr-new -V 1 --noreplaygain
You can adjust the quality and type to suit your needs of course.
The noreplaygain simply saves a bit of time, since I don't use LAME's replaygain.
-
--priority 1 -q 0 --vbr-new -V 1 --noreplaygain
Hmm... Not quite.
--priority n is only for OS/2, thus redundant.
-q 0 is the slowest quality switch. It's considered experimental and has not been proven to be better than the default (without any -q n switch), only slower.
I don't think it's possible to change the encoder priority with LAME switches. Some encoder frontends like Razorlame have thread priority options. Those options change the process priority in a similar way you can do it in the Windows Task Manager.
In my opinion such a priority switch should be added to MC. I've mentioned this previously here: http://yabb.jriver.com/interact/index.php?topic=28073.0
-
Hmm... Not quite.
--priority n is only for OS/2, thus redundant.
Yes, that's what the switches doc says.
Ever tried it and watched the CPU activity on your XP system?
The Beatles - Abbey Road - Golden Slumber
From APL to MP3
-q 0 -V1 --vbr-new
10 seconds at 100% CPU
--priority 1 -q 0 -V1 --vbr-new
11 seconds at 34% CPU
As for the other switches, I think I said adjust to suit needs. Works fine for me, but then, I'm not abx-ing multiple samples.
I'm just listening.
-
Yes, that's what the switches doc says.
Ever tried it and watched the CPU activity on your XP system?
The Beatles - Abbey Road - Golden Slumber
From APL to MP3
-q 0 -V1 --vbr-new
10 seconds at 100% CPU
--priority 1 -q 0 -V1 --vbr-new
11 seconds at 34% CPU
Very interesting. If it really works on XP it would make things much better. Actually, JRiver could easily add a tick box for the --priority switch.
When it comes to "-q 0" I suppose you don't use the default LAME version. In LAME 3.96.1 the "-q 0" switch is buggy. It makes encoding extremely slow, much slower than with the earlier versions. This bug is fixed in the v. 3.97b1 (which is the currently recommended version at HA).
-
Very interesting. If it really works on XP it would make things much better. Actually, JRiver could easily add a tick box for the --priority switch.
When it comes to "-q 0" I suppose you don't use the default LAME version. In LAME 3.96.1 the "-q 0" switch is buggy. It makes encoding extremely slow, much slower than with the earlier versions. This bug is fixed in the v. 3.97b1 (which is the currently recommended version at HA).
Well, if it didn't work, I wouldn't have the CPU figures. No dual core, no multi threading here. Just a plain vanilla P4 in a generic box.
As for version, no, I do not use 3.96.1
I use 3.98 a2 Just seems better (for the music I listen to) than 3.97b1
-
So, JRiver, how about adding a selection to enable this priority ability?
Cuts down on CPU usage by a great deal and has no ill effects.
Very useful especially now that MC will spawn more than one process.
-
I can confirm that the option works fine on XP.
lame --longhelp:
MS-Windows-specific options:
--priority <type> sets the process priority:
0,1 = Low priority (IDLE_PRIORITY_CLASS)
2 = normal priority (NORMAL_PRIORITY_CLASS, default)
3,4 = High priority (HIGH_PRIORITY_CLASS))
Note: Calling '--priority' without a parameter will select priority 0.
It would a good option for mass conversions. Just a tick box is needed in the MP3 encoding options.
For example:
Unticked:
--preset fast medium
Ticked:
--preset fast medium --priority