sox-users — SoX list to discuss end user topics

Re: [SoX-users] partial fade in

[Peter P. <pet...@fa...>]

* Nicolas Graner <ni...@gr...> [2025-07-19 15:47]:
> Hello all,
> 
> I would like to ramp the volume of an audio file from a given level to
> full volume over a specified time interval. For instance, increase the
> level linearly from 30% at time t=0 to 100% at time t=10s. In other
> words, perform a fade in starting from a level greater than 0.
> 
> I can do it by inserting an appropriate amount of silence before the
> beginning, performing a fade in, then removing the extra silence. But
> this seems unnecessarily complex, especially if the effect is to be
> applied at a time other than the beginning. Is there a better way to do
> it with SoX ?

Dear Nicolas,

apart from the other replies to your question let me add that any
consequent functionality, that is beyond simple fade ins and fade, outs will
eventually result in the specification of an amplitude envelope with
possibly infinite segments, usually declared as time/value pairs. This
is a big thing to implement, especially due to the unknown number of
segments I imagine.

best,
Peter

Re: [SoX-users] partial fade in

[Nicolas G. <ni...@gr...>]

Martin Guy <so...@fa...> wrote on 2025-07-19 22:50:
> It would be better if fade could be told to start (and/or end) at a 
> level higher than zero, such as
>
>      fade --min 30 --max 100

Yes, that's exactly what I would like.

> https://codeberg.org/sox_ng/sox_ng/issues/525 should be included in 
> sox_ng-14.7.0 in November 2025.

Looking forward to it. Thanks in advance :)

Nicolas

Re: [SoX-users] partial fade in

[Martin G. <so...@fa...>]

On 19/07/25 15:46, Nicolas Graner wrote:
> Hello all,
>
> I would like to ramp the volume of an audio file from a given level to
> full volume over a specified time interval. For instance, increase the
> level linearly from 30% at time t=0 to 100% at time t=10s. In other
> words, perform a fade in starting from a level greater than 0.
>
> I can do it by inserting an appropriate amount of silence before the
> beginning, performing a fade in, then removing the extra silence. But
> this seems unnecessarily complex, especially if the effect is to be
> applied at a time other than the beginning. Is there a better way to do
> it with SoX ?

One way would be to duplicate the track into one copy at a constant 
volume of 30% and the other with a fade-in from 0 to 70% and then mix 
them together but it seems like a bit of a contortion.

It would be better if fade could be told to start (and/or end) at a 
level higher than zero, such as

     fade --min 30 --max 100

with a little thought as to what that means when the fade shape is not 
linear.

https://codeberg.org/sox_ng/sox_ng/issues/525 should be included in 
sox_ng-14.7.0 in November 2025.


    M

[SoX-users] partial fade in

[Nicolas G. <ni...@gr...>]

Hello all,

I would like to ramp the volume of an audio file from a given level to
full volume over a specified time interval. For instance, increase the
level linearly from 30% at time t=0 to 100% at time t=10s. In other
words, perform a fade in starting from a level greater than 0.

I can do it by inserting an appropriate amount of silence before the
beginning, performing a fade in, then removing the extra silence. But
this seems unnecessarily complex, especially if the effect is to be
applied at a time other than the beginning. Is there a better way to do
it with SoX ?

Thanks for any help.
Nicolas

Re: [SoX-users] [solved] sox_ng 14.6.0.1

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

On 29/06/25 15:15, Nicolas Graner wrote:
> Martin Guy <mar...@gm...> wrote on 2025-06-29 13:15:
>> On 28/06/25 22:54, Nicolas Graner wrote:
>>> when running sox_ng, I get :
>>> sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory
>> You probably need to
>>    sudo ldconfig
> Yes, it worked. Thanks a lot!
>
>> It will also be OK after a reboot.
> No. I tried rebooting before and it made no difference.


That's odd. I assume it does that only if you install new libraries then.

Anyway, I've added a gotcha to the INSTALL file, thanks for letting us know


    M

Re: [SoX-users] [solved] sox_ng 14.6.0.1

[Nicolas G. <ni...@gr...>]

Martin Guy <mar...@gm...> wrote on 2025-06-29 13:15:
> On 28/06/25 22:54, Nicolas Graner wrote:
>> when running sox_ng, I get :
>> sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory

> You probably need to
>   sudo ldconfig

Yes, it worked. Thanks a lot!

> It will also be OK after a reboot.

No. I tried rebooting before and it made no difference.

Nicolas

Re: [SoX-users] sox_ng 14.6.0.1

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

