-signal.channels);
Here you can add a check to insert a new data chunk header whenever
necessary. You also need to modify wavwritehdr() to be aware of this.
PS: I asked a similar question on the SoX users list, but didn't get
an answer.
Neither of the lists seem very active of late.
--
Måns Rullgård
m
src/formats.h | 1 +
3 files changed, 211 insertions(+), 1 deletion(-)
create mode 100644 src/dsf.c
Please disregard this patch. I have a better one in the works.
--
Måns Rullgård
m...@mansr.com
s
>> official maintainer.
>
> No problem. I hope they come back. It is certainly a scary thought
> if I were to become an official... anything :x
I'd be willing to co-maintain it, sho
Eric Wong <normalper...@yhbt.net> writes:
> Måns Rullgård <m...@mansr.com> 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
elif defined(HAVE_MEMALIGN)
> + #define aligned_alloc(a, s) memalign(a, s)
> + #define aligned_free(p) free(p)
> #elif defined _MSC_VER
>#define aligned_alloc(a, s) _aligned_malloc(s, a)
>#define aligned_free(p) _aligned_free(p)
--
Måns Rullgård
---
t misleading: it will properly handle
> whatever bitwidth SoX asks for. The 24 vs 32 was
> just the initiating problem.
>From what I can tell, it makes a difference only for non-power-of-2
sample widths. 24
ug=882236
>
> The direct link to the patch is
>
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=882236;filename=0001-Handle-vorbis_analysis_headerout-errors.patch;msg=19
Patch attached for reference. Looks reasonable to me.
--
Måns Rullgård
>From 93b6e4b5b0efa47b
Jaromír Mikeš <mira.mi...@gmail.com> writes:
> 2017-11-04 21:43 GMT+01:00 Jaromír Mikeš <mira.mi...@gmail.com>:
>
>>
>>
>> 2017-11-04 21:10 GMT+01:00 Måns Rullgård <m...@mansr.com>:
>>
>>> Eric Wong <normalper...@yhbt.net&g
Eric Wong <normalper...@yhbt.net> writes:
> Måns Rullgård <m...@mansr.com> 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.
>
Eric Wong <normalper...@yhbt.net> writes:
F> Måns Rullgård <m...@mansr.com> 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
Jaromír Mikeš <mira.mi...@gmail.com> writes:
> BTW I moved debian packaging here if you are interested:
> https://anonscm.debian.org/git/pkg-multimedia/sox.git
>
> I think it is better than do it in sourceforge upstream repo.
Yes, that's better handled separately by each
ears channels
> is capped to UINT16_MAX by the previous patch.
>
> On a side note, lsx_valloc could probably be updated to do
> overflow checking and we could use it here to make future
> auditing/review easier.
We should probably also put
absurd like 64k.
--
Måns Rullgård
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
SoX-devel m
SF?
Probably not. If you open issues on my github repo, I'll at least see
them. Maybe I'll even fix them.
--
Måns Rullgård
--
Check out the vibrant tech community on one of the world's m
gt;> > What is the right place to send PRs?
>> > Is there 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
0);
> }
>
> static void read_comment_file(sox_comments_t * comments, char const * const
> filename)
> --
> 2.24.1.735.g03f4e72817-goog
>
>
> ___
> SoX-devel mailing list
> SoX-devel@lists.sourceforge.net
> https://lists
y it was ever added in the first place.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
;
> + rounded_value &= (-1 << (32 - effp->in_signal.precision));
> +
> + scaled_value = (double)rounded_value / SOX_SAMPLE_MAX;
>
>if (unit == '%')
> scaled_value *= 100;
> ==
>
> :JW
>
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
a size using
> 1/20 (100 milliseconds when stereo) can be more appropriate than the
> very small 40 millisecond hard-coded sample window size.
>
> The following is the updated patch:
I'm certainly not going to take a patch with several unrelated changes
as is, nor am I going to
ly available to work very hard at finding
> some good reason to cast aspersions upon my discoveries. But I would
> submit that the easier path would be to take my discoveries on board
> and make good use of what has cost me in time and effort, at no
> cost to yourself.
If that's the attitude
Cary Lewis writes:
> Please, for the sake of the software, find a way to be civil to each other.
It's a shame he felt the need to be so rude.
> Perhaps a SOX code of conduct is in order?
Not if I can help it.
--
Måns Rullgård
___
SoX
./.libs -lsox -L/usr/local/lib -lpng [...]
> cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...]
>
> The first works, the second does not.
> The only difference between the two is the place
> where the extra -L/usr/local/lib gets added,
> as described in the
difference between YES and yes?
> (Some other options have 'yes' instead of 'YES'.)
> Does the capitalizing mean it's the default?
> If so, do the options without capitalized values have no defualt?
Alternatives in capitals are defaults. Where none is indicated, the
default depends on some other option.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
LIBTOOL=/usr/bin/libtool on OpenBSD, which
Feel free to set that variable on your system. Or, you know, don't set
LDFLAGS in the first place.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
).
I will not attempt to guess what alternative names libraries might have
been installed under. If you've renamed things, it's on you to inform
the build system of the new name. Like this:
$ ./configure --with-png=png16
See, I already thought of that.
--
Måns Rullgård
__
ot;-Wl,-z -Wl,defs" from that line,
> the "gcc -shared" command goes through as expected,
> producing libsox.so
Apparently OpenBSD shared libraries aren't linked with libc. That's a
quirk I haven't noticed before.
The simplest solution here is probably to just drop the -z defs
HAVE_LAME=${with_lame:-101}
> autom4te.cache/output.0:HAVE_TWOLAME=${with_twolame:-101}
> autom4te.cache/output.0:HAVE_LIBGSM=${with_libgsm:-101}
> autom4te.cache/output.0:HAVE_OPENCORE_AMRWB=${with_opencore_amrwb:-101}
> autom4te.cache/output.0:HAVE_VO_AMRWBENC=${with_vo_amrwbenc:-101}
> autom4te.cache/output.0:HAVE_OPENCORE_AMRNB=${with_opencore_amrnb:-101}
> autom4te.cache/output.0:HAVE_LIBSNDFILE=${with_libsndfile:-101}
Fixed.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
t; I will need to rebase that on the current master.
You are wasting your time and mine. Please stop.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
; Thank you.
>
>>> [$9 *], m4_argn([8], m4_shift2($@))) dnl OpenBSD m4 can't count
>
> Can you please give a minimal example of an m4 input
> that demonstrates the problem? If something as fundamental
> as counting the number of arguments is broken,
> it needs fixing of course, instead of having
> software have to work around that.
Sure. Run m4 over the below. It should print '10' three times.
---CUT---
divert(-1)dnl
changequote([, ])
define([dquote], [[$@]])
define([argn], [pushdef([_$0], [popdef([_$0])]dquote([$]incr([$1])))_$0($@)])
define([foo], [argn([10], $@)])
define([bar], [argn([9], shift($@))])
define([baz], [argn([8], shift(shift($@)))])
define([numbers], [[1], [2], [3], [4], [5], [6], [7], [8], [9], [10]])
divert(0)dnl
foo(numbers)
bar(numbers)
baz(numbers)
---CUT---
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
egardless, though, once I figure out what the hell it's for in
the first place.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
ne.
> I will send a separate report.
>
> Audio devices:
> alsa no
> aono
> coreaudio no
> oss no
> pulseaudiono
> sndio yes
>
d some copies of the gsm stack sox used to have
> in asterisk and some other audio processing software - thank you.
> Before I go looking for copies of lpc,
> have you please found it elsewhere too?
There are packages called "lpc10" in Mageia, Mandriva (aren't those
related?),
a third party package to be able to
> add a string to CFLAGS (or whatever) is precisely what
> I would call jumping through hoops and being hostile to developers.
But it's not just adding a string. I already explained that. It's also
not a third-party package. It's a compani
le to developers.
Same goes for Windows.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
in principle, for
a format to be optional without any external dependencies. In fact, I
want to make most of them optional. Many are super-obscure, and
including them only creates a larger attack surface for no benefit in
most cases.
--
Måns Rullgård
_
oX predates stdint.h. It made sense once upon a time. We can get rid
of those typedefs, but since libsox users might be relying on them, we
should give them a chance to update their code before simply deleting
them. All in good time.
--
Måns Rullgård
libs -lsox -L/usr/local/lib -lFLAC [etc]
How did that -L/usr/local/lib get there?
Please send me your config.log so I can see what's going on.
It all works fine on my VM with this environment and no configure options:
AUTOCONF_VERSION=2.69
AUTOMAKE_VERSION=1.16
CC=cc
C_INCLUDE_PATH=/usr/local/include
LIBRARY_PATH=/usr/local/lib
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
edocs/gcc/Environment-Variables.html
These are the preferred method for indicating the location of libraries
since they augment the compiler's default search path without
interfering with command-line options which are searched first.
--
Måns Rullgård
>
> no
>
> I don't know what effect it has on the subsequent compilation,
> or what assumptions thinking "we are using the GNU compiler" leads to.
That checks whether __GNUC__ is defined. Since clang supports (most)
gcc extensions, it defines this symbol
If
OpenBSD chooses to install packages outside the normal search path of
the linker, that's really not a SoX problem. How you inform the linker
of their location isn't important, but it's your responsibility to do it
one way or another. If one of the possible methods might in some odd
circumstance
ypes -pedantic -o .libs/sox sox.o
>> -L/usr/local/lib -L./.libs -lsox -lltdl -lpng -lao -lgsm -lmad -lid3tag -lz
>> -lmp3lame -ltwolame -lopusfile -lopus -lsndio -lvorbisfile -lwavpack
>> -lcrypto -lsndfile -lFLAC -lvorbisenc -lvorbis -logg -lm
>> -Wl,-rpath,/home/hans/li
>
> People already did, nine years ago; choosing
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15471
> as a random example.
>
> Wanna guess what GNU did about it?
Told them libtool knows best, close bug?
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
> and it breaks on OpenBSD because of the following libtool bug."
> See how it goes.
There's a reason I suggested someone else do it. I have zero patience
for GNU people and their self-righteous attitudes.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
e only seen it fail on my system.
It is clear now that the errors you're seeing are caused by the
-L/usr/local/lib flag along with an old libsox being there. It is also
clear that libtool is to blame for this. If it relies on -L flags to
find the just-built library
> $ play -V -n -b 16 synth 1
> play INFO sunaudio: Sun Audio driver only supports bytes and words
> play:SoX v14.4.2
> play INFO nulfile: sample rate not specified; using 48000
>
> Input File : '' (null)
> Channels : 1
> Sample Rate: 48000
> Pre
gt; > -lcrypto -lsndfile -lFLAC -lvorbisenc -lvorbis -logg -lm
>> > -Wl,-rpath,/home/hans/lib -Wl,-rpath,/usr/local/lib
>
> With the current new-build, the ultimate linkage fails on OpenBSD
> for plain ./configure (without any args or env variables):
>
> /bin/sh ../li
-g -O2 -fstack-protector -Wall
>> >> -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -o .libs/sox sox.o
>> >> -L/usr/local/lib -L./.libs -lsox -lltdl -lpng -lao -lgsm -lmad -lid3tag
>> >> -lz -lmp3lame -ltwolame -lopusfile -lopus -lsndio -lvorbisfile -lwavpack
>> >> -lcrypto -lsndfile -lFLAC -lvorbisenc -lvorbis -logg -lm
>> >> -Wl,-rpath,/home/hans/lib -Wl,-rpath,/usr/local/lib
>> >
>> > Presumably, the problem does not occur wih a release,
>> > because it already comes with a ./configure script,
>> > so the builder does not have to run autoreconf -i,
>> > which is when the (broken) ./libtool gets created.
>> > So the 'libtool' called is the OpenBSD libtool,
>> > which does not have that bug.
>>
>> Unfortunately, that's not the case. The release tarball includes
>> whatever libtool script is on the system that generated it.
>
> Apparently, 14.4.2 does not:
>
> $ tar xzf /usr/ports/distfiles/sox-14.4.2.tar.gz
> $ find sox-14.4.2/ -name libtool
It is created by configure from the ltmain.sh script which is included.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
bisfile.so
> /usr/pkg/lib/libvorbis.so /usr/pkg/lib/libogg.so -lm -fopenmp -Wl,-rpath
> -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib
>
> Full path of .libs/libsox.so and the external libraries,
> -lm -lmagic for the system libraries.
> Not sure how /usr/local/lib got there
> - /usr/local doesn't even exist here.
You used the (default) /usr/local installation prefix. An rpath entry
for this is added to the linked executable so the shared library will be
found once installed. This is reasonable.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Måns Rullgård writes:
> Jan Stary writes:
>
>> On Aug 27 11:40:48, h...@stare.cz wrote:
>>> On Aug 24 08:56:43, h...@stare.cz wrote:
>>> > On Aug 23 23:55:51, h...@stare.cz wrote:
>>> > > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L
to /usr/local. Maybe you made some mistake.
Frankly, I don't give a damn. It's not happening here.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
't need anything besides dlopen() for it to work.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
t; the position of -L seems to be the difference.
Both ways work fine on my OpenBSD system (clean install + lame etc).
There is no difference in behaviour between the master and new-build
branches.
--
Måns Rullgård
___
SoX-devel mailing
ave an old libsox in
/usr/local/lib, and with that -L flag early in the command, it takes
precedence over the just-built libsox, causing the link to fail. If
you're building the same version, it won't matter which one the linker
finds, so it succeeds.
This whole issue is unique to OpenBSD. On
(of course). So the requirement
> to have autoconf, automake and autoconf-archive probably needs to
> be augmented with GNU libtool; otherwise,
Is there any other libtool?
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
fixes many (but not all, unfortunately) issues
> when software links to libraries already installed
> instead of those just built because, for example,
> "-L/usr/local/lib" comes before "-L../libfoo".
>
> That seems to be precisely
d via absolute paths -
> seems to be precisely those detected by pkg-config
> (not sure what the point of pkg-config --libs is then);
> the others (-lm -lmagic) are found in the -L path.
>
> The linking commands are not invented by Linux or FreeBSD or OpenBSD
> - they are w
e care of all such issues and more.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
itten by hand,
> as opposed to produced by auto*
While I'm no fan of autotools, the existing script works. I'll consider
replacements if maintaining it becomes too much of a burden.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Claude Warren writes:
> Would the new tool work on strange platforms like pi-zero?
I have no immediate plans to replace the existing autoconf based build
system. If you're having trouble building for some target, please
provide details so that it can be fixed.
--
Måns Rullg
Pander writes:
> On 8/2/20 12:52, Måns Rullgård wrote:
>> Måns Rullgård writes:
>>
>>>> + if (stat->fft_average) {
>>>> + for (i = 0; i < samples / 2; i++) /* FIXME: should be <=
>>>> samples / 2 */
>>>>
on height of spectrogram
> Add spectrogram -n flag to normalise the output to maximum brightness
>
> Pander (1):
> Added average power spectrum for stat -freq -a
>
> gabor.kar...@gmx.at (1):
> fix manpage warning: "table wider
t; for (done = 0; done < len; done++) {
> @@ -192,6 +216,7 @@ static int sox_stat_flow(sox_effect_t * effp, const
> sox_sample_t *ibuf, sox_samp
> stat->read += len;
>}
>
> + free(re_average);
>*isamp = *osamp = len;
>/* Process all sample
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 tested it on a few
Eric Wong writes:
> 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
y format that isn't mostly sequential, certainly not
that's supported in SoX. There might exist some format that separates
channel data such that reading sequentially from multiple starting
points is the best strategy.
What sort of improvement do you get from this anyway? I'm not opposed
t
unexpected changes. Still, I may have missed something.
The new code is in the 'new-wave' branch in the git repo. Please try it
out, especially if you have any weird WAV files lying around.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel
le;
> @@ -382,6 +431,7 @@ static FILE * xfopen(char const * identifier, char const
> * mode, lsx_io_type * i
> #endif
> f = popen(identifier + 1, POPEN_MODE);
> *io_type = lsx_io_pipe;
> +incr_pipe_size(f);
> #else
> lsx_fail("t
on_default) {
> reqpar.le = SIO_LE_NATIVE;
> if (ft->encoding.reverse_bytes)
I'm not familiar with OpenBSD, so I'll trust you guys that this is correct.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
I had queued up from years ago.
> (I mailed separately about the wavpack issue).
Thanks. I'll check them over and push them unless I spot any problems.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sou
dft_size, sizeof(*(p->dft_buf)));
> + p->window = lsx_calloc(p->dft_size + 1, sizeof(*(p->window)));
> + p->magnitudes = lsx_calloc((p->dft_size / 2) + 1,
> sizeof(*(p->magnitudes)));
> +
>if (is_p2(p->dft_size) && !effp->flow)
> lsx_safe_rdft(p->df
build systems seems to me like an unnecessary
burden. I am therefore tempted to simply delete all but the autotools
based one. If nobody makes a compelling argument for keeping these
extra build systems, I intend to do this next time a change would
require updating them.
--
Måns Rullgård
Eric Wong writes:
> 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
> copyri
Måns Rullgård writes:
>> + if (stat->fft_average) {
>> + for (i = 0; i < samples / 2; i++) /* FIXME: should be <= samples
>> / 2 */
>> + fprintf(stderr, " %f %f\n", ffa * i, re_average[i] / len);
>> + }
>
>
Eric Wong writes:
> 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.
Eric Wong writes:
> 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
>> >> Li
/projects/opencore-amr/
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Måns Rullgård writes:
> Then there is the OpenCORE library[1]. Although in part based on the
> 3GPP code, it is apparently somehow blessed to make it legal. However,
> it only includes decoding. Yet another library, vo-amrwbenc, can encode
> the WB variant but not NB. Both o
/gsm.h so far. The patch also includes a fix
> for detecting lame.h in addition to lame/lame.h
Patches or not, do you have any compelling reason to keep the cmake
system? I don't like it, and I certainly don't want to maintain it.
--
Måns Rullgård
_
t; on other systems, how would we use src/bit-rot/sndio.h?
There's a commented-out line in the Makefile that adds -Ibit-rot to the
compiler flags. I'm guessing someone used (or intended to use) this to
compile e.g. sndio.c. It would obviously still fail to link. The
purpose of this would (presumably) be to make sure those files are kept
up to date if changes are made to the libsox internal interface.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
>> - [AC_CHECK_HEADERS(machine/soundcard.h,
>> - [AC_CHECK_LIB(ossaudio, _oss_ioctl, OSS_LIBS="$OSS_LIBS -lossaudio")],
>> - using_oss=no)])])
>> +AC_OPTIONAL_FORMAT(oss, OSS, [AC_CHECK_HEADERS(sys/soundcard.h,,
>> uing_oss=no)])
>
> Apparently,
we want to use it).
-lossaudio is _only_ for the emulation on *BSD. No library is required
on systems with real OSS drivers. We shouldn't be using the emulation,
so there is no need to link with the library either.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Any objections?
>
> Please do kill it.
That's one vote in favour of ditching it. Good enough for me.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
; completes successfully, for now. The Visual Studio projects are almost
>> certainly broken.
>
> I see the CMake system has been removed.
Yes, something I did broke it even more than it already was.
> Can we also remove the ancient broken VS
no
> pulseaudio.no
> sunaudio...no
> waveaudio (MS-Windows).no
>
> and it builds fine.
>
>> > also, even with oss detected, we no longer set -libossaudio,
>> > which also seems wr
Jan Stary writes:
> On Aug 11 15:29:17, m...@mansr.com wrote:
>> > Can we also remove the ancient broken VS projects please?
>>
>> Of course.
>
> https://sourceforge.net/u/janstary/sox/ci/msvc/tree/
Oh, I had already done the delete on
es, or so it seems.
Writing is not implemented, so that would be a welcome patch.
Be warned, the current handling of oversized data is rather broken, so
don't bother trying to preserve any existing behaviour.
--
Måns Rullgård
___
SoX-d
is me. I really ought
to figure out what's needed to make a release. It's been too long since
the last one, and quite a few fixes have piled up. Some distributions
have released versions based on more recent git commits, so that may be
what you've seen.
--
Måns
than
that, there is no facility for runtime loading of effects.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Måns Rullgård writes:
> ma...@riseup.net writes:
>
>> Hi everyone,
>>
>> we (my colleagues and I) are in need of some Sox functionality with
>> support for RF64 files and are thinking about adding proper (reading and
>> writing) support for RF64 files
make autoconf-archive libtool pkgconf
autoconf-2.69_3
automake-1.16.3
autoconf-archive-0.2019.01.06
libtool-2.4.6_1
pkgconf-1.7.3,1
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
es installed. It works fine
>> on FreeBSD here.
>> $ freebsd-version
>> 12.2-RELEASE-p3
>> $ pkg info autoconf automake autoconf-archive libtool pkgconf
>> autoconf-2.69_3
>> automake-1.16.3
>> autoconf-archive-0.2019.01.06
>> libtool-2.4.6_1
>>
8 years ago. Piling the patches
> is starting to get cubersome when packaging downstream
> - are there any plans for a release?
I can slap a tag on the git repo and call it a day if that makes people
happy. The process for creating the files comprising earlier releases
is convoluted and
Martin Guy writes:
> On 5/20/24 15:27, Måns Rullgård wrote:
>> Martin Guy writes:
>>> I would post an issue and patch on sourceforge, but that seems useless as
>>> the existing patches haven't been applied since 2006.
>> You can send patches to this maili
Jan Stary writes:
> On May 20 19:20:11, martinw...@gmail.com wrote:
>> On 5/20/24 15:27, Måns Rullgård wrote:
>> > Martin Guy writes:
>> > > I would post an issue and patch on sourceforge, but that seems useless as
>> > > the existing patches haven't
Jan Stary writes:
> On May 21 18:08:08, martinw...@gmail.com wrote:
>>
>> On 5/21/24 17:00, Måns Rullgård wrote:
>> > Martin Guy writes:
>> >
>> > diff --git a/src/spectrogram.c b/src/spectrogram.c
>> > index 3dcda69c..c13eb6c9 100644
>&g
actual) +
> 0.5;
> - p->block_steps = effp->in_signal.rate / pixels_per_sec;
> + p->block_steps = max(effp->in_signal.rate / pixels_per_sec, 1);
>p->step_size =
> p->block_steps / ceil((double)p->block_steps / p->step_size) + 0.5;
>p->block_ste
Martin Guy writes:
> I would post an issue and patch on sourceforge, but that seems useless as
> the existing patches haven't been applied since 2006.
You can send patches to this mailing list.
--
Måns Rullgård
___
SoX-devel mailing list
SoX
x/bugs/319/
>
> and here.
>
> Thanks and keep up the good work
This crash has nothing to do with the multiplication overflow described
in the CVE. Still it's a bug, so I've fixed it.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Martin Guy writes:
> On 5/30/24 15:48, Måns Rullgård wrote:
>
>> Martin Guy writes:
>>
>>> Forwarded Message
>>> Subject:CVE-2019-8354 claims to have been fixed in SoX, but isn't
>>> Date: Thu, 30 May 2024 12:49:17 +0200
99 matches
Mail list logo
