33 Releases Later: What Changed in SIMS v2t Since Launch

We released SIMS v2t on 27 March 2026 as v1.0: a drag-and-drop queue, YouTube and playlist support, a cloud API mode, an offline whisper.cpp mode, and one-click setup for ffmpeg and yt-dlp. That post is still up and everything in it still works.

It is also badly out of date. Between v1.0.0 (22 March) and v2.0.19 (8 August) there were 33 releases. This is the digest — what the launch post promised, what the application does now, and the three places where measuring something changed our own advice.

Then and now

| | At launch (v1.0) | Today (v2.0.19) | |---|---|---| | Output | .txt only | .txt, plus timed .vtt and .srt, plus optional *.info.json media sidecar | | Speakers | — | Person 1 / Person 2 — English via tinydiarize, any language via post-ASR pyannote | | Engines | Cloud API or local whisper.cpp | Both, plus in-app WASM, plus large-v3 locally | | Hardware | CPU | CUDA / Vulkan / CPU with GPU auto-detect and automatic CPU fallback | | Sources | YouTube, playlists, files, folders | The same plus TikTok, direct media URLs, Castbox podcast channels, and 1000+ yt-dlp sites | | Automation | GUI only | Local REST API — jobs, batches, SSE, signed webhooks, Swagger UI, SQLite persistence | | Interface | English | 8 languages — EN, UK, RU, DE, ES, FR, PL, PT | | Setup | One button for tools | Setup guide branched by profile: Simple / Quality / Power | | Queue | One sequential queue | Two queues — download and transcription — with independent limits and backpressure |

Timestamps, and one decision behind them

The single biggest change is timed output. From v2.0.8 an optional WebVTT file is written next to every transcript, with millisecond segment timestamps, from every mode: local whisper.cpp, HTTP API, in-app WASM, and the YouTube subtitle path.

The decision worth naming is in v2.0.9: plain text is now built from the same timed segments as the WebVTT. Before that, the two were produced by different code paths and could word things differently. One export could say something the other did not.

And when timestamps cannot be produced honestly, the job fails and says so. There are no synthetic times anywhere in the pipeline — if an HTTP provider does not return usable segment timings and you asked for WebVTT, you get a clear error rather than a file full of plausible numbers.

We benchmarked it, and it changed our default

We ran the same 22.6-minute English meeting through several engines and compared each against Microsoft Teams captions and YouTube auto-captions. Overlap is Jaccard on unique word tokens, case-insensitive — higher is closer to the reference.

| Engine | vs Teams | vs YouTube | Cost and time | |---|---|---|---| | OpenAI whisper-1 (HTTP) | 0.90 | 0.90 | ~50 s, ~$0.14 for this call | | Local large-v3 (CUDA) | 0.90 | 0.92 | ~1.6 min on an RTX 3060 Ti, $0 | | YouTube auto-captions | 0.89 | — | external reference | | Local medium | 0.83 | 0.85 | solid when disk or VRAM is tight | | Local large-v3-turbo | 0.64 | 0.65 | faster, but hallucinated and looped on this file |

Three things came out of that table, and all three are now our advice rather than our marketing.

large-v3-turbo is not a free upgrade. It is faster and it scored 0.64 where large-v3 scored 0.90 on the same audio. It had been an attractive default. Verify it on your own material before trusting it with a long meeting.

A local GPU matches the paid cloud call here. large-v3 on a mid-range RTX 3060 Ti scored the same as whisper-1 against Teams and slightly better against YouTube, at zero cost per minute and with the audio never leaving the machine.

gpt-4o-transcribe and gpt-4o-mini-transcribe are not drop-in replacements for long recordings. They hit output-token caps and return truncated text unless you chunk the audio yourself. We say so because we tried it, not because we prefer the alternative.

One spot-check we kept because it is more honest than the averages: on the phrase "bulk upload", Teams, OpenAI and local large-v3 all produced bulk. Local medium frequently produced Bork. An aggregate score of 0.83 does not tell you that your domain vocabulary is the part that breaks.

The bug we would rather not advertise

In v2.0.1 we fixed this: API keys were not being saved at all.

