Tough problem, I'm going to make an off the wall comment that may or may not be useful. Is there some way to do a SoX pipeline on left plus right audio and then left minus right audio in sequence each with a different FIR so that you can combine them to look like left and right got the original FIR's that you want?
I hope you can see what I mean.
Last edited:
OK I got it now. SOX offers an effect called "fir" for convolution.
It looks mono. However sox works with "self decribed" files that have headers describing the rate and #channels so maybe it could work with a stereo txt file. Otherwise there should be a way of making a chain to split out channels (remix), then process each channel separately, then recombine the set. I think that's what Scott's saying as well.
Last edited:
Yes, I stated it in an overly complicated way. I have not played with it but read the manual for file combining carefully. IME there are a lot of things that work with the right command line switches that are not immediately obvious.
If you can split a stereo file into two mono files and apply an fir to just one and recombine them to a stereo file that you can pipe to a second SoX instance that does the other channel you can do what you want. There will be some latency not sure you mind, IIRC SoX uses the MIT FFTW library which can be fast. The BruteFIR docs might give you some hints on the best size of FIR for speed.
As I wrote, the process that works in SOX is:
1. sox.exe stereo_IN.wav mono_1.wav remix 1,1 fir filetr1.txt
2. sox.exe stereo_IN.wav mono_2.wav remix 2,1 fir filetr2.txt
3. sox.exe -M mono_1.wav mono_2.wav stereo_out.wav
My problem is how 'pipe' the three commands:
sox.exe stereo_IN.wav - 1,1 fir filetr1.txt | sox.exe -M - mono_2.wav stereo_out.wav
sox.exe stereo_IN.wav - 2,1 fir filetr2.txt | sox.exe -M mono_1.wav -stereo_out.wav
works too, but I should 'pipe' the two command producing the 2 mono (1 and 2) to the one recombining it in a stereo (3) this is what I could not figure out how to do.
Latency is not a problem, if contained in less than few seconds, provided the output is in sync.
Could you please point me to the documentation describing "self decribed" files used by sox or simply post an example? I'm using flat txt files, this could easily be the problem!
There are a few hints in the manual SoX like this. I've cut and pasted relevent items. I can try a few thing later today/tonight to see if I can get it to work.
Code:
"|program [options] ..."
This can be used in place of an input filename to specify the the given
program’s standard output (stdout) be used as an input file. Unlike −
(above), this can be used for several inputs to one SoX command. For
example, if ‘genw’ generates mono WAV formatted signals to its standard
output, then the following command makes a stereo file from two generated
signals:
sox −M "|genw −−imd −" "|genw −−thd −" out.wav
For headerless (raw) audio, −t (and perhaps other format options) will need to be given,
preceding the input command.
−p, −−sox−pipe
This can be used in place of an output filename to specify that the SoX command
should be used as in input pipe to another SoX command. For example, the command:
play "|sox −n −p synth 2" "|sox −n −p synth 2 tremolo 10" stat
plays two ‘files’ in succession, each with different effects.
−p is in fact an alias for ‘−t sox −’.
Multiple Effects Chains
A single effects chain is made up of one or more effects.
Audio from the input runs through the chain until either the end of the input file
is reached or an effect in the chain requests to terminate the chain.
SoX supports running multiple effects chains over the input audio. In this case,
when one chain indicates it is done processing audio, the audio data is then sent
through the next effects chain. This continues until either no more effects chains
exist or the input has reached the end of the file.
An effects chain is terminated by placing a : (colon) after an effect.
Any following effects are a part of a new effects chain.
File Format Types
SoX can work with ‘self-describing’ and ‘raw’ audio files. ‘self-describing’ formats (e.g. WAV, FLAC, MP3)
have a header that completely describes the signal and encoding attributes of the audio data that follows.
‘raw’ or ‘headerless’ formats do not contain this information, so the audio characteristics
of these must be described on the SoX command line or inferred from those of the input file.
Last edited:
I'm afraid a "self describing" file might just be one of a standard headered set of files like .wav not one you can define yourself.
The problem I see is that a SoX pipeline needs both channels to be passed in sync to the next instance. All the references for multiple effects seem to wait to terminate the first before starting the next. There is also a newfile, restart mechanism but I don't see it helping.
EDIT - Wait a second why can't genw in the example below be two instances of SoX generating left and right (each with their own fir's) as mono files? You just put "-" after a SoX command to make it output to stdout, This looks promising don't have time to try it now.
The problem I see is that a SoX pipeline needs both channels to be passed in sync to the next instance. All the references for multiple effects seem to wait to terminate the first before starting the next. There is also a newfile, restart mechanism but I don't see it helping.
EDIT - Wait a second why can't genw in the example below be two instances of SoX generating left and right (each with their own fir's) as mono files? You just put "-" after a SoX command to make it output to stdout, This looks promising don't have time to try it now.
Last edited:
SOX stereo convolution with seperate FIRs
I gave it a try and its close, but was generating pipe and file errors on my RPI so I went looking for a solution. This works for stereo FIR convolution. Used on sox v14.4.1.
It's not obvious from the manual but I got some more hints from command line - SoX pipe operations and data loss - Super User I tested with a 16K tap LP FIR@1Khz applied to one channel and a HP FIR@1Khz applied to the other channel. The test file (xylophones) and filters are in a zip file at the end. The xylophone file is mp3 but can be converted (bloated) to the required wav file with "mpg123 -w xylophones.wav xylophones.mp3". The top 2 waveforms are originals and the bottom 2 are post filtered.
I gave it a try and its close, but was generating pipe and file errors on my RPI so I went looking for a solution. This works for stereo FIR convolution. Used on sox v14.4.1.
Code:
sox -M -t sox "|sox xylophones.wav -p remix 1,1 fir HP1Kfir.txt" "|sox xylophones.wav -p remix 2,1 fir LP1Kfir.txt" outstereo.wavIt's not obvious from the manual but I got some more hints from command line - SoX pipe operations and data loss - Super User I tested with a 16K tap LP FIR@1Khz applied to one channel and a HP FIR@1Khz applied to the other channel. The test file (xylophones) and filters are in a zip file at the end. The xylophone file is mp3 but can be converted (bloated) to the required wav file with "mpg123 -w xylophones.wav xylophones.mp3". The top 2 waveforms are originals and the bottom 2 are post filtered.
Attachments
Got it!
Thanks to DonVK and scott wurcer!
REM sox.exe stereo_IN.wav mono_1.wav remix 1,1 fir filter1.txt
REM sox.exe stereo_IN.wav mono_2.wav remix 2,1 fir filter2.txt
REM sox.exe -M mono_1.wav mono_2.wav stereo_out.wav
could be reduced to a single line like this one:
sox −M "|sox.exe stereo_IN.wav -t wav -c 1 - remix 1,1 fir filter1.txt" "|sox.exe stereo_IN.wav -t wav -c 1 - remix 2,1 fir filter2.txt" out.wav
It works, just have to test how long does it takes to produce the first audio using long files (latency), but it works.
Last edited:
The latency should be mostly related to the lengths of the fir filters. This is where a super optimizer would be useful. Please post your results I'm curious now.
Too bad it does not process files in parallel, but it write to output all at once at the end, so is unsuitable for real time (i.e applying FIR to streamed pcm from Qobuz or Tidal).
With Large WAV files (600 MB) it takes few seconds on my i5 with windows 10.
Any Idea?
Sox does process incoming data in chunks - see its param --buffer (resp. --input-buffer). Default value is 8kB. If the pipes are properly implemented (asynchronous blocking), the whole chain will run in parallel.
From what I've learnt MS-DOS pipes are fake Information Technology: An Introduction for Today’s Digital World - Richard Fox - Knihy Google . You could use cygwin or the new WSL project to run proper pipes in MS Windows.
Nevertheless, overall latency even with regular pipes suffers because they are long (64kB in linux) and take time to fill up, before telling the other side to start processing data. There are configurable buffers available (at least in linux), or configure the whole chain into single sox instance.
From what I've learnt MS-DOS pipes are fake Information Technology: An Introduction for Today’s Digital World - Richard Fox - Knihy Google . You could use cygwin or the new WSL project to run proper pipes in MS Windows.
Nevertheless, overall latency even with regular pipes suffers because they are long (64kB in linux) and take time to fill up, before telling the other side to start processing data. There are configurable buffers available (at least in linux), or configure the whole chain into single sox instance.
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.