Multi Band Processor

Multi Band Processor

[Robert Jeffares]

[-- Attachment #1.1: Type: text/plain, Size: 3273 bytes --]

Hi all,

I spent a very long time trying to get the multi band processor shown in 
man sox to work.

It seems the manual is older then the code which has changed.

I needed a processor that would take audio from various not so great 
sources, adjust the dynamic range to suit a talk radio stream, and try 
and correct the frequency balance. One source consistently has poor room 
acoustics. Another has levels that vary wildly and a range of audio 
frequency bandwidths.

compand works as advertised. Perhaps not that clearly.

mcompand does not work as implied. It does some of what mcompand does 
but not all.

The manual could do with a makeover. Happy to help but I only know what 
the code does by trial and error so there may be stuff in there I have 
missed.

This code works, and I share it in the interest of others in like 
situations looking for a sledge hammer to fix bad audio or a way to try 
and make the audio sound consistent. This is a SPEECH processor. Do not 
use it for music!

I would encourage comments suggestions and improvements.

I also have sox putting an intro and outro on the processed audio using 
splice so that items are produced complete. This is just the processing 
engine.


============================ snip ======================================

#! /bin/bash


# the delay option is not available when mcompand is called by sox

# doing this as a function makes it easy to switch on and off

function bandmod {

sox -V leveled.wav mcompanded.wav mcompand\

"$f1_process" $f1_crossover\

"$f2_process" $f2_crossover\

"$f3_process" $f3_crossover\

"$f4_process" $f4_crossover\

"$f5_process" $f5_crossover\

"$f6_process" $f6_crossover\

"0,0.8 -38,-38,-28,-28,-0,-6" gain 10 highpass 22 highpass 22 sinc -n 
255 -b 16 -12000

}



# set up band pass processing


#first band

f1_crossover='120'

f1_process='0,0.8 -60,-60,-48,-24,-24,-6,-12,-1.5,-6,-0.3 -21 -15'

# attack1,decay1{,attack2,decay2} 
[soft-knee-dB:]in-dB1[,out-dB1]{,in-dB2,out-dB2} [gain 
[initial-volume-dB [delay]]]


#second band

f2_crossover='360'

f2_process='0,0.8 -60,-60,-48,-24,-24,-6,-12,-1.5,-6,-0.3 -9 -15'


#third band

f3_crossover='1080'

f3_process='0,1.2 -60,-60,-48,-24,-24,-6,-12,-1.5,-6,-0.3 -9 -15'


#fourth band

f4_crossover='3240'

f4_process='0,1.2 -60,-60,-48,-24,-24,-6,-12,-1.5,-6,-0.3 -9 -19'


#fifth band

f5_crossover='5000'

f5_process='0,2.0 -60,-60,-48,-24,-24,-6,-12,-1.5,-6,-0.3 -24 -19'


#sixth band

f6_crossover='10000'

f6_process='0,1.8 -60,-60,-48,-24,-24,-6,-12,-1.5,-6,-0.3 -48 -19'


#for next loop makes it easy to set up for multiple files

for i in $1

do

#take spaces out of filename

newfile=$(mv "$i" "${i// /}")

#now work with new name

#get the filename for later use

filename=$(basename $1)

echo $filename

filename="${filename%.*}"

echo $filename

# lets get the dynamic range sorted before band processing

# files are processed as wav so there is no loss of quality

sox -V $newfile leveled.wav compand 0,1.2 
-60.1,-inf,-60,-160,-48,-24,-24,-6,-12,-1.5,-6,-0.3 -18 -6

sleep 2


bandmod


# the processed audio replaces the original audio

mv mcompanded.wav $filename.wav

rm leveled.wav

done


exit 0


============================ snip ======================================



regards

Robert


[-- Attachment #1.2: Type: text/html, Size: 8984 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Multi Band Processor

[Dr. Thomas Tensi]

Hello Robert,


sorry for the late answer, hope this helps nevertheless!

 > I spent a very long time trying to get the multi band processor shown
 > in man sox to work.
 > It seems the manual is older then the code which has changed.

Hmm.  I am in currently rewriting some of the SoX code for (open-source)
SoX-VST-Plugins for DAWs (with bit-exact identical behaviour to the
command-line version) and as far as I can tell, the compand and mcompand
parameters work as described in the manual.

 > I needed a processor that would take audio from various not so great
 > sources, adjust the dynamic range to suit a talk radio stream, and try
 > and correct the frequency balance. One source consistently has poor
 > room acoustics. Another has levels that vary wildly and a range of
 > audio frequency bandwidths.
 >
 > compand works as advertised. Perhaps not that clearly.
 > mcompand does not work as implied. It does some of what mcompand does
 > but not all.

I find the transfer function definition in SoX a little bit weird, but
it is extremely flexible.  You do not define some compression ratio or
some compression threshold directly, but define base points of that
function.

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 would encourage comments suggestions and improvements.

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.

As far as I can see, your transfer functions, gain and initial volumes
are very similar for all of the bands, hence the modular approach could
be helpful.  The crossover frequencies look okay for me.

I find your release times of 1.2s or even 2.0 quite extreme, but if they
work for your sound material, that's fine.

Hope this helps!


	Best regards,

		Thomas


_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Multi Band Processor

[Robert Jeffares]

Thanks for responding Thomas,

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.

The source audio will have 20 level and eq variances in 20 minutes.

With some patience and experimentation I have something that functions 
OK and delivers acceptable audio which is an improvement on the source.

On 19/04/21 6:50 am, Dr. Thomas Tensi wrote:
> Hello Robert,
>
>
> sorry for the late answer, hope this helps nevertheless!
>
> > I spent a very long time trying to get the multi band processor shown
> > in man sox to work.
> > It seems the manual is older then the code which has changed.
>
> Hmm.  I am in currently rewriting some of the SoX code for (open-source)
> SoX-VST-Plugins for DAWs (with bit-exact identical behaviour to the
> command-line version) and as far as I can tell, the compand and mcompand
> parameters work as described in the manual.

compand will do some things that don't work in mcompand. The manual 
implies that the parameters are identical.

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.

"0,2.0 -38,-38,-28,-28,-6,-28" gain 3  highpass 22 highpass 22 sinc -n 
255 -b 16 -12000

The reason for this is not clear in the documentation. the gain highpass 
and sync all make sense.

>
> > I needed a processor that would take audio from various not so great
> > sources, adjust the dynamic range to suit a talk radio stream, and try
> > and correct the frequency balance. One source consistently has poor
> > room acoustics. Another has levels that vary wildly and a range of
> > audio frequency bandwidths.
> >
> > compand works as advertised. Perhaps not that clearly.
> > mcompand does not work as implied. It does some of what mcompand does
> > but not all.
>
> I find the transfer function definition in SoX a little bit weird, but
> it is extremely flexible.  You do not define some compression ratio or
> some compression threshold directly, but define base points of that
> function.
>
> 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 would encourage comments suggestions and improvements.
>
> 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

>
> As far as I can see, your transfer functions, gain and initial volumes
> are very similar for all of the bands, hence the modular approach could
> be helpful.  The crossover frequencies look okay for me.
I have adjusted the crossover frequencies 'by ear' to use the filter 
slope to best advantage.
>
> I find your release times of 1.2s or even 2.0 quite extreme, but if they
> work for your sound material, that's fine.

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.

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.

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 wish I had the skill to be able to read the source code and perhaps 
write manuals.

Thanks again Thomas for your input.

>
> Hope this helps!
>
>
>     Best regards,
>
>         Thomas
>
>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users


_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Multi Band Processor

[Dr. Thomas Tensi]

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

SoX Plugins for DAWs

[Dr. Thomas Tensi]

Dear all,

in my opinion SoX is a very powerful package for command-line audio
processing. Hence to be able to exactly mimic its behaviour in a digital
audio workstation (DAW) I have reimplemented its algorithms as
open-source audio plugins for DAWs.

The package "SoX-Plugins" provides VST plugins for the - in my opinion -
more prominent audio processing effects from SoX like filters, gain,
overdrive, compander and reverb.

It is completely free, open-source, platform-neutral, programmed in C++
and based on the JUCE audio framework. Currently only a version for VST3
plugins under Windows 10 is provided, but porting it to other targets
should be straightforward, since building is supported by a
platform-neutral CMAKE build file.

During the reimplementation in C++ I have restructured and simplified
the original C code of SoX for easier maintenance, because there were
some redundancies and unnecessary complexity due to their several
contributors. Nevertheless the implementation aims at producing
bit-exact identical renderings in the DAW, i.e. one can be sure that the
DAW will produce exactly the same results as the external rendering by
SoX. A test subtracting DAW audio and external rendering reveals that
this goal is achieved: apart from roundoff errors (SoX often uses 32bit
integer processing, while the VSTs always uses double floating point
processing) the results cancel out with typically a residual noise of
-140dBFS (with 24 bit FLAC files) or even less for higher external bit
depths.

How can this precise emulation be helpful?

In my use-case I am using a command-line based toolchain for generating
band notation videos from a text file score in the lilypond notation
language plus some configuration file telling about instruments and
audio postprocessing etc. In that tool-chain generation of those
notation videos with audio tracks can be done by command-line
open-source tools from text files _without any human intervention_.
Important part of this tool-chain is SoX, because raw audio generation
from MIDI often needs some beefing up by an audio processor (if you're
interested, you can find details on this approach at GitHub
https://github.com/prof-spock/LilypondToBandVideoConverter).

Of course, since a configuration-driven generation is not very
interactive by nature, you sometimes just have to tweak effect settings
or instruments directly. Hence I am using a DAW on intermediate audio
files of the tool-chain and fiddle with the audio postprocessing there
to get the necessary parameters for the command line tool-chain.

Understandably a spiffy user interface is _not at all_ a priority in
this project, but only the correct reproduction of the SoX algorithms
with adequate (slider or combobox) parametrisation.  Also the parameter
ranges in the UI are somewhat debatable, but they simply reflect the
wide parameter ranges of the associated SoX command-line effect.

Because SoX has rich command line options for its effects, not every
effect configuration from SoX can be transported into the slider
oriented GUI of a VST.  E.g. the compander of SoX allows the definition
of a transfer function having multiple segments. Although the internal
engine of the VST compander implements exactly the same internal segment
logic, the user interface only allows the typical definition of a
threshold, a soft knee and a compression ratio (giving a total of three
segments).

All in all, the following SoX effects are available in this package:

    allpass, band, bandpass, bandreject, bass, biquad, compand,
    equalizer, gain, highpass, lowpass, mcompand, overdrive, phaser,
    reverb, treble and tremolo

The time-variant effects phaser and tremolo are time-locked (see
documentation for details); hence the rendering can be exactly
synchronized to externally rendered audio snippets.

Documentation is available at
https://github.com/prof-spock/SoX-Plugins/raw/master/SoXPlugins-documentation.pdf,
the package itself is at https://github.com/prof-spock/SoX-Plugins .

Hope this is helpful for you.


Best regards

Thomas

--------------------

P.S.: This project is a derivative work based on the foundations laid by
the SoX community.  Although the algorithms used were modified and
redesigned, this project would been much more complicated and tedious
without this basis. Hence my thanks go to Chris Bagwell, Nick Bailey,
Daniel Pouzzner, Måns Rullgård, Rob Sewell and all the other
contributors of the SoX project: without your effort this would not have
been possible!


_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

SoX Plugins for DAWs

[Dr. Thomas Tensi]

Dear all,


[[sorry for the double post, but this was buried in a thread where it
didn't belong to]]

In my opinion SoX is a very powerful package for command-line audio
processing. Hence to be able to exactly mimic its behaviour in a digital
audio workstation (DAW) I have reimplemented its algorithms as
open-source audio plugins for DAWs.

The package "SoX-Plugins" provides VST plugins for the - in my opinion -
more prominent audio processing effects from SoX like filters, gain,
overdrive, compander and reverb.

It is completely free, open-source, platform-neutral, programmed in C++
and based on the JUCE audio framework. Currently only a version for VST3
plugins under Windows 10 is provided, but porting it to other targets
should be straightforward, since building is supported by a
platform-neutral CMAKE build file.

During the reimplementation in C++ I have restructured and simplified
the original C code of SoX for easier maintenance, because there were
some redundancies and unnecessary complexity due to their several
contributors. Nevertheless the implementation aims at producing
bit-exact identical renderings in the DAW, i.e. one can be sure that the
DAW will produce exactly the same results as the external rendering by
SoX. A test subtracting DAW audio and external rendering reveals that
this goal is achieved: apart from roundoff errors (SoX often uses 32bit
integer processing, while the VSTs always uses double floating point
processing) the results cancel out with typically a residual noise of
-140dBFS (with 24 bit FLAC files) or even less for higher external bit
depths.

How can this precise emulation be helpful?

In my use-case I am using a command-line based toolchain for generating
band notation videos from a text file score in the lilypond notation
language plus some configuration file telling about instruments and
audio postprocessing etc. In that tool-chain generation of those
notation videos with audio tracks can be done by command-line
open-source tools from text files _without any human intervention_.
Important part of this tool-chain is SoX, because raw audio generation
from MIDI often needs some beefing up by an audio processor (if you're
interested, you can find details on this approach at GitHub
https://github.com/prof-spock/LilypondToBandVideoConverter).

Of course, since a configuration-driven generation is not very
interactive by nature, you sometimes just have to tweak effect settings
or instruments directly. Hence I am using a DAW on intermediate audio
files of the tool-chain and fiddle with the audio postprocessing there
to get the necessary parameters for the command line tool-chain.

Understandably a spiffy user interface is _not at all_ a priority in
this project, but only the correct reproduction of the SoX algorithms
with adequate (slider or combobox) parametrisation.  Also the parameter
ranges in the UI are somewhat debatable, but they simply reflect the
wide parameter ranges of the associated SoX command-line effect.

Because SoX has rich command line options for its effects, not every
effect configuration from SoX can be transported into the slider
oriented GUI of a VST.  E.g. the compander of SoX allows the definition
of a transfer function having multiple segments. Although the internal
engine of the VST compander implements exactly the same internal segment
logic, the user interface only allows the typical definition of a
threshold, a soft knee and a compression ratio (giving a total of three
segments).

All in all, the following SoX effects are available in this package:

    allpass, band, bandpass, bandreject, bass, biquad, compand,
    equalizer, gain, highpass, lowpass, mcompand, overdrive, phaser,
    reverb, treble and tremolo

The time-variant effects phaser and tremolo are time-locked (see
documentation for details); hence the rendering can be exactly
synchronized to externally rendered audio snippets.

Documentation is available at
https://github.com/prof-spock/SoX-Plugins/raw/master/SoXPlugins-documentation.pdf,
the package itself is at https://github.com/prof-spock/SoX-Plugins .

Hope this is helpful for you.


Best regards

Thomas

--------------------

P.S.: This project is a derivative work based on the foundations laid by
the SoX community.  Although the algorithms used were modified and
redesigned, this project would been much more complicated and tedious
without this basis. Hence my thanks go to Chris Bagwell, Nick Bailey,
Daniel Pouzzner, Måns Rullgård, Rob Sewell and all the other
contributors of the SoX project: without your effort this would not have
been possible!


_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users