Re: [SoX-devel] SoX won't compile

[Cary Lewis <cary.lewis@gm...>]

Ha ha. At least you're honest...

On Mon, Feb 1, 2021 at 12:56 PM Måns Rullgård <mans@...> wrote:

> info@... writes:
>
> >> Simone Filippini <info@...> writes:
> >>
> >>> OS: FreeBSD 12.2
> >>> Commit: dd8b63
> >>> After "autoreconf -i" I get:
> >>> "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is
> >>> undefined."
> >>> I tried several previous commits but the error persists OR there are
> >>> errors after "./configure"
> >>> I can only compile the 2017 version of SoX on mansr GitHub.
> >>> Can anyone help me?
> >> Make sure you have all the required packages 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
> >> pkgconf-1.7.3,1
> >
> > pkgconf was missing. Thanks a lot.
> > Is there any reason why your patches to support dsd are not merged in
> this
> > version on sourceforge?
>
> Yes, I'm lazy.
>
> --
> Måns Rullgård
>
>
> _______________________________________________
> SoX-devel mailing list
> SoX-devel@...
> https://lists.sourceforge.net/lists/listinfo/sox-devel
>

Re: [SoX-devel] SoX won't compile

[Måns Rullgård <mans@ma...>]

info@... writes:

>> Simone Filippini <info@...> writes:
>> 
>>> OS: FreeBSD 12.2
>>> Commit: dd8b63
>>> After "autoreconf -i" I get:
>>> "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is
>>> undefined."
>>> I tried several previous commits but the error persists OR there are 
>>> errors after "./configure"
>>> I can only compile the 2017 version of SoX on mansr GitHub.
>>> Can anyone help me?
>> Make sure you have all the required packages 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
>> pkgconf-1.7.3,1
>
> pkgconf was missing. Thanks a lot.
> Is there any reason why your patches to support dsd are not merged in this
> version on sourceforge?

Yes, I'm lazy.

-- 
Måns Rullgård

Re: [SoX-devel] SoX won't compile

[<info@au...>]

> Simone Filippini <info@...> writes:
> 
>> OS: FreeBSD 12.2
>> Commit: dd8b63
>> 
>> After "autoreconf -i" I get:
>> "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is 
>> undefined."
>> 
>> I tried several previous commits but the error persists OR there are 
>> errors after "./configure"
>> 
>> I can only compile the 2017 version of SoX on mansr GitHub.
>> 
>> Can anyone help me?
> 
> Make sure you have all the required packages 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
> pkgconf-1.7.3,1

pkgconf was missing. Thanks a lot.
Is there any reason why your patches to support dsd are not merged in 
this version on sourceforge?
I tried to parse all your commits on github when you implemented dsd and 
tried to merge them all with the code here on SF.
When trying to compile I get:

--- libsox_la-sdm.lo ---
In file included from sdm.c:670:
./sdm_x86.h:52:41: error: unknown type name 'sdm_filter_t'
                                   const sdm_filter_t *f,
[...]

Any input would be really appreciated.
Thanks for your work,
Regards,
Simone

Re: [SoX-devel] SoX won't compile

[Måns Rullgård <mans@ma...>]

Simone Filippini <info@...> writes:

> OS: FreeBSD 12.2
> Commit: dd8b63
>
> After "autoreconf -i" I get:
> "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is undefined."
>
> I tried several previous commits but the error persists OR there are errors after "./configure"
>
> I can only compile the 2017 version of SoX on mansr GitHub.
>
> Can anyone help me?

Make sure you have all the required packages 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
pkgconf-1.7.3,1

-- 
Måns Rullgård

[SoX-devel] SoX won't compile

[Simone Filippini <info@au...>]

OS: FreeBSD 12.2
Commit: dd8b63

After "autoreconf -i" I get:
"Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is undefined."

I tried several previous commits but the error persists OR there are errors after "./configure"

I can only compile the 2017 version of SoX on mansr GitHub.

Can anyone help me?

Regards,
Simone

⁣​

[SoX-devel] A different display

[Claude Warren <claude@xe...>]

Greetings,

