Why Audio CLIs Are Shaped for AI Agents

It's who suddenly needs them.

And the surprising answer is: quite a lot, and the reason why is older than the agents.

The framing I'd put on it — this isn't a listicle of binaries. It's a category of software written for humans typing, that turns out to be perfectly shaped for machines typing. ffmpeg is the universal transcoder; the interesting work, noise profiling, loudness measurement, tagging, transcription, lives in specialist tools that each do one thing better than any GUI.

Some of these tools rewrite your audio, and some deliberately never touch a sample. SoX and ffmpeg-normalize change the sound itself. rsgain and loudgain only write metadata and let the player adjust at playback. That's an archival decision hiding inside a technical one. And the oddity that pays off later: the most capable of all of them, SoX, hasn't had a stable release since 2015. February twenty-second, version 14.4.2. Over eleven years. Still out-features most editors at what it does.

Two things ffmpeg is clumsy at. Noise profiling — you find a silent stretch of the recording, the room tone, and you tell SoX, build me a profile of exactly this noise. Then a second pass subtracts it from the whole file. The recipe is two commands: profile from the first second of silence, then apply it with a reduction amount around 0.2. And the amount matters — the safe range everyone quotes is 0.20 to 0.30. Push above roughly 0.3 and you get what the literature charmingly calls metallic bubbling artifacts.

Your studio is fine, I've mixed in it. The second power is silence detection — threshold and duration rules for trimming dead air, so a tool can find and cut the gaps without anyone selecting anything with a mouse. Then there's pitch and tempo as separate operations, which is harder than it sounds, dithering, resampling through libsoxr, and it'll host LADSPA plugins. Plus soxi for probing files, play and rec for capture.

It's beautiful. The SoX man page says it's "particularly suited to making quick, simple edits and to batch processing. If you need an interactive, graphical audio editor, use audacity(1)." The command-line tool itself points you at the GUI for interactive work. That's the division of labour this whole episode is about, written down by the tool's own authors a decade before anyone said "agent."

Now, the paradox. Last stable release 2015, last repository push 2023, unmaintained upstream — and it ships on every Linux distro by default and still beats GUI editors at noise profiling and silence detection. I don't know what to do with that. There's no successor. Nobody rewrote it. It just... Stopped changing because it finished.

Would you build a workflow for an agent on top of something with no maintainer?

Loudness normalisation is the category where the CLIs beat GUIs outright, no argument. Three tools, three jobs. ffmpeg-normalize is the batch workhorse — v1.44.0 landed on November ninth, so five days ago, adding a verify pass that checks the output level actually landed where it should. It does EBU R128 two-pass by default, and the podcast preset targets minus sixteen LUFS, which is the AES standard for spoken word.

Broadcast loudness standards migrated from peak measurement — which tells you nothing about perceived volume — to integrated loudness, and speech sits louder than music masters. AES settled on minus sixteen LUFS for podcast delivery; music normalisers like loudgain target minus eighteen. The interesting flags are the agent-shaped ones. Batch mode shifts every track on an album by the same amount, so the relative loudness the mastering engineer built survives. Threshold skips files already at target. Print-stats gives you per-file status — normalized, skipped, error — and a non-zero exit code if anything failed.

It's everything. An agent can't watch a progress bar. A non-zero exit code is a machine-readable sentence that says "I failed, check my output." And there's print-summary, before-and-after loudness tables. This is a tool describing itself in text, which — hold that thought, because part two of this conversation is entirely about that.

Try doing that by hand in a GUI. You'd measure each track, compute the offset that gets the loudest one to target, then apply that identical gain to the rest, track by track, hoping you don't clip. Forty clicks and one arithmetic error and your quiet ballad is now louder than your opener. One command, and the relative dynamics survive intact.

rsgain, version 3.8 as of September, writes ReplayGain 2.0 metadata and leaves the audio stream untouched. The README is blunt about it — batteries included, scan your whole library with no external scripts. And it's the backend for the MusicBrainz Picard ReplayGain plugin, so the GUI people are driving the same engine through a wrapper. loudgain does the same job with mp3gain syntax at minus eighteen LUFS, and its documentation says it "will never modify the actual audio data." Emphasis theirs.

