JagTech

Every church knows they should be podcasting, but various technical and administrative hurdles quickly dampen our enthusiasm. The holy grail, of course, is an automated process where the sermon magically appears on iTunes every Monday morning, no human intervention required. But the reality, of course, is that it is very hard to automate every step, given the need for the tagging of the mp3 with relevant meta-data, and the need for a sound-desk guy to actually hit ‘record’ and ‘stop’ at the appropriate moments. Nonetheless, on a recent day off I set out to automate the process as much as possible. Our 5pm services were already being podcast by a congregation member, via a manual process. But I wanted to add our morning services, without having to recruit, train, and roster more congregation members. So this post details the journey, the tools, and a couple of hand-crafted resources. I suspect I’ve re-invented the wheel in a few places, and there are almost certainly better ways of doing it – so any suggestions for further streamlining the process are very welcome.

1. Recording the sermon

The first step in the whole process is, naturally, recording the sermon. In my case, this was already happening, which was very convenient. I’ll pass over the possibility that you’re recording to tape. (If that is you, just go back to rubbing those sticks together to start the fire for cooking dinner). In theory it could be done with Sound Recorder on Windows, but our sound-desk guy (who is a gun in this area) uses a free program called SoundEngine from Cycle of 5th. The other very popular tool is Audacity, which, with the lame encoder installed, can also do the conversion to mp3. If you’re going to be doing fancy noise reduction, levelling etc then you may also want to take a sound sample before the sermon starts. (But if that’s you, why aren’t you writing this blog instead of a n00b like me?). Anyway, the end result should be a .wav file on disk somewhere, ready for the next step. To facilitate the process, the file needs to be prefixed in a way that uniquely identifies it. At St James our “standard” has fairly random combinations of the preacher’s name, the Bible passage, and the topic. But, fortuitously, every file does have a date prefix – yyyy-mm-dd. With a directory full of .wav files, then, I was ready for the next step.

2. Transferring the file

The next task is getting the file somewhere so it can be coverted to mp3 and uploaded to the internet. In an ideal world everything is done on the same computer, so this step may be unnecessary for some. At St James our sound computer is in the church, which is conveniently wired into the church network with internet access. (The other options were to plug in a wireless USB, or set up a manual task for someone to put the .wav file on a USB stick each week and walk it over via ‘sneakernet’). But the sound computer is also switched off when not in use, so it wasn’t the ideal place to be scheduling programs to run in the early morning. The solution then was to count on the fact that the computer would be switched on for our evening service, and simply drop a batch-file into the start-up program group that copies any new files across to my office PC, which is always switched on. (Yes, I know it’s bad form to set up an automated process depending on my personal PC – ideally this should have been done on church’s main server). So when the sound-guy logs in for the evening service, a quick DOS-box pops up to copy the morning sermon across. The batch-file is fairly bare bones:

@echo off
echo Automated Copy for Podcasting - Please see Jon if worried about this
echo %DATE% %TIME% >> podcast.log
xcopy i:\ \\jon-pc\podcasts\am /m /d:2009-01-10 /c 1>>podcast.log

All this does is to copy all the files that have been modified after the podcasting start-date (/d), but not yet transferred (/m). The start-date was necessary because we had a back-log of several gig of historical .wav files that I did not want to copy. The batch also directs the output of the copy to a log file in case something goes wrong. I considered doing the encoding step before the transfer, so it would only have to do a 10mb transfer instead of 200mb. But as we go on to see, the encoding takes 3-4 minutes, and I wanted to minimize the disruption for the sound-guy.

3. Encoding the file

So at this stage we have a .wav file sitting on a computer, waiting to be encoded as an mp3 file. Again, there are various options to do this. As a manual step, any number of programs like Audacity (free) or Adobe SoundBooth (expensive) can do it. Most of the free ones rely on a command-line tool called lame, and so the best option really is just to use lame directly, which allows it to be automated in a batch-file. Once installed, you really want to put lame in the command path, so you can run it from anywhere. (Which means, under Vista, you go to control panel -> system -> advanced system settings -> environment variables, double-click on the ‘Path’ variable, and add “;C:\Program Files\lame” without the quotes). I got the settings for lame from our sound-guy. He runs various other manual processes on it first, which produces a smaller file with better-quality audio, but for the sake of an automated process, I was happy to go with the basics:

lame --nohist --vbr-old -V 7 -q 0 -a -m m -c --resample 44.1 2009-10-01-Sermon.wav My_Sermon.mp3

This generally produces a 10-12mb file for a 25-30min sermon, with acceptable quality. The processing takes a few minutes. On my PC (4Gb Ram, Core Duo, E8600 3.3Ghz), about 4 minutes. Which leaves you with a mp3 file ready for uploading…

4. Tagging the file

…except, of course, that I really wanted to tag the mp3 with the relevant details of the sermon, so that mp3 players could display it. So we actually need to back up a step and add some settings to lame. The following parameters set all the relevant id3 tags with the sermon meta-data (using quotes for parameters with spaces), although you would also add the parameters from the previous step for the actual encoding:

lame --tt <title> --ta <preacher> --tl <album> --ty <year> --tc <comment> --tn <track number> --tg <genre> --ti <image file> sermon.wav

