AivoRelay is a free, open-source dictation and transcription app for Windows. Press a global hotkey, speak, and insert the result into most Windows apps. Use local models when privacy matters, or connect your own cloud API key for Gemini 3.5 Transcribe, Gemini 3.5 Transcribe Live, Soniox, Deepgram, Groq, or another compatible provider. It also includes transcription profiles, custom vocabulary, live preview, audio-file transcription, AI-assisted text replacement, and a browser relay for sending text and screenshots to AI websites.

Source and download:

https://github.com/MaxITService/AIVORelay

My team at Bandwidth Labs has been working on something for a while that I'm pretty excited to finally put in people's hands.
We set out on this journey after building voice agents and working with customers to deploy them. When we started I was pretty impressed with how good transcription models actually were as far as accuracy goes… But they left a lot to be desired when we introduced real world telephone calls. On top of that as we wrestled to claw back all the milliseconds we could, the way transcriptions were handled became an area of research for us.

We built our own Speech to Text model from scratch.

The goal was to build it from day one to be streaming native, and pay extra attention to things like:
• 8khz telephone audio and challenging acoustic conditions
• Low Latency
• Not having partial transcripts constantly changing underneath you
• Efficiency that would allow us to deploy it at our network edges for optimized latency

It supports μ-law, A-law, G.722, Linear16 and Opus, including 8khz phone audio.
You get per word timestamps, and we also have keyword boosting, PII redaction and normal “offline” style transcription endpoints as well. In our testing we measure sub 60ms to final transcript when using the streaming modes.

Our model only emits stable words, even while streaming. Once we emit a word, we don't go back and revise it. In our own testing against the OpenASR Leaderboard tests we are seeing an overall average WER of 4.225% (official test results coming soon). We also evaluate against some internal benchmarks around real world common telephony quality and conditions and feel it does really well.

In our own agent use cases this allows us to begin executing work early as soon as something of value shows up while a user is speaking. This can often dramatically reduce voice agent latency.
It's English only right now. And it’s experimental, especially the word boosting and PII redaction - so we would love for the community to try it out, and give us some feedback.
There's a browser demo at https://labs.bandwidth.com/experiments/speech-to-text that doesn't require an account if you just wanna try it real quick, and if you sign up for a labs account you can get free access to the model while it’s on labs via API.
One important disclosure: this is a research/beta service. We monitor usage and may retain and review audio, transcripts and related data submitted to the experiment so we can evaluate the model, investigate failures and improve it. Full details are in the Labs terms.

If you build voice agents or voice Apps, or tinker in this space at all - come try it out and let us know what you think.

Working with a large physician dictation corpus at work (i'm at shaip, flagging that upfront so it's not a stealth vendor post) and the channel split surprised me. telephone dictation is close to half the total hours, smartphones next, dedicated speechmics a small fraction. so narrowband is still the dominant real-world input for clinical documentation, not the clean stuff.

For anyone building medical ASR — do you upsample the 8k telephone audio to 16k and train one model across everything, or keep separate models per channel and route at inference? i've seen both argued and no clear answer.

Related thing i'm unsure about: does adding wideband data actually improve narrowband WER, or does it just make the model overconfident and hurt on the noisy telephone side?

And one more — specialty distribution is heavily skewed, cardiology is a huge chunk while psychiatry and derm are tiny. does specialty-balanced sampling move WER at all, or is that purely a language model problem and the acoustic side doesn't care?

Hey there! would greatly appreciate if someone could drop me some advice.

I'm building an iOS app that may transcribe several hours of a user speaking a day (not simultaneous)

My currently problem is latency. With api's like Gemini, uploading a 5 minute recording and waiting for the full transcription is too slow.

can either be locally or not, is there a way to make it transcribe not long after you stop talking?

What would you use today?

​Hi everyone,

​I’m working with long audio recordings (several hours of MP3s) that have noticeable background noise, room reverb, and inconsistent quality. My goal is to clean up the speech and get accurate text transcriptions.

​I'm open to both cloud-based APIs/services (like Adobe Enhance Speech, AssemblyAI, Deepgram, ElevenLabs, OpenAI API) and local open-source models (like Whisper Large-v3, DeepFilterNet).

