Whisper, Parakeet, and the Cost of Local Transcription
Meetily’s local transcription question begins after the audio pipeline has already chosen a device, normalized the signal, and marked a speech segment. The current application then has to decide how that segment becomes text: which local engine receives it, what metadata comes back, and how much model and hardware capacity the choice consumes. This chapter explains what Meetily’s common transcription interface standardizes, what Whisper and Parakeet still do differently, and why “local” is an operational model decision rather than a free feature.
The distinction matters because a transcript is not only a string. It may need to arrive in chronological order, carry a position in the recording, indicate whether the result is partial, and give the interface some signal about confidence. Two recognizers can both run on the same machine while exposing very different evidence about the text they produced.
One interface, two different recognizers
Meetily’s recording path accepts two local provider choices: localWhisper and parakeet. Other provider names are not accepted as the local engine for live recording. Both engines receive speech-oriented audio in a common form—16 kHz, mono, floating-point samples—and both return text through an asynchronous interface. The interface also allows for optional confidence and partial-result information, plus checks for whether a model is loaded and which model is active.
That shared interface is valuable because the rest of the application can manage a meeting without knowing every inference-library detail. The audio worker can hand a segment to an engine, wait for a result, and emit a transcript update. The same event can include the text, a recording-relative start and end time, a duration, a sequence number, and status information for the interface. The abstraction owns the workflow shape, not identical behavior.
Whisper and Parakeet differ at exactly that point. Meetily’s Whisper path wraps whisper-rs, the Rust binding used for the Whisper model family. It accepts a language preference, can let the model detect the language, and can request translation to English. It returns a confidence value and can mark short results as partial according to the application’s duration rule. Parakeet uses an ONNX-based model path. Its current provider wrapper does not expose confidence scores or partial results, and it warns that the language preference is not yet supported. The worker therefore has less model-provided information to show when Parakeet produces text.
A confidence indicator must be read in that context. Whisper’s current confidence is a simplified value derived from the returned segment text rather than a calibrated probability of correctness. Parakeet supplies no confidence value, so the event layer can use a display default when it needs one. Those values should not be compared as if “0.8” from one provider meant the same thing as “0.8” from another. The interface makes the field optional precisely because the evidence differs.
The same caution applies to partial results. In a live meeting, a partial result can make the interface feel responsive, but it may later be replaced or refined. A final result is easier to persist but may require waiting for the speech segment to close. Parakeet’s current wrapper reports no partial state, while Whisper marks short segments as partial under the application’s policy. That is a provider behavior visible through the common interface, not a guarantee of a uniform live-caption experience.
The worker’s handling of order is another deliberate choice. The code describes an optimized parallel transcription task, but its current worker count is one. The reason is chronological emission: if several segments were processed concurrently, a later segment could finish before an earlier one and reach the interface out of order. Serial processing gives the transcript a predictable sequence at the cost of giving up live concurrency. There are queue and completion counters, progress events, and a final check that compares queued and completed work. These mechanisms make the handoff observable, but they do not turn the current live path into a multi-worker system.
The event’s timestamps are recording-relative, not just wall-clock labels. That difference is important for a user who wants to click a transcript line and hear the corresponding audio. The worker uses the segment’s start time from the audio pipeline and calculates its end from the sample count. It also emits a sequence identifier so the receiving side can distinguish a new segment from a later update. Local transcription is therefore producing structured meeting evidence, not merely a paragraph to display.
The engine also has to defend against bad inputs and bad outputs. Empty or too-short audio is rejected before inference. Whisper results pass through cleanup routines that remove obvious repetition and patterns such as “thank you for watching,” which can appear when a model hallucinates from silence or poorly framed audio. This is a sensible response to the preceding VAD and audio-quality problem, but it is a heuristic. A phrase that happens to resemble one of the patterns could be removed from an otherwise valid result. Quality control reduces a known failure mode; it does not prove that every discarded phrase was wrong.
The causal picture is now clearer. VAD decides when a speech segment exists. The worker converts it into the recognizer’s expected sample format and chooses a local engine. The engine returns text with provider-specific limits. The worker attaches time and order, then sends the result to the interface and the recording-history path. Model choice changes the evidence available at the end of that chain.
Model files and the hardware budget
Running a model locally shifts the main cost from a provider bill and network request to local artifacts, memory, compute, and lifecycle management. Meetily keeps Whisper models in an application data directory, discovers them from a catalog, checks whether they look complete and have a valid model header, and loads one model at a time. The catalog offers smaller and larger Whisper variants, including quantized options; the configured default when no preference exists is large-v3-turbo.
Parakeet follows a different artifact shape. Its default is an int8 version of the Parakeet TDT model, stored as a directory containing several ONNX components and a vocabulary. The engine validates the expected files by exact byte counts before treating the model as available. That strict directory check is useful because a model is not one file that can be judged by a single header. A missing or truncated encoder, decoder, preprocessing model, or vocabulary can make the directory unusable even when some pieces are present.
These validation rules answer one question—“does the local artifact look complete enough to load?”—but not every question an operator may care about. They do not amount to an independent accuracy benchmark, and the examined code does not establish cryptographic provenance for every downloaded artifact. A file can have the expected shape and still require trust in its download source. Local inference begins only after the model has crossed that acquisition boundary.
Model size and quantization also change the meaning of “runs locally.” A larger model may offer a quality advantage in difficult speech, but it consumes more storage and makes memory pressure more likely. Quantization can make a model easier to download and execute on ordinary hardware, while the repository’s labels describe it in terms such as speed or balance rather than providing a cross-machine measurement. The right question is not which model has the most impressive name. It is whether the machine can keep the chosen model responsive while the audio pipeline and interface continue to operate.
Acceleration is a second layer of that decision. Meetily’s Rust manifest exposes platform-specific features for Metal and CoreML on macOS, CUDA and Vulkan on Windows or Linux, HIP/ROCm on Linux, and CPU-oriented OpenBLAS/OpenMP options. The build scripts try to detect the development SDK needed for an acceleration path. A graphics driver alone is not the same thing as a build environment that can compile and link the required backend. The current build documentation consequently distinguishes hardware detection, compiled features, and the final runtime choice.
The packaged and source-build paths can differ. The build guide says macOS packages enable Metal and CoreML, while Windows distribution builds use a Vulkan-enabled Whisper build; Linux users select an appropriate source-build configuration. A developer running a CPU-only build and a person using a packaged GPU-enabled build are not evaluating the same performance envelope. The repository gives configuration guidance, but it does not provide a benchmark that predicts transcription speed for a particular processor, graphics device, meeting length, or audio condition.
A practical selection decision therefore has several dimensions. If the priority is a small download and modest memory use, a smaller or quantized model may be the reasonable starting point. If the priority is difficult speech and the machine can sustain the cost, a larger model may be preferable. If the priority is stable live feedback, a model that keeps up with incoming segments matters more than a theoretical quality advantage that creates a growing queue. If the reader needs language hints, translation, confidence, or partial-result semantics, the provider capability matters as much as the model’s headline accuracy.
The model lifecycle also affects privacy. Whisper and Parakeet inference in the recording path can happen without sending the audio to a remote speech service. But the application includes download commands with external URLs, progress reporting, cancellation, and corruption handling. The model may arrive from a public host before it is used locally. An organization that treats model files as software supply-chain inputs must decide which hosts are allowed, how downloads are reviewed, and whether the package or source build is the approved route. Those questions are outside the recognizer interface but inside a defensible local deployment.
There is a useful asymmetry here. With a cloud recognizer, the provider usually owns the remote compute and the operator negotiates network, retention, and service availability. With Meetily’s local recognizer, the operator owns the machine, model files, runtime, and performance failure. That can be a strong privacy advantage because the original audio need not leave the workstation for speech recognition. It is also a responsibility transfer: an overloaded laptop, missing model, incompatible build feature, or corrupted artifact can stop the workflow locally.
That responsibility transfer changes how a failure should be interpreted. A missing model is not the same problem as a bad microphone. A model that fails validation is not the same problem as a recognizer that produces an empty result. The application exposes separate lifecycle states for downloads, model availability, loading, and transcription, so an operator can in principle locate the failed transition. The distinction is valuable in a local system because there is no remote service team silently absorbing the difference. The person running Meetily has to decide whether to download another artifact, choose a smaller model, change the build, repair the audio path, or accept that a particular session cannot be transcribed.
Consider three ordinary meeting conditions. On a modest laptop, a smaller or quantized model may preserve responsiveness, but the reader should validate the resulting transcript on the kinds of speech that matter rather than relying on the catalog label. On a workstation with a supported acceleration build, a larger model may be practical, but the benefit still depends on whether the audio arriving from the earlier pipeline is clean and well segmented. In a multilingual meeting, Whisper’s language and translation controls may be more useful than a provider that currently ignores a language hint. These are conditional choices, not a ranking of the two engines: the repository describes capabilities and defaults, but does not provide a common benchmark across hardware, languages, speakers, or meeting conditions.
The cost also appears at session boundaries. Loading a model consumes time and memory before the first useful transcript arrives. Keeping it loaded may make the next segment faster, but it retains a large local resource while the meeting continues. Unloading too early would risk interrupting queued work; unloading only after the worker drains the queue protects ordering and completeness at the price of a longer stop path. Meetily’s lifecycle code makes that ordering explicit, which lets the reader connect model management to the later storage question instead of treating loading as an invisible one-time setup step.
Meetily tries to make the lifecycle explicit. Models are initialized and validated before recording starts. The selected model is loaded before the worker processes speech. When recording stops, the application waits for queued transcription work before unloading the model, subject to its shutdown ceiling. After the engine emits its timestamped events, the next question is where those events become durable. A model that is private at inference time is only useful to the meeting owner if the resulting transcript can be stored, recovered, and reused without losing its relationship to the audio.
The central lesson is therefore not that Whisper is better than Parakeet or that one model is universally right. Meetily’s abstraction lets the application preserve one capture workflow while exposing meaningful differences in metadata, language handling, model artifacts, and resource cost. The user’s choice should follow the meeting’s conditions and the machine’s limits. Local transcription reduces one kind of network exposure, but it does not eliminate model provenance, build configuration, or runtime capacity as parts of the trust model.