I have worked out my earlier issues (I think) and am now looking for a way
to display the sox status on a small (4x20) lcd screen.  I am working on a
Raspberry Pi project and want to be able to show the vu meter and other
recording information usually presented on the screen during sox execution.

My thought is to abstract the display calls into a couple of methods (I
have not explored exactly what that looks like yet), take the existing code
an move it into the methods and then produce a second implementation for my
use case.  I am thinking that placing the methods in a library will allow
multiple implementations  to be developed and a single one selected at link
time.

Are there any suggestions (or even a "just don't")?

I did implement he VU meter as an effect and that works but I thought this
might be a better solution.

Claude

-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>;
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [SoX-devel] Jack Driver

[Cary Lewis <cary.lewis@gm...>]

Can’t you just use cat or dd to read from the input source and tee to sox and the output device? Or do you need to Sox to decode the stream so that it plays? 

> On Nov 14, 2020, at 4:52 PM, Claude Warren <claude@...> wrote:
> 
> 
> I think I need a Jack device driver and I don't see one available, so I think I have to write one.  So is there any documentation about how to write a SoX device driver?
> 
> To back up a bit, I think I need a Jack device driver because I want to take the audio input and record it while also sending it to the output.  I don't want SoX to modify the  signal going to output.  So something like:
> 
> Input ----+---- output
>           |
>          SoX ---- disk
> 
> Put differently:  Tee the input with one going to output and one going to sox to record to disk.
> 
> Anybody have either documentation for how to write the device driver or a solution for the problem?
> 
> Claude
> 
> -- 
> I like: Like Like - The likeliest place on the web
> LinkedIn: http://www.linkedin.com/in/claudewarren
> _______________________________________________
> SoX-devel mailing list
> SoX-devel@...
> https://lists.sourceforge.net/lists/listinfo/sox-devel

[SoX-devel] Jack Driver

[Claude Warren <claude@xe...>]

I think I need a Jack device driver and I don't see one available, so I
think I have to write one.  So is there any documentation about how to
write a SoX device driver?

To back up a bit, I think I need a Jack device driver because I want to
take the audio input and record it while also sending it to the output.  I
don't want SoX to modify the  signal going to output.  So something like:

Input ----+---- output
          |
         SoX ---- disk

Put differently:  Tee the input with one going to output and one going to
sox to record to disk.

Anybody have either documentation for how to write the device driver or a
solution for the problem?

Claude

-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>;
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [SoX-devel] Additional info: examples and sox_sample_test not built

[Måns Rullgård <mans@ma...>]

"Wolfgang Stoeggl" <wolfgang.stoeggl@...> writes:

> Hi,
>
> for now, it helps to change into the src subdirectory and run the make
> commands from there:
>
> cd src
> make examples
> make extras

Yes, I know.  I intend to get rid of the recursive makefiles anyway,
which will take care of all such issues and more.

-- 
Måns Rullgård

[SoX-devel] Additional info: examples and sox_sample_test not built

[Wolfgang Stoeggl <wolfgang.stoeggl@ao...>]

Hi,

for now, it helps to change into the src subdirectory and run the make commands from there:

cd src
make examples
make extras

Best regards
Wolfgang


> -----Original Message-----
> From: Wolfgang Stoeggl via SoX-devel <sox-devel@...>
> Sent: Saturday, 26. September 2020 08:33
> To: Sox-devel <sox-devel@...>
> Cc: Wolfgang Stoeggl <c72578@...>
> Subject: [SoX-devel] examples and sox_sample_test not built
> 
> Hi Måns,
> 
> in current git master [1], the examples and sox_sample_test are not built
> automatically anymore using make (since commit
> 3b6c27419f736c2dfa3b2bf3d34dfe656832c464).
> 
> How are these supposed to be enabled now?
> 
> The following is not working:
> make examples
> make: *** No rule to make target 'examples'.  Stop.
> 
> make extras
> make: *** No rule to make target 'extras'.  Stop.
> 
> 
> Thanks and best regards,
> Wolfgang
> 
> 
> [1]
> https://sourceforge.net/p/sox/code/ci/dd8b63bdc2966c931b73d5f7a17db33
> 6cbec6c21/
> 
> 
> _______________________________________________
> SoX-devel mailing list
> SoX-devel@...
> https://lists.sourceforge.net/lists/listinfo/sox-devel

