sox-users Mailing List for SoX - Sound eXchange

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

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

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

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


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

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


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

I guessed maybe that :)

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


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

already-implemented effects are practical.  An EBU-R128

loudness measurement also has some support, and

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

to result in anyone actually putting up some dough

to encourage someone to do it.

(and probably not me unless that it specifically requested;

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

on the list.)


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

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

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

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

all work to do. Just translating and adapting dolbybcsoftwaredecode

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

the algorithm already coded and with considerable help

from the original author.


     M

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

Marco

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

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


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

Let me know when they're ready! :)


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

submit issues for them possibly with links and/or

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

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


How on earth does a de-reverber work?


    M



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

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

> How on earth does a de-reverber work?

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

-- 
Jeremy Nicoll - my opinions are my own

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


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

Let me know when they're ready! :)


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

submit issues for them possibly with links and/or

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

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


How on earth does a de-reverber work?


    M

Happy birthday!
What do you think about the following effects:
- XTC ambiophonic
- de-reverber?

Marco

-----Messaggio originale-----
Da: SoX NG <so...@fa...> 
Inviato: domenica 27 aprile 2025 06:12
A: sox...@li...
Oggetto: Re: [SoX-users] Comment ID3 tag not read

On 27/04/25 02:24, his birthday, Martin Guy blurted:


All good stuff.


Is there any more stuff I should add to the next feature release on 05-18?


    M



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

On 27/04/25 02:24, his birthday, Martin Guy blurted:


All good stuff.


Is there any more stuff I should add to the next feature release on 05-18?


    M

On 25/04/25 00:12, Nicolas Graner wrote:
> Thanks very much for your detailed answer.


My pleasure.


> I can wait for the next sox_ng release in May, no hurry. :)


Thanks. I'm working on other stuff too, libdolbyb to put

Dolby B encoding and, more importantly, decoding as

many people have old archives but don't want to have to

buy a more expensive Dolby B licensed deck and

spend the money on better heads and electronics.


It's working in sox_ng trunk now, giving bit-for-bit exact

same output as the original Pascal.


I was sniffing ReZound and may get around to it.

It's original developer is still with us but is doing

other things. He seems more interesting in me

implementing or finishing things he was working on

or had in his TODO list but he is responsive

to technical questions so I consider myself to be

blessed in this respect. It's a fab graphical audio editor

whose only lack is a log frequency axis spectrogram display

as an alternative to the waveform. Give me time :)


My latest is maintaining Professor David Turner's interpreter for the

seminal pure lazy functional programming language Miranda

miranda.org.uk


I was Prof. Turner's pupil, then colleague, then friend and

translated the interpreter of his previous lazy flanguage,

KRC, the modestly-named Kent Recursive Calculator, from

BCPL-for-EMAS to C-for-Unix. in the 2000s he even regaled

me damson, the Sparc SunStation on which he had developed

Miranda in the 90's. I remember him bounding up the stairs

to deposit damson in her new home and then being so terrified

of the steep and narrow staircase to descend that I almost had to

carry him down in my arms, bottle-bottom shortsighted that he was.

codeberg.org/DATurner/miranda

It now works on all off the GCC Compile Farm except for, paradoxically,

all Sun Sparc/Solaris machines on which it dumps core as soon as you

ask for 1 + 2.


> comments to store application-specific data into MP3 files


OK, I'll come clean. I broke ID3-through-LAME writing in 14.5

by including UTF16-writing code that didn't check the return values

from id3_set_fieldvalue() or somesuch and, in fact, it was failing.

I've reverted it and am working on a patch release for 14.5.1

but had to stop today when I found myself screaming at the screen.

The pushers, putas and punkabestia under my window must have

wondered who was doing what to me, but it was just me.


It's OK in trunk, so grab that.

> tell users to run sox_ng instead of sox

Absolutely! Not only are all CVEs fixed and a slew of grave,

noisy and talkative bugs,but it's now sprouting more stuff.

The new ones are:

* softvol, a volume control that can slowly

increase the volume and, when it would have clipped,

adjust the software volume control so it exactly peaks.

The crunched I expected are totally inaudible, presumably

because they coincide with the peaks of the sound wave

and have latency 0

* a new combining method for sox synth that uses

the synthesized wave to modulate a delay of any length.

Well, up to a year, 15GB.

* dolbyb for Dolby B noise reduction application and removal.

It emulstes in software a real Dolby B unit's electronics,