And a good agent should ask. Tagging is reversible — the file is bit-identical, the player adjusts at playback. Baking is universal — every player, every car stereo, every bad conference laptop plays it right. You trade reversibility for reach. That's an archival decision, and the human should be in it, but it's the only place the human needs to be.

Tellingly. r128gain was the earlier fast scanner, and its author retired it — his note says when he first wrote it there was simply no solution on Linux, and now there are several better maintained alternatives, and he recommends rsgain. A developer pointing you away from his own tool because the field passed him by is the healthiest thing in open source.

beets. The music library manager for, in its own words, obsessive music geeks. Sixteen thousand stars, version 2.14.1 in September. It matches your files against MusicBrainz and Discogs, fixes wrong titles — the README shows it correcting "White Light Generation" to "Whitelightgenerator" at ninety-eight-point-four percent similarity, which is a typo somebody made on purpose or by falling asleep — fetches album art, finds duplicates, and its convert plugin wraps the specialist encoders for lossless-to-lossy conversion. Underneath it sits mutagen, the Python tagging library, and below that id3v2, metaflac, AtomicParsley for the odd containers.

Then the newest layer, and the most agent-native: transcription. whisper.cpp ships whisper-cli, dramatically faster than the Python original, but it's fussy — it wants 16 kilohertz mono WAV, nothing else. So every real workflow pipes ffmpeg in front of it to do the conversion, then runs the large-v3-turbo model, and out comes subtitles and text. We did a whole episode on building your own Whisper-style setup, and the pipeline hasn't changed shape — it's just acquired company. Tools built explicitly for agents now. trx bills itself as an agent-first CLI for transcription, with JSON output, a fields flag, and a dry-run flag it says are designed for AI agents. Its init command installs whisper-cli, yt-dlp and ffmpeg, plus — its words — the agent skill for your AI coding tool. And holarchic's transcribe takes a batch of links or files and emits text and subtitle files per input, no API keys.

The tools are courting the agents. That's new, and it's the bridge to the second half of this, because the natural question is: why would a command-line tool be easier for an agent to drive than a GUI? And there's an actual answer, with numbers.

The structural argument comes from a paper this year called "Terminal Is All You Need." Representational compatibility — LLMs generate text, terminals consume and produce text, tool invocations correspond to shell commands, parameters to arguments, output arrives through standard text streams. Their line: "No additional perception or translation layer is required." A GUI agent has to solve a perception problem before it can act at all — interpret pixels, compute coordinates, map them to motor actions — and that translation layer is, in their words, the primary bottleneck for GUI agent performance.

That's better than my version. The numbers make it visceral. On OSWorld, the best model manages about twelve percent task success against seventy-two for humans. Frontier web agents show up to fifty-nine percent lower success on realistic tasks than on simpler benchmarks. And the constructive side: a carefully designed text-based agent interface beat the default Linux shell by nearly eleven percentage points on SWE-bench, and code-as-action beat JSON function calling by up to twenty percent. The terminal isn't a legacy holdover the agents will replace — the paper calls it a design exemplar whose properties any agent-facing modality has to replicate.

There is, and it makes the argument better. A matched benchmark this year — four hundred and forty desktop tasks, eighteen applications, identical goals and final-state verifiers. The strongest GUI agent hit fifty-nine percent full pass. The strongest CLI agent, original skills, forty-eight. GUI wins the headline.

But. Only thirty-seven-point-six percent of the verifier checkpoints could even be satisfied by the original skill interface. The CLI agent wasn't weaker — it was under-described. When the authors patched the skills, guided by the verifiers, CLI rose to sixty-nine-point-three percent. And I have to say this carefully: that sixty-nine is a coverage-controlled diagnostic upper bound. It used verifier information. It is not what you get out of the box. The authors' own conclusion is that much of the CLI deficit comes from incomplete skill coverage rather than model capability alone.

The skill layer is the product. That's the reframe. A good CLI in twenty twenty-six isn't just powerful — it describes itself. Meaningful exit codes. Print-stats. Dry-run. JSON output. And look back at part one: ffmpeg-normalize's non-zero exit on any failed file, trx's agent-first flags. Those aren't conveniences. That's the tool knowing who's driving it.

