sox-users Mailing List for SoX - Sound eXchange (Page 3)

On 05/02/25 20:38, Dr. Thomas Tensi via Sox-users wrote:
 > > I'm thinking of removing it as useless and distracting
 > > baggage.
 >
 > I think this is too extreme to just throw it out.

 > We had some discussion in issue 276
 > (https://codeberg.org/sox_ng/sox_ng/issues/276) what a good
 > sequential delay could be.
 >
 > So my preference would be to set up some sequential
 > delay where not all stages are fed with the same input
 > signal, but instead with some sum of previous stages...

As long as it does something that you can't do with any of
the current effects, and is generic enough to be able to
construct any of the kinds of delay we see in the literature:
multi-tap (which can probably already be done with "echo"
already, if with some effort) and feedback for example.

 > > There are other reasons to start thinking of a major
 > > release 15.0.0; nothing startling but a few
 > > non-backward-compatible changes are beckoning like making
 > > `silence` trim from the silence point instead of 0.02
 > > seconds after it,
 >
 > Which is wrong by any reasonable considerations ...
 >
 > > not something we can put in 14.X because at least one
 > > artist has already used this discrepancy to achieve the
 > > result they wanted.
 >
 > Hmm, I cannot see the use case for that behaviour.  Maybe
 > some playing around with the thresholds and the durations
 > could take care of that?

I think "silence" is so broken that we can't hold off from
changing it. It now doesn't regurgutate random fragments of
the input after the proper output but has other problems
still. Once we remove the random garply, the gate is open
for other fixes, but we should release them all at once
(in the next minor release in May probably, unless I remain
a fanatic about keeping any functional changes for a major release,
but that's increasingly seeming an untenable position for
"echos" and "silence").

 > > it is not a chorus, which is the addition of delayed
 > > and detuned version of the same signal; it is a simple
 > > flanger,
 >
 > Now you've lost me.  When you are modulating a delay line,
 > you will get a vibrato on the original signal with some
 > slight delay.

A real chorus takes one instrument sound and makes it sound like
there are several of them playing not entirely synchronously
and at very slightly different pitches.

See http://csounds.com/toots/#toot4 - Chorusing

In SoX that would be

sox -n out.au synth 10 saw 100 synth saw mix 101

for a chorus of a 100Hz tone with a wahwah frequency of one second
and a very different set of additional harmonics, with strong
ones at 25, 26, 50, 51, 75, 76, 125, 126 and so on and weaker
ones at every multiple of 1Hz (that's from looking at it on a
spectrogram. I don't understand why 25 should be special when
the inputs only have components of 100Hz, 101Hz and their multiples).

The SoX "chorus" effect does phase modulation which does
play with detuning but with a sawtooth modulator you get
a slightly higher and slightly lower version alternately,
and of a frequency difference that depends on the slope
of the modulator wave, not on it frequency.
With sine wave modulation, the frequency of the phantom
second instrument is the first one with a kind of vibrato
that makes its frequency wobble round the original, and
not even by an easily predictable amount, since it depends on
the slope of the delay modulation wave, not on its frequency,
and probably a few other parameters as well.

To mix with a constantly different frequency by that technique,
the modulation wave would need to be an ever-rising delay time,
which would make the original and choral voices get
progressively further out of sync with each other.

Yes, there are a lot of things called "chorus" out there
which are just modulated delay simply because it's cheaper
and easier to implement. A real chorus would need to
detune the signal, probably FFT-ing it, shifting the frequency
components up or down a bit and resynthesizing, and then mix.

 > The current fixed chorus does exactly that
 > with as many parallel stages as you like - at least 7.

Good. Getting rid of fixed size limits is also on the list and
the number of "echo" stages is now unlimited. Its maximum of
7 stages was a pointless fiction based on two misconceptions
by its author: that it worked internally in integers (it doesn't,
it works in floats) and that the maximum number of 24-bit signals
you can add together into a 32-bit word is 7 (it isn't, it's 255
or maybe 256).
"echos" has always has an unlimited number of stages AFAIK.

"chorus"' current limit of 7 stages may also be bogus or
at worst should be 255; I haven't looked hard at it yet.

 > What we were talking about in another thread is the
 > similarity of phaser and flanger.
 > The phaser effect is similar to a flanger,
 > but the comb-filtering is somewhat different.
 >
 > So as already mentioned we should leave the chorus, but
 > replace the phaser (or leave it for compatibility reasons as
 > is and add a "fazer" effect as you had proposed).

and to avoid confusion, let "the SoX chorus effect" mean
the time-modulated delay thing, "khorus" mean the mixing of detuned
signals and plain "chorus" a vague term that has been applied
to many different effects (and not just these two - every
guitar pedal is different!)

 > https://en.wikipedia.org/wiki/Chorus_(audio_effect)
 >
 >     The effect is achieved by taking an audio signal and
 >     mixing it with one or more delayed copies of itself. The
 >     pitch of the added voices is typically modulated by an
 >     LFO, which is implemented similarly to a flanger, except
 >     with longer delays and without feedback.

Yeah. Whoever wrote that only knew about the modulated delay lines
that are so commonly used to make an affordable effect.
For a real chorus you have to hire several dozen singers
instead of paying one and putting them through a guitar pedal!

 > In my opinion the current chorus is a "real chorus", but I'm
 > happy to be corrected.

It's my pleasure :)

    M


Just joking. I don't have the truth in my pocket either.

On 05/02/25 19:51, Joe Weaver wrote:
 > I am all for making `silence` trim from the silence point
 > and not some bizarre offset.  It should be exact.
 > And if someone wrote something with it oddly offset,
 > it should be fixable on their end to work with it the way it should be.

It should be, but it isn't. It's not an easy decision to make
when you know that, by being finickity and perfectionist
you can mess up other people's existing work and that they,
of whoever is using what they did may never notice... except
that something doesn't work for inecplicable reasons any more.
And SoX is so old that it has been used a *lot*, also in serious
situations, not only for for tinkering and experimemtation.

The only sidecases are when, like echos and chorus,
they have obviously never worked at all, or when making
a major release in which you are allowed to break things,
but even then it's a close call, forcing people to keep
several versions of it lying around and know which one
to use when.


    M

Thanks to all for the input. I'll reply separately to the points in each.


On 05/02/25 19:13, Doug Lee wrote:

 >> 2) It is exactly the same as "echo" with different (and more) parameters
 > I thought it differed from echo in that successive echos created by 
