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