complete with the calibration procedure in which you have to

earth certain points and adjust some pots until the voltage is

right at some other point on the circuit. I'ts bang on, hats off,

based on dolbybcsoftwaredecode by translating its Free Pascal

into a C library. It doesn't work on bigendian systems yet but

I think it's just a question of how it assembled and disassembles

the samples when they arrive as bytes from a file.

For your need case, I'd provide both a sox interface and

an id3 interface that does the same thing. That way as

working ID3 handling in SoX and id3 comes and goes

your customers will have a working system.

> Keep up the good work on sox_ng!


You know where the cookie jar is. Offer me a beer :D


   M


This message was composed with Thunderbird so,

if the lines are backwards or one on top of the other,

please apply the appropriate filters.

Thanks very much for your detailed answer.

I can wait for the next sox_ng release in May, no hurry. :)

In the project on which I am working, which uses SoX as a backend, I use
comments to store application-specific data into MP3 files. I now have
two options: either tell users to run sox_ng instead of sox, or write my
own function to read COMM tags directly from the file without relying on
SoX.

Keep up the good work on sox_ng!

Nicolas

SoX NG <so...@fa...> wrote on 2025-04-24 11:30:
> On 23/04/25 15:30, Nicolas Graner wrote:
>> it seems that SoX cannot read a "Comment" ID3 tag in an MP3 file, even
>> though it can create one. Is this a known issue?
>
> Thanks for reporting this. Yes, reading comments turns out not to work
> in all versions of sox based on 14.4.2 because Comments are encoded
> in a different way from all other tags and 14.4.2 handles them all the 
> same way.

On 23/04/25 15:30, Nicolas Graner wrote:
> it seems that SoX cannot read a "Comment" ID3 tag in an MP3 file, even
> though it can create one. Is this a known issue?


Thanks for reporting this. Yes, reading comments turns out not to work

in all versions of sox based on 14.4.2 because Comments are encoded

in a different way from all other tags and 14.4.2 handles them all the 
same way.


Mans Rullgard made the right fix for it on 22 May 2017, but no one's

ever made a release on sox.sf.net since 14.4.2 in Feb 2015, so most of the

software distributions have not caught up with anything new.


Unfortunately, the code fix was applied after a major rewrite of

the ID3-handling code, which is also tangled up with his DSD/DSDIFF format

driver and it cannot easily be applied to any other version based on 14.4.2.

You'll only find it in the versions from the few distros who took the 
deep plunge

and based on their SoXen on a snapshot of the sox.sf.net unstable 
development

branch in 2021: ArchLinux, Artix, CRUX, FreeBSD, Gentoo, Mageia, NixOS, 
OpenBSD

and Pisi Linux. However, caveat emptor!, because the unstable 
development branch

also has many new bugs that weren't in 14.4.2 and even fails some old 
CVEs that 14.4.2

passed. Maybe it's just as well a release was never made, despite all 
the good new stuff!


Your best bet is sox_ng but I only managed to extricate the DSD/ID3 tangle

in January 2025, so it will appear in the next new-feature release of sox_ng

(14.6.1) on 18th May 2025.


In the meantime, if you have a Unix you can


git clone https://codeberg.org/sox_ng/sox_ng

cd sox_ng

autoreconf -i

./configure --with-ffmpeg

make

sudo make install


and if you want the commands to be called "sox" "soxi", "play" "rec"

as well as "sox_ng" "soxi_ng" and so on, configure --enable-replace


If instead you're forced to use Windows and are in a hurry

I may be able to whip up a .exe of its current state,

something I have to face by 18th May anyway.


     M


http://martinwguy.net

Hello all,

it seems that SoX cannot read a "Comment" ID3 tag in an MP3 file, even
though it can create one. Is this a known issue?

## test Comment tag
$ id3 -l test1.mp3 
test1.mp3: No ID3 tag
$ sox test1.mp3 --comment Comment=foobar test2.mp3
$ id3 -l test2.mp3
test2.mp3:
Title  :                                 Artist:                               
Album  :                                 Year:     , Genre: Unknown (255)
Comment: foobar                          Track: 0
$ soxi -a test2.mp3

## test Comment and Title tags
$ sox test1.mp3 --comment Comment=foobar --comment Title=My-Song test3.mp3
$ id3 -l test3.mp3 
test3.mp3:
Title  : My-Song                         Artist:                               
Album  :                                 Year:     , Genre: Unknown (255)
Comment: foobar                          Track: 0
$ soxi -a test3.mp3 
Title=My-Song
$ sox --version
sox:      SoX v14.4.2