"echos" are included in what is fed into
 > the next echo in the effect. This would indeed mean that inputs to 
second and subsequent echos are replaced,
 > as part of the function of the effect.

echos does this (you need fixed-width font here!)

    In--+--------+-------------------+-------------------->|   |
        |        |                   |           * gain-in |   |
    ____v___    _v_     ________    _v_     ________       |   |
   |        |  |   |   |        |  |   |   |        |      |   |
   | delay1 |  | + |-->| delay2 |  | + |-->| delayN |      | |
   |________|  |___|   |________|  |___|   |________|      |   | * gain-out
        |        ^          |        ^          |          | + 
|------------>
        |        |          |        |          |          | |         Out
        |        |          |        |          +--------->|   |
        |        |          |        |           * decay N |   |
        |        |          +--------+-------------------->|   |
        |        |                               * decay 2 |   |
        +--------+---------------------------------------->|   |
                                                 * decay 1 |___|

So yes, delay2in is (delay1out + In) but the net result is that
delay2out is (In delayed by delay2) + (In delayed by (delay1+delay2))
and these two are exactly equivalent:

sox_ng --no-dither in.au out.au echos .5 .5 1000 .5 300 .5
sox_ng --no-dither in.au out.au  echo  .5 .5 1000 .5 300 .5 1300 .5

and so on for 3 delays etc.

In fact, the test suite tests specifically that to test echo and echos
against each other. (I say sox_ng, not sox, only because that's
the only place it actually works!)

If the echo-in-series effect is in fact what you need,
it can be considered a syntactic shorthand, but I doubt that anyone
ever needs specifically that. There's nothing like that in the DSP 
literature
or in any other package that I know of.

 > Didn't know that either, but I do use the silence effect often,
 > and probably sometimes with unusual parameters - like durations of 0.

The more I hear of the silence effect, the more problems I hear it has.
I found out today that if you have audio that peaks midway at -1dB,
to remove everything after (or before) that peak, you have to specify
-3.95dB. -3.94 leave the entire recording intact.


 > my failure to weigh in before the "filter" effect was removed
 > because I subsequently tried to use the FM broadcast filter example 
out of the
 > manual only to find I didn't know how to replace that effect in the 
example.

I didn't know about that; I wasn't following SoX in 2011.
If it did something you needed it can probably be put back now
though I haven't even looked at what it did yet.

In general I am against removing stuff, or even making it work "better"
because someone on the other side of the planet will have used what
it does to create a piece of music or in a script or called from another
program, and changing/removing stuff is a great way to break other
people's work by remote control, without even knowing you're doing it.

For example, there are compositions written in Csound in the 1980s
that render bit-perfect with today's Csound the same as they did
when they were written under MS/DOS.

In my case, I wanted to test many different versions of SoX and
had to sniff the version numbers and select -2 and -c 2 acording
to how old it was. If they had kept honouring -2 as an alias,
even undocumented, it would have made thing easier.

Unfortunately there was a deprecation/removal frenzy some time

before 14.4.2 so it's a bit late now, but I would avoid another one.


     M

Hello SoX_NG,


you wrote:
 > `echos` is a bizarre effect that has never worked due to a
 > bug that overwrote the input samples before using them).

Agreed.

 > It's been "fixed" in sox_ng to do what it says in the
 > manual and comments but
 >
 > 1) It's odd, not a classic effect and seems more like a
 >    coding enthusiasm than a useful effect
 >
 > 2) It is exactly the same as "echo" with different (and
 >    more) parameters
 >
 > I'm thinking of removing it as useless and distracting
 > baggage.

Well, first of all thanks for your effort fixing it!