But at this stage I also realised that I didn’t want to be typing in all that junk each week – the whole point was to automate the process. So I needed a batch file to do everything. But for now that meant having a text-file with all the details for sermons in the coming weeks which the batch file could just read and extract the relevant details each week. So I created a simple excel file with tabs for each service, and into which I could just cut-and-paste the preaching roster. The key was to have a field with the sermon date, which allows matching against the date-prefix on individual wave files. Then I did a ‘save-as’ to create a CSV file that could be read by a batch file. So instead of updating this file each week, I’ll just update it once every couple of months when a new preaching roster comes out.

5. Posting the file

With an .mp3 file hot in my hand, the next step was to put it online. I have a web hosting service with bluehost, from which I run various sites, including a sermon blog. So I just FTP‘d my files directly there. As a manual process this is quite easy, because Vista lets you map FTP servers as normal drives. As an automated process it is a little more tricky. I used the FTP command-line tool in Windows, with the -s option which lets you specify a file with FTP commands to execute (example here). However, you still need to dynamically insert the file-name, even if all the other commands are standard. So I decided to generate the FTP command file each time by constructing it from scratch. Here is the relevant section from the master batch-file (see the final step for the whole file):

echo %%~nf: Posting via FTP
echo OPEN %ftpserver% > postmp3.ftp
echo %ftpuser%>> postmp3.ftp
echo %ftppass%>> postmp3.ftp
echo BIN >> postmp3.ftp
echo HASH >> postmp3.ftp
echo PROMPT >> postmp3.ftp
echo CD %ftpdir% >> postmp3.ftp
echo PUT "!fn!.mp3" >> postmp3.ftp
echo DIR >> postmp3.ftp
echo BYE >> postmp3.ftp
ftp -s:postmp3.ftp > "%%~nf.log"


Ignoring the assortment of strange variables, the result is a .ftp file that can be passed to Windows’ ftp command-line tool to automatically transfer the file. Having gotten the .mp3 online, the only step remaining is to let people know about the newly podcast sermon.

6. Syndicating the podcast

There are various ways to actually make the .mp3 available. The simplest is just to make a link to the new file on your website. But in an automated process, it is not really kosher to manually modify a webpage every week. The more accepted method is to publish the file using RSS (Really Simple Syndication). This is just a particular text-file format (actually, a sub-format of XML) which describes a “channel” (e.g. your sermon podcasting service) and the most recent “items” (e.g. your last few sermons). This can then be regularly retrieved and displayed by various programs (e.g. Outlook), web-sites (e.g. iTunes), and add-ins (e.g. Vista side-bar, Google gadgets, WordPress widgets) which know how to use RSS files. Once they’ve been pointed at the RSS file on your website, you just update your RSS file each time a new sermon is available, and these programs will automatically display the new sermon. Adding your podcast to iTunes is quite simple, this way. All you do is run iTunes, go to iTunes Store->Podcasts, and under “Quick Links” is an option to “Submit a Podcast”. Follow the prompts, and enter the link to the RSS file at the appropriate point. The verification process takes a couple of days, but from then on iTunes makes your podcast available for searching and subscribing just like major churches, radio stations etc.

Creating an RSS file is not for the squeamish, however. So one option is to use a service like Libsyn, which provides the hosting of .mp3 files as well as the automatic generation of RSS files from the .mp3 files you upload. In my case, though, I was shooting for complete automation. So I generated the RSS file dynamically from my batch file. Since one of our services was already using Libsyn, I just downloaded their RSS file and modified it. The channel information was never going to change, so I stored that in a text file. Then in the master batch I copied that file to a new one, and appended an item for each sermon. Finally, I copied the new RSS file to our website using the same FTP transfer process as above. It was a little tricky getting the formatting of dates and other items correct, as RSS is a very specific format and some readers don’t react well to errors. A useful site for checking the output is Feed Validator.

Once the RSS file is in place (for example), a link to the file can be provided to iTunes and other programs or add-ins. Since I was already running a sermon blog, which runs on WordPress, I just added the built in RSS widget to the WordPress side-bar, which then automatically started listing the latest sermons. I also added a page displaying the fuller details of each sermon, using the MultiFeedsnap add-in for WordPress. These don’t require any manual updating – they just regularly check the latest version of the RSS file.

7. Putting it all together

The final stage was putting all the various steps into one batch file, and scheduling this to run early Monday mornings using Vista’s Task Scheduler. The mechanics of this file are beyond the scope of this post, but you are free to download and tinker (no guarantees expressed or implied). Remember that it requires the lame encoder to be installed for it to work. To supply the parameters rather than hard-code them in Task Scheduler, I also created a wrapper batch file, although I’ve omitted some of the details for security reasons . The end result is quite effective: the files are transferred, encoded, matched against a record in the CSV file, tagged with the relevant sermon meta-data, uploaded, and syndicated – all without any user intervention except 1) the sound-guy hitting ‘record’ and ‘stop’ and setting the filename each week, and 2) me updating the preaching roster CSV file every couple of months. Otherwise, I dare to say, it is streamlined podcasting. JAG.