On 2024-05-11 17:47, Michael Cottle, (David) wrote:
Thanks for responding.
Reading what you wrote below I realise I made a mistake in what I said
yesterday.
Personally I never use "play" or "rec", so forgot that with "rec" the
options
given only applied to the output file.
(My use of sox, via scripts which build the commands, always spells out
explicitly
which global options I'm using, which input file options, & which output
ones per
output file, so I didn't pay enough attention to what you said. Sorry!)
We are recording 4 spaces of a music building 24/7 using stereo pairs.
There must be more to it than that. Do you stop & restart the process
every n
hours? If not surely every audio file will grow in length continually
until
the end of time.
Depending on how source audio can be fed into separate sox processes, I
might be
inclined to try to capture each hour's audio into a named duration file,
but have
some overlaps. So eg the notionally 3pm-4pm file might end up with
audio from
14:55 through 16:05 in it.
Depending on how you schedule use of your rehearsal rooms etc that might
make it
easier for people to find the stuff they are interested in, and it's
also safer
(from a disk reliability, computer failure, power cuts etc point of
view) to
chop things up into chunks.
Other things (like where the files eventually end up, & how they get
there)
could also be more easily handled, & reliable, if none of the files
concerned
are colossal.
Do you also make backups of the files? How do you manage retention? If
someone assaults someone-else in a rehearsal room (or is accused of it)
do
you keep the audio files for those times?
I’m currently experimenting with a Focusrite Clarett which has 8 analog
and 10
digital inputs.
rec test.aif
Records all 18 channels in order. When I open that in Amadeus Pro it
correctly
recognizes it as 9 stereo channels. (I send test tones to 1 and 3 that
are
beeping at 1 hz and 5 hz). But this creates is more channels than we
need.
rec -c 2 test.aif
Records the first two channels.
So reads ALL the channels you send to sox, but only passes two of them
on.
rec -c 8 test.aif
Records the first 8 channels. I don’t do anything differently to the
interface.
OK
I have then successfully used remix to split up the files into stereo
tracks
(the end goal). I didn’t think remix could be used when recording, just
with
existing files.
I don't think sox distinguishes between data read from existing files,
and data
coming (piped?) from some other process|source.
But I just tried:
rec -c test.aif remix 3 4
And that recorded just tracks 3 and 4, which was my original question.
What is the "-c" for?
I then opened two terminal windows and recorded tracks 1 and 2 using
one instance of sox, then 3 and 4 with the other.
So with 4 pairs you'd need 4 instances of sox listening to the audio
interface & each selecting only a ninth of what it is sending.
Every instance of sox is going (somehow) to have to recognise & skip
over a lot of data. I've no idea how sox does that (& presumably
what it has to do depends on how the various channels' data is
jumbled up in the incoming audio stream).
That also worked, which was likewise my original goal. But now the
question is, am I going about it incorrectly and taxing the system
or sox using remix during the recording process?
I doubt there's much "taxing" involved; it might be different if you
wanted sox to mix together audio from various input channels, and
process those in some way, but you're only selecting specific input
channels & sending them onward.
Nevetheless you're going to have to read all input channels' data
four times, which does sound excessive.
As you said, taking a first stab at the problem & creating just a
file with 8-ch in it first might be sensible.
That first process would read all the data but write out only 8-ch.
The subsequent 4 processes would read the 8-ch file 4 times, but
only write out 2-ch 4 times.
So (if this is right) running sox in parallel in 4 terminals means
18 channels of data from the interface gets read 4 times
2 channels of data are plucked out & written, 4 times
= 72 ch of data get read in total, 8 get written
Whereas creating an 8=ch file then splitting it:
18 channels of data from the interface gets read once
8 channels of that data gets written once
then
8 channels of data get read 4 times
2 channels of data get written 4 times
Total: 18 + 32 = 50 channels' worth of data gets read
16 channels' worth of data gets written
Only measurement (of cpu time etc) will tell you if there's any
significant performance | time difference in these approaches.
However, I'd do the latter. I think your first priority is saving
the incoming audio on disk as simply and reliably as possible. If
that fails (unless it's also saved somewhere else) you have lost it.
I wonder if something like linux's "tee" can make a second copy (on
another disk) of the 8-ch file in parallel with the first. (I used
to work for a bank where transaction data was recorded simultaneously
on hard disks MILES apart, in the hope that if a catastrophe wiped
out one data-centre the other one(s) might be ok. That was in the
1990s .. so what is matter-of-fact now was very unusual then.)
Once one has the 8-ch file (& maybe a safety copy, which could
certainly be made just after each original 8-ch file one was
complete, if not in parallel at the time), THEN I'd think about
doing the splitting up.
--
Jeremy Nicoll - my opinions are my own
_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
