Two-Host Podcast: Hum, Clock Drift and Loudness Delivery
You are post-producing a weekly 90-minute interview podcast. Host A records locally to WAV at 48 kHz/24-bit on a laptop. Host B records through a USB interface at 44.1 kHz/16-bit on a different machine in another city. The two files are aligned by hand in the editor. Listening tests reveal: a steady low hum on A with audible harmonics; sharp pops on B's plosives; a faint broadband hiss on both; and, by the 80-minute mark, the two speakers have drifted about half a second apart, so laughs and interruptions no longer line up. The show currently ships at about −22 LUFS integrated with peaks at −0.2 dBFS true peak. Distribution goes to a podcast host, YouTube, and a broadcast affiliate that requires EBU R128. The producer wants the whole chain documented so a freelancer can repeat it next week.
1. Specify the correct order of the repair and mixing chain, and justify why each step must precede the next.
Read the worked answer
Documented chain, with reasons:
- Session setup and sample-rate conversion. Bring B's 44.1 kHz file to the project rate once, using a high-quality sample-rate converter (soxr, SSRC or the DAW's best setting) at 24-bit, before any processing. Doing it twice, or after dynamics processing, compounds rounding and can smear transients.
- DC offset and hum removal. Remove the 60 Hz fundamental (or 50 Hz, depending on mains) and its harmonics with narrow notch filters, Q chosen so the notch is a few Hz wide. This must come first: the hum sits in the same band as male fundamental frequencies, and any later EQ boost or compression would lift it.
- Click and plosive repair. De-plosive before compression, because a compressor reacts to the low-frequency energy burst of a plosive and pumps the whole programme down for a moment afterwards.
- Broadband noise reduction. Spectral denoising before compression, because makeup gain raises the noise floor in quiet passages; denoising after compression leaves the artefacts of the compression baked in.
- High-pass filter around 70–90 Hz for rumble and handling noise, then tonal EQ.
- Dynamics: gentle compression, then de-esser. De-essing after compression because compression tends to exaggerate sibilance.
- Loudness normalization and true-peak limiting, last. Every prior step changes gain and integrated loudness, so measuring earlier is wasted effort.
Log the exact settings at each stage. A freelancer reproducing this needs parameter values, not just step names.
2. Explain the half-second drift at minute 80, and evaluate three possible fixes, including whether a sample-rate conversion alone solves it.
Read the worked answer
Cause. The two recordings were captured on two independent, unsynchronised clocks. Consumer and prosumer converters are specified to within tens of parts per million, but a typical 30–100 ppm mismatch between two devices is enough: at 60 ppm over 4800 seconds the offset is 0.29 s; at 100 ppm it is 0.48 s. That is the half second observed at minute 80. No amount of resampling to a common nominal rate removes it, because the two files are internally consistent - they simply count seconds at slightly different speeds.
Fixes:
- Word clock or a single interface (prevention). Both hosts record on one machine, or both interfaces are clocked from one source. Best fix; costs hardware and coordination.
- Record a sync event at start and end. A hand clap or a shared audio beep at the top and the tail. Measure the offset between the two events, then apply a pitch-preserving time-stretch (or a variable-speed correction) across the join points. Because drift is linear, segmenting the file into five-minute chunks and trimming or padding a few milliseconds at each boundary keeps each chunk under a couple of milliseconds off - inaudible.
- Deliberate off-nominal resampling. If B's file is treated as 48000 × (1 + 60 ppm) = 48002.88 Hz, resampling to 48 kHz compresses the timeline by exactly the drift, once, over the whole file. This is mathematically clean and preserves pitch if the tool does a proper rational resample, but it requires knowing the drift precisely from the sync events - it is not a blind conversion.
A plain 44.1 → 48 kHz conversion does not help at all: it corrects a format mismatch, not a timing mismatch.
3. The show ships at −22 LUFS with peaks at −0.2 dBTP. Recommend a loudness target and peak ceiling for each destination, and explain the reasoning.
Read the worked answer
Two separate problems: the programme is too quiet, and its peaks are too close to full scale.
Loudness. Integrated loudness targets differ by platform: podcast platforms and Spotify normalize playback to roughly −14 LUFS, Apple Podcasts around −16 LUFS; YouTube normalizes to about −14 LUFS; the broadcast affiliate requires EBU R128, which specifies −23 LUFS integrated with a −1 dBTP ceiling. Shipping at −22 LUFS means every streaming destination turns the programme up, which raises the noise floor and can make the denoising work audible - and it will sound flat next to other shows.
Recommended masters:
- Podcast RSS master: −16 LUFS integrated, −1 dBTP. This sits at or below every major platform's normalization target, so nothing is turned up and the noise floor stays where it was mixed.
- YouTube master: −14 LUFS integrated, −1 dBTP, if you want to avoid the platform's own gain change; or reuse the −16 master and accept a 2 LU boost. Consistency across episodes matters more than the exact number.
- Broadcast affiliate master: −23 LUFS integrated, −1 dBTP, separate deliverable. Never ship the podcast master to the affiliate.
Peak ceiling. −0.2 dBTP is dangerous: AAC or Opus encoding at 128 kbps can overshoot the source by 0.5 dB or more, and intersample peaks that are invisible in a sample-peak meter will clip downstream. Set a true-peak limiter at −1 dBTP, and measure with a true-peak (oversampled) meter, not a sample-peak meter.
Also check channel configuration: if the mix is dual mono, loudness meters may sum the channels; measure in the delivery configuration to avoid a 3 LU surprise.