A podcast editor’s worst nightmare: losing an audio track (recovering lost audio from Audacity)
It’s every podcast editor’s worst nightmare for an audio track to be lost. It means the whole episode is in jeopardy. For obj_podcast, we record a master audio track (sometimes called a sync track), which is a single track of all voices, directly off the Discord voice chat that we use for recording. It serves as a worst-case backup; but combining the low audio quality of the voice call, and the voices not being separated into tracks making it impossible to edit, it falls far short of the usual quality of released content.
So when one of the audio tracks is lost, due to data loss or in this case, a program crash, the whole episode is in jeopardy: it’s not possible to release an episode with a missing voice; it’s extremely hard to substitute the master audio in as a missing voice as its quality is low and often the voice is not “clean” due to other people interrupting; and while releasing the master audio as-is could be an option, it’s one best avoided as it is low quality.
Here is an example of the difference between Master audio (top track), and individual locally recorded audio tracks (everything below). It should be noted that the dial-in caller, Sushi, may have a different microphone setup. But the breakups of the audio due to variability of the internet is something that affects everyone from time to time; as is cases where people talk over each other — I have no ability to separate these when they’re all mixed into one track.
For the recording for obj_clubhouse episode 1 — Hollow Knight, we suffered this nightmare, but in double: not only did one of the hosts, Mimpy (Minty Python) suffer a program crash that wiped his entire recording (you can hear his reaction to that happening at the end of the episode, caught on the master audio); but I also lost the master audio, something I didn’t reveal to anybody at the time, and quietly despaired in private for a few minutes. The two losses would have meant the entire recording was lost, posting the low quality master audio wasn’t even an option. We were facing losing a combined 8 or 9 hours of collective recording time due to technical faults.
Mimpy’s and my crashes were different, Mimpy’s Audacity became non-responsive, while for mine I had caused the crash myself while trying to use another instance of Audacity, forgetting that I was still recording in another one. As a result while Mimpy’s audio was well and truly lost, fortunately I found all of the temporary Aduacity files for my recorded audio were still in the temporary folder, although Audacity’s automatic recovery failed to restore it. After some Googling, and scripting, I was able to recover my master audio (some notes on the method posted below).
Much to Mimpy’s credit, once I had recovered the master audio, he offered to completely re-dub his audio. This meant he would take the master audio, play it back, and re-record him saying the same words into a microphone. Something that takes a lot of patience since it involves listening through the entire episode, and likely making several attempts at saying the same words in a way that feels natural.
The results speak for themselves; the released episode has Mimpy’s re-dub seamless added. I simply cannot, and nor can anyone else I’ve spoken to, tell that Mimpy’s audio is a re-dub. It sounds natural, and in some places where I’ve had to blend master audio with the re-dub due to some rare omissions, aside from a slight shift in audio quality, you cannot tell that it had been done at all.
There was only one instance in which Mimpy fumbled his lines. Due to too many people talking at once in the master audio, he couldn’t hear what he was saying, and resulted in this amusing moment that until now only I got to hear. I wanted to share this with everyone to hear some of the process that goes on behind the scene. I’ve placed the master audio in the left channel, and Mimpy’s dub in the right channel.
Recovering lost Audacity audio due to a crash
Here’s a brief overview of the method I settled on to recover lost files (this is more of personal notes rather than a complete guide, just in case I need to refer back to this in the future).
Audacity stores its temporary recordings as several second-long audio clips in .au format inside your AppData/Local/Audacity/SessionData/<project name> folder. The first thing I did was to make a copy of them to avoid anything automatically deleting them. I wasn’t sure if launching Audacity would clear out any old temporary files, so I wasn’t about to risk it.
Unfortunately the folders within have somewhat randomized filenames, so are not necessarily in the right order. The file’s creation time however is probably correct for a single recording session, so that can be used to decide what order the files come in.
I used Python to dump all the files in these folders into a list, and sort them by their file creation times, then feed each file in turn through the open source audio processing tool SoX to convert them into WAV files.
Once converted to WAV files, I had SoX concatenate them all into a single file. This had to be done in a few different chunks due to some limitations on how many could be concatenated at once (I didn’t get down to why this was happening, but could have been a bug in my code).
Once concatenated, the final WAV file can be re-imported into Audacity as if the crash never happened.