Google Files Patent to Turn Written Text Into Speech by Cleaning Up Static
Google's text-to-speech method starts with a burst of pure static and cleans it up, pass by pass, until it becomes a person talking. The filing says six or fewer cleanup passes can be enough.
What Google's static-to-speech patent actually does
Every time your phone reads a text message or a set of directions out loud, a computer has to turn written words into actual sound. Many of the best systems do that by building the audio one tiny slice at a time, with each slice depending on every slice before it. That is slow and uses a lot of computing power.
This Google patent application takes a different route. It starts with a burst of random static the same length as the finished clip, then cleans it up over a handful of passes, with the text steering each pass toward the right words. The filing says six or fewer passes can match or beat the quality of the slower approach.
It also skips a middle step many systems rely on: a rough sketch of the sound that a separate program has to draw first. Here, one system goes straight from words to audio.
… generating a final representation of the waveform output that defines an utterance of the text input by a speaker by updating the current representation of the waveform output at each of a plurality of iterations …
Translation: It builds the final spoken audio step by step over multiple rounds.
How Google's noise-cleaning loop builds a voice
The system starts by turning text into a string of phonemes (the basic sounds that make up words), with silence markers at word boundaries. An encoder (a neural network that boils the sequence down to a compact set of numbers) produces a hidden representation. A duration predictor then guesses how long each sound should last, and the system stretches that representation to match the timeline of the final audio. In the filing's example, the guidance runs at 80 values per second while the audio runs at 24,000.
Next comes the cleanup loop. The system creates a waveform (the raw list of values that a speaker turns into sound) filled with random noise. At each pass, a noise estimation network looks at the current waveform plus the text guidance and guesses, for every single value, how much of it is noise. The system subtracts a scaled version of that guess, with the step size set by a noise level for that pass. On every pass except the last, it adds a small amount of fresh noise back.
The number of passes can be set to fit a speed or computing budget. For training, the networks learn together from recordings paired with their text: noise is added to a real recording, and the network is graded on how well it guesses that noise. Because this happens end to end, no separate sound-sketch model is needed.
processing (i) the current waveform output and (ii) the conditioning input using a noise estimation neural network to generate a noise output; and updating the current waveform output using the noise output and the noise level for the iteration.
Translation: An AI checks the audio for static and cleans it up based on the current noise level.
Why faster text-to-speech matters for Google
If you use a screen reader, ask for directions out loud, or have your phone read messages while you drive, speed matters: a voice that pauses before every sentence feels broken. The filing says its approach cuts delay and uses many fewer computing resources than the slower, slice-by-slice method, while matching or beating its quality. That could make good voices easier and cheaper to run.
It also simplifies the build. Because one system goes straight from text to audio, there is one fewer model to design and train. One caveat: the application continues an earlier one filed in 2022 with a 2020 priority date, and a patent filing alone does not tell you what Google actually ships.
That makes this Google's 57th filing we've tracked in voice and speech AI since May, a topic that already covers work like cutting background noise from compressed audio and handling sentences of any length.
Slow speech generation is a real annoyance, and a costly one at Google's scale. When a voice takes a beat too long to answer, you notice, and every extra pass of computing adds up across millions of requests. Cutting the work to six or fewer passes goes straight at that.
The size of the fix matches the size of the problem. The description says quality holds up against the slower method, and dropping the separate sound-sketch step means less machinery to run. Nobody thinks about how a talking voice is built, but everyone notices when it lags or sounds off.
One caution: the application continues an earlier one with a 2020 priority date, so the idea has been around a while. The document cannot tell us whether any of it runs in the voices you hear today.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Google patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
7 drawing sheets from US 2026/0341267 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in