From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=DKIM_ADSP_ALL,DKIM_INVALID, DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id EFA651F406 for ; Mon, 16 Oct 2023 11:10:39 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=sourceforge.net header.i=@sourceforge.net header.a=rsa-sha256 header.s=x header.b=eBi8tX6R; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=sf.net header.i=@sf.net header.a=rsa-sha256 header.s=x header.b=DvYaPPgA; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=u-l-v.org header.i=@u-l-v.org header.a=rsa-sha256 header.s=ds202212 header.b=JKnj/7pv; dkim-atps=neutral Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1qsLUS-0006fC-NK; Mon, 16 Oct 2023 11:10:27 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qsLUR-0006f5-Ge for sox-users@lists.sourceforge.net; Mon, 16 Oct 2023 11:10:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:From:References:To:Subject:MIME-Version :Date:Message-ID:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FNlAWCNiKPyaBlUSmmJrzu7A7jsOt/Wt9269P7Xu3mM=; b=eBi8tX6RZyBUQVDVzHHLzDhSf4 Pt2udZ9pXjGeGqOwUf19Dry9L8x3F0cRyLqawrobvgUFyvYagw82YdguX75PDiu29fwi/XjSvBxcA LdTH/keXEoRYJMIvLvToFgJohkfnSG79LbybH4YNbTSvyxNEMgpnEiKwOSGPOXlPP1ME=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID: Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=FNlAWCNiKPyaBlUSmmJrzu7A7jsOt/Wt9269P7Xu3mM=; b=DvYaPPgAtWZWFu+s77Zyj4Fmi5 +h74uSMQs3rqIrfTbuPQrL2G+LTk5pQe0DFNwU5hvz87YWDAEUC+pqdjj+pCtJsDSU7ScHCKKNPaj 7t5Z0yYsF7XzieLYScM4SaTdlmwBHOd11/d1PI2VDyaDP8SDsFSLizQUUeTc6szCTPf8=; Received: from smtp.domeneshop.no ([194.63.252.55]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1qsLUI-0004wy-Fn for sox-users@lists.sourceforge.net; Mon, 16 Oct 2023 11:10:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=u-l-v.org; s=ds202212; h=In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FNlAWCNiKPyaBlUSmmJrzu7A7jsOt/Wt9269P7Xu3mM=; b=JKnj/7pvuOduvQhAgYbz95wDTr t1QCoGcoCsitO2U7aW/IW7JYL9kSPJV67cYqnXK0aH0HuoRaQbKX5Zw3g0bPfYKQOKS0ObCr2RvrW gwDtL0fBVRcSH22XydLP0Z+CSz9THsYUPR7wa1N9VGZeWOSCez+VibfcueQ779RJHCCovmI0WD35M 8dKJLFJWrhViRTmwZwGVfTJcPj6DV2q7j+O/t7K7H5Rw/RGp0+w/0w/EpFczDMtQ4cLmWuYpoyalb ZSt7srjHBHuPLMLGu5zR44/DkmTtvdAeGlJfoYpI3S0JJZBAhwjTVOi0ZqyXf2cq7tl90xJMfHtel vqAEgBNg==; Received: from [84.213.205.210] (port=50236 helo=[192.168.0.13]) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qsLU7-003rcf-RO for sox-users@lists.sourceforge.net; Mon, 16 Oct 2023 13:10:07 +0200 Message-ID: <61c9fb0e-a403-015d-6e6f-74f6ae05c28c@u-l-v.org> Date: Mon, 16 Oct 2023 13:10:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-GB, nb-NO To: sox-users@lists.sourceforge.net References: <510211ee-553e-9016-08af-b3e2b9f4bf7c@u-l-v.org> In-Reply-To: X-Headers-End: 1qsLUI-0004wy-Fn Subject: Re: Help with --combine merge X-BeenThere: sox-users@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Ulf A. S. Holbrook via Sox-users" Reply-To: sox-users@lists.sourceforge.net Cc: "Ulf A. S. Holbrook" Content-Type: multipart/mixed; boundary="===============2735184495856862554==" Errors-To: sox-users-bounces@lists.sourceforge.net This is a multi-part message in MIME format. --===============2735184495856862554== Content-Type: multipart/alternative; boundary="------------3myEKNVCHBrx0cafGeVKXb1q" Content-Language: en-GB, nb-NO This is a multi-part message in MIME format. --------------3myEKNVCHBrx0cafGeVKXb1q Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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)? > > > --------------3myEKNVCHBrx0cafGeVKXb1q Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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)?



--------------3myEKNVCHBrx0cafGeVKXb1q-- --===============2735184495856862554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2735184495856862554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sox-users mailing list Sox-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-users --===============2735184495856862554==--