Defining CPU threads / using presets / order of switches ?

[hiccup2]

Hi guys, thanks for this tool!

Not being very savvy with command line stuff etc., I still got it to work to a certain level.
But there are two things I haven't been able to figure out by myself:

I am using the 'custom' switch. (Win10)

1. I tried to set a higher amount of CPU thread usage to speed things up a bit, but I can't get that to work. It seems to use no more than 4 threads whatever I try.
   edit:
   It's even worse, in Task Manager it looked like 4 threads were active, but taking a better look shows they are alternating, so it's only 2 threads active at the same time.

2. To solve the Opus problem, a preset file can be used. I couldn't get that to work either.

Are these features perhaps only available for the 'easy' switch, and not for the 'custom' one?

3. When trying to get things to work, I got the impression that the order of switches is important? Sometimes it would fail at first, but after changing the order of some switches it would then work. Is the order of switches important indeed?

TIA!

[complexlogic]

You are correct that multithreaded and presets are easy mode only features. I generally recommend the 'easy' interface over 'custom', especially for new users, unless you need the flexibility of 'custom' for some reason.

The only order that matters is the command/mode type, e.g. rsgain easy or rsgain custom. After that, the options/switches can be defined in any order you want.

[hiccup2]

Thanks for the fast reply complexlogic.

Yes, for my purpose (making it available as a tool in MusicBee) I need to use 'custom'.
'Easy' seems unusable in that case. (related to the fact that 'easy' only works on folders for as far as I understand)

Would you consider making multithreaded and presets available for 'custom'?
(In a general sense I would expect a 'custom' feature having more options and possibilities than an 'easy' option. Not less?)

[complexlogic]

making it available as a tool in MusicBee

Thanks for the context. In that case, yes, you will definitely need to use the Custom Mode.

Currently the multithreaded logic uses folders instead of files, which is advantageous when a large amount of music needs to be scanned. This is why multithreaded is only available in Easy Mode. Perhaps I will consider a file-based multithreaded mode in the future for Custom Mode.

A better option would be to multithread the processes outside of rsgain. I'm not familiar with the MusicBee plugins, but generally when scripting you can run multiple processes in parallel. I recommend checking out the MusicBrainz Picard plugin code for rsgain, which includes multithreading by default. Although rsgain custom mode doesn't have built-in support for multithreading, the plugin will start multiple parallel processes of it so it's mulithreaded anyway.

In regard to the presets, it is true that they aren't available in Custom Mode, but you don't need them. The presets are merely a convenience wrapper around the Custom Mode options. You previously mentioned Opus handling, just use the -o option. Run rsgain custom -h for a comprehensive list of options.

[hiccup2]

I'm not a coder, and I am not capable of writing actual plugins.
In this case for MusicBee, it has a function that you can send selected files to an external tool that is able to process those files.
And you can add required parameters for such an external tool. So for rsgain, all I can do is use parameters that are available for 'custom'.

So a parameter for multithreaded would be nice (since rsgain is not performing that great on only 2 threads), and a parameter that allows for Opus files to be processed at -5LU would also be nice, since they are currently playing too loud after being processed by rsgain.

edit:
B.t.w., Picard also returns too high loudness levels for Opus files.

[complexlogic]

The Picard plugin writes -18 LUFS by default, but there is an option to write the -23 LUFS instead. I'll consider your above feedback for a future release.

[hiccup2]

"The Picard plugin writes -18 LUFS by default, but there is an option to write the -23 LUFS instead."

That looks like a global setting, so Picard will always process Opus files louder than other file types.
Ah well, that's something for them to raise/solve.

'll consider your above feedback for a future release."

Great. I hope my requests are sensible and can/will be implemented.
Thanks a lot.