Hi guys,
I stumbled upon your presentation/application today.
I noticed that you were mentioning issues with SoX 14.3.2.
I'd just like to make sure I get this right:
1) Training was done using SoX < 14.3.2;
2) Using SoX >= 14.3.2 requires retraining to get great accuracy.
Thus, if I get this rig
On Mon, Nov 19, 2012 at 12:38 PM, Jan Stary wrote:
> On Nov 19 01:56:52, ulr...@chirlu.de wrote:
> > 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.
> >
>
Hi guys,
I'm in the process of doing some long overdue packaging changes for Debian.
(Moving away from obsolete makefiles and CDBS to the modern 3.0 (quilt) format).
In the process, I've found a small issue with our Autotools files.
Namely, "make distclean" removes some files that are distribute
Replying to myself
On Fri, Jan 18, 2013 at 10:39 AM, Pascal Giard wrote:
[...]
> As this should be backported to dot too, I'd appreciate if someone
> (Ulrich?) could teach me how to fish^Wcherry pick that commit and
> merge it to the dot branch.
Managed to find the info, did
Hi guys,
just FYI, I've just pushed some significant changes to the Debian
packaging files. They're finally in good shape. Some of those changes
were long overdue.
The only thing I want/need to do before pushing the upcoming 14.4.1 or
14.4.2 releases to Debian is to read about the introduction of
I guess it comes down to the latency you can tolerate.
Envoyé de mon iPodTouch 4G
Le 2013-01-25 à 15:07, Paul Brun a écrit :
> Hi guys,
>
> I am sure someone who is familiar with SOX is able to answer this. We are
> currently trying to implement a solution where we have an
> Audio Player in .
Hi Chris!
On Tue, Jan 29, 2013 at 10:00 PM, Chris Bagwell wrote:
> This is the final release candidate before official release on 1013/02/01.
>
> git tag: sox-14.4.1rc3
[...]
>
> Pascal Giard (4):
> "make distclean" should not get rid of the files distributed i
Hi guys,
On Wed, Jan 30, 2013 at 7:45 PM, Chris Bagwell wrote:
>
>
>
> On Wed, Jan 30, 2013 at 3:13 PM, Ulrich Klauer wrote:
>>
>> Chris Bagwell :
>>
>> > This is the final release candidate before official release on
>> > 1013/02/01.
Year 1013? I will assume 2013 ;-p
Seriously though, still a
On Wed, Jan 30, 2013 at 9:52 PM, Pascal Giard wrote:
> That being said, it would help me if you could tell me if a new symbol
> was introduced or an existing one modified in 14.4.1.
> See [1] for details on what constitutes an ABI change.
>
> I don't know if I can automate
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.
Good!
> I'll have to read
On Thu, Jan 31, 2013 at 10:24 PM, Ulrich Klauer wrote:
> 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" sin
On Sat, Feb 2, 2013 at 10:07 AM, Ulrich Klauer wrote:
> Finally (mainly relevant to Pascal), I branched off a "debian" branch
> from sox-14.4.1. My idea is that this branch can contain the packaging
> files for the different Debian sub-versions of 14.4.1, while the
> master branch has packaging fi
On Fri, Feb 1, 2013 at 7:40 PM, Ulrich Klauer wrote:
> 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 rea
On Wed, Feb 6, 2013 at 9:38 PM, Ulrich Klauer wrote:
> 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 yo
Hi guys,
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 can be done by e.g. ca
Hi guys,
derived into this this morning, thought this might affect SoX.
tl;dr: A "newish" issue when attempting to use the old trick to detect
if off_t needs to be forced to 64 bit (-D_FILE_OFFSET_BITS=64).
http://stackoverflow.com/questions/22664658/finding-off-t-size
-Pascal
--
Homepage (htt
Hi guys,
Some work in Debian is pushing toward reproducible builds [1] and
that work is advancing quite well. At the moment, 83%+ of the whole
archive passes.
SoX isn't one of those packages though as it uses timestamps macros
[2]. These timestamps macros are only use to tell users/coders about
On Wed, Feb 25, 2015 at 2:52 PM, Jan Stary wrote:
> This is the ./configure --help of the new 14.4.2.
> After the obligatory options such as --prefix,
> it presents the 'Optional Packages' section.
> This offers various additinal audio formats
> and output drivers.
>
> I believe it would be an imp
On Tue, Feb 24, 2015 at 10:02 PM, Chris Bagwell wrote:
> I've come to not like compile time timestamp showing up in output as well.
> Complicates CI tests checking for behavior regressions, defeats rsync's
> --hard-link option if one uses that to keep backups of past CI builds, etc.
>
> In short t
Wanting to test the timestamp removal pushing committing the changes,
I first tried to build the master branch.
However, it fails with the following:
$ /bin/sh ../libtool --silent --tag=CC --silent --mode=link gcc
-Wtraditional-conversion -g -O2 -fstack-protector -Wall -W
-Wmissing-prototypes -
Hi Chris!
On Fri, Feb 27, 2015 at 12:11 AM, Chris Bagwell wrote:
> Nothing jumps out at me other to to verify you reran autoreconf since I
> notice you've shown verbose output and now you have to go out of your way
> with 'make V=1' to see that libtool line.
I did go out of my way as I was tryin
Hi Chris,
On Sat, Feb 28, 2015 at 2:04 PM, Chris Bagwell wrote:
>
>
> On Fri, Feb 27, 2015 at 9:02 AM, Pascal Giard wrote:
>>
>>
>> > lsx_error is referenced by that flac.lo and symbol should be in
>> > libsox.la
>> > (from format_i.o) t
---
>> Subject: [PATCH] fix build with --with-dyn-default
>>
>> This was broken in commit 5c58413544fd600bf12fdc54fa9648f0bc1ea860
>> ("Don't export (most) internal libsox symbols")
>>
>> and noticed by both Pascal Giard and myself:
>> http:
Hi guys,
can anyone have a look at http://bugs.debian.org/823417 please?
Regards,
-Pascal
--
Homepage (http://www.ece.mcgill.ca/~pgiard1)
Debian GNU/Linux (http://www.debian.org)
TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
ISIP Laboratory: McGill (http://www.isip.ece.mcg
24 matches
Mail list logo