Fwd: Recording specific channels

-------- Forwarded Message --------
Subject: 	Re: [SoX-users] Recording specific channels
Date: 	Tue, 14 May 2024 00:33:31 +0300
From: 	Sergei Steshenko <[email protected]>
To: 	Jan Stary <[email protected]>



"This is a SoX mailing list. Keep it that way." - well, then this: "How 
can I tell in Linux which process sent my process a signal 
<https://stackoverflow.com/questions/8400530/how-can-i-tell-in-linux-which-process-sent-my-process-a-signal>" 
- 
https://stackoverflow.com/questions/8400530/how-can-i-tell-in-linux-which-process-sent-my-process-a-signal 
might be useful to find out what causes SoX to terminate. But 
implementing this would require change in SoX source code.

..

What I sent is not FUD. I have no fear, I am certain the things are 
happening the way they are described in the texts, and I have no doubt 
the collapse due to complexity and growing incompetence in various 
fields will happen. For example, I saw negative results of bad SW 
architecture in the medical sector.

--Sergei.

On 13/05/2024 23:48, Jan Stary wrote:
> I have no illusions about software in general,
> but what you link is a definition of FUD.
>
> This is a SoX mailing list.
> Keep it that way.
>
> 	Jan
>
>
> On May 13 23:40:56,[email protected]  wrote:
>> "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,[email protected]   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"<[email protected]>:
>>>>
>>>> On May 13 17:28:39,[email protected]   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 fromhttps://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"<[email protected]>:
>>>>>
>>>>> On May 13 15:57:43,[email protected]   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"<[email protected]>:
>>>>>>
>>>>>> On May 13 09:26:10,[email protected]   wrote:
>>>>>>> On May 12 22:56:45,[email protected]   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
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/sox-users
>> _______________________________________________
>> Sox-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sox-users

_______________________________________________
Sox-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sox-users