Activity for SoX - Sound eXchange
-
Yuichi Ohkawa posted a comment on ticket #354
This issue is not due to the old API, but in src/coreaudio.c:155. This is caused by specifying "property_size", instead of 256, which is the length of "name". The property_size is value for length of device structure list. This is also a security issue sice if there are many devices and property_size may exceed 256. Also, property_size is not initialized in the for loop, so if there are multiple devices, the names will become shorter and shorter.
-
Joshua Cannon created ticket #235
Respect LD_LIBRARY_PATH for handler loading
-
Walther Maldonado created ticket #372
threshold parameter for "silence" filter isn't handled correctly.
-
Need a way to specify the directory for temporary files.
-
hkctkuy created ticket #128
Division by zero at `wav.c:967`
-
Division by zero at `voc.c:334`
-
Missing attachments: input and patch
-
Missing attachments
-
Global-buffer-overflow at `adpcms.c:58`
-
roucaries bastien posted a comment on ticket #369
Fixed by
-
This is CVE-2023-32627
-
Fixed by debian fix for CVE-2021-23159
-
This is CVE-2023-34318
-
Debian fix of CVE-2021-23159 and CVE-2021-23172. fix it https://salsa.debian.org/lts-team/packages/sox/-/blob/debian/stretch/debian/patches/CVE-2021-23159.patch
-
This is CVE-2023-34432
-
This is CVE-2023-26590
-
Fixed by fix of CVE-2022-31650 https://salsa.debian.org/lts-team/packages/sox/-/blob/debian/stretch/debian/patches/CVE-2022-31650.patch
-
babybus created ticket #370
FPE in SoX 14.4.3git (src/aiff.c:622:58 in lsx_aiffstartwrite)
-
FPE in SoX 14.4.3git（src/voc.c:334:18 in read_samples)
-
heap-buffer-overflow in SoX 14.4.3git（src/hcom.c:160:41 in startread）
-
heap-buffer-overflow in SoX 14.4.3git（src/formats_i.c:98:16）
-
Jonny Anon posted a comment on ticket #307
There is a solution to this here https://sourceforge.net/p/sox/patches/105/ I lack the skill to compile binaries myself so I hope you can implement this into the main build.
-
Gordon Delgado created ticket #234
Can Normalization Be Dom Independently For Each Channel
-
fca posted a comment on ticket #363
I can confirm this happens on Arch Linux Arm (aarch64). Using --norm=-3 succeeds as a workaround for me as well. sox --norm input.oga output.oga [1] 15349 segmentation fault sox --norm gdb sox run --norm input.oga output.oga Starting program: /usr/bin/sox --norm input.oga output.oga [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x0000007ff7d2470c in strlen () from /usr/lib/libc.so.6...
-
Jan Starý posted a comment on ticket #366
(Similarly for *.txt files)
-
$ make html groff -t -man -Thtml -P -Dsoxpng sox.1 | sed 's,<head>,&<link rel="stylesheet" href="http://sox.sourceforge.net/pub/skins/sox/sox.css" type="text/css"></link>,' > sox.html /bin/sh: groff: command not found groff -t -man -Thtml -P -Dsoxpng soxi.1 | sed 's,<head>,&<link rel="stylesheet" href="http://sox.sourceforge.net/pub/skins/sox/sox.css" type="text/css"></link>,' > soxi.html /bin/sh: groff: command not found groff -t -man -Thtml -P -Dsoxpng soxformat.7 | sed 's,<head>,&<link rel="stylesheet"...
-
html and pdf generation is broken
-
macos: curl not wget
-
$ sox ~/Downloads/sox-zero.voc -n noiseprof /dev/null sox FAIL sox: `/Users/hans/Downloads/sox-zero.voc' format changed: Unsupported data format
-
$ sox ~/Downloads/sox-zero.hcom -n noiseprof /dev/null sox FAIL formats: can't open input file `/Users/hans/Downloads/sox-zero.hcom': premature EOF
-
Cannot reproduce with current git: $ play Downloads/sox-zero.wav play FAIL formats: bad input format for file `Downloads/sox-zero.wav': data encoding or sample size was not specified $ sox ~/Downloads/sox-zero.wav -n noiseprof /dev/null sox FAIL formats: bad input format for file `/Users/hans/Downloads/sox-zero.wav': data encoding or sample size was not specified What is the version where you are seeing this?
-
After adding a few naive printfs: with any audio file whatsoever, the ft->encoding.bits_per_sample in these lines is zero. Setting the buf_size is just where it shows.
-
Also, using AO as an output makes play crash with a SIGFPE on any file whatsoever, not just on those example files. Which makes me believe that 1. AO support is broken 2. Nobody's been using it for a long time Are there any systrems that use AO as their default/native sound playing system?
-
I don't understand the buf_size dance either. In commit 3d4cdf3d163b9d8c6a4241ff412b785178af4865 it was changed from ao->buf_size = sox_globals.bufsiz - (sox_globals.bufsiz % ft->signal.size); ao->buf_size *= ft->signal.size; to ao->buf_size = sox_globals.bufsiz - (sox_globals.bufsiz % (ft->encoding.bits_per_sample >> 3)); ao->buf_size *= (ft->encoding.bits_per_sample >> 3); Apparently, something like what the first line does needs to be there, because with a simple ao->buf_size = sox_globals.bufsiz;...
-
I just tried on OpenBSD with only AO compiled in (--with-ao), --disabling all other outputs, including the native sndio. I can confirm that play segfaults on both of your examples. $ play -V6 sox-fpe.voc play DBUG sox: Looking for a default device: trying format `ao' Floating point exception (core dumped) #0 0x00000b33b5565459 in startwrite (ft=0x7f7ffffcfa20) at ao.c:38 38 ao->buf_size = sox_globals.bufsiz - (sox_globals.bufsiz % (ft->encodin g.bits_per_sample >> 3)); (gdb) bt #0 0x00000b33b5565459...
-
Is AO the default output on Fedora? If not, how ecatly do you send the output to AO? Does the FPE always occur when playing the above files via AO? Have you tried on other systems that use AO as their output?
-
Also note that this is not "the output of added effect". In fact, it is perfectly legal for effects tp change the rate of number of channels: rate will change the sample rate by definition, synth will add channels, and remix will change the number of channels ...
-
$ ./example1 monkey.wav monkey.cdr formats: cdda can't encode at 8012Hz; using 44100Hz formats: cdda can't encode mono; setting channels to 2 What else is there to be done?
-
If we want to use libsndfile for core functionality then we'll need an in-tree copy anyway Isn't the whole point of pushing these formats into libsndfile that sox will not need its own copy of them?
-
macOS build is like any other
-
The manpages says To specify that no comment should be stored in the output file, use --comment "" . So I don't think this is a bug.
-
get device name properly on macOS
-
Can we please close this, after more than a decade? As to the feature itself: the proposed .soxrc introduces new syntax, which would require a new parser, as if that's not a mess already. If sox ever has this, let's agree the syntax has to be identical to the command line; at which point the only feature is that you don;t have to type it; which imho means it's not even worth the extra complexity.
-
move AUTHORS to the manpage
-
sphere: do not underflow
-
fixed in https://sourceforge.net/p/sox/code/merge-requests/22/
-
validate channels and rate
-
aiff: don't write a silly number of channels
-
wav: bits per sample cannot be zero
-
voc validate bits per word
-
hcom: validate dicsize, don't leak dictionary
-
don't leak comments on failed open_{read,write}
-
What "sox.html help" are you talking about? sox comes with a standard manpage ...
-
remove the test suite
-
I am ignoring the fuzzer angle, my only concern is the behaviour of sox. IMHO sox shuld just plain refuse to work with a file that claims to have 2147483648 channels or a samplerate of 4.13624e-25 ...
-
Han Zheng posted a comment on ticket #360
Sorry for the confusion, maybe I didn't explain it clearly. As an secrurity researcher, I'm trying to develop a fuzzer and find those crafted expectational cases to validate the fuzzers' efficiency and if possible, help developers to fix those bugs (if they're considered as bugs). Are they specificaly crafted, with bogus sample rate and number of channels etc to trigger these exceptional cases you're correct, it's not a valid aiff files. since the goal of fuzzer is finding crafted file to trigger...
-
Are they aiff files? They have no filename extension, but contain a COMM chunk. Renaming them to aiff, this is what soxi has to say about the assert and the fpe example, respectively: Input File : 'sox-assert.aiff' (sf) Channels : 1073807359 Sample Rate : nan Precision : 8-bit Duration : 00:00: nan = 0 samples ~ nan CDDA sectors File Size : 4.05k Bit Rate : 0.00 Sample Encoding: 8-bit Signed Integer PCM Comment : '' Input File : 'sox-fpe.aiff' (sf) Channels : 2147483648 Sample Rate : 4.13624e-25...
-
more channels for dat files
-
What is the @@ in 'sox --single-threaded @@ -t aiff /dev/null' supposed to be? you're correct, @@ is the place to put the input file. This is fuzzer's argument format. And whatever audio file I give there, it works. did you try the file given in poc.zip? in my environment I can reproduce these two bugs via the poc file given in zip.
-
Looking at src/aiff.c, sox does recognize and read and write INST, MARK, COMT and other aiff chunks. It ignores INST if MARK isn't also present. Let's test with your file ...
-
Can you please post an example aiff file with all the headers you want preserved?
-
Simply cranking up the LINEWIDTH in src/dat.c makes the following work: sox -r 8000 -c 32 -n file.dat synth 1 sin sox file.dat file.wav play file.dat Out of curiosity, where are you using 32 channel DAT files?
-
What is the @@ in 'sox --single-threaded @@ -t aiff /dev/null' supposed to be? Syntacticaly, that's where you nae the input file. And whatever audio file I give there, it works. What are the files in your zip attachment supposed to show?
-
It's silly of course: with 7 samples, there's no "spectrum" to talk of. With rate 5k it's 11 samples, and with rate 4999 it's also 11 samples: 08 42 73 7d 66 2e ea aa 86 87 aa 08 42 72 7d 66 2e e9 ab 86 85 aa On the first one (5k), spectrogram works; on the second one (4999), spectrogram segfaults. (Either with the patch or without.)
-
On OpenBSD 7.2/amd64, with the latest git, it also works with rate down to 5k, but segfaults with rate 4999. Same thing happens with the patch. gdb says #0 0x0000046b6931b0e9 in memcpy (dst0=0x46c26d06000, src0=Variable "src0" is no t available. ) at /usr/src/lib/libc/string/memcpy.c:103 103 TLOOP(*(word *)dst = *(word *)src; src += wsize; dst += wsize); (gdb) bt #0 0x0000046b6931b0e9 in memcpy (dst0=0x46c26d06000, src0=Variable "src0" is not available. ) at /usr/src/lib/libc/string/memcpy.c:103...
-
Barough created ticket #232
Audio libraries
-
Same happens with the patch. I will test on other systems.
-
With current git on a macOS, the commad above does not segfault, but runs indefinitely and eats up the CPU. Without the rate effect, the spectrogram gets produced. With rate 8k, 7k, 6k, 5k it still works; with rate 4999 it doesn't.
-
I can confirm this happens on macOS with the latest git. It does not happen when the --norm has an argument, as in --norm=-3 The culprit is the norm_level = lsx_strdup(optstate.arg) call in parse_gopts_and_fopts() under case 19 - looking at lsx_strdup in src/xmalloc.c, it simply returns lsx_checkptr(strdup(s)); but strdup(NULL) will already segfault, because strlen(NULL) will segfault. (The whole sox options parsing is a mess.)
-
I can confirm this happens on macOS with the latest git. It does not happen when the --norm has an argument, as in --norm=-3 The culprit is the norm_level = lsx_strdup(optstate.arg) call in parse_gopts_and_fopts() under case 19 - looking at lsx_strdup in src/xmalloc.c, it simply returns lsx_checkptr(strdup(s)); but a strdup() of NULL will already segfault. (The whole sox options parsing is a mess.)
-
OptimFROG (ofr) Support
-
Piotr Chlebek created ticket #230
Support overlapping fade effect
-
Any news regarding this?
-
Monkeys Audio (APE) Support
-
Sox User posted a comment on ticket #225
Sorry for not responding much sooner. I watched this space for a few weeks and then kind of wandered off. Thanks for your suggestions, Martin. I'll have a look at those projects. In the interim I just went back to using ffmpeg for logarithmic spectrograms. It took a bit of trial and error to figure out the gotchas in ffmpeg's implementation (there's no documentation about the effect of output image dimensions, but it's extremely sensitive to that). On the plus side, it seems like someone may have...
-
Jim Lill created ticket #365
sox: Soory, there is no default audio device configured
-
Jürgen Schwietering posted a comment on ticket #364
workaround used in an automated production system is padding the name using spaces: i.e.: sox result.wav -n spectrogram -t " chorus "
-
sox spectrogram title option breaks when using keyword
-
L29Ah created ticket #363
sox segfaults when parsing CLI options
-
Dabe Murphy created ticket #125
Fix `property_size = sizeof(name)`
-
isidroco modified a comment on ticket #217
Nice script Kamil, though comparing MaxAmp = 0 can be fooled with a crafted file with enough DC negative offset to just peak at 0, and will skip not perfect mono files (ie: dithered) . If first 4 chars of RMS amplitude = "0.00" will detect "almost" mono files whose L-R amplitude is less than -40 dB. Your batched slightly inspired me to "solve" this: https://sourceforge.net/p/sox/feature-requests/228/#0887 Here's an improved batch with that idea, which can optionally take FLACs: @echo off set _soxExe=c:\AUDIO\UT\SOX\sox.exe...
-
Nice script Kamil, though comparing MaxAmp = 0 can be fooled with a crafted file with enough DC negative offset to just peak at 0, and will skip not perfect mono files (ie: dithered) . If first 4 chars of RMS amplitude = "0.00" will detect "almost" mono files whose L-R amplitude is less than -40 dB. Your batched slightly inspired me to "solve" this: https://sourceforge.net/p/sox/feature-requests/228/#0887 Here's an improved batch with that idea, which can optionally take FLACs: @echo off set _soxExe=c:\AUDIO\UT\SOX\sox.exe...
-
My current workaround: @echo off set _soxExe="c:\AUDIO\UT\SOX\sox.exe" verify other 2>nul & REM sets errorlevel to 1, check if enableextensions works setlocal enableextensions enabledelayedexpansion & REM to get var value at exec with !varNm! if %errorlevel%==1 ( echo ERROR newer cmd.exe is needed & goto :fin ) if exist "%~f1" if exist "%~f2" goto :ok12 echo . echo . mix2stereo v22.0914 echo . echo . Usage: mix2stereo audioFile1 audioFile2 [flac|wav] echo . echo . Makes stereo from 2 audiofiles echo...
-
Nice script Kamil, though comparing MaxAmp = 0 can be fooled with a crafted file with enough DC negative offset to just peak at 0, and will skip not perfect mono files (ie: dithered) . If first 4 chars of RMS amplitude = "0.00" will detect "almost" mono files whose L-R amplitude is less than -40 dB. Your batched slightly inspired me to "solve" this: https://sourceforge.net/p/sox/feature-requests/228/#0887 PS: Just updated your batch with those ideas, sent it to your email.
-
Nice script Kamil, though comparing MaxAmp = 0 can be fooled with a crafted file with enough DC negative offset to just peak at 0, and will skip not perfect mono files (ie: dithered) . If first 4 chars of RMS amplitude = "0.00" will detect "almost" mono files whose L-R amplitude is less than -40 dB. Your batched slightly inspired me to "solve" this: https://sourceforge.net/p/sox/feature-requests/228/#0887
-
My current workaround: @echo off set _soxExe="c:\AUDIO\UT\SOX\sox.exe" verify other 2>nul & REM sets errorlevel to 1, check if enableextensions works setlocal enableextensions enabledelayedexpansion & REM to get var value at exec with !varNm! if %errorlevel%==1 ( echo ERROR newer cmd.exe is needed & goto :fin ) if exist "%~f1" if exist "%~f2" goto :ok12 echo . echo . mix2stereo v22.0911 echo . echo . Usage: mix2stereo audioFile1 audioFile2 echo . echo . Makes stereo from 2 audiofiles echo . Left...
-
My current workaround: @echo off set _soxExe="c:\AUDIO\UT\SOX\sox.exe" verify other 2>nul & REM sets errorlevel to 1, check if enableextensions works setlocal enableextensions enabledelayedexpansion & REM to get var value at exec with !varNm! if %errorlevel%==1 ( echo ERROR newer cmd.exe is needed & goto :fin ) if exist "%~f1" if exist "%~f2" goto :ok12 echo . echo . mix2stereo v22.0911 echo . echo . Usage: mix2stereo audioFile1 audioFile2 echo . echo . Makes stereo from 2 audiofiles echo . Left...
-
Nice script Kamil, though comparing MaxAmp = 0 can be fooled with a crafted file with enough DC negative offset to just peak at 0, and it will miss not perfectly 0 L-R mono files (ie: dithered) . Maybe comparing first 4 chars of RMS amplitude to "0.00" which detect near mono files whose L-R amplitude is less than 0.01 dB. Your batched slightly inspired me to "solve" this: https://sourceforge.net/p/sox/feature-requests/228/#0887 Your _soxExe should have "" but they must be enclosed on escaped" on...
-
My current workaround: @echo off set _soxExe="c:\AUDIO\UT\SOX\sox.exe" verify other 2>nul & REM sets errorlevel to 1, check if enableextensions works setlocal enableextensions enabledelayedexpansion & REM to get var value at exec with !varNm! if %errorlevel%==1 ( echo ERROR newer cmd.exe is needed & goto :fin ) if exist "%~f1" if exist "%~f2" goto :ok12 echo . echo . mix2stereo v22.0911 echo . echo . Usage: mix2stereo audioFile1 audioFile2 echo . echo . Makes stereo from 2 audiofiles echo . Left...
-
Nice script Kamil, though comparing MaxAmp = 0 can be fooled with a crafted file with enough DC negative offset to just peak at 0, and it will miss not perfectly 0 L-R mono files (ie: dithered) . Maybe comparing first 4 chars of RMS amplitude to "0.00" which detect near mono files whose L-R amplitude is less than 0.01 dB.
-
Same problem here, w7 x64 it fails even manually specifying Sound Card's name, or any soundcard number (i have two audio cards) ie: sox infile −t waveaudio 2
-
Remix: Arbitrary select channels from each input file
-
Martin Guy posted a comment on ticket #358
Output file with patch applied
-
Confirmed on Debian stable (bullseye) with git master HEAD 42b3557e1 also when the au is converted to wav, also when the "rate 3k" effect is omitted. The segfault occurs in print_at_() when it's trying to add the "Time (s)" label to the graph, and is probably caused by the file only being 100 samples long, about 0.002 seconds. "sox int8-linear-pcm.au -n spectrogram -r" does not segfault and produces a png file 13 pixels wide. Without -r, it's trying to print "Time (s)" at screen coordinate x = -2147483572...
-
Sox's default fade type is logarithmic, not linear. It is behaving correctly. You need "fade t 0.5 0 0.5" Not a bug.
-
This has several issues: - it doesn't apply cleanly to the git master HEAD - the formatting doesn't match the exiting code - the compiler reports that "i" may be used uninitialized at line 915 (tick=i/10) and the later "Tick label" line. Use of i here, left over from the end of a previous loop, is bizarre. - I've tried applying the failed patch (to spectrogram.c) manually to git master HEAD, but the x-axis ticks remain in seconds, and "Time (s)" is replaced by the file length in HMS format (that's...
-
This has several issues: - it doesn't apply cleanly to the git master HEAD - the formatting doesn't match the exiting code - the compiler reports that "i" may be used uninitialized at line 915 (tick=i/10) and the later "Tick labes" line. Use of i here, left over from the end of a previous loop, is bizarre. - I've tried applying the failed patch (to spectrogram.c) manually to git master HEAD, but the x-axis ticks remain in seconds, and "Time (s)" is replaced by the file length in HMS format (that's...
-
This has several issues: - it doesn't apply cleanly to the git master HEAD - the formatting doesn't match the exiting code - the compiler reports that "i" may be used uninitialized at line 915 (tick=i/10) and the later / Tick label/ line. Use of i here is bizarre. - I've tried applying the failed patch (to spectrogram.c) manually to git master HEAD, but the x-axis ticks remain in seconds, and "Time (s)" is replaced by the file length in hⓂ️s format (that's probably my fault in misapplying it) I suggest...
-
404 Repo not found
-
Mans Rullgard modified ticket #113
spectrogram: add FFTW3 support