On 2017-10-25 01:29, Glenn English wrote:
On Tue, Oct 24, 2017 at 7:44 PM, Jeremy Nicoll - ml sox users
<jn.ml.sxu.88@xxxxxxxxxxxxxxxxxxxx> wrote:
I can't answer the question, but I think whoever does will need to
know
more. Are these multiple capabilities needed on different pieces of
audio, but all being processed at the same time?
No, just one hugish (1G++) flac file, processed in several different
ways.
Or do you mean that for one audio source a whole sequence of things
are to be done to it?
Got it :-)
- which seems to me to be one sox command with various effects
coded one afetr another
That's another possibility, but it takes a very long time to cat a
billion little flacs into a single or mp3 it, so I assumed it'd take a
long time to eq or compress the huge flac, so I wanted to do several
things in parallel. That's not a deal killer because this program is
being designed to do the SoX part(s) of the job with no human
intervention. But I'd like to get its job done overnight.
It's either one huge file, or it's not.
I have no idea whether for the effects you wish to use it'd make any
difference whether you apply them to all the small files first, then
concatenate the results, or whether some/all will only work properly
if applied to the huge file.
On Windows, if a script issues
start sox ...
(though such a command tends to look rather more like
start /b "atitle" "c:\x\y\z\sox.exe" arg1 arg2 arg3... )
then that started sox runs in a different process from the one that
the script is running under, and therefore a script could issue a
series of "start sox..." commands at a time. However if, say, it
issued 7 of these (if one had a 4 cpu ie 8 core machine) there'd be
no easy way to find out when each sox command stopped so it was a
good time to start another one.
On the other hand if you divided your umpteen files into, say, 7
lists of files you could have your master script start 7 subsidiary
scripts with "start .. whatever's needed to start that script" and
then each one could issue a sox command, then when that's complete
issue the next one and so on. You might find that 7 sets of sox
commands was too many on an 8 core machine; it depends what else
has to run at the same time.
If I were doing that I would have the subsidiary script create when
it starts a flag file unique to it, then check that file exists each
time it's about to issue another sox command. If not, stop. That
way you can easily stop one set of commands by deleting its flag file.
Scripts I have that do that also delete the unique flagfile when they
stop naturally.
--
Jeremy Nicoll - my opinions are my own
------------------------------------------------------------------------------
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
