Compressor in v2.1.1 throws error when run as Chain script

[jimmyhosen]

XP, v2.1.1, .exe installer

Hello,
I would like help figuring out how to use custom parameters with the standard Compressor. I really liked how the standard lookahead Compressor worked with custom parameters (via chain script) in v2.0.6, but now it does not work that way in v2.1.1. (I normally went into the App Data folder and manually modified the scripts using Notepad++.) None of my old chains from v2.0.6 containing the standard Compressor work anymore.

Any advice on how I could make this work in v2.1.1?

Unfortunately, the new Audacity v2.1.1 throws the following error:

Could not update effect "Compressor" with:
Compressor: Threshold=-26.4 NoiseFloor=-56.4 Ratio=1.19 AttackTime=0.004 ReleaseTime=1.024 Normalize=yes UsePeak=no

Apparently, v2.1.1 does not accept custom values, such as Ratio. (v2.0.6 seemed to work fine with custom parameters.) To test this, I went and made a brand new Compressor chain in v2.1.1, then inspected its code. I discovered that the order of the Compressor parameters has now changed. I hoped that the issue was merely the order and the addition of quotation marks around the parameter values. Unfortunately, putting things in order & quotes did not help:

Could not update effect "Compressor" with:
Compressor:AttackTime="0.004" NoiseFloor="-56.4" Normalize="1" Ratio="1.19" ReleaseTime="1.024" Threshold="-26.4" UsePeak="0"

Just to be sure, I even tried it with all the extra zeros, but that also failed:

Could not update effect "Compressor" with:
Compressor:AttackTime="0.004000000000" NoiseFloor="-56.400000000000" Normalize="1" Ratio="1.190000000000" ReleaseTime="1.024000000000" Threshold="-26.400000000000" UsePeak="0"

Also, unfortunately, with the change to no longer accept custom parameters, we are stuck with an insufficient list of parameter values from which to choose:

1. There is only one Ratio available that is less than 2:1 (1.5:1). My main work is doing fine adjustments to Spoken Word, which frequently requires a ratio of less than 2:1. I need specific ratios at least down to the tenth (x.0), preferably the hundredth for ratios < 2.
2. The current list of Ratios is still linear (multiples of 0.5), which makes no practical sense. It really should be in powers of 2, because that is how "nature" operates. Ratio = 2^(b/c). "c" should probably be 4 or 8 (but probably 8). Better yet, I would like text fields into which to type numbers. Anyway, please see my spreadsheet for a couple ideas of what I think are better lists of Ratios: https://docs.google.com/spreadsheets/d/ ... eM/pubhtml
3. Attack and Release times are too long. I need Attack at least down to 4 milliseconds, and Release down to 500 milliseconds. Unfortunately, the shortest available times are 100 milliseconds and 1000 milliseconds, respectively.

If necessary, I am interested in learning how to write code to make a new Compressor based upon the standard one, but with better parameter capabilities. I really like the standard Compressor, so I am disappointed that I might not be able to use it anymore, unless I revert to v2.0.6. Anyone have any advice on how to go about learning?

[Gale Andrews]

XP, v2.1.1, .exe installer

I would like help figuring out how to use custom parameters with the standard Compressor. I really liked how the standard lookahead Compressor worked with custom parameters (via chain script) in v2.0.6, but now it does not work that way in v2.1.1. (I normally went into the App Data folder and manually modified the scripts using Notepad++.) None of my old chains from v2.0.6 containing the standard Compressor work anymore.

With values that are in range, I can use a Compressor Chain created in 2.0.6 in 2.1.1, in spite of the different syntax and rounding levels in the Chain files. And in 2.1.1 I can overwrite that 2.0.6 Chain with the new syntax by using "Edit Parameters" for the Compressor in "Edit Chains".

Generally, there should still be Chain compatibility between 2.0.6 and 2.1.1 for built-in effects. Chains containing LADSPA and VST effects may not be compatible between 2.0.6 and 2.1.1 due to the addition of Real Time Preview to those effect classes.

Could not update effect "Compressor" with:
Compressor:AttackTime="0.004000000000" NoiseFloor="-56.400000000000" Normalize="1" Ratio="1.190000000000" ReleaseTime="1.024000000000" Threshold="-26.400000000000" UsePeak="0"

If you are using parameters outside those allowed by the effect, for example a ratio of 1.19, I agree that produces the "Could not update effect "Compressor" with" error. We do have strict validation of effect input now, which is most visible to users in effects that let you enter values in text boxes.

If you wanted to change this yourself, I think you would have to change these minima and maxima in /src/effects/Compressor.cpp in the source code, then recompile Audacity.

Code: Select all