Nevertheless I think this is too extreme to just throw it
out.  We had some discussion in issue 276
(https://codeberg.org/sox_ng/sox_ng/issues/276) what a good
sequential delay could be.

So my preference would be to set up some sequential
delay where not all stages are fed with the same input
signal, but instead with some sum of previous stages...

 > There are other reasons to start thinking of a major
 > release 15.0.0; nothing startling but a few
 > non-backward-compatible changes are beckoning like making
 > `silence` trim from the silence point instead of 0.02
 > seconds after it,

Which is wrong by any reasonable considerations ...

 > not something we can put in 14.X because at least one
 > artist has already used this discrepancy to achieve the
 > result they wanted.

Hmm, I cannot see the use case for that behaviour.  Maybe
some playing around with the thresholds and the durations
could take care of that?

 > `chorus` has also never worked and has been fixed. Twice.
 > See the waveform images in comment
 >
 > https://codeberg.org/sox_ng/sox_ng/issues/276#issuecomment-2581801

 > but it is not a chorus, which is the addition of delayed
 > and detuned version of the same signal; it is a simple
 > flanger,

Now you've lost me.  When you are modulating a delay line,
you will get a vibrato on the original signal with some
slight delay.  The current fixed chorus does exactly that
with as many parallel stages as you like - at least 7 😉 -
(each constituting a parallel "voice").

In contrast, Rob Sykes' flanger only has a single modulated
delay line with a feedback loop, so as a flanger it's
similar to a chorus, but you will have to play around to
recreate a chorus by several flangers and with no feedback
applied.

 > of which we already have a much better one by Rob
 > Sykes, which can probably be parameterized to do the same
 > as `chorus`,

What we were talking about in another thread is the
similarity of phaser and flanger.  The current "phaser" uses
a single modulated delay line and this is by definition a
"flanger".  A real phaser consists of a number of
allpass-filter stages that do a frequency dependent phase
shift.  The phaser effect is similar to a flanger, but the
comb-filtering is somewhat different.

So as already mentioned we should leave the chorus, but
replace the phaser (or leave it for compatibility reasons as
is and add a "fazer" effect as you had proposed).

 > So, if a major release is looming, we could replace the
 > flanging `chorus` with a real chorus.

For a reference you will find the following paragraph in
https://en.wikipedia.org/wiki/Chorus_(audio_effect)

     The effect is achieved by taking an audio signal and
     mixing it with one or more delayed copies of itself. The
     pitch of the added voices is typically modulated by an
     LFO, which is implemented similarly to a flanger, except
     with longer delays and without feedback.

In my opinion the current chorus is a "real chorus", but I'm
happy to be corrected.


Best regards,
Prof. Spock

I am all for making `silence` trim from the silence point and not some
bizarre offset.  It should be exact.  And if someone wrote something with
it oddly offset, it should be fixable on their end to work with it the way
it should be.

I have never used the other effects.

On Wed, Feb 5, 2025 at 10:24 AM SoX NG <so...@fa...> wrote:

> `echos` is a bizarre effect that has never worked due to a bug
>
> that overwrote the input samples before using them).
>
> It's been "fixed" in sox_ng to do what it says in the manual and
> comments but
>
> 1) It's odd, not a classic effect and seems more like a coding
> enthusiasm than a useful effect
>
> 2) It is exactly the same as "echo" with different (and more) parameters
>
> I'm thinking of removing it as useless and distracting baggage.
>
>
> There are other reasons to start thinking of a major release 15.0.0;
>
> nothing startling but a few non-backward-compatible changes are beckoning
>
> like making `silence` trim from the silence point instead of 0.02
> seconds after it,
>
> not something we can put in 14.X because at least one artist has already
>
> used this discrepancy to achieve the result they wanted.
>
>
> `chorus` has also never worked and has been fixed. Twice.
>
> See the waveform images in comment
>
> https://codeberg.org/sox_ng/sox_ng/issues/276#issuecomment-2581801
>
> but it is not a chorus, which is the addition of delayed and detuned
> version of the same signal;
>
> it is a simple flanger, of which we already have a much better one by
> Rob Sykes,
>
> which can probably be parameterized to do the same as `chorus`,
>
> So, if a major release is looming, we could replace the flanging
> `chorus` with a real chorus.
>
>
> 14.4.X and 14.5.X should probably leave them making the same horrible
> noises as before
>
> and in theory 14.6 should too. Whether making them work as described is
> a bug fix or a
>
> non-backward-compatible change is debatable. Sorry, I worry about these
> things.
>
>
> So my question is: despite the fact that neither `echos` nor `chorus`
> has ever worked,
>
> has anyone ever used them to advantage? i.e. Is there any reason to keep
> them?
>
>
>      M
>
>
>
> _______________________________________________
> Sox-users mailing list
> Sox...@li...
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

On Wed, Feb 05, 2025 at 04:23:17PM +0100, SoX NG wrote:
> `echos` is a bizarre effect that has never worked due to a bug
> that overwrote the input samples before using them).

I used it but never for anything intense, and I never knew that! But see below.

> It's been "fixed" in sox_ng to do what it says in the manual and comments but
> 
> 1) It's odd, not a classic effect and seems more like a coding enthusiasm than
> a useful effect
> 
> 2) It is exactly the same as "echo" with different (and more) parameters

I thought it differed from echo in that successive echos created by "echos" are included in what is fed into
the next echo in the effect. This would indeed mean that inputs to second and subsequent echos are replaced,
as part of the function of the effect. Given this, I wonder if what you found is a bug or a feature. :-)

> I'm thinking of removing it as useless and distracting baggage.

I don't have a strong opinion on that, since I've rarely used it and not for anything critical.

> There are other reasons to start thinking of a major release 15.0.0;
> 
> nothing startling but a few non-backward-compatible changes are beckoning
> 
> like making `silence` trim from the silence point instead of 0.02 seconds
> after it,

Didn't know that either, but I do use the silence effect often, and probably sometimes with unusual
parameters - like durations of 0.

> not something we can put in 14.X because at least one artist has already
> used this discrepancy to achieve the result they wanted.

This is where I will briefly whine (good-naturedly of course) about my failure to weigh in before the
"filter" effect was removed, because I subsequently tried to use the FM broadcast filter example out of the
manual only to find I didn't know how to replace that effect in the example.

> `chorus` has also never worked and has been fixed. Twice.
> 
> See the waveform images in comment
> 
> https://codeberg.org/sox_ng/sox_ng/issues/276#issuecomment-2581801
> 
> but it is not a chorus, which is the addition of delayed and detuned version
> of the same signal;
> 
> it is a simple flanger, of which we already have a much better one by Rob
> Sykes,
> 
> which can probably be parameterized to do the same as `chorus`,