​For those who handle long, noisy recordings regularly:

​Best Pipeline: Do you recommend running the audio through a dedicated voice enhancer/denoiser first (e.g., Adobe Enhance, ElevenLabs Isolator, DeepFilterNet), or does modern ASR (Whisper Large-v3, Deepgram Nova-3, AssemblyAI) handle raw noisy audio well enough on its own?

​Tool Recommendations: What are the most reliable cloud services or Web/CLI applications for processing multi-hour files without hitting file size limits or timing out?

​Hallucination Prevention: Any tips or API parameters (VAD settings, prompt conditioning) to prevent Whisper/ASR models from hallucinating text during silent or non-speech noisy sections?

​Thanks in advance for any insights and recommendations!

A few months ago, I hit a wall when using Picovoice's Porcupine to add wake word detection to a React Native mobile app I was building for an enterprise client.
When I evaluated how much it would cost, I observed it would take about $6000 or more to obtain a valid commercial license from Picovoice, which was quite crazy lol.
You'd also need internet access to use Porcupine, since Picovoice needs to validate the Access key per device, which meant it couldn't even work in air-gapped environments.

I explored several solutions, but they all required a commercial license and internet access for validation. This obviously would be very bad for the company I was working with, so I did some more research, and I discovered that the Python and Home Assistant ecosystem didn't face this problem, as a couple of good and free wake word detection libraries already existed, with openWakeWord by David Scripka leading the bunch.
This was really exciting, but I was shocked to see that even though openWakeWord was novel in its own right, no React Native version existed, and I couldn't use it in my project.

So I decided to build a port of openWakeWord in React Native called react-native-openwakeword.

The pipeline resembles how the Python pipeline already handles inference, with a few C++ tricks I could find on the internet.

openWakeWord is famously known for using a three-stage pipeline: melspec, embedding, and the actual wake word model. So I built a flow that works in C++ and used Nitro Modules to use JSI and connect back to JavaScript. Here is how it works:

Audio flows from the phone's microphone, sampled at 16000 times per second, and sends this frame using an ArrayBuffer to the C++ function directly using JSI.

The C++ module uses three ring buffers to implement sliding windows for moving data through the three models. Ring buffer capacities are sized as powers of 2 (larger than strictly needed), so wraparound operations can use a bitwise AND instead of the modulo operator, which is cheaper on the CPU.

The first ring buffer, AudioRing, is for the melspec model, and it takes the audio samples and converts them to float32 (this uses NEON to run SIMD to accelerate this on phones); then the result is written directly into the melspec model input memory (to avoid unnecessary copies), the melspec model is run on it, a fixed normalization formula is applied, and 8 mel-frames are put into the next ring buffer.

The next ring buffer, MelRing, takes the most recent 76 mel-frames and copies them directly into the embedding model input memory; it runs the model, and the embedding result is put into the next ring buffer, EmbRing.

Once EmbRing holds at least 16 embeddings, it copies the most recent 16 directly into the wake word model's input memory, runs the model, and the probability is returned.

This probability is compared against a given threshold (default is 0.5) and returns an object {probability, isDetected} back to the JavaScript layer (synchronously).

I faced a few gotchas in the beginning trying to figure out what inputs each model (melspec, embedding, and wake word) was expecting, but I eventually got it to work.

Since the melspec model processes audio in 1280-sample chunks (80ms at 16kHz), the entire three-model pipeline needs to run in under 80ms to keep up in real time, and after these optimizations, the package detects wake words in 16-21ms.

I'd appreciate your thoughts on the architecture and if there's anything useful that could be added to this package.

Github: https://github.com/Incognitol07/react-native-openwakeword

Wanted to put this on the radar for people here.

Handy is a free and open source dictation app for Windows, Mac and Linux. You hold a shortcut, talk, release, and your words get typed into whatever app you're in. It all runs locally, so there's no subscription and no internet needed once it's set up.

I have been using it for six or seven months on English and it has held up really well. I use the Parakeet v3 model, which runs on the CPU and is quick. Accuracy has been solid for everyday stuff like emails, notes and longer writing.