[SoX-devel] examples and sox_sample_test not built

[Wolfgang Stoeggl <c72578@ya...>]

Hi Måns,

in current git master [1], the examples and sox_sample_test are not built automatically anymore using make (since commit 3b6c27419f736c2dfa3b2bf3d34dfe656832c464).

How are these supposed to be enabled now?

The following is not working:
make examples
make: *** No rule to make target 'examples'.  Stop.

make extras
make: *** No rule to make target 'extras'.  Stop.


Thanks and best regards,
Wolfgang


[1] https://sourceforge.net/p/sox/code/ci/dd8b63bdc2966c931b73d5f7a17db336cbec6c21/

Re: [SoX-devel] silence additional patch

[Måns Rullgård <mans@ma...>]

Cary Lewis <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

Re: [SoX-devel] silence additional patch

[Cary Lewis <cary.lewis@gm...>]

Please, for the sake of the software, find a way to be civil to each other.

Perhaps a SOX code of conduct is in order?

> On Sep 6, 2020, at 8:50 AM, fbk-qriry@... wrote:
> 
> 
>> 
>> 
>> If that's the attitude you're going to display, I will have to ask you
>> to kindly go away until such time as you are able to engage in a polite
>> conversation.  Perhaps you could use that time to study good software
>> development practices.
>> 
> 
> Please remove all of my posts from your server.
> 
> :JW
> 
> 
> 
> _______________________________________________
> SoX-devel mailing list
> SoX-devel@...
> https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: [SoX-devel] silence additional patch

[<fbk-qriry@za...>]

>
>If that's the attitude you're going to display, I will have to ask you
>to kindly go away until such time as you are able to engage in a polite
>conversation.  Perhaps you could use that time to study good software
>development practices.
>

Please remove all of my posts from your server.

:JW

Re: [SoX-devel] silence additional patch

[Måns Rullgård <mans@ma...>]

fbk-qriry@... writes:

>>fbk-qriry@... writes:
>>
>>> Further to my previous "silence" patch I have discovered
>>> that there is another error involving the rms calculations.
>>>
>>> Initially, and after a reset, the rms sample window is empty
>>> yet the rms calculation always uses the window size as
>>> the calculation denominator. This will make the rms
>>> value appear artificially low to start with. Instead, an
>>> actual count of samples should be used.
>>>
>>> Incidentally, I think that the hard-coded 1/50 for selection
>>> of a window size should also be parametized. Sometimes 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 do the work unravelling what's what.
>>
>>-- 
>>Mns Rullgrd
>>
>
> Perhaps that is why there are still so many blatant bugs in sox
> after all of these years?
>
> I have only started looking and I am sure I can find many
> many more.
>
> It is entirely up to you. I feed information into your brain
> and if your brain is incapable or unwilling to digest any of it
> then that is entirely your problem.
>
> Please bear in mind that sox currently contains hundred of
> related and unrelated lines of code. And that doesn't stop
> sox from working does it? Unrelatedness has never been
> an obstacle in the past has it?
>
> Anyhow would you care to introduce yourself and explain how
> it is that you have apparently become the sole arbiter of what
> is good or bad for sox.
>
> Incidentally, I can very easily patch sox entirely for my own
> benefit and there is no compulsion for me to publish such
> private changes on any public forum. I only do that out of
> the goodness of my heart. The patches merely serve as a convenient
> way of explaining the bugs in more detail. Once a person such as
> your kind self has availed him- or her-self of the wisdom of my discoveries
> then your good person is freely 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 you're going to display, I will have to ask you
to kindly go away until such time as you are able to engage in a polite
conversation.  Perhaps you could use that time to study good software
development practices.

-- 
Måns Rullgård

Re: [SoX-devel] silence additional patch

[<fbk-qriry@za...>]

