A script to speedup audio file playback on iPod

Oct 04, '10 07:30:00AM

Contributed by: name99

I frequently listen to spoken word content (podcasts and audio books) on my iPod. I find that most such content is way too slow for my tastes. I've been very disappointed in how Apple handles speeding up this sort of audio, so for a long time I've handled this manually, and I figured it made sense to share the method as a hint.

Apple has the ability on iPods/iPhones to play audio at faster than 1x but there are various problems with what they offer.

The issues include:

(a) Apple has a variety of confusing rules about what will or will not be speeded up on different devices. On my particular iPod nano the ONLY content that will be sped up is AAC content that has a .m4b suffix and did not come from a podcast. On newer devices the rules are slightly relaxed, but are still pretty stringent, and video is not included (even when, as is the usual case for me, I'm not interested in the video and only want to listen to the audio portion).

(b) The first round of devices sped audio up by 1.25x. This is not nearly enough for my tastes. The newest round of devices speed audio up by 1.5x. This is still usually too slow for me. On the other hand, you do occasionally get a very fast speaker for whom this 1.5x is too fast.

My solution to all this is to preprocess all my audio to speed up by my chosen speed factor. For me, the best speed factor is usually 1.3x. This, combined with the 1.25x of my iPod nano gives me a 1.625x speedup which is about right, with the ability to fall back to the hardwired 1.3x speed on the rare occasions of a very fast speaker. If you like this script, experiment with a speedup that works best for you.

The code of interest is the bash script below. You use it by cd'ing to a directory holding the audio and video files you wish to speed up. You execute the script, giving an optional parameter, which is the speedup factor (by default 1.3 is used if you don't specify this argument). The script runs for a while and, for each source file 'NAME.type' it produces a corresponding file '1.3x NAME.m4b' (or 1.2x or whatever speedup you used). The original file is not touched, not deleted or harmed in any way. The code uses two auxiliary appications.

The first is 'afconvert' which is part of OSX and converts between a fairly wide range of audio and video files. I use it to convert the original file (whatever format that may be) into a WAV which is then fed to the second program, sox.

The utility sox supposedly is supposed to be able to handle many audio formats, but the only file type I have EVER got it to open is WAV; I can't even get it to open mp3 let alone AAC. But we have afconvert to do that part of the job. What we do with sox is send the audio through a number of filters which:

You then export the result as a WAV file, use afconvert to convert it to a .m4b file, and you're done.

In my experience afconvert has handled everything I've needed it to handle (basically mp3, aac4 and h.264 video). It would probably fail on a protected file (like an m4p), but I never tried this.

Finally the script makes no use of any sort of shared state so you can run multiple copies on different directories at once. As configured below it runs on 3 files simultaneously (the kNumInstances) variable, which for my 2 CPU machine works well. If you have 4 CPUs (or a hyperthreaded dual CPU), you can probably bump kNumInstances to 6. And, if you just can't wait, you can open a second terminal window, cd to a different directory of audio files, and start a second session on those files.

Note that I do NOT check for whether each file is 'audio' or not, I just throw everything at afconvert. This means that if you have subdirectories, or PDF files or whatever in the directory of interest, you will get errors for each such anomalous file. I used to include a check for file type but found that it just wasn't necessary -- the way I use the script, I just don't have anything in the folders I convert except the files of interest.

Note also that for each file you will get a number of warnings about some clipped samples. This is deliberate. I set the volume scaling so that I am right at the limit of the dynamic range available, and as a result some minuscule fraction (.01% or whatever -- 800 samples might seem like a lot, but audio has 40 000 samples PER SECOND) of samples are clipped -- nothing you can hear. If it bothers you, look through the script, read the sox man page, and change the numbers used for the two gain commands.

So, to summarize:

[crarko adds: I haven't tested this one. It's a long script, so instead of listing it I put it up for download (compressed) from here.]

Comments (1)


Mac OS X Hints
http://hints.macworld.com/article.php?story=20101001210648147