Fair warning, it's simple by design. Small pause before the text appears, no phone app, no fancy AI rewriting of your sentences. None of that bothers me for how I use it.

Most dictation tools worth using cost money these days, so it's nice to have one that's free and doesn't send your voice off somewhere.

Sharing it because the paid options in this space keep getting more expensive, and a lot of people don't know a free one this capable exists.

github.com/cjpais/Handy

handy.computer

I’ve been working on an open-source video dubbing pipeline that tries to preserve the original speaker’s voice when translating a video into another language.

Current pipeline:

video → vocal/background separation → Whisper/WhisperX transcription + alignment → translation → VoxCPM2 reference voice cloning → reconstruction → optional LatentSync

The attached demo compares the original English clip with the Turkish dub produced by the current pipeline.

The main problems I’m working on now are:

• preserving speaker identity across languages
• handling duration differences between source and translated speech
• improving multi-speaker / diarization support

Most media processing and AI inference runs locally. Translation currently uses Google Translate, so the project is local-first rather than fully offline.

Code:
https://github.com/kadirb4rut/video-dubbing-translator

I’d especially appreciate feedback from people working on TTS, voice cloning, alignment, or speech-to-speech systems.

I maintain speech-swift and recently implemented NVIDIA’s Nemotron VoiceChat 11B for MLX. I recorded a complete session rather than stitching together generated clips:

https://youtu.be/6LCxSnIMB-M

VoiceChat is an end-to-end speech model rather than an ASR → LLM → TTS cascade. Every 80 ms it consumes another microphone frame and emits a token. Those tokens jointly

• Live process RSS: 7.5 GB
• Weights on disk: 8.0 GB
• MCP round trip: 68 ms

The Swift/MLX runtime is Apache 2.0. The NVIDIA checkpoint is distributed under OpenMDW 1.1. Reproduction commands and source links are in the video description.

Hello everyone,

Wanted to understand what are some of the interesting usecases people are building for TTS. And while building these what kind of features do you need especially for Indian languages

I'm building a vocabulary-learning app in Flutter where hearing and saying the word correctly is the product, not a nice-to-have. I've hit a problem I can't design around and I'd rather ask than keep patching.

The stack

• Flutter, ~1,600 words live across EN/ES/PT/IT/FR
• TTS: ElevenLabs (eleven_multilingual_v2) called through a Supabase Edge Function so the key never ships in the client
• Every clip cached server-side once per (text, language), shared across all users — so a given string is synthesized exactly once, ever
• Cached again on-device (150MB LRU) so replays are instant and offline
• flutter_tts as fallback behind a 2.5s timeout so playback never goes silent
• STT: speech_to_text for a pronunciation-practice screen — hear the word, say it, get graded

The problem: heteronyms, in both directions

Output. "Wind" (moving air) and "wind" (to coil) are the same string and different sounds. TTS picks one reading and commits. My word library actually knows which sense is on screen — every entry carries a part of speech — but there's no API surface to hand that over. ElevenLabs pronunciation dictionaries are exact-string, case-sensitive, and have no POS or context scoping, so one spelling gets one entry and the second sense is unreachable. Phoneme tags do exist, but per the docs only on eleven_flash_v2 and v3 — not the multilingual model I'm on, and switching models means re-synthesizing the whole cache and losing voice identity across five languages.

Input. This is the part that actually bothers me. The practice screen normalizes the transcript and Levenshtein-scores it against the target. But STT returns orthography — say either reading of "wind" and the transcript is "wind" either way. A learner who mispronounces it scores full marks. The feature is structurally incapable of catching the error it exists to catch.

What I've tried

Respelling the audio-only string before it reaches the engine — the screen text is never touched. wind(noun) → winned, wind(verb) → wined, read(past) → red, and so on. This is basically ElevenLabs' own recommended "alias" workaround and it works for the ~8 vowel-shift pairs I've mapped. Side benefit: since my cache key is a hash of (lang + text), two senses naturally get two cache entries.

It fails in three ways:

