which is better / more effective

which is better / more effective

[Glenn English]

I'm getting ready to ask sox to do several things: EQ, compression,
normalization, speed change, etc. I see on the web, suggestions of
several different ways to do this: make one call to sox with several
switches, make several calls to sox with one switch, or pipe those
several calls together.

Which of these works best? Does it matter? Does sox just figure all
this out and fork several times if it needs to? (multi-core CPU and
lots of RAM on Debian Linux, and the file is ~1G FLAC, if any of that
makes any difference)

--
Glenn English

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: which is better / more effective

[James Trammell]

[-- Attachment #1.1: Type: text/plain, Size: 1793 bytes --]

Hi,

Myself being new to SoX and unfamiliar with the code, my advice would be to
try all three ways, then run a few tests to find any bad behavior. Trust,
but verify.

file A = one call with several switches.
file B = several calls with one switch.
file C = several calls with one switch, piped together.

Null test

Invert the phase of B, combine with A, listen for problems.
Invert the phase of C, combine with A, listen for problems.
Invert the phase of C, combine with B, listen for problems.

Spectrograph

I would also load files A, B and C into spectrograph software to see what
information is present at the very bottom bits of the bit depth.

Try the conversions without dither to see if the spectrographs show
different levels of truncation noise.

-James




On Sat, Nov 25, 2017 at 1:50 PM, Glenn English <ghe2001@gmail.com> wrote:

> I'm getting ready to ask sox to do several things: EQ, compression,
> normalization, speed change, etc. I see on the web, suggestions of
> several different ways to do this: make one call to sox with several
> switches, make several calls to sox with one switch, or pipe those
> several calls together.
>
> Which of these works best? Does it matter? Does sox just figure all
> this out and fork several times if it needs to? (multi-core CPU and
> lots of RAM on Debian Linux, and the file is ~1G FLAC, if any of that
> makes any difference)
>
> --
> Glenn English
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

[-- Attachment #1.2: Type: text/html, Size: 2702 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: which is better / more effective

[Måns Rullgård]

James Trammell <james.trammell@gmail.com> writes:

> Hi,
>
> Myself being new to SoX and unfamiliar with the code, my advice would be to
> try all three ways, then run a few tests to find any bad behavior. Trust,
> but verify.
>
> file A = one call with several switches.
> file B = several calls with one switch.
> file C = several calls with one switch, piped together.
>
> Null test
>
> Invert the phase of B, combine with A, listen for problems.
> Invert the phase of C, combine with A, listen for problems.
> Invert the phase of C, combine with B, listen for problems.
>
> Spectrograph
>
> I would also load files A, B and C into spectrograph software to see what
> information is present at the very bottom bits of the bit depth.
>
> Try the conversions without dither to see if the spectrographs show
> different levels of truncation noise.

Before going to all that trouble, just compare the three files and see
if they differ at all.  If the output precision is less than 24 bits, it
will have dither automatically applied (unless disabled with the -D flag),
so for such a test the -R flag should be used to select a fixed seed for
the dither RNG.

-- 
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-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: which is better / more effective

[Måns Rullgård]

Glenn English <ghe2001@gmail.com> writes:

> I'm getting ready to ask sox to do several things: EQ, compression,
> normalization, speed change, etc. I see on the web, suggestions of
> several different ways to do this: make one call to sox with several
> switches, make several calls to sox with one switch, or pipe those
> several calls together.
>
> Which of these works best? Does it matter? Does sox just figure all
> this out and fork several times if it needs to? (multi-core CPU and
> lots of RAM on Debian Linux, and the file is ~1G FLAC, if any of that
> makes any difference)

Sox has very limited support for multi-processing built-in, and it
doesn't work very well.  For a long effects chain, you'll get better
throughput by piping multiple processes.

If you have a single command like this:

  sox in.flac out.flac effect1 effect2 effect3

it can be split up like this:

  sox in.flac -p effect1 | sox -p -p effect2 | sox -p out.flac effect3

The end result should be exactly the same.

It probably doesn't make sense to put light-weight effects in a separate
command as the extra inter-process copying could easily negate any
gains.

-- 
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-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: which is better / more effective

[Glenn English]

On Sun, Nov 26, 2017 at 12:36 PM, Måns Rullgård <mans@mansr.com> wrote:

> Sox has very limited support for multi-processing built-in, and it
> doesn't work very well.  For a long effects chain, you'll get better
> throughput by piping multiple processes.
>
> If you have a single command like this:
>
>   sox in.flac out.flac effect1 effect2 effect3
>
> it can be split up like this:
>
>   sox in.flac -p effect1 | sox -p -p effect2 | sox -p out.flac effect3
>
> The end result should be exactly the same.
>
> It probably doesn't make sense to put light-weight effects in a separate
> command as the extra inter-process copying could easily negate any
> gains.

Thank you. The pipes seemed the simplest way (the way my program is
being written), but sox is pretty new to me...

--
Glenn English

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users