sox-users — SoX list to discuss end user topics

Re: [SoX-users] sox_ng-14.7.0 is out

[Dr. T. T. <t....@gm...>]

Hello Martin,


you wrote:
 > > Well, since there is no shared codebase between SoX_ng
 > > and the VST SoX-Plugins, I have to keep up with you
 > > somehow.
 > I can advise you when there are significant changes like
 > the recent attention that chorus, phaser and flanger have
 > gotten and new effects like "saturation" but apart from
 > that, yes, just making them an interface to libsox would
 > be one solution but I think the use of FP brings some
 > advantages worth keeping.

Thanks for this change, it's a really big improvement for
SoX.  (By the way, we both discussed this topic a long time
ago ;-)

Fortunately, the SoX-plugins have used double from the
beginning, as they are DAW plugins and are naturally
accustomed to completely disregarding the economical use of
resources.

And you don't need to inform me about changes, I'll find out
from your release notes. You have enough to do.


	Best regards,

		Thomas

Re: [SoX-users] sox_ng-14.7.0 is out

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

On Fri, 21 Nov 2025 at 19:08, Dr. Thomas Tensi via Sox-users
<sox...@li...> wrote:
> Well, since there is no shared codebase between SoX_ng and
> the VST SoX-Plugins, I have to keep up with you somehow.

I can advise you when there are significant changes like the
recent attention that chorus, phaser and flanger have gotten
and new effects like "saturation" but apart from that, yes,
just making them an interface to libsox would be one solution
but I think the use of FP brings some advantages worth keeping.

   M

Re: [SoX-users] sox_ng-14.7.0 is out

[Dr. T. T. <t....@gm...>]

Hello Martin,


you wrote:
 > > [Prof. Spock has to ensure the absolute compatibility of
 >    the SoX-Plugins]
 > Not sure precisely what you are referring to but I've been
 > looking at the libtool libltdl dynamic formats ("SoX
 > plugins") stuff recently, which is how LADSPA plugins are
 > found and loaded; presumably loading and usinng VST ones
 > should be possible too, more your area than mine :)

Well, since there is no shared codebase between SoX_ng and
the VST SoX-Plugins, I have to keep up with you somehow.

A simple solution would be to just use SoX_ng as a library
and only provide a graphical DAW interface.  However, since
I have invested so much time in the C++ renovation of the
original SoX code, I do not want to just throw that work
away.  And in my opinion, that would also be unsportsmanlike
;-)

Nevertheless, your implementation is the reference and
although I am not copying it, I need to ensure that the
output of my implementation does not differ too much from it
(the often-mentioned acceptable difference of -100dB between
the signals).

But in summary: keep up the good work!


	Best regards,

		Thomas

Re: [SoX-users] sox_ng-14.7.0 is out

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

On Fri, 21 Nov 2025 at 13:34, Dr. Thomas Tensi via Sox-users <
sox...@li...> wrote:

> Have you changed the parameter ranges of the effects
> recently?
>
> Looking at the code, I noticed that phaser out_gain now has
> a limit of 1, for example, while the original ("Jürgen
> Müller") SoX code had a limit of 1E9.
>

Ah, so it was HUGE_VAL. I'll put that back.
Or you can as you have write access on the repository.
Whoever gets there first.

That type of change affects some of my automated rendering
> configurations

My deepest apologies. One of the troubles of open source is that
you can break everybody else's worlds by remote control.
Once you realise, you can revert to the last version where it is
as it was.

> the absolute compatibility of the SoXPlugins

Not sure precisely what you are referring to but
I've been looking at the libtool libltdl dynamic formats ("SoX plugins")
stuff recently, which is how LADSPA plugins are found and loaded;
presumably loading and usinng VST ones should be possible too,
more your area than mine :)

Onward!

   M

Re: [SoX-users] sox_ng-14.7.0 is out

[Dr. T. T. <t....@gm...>]

Hello Martin,


thank you for your ongoing efforts to keep SoX alive, and
please excuse me for complaining without contributing in
the last time, but I have a question.

Have you changed the parameter ranges of the effects
recently?

