Activity for SoX - Sound eXchange
-
Martin Guy posted a comment on ticket #382
In Debian testing, yes. sox_ng has --multi-threaded enabled by default which usually completes sooner at a cost of more total CPU time due to more inter-process communication. Sorry this has caused breakage; maybe it should go back to --single-threaded by default to avoid such scenarios.
-
David Mandelberg posted a comment on ticket #382
Oops, apparently Debian switched from sox to sox_ng and I didn't realize it. I filed this at https://codeberg.org/sox_ng/sox_ng/issues/826 so this issue can be closed.
-
I just tested on another computer I have access to. It's an AMD 5600G running Debian trixie, sox 14.4.2+git20190427-5+b3 and linux 6.12.63+deb13-amd64. On that system, running in parallel is actually faster than in series, which is what I'd normally expect: $ time (for x in {1..3}; do sox silence.wav -n stats -b 16 & done; wait) [...] real 0m0.040s user 0m0.114s sys 0m0.004s $ time (for x in {1..3}; do sox silence.wav -n stats -b 16; done; wait) [...] real 0m0.118s user 0m0.102s sys 0m0.016s
-
parallel stats performance scales poorly
-
sox_open_mem_write() only creates the file; it doesn't write anything into it. You'll find out how much is written from the subsequent calls to sox_write().
-
Steve Baker created ticket #381
Missing checks for misplaced command line arguments.
-
The -V0 parameter to 'play' doesn't turn off all output.
-
jwdevel created ticket #132
Ability to set PuseAudio "application name" via env. var.
-
Eight years on... You're welcome & thanks for confirming it works OK https://codeberg.org/sox_ng/sox_ng/issues/203
-
Stephen Sherry posted a comment on ticket #307
@martinwguy, that seems to have worked. Thanks very much.
-
sox_ng from 14.5.0 on reads APE files (and dozens of others) using ffmpeg.
-
Hi! I've had another look at this, and the problem may be that the code calls sox_memstream_write(), writes a load of stuff into it and then calls sox_read on the same sox_format_t that was opened for writing, whereas what it should do is sox_close() the output and then read the data directly from the memory buffer pointer and length that are updated only by stdio when the file is flushed or closed. I suspect that it "works" when using a disk file because either SoX or stdio has separate read and...
-
Hi! I've had a look at this and it seems that the reason is that "speed" changes the sample rate but the call to sox_open_write() specifies the sample rate of the output file as a copy of that of the input file. It is sox.c, which is "just" another client of libsox, that automatically inserts effects in the chain to adapt the sample rate at the end, make the number of channels match, not libsox, which is why it works from the command line as you expected. If you add a "rate 48000" (or whatever the...
-
Hi! I've had a look at this and it seems that the reason is that "speed" changes the sample rate but the call to sox_open_write() specifies the sample rate of the output file as a copy of that of the input file. It is sox.c, which is "just" another client of libsox, that automatically inserts effects in the chain to adapt the sample rate at the end, make the number of channels match, not libsox, which is why it works from the command line as you expected. If you add a "rate 48000" (or whatever the...
-
Found and fixed an out-by-one error when the window size in samples is exactly the same as the file length. https://codeberg.org/sox_ng/sox_ng/issues/561 Thanks for reporting this
-
Greetings! Pythagorean tuning just went into sox_ng as a synth -p option like -j but I'm boggling at the number of alternative 12-tone exact-octave tunings like Werckmeister I, II and III, not to mention non-exact-octave and Gamelan or 53-tone scales. https://codeberg.org/sox_ng/sox_ng/issues/729 I have the distinct sensation that I don't know what I'm doing. Can you advise how to proceed? M
-
soxrc
-
I think we can unite all these requirements. It's /etc/soxrc, $HOME/.soxrc because I'm old and I get to decide :) I'm sure .local/ and .config/ are nice but dot files and rcs are old-skool and SoX is old-skool. And I'm old-skool. sox.sf.net has never used /etc/soxrc so we can swipe it instead of cowering under a sox_ngrc or a soxrc_ng. I assume that "identical to the command line" means "with the leading -- for lines like --combine mix" when saying "when I give multiple files, I want to hear them...
-
prof-spock has done this at https://github.com/prof-spock/SoX-Plugins
-
Done in sox_ng git, will be released in 14.8 in May 2026
-
That looks do-able with a bit of translation from C# to C. https://codeberg.org/sox_ng/sox_ng/issues/730
-
Please feel free to write for https://codeberg.org/sox_ng/sox_ng/wiki either sending me the page text and I'll format it, or if you are happy to write in markdown, I can add you as a collaborator on the project.
-
https://codeberg.org/sox_ng/sox_ng/issues/522
-
https://codeberg.org/sox_ng/sox_ng/issues/717
-
See https://codeberg.org/sox_ng/sox_ng/issues/708 which regards other people's requests for textual spectrogram output but your ideas of on-the-fly output and of being able to ask for values in frequency bands (average? maximum in-range?) is interesting. If you're still with us, I'm more likely to be told you've written if you comment there.
-
https://codeberg.org/sox_ng/sox_ng/issues/716 However, from the attachment, it looks like everything is transparent except for pixels over a certain loudness, not the opposite as the description seems to say. Am I understanding correctly? If you're still with us, I'm more likely to notice a comment there than here.
-
https://codeberg.org/sox_ng/sox_ng/issues/714
-
Yes, it can read and write w64 files, and so can sox-14.4.1 (Feb 2013) $ sox_ng -n somefile.w64 trim 0 7:00:00 $ ls -l somefile.w64 -rw-rw-r-- 1 martin martin 4838400104 Nov 26 18:45 somefile.w64 $ file !$ file somefile.w64 somefile.w64: Sony Wave64 RIFF data, WAVE 64 audio, mono 48000 Hz $ soxi somefile.w64 Input File : 'somefile.w64' Channels : 1 Sample Rate : 48000 Precision : 32-bit Duration : 07:00:00.00 = 1209600000 samples ~ 1.89e+06 CDDA sectors File Size : 4.84G Bit Rate : 1.54M Sample Encoding:...
-
Does mansr's DSF/DFF file support, included in sox_ng-14.6 and later, do what you need?
-
Paul posted a comment on ticket #202
Although no, it is relevant. Here's an example.
-
No longer relevant.
-
"sox format" should write the data as it is generated, not all at once when all input has been processed. For real-time use, you'd have to duplicate the input somehow, so that both SoXen can read the same data. You can do this on Unix with rm -f fifo1 fifo2 mkfifo fifo1 fifo2 tee fifo1 > fifo2 & # Reads stdin and sends it to both fifos sox_ng -M -t sox "|sox_ng fifo1 -p remix 1,1 fir filter1.txt" "|sox_ng fifo2 -p remix 2,1 fir filter2.txt" PN_shelving.wav # or "-b 16 -t raw -" to send to stdout...
-
https://codeberg.org/sox_ng/sox_ng/issues/705
-
https://codeberg.org/sox_ng/sox_ng/issues/704
-
https://codeberg.org/sox_ng/sox_ng/issues/704
-
Yes, that sounds reasonable, https://codeberg.org/sox_ng/sox_ng/issues/703
-
If I understand what you need, to cross-fade between samples instead of just concatenating them, you should be able to achieve this with the splice effect; there is an example of how to use it in the manual.
-
rec audio.wav trim 0 30:00 should record exactly half an hour of sound
-
sox_ng 14.7.0 and on have EBU R 128 Loudness measurements, Momentary, Short Term and Integrated, incorporated into the stat effect. https://codeberg.org/sox_ng/sox_ng/releases Does that do what you need?
-
Thanks. Can you provide some example files to test possible support for this format?
-
sox_ng now has AAC/M4A decoding using the external ffmpeg program. Unfortunately, AAC's baselins patents expire in 2028 and the last of the extensions in 2031 so for the moment it won't be including native support. Thank anyway
-
Hi. What is .xtr file format? The closest I've found in a web search is a mention of recordings of Voice-Over-IP telephone calls by X-Lite, but we would need a specification of the file format and some example files to test it with; if it's the file format of a commercial product, specs are unlikely to be available.
-
Sorry, what do you mean by "cut 8 khz and to move it to 0-8Khz"? What would be the characteristice of the resulting file?
-
https://codeberg.org/sox_ng/sox_ng/issues/702
-
sox_ng includes everything, now that all patents have expired (AMR coding expires last year and LPC10's previously uncertain copyright status is no sorted out). Its Windows EXEs at https://codeberg.org/sox_ng/sox_ng/releases contain everything; for Unix systems you'll either have to wait for your software distribution to switch to sox_ng, or compile it yourself - see its README.md for instructions to do this.
-
Thanks for the suggestion. To be useful, would printing them out as INFO messages (with sox -V) be sufficient? If so, can you provide a sample file containing an EVNT data chunk to be able to try this out?
-
Thanks. https://codeberg.org/sox_ng/sox_ng/issues/700
-
https://codeberg.org/sox_ng/sox_ng/issues/690
-
Thanks; the coreaudio API was updated by https://codeberg.org/sox_ng/sox_ng/commit/c5aa611 including arbitrary-length device name size
-
Thanks; applied by https://codeberg.org/sox_ng/sox_ng/commit/31e6b04
-
Thanks; applied by https://codeberg.org/sox_ng/sox_ng/commit/263f885
-
Thanks; applied by https://codeberg.org/sox_ng/sox_ng/commit/263f885
-
Thanks. Leak fixed by https://codeberg.org/sox_ng/sox_ng/commit/afd9cdb Dictionary validation by https://codeberg.org/sox_ng/sox_ng/commit/db7a256
-
Thanks; already fixed in sox_ng
-
Already removed from sox_ng; there, test/ is now the new regression test suite.
-
Thanks; sox_ng now accepts any line length; see https://codeberg.org/sox_ng/sox_ng/issues/412
-
Thanks; fixed in sox_ng by https://codeberg.org/sox_ng/sox_ng/issues/20
-
Thanks; this has already been fixed in sox_ng by using memmove() instead of memcpy()
-
Updated to fit the new API and merged into sox_ng as https://codeberg.org/sox_ng/sox_ng/commit/220795d for the next bugfix release on 2026-02-18. Many thanks -M
-
Thanks, that's gone into sox_ng today (6.5 years later!) https://codeberg.org/sox_ng/sox_ng/commit/f4c709a modified to apply to all uses of rewind() and will go out in the next bugfix releases on 2026-02-18 Blessings M
-
Charles posted a comment on ticket #275
I'm still here :) . It was on Linux (Ubuntu) with its standard x86-64 kernel, so nothing exotic.
-
Fixed in sox_ng-14.5.0.1 and later at https://codeberg.org/sox_ng/sox_ng/releases
-
A modified version of LoRd_MuldeR's patch is included in sox_ng-14.5.0.1 and later at https://codeberg.org/sox_ng/sox_ng/releases Could you check that it works for you?
-
A modified version of LoRd_MuldeR's patch is included in sox_ng-14.5.0.1 and later at https://codeberg.org/sox_ng/sox_ng/releases Could you check that it works for you?
-
A modified version of LoRd_MuldeR's patch is included in sox_ng-14.5.0.1 and later. Could you check that it works for you?
-
https://codeberg.org/sox_ng/sox_ng/issues/695 If you're still with us, Charles and Trevor, do you remember what CPU/OS this happened on in case it's a little-endian/big-endian problem or similar?
-
I'm not actively working on a project that uses SoX anymore unfortunately.
-
https://codeberg.org/sox_ng/sox_ng/issues/516 Fixed in the git version of sox_ng, will be released in sox_ng.14.8 in May 2026
-
sox-14.4.2 and sox.sf.net head give me b.raw identical to a.raw However, 32-bit floating point has a precision of 25 bits (24-bit mantissa plus the sign bit) so I think this is a moot point.
-
This just went into sox_ng in the interrim release 14.6.1+git20251026 at https://codeberg.org/sox_ng/sox_ng/releases sox_ng in.wav -n stat now includes EBUR128 True Peak: 0.818931 EBUR128 Momentary: -30.340801 EBUR128 Short term: -35.450052 EBUR128 Integrated: -21.358310 Those are in Loudness Units relative to Full Scale (LUFS). Is that the sort of thing that's wanted, and can someone check that the figures it reports are correct? There's 14.6.1+git20251026 at https://codeberg.org/sox_ng/sox_ng/releases...
-
https://codeberg.org/sox_ng/sox_ng/issues/151
-
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
-
Raphaël posted a comment on ticket #124
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
-
Harsh kurra posted a comment on ticket #203
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
-
kerem posted a comment on ticket #200
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: feature-requests@sox.p.re.sourceforge.net feature-requests@sox.p.re.sourceforge.net on behalf of Martin Guy martinwguy@users.sourceforge.net Sent: Thursday, July 10, 2025 11:42 PM To: [sox:feature-requests] 200@feature-requests.sox.p.re.sourceforge.net 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
