Hello Robert,
you wrote:
> Thanks for responding Thomas
You're always welcome. Sorry to be that late, but I was
busy...
> my system starts with a compand function to iron out the
> devastating differences in audio levels on our sources.
>
> This is followed by a mcompand 5 band process which has a
> low end rolloff, a voice presence tweak, and a gentle high
> end caress to mitigate hiss and sibilance.
>
> [results with compand plus mcompand are acceptable]
This seems to me like a very good approach.
> > [compand is just a special case of mcompand with a
> > single band and a crossover frequency of 22kHz]
> compand will do some things that don't work in mcompand.
> The manual implies that the parameters are identical.
Maybe I do not understand the problem. Doing a compand
followed by an mcompand can be absolutely reasonable,
because the first stage levels the signal overall and then
the second stage does some individual tweaks on the
frequency bands.
So there is no disagreement on your approach at all.
But definitely: although the implementation for compand and
mcompand is separate in SoX (there is code duplication in
the source code for mcompand.c and compand.c), they
implement _exactly the same algorithm_.
I have tested it against my reimplementation (where both
approaches are unified) and a reimplemented mcompand with a
single band behaves _exactly_ like the original SoX
command-line compand.
If this were not the case, you would just have crushed my
mental model ;-)
> mcompand has to have a global compand type item at the
> end. This is not clearly explained. I have played with
> this and arrived at something that works for me.
No. The compand item at the end does not have a frequency
specification because this compander band does not have an
upper crossover frequency.
The command line logic is
mcompand band1CompanderSpec band1TopFrequency \
band2CompanderSpec band2TopFrequency \
... \
band(n-1)CompanderSpec band(n-1)TopFrequency \
band(n)CompanderSpec
The last compander has no explicit top frequency, but it is
just infinity or - more precisely - the Nyquist frequency
(e.g. for a 48kHz sample rate signal this is 48kHz/2 =
24kHz).
In command-line SoX an mcompand with one band behaves exactly
like a compand. I did not check whether you can specify
such an mcompand, but if yes, there must be no difference.
You just have the additional double quotes with mcompand.
Let me clarify this with an ASCII-art picture (hope this
works). This is the signal flow in mcompand:
Input
Signal
|
v
+----+ +----+ +------+ +...+
|LR1 |-->|LR2 |--> ... -->|LRn-1 |-->.LRn.--> x
+----+ +----+ +------+ +...+
| | | |
v v v v
+----+ +----+ +------+ +----+
|CMP1| |CMP2| ... |CMPn-1| |CMPn|
+----+ +----+ +------+ +----+
| | | |
v v v v
+-----------------------------------------+
| Signal Adder |
+-----------------------------------------+
|
v
Output
Signal
So the input signal is split by so-called Linkwitz-Riley
crossover filters that take a signal and split it into two
signals at their crossover frequency: a low frequency signal
below that frequency and a high frequency signal above that
frequency. In the picture "low" goes down into a compander
and "high" goes right into the next LR-filter. The last
filter LRn (with the x-output) is not specified in the
mcompand command line, because it does not really do
anything complicated: its crossover frequency is the Nyquist
frequency, hence x must be the null signal and everything
coming in from the left goes directly down to CMPn (the n-th
compander).
Finally all compander outputs are summed up into the output
signal.
Reduced to one band this gives you: an LR-filter with no
signal change (the filter parameters degenerate to an
identity filter without phase issues), a standard compander
and finally an adder with just one signal. Looks like a
compander to me.
>> Your functions look okay, but you could consider rounding
>> off the corners of the transfer function by adding a knee
>> value of e.g. 4dB.
> I copied someone else's and then modified. It came without
> knee. I have added the knee and it certainly smooths the
> transitions. Thanks for that.
I guess you really can't hear the difference with your rough
material and your compression settings, but it does no harm.
> > What you could do is factor out the common parameters and
> > just put in the changed values instead; you already did
> > that in part, but putting this further would make your
> > script more modular.
> At the prototype stage it was easier for me to keep each
> band seperate. I found that to much difference between
> band parameters caused phase issues. It works best when
> each band is processed more or less the same and the
> outputs are combined in the desired ratio. I roll off the
> low end. Allow voice frequencies
I didn't check that, but I can imagine that this is
generally a problem with multiband companders. Frequencies
near the crossover frequency behave completely differently
depending on whether they are below it (and in band i-1) or
above it (and in band i). Hence your approach is reasonable.
> > [extreme release times of 1.2s or even 2.0s]
> The audio sourced from three different TV channels,
> typically comes crashing in at high level. 20db above the
> average level. Either a device or an operator cranks it
> down. Given the consistency it's a device. To even things
> out a fast attack and a slow release works. The noise
> floor [ hum hiss air condx passing traffic etc ] is about
> -32. Long release prevents the noise being sucked up. I am
> dealing with speech. Sources run from reverberant studios
> to less than ideal remote locations. Camera operators have
> the high pass filter useful for lapel mic's in circuit
> when the reporter is using a hand held ENG mic. Automatic
> level controllers [that don't] at venues used for Press
> Conferences or to deliver speeches defeat everything in
> the subsequent path.
> I have been able to get a consistent clear result. Today
> there was a vox pop segment recorded at a bus station with
> several diesel buses running in the background. The
> processed version was better then the original broadcast
> audio.
Congratulations! That requires a lot of tweaking and
expertise from your side.
> The 'processor' can be run in a shell script that is
> invoked when an operator edits the source audio and sends
> it 'to be carted'. Our low budget LPFM can't afford the
> $7k processor, which I am not so sure could be tuned as
> sweetly as this.
That's the advantage of command-line open-source tools.
> I have a set of processors, one for each of our sources.
> The goal is to deliver a consistent sound to our listener
> but not have the processing so heavy as to be tiresome.
> mcompand has enabled me to build a virtual device which
> achieves this. I am really appreciative of all the work
> done in sox and associated code by a legion of people.
I myself am not active in the SoX development, which is a
great work in my opinion. Standing on the shoulders of
giants...
> I wish I had the skill to be able to read the source code
> and perhaps write manuals.
We as developers are typically not good at the latter; so we
appreciate people getting along with the software anyway ;-)
Best regards,
Thomas
_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