On 28/06/25 22:54, Nicolas Graner wrote:

> when running sox_ng, I get :
>
> sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory
>
> What should I do?

You probably need to

    sudo ldconfig

so that the shared library presence index is updated.

It will also be OK after a reboot.


    M

Re: [SoX-users] sox_ng 14.6.0.1

[Nicolas G. <ni...@gr...>]

Hello all,

I'm trying to install sox_ng-14.6.0.1 from the tarball on Debian.

configure, make and make install run without errors.

Then, when running sox_ng, I get :

sox_ng: error while loading shared libraries: libsox_ng.so.3: cannot open shared object file: No such file or directory

What should I do?

My config:
$ uname -a
Linux hypra-graner 5.5.0-0.bpo.2-amd64 #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64 GNU/Linux

TIA,
Nicolas

[SoX-users] sox_ng 14.6.0.1

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

A patch release is available for sox_ng-14.6.0 to

o Fix opusfile detection when using pkg-config
o Fix compilation of libdolbyb
o Fix compilation on MSYS2/MinGW with GCC 15.1
o Fix compilation on MacOS X with older SDKs
o Fix compilation on Sortix
o Fix compilation on AIX 7.3

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

This is turning out to be a difficult one to get right; please report 
any other problems.

    M

Re: [SoX-users] sox_ng-14.6.0 released

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

On 17/06/25 22:20, Sylvain Leroux wrote:
> The one feature it always lacked was good noise reduction. At the 
> time, Audacity was much better than Sox at removing mic and background 
> (mostly) white noise. Maybe there is an issue tracker where I might 
> ask that for the next feature release?


Noise reduction or noise removal? For removal of mic and background 
coloured noise, you need noiseprof and noisered which are already in 
stock sox.


    M

Re: [SoX-users] sox_ng-14.6.0 released

[Sylvain L. <sy...@ch...>]

17 juin 2025 20:16:51 SoX NG <so...@fa...>:

> Well, we seem to have shaken 14.6 out over the last month
> and 14.6.0 is now up at
> 
>     https://codeberg.org/sox_ng/sox_ng/releases
> 
> Apart from the last six months' enhancements, bug fixes and relaxations,
> the most interesting additions are two new effects and
> a new combine method for synth.
> 
> Effect dolbyb is the big one, something people have been hankering for
> for some time now, and its frequency response curves, though not as
> exact as commercial offerings such as DDiCodec claim, are surprisingly
> close to those of a Nakamichi NR-200. We have yet to see how close its
> reactions in the time domain are to the real thing but as it is a digital
> simulation of real Dolby B electronic circuitry, my expectations are good.
> 
> The tricky part is adjusting its response to whatever level the tape was
> digitized at; a real tape deck knows what voltages represent the "Dolby level"
> on the tape itself, corresponding to the saturation level of the tape itself,
> but when it's been digitized through a preamp and the sound card's mixer,
> the level could be anything, which is what its "threshold gain" parameter
> is for. As yet, listening tests at a variety of levels is the best we have
> but are hoping to be able to semi-automate an initial guess for it.
> 
> The second new effect is "softvol". If one of those is in the effects chain,
> the 'v' and 'V' keys in interactive mode (i.e. when it's called as "play_ng")
> adjust the volume while it's playing, something that seems to have stopped
> working when it's trying to adjust the volume in the sound card's mixer,
> and it goes far over "to 11", limiting itself only when the audio would
> have clipped.
> 
> Its other optional parameter slowly increases the volume, again limited to
> when the audio would have clipped. This not only lets you play a range of
> tracks recorded at different levels and adjusts them all to about the same
> volume, but brings out the quiet passages. My personal favourite is
> "softvol 400 10" which gradually increases the volume so that it doubles
> in ten seconds if everything is quiet, but it starts at 40,000% of normal volume
> giving a strange emphasis to the opening moments of the track, which may contain
> something quiet but interesting and at worst make a track start with a burst.
> 
> Lastly, the "synth vdelay" option uses the synthesized wave as an offset
> into a delay line of the input signal, which allows the creation of a range
> of custom choruses and phasers as well as some strange other effects.
> 
> An example of softvol and vdelay in action can be found under
> http://martinwguy.net/test of which Osage Extension is the apparently
> silent second half of the leadout of the film "Killers of the Flower Moon"
> but which is actually something very very quiet: a fly passes,
> distant thunder rolls, wolves howl in the distance, all overlaid with
> the MP3 noise of the original amplified to an audible level and all
> processed with a triangular vdelay to make it yodel by an octave and a half.
> Osage_Harper instead is a 6-minute track that this serendipitous discovery
> inspired a contemporary composer, David "Kawika" Harper, to create.
> 
> Thanks to the many developers who contributed changes included in this release
> and to the authors who pulled all the stops out to help me make the best
> we could of their work.
> 
> The next new-feature release, 14.7.0, is scheduled for November '25,
> and, in August, bug-fix releases to each of the 14.X release series.
> 
> All contributions, suggestions and reports of oddities are welcome.
> 
>     M
> 
> 
> 
> _______________________________________________
> Sox-users mailing list
> Sox...@li...
> https://lists.sourceforge.net/lists/listinfo/sox-users
Congratulations, and thanks to the team and all contributors. It is a pleasure seeing the revival of that project.

The one feature it always lacked was good noise reduction. At the time, Audacity was much better than Sox at removing mic and background (mostly) white noise. Maybe there is an issue tracker where I might ask that for the next feature release?

Best regards,
- Sylvain Leroux

[SoX-users] sox_ng-14.6.0 released

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

Well, we seem to have shaken 14.6 out over the last month
and 14.6.0 is now up at

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

Apart from the last six months' enhancements, bug fixes and relaxations,
the most interesting additions are two new effects and
a new combine method for synth.

Effect dolbyb is the big one, something people have been hankering for
for some time now, and its frequency response curves, though not as
exact as commercial offerings such as DDiCodec claim, are surprisingly
close to those of a Nakamichi NR-200. We have yet to see how close its
reactions in the time domain are to the real thing but as it is a digital
simulation of real Dolby B electronic circuitry, my expectations are good.

The tricky part is adjusting its response to whatever level the tape was
digitized at; a real tape deck knows what voltages represent the "Dolby 
level"
on the tape itself, corresponding to the saturation level of the tape 
itself,
but when it's been digitized through a preamp and the sound card's mixer,
the level could be anything, which is what its "threshold gain" parameter
is for. As yet, listening tests at a variety of levels is the best we have
but are hoping to be able to semi-automate an initial guess for it.

The second new effect is "softvol". If one of those is in the effects chain,
the 'v' and 'V' keys in interactive mode (i.e. when it's called as 
"play_ng")
adjust the volume while it's playing, something that seems to have stopped
working when it's trying to adjust the volume in the sound card's mixer,
and it goes far over "to 11", limiting itself only when the audio would
have clipped.

Its other optional parameter slowly increases the volume, again limited to
when the audio would have clipped. This not only lets you play a range of
tracks recorded at different levels and adjusts them all to about the same
volume, but brings out the quiet passages. My personal favourite is
"softvol 400 10" which gradually increases the volume so that it doubles
in ten seconds if everything is quiet, but it starts at 40,000% of 
normal volume
giving a strange emphasis to the opening moments of the track, which may 
contain
something quiet but interesting and at worst make a track start with a 
burst.

Lastly, the "synth vdelay" option uses the synthesized wave as an offset
into a delay line of the input signal, which allows the creation of a range
of custom choruses and phasers as well as some strange other effects.

An example of softvol and vdelay in action can be found under
http://martinwguy.net/test of which Osage Extension is the apparently
silent second half of the leadout of the film "Killers of the Flower Moon"
but which is actually something very very quiet: a fly passes,
distant thunder rolls, wolves howl in the distance, all overlaid with
the MP3 noise of the original amplified to an audible level and all
processed with a triangular vdelay to make it yodel by an octave and a half.
Osage_Harper instead is a 6-minute track that this serendipitous discovery
inspired a contemporary composer, David "Kawika" Harper, to create.

Thanks to the many developers who contributed changes included in this 
release
and to the authors who pulled all the stops out to help me make the best
we could of their work.

The next new-feature release, 14.7.0, is scheduled for November '25,
and, in August, bug-fix releases to each of the 14.X release series.

All contributions, suggestions and reports of oddities are welcome.

     M

[SoX-users] sox_ng-14.6.0-rc1

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

I am happy to announce a release candidate for the second new-feature 
release of sox_ng

incorporating the best of many people's work over the last six months.


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


It has been tested on aarch, amd, arm, chrp, loongarch, mips, powerpc, 
riscv, sparc and x86 processors, 32- and 64-bit, big- and little-endian 
on AIX, AlmaLinux, AlpineLinux, Archlinux, CentOS, Debian, FreeBSD, 
MacOS X, NetBSD, OpenBSD, OpenSUSE, Rocky, Solaris and Ubuntu and 
compiled (but not tested) for Windows.


New features:

   o Read NSP format files
   o Read MSP2K (Akai sampler) format files
   o Read and write AIFC a-law and u-law encodings
   o Copy AIFF's MARK and INST chunks more often
   o Copy AIFC's MARK and INST chunks
   o Read and write DSF format and read DFF and WSD formats
   o Add the DSD-related "dop" and "sdm" effects
   o Add reading of Ogg FLAC files (with ffmpeg)
   o SDS format is now autodetected
   o MP3 with CRC protection and MP2 formats are now autodetected
   o AIFF format now supports ID3 tags
   o The ID3 "TCOM" (Composer) tag is now supported
   o Add "softvol" effect, a software gain that avoids clipping and 
maybe rises
   o Make the 'v' and 'V' keys prefer to adjust softvol if it is active
   o Add "dolbyb" effect to decode and encode Dolby B noise reduction
   o synth: Add "vdelay" combine method to phase-modulate by the synth wave
   o Remove the limit on the number of echo/echos stages (was 7)
   o Remove the limit on the number of channels that phaser can handle 
(was 4)
   o Raise the limit on the number of chorus stages from 7 to 256
   o Remove unnecessary limits on arguments to 
echo,echos,chorus,phaser,flanger
   o wget, wget2 and curl are sought at runtime instead of at build time and
     ./configure --with-curl now just makes it prefer curl to wget.
   o Make "echos" run 20% faster
   o Make --multi-threaded the default
   o Error messages have been harmonized. The best was
     sox_ng WARN chorus: chorus: warning >>> gain-out can cause saturation
   o When curl or wget fail to fetch a URL, decode the exit status to a 
message
   o Add flow diagrams to --help-effect 
chorus/compand/earwax/echo/echos/phaser

Bug fixes:

   o The "stats" effect's Bit-depth values have been revised to reflect
     what Bit-depth means and handle corner cases like -32768
   o Revise all effects' usage messages to the same format and more helpful
   o "echos" and "chorus" have never worked but now do what they say
   o "bend"'s logarithmic frequency curve is more closely logarithmic
   o Fix "silence" not to add a random selection of fragments at the end
   o "silence" no longer outputs a random selection of fragments at the end
   o Make "firfit" understand frequencies like "10k"
   o Read mono 8-bit MAUD files with an odd number of samples
   o Handle unknown odd-sized chunks in AIFF files
   o Detect and report read errors from short audio files
   o Detect and report write errors to audio files
   o When data read from a pipe is short, report stats for what there was
   o When an fatal error is detected, stop and exit non-zero in all cases
   o No formats or effects are experimental or deprecated any more
   o Multi-channel LADSPA plugins now work
   o The LD_LIBRARY_PATH change has been reverted (it bombed on Solaris)
   o Revert the "Unicode when writing id3 tags" patch which never worked
   o ffmpeg's ADX format is no longer autodetected (too many false 
positives)
   o Reject parameter values of NaN instead of dumping core
   o Correct the manual and make its mcompand example work