The Comment and Title tags are created as expected, as shown by
"id3 -l", but soxi sees only Title. All other tags work fine as well,
only Comment is invisible to soxi (or sox --i).

What gives?

Nicolas

On Wed, 26 Mar 2025 at 04:50, Jan Stary <ha...@st...> wrote:

> > This won't really work.  I'm planning to play hundreds of tones with
> logic
> > like "that frequency on that channel was heard at -30dB - next time try
> > -40dB" etc. etc.
>
> That is a very flawed hearing test. Your hearing accomodates
> and dis-accomodates quite quickly according the the sounds
> heard just before. There is a reason perception tests contain
> breaks and intermitent music jingles. Listening to twenty
> half-second sine tones in sequence will very much influence
> your hearing of the next half-seconf sine tone.


I'm not trying to do anything scientifically significant - I have no
background knowledge to base it on.  It's just an experiment/learning
exercise.  That being said, I am (pseudo)randomising the tone order and ear
tested.  I am also iterating over the test tones multiple times (I'm up to
45 iterations so far) with breaks in between - each iteration refines the
result (just audible volume) for each frequency.

In another mail you asked about the version of sox I'm using - I have not
tried any other versions and I won't be - you may have seen in mail to
someone else that I have "solved" my issue by fading the generated tones
for 0.05 of a second at each end.  My theory is that the "pops" I was
hearing were simply some hardware in my audio chain reacting to the instant
volume changes.

> This won't really work.  I'm planning to play hundreds of tones with logic
> like "that frequency on that channel was heard at -30dB - next time try
> -40dB" etc. etc.

That is a very flawed hearing test. Your hearing accomodates
and dis-accomodates quite quickly according the the sounds
heard just before. There is a reason perception tests contain
breaks and intermitent music jingles. Listening to twenty
half-second sine tones in sequence will very much influence
your hearing of the next half-seconf sine tone.

(But that's not the problem here.)

On Mar 25 13:52:48, bri...@gm... wrote:
> On Tue, 25 Mar 2025 at 12:56, Jan Stary <ha...@st...> wrote:
> 
> > On Mar 25 11:58:15, bri...@gm... wrote:
> > > I'm thinking of using sox's synth capability to make myself a simple
> > > hearing tester.  It will play a bunch of tones at various frequencies,
> > > channels and volumes and record my response, or not.
> >
> > What version of SoX is it?
> 
>  bwatson@puck:~$ sox --version
> sox:      SoX v14.4.2

To say the obvious: are you experiencing the same
with the current git (or one of its non-dead forks)?

On Tue, 25 Mar 2025 at 14:33, SoX NG <so...@fa...> wrote:

I can suggest another possible workaround: to fade the very end of the sound


Thank you!  It may well be a work around, but adding "fade l 0.05 0.5 0.05"
to the end of my synth options works perfectly.

Brian

 > it happening with two different audio cards is perplexing.

Could you try another test, to see if it is SoX or the way it handles
your audio hardware that is at fault?

Could you try generating the tones into a temporary file
and play that using something else, like ffplay, mplayer,
wavplay or whatever?

      M

On 25/03/25 18:10, Brian Watson wrote:
 > On Tue, 25 Mar 2025 at 12:57, SoX NG <so...@fa...> wrote: >> 
One workaround would be generate them first and play them >> in one 
session, if that is feasible in your use case.

 >This won't really work. I'm planning to play hundreds of tones with 
logic > like "that frequency on that channel was heard at -30dB - next 
time try > -40dB" etc. etc. Ah, I was afraid that might be the case.
 > My USB hardware is a Schiit Modi+ DAC. Is that really pronounced the 
way I assume it is? :) >I tried using the built-in sound hardware in my 
device (card 1: PCH [HDA > Intel PCH], device 0: ALC283 Analog [ALC283 
Analog]) and I get similar, but > worse, artefacts at the end - there in 
now some delay between the end of > the tone and the "pop" and the 
different channels seem to "pop" > independently.

This is all mysterious and odd. I've checked Jan's 480 example and
of course it does start and end exactly at 0. Popping some time after
the audio ends, and presumable SoX has exited, is just bizarre.
The reason we're suggesting other non-SoX things that it might be
is not just denial, but also because we're unable to reproduce the failure
using the exact same commands so we don't have anything else to go on.