1. Stress-shift pairs. REcord/reCORD, PREsent/preSENT, CONtent/conTENT. Respelling can't encode stress, and I haven't found a trick spelling that does.
2. Monolingual. It's an English orthography hack. Nothing about it transfers to ES/PT/IT/FR, all of which have their own homographs.
3. Manual. Hand-curated table. Doesn't scale to a few thousand words.

What I'm actually asking

1. Is there a TTS API that accepts a sense/POS hint, or per-request phonemes, on a multilingual model? Or does everyone route heteronyms to a separate English-only model and eat the voice mismatch?
2. If IPA is the only real answer — has anyone found v3-class IPA reliable enough in production? The docs quote 80–90% consistency, which for a teaching app means the wrong pronunciation ships to a learner one time in eight.
3. For stress-shift specifically: any orthographic trick that works, or is phoneme-level control genuinely the only path?
4. On the STT side — is there a mobile-viable way to get phonemes rather than words? I've looked at wav2vec2 phoneme-CTC or a forced aligner with GOP scoring via ONNX on-device, but I don't know if that's realistic on a mid-range phone or if I'm about to spend a month learning that it isn't. Whisper doesn't help; it also returns orthography.
5. The unglamorous option: detect heteronyms and simply disable pronunciation scoring for them, with an honest note to the user. Is that what shipped apps actually do?

If you've built pronunciation feedback into anything real, I'd love to know where you drew the line between "graded properly" and "good enough." Happy to share code for any of the above.

I ran a matched-content experiment on speaker verification: 4 speakers, identical sentences, controlled changes in pitch, phonation and articulation, fixed microphone position and gain, every utterance through three encoders — ECAPA-TDNN, a ResNet speaker encoder, and WavLM-base-plus-sv.

One speaker sat 0.7 semitones below his normal pitch. That is below the threshold where a listener reliably hears any change at all. His verification score dropped 0.238 across all eight sentences.

The interesting part is that pitch was not what moved him. His harmonics-to-noise ratio fell from 10.63 to 8.39 dB over the same block. The encoder was reacting to phonation, and the pitch number was just the thing that happened to be easy to measure.

Across the whole run, all 30 speaker × condition × encoder cells were negative, 28 of them unanimous across every utterance. These systems are not mainly disturbed by shouting or disguise. They are disturbed by someone speaking slightly differently in a way nobody would notice.

To be clear about credit: the displacement effect itself is not my finding. I had it as my headline until an adversarial prior-art audit turned up Hughes et al. (Interspeech 2023), who established it with six trained phoneticians across seventeen conditions. I withdrew the claim and reframed the paper as a replication and extension across encoder architectures. The audit is published in full, including the claim it killed.

Two things I could not find in prior work:

Jitter beats HNR. Pitch deviation and jitter are independently associated with displacement in all three encoders, and HNR adds nothing once jitter is in the model — it correlates 0.55 with jitter and loses all independent power beside it. HNR is the measure most people reach for, and on its own it will attribute the effect to the wrong thing.

Rough phonation breaks F0 trackers in one direction. 10 of 145 utterances carried impossible pitch values, up to 32.1 semitones — a 6.4× frequency ratio no human produces. All 10 were in rough phonation, none in modal (Fisher exact p = 2.4e-11). Octave errors push upward and essentially never downward, so this is differential measurement error, not noise, and it loaded onto one specific regression coefficient. Cheap fix: validate your F0 tracker per phonation condition and publish the validation.

Everything is up — manuscript, pre-registration, the full prior-art audit, per-utterance tables for all three encoders (233 rows each), the analysis scripts, and the 137 source recordings. Every number reproduces from the CSVs without touching the audio.

Paper and data: https://doi.org/10.5281/zenodo.21921958

Write-up: https://ai.bedvibe.studio/speaker-drift/

Audio licence note: research, benchmarking, evaluation and teaching are permitted; ML training and voice cloning are not. The speakers are identifiable adults.

I am running Faster Whisper on CPU only and get good running times with about 2.5 min for 60 min sound with Whisper Base. With Pyannote for diarization the rate is about 0.9 times the sound length, aka 54 min for 60 min sound.

That is terribly slow compared to the transcription without Payannote.

Are there any faster alternatives out there, or hacks to make Payannote run faster with Whisper?