Talk DAT! (often written TalkDAT) is in public beta. Install the Windows build from the Microsoft Store; a separate Mac beta covers Apple silicon on macOS 14 or later.
Hold Ctrl+Win, speak, release. The microphone opens on the trigger and closes when you let go, and the finished text is delivered into the app that has focus. If a keyboard chord is the wrong tool for your hands, bind Mouse 4, a bumper on an Xbox controller, or a pad on a MIDI keyboard instead.
An always-listening app has to keep an input stream open, decide which speech was meant for it, and be trusted not to act on the rest. Push-to-talk removes all three problems. Talk DAT! records the microphone only after a configured hold, toggle, click, mouse, or controller trigger.
It also makes problems easy to spot: if nothing was captured, the trigger was not pressed. And two silent seconds during a capture and the app says so, before you dictate a paragraph into a dead microphone.
The exception is the wake word. It is a beta feature, its optional runtime and model may not be bundled, and switching it on keeps a local microphone listener open. That standing listener is exactly the cost push-to-talk avoids.
The Windows defaults are hold Ctrl+Win to talk, Ctrl+Win+Space to toggle a hands-free session, Ctrl+Win+Alt for command mode, Esc to cancel, and Ctrl+Win+Esc as the panic stop. Three trigger styles are selectable: hold and toggle together, hold only, or a single-button toggle.
Beyond the keyboard, middle mouse, Mouse 4, and Mouse 5 can take part in a chord. Xbox and XInput buttons can be bound, including A, B, X, Y, both bumpers, Start and Back, the stick clicks, and the D-pad directions. Controller polling only runs when a controller button actually appears in a configured chord, so an idle gamepad costs nothing. Notes on a connected MIDI input work under the same rules.
Hotkey capture works by pressing the combination you want and releasing it, not by typing key names into a box. Supported actions can be rebound in Settings, and conflicts are explained in plain language for both exact and nested overlaps.
Three protections sit underneath. Slow handlers are dispatched off the low-level Windows input hook thread, so one long operation cannot silently kill every hotkey. A watchdog checks physical key state to recover from a swallowed Windows-key release. And holding the trigger does not restart capture over and over: a fast bounce after release is ignored, while a deliberate repress past that boundary cancels the result in flight and starts fresh.
One caveat. The conflict guard is a warning, not a block, and a conflicting chord can still be saved. If a trigger stops firing after you changed it, that warning is the first thing to reread.
Auto delivery picks an insertion method from the Windows process that has focus. Ordinary applications get a verified clipboard write followed by Ctrl+V. Terminal-style targets can use Shift+Insert. Simulated typing is available as an explicit method or a fallback, at a configurable interval that defaults to about 2 milliseconds a character. Recognised remote clients, including RDP, VNC, TeamViewer, AnyDesk, RustDesk, and Parsec, route to direct typing, because synthetic pastes travel badly over a remote session.
Two limits before you rely on it. A successful synthetic paste call does not prove the target application accepted the text. And the destination is whichever window has focus when delivery completes, not the one you started in, so switching windows mid-dictation sends the text to the new one.
Recovery is armed before the microphone opens. A local safety WAV and a metadata record are written first, so a crash, a forced exit, or a refused insertion still leaves something to recover. Protected recovery stays enabled and retains at least the latest five sessions; the count is adjustable within a bounded range, generally 5 to 50.
From History you can play the recovered clip, send it back through the pipeline to transcribe and format it again, copy any text produced before the failure, or clear the protected recordings. If insertion and its fallback both fail, the finished result is still on your clipboard and in History.
About audio saving. Turning off audio saving disables a general archive; the bounded protected recovery buffer stays. There is no permanent audio archive, and there is a limited recovery buffer on this PC.
Plenty of people arrive here from a free script that binds a key, records, and calls a speech API. That is a reasonable starting point, and for some people it stays the right answer. We do not publish claims about specific third-party projects we have not tested, so here is the checklist we would use on any of them.
Does the trigger survive a swallowed key release, a slow handler, and a rapid repress? Does a dead microphone get diagnosed, or does the recording silently produce nothing? Is the audio kept somewhere when the paste fails, or is it lost? Can it deliver into a terminal and a remote desktop session as well as a text box? Every answer for Talk DAT! is on this page or on the full feature list.
Straight answers, matching what the product actually does today.
You hold a trigger, speak, and release. The microphone opens on the press and closes on the release, so nothing is recorded between dictations. Talk DAT! then transcribes what you said, cleans it up, and delivers the finished text into the Windows app focused when delivery completes.
Yes, on Windows. Middle mouse, Mouse 4, and Mouse 5 can take part in a configured chord. Xbox and XInput buttons can be bound, including A, B, X, Y, the bumpers, Start and Back, the stick clicks, and the D-pad, and controller polling only runs when a controller button appears in a chord. Notes on a connected MIDI input work the same way.
Supported actions are rebound in Settings by pressing the combination you want and releasing it, rather than typing key names. Exact and nested conflicts are explained in plain language. The guard is a warning rather than a block, so a conflicting chord can still be saved: if a trigger stops firing after a change, reread that warning first.
No. Recording starts only after a configured hold, toggle, click, mouse, or controller trigger. The optional wake word is the exception: it is a beta feature, it may need a runtime and model that are not bundled, and enabling it keeps a local microphone listener open.
Into the Windows app focused when delivery completes, by a verified clipboard write and paste, Shift+Insert for terminal-style targets, or simulated typing. Recognised remote desktop clients route to direct typing. The destination is the final focus rather than the starting window, so switching windows mid-dictation sends the text to the new one.
The finished text stays on your clipboard and in local History, so you still have it. A protected local recording is armed before the microphone opens, so from History you can play it, send it through the pipeline again, copy any text produced before the failure, or clear the protected recordings.
Install Talk DAT!, press the keys you actually want, and start talking. Free to use, with no account needed to dictate.
