sox-users — SoX list to discuss end user topics

[SoX-users] A SoX puzzle: the flanger equivalent to phaser?

[Martin G. <mar...@gm...>]

This month I've been working mostly on the documentation
and one of the additions to the manual is:

    chorus -l gain-in gain-out delay decay speed depth -wave

    is equivalent to

    flanger delay depth 0 100/(decay/gain-in) speed wave 0 linear \
        vol (decay+gain-in)xgain-out

and I've scratched my head to figure out the same for phaser but
haven't yet managed to make flanger produce a similar-enough wave
to phaser, except for all-input-and-no-delay

If anyone fancies a mathematical puzzle, what are the formulae to derive
the arguments to flanger, given

    phaser -l gain-in gain-out delay regen speed -wave

I've got to

    vol gain-in/(1+regen) \
    flanger 0 delay regen*100 100*regen speed wave 0 \
    vol gain-out

but the waveform's not even similar.

phaser -l is to interpret linearly between samples but is only in the
main branch as yet so I've made a 14.6.1+git20251022 release
in case someone wants to check hypotheses at
https://codeberg.org/sox_ng/sox_ng/releases

    M

Re: [SoX-users] Enuf

[David J. <da...@dr...>]

Long time lurker here.

Thanks for all you do. I've been using SoX for many years and feel it's an
invaluable part of my toolkit.

Sorry to hear you're going through a rough time. I'm sure I'm not alone in
letting you know that the community loves and appreciates you, and will be
there for you in whatever way we can.

All the best,
*David*


On Fri, Oct 17, 2025 at 11:53 AM Martin Guy <mar...@gm...> wrote:

> My apologies for that little outburst. A drunken idiot (me) took hold
> of my keyboard while I was still logged in.
> For the record, Dan's comments on SoX issues have always been
> perspicacious, precise and helpful,
> and that is the only form of interaction I have had with him. Why I
> felt persecuted is a bit of a mystery to me,
> the rantings of a sick mind or something to do with the rest of the
> life I live, I would guess.
>
> Unfortunately, after finalizing 14.6.1 I went out and some young idiot
> kicked my legs out from under me
> while trying to steal my lighter, I fell on my back and fractured a
> vertebra, managed to get home but
> wasn't able to move from my bed for three days, then started using
> white wine as an anaesthetic but
> it got a bit out of hand. I'm OK now, if still in constant pain but
> not as bad as before,
> and it looks like it will repair properly, but still feel a bit
> strange, weak and confused.
>
> No excuse, of course, but to understand can be to forgive,
>
> And yes, I do intend to continue with the releases of sox_ng.
>
>     M
>
>
> _______________________________________________
> Sox-users mailing list
> Sox...@li...
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

Re: [SoX-users] Enuf

[Martin G. <mar...@gm...>]

My apologies for that little outburst. A drunken idiot (me) took hold
of my keyboard while I was still logged in.
For the record, Dan's comments on SoX issues have always been
perspicacious, precise and helpful,
and that is the only form of interaction I have had with him. Why I
felt persecuted is a bit of a mystery to me,
the rantings of a sick mind or something to do with the rest of the
life I live, I would guess.

Unfortunately, after finalizing 14.6.1 I went out and some young idiot
kicked my legs out from under me
while trying to steal my lighter, I fell on my back and fractured a
vertebra, managed to get home but
wasn't able to move from my bed for three days, then started using
white wine as an anaesthetic but
it got a bit out of hand. I'm OK now, if still in constant pain but
not as bad as before,
and it looks like it will repair properly, but still feel a bit
strange, weak and confused.

No excuse, of course, but to understand can be to forgive,

And yes, I do intend to continue with the releases of sox_ng.

    M

[SoX-users] Enuf

[Martin G. <mar...@gm...>]

Ok, that's enough. sox-14.6.1 is the last release I will make.
A predator, danadam, is following me everywhere I go.

Glad you liked it

Blessings

    M

[SoX-users] Announcing bugfix releases for sox_ng

[SoX N. <so...@fa...>]

I'm happy to annouce the latest bugfix releases for sox_ng,
14.4.5, 14.5.2 and 14.6.1
available at https://codeberg.org/sox_ng/sox_ng/releases

Enjoy

   M

[SoX-users] Sox_ng-14.6.1 bugfix release candidate is up

[SoX NG <so...@fa...>]

I am happy to announce sox_ng-14.6.1-rc1,
the first release candidate of bugfixes to 14.6.0.

It's the same as the main development branch
as only bug fixes have gone in since 14.6.0.