Can't speak to that, but I *can* say that chorus has baffled me for years because it never seemed to do what
I intuitively expected.


-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
In laughter, love is found; but in tears, it is forged.  (12/09/01)

`echos` is a bizarre effect that has never worked due to a bug

that overwrote the input samples before using them).

It's been "fixed" in sox_ng to do what it says in the manual and 
comments but

1) It's odd, not a classic effect and seems more like a coding 
enthusiasm than a useful effect

2) It is exactly the same as "echo" with different (and more) parameters

I'm thinking of removing it as useless and distracting baggage.


There are other reasons to start thinking of a major release 15.0.0;

nothing startling but a few non-backward-compatible changes are beckoning

like making `silence` trim from the silence point instead of 0.02 
seconds after it,

not something we can put in 14.X because at least one artist has already

used this discrepancy to achieve the result they wanted.


`chorus` has also never worked and has been fixed. Twice.

See the waveform images in comment

https://codeberg.org/sox_ng/sox_ng/issues/276#issuecomment-2581801

but it is not a chorus, which is the addition of delayed and detuned 
version of the same signal;

it is a simple flanger, of which we already have a much better one by 
Rob Sykes,

which can probably be parameterized to do the same as `chorus`,

So, if a major release is looming, we could replace the flanging 
`chorus` with a real chorus.


14.4.X and 14.5.X should probably leave them making the same horrible 
noises as before

and in theory 14.6 should too. Whether making them work as described is 
a bug fix or a

non-backward-compatible change is debatable. Sorry, I worry about these 
things.


So my question is: despite the fact that neither `echos` nor `chorus` 
has ever worked,

has anyone ever used them to advantage? i.e. Is there any reason to keep 
them?


     M

On Jan 20 15:30:29, dg...@dl... wrote:
> On my Mac Mini (details below), the following simple command
> starts hanging more and more often the longer I
> run the machine without a reboot:
> sox --buffer 512 -n -d synth 1 sin 440

I suspect macOS's audio subsystem and
SoX's very outdated support for it.

Can you reproduce the problem with the latest SoX?
The homebrew version, though patched, is extremely old.

Also, run it with sox -V to see the debug messages, as in
sox -V5 --buffer 512 -n -d synth 1 sin 440 gain -6
and post the complete output here: both for
the successful run and for the hang.

> The buffer size reduction makes this happen sooner,
> but the issue can eventually happen without this I believe.

So does it ever occur without the --buffer option?
(Not that I think that is the problem.)

> When the hang occurs:
> * It is immediate with no output sound, though the SoX progress display does appear.
> * The progress counter does not advance.
> * Kill will not kill the process; kill -9 is required.
> * ps shows the status as S+, meaning foreground and in a less-than-20-second sleep.
> * nwchan is 0 and wchan is -

What does 'wchan' and 'nwchan' mean?
I don't see those in this here macOS's ps(1) or top(1) output.

> My Mac is running Monterey
> because it is too old to run a newer OS,

