Reuben Thomas :
> sox.sf.net gives an error page at present, and I don't see anything
> about this on the mailing list…
Yes, apparently the Wiki installation has some (configuration?) problem. Static
content, like the man pages, is still accessible:
http://sox.sourceforge.net/sox.html
Ulrich
It's back. Did anyone do anything? Otherwise, it was probably just a transient
problem on SourceForge's side.
Ulrich
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynam
Jan Stary :
> SoX is just writing to stdout and has no knowledge about
> its stdout being either redirected (to two.wav) or piped (to cat > three.wav)
> later, right? Can someone please shed some light on what difference is
> it to sox in this (regarding length probably)?
> $ sox file.mp3 -t wa
Hi,
it seems that libav 9, which is due some time soon, finally removes
(at least some of) the deprecated API functions that the compiler has
been complaining about for a while.
So, question is: Does anyone want to update src/ffmpeg.c to use the
new API? (If so, this should probably go into
Chris Bagwell :
> Any objections to pushing out a new release of SoX? Anybody have a
> TODO they'd like to finish before a new release?
That's the maintenance release from the "dot" branch, right? I think
I'm *almost* finished with that (just marked ffmpeg as deprecated
...), there is one
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 dot.
> 2) FLAC: fix MD5 check and code simplification
> https://sourceforge.net/tracker/?func=d
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
may be inapplicable (e.g., for frequency-domain expression).
Regarding the LA
Eric Wong :
>> 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
>> may be inapplicable (e.g., for frequency-domain expression).
> For compression, then shouldn't -b be the maximum bits-per-sample
> decodi
OK, took a bit longer than expected (as always ...), but I think I've
included everything I wanted (or decided I don't want it anymore ;-)).
So I'd be OK for release now.
Ulrich
--
Master Visual Studio, SharePoint, S
Rob Sykes :
> Hmm, I had been committing to master for this release -- should I have
> been committing to dot?
I think I backported (most of?) your bug fixes, such as the recent rate hang or
integer division issue. More invasive changes, like the rate speedups, are fine
in master.
Ulrich
---
Jan Stary :
> Would it be possible to have SoX figure itself that the flac
> functionality is available (through libsndfile) and just use it,
> without having to specify it explicitly?
Yes, and it is actually quite simple to do this. A minimal format handler like
that in src/w64.c is all that
Paul Brun :
> Is it possible to adjust the bass, treble, tempo, etc while
> the audio file is being played??
No, this is not supported, neither in SoX-the-program nor in libSoX.
Ulrich
--
Master Visual Studio, SharePoi
Chris Bagwell :
> This is the final release candidate before official release on 1013/02/01.
I fixed another bug, in compand/mcompand; quite nasty, but probably
not hit very often. If you think it was too late, you could branch off
a release branch at rc3 and release from that instead of dot:
Chris Bagwell :
> Are you up for updating NEWS before real release? If not, I'll do it but
> probably will be closer to filtered shortlog than in past.
Just pushed a draft. The list is a bit short, but I think those are
the fixes that are most likely to be noticeable for more than a
handful
Pascal Giard :
> On Wed, Jan 30, 2013 at 10:30 PM, Chris Bagwell wrote:
> > For SoX, you should be able to get an idea of API and ABI modifications
> > using "git log -u src/sox.h" since that defines our interface to library.
> > That shows no modifications in dot branch since 14.4.0 release.
> G
Pascal Giard :
> Could you elaborate on the modifications you have in mind that could
> constitute a modification please?
> Based on your judgement, do you think an application using libsox2
> could reasonably depend on the previous behavior?
That would mean a change that is not backward compati
FYI, I put up the announcement on the website ("Latest News"). Since
this sentence ...
> Check that PulseAudio is present before trying to use it.
... has already caused confusion (can be misunderstood as a request to
the user - "please check ... before trying to use the new SoX
version"), I
Pascal Giard :
> I'll try to be diligent in pushing 14.4.1 to Debian unstable however
> it will be hard this weekend¹.
> ¹ My birthday party is added on top of to the usual routine that
> having 2 young kids imposes.
Belated happy birthday!
> I want to have a close look and think thoroughly abou
It seems that the distributed Windows binary doesn't contain libflac
or libsndfile:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=93850&view=findpost&p=822864
On sox-users, bat guano suspected it may be due to the workaround on
mingwbuild:96 being commented out. If that is the pr
Chris Bagwell :
> To lower confusion, should I
> release a sox-14.4.1.1-win32 or go as far as a sox-14.4.2-win32?
"Why is the Windows version more recent than the Unix one??" ;-) So I'd think
14.4.1.1 is better, or 14.4.1-a or something. It is only a different build from
the same source afte
6121569b884ba Mon Sep 17 00:00:00 2001
From: Ulrich Klauer
Date: Sun, 10 Feb 2013 15:56:13 +0100
Subject: [PATCH] Link Windows build to wsock32.dll again
Link the Windows build to wsock32.dll for ntohl() again instead of
trying to provide an own implementation.
(Partial revert of commit d0647a4
Pascal Giard :
> FWIW the 14.4.1 source tarball contains outdated versions of
> config.guess and config.sub .
>
> It's not a big deal as I can easily workaround this and update them
> for Debian, but it may be useful to users if you could include the
> latest ones in the next releases.
>
> This c
> > 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, "autoreconf --force" doesn't update t
Hi,
recently, I've done some research and experimenting on how to build
SoX binaries for Windows, and I've come to think that the best tool is
MXE (M Cross Environment, http://mxe.cc/). Essentially, it is a
collection of patches and build scripts with some makefile glue, made
exactly for ou
Chris Bagwell :
> Sounds promising solution. I especially like how it downloads everything
> so we can move between build computers much faster.
Yes, although "fast" is relative; it takes its time to build
everything from scratch, especially GCC (about twenty minutes for me;
a faster compute
Chris Bagwell :
> I've just uploaded sox-14.4.1a-win32 packages to Sourceforge. If I get
> some positive feedback on it, I'll make it recommended download version for
> Windows platform and delete the original sox-14.4.1-win32 packages.
Speaking of recommended download versions, SourceForge reco
Dave Lambley :
> Before I get stuck into cleaning it up for submission, is anyone else
> working on RF64 support?
Not directly (as far as I know), but libsndfile supports RF64. This
means SoX can read it via -t sndfile (sox -t sndfile example.rf64
out.w64). In principle, it should also offer
Stephen Paterson wrote:
I can't get it to work with libsox. I've made a tiny modification to
example3.c that should do the same but no matter what I try I always
end up with a file that is exactly half the length of the one I get
from sox (or some crazy audio).
example3 is buggy. It doesn
Eric Seigne wrote:
> setlocale(LC_ALL, "C");
> juste before "e = sox_create_effect(sox_find_effect("noiseprof"));"
> So is this bug resolved with last git version ?
Well, your local locale is only set because you call setlocale()
somewhere else in your program. SoX/libSoX never do tha
Christian Hoene wrote:
> the attached program converts a file to one channel and a sampling
> rate of 8000. If the input is a stereo file, then the duration of
> the output file is half of the duration of the input file. The last
> half is missing.
sox_add_effect() modifies its "in" paramet
Christian Hoene wrote:
> One question. Is sox reentrant. Can I fork a sox program and run two
> sox chains in parallel?
When you call fork(), the address space is duplicated, so unless there
are already open files, the processes are completely independent.
Re-entrancy, on the other hand, is
31 matches
Mail list logo
