[gstreamer-bugs] [Bug 404646] New: [audiofx] Compressor element

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=404646

  GStreamer | gst-plugins-good | Ver: HEAD CVS

           Summary: [audiofx] Compressor element
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: slomo at ubuntu.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: ensonic at sonicpulse.de, thomas at apestaart.org,
                    bilboed at bilboed.com, slomo at ubuntu.com,
                    mail at renestadler.de
     GNOME version: Unspecified
   GNOME milestone: Unspecified


+++ This bug was initially created as a clone of Bug #340362 +++

It would be nice if a compressor element could be added to the audiofx element.
This was already discussed partly in #340362 but this bug was in reality about
something else.

Below are the essential comments from that bug



Rene Stadler:

-6 dB hard limiting means to apply a transfer function like

   ouput = tanh ((input - 0.5) / 0.5) * 0.5 + 0.5

to all values with input > 0.5 and a respective negative variant for values < 
-0.5.

This will smoothly compress values above 0.5 (ca. -6 dB), which has the
following advantages:

  - You can input values >1.0 and still get a good sounding output (unless you
really overdo it).  This is of use for ReplayGain if you disable clipping
prevention (which you don't have to).

  - The dynamic range gets reduced (input 1.0 -> output  ca. 0.88).  This
allows you for example to listen to classical music through loudspeakers in
front of a computer (noisy environment), or for playing music on a party.  This
is entirely unrelated to ReplayGain.

Stefan Kost:
I can second René's comments. Dynamic compression, expansion, limmiting can
also be seen as a lookup-table transformation in->out. A compressor starts to
work for a signal above a threshold and then compresses the signal. A hard
limmiter clamps the signal above the treshhold to the treshhold. A compressor
compresses signals above the threshold, e.g. a compressor with the ration 2:1
would do

out = thresh + ((in-thresh)/2.0)

That would be a compressor with hard knee characteristcs. The other bahaviour
is soft-knee which would use a smooth curved transition when going from linear
to compressed.


Rene Stadler:
http://bugzilla.gnome.org/attachment.cgi?id=73746&action=view

Graphs of different transfer functions

A picture says more than thousand words:

 1. Red graph: Clipping (as originally proposed by Артём)
 2. Blue graph: Linear filter (like Stefan mentioned)
 3. Green graph: Smooth hard limiting (like I mentioned)

All filters have a threshold of 0.5 (ca. -6 dB), that is they leave values
below 0.5 (above -0.5) intact.  The picture shows clearly why for clipping, the
waveform gets irreversibly distorted if it exceeds the threshold.  I mention
this because some people seem to have the impression that clipping can somehow
be undone by reducing the volume or something.  It is not.  Clipping is also
done implicitely by audioconvert when it converts from float to integer, which
is most often done to finally send the data to the sound card.  That's the red
area on the graphs, it can never be reached in integer formats as it is beyond
what is defined as maximum.

Second one is a real signal compressor that gives good results instead of
useless distortion.  It's exactly what Stefan said: Basically a selective
volume change that only operates on values exceeding a threshold.  It is very
efficient (just a multiplication in addition to the switching), but that comes
at a price: Trained ears (which I don't claim to have) seem to be able to hear
the point of the threshold because of the rather abrupt change that exceeding
the threshold introduces.  This depends on the input data and especially the
ratio of course.

The third one avoids that by giving smooth values instead.  These come at the
price of higher computational comlexity (a tanhf in addition to the switching
plus scaling around a bit).


Stefan Kost:
In pro-audio devices compressors have four parameters:
* attack (lets omit this for now)
* ratio
* threshold (the point where the compression kicks in)
* characteristics = {soft-knee, hard-knee)

I would use threshold (double) and characteristics (enum) and ration (fraction)
as gobject properties. I am not sure wheter the ration has to be a fraction or
can't simply be a double too.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email