The changes are:

New features:
   o Create sparse audio files when the data is zeroes

Bug fixes:
   o On Windows, delete temporary files and output files with write errors
   o Fix opusfile detection when using pkg-config
   o Fix compilation on AIX 7.3, MSYS2/MinGW, Sortix and on MacOS X with 
older SDKs
   o On Windows you no longer have to "set AUDIODRIVER=waveaudio"
   o Spell-check and revise the manuals, fix some usage messages
   o Make reading MP2/3 and Ogg files work with -t sndfile
   o Make writing MP3 files work with -t sndfile
   o Fix various floating point exceptions and segmentations faults
   o When writing WAV files >4GB, set the size to "unspecified"
   o Reject negative sample rates
   o Make the GSRT padding byte for odd numbers of samples silent
   o Use sigaction() so that SoX is stoppable even when blocked by I/O.
   o Make the status display adapt to the terminal width
   o Fix reading of zero-length AIFF files
   o Fix reading of AMR files with invalid block types
   o Fix an input buffer overrun with OSS audio device
   o Fix OSS drivers that treat mono output as stereo
   o Fix ogg output (broken in 14.6.0, fixed in 14.6.0.4)
   o Fix asymmetric drain in noisered
   o Initialize the channel map when using pulseaudio
   o Make it compile with C89 compilers
   o Correct WAV's byte rate for TXW's 33333.333Hz sample rate
   o Detect and report the unsupported Sonarc-in-WAV format
   o Fix OKI ADPCM compression and decompression to respect the standard
   o Give LADSPA_PATH a sensible system default
   o Fix maximum and minimum values of speexdsp -agc and -denoise
   o Avoid slowdown of overdrive due to denormalized floating point values

Interesting changes to the manual are:

   o You can read WAV files with bit-depths not 8/16/24/32 using -t sndfile
   o libmad is unable to read MP2 files with bit rate > 192K and
     -t sndfile reading MP2 files is broken but -t ffmpeg will do it.
   o Writing MP3 files adds a hundredth of a second of quiet garbage at the
     start and/or the end; with -t sndfile it uses libmpg123 and doesn't
   o Pitch's output can make bend dump core, so use bend then pitch if 
possible

Thanks to boxofrox, Daniel Adamski, Doug Cook, Doug Lee, Erik Ronstrom,
Han Zheng, Hendra Gunadi, Jacob "torridgristle", Jiri Kucera, John 
Brandwood,
Kirill Okhotnikov, LigH, Mans Rullgard, Mark Johnston, Michael Mikonos,
Michal S, Onno van der Linden, Pablo AB, Peter O'Shea, Prof Spock,
Ross Bencina, Thomas Klausner and others for reporting, analysis and fixes
and to unusual corners of the GCC Compile Farm for testing.

The "write sparse files" change should really have been held back
until the next minor release but was brought forward so that the test
for WAV files with >= 4GB of data doesn't use 4GB of disk space.

Please test, enjoy and report problems to so...@gr...

    M

Re: [SoX-users] sox_ng real-time processing update

[Martin G. <mar...@gm...>]

On 20/08/25 23:57, Doug Lee wrote:
> On Sat, Aug 16, 2025 at 12:02:37PM +0200, Martin Guy wrote:
>> On 15/08/25 22:05, Doug Lee wrote:
>>> Until today, I've used SoX 14.4.1 for its speed.
>> Faster than 14.4.2 ?
> Sadly I don't have test results for that, but I do have notes indicating that, a while back, this may well
> have been the case.
Hmm, well nothing has changed that I can see since 14.4.2 and the only 
changes to the win32 stuff between 14.4.1 and 14.4.2 are to its 
libtool-dynamic-library stuff. In fact nothing has changed in the 
windows driving code since sox-12.18.2 from 2006, which is when I 
stopped looking.
>>> In the older SoX, --buffer 1024 was sufficient for most operations
>>> on my machine, and I could even get away with --buffer 768 sometimes.
>>> On sox_ng, I need --buffer 3000 at a mimimum, and --buffer 4000 if I use
>>> speexdsp
>> What are the symptoms that these bigger buffers relieve?
>> Interruptions in the heard audio?
> I call it stuttering - pretty fast stuttering at that. One friend who tested this did not experience this
> though, much to my delight.

Another guess is that something has changed at your end, like the audio 
hardware or the version of Windows so I've cross-compiled 14.4.1 and 
14.4.2 for win32 and win64 under http://martinwguy.net/test if you'd 
like to see whether you see different results with those. md5sums are:

