EditVoice Fixes a Wrong Word in Your Voiceover Without a Re-Record
A new open model changes the words in a finished recording by letting you type the corrected sentence. The clever part is that the fix can take longer or shorter than the mistake did.
The hard part of fixing one wrong word in a recording was never the voice. It was the timing.
Say your narrator read "the event opens on the fourth" and the client meant the twenty-fourth. Two syllables have to become four. Every patch you try runs into the same wall: the gap is the wrong size. Squeeze the new word in and it sounds rushed. Stretch the room around it and the breath lands in the wrong place. Most listeners could not tell you what is wrong. They just hear that something is.
A research release that went up on Hugging Face yesterday goes straight at that problem. It is called EditVoice, and the idea is plain. You hand it the recording, the transcript of what was said, and the transcript of what you wanted said. It changes only the words that differ and lets the new version run as long as it needs to.
That last part is the whole story, and it is why this one is worth your attention.
What EditVoice actually does
EditVoice comes from Hongyao Deng and six co-authors, with the paper posted September 24 and the model files on Hugging Face September 28. It does three jobs from one set of files.
Edit a recording. Give it the original audio, what was said, and what you want said. It inserts, deletes, or swaps words and returns new audio in the same voice.
Generate new speech from a sample. Give it a short clip of a voice and its transcript, then type a new sentence. It speaks that sentence in the voice. This is what most people mean by voice cloning.
Convert a voice. Take one speaker's recording and make it sound like another reference speaker.
For a video editor or a podcast producer, the first job is the one that changes your week. The other two exist elsewhere already. Word-level fixes to a finished recording, in open code you can run yourself, are the part to pay attention to.
Why the length problem matters so much
Here is the mechanism in plain terms.
Many recent voice generators build the whole clip at once, in parallel, rather than one sound after another. That is fast. The authors point out the catch: these systems typically need to be told how long the output will be before they start. Decide the length wrong and the model has to cram or pad the words to fit.
For fresh speech that is a small annoyance. For edits it is the whole problem. When you change "fourth" to "twenty-fourth", nobody knows the right length in advance. It depends on how this narrator, in this sentence, at this pace, would have said it.
EditVoice lets the length move while it works. It treats the job as a series of edits (put a sound in here, take one out there, swap this one) and the clip grows or shrinks as those edits happen. The authors describe it as, to their knowledge, the first model of its kind that does not need the length fixed in advance. I cannot independently confirm "first". What I can say is that the approach fits the problem a working editor actually has.
There is a second detail editors will care about. The team trained the editing path separately for noisy recordings, using a different sound-rendering stage from the clean voice-generation path. Real voiceovers have room tone, a bit of hiss, a fridge in the next room. A fix that sounds studio-clean next to a slightly noisy original is its own kind of tell.
What the licence lets you do
The code is Apache 2.0, with a few bundled third-party parts keeping their own licences. The model files are a mix: some come from the authors, some from the open CosyVoice2 voice model, both under Apache 2.0. The final piece that turns the edited result back into sound comes from Kimi-Audio under MIT. The model card says plainly that no single licence covers every file, and it keeps a file-by-file map.
Apache 2.0 and MIT are both permissive, commercial-friendly licences. So by the terms on the page, repairing a client podcast or fixing a paid narration is on the table. Read the map yourself before you invoice anyone, because one required piece (below) sits outside it.
The more important permission is not in any licence. Only edit a voice you have the right to edit: your own, or a narrator who has agreed to it in writing. A tool that changes what someone said, in their voice, is exactly the tool you need a paper trail for.
Put this into practice
Start by listening before you install anything. The authors' sample page has before-and-after editing examples. If those do not sound good enough for your work, you have saved yourself an afternoon.
If they do, here is the realistic path.
1. Plan on a Linux machine with an NVIDIA graphics card. The README recommends Python 3.10 and asks for PyTorch 2.3.1 built for your card's CUDA version. It does not give a memory figure, so a rented cloud machine is the low-risk way to try it first.
2. Sort out the one missing piece before anything else. EditVoice needs a text-cleaning package called ttsfrd, which tidies written text (numbers, symbols, formatting) into something the model can read aloud. The authors do not ship it and say to get it "from an authorized source." The only published copy I found comes from the CosyVoice team, who list it as a download (FunAudioLLM/CosyVoice-ttsfrd on Hugging Face) with a Linux wheel for Python 3.10. That is the step most likely to stop you, and it is why I would not try this natively on a Mac or Windows machine.
3. Install EditVoice and pull the model files. The README walks through pip install -e . and a download script. It also ships a checksum file so you can confirm nothing was corrupted on the way down.
4. Write your fix as one line of text. Edits are described in a small file, one fix per line:
{"sample_id":"fix-001","source_wav":"audio/narration_take3.wav","source_text":"The event opens on the fourth.","target_text":"The event opens on the twenty-fourth."}
In my reading of how it works, the original transcript should match what was actually said, so if the narrator ad-libbed a word, put it in.
5. Run the edit. The editvoice-edit command, in the mode the README calls end-to-end, takes that file and writes the corrected audio to an output folder. It checks for existing output files before it starts, which is a small kindness when you are working on a deadline.
6. Cut only the sentence, not the whole take. Give it the one sentence around the mistake rather than a ten-minute file. Then drop the returned sentence back into your timeline and crossfade at the natural pauses on either side. Smaller inputs are faster to check and easier to throw away.
7. Batch when you have a list. If the client sends seven corrections, put seven lines in the file. The same command handles them in one run.
One habit worth keeping: listen to every fix at full volume, on headphones, right next to the untouched audio on either side. The failure you are hunting for is not a robot voice. It is a subtle change in pace or breath that you only hear at the join.
Where EditVoice breaks
English only. It was trained on about 10,000 hours of English speech from GigaSpeech. Do not expect it to fix a Spanish or Mandarin read.
The install is the real barrier. The missing text package, the Linux-only build I could find, and the specific Python and PyTorch versions together turn "try it" into a proper afternoon. Hardware is the smaller problem.
There is no hosted version. No Hugging Face Space, no web demo that takes your own file. The sample page is curated by the authors, so it shows the fixes they were happy with.
It is brand new and lightly used. The code repository had zero stars when I checked. The training code is listed as not yet released. Nobody outside the lab has published tests on real client material, and that is where edge cases live.
Quality claims are the authors' own. The paper reports "competitive" results on standard voice-generation tests and on a speech-editing benchmark called RealEdit. Competitive is a modest word, and it means this is not guaranteed to beat whatever paid tool you already use.
It changes the audio, it does not just copy words across. The edited region is freshly generated speech. On a long sentence you should expect small differences around the edit, not only at the word you changed.
The bigger shift for anyone who records voices
The pattern in this release is showing up across creative AI right now. The better tools are dropping the "describe the whole thing and hope" approach and asking for the end result instead. Here, the end result is simply the sentence you wanted. You already know how to write that. It is the corrected script.
That changes what a re-record costs. The re-record used to be the safe default: book the narrator, match the mic, match the energy, hope the room sounds the same as it did three weeks ago. A fix you can type moves the decision somewhere else. The question becomes whether a generated patch is good enough for this particular line, and that is a judgment you can make in minutes.
EditVoice is not the tool that settles it for everyone. It is a research release with a rough install, English only, and no track record yet. But it goes after the right problem, and in the right way. If you fix voice recordings for a living, spend twenty minutes on the sample page this week. Then decide whether the afternoon of setup is worth it for your next "can we just change one word?" email.
Medium metadata
Title: EditVoice Fixes a Wrong Word in Your Voiceover Without a Re-Record
Subtitle: A new open model edits finished speech by letting you type the corrected sentence. The trick is that the fix can run longer or shorter than the mistake.
Tags: AI Voice, Podcasting, Audio Editing, Voiceover, Open Source AI
Estimated read time: 7 minutes