Chris's Compressor - Three Queries

[vanroy]

Hi All,

I've been working with Chris's fantastic compressor. Just a few queries based on things I found when trying it out using compressor plugin default settings with Audacity (ver 1.3.9 beta) .

1. It often lifts the very last part (less than half a second) of the music/vocal to an unnaturally high level compared to the rest of the piece - so that this end section doesn't appear to match. Is there any reason for this and a setting I could change to prevent this? Is this the "bug" that is referred to elsewhere in the audacity forum?

2. When applied to a piece 90 seconds long it compressed the first 6 seconds of speech then truncated the file at that point so that 1 min 24 of audio was lost. Is there a reason this might happen and a setting I can change to prevent this?

3. I've read in this forum about people often using 0.77 rather than the 0.5 default. How does this default of 0.5 relate to compression ratio on the built in Audacity compressor. Does 0.5 equate to 2:1 or is there no relationship? Is there any reason why 0.77 is such a sweet spot?

Look forward to any help you can offer

Thanks.

[steve]

1) It's a "bug" or "limitation" of the compressor, but a difficult one to fix in the code. The reason that it happens is because the effect is trying to keep a more even "average" volume level. Of course, when it gets to the end, the volume drops to zero, so in attempting to maintain an average volume level, the compressor over compensates and artificially boosts the last bit of the track.

To workaround this problem, generate a couple of seconds of Noise (Generate menu) at the end of the track. After applying the effect, trim off the Noise.

2) That shouldn't happen. Perhaps you are running short of RAM or disk space? If it's not that, are you using the latest Audacity 1.3.x ?

3)As it says;

You can soften the soft parts with values < 0, and invert
loudness with values > 1

So values above 0 will apply dynamic compression.
Valued less than 0 will apply dynamic expansion.
A value of 1 will apply "total" compression (squash everything flat)
Values greater than 1 will make loud parts quiet and quiet parts loud.

0.2 is pretty mild.
0.5 is a reasonable amount of compression that retain a good amount of the natural dynamics.
0.7 is a somewhat heavy compression, typical of commercial radio.
1.0 is over-the-top compression.

This effect is different from the Audacity compressor (and other compressors).

[kozikowski]

I use 0.77 instead of 0.5 because I posted once asking for a compression setting that most closely approximated the live program service of the local NPR radio station KPCC Pasadena. I had two segments of the same show with and without radio transmitter compression applied.

That was the result. 0.5 is not quite aggressive enough to perform the simulation.

If you have the occasion to capture an on-line radio show, you will be amazed on how messy the production volume controls are. You can't capture an on-line show and listen in the car. Can't be done unless you drive a very quiet automobile. You'd be constantly cranking the volume control up and down. I drive a truck and I like the volume management at KPCC.

QED 0.77.

I've been using that number ever since.

KPCC piles up many entertaining radio shows on Saturday and I just can't pay attention to everything all the time. On-line radio is your friend.


You can post your enjoyment of the software on Chris's web site.

http://pdf23ds.net/software/dynamic-compressor/

I still think he has no idea what he did. You can spell his name wrong and he's still the top Google hit. That's hard to do.

Koz

[vanroy]

Steve & Koz,

Thanks for the helpful comments.

re: The Chris Compressor truncation problem. I was running AUD ver 1.3.9 when I first noticed that problem. Ive tested the same 90 second audio file in AUD version 1.2.6 and it shows the same truncation problem.

I've then retested with shorter audio file lengths. It seems I can go up to about 80 seconds of audio before I get the truncation problem in both version 1.2.6 and version 1.3.9.

I also tested with a 5 min long file and it was truncated at about 55 seconds.

If noone else has reported this then I guess it could well be something to do with my system. I have Pentium 4 2.8Ghz with 1GB of RAM and Plenty of hard disk space - and have done a lot of video editing on this system and never run into problems before. But maybe its time for that long awaited upgrade! I checked RAM usage as it was processing using "spotlight on windows" and saw no appreciable increase in RAM use at it was compressing.

