One of the things that has become synonymous with sourcing audio for radio broadcast is downloading the audio from a variety of FTP servers using software clients like FileZilla or WinSCP.
I’ll explain the process we use in Crawford Broadcasting’s Birmingham market to automate getting the audio before placing it in our system. Of course, it wouldn’t be a solution from yours truly unless it used software that is freely available for download.
Why automate this process? Downloading individual pieces of audio (usually MP3) and processing it into our broadcast system takes somewhere between 8 to 10 steps for any given piece of audio. Multiply that by the number of audio shows or clips in a typical daily broadcast log, and you can see that the task is not only large but monotonous.
When we perform a task repeatedly, we’re only increasing the chance of introducing errors. Well-tested automation processes can free up time for other tasks.
This started simply enough with content like weather forecasts and traffic reports but has morphed into much more with programs from Ambassador (AMB-OS) and others that maintain their own FTP sites with their audio on them.
The secret sauce in the overall process is creating “batch” files, then using the built-in Windows Task Scheduler to run those batch file scripts at a prescribed time. Our weather forecasts and the like were simple one-line batch files that referenced a text file with all of the account information and what file(s) to grab from the FTP, but it became apparent that the batch files would need to become a little more complex to get audio from several of the shows that we wanted.
Since I don’t have great scripting skills, I looked for something that might do the bulk of the scripting and allow me simply to tweak the batch file script. I found that WinSCP, which is itself an FTP client, can do that work for the user.
In WinSCP, once you create your connection to the FTP server (see Fig. 1), one of the options is to generate a URL/Script/.NET Assembly Code for the connection. I use the script tab and choose the “batch file” option to generate a batch file with the option in the window to copy the created file to the clipboard.
From there, I can open up Windows Notepad and tweak the “command” portion of the file with individual commands like the GET command, which indicates where the file I want is located on the internet and where I want to put it on our local computer.
When I’m happy with the command, I save the file, not with the “.txt” file extension that Notepad would like to use but with the “.bat” file extension. This allows the file to be executable.
Consequently, once the file is saved, I can double-click on it, and it should do what I’ve asked it to do: Use WinSCP to log into an FTP server that we have permissions to access, download an audio file in the FTP server’s file structure and place it on our computer in a specified folder.
As you can see from Figs. 2 and 3, the only real difference between what WinSCP creates and what I have added in Notepad is that one GET command line. (If you have trouble reading these images, email radioworld@futurenet.com with “Please send me Todd Dixon FTP images” in the subject line.)
I’d be remiss if I weren’t honest about how frustrating it is to get the formatting right on the actual command line; most internet servers are Linux-based and not particularly forgiving about upper/lower case and spacing. When it works the first time, you get a feeling that I liken to taking a fortified position in a war.
But not only have you created a script that will get the file from that vendor indefinitely (until they change file-naming conventions or folder structures), you’ve also created a template to use for other FTP client sites to get their audio as well. The thinking required for the next piece of audio that you want to download automatically from a different site is generally similar to what you have done previously.
It’s important to discuss this with the person that has done the work manually for a while. One client’s audio might be uploaded all at once for the next week. Another may upload single pieces of audio each day at a particular time.
In fact, the astute reader might have noticed the timestamp in Fig. 3 that includes “+1D” in the formatting of the file name we want to get from their FTP server in the command line. This particular client puts their entire week’s audio onto their FTP site, so to make our automation work correctly, the batch file is only grabbing the audio for the next day based on the date and time you get the audio in the current day.
Once you have tested the batch file to make sure that it runs correctly when you manually force it to run, the next step is to get the automation to execute the batch file at the time of your choosing.
The last piece is to use the Windows Task Scheduler to run the batch file. Task Scheduler is built into the Windows operating system for automated tasks like updating software, checking internet time and a host of other processes. It also allows you to automate tasks like restarting a program once a day in the middle of night or, in our case, running a batch file at a particular time. What time should that be? Again, discuss with the person who has been doing it manually; they will know the client’s tendencies. The scheduler walks you through scheduling the batch file for the time and the weekly days that you may want to get the files. I typically place the batch files into the same folder where I’ll be putting the audio so that everything can be seen in the same folder; but you might choose to put multiple batch files together in one place and only separate the audio into different folders.
When the task has been created, it’s my practice to go into its properties and make sure things like “run with higher privileges” and “run whether on battery or not” are selected so that I can be sure that the task will run as it should. In task scheduler, you can also right-click on the newly created task and choose to run it to see that your batch file executes as you have planned and puts the audio you want into its correct folder.
The goal of this exercise is to remove the opportunity for error in our systems. Test this work well before you implement it into your workflow. I’ll generally set up the process but then let the person who does the work manually check it against their audio for a week or more before it goes live.
Finally, after the process described above, we move the audio from an individual folder with conversion and cart number creation, so that the process, in the end, is hands-off. At Crawford we use RCS NexGen and its audio format converter utility; I’m certain there are other software products that do audio conversion and radio automation systems that feature match automatic loading of audio into their systems as RCS does in its product; but if you’re interested in how we handle that part of the process, just drop an email to radioworld@futurenet.com with the subject line “Please send Dixon FTP Part 2,” and Radio World will send you the text.
The author likes to find open-source software solutions that make sense for broadcast. He is the chief engineer for Crawford Media Group’s Birmingham, Ala., market.
