Activity for SoX - Sound eXchange
-
Martin Guy posted a comment on ticket #345
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.
-
Eugene posted a comment on ticket #356
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
-
jwdevel created ticket #378
Autoconf failure, following INSTALL instructions
-
Jan Starý posted a comment on ticket #374
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
-
Inigo Urrestarazu Porta posted a comment on ticket #236
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 iurrestarazupor@users.sourceforge.net 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 iurrestarazupor@users.sourceforge.net bounces saying "unknown user" so this is the only communication channel we have :-/ Can you check that "Bagwell and others" works correctly for you?
-
Reuben Thomas posted a comment on ticket #236
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.
-
Logarithmic frequency axis option is included in sox_ng-14.5.0 which in Release Candidate stage at the moment and shoudl be finalized in the next week or two. Details of log axis: https://codeberg.org/sox_ng/sox_ng/issues/165 Download source code: https://codeberg.org/sox_ng/sox_ng/releases/tag/sox_ng-14.5.0-rc2 and there is an issue there for MEL/Bark which may happen in the future https://codeberg.org/sox_ng/sox_ng/issues/267
-
Where? SoX does not include these audio libraries, it normally uses them from whatever software distribution you are using. If you mean in the static SoX EXE for Windows you will probably have to wait until someone faces a Windows build for https://codeberg.org/sox_ng/sox_ng
-
Hi!!! Thank you so much :) I would say that the beginning of the README would be great a place to put it. I would say that's the most accessible place to put it
-
I'm also not sox.sf.net personally but will do it here https://codeberg.org/sox_ng/sox_ng/issues/266 from where it will probably migrate to sox..sf.net at some point.
-
Thanks. I need to seek advice about what to put to credit it properly (as there are rather a lot of SoX developers!) Where would be a good place to put it so that anyone else who wants to know this will see it? In a file called "CITATION" in the top directory of the source tree? In the README?
-
Only affects 42b355 not 14.4.2
-
Hi! Basically it's how to reference it properly (specially in academic contexts), so that among others fair credit is attributed, and others can easily find it. For example, this is the what the ELAN project says: https://archive.mpi.nl/tla/elan/cite or Stan: https://mc-stan.org/users/citations/ or R language: ## ## To cite R in publications use: ## ## R Core Team (2021). R: A language and environment for statistical ## computing. R Foundation for Statistical Computing, Vienna, Austria. ## URL https://www.R-project.org/....
-
https://codeberg.org/sox_ng/sox_ng/issues/258
-
@janstary The GCC Compile Farm is the most monstrous Unix and compiler portability test on Earth. You can ask for an account at https://portal.cfarm.net/users/new
-
UTF-8 encoding for filenames and ID3 tags has gone into sox_ng-14.5.0 but I too have a only a fingernail of experience in Windows builds. mansr is the SoX guru of MSVC builds but seems to be busy with other things at the moment. However, we're going off topic...
-
What's a citation form? Can you give an example so that we can try to fill it in appropriately?
-
https://codeberg.org/sox_ng/sox_ng/issues/257
-
Feel free to implement one! However, there are several graphical tools that use libsox to do the heavy DSP work and prof-spock has even rewritten a large number of the effects in C++ using floating point samples instead of 32-bit as DAW VST3 plugins for Win, Mac and Linux. Find a GUI tool that uses those and you should be home and dry
-
https://codeberg.org/sox_ng/sox_ng/issues/256
-
https://codeberg.org/sox_ng/sox_ng/issues/151 This issue is open for a bounty on sox_ng. If you want to see this happen sooner, deposit a few cents. I won't be taking it, but some other professional DSP programmer might.
-
https://codeberg.org/sox_ng/sox_ng/issues/158
-
https://codeberg.org/sox_ng/sox_ng/issues/157
-
https://codeberg.org/sox_ng/sox_ng/issues/251
-
https://codeberg.org/sox_ng/sox_ng/issues/150
-
https://codeberg.org/sox_ng/sox_ng/issues/159
-
https://codeberg.org/sox_ng/sox_ng/issues/203
-
https://codeberg.org/sox_ng/sox_ng/issues/244
-
https://codeberg.org/sox_ng/sox_ng/issues/245
-
https://codeberg.org/sox_ng/sox_ng/issues/109
-
https://codeberg.org/sox_ng/sox_ng/issues/252
-
https://codeberg.org/sox_ng/sox_ng/issues/253
-
https://codeberg.org/sox_ng/sox_ng/issues/242
-
https://codeberg.org/sox_ng/sox_ng/issues/245
-
Only affects 42b355, not 14.4.2
-
https://codeberg.org/sox_ng/sox_ng/issues/27
-
https://codeberg.org/sox_ng/sox_ng/issues/163
-
A better version of this has gone into sox_ng for 14.5.0-rc2 https://codeberg.org/sox_ng/sox_ng/issues/254
-
https://codeberg.org/sox_ng/sox_ng/issues/242
-
https://codeberg.org/sox_ng/sox_ng/issues/243
-
Laszlo Ersek posted a comment on ticket #295
Actually, after a bit of experimenting, the difference is not beween the global -G option and the explicit gain effect. Instead, it's the -s option of the dither effect that makes the difference. The -s option selects the Shibata noise-shaping filter for dither. There are three cases: sox -G in.wav -r 44100 -b 16 -e signed-integer out.wav sox in.wav -r 44100 -b 16 -e signed-integer out.wav gain -h dither sox in.wav -r 44100 -b 16 -e signed-integer out.wav gain -h dither -s The first two are identical;...
-
Same here. See also https://stackoverflow.com/questions/6882125/reducing-removing-clipping-in-sox-when-converting-the-sample-rate#comment128663369_6890216
-
Issue https://codeberg.org/sox_ng/sox_ng/issues/164
-
Hi! I'm maintaining SoX and aiming for the first minor (new features) release on 2024-11-18, If you are interested in forward-porting this I'd be happy to include it. Otherwise the next minor release will be on 2025-05-18. https://codeberg.org/sox_ng/sox_ng
-
Only affects 42b355, not 14.4.2
-
SoX looks for its effect/format dl's in whatever PKGLIBDIR was set to when it was compiled so if you want to install it in a scratch directory you need to recompile it using ./configure --prefix=$HOME or whereever
-
Fixed in sox_ng by "./configure --with-curl" https://codeberg.org/sox_ng/sox_ng/issues/112 Will be released 18 November 2024
-
Don Olson created ticket #237
GUI Request . . .
-
Joachim Bauch created ticket #130
vorbis: Fix memory leaks
-
Citation form
-
JarC modified a comment on ticket #129
Been using the Windows binaries from SourceForge without any issues so far. Truth be told, I mostly use it for analysis, never to modify the actual soundfiles. The only issue I have is I have to jump through hoops to work with files having non-Ansi names, would be nice if it could at least support utf-8/unicode characters in filenames (see patch #105)
-
Been using the Windows binaries from SourceForge without any issues so far. Truth be told, I mostly use it for analysis, never to modify the actual soundfiles.
-
rogper posted a comment on ticket #129
It would be great if SoX could be added to vcpkg repository. It would make the library easier to consume, and I even think vckpgks can distribute .exe files as part of the content. But I'm not sure how good support SoX has for Windows(?)