The keyring crate had been added without a platform backend. In version 3.x that silently falls back to an in-memory mock store — every write reported success and went nowhere. After a restart the key read back empty. Both keys were affected: the transcription key and the Gemini Vision key.

It is worth writing down because of the shape of it. Nothing errored. The save button worked. The code path ran to completion and reported success, and the only symptom was a key that was gone the next morning. A store that accepts writes and keeps nothing looks exactly like a store that works, right up until you read. Native backends are enabled now, keys land in Windows Credential Manager and the macOS Keychain, and anyone who lost a key needs to enter it once more — those keys were never anywhere to recover.

Automation: v2t as a pipeline component

From v1.8.0 v2t runs a local HTTP server on 127.0.0.1 while the app is open, so another service can hand it work:

• POST /v1/jobs for a URL or a local file, GET /v1/jobs/{id} for status, GET /v1/jobs/{id}/transcript for the text
• POST /v1/batches for up to 1000 items, with atomic validation — an error in item N rolls back everything already registered
• GET /v1/jobs/{id}/events as SSE for live progress
• Signed webhooks on completion: HMAC-SHA256 in X-V2T-Signature, an idempotent delivery id, three attempts with exponential backoff, no retry on 4xx
• Swagger UI and OpenAPI 3.1 at /v1/docs, suitable for client code generation

v1.9.0 added SQLite persistence, so job history survives a restart — and jobs that were running when the app stopped come back marked interrupted rather than quietly disappearing or pretending to have finished.

The limits are deliberate and documented: it binds to localhost only, with no LAN access and no CORS. If you want a remote consumer, put your own backend in front of it.

Skipping the work entirely

Some videos already have a human-written transcript. From v1.6.0, if a single YouTube video has manual subtitles in one of your priority languages, v2t takes the subtitle file and skips both the download and Whisper. Those jobs are marked 📝 in the queue so you can see which transcripts came this way.

Auto-generated captions are deliberately not used: on Ukrainian and Russian they were consistently worse than Whisper medium. Faster and worse is not an optimisation.

Eight languages, and what we will not claim about them

v1.7.0 localised the interface into English, Ukrainian, Russian, German, Spanish, French, Polish and Portuguese — 344 keys per locale, 2752 translated strings, with a CI gate that fails if a key is missing or empty in any locale.

The translation was done by a local Ollama model overnight on the same RTX 3060 Ti, against a v2t glossary, with automated checks for placeholder drift and lost glossary terms. Ukrainian and Russian had human review. German, Spanish, French, Polish and Portuguese did not. They are good enough to ship and they are waiting for bug reports from people who actually work in them. This is an MIT project with a small number of reviewers, and saying "eight languages, all reviewed" would have been the easier sentence to write.

Backend error messages and the [yt-dlp] … / [ffmpeg] … log stream stay in English on purpose — that text ends up in support tickets.

The unglamorous half

Most of 33 releases is not features. A sample of what real files and real sites actually did to us:

• TikTok returned video with no usable audio. The root cause took three releases to reach: yt-dlp was picking an HEVC format whose MP4 has no playable audio track even though the format list claims AAC. TikTok URLs now request H.264 + AAC directly.
• Playlists overwrote themselves. With a filename template that had no {track}, every entry wrote to the same .txt, and resume then skipped tracks 2…N as "already done". Entries now get _t1, _t2 automatically, and kept videos go into a per-playlist folder.
• Temp files leaked. Work directories are now always removed after success, discarded on stop, and orphans older than two hours are swept at startup.
• Bulk queues were getting IP-blocked. The download pacing default went from 1.5 s to 20 s with jitter, with backoff on 403/429/503, and a TikTok IP block is now reported as exactly that instead of being retried as a soft rate limit.
• A stuck progress bar. After download, the queue says Waiting for transcription… instead of showing a yt-dlp bar frozen at 100%.

Get it

v2t is free and MIT-licensed. Downloads and the full changelog are on GitHub.

If you are coming from v1.0: turn on Export timed transcript as WebVTT, and if you have an NVIDIA card, use local large-v3 with GPU acceleration. That combination is the one we measured, and it is the one we use ourselves.