I can suggest another possible workaround: to fade the very end of the sound
and maybe also the start, in case it is the sudden onset and stop that 
provoke it
in your setup, but it happening with two different audio cards is 
perplexing.

     M

On Tue, 25 Mar 2025 at 12:57, SoX NG <so...@fa...> wrote:

> On 25/03/25 15:58, Brian Watson wrote:
> > play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -25dB remix 1 0
> >
> > wrapped into a script with the frequency, gain and remix parameters
> > replaced with variables will work exactly as I had hoped.
> >
> > Except - when I listen to the generated sounds there is a small pop, or
> > crack, at the start and end of each sound.
>
> I've tried your exact command line here (Debian GNU/Linux)
> and just get a peep, no pops.
>
> One workaround would be generate them first and play them
> in one session, if that is feasible in your use case.
>
> for f in 5000 6000 7000 8000 9000 10000
> do
>          sox -n tone-$f.wav synth 0.5 sin $f
> done
> play --combine concat tone*wav
>

This won't really work.  I'm planning to play hundreds of tones with logic
like "that frequency on that channel was heard at -30dB - next time try
-40dB" etc. etc.

If instead you need variable pauses between tones, I suspect you need
> a different sound device; USB ones exist and are cheap0est and easiest
> if quality is not at a premium.
>

My USB hardware is a Schiit Modi+ DAC.  This is far from "premium" by HiFi
DAC standards, but I believe it should be more than capable of this task. I
tried using the built-in sound hardware in my device (card 1: PCH [HDA
Intel PCH], device 0: ALC283 Analog [ALC283 Analog]) and I get similar, but
worse, artefacts at the end - there in now some delay between the end of
the tone and the "pop" and the different channels seem to "pop"
independently.

On Tue, 25 Mar 2025 at 12:56, Jan Stary <ha...@st...> wrote:

> On Mar 25 11:58:15, bri...@gm... wrote:
> > I'm thinking of using sox's synth capability to make myself a simple
> > hearing tester.  It will play a bunch of tones at various frequencies,
> > channels and volumes and record my response, or not.
>
> What version of SoX is it?
>

 bwatson@puck:~$ sox --version
sox:      SoX v14.4.2
bwatson@puck:~$ dpkg -l | grep alsa
ii  alsa-base                              1.0.25+dfsg-0ubuntu7
           all          ALSA driver configuration files
ii  alsa-topology-conf                     1.2.5.1-2
            all          ALSA topology configuration files
ii  alsa-ucm-conf                          1.2.6.3-1ubuntu1.12
            all          ALSA Use Case Manager configuration files
ii  alsa-utils                             1.2.6-1ubuntu1
           amd64        Utilities for configuring and using ALSA
ii  libsox-fmt-alsa:amd64
 14.4.2+git20190427-2+deb11u2ubuntu0.22.04.1 amd64        SoX alsa format
I/O library
bwatson@puck:~$ uname -a
Linux puck 5.15.0-134-generic #145-Ubuntu SMP Wed Feb 12 20:08:39 UTC 2025
x86_64 x86_64 x86_64 GNU/Linux

> After a bit of reading I have figured that something like this:
> > play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -25dB remix 1 0
> > wrapped into a script with the frequency, gain and remix parameters
> > replaced with variables will work exactly as I had hoped.
>
> Why do you need the 44100 sample rate?
>

Just because it was the sample rate in the example that I learned this
syntax from.


> Why are you only using half a second of sound?
>

Because I want to generate lots (probably hundreds) of tones one after the
other and see if I hear them or not.  Half a second seems long enough that
I should be able to hear it, but not long enough that I waste time
listening once it has been heard.

>
> > Except - when I listen to the generated sounds there is a small pop, or
> > crack, at the start and end of each sound.
>
> I suspect being off the zero crossings:
> Half a second of a 5 kHz sine wave at 44100
> will not result in a full, finished period of the wave.
> You will have "jumps" at the seams.
>
> play -n synth 10 sin 440 gain -3 dcshift 0.5
>

That was REALLY loud for me - I'm glad my headphones were on the desk!

play WARN alsa: can't encode 0-bit Unknown or not applicable

 File Size: 140T
  Encoding: n/a
  Channels: 1 @ 32-bit
Samplerate: 48000Hz
Replaygain: off
  Duration: unknown

In:0.00% 00:00:04.10 [00:00:00.00] Out:193k  [!=====|=====!] Hd:0.0
Clip:49.3k
play WARN dcshift: dcshift clipped 49322 samples; decrease volume?


