LocalText2Voice: a local TTS desktop app for audiobooks and podcasts
A complete local production workflow for clean narration, structured learning content, and podcast-ready audio
At a glance
- What is it?
- LocalText2Voice is a Python and PySide6 desktop app that turns long text and EPUB books into narration using local engines such as Piper, Kokoro and Chatterbox. It is Windows-first, Linux runs from source, and the documentation is thinner than the feature list.
- Who is it for?
- Adopt LocalText2Voice if you produce long-form narration on Windows and want local engines such as Piper or Kokoro with an optional cloud fallback. Skip it if you need macOS, a headless server pipeline, or a stable video workflow, since the storyboard is labelled beta and the README states that AI continuity and timing still need human review.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem LocalText2Voice is built around
Most text-to-speech tools are built for a sentence. You paste a line, hear it, and close the tab. Long-form narration is a different job: a book chapter, a course module, or a podcast episode runs for tens of minutes, and the work is mostly bookkeeping. You need to keep the voice consistent, split the text into segments, regenerate one bad paragraph without redoing the rest, and then mix the result with music and normalisation.
LocalText2Voice targets that second job. The README describes it as a desktop app for creating long-form spoken audio with AI text-to-speech, and the stated goal is to paste or import a long text, choose a voice engine, generate clean narration, review the result, and optionally create a podcast mix with music, fades, ducking, and normalization. The audience is implied by the topics and the feature set: people producing audiobooks, structured learning content, and podcast-ready audio, not developers wiring up a TTS API call.
The offline angle matters here. The app can run local engines such as Piper, Kokoro, Chatterbox, Qwen3 TTS, and OmniVoice, with an optional non-commercial F5-TTS Russian engine, and it also leaves room for cloud APIs such as OpenAI TTS, ElevenLabs, Google Gemini TTS, and Azure Speech. That mix is the design centre: local by default, cloud when you want it.
How the pieces fit: engines, the Engine Host, and FFmpeg
The repository layout tells you more about the architecture than the README does. There is an app/ directory for the desktop code, a separate engines/ directory, and a top-level engine_host.py. The engine host is a persistent process, and the 2.0.1 release notes confirm the intent: the Engine Host is reused when regenerating Review segments. That means the model is not reloaded every time you regenerate a paragraph, which is the difference between a usable review loop and a coffee break.
FFmpeg is vendored in an ffmpeg/ directory, and the Linux notes require FFmpeg in PATH. So the audio assembly step (concatenation, music mixing, fades, ducking, normalisation) is FFmpeg work, not Python audio code. The music/ and voices/ directories hold the assets those steps consume.
The dependency list in requirements.txt is honest about the stack. PySide6 and QtAwesome for the interface, soundcard for playback, mutagen for audio metadata, python-docx for document import, fastapi and uvicorn for a local service layer, and litellm for model access. The 2.0.1 notes add LiteLLM-compatible analysis, optional Pillow image handling, and S3/R2 compatible temporary reference storage. The mcp_stdio_bridge.py file at the top level suggests the app can also be driven over MCP, though the README excerpt does not document that path.
One design detail worth noting: engines download their own isolated dependencies, including PyTorch runtimes. The README says disk usage grows with each optional engine because models and isolated dependencies are downloaded on demand. That is a reasonable isolation choice and a real storage cost.
Installing LocalText2Voice on Windows and generating a first chapter
On Windows 10 or 11 64-bit, the README points to the packaged installer as the recommended distribution. Downloading and running it is the whole install. The README links the installer directly from the releases page, and v2.0.2 fixed a Windows startup issue caused by an incompatible Poppler ICU DLL that Qt picked up during the v2.0.1 build. If you are on v2.0.1 and the app fails to start, that is the known cause, and the notes state that upgrading removes the conflicting ICU files without deleting settings, projects, downloaded models or generated audio.
If you are running from source, the top-level run_dev.bat and run_dev.sh scripts are the entry points, and main.py is the application entry. The README does not spell out the source install commands in the excerpt, so the safest reading is to follow the repository scripts rather than invent a pip line.
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt
run_dev.batThe requirements.txt file pins PySide6>=6.7,<7 and litellm>=1.75,<2 among others. Note that this file does not include the engine stacks: the Kokoro engine has its own requirements-kokoro-engine.txt, which is the isolated-dependency model in practice.
Linux is documented separately. The README states that Linux runs from source, requires Python 3.10+ with virtual-environment support, and needs FFmpeg in PATH. The documented Linux workflow has been tested on Arch/CachyOS with KDE Plasma and Wayland. macOS is not currently tested or officially supported.
For a first real use, the flow the README describes is: import or paste text, pick an engine and voice, generate, then review. The Review step is where the Engine Host reuse shows up. Regenerating a single segment should not force a full model reload. The 2.0.1 notes also mention fixing Qwen voice selection from the Voice Library, which tells you voice selection is a real failure point: the 1.5.1 notes describe matching exact voice IDs and names before generic tags, so a voice tagged teacher no longer wins over a voice named Teacher.
EPUB import, M4B export, and the Video Storyboard beta
Version 2.0.1 added EPUB 2/3 import in reading order, preservation of book metadata and cover art, and structured M4B audiobook export. That is the most concrete long-form feature in the release history. Reading order matters more than it sounds: a naive EPUB parse can scramble chapters, and the release note specifically claims reading order is preserved. If you are converting books, that claim is the first thing to verify against a title with footnotes or nested sections.
The Video Storyboard is the other 2.0.1 addition, and the README labels it beta. It analyzes narration, discovers characters and locations, generates or imports images, creates video clips, edits the timeline, and renders an MP4 with the audiobook audio. It ships with 50 built-in visual styles, customisable prompts, scene review, continuity profiles, image editing, ComfyUI workflows and optional Runpod providers.
The README is unusually direct about the limits: AI continuity and timing still need human review. Take that at face value. A pipeline that infers characters and locations from narration and then generates images for them will drift, and the continuity profiles exist precisely because the model cannot hold consistency on its own. If you want a finished video with no manual pass, this is not that. If you want a first-cut storyboard you then edit, the beta is aimed at you.
Where LocalText2Voice is the wrong tool
Three constraints stand out. The first is platform. Windows gets the packaged installer; Linux runs from source and is tested on one distribution family; macOS is not tested or supported. If your team is on Macs, this is not a drop-in.
The second is hardware. The README's profiles are guidance, not limits. The recommended profile is a modern 6-core CPU, 16 GB RAM, an SSD with 20 to 30 GB free, and an NVIDIA CUDA GPU with 8 GB VRAM. An NVIDIA GPU is optional, and most local engines can fall back to CPU, but the README says generation may be considerably slower. GPU acceleration currently focuses on NVIDIA CUDA, and the README warns that other GPU families should not be assumed to accelerate every engine. If you have an AMD or Intel GPU and expect acceleration, check before you plan around it.
The third is the shape of the tool. This is a desktop app with a Qt interface, not a headless CLI you can drop into a CI job. The fastapi and uvicorn dependencies suggest a local service layer, and mcp_stdio_bridge.py suggests scripted access, but the README excerpt does not document a batch mode or a stable command-line contract. For a nightly pipeline that converts a folder of Markdown to MP3, you would be building on undocumented ground.
Disk usage is the quiet one. Each engine pulls its own models and isolated dependencies, including PyTorch runtimes, and projects plus exported audio need space beyond the listed figures. Enabling four engines to compare voices is not free.
How it compares with Piper and Kokoro used directly
Piper and Kokoro are the engines LocalText2Voice wraps, and both are usable on their own. The difference is what sits around them. Running Piper directly gives you a model file and a synthesis call: you handle text splitting, chunk boundaries, voice selection, regeneration of a single bad segment, loudness normalisation, and music mixing yourself. That is fine if you already have a pipeline, and it is lighter: no Qt runtime, no FastAPI service, no per-engine PyTorch downloads.
LocalText2Voice trades that lightness for the review loop. Segment-level regeneration backed by a persistent Engine Host, a Voice Library with ID and name matching rules, EPUB import with reading order, M4B export, and FFmpeg-based mixing with fades and ducking. Those are the parts you would otherwise write and maintain. The trade is real in both directions: the app is a bigger install and a GUI, and direct engine use is scriptable and small.
There is also a middle path the README implies: use the local engines for generation and a cloud API such as OpenAI TTS, ElevenLabs, Google Gemini TTS, or Azure Speech when you want a different voice. That is not a competitor comparison so much as a hedge, and it is the reason the app is not purely offline. The offline-capable badge is accurate for the local engines, but cloud APIs are first-class options, not an afterthought.
Maintenance, upgrades, and the MIT licence
The project is not archived, and the last push was on 2026-09-13. The release cadence in the release history is tight: v2.0.2 on 2026-09-13, v2.0.1 on 2026-09-13, and v1.5.1 on 2026-08-21. The v2.0.2 entry is a packaging fix, which is a good sign for the upgrade path and a reminder that a desktop app with vendored native libraries has build-level failure modes that have nothing to do with TTS quality.
The upgrade note is specific and worth repeating: upgrading from v2.0.1 removes the conflicting ICU files without deleting settings, projects, downloaded models or generated audio. That is the migration behaviour you care about, and it is documented for one hop only. The README does not document rollback, and it does not describe what happens to a project created on 2.0.x if you downgrade.
The code is MIT licensed, which is permissive and places few obligations on you. Two caveats sit outside the MIT grant. The optional F5-TTS Russian engine is described as non-commercial, so enabling it changes what you can do with the output. And the app can call cloud APIs such as OpenAI TTS, ElevenLabs, Google Gemini TTS, and Azure Speech, which carry their own terms and per-use costs. THIRD_PARTY_NOTICES.md and the licenses/ directory exist for exactly this reason; read them before shipping audio commercially. None of this is legal advice.
Editorial conclusion
Adopt LocalText2Voice if you produce long-form narration on Windows and want local engines such as Piper or Kokoro with an optional cloud fallback. Skip it if you need macOS, a headless server pipeline, or a stable video workflow, since the storyboard is labelled beta and the README states that AI continuity and timing still need human review. Before committing, install the Windows build, generate one chapter, and check the Engine Host behaviour and the disk cost of each engine you enable.
Frequently asked questions
How can I tell if someone is using an AI voice?
The README does not offer a detection method. It only states that LocalText2Voice can run local engines such as Piper, Kokoro, Chatterbox, Qwen3 TTS and OmniVoice, and that optional cloud APIs such as OpenAI TTS and ElevenLabs are also supported.
How do I turn on voice text in LocalText2Voice?
The README describes the flow as pasting or importing a long text, choosing a voice engine, generating narration, and reviewing the result. On Windows 10 or 11 64-bit the packaged installer is the recommended distribution; on Linux the app runs from source with Python 3.10+ and FFmpeg in PATH.
Is voice cloning illegal?
The README does not discuss voice cloning or its legality. It does state that the optional F5-TTS Russian engine is non-commercial, and that THIRD_PARTY_NOTICES.md and the licenses/ directory cover third-party terms.
Is there a free voice to text option in LocalText2Voice?
LocalText2Voice is a text-to-speech tool, not speech-to-text. The README describes turning books, lessons, articles, notes and courses into audiobooks and podcast-style audio, and the project is MIT licensed.
Community notes