sox-users — SoX list to discuss end user topics

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

Re: [SoX-users] Silence with lead-in time kept?

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

On 29/04/25 17:31, Doug Lee wrote:

> I've often wanted silence to allow for a certain amount of sound prior to the end of a silence period to be
> kept. silence -l handles the opposite, keeping sound after silence begins; so maybe -L?
>
> silence -l -L.5 1 .2 1% -1 .2 1%
>
> would keep 0.5 seconds of sound before each non-silent period. This avoids loss of lead-in sounds that,
> while short, are definitely noticed by the ear - start of air flowing through a trumpet or pipe organ, the
> consonant before a loud spoken vowel, etc.


You can probably achieve the same result by reversing the audio,

silencing it with -l and reversing again but I wouldn't want to force

people to do that; it should be a relatively simple change to make.


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


Thanks for the suggestion!


     M


This message was composed with Thunderbird, so if the lines are

backwards or on top of each other, please apply the appropriate filters.

[SoX-users] Silence with lead-in time kept?

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

I keep forgetting to suggest this, and I know the silence effect has been discussed already a time or two, but...

I've often wanted silence to allow for a certain amount of sound prior to the end of a silence period to be
kept. silence -l handles the opposite, keeping sound after silence begins; so maybe -L?

silence -l -L.5 1 .2 1% -1 .2 1%

would keep 0.5 seconds of sound before each non-silent period. This avoids loss of lead-in sounds that,
while short, are definitely noticed by the ear - start of air flowing through a trumpet or pipe organ, the
consonant before a loud spoken vowel, etc.


-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"You must let me try, for a true soldier does not admit defeat before
the battle."
--Helen Keller (in a letter to the president of Radcliffe College)

Re: [SoX-users] R: R: Comment ID3 tag not read

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

On 28/04/25 09:52, bandiera.marco_2006--- via Sox-users wrote:


> In fact I am absolutely not able to program these effects

I guessed maybe that :)

> I only propose their creation because I think they would be useful.


Thanks, and I'm sure many people agree with you, but only

already-implemented effects are practical.  An EBU-R128

loudness measurement also has some support, and

libebur128 does exist, but it's not strongly enough felt

to result in anyone actually putting up some dough

to encourage someone to do it.

(and probably not me unless that it specifically requested;

I have rather a lot of easier (hence giving more for less) stuff

on the list.)


> https://integraudio.com/5-best-reverb-removal-plugins/

Right, so the math theory on how to do it is there, but those

are all closed-source buy-me-only executable blobs so unless

there's something similar in, say, Audacity or something, it's

all work to do. Just translating and adapting dolbybcsoftwaredecode

into libdolbyb has taken weeks full-time, and that's with

the algorithm already coded and with considerable help

from the original author.


     M

[SoX-users] R: R: Comment ID3 tag not read

[<ban...@li...>]

Thanks Martin.
In fact I am absolutely not able to program these effects; I only propose their creation because I think they would be useful.
I have no idea how a de-reverb could work, but certainly there are those who have tried to create it:
https://integraudio.com/5-best-reverb-removal-plugins/

Marco

-----Messaggio originale-----
Da: Martin Guy <mar...@gm...> 
Inviato: domenica 27 aprile 2025 11:37
A: sox...@li...
Oggetto: Re: [SoX-users] R: Comment ID3 tag not read

> What do you think about the following effects:
> - XTC ambiophonic
> - de-reverber?


I'm sure other people would also find them useful.

Let me know when they're ready! :)


Or, if you're not into DSP programming yourself, you can

submit issues for them possibly with links and/or

notes on how to implement them and see if anyone bites;

maybe put a bounty on them if that's your thing.


How on earth does a de-reverber work?


    M



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

Re: [SoX-users] R: Comment ID3 tag not read

[Jeremy N. - ml s. u. <jn....@wi...>]

On 2025-04-27 10:37, Martin Guy wrote:

> How on earth does a de-reverber work?

I expect you use a Tardis to get access to the original
untreated sound.

-- 
Jeremy Nicoll - my opinions are my own

Re: [SoX-users] R: Comment ID3 tag not read

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

> What do you think about the following effects:
> - XTC ambiophonic
> - de-reverber?


I'm sure other people would also find them useful.

Let me know when they're ready! :)


Or, if you're not into DSP programming yourself, you can

submit issues for them possibly with links and/or

notes on how to implement them and see if anyone bites;

maybe put a bounty on them if that's your thing.


How on earth does a de-reverber work?


    M