A cry from a fellow composer arrived yesterday asking how to quickly adjust the gain level for over 10,000 audio files. Designers from all over recommended the usual applications — Peak, SoundForge, Waves, Barbabatch, Wavelab — as help to his predicament.
Fine recommendations, but this is a perfect job for Linux. A simple script, the bash shell and free Linux audio applications can fix him up nicely. (Those who don't have a spare PC quit belly-aching. Linux doesn't require the horsepower that Windows craves, so retrieve that old clunker you tossed last year and see my article Resurrect Your Old PC for Music—with Linux for the cost of a blank CD.)
Admittedly, this solution is a big yawn for *nix users, but you'd be surprised how many artists are still locked into GUI-land and don't see the benefit of shells. Perhaps it's not all their fault... maybe we've stopped passing on the tricks of past generations... take note old timers: pass on your treasures!
I'll use a slightly different example than the gain level adjustment, but it's virtually the same for any audio process. Let's say you want to change all your WAV files to 22k. Easy, write a script! There are many ways to accomplish the task, but I'll use the sndfile-resample utility that uses the handy libsamplerate library:
sndfile-resample -to 22050 -c 0Here's the entire loop you can place in a bash script:
The script simply takes all the WAV files in one directory, sample-rate converts to 22k and places the converted files in another directory. What could be easier? (Obviously, this is a segment from a larger script — the $outputdirpath is a variable set earlier.)
There are plenty of ways to process audio in Linux and there are many good plugins at your disposal: EQs, limiters, filters, delay lines, flangers, etc. See plugin.org and LADSPA for a partial list.
Free? Yep, the other thing that Windows doesn't have: FREEDOM. Linux is free and so are 99% of the audio applications for Linux — including all the package updates.
Speaking of free: Here's an important update to my article on Fervent Software's Studio To Go!. Fervent software is providing free package upgrades for all customers of version 1.0:
Here's the scoop from Fervent:
*** FREE PACKAGE UPGRADES ***
For existing customers who have installed
Studio to Go! v1.0 we have made available free
upgrade packages for the major audio applications.
Log on to the Fervent website and look in the
registered user's menu to find out more!
Now, what was that about no free lunch?
How do you render massive amounts of files?
Categories
Audio
Comments (6)
Read More Entries by Brad Fuller.
A few other things Windows doesn't have...
The shell is definitely the most powerful aspect (and for Windows users, generally the most overlooked aspect), but popular Linux GUIs have several other features I would love to see in Windows.
(The following are technically Gnome features rather than Linux features, but the article dealt with bash features and not kernel features, so this seems a logical extension. I believe KDE has comporable features for most of these.)
#1: Layering. Being able to move a window up and down a layer, effectively allowing any window to be "always on top". Extremely handy when comparing two documents, especially because of #2... (More recent versions of Gnome simplify this to "On Top", which is just as good for most intents and purposes.)
#2: Mouse scroll button acts on object it is hovering over whether or not is has focus. This means that the web browser in the background does not need to be the active window for me to scroll down, which saves me a lot of Alt-Tabbing. In Windows, using the scroll button will scroll the active window regardless of the mouse's location.
#3: Shading. I don't use this nearly as often, but when I do I'm thrilled to have it. Being able to effectively minimize to a place other than the toolbar and have the window appear and disappear based on mouseover are extremely handy.
#4: Multiple terminals. (Now this is a pure Linux feature...) Being able to log in as multiple users on multiple virtual terminals on the main system is incredibly handy. Similarly, "su" and multiple virtual desktops fill similar needs in different ways. (However, "su" *can* be simulated on Windows by typing "runas /user:usesrname cmd".)
There is no free lunch...
Thanks for your reply, kollivier.
A person in the audio field, heck even hobbyists, fully understand and are well equipped to handle "ins" and "outs." It's part of the fabric of audio life. I don't see this as an issue.
Those who would be creating audio processing scripts would, most often, be professionals. Scripting isn't a foreign idea to them. True, it's easy to poke and prod in a menu or in the parameter settings of a plug in; true, one will have to learn bash; true, ya need to type more; true, some people take the easy road. But, the overall benefit outweighs the time invested (and it's faster. Increase speed == increase money in pocket.)
Whether to use a character-based or graphically-based interface is a question for the problem to be solved. Form is preceded by function for the terminal/bash UI but is no less a suitable interface for humans. To take an elevator from the ground to the second floor is over kill. I say: use the stairs. It will be quicker and you'll stay in shape!
brad
I like your idea of developing a “bash script creator.”
Re:
What, your editor doesn’t generate a HTML rendition of the highlighted code for you?
Mine does.
http://www.vim.org/htmldoc/syntax.html#:TOhtml
;-)
Re:
Thanks for replying, aristotle.
You're right, I should have removed the "ls" and quoted. Thanks for pointing that out.
The reason for the temp file is for both debugging purposes and for processing the audio files in several steps. Sample rate converting is actually mundane. Most often, files are processed in multiple steps. You will want to hear the results at each stage. For instance, processing like this:
requires a lot of tuning (even if you are using a GUI frontend.) The sound designer must hear the individual steps to make sure he has it right. Temp files can be removed, if the user so chooses, afterwards.
What, you don't like my color coded code? :-) I simply used a PNG so that I wouldn't have to type all those darn html color tags.
Re:
(A note at first: why are you posting a screenshot of a listing? Noone can copy-paste it like that.)
That’s a useless use of ls[1] there. And because you’re taking filenames from a backticked command, it will fail to process filenames with spaces (or other weirder characters). You are also not quoting the variables, so again filenames with spaces will throw a monkey wrench in there.
And why are you saving output in a temporary file with a fixed filename? That is always asking for trouble. Just stick the output in the right place directly.
That means writing it like so:
for i in *.wav ; do echo "$i -> $outputdir/$i" sndfile-resample -to 22050 -c 0 "$i" "$outputdir/$i" doneThat’s much shorter and works more robustly.
[1] http://www.ruhr.de/home/smallo/award.html#ls
There is no free lunch...
I fully agree that a lot of open source software offers great possibilities, but I think there's something on *our* side that we're not seeing. And that is that the learning curve to get comfortable with shell scripting is steep. In my experience (and attempts to move people over to scripting), the reason many people stick with GUIs is that although the solution may be 'clunky' and require some manual steps, the solution is one they can implement immediately.
The script itself may look simple, but it requires a whole lot of pre-requisite knowledge. Programming still requires you to think in terms of inputs and outputs, rather than natural language ("I want to resample these files"), and you have to become aware of a series of commands and know how to utilize them. (including wildcards, etc., etc.) You also need to be able to debug and test when scripts go wrong. The learning time required for shell scripting probably would be at least several days, if not weeks. And that's time these people aren't billing clients.
So most people I know do fully see the benefits of being able to write scripts - but they also see an intimidating learning curve and an unknown payoff. (Will I use this once a week, once a month, or twice a year?) That is what makes people steer away from these things, in my experience.
A GUI "script builder" ala Apple's Automator would probably do wonders in reducing the learning curve and also one-upping Windows in terms of power and simplicity. I don't think it is *the* killer app, but it certainly would be a great tool for professionals and increase the appeal of open source and Linux distros. Since almost all open source apps have sophisticated command line interfaces, the number of applications and commands available to the script builder would be huge.
So don't forget that while GUIs can be less efficient, they can also be much quicker to learn, and sometimes that reduced learning curve makes the difference between using, or not using, a particular technology.