A Pronouncing Dictionary Of American English

Working with A Pronouncing Dictionary Of American English

I spent way too many hours wrestling with this back when I was building a text-to-speech pipeline for an industrial voice project. The CMU Pronouncing Dictionary is the standard reference most people reach for, and for good reason. It is free, well-maintained, and covers a surprising amount of the language. But it also has quirks that will bite you if you treat it like a black box. The raw data lives at github.com/cmusphinx/cmudict. The main file is cmudict-0.7b.txt, which maps roughly 134,000 headwords and their variants to ARPABET phoneme strings. There is also a newer cmudict-1.0 and a cmudict-1.1 if you want the expanded version. Each line has a word, a parenthetical variant number, and then the phonetic transcription. The format looks like this: AEROBIC 0 AE0 R OW1 B IH1 K

The numbers after the vowels indicate stress: 0 means no stress, 1 means primary stress, 2 means secondary stress. Everything else is a consonant. That is the whole encoding system. Simple, once you stop second-guessing it.

A Pronouncing Dictionary Of American English in practice

Here is what actually happens when you load this into your own tooling. You parse each line, build a lookup table keyed on the word token, and handle variant numbers by either keeping all forms or picking variant 0 and moving on. Most people pick variant 0 because they only need one canonical pronunciation. That is fine for general work. I ran into a specific problem last year that almost cost me a week. I was working with medical terminology for a patient communication system, and the word "colostomy" was completely missing from the dictionary. Not rare, not obscure, just absent. The TTS engine fell back to a rule-based renderer that produced something that sounded like "kol-uh-stom-ee" instead of the actual intended "kah-lah-stom-ee." I had to manually add the word and its correct ARPABET transcription into a custom override file, then merge that on top of the base dictionary at runtime. That workaround is basically standard practice. Nobody builds on the raw CMU dict alone. You layer a personal or domain-specific supplement on top and load it first so your custom entries take precedence. The file format is identical, so the merge is trivial. Python code to do it takes about twenty lines.

The ARPABET inventory itself covers about 44 phonemes including diphthongs and schwa. It is not IPA. If you need IPA you have to map ARPABET symbols to IPA, which is mostly mechanical but not perfectly lossless. The mapping is well documented and there are libraries for it, but you should know the difference upfront so you are not surprised later.

Common pitfalls and what the data actually gets wrong

One counter-intuitive thing about this dictionary is that it does not track regional variation. It represents a single generalized American accent. If you need British English or Southern US variants, you are out of luck with this resource. The Oxford English Dictionary paired with its phonetic data handles that better, but the OED is not free and the format is completely different. Another thing people miss: the dictionary is not a pronouncing dictionary in the traditional sense. It does not give you audio files. It gives you phonemic transcriptions. Some tools wrap it with generated speech, but the dictionary itself is text only. If your use case is learning to pronounce words by ear, you need something else. The Merriam-Webster online dictionary with audio is more useful for that purpose. There is also a gap with proper nouns and brand names. If you are building a speech system that reads news articles, you will encounter "Kardashian" or "Zoom" or "Figma" and most of them will either be missing or have a transcribed form that sounds wrong. I stopped trying to fix these at the dictionary level and instead built a post-processing pass that detected capitalized proper nouns and ran them through a separate name-pronunciation model. That cut my error rate dramatically without requiring me to manually curate thousands of names.

How to use it efficiently

If you are building something with this, here is the practical approach that saved me time: The dictionary is version 0.7b as of the last stable release I am tracking, though cmudict-1.1 exists now. Check the repository for the latest. The license is permissive enough for most projects, but read the included LICENSE file before embedding it in a commercial product just to be safe. I mostly stopped maintaining my own fork of the dictionary after moving to a different architecture. The merge-file approach I described above is still the most practical workaround for domain-specific gaps, and it scales reasonably well if you keep your supplement organized by topic area. Medical, legal, technical, brand names. Each category gets its own file, and you load only what your system needs.

For most people using A Pronouncing Dictionary Of American English, the CMU source is the right starting point. Just know its limits before you build on top of it.