>
>> Further to my previous "silence" patch I have discovered
>> that there is another error involving the rms calculations.
>>
>> Initially, and after a reset, the rms sample window is empty
>> yet the rms calculation always uses the window size as
>> the calculation denominator. This will make the rms
>> value appear artificially low to start with. Instead, an
>> actual count of samples should be used.
>>
>> Incidentally, I think that the hard-coded 1/50 for selection
>> of a window size should also be parametized. Sometimes 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 do the work unravelling what's what.
>

I might also point out that the two issues I have rasied apply
to the one same file, namely silence.c. Since patches must be
applied in the correct order, and since you appear to
unconditionally and irrationally rejected my first patch then
I cannot possibly issue a patch that depends on the prior patch.

Therefore it makes a lot of sense to submit an cumulative patch.

:JW

Re: [SoX-devel] silence additional patch

[<fbk-qriry@za...>]

>fbk-qriry@... writes:
>
>> Further to my previous "silence" patch I have discovered
>> that there is another error involving the rms calculations.
>>
>> Initially, and after a reset, the rms sample window is empty
>> yet the rms calculation always uses the window size as
>> the calculation denominator. This will make the rms
>> value appear artificially low to start with. Instead, an
>> actual count of samples should be used.
>>
>> Incidentally, I think that the hard-coded 1/50 for selection
>> of a window size should also be parametized. Sometimes 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 do the work unravelling what's what.
>
>-- 
>Mns Rullgrd
>

Perhaps that is why there are still so many blatant bugs in sox
after all of these years?

I have only started looking and I am sure I can find many
many more.

It is entirely up to you. I feed information into your brain
and if your brain is incapable or unwilling to digest any of it
then that is entirely your problem.

Please bear in mind that sox currently contains hundred of
related and unrelated lines of code. And that doesn't stop
sox from working does it? Unrelatedness has never been
an obstacle in the past has it?

Anyhow would you care to introduce yourself and explain how
it is that you have apparently become the sole arbiter of what
is good or bad for sox.

Incidentally, I can very easily patch sox entirely for my own
benefit and there is no compulsion for me to publish such
private changes on any public forum. I only do that out of
the goodness of my heart. The patches merely serve as a convenient
way of explaining the bugs in more detail. Once a person such as
your kind self has availed him- or her-self of the wisdom of my discoveries
then your good person is freely 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.

:JW

Re: [SoX-devel] silence additional patch

[Måns Rullgård <mans@ma...>]

fbk-qriry@... writes:

> Further to my previous "silence" patch I have discovered
> that there is another error involving the rms calculations.
>
> Initially, and after a reset, the rms sample window is empty
> yet the rms calculation always uses the window size as
> the calculation denominator. This will make the rms
> value appear artificially low to start with. Instead, an
> actual count of samples should be used.
>
> Incidentally, I think that the hard-coded 1/50 for selection
> of a window size should also be parametized. Sometimes 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 do the work unravelling what's what.

-- 
Måns Rullgård

[SoX-devel] silence additional patch

[<fbk-qriry@za...>]

Further to my previous "silence" patch I have discovered
that there is another error involving the rms calculations.

Initially, and after a reset, the rms sample window is empty
yet the rms calculation always uses the window size as
the calculation denominator. This will make the rms
value appear artificially low to start with. Instead, an
actual count of samples should be used.

Incidentally, I think that the hard-coded 1/50 for selection
of a window size should also be parametized. Sometimes 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:

===================================================================
--- sox-downstream-sox-14.4.2.0.modified/src/silence.c.jw
+++ sox-downstream-sox-14.4.2.0.modified/src/silence.c
@@ -55,6 +55,7 @@
     double      *window_current;
     double      *window_end;
     size_t   window_size;
+    size_t   window_count;
     double      rms_sum;
 
     char        leave_silence;
@@ -73,6 +74,7 @@
 
     silence->window_current = silence->window;
     silence->window_end = silence->window + silence->window_size;
+    silence->window_count = 0;
     silence->rms_sum = 0;
 }
 
