sox-devel — SoX list to discuss development

[SoX-devel] sox_ng second micro release candidates

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

sox_ng-14.4.4-rc2 and 14.5.1-rc2 are ready for testing


Bug fixes since 14.4.4-rc1:

   o Fix reverb halving the audio length when input is mono
   o avr, txw: Fix false positive write errors
   o prc: Don't report read errors when reading a cardinal hits EOF
   o Report the correct parameter names in effects' syntax errors
   o Fix compilation with ibm-clang and on Solaris
   o Fix opus' failure to find its include files
   o Make compilation --with-dyn-defaults work again (broken since 14.4.2)


and in 14.5.1-rc2 also:


   o Reduce infinite chorus/echo(s)/flanger/phaser delay ranges to one 
second

   o Import janstary's improvements to the manual for libsox

   o Improve phaser's manual section
   o Fix a double free() when echoing stereo files



https://codeberg.org/sox_ng/sox_ng/releases/tag/sox_ng-14.4.4-rc2
https://codeberg.org/sox_ng/sox_ng/releases/tag/sox_ng-14.5.1-rc2


Please report any problems with them to me or to so...@gr...


If all is well in a week, they become the releases


     M

[SoX-devel] Effects Explained

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

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

[SoX-devel] SoX developments in sox_ng

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

Hi

    Discussion of changes to SoX's functionality seem to happen most now 
in their issue comments so I though I'd summarize the active ones here 
in case anyone wants to follow how SoX is evolving or has input.


    One has already been resolved by Rob: a change in the Bit-depth 
