Machine transcription is the easy half. The editor is the product.
A platform to turn audio and video into usable text, where the real engineering was not the recognition, it was building an editor a professional transcriber could work in all day.
Recognition is a component. Correcting it is the job.
The product had to accept whatever people have: FLAC, WMA and m4a audio, AVI, MPEG and MOV video, recorded in rooms rather than studios. Ingestion alone was a meaningful piece of work before any recognition happened.
Then the hard part. Machine transcription of real conversation struggles with dialect and accent, several languages in one recording, mispronunciation, overlapping speech, domain jargon and the pauses that make a sentence mean something different.
Which means the output always needs correcting, and the correcting interface is where the product succeeds or fails. Early builds had exactly the defects that make an editor unusable in practice: the cursor jumping position, keys not behaving as they do in every other editor, and inline editing that fought the user.
A purpose-built editor, and honesty about what the model cannot do.
We assembled a MEAN-stack team and treated the editor as the product, not as a wrapper around the recognition output. The cursor, key handling and inline editing problems were fixed at the root by building a dedicated editor component instead of patching behaviour onto a text area.
Recognition output is annotated, not presented as finished. Words the system is unsure of, sections it could not hear and passages where speakers overlap are flagged, so the transcriber's attention goes where the machine is weakest instead of being spent re-reading text that is already correct.
Multi-format ingestion is handled server-side with format normalisation, so the user uploads what they have, not converting first.
The APIs were built to be used by something other than this interface, on the assumption that transcription would eventually need to feed other systems rather than only ever end in a download.
What the platform does.
Multi-format ingestion
FLAC, WMA, m4a, AVI, MPEG, MOV and more, normalised server-side so the user does not convert anything.
Speech recognition
Transcription with per-segment confidence retained rather than discarded.
The editor
A purpose-built editing surface: predictable cursor behaviour, standard key handling, true inline editing.
Uncertainty flagging
Mispronounced, inaudible and overlapping passages marked so review effort goes where it is needed.
Playback sync
Audio position tied to text position, which is the single feature professional transcribers judge a tool on.
Export
Corrected transcripts out in the formats downstream tools expect.
APIs
Built for integration from the start rather than retrofitted.
MEAN, chosen for the editor as much as the API.
Front end
Back end
Data
Media
What the product got.
- An editor people could actually work in. The cursor, key and inline-editing defects were the reason early versions were abandoned by testers. Fixing them properly was the difference between a demo and a product.
- Review effort directed by confidence. Flagging uncertain and inaudible passages meant transcribers stopped re-reading text that was already right.
- Users upload what they have. Server-side normalisation removed the conversion step that had been the first point at which people gave up.
- Integration was possible later because it was designed for earlier. The API surface meant transcription could feed other systems without a rebuild.
