From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 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 006081F66F for ; Tue, 17 Nov 2020 12:07:45 +0000 (UTC) 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.90_1) (envelope-from ) id 1kezll-00043i-S5; Tue, 17 Nov 2020 12:07:33 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kezli-00042w-Kr for sox-users@lists.sourceforge.net; Tue, 17 Nov 2020 12:07:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Message-ID:References:In-Reply-To:Subject:To:From: Date:Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To:Cc: 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=q3twgxLo5JV8HZH5Z2Mu6E1EWoMAISy+jAhqHhpf1V0=; b=PGmxJLVtNugzjWYiY5cWbNCiPB KtGhgmxp+POefDjJqcQch24YORv6uUJfqeF2jHKnCFFOacBxJr3jaqx/JqbyfAMDo7V1jNnSDTFK8 NBZ7dWnTp3I8ewqRZRwMP1iqzuV+seGx0McYTIl+UicC7/llv7ufDDm9QuHI/uOvteMY=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Message-ID:References:In-Reply-To:Subject:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To:Cc: 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=q3twgxLo5JV8HZH5Z2Mu6E1EWoMAISy+jAhqHhpf1V0=; b=ZWhOr05K83VDtkjKXF2NiCqcGb zFOBgbHTGokD99O5klQ8T7xvJv+Edeu+rwQsAA0OUnFapV4cD//N3rjy5LfzZKzE5+dD7B6YP83r/ aKOQy2YI3Mg5wAJMjGaSkgj3iu6hhbVRGtP4o9/J8r29IybwovTY//AnT0Bn22L2/Kas=; Received: from authenticated.a-painless.mh.aa.net.uk ([90.155.4.48]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kezlY-00A3LO-LO for sox-users@lists.sourceforge.net; Tue, 17 Nov 2020 12:07:30 +0000 Received: from a-webmail.thn.aa.net.uk ([2001:8b0:62::22] helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kezC4-0000bn-HH for sox-users@lists.sourceforge.net; Tue, 17 Nov 2020 11:30:40 +0000 Received: from cpc132308-sgyl43-2-0-cust392.know.cable.virginm.net ([92.237.237.137]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Tue, 17 Nov 2020 11:30:30 +0000 MIME-Version: 1.0 Date: Tue, 17 Nov 2020 11:30:30 +0000 From: Jeremy Nicoll - ml sox users To: sox-users@lists.sourceforge.net In-Reply-To: References: <1cd5c375f96efc01a563bd1cf93da940@wingsandbeaks.org.uk> Message-ID: <1aae19199b3d3f47a2422738f12ff92d@wingsandbeaks.org.uk> X-Sender: jn.ml.sxu.88@wingsandbeaks.org.uk User-Agent: Roundcube Webmail/1.3.15 X-Headers-End: 1kezlY-00A3LO-LO Subject: Re: new user trying to set up a processing chain 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: , Reply-To: sox-users@lists.sourceforge.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: sox-users-bounces@lists.sourceforge.net On 2020-11-17 03:07, raymond grote wrote: > Hi Jeremy, You're correct, I didn't give enough information. > I'm using Windows 10. I'm not at a very proficient level with > scripting. I see the potential of it, but am not confident with a > scripting language yet. I'm assuming batch script would be fine for my > needs ... If you know no other alternative (eg: python, perl etc) and don't want to install anything else, basic .bat/.cmd scripts might be ok. If they are only issuing sox commands it should be fine, but if eg you also want to issue "lame" commands to make mp3 files, and set tags and have to chop up and recreate modified filenames, you might need something else. VBS would probably be better than .bat/.cmd and the cscript.exe/wscript.exe that runs those is part of Windows. For bat/cmd (and vbs etc) there's excellent information on how to use the available commands, at https://ss64.com/ > I totally understand what you're saying about making sure the > processing is easy to follow and adjust, rather than trying to make it > run as efficiently as possible. I tend to agree with that mindset, but > I feel like there's a line between an easy-to-follow way, and a way > that's hacked together because you don't understand the basic tools > which make certain things a hundred times easier. I sometimes feel > like I'm on the wrong side of that, So I'm a bit paranoid that I'm > doing things in a stupid way haha I think you're overthinking this. Everyone has to learn, whether it's better use of script language, or better use of tools like sox. One of the reasons I do things in stages is that a script that (say) applies a certain amount of gain to a set of files will be usable in the next project that wants a different amount of gain applied to a different set of files. The same script can be adapted to do something slightly different, as it already has all the logic for working through a set of files (and all the error-checking that I wrap around the overall logic). Time spent writing "the perfect script" is possibly wasted. What you need (IMO) is a set of tools that are easy to adapt to new circumstances. > A simple example follows. Not sure if I'd actually use this, I was > just trying to think of a situation which illustrates my > uncertainties. > Step 1. I have a file called test.wav and I want to pitch shift it. > sox test.wav temp.wav pitch -500 > Step 2. Then I should mix the pitch shift copy with the original, and > apply reverb to the mix. > sox -m test.wav temp.wav test_processed.wav reverb OK, but suppose you get into that habit, of always naming the output file "temp.wav"? One day you'll forget and find you overwrote the output from another sox command that previously created the same file. That's an argument for: - always using the sox command option that prevents any file from being overwritten; that's the "global option": --no-clobber - or having scripts always generate result filenames that should not already exist, verifying that they don't already exist (and to be careful, also using the sox don't-overwrite option) Sox command parameters are made up as [gopts] [[fopts] infile]... [fopts] outfile [effect [effopt]]... ie global options, then a set of input files each possibly preceded by options for how they are processed, then the output file (possibly preceded by its options) followed by effects each of which is possibly followed by its options. (The "[" and "]" might be in the wrong place but I knew what /I/ meant.) I find it easier in scripts that build up commands to have code that looks at each potential part of the overall command, maybe contributing options, maybe not. I also tend to name intermediate (or final) output files so once can see at least something about the process that created them, so if eg one of the steps in a script was to reverse a stereo image, the file leafname might have eg "reversed" in it. > File/directory structure should be simple. Basically, the original > file and the _processed version should be in the same folder, at least > for now. Temp.wav is not needed. It would be useful to hear > intermediate results, but assuming I don't need to check those, I > really don't need it. For /pitch shift/ you might not need it, but for lots of other more subjective effects you probably will need it. For example if you experiment with a dozen slight variations in the parameters for a particular effect, you'll want all the output files to exist so you can listen to them (or eg run stat or stats effects to check their levels etc). And then you'll not find names like temp, temp1, temp2 ... much use for identifying which one's which. > So my question is twofold. Is it common practice to launch sox once > for some processing and then again for other stuff? I don't it matters what's common practice or not. What matters is that you understand what your commands do and how they do them, and are happy with that. > I know you can chain effects in one sox instance ... and also pipe stuff between successive calls of sox If (say) your input files are from some laboratory process so there's going to be tens of thousands of them and they're alll basically similar, and you want to do the exact same thing to them all, then it's maybe worth finding the most efficient way to do it. But in the initial stages while you experiment and refine what that process is, I'd say you still want to make life easy for yourself. You want to be able to glance at a filename and have it tell you what's in the file. If on the other hand (like me) you deal with distinct sets of files - recordings of concerts that then get split into separate files, and have eg levels measured, gains applied, fades in & out applied, and then mp3s at various quality settings made with appropriate tags) then every project is different - the times, lengths, position of fades, fade parameters, gain settings, format of the tags etc are different from concert to concert. I'll listen to parts of every file along the way, so I /have/to create every one of them. > Secondly, is it a good idea to use a temporary output file > on the hard drive as I have done for intermediate processing steps? I'd say yes, but if you really really don't want to, don't. Going back to your example, suppose you find out later that the final file has clipping in it? How do you tell (assuming test.wav was ok) where that problem came from if you've not got the intermediate files to listen to? -- Jeremy Nicoll - my opinions are my own _______________________________________________ Sox-users mailing list Sox-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-users