So what machine is it, exactly?
(Monterey is 2021, that's not old.)

> but this is a rather old problem. I am running SoX from Homebrew.

Try with the latest cvs.
(Or one of the resurrected versions
mentioned on this list in the last year.)

> In case it matters, my default output device is a Turtle Beach USB
> sound card, though I don't think the device changes this issue.

Have you tried? Does it ever occur using the machine's native device?
(What is that native device, and why are you using the usb instead?)

> I do run Loopback but am not using it for default output.

Does it ever occur when you are not using Loopback?
(Not that I think it will make a difference,
but don't bring other variables into it.)

For reference, this is what SoX 14.4.2 (built from source) does on my
MacBook Air that has been running macOS 15.2 (Sequoia) for weeks now.

$ sox -V5 --buffer 512 -n -d synth 1 sin 440 gain -6
sox DBUG sox: Looking for a default device: trying format `coreaudio'
sox DBUG coreaudio: audio device did not accept 44100 sample rate. Use 48000 instead.
sox:	  SoX v
time:	  Aug  7 2024 16:53:02
uname:	  Darwin mb.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec	6 18:40:14 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T8103 arm64
compiler: gcc Apple LLVM 15.0.0 (clang-1500.1.0.2.5)
arch:	  1288 48 88 L
sox INFO nulfile: sample rate not specified; using 48000

Input File     : '' (null)
Channels       : 1
Sample Rate    : 48000
Precision      : 32-bit

sox DBUG coreaudio: audio device did not accept 44100 sample rate. Use 48000 instead.
sox INFO formats: can't set 1 channels; using 2

Output File    : 'default' (coreaudio)
Channels       : 2
Sample Rate    : 48000
Precision      : 25-bit
Sample Encoding: 32-bit Floating Point PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

sox DBUG effects: sox_add_effect: extending effects table, new size = 8
sox DBUG synth: type=sine, combine=create, samples_to_do=48000, f1=440, f2=440, offset=0, phase=0, p1=-1, p2=-1, p3=-1 mult=0
sox DBUG gain: mult=1
sox DBUG remix: 0:
sox DBUG remix: 	0 1
sox DBUG remix: 1:
sox DBUG remix: 	0 1
sox INFO sox: effects chain: input	  48000Hz  1 channels (multi) 32 bits unknown length
sox INFO sox: effects chain: synth	  48000Hz  1 channels (multi) 32 bits 00:00:01.00
sox INFO sox: effects chain: gain	  48000Hz  1 channels	      32 bits 00:00:01.00
sox INFO sox: effects chain: channels	  48000Hz  2 channels (multi) 32 bits 00:00:01.00
sox INFO sox: effects chain: output	  48000Hz  2 channels (multi) 25 bits 00:00:01.00
sox DBUG sox: automatically entering interactive mode
sox DBUG sox: start-up time = 0.076597
In:0.00% 00:00:01.00 [00:00:00.00] Out:48.0k [ =====|===== ]	    Clip:0
sox DBUG input: output buffer still held 128 samples; dropped.
Done.


	Jan

On Tue, Jan 21, 2025 at 09:02:07AM +0100, SoX NG wrote:

> On 21/01/25 08:49, SoX NG wrote:
> > There was an issue with coreaudio device naming which affected MacOS
> > 
> > https://codeberg.org/sox_ng/sox_ng/issues/167
> > 
> > fixed in sox_ng - trying sox_ng might pinpoint whether it is that or
> > something else.
> 
> 
> Hm. Homebrew takes 14.4.2 but its formula includes that patch picked from
> 80x24.org
> 
> However, there are many other bugfixes in sox_ng that may help.
> 
> Use the 14.5.0 series as 14.4.3.1 happened before the coreaudio patch went in.

Thanks much. Actually the reason I didn't give a version number is that my SoX, probably because of that
patch, doesn't give one either. I've stuck to this Brew version because of its built-in Opus support
(read-only is fine for me).


-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
Time is the friend of one who is true, and the enemy of one who isn't.
(02/05/2010)

On 13/01/25 20:07, Thomas Barth via Sox-users wrote:
>
> I use sox for converting and merging vox-files in a shell script. But 
> the vox files often have different duration in seconds and I want to 
> make sure that the shorter file always has the duration of the longer 
> file before merging.
>
> With soxi -D <file.vox> I get the length in seconds. If the 
> differences between the two files are greater than 2 seconds, I 
> calculate the stretch factor. The “problem” now is that the stretched 
> file is often longer than the longer file itself, e.g.
>
> soxi -D fileA.vox = 870.408000
> soxi -D fileB.vox = 868.360000
>
> stretch factor = 1.00235846883780920355
>
> The used command for stretching is:
>
> sox -r 8000 -t vox “$fileB” -r 8000 -t vox 
> “${work_dir}/fileB_stretched.vox” stretch “$factor”
>
> But the unexpected result of stretching this file is
>
> soxi -D ${work_dir}/fileB_stretched.vox = 875.197500
>
> I don't know how this inaccuracy is caused.


Long story short: yes, "stretch" does create a slightly longer file than 
is mathematically expected because it has a "drain" phase in which it 
empties out what's left in the delay line it uses to create the effect.


"tempo", despite having a drain phase, does seem to get the length as 
expected.


     M

On 21/01/25 08:49, SoX NG wrote:
> There was an issue with coreaudio device naming which affected MacOS
>
> https://codeberg.org/sox_ng/sox_ng/issues/167
>
> fixed in sox_ng - trying sox_ng might pinpoint whether it is that or 
> something else.


Hm. Homebrew takes 14.4.2 but its formula includes that patch picked 
from 80x24.org

However, there are many other bugfixes in sox_ng that may help.

Use the 14.5.0 series as 14.4.3.1 happened before the coreaudio patch 
went in.


    M

On 20/01/25 21:30, Doug Lee wrote:
> On my Mac Mini (details below), the following simple command starts hanging more and more often the longer I
> run the machine without a reboot:
>
> sox --buffer 512 -n -d synth 1 sin 440
>
> The buffer size reduction makes this happen sooner, but the issue can eventually happen without this I believe.
>
> When the hang occurs:
> * It is immediate with no output sound, though the SoX progress display does appear.
> * The progress counter does not advance.
> * Kill will not kill the process; kill -9 is required.
> * ps shows the status as S+, meaning foreground and in a less-than-20-second sleep.
> * nwchan is 0 and wchan is -
>
> My Mac is running Monterey because it is too old to run a newer OS, but this is a rather old problem. I am
> running SoX from Homebrew. In case it matters, my default output device is a Turtle Beach USB sound card,
> though I don't think the device changes this issue. I do run Loopback but am not using it for default output.

Hi!

   On cfarm104, a Mac Mini (2020), CPU Apple M1, arm64 architecture, 
MacOSX 12.6 21.6.0 with sox_ng-14.5.0 your command runs fine and 
immediately.

I don't know if it's making sound as it's on the other side of the 
planet - maybe it's squeaking in their machine room - nor how to find 
out what sound card it has (any clues how to find out without being 
root? There's no nothing likely-looking in /dev).


To see if it's a SoX internal issue or something to do with the sound 
card, could you try

sox --buffer 512 -n foo.wav synth 1 sin 440


Yes, SoX is often Ctrl-C-impervious; Ctrl-\ kills it.


There was an issue with coreaudio device naming which affected MacOS

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

fixed in sox_ng - trying sox_ng might pinpoint whether it is that or 
something else.

I'm building it using the regular tools with build dependencies 
installed under $HOME but I've built it successfully with homebrew in 
the past. That shouldn't impact the issue.


Also, what version of sox are you using? 14.4.2?


    M

On my Mac Mini (details below), the following simple command starts hanging more and more often the longer I
run the machine without a reboot:

sox --buffer 512 -n -d synth 1 sin 440

The buffer size reduction makes this happen sooner, but the issue can eventually happen without this I believe.

When the hang occurs:
* It is immediate with no output sound, though the SoX progress display does appear.
* The progress counter does not advance.
* Kill will not kill the process; kill -9 is required.
* ps shows the status as S+, meaning foreground and in a less-than-20-second sleep.
* nwchan is 0 and wchan is -

My Mac is running Monterey because it is too old to run a newer OS, but this is a rather old problem. I am
running SoX from Homebrew. In case it matters, my default output device is a Turtle Beach USB sound card,
though I don't think the device changes this issue. I do run Loopback but am not using it for default output.

-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
Freedom is not the ability to have what we want.  Freedom is merely the
ability to seek it.  To be free defines what we can do, not what we can get.
(03/28/05)

Yet another patch release for Windows, this time making reading URLs 
with wget/curl work

by reading wget's output in binary mode... and making reading from 
ffmpeg work on Unix

by *not* reading in binary mode (glibc's popen() fails if the mode is 
"rb"!)


Ah, Windows. Such fun.


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


     M

On Jan 13 20:07:12, sox...@li... wrote:
>>> I use sox for converting and merging vox-files in a shell script. But
>>> the
>>> vox files often have different duration in seconds and I want to make
>>> sure
>>> that the shorter file always has the duration of the longer file
>>> before
>>> merging.
>>
Or lie about the sampling rate by putting -r before the input file names

and then "rate" then all to the same srate before mixing?

If you care about voice timbre, there are pitch and bend

to readjust the tonality without affecting the duration.


    M

A reply like that is an almost perfect way
to make me not care.


On Jan 14 00:48:45, sox...@li... wrote:
> 
> Am 2025-01-13 21:19, schrieb Jan Stary:
> > On Jan 13 20:07:12, sox...@li... wrote:
> > > I use sox for converting and merging vox-files in a shell script.
> > > But the
> > > vox files often have different duration in seconds and I want to
> > > make sure
> > > that the shorter file always has the duration of the longer file
> > > before
> > > merging.
> > 
> > Why? You are not telling the whole story.
> 
> My fantasy story for you is: I work for the German secret service and
> monitor telephone conversations. The VOX files contain the recordings from
> side A and B respectively. Unfortunately, the technology is not perfect. For
> some reason, the recording of side A is usually somewhat slower, probably
> due to asynchronous processes in the background. In a 42-minute
> conversation, the difference _can_ be up to 20 seconds. That's why I try to
> stretch the recording with the shorter duration to the duration of the
> longer recording in order to get the dialog in sync.
> 
> The individual files are mono and with the merging it remains mono.
> 
> I had already tried the tempo option, but that didn't work at all.
> Stretching is not worthwhile when the difference is so small. A certain
> tolerance can be taken into account. However, I will make it dependent on
> the length in future.
> 
> chatgpt is an ideal helper (albeit with flaws) who doesn't ask superfluous
> questions and always tries to offer individual solutions and even spreads
> good vibes. I can't say that your text puts me in a good mood ;-) But thank
> you for taking the trouble to reply. It would have been your chance to show
> that humans can still be smarter than AI :) I'll keep experimenting with it
> until the result is perfect.
> 
> 
> _______________________________________________
> Sox-users mailing list
> Sox...@li...
> https://lists.sourceforge.net/lists/listinfo/sox-users
> 

If the difference-to-length ratio is small enough, maybe the speed effect would be enough - just requires a
bit of math to work out exactly. Which solution is best would depend on exactly what is and is not important
to you:

* Speed alters pitch but can get an exact length.
* Stretch and tempo can get the length but alter sound quality (more on these below).
* Delays at points of relative silence may also be used but would require more work (more on this below also).

Stretch and tempo alter sound quality in different ways, but both can be fine-tuned. Also their factor
parameters are inverses: stretch 2 makes a file twice as long, as does tempo .5. For tempo, -s may help you
if you are dealing with speech more than with complex sounds. (Aside: The person that said you aren't
telling the whole story was quite possibly asking for information like that - type of sound, range of file
length differences, etc.)

The delay idea is both more complex and, I think, less likely to be what you want; but it involves inserting
delays at acceptable points in the file to extend its length. This would probably be better done with a GUI
sound editor, since I rather doubt something like "trim 0 .5 delay .05 : restart" would yield anything
palatable. :)

On Tue, Jan 14, 2025 at 12:48:45AM +0100, Thomas Barth via Sox-users wrote:

Am 2025-01-13 21:19, schrieb Jan Stary:
> On Jan 13 20:07:12, sox...@li... wrote:
> > I use sox for converting and merging vox-files in a shell script. But
> > the
> > vox files often have different duration in seconds and I want to make
> > sure
> > that the shorter file always has the duration of the longer file
> > before
> > merging.
> 
> Why? You are not telling the whole story.

My fantasy story for you is: I work for the German secret service and monitor
telephone conversations. The VOX files contain the recordings from side A and
B respectively. Unfortunately, the technology is not perfect. For some reason,
the recording of side A is usually somewhat slower, probably due to
asynchronous processes in the background. In a 42-minute conversation, the
difference _can_ be up to 20 seconds. That's why I try to stretch the
recording with the shorter duration to the duration of the longer recording in
order to get the dialog in sync.

The individual files are mono and with the merging it remains mono.

I had already tried the tempo option, but that didn't work at all. Stretching
is not worthwhile when the difference is so small. A certain tolerance can be
taken into account. However, I will make it dependent on the length in future.

chatgpt is an ideal helper (albeit with flaws) who doesn't ask superfluous
questions and always tries to offer individual solutions and even spreads good
vibes. I can't say that your text puts me in a good mood ;-) But thank you for
taking the trouble to reply. It would have been your chance to show that
humans can still be smarter than AI :) I'll keep experimenting with it until
the result is perfect.

-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"There are no guarantees.  From a standpoint of fear, none are
strong enough.  From a standpoint of love, none are necessary."
- from Emmanuel's Book II

Am 2025-01-13 21:19, schrieb Jan Stary:
> On Jan 13 20:07:12, sox...@li... wrote:
>> I use sox for converting and merging vox-files in a shell script. But 
>> the
>> vox files often have different duration in seconds and I want to make 
>> sure
>> that the shorter file always has the duration of the longer file 
>> before
>> merging.
> 
> Why? You are not telling the whole story.

My fantasy story for you is: I work for the German secret service and 
monitor telephone conversations. The VOX files contain the recordings 
from side A and B respectively. Unfortunately, the technology is not 
perfect. For some reason, the recording of side A is usually somewhat 
slower, probably due to asynchronous processes in the background. In a 
42-minute conversation, the difference _can_ be up to 20 seconds. That's 
why I try to stretch the recording with the shorter duration to the 
duration of the longer recording in order to get the dialog in sync.

The individual files are mono and with the merging it remains mono.

I had already tried the tempo option, but that didn't work at all. 
Stretching is not worthwhile when the difference is so small. A certain 
tolerance can be taken into account. However, I will make it dependent 
on the length in future.

chatgpt is an ideal helper (albeit with flaws) who doesn't ask 
superfluous questions and always tries to offer individual solutions and 
even spreads good vibes. I can't say that your text puts me in a good 
mood ;-) But thank you for taking the trouble to reply. It would have 
been your chance to show that humans can still be smarter than AI :) 
I'll keep experimenting with it until the result is perfect.

On 13/01/25 21:19, Jan Stary wrote:
> On Jan 13 20:07:12, sox...@li... wrote:
>> I use sox for converting and merging vox-files in a shell script. But the
>> vox files often have different duration in seconds and I want to make sure
>> that the shorter file always has the duration of the longer file before
>> merging.


If I were going to stretch an audio file, I'd do it with DFTs and 
interpolation but SoX doesn't have that yet so we're left with a choice 
between two rather crappier algorithms to choose between.


That "stretch" doesn't get the overall time right is a separate issue so 
in the meantime, should we make what we've got work as it should?


If you file an issue, it will get fixed in finite time.


     M

On Jan 13 20:07:12, sox...@li... wrote:
> I use sox for converting and merging vox-files in a shell script. But the
> vox files often have different duration in seconds and I want to make sure
> that the shorter file always has the duration of the longer file before
> merging.

Why? You are not telling the whole story.

Is that always two files, both mono, being merged into stereo?
What is the use case, why are you doing the stretching?

Also, why are you using 'stretch' and not 'tempo'?
According to the manual, "its results are comparatively poor";
I'd say it's comparatively horrendous:

sox -r 8k -n file.vox synth 10 sin 440 gain -6 
sox -r 8k file.vox stretch.vox stretch 2.0 
sox -r 8k file.vox tempo.vox tempo 0.5
soxi file.vox stretch.vox tempo.vox
play file.vox stretch.vox tempo.vox

> With soxi -D <file.vox> I get the length in seconds. If the differences
> between the two files are greater than 2 seconds,

Why 2 seconds?
Why are you doing the stretching at all,
and why not if the lenght difference is 1.95s?

> I calculate the stretch factor. The “problem” now is that
> the stretched file is often longer than
> the longer file itself, e.g.
> soxi -D fileA.vox = 870.408000
> soxi -D fileB.vox = 868.360000
> 
> stretch factor = 1.00235846883780920355
> 
> The used command for stretching is:
> 
> sox -r 8000 -t vox “$fileB” -r 8000 -t vox “${work_dir}/fileB_stretched.vox”
> stretch “$factor”
> 
> But the unexpected result of stretching this file is
> 
> soxi -D ${work_dir}/fileB_stretched.vox = 875.197500

This seems to be more precise:

sox -r 8k -n fileA.vox synth 870.408 sin 440 gain -6
sox -r 8k -n fileB.vox synth 868.360 sin 440 gain -6
bc -e 'scale = 8 ; 868.360 / 870.408'             
sox -r 8k fileB.vox stretched.vox tempo .99764708
soxi fileA.vox fileB.vox stretched.vox 

Also, is this error specific to vox files?
Have you tried with wavs?

(I don't think it would make a difference,
as I believe the stretch effect itself is the culprit.)

> chatgpt says

Srsly, stop right here.


Jan

Hello,

I use sox for converting and merging vox-files in a shell script. But 
the vox files often have different duration in seconds and I want to 
make sure that the shorter file always has the duration of the longer 
file before merging.

With soxi -D <file.vox> I get the length in seconds. If the differences 
between the two files are greater than 2 seconds, I calculate the 
stretch factor. The “problem” now is that the stretched file is often 
longer than the longer file itself, e.g.

soxi -D fileA.vox = 870.408000
soxi -D fileB.vox = 868.360000

stretch factor = 1.00235846883780920355

The used command for stretching is:

sox -r 8000 -t vox “$fileB” -r 8000 -t vox 
“${work_dir}/fileB_stretched.vox” stretch “$factor”

But the unexpected result of stretching this file is

soxi -D ${work_dir}/fileB_stretched.vox = 875.197500

I don't know how this inaccuracy is caused. Is there a way to stretch it 
more accurately?

chatgpt says that the cause of the deviation is probably due to the 
block sizes of the VOX format or rounding errors when calculating the 
sample length. A precise solution requires either post-processing of the 
stretched file (e.g. with trim) or the use of a lossless format such as 
WAV for intermediate processing. However, I achieved the same result 
with these files in WAV format and I dont want to use trim.

Any idea?

There's a link in the SoX manual that points to a series of articles by 
Scott Lehman explaining effects that has disappeared from the web and is 
only partially archived on archive.org

  * Expansion/Noise Gating
    <https://codeberg.org/sox_ng/sox_ng/wiki/Expansion>
  * Equalization <https://codeberg.org/sox_ng/sox_ng/wiki/Equalization>
  * Compression/Limiting
    <https://codeberg.org/sox_ng/sox_ng/wiki/Compression>
  * Phase Shifting (Phasing)
    <https://web.archive.org/web/20100110002107/http://www.harmony-central.com/Effects/Articles/Phase_Shifting/>
  * Ring_Modulation
    <https://codeberg.org/sox_ng/sox_ng/wiki/Ring_Modulation>
  * Chorus <https://codeberg.org/sox_ng/sox_ng/wiki/Chorus>
  * Delay <https://codeberg.org/sox_ng/sox_ng/wiki/Delay>
  * Reverberation <https://codeberg.org/sox_ng/sox_ng/wiki/Reverb>
  * Flanging <https://codeberg.org/sox_ng/sox_ng/wiki/Flanging>

Ive recovered it into the sox_ng wiki for those of you interested:

https://codeberg.org/sox_ng/sox_ng/wiki/EffectsExplained


Enjoy, and report any breakage


    M

I am happy (relatively speaking) to announce yet another patch release 
14.5.0.2


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


Bug fixes:

   o Make reading from ffmpeg work by popen()ing "rb"


Der. Geddit right [beans]


     M

I've finally bitten the bullet and made win32 exes of sox_ng-14.5.0

|New features: o Add Unicode support on Windows for filenames and 
command-line arguments Bug fixes: o Make it build for Windows using MXE|


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


Enjoy


      M

I am happy to announce sox_ng 14.5.0, its first minor (new feature) release


"For general audio file processing my preferred package is Sound 
eXchange (SoX),

there is almost nothing it can’t do with the audio data."

     - Scott Werner, in "Record replay RIAA correction in the digital 
domain"


New features:

o Add effect speexdsp with automatic gain control and noise reduction
o Auto-detect MP3 files
o If ./configured --with-ffmpeg and ffmpeg is installed, autoread formats:
   3g2, 3gp, aac, ac3, adts, adx, ape, apm, aptx, argo_asf, asf, ast, avi,
   dfpwm, dts, dvd, eac3, f4v, flv, gxf, ism, kvag, m4a, m4v, mkv, mlp,
   mp4, mpeg, mpegts, mxf, nut, oga (Ogg with FLAC data), ra, rm, rso, sbc,
   smjpeg, spdif, speex, svcd, tta, vag, vcd, vob, webm, wma, wsaud, wtv
   and yet more with -t ffmpeg
o Add "stat -a" to give the average power spectrum
o Add "spectrogram -n" flag to normalize its brightness
o Add "spectrogram -L" flag to give a logarithmic frequency axis
o Add "spectrogram -R" flag to specify the frequency range
o Raise spectrogram's height limit from 8193 to 200000 pixels
o Lower the minimum speed of the flanger effect from 0.1 to 0.01 Hz
o Make combine effects work when there's a single file
o riaa: Add 192kHz sample rate
o sphere format: Support ALAW encoding
o SD2 format: Support resource forks
o ID3 tags: Support unicode when writing
o WAV files: Read when the number of valid bits is less that the sample size
o Use posix_fadvise to increase readahead and double its speed
o Use FFTW to make non-2^n-size spectrograms a hundred times faster
o Resize Linux pipe buffers to make multi-threaded effects 10-80% faster
o Reduce sox -t pulseaudio --[input-]buffer latency from up to 2 secs to low
o Enable building to fetch URLs with curl instead of wget
o Be able to read files that are still being written by another process
o Make "make check" run the regression test suite
o Drop sox_version_info_t's "time" element to get reproducible builds
o Remove the undocumented and useless "divide" effect
o Enhance ./configure --enable-stack-protector with =strong and =all and,
   with no --(en|dis)able-stack-protector option, pick the best available

Bug fixes:

o Fix coreaudio device name truncation on MacOS X
o Make it compile on Haiku and NetBSD and with gcc-2.95
o Americanize spelling in the manual
o Make "make installcheck" work again
o Fix the delay buffer full flag assigned during drain
o ./configure --with-{amrnb,amrwb,sndfile}=dyn --without-dyn-default
   used to link them statically instead
o Drop the unreliable pipe-rewinding libc hacks and do it in-house
o Fix bug introduced in sox_ng-14.4.3: au files with -t ao play short
o Fix segfault when --norm is passed with no parameter
o Fix compilation on AIX 7.1, Haiku, NetBSD, OpenBSD and with gcc-2.95


available from

https://codeberg.org/sox_ng/sox_ng/releases/download/sox_ng-14.5.0/sox_ng-14.5.0.tar.gz

md5sum: 4e0c8461be88c37153770342118c5c59
sha256sum: fcb34d043dca7f77ba18f169f99166e9ed14c8c26af84d3aaad2051af97501de


Thanks to all who contributed this work over the last nine years,

to the members of the SoX steering committee for guidance, and

to the people running the GCC Compile Farm for portability testing.


The next micro (bugfix) releases are scheduled for 2025-02-18 and there 
will be

more new stuff in the next minor release, scheduled for 2025-05-18.


     M


||