n8n Automation Hub
A pipeline that worked, right up until it met a real episode
The clipping pipeline's job is simple to describe: take a long video, pull the audio out with ffmpeg, transcribe it with Groq's Whisper API, hand the transcript to an LLM to pick the best moments, then render short clips from the result. Every piece of that had been tested — on short clips, a few minutes each, built specifically to exercise the pipeline without waiting around for a real download and a real transcription every time.
The first real production input was a podcast episode running close to seventy minutes. It failed at the very first network call the pipeline makes after extraction — the request to Groq's Whisper endpoint — with Request Entity Too Large.
The error Groq actually returns
The extracted audio file for that episode came out at 34.2MB. Groq's Whisper API has a hard 25MB limit per request, and the API doesn't chunk or downsample anything on its end — it just rejects the file. Nothing about the short test clips had ever come close to that ceiling, which is exactly why the bug had stayed invisible through every earlier test run.
The ffmpeg extraction step was set to -c:a libmp3lame -b:a 64k -ar 16000 -ac 1 — 64kbps mono, 16kHz sample rate. That's a perfectly reasonable setting for a two-minute test clip. It's also a setting that scales linearly with runtime, and nobody had done the arithmetic for a seventy-minute file before this ran.
Why a bitrate change was the right fix, not a workaround
The tempting quick fix here is to catch the error and split the audio into chunks before sending it — more moving parts, more places for the pipeline to break. The actual fix was smaller: drop the extraction bitrate to 32kbps mono. Whisper's transcription quality doesn't meaningfully degrade at 32kbps for spoken-word audio — it isn't music, there's no reason to protect frequency range that speech doesn't use — and cutting the bitrate in half cuts the file size in half for the same runtime.
The number that made the fix durable, not just a patch
32kbps mono at 16kHz stays under Groq's 25MB limit up to roughly 104 minutes of audio. That's not a guess — it's the actual ceiling this specific setting buys, and it's comfortably above every episode length this show has run so far. The fix isn't “make this one episode work,” it's “make the whole show's realistic episode-length range work without hitting this again,” which is the difference between a fix and a patch that fails again on the next slightly-longer episode.
What I'd check before the next long-form input
Any pipeline step whose resource cost scales with input length needs its test data to actually reach production scale at least once before going live — a two-minute test clip cannot surface a limit that only bites past the 25-30 minute mark. If a future episode runs past 100 minutes, the same math says drop further, to 24k or 16k, or split the audio into chunks before transcription instead of relying on bitrate alone.