0fb844665b732d0f435b69527a124aff  sox-14.4.1-win32.exe.zip
31933baed228c9d30ebb31f99236bcbe  sox-14.4.1-win64.exe.zip
6c759fd2dcba84667b0f4af1f5bb29a5  sox-14.4.2-win32.exe.zip
221345aa7b19d76a2fbb9e87ab6ea9be  sox-14.4.2-win64.exe.zip

>>> I lack the know-how to craft a WSAPI driver for sox_ng;
>> I don't even know what a WASAPI driver is but you could file an issue for it.
> Right, WASAPI; I missed an A. :) One of a slowly increasing number of Windows sound device interfaces, it
> seems; but supposedly the fastest native one - native, I say, because I don't know how it compares to ASIO
> which is third-party and about which I know little.

Thanks. https://codeberg.org/sox_ng/sox_ng/issues/579


     M

Re: [SoX-users] sox_ng real-time processing update

[Doug L. <dg...@dl...>]

Forgot to answer this one.

On Sat, Aug 16, 2025 at 12:02:37PM +0200, Martin Guy wrote:
> On 15/08/25 22:05, Doug Lee wrote:
> > Until today, I've used SoX 14.4.1 for its speed.
> 
> Faster than 14.4.2 ?

Sadly I don't have test results for that, but I do have notes indicating that, a while back, this may well
have been the case.

> > Today, I am starting to use sox_ng 14.6.0 instead.
> >
> > In the older SoX, --buffer 1024 was sufficient for most operations
> > on my machine, and I could even get away with --buffer 768 sometimes.
> > On sox_ng, I need --buffer 3000 at a mimimum, and --buffer 4000 if I use
> > speexdsp
> 
> What are the symptoms that these bigger buffers relieve?
> Interruptions in the heard audio?

I call it stuttering - pretty fast stuttering at that. One friend who tested this did not experience this
though, much to my delight.

> The buffer-related commits in sox_ng since 14.4.2 are:
> 5e37160 (pre-14.5.0) about pulseaudio buffering (I hope you're not using
> that!)

I am not using pulseaudio; on Windows I use waveaudio only... and I may have forgotten to mention that these
are all Windows SoX/sox_ng builds I've been discussing.

> > I lack the know-how to craft a WSAPI driver for sox_ng;
> 
> I don't even know what a WASAPI driver is but you could file an issue for it.

Right, WASAPI; I missed an A. :) One of a slowly increasing number of Windows sound device interfaces, it
seems; but supposedly the fastest native one - native, I say, because I don't know how it compares to ASIO
which is third-party and about which I know little.


-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"If you refuse to be made straight when you are green,
you will not be made straight when you are dry." {African}

Re: [SoX-users] sox_ng real-time processing update

[Martin G. <mar...@gm...>]

On 15/08/25 22:05, Doug Lee wrote:
 > Until today, I've used SoX 14.4.1 for its speed.

Faster than 14.4.2 ?

 > Today, I am starting to use sox_ng 14.6.0 instead.
 >
 > In the older SoX, --buffer 1024 was sufficient for most operations
 > on my machine, and I could even get away with --buffer 768 sometimes.
 > On sox_ng, I need --buffer 3000 at a mimimum, and --buffer 4000 if I use
 > speexdsp

What are the symptoms that these bigger buffers relieve?
Interruptions in the heard audio?

The buffer-related commits in sox_ng since 14.4.2 are:
5e37160 (pre-14.5.0) about pulseaudio buffering (I hope you're not using 
that!)
df8fb9a (pre-14.5.0) about pipe buffering

If you are using pulseaudio, try not doing so (that patch should have 
improved
pulseaudio latency, but maybe it has side effects on buffering performance.)

Or... are you able to "git bisect" on Windows? My current win32-maker
is MXE, which cross-compiles from Unix and needs you to make a release
tarball available on codeberg for each version to test, so that's
prohibitively effortful.

 > I appreciate the static sox_ng Windows build for its single-file 
simplicity.
 > I also appreciate the bundling of ffmpeg.exe

Thanks for saying so.

 > I did not see wget.exe in the Zip

I used to bundle it (them) with sox_ng.exe, but wget was much bigger
than sox (!) so now you find it separately at the end of the
list of downloads on the Release page.

 > I lack the know-how to craft a WSAPI driver for sox_ng;
 > but if that ever happens, and especially if sox_ng
 > becomes capable of enumerating found in/out devices (with or without 
the -V3 trick used on MacOS), I'll be,
 > as they say, all ears!