figures to fix a couple of bugs: that positive values should include the 
0 sign bit as a significant digit of the right hand value and that 
negative values' leading 1s do not count as significant digits for the 
left hand value (if I've understood it properly) plus a couple of corner 
cases like -32768. Oddly enough, the issue was raised in the sox.sf.net 
ticket tracker by someone who thought that the Bit-depth values should 
be the same for a signal and for the inverted version of it, which isn't 
true because 8 has one more significant digit than -8. A "fix" was even 
committed there to address it, so there are now three different versions 
of Bit depth figures, two wrong and one right. At least I hope it's 
right now!

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


   One is still being investigated, that the "echos" effect says it does 
one thing in the manual, says it does something else in the header 
comments in stats.c but in reality seems to do something different from 
either of these in reality, apparently very similar to what "echo" does. 
We're trying to find out what it does do in reality and which of the 
claimed functionalities is more useful, as well as thinking of two new 
echo effects: one the same as traditional guitar effects that repeat the 
echo forever and the other the already well-known "tapped delay" DSP effect.

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


Feel free to discuss here of course and I'll import the gems into the 
issue tracker, as I don't think there's an easy way to interact with 
issue comments from the command line.


     M

[SoX-devel] sox_ng-14.5.0-rc2

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

The second release candidate for sox_ng-14.5.0 is available at

https://codeberg.org/sox_ng/sox_ng/releases/tag/sox_ng-14.5.0-rc2


Changes:

o Fix compilation when there is LAME_ID3TAG but not ID3TAG
o Reinstate --disable-stack-protector and enhance --enable-stack-protector
with =strong and =all and, with no such option, pick the best available

md5sum: f95ab709ba38213f497b62282bb4f813
sha256sum: a36f35667bf7ba9a0e0b7d69b6ab1dbfa565e45fb7cfff33103b7582eff33ff4


Please test and enjoy


     M

[SoX-devel] Release candidate 14.5.0-rc1

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

I am happy to announce the first release candidate
of the first minor (new features) release of sox_ng
incorporating new work done over the last nine years.

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

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, loas, 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 Read files that are still being written to by another process
   o Enable building with libmpg123 instead of libmad (no seek support yet)
   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 Remove obsolete ./configure --disable-stack-protector

Bug fixes since 14.4.3.1:

   o Fix coreaudio device name truncation on MacOS X
   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
   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 Haiku, NetBSD, OpenBSD, AIX 7.1 and with gcc-2.95

Please test, especially the new features, and send problem reports
to so...@fa... or so...@gr... and if you feel that
some new feature is inappropriate to SoX, please object.

Thanks to everyone who has worked on SoX over time -
they are credited in the git log - and to the people who
run the marvellous GCC Compile Farm.

    M

Re: [SoX-devel] A sox pipe mystery

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

On 03/11/24 07:52, Martin Guy wrote:
>      sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f ircam -" 'Candy Toy.wav'
> 
> works but
> 
>      sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox -" 'Candy Toy.wav'
> 
> fails saying
> 
>     sox FAIL formats: can't open input  `-': can't find sox file format identifier

In case you tried this, found it worked and assumed that I'm mad...

Today, instead, all the failing cases worked fine and *I* thought I was 
mad. The only difference today was that I had a background process 
running 100% on one of the two CPUs. Stopped that, it failed again every 
time. With the background process running again it failed about once in 
seven runs, so is timing-dependent.

It turns out to be because ffmpeg writes a few bytes of WAV header to 
the pipe, sox reads them, ffmpeg writes again, sox reads again, and when 
the file autodetection code tries to rewind the pipe back to 0, stdio no 
longer has the initial data in its buffer.

It's resolved by dumping the pipe rewinding hacks completely and 
inplementing an in-house pipe rewinder that, when doing auto-detection 
from a pipe (the only use case of pipe rewinding), it remembers the 
first block of data and returns it again later before switching to 
regular stdio reading for the rest of the data.

I'm happy this bit me and seems resolved now because the plethora of 
different pipe rewinding hacks for different libc versions was getting 
silly and has caused no end of grief to maintainers of unusual distros.

Implemented as https://codeberg.org/sox_ng/sox_ng/commit/69751b3

     M

Re: [SoX-devel] A sox pipe mystery

[Eric W. <nor...@yh...>]

Martin Guy <mar...@gm...> wrote:
> Hi all
> 
>    I'm looking at launching external programs to decode a million other
> formats automatically and have run into a mystery I cannot fathom.
> 
> 
>     sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f ircam -" 'Candy
> Toy.wav'
> 
> works but
> 
>     sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox -" 'Candy
> Toy.wav'
> 
> fails saying
> 
>    sox FAIL formats: can't open input  `-': can't find sox file format
> identifier
> 
> as do
> 
>     -f wav   sox FAIL formats: can't open input  `-': WAVE: RIFF header not
> found
>     -f aiff  sox FAIL formats: can't open input  `-': AIFF header does not
> begin with magic word `FORM'
> 
> though
> 
>     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox -" > 'Candy Toy.sox'
> 
>     sox 'Candy Toy.sox' 'Candy Toy.wav'
> 
> works.
> 
> 
> Is it because ffmpeg is seeking back in the file and rewriting the header
> once it's decoded? Nope:
> 
>     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | cat > 'Candy
> Toy.sox'
> 
>     cat 'Candy Toy.sox' | sox - 'Candy Toy.wav'
> 
> works too.
> 
> 
> What's the difference for sox between that last command pair that works and
> 
>     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | sox - 'Candy
> Toy.wav'
> 
> or
> 
>     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | cat | sox - 'Candy
> Toy.wav'
> 
> that don't?
> 
> 
> And how come -f ircam works in the simple pipeline invocations but -t
> {wav,aiff,sox} don't?

Looks like if you specify input format via `sox -t sox', it
consistently works, but inconsistently w/o -t on the input.

I don't have a wma, but with flac this fails after a while:

	n=0
	while sox '|ffmpeg -loglevel quiet -i in.flac -f sox -' out.wav
	do
		n=$((n + 1))
	done
	echo $n # I got to 14

However, with `-t sox' it hasn't failed after a few minutes:

	n=0
	while sox -t sox '|ffmpeg -loglevel quiet -i in.flac -f sox -' out.wav
	do
		n=$((n + 1))
	done
	echo $n

I suspect scheduling + stdio/pipe buffering unpredictability
causes format detection to fail without `-t sox' if a read is
too small.  Most likely sox needs to repeat fread(3) during the
detection phase to ensure the buffer is actually full enough.

With cat(1) in the middle, the input sox sees probably becomes
more predictable if cat buffers output into larger chunks before
sox sees it.  ffmpeg probably makes small write(2) calls which
sox can't handle since I've never had a problem with sox writing
to sox via "|sox ..." inputs (which I use nearly every day in
scripts).

(not really feeling like reading code atm to confirm).

[SoX-devel] A sox pipe mystery

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

Hi all

    I'm looking at launching external programs to decode a million other 
formats automatically and have run into a mystery I cannot fathom.


     sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f ircam -" 'Candy 
Toy.wav'

works but

     sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox -" 'Candy 
Toy.wav'

fails saying

    sox FAIL formats: can't open input  `-': can't find sox file format 
identifier

as do

     -f wav   sox FAIL formats: can't open input  `-': WAVE: RIFF header 
not found
     -f aiff  sox FAIL formats: can't open input  `-': AIFF header does 
not begin with magic word `FORM'

though

     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox -" > 'Candy Toy.sox'

     sox 'Candy Toy.sox' 'Candy Toy.wav'

works.


Is it because ffmpeg is seeking back in the file and rewriting the 
header once it's decoded? Nope:

     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | cat > 'Candy 
Toy.sox'

     cat 'Candy Toy.sox' | sox - 'Candy Toy.wav'

works too.


What's the difference for sox between that last command pair that works and

     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | sox - 'Candy 
Toy.wav'

or

     ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | cat | sox - 
'Candy Toy.wav'

that don't?


And how come -f ircam works in the simple pipeline invocations but -t 
{wav,aiff,sox} don't?

(Not that I'm complaining - at least one intermediate format works. 
Finally, a use for ircam format!)


     M

[SoX-devel] Realizing EBU R.128 loudness statistics

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

People have been saying since 2011 how much they'd appreciate
EBU R.128 loudness measurement in SoX and there's an issue
https://codeberg.org/sox_ng/sox_ng/issues/151
laying out its whys, wherefores and hows but so far
no one has wanted to encourage someone capable of it to act.

I'm suggesting to people interested in this to deposit
bounty money for it. The author(s) of the solution accepted
into sox_ng will receive the total sum in question or,
if there are two equally good implementations and
the result is a synthesis of the two, half each.
My work is free and I will not claim it.

The bounty-specific information will appear in sox_ng's
[Accounting](https://codeberg.org/sox_ng/sox_ng/wiki/Accounting)
and [Bounties](https://codeberg.org/sox_ng/sox_ng/wiki/Bounties)
pages and I'll let you know if it makes it in time for the
2024-11-18 micro release.

      M

Re: [SoX-devel] Reinstate the -1 -2 -s -u flags?

[Taylor <tay...@pr...>]

> One of the things I'm considering for sox_ng
> minor release is to reinstate the -1 -2 -s -u etc flags
> https://codeberg.org/sox_ng/sox_ng/issues/210
> removed in 14.4.1 and wondered what people think.
...
> Opinions?

https://sourceforge.net/p/sox/code/ci/f05b1a3 year 2012

Weak oppose. Counting single bits (-b 8 ... -b 24 ... -b 64 ...)
is way more logical than counting groups of bits of whataver
"default" size.

[SoX-devel] Reinstate the -1 -2 -s -u flags?

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

Hi again!
    One of the things I'm considering for sox_ng
minor release is to reinstate the -1 -2 -s -u etc flags
https://codeberg.org/sox_ng/sox_ng/issues/210
removed in 14.4.1 and wondered what people think.

In brief, it makes old scripts work out of the box
and means less typing in command-line work,
emitting a warning whenever they're used and with
all the ls-like options documented in a single paragraph
with warnings about not using them in scripts as
everyone has 14.4.2 or 42b355 which don't support them.

Fortunately, unlike the -b -w -l -d options
that preceded them (!), none of them have been repurposed
(and reusing old flags with a new meaning is iffy anyway)
and SoX is at a stage of maturity that it seems unlikely
that it will need a lot of new one-letter command-line
options.

Opinions?

     M

Re: [SoX-devel] In which way to add EBU R 128 loudness stats?

[Rob S. <aq...@ya...>]

On Saturday 14 September 2024 at 09:58:41 CEST, Martin Guy <mar...@gm...> wrote: 

> OK, there's also libebur128 which is included in almost all distros.
> I guess whoever implements it will decide what's best..

Ok, good, if this lib works well with SoX then it would be the way to go.

> What's the difference between stat and stats in your understanding? I
> see that stats is also per-channel and seems to do more complex analyses 
> but don't really grasp the characteristic difference.

IIRC, each SoX effect can request that it is passed separate streams for each channel (and almost all effects do this) or a single stream of data with multi-channel interleaved (and this is what the stat effect does).   So when I wanted to add some more stuff to stat and for the new stuff to be per channel, Chris agreed that a new effect for multi-channel stats was needed.

> The legend? It looks like we have few chars to play with.
> "EBU R 128"? "Loudness"?

I’d be precise as room allows since there are other loudness standards e.g. Replay Gain, Apple’s Sound Check, etc.
-- 
Rob

Re: [SoX-devel] In which way to add EBU R 128 loudness stats?

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

On 13/09/24 21:22, Rob Sykes via SoX-devel wrote:
> It looks like Audacity has an EBU R 128 implementation, so we might be able to reuse that:
> 
> https://forum.audacityteam.org/t/question-on-lufs-normalization-with-different-types-of-content/80999

OK, there's also libebur128 which is included in almost all distros.
I guess whoever implements it will decide what's best..

> Adding it to the stats effect would make sense to me.
What's the difference between stat and stats in your understanding? I 
see that stats is also per-channel and seems to do more complex analyses 
but don't really grasp the characteristic difference.

The legend? It looks like we have few chars to play with.
"EBU R 128"? "Loudness"?

>  IIRC, EBU R 128 requires 4× upsampling ...
Added to the issue, thanks.

     M

Re: [SoX-devel] In which way to add EBU R 128 loudness stats?

[Rob S. <aq...@ya...>]

It looks like Audacity has an EBU R 128 implementation, so we might be able to reuse that:


https://forum.audacityteam.org/t/question-on-lufs-normalization-with-different-types-of-content/80999


Adding it to the stats effect would make sense to me.  IIRC, EBU R 128 requires 4× upsampling which, as a means to audio measurement without affecting the audio for a following SoX effect means that utilising the rate effect for this would not be simple. So just dumping someone-else’s EBU R 128 implementation as a 'tee' within stats could be the way to go.

Cheers,
Rob

[SoX-devel] In which way to add EBU R 128 loudness stats?

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

Hi again

Several people have suggested (since 2011!) adding EBU R 128 loudness so 
it looks like a good candidate for the next minor release if someone 
wants to implement it.

https://sourceforge.net/p/sox/feature-requests/167
https://codeberg.org/sox_ng/sox_ng/issues/151

I'm writing here to ask where and how to add it, to ensure that we 
remain faithful to SoX's style and so that, if sox.sf.net imports the 
work, we remain compatible. In particular, should it be added to the 
output of "sox stat", to "sox stats" (the per-channel version) or both, 
and what should its label be?

     M

Re: [SoX-devel] Announcing sox_ng-14.4.3

[Taylor <tay...@pr...>]

> > discussion not relevant to mainline sox to so...@gr...
> Oops. so...@gr...

OK ... https://groups.io/g/sox-ng

> > gives "sox_ng-14.4.3.tar.gz" 1'639'540
> Sorry, is there something wrong with that?

Not at all.

> Thanks, I've quickly updated the issue
> https://codeberg.org/sox_ng/sox_ng/issues/65

Thanks. Much better now. Maybe change

> An MS/DOS port is probably difficult both for its 8.3 filenames and for its memory management differences.

to

> A 16-bit DOS port would be very difficult due to memory management differences.

A 32-bit DOS binary does not suffer from memory management
differences, and runs on 16-bit DOS (such a FreeDOS) via a DOS
extender. Good DOS extenders are ca 8 KiO...40 KiO in size and
can be included in the binary, so a standalone
DOS binary is well possible.

Re: [SoX-devel] Announcing sox_ng-14.4.3

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

On 06/09/24 12:22, Martin Guy wrote:

> discussion not relevant to mainline sox to so...@gr...

Oops. so...@gr...


They don't allow _ in group names


     M

Re: [SoX-devel] Announcing sox_ng-14.4.3

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

On 05/09/24 12:19, Taylor via SoX-devel wrote:
>> If this is interesting, either fetch a tarball from
>> https://codeberg.org/sox_ng/sox_ng/releases
> https://codeberg.org/sox_ng/sox_ng/releases/download/sox_ng-14.4.3/sox_ng-14.4.3.tar.gz
>
> gives "sox_ng-14.4.3.tar.gz" 1'639'540

Sorry, is there something wrong with that?


>> I for one am confused though why it's got a new name, source location
>> etc. Is this intended to replace the sox available from:
>> https://sourceforge.net/projects/sox/ ?
>> Even if it is, why is it not just v15, but hosted in the same place
>> as prior versions, where extant users can find it?
> YES please label next version as 15 and put it on SF. Even if you
> don't want to use SF as primary platform, upload it there too.
> Alternatively shut down the SF project page, but move all relevant
> old versions to the new platform first.

Initally I offered to manage sox.sf.net but it turned out not to be 
possible so had to make a hard fork to proceed. The _ng thing is a bit 
camp and Trekkie but it's traditional, so...


No, it's not meant to obscure sox.sf.net and by default does not replace 
sox; they can coexist peacefully on the same thing. There is ./configure 
--enable-replace if you want links made from the traditional names to 
the _ng ones so that it behaves the same as traditional sox, sox.h, 
libsox and their friends.

>> I did do, but although README files mention PDFs and EXEs, there are
>> none such in there. Yes, I know it's "source" but I thought there
>> might at least be a revised manual to read.
The README is autogenerated by README.sh and I haven't disturbed that as 
there were no functional changes; README.md is the sox_ng-specific one. 
sox_ng.txt looks like manual page sox_ng.1 put through nroff -man; I 
will now remember to update that for the next releases, thanks. At some 
point there should also be a new libsox_ng.3 manual page to replace the 
doxygen stuff thanks to Jan Stary's good work in that area, though his 
work is formatted for -mandoc, not -man so will need reformatting to 
work on systems that don't have the -mandoc macros.


Thanks for the info on Windows ports. The last time I compiled projects 
for MS* was in the '286 era so need to learn about the current state of 
the art in that area and your detailed input is appreciated.


We seem to be filling sox-devel with stuff specific to sox_ng, which 
doesn't feel right; I think it would be more respectful to people not 
interested in _ng if discussion not relevant to mainline sox went to 
so...@gr...


And, as several people seem to be suggesting it, no, I don't want to 
interfere with sox.sf.net which has its own different direction and is 
the number one source for all other work on SoX.

New air is good for the cathedral, but not so much as to blow out the 
candles.


    M

Re: [SoX-devel] Announcing sox_ng-14.4.3

[Taylor <tay...@pr...>]

Hello all

> If this is interesting, either fetch a tarball from
> https://codeberg.org/sox_ng/sox_ng/releases

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

gives "sox_ng-14.4.3.tar.gz" 1'639'540

> This has clearly been lots of work, and is to be applauded

Agree. :-)

> I for one am confused though why it's got a new name, source location
> etc. Is this intended to replace the sox available from:
> https://sourceforge.net/projects/sox/ ?
> Even if it is, why is it not just v15, but hosted in the same place
> as prior versions, where extant users can find it?

YES please label next version as 15 and put it on SF. Even if you
don't want to use SF as primary platform, upload it there too.
Alternatively shut down the SF project page, but move all relevant
old versions to the new platform first.

> I did do, but although README files mention PDFs and EXEs, there are
> none such in there. Yes, I know it's "source" but I thought there
> might at least be a revised manual to read.

IIRC the PDF was broken in the last old release. A manual is CRUCIAL.
I can find file

"sox_ng.txt" 180'033 2024-09-01 14:43

and inside it says

> December 31, 2014

So YES please make sure that future releases will have an
up-to-date manual at least in plain text format.

> And unlike Sourceforge there seem to be no Windows builds

YES please compile a high-compatibility Win32 executable (low CPU
requirements, low DLL requirements, low API requirements). Not because
Windows would be great, but because high-compatibility Win32 executables
can be run anywhere, such as on FreeDOS, ReactOS, and on Linux via Wine.

> I then looked at the issues tracker, searching it for "Windows". I
> was slightly worried by
> https://codeberg.org/sox_ng/sox_ng/issues/65
> "Compile for MS/DOS"

I am woried too. Please drop this issue, and make two separate ones:
* "Compile a high-compatibility standalone Win32 executable"
* "Compile a 32-bit DOS executable"

> Also, I for one would not want sox_ng for Windows only to be
> available via some sort of setup.exe - I'd prefer just a zipped set
> of files that I can place where I want them on my system.

YES please provide a high-compatibility standalone Win32
executable (without any installer), not depending on any DLL:s
(except KERNEL32.DLL maybe), inside a ZIP containing
a manual too.

> One never knows what an installer does.

Agree, no secret "calling-home" and no pressuring
to "online update" please.

> The manual has changed little so far apart from spelling corrections,
> but is growing new paragraphs as new features now go in. I guess I
> forgot to generate the PDFs as part of the release process.

> I haven't faced Windows builds yet. As a command-line utility I am
> assuming that porting to MSDOS and Windows is essentially the same
> thing, and that what worked with command.com will work in cmd.exe

Well, not at all.

A Win32 binary can be compiled with MinGW-32, MinGW-64
selecting Win32 as target, Watcom selecting Win32 as target,
MSVC (old versions such as MSVC 6 are much better, the newer
ones produce very incompatible binaries), or cross-compiled
with Linux GCC selecting Win32 binary as target.

A 32-bit DOS binary can be compiled with Watcom selecting
DOS/32A as target, or with DJGPP, or cross-compiled with Linux
GCC selecting DJGPP binary as target.

> and we have some very ancient compilers:
> Turbo C
> Watcom C
> Microsoft C (MSC)
> That should put its portability to the test! 8.3!

Wartcom / OpenWatcom or DJGPP is the choice for DOS ie Free-DOS.
It would be probably very difficult to compile a 16-bit binary due
to the 64 KiO segment limit. A standalone DOS binary will
run irrespective of "8.3". In order to compile under DOS, one
would probably have to rename a few files such as:
"rate_poly_fir.h"
"rate_poly_fir0.h"

> A static binary containing all the required libraries may be a
> simpler solution that wouldn't provide libsox for Windows

YES please compile a standalone high-compatibility Win32 executable.

The Win32 DLL of libsox can be provided separately.

Re: [SoX-devel] Announcing sox_ng-14.4.3

[Måns R. <ma...@ma...>]

Jeremy Nicoll - ml sox devel <jn....@wi...> writes:

> I for one am confused though why it's got a new name, source location
> etc.

Consider it a hostile fork.

-- 
Måns Rullgård

Re: [SoX-devel] Announcing sox_ng-14.4.3

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

On 03/09/24 17:47, Jeremy Nicoll - ml sox devel wrote:

 > I for one am confused though why it's got a new name, source location

 > etc.  Is this intended to replace the sox available from:

 > https://sourceforge.net/projects/sox/ ?

> Even if it is, why is it not just v15, but hosted in the same place
> as prior versions, where extant users can find it?
>
I offered to maintain sox.sf.net as that seemed to make more sense at 
the time, but nothing doing so I was forced to make a hard fork. As it 
turns out, that was a blessing in disguise because I could fork 14.4.2, 
to which most of the existing patches in the distros apply more cleanly, 
because it freed me to choose more modern and free tools than 
sourceforge.net and because sox.sf.net's commits since 14.4.2 are a 
mixture or bug fixes, new features and refactoring, so it would have 
been awkward to try and make micro, minor and (possibly) major releases 
without a lot of fiddling about.

However, the good work there is filtering into sox_ng, largely because 
it is the main source of patches for the distros.

> If this is interesting, either fetch a tarball from
>>
>> https://codeberg.org/sox_ng/sox_ng/releases
>
> I did do, but although README files mention PDFs and EXEs, there are
> none such in there.  Yes, I know it's "source" but I thought there
> might at least be a revised manual to read.

The manual has changed little so far apart from spelling corrections, 
but is growing new paragraphs as new features now go in. I guess I 
forgot to generate the PDFs as part of the release process.


> And unlike Sourceforge there seem to be no Windows builds.
 > https://codeberg.org/sox_ng/sox_ng/issues/65
 > "Compile for MS/DOS"

I haven't faced Windows builds yet. As a command-line utility I am 
assuming that porting to MSDOS and Windows is essentially the same 
thing, and that what worked with command.com will work in cmd.exe but I 
may be wrong of course.

> Also, I for one would not want sox_ng for Windows only to be
> available via some sort of setup.exe - I'd prefer just a zipped set
> of files that I can place where I want them on my system.
>
> One never knows what an installer does.

Thanks for the input, I'll remember that that's a desirable format when 
I (or someone else) faces the Windows build. A static binary containing 
all the required libraries may be a simpler solution that wouldn't 
provide libsox for Windows, but it appears that almost no one uses that 
anyway.


    M

Re: [SoX-devel] Announcing sox_ng-14.4.3

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

On 2024-09-01 16:21, Martin Guy wrote:
> # sox_ng: First release announcement
> 
> 
> I am happy (with some trepidation) to announce the first release
> of sox_ng, a new project to unify the work in the 50 distros ....


This has clearly been lots of work, and is to be applauded.


I for one am confused though why it's got a new name, source location
etc.  Is this intended to replace the sox available from:

   https://sourceforge.net/projects/sox/   ?


Even if it is, why is it not just v15, but hosted in the same place
as prior versions, where extant users can find it?



> If this is interesting, either fetch a tarball from
> 
> https://codeberg.org/sox_ng/sox_ng/releases

I did do, but although README files mention PDFs and EXEs, there are
none such in there.  Yes, I know it's "source" but I thought there
might at least be a revised manual to read.

And unlike Sourceforge there seem to be no Windows builds.



I then looked at the issues tracker, searching it for "Windows". I
was slightly worried by

   https://codeberg.org/sox_ng/sox_ng/issues/65
   "Compile for MS/DOS"

because I couldn't tell from the text there whether it genuinely is
about "MS/DOS" (not present in Windows for maybe 20+ years) or if it
just means the "Command Prompt" (cmd.exe) terminal environment that's
been in Windows since then - which I use a lot - or its successor
"Powershell" - which I have never used, & don't plan to.


Also, I for one would not want sox_ng for Windows only to be
available via some sort of setup.exe - I'd prefer just a zipped set
of files that I can place where I want them on my system.

One never knows what an installer does.




-- 
Jeremy Nicoll - my opinions are my own

Re: [SoX-devel] sinc: continue on lowpass filter with cutoff above Nyquist

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

On 03/09/24 07:06, Rob Sykes via SoX-devel wrote:
> If the sinc effect were given the ability to auto-remove when the cutoff is above Nyquist, it would need to emit a WARN message or perhaps better, to auto-remove only if instructed to do so via a new flag.
>
Thanks, that sounds right

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


    M

Re: [SoX-devel] sinc: continue on lowpass filter with cutoff above Nyquist

[Rob S. <aq...@ya...>]

Hello Martin,

Generally, SoX should do what it’s been told to do i.e. not try to guess what alternative would please the user when this is not possible.

For example, in this particular case, as well as a cut-off point, the lowpass sinc filter has a transition band width that is adjustable by the user, who may just as concerned in achieving the associated (perhaps gentle) roll-off as the ultimate cut-off.  So the ‘correct’ behaviour in this case might be to increase the sample-rate, apply the sinc, and optionally return the sample-rate to the original.

Scripting works well in such situations i.e. using soxi to query the audio file attributes and building up the sox command line as appropriate to the user’s preferences.

That said, the current code does allow for effects that deem themselves redundant to simply remove themselves from the effects chain.  E.g. see the rate effect: it will remove itself if its input rate and requested rate are equal.

If the sinc effect were given the ability to auto-remove when the cutoff is above Nyquist, it would need to emit a WARN message or perhaps better, to auto-remove only if instructed to do so via a new flag. 

HTH,
Rob

[SoX-devel] sinc: continue on lowpass filter with cutoff above Nyquist

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

You're welcome. I think it needed it.


Now that we're in minor release phase and can pour as much of the 
fabulous work that people have done on SoX over the last nine years as 
we can into sox_ng, I have a question about SoX itself which I think 
belongs here. The sox_ng (or sox-ng) list  is only for discussion of the 
mountain of cruft I've built on top of and around the code base we know 
and love.


This is about an issue I'm putting in myself for my own use case where I 
process a ripped enormous CD collection with a low-pass brickwall filter 
"sinc" at 15175Hz because a lot of the CDs clip as recorded and all the 
interesting musical information is below that frequency so it removes 
the harshest part of the cllipping.


When it gets to the data CDs with WMAs and stuff recorded at 22050 or 
16kHz, sox dies saying the cutoff frequency is above half the sampling 
rate. But if a brickwall lowpass's cutoff frequency is above the Nyquist 
frequency it should be a no-op, a copy-through.


I've done for myself: where it checks for this case, I just set the 
cutoff frequency to half the sampling rate and it seems to work without 
blowing up but it's not right because if the cutoff is way above half 
the sampling rate, this erroneously fiddles with the top end for the 
edge effects I presume it has around the target frequency. But it *is* 
easy to implement.


My question is, to have the most SoXey result, would it be right to flip 
from sinc to a copy-through when that happens, and how difficult is it 
likely to be to implement?


Thanks, onwards...


    M