// Define keys, defaults, minimums, and maximums for the effect parameters
//
//     Name          Type     Key                  Def      Min      Max      Scale
Param( Threshold,    double,  XO("Threshold"),     -12.0,   -60.0,   -1.0,    1   );
Param( NoiseFloor,   double,  XO("NoiseFloor"),    -40.0,   -80.0,   -20.0,   5   );
Param( Ratio,        double,  XO("Ratio"),         2.0,     1.5,     10.0,    2   );
Param( AttackTime,   double,  XO("AttackTime"),    0.2,     0.1,     5.0,     100 );
Param( ReleaseTime,  double,  XO("ReleaseTime"),   1.0,     1.0,     30.0,    10  );
Param( Normalize,    bool,    XO("Normalize"),     true,    false,   true,    1   );
Param( UsePeak,      bool,    XO("UsePeak"),       false,   false,   true,    1   );

The current list of Ratios is still linear (multiples of 0.5), which makes no practical sense. It really should be in powers of 2, because that is how "nature" operates. Ratio = 2^(b/c). "c" should probably be 4 or 8 (but probably 8). Better yet, I would like text fields into which to type numbers.

With text fields you would see validation errors for values that were outside the minima/maxima when running Compressor from the Effect menu.

I'll note your suggestion about text box input for Compressor (I agree, personally).

By editing the Chain text files you can enter finer ratios that are in range, such as "1.600000000000", but I'll leave others to comment further on your other point.

Gale

[jimmyhosen]

Gale, thank you so much for replying.

You mentioned I could make some modifications to Audacity, then recompile it. Thank you for pointing out the section of code containing the parameter limits. I assume these links are the best place...
http://wiki.audacityteam.org/wiki/Developer_Guide
http://wiki.audacityteam.org/wiki/Developing_On_Windows

I have never "compiled" a program. I am concerned about the time necessary for the learning curve. I have a little bit of other programming experience (JavaScript, GAS, spreadsheets). Any guesses on how much time this could take? Weeks? Months?

Also, I am curious to learn more about making my own effect plugins, but would I actually be able to use my own effects in Chain Scripts? This is important to me. I thought there was a limitation on that.

Finally, I added quite a lot to that spreadsheet of ideas for the built-in lookahead "Compressor". I changed the name to "Audacity Compressor - ideas for improved parameter entries". It now includes several things, such as tables of proposed values for the GUI sliders, as well as proposals for "extended parameter ranges" to support custom/advanced use of this effect. Here is the link to the spreadsheet:
https://docs.google.com/spreadsheets/d/ ... eM/pubhtml

I have made a new post in the feature requests section of the forum:
http://forum.audacityteam.org/viewtopic ... 20&t=87604

[Gale Andrews]

I have never "compiled" a program. I am concerned about the time necessary for the learning curve. I have a little bit of other programming experience (JavaScript, GAS, spreadsheets). Any guesses on how much time this could take? Weeks? Months?

When I start over with a new Windows installation I can go from installing Visual Studio, installing and building wxWidgets then building Audacity in about 40 minutes. I still have HDD spinning disks, but it would be faster than that on a solid state drive because building is then faster.

Your main issue will be XP. Visual Studio (VS) 2013 with which we build Audacity 2.1.0 and later doesn't run on XP. However applications built with VS 2013 can still run on XP.

So, you'd have to build Audacity with VS 2008 using the legacy instructions (below the yellow "Getting Started" box) on http://wiki.audacityteam.org/wiki/Developing_On_Windows.

The 2.1.1 release source code https://github.com/audacity/audacity/ar ... -2.1.1.zip and the 2.1.0 release code https://github.com/audacity/audacity/ar ... -2.1.0.zip still contain the "audacity-VS2008_OBSOLETE.sln" solution file which is the file to build Audacity with using VS 2008.

But no-one knows if 2.1.1 or 2.1.0 would build with that solution file, because we had moved to VS 2013 by then. 2.1.0 might be more likely to build with VS 2008.

So the upshot is you may not be able to build later than Audacity 2.0.6 if you only have access to XP, and you can use arbitrary Compressor parameters in 2.0.6 already without compiling Audacity.

Do you have access to Windows 7 or later which VS 2013 requires?

If all that is required is to change the parameters I indicated (and anywhere else they are referenced) then user Edgar may be prepared to make an arrangement off list to do a build for you for a reasonable sum (he will of course decide for himself), or possibly I might as long as no programming is needed. Edgar is a programmer, I am not.

Also, I am curious to learn more about making my own effect plugins, but would I actually be able to use my own effects in Chain Scripts? This is important to me. I thought there was a limitation on that.

You should decide what effect format you are going to program in first. All the supported effect formats including VST and LV2 can be added to a Chain, but only from 2.1.0 onwards.

If you wrote your effect in C++ using LADSPA so it could be built into Audacity (above the divider in the Effect Menu) or in Nyquist, or as a standalone LADSPA effect, you could use your effect in a Chain in 2.0.6. Nyquist is fairly simple but also the most limited. Steve is the expert about Nyquist, you should ask him.


Gale

[jimmyhosen]

