You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(21) |
Oct
(24) |
Nov
(11) |
Dec
(18) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(6) |
Feb
(4) |
Mar
(37) |
Apr
(12) |
May
(17) |
Jun
(17) |
Jul
(8) |
Aug
(5) |
Sep
(29) |
Oct
(18) |
Nov
(22) |
Dec
(41) |
2002 |
Jan
(31) |
Feb
(42) |
Mar
(41) |
Apr
(34) |
May
(12) |
Jun
(25) |
Jul
(23) |
Aug
(10) |
Sep
(20) |
Oct
(15) |
Nov
(25) |
Dec
(16) |
2003 |
Jan
(56) |
Feb
(30) |
Mar
(33) |
Apr
(13) |
May
(21) |
Jun
(6) |
Jul
(15) |
Aug
(6) |
Sep
(6) |
Oct
(14) |
Nov
(2) |
Dec
(15) |
2004 |
Jan
(28) |
Feb
(19) |
Mar
(7) |
Apr
(10) |
May
(9) |
Jun
(12) |
Jul
(15) |
Aug
(62) |
Sep
(45) |
Oct
(50) |
Nov
(45) |
Dec
(36) |
2005 |
Jan
(18) |
Feb
(17) |
Mar
(20) |
Apr
(18) |
May
(16) |
Jun
(15) |
Jul
(27) |
Aug
(27) |
Sep
(42) |
Oct
(24) |
Nov
(32) |
Dec
(21) |
2006 |
Jan
(22) |
Feb
(32) |
Mar
(32) |
Apr
(24) |
May
(18) |
Jun
(33) |
Jul
(8) |
Aug
(33) |
Sep
(22) |
Oct
(31) |
Nov
(33) |
Dec
(26) |
2007 |
Jan
(17) |
Feb
(55) |
Mar
(30) |
Apr
(10) |
May
(36) |
Jun
(33) |
Jul
(20) |
Aug
(12) |
Sep
(96) |
Oct
(27) |
Nov
(40) |
Dec
(31) |
2008 |
Jan
(71) |
Feb
(45) |
Mar
(61) |
Apr
(6) |
May
(18) |
Jun
(17) |
Jul
(14) |
Aug
(66) |
Sep
(49) |
Oct
(92) |
Nov
(57) |
Dec
(68) |
2009 |
Jan
(68) |
Feb
(52) |
Mar
(56) |
Apr
(65) |
May
(58) |
Jun
(38) |
Jul
(24) |
Aug
(75) |
Sep
(41) |
Oct
(98) |
Nov
(55) |
Dec
(107) |
2010 |
Jan
(66) |
Feb
(64) |
Mar
(45) |
Apr
(32) |
May
(90) |
Jun
(53) |
Jul
(39) |
Aug
(51) |
Sep
(102) |
Oct
(31) |
Nov
(30) |
Dec
(32) |
2011 |
Jan
(26) |
Feb
(65) |
Mar
(69) |
Apr
(35) |
May
(116) |
Jun
(23) |
Jul
(24) |
Aug
(32) |
Sep
(95) |
Oct
(60) |
Nov
(95) |
Dec
(89) |
2012 |
Jan
(139) |
Feb
(75) |
Mar
(88) |
Apr
(46) |
May
(58) |
Jun
(51) |
Jul
(95) |
Aug
(24) |
Sep
(33) |
Oct
(12) |
Nov
(18) |
Dec
(45) |
2013 |
Jan
(84) |
Feb
(56) |
Mar
(54) |
Apr
(24) |
May
(20) |
Jun
(16) |
Jul
(51) |
Aug
(75) |
Sep
(41) |
Oct
(45) |
Nov
(96) |
Dec
(38) |
2014 |
Jan
(42) |
Feb
(33) |
Mar
(47) |
Apr
(9) |
May
(50) |
Jun
(24) |
Jul
(17) |
Aug
(4) |
Sep
(10) |
Oct
(41) |
Nov
(20) |
Dec
(64) |
2015 |
Jan
(41) |
Feb
(43) |
Mar
(20) |
Apr
(14) |
May
(44) |
Jun
(34) |
Jul
(55) |
Aug
(20) |
Sep
(9) |
Oct
(10) |
Nov
(6) |
Dec
(40) |
2016 |
Jan
(17) |
Feb
(31) |
Mar
(27) |
Apr
|
May
(2) |
Jun
(19) |
Jul
(7) |
Aug
(27) |
Sep
(79) |
Oct
(4) |
Nov
(14) |
Dec
(146) |
2017 |
Jan
(7) |
Feb
(6) |
Mar
(14) |
Apr
(5) |
May
(7) |
Jun
(49) |
Jul
(27) |
Aug
(27) |
Sep
(28) |
Oct
(28) |
Nov
(26) |
Dec
(9) |
2018 |
Jan
|
Feb
(5) |
Mar
(6) |
Apr
(11) |
May
(9) |
Jun
(5) |
Jul
(14) |
Aug
(1) |
Sep
(13) |
Oct
(2) |
Nov
(3) |
Dec
(5) |
2019 |
Jan
(8) |
Feb
(8) |
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(13) |
Nov
(4) |
Dec
(29) |
2020 |
Jan
(3) |
Feb
|
Mar
(12) |
Apr
(8) |
May
(36) |
Jun
(26) |
Jul
(27) |
Aug
(30) |
Sep
(2) |
Oct
|
Nov
(12) |
Dec
(2) |
2021 |
Jan
(4) |
Feb
(9) |
Mar
(4) |
Apr
(18) |
May
(21) |
Jun
(19) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(16) |
Nov
(4) |
Dec
(2) |
2022 |
Jan
(5) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(5) |
Dec
|
2023 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
(16) |
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
(7) |
Nov
(3) |
Dec
(2) |
2024 |
Jan
(9) |
Feb
|
Mar
(3) |
Apr
(14) |
May
(38) |
Jun
(15) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jan S. <ha...@st...> - 2024-05-12 15:24:22
|
On May 11 10:50:14, jn....@wi... wrote: > On 2024-05-10 23:56, Michael Cottle, (David) wrote: > > I need to record specific channels from a multi-channel interface. > I would GUESS that how you do this depends on whether the audio interface(s) > always send all channels of audio, or only those you choose on the inteface > itself. Is anyone aware of an audio interface that lets you choose which channel it sends? I have only seem sound cards that always send everything. > Then the file (or stream) of audio might contain header info saying (to sox) > how many channels of data are being sent. Or it might not in which case you > would HAVE TO TELL sox what is coming in. Again, is anyone aware of a sound interface that sends something else than the raw audio data (as expected)? I haven;t seen anything that would send, say, a wav file. (How would the length possibly be right in the header that comes first, for example?) On May 11 16:47:55, D.C...@ut... wrote: > We are recording 4 spaces of a music building 24/7 using stereo pairs. Surely you are cutting these at some point (midnight?), chunking the 24/7 into some managable recordings. > Logic is just a shell we use (because it has a nice interface) > to write the CAF files, then we use SoX to split them up every hour. But it's not one endless CAF file, right? So what exactly is Logic Pro writing? > We also use SoX to discard silent files. Does that mean you always record everything, even the silence in the rooms where nothing happens? > The problem is, Logic can be flakey, so we are investigating > SoX as the recording device also. You said you use Logic for its nice interface? In what way is Logic's interfaces nicer that SoX's? > I think I solved my initial issue: > 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. Whether that is "right" depends of course: if I record 6 channels of drums, 6 of vocals and 6 of the horn section, showing those 18 mono channels as 9 stereo channels isn't "right". > rec -c 2 test.aif > Records the first two channels. > rec -c 8 test.aif > Records the first 8 channels. I believe SoX gets all 18 when reading from the audio device, but only uses the first -c N to create the N-channel output. > 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. But I just tried: > rec -c test.aif remix 3 4 > And that recorded just tracks 3 and 4, which was my original question. That is not a valid SoX command line. Do you mean "rec -c 2 test.aif remix 3 4" ? > I then opened two terminal windows and recorded > tracks 1 and 2 using one instance of sox, then 3 and 4 with the other. "Then"? So you missed channels 3 and 4 while recording 1 and 2 - but you want to be recording all of 1-8 all the time, right? > 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? > It is handy to have all the separate CAF files as stereo pairs > (for each room), but would it be more efficient to record all 8 channels > to a single file, then split them up using SoX and remix? Read about remix in the SoX manpage. You simply specify the contributing channels. I would just record 1-8 into one file, with one SoX instance, as that is what you want to have anyway, and split into 1-2, 3-4 etc offline later. Would SoX even have the device available four times simultaneously, if you ran the four instances? You need to write eight channels of audio. I don't think it is more "taxing" to write one 8ch file instead of writing four 2ch files (each discarding 6 channels of input). On the contrary, it is more simple, while the amount of writing work is the same. You might want to look into OpenBSD's superb "sndio" subsystem and its native "aucat" tool, which can split an audio device into subdevices by channels. > 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. A triviality with https://man.openbsd.org/aucat Jan |
From: Jeremy N. - ml s. u. <jn....@wi...> - 2024-05-12 10:48:06
|
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 |
From: Michael C. (David) <D.C...@ut...> - 2024-05-11 16:48:22
|
Thanks for responding. It might be helpful to describe our goals. We are recording 4 spaces of a music building 24/7 using stereo pairs. These files are then used by students, faculty, or staff to listen to rehearsals, create audition materials, or edit concerts. We’ve been doing this for nearly 12 years (using Audio Companion, Amadeus Pro, but currently Logic Pro). Logic is just a shell we use (because it has a nice interface) to write the CAF files, then we use SoX to split them up every hour. We also use SoX to discard silent files. The problem is, Logic can be flakey, so we are investigating SoX as the recording device also. I think I solved my initial issue: 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. rec -c 8 test.aif Records the first 8 channels. I don’t do anything differently to the interface. 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. But I just tried: rec -c test.aif remix 3 4 And that recorded just tracks 3 and 4, which was my original question. I then opened two terminal windows and recorded tracks 1 and 2 using one instance of sox, then 3 and 4 with the other. 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? It is handy to have all the separate CAF files as stereo pairs (for each room), but would it be more efficient to record all 8 channels to a single file, then split them up using SoX and remix? 5/11/24, 04:33, "Jeremy Nicoll - ml sox users" <jn....@wi...>: On 2024-05-10 23:56, Michael Cottle, (David) wrote: > I need to record specific channels from a multi-channel interface. I would GUESS that how you do this depends on whether the audio interface(s) always send all channels of audio, or only those you choose on the inteface itself. Then the file (or stream) of audio might contain header info saying (to sox) how many channels of data are being sent. Or it might not in which case you would HAVE TO TELL sox what is coming in. According to the so manual, sox can be told via -c n eg -c 4 that the incoming audio contains that number of channels ... so your example of -c 2 doesn't seem right to me unless the interface was ONLY SENDING 2 channels of audio. If eg you have an 8 channel interface configured only to send 5 channels I've no idea whether sox would know there's 5, or know there could have been 8, or be sent 8, 3 of which are silent, or have no idea at all. Presumably the manuals for the interfaces will tell you... Alternatively you could use soxi to find out what is in the file according to its headers. If sox is being sent, say, 5 channels of audio, you use the "remix" effect to map selected input channels onto the desired output channels. -- Jeremy Nicoll - my opinions are my own _______________________________________________ Sox-users mailing list Sox...@li... https://lists.sourceforge.net/lists/listinfo/sox-users |
From: Jeremy N. - ml s. u. <jn....@wi...> - 2024-05-11 10:33:01
|
On 2024-05-10 23:56, Michael Cottle, (David) wrote: > I need to record specific channels from a multi-channel interface. I would GUESS that how you do this depends on whether the audio interface(s) always send all channels of audio, or only those you choose on the inteface itself. Then the file (or stream) of audio might contain header info saying (to sox) how many channels of data are being sent. Or it might not in which case you would HAVE TO TELL sox what is coming in. According to the so manual, sox can be told via -c n eg -c 4 that the incoming audio contains that number of channels ... so your example of -c 2 doesn't seem right to me unless the interface was ONLY SENDING 2 channels of audio. If eg you have an 8 channel interface configured only to send 5 channels I've no idea whether sox would know there's 5, or know there could have been 8, or be sent 8, 3 of which are silent, or have no idea at all. Presumably the manuals for the interfaces will tell you... Alternatively you could use soxi to find out what is in the file according to its headers. If sox is being sent, say, 5 channels of audio, you use the "remix" effect to map selected input channels onto the desired output channels. -- Jeremy Nicoll - my opinions are my own |
From: Michael C. (David) <D.C...@ut...> - 2024-05-10 23:13:17
|
Hi, I apologize if this is the incorrect forum for a basic question. I’ve spent about two hours searching for an answer. I need to record specific channels from a multi-channel interface. (Several versions of Scarlett and Focusrite preamps). I can record all channels using rec test.aif, and I can record the first two channels with rec -c 2 test.aif. But I don’t see how to record channels 3 and 4. I’m on OS X (therefore Terminal, Unix). I’ve tried hw:n,n, as suggested on some sites, but I don’t know what those numbers mean, and it returns an error. |
From: Måns R. <ma...@ma...> - 2024-04-24 08:24:13
|
Jeremy Nicoll - ml sox users <jn....@wi...> writes: > On 2024-04-23 08:58, Rodolfo Medina wrote: > >> and observe, >> or hear, > > When you say "observe" what do you mean? > > Are you visually comparing waveforms in some GUI tool? > > If you /randomly/ play one or other of each of the channels' files can you > tell which is which without already knowing? > > (You might be able to do that with a script that picks one or other at > random, The madplay package comes with a nice script for this called abxtext. -- Måns Rullgård |
From: Rodolfo M. <rod...@gm...> - 2024-04-23 21:03:36
|
Jeremy Nicoll - ml sox users <jn....@wi...> writes: [...] Thanks, Jeremy and Jan, in the next couple of days I'll be working on it and then report here. Cheers, Rodolfo |
From: Jeremy N. - ml s. u. <jn....@wi...> - 2024-04-23 20:04:02
|
On 2024-04-23 08:58, Rodolfo Medina wrote: > Now, using sox I split each of them in four single channels So... you've now got eight single-channel files? > and observe, > or hear, When you say "observe" what do you mean? Are you visually comparing waveforms in some GUI tool? If you /randomly/ play one or other of each of the channels' files can you tell which is which without already knowing? (You might be able to do that with a script that picks one or other at random, o, if you can't program a suitable script, make lots of differently-named shortcuts to one or other file & double-click those), put them all in a single folder away from the source files, then click lots of shortcuts paying as little attention to their names as possible, then note which source you thought each was, then work out afterwards if you were right or not.) > that in the first method those single channels are better separate: What do you mean? Nothing in what you've described should have mixed any of the sounds of one channel with any other. They should all be "equally separate". When listening to one of them there should be no other sound being played that would (possibly) be muddled with it. One cannot judge "separation" of a MONO sound. > I can > say so because one of my microphones is an ugly 6-dollar bad thing I > bought > just for experiment and I can recognize it: it's a sensation but very > clear > but difficult here to explain: OK, it sounds poor. We get that it won't sound as good as the same source sound made directly in front of some other mic (assuming the mics are all somewhat directional). > however pacat alerts us with its message: > > Warning: failed to write channel map to file. > > so the second methods is not good unless we manage to eliminate that > message, Who knows what it means? If it's just a list that says that the original three or four sources are placed in the file in such-and-such an order (eg source channels 1 2 3 4 are in the file in order 2 4 1 3) it should have nothing to do with sound quality, especially after sox has extracted the channels to separate mono files. I think you should run the "stat" & "stats" effects against all eight of the single-channel files. You might find that one set of four are all louder than the other set (which could easily make the louder ones seem clearer, or "better separated"). -- Jeremy Nicoll - my opinions are my own |
From: Jan S. <ha...@st...> - 2024-04-23 11:35:53
|
On Apr 23 07:58:33, rod...@gm... wrote: > Jan Stary <ha...@st...> writes: > > >> $ pacat --record -d > >> alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 > >> --channel-map=aux0,aux1,aux2,aux3 --file-format=wav dump.wav > >> > >> Warning: failed to write channel map to file. > >> > >> and in fact the resulting file seems not to be as accurate as the one I get > >> creating first the raw file and then converting it to wav via sox. > > > > In what way is the converted file more "accurate"? > > We have now two different methods to produce the wav 4-channel audio file: the > first we call output2.wav we got with: > > $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 > dump2.raw > > $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 4 dump2.raw output2.wav > > and the second we call dump.wav simply with: > > $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 --file-format=wav dump.wav Do you know that what pacat produces is actualy 16bit unsigned integers at 44100? If so, why don't you say so explicitly, leaving that as an artifact, when you need to rely on that later? > Now, using sox I split each of them in four single channels and observe, > or hear, that in the first method those single channels are better separate: > I can say so because one of my microphones is an ugly 6-dollar bad thing > I bought just for experiment and I can recognize it: it's a sensation > but very clear but difficult here to explain: Neither SoX nor pacat have no relation over to microphone. They are fed a sequence of numbers, whatever the numbers are, Also, your (converted) output2.wav and the (recorded) dump.wav are two different recordings of two different signals. There is nothing to compare here. > however pacat alerts us with its message: > Warning: failed to write channel map to file. I very much doubt that has anything to do with your "unexplaineble sensation", but let's try: what exactly does that message mean? What is a channel map? Did SoX write the channel map into the wav file? > so the second methods is not good unless we manage to eliminate that message, > but the first method seems very good with just one step more. I don't use pacat, but I assure you it does exactly the same thing when it records a wav file as when it records a raw file, besides slaping some 44 bytes of a header onto it. Similarly, SoX does nothing with the actual audio data when converting the raw file into a wav file, or when separating the channels: the extracted channel is exactly the same sequence of numbers. At any rate, you have your answer: yes, sox will convert to any target format, if you know what the source format is. |
From: Rodolfo M. <rod...@gm...> - 2024-04-23 07:58:50
|
Jan Stary <ha...@st...> writes: >> $ pacat --record -d >> alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 >> --channel-map=aux0,aux1,aux2,aux3 --file-format=wav dump.wav >> >> Warning: failed to write channel map to file. >> >> and in fact the resulting file seems not to be as accurate as the one I get >> creating first the raw file and then converting it to wav via sox. > > In what way is the converted file more "accurate"? We have now two different methods to produce the wav 4-channel audio file: the first we call output2.wav we got with: $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 > dump2.raw $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 4 dump2.raw output2.wav and the second we call dump.wav simply with: $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 --file-format=wav dump.wav Now, using sox I split each of them in four single channels and observe, or hear, that in the first method those single channels are better separate: I can say so because one of my microphones is an ugly 6-dollar bad thing I bought just for experiment and I can recognize it: it's a sensation but very clear but difficult here to explain: however pacat alerts us with its message: Warning: failed to write channel map to file. so the second methods is not good unless we manage to eliminate that message, but the first method seems very good with just one step more. Thanks, Rodolfo |
From: Jan S. <ha...@st...> - 2024-04-23 06:08:07
|
> $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 --file-format=wav dump.wav > > Warning: failed to write channel map to file. > > and in fact the resulting file seems not to be as accurate as the one I get > creating first the raw file and then converting it to wav via sox. In what way is the converted file more "accurate"? |
From: Rodolfo M. <rod...@gm...> - 2024-04-22 17:46:36
|
Jan Stary <ha...@st...> writes: > On Apr 22 12:43:51, rod...@gm... wrote: >> >> I suppose I copied/pasted that stuff from somewhere. >> > [...] > > OK, that's your first problem: don't "copy commands from somewhere." > Read the manual of your tool, pacat(1) in this case, > and use that appropriately. > > In particular, pacat/parec seems to be able to record a wav file, > in which case you are creating your own problem for no reason. Thanks: my main problem was the multichannel structure, not the conversion itself. Reading the manual as you suggest, I did: $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 --file-format=wav dump.wav and pacat performs the record but complains: Warning: failed to write channel map to file. and in fact the resulting file seems not to be as accurate as the one I get creating first the raw file and then converting it to wav via sox. Thanks for your help, Rodolfo |
From: Jan S. <ha...@st...> - 2024-04-22 14:02:24
|
On Apr 22 12:43:51, rod...@gm... wrote: > Jan Stary <ha...@st...> writes: > > > That still does not specify the smaple rate and the encoding. > > Repeat the questions: > > > > Why don't you specify the format explicitly? > > I suppose I copied/pasted that stuff from somewhere. > > > Why do you record multichannel input into a raw file? > > As above. OK, that's your first problem: don't "copy commands from somewhere." Read the manual of your tool, pacat(1) in this case, and use that appropriately. In particular, pacat/parec seems to be able to record a wav file, in which case you are creating your own problem for no reason. > >> and then sox: > >> $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 4 dump2.raw output2.wav > >> This way it seems to work. Do you tink it's correct? > > > > How would anyone but you know? > > Is the recording's sample rate actualy 44100? > > Is the encoding actualy signed 16bit integers? > > If so, why don't you say that explicitly in your pacat command? > > Mmmmhh... Are you actualy trolling or what? If this is your answer (for the third time), I give up trying to help you. |
From: Rodolfo M. <rod...@gm...> - 2024-04-22 12:44:10
|
Jan Stary <ha...@st...> writes: > That still does not specify the smaple rate and the encoding. > Repeat the questions: > > Why don't you specify the format explicitly? I suppose I copied/pasted that stuff from somewhere. > Why do you record multichannel input into a raw file? As above. >> and then sox: >> $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 4 dump2.raw output2.wav >> This way it seems to work. Do you tink it's correct? > > How would anyone but you know? > Is the recording's sample rate actualy 44100? > Is the encoding actualy signed 16bit integers? > If so, why don't you say that explicitly in your pacat command? Mmmmhh... >> ...number 4 is due to the fact that Behringer UMC404HD is a four-channel >> audio interface. > > The -c 4 tells SoX that dump2.raw is a 4 channel file. > By then, the Behringer has nothing to do with it. But dump2.raw is 4-channel because pacat created so and pacat created so because I told it to and I told it to because Behringer is 4-channels. Thanks, Rodolfo |
From: Jan S. <ha...@st...> - 2024-04-22 11:47:47
|
On Apr 22 10:55:46, rod...@gm... wrote: > Rodolfo Medina <rod...@gm...> writes: > > > I'm converting to wav format a raw file that comes from this: > > > > $ pacat --record -d > > alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 > dump.raw > > > > because it's the result of a three-microphone live recording using my > > four-channel Behringer audio interface. I expect the result to be a > > three-channel file: what will the right sox command be? The following: > > > > $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 2 dump.raw output.wav > > > > produces a two-channel file: please help. Instead, if I record with: > > > > $ sox -t alsa hw:2,0 output.wav > > > > I get a four-channel file. But I'd prefer using pacat. Please help. Thanks. > > Sorry, it was a pacat problem, not sox's: the proper syntax for the pacat > command is: > > $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 > dump2.raw That still does not specify the smaple rate and the encoding. Repeat the questions: Why don't you specify the format explicitly? Why do you record multichannel input into a raw file? > and then sox: > $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 4 dump2.raw output2.wav > This way it seems to work. Do you tink it's correct? How would anyone but you know? Is the recording's sample rate actualy 44100? Is the encoding actualy signed 16bit integers? If so, why don't you say that explicitly in your pacat command? > ...number 4 is due to the fact that Behringer UMC404HD is a four-channel audio > interface. The -c 4 tells SoX that dump2.raw is a 4 channel file. By then, the Behringer has nothing to do with it. Jan |
From: Rodolfo M. <rod...@gm...> - 2024-04-22 11:03:03
|
Rodolfo Medina <rod...@gm...> writes: > Rodolfo Medina <rod...@gm...> writes: > >> I'm converting to wav format a raw file that comes from this: >> >> $ pacat --record -d >> alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 > dump.raw >> >> because it's the result of a three-microphone live recording using my >> four-channel Behringer audio interface. I expect the result to be a >> three-channel file: what will the right sox command be? The following: >> >> $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 2 dump.raw output.wav >> >> produces a two-channel file: please help. Instead, if I record with: >> >> $ sox -t alsa hw:2,0 output.wav >> >> I get a four-channel file. But I'd prefer using pacat. Please help. >> Thanks. > > > Sorry, it was a pacat problem, not sox's: the proper syntax for the pacat > command is: > > $ pacat --record -d > alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 > --channel-map=aux0,aux1,aux2,aux3 > dump2.raw > > and then sox: > > $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 4 dump2.raw output2.wav > > This way it seems to work. Do you tink it's correct? ...number 4 is due to the fact that Behringer UMC404HD is a four-channel audio interface. Rodolfo |
From: Rodolfo M. <rod...@gm...> - 2024-04-22 10:56:05
|
Rodolfo Medina <rod...@gm...> writes: > I'm converting to wav format a raw file that comes from this: > > $ pacat --record -d > alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 > dump.raw > > because it's the result of a three-microphone live recording using my > four-channel Behringer audio interface. I expect the result to be a > three-channel file: what will the right sox command be? The following: > > $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 2 dump.raw output.wav > > produces a two-channel file: please help. Instead, if I record with: > > $ sox -t alsa hw:2,0 output.wav > > I get a four-channel file. But I'd prefer using pacat. Please help. Thanks. Sorry, it was a pacat problem, not sox's: the proper syntax for the pacat command is: $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 --channels=4 --channel-map=aux0,aux1,aux2,aux3 > dump2.raw and then sox: $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 4 dump2.raw output2.wav This way it seems to work. Do you tink it's correct? Thanks, Rodolfo |
From: Jan S. <ha...@st...> - 2024-04-22 10:51:58
|
On Apr 21 20:45:20, rod...@gm... wrote: > I'm converting to wav format a raw file that comes from this: > $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 > dump.raw Do you know what format the Behringer uses, and what format pacat uses when writing the raw file? If so, just pass that as an input format to sox, and convert to whatever you want. > because it's the result of a three-microphone live recording using my > four-channel Behringer audio interface. I expect the result to be a > three-channel file: Why do you expect that? Why don't you specify any format when recording? Why are you recording three streams into a raw file in the first place? > what will the right sox command be? sox -t raw -r ... -e ... -b ... -c ... file.raw file.wav (putting in the actual values of course) > The following: > $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 2 dump.raw output.wav > produces a two-channel file: please help. You are telling SoX that the raw input is a two channel file. Why? (Given that, SoX also produces a two channel wav output, as expected.) > Instead, if I record with: > $ sox -t alsa hw:2,0 output.wav > I get a four-channel file. Recording on a four track device, you get a four channel wav file. Isn't that what you want? > But I'd prefer using pacat. Why? It is quite possible that the raw file pacat has produced is actualy a four channel file. But why don't you specify the output format explicitly, and why don't you record a wav file to begin with, if that's what you want? Jan |
From: Rodolfo M. <rod...@gm...> - 2024-04-21 21:06:20
|
Hi, Jeremy, hi all: I'm converting to wav format a raw file that comes from this: $ pacat --record -d alsa_input.usb-BEHRINGER_UMC404HD_192k-00.analog-surround-40 > dump.raw because it's the result of a three-microphone live recording using my four-channel Behringer audio interface. I expect the result to be a three-channel file: what will the right sox command be? The following: $ sox -t raw -r 44100 -e signed-integer -L -b 16 -c 2 dump.raw output.wav produces a two-channel file: please help. Instead, if I record with: $ sox -t alsa hw:2,0 output.wav I get a four-channel file. But I'd prefer using pacat. Please help. Thanks. Cheers, Jeremy Rodolfo |
From: Eric W. <nor...@yh...> - 2024-03-25 10:10:53
|
Klaus Kauker <ma...@kl...> wrote: > Hey there > > if I play one single file with e.g. 30 seconds in it plays pretty much instantly. e.g.: play file1.mp3 trim 30 Right, src/sox.c has optimize_trim() when trim is the first effect but AFAIK it only affects single inputs > If I pass more than one file sox somehow takes much longer to seek to the desired position: play file1.mp3 file2.mp3 trim 30 Yeah, the optimize_trim() function only triggers with single inputs. Maybe Jan has a faster computer and didn't notice "trim 30" taking longer to start than no trim at all. Using a larger value (e.g. "trim 300" on longer audio files) will make a more noticeable delay for faster computers. > I think modifying the command to: play file1.mp3 trim 30 ; play file2.mp3 works fine in most cases but it introduces an audible gap between the files. Right, that will restart your audio device, and AFAIK sox doesn't make use of the metadata required for gapless mp3 playback. (FLAC and most other formats don't need special code for gapless) > Is there a solution for gapless playback and fast trimming? You can have two sox invocations write to the same pipe via subshell: FMT='-t s32 -r 44100 -c2' # any format will work, but it has to be consistent (sox file1.mp3 $FMT - trim 30 && sox file2.mp3 $FMT -) | play $FMT - I expect the gaps will still be there with mp3 files, though. |
From: Jan S. <ha...@st...> - 2024-03-09 08:44:07
|
On Mar 05 21:58:51, ma...@kl... wrote: > if I play one single file with e.g. 30 seconds in > it plays pretty much instantly. e.g.: play file1.mp3 trim 30 > If I pass more than one file sox somehow takes much longer How much longer? How do yu measure? > to seek to the desired position: play file1.mp3 file2.mp3 trim 30 I cannot reproduce: play file1.mp3 file2.mp3 file3.mp3 trim 30 just starts playing 30s into file1, same as with play file1.mp3 trim 30 Please post the full output of play -V5 file1.wav file2.wav trim 30 Jan |
From: Klaus K. <ma...@kl...> - 2024-03-05 21:25:49
|
Hey there if I play one single file with e.g. 30 seconds in it plays pretty much instantly. e.g.: play file1.mp3 trim 30 If I pass more than one file sox somehow takes much longer to seek to the desired position: play file1.mp3 file2.mp3 trim 30 I think modifying the command to: play file1.mp3 trim 30 ; play file2.mp3 works fine in most cases but it introduces an audible gap between the files. Is there a solution for gapless playback and fast trimming? THX Klaus |
From: Jan S. <ha...@st...> - 2024-01-11 21:27:23
|
On Jan 11 11:29:24, jjl...@gm... wrote: > But, for simple things like converting audio formats, as in "sox in.this out.that"? > I use dBPowerAmp > Music Converter, which has a small fee for MP3 converters (with a free > trial.) It has a GUI or you can just right-click on any supported audio > format and click "Convert". That's the opposite of SoX. > It has a batch mode as well. The command line has a batch mode. |
From: Jeff L. <jjl...@gm...> - 2024-01-11 16:29:52
|
I suspect Peter hit the nail on the head, providing context. The Sox manual, in UNIX man-page format, is probably the hardest to read man-page I've read, in over 40 years as a software engineer. Yet I couldn't write a better one. It's a problem caused by the complexity of SoX plus the approach of a man-page, especially when what you need isn't a reference but a tutorial. Consider googling for a "SOX tutorial", which will help you get started. Also, when I have trouble figuring out a particular use case, I google for "how to do XXX with sox" and usually find a lot of helpful examples, and after some study I can then understand the related reference manual entries. It is tricky to get started, but if you have an audio process that you want to do repeatedly or especially from a script, there's nothing better -- nothing I know of that even comes close. But, for simple things like converting audio formats, I use dBPowerAmp Music Converter, which has a small fee for MP3 converters (with a free trial.) It has a GUI or you can just right-click on any supported audio format and click "Convert". It has a batch mode as well. dBpoweramp Music Converter - mp3 converter, FLAC, WAV, AAC & Apple Losslesss. Free 21 day trial, download & convert <https://www.dbpoweramp.com/dmc.htm> I've been using this for about 20 years now. Jeff On Thu, 11 Jan 2024 at 04:36, Peter P. <pet...@fa...> wrote: > Dear Mark, > > you seem to be working on a Windows operating system. Sox is a software > that you would run from within the OS command prompt/shell/terminal. So > open the command line shell[1] and type the command > sox > to see if it is installed correctly. If you get a reply from sox other > than a message that the command can not be found, learn how to navigate > to other drives and folders[2]. > > Once you arrive in the folder that holds audiofile.mp3 execute the sox > command as described in the sox manual. > > best, P > > [1] > https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands > [2] https://www.computerhope.com/issues/chusedos.htm > > * Mark Donaldson <mwd...@ou...> [2024-01-11 01:32]: > > Hello! > > > > This sure sounds like a dandy program, but I'm trying to get around the > syntax. > > > > Say I have a an audio file on my D drive called audiofile.mp3 and I want > to convert it to a wav file. > > > > My sox program is on my C drive in programs. > > > > So how do I convert this mp3 then? > > > > Sounds like a great place to start! > > > > Please help me and thanks! > > > > Mark Donaldson > > > > > > > > _______________________________________________ > > Sox-users mailing list > > Sox...@li... > > https://lists.sourceforge.net/lists/listinfo/sox-users > > > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |
From: Jeff L. <jjl...@gm...> - 2024-01-11 16:12:19
|
I believe I have some Bat-cording on my Bat-utility belt, which is in the Bat-cave at the moment. ;-) On Tue, 2 Jan 2024 at 08:11, Thomas Förster via Sox-users < sox...@li...> wrote: > Hi Markus, > > here is an example for sox commandline for my special use. Please adapt it > to your need and correct your windows-batch-code: > > sox -r 44100 -b 24 -c 2 -e signed-integer input.raw -t wavpcm > output_24bit.wav > sox -r 88200 -b 24 -c 2 -e float input.raw outputput_24bit.wav > > Regards > Thomas > > Am 29.12.23 um 10:09 schrieb markus.blaschke--- via Sox-users: > > Hello, > > I want to convert raw files from a Bat cording system to wav-files for the > Bat analysing system. > And I found the Program SOX where I saw that it works with this to file > formats. > > I work with Windows 10 > > an I know from the Internet page of the Bat cording systeme that the > > RAW files have no header > > samplerate 500 kHz > little endien format > PCM 16-bits > > other WAV files from an other Bat-cording system have > > Channels : 1 > Sample Rate : 312500 > Precision : 16-bit > Sample Encoding: 16-bit Signed Integer PCM > > so i tried a batchfile to convert > > @echo > cd C:\temp\sox-14-4-2 > for %%i in (C:\temp\*.raw); do (sox.exe -r 500k −b 16 -L −c 1 %%i -r > 312500 -b 16 -L -c 1 .\converted\%%i.wav) > pause > > > but i get this back: > > sox.exe FAIL formats: bad input format for file > `C:\temp\20230523-N091_B0220-000014.raw': sampling rate was not specified > > I thought the "-r 500k" is the information for the sampling rate. > > Does anybody can give me an Idea to understand the line? > Thank you for all your Help > > Markus > > > _______________________________________________ > Sox-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sox-users > > > _______________________________________________ > Sox-users mailing list > Sox...@li... > https://lists.sourceforge.net/lists/listinfo/sox-users > |