Re: Recording specific channels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"I am pretty sure it is not interferring with other processes (such as audio recording) running on the target machine. It would be pretty sad it it did." - if not yet, I highly recommend to read "Everything Is Broken" - https://medium.com/message/everything-is-broken-81e5f33a24e1 . And then spice it up with "OCTOBER 1, 2014; DR. JOSEPH TAINTER: THE COLLAPSE OF COMPLEX SOCIETIES" - https://mcalvanyweeklycommentary.com/october-1-2014-dr-joseph-tainter-the-collapse-of-complex-societies/ .

...

A very interesting and educational thread.

--Sergei.

On 13/05/2024 23:14, Jan Stary wrote:
On May 13 19:50:05, D.Cottle@xxxxxxxx wrote:
[Screen share… ]

I connect to this machine via screen share. I closed the screen share to make sure there was no activity on that machine that might interfere with the recording.
I am pretty sure it is not interferring with other processes
(such as audio recording) running on the target machine.
It would be pretty sad it it did.

But it is another variable to be aware of.
God knows if this "screen share" decides
to send a CTRL^C after five minutes of "inactivity",
killing the SoX process.

BTW, why don't you simply ssh to the machine, being a OSX machine,
i.e. a UNIX machine? Ah, right: because you need the GUI,
running Logic Pro. Another reason to replace that
with a command line tool :-)

[nine years old…]
That’s embarrassing. But it shows we’ve been using it to split up the files without much problem for that long.
SoX is pretty solid when processing audio signals offline
- less so in using the various systems's audio interfaces.
In particular, the OSX audio subsystem is a moving target
and has changed a lot since 2015.

The other complication is that these are university machines, maintained by our tech staff. They already roll their eyes at my shenanigans, playing outside the sandbox. They do give me a lot more freedom than any other faculty member, but this will have to go through them. I’ll ask them to install the update.
What a shame.

It took six minutes to install the latest SoX
on my old mac mini now.

I appreciate all the help. Sorry for being clueless. I’ll be unavailable for the next few weeks, but will revisit after that.
No worries. Your use case seem pretty interesting.

	Jan

5/13/24, 13:31, "Jan Stary" <hans@xxxxxxxx>:

On May 13 17:28:39, D.Cottle@xxxxxxxx wrote:
This one I started then closed the screen share
so there was no other activity.
I am not sure what you mean by "the screen share"
- do you mean /usr/bin/screen? I doubt it has
anything to do with SoX stopping.

It stopped after 5 minutes.
minion-2-recording:~ minion$ ~/sox/rec -V5 -c 8 -b 16 -r 48k /Volumes/CAF3/test77.aif
/Users/minion/sox/rec:      SoX v14.4.2
time:     Feb 22 2015 14:58:07
You SoX is nine years old.
The first thing to try is to use the current version.

How did you install your SoX? Is that a pre-built OSX binary?
The last published version of that is indeed 14.4.2
Build and install from https://sourceforge.net/p/sox/code/ci/master/tree/
and see if the problem persists. I vaguely remember there were problems
in the past with sox finishing prematurely.

uname:    Darwin minion-2-recording 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:17:35 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8112 x86_64
compiler: gcc 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)
Uff.

/Users/minion/sox/rec DBUG coreaudio: audio device did not accept 2 channels. Use 18 channels instead.
/Users/minion/sox/rec DBUG coreaudio: audio device did not accept 44100 sample rate. Use 48000 instead.
This seems stramge too, as you did not tell sox to use two channels,
or to use a 44100 sample rate.

/Users/minion/sox/rec WARN formats: can't set 8 channels; using 18
This is understandable.

Input File     : 'default' (coreaudio)
Channels       : 18
Sample Rate    : 48000
Precision      : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