There was a noticeable lag when processing the longer audio files. The progess bar on the "compressing" message gets to half way then pauses briefly - then carries on to the end to show completed - then the track is then shown compressed but truncated.

I would be curious to know if anyone else has experienced this behaviour with files over about 80 seconds in length using Chris Compressor default settings in AUD 1.2.6 or 1.3.9

[steve]

2. When applied to a piece 90 seconds long it compressed the first 6 seconds of speech then truncated the file at that point so that 1 min 24 of audio was lost. Is there a reason this might happen and a setting I can change to prevent this?

I've just had a look at this, and there's definitely a bug.

Regarding Q1, Someone else has given another suggestion (though I can't find their post now) to try raising the "Floor" level and see if that improves it. Depending on exactly what you are seeing, this may fix it, though there is another problem here for which the workaround I suggested in my previous post will sometimes work.

I'm wondering if Q1 and Q2 are related to the same bug, but I'm not sure exactly what you are seeing on your machine. Here I'm seeing that tracks are sometimes truncated and sometimes the last bit of audio is amplified way beyond distortion levels. If I find a reliable method to reproduce the issue I'll post a message on Metablog.

:[update]: I've got a project saved that produces the "truncate" problem reliably. It's late now so I will have to come back to this another time.

[zakafreakarama]

About the truncated files: That happened to me just 2 days ago when working with an mp3 file. The last 15-20 seconds just disappeared after applying the compressor. It was very annoying, but I found a workaround to prevent this.
I wasn't sure if it was a bug, and if it was I couldn't know if it was Audacity's or the compressor's fault. So I tried one thing: got the audio file converted to a lossless format with an external application (in this case I used SoundConverter and transcoded the file to FLAC). Then I opened the new file with Audacity, applied the compressor and... voilà! Worked like a charm!

So it seems it's not (only) the compressor's fault after all...

Try it!

[steve]

So I tried one thing: got the audio file converted to a lossless format with an external application (in this case I used SoundConverter and transcoded the file to FLAC). Then I opened the new file with Audacity, applied the compressor and... voilà! Worked like a charm!

Have you checked that the "converted" file is identical to the original? If you start with a 32 bit file and end up with a 16 bit file then it's not identical. I suspect that during the conversion there has been a tiny bit of "dither noise" added so that silent samples are no longer absolutely silent and this would account for why the workaround works.

[zakafreakarama]

Have you checked that the "converted" file is identical to the original? If you start with a 32 bit file and end up with a 16 bit file then it's not identical. I suspect that during the conversion there has been a tiny bit of "dither noise" added so that silent samples are no longer absolutely silent and this would account for why the workaround works.

No 32-bit file this time. I know what you mean, I've had my personal struggles with that dither noise Audacity adds when exporting to 16-bit (actually I first thought it was a bug, because it doesn't happen when exporting to Ogg-Vorbis; Gale helped me out telling me how to change the settings to avoid that annoying hissing sound).

I just took a regular 16-bit mp3 file, converted it to FLAC with SoundConverter and that's it. I don't know what made that work either; tried the same thing yesterday with another song and it didn't. Funnily enough, cutting the last 3 (or so) seconds of absolute silence did (!).

[steve]

I think I may have found a bug.
I can't post a revised version here as the plug-in is "All rights reserved - Permission granted for personal use, without redistribution."
However, if you want to try my proposed fix, open the plug-in in a text editor and find the word "nil" on line 289. Change it from "nil" to "0" (zero - without quotes).

From

Code: Select all

        (if (and (> samp-num 100) (< sample -1000))
            nil
            (max sample -1000))))))

To

Code: Select all

        (if (and (> samp-num 100) (< sample -1000))
            0
            (max sample -1000))))))

I'm not 100% sure I've got it entirely right, so it would be useful if you could test it. I've sent a message to the author so hopefully he will be able to judge if that's it or not.

[steve]

Just heard from Chris (the author), and while this does hack up a fix, it shows up a couple of other little issues that he's now working on.
Keep an eye on his web-site for version 1.2.2