@@ -277,9 +279,15 @@
 {
   /* When scaling low bit data, noise values got scaled way up */
   /* Only consider the original bits when looking for silence */
-  sox_sample_t masked_value = value & (-1 << (32 - effp->in_signal.precision));
+  double scaled_value;
+  sox_sample_t rounded_value = value;
 
-  double scaled_value = (double)masked_value / SOX_SAMPLE_MAX;
+  /* before we mask we should round the value (a sqrt irrational) */
+  if (effp->in_signal.precision < 32)
+    rounded_value += (1 << (32 - effp->in_signal.precision - 1));
+  rounded_value &= (-1 << (32 - effp->in_signal.precision));
+
+  scaled_value = (double)rounded_value / SOX_SAMPLE_MAX;
 
   if (unit == '%')
     scaled_value *= 100;
@@ -294,12 +302,17 @@
     priv_t * silence = (priv_t *) effp->priv;
     double new_sum;
     sox_sample_t rms;
+    size_t count;
 
     new_sum = silence->rms_sum;
     new_sum -= *silence->window_current;
     new_sum += ((double)sample * (double)sample);
 
-    rms = sqrt(new_sum / silence->window_size);
+    count = silence->window_count;
+    if (count < silence->window_size)
+	count++;
+
+    rms = sqrt(new_sum / count);
 
     return (rms);
 }
@@ -315,6 +328,9 @@
     silence->window_current++;
     if (silence->window_current >= silence->window_end)
         silence->window_current = silence->window;
+
+    if (silence->window_count < silence->window_size)
+	silence->window_count++;
 }
 
 /* Process signed long samples from ibuf to obuf. */
===================================================================

:JW

Re: [SoX-devel] PACKAGE_EXTRA?

[Claude Warren <claude@xe...>]

I am using it to verify that I have the custom version I am building.  My
custom extension sends the vu meter to an 4x20
LCD screen on a raspberry pi.

On Sat, Sep 5, 2020 at 3:37 PM Måns Rullgård <mans@...> wrote:

> Claude Warren <claude@...> writes:
>
> > I see that I can set DISTRO with the "--with-distro " option on
> configure.
> > But I don't see any way to set PACKAGE_EXTRA.  Is there a simple way to
> do
> > this?
>
> There doesn't seem to be any better way than setting it via CFLAGS.
> It is also not clear why it was ever added in the first place.
>
> --
> Måns Rullgård
>


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>;
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [SoX-devel] PACKAGE_EXTRA?

[Måns Rullgård <mans@ma...>]

Claude Warren <claude@...> writes:

> I see that I can set DISTRO with the "--with-distro " option on configure.
> But I don't see any way to set PACKAGE_EXTRA.  Is there a simple way to do
> this?

There doesn't seem to be any better way than setting it via CFLAGS.
It is also not clear why it was ever added in the first place.

-- 
Måns Rullgård

[SoX-devel] PACKAGE_EXTRA?

[Claude Warren <claude@xe...>]

I see that I can set DISTRO with the "--with-distro " option on configure.
But I don't see any way to set PACKAGE_EXTRA.  Is there a simple way to do
this?

Claude

-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>;
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [SoX-devel] silence patch

[Måns Rullgård <mans@ma...>]

fbk-qriry@... writes:

> There is a bug in the "silence" effect that appears to
> have been introduced in 2009 with commit bbb403.
>
> In function aboveThreshold() the value being scaled
> is effectively the result of a sqrt but when it
> gets scaled the value is not rounded but coarsely truncated instead.
> Truncation is wrong. Rounding is right.
>
> Prior to this commit the value was effectively
> rounded to the nearest whole value (according to
> the precision). Without the following patch the "silence"
> results are considerably different to earlier versions.
>
> For example:
>
>   value        old masked  current
>   -----        ----------  -------
>   0x009bd6ae   0x0000009c  0x009b0000
>   0x00a170b8   0x000000a1  0x00a10000
>
> The 0x009bd6ae used to be correctly rounded to 0x9c whereas
> the current version effectively truncates the value to 0x9b.
>
> That is a serious flaw that should have been picked up
> during testing. But better discovered 11 years later by a
> random member of the public than never.

The only serious flaw I see here is your condescending tone.