Gale, thank you!
I could not have asked for better info. I will think about what to do. Not sure at the moment.
No access to Win7 right now. My PC does not meet its hardware requirements.

[steve]

Could not update effect "Compressor" with:
Compressor:AttackTime="0.004" NoiseFloor="-56.4" Normalize="1" Ratio="1.19" ReleaseTime="1.024" Threshold="-26.4" UsePeak="0"

Attack time of 4 milliseconds won't work properly with this compressor - the algorithm does not go that low. Even if it did, it would not work correctly with such a short attack time when using RMS levels because the RMS averaging window is considerably larger than that.
When based on peak level, such a short attack time will create noticeable distortion for frequencies below about 100 Hz because the compressor will be tracking the individual cycles of the waveform rather than the overall amplitude envelope.

I agree that the compression ratio could go lower. (ideally down to 1:1 imo)

[jimmyhosen]

Attack time of 4 milliseconds won't work properly with this compressor - the algorithm does not go that low. Even if it did, it would not work correctly with such a short attack time when using RMS levels because the RMS averaging window is considerably larger than that.

Interesting. I expected the RMS averaging window to depend upon the attack time. Thank you for letting me know. Seems to sound ok. What is the exact period of the "averaging window"?

When based on peak level, such a short attack time will create noticeable distortion for frequencies below about 100 Hz because the compressor will be tracking the individual cycles of the waveform rather than the overall amplitude envelope.

I think this is not an issue. If a person chooses a proper attack time for the lowest frequency in the bandpass frequency range, then it should work fine. Please see my spreadsheet of tables. It explains this.

[steve]

Definitely interesting - If I recall correctly, the original implementation used an RMS window of 10 ms, but in the current implementation it is just 2 ms. That is both good and bad news. On the positive side, it means that the envelope follower is tracking the waveform very closely (so your 4ms attack time will still mis-track, but not as badly as I initially thought), but on the downside it means that for audio that has lots of low bass frequencies, the RMS calculation will be all over the place.

I expected the RMS averaging window to depend upon the attack time.

It's based on a "circular buffer" that is the same, regardless of the Attack/Release times.

[jimmyhosen]

Note: I edited this reply at 90 minutes after its original posting.

on the downside it means that for audio that has lots of low bass frequencies, the RMS calculation will be all over the place.

No, that will not happen if the RMS evaluation window is equal to the Attack Time, and if people choose an "appropriate" Attack Time. An "appropriate" Attack Time matches the lowest frequency in the bandpass. Please take another look at my spreadsheet. It explains this.

Important: I believe that the RMS value should be calculated over the period of the Attack Time, not some arbitrary time like 2 ms or 10 ms. Otherwise, the Attack Time makes no sense and the arbitrary RMS window undermines the reason for doing RMS compression at all. If your lowest used frequency is 20 Hz, then I think you could get noticeable distortion if the RMS window is only 2 ms. Why? Because the period of 20 Hz is 50 ms, and half its period is 25 ms, both of which are far longer a duration than 2 ms. In this case, I think the RMS evaluation window should be 25 ms, not 2 ms.

It seems to me that the short window of 10 ms, and now even shortened to 2 ms, was due to the programmer noticing problems and then "chasing his tail" instead of addressing the primary issue. My perception is that the "primary issue" is that Attack Time (and thereby also the RMS window) should be chosen by the user in the following manner:

• Attack Time = (Hz^-1)/2

Also could be written as:

• = (2*Hz)^-1
• = 1/(2*Hz)

...where "Hz" is the lowest frequency in the frequency band ("bandpass") of the signal, and the period for RMS evaluation should be equal to the Attack Time. I might be wrong, but if I am, then I think I might only be wrong about the ideal Attack Time being equal to "half" the period of the lowest frequency (maybe instead it is the "same" as the period of the lowest frequency).

Example: Spoken Word. High pass filter at 125 Hz. (125^-1)/2 = 0.004 = 4 ms.

Also, I believe that Attack Times should be measured in milliseconds, not seconds.

That said, I definitely am thankful for programmers! Without people who have contributed thus far, we would have nothing at all. The current Compressor is an excellent start!

[steve]

No, that will not happen if the RMS evaluation window is equal to the Attack Time

but that is not how this compressor works. If you wish to redesign the compressor then patches for the code are welcome on the developer's mailing list (http://web.audacityteam.org/contact/lists)

I believe that the RMS value should be calculated over the period of the Attack Time, not some arbitrary time like 2 ms or 10 ms.

RMS is a way to measure the magnitude of varying signals - a kind of averaging. I think it could be interesting to see what happens if the averaging period was tied to the attack time, but the intended use is to provide a measure of average signal level, not the short term level of part of the waveform. What is the advantage of using RMS for very short periods? Why not use peak?

...where "Hz" is the lowest frequency in the frequency band ("bandpass") of the signal

are you expecting the user to factor that in, or for the compressor to work that out somehow?