Phonemizer is a wrapper, and the backend table decides what you actually get

One API over four external engines

Phonemizer is described as a simple text to phones converter for multiple languages, and the first thing to understand is that it does not contain a phonemizer.

It is based on four backends: espeak, espeak-mbrola, festival and segments. Each of those is an external program or library, and Phonemizer is the layer that gives them a consistent Python and command line interface. The choice is explicitly left to the user.

Two entry points are provided, the `phonemize` command line tool and the Python function `phonemizer.phonemize`. Both reach the same engines.

The dependencies list shows how thin the wrapper is. The required packages are joblib for parallelism, attrs for the class definitions, dlinfo for inspecting shared libraries, and typing-extensions. There is no phoneme table, no lexicon and no model file in this repository.

That has an immediate practical consequence. A Phonemizer installation is really three things: a Python package, at least one backend binary, and the data files that backend needs. The Dockerfile in the repository makes this concrete, installing festival, festvox-us1, festlex-cmu, festlex-poslex, espeak-ng, mbrola and mbrola-fr1 from the Ubuntu repository before the package is even built.

So if you are evaluating this for a container or a research environment, the backend installation is most of the work and the Python package is the small part.

The comparison table is the real specification

The README spends more space on a feature matrix than on prose, and it should be read as the specification of what you get.

On phone set, espeak and festival produce IPA, espeak-mbrola produces SAMPA, festival uses its own custom phone set, and segments produces whatever you define. So phoneme comparison across backends is not meaningful here: a phone from one engine is not a phone from another.

On languages, espeak supports over 100, espeak-mbrola supports 35, festival currently supports only American English, and segments supports whatever you supply.

On speed, espeak and segments are fast, espeak-mbrola is slow and festival is very slow.

Then the token features, which is where the real functional differences are. All four produce phone tokens. Only festival produces syllable tokens, so it is the only backend that can segment at the syllable level. espeak, festival and segments preserve word tokens, while espeak-mbrola does not, so with that engine you get a flat stream of phones with no word boundaries. espeak, espeak-mbrola, festival and segments all preserve punctuation.

The last three rows are the subtleties. Only espeak marks stressed phones. Only espeak applies the tie convention used in IPA typography, where a diacritic on one side of a symbol is tied to the other. Those two are small features that matter enormously if your downstream task is prosody analysis, and they exist in exactly one engine.

espeak is the default answer, festival is the specialist

Reading the table, two of the four backends cover most needs.

espeak-ng is a text-to-speech package supporting many languages with IPA output. It is fast, supports over 100 languages, preserves word tokens and punctuation, marks stressed phones and handles tie. For anything that is transcription of running text across languages, it is the only backend that does all of that, and it is the one to reach for by default.

espeak-ng-mbrola trades capabilities for voice quality territory: it uses SAMPA instead of IPA and does not preserve word boundaries. Choosing it means giving up the structure of your output, which matters if you are feeding it into anything that needs to know which word a phone belongs to.

festival is the outlier in the useful direction. It is very slow, it supports only American English, it uses a custom phone set rather than IPA, and it does not mark stress. What it does that nothing else does is emit syllable tokens and preserve word tokens, so for syllable-level segmentation of English it is the only option in the list.

That combination, very slow plus single language plus custom phone set, makes festival a specialist tool. If your task is pronunciation dictionaries at the syllable level for English, it earns its place; if your task is multilingual G2P, it does not.

The espeak-mbrola option exists because MBROLA voices are the reason, so the 35 languages it supports are selected for voice availability rather than for linguistic coverage.

segments is the one backend you configure yourself

segments is categorically different from the other three. It is a Unicode tokenizer that builds a phonemization from a grapheme to phoneme mapping supplied by you as a file.

Nothing about the phonemization is built in. The languages are user defined and the phone set is user defined, which means you are supplying the linguistic data and the engine only does the tokenization and lookup.

That makes it the right backend when you have your own orthography to phoneme rules, an existing dataset of a narrow language, or a phone inventory that must match a specific system rather than a general one. It is fast.

It also has a dependency cost the other backends do not, and the project is explicit about why. The segments extra pulls in a heavy dependency chain, csvw, rdflib, jsonschema, babel and language-tags, none of which users of the espeak or festival backends need. So segments is an optional extra installed with `pip install phonemizer[segments]` rather than a default.

That separation is a good sign about how the project is maintained. The base install stays small, and the heavyweight path is opt-in for the people who need it.

Other extras exist for the same reason, a `test` extra pulling pytest, pytest-cov, coverage and segments for running the suite.

The Dockerfile shows the installation you would otherwise have to work out

Since Phonemizer itself installs nothing useful on its own, the Dockerfile is the most instructive file in the repository.

The base is Ubuntu 20.04, with `LANG` and `LC_ALL` set to `C.UTF-8`, which matters because these engines read text files and a misconfigured locale produces encoding failures that look like data corruption.

The apt layer installs both phonemizer engines and their data in one go: festival with the American voice festvox-us1, the CMU and POSLEX lexicons, espeak-ng, mbrola with the French voice mbrola-fr1, git, and python3 with pip.

Then two details that show the author has debugged this in a container. pytest is installed through pip rather than apt so a recent version is available. And a symlink is created from `python` to `python3`, with a comment explaining that the tests expect the executable to be named `python`.

The build then installs the package with its test extra and, notably, runs `phonemize --version` before the test suite. If the CLI entry point or a backend is missing, the image fails to build instead of producing something broken.

The build and run commands are in comments at the top of the file: build with `sudo docker build -t phonemizer .`, then run an interactive shell with `sudo docker run -it phonemizer /bin/bash`. The Dockerfile also notes the versions it was written against, festival 2.5.0 and espeak-ng 1.50 from the Ubuntu repository.

There is also a pixi.lock at the repository root, so a second environment definition exists alongside Docker.

Where Phonemizer is the wrong choice

Three cases.

If you need syllable segmentation or stressed vowels across many languages, no backend here gives you both. Only festival tokenizes syllables and it is American English only, so a multilingual syllable-level task means running festival alongside something else and reconciling two phone inventories.

If you need a pure Python dependency with no system packages, this is the wrong library. Phonemizer wraps compiled engines that must be present on the machine, and on a managed or locked-down host, installing espeak-ng and festival with their voice and lexicon data is often the part that gets blocked.

If you need a single canonical phone inventory across your whole pipeline, be careful. Changing backend changes the phone set, so IPA from espeak and a custom phone set from festival are not comparable, and switching backends after you have collected data means recomputing everything.

On the project itself, cadence has slowed between major versions. v3.4.0 was published on 2026-07-31 after v3.3.0 on 2024-08-01 and v3.2.1 on 2022-06-09, so there is a long gap between the two most recent minor releases and then a two-year gap before that. The last push was on 2026-09-30, so work continues. Tests run on Linux, macOS and Windows in continuous integration.

The licence is GPL-3.0 or later, which matters if you ship it inside a product rather than using it in research. The project is citable through a Journal of Open Source Software paper, which is worth knowing if you need a reference for a methods section.

Editorial conclusion

Adopt Phonemizer if you need grapheme to phoneme conversion across many languages from Python or a shell, since it wraps four engines behind one interface. Skip it if you need syllable-level tokens or stressed phones, which only the festival backend provides, or if you need a pure Python solution, since the backends are external programs that must be installed on the machine. Verify first which backend is available in your environment, because Phonemizer delegates to espeak-ng or festival binaries rather than bundling a phonemizer of its own.

Frequently asked questions

Official sources

1. bootphon/phonemizer on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases