Hi, John Rigg wrote: True, I'm a digital age guy, so I hadn't thought of that... By relevant settings I mean evaluting several settings across the available ones to later determine the behavior of the knee. If the knee was a toggle switch, the different knee settings were evaluated. I was assuming that RMS measruments and windowed integration act as a high pass filter, is this not true? Thanks for your comments, Andrés

On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote: Interesting. Could you post the pictures for the two others as well ? -- FA Lascia la spina, cogli la rosa.

On Thu, Oct 05, 2006 at 10:48:07 -0500, Andres Cabrera wrote: What's that glitch near the cursor? Is that a bug, or was it in the input waveform? What immediatly strikes me as wierd is that you don't get that rippling effect in the attack, or at least it's not as pronounced. Without delving into the code too deeply, I think theres a bug, theres some interpolation factor that's calculated from the attack coefficient (ef_a), but then its later applied whether were in the attack segment or the decay segment. So actually it's not linearly interpolated, I think I was attempting to process the gain response with the envelope function. But I'm not really sure, as theres no comments in the code (bad Steve, no biscuit). - Steve

On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote: I just had a look at the TAP sources. The gain is only updated every fourth sample, probably because the calculations to compute it involve some functions that are not so cheap in CPU terms. This explains the ripples. The least that should be done is to interpolate the gain between these points (introducing some latency). A better idea would be to simplify the calculations - I haven't looked at them in detail but they seem much too heavy for what's needed. -- FA Lascia la spina, cogli la rosa.

On Thu, Oct 05, 2006 at 05:04:07 +0100, Steve Harris wrote: The SC* plugins do the same as TAP (calculate the gain every 4 samples), but I interpolate the gain values between each computation. The attch/deacay times were slow enough in my testing that it was OK to do that. It would be trivial to change the plugins to caclulate every sample, but at the time they were first released it made the plugin too expensive to run many at once. Things may be better on current CPUs. - Steve

On Thu, Oct 05, 2006 at 07:07:34PM +0200, Fons Adriaensen wrote: That is what, 90 microseconds at 44.1 kHz? I don't think there are any analog compressors that react anywhere near that fast. Don't worry about it :-) -- Paul Winkler http://www.slinkp.com

On Thu, Oct 05, 2006 at 08:14:35 +0200, David Olofson wrote: So that would be a little iffy. SC4 only advertises that it goes down to 1.5ms, which gives something like 90 segments in the attack segment. Looking at the code, the compressors use a pretty expensive linear -> dB conversion routine (cubicly interpolated lookup table) to work out the gain changes, maybe I could substitute a cheap approximation function. I'll bet that analogue compressors didn't use accurace logarithmic approximations. I'm not sure It'd be worth dropping the calcualtion period below 2 though. - Steve

On Thu, 2006-10-05 at 20:14 +0200, David Olofson wrote: If those sort of settings are to be available in a software compressor then we need upsampling as the bandwidth of the sidechain must be at least 10Khz (and possibly much higher) and the product of a 10Khz bandwidth sidechain and a 20Khz bandwidth audio stream exceeds 1/2 the SR for 44.1 and 48Khz. For slower compression, the possibility of just including a low pass filter in the sidechain processing just before the final sample * gain calculation is an alternative. Good dynamics processing in software is a pig. Regards, Dan. ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

On Sun, Oct 15, 2006 at 12:05:14PM +0100, John Rigg wrote: Oops. The linked-to article is by Frank Foti. Dan Mapes-Riordan's article "A Worst Case Analysis for Analog-Quality (Alias-Free) Digital Dynamics Processing" appeared in AES journal Nov 1999. It described a nice test method using a pair of swept sine waves around 10Hz apart to give an amplitude modulated signal which exercises the attack and decay of the compressor under test. As the input fundamental frequencies approach the upper limit of hearing, they decrease in loudness and the lower-frequency aliasing artifacts become more audible. John

