Alexandria Audiobook Generator: Local Multi-Voice TTS With a Qwen3-TTS Engine
AI-powered multi-voice audiobook generator — LLM script annotation, voice cloning, voice design, LoRA training, per-line style control, and export to MP3, chaptered M4B, or Audacity multi-track. Built on Qwen3-TTS.
At a glance
- What is it?
- Alexandria turns a book file into a chaptered audiobook by way of an LLM annotation pass and a local Qwen3-TTS engine. It is a Pinokio app with a browser editor, and its hardware table makes clear that the GPU story is narrower than the feature list.
- Who is it for?
- Adopt Alexandria if you have an NVIDIA card on Windows or Linux with driver 550+, a separate LLM server, and a book you want voiced without sending text to a cloud TTS vendor. Do not adopt it if you are on AMD Windows, Apple Silicon, or Intel macOS and expect GPU speed, since the README lists those as CPU-only.
- 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 44 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Annotation Pass Is the Actual Product
Raw text-to-speech on a novel produces one narrator reading every line, including dialogue that belongs to different characters. Alexandria's answer is to make an LLM do the casting first. The README describes automatic script annotation: an LLM parses the text into JSON with speakers, dialogue, and TTS instruct directions. That JSON, not the original manuscript, is what the TTS engine consumes. Everything downstream (voice assignment, per-line instruct, chunk boundaries) hangs off that structure. If the annotation is wrong, the audio is wrong, which is why the project ships an optional second LLM pass it calls Script Review. That pass is described as fixing attribution tags left inside dialogue, splitting misattributed narration and dialogue, merging narrator entries that were split too finely, and validating instruct fields. The existence of a dedicated repair pass tells you the first pass is unreliable enough to need one. That is the honest framing: annotation is a probabilistic step, and the tool is built around cleaning it up rather than pretending it lands perfectly. It is aimed at people who want a multi-voice result and are willing to review a script before rendering, not at people who want a one-button file-to-MP3 converter.
From Script JSON to Speaker Roster and Voice Assignment
Once annotation exists, persona generation takes over. According to the README, the LLM analyzes the script to create voice descriptions for each character, then generates reference audio through VoiceDesign and assigns clone voices automatically. The README sums this up as one click from script to fully-voiced cast. Speaker aliases are the mechanism for handling naming drift: multiple speaker names can map to one voice, with the README's example being YOUNG ELENA mapped to ELENA, so variants share a single voice configuration. Chunking is speaker-aware rather than fixed-width. Consecutive lines by the same speaker are grouped up to 500 characters, which the README frames as preserving natural flow. Continuity across those chunks is handled by passing the character roster and the last three script entries into each new chunk, so the model keeps names and style consistent at the seams. That is a small context window by LLM standards, and it is worth understanding as a design constraint: continuity is local, not global. A character introduced in chapter one and reintroduced in chapter nine has no shared memory across the gap except whatever the roster carries.
Four Ways to Get a Voice, With Different Costs
Alexandria exposes several distinct voice paths, and they are not interchangeable. The built-in option is nine pre-trained voices with instruct-based control over emotion and tone. Voice cloning takes a 5 to 15 second reference sample and reproduces that voice. Voice Designer creates a new voice from a text description, with the README's example being a warm, deep male voice with a calm and steady tone. LoRA training goes further: it fine-tunes the Base model on a custom voice dataset to produce what the README calls a persistent voice identity with instruct-following. The distinction matters. Cloning and VoiceDesign are immediate and cheap. LoRA training is the only path that produces a reusable adapter, and it is the only one that requires a dataset, which is why the project ships a Dataset Builder for creating LoRA training datasets with per-sample text, emotion, and audio preview. The README also states that pre-trained LoRA presets are included out of the box and ready to assign. For most projects, presets plus cloning will cover the cast. LoRA is for a voice you intend to reuse across multiple books and want to steer with instruct text.
Running It: Pinokio, an LLM Server, and a GPU Table That Matters
Installation is through Pinokio, which the README lists as the recommended route and as a hard requirement in the Requirements section. Alongside it you need an LLM server exposing an OpenAI-compatible API. The README names LM Studio (recommended, with Qwen3 or similar), Ollama, and the OpenAI API as options. There is no separate TTS server to stand up: the README states that Alexandria includes a built-in Qwen3-TTS engine that loads models directly, with weights downloaded automatically on first use at roughly 3.5 GB per model variant, and that an external Qwen3-TTS Gradio server can optionally be connected instead. Hardware numbers are given concretely. 8 GB VRAM is the stated minimum, 16 GB or more recommended. Each TTS model uses about 3.4 GB, and remaining VRAM determines batch size. RAM is 16 GB recommended with 8 GB minimum. Disk is about 20 GB, broken down as 8 GB for the venv and PyTorch and roughly 7 GB for model weights. The compatibility table is the part to read before installing. NVIDIA on Windows and Linux is full support with driver 550+ and CUDA 12.8, with flash attention on both and triton on Linux. AMD on Linux is full support with ROCm 6.3+. AMD on Windows is CPU only, and the README says GPU acceleration is not supported there. Apple Silicon and Intel on macOS are CPU only, with MPS acceleration explicitly not supported. The README describes CPU mode as available on all platforms but significantly slower.
Exports, Pauses, and the Non-Verbal Details
Export targets four destinations. A combined audiobook as a single MP3. Individual voicelines as one MP3 per line for DAW work. An Audacity export described as a one-click zip containing per-speaker WAV tracks, a LOF project file, and labels for automatic multi-track import. And M4B, the chaptered AAC format, with per-chunk or auto-detected chapter markers, which the README names as compatible with Audiobookshelf, Apple Books, and VLC. The M4B path arrived in v1.5, which the release notes title M4B Export, Voice Cloning Upload and Stability Fixes. Pause handling is configurable rather than fixed: 500ms between speakers by default and 250ms between segments by the same speaker. The project also asks the LLM to write non-verbal vocalizations such as Ahh!, Mmm..., and Haha! with context-aware instruct directions. That is a deliberate choice with a visible cost. Non-verbal sounds are generated by the same model that does the annotation, so they inherit its failure modes, and a misjudged interjection is more conspicuous in finished audio than a slightly flat line of narration.
Throughput Claims and Where the Documentation Thins
The README advertises batch processing with what it calls 3-6x real-time throughput and an optional torch.compile path it calls codec compilation for 3-4x faster batch decoding. These are the project's own numbers, presented without a stated test configuration, and I have not run them. Treat them as directional. What the README does specify is the mechanism: batch rendering with sub-batching, and sub-batching tied to available VRAM, which is why the 8 GB minimum and 16 GB recommendation exist. The practical consequence is that batch size is not a setting you tune for convenience; it is bounded by the card. The documentation is also thin in a few places worth naming. The README does not state an inference speed figure per model beyond the batch multipliers, so estimating wall-clock time for a full novel is guesswork. It does not describe how chapter detection works for M4B beyond auto-detected chapter markers. And it directs readers to the Wiki for anything beyond the basics, which means the README alone is not sufficient preparation for LoRA training or large batch runs. The README also carries a note that the project has seen a sudden surge of attention and that the maintainer may not respond to every issue promptly, asking users to read the README and Wiki before filing. That is a maintenance-capacity signal, and it is stated by the author rather than inferred.
Where It Fits Against a Plain TTS Pipeline
The obvious alternative is a general TTS library or CLI, such as a Coqui-style toolkit or a cloud TTS API, driven by your own script. The difference is where the work sits. A plain TTS pipeline gives you a text-to-waveform function and leaves speaker attribution, chunk boundaries, instruct directions, and export packaging to you. Alexandria's whole value is that it owns the layer above the model: annotation, review, persona assignment, chunking with context carry-over, and M4B or Audacity packaging. If you already have a clean script with speakers marked and you only need audio, that layer is overhead, and a direct TTS call is less machinery. The other real alternative is a cloud TTS service with multiple built-in voices. That removes the 8 GB VRAM requirement and the driver constraints entirely, and it removes the model download. It also means your manuscript text leaves your machine, which is the reason a local engine exists in this project at all. Alexandria's position is that the LLM annotation step can also be local, via LM Studio or Ollama, so the whole pipeline can run without a network call. That is the trade: you supply the GPU and the patience, and you keep the text.
Licence, Upgrades, and What to Check Before a Full Book
The repository is MIT licensed, which is permissive and places few obligations on how you use or redistribute the code. That covers the software. It does not automatically cover the model weights, the LLM you connect, or the reference audio you clone, and the README does not address those layers. If you clone a voice from a sample, or fine-tune a LoRA on a dataset, the rights question belongs to those inputs, not to the MIT grant on the Python code. I am not giving legal advice here; the point is simply that the licence line in the repository metadata is narrower than the pipeline it ships. On upgrades, the release cadence visible in the material is roughly one release per month across v1.3, v1.4, and v1.5, with each one adding a distinct capability: LoRA voice training and the voice designer in v1.3, the dataset builder and built-in presets in v1.4, M4B export and voice cloning upload in v1.5. That is a project still filling in its feature set rather than one in maintenance, which means upgrade cost is real. The README does not document a migration path between versions or a schema version for saved scripts, and the Script Library saves and loads annotated scripts with voice configurations. Whether a script saved under v1.4 loads cleanly under a later release is not stated. If you build a library of annotated scripts, test one saved script after each upgrade before starting a new book. That check is cheap and the failure it prevents is not.
Editorial conclusion
Adopt Alexandria if you have an NVIDIA card on Windows or Linux with driver 550+, a separate LLM server, and a book you want voiced without sending text to a cloud TTS vendor. Do not adopt it if you are on AMD Windows, Apple Silicon, or Intel macOS and expect GPU speed, since the README lists those as CPU-only. Before committing a long book, verify the GPU row for your exact card and OS, and check the Wiki for LoRA training and batch generation guidance, because the README points there for anything past the basics.
Community notes