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

Audacity Help Forum Windows
1

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/1oDipeaoTL43wnkojeuW0L7qjQjCSuBU1vt-VYFUXWeM/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?

2

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.

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.

// 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   );



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

3

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/1oDipeaoTL43wnkojeuW0L7qjQjCSuBU1vt-VYFUXWeM/pubhtml

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

4

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/archive/Audacity-2.1.1.zip and the 2.1.0 release code https://github.com/audacity/audacity/archive/Audacity-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.

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

5

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.

6

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)

7

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.

8

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.

It’s based on a “circular buffer” that is the same, regardless of the Attack/Release times.

9

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!

10

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)

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?

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

11

Hi Steve,

If you wish to redesign the compressor

It is looking like the ideal thing for me to do is to redesign the Compressor. Unfortunately, I have little programming experience (only JS, GAS and spreadsheets). With that, I must remember that I am but a beggar here and I should be thankful for people like you! I really do appreciate all the work you guys have put into this. You have enabled thousands (millions?) of people to do many great things. So anyway, maybe it is time for me to try to learn.

the intended use (of RMS) is to provide a measure of average signal level, not the short term level of part of the waveform.

Yes, I understand it is an average. …but 2 ms is even shorter than the 25 ms that I mentioned previously, which makes my proposal for full-range audio 12.5 times longer than the current arbitrary window.

What is the advantage of using RMS for very short periods? Why not use peak?

That is an excellent question. This is where I could be wrong and the current algorithm could be better than my thinking, making all of my stink take up too much precious time from other people, including you.

The Peak function does not seem to do what I need it to do. It squashes everything, not letting transients through. I want transients above the low frequency cutoff to be allowed through, while at the same time getting lookahead action. Letting the transients through gives me more control over the crest factor. After doing the compression, I can look at the signal and adjust the crest factor by using the Fast Lookahead Limiter.

When compressing based upon Peak, no matter what, everything gets squashed based upon the loudest peak. No leading transients are allowed through. When based upon RMS, leading transients are allowed through if they are short enough, which is what I want. Again, I also get the “lookahead” action for the passages which have louder RMS amplitude.

Obviously, my idea for a formula could be flawed. There is a possibility that better formulas could be to not divide the period of the lowest frequency by 2, or even to multiply it by 2 (instead of cutting it in half, like I proposed). The formulas for these would be:

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


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

Yes, of course I am expecting the user to factor that in. I do not understand why someone would not factor that in, unless they choose an “automatic” Attack & Release setting. If people don’t know what Attack Time to use, then they would benefit from either looking at a table of recommendations, or maybe the effect itself could list both the Attack Time and its associated “lowest recommended frequency”, to aid users in making good choices.

12

I have updated my spreadsheet to reflect some excellent insights that were provided by Steve (Senior Forum Staff) in the thread for my feature request. (Thank you, Steve!)

Once again, the link to my spreadsheet:
https://docs.google.com/spreadsheets/d/1oDipeaoTL43wnkojeuW0L7qjQjCSuBU1vt-VYFUXWeM/pubhtml

You can view my feature request thread here:
https://forum.audacityteam.org/t/compressor-needs-better-parameter-options/39862/1