On Mon, Oct 16, 2006 at 07:48:35PM +0100, Dan Mills wrote: The question is: how much of this HF energy is there ? There shouldn't be much in a compressor with controlled attack / release times. In that case it is always possible to filter the control signal. In fact the obvious way to set attack / release times is by such filtering ! A fast peak limiter could still do this. But even here it can be avoided by look-ahead, i.e. having a short delay on the audio which in turn allows a finite attack time. A fast limiter needs a higher sample rate or interpolation anyway, just to detect the correct peak level. Remember that 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a signal when converted to the analog domain can be several dB above that of the highest sample. -- FA Lascia la spina, cogli la rosa.

On Tue, Oct 17, 2006 at 11:56:20AM +0200, Fons Adriaensen wrote: True, but if the audio signal contains significant HF energy near the band limit, it doesn't take a very fast gain change to push it past that. Bear in mind that the ear is _very_ sensitive to aliasing artifacts, so `significant' can be a very small amount. John

--- Steve Harris &lt;S.W.Harris(a)ecs.soton.ac.uk&gt; wrote: The last thing almost all software compressors do is something of the form output = gain * sample; If either gain or sample contain aliasing, or if the sum of their bandwidths would cause aliasing then there will be aliasing present at the output. To an extent what happens earlier is in the sidechain is less important as long as the last condition can be met at the 'gain cell'. Audio_bw + Gain_bw must be < 0.5 * SR at the gain control multiplier. To address Erics point, in a slow 'gain riding' compressor your point is valid, but this fails for things like fast limiters or even for something like an emulation of an SSL Mix bus comp, which has some seriously fast attacks available. Further, it is not the instruments fundamental that is the problem, as energy in the harmonics will also get aliased quite happily (And the aliasing products are non harmonically related). I am going to code it up, we will see what happens when we have something measurable (and listenable). Regards, Dan. Send instant messages to your online friends http://uk.messenger.yahoo.com

On Wed, Oct 18, 2006 at 10:45:02AM +0100, Steve Harris wrote: I was referring to aliasing in the compressed audio. Harmonic distortion is introduced during the attack (and decay, but usually to a lesser extent because it's slower). Consider a sine wave audio input. In the attack, the gain is decreasing, so the rising parts of each input half-cycle are reduced in slope, and the falling parts are increased in slope. The audio waveform starts to take on a sawtooth shape if the rate of gain change is high enough. This is a form of harmonic distortion and happens with any compressor, analog or digital. In a digital compressor aliasing will occur if the sample frequency is insufficient to deal with the introduced harmonics (which have been added _inside_ the digital domain remember, so no amount of anti-aliasing filtering on an input ADC will have any effect on it). It will only last for the duration of the attack/decay, but that doesn't make it inaudible. A small amount of harmonic distortion on its own is not objectionable, but when it is accompanied by aliasing it's bad news. John

On Tue, 2006-10-17 at 11:56 +0200, Fons Adriaensen wrote: indeed. there are people who are coming to believe that this "error" is responsible for a significant part of the audible difference between digital and analog playback when the levels in the source material are high.

On Tuesday 17 October 2006 16:43, Fons Adriaensen wrote: I would consider that a hardware bug - but you never know... If this actually does happen, it would certainly cause a great deal of damage with the kind of compression applied to most things these days. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Tue, Oct 17, 2006 at 04:43:39 +0200, Fons Adriaensen wrote: I've actually measured this with an oscilloscope (because I'm that sad, and to settle an argument), and at least the DA converters I tested did respect the fact that the peak voltage was obove the INT_MAX voltage level. It was a few years ago, so I cant remember what I tested, but one thing was a yamaha digital desk. - Steve

--- John Rigg &lt;ladev(a)sound-man.co.uk&gt; wrote: cheaply? It might if we only needed to do the control signal, but at 44.1, there just is not the bandwidth in either the control or AUDIO channels to alllow fast gain changes. Therefore we need to upsample both the audio and the control data (albiet that the control upsampler can get away with a lot less bandwidth then the audio one). When we hit that multiplier the condition is that the sum of the audio bandwidth and the control bandwidth must fit within the nyquest limit, at 44.1 ther just is nothing like the required bandwidth at this point. With both the audio and control bandlimited to 0.25 * FS, we can safely multiply them, any more then that (split any way you like) and it all falls apart. With respect to viewing the attack and decay logic as a LPF, this is only the case if the same timeconstant applies to both (seldom the case), as otherwise there is a discontinuity in the rate of change at the transition which will itself generate HF splatter. It is a thorny problem. Regards, Dan. Send instant messages to your online friends http://uk.messenger.yahoo.com