Looking at the code, I noticed that phaser out_gain now has
a limit of 1, for example, while the original ("Jürgen
Müller") SoX code had a limit of 1E9.

I can understand that this might be significant if the output
were fed directly into the delay line (but you have the rule
check anyway), but in my mental model, out_gain is only
a factor for the output line.

That type of change affects some of my automated rendering
configurations, as they use the "old" parameter convention
for the effects. Of course, this could easily be fixed by
inserting subsequent gain stages, but in my opinion, there
is no reason to restrict the range so much.

Furthermore, I find it difficult to keep up with you in
terms of the absolute compatibility of the SoXPlugins, as
you are as busy as a bee and I am lazy and currently
preoccupied with other issues.


	Best regards,

		Thomas (aka Prof. Spock)

[SoX-users] sox_ng-14.7.0 is out

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

with much the same as the +git release of a few days ago, slightly fixed.

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

    M

Re: [SoX-users] Interim release sox_ng-14.6.1+ git20251115

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

http://martinwguy.net/test

Der

[SoX-users] Interim release sox_ng-14.6.1+ git20251115

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

I'm happy to announce another bleeding edge interim git release,
three days before we start another endless cycle of release candidates
on the 18th.

The area that have sustained the most damage since the last +git is MPEG audio.

It now knows the difference between MP1, MP2 and MP3, and sndfile
decoding and encoding of these. Only encoding to MP2 with sndfile
doesn't work, but it uses twolame too, so no great loss.
Its mp3 encoding gets the length right though and decoding uses
libmpg123 instead of MAD so may give different quality results
and be able to decode broken files that MAD chokes on or gets wrong.
If MP2s not made by Twolame are rare, MP1 files are like hens' teeth;
I've put those I could find up under http://nartinwguy/test
and one of the MP1s even contains a cover art image.

Like the last +git, you should also be able to
* adjust MP2's variable bit rate encoding using -C from -10 to +10
* encode audio with more than two channels to MP2 and MP3;
  it should mix them down to stereo instead of failing;
* encode to MP2 with a sample rate below 16kHz;
  it should automatically resample to 16kHz instead of failing.

It has gained new dithering filter shapes from SSRC so there is now
dither -f shibata-A0 to -B6 for two alternate Lowest Threshold of Hearing
curves at seven severities, mostly for output at 44100 and 48000Hz only but
with A0 to A2 at 88k, 96k and 192kHz and shibaba-A-saturated at 8, 11 and 22
only. Thanks to danadam for most of this work; I only added the other rates
and hope I got them right. Details and graphs at Naoki Shibata's
https://shibatch.org/ssrc and danadam's excruciatingly precise test graphs at
https://codeberg.org/sox_ng/sox_ng/issues/493

Another thing that would enjoy testing is the new `saturation` effect
that makes "from subtle warmth to crunchy fuzz" applying a sqrt, tanh or diode
soft clipping function at adjustable severities. Hats off to akwizgran.
The only major mod I made to the original pull request was to convert it
from doubles to floats internally, which made it 40% faster and the results
before and after differ nowhere more than one sample value in a few places
at 16-bit and at 24.

It should also now die when you hit Ctrl-C when it's reading from stdin,
from a pipe or reading an m3u playlist containing URLs instead of just
sitting there staring at you and --version is SoX_ng v14.6.1+git20251115
instead of claiming to be 14.6.1.

Thanks to the numerous new bug reports, of which the strangest is
synth immediately followed by reverb outputting 10dB quieter than normal.
The cause is unknown but the workaround is to insert "gain 0" between them.
If anyone fancies having a look at this there is now
https://codeberg.org/sox_ng/sox_ng/wiki/Mult on what SOX_EFF_GAIN seems to do
and how the gain -h ... gain -r automatic gain compensation seems to work.
If anyone knows more about this area of SoX internals, do correct me.

All other user-visible changes since 14.6.1 are listed on
https://codeberg.org/sox_ng/sox_ng/releases

Looking forward to knowing where it's broken and any other pending
new features or fixes that are ready but that I've forgotten about,
I give you the

```
md5sums:
4577ed4c80cebc85f91e846f42135ae3  sox_ng-14.6.1+git20251115.tar.gz
8c6a3ec9d88a2a8558e4786f8b45ef75  sox_ng-14.6.1+git20251115.zip
c0dcca7fb1d2440d2c37f600e4570a40  sox_ng-14.6.1+git20251115-win32-exe.zip
6604c5ae0cc0b576b01e736006a36fcb  sox_ng-14.6.1+git20251115-win64-exe.zip
sha256sums:
0eca9de5169524b4b079ed3c7389b19de857a969362d3ea528f934f569f39daa
sox_ng-14.6.1+git20251115.tar.gz
1b95b59613784226c0e564bdb957a4ea54e82590f66e5329e84f6ccc63087780
sox_ng-14.6.1+git20251115.zip
f56d84be27bf9a120c65d2a6234d82f1f72984b93eacc7a3587951a09f11b2d2
sox_ng-14.6.1+git20251115-win32-exe.zip
8d5990314e3439319b5d8ad4fccc2eb57efc4a2d16a6d4395dbc499670ff9cb9
sox_ng-14.6.1+git20251115-win64-exe.zip
```

and appreciate the gentle tolerance of occasional craziness.

    M

[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