INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Priority setting for Lame encoder  (Read 1994 times)

GHammer

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1930
  • Stereotypes are a real timesaver!
Priority setting for Lame encoder
« 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.
Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: Priority setting for Lame encoder
« Reply #1 on: November 25, 2005, 05:04:37 am »

--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
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

GHammer

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1930
  • Stereotypes are a real timesaver!
Re: Priority setting for Lame encoder
« Reply #2 on: November 25, 2005, 08:06:02 am »

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.
Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: Priority setting for Lame encoder
« Reply #3 on: November 25, 2005, 09:08:58 am »

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).
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

GHammer

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1930
  • Stereotypes are a real timesaver!
Re: Priority setting for Lame encoder
« Reply #4 on: November 25, 2005, 09:31:25 am »

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
Logged

GHammer

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1930
  • Stereotypes are a real timesaver!
Re: Priority setting for Lame encoder
« Reply #5 on: December 17, 2005, 06:34:28 am »

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.

Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: Priority setting for Lame encoder
« Reply #6 on: December 17, 2005, 10:10:18 am »

I can confirm that the option works fine on XP.

lame --longhelp:
Quote
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
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755
Pages: [1]   Go Up