Re: Recording specific channels

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sox-users