[Note: some of this is answered in my response to Jan, how we record and split things up.]
Overlaps would be too much work. We often don’t know what files someone will need. The whole point of being 24/7. If someone needs files from 1:35 to 3:15 we just give them 1 to 4. They combine them (with
no seam at 2pm) then edit down to what they need. We routinely combine files into larger segments and we need them to be seamless. That is, I think that would be easier. I guess we could overlap every hour by 5 minutes. But then a movement that starts at 3:45
and goes to 4:15 means we would have to do some detailed edit to get the whole movement. (Again, we don’t always know when people will use it. That’s the whole point.) Our way, you join the files, drop markers at mvts and split the file using Amadeus Pro.
Very easy.
We’ve considered a text driven system. People text an account, the script extracts the information, it starts and stops. We’ve also considered reading calendar data and using that. Just haven’t done it yet.
24/7 (sledge hammer) is better. It just goes. Patrons don’t have to schedule, ask, or check. It just always works. If I get an email asking to record something, I wouldn’t even have to read it (though I do). Or did I record something last Tuesday? Of course
we did. As I said earlier, I’ve gotten requests for lost sessions (done with their own equipment, not ours) from 5 years back after they lost their files. I pulled a full season of concerts with a local orchestra because there was a miscommunication with our
office (we thought they were using their own engineer, they thought we were recording it). I just went back and grabbed them all. Once a year I get a request that starts “my mother gave a masterclass in 2014, I don’t suppose…” We usually have it, even if someone
just walks in and plays for a while.
Colossal files: we just buy hard drives. They are cheap. We record to an external 1T drive (so as not to clog up the OS), then move immediately to a 4T drive for the AIFs (so as not to clog up THAT drive),
then compress to mp3 to another 4T drive after two months. Then we put it on a shelf. Also, we have two completely redundant systems so if one crashes the other captures it.
It is, in fact, a security system. Not much different from all the cameras we have for security. FWIW, we got a lot of grumbling from a few faculty when we started it, but these days there are 30+ recording
devices in every classroom, so if anything I’ll come to their rescue when they are accused of saying something they didn’t.
5/12/24, 04:48, "Jeremy Nicoll - ml sox users" <jn.ml.sxu.88@xxxxxxxxxxxxxxxxxxxx>:
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
|