/Users/minion/sox/rec DBUG aiff: converted 48000 to 100 16 37777777673 37777777600 0 0 0 0 0 0
Looking at the write_ieee_extended() function is src/aif.c,
this seems to be some cleverty of saving an integer,
viewed as a double, in a buffer of ten chars and storing that instead,
reporting the ten bytes as octals:

        lsx_debug_more("converted %g to %o %o %o %o %o %o %o %o %o %o",

It seems that AIF stores the sample rate in this way.

Looking around srcc/aiff.c, there are also
"Machine-independent I/O routines for IEEE floating-point numbers",
(c) Apple 1991. Apparently, SoX needs a maintainer.

Output File    : '/Volumes/CAF3/test77.aif'
Channels       : 8
Sample Rate    : 48000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : big
Reverse Nibbles: no
Reverse Bits   : no
Comment        : 'Processed by SoX'

/Users/minion/sox/rec DBUG effects: sox_add_effect: extending effects table, new size = 8
/Users/minion/sox/rec DBUG remix: 0:
/Users/minion/sox/rec DBUG remix:    0 0.333333
/Users/minion/sox/rec DBUG remix:    8 0.333333
/Users/minion/sox/rec DBUG remix:    16 0.333333
/Users/minion/sox/rec DBUG remix: 1:
/Users/minion/sox/rec DBUG remix:    1 0.333333
/Users/minion/sox/rec DBUG remix:    9 0.333333
/Users/minion/sox/rec DBUG remix:    17 0.333333
/Users/minion/sox/rec DBUG remix: 2:
/Users/minion/sox/rec DBUG remix:    2 0.5
/Users/minion/sox/rec DBUG remix:    10 0.5
/Users/minion/sox/rec DBUG remix: 3:
/Users/minion/sox/rec DBUG remix:    3 0.5
/Users/minion/sox/rec DBUG remix:    11 0.5
/Users/minion/sox/rec DBUG remix: 4:
/Users/minion/sox/rec DBUG remix:    4 0.5
/Users/minion/sox/rec DBUG remix:    12 0.5
/Users/minion/sox/rec DBUG remix: 5:
/Users/minion/sox/rec DBUG remix:    5 0.5
/Users/minion/sox/rec DBUG remix:    13 0.5
/Users/minion/sox/rec DBUG remix: 6:
/Users/minion/sox/rec DBUG remix:    6 0.5
/Users/minion/sox/rec DBUG remix:    14 0.5
/Users/minion/sox/rec DBUG remix: 7:
/Users/minion/sox/rec DBUG remix:    7 0.5
/Users/minion/sox/rec DBUG remix:    15 0.5
This must be how the 18 input channels contribute
to the 8 output channels, in a round-robin fashion, apparently.
Which is probably not what you want: 0 to 15 contribute as
the two channels into 0-8 each, and then 16 and 17, respectively,
are the third contributor to 0 and 1, respectively;
the fractions are most probably the relative volumes.

This could be another SoX bug,
possibly solved during the last nine years :-)

/Users/minion/sox/rec INFO sox: effects chain: input        48000Hz 18 channels (multi) 32 bits unknown length
/Users/minion/sox/rec INFO sox: effects chain: channels     48000Hz  8 channels (multi) 32 bits unknown length
/Users/minion/sox/rec INFO sox: effects chain: dither       48000Hz  8 channels         16 bits unknown length
/Users/minion/sox/rec INFO sox: effects chain: output       48000Hz  8 channels (multi) 16 bits unknown length
/Users/minion/sox/rec DBUG sox: start-up time = 0.103435
In:0.00% 00:05:20.42 [00:00:00.00] Out:15.4M [      |      ]        Clip:0
Done.
Still no idea why Sox stops here.
At any rate, try with the recent version.

Jan


/Users/minion/sox/rec DBUG aiff: converted 48000 to 100 16 37777777673 37777777600 0 0 0 0 0 0
minion-2-recording:~ minion$


5/13/24, 10:55, "Jan Stary" <hans@xxxxxxxx>:

On May 13 15:57:43, D.Cottle@xxxxxxxx wrote:
[* * * * * /Users… ]

This looks promising, and I apologize for my ignorance (I have a bad habit of learning just enough code to do what I need), but it didn’t work for me.

First, just to clarify, my sox folder is in the top level of my users account. I know it should be in the /bin/, but I get a new machine every year and keep forgetting how to move it and get the correct  path (~/.bash_profile?) and don’t want to pester our tech staff to do it, so in the command line I just have to type the extra ~/sox/rec.
The path can be whatever - as long as it is in your $PATH
you can just call 'sox'. You can also specify the PATH at the
beginning you your crontab. (This has nothing to do with sox.)

Second, in this example I don’t understand where the file is
being written to.
Exactly where the command says: /tmp/file-`date +\%s`.wav
Look under /tmp, see the files named file-whatever.

Last, it didn’t create a new file, but just stopped after 1 minute.
Yes - it creates a new one at the beginning of the next minute.

        Jan


PS: Please quote the emails you are replying to properly
and don't top-post. It is customary in tech mailing list
to quote the relevant portion verbatim and comment inline.
Also, please wrap your lines - some pople (me included)
read this in a text terminal. Long lines make it unnecessarily
difficult to quote a bit from one "line" which is in fact
a whole paragraph.




5/13/24, 08:47, "Jan Stary" <hans@xxxxxxxx>:

On May 13 09:26:10, hans@xxxxxxxx wrote:
On May 12 22:56:45, D.Cottle@xxxxxxxx wrote:
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) [...] We routinely combine files
into larger segments and we need them to be seamless.
Ah, right, that's what you mean by "sample perfect". Let's try:

$ sox -n sine.wav synth 10
$ sox sine.wav part%n.wav trim 0 5 : newfile : trim 0 5
$ soxi sine.wav part*.wav

On my machine, that's 480000 split into 240000 + 240000 exactly
when I said 5s out of 10s.
On the contrary, this is not sample perfect:
a line in my crontab, starting a recording of one minute every minute.

* * * * * /Users/hans/bin/rec -q /tmp/file-`date +\%s`.wav trim 0 00:01:00

This does indeed record each minute of audio into
an appropriately named file, but the transition is not seamless
(as verified by playing a song longer than one minute).

But if you change this to record your "predefined blocks"
of a couple of hours, then perhaps overlaping a few samples
will not matter if the seams are at silent times.
Or you could record whole days, restarting at, say, 3 am.

Jan


_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users

[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux