I'd like to find source for audio compression classes or functions in C or C++. It would be nice if it had lookahead (slight delay is OK).
Audio Compressor/AGC in C or C++
Started by ●December 9, 2005
Reply by ●December 9, 20052005-12-09
__GG wrote:> I'd like to find source for audio compression classes or functions > in C or C++. It would be nice if it had lookahead (slight delay is > OK).Try http://google.com. I found, for instance, this site: http://datacompression.info/NonCommercialLibs.shtml Cheers! --M
Reply by ●December 9, 20052005-12-09
I think the op is asking about dynamic range compressor i.e. AGC, i.e automatic loudness adj... not data reduction type of compression... Mark
Reply by ●December 9, 20052005-12-09
mlimber wrote:> > __GG wrote: > > I'd like to find source for audio compression classes or functions > > in C or C++. It would be nice if it had lookahead (slight delay is > > OK). > > Try http://google.com. I found, for instance, this site: > > http://datacompression.info/NonCommercialLibs.shtmlThose a data compressors. The OP was asking about dynamic range compressors which are very different. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "We can build a better product than Linux" -- Microsoft Corp.'s Windows operating-system chief, Jim Allchin. One has to wonder why, with their huge resources, they haven't.
Reply by ●December 9, 20052005-12-09
__GG wrote:> I'd like to find source for audio compression classes or functions > in C or C++. It would be nice if it had lookahead (slight delay is > OK). >There's a few in the musicdsp archive. One has just been added using C++: http://www.musicdsp.org/archive.php?classid=4#204 Richard Dobson
Reply by ●December 9, 20052005-12-09
On Sat, 10 Dec 2005 08:46:20 +1100, Erik de Castro Lopo <nospam@mega-nerd.com> wrote:>mlimber wrote: >> >> __GG wrote: >> > I'd like to find source for audio compression classes or functions >> > in C or C++. It would be nice if it had lookahead (slight delay is >> > OK). >> >> Try http://google.com. I found, for instance, this site: >> >> http://datacompression.info/NonCommercialLibs.shtml > >Those a data compressors. The OP was asking about dynamic >range compressors which are very different. > >ErikCorrect. Unfortunate that the term 'compressor' is overloaded. That's why I said 'AGC' in the title. Huge number of hits on Google, of course, and many are data compressors. Of the others, I have no idea how well they work. I was hoping that those on this group would have tried various algorithms. In particular, I'm wondering about fast envelope/peak detection and signal averaging. That seems to be one of the keys, esp as regards CPU cycles. In this particular app, it's important that the initial attack does not spike (as it would if gain were up and the env detector did not react instantly). Something analogous (no pun intended) to the traditional diode/cap peak detector still has a finite ramp-up time, so buffer 'look ahead' is desirable. On the other hand, I don't want to delay any longer than necessary. So the lookahead interval should be roughly sync'd (or greater than) the attack response of the envelope filter. All this might be wishful thinking. Commercial apps probably do this, but I'm not hopeful about finding C++ code that's optimized in this respect. Back to the envelope detector: How is this usually done? I think peak is the way to go in general (don't want to waste cycles on RMS if it's not going to help). I seem to remember some algorithms that simply added each new sample into a running tally of absolute values. There was a 'magic number' multiplier in the picture, 0.999, I believe. Anyone know about that? I've seen
Reply by ●December 9, 20052005-12-09
Look through the datasheets of TAS3103, AD1954. The operation of the lookahead compressor is explained there very clearly. The C implementation is pretty obvious and straightforward, it is just 5-10 lines of code. The main point about the compressors is there is no universal rule about the parameters; it all depends on the desired effect and the audio content. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com> In particular, I'm wondering about fast envelope/peak detection > and signal averaging. That seems to be one of the keys, esp as > regards CPU cycles. > > In this particular app, it's important that the initial attack does > not spike (as it would if gain were up and the env detector did not > react instantly). Something analogous (no pun intended) to the > traditional diode/cap peak detector still has a finite ramp-up time, > so buffer 'look ahead' is desirable. On the other hand, I don't > want to delay any longer than necessary. So the lookahead > interval should be roughly sync'd (or greater than) the attack > response of the envelope filter. > > All this might be wishful thinking. Commercial apps probably do this, > but I'm not hopeful about finding C++ code that's optimized in this > respect. > > Back to the envelope detector: How is this usually done? I think > peak is the way to go in general (don't want to waste cycles on RMS > if it's not going to help). I seem to remember some algorithms that > simply added each new sample into a running tally of absolute values. > There was a 'magic number' multiplier in the picture, 0.999, I > believe. Anyone know about that? >
Reply by ●December 9, 20052005-12-09
in article e1ckp11umqqr60cls9tu8j07spvn30nmss@4ax.com, __GG at __GG@nomail.com wrote on 12/09/2005 20:43:> On Sat, 10 Dec 2005 08:46:20 +1100, Erik de Castro Lopo > <nospam@mega-nerd.com> wrote: > >> mlimber wrote: >>> >>> __GG wrote: >>>> I'd like to find source for audio compression classes or functions >>>> in C or C++. It would be nice if it had lookahead (slight delay is >>>> OK). >>> >>> Try http://google.com. I found, for instance, this site: >>> >>> http://datacompression.info/NonCommercialLibs.shtml >> >> Those a data compressors. The OP was asking about dynamic >> range compressors which are very different. >> > > Correct. Unfortunate that the term 'compressor' is overloaded. > That's why I said 'AGC' in the title."sample", and "modulation" are other terms that often means something different to the audio/music folks.> ... I'm wondering about fast envelope/peak detection > and signal averaging. That seems to be one of the keys, esp as > regards CPU cycles.what does the speed and smoothing (averaging) of your envelope/peak detection have anything to do with CPU cycles?> In this particular app, it's important that the initial attack does > not spike (as it would if gain were up and the env detector did not > react instantly). Something analogous (no pun intended)it's *not* a pun! that is precisely why we call it "analog" electronics or "analog" processing.> to the traditional diode/cap peak detector still has a finite ramp-up time, > so buffer 'look ahead' is desirable. On the other hand, I don't > want to delay any longer than necessary. So the lookahead > interval should be roughly sync'd (or greater than) the attack > response of the envelope filter.sounds to me that you understand the issues quite well. so why is it that you need help? you should be telling us how to do it! :-)> All this might be wishful thinking. Commercial apps probably do this, > but I'm not hopeful about finding C++ code that's optimized in this > respect.pretty easy to write. 50 lines of code or less.> Back to the envelope detector: How is this usually done?how about an analog to the diode/capacitor/load peak detector? or how about squaring, LPFing, and square root (last step usually not necessary) for an RMS envelope?> I think > peak is the way to go in general (don't want to waste cycles on RMS > if it's not going to help).it depends on what you're trying to do? are you trying to maintain a certain perceptual loudness characteristic (then you need to do "A-weighting" or "C-weighting" or even "E-weighting" (if you have the CPU cycles) and RMS envelope detection. if you're trying to limit peak excursions into the forbidden saturation region, then it's diode/capacitor/resistor peak detection.> I seem to remember some algorithms that > simply added each new sample into a running tally of absolute values. > There was a 'magic number' multiplier in the picture, 0.999, I > believe. Anyone know about that?never seen it. why is 999/1000 so "magic"? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●December 10, 20052005-12-10
__GG wrote:> On Sat, 10 Dec 2005 08:46:20 +1100, Erik de Castro Lopo > <nospam@mega-nerd.com> wrote: > > >>mlimber wrote: >> >>>__GG wrote: >>> >>>>I'd like to find source for audio compression classes or functions >>>>in C or C++. It would be nice if it had lookahead (slight delay is >>>>OK). >>> >>>Try http://google.com. I found, for instance, this site: >>> >>>http://datacompression.info/NonCommercialLibs.shtml >> >>Those a data compressors. The OP was asking about dynamic >>range compressors which are very different. >> >>Erik > > > Correct. Unfortunate that the term 'compressor' is overloaded. > That's why I said 'AGC' in the title. > > Huge number of hits on Google, of course, and many are data > compressors. Of the others, I have no idea how well they work. > I was hoping that those on this group would have tried various > algorithms. > > In particular, I'm wondering about fast envelope/peak detection > and signal averaging. That seems to be one of the keys, esp as > regards CPU cycles. > > In this particular app, it's important that the initial attack does > not spike (as it would if gain were up and the env detector did not > react instantly). Something analogous (no pun intended) to the > traditional diode/cap peak detector still has a finite ramp-up time, > so buffer 'look ahead' is desirable. On the other hand, I don't > want to delay any longer than necessary. So the lookahead > interval should be roughly sync'd (or greater than) the attack > response of the envelope filter. > > All this might be wishful thinking. Commercial apps probably do this, > but I'm not hopeful about finding C++ code that's optimized in this > respect. > > Back to the envelope detector: How is this usually done? I think > peak is the way to go in general (don't want to waste cycles on RMS > if it's not going to help). I seem to remember some algorithms that > simply added each new sample into a running tally of absolute values. > There was a 'magic number' multiplier in the picture, 0.999, I > believe. Anyone know about that? > > I've seenThere's no assurance that a any sample in a modest number rill be near a peak unless the oversampling ratio is high. That's why envelope detection is often done with a Hilbert transform and computing I^2 + Q^2. Even without bothering to take the square root, that's not cheap. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●December 10, 20052005-12-10
On Fri, 09 Dec 2005 21:52:25 GMT, Richard Dobson <richarddobson@blueyonder.co.uk> wrote:>__GG wrote: > >> I'd like to find source for audio compression classes or functions >> in C or C++. It would be nice if it had lookahead (slight delay is >> OK). >> >There's a few in the musicdsp archive. One has just been added using C++: > >http://www.musicdsp.org/archive.php?classid=4#204 > >Richard DobsonThanks, Richard. The 'Chunkware' code (your link) looks well written, but I was actually expecting something more complex. If that works well, all the better. I also found this: http://www.music.helsinki.fi/research/spkit It looks interesting. Rather involved set of classes, though. Also, the 'SonicFlow' compressor on SourceForge.net. I'd still like to get pro opinions on those implementations if any of you have reviewed the code or run them.
