On 2020-11-17 03:07, raymond grote wrote:
Hi Jeremy, You're correct, I didn't give enough information.
I'm using Windows 10. I'm not at a very proficient level with
scripting. I see the potential of it, but am not confident with a
scripting language yet. I'm assuming batch script would be fine for my
needs ...
If you know no other alternative (eg: python, perl etc) and don't
want to install anything else, basic .bat/.cmd scripts might be ok.
If they are only issuing sox commands it should be fine, but if eg
you also want to issue "lame" commands to make mp3 files, and set
tags and have to chop up and recreate modified filenames, you might
need something else. VBS would probably be better than .bat/.cmd
and the cscript.exe/wscript.exe that runs those is part of Windows.
For bat/cmd (and vbs etc) there's excellent information on how to
use the available commands, at
https://ss64.com/
I totally understand what you're saying about making sure the
processing is easy to follow and adjust, rather than trying to make it
run as efficiently as possible. I tend to agree with that mindset, but
I feel like there's a line between an easy-to-follow way, and a way
that's hacked together because you don't understand the basic tools
which make certain things a hundred times easier. I sometimes feel
like I'm on the wrong side of that, So I'm a bit paranoid that I'm
doing things in a stupid way haha
I think you're overthinking this. Everyone has to learn, whether it's
better use of script language, or better use of tools like sox.
One of the reasons I do things in stages is that a script that (say)
applies a certain amount of gain to a set of files will be usable in
the next project that wants a different amount of gain applied to a
different set of files.
The same script can be adapted to do something slightly different, as
it already has all the logic for working through a set of files (and
all the error-checking that I wrap around the overall logic).
Time spent writing "the perfect script" is possibly wasted. What you
need (IMO) is a set of tools that are easy to adapt to new
circumstances.
A simple example follows. Not sure if I'd actually use this, I was
just trying to think of a situation which illustrates my
uncertainties.
Step 1. I have a file called test.wav and I want to pitch shift it.
sox test.wav temp.wav pitch -500
Step 2. Then I should mix the pitch shift copy with the original, and
apply reverb to the mix.
sox -m test.wav temp.wav test_processed.wav reverb
OK, but suppose you get into that habit, of always naming the output
file
"temp.wav"? One day you'll forget and find you overwrote the output
from
another sox command that previously created the same file.
That's an argument for:
- always using the sox command option that prevents any file from
being overwritten; that's the "global option": --no-clobber
- or having scripts always generate result filenames that should not
already exist, verifying that they don't already exist (and to be
careful, also using the sox don't-overwrite option)
Sox command parameters are made up as
[gopts] [[fopts] infile]... [fopts] outfile [effect [effopt]]...
ie global options, then a set of input files each possibly preceded by
options for how they are processed, then the output file (possibly
preceded by its options) followed by effects each of which is possibly
followed by its options. (The "[" and "]" might be in the wrong place
but I knew what /I/ meant.)
I find it easier in scripts that build up commands to have code that
looks
at each potential part of the overall command, maybe contributing
options,
maybe not.
I also tend to name intermediate (or final) output files so once can see
at least something about the process that created them, so if eg one of
the steps in a script was to reverse a stereo image, the file leafname
might have eg "reversed" in it.
File/directory structure should be simple. Basically, the original
file and the _processed version should be in the same folder, at least
for now. Temp.wav is not needed. It would be useful to hear
intermediate results, but assuming I don't need to check those, I
really don't need it.
For /pitch shift/ you might not need it, but for lots of other more
subjective effects you probably will need it. For example if you
experiment with a dozen slight variations in the parameters for a
particular effect, you'll want all the output files to exist so you
can listen to them (or eg run stat or stats effects to check their
levels etc). And then you'll not find names like temp, temp1, temp2
... much use for identifying which one's which.
So my question is twofold. Is it common practice to launch sox once
for some processing and then again for other stuff?
I don't it matters what's common practice or not. What matters is
that you understand what your commands do and how they do them, and
are happy with that.
I know you can chain effects in one sox instance ...
and also pipe stuff between successive calls of sox
If (say) your input files are from some laboratory process so there's
going to be tens of thousands of them and they're alll basically
similar, and you want to do the exact same thing to them all, then
it's maybe worth finding the most efficient way to do it. But in
the initial stages while you experiment and refine what that process
is, I'd say you still want to make life easy for yourself. You want
to be able to glance at a filename and have it tell you what's in
the file.
If on the other hand (like me) you deal with distinct sets of files
- recordings of concerts that then get split into separate files, and
have eg levels measured, gains applied, fades in & out applied, and
then mp3s at various quality settings made with appropriate tags)
then every project is different - the times, lengths, position of
fades, fade parameters, gain settings, format of the tags etc are
different from concert to concert. I'll listen to parts of every
file along the way, so I /have/to create every one of them.
Secondly, is it a good idea to use a temporary output file
on the hard drive as I have done for intermediate processing steps?
I'd say yes, but if you really really don't want to, don't.
Going back to your example, suppose you find out later that the final
file has clipping in it? How do you tell (assuming test.wav was ok)
where that problem came from if you've not got the intermediate files
to listen to?
--
Jeremy Nicoll - my opinions are my own
_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