> > The obvious answer is that this pop/crack comes from ALSA,
> > or my DAC or my headphones.
>
> I don't how that's obvious,
> but I cannot replicate the pops and cracks with my SoX.
>

My experience has been that people tend to blame some external entity
rather than the subject of the question - so, I like to try to rule them
out.


> > The only thing that makes me think that it is sox is that the
> > "vol" given to "synth" changes the volume of the pop/crack.  If I do, for
> > example:
> > play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -100dB remix 1 1
> > I get nothing but silence.
>
> At -100 dB,there is no audible sound,
> so this is not an example of anything.
>

I had suspected that maybe the act of opening or closing the sound device
might be causing the pop I'm hearing.  I believe playing this effectively
silent sound still opens and closes the sound hardware and rules that out?

> I'm taking this as sox being able to open my
> > sound hardware and play the very quiet sound with no pop/crack?
>
> With the line above, you are effectively playing silence.
> There are no pops and cracks in silence.
>

The pop is only at the end - I had suspected that maybe it was the closing
of the sound device/hardware that caused it.


> > I've seen discussion on similar topics where duration of the tone is
> > manipulated to ensure it aligns with write buffers.  I suspect that's the
> > problem I am seeing
>
> Mee too.
>
> play -r 48000 -n synth 10 sin 480
>

I had to add "vol -30dB" so as not to deafen myself - this generates the
same pop at the end.

Brian

On 25/03/25 15:58, Brian Watson wrote:
> play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -25dB remix 1 0
>
> wrapped into a script with the frequency, gain and remix parameters
> replaced with variables will work exactly as I had hoped.
>
> Except - when I listen to the generated sounds there is a small pop, or
> crack, at the start and end of each sound.

I've tried your exact command line here (Debian GNU/Linux)
and just get a peep, no pops.

One workaround would be generate them first and play them
in one session, if that is feasible in your use case.

for f in 5000 6000 7000 8000 9000 10000
do
         sox -n tone-$f.wav synth 0.5 sin $f
done
play --combine concat tone*wav

(by default, "play" uses --combine sequence,
which closes and reopens the audio device between files)

If instead you need variable pauses between tones, I suspect you need
a different sound device; USB ones exist and are cheap0est and easiest
if quality is not at a premium.

Another cause could be impedance mismatching between the audio output and
the amplifier's input, or putting headphone output into a microphone input
or something like that.

     M

On Mar 25 11:58:15, bri...@gm... wrote:
> I'm thinking of using sox's synth capability to make myself a simple
> hearing tester.  It will play a bunch of tones at various frequencies,
> channels and volumes and record my response, or not.

What version of SoX is it?

> After a bit of reading I have figured that something like this:
> play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -25dB remix 1 0
> wrapped into a script with the frequency, gain and remix parameters
> replaced with variables will work exactly as I had hoped.

Why do you need the 44100 sample rate?
Why are you only using half a second of sound?

> Except - when I listen to the generated sounds there is a small pop, or
> crack, at the start and end of each sound.

I suspect being off the zero crossings:
Half a second of a 5 kHz sine wave at 44100
will not result in a full, finished period of the wave.
You will have "jumps" at the seams.

play -n synth 10 sin 440 gain -3 dcshift 0.5

> The obvious answer is that this pop/crack comes from ALSA,
> or my DAC or my headphones.

I don't how that's obvious,
but I cannot replicate the pops and cracks with my SoX.

> The only thing that makes me think that it is sox is that the
> "vol" given to "synth" changes the volume of the pop/crack.  If I do, for
> example:
> play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -100dB remix 1 1
> I get nothing but silence.
 
At -100 dB,there is no audible sound,
so this is not an example of anything.

> I'm taking this as sox being able to open my
> sound hardware and play the very quiet sound with no pop/crack?

With the line above, you are effectively playing silence.
There are no pops and cracks in silence.

> I've seen discussion on similar topics where duration of the tone is
> manipulated to ensure it aligns with write buffers.  I suspect that's the
> problem I am seeing

Mee too.

play -r 48000 -n synth 10 sin 480

	Jan