Thanks to the many people who actually did the work I've included here,

to the few who have really pulled all the stops out over the last six months

to help me make the best of their ideas and to the many testers and 
suggesters

who've pointed out sharp corners, holes in the road and good future 
directions.


Please test whatever you find most interesting and highlight problems of 
any kind


      M

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

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

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

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


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

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

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


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


Thanks for the suggestion!


     M


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

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

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

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

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

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

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

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


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

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

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

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


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

I guessed maybe that :)

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


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

already-implemented effects are practical.  An EBU-R128

loudness measurement also has some support, and

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

to result in anyone actually putting up some dough

to encourage someone to do it.

(and probably not me unless that it specifically requested;

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

on the list.)


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

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

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

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

all work to do. Just translating and adapting dolbybcsoftwaredecode

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

the algorithm already coded and with considerable help

from the original author.


     M

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

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

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

Marco

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

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


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

Let me know when they're ready! :)


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

submit issues for them possibly with links and/or

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

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


How on earth does a de-reverber work?


    M



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

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

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

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

> How on earth does a de-reverber work?

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

-- 
Jeremy Nicoll - my opinions are my own

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

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

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


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

Let me know when they're ready! :)


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

submit issues for them possibly with links and/or

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

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


How on earth does a de-reverber work?


    M

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

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

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

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

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

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

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

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

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.

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

[Nicolas G. <ni...@gr...>]

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.

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

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

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

[SoX-users] Comment ID3 tag not read

[Nicolas G. <ni...@gr...>]

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