--- John Rigg &lt;ladev(a)sound-man.co.uk&gt; wrote: But that puts potentially expensive gain calculations into the fast sr code, also I was rather planning on using the impulse used for the upsampler to provide the band limiting for free. then apart. True as far as I can see, and there is a sting in the tail - you cannot just upsample at the input to something like jamin and have done with it, you would have to band limit between each stage as otherwise the HF crud from the first stage will just get aliased in the second! BEAST was the project that had the SSE 2* up/down sampler code that seems to be reasonably quick. change switches limit on the the cutoff is True when I think about it. That is why I am trying to do the upsampling **JUST** before the gain multiplication, so that the upsampler also provides the band limiting. The downside (Apart from the CPU load) is the need to add a Latency port to things that would not otherwise need one. I might (depending on how manic work gets) have something based on SC4 using libsamplerate by the weekend. I doubt that libsamplerate is the correct tool for this however, we don't need the features and given we know the ratio is 2, we can gain some serious speedups with vector optimisations. Would an 'Aliasing free gain cell' library be of interest to anyone? The idea would be that it could be dropped in place of the whole output = gain * sample; thing and would handle upsampling gain and sample arrays, multiplying them and downsampling the result. This would potentially make fixing a LOT of the LADSPA dynamics much easier and would be one place to bugfix rather then scattering that pain all over the place. The API is likely to be 'interesting' as most dynamics plugs don't generate an array of gain values then apply them, and a single sample streaming resampler doesn't bear thinking about. Regards, Dan. Send instant messages to your online friends http://uk.messenger.yahoo.com

--- Steve Harris &lt;S.W.Harris(a)ecs.soton.ac.uk&gt; wrote: rather planning But all that can still be done at 44.1/48, it is only the final sample multiplication that needs its inputs band limited and thus potentially needs the upsampler. The usual half band impulse convolution based approach. But that breaks the ability to use the vectorisation capability of modern compilers and besides the call and return overhead will end up costing as much as the convolution! We seem to be discussing two separate problems here, aliasing in the gain cell and real 'audio' peak discovery, they are peripherally related byt are not the same thing. Regards Dan (Who really now has to go and do some work). Send instant messages to your online friends http://uk.messenger.yahoo.com

Sorry, I'm coming into this late but ..... Dan Mills wrote: You need a low pass filter on the control signal. It should be somewhere well below 1kHz. No it doesn't. You want to absolutely avoid fast changes in the control signal because fast changes will modulate the audio signal whcih is **not** desirable. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "The reasonable man adapts himself to the world; the unreasonable one persists to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw (1856-1950)

Dan Mills wrote: This is the way analogue compressors work. If you have a sound with a fast transient going into a slow attack compressor, the transient passes throught pretty much untouched (apart from any clipping that may occur due to other parts of the design). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Failure is not an option. It comes bundled with your Microsoft product.

On Wed, 2006-10-18 at 08:28 +1000, Erik de Castro Lopo wrote: The clipping of the signal could be designed to sound resonably good by having the area around zero to be linear, but as you get closer to the extremes, the response curve bends inwards, fitting a virtual headroom of say 36 dB into only 12 dB of the mastered 16bit signal. Overdrive I think is the proper name? A sine wave transient too fast for the compressor to handle immediately would then start out as a square with gentle rounded corners instead of a square with a flat-roof haircut. The distribution of the added frequencies is thus moved to lower octaves where the distortion is less dangerous/disturbing. An improvement could then be to apply a 2 dB/oct high-pass before the overdrive circuit followed by the inverse after the circuit, emphasizing the effect on the faster transients and leaving deep sine waves to use the full dynamic range unaltered, without distortion. This would also be an approximation of magnetic tape dynamic response. 50 ms still appears like a long time. Was there a technical reason not to go down to around 20 ms to reach the psychological sense of "simultaniously"? Or perhaps 50 ms is a good value? Something very dramatic obviously happened in the signal when the compressor kicked in, so moving the "drama" from dynamics into short bursts of distortion might actually help in preserving a sense of "naturalness." --