On Tue, Mar 25, 2025 at 11:58:15AM -0300, Brian Watson wrote:
>    Hi,
>    I'm thinking of using sox's synth capability to make myself a simple
>    hearing tester.  It will play a bunch of tones at various frequencies,
>    channels and volumes and record my response, or not.
>    After a bit of reading I have figured that something like this:
>    play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -25dB remix 1 0
>    wrapped into a script with the frequency, gain and remix parameters
>    replaced with variables will work exactly as I had hoped.
>    Except - when I listen to the generated sounds there is a small pop, or
>    crack, at the start and end of each sound.  This is going to invalidate
>    my results as the pop/crack is, obviously, not at the frequency of the
>    test tone.

I do not get a pop, but I removed "-t alsa" from your line - that should not be necessary unless your default
driver/device differ from what you want to use. I tried on MacOS and Windows, where it worked flawlessly,
and on a Ubuntu WSL2 instance, where it worked but had the typical buffering issues I see in that environment.

>    The obvious answer is that this pop/crack comes from ALSA, or my DAC or
>    my headphones.  The only thing that makes me think that it is sox is
>    that the "vol" given to "synth" changes the volume of the pop/crack.

On MacOS, my driver was of course coreaudio. On Windows, it was waveaudio. On the WSL2 instance, I believe
it was ao; alsa did not work there.

>    If I do, for example:
>    play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -100dB remix 1 1
>    I get nothing but silence.  I'm taking this as sox being able to open
>    my sound hardware and play the very quiet sound with no pop/crack?

A very quiet sound amid total silence will not produce a big enough transient to make a pop/crack likely.

>    I've seen discussion on similar topics where duration of the tone is
>    manipulated to ensure it aligns with write buffers.  I suspect that's
>    the problem I am seeing, but I don't understand enough to take that
>    information and apply it here.

You might try --buffer with various lengths to see if that fixes the issue. I'd start with 4096, then 2048,
then 1024, etc., to find the smallest value that does not pop.

>    Also, I'm doing this as a learning exercise/experiment and am not
>    trying to create a "product", but if this has already been done or
>    there are better ways to do it I'd be interested to learn.

I've used SoX as a rudimentary hearing tester for many years but never packaged my methods into anything
coherent.


-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"I am a leader by default, only because nature does not allow a vacuum."
Bishop Desmond Tutu

Hi,

I'm thinking of using sox's synth capability to make myself a simple
hearing tester.  It will play a bunch of tones at various frequencies,
channels and volumes and record my response, or not.

After a bit of reading I have figured that something like this:

play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -25dB remix 1 0

wrapped into a script with the frequency, gain and remix parameters
replaced with variables will work exactly as I had hoped.

Except - when I listen to the generated sounds there is a small pop, or
crack, at the start and end of each sound.  This is going to invalidate my
results as the pop/crack is, obviously, not at the frequency of the test
tone.

The obvious answer is that this pop/crack comes from ALSA, or my DAC or my
headphones.  The only thing that makes me think that it is sox is that the
"vol" given to "synth" changes the volume of the pop/crack.  If I do, for
example:

play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -100dB remix 1 1

I get nothing but silence.  I'm taking this as sox being able to open my
sound hardware and play the very quiet sound with no pop/crack?

I've seen discussion on similar topics where duration of the tone is
manipulated to ensure it aligns with write buffers.  I suspect that's the
problem I am seeing, but I don't understand enough to take that information
and apply it here.

Also, I'm doing this as a learning exercise/experiment and am not trying to
create a "product", but if this has already been done or there are better
ways to do it I'd be interested to learn.

On 03/03/25 13:40, Doug Lee wrote:
> 5012661833014706355.oga: Ogg data, Opus audio, version 0.1, mono, 48000 Hz (Input Sample Rate)

Confirmed. Should autodetect.

     M

On Mon, Mar 03, 2025 at 10:52:26AM +0100, SoX NG wrote:
[a nice list of fixes and enhancements for the two SoX versions]

Under 14.5.1's features:

> o Automatically read Ogg FLAC (.oga) files with ffmpeg

Heads up in case this is an issue: Unigram, a Windows Telegram third-party app, creates .oga files that are
Opus. I don't know if that's actually Unigram doing that, or the Telegram infrastructure.

Ubuntu's file(1) command says this about one of mine:

5012661833014706355.oga: Ogg data, Opus audio, version 0.1, mono, 48000 Hz (Input Sample Rate)

Not sure if this list allows small attachments, so you can get that test file at
https://www.dlee.org/5012661833014706355.oga for now.

-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"I before E, except after C, or when sounded like A, as in neighbor
and weigh, except for when weird foreign concierges seize neither
leisure nor science from the height of society."