Artificial Intelligence
Transcriptor
Transcriptor converts audio and video into readable, speaker-separated transcripts locally. It combines speech recognition with speaker diarisation, and after the first model download it works completely offline.
01 — The problem
What was actually happening
Meeting and interview recordings are only useful once they are text — but the convenient options all send confidential audio to a third-party service and bill by the minute. The free options return an undifferentiated wall of text with no indication of who said what.
- Cloud transcription means uploading recordings that often contain confidential business conversations.
- Per-minute pricing makes routine use of long recordings hard to justify.
- Without speaker labels, a multi-person transcript is close to unreadable.
- Command-line AI tooling is usually too hostile for anyone who is not already comfortable with Python environments.
02 — The solution
What I built, and why
Run the whole pipeline locally and hide the machinery. Audio is extracted, transcribed and split by speaker on the user's own hardware; the interface is a single command you can drag a file onto.
- Speech recognition and speaker diarisation combined into one pass, producing `Speaker 1:` / `Speaker 2:` formatted output.
- Speaker count detected automatically per recording — nothing to configure.
- Selectable model size, trading speed against accuracy depending on whether you need a quick draft or a final transcript.
- Watch mode: point it at a folder and anything dropped in is transcribed automatically.
- Native desktop notifications on completion, because a long recording can take a while and nobody should have to watch a terminal.
- Dependencies resolved automatically from an inline manifest — no virtual environment for the user to manage.
03 — Process
How the work was sequenced
- 01
Define the real requirement
The requirement was not 'transcription' — it was transcription that could be used on confidential material without a procurement conversation. That ruled out the entire hosted category.
- 02
Evaluate the models
Compared speech-recognition model sizes on CPU-only hardware to find where accuracy stops improving faster than runtime degrades, and set the default there.
- 03
Solve the readability problem
Added a speaker diarisation stage and aligned it with the transcript, turning a wall of text into a conversation that can actually be read.
- 04
Remove the setup
Collapsed installation to one command, moved the one-time credential step into a first-run prompt, and cached it so it is never asked again.
- 05
Design the interaction
Made the common case trivial — type the command, drag a file in, press Enter — and kept flags available for the less common ones.
- 06
Harden for long jobs
Added batch input, watch mode and completion notifications so multi-hour runs fit into a working day instead of interrupting it.
04 — Technology
The stack, as decisions
Intelligence
Application
Experience
05 — Results
What it changed
$0
Per hour of audio — no API keys, no per-minute billing
Offline
After the initial model download, nothing leaves the machine
Auto
Speaker count detected per recording, no configuration
Running models locally is a product decision before it is a technical one — it changes what the tool is allowed to be used for. The engineering that mattered most was not the model pipeline, it was removing every setup step between a person and their first transcript.
Have a problem worth solving?
Tell me what the process looks like today and where it breaks. If technology is the right answer, I will tell you what I would build — and if it is not, I will tell you that too.