I am interested in this as I've had a suspicion that it's rounding towards zero instead of in the same direction. https://codeberg.org/sox_ng/sox_ng/issues/564
sox-14.4.2 and sox.sf.net head give me b.raw identical to a.raw https://codeberg.org/sox_ng/sox_ng/issues/563
That issue seems to have got deleted, so it's now https://codeberg.org/sox_ng/sox_ng/issues/563
It may work if you set AUDIODRIVER=waveaudio before launching SoX. As to why this stopped working between 14.4.1 and 14.4.2, https://codeberg.org/sox_ng/sox_ng/issues/396
Thanks for reporting. https://codeberg.org/sox_ng/sox_ng/issues/562 I've tried encoding a short sine wave with sox -n 440.wav synth 1 sine ffmpeg -i 440.wav -acodec adpcm_ima_wav 440-adpcm.wav sox 440-adpcm.wav -e signed -b 16 440-adpcm-s16.wav but the result looks like a centered sine wav. Also, this bug was introduced sometime between versions 12.18.2 and 12.99.10 when "ima_rw.c" and "vox.c" were merged into "adpcms.c" So I'm assuming it came in as part of the new adpcms.c but am having trouble...
Patch seems to make it sound correct, applied to sox_ng on 2025-08-09. Will be in next micro releases scheduled for 2025-08-18
https://codeberg.org/sox_ng/sox_ng/issues/552
Thanks. The suggested fix is perfect, modulo *isamp and *osamp https://codeberg.org/sox_ng/sox_ng/issues/545
Thanks. The suggested fix is perfect. https://codeberg.org/sox_ng/sox_ng/issues/545
Confirmed. The suggested fix seems correct. https://codeberg.org/sox_ng/sox_ng/issues/548
Fixed by sox.sf.net commit bb1b9b6
Fixed by sox.sf.net commit b7883ae https://codeberg.org/sox_ng/sox_ng/issues/18
By sox.sf.net commit b7883ae
Preventing division by zero in src/ao.c
https://codeberg.org/sox_ng/sox_ng/issues/537
Do you still have a "crafted mp3 file" that provokes this? Thanks -M
https://codeberg.org/sox_ng/sox_ng/issues/536
https://codeberg.org/sox_ng/sox_ng/issues/109 was applied to sox_ng in October 2024
https://codeberg.org/sox_ng/sox_ng/issues/167 applied to sox_ng in October 2024
https://codeberg.org/sox_ng/sox_ng/issues/262 applied to sox_ng in January 2025
https://codeberg.org/sox_ng/sox_ng/issues/247 applied to sox_ng in January 2025
Was applied to sox_ng in October 2024. https://codeberg.org/sox_ng/sox_ng/issues/185
ping?
Many thanks. Yes, SoX has been sleeping for ten years but now resurges! However, I've been careful to change the source as little as possible so your patches should still apply. Not having any luck with bitbucket - the spinner just keeps spinning - is there another way to get your stuff to me? Blessings -M
Hi @martinwguy Here is the Bitbucket commits which i did to support AAC decoder . https://bitbucket.org/hkurra/sox/commits/branch/master I did this almost 10 years ago not much aware of the context
Well, thanks for the reply after 10 years but I changed 2 companies and forgot what I requested already. Now after reading my messages, I don't do or need anything about that topic. Thanks anyway. From: [email protected] [email protected] on behalf of Martin Guy [email protected] Sent: Thursday, July 10, 2025 11:42 PM To: [sox:feature-requests] [email protected] Subject: [sox:feature-requests] #200 adp format...
sox_ng 14.5.1 and 14.6.0.1 include opus file support. See https://codeberg.org/sox_ng/sox_ng/releases
We currently have no example ADP files or any software other than adpcm_converter.exe that can handle them. It's also discussed at https://hydrogenaudio.org/index.php/topic,16006.0.html but their links to example files are now broken and archive.org has not saved them. If you can provide example ADP files, some description of the file structure or source code of programs that can handle it, we may be able to do something. Redirect to https://codeberg.org/sox_ng/sox_ng/issues/523
sox_ng's Windows builds are 100% static and require no DLLs. https://codeberg.org/sox_ng/sox_ng/releases
sox_ng's Windows builds are 100 static and require no DLLs. https://codeberg.org/sox_ng/sox_ng/releases
sox in.wav out.wav gain -n -89 should do what you want (though normalizing to -89 dB makes for very quiet files!)
sox_ng-14.5.0 can read APE format (using ffmpeg). Native APE support is also planned https://codeberg.org/sox_ng/sox_ng/issues/193
Mans Rullgard's DSD support is included in sox_ng-14.6.0 https://codeberg.org/sox_ng/sox_ng/releases
On Windows, to get access to the audio device you need to have said set AUDIODRIVER=waveaudio before launching SoX, or use sox foo.mp3 -t waveaudio -d https://codeberg.org/sox_ng/sox_ng/issues/396 Just saying sox should list, in one of the final paragraphs, AUDIO DEVICE DRIVERS, the audio drivers that are available. To select a particular audio device as the default one if you have several, you can set AUDIODEV=blablabla though I don't know what blablabla should be for waveaudio devices. As for something...
I can only see sox.html being created by make html in a SoX source directory but they are not installed anywhere unless some distro has installed them in /usr/share/doc or something and forgotten to include the soxpng directory, which contains the tables created with tbl as PNG images. Notice also that these images look awful if your browser is using a white-on-black (or green-on-black in my case) theme. In the meantime you may have better luck with the sox[_ng].pdf file. Ben, if you can tell us...
sox_ng-14.5.0 can read M4A files using ffmpeg but having native support would be better as it may enable writing of it too. @Harsh If you still have the diffs for your implementation I would be happy to see if I can include that in sox_ng https://codeberg.org/sox_ng/sox_ng/issues/198
https://codeberg.org/sox_ng/sox_ng/issues/517 How should we display the phase information on the spectrogram? (Maybe comment there rather than here so I'm more likely to see it)
https://codeberg.org/sox_ng/sox_ng/issues/44 Implemented in sox_ng-14.6.0
But check out https://github.com/prof-spock/SoX-Plugins which reimplements libsox in C++ and floating point as VST3 plugins.
https://codeberg.org/sox_ng/sox_ng/issues/515
https://codeberg.org/sox_ng/sox_ng/issues/513
Windows builds of sox_ng with updated everything are now available at https://codeberg.org/sox_ng/sox_ng/releases
You can split the track into separate channels, normalize each and then reunite them: sox in.wav left.wav remix 1 norm sox in.wav right.wav remix 2 norm sox -M left.wav right.wav out.wav There is also gain -n with -e or -B or -b to equalize all channels to the same maximum level. We could also add -e, -B and -b to the norm effect. https://codeberg.org/sox_ng/sox_ng/issues/512
You can split the track into separate channels, normalize each and then reunite them: sox in.wav left.wav remix 1 norm sox in.wav right.wav remix 2 norm sox -M left.wav right.wav out.wav There is also gain -n with -e or -B or -b to equalize all channels to the same maximum level.
You can split the track into separate channels, normalize each and then reunite them: sox in.wav left.wav remix 1 norm sox in.wav right.wav remix 2 norm sox -M left.wav right.wav out.wav
CDDA endianess wrong
Thanks for this. As you can probably tell, the project is somewhat moribund at present. I hope to find time to build on some of the excellent work that has been done elsewhere to revive it soon; but in the mean time there are forks such as https://codeberg.org/sox_ng/sox_ng/ that are being actively worked on.
sox.exe 14.4.2 still has a slight memory leak
https://codeberg.org/sox_ng/sox_ng/issues/441 Resolved for INST and MARK. It should already support COMT comments but for other chunks it doesn't know about there is https://codeberg.org/sox_ng/sox_ng/issues/446
Should be fixed in sox_ng, to be released end of May 2025
This is CVE-2021-23172 Absent in 14.4.2, Debian and sox_ng Present in 42b355 and sox.sf.net master
This is CVE-2021-23172 Absent in 14.4.2, Debian and sox_ng Present in 42b355 and sox.sf.net master
This is CVE-2021-3643 Absent in 14.4.2, Debian and sox_ng Present in 42b355 and sox.sf.net master
This is CVE-2021-33844 Absent in 14.4.2, Debian and sox_ng. Present in 42b355 and sox.sf.net master
This is CVE-2021-33844 Absent in 14.4.2, Debian and sox_ng Present in 42b355 and sox-sf-net master
https://codeberg.org/sox_ng/sox_ng/issues/425 Fixed by adding SOX_EFF_CHAN to the effect handler's flags To be released in sox_ng-14.4.5 and 14.5.1 in a few weeks' time.
I think sox must avoid clipping whenever possible. If this workaround is the easiest solution then, when sox determines the user wants 32 bit float as output or stats, it must start using libsndfile implicitely without specifying -t sndfile.
There is a way: sox -t sndfile 32_bit_float.WAV -n stats -w 0.01 https://codeberg.org/sox_ng/sox_ng/issues/422
Anzi, like it says in the manual, "If you need an interactive, graphical audio editor, use audacity(1)." or "temerity" as it's now called. SoX is a command line tool. Fast, expressive, cryptic, powerful. Using a GUI is like going into a boulangerie in a country where you don't speak the language. You can point at the things you see, say "This, this and this" and hold out your hands so they can take the money they want. The command line is like being able to say "I'd like something with wholemeal...
https://codeberg.org/sox_ng/sox_ng/issues/412
Confirmed in 14.4.2, 42b355 and current sox.sf.net git HEAD Absent in Debian and sox_ng-14.5.0 sox FAIL formats: can't open input file `poc_assert_rate_init': implausibly la rge number of channels
Autoconf failure, following INSTALL instructions
git clone https://git.code.sf.net/p/sox/code sox cd sox head INSTALL autoreconf -fi head INSTALL
Absent in 14.4.2; present only in 42b355 and current git master
Do you mean that play -t waveaudio doesn't work in scripts but does at the DOS prompt? As a workaround you can set AUDIODRIVER=waveaudio beforehand. To make it persistent via the GUI, it should be: Control Panel : System : Advanced : Environment Variables https://codeberg.org/sox_ng/sox_ng/issues/396
Confirmed in plain 14.4.2: malloc(): corrupted top size Aborted (core dumped)) Absent in plain 42b355, Debian, sox_ng.14.5.0.3 and sox_ng-14.5.0.3 with address sanitizer: sox FAIL formats: can't open input file `poc_file': Implausible dictionary size in HCOM header Confirmed in 42b355 and current git master with address sanitizer: ERROR: AddressSanitizer: heap-buffer-overflow
Confirmed in plain 14.4.2 malloc(): corrupted top size Aborted (core dumped)) Absent in plain 42b355, Debian, sox_ng.14.5.0.3 and sox_ng-14.5.0.3 with address sanitizer sox FAIL formats: can't open input file `poc_file': Implausible dictionary size in HCOM header Confirmed in 42b355 with address sanitizer.
Confirmed in 14.4.2 and 42b355 and current sox.sf.net HEAD Absent in Debian and sox_ng-14.5.0: sox_ng FAIL formats: can't open input file `poc_file': Implausible dictionary size in HCOM header
sox-14.4.2: sox WARN voc: VOC input: short file Exits 0 and creates a 3132-sample file Debian bookworm sox and sox_ng-14.5.0: Exits 0 and creates a 4-sample file 42b355: Floating point exception (core dumped)
I can't reproduce this on Debian bookworm, building with the same compiler and flags, with your command line or with ./configure CC=clang CFLAGS="-fsanitizer=address -O0 -g3" and with or without the address sanitizer. I'm assuming 14.4.3git is commit 42b355 on sox.sf.net, the one some distros (gentoo and a few others) picked up. With Debian bookworm's SoX, sox.sf.net 42b355 or current git HEAD I get: sox FAIL formats: can't open input file `poc_file': implausibly large number of channels or, with...
I can't reproduce this on Debian bookworm, building with the same compiler and flags, with your command line or with ./configure CC=clang CFLAGS="-fsanitizer=address -O0 -g3" and with or without the address sanitizer. I'm assuming 14.4.3git is commit 42b355 on sox.sf.net, the one some distros (gentoo and a few others) picked up. With Debian bookworm's SoX, sox.sf.net 42b355 or current git HEAD I get: sox FAIL formats: can't open input file `poc_file': implausibly large number of channels or, with...
There is the sox --temp directory option described in the manual. If you are on Windows you can also set TEMP or TMP but on Unix this isn't respected. For a persistent solution, you can add SOX_OPTS="--temp ." export SOX_OPTS to your ~/.profile (or ~/.bashrc or ~/.bash_profile if you use bash - it's a bit confused about what its startup files are; adding test -f ~/.profile && source ~/.profile at the start of ~/.bashrc and not having ~/.bash_profile seems the best workaround)
Yes, silence has other problems too, like trimming from 0.02 seconds after silence starts and coughing out a random selection of garply after the trimmed audio (the second fixed in sox_ng) Thanks for the exhaustive analysis. https://codeberg.org/sox_ng/sox_ng/issues/395
Thanks https://codeberg.org/sox_ng/sox_ng/issues/394
No it doesn't
https://codeberg.org/sox_ng/sox_ng/issues/241
Applied in sox_ng main branch, will be released on 18 feb 2025
Note that the 'duration' of the silence effect defaults to meaning "in samples", not "in seconds". From what you say it sounds like there is a problem, but I wanted to make sure you're aware of checking for silences of one sample. For seconds you need to say 1s and -1s
From the manual: "If you need an interactive graphical editor, use audacity(1)"
You could make this happen at runtime by modifying src/formats.cto if (lt_dlforeachfile(PKGLIBDIR, init_format, NULL) != 0) lt_dlforeachfile(getenv("LD_LIBRARY_PATH")); https://codeberg.org/sox_ng/sox_ng/issues/295 Should LD_LIBRARY_PATH override PKGLIBDIR or vice versa?
There are bugs in the Bit-depth calculation, among which one is revealed by the positive/negative test with low bits zero, but the OP's extensive study and exhaustive test suite are based on a misconception of what bit-depth is: that it should be the same for the positive and negative versions of the same signal. TL;DR: sample value +8 requires one more bit that sample value -8. See https://codeberg.org/sox_ng/sox_ng/issues/273#user-content-analysis
SoThere are bugs in the Bit-depth calculation, among which one is revealed by the positive/negative test, but the OP's extensive study and exhaustive test suite are based on a misconception of what bit-depth is: that it should be the same for the positive and negative versions of the same signal. TL;DR: sample value +8 requires one more bit that sample value -8. See https://codeberg.org/sox_ng/sox_ng/issues/273#user-content-analysis
Sourecorge is ahit There are bugs in the Bit-depth calculation, among which one is revealed by the positive/negative test, but the OP's extensive study and exhaustive test suite are based on a misconception of what bit-depth is: that it should be the same for the positive and negative versions of the same signal. TL;DR: sample value +8 requires one more bit that sample value -8. See https://codeberg.org/sox_ng/sox_ng/issues/273#user-content-analysis
Despite the OP's extensive study and exhaustive test suite, this issue is based on a misconception of what bit-depth is. See https://codeberg.org/sox_ng/sox_ng/issues/273#user-content-analysis TL;DR: sample value +8 requires one more bit that sample value -8.
@JarC There is now a Windows build of sox_ng at https://codeberg.org/sox_ng/sox_ng/releases/tag/sox_ng-14.5.0.1-rc1
Oh, I see!!! That's nice :) Either way, others or Sox contributors is fine. We can properly cite it now. Thank you so much
The BibTeX manual says: If you have too many names to list in an author or editor field, you can end the list with “and others”; the standard styles appropriately append an “et al.” so "and others" it is for BibTeX , Thank you for your precision
OK, the final version is: To cite SoX in publications use: Lance Norskog, Chris Bagwell et al. (2015). SoX: Sound eXchange. the Swiss Army knife of audio manipulation. URL http://sox.sourceforge.net A BibTeX entry for SoX users is @manual{SoX2015, title = "SoX: Sound eXchange, the Swiss Army knife of audio manipulation", author = "Norskog, Lance and Bagwell, Chris and others", edition = "14.4.2", year = 2015, url = "http://sox.sourceforge.net", }
Hi Martin, Sorry I could not come to this before. I could not find the bibtex manual you mention, but I think I would prefer to keep it as Sox contributors, since it´s clearer about the role these "others" play. Alia and others should be just synonyms, and I bet some people are going to complain is they read "others"/"alia". We use "alia"/"other" to abbreviate, but all of them should be mentioned somewhere in the paper, and people are going to say "this is wrong, because these alia don't exist anywhere"...
Inigo, I tried to mail you privately to check that your software handles "and others" correctly, but mail to [email protected] bounces saying "550 unknown user" so this is the only communication channel we have :-/ Can you check that "Bagwell and others" works correctly for you?
Inigo, I tried to mail you provately to check that your software handles "and others" correctly, but mail to [email protected] bounces saying "unknown user" so this is the only communication channel we have :-/ Can you check that "Bagwell and others" works correctly for you?
The standard way to have an explicit "et al" in BibTeX is to use the pseudo-author "others", which is documented as point 5 on p. 12 of the BibTeX manual.
OK, the final version is: To cite SoX in publications use: Lance Norskog, Chris Bagwell et al. (2015). SoX: Sound eXchange. the Swiss Army knife of audio manipulation. URL http://sox.sourceforge.net A BibTeX entry for SoX users is @manual{SoX2015, title = "SoX: Sound eXchange, the Swiss Army knife of audio manipulation", author = "Norskog, Lance and Bagwell, Chris and SoX Contributors", edition = "14.4.2", year = 2015, url = "http://sox.sourceforge.net", }
That looks great, thanks!!! Indeed, the parser gets "et al." as part of the name. I don't think there's a standard way to adress this issue. A common practice is to name it as "R development team". In this case, since there appear to be two clear developers and contributors, I don't think anyone is ever going to complain with (this is how I edited it for myself): @manual{SoX2015, title = "SoX: Sound eXchange, the Swiss Army knife of audio manipulation", author = "Norskog, Lance and Bagwell, Chris...
Thanks. We're almost there: To cite SoX in publications please use: Lance Norskog, Chris Bagwell et al. (2015). SoX: Sound eXchange. the Swiss Army knife of audio manipulation. URL http://sox.sourceforge.net A BibTeX entry for SoX users is @manual{SoX2015, title = "SoX: Sound eXchange, the Swiss Army knife of audio manipulation", author = "Norskog, Lance and Bagwell, Chris et al.", edition = "14.4.2", year = 2015, url = "http://sox.sourceforge.net", } We have just one query: The main author usually...
Thanks. We're almost there: To cite SoX in publications please use: Lance Norskog, Chris Bagwell et al. (2015). SoX: Sound eXchange. the Swiss Army knife of audio manipulation. URL http://sox.sourceforge.net A BibTeX entry for SoX users is @manual{SoX2015, title = "SoX: Sound eXchange, the Swiss Army knife of audio manipulation", author = "Bagwell, Chris and Norskog, Lance et al.", edition = "14.4.2", year = 2015, url = "http://sox.sourceforge.net", } We have just one query: The main author usually...
Thanks. We're almost there: To cite SoX in publications please use: Lance Norskog, Chris Bagwell et al. (2015). SoX: Sound eXchange. the Swiss Army knife of audio manipulation. URL http://sourceforge.net/projects/sox A BibTeX entry for SoX users is @manual{SoX2015, title = "SoX: Sound eXchange, the Swiss Army knife of audio manipulation", author = "Bagwell, Chris and Norskog, Lance et al.", edition = "14.4.2", year = 2015, url = "http://sox.sourceforge.net", } We have just one query: The main author...
PS You could report the ffmpeg axis labelling nastiness to their issue tracker as we don't handle that but thanks for the info.