A developer on V2EX just published a Python audio-to-text CLI. It does local Whisper transcription, falls back to the OpenAI speech API, exports TXT/SRT/VTT/TSV/JSON, and can route text through DeepL for translation. Needs Python 3.11+ and FFmpeg, MIT licensed. The author closed the post asking for feedback on three things specifically: long-audio transcription, recognition accuracy, and subtitle segmentation. The first reply was blunt — don't use Whisper if you care about accuracy.
That reply is more useful than it looks. It tells you where the fragile part of this tool is, and by elimination, where the durable part is.
The model call is the part you don't own
Accuracy depends on the model. Whisper gets second-guessed, OpenAI's API changes pricing and behavior, and the author themselves built in a toggle between local and cloud transcription because no single engine is a safe bet. If your tool's value lives in the model call, you're renting your value from someone else's roadmap.
The part that doesn't move is the step after transcription. Once you have timestamped segments, turning them into clean subtitle files is pure deterministic logic: merging short fragments, splitting lines that run too long, enforcing minimum and maximum cue durations, formatting timecodes correctly for SRT versus VTT, keeping byte offsets straight for TSV. Same input, same output, every time. No model, no randomness. That's the reusable asset. It's boring, and boring is exactly why it keeps its value when the model underneath gets swapped out.
I'd go further: this matches a broader signal across what builders are shipping right now. The job market one commenter described rewards people who can do agent application development. The experiments people are running — AI teams with assigned roles, AI-native boards that hand structured text back and forth for a human to adjust — all lean on the same idea. The valuable thing is a deterministic, inspectable unit that an agent can call and a human can correct. Not the generation step. The structuring step.
Split the tool at the FFmpeg line
So the plan is to cut the CLI in half and rehost the back half. But the cut has to be honest about a hard boundary.
Local Whisper models and FFmpeg decoding cannot move onto VicroCode. FFmpeg is a native binary that chews through audio containers, and local Whisper wants the model weights and compute on a machine you control. VicroCode gives you online Python execution, not a general media-processing box with arbitrary system binaries, so I'm not going to pretend the decode-and-transcribe stage can run there. It can't, and claiming otherwise would just produce a broken design. That whole front half — ingest the audio, run FFmpeg, run Whisper or hit the speech API — stays local or on infrastructure the user already owns.
What crosses the line is structured data. The local stage emits timestamped segments as JSON. That JSON is small, portable, and has no media dependency. Everything downstream of it is fair game.
Rebuild the export half as a hosted Python endpoint
Here's the architecture I'd actually build. The segmentation-and-export logic becomes a Python service you run Python online, exposed through API Endpoint Hosting so it's callable from the local CLI, from a script, or from an agent as a tool call. The endpoint takes the segment JSON plus formatting parameters — max characters per line, max lines per cue, min and max cue duration, target format — and returns the rendered TXT, SRT, or VTT. No audio ever touches it. It's a deterministic transform with a clean contract, which is precisely the kind of thing an agent can invoke reliably because the output is predictable.
Behind it sits a job ledger in SQLite. Every submission gets a row: source identifier, parameters used, which formats were generated, a version number, timestamps. When someone re-runs the same clip with tighter line limits, you get a new version instead of a silent overwrite, and you can diff them. Because this is a real database you can open and inspect, a built-in SQLite editor lets you fix a stuck job state or correct a mislabeled row by hand without writing a migration script for a one-off. For a small team or a solo operator, that direct-edit escape hatch saves a lot of grief.
A preview-and-edit board a human can actually use
The missing piece in most transcription CLIs is the correction loop. Machine subtitles are never cue-perfect — timing drifts, a line wraps awkwardly, a name comes out wrong. People fix these by hand, and the CLI gives them nowhere to do it except a text editor.
So the last component is an HTML board you run HTML online: load a job's cues into a simple table, edit text inline, nudge start and end times, re-split a line, then call the same export endpoint to regenerate the file. Save the corrected version back to the ledger so the edit is captured, not lost. This is the Lulu Board pattern applied to subtitles — the machine produces a structured draft, the human adjusts it on a canvas, and the result is shareable rather than a throwaway. If you want, the published project can be shared or monetized directly, since hosting and monetization are built in.
What this buys you, and what I can't promise
The trade I like here: the volatile model work stays where it belongs, and the stable, reusable half becomes a hosted, versioned, agent-callable service with a human correction loop attached. You can swap Whisper for the OpenAI API, or for whatever comes next, and the export endpoint doesn't care — it only ever sees segments.
Two honest caveats. I haven't benchmarked this against the original CLI, so any claim about speed, throughput, or output quality is unverified — the accuracy complaint in that thread is about the model, and moving export off-box does nothing to fix transcription accuracy. And there are no customer results or adoption numbers to point to here; this is a design derived from one shared tool and a handful of adjacent signals, not a case study with outcomes. Build the boring half well, keep the FFmpeg boundary where it is, and you've got something durable regardless of which model wins.