There is already an issue to be able to list available audio devices
https://codeberg.org/sox_ng/sox_ng/issues/521 but how to do it is
different for every audio driver :(
Maybe by 18 November unless someone else gets there first.

I don't even know what a WASAPI driver is but you could file an issue 
for it.
Maybe someone else who also who wants it will have a go.

 > Thanks very much to those who are maintaining and enhancing sox_ng.

You know where the cookie jar is :) though I must also thank the amazing
team of DSP engineers and testers that is forming around sox_ng.
Before I was mostly reusing the last nine years of patches
in the distros, in bug trackers and in the 50-or-so forks; now even
new issues get picked up, analyzed and often resolved independently.
Fab.

     M

[SoX-users] sox_ng real-time processing update

[Doug L. <dg...@dl...>]

Years ago, I wrote a Python program I called Audir (Audio Director). It remains at
https://www.dlee.org/audir/ and can use SoX as a real-time sound relay among devices, to/from files, etc. My
comments below all apply to using SoX or sox_ng to relay sound between sound devices and/or Virtual Audio
Cable devices on a Windows 11 Professional, eight-core Dell laptop running on power.

Until today, I've used SoX 14.4.1 for its speed. Today, I am starting to use sox_ng 14.6.0 instead. These
are findings in case useful:

In the older SoX, --buffer 1024 was sufficient for most operations on my machine, and I could even get away
with --buffer 768 sometimes. On sox_ng, I need --buffer 3000 at a mimimum, and --buffer 4000 if I use
speexdsp - which, I might add, is a rather fun thing to do to my default audio output path when I bounce
among chat programs, meetings, etc.! I don't know how these numbers translate to delays in ms, nor whether
the mappings of --buffer <size> to ms are the same between the SoX and sox_ng versions.

I appreciate the static sox_ng Windows build for its single-file simplicity. I also appreciate the bundling
of ffmpeg.exe for those who need it. I did not see wget.exe in the Zip but the docs made it seem like it was
supposed to be there? The SoX 14.4.1 Zip, years ago, included wget.exe but not ffmpeg.exe, included several
(required) DLL files, and did not support as many formats out of the box as the sox_ng static build does -
e.g., flac. This update, I also very much appreciate.

I lack the know-how to craft a WSAPI driver for sox_ng; but if that ever happens, and especially if sox_ng
becomes capable of enumerating found in/out devices (with or without the -V3 trick used on MacOS), I'll be,
as they say, all ears!

Thanks very much to those who are maintaining and enhancing sox_ng.

-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"No person is your friend who demands your silence or denies your
right to grow." --Alice Walker

[SoX-users] SoX giving higher bit rates for small files

[SoX NG <so...@fa...>]

I've noticed that soxi gives higher bit rates for very short 
uncompressed audio files:

sox -n -r 48000 -b 16 out.wav synth 1 sine
sox --info out.wav
Bit Rate       : 768k

sox -n -r 48000 -b 16 out.wav synth 0.1 sine
sox --info out.wav
Bit Rate       : 772k

sox -n -r 48000 -b 16 out.wav synth 0.01 sine
Bit Rate       : 803k

because it is dividing the total file length in bits by the audio length
in seconds, including the (usually fixed-size) header.

The manual for soxi says:

-B     Show the bitrate averaged over the whole file

presumably "averaged" because some compressed formats have variable
audio data rates.

and Rob Sykes writes:

 > I expect that I may be responsible for the current behaviour but
 > I'm afraid I can't remember the reasoning behind it. In any case,
 > times have changed so if the consensus is that something
 > else makes more sense now, I've no objection to it being changed.

So my question is whether soxi giving the bit rate including the header
is sensible and useful, or whether it would be better for it to report
the bit rate of the audio data stream (so it would be the same in
all the above cases) and to change the help to

-B     Show the audio bitrate averaged over the whole file

Thanks

     M

https://codeberg.org/sox_ng/sox_ng/issues/560

[SoX-users] ogg output was broken in all the last releases

[SoX NG <so...@fa...>]

Hi again

A bug has turned up in all the last releases that made

    sox_ng in.wav out.ogg

fail always, so there are now patch releases 14.4.4.1, 14.5.1.2 and 14.6.0.4
fixing just that. 14.4.3 and 14.5.0 are OK.

If you prefer to patch your existing version, it's:

