Eric Wong wrote:
> Ulrich Klauer wrote:
> > If so, it'd probably
> > be useful to have something like a repeat option for the SoX effect
> > that creates additional instances as needed, something like
> > sox -c 3 ... ladspa -r oneone
> > whereas
&g
ll like it :)
>From 71d405612c76b3ddeb560ca08a7e2f7c1bc01ade Mon Sep 17 00:00:00 2001
From: Eric Wong
Date: Fri, 22 Jun 2012 08:34:25 +
Subject: [PATCH] speed up "|program" inputs on Linux 2.6.35+
Linux 2.6.35+ allows pipe buffer resizing via fcntl(2). When
running multi-threaded SoX in
"SourceForge.net" wrote:
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=110706&aid=3553685&group_id=10706
(not convenient for me to open a browser right now, will later if I remember)
> Is ffmpeg optional? If so, could there be an option added:
>
> --disable
Rob Sykes wrote:
> > From: Ulrich Klauer
> > Sent: Wednesday, 14 March 2012, 1:19
>
> > b) make multi-threaded the default again when/since we've sorted out the
> > problems that made MT slower than ST.
> Were there any objections to doing this now? I expect a performance
> gain for common t
Daniel Jensen wrote:
> Obviously since Audacity's filter is GPL'd while SoX's effects are
> LGPL'd, code can't be shared. (Even if SoX decided that this could go
> under the GPL, since Audacity's filter is in WxWidgets-heavy C++ this
> wouldn't help much.) I know very little about how clean-ro
Hans Petter Selasky wrote:
> Hi,
>
> Line buffering should be off, but this statement leads to SOX reading 1 and
> one byte from the recording DSP device under FreeBSD:
>
> /* Change to non-buffered I/O */
> setvbuf(ft->fp, NULL, _IONBF, sizeof(char) * file->size);
> return(SOX_SUCC
Hans Petter Selasky wrote:
> Will someone handle this or do I have to file a bug-report?
Probably best to file a bug report so it doesn't get forgotten.
The SoX developer(s) responsible for this are probably too
busy at the moment.
Ulrich Klauer wrote:
> So, question is: Does anyone want to update src/ffmpeg.c to use the
> new API? (If so, this should probably go into dot.) Or should we
> remove the ffmpeg driver altogether and tell users to run "ffmpeg ...
> | sox - ..." (or "avconf ... | sox - ...")?
I favor removin
Chris Bagwell wrote:
> Any objections to pushing out a new release of SoX? Anybody have a TODO
> they'd like to finish before a new release?
No objections, I have a few outstanding patches/pull requests in the
tracker I'd like to get into the release.
I have patches attached and git pull reques
Ulrich Klauer wrote:
> Eric Wong :
>
> > === FLAC-related fixes (these are most important):
> >
> > 1) FLAC: encoding buffer overflow fix:
> > https://sourceforge.net/tracker/?func=detail&atid=110706&aid=3474924&group_id=10706
>
> Now in do
Ulrich Klauer wrote:
> Eric Wong :
>
> > In any case, do we agree "soxi -b" showing "0" is incorrect?
>
> Not necessarily, for codecs using compression, it may be impossible to
> say how much space one sample takes, as this may change, or the term
&
Chris Bagwell wrote:
> On Sat, Feb 23, 2013 at 9:29 AM, Jan Stary wrote:
> > Currently. sox uses wget(1) to access remote files and streams.
> > What is the developers' opinion about what do do with it
> > (if anything)?
> >
> > The obvious candidates are wget(1), ftp(1), curl(1) and libcurl(3).
Jan Stary wrote:
> On Feb 26 10:14:58, ch...@cnpbagwell.com wrote:
> > I see no down side to optionally supporting ftp in SoX; in addition to wget.
>
> Would ./configure be the proper place to make the decision?
Yes, I think so. Not sure of the best way to check for behavior/stdout
support, tho
Ulrich Klauer wrote:
> > > This can be done by e.g. calling "autoreconf --force".
> > Perhaps we should make this run unconditionally in release.sh. Running
> > the script will take a few seconds more, but we'd be sure to have the
> > most recent versions in each release.
>
> As it turns out, "au
Hi all, I finally got around to updating my sox.git installation and
noticed my usual --with-dyn-default build switch (inherited from the
Debian packaging) seems incompatible with:
commit 5c58413544fd600bf12fdc54fa9648f0bc1ea860
"Don't export (most) internal libsox symbols"
Anyway
Eric Seigne wrote:
> Here is a bug on "noiseprof" i've found with a qt/c++ program linked
> with libsox: i'm french and my LC_ALL is fr_FR,UTF-8,
> here is the "/tmp/speech,noise-profile" file:
>
> Channel 0: 3,047390, 1,534390, 4,114414, 3,004703, 1,243448, 2,580552,
> please have a look a
Adding sox-devel to Cc:, Jan was able to trigger a segfault on
OpenBSD i386 with the below example on 14.4.1.
Jan Stary wrote:
> On Sep 04 06:22:25, normalper...@yhbt.net wrote:
> > Can you replace .wav with .sox (or other formats) and reproduce the
> > issue with a different format?
>
> The sam
Jan Stary wrote:
> On Sep 04 07:03:31, normalper...@yhbt.net wrote:
> > Can you reproduce the issue by using a temporary file instead of a pipe?
> > I strongly suspect this is OpenBSD-specific and only to pipes.
>
> SoX refuses to make the temporary file:
>
> $ sox -n one.sox synth 4.145 sin 4
Jan Stary wrote:
> On Sep 04 17:26:47, normalper...@yhbt.net wrote:
> > Right, it's a rewind pipe problem. Btw, does specifying -t/-c/-b/-r
> > for the pipe avoid the problem by avoiding the need to automatically
> > detect filetype?
>
> Ha, it does:
> Anyway, we _do_ have a rewind_pipe() probl
Brad Holland | Muzik Liberated wrote:
> We are looking for a small script (perhaps using sox) that scans a raw
> audio file and applies some modulation to the audio file which
> amplifies the content at specific points (when the signal is lower
> than -6db) and continues to do this every time the
Btw, I posted https://sourceforge.net/p/sox/patches/101/ last
night. Any testers/feedback would be greatly appreciated.
I've only used tap_limiter with it and it seems to works great.
background:
Some LADSPA plugins report their latency using a output control
port named "latency". We may c
Joe Desbonnet wrote:
> If this code is worth contributing please advise what are the next steps
> (if any). Consider this code contributed under whatever terms that are
> required to have it added to the project.
You mentioned there was already an open feature request? uploading the
patch to the
Chris Bagwell wrote:
> I'm flexible if anyone has a feature they wanted to get in but here is
> rough schedule:
Hi Chris, great to know a new release is on the way!
I would like my LADSPA latency compensation patch looked at and
hopefully merged: https://sourceforge.net/p/sox/patches/101/
I thi
Pander wrote:
> Please review the attached patch for outputting the average power spectrum.
I am not knowledgable in the math behind this, but I noticed one
memory management error:
> @@ -134,6 +138,15 @@ static int sox_stat_flow(sox_effect_t * effp, const
> sox_sample_t *ibuf, sox_samp
>pr
This is useful to allow the "stats" effect to show the incomplete
stats if the writing pipe is broken. This is helpful for users of
dtas-player[1] to show stats while seeking within portions of a
file, as dtas-player will trigger SIGPIPE to stop a sox process
before spawning a new one.
---
Also s
Pander wrote:
> Hi all,
>
> Could some please tell me of my patch for average power spectrum has
> been accepted or not?
Checking the git repo at git://git.code.sf.net/p/sox/code, it doesn't
seem so; but it's typical to take some time (several months) for patches
to get merged because the develo
Eric Wong wrote:
> Daniel Jensen wrote:
> > Obviously since Audacity's filter is GPL'd while SoX's effects are
> > LGPL'd, code can't be shared. (Even if SoX decided that this could go
> > under the GPL, since Audacity's filter is in WxWidg
Mans Rullgard wrote:
> + lsx_fail_errno(ft, SOX_EHDR, "inavlid channel count %d",
"invalid"
I didn't notice anything else obviously wrong. Haven't tested, as I've
never encountered DSF/DSD and doubt I'll ever have to given the
(very fortunate :) lack of adoption.
Any examples for t
Mans Rullgard wrote:
> +++ b/src/hcom.c
> @@ -432,9 +432,10 @@ static int stopwrite(sox_format_t * ft)
>int rc = SOX_SUCCESS;
>
>/* Compress it all at once */
> - if (compressed_len)
> + if (compressed_len) {
> compress(ft, &compressed_data, (int32_t *)&compressed_len);
> - free(
ead (2015-09-07 00:39:24 +)
----
Eric Wong (1):
use posix_fadvise to increase readahead
configure.ac | 1 +
src/formats.c | 18 --
src/sox_i.h | 4
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index
mode (2015-10-03 22:04:50 +)
----
Eric Wong (1):
use non-blocking stdin for interactive mode
src/sox.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/sox.c b/src/sox.c
index bab0f45..fdb7616 100644
--- a/src/sox.c
+++ b/src/sox.c
@@ -1789,
Mans Rullgard wrote:
> This adds a sigma-delta modulator for 1-bit (DSD) encoding. It is
> invoked by the "dither" effect when the output precision is 1-bit or
> manually with choice of the following noise-shaping filters:
>
> fast Reasonably good quality while fast enough for real-time
>
Tarim wrote:
> Thanks Eric, that makes things a lot cleaner, more resilient and, at a
> guess, more portable (surely any OS with select will have O_NONBLOCK?)
O_NONBLOCK is common, yes, but I have zero knowledge or interest in
proprietary OSes. For systems with O_NONBLOCK, the select calls in
Please don't drop Cc: to public lists, others can help while I'm away.
I welcome direct emails, just keep others in the loop :)
Tarim wrote:
> Having problems building sox from your git repository at the moment.
>
> I get:
> ./configure: line 14592: syntax error near unexpected token `OPUS,'
>
Pander wrote:
> Because of a question on the users list, I would like to ask how to move
> forward the following patch and documentation?
I guess the real sox developers are still busy...
I suppose I'll start publishing things I've reviewed/tested
and push things I've reviewed to branches my serv
Series tested with the following commands to create and play
a `test.dsf' file using an existing FLAC file:
sox $INPUT.flac test.dsf rate 2822.4k sdm
sox test.dsf -b 24 -r 48k -p | play -p
(I didn't test dsdiff nor building with non-autotools).
Pushed to the "mr/dsd" branch on gi
Måns Rullgård wrote:
> There are some fixes and improvements in my github repo at
> https://github.com/mansr/sox
>
> You probably want to grab those as well.
Thanks. I've split them into 3 topics (mr/{dsd,build,pad})
for easier review on my repo @ git://80x24.org/sox.git
I couldn't test the MSV
Mans Rullgard wrote:
> Also check for the aligned_alloc() function and alias to Microsoft's
> _aligned_malloc() if necessary.
How much does aligned_alloc help performance for you (and with which
settings)? I'm on an older system with only memalign and
posix_memalign, and trying to enable it didn
Måns Rullgård wrote:
> That CPU doesn't have AVX so 16-byte alignment is enough, and plain
> malloc usually provides that. It obviously doesn't hurt to add support
> for memalign as well even though it is considered obsolete. If you do
> that, you should also take care of #including malloc.h.
Y
Måns Rullgård wrote:
> Eric Wong writes:
> > dnl Checks for library functions.
> > -AC_CHECK_FUNCS(strcasecmp strdup popen vsnprintf gettimeofday mkstemp
> > fmemopen aligned_alloc)
> > +AC_CHECK_FUNCS(strcasecmp strdup popen vsnprintf gettimeofday mkstemp
> >
(2015-02-26
22:48:40 -0500)
are available in the git repository at:
git://80x24.org/sox.git pu
for you to fetch changes up to 8a3351c2437b2d5367eafde60e95f52d3815065d:
Merge branch 'ew/align' into pu (2015-12-25 23:04:20 +)
--
Martin Guy wrote:
> On 26/12/2015, Eric Wong wrote:
> > I've started maintaining a branch of things in their absence.
>
> Thanks Eric. I have three commits, all regarding "sox spectrogram":
> - remove arbitrary limit on spectrogram output height (was 1200)
things. Thanks for the heads-up
> on these possible issues
No problem. I'm still not too experienced in this area,
either but I started forcing myself to learn in another project.
> On 26/12/2015, Eric Wong wrote:
> >
> > I'd prefer if we could avoid CPP inside C
Martin Guy wrote:
> On 26/12/2015, Eric Wong wrote:
> > --- a/src/spectrogram.c
> > +++ b/src/spectrogram.c
> > @@ -70,7 +70,11 @@ typedef struct {
> >sox_bool using_stdout; /* output image to stdout */
> >
> >/* Shared work area */
> &g
Jan Stary wrote:
> It seems that if the -x size of the spectrogram is bigger
> than the number of actual samples (1000 in the example),
> or samples/second, SoX segfaults instead of rejecting that option
> (say, limiting the number to the number of samples available).
Thanks. I think ensuring p-
Måns Rullgård wrote:
> I'd be willing to co-maintain it, should it come to that.
Thank you, much appreciated!
--
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
http
Hi Pascal,
I found a fix to this problem by adding lsx_error and lsx_flush
to the regular expression (and I needed to "make clean" before
rebuilding, so there's likely still a smaller build problem there).
Pushed to the "ew/dyn-default-fix" branch on git://80x24.org/sox
(as well as my "pu" (propo
Kevin Conder wrote:
> I have a fix for Bug #261: absurd docs bug - PDF is doubled 14.4.1 and
> 14.4.2. The problem is when any PDF is created, the result is two
> duplicate documents concatenated together.
> http://sourceforge.net/p/sox/bugs/261/
>
> The cause was a bug in pdfroff. The solution i
Thanks, merged into my "pu" branch with some edits to the commit
message:
http://80x24.org/sox.git/patch?id=b448ffc111be3d50
git://80x24.org/sox.git
/me still eagerly awaits the return of the maintainers...
-
gqrxzy8...@ftml.net wrote:
> I haven't tested this but it appears the code:
>
> https://sourceforge.net/p/sox/code/ci/master/tree/src/coreaudio.c#l154
> char name[256];
> status =
> AudioDeviceGetProperty(devices[i],0,false,kAudioDevicePropertyDeviceName,&prope
gqrxzy8...@ftml.net wrote:
Thanks. Pushed to the "pu" (potential updates) branch of
git://80x24.org/sox
https://80x24.org/sox.git/patch?id=bf2afa54a7dec
> PS: Changing from using the deprecated CoreAudio interfaces would be a
> larger change...
Mans and I are just keeping the lights on until
Matt Flax wrote:
> Hi there,
>
> I currently use libsox to load and save audio data. I was wanting to
> write and read 64bit data, however the generic sox sample type is 32 bit
Correct, sox does some calculations internally in 64-bit double,
but data which flows in between the effects is all 3
Jan Stary wrote:
> Hi Eric,
>
> recently, Alex Ratchov (of OpenBSD's sndio) has added a diff
> to src/sndio.c that enables a finer setting of the desired
> parameters of the underlying audio (namely, bit width).
>
> Currently, the diff (attached) exists as a patch to the OpenBSD
> port of SoX (w
Jan Stary wrote:
> Eric Wong wrote:
> > with Måns sox,
Sorry, copy+paste error since I can't type 'å' properly :x
> > The patch looks sane, and if OpenBSD is anyway building with this, it's
> > probably good to pick it up.
>
> Yes, the Open
Jan Stary wrote:
> On Sep 20 22:24:28, normalper...@yhbt.net wrote:
> > Thanks, it's sitting in my "pu" branch on git://80x24.org/sox
> > with Alex credited as the author.
>
> Thank you.
>
> What is the relation of this git branch at git://80x24.org/sox
> to the actual SoX repository at git://gi
For those of you unable to remain subscribed to SF.net,
I am putting JavaScript-free mirrors on public-inbox.org:
https://public-inbox.org/sox-users/
https://public-inbox.org/sox-devel/
NNTP readers may use:
nntp://news.public-inbox.org/inbox.comp.audio.sox
nntp:/
Jan Stary wrote:
> On Jun 29 08:49:26, normalper...@yhbt.net wrote:
> > For those of you unable to remain subscribed to SF.net,
> > I am putting JavaScript-free mirrors on public-inbox.org:
> >
> > https://public-inbox.org/sox-users/
> > https://public-inbox.org/sox-devel/
>
> Let me und
Jan Stary wrote:
> marc.info is aware of the SF re-subscriptions
> and is takign care of it, so
>
> http://marc.info/?l=sox-users&r=1&w=2
> http://marc.info/?l=sox-devel&r=1&w=2
> http://marc.info/?l=sox-commits&r=1&w=2
>
> (and other SF lists) will continue being archived.
Th
Taylor Holberton wrote:
> Hello everyone!
>
> I was considering using sox as a plug-in to one of my projects. I noticed a
> few quirks with CMake and I began writing a patch. Then I noticed the last
> release was over two years ago and I don't see any more activity in the git
> logs.
>
> Is this
Jaromír Mikeš wrote:
> Please let me know if you can provide patches for these fixes
> or make new release to fix these issues.
Thanks for the email. I guess neither Mans or I pay attention
to the bugtrackers :x, and the original developers are busy.
(and I don't like web-based UIs)
Anyways, I'
Måns Rullgård wrote:
> All but one fixed here: https://github.com/mansr/sox
I think this should fix the last one. I didn't check too
closely, just verified it's no longer segfaulting.
(But lsx_valloc doesn't check for multiplication overflow)
---8<-
Fro
Måns Rullgård wrote:
> This will leak memory like crazy.
You're right. I somehow got spoiled into thinking it was
alloca-like from another project :x.
> I'd prefer not to do a malloc/free for each block, but rather do it just
> once. This will require a little more work, of course.
Yes, it sho
Jan Stary wrote:
> Sorry for crossposting, but whoever's running the public-inbox.org mirror,
> please get it fixed.
Sorry, though I'm not sure what's tripping up mlmmj for you.
I'll disable mlmmj for this list since it wasn't used anyways...
Was that the only bounce you've seen, lately?
I don't
Måns Rullgård wrote:
> Eric Wong writes:
>
> > Måns Rullgård wrote:
> >> This will leak memory like crazy.
> >
> > You're right. I somehow got spoiled into thinking it was
> > alloca-like from another project :x.
>
> Never use such functions.
---
src/adpcm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/adpcm.c b/src/adpcm.c
index 2e13867e..b400eb95 100644
--- a/src/adpcm.c
+++ b/src/adpcm.c
@@ -113,7 +113,13 @@ const char *lsx_ms_adpcm_block_expand_i(
const unsigned char *ip;
unsigned ch;
Måns Rullgård wrote:
> I really don't want to use alloca(). It is non-standard, non-portable,
> somewhat dangerous, and messes with compiler optimisation. There is
> nothing good about it. Guess I'll have to do it myself.
One could also use thread-specific data to avoid messing with the
signat
Mans Rullgard wrote:
> --- a/src/adpcm.h
> +++ b/src/adpcm.h
> @@ -29,8 +29,11 @@
> /* default coef sets */
> extern const short lsx_ms_adpcm_i_coef[7][2];
>
> +extern void *lsx_ms_adpcm_alloc(unsigned chans);
> +
> /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output
Jan Stary wrote:
> On Nov 07 18:14:23, normalper...@yhbt.net wrote:
> > But the HTTPS mirrors at https://public-inbox.org/sox-devel/ should
> > remain up.
>
> The mirror at
> https://marc.info/?l=sox-users&r=1&w=2
> https://marc.info/?l=sox-devel&r=1&w=2
> is very reliable and the interface sucks
Måns Rullgård wrote:
> Eric Wong writes:
> > Mans Rullgard wrote:
> >> --- a/src/adpcm.h
> >> +++ b/src/adpcm.h
> >> @@ -29,8 +29,11 @@
> >> /* default coef sets */
> >> extern const short lsx_ms_adpcm_i_coef[7][2];
>
eForge.net project; either...
Will also try to look at https://bugs.debian.org/881121 soon
(maybe Måns can help).
---8<-----
From: Eric Wong
Subject: [PATCH] wavpack: check errors when initializing
Avoid NULL dereference when opening an WavPack input file fails
as described by Debia
Joonun Jang wrote:
> Package: sox
> Version: 14.4.1-5+b2
> Severity: normal
> Tags: security
>
> null pointer dereference while running sox with "poc.aiff output.aiff speed
> 1.027" option
>
> Running 'sox poc.aiff output.aiff speed 1.027' with the attached file raises
> null pointer dereferen
Jaromír Mikeš wrote:
> Hi,
>
> we found little problem in sox man pages please consider use attached patch.
> The warning said "table wider than line width"
Sure, no objections to the actual patch, here.
I'm curious how you generate the patch, since the headers seem
machine-generated, but it's
Ioan-Adrian Ratiu wrote:
> commit 5c58413544 ("Don't export (most) internal libsox symbols")
> breaks dynamic flac builds as flac.c references lsx.error, so add it
> to the list of exceptions.
Thanks, but Mans already added that exception in
commit 600c291ab00f4afb2941cd93f69942fe395f3e8a
("Updat
Måns Rullgård wrote:
> Jan Stary writes:
> > What is tha right place to send PRs?
> > Is thete a point opening tickets on SF?
>
> Probably not. If you open issues on my github repo, I'll at least see
> them. Maybe I'll even fix them.
I prefer everything comes to this list.
I will never use a
Jan Stary wrote:
> On Mar 18 19:41:49, normalper...@yhbt.net wrote:
> > I prefer everything comes to this list.
>
> Eric, do you also maintain your SoX fork somewhere?
git://80x24.org/sox.git
https://80x24.org/sox.git
-
Rob Sykes via SoX-devel wrote:
> Chris and I would be more than happy for someone else to take
> over the reins. Måns, Eric, if you would like admin. rights to
> the SF project, just let me know. Cheers, Rob
Hey, did Måns take up on this offer?
I'm a terminal user and horrible at dealing with w
Mans Rullgard wrote:
> This fixes infinte loops and crashes with invalid inputs.
s/infinte/infinite/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/s
Mans Rullgard wrote:
> +extern void *lsx_ms_adpcm_alloc(unsigned chans)
> +{
> +return lsx_malloc(chans * sizeof(MsState_t));
Initially I thought this might overflow, but it appears channels
is capped to UINT16_MAX by the previous patch.
On a side note, lsx_valloc could probably be upda
Sonny Ray wrote:
> I don't know how merge request notifications work on SourceForge; if this
> is spammy, apologies.
I didn't even know that was a thing on SF. Anyways I prefer all
messaging be done via email so we can still message each other
in case the centralized system bites the dust.
> Ma
From: Eric Wong
When accepting keyboard input, it is possible for select() to
return a false-positive with spurious wakeups from inside the
update_status callback.
Using the FIONREAD ioctl in place of select is also a possibility,
but may be less portable.
---
src/sox.c | 12
1
Linux 2.6.35+ allows pipe buffer resizing via fcntl(2). When
running multi-threaded SoX invocations with large buffers, the
default pipe size (64K) can be too small and become a bottleneck
for IPC. Increasing the pipe to the maximum allowed size
reduces the amount of stalls in data flow between
From: Alexandre Ratchov
Reported-by: Jan Stary
cf. http://marc.info/?l=openbsd-ports&m=147395657332262&w=2
---
src/sndio.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/sndio.c b/src/sndio.c
index e031b5bb..77785ce4 100644
--- a/src/sndio.c
+++ b/src/sndio.c
@@
-a (2020-07-31 09:14:53 +)
Alexandre Ratchov (1):
sndio: handle 24-bit samples properly on OpenBSD
Eric Wong (2):
use non-blocking stdin for interactive mode
speed up "|program" inputs on Linux 2.6.35+
Guido Günther (1):
Handle vorbis_analysis_headerout
From: Guido Günther
This is related to
https://github.com/xiph/vorbis/pull/34
but could also happen today with on other errors in the called function.
---
src/vorbis.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/vorbis.c b/src/vorbis.c
index aafce7e2..9f
From: Jan Stary
The SoX manpage does not have an 'Input File Balancing" section,
but it has an "Input File Combining" section.
ref: <20150715131359.ga12...@www.stare.cz>
---
sox.1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sox.1 b/sox.1
index 2c4ca470..35a22d98 100644
-
on Y-axis-height by making array
allocation dynamic. In practice, you can't remove the limit as getopt
insists on minimum and maximum values for numeric arguments, so we
copy the similarly arbitrary limit of 20 from MAX_X_SIZE.
Tested-by: Eric Wong
---
src/spectrogram.c
From: Martin Guy
This change adds a "normalize" flag, -n, to sox spectrogram to adjust
the spectrogram gain such that the highest values get the brightest
colours, allowing one to get uniform spectrograms regardless of
different volumes in music files.
Tested-by: Eric Wong
From: "gabor.kar...@gmx.at"
Reported-by: Jaromír Mikeš
---
sox.1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sox.1 b/sox.1
index 35a22d98..5a4766dd 100644
--- a/sox.1
+++ b/sox.1
@@ -2699,7 +2699,7 @@ as detailed in the following table:
.ne 6
.TS
center;
-lB lw52.
+lB
From: Pander
references:
https://sourceforge.net/p/sox/mailman/message/33186778/
https://sourceforge.net/p/sox/mailman/message/33175940/
https://sourceforge.net/p/sox/mailman/message/33625255/
Edited-by: Eric Wong
[ew: removed extraneous whitespace changes,
squashed re_average initialization
Måns Rullgård wrote:
> Eric Wong writes:
> > Subject: [PATCH] wavpack: check errors when initializing
> >
> > Avoid NULL dereference when opening an WavPack input file fails
> > as described by Debian Bug #881145.
> >
> > While we're at it, check fo
Måns Rullgård wrote:
> Eric Wong writes:
>
> > Hi Måns, I guess you're merging stuff these days?
> >
> > I still use sox every day, but I've mostly stopped hacking C
> > since gcc and clang takes too long to compile.
>
> Get a faster computer.
Måns Rullgård wrote:
> Eric Wong writes:
>
> > From: Pander
>
> Does "Pander" have a real name?
Does it matter for this project?
Fwiw, I'm against real name policies; and there's no
copyright assignment or DCO here.
I don't see an acceptable
Måns Rullgård wrote:
> Måns Rullgård writes:
>
> > I have done a thorough overhaul of the WAV file reader, fixing several
> > open bugs as well as some I discovered while working on it. Now any
> > change of this magnitude is not without risk of breaking something that
> > used to work. I have
Eric Wong wrote:
> All relevant audio file formats store data sequentially, so
> give a hint to the kernel to perform more readahead. In current
> Linux, the readahead hint doubles readahead pages and can help
> with playback on slow devices.
Btw, I've been running this for
Måns Rullgård wrote:
> Eric Wong writes:
>
> > Eric Wong wrote:
> >> All relevant audio file formats store data sequentially, so
> >> give a hint to the kernel to perform more readahead. In current
> >> Linux, the readahead hint doubles readahead pages
Only compile-tested, and I gotta run out for a bit and my not
return alive. I just noticed some EINTR errors while writing to
pipes and haven't dealt with stdio or C in ages at this point.
diff --git a/src/formats_i.c b/src/formats_i.c
index 7048040d..d4082cc5 100644
--- a/src/formats_i.c
+++ b/s
Måns Rullgård wrote:
> The return value and ft->tell_off will be wrong in case the fwrite() was
> restarted.
Right, updated patch (covers fread + fflush) below; but still
somewhere else is hitting EINTR... I'm still alive for now,
but not feeling great about it :<
> What did you do that caused
commit 77360f7193a2ba2e (mp3: fix duration calculation, 2019-12-16)
appears incompatible with MP3s made using "lame --id3v2-only".
sox ends up thinking the length is too short compared to the
actual MP3 length.
Reverting that commit fixes the issue. I haven't had a chance
to look further into it,
ping?
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Jan Stary wrote:
> Is anyone using sox --multi-threaded, with OpenMP installed?
> Has anyone measured the difference, i.e. the speed benefit?
IIRC it was nearly a linear speedup on 2-4 cores with --buffer 131072.
I mainly run multiple sox processes nowadays via pipes and
replace them mid-stream,
1 - 100 of 101 matches
Mail list logo