The paper's archetypal desktop task, the opening example — renaming three tracks in Audacity. The benchmark that beat the CLI opens with an audio task. Audio is the ideal test case because the CLI tools already exist, they're mature, and for batch work they're strictly more capable than the GUI. This episode is the benchmark's own example.

Pottage was the everyday meal of most medieval English peasants, eaten day after day, varied only by what the garden and the season allowed.

The mainstream version of the argument ran in The Register in March. "Google knows asking agents to navigate GUIs designed for humans is ridiculous. Microsoft might not." Their thesis: Microsoft put Copilot inside the apps, where it lacked anything except local context, while everyone else now wants agents that operate apps from outside. And for that, "an agent needs a universal interface that's easier to operate than the GUI. So say hello — again — to the command line interface." Their prediction is nearly every major software provider scrambling to ship CLIs. They call it a SaaSpocalypse.

A CLI for Workspace — installs skills that teach an agent Docs, Drive, Calendar, Gmail, Sheets. The scramble has started. Now, the concrete part. Daniel asked what you can actually get done that used to be an hour in Audacity, so let's walk it. Podcast episode prep. Normalize to the podcast preset at minus sixteen LUFS, then a SoX silence pass to trim dead air, then noise reduction — either SoX's profile-and-subtract or ffmpeg's arnndn, the neural one, where you blend the cleaned signal back toward the original at a mix around 0.7 so it stays natural.

In a GUI it's import, select, loudness normalization, capture a noise profile, manually select every silent stretch, export. Dozens of clicks, and it doesn't repeat across forty episodes, which is the real killer — the GUI version doesn't scale to a back catalogue. The agent version is the same pipeline every time, and the agent assembles it from a sentence.

Album-preserving batch normalization across a folder of files. A whole-library rsgain pass — one command over the mounted drive, every file tagged, not one sample touched. Library rescue: import against MusicBrainz, convert, find the duplicates. Transcript plus show notes: ffmpeg to sixteen-kilohertz mono, whisper-cli with large-v3-turbo, subtitles and text, then any model summarizes.

The detail that closes the loop — write-encoder-settings. ffmpeg-normalize stamps the exact ffmpeg-equivalent command and the measured loudness values into an ENCODER_SETTINGS tag inside the output file. So the agent's work is auditable later. The file carries its own provenance, in text, that another agent can read.

And the inversion worth sitting with: in audio, the CLIs came first and the GUIs came second. Audacity was the friendly wrapper around things like SoX. The agent era isn't handing ordinary people something new — it's restoring the original order. Whether an agent should prefer maintained ffmpeg or the unmaintained-but-still-superior SoX for the jobs SoX wins, no source settles. I don't know the answer.

Hilbert.

You're running controlled noise-reduction trials across microphones.

The unchanging room is part of the benchmark, then.

That's the strange part — his log is the one thing in this whole episode that's already machine-readable and agent-auditable, and he built it with a pen.

So where does that leave the open questions. Nobody has isolated agents driving audio CLIs specifically — the closest study is the benchmark whose example task is renaming tracks in Audacity, and it doesn't pull audio tools out as a category. And no mainstream GUI audio editor ships an official agent interface. The agent-facing layer, the trx-style wrappers, is being built entirely outside the editors, by third parties wrapping CLIs that already existed.

If the skill layer is the product, then the tools that win aren't the most powerful ones. They're the ones that describe themselves best in text — exit codes, machine-readable output, dry runs. Which means SoX may be the most capable tool we named today and the least ready. It out-features everything and it tells you almost nothing about itself in a form an agent can check.

If you take one thing from this episode, take the exit code. The reason an agent can drive these tools flawlessly isn't raw intelligence — it's that the tool answers in text and fails in text. Everything else, the pipelines, the batch passes, follows from that one property.

Which leaves us with Hilbert Flumingtop at the desk, producing this show as he does every day, and the strange thought that his notebook is the oldest skill interface we've ever discussed on air.

We'll be back soon. My Weird Prompts is at my weird prompts dot com — the archive is there, all of it.

See you tomorrow, everyone.