> The patch:
>
> ======================================================================
> --- sox-downstream-sox-14.4.2.0.modified/src/silence.c.jw
> +++ sox-downstream-sox-14.4.2.0.modified/src/silence.c
> @@ -277,9 +277,15 @@
>  {
>    /* When scaling low bit data, noise values got scaled way up */
>    /* Only consider the original bits when looking for silence */
> -  sox_sample_t masked_value = value & (-1 << (32 - effp->in_signal.precision));
> +  double scaled_value;
> +  sox_sample_t rounded_value = value;
>
> -  double scaled_value = (double)masked_value / SOX_SAMPLE_MAX;
> +  /* before we mask we should round the value */
> +  if (effp->in_signal.precision < 32)
> +    rounded_value += (1 << (32 - effp->in_signal.precision - 1));
> +  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] silence patch

[<fbk-qriry@za...>]

There is a bug in the "silence" effect that appears to
have been introduced in 2009 with commit bbb403.

In function aboveThreshold() the value being scaled
is effectively the result of a sqrt but when it
gets scaled the value is not rounded but coarsely truncated instead.
Truncation is wrong. Rounding is right.

Prior to this commit the value was effectively
rounded to the nearest whole value (according to
the precision). Without the following patch the "silence"
results are considerably different to earlier versions.

For example:

  value        old masked  current
  -----        ----------  -------
  0x009bd6ae   0x0000009c  0x009b0000
  0x00a170b8   0x000000a1  0x00a10000

The 0x009bd6ae used to be correctly rounded to 0x9c whereas
the current version effectively truncates the value to 0x9b.

That is a serious flaw that should have been picked up
during testing. But better discovered 11 years later by a
random member of the public than never.

The patch:

======================================================================
--- sox-downstream-sox-14.4.2.0.modified/src/silence.c.jw
+++ sox-downstream-sox-14.4.2.0.modified/src/silence.c
@@ -277,9 +277,15 @@
 {
   /* When scaling low bit data, noise values got scaled way up */
   /* Only consider the original bits when looking for silence */
-  sox_sample_t masked_value = value & (-1 << (32 - effp->in_signal.precision));
+  double scaled_value;
+  sox_sample_t rounded_value = value;
 
-  double scaled_value = (double)masked_value / SOX_SAMPLE_MAX;
+  /* before we mask we should round the value */
+  if (effp->in_signal.precision < 32)
+    rounded_value += (1 << (32 - effp->in_signal.precision - 1));
+  rounded_value &= (-1 << (32 - effp->in_signal.precision));
+
+  scaled_value = (double)rounded_value / SOX_SAMPLE_MAX;
 
   if (unit == '%')
     scaled_value *= 100;
======================================================================

:JW

Re: [SoX-devel] Build system cleanup

[Måns Rullgård <mans@ma...>]

Jan Stary <hans@...> writes:

> On Aug 28 10:21:41, mans@... wrote:
>> Jan Stary <hans@...> writes:
>> 
>> > On Aug 27 11:21:58, hans@... wrote:
>> >> Testing on NetBSD 8.0, with the latest commits
>> >> to the new-build branch pulled in.
>> >
>> > With ./configure CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr/pkg/lib
>> > the external libraries are detected, with the exception of png:
>> >
>> > checking for png.h... yes
>> > checking for png_set_rows in -lpng... no
>> >
>> > The problem is that the png library,
>> > as installed by the NetBSD packaging system,
>> > is /usr/pkg/lib/libpng16.so, not /usr/pkg/lib/libpng.so
>> > (the header is /usr/pkg/include/png.h).
>> 
>> 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
>
> That results in
>
> checking for png.h... yes
> checking for png_set_rows in -lpng16... no
>
> $ nm /usr/pkg/lib/libpng16.so | grep png_set_rows
> 000000000001d6f2 T png_set_rows

Then your library search path isn't set right.  If you're hoping to
embark on a two-week argument over the same thing on NetBSD, I'm going
to have to disappoint you.

It works with LIBRARY_PATH=/usr/pkg/lib, and I'm leaving it at that.
If you refuse to use the simple, obvious, and documented solution,
you're on your own.

> ./configure --help says
>
> --with-png              Use png (YES/no/*)
>
> What does the '*' stand for?

It means you can supply an arbitrary name.

> Is there a 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