diff --git a/src/vorbis.c b/src/vorbis.c
index a1bed232..ef5b9e2b 100644
--- a/src/vorbis.c
+++ b/src/vorbis.c
@@ -309,11 +309,9 @@ static int startwrite(sox_format_t * ft)

    /* TODO */
    rate = ft->signal.rate;
-  if (rate) {
+  if (rate)
      lsx_fail_errno(ft, SOX_EHDR,
        "Error setting-up Ogg Vorbis encoder; check sample-rate & # of 
channels");
-    return SOX_EOF;
-  }

    /* Use encoding to average bit rate of VBR as specified by the -C 
option */
    if (ft->encoding.compression != HUGE_VAL) {

which happened as part of the drive to make all failures actually fail, but
the above case seems to be "oxbow code" that never actually did anything 
useful
(lsx_fail_errno() doesn't print a message but just stores the message
for future use).

Versions with working ogg output are under
https://codeberg.org/sox_ng/sox_ng/releases

    M

Re: [SoX-users] partial fade in

[Peter P. <pet...@fa...>]

* Nicolas Graner <ni...@gr...> [2025-07-19 15:47]:
> Hello all,
> 
> I would like to ramp the volume of an audio file from a given level to
> full volume over a specified time interval. For instance, increase the
> level linearly from 30% at time t=0 to 100% at time t=10s. In other
> words, perform a fade in starting from a level greater than 0.
> 
> I can do it by inserting an appropriate amount of silence before the
> beginning, performing a fade in, then removing the extra silence. But
> this seems unnecessarily complex, especially if the effect is to be
> applied at a time other than the beginning. Is there a better way to do
> it with SoX ?

Dear Nicolas,

apart from the other replies to your question let me add that any
consequent functionality, that is beyond simple fade ins and fade, outs will
eventually result in the specification of an amplitude envelope with
possibly infinite segments, usually declared as time/value pairs. This
is a big thing to implement, especially due to the unknown number of
segments I imagine.

best,
Peter

Re: [SoX-users] partial fade in

[Nicolas G. <ni...@gr...>]

Martin Guy <so...@fa...> wrote on 2025-07-19 22:50:
> It would be better if fade could be told to start (and/or end) at a 
> level higher than zero, such as
>
>      fade --min 30 --max 100

Yes, that's exactly what I would like.

> https://codeberg.org/sox_ng/sox_ng/issues/525 should be included in 
> sox_ng-14.7.0 in November 2025.

Looking forward to it. Thanks in advance :)

Nicolas

Re: [SoX-users] partial fade in

[Martin G. <so...@fa...>]

On 19/07/25 15:46, Nicolas Graner wrote:
> Hello all,
>
> I would like to ramp the volume of an audio file from a given level to
> full volume over a specified time interval. For instance, increase the
> level linearly from 30% at time t=0 to 100% at time t=10s. In other
> words, perform a fade in starting from a level greater than 0.
>
> I can do it by inserting an appropriate amount of silence before the
> beginning, performing a fade in, then removing the extra silence. But
> this seems unnecessarily complex, especially if the effect is to be
> applied at a time other than the beginning. Is there a better way to do
> it with SoX ?

One way would be to duplicate the track into one copy at a constant 
volume of 30% and the other with a fade-in from 0 to 70% and then mix 
them together but it seems like a bit of a contortion.

It would be better if fade could be told to start (and/or end) at a 
level higher than zero, such as

     fade --min 30 --max 100

with a little thought as to what that means when the fade shape is not 
linear.

https://codeberg.org/sox_ng/sox_ng/issues/525 should be included in 
sox_ng-14.7.0 in November 2025.


    M

[SoX-users] partial fade in

[Nicolas G. <ni...@gr...>]

Hello all,

I would like to ramp the volume of an audio file from a given level to
full volume over a specified time interval. For instance, increase the
level linearly from 30% at time t=0 to 100% at time t=10s. In other
words, perform a fade in starting from a level greater than 0.

I can do it by inserting an appropriate amount of silence before the
beginning, performing a fade in, then removing the extra silence. But
this seems unnecessarily complex, especially if the effect is to be
applied at a time other than the beginning. Is there a better way to do
it with SoX ?

Thanks for any help.
Nicolas

Re: [SoX-users] [solved] sox_ng 14.6.0.1

[Martin G. <mar...@gm...>]

On 29/06/25 15:15, Nicolas Graner wrote:
> Martin Guy <mar...@gm...> wrote on 2025-06-29 13:15:
>> On 28/06/25 22:54, Nicolas Graner wrote:
>>> when running sox_ng, I get :
>>> sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory
>> You probably need to
>>    sudo ldconfig
> Yes, it worked. Thanks a lot!
>
>> It will also be OK after a reboot.
> No. I tried rebooting before and it made no difference.


That's odd. I assume it does that only if you install new libraries then.

Anyway, I've added a gotcha to the INSTALL file, thanks for letting us know


    M

Re: [SoX-users] [solved] sox_ng 14.6.0.1

[Nicolas G. <ni...@gr...>]

Martin Guy <mar...@gm...> wrote on 2025-06-29 13:15:
> On 28/06/25 22:54, Nicolas Graner wrote:
>> when running sox_ng, I get :
>> sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory

> You probably need to
>   sudo ldconfig

Yes, it worked. Thanks a lot!

> It will also be OK after a reboot.

No. I tried rebooting before and it made no difference.

Nicolas

Re: [SoX-users] sox_ng 14.6.0.1

[Martin G. <mar...@gm...>]

On 28/06/25 22:54, Nicolas Graner wrote:

> when running sox_ng, I get :
>
> sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory
>
> What should I do?

You probably need to

    sudo ldconfig

so that the shared library presence index is updated.

It will also be OK after a reboot.


    M

Re: [SoX-users] sox_ng 14.6.0.1

[Nicolas G. <ni...@gr...>]

Hello all,

I'm trying to install sox_ng-14.6.0.1 from the tarball on Debian.

configure, make and make install run without errors.

Then, when running sox_ng, I get :

sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory

What should I do?

My config:
$ uname -a
Linux hypra-graner 5.5.0-0.bpo.2-amd64 #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64 GNU/Linux

TIA,
Nicolas

[SoX-users] sox_ng 14.6.0.1

[SoX NG <so...@fa...>]

A patch release is available for sox_ng-14.6.0 to

o Fix opusfile detection when using pkg-config
o Fix compilation of libdolbyb
o Fix compilation on MSYS2/MinGW with GCC 15.1
o Fix compilation on MacOS X with older SDKs
o Fix compilation on Sortix
o Fix compilation on AIX 7.3

https://codeberg.org/sox_ng/sox_ng/releases/tag/sox_ng-14.6.0.1

This is turning out to be a difficult one to get right; please report 
any other problems.

    M

Re: [SoX-users] sox_ng-14.6.0 released

[Martin G. <mar...@gm...>]

On 17/06/25 22:20, Sylvain Leroux wrote:
> The one feature it always lacked was good noise reduction. At the 
> time, Audacity was much better than Sox at removing mic and background 
> (mostly) white noise. Maybe there is an issue tracker where I might 
> ask that for the next feature release?


Noise reduction or noise removal? For removal of mic and background 
coloured noise, you need noiseprof and noisered which are already in 
stock sox.


    M

Re: [SoX-users] sox_ng-14.6.0 released

[Sylvain L. <sy...@ch...>]

17 juin 2025 20:16:51 SoX NG <so...@fa...>:

> Well, we seem to have shaken 14.6 out over the last month
> and 14.6.0 is now up at
> 
>     https://codeberg.org/sox_ng/sox_ng/releases
> 
> Apart from the last six months' enhancements, bug fixes and relaxations,
> the most interesting additions are two new effects and
> a new combine method for synth.
> 
> Effect dolbyb is the big one, something people have been hankering for
> for some time now, and its frequency response curves, though not as
> exact as commercial offerings such as DDiCodec claim, are surprisingly
> close to those of a Nakamichi NR-200. We have yet to see how close its
> reactions in the time domain are to the real thing but as it is a digital
> simulation of real Dolby B electronic circuitry, my expectations are good.
> 
> The tricky part is adjusting its response to whatever level the tape was
> digitized at; a real tape deck knows what voltages represent the "Dolby level"
> on the tape itself, corresponding to the saturation level of the tape itself,
> but when it's been digitized through a preamp and the sound card's mixer,
> the level could be anything, which is what its "threshold gain" parameter
> is for. As yet, listening tests at a variety of levels is the best we have
> but are hoping to be able to semi-automate an initial guess for it.
> 
> The second new effect is "softvol". If one of those is in the effects chain,
> the 'v' and 'V' keys in interactive mode (i.e. when it's called as "play_ng")
> adjust the volume while it's playing, something that seems to have stopped
> working when it's trying to adjust the volume in the sound card's mixer,
> and it goes far over "to 11", limiting itself only when the audio would
> have clipped.
> 
> Its other optional parameter slowly increases the volume, again limited to
> when the audio would have clipped. This not only lets you play a range of
> tracks recorded at different levels and adjusts them all to about the same
> volume, but brings out the quiet passages. My personal favourite is
> "softvol 400 10" which gradually increases the volume so that it doubles
> in ten seconds if everything is quiet, but it starts at 40,000% of normal volume
> giving a strange emphasis to the opening moments of the track, which may contain
> something quiet but interesting and at worst make a track start with a burst.
> 
> Lastly, the "synth vdelay" option uses the synthesized wave as an offset
> into a delay line of the input signal, which allows the creation of a range
> of custom choruses and phasers as well as some strange other effects.
> 
> An example of softvol and vdelay in action can be found under
> http://martinwguy.net/test of which Osage Extension is the apparently
> silent second half of the leadout of the film "Killers of the Flower Moon"
> but which is actually something very very quiet: a fly passes,
> distant thunder rolls, wolves howl in the distance, all overlaid with
> the MP3 noise of the original amplified to an audible level and all
> processed with a triangular vdelay to make it yodel by an octave and a half.
> Osage_Harper instead is a 6-minute track that this serendipitous discovery
> inspired a contemporary composer, David "Kawika" Harper, to create.
> 
> Thanks to the many developers who contributed changes included in this release
> and to the authors who pulled all the stops out to help me make the best
> we could of their work.
> 
> The next new-feature release, 14.7.0, is scheduled for November '25,
> and, in August, bug-fix releases to each of the 14.X release series.
> 
> All contributions, suggestions and reports of oddities are welcome.
> 
>     M
> 
> 
> 
> _______________________________________________
> Sox-users mailing list
> Sox...@li...
> https://lists.sourceforge.net/lists/listinfo/sox-users
Congratulations, and thanks to the team and all contributors. It is a pleasure seeing the revival of that project.

The one feature it always lacked was good noise reduction. At the time, Audacity was much better than Sox at removing mic and background (mostly) white noise. Maybe there is an issue tracker where I might ask that for the next feature release?

Best regards,
- Sylvain Leroux

[SoX-users] sox_ng-14.6.0 released

[SoX NG <so...@fa...>]

Well, we seem to have shaken 14.6 out over the last month
and 14.6.0 is now up at

     https://codeberg.org/sox_ng/sox_ng/releases

Apart from the last six months' enhancements, bug fixes and relaxations,
the most interesting additions are two new effects and
a new combine method for synth.

Effect dolbyb is the big one, something people have been hankering for
for some time now, and its frequency response curves, though not as
exact as commercial offerings such as DDiCodec claim, are surprisingly
close to those of a Nakamichi NR-200. We have yet to see how close its
reactions in the time domain are to the real thing but as it is a digital
simulation of real Dolby B electronic circuitry, my expectations are good.

The tricky part is adjusting its response to whatever level the tape was
digitized at; a real tape deck knows what voltages represent the "Dolby 
level"
on the tape itself, corresponding to the saturation level of the tape 
itself,
but when it's been digitized through a preamp and the sound card's mixer,
the level could be anything, which is what its "threshold gain" parameter
is for. As yet, listening tests at a variety of levels is the best we have
but are hoping to be able to semi-automate an initial guess for it.

The second new effect is "softvol". If one of those is in the effects chain,
the 'v' and 'V' keys in interactive mode (i.e. when it's called as 
"play_ng")
adjust the volume while it's playing, something that seems to have stopped
working when it's trying to adjust the volume in the sound card's mixer,
and it goes far over "to 11", limiting itself only when the audio would
have clipped.

Its other optional parameter slowly increases the volume, again limited to
when the audio would have clipped. This not only lets you play a range of
tracks recorded at different levels and adjusts them all to about the same
volume, but brings out the quiet passages. My personal favourite is
"softvol 400 10" which gradually increases the volume so that it doubles
in ten seconds if everything is quiet, but it starts at 40,000% of 
normal volume
giving a strange emphasis to the opening moments of the track, which may 
contain
something quiet but interesting and at worst make a track start with a 
burst.

Lastly, the "synth vdelay" option uses the synthesized wave as an offset
into a delay line of the input signal, which allows the creation of a range
of custom choruses and phasers as well as some strange other effects.

An example of softvol and vdelay in action can be found under
http://martinwguy.net/test of which Osage Extension is the apparently
silent second half of the leadout of the film "Killers of the Flower Moon"
but which is actually something very very quiet: a fly passes,
distant thunder rolls, wolves howl in the distance, all overlaid with
the MP3 noise of the original amplified to an audible level and all
processed with a triangular vdelay to make it yodel by an octave and a half.
Osage_Harper instead is a 6-minute track that this serendipitous discovery
inspired a contemporary composer, David "Kawika" Harper, to create.

Thanks to the many developers who contributed changes included in this 
release
and to the authors who pulled all the stops out to help me make the best
we could of their work.

The next new-feature release, 14.7.0, is scheduled for November '25,
and, in August, bug-fix releases to each of the 14.X release series.

All contributions, suggestions and reports of oddities are welcome.

     M

[SoX-users] sox_ng-14.6.0-rc1

[SoX NG <so...@fa...>]

I am happy to announce a release candidate for the second new-feature 
release of sox_ng

incorporating the best of many people's work over the last six months.


Download page: https://codeberg.org/sox_ng/sox_ng/releases


It has been tested on aarch, amd, arm, chrp, loongarch, mips, powerpc, 
riscv, sparc and x86 processors, 32- and 64-bit, big- and little-endian 
on AIX, AlmaLinux, AlpineLinux, Archlinux, CentOS, Debian, FreeBSD, 
MacOS X, NetBSD, OpenBSD, OpenSUSE, Rocky, Solaris and Ubuntu and 
compiled (but not tested) for Windows.


New features:

   o Read NSP format files
   o Read MSP2K (Akai sampler) format files
   o Read and write AIFC a-law and u-law encodings
   o Copy AIFF's MARK and INST chunks more often
   o Copy AIFC's MARK and INST chunks
   o Read and write DSF format and read DFF and WSD formats
   o Add the DSD-related "dop" and "sdm" effects
   o Add reading of Ogg FLAC files (with ffmpeg)
   o SDS format is now autodetected
   o MP3 with CRC protection and MP2 formats are now autodetected
   o AIFF format now supports ID3 tags
   o The ID3 "TCOM" (Composer) tag is now supported
   o Add "softvol" effect, a software gain that avoids clipping and 
maybe rises
   o Make the 'v' and 'V' keys prefer to adjust softvol if it is active
   o Add "dolbyb" effect to decode and encode Dolby B noise reduction
   o synth: Add "vdelay" combine method to phase-modulate by the synth wave
   o Remove the limit on the number of echo/echos stages (was 7)
   o Remove the limit on the number of channels that phaser can handle 
(was 4)
   o Raise the limit on the number of chorus stages from 7 to 256
   o Remove unnecessary limits on arguments to 
echo,echos,chorus,phaser,flanger
   o wget, wget2 and curl are sought at runtime instead of at build time and
     ./configure --with-curl now just makes it prefer curl to wget.
   o Make "echos" run 20% faster
   o Make --multi-threaded the default
   o Error messages have been harmonized. The best was
     sox_ng WARN chorus: chorus: warning >>> gain-out can cause saturation
   o When curl or wget fail to fetch a URL, decode the exit status to a 
message
   o Add flow diagrams to --help-effect 
chorus/compand/earwax/echo/echos/phaser

Bug fixes:

   o The "stats" effect's Bit-depth values have been revised to reflect
     what Bit-depth means and handle corner cases like -32768
   o Revise all effects' usage messages to the same format and more helpful
   o "echos" and "chorus" have never worked but now do what they say
   o "bend"'s logarithmic frequency curve is more closely logarithmic
   o Fix "silence" not to add a random selection of fragments at the end
   o "silence" no longer outputs a random selection of fragments at the end
   o Make "firfit" understand frequencies like "10k"
   o Read mono 8-bit MAUD files with an odd number of samples
   o Handle unknown odd-sized chunks in AIFF files
   o Detect and report read errors from short audio files
   o Detect and report write errors to audio files
   o When data read from a pipe is short, report stats for what there was
   o When an fatal error is detected, stop and exit non-zero in all cases
   o No formats or effects are experimental or deprecated any more
   o Multi-channel LADSPA plugins now work
   o The LD_LIBRARY_PATH change has been reverted (it bombed on Solaris)
   o Revert the "Unicode when writing id3 tags" patch which never worked
   o ffmpeg's ADX format is no longer autodetected (too many false 
positives)
   o Reject parameter values of NaN instead of dumping core
   o Correct the manual and make its mcompand example work


Thanks to the many people who actually did the work I've included here,

to the few who have really pulled all the stops out over the last six months

to help me make the best of their ideas and to the many testers and 
suggesters

who've pointed out sharp corners, holes in the road and good future 
directions.


Please test whatever you find most interesting and highlight problems of 
any kind


      M