John Rigg wrote: But this should only be happening on transients and the clipping should stop as soon as the attack portion of the compression process kicks in. Most instruments with fast transients usually *already* have a high levels of higher harmonics (and inharmonics) that die away far more quickly than the lower harmonics. Ok, lets say we're sampling at 44.1kHz, which makes the highest 3rd harmonic we can represent is 22.0/3 kHz which is about 7kHz. Do you really listen to many instruments where the fundamental is at 7kHz????? These higher harmonics will be transitory. As soon as the attack portion of the compressor's action is over they're gone. In addition, any aliasing that does occur will be almost indistinguishable from the inharmonics frequencies already in transient part of the sound. I say again, nearly all instruments with very fast transients have a high number of inharmonics frequencuies that die off almost immediately. For instance, think of instruments like acoustic guitars and pianos. Its very easy to get carried away with trying to reach some sort of audio perfection. Things like upsampling in order to apply compression is over-engineering. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Attacks by Microsoft Chairman Bill Gates on the GNU General Public License, under which much open source and free software is distributed, have been driven by a fear that the GPL creates a domain of software that Microsoft cannot privatize and control" -- Richard Stallman

On Wed, Oct 18, 2006 at 06:50:39PM +1000, Erik de Castro Lopo wrote: Yes but my point is that the resulting aliasing sounds worse than the harmonic distortion. True, but those are removed by the anti-aliasing filters in the ADCs. The problem here is harmonics generated _inside_ the digital domain. Once they're generated it's too late to filter them out, as the aliasing has already occurred. A lead guitarist will often deliberately play a harmonic `squeal' in a lead solo (particularly in rock and metal). As a guitarist myself, I fairly frequently generate fundamentals of around 4 kHz. Deliberate use of higher frequencies than that might not be very common, but the equipment should at least deal with it gracefully. The fact remains that a lot of high end professional users consider many of the free software plugins to be "nearly unusable" (see Ben Loftis' earlier post in this thread). This isn't intended as a criticism of the developers, just an acknowledgement that perhaps more attention needs to be paid to some fairly subtle aspects of design that have not been considered important up to now, if these high end users are to take Linux audio more seriously. John

John Rigg wrote: The aliasing is present for 10s of milliseconds. It blurs into the instrument attack. Have a look at the attack transient of an acoustic guitar or a piano. There a bunch of stuff in the first 30 odd milliseconds that bears no relationship with the fundamental note frequencey. I talking about the stuff below half the sample rate. Thats a bit less than an octave below what I'm talking about. I agree completely. I have no problem whatsoever with the possibility that all current free software compressors are poorly implemented, but that doesn't prove that its not possible to implement a good compressor without upsampling. All the best and most famous compressors were implemented using flawed 1960s and 1970s technology. The Joe Meek compressor uses light depend resistors!!!! In order to make a good digital compressor, we need to remember that a compressor is lo-tech. Any benchmark DSP implementation should also be relatively lo-tech. Once you have a good working lo-tech DSP implementation then you can start looking to improve it using whatever far out DSP techniques you can think of. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Indeed, I am impressed that Google runs an 8,000 node Linux cluster, 5 data centers, an extensive network, and a rapidly evolving application all with a staff of 12." -- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc

--- Fons Adriaensen &lt;fons.adriaensen(a)skynet.be&gt; wrote: It doesn't export it, but the original BSD licensed code for the 'dyson' compressor does have this feature. Regards, Dan. Send instant messages to your online friends http://uk.messenger.yahoo.com

Hi, Steve Harris wrote: I know... I've been meaning to look at the sources for a while, but haven't done it yet... I'm curious as to why it is worrying. I'm not expecting the square waves to yield particularly important results, but I'm interested to know why it seems such a bad idea. I tried... but there's no way to turn delay compensation off for plugins in Sonar, either in DX or VST versions... So there probably is some delay, but I have no way of finding out how much. It's specially hard for Waves plugins since they use a rare waveshell which is not compatible with most simple hosts. Do waves plugins work with xfst? Cheers, Andrés

On Thursday 05 October 2006 14:09, John Rigg wrote: Which is why one of the best compressors of all time, designed by CBS Labs back in about 1960, was so good. It had 2 versions for two different broadcast scenarios, one for the 75u-s pre-emphasis of fm, and one that was flat for am. But both had 2 circuits, with the faster circuit having microsecond response times to control the peaks while allowing a fairly high average. I'm refering of course to the Volumax and Audimax devices. Some of those are still in service, hidden away at transmitters in your neighborhood. The single vacuum tube they used in one of them, a 'nuvistor' has probably long since been replace by a depletion mode fet transistor and the device recalibrated back to factory specs. And all the 2 uf electrolytic capacitors used in the original have long since been replaced with 2 uf mylars. At that point, you can literally forget its in there, for years at a time. You couldn't hear it working unless the next audio source switched to was -30db from the previous one, then you could hear it slowly raisng the gain for several seconds, eventually picking up a peak that opened the high speed gate and 100ms later the sound was at the normal level again. All without the sleeping dj ever knowing he wasn't doing his job on the board. Anything else we attempt to put in there just seems to bring back memories of that 5 minutes of heavy breathing from last night, just before you went to sleep... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Hi, First, let me clarify that my main intent with this paper is not to bash linux plugins or demerit people's work, but to see how other commercial plugins compare to the linux ones, to be able to make the best possible compressors as open source. I'm just presenting my results, it's a learning experience for me, so I appreciate all comments. Alfons Adriaensen wrote: Yes, gain change was measured comparing individual samples, this measures the exact effect of the plugin on a known signal. The csound program compensates for any delay introduced by the plugin by not comparing exact times, but rather by looking for the start sample for each section. When I talk about latency in the paper, I'm not referring to audio latency or latency introduced by the plugin from a look-ahead method, but rather about a latency (or delay) in the start of gain reduction by the plugin, which is probably dictated by the 'windowed' or integration mechanism used by the plugin to calculate the envelope. It's worth noting that the Renaissance Compressor does not introduce this type of latency (i.e. gain reduction is applied to a signal from the start of the first sample), but still it does not introduce any delay in the audio signal. The first sample of the waves is exactly in the same position for both the source signal and the processed signal. This seems to point to a compression algorithm that relies on additional mechanisms to follow an envelope, which can track gain from a few samples (probably within the process buffer size, to keep the signal in time). I'm thinking that maybe Sonar (which I used to process audio with the RCompressor plugin) has applied some sort of delay compensation mechanism, and maybe there is after all a delay in the plugin that is later compensated... True, but since either the plugin produces no delay, or Sonar has compensated the delay, this is not evident. I'll see if I can find a simple host that can load Rcompressor and can process the file without delay compensation, to check for plugin delay (or see if there's a way in Sonar to turn delay compensation off). Since the source white noise is known, it was possible to compare the effect sample by sample. As said in the paper, there was no effect on the phases of the sound (so each sample was still in the same place, but its gain had changed) True, but I'm measuring the audio processed in the digital domain. I included square waves and saw waves (saw waves used are also not band-limited) in the test sample for completeness and to see whether they yield significant results, but most of the conclusions are drawn from the pure sine waves. I don't.... Sine waves would show this better. What I think is most significant in the paper is not the fact that the linux plugins tested introduced 'compression latency', but that they produced jagged gain reduction curves. This jaggedness is periodic and independent of the processed signal. This either points to a user error that is hard to avoid (I tried to be as thorough and careful as I could), that might (or might not) be affecting audio quality, or to some problem somewhere in the audio chain (maybe it's not the plugin). I'm very interested in finding out the reason for this if only to learn I'm doing something wrong. Cheers, Andrés