Your Recordings Are a Search Problem, Not a Transcription Problem

Transcription stopped being the hard part some time ago. Whisper-class models are accurate across accents and crosstalk, they run on a laptop without a GPU rental, and any number of apps will turn a 90-minute interview into 12,000 words of text while you make coffee.

Then you have 12,000 words. The following week, another 12,000. By the end of a project you are holding a folder of transcripts that is, in the most literal sense, a haystack — one you created yourself, in a new format, to solve a problem that was never really about text.

Because the question you ask later is almost never *what did she say*. It is where was the bit where she talked about the funding falling through — and you are asking it about forty seconds inside one file out of sixty.

The three ways Cmd-F fails you here

Search a transcript the obvious way and it fails for three specific reasons, and it is worth naming them, because each one points at what the fix has to do.

You remember the idea, not the sentence. Nobody recalls verbatim phrasing from a conversation they had in March. You remember that someone described being pushed out of a company. They said "it was made fairly clear that I should start looking." There is not one shared word between what you remember and what you are searching for, and keyword search is a game of shared words.

The file boundary is in the wrong place. Cmd-F works inside a document. Your question spans the archive — *did anyone else mention that supplier?* — and answering it means opening sixty files one at a time, which is a task people simply stop doing after the fourth one.

Names come through wrong. Proper nouns are where every transcription model is weakest: the surname, the drug, the product, the town. Search for the correct spelling and the one passage you need is the one passage that does not match, precisely because it was the unusual word.

What a recordings archive actually needs to do

That last row is the one people underrate. A transcript is a compression of an interview with the tone removed. For quoting, checking, and deciding whether someone was joking, you want to arrive at the audio.

The upload question, which is not paranoia in this category

Most transcription services are cloud services. For a conference talk, fine. For the material that actually accumulates in a working archive, the calculation is different, because the recordings are usually the most sensitive files anyone owns:

• an interview given on condition it went no further than you
• a client call under an NDA that named one recipient
• a patient or participant who signed a consent form listing exactly who would hear it
• an internal review nobody intended to be a document at all

Uploading those is a disclosure event whatever the vendor's retention policy says, and retention policies are the part of a service that changes without anyone emailing you. If the recordings are covered by GDPR, HIPAA or the EU AI Act, the difference between processing on your own machine and processing on someone else's is the difference between a control you can demonstrate and an intention you cannot. It is the same reasoning that applies to privileged documents, with the added wrinkle that a voice is identifying on its own.

How this works when it runs on your own Mac

The pieces are not exotic any more, which is why this is now a reasonable thing to expect from a search tool rather than a pipeline you build.

1. Transcription. Dhito runs OpenAI's Whisper locally on Apple Silicon, using the Neural Engine, as recordings are indexed. No upload, and it works with the network off. 2. Segment-level indexing. This is the part that decides whether you get a moment or a file. The transcript is indexed in timed segments rather than as one block of text, so each passage keeps the timestamp it came from. 3. Semantic embedding. Each segment is embedded into the same index as your PDFs and notes — the same vectors that make "funding fell through" match "the round never closed". 4. A clickable timestamp. A result opens the recording at the second it was said, rather than handing you a file and a scrub bar. 5. Frames, for video. Screen-shared slides are sampled and read with a local vision model, so a number someone put on screen and never read aloud is still findable.

One consequence worth spelling out: because recordings land in the *same* index as your documents, a single query crosses both. You search once and get the clause in the contract PDF and the minute in the call where it was argued over. That is the thing a dedicated transcription app structurally cannot do, however good its transcripts are.

A workflow that survives a hundred interviews

1. Stop renaming files. Zoom Meeting 2026-03-14 11:02.mp4 is fine. The naming discipline you keep promising to adopt is not coming, and the index makes it unnecessary. 2. Put recordings under one tree — one folder, subfolders however you like — and point the app at it. Nested structure costs nothing. 3. Run the first index overnight. A large archive takes hours on the first pass. Everything after that is incremental. 4. Ask in your own words. "The part where he backtracked on the timeline" is a better query than any keyword you could guess, because it describes the meaning you remember. 5. Land, listen, then quote. Jump to the timestamp, hear the surrounding thirty seconds, and take the quote from the audio. Transcripts are for finding; recordings are for quoting. 6. Ask the file a question when you need the gist rather than a moment. Transcripts feed the same local document chat as your PDFs, so *what did we agree about the deadline* gets an answer pointing back at the moment it was said.

Where this stops

Worth knowing before you reorganise a workflow around it:

• No speaker labels. It indexes what was said and when, not who said it. For a six-person panel where attribution is the work, pair it with a diarisation tool.
• It is not a transcript editor. There is no clean-up pass, no subtitle export, no correcting a misheard surname so the fix sticks. This is a search layer, not a production tool.
• Bad audio stays bad audio. Semantic matching is forgiving — a query often matches on surrounding context even when a word came through wrong — but a phone in a coat pocket in a loud bar is not recoverable by anyone's model.
• Apple Silicon only. The vision and speech models run on the Neural Engine. macOS 13 or later.
• The first pass costs real time and disk. Local inference is free per query, not free in the abstract.

Test it against your own archive

Specification sheets cannot tell you whether retrieval works on *your* recordings, with your subject matter and your phrasing. Half an hour tells you more than any article, this one included.

Write down five moments you genuinely remember and genuinely cannot find — the ones that cost you an evening last month. Index one folder of real recordings, wait for the pass to finish rather than judging a half-built index, then search for those five the way you would describe them to a colleague. Count how many land in the top three results, and whether they land on the minute or just on the file.

Dhito's trial is 14 days with every feature unlocked, no account and no card, which makes that test cost you time and nothing else. Afterwards it is $4.99 a month or $99 once, with no per-minute transcription charge — the inference is running on hardware you already bought.

The recordings are already on the disk. What has been missing is a way to ask them anything.