I think you'd be on to something! The for-loop probably calls sox at 
each loop and causes some issues.

However, if I run

sox --combine merge *.WAV merged.wav

or write to a different directory, it still merged everything into the 
last file in the list /and /it creates a new file.

So, I have files labelled 1.wav ... 90.wav Each are 1 minute long. When 
running the merge command, the last file in the list becomes the one 
everything is merged into, and ends up having 89 channels and not 90. 
The new merged.wav ends up being 8 seconds long, yet have 178 channels, 
ie 89 x2. So somewhere along the line the loop is doubled, and I cannot 
understand how.


/*
Ulf A. S. Holbrook
post@u-l-v.org
http://www.u-l-v.org/
+47 99569230
*/

On 15/10/2023 22:39, Jeremy Nicoll - ml sox users wrote:
> On 2023-10-15 14:27, Ulf A. S. Holbrook via Sox-users wrote:
>> Hello!
>>
>> I'm trying to combine a large amount of files into one single file 
>> and wondered if someone could lend a hand. I have individual folders 
>> of 90 1-minute files in .wav and want to merge them into one 
>> 90-channel file. I'm running
>>
>> for file in /dir
>>
>> do
>>
>> sox --combine merge *.WAV >> merged.wav
>>
>> done
>
>
> I am guessing here ... and if that's a linux shell command I don't 
> know if
> it evaluates *.WAV just once or more than once.  It's also not clear 
> to me
> if you delete merged.wav between experiments.
>
>
> I've never seen an example sox command that uses redirection to place 
> output
> in a result file, so wonder if what's (not) being written there is 
> progress
> or error messages rather than audio data?  Perhaps
>
>    sox --combine merge *.WAV merged.wav
>
> or
>
>    sox --combine merge *.WAV \anotherdir\merged.wav
>
> would work better.
>
>
> It looks to me as if your code runs sox many times.  Why not run it just
> once reading all the input files in one operation?
>
> If multiple runs ARE needed, does it work when the source directory only
> contains one file?  Or two files?  Can you make a copy of the generated
> file each time - NOT in the same directory, so there's no risk of it 
> being
> matched by the "*.WAV" if that pattern is matched multiple times? - and
> examine each run's output to see what it actually contains (eg with the
> stats effect)?
>
>
>