wav2letter++ Is Now a Recipe Archive: What the Flashlight Consolidation Means for ASR Work

The Repository Is Now a Pointer, Not a Product

The first thing the README tells you is that wav2letter has been moved and consolidated into Flashlight, under the ASR application, and that future wav2letter development will occur there. That sentence reframes everything else on the page. This is not a toolkit you evaluate on its own merits any more. It is a historical snapshot with a set of research recipes attached.

The release history supports that reading. v0.2 is labelled pre Flashlight-consolidation and carries a December 2020 date. v0.1 goes back to December 2018. Two releases, two years apart, and then nothing. The README also points readers who want the old code at the v0.2 tag, which depends on the correspondingly old Flashlight v0.2 release, and notes that the wav2letter-lua project lives on its own branch. So the repository is really three artefacts in one: a frozen C++ codebase, a branch holding a Lua-era implementation, and a recipe collection that still gets referenced.

Who is this for, then? Not a team starting a speech recognition product. The plausible audience is narrow: researchers who need to reproduce a specific published result, and engineers who want to read a reference implementation of end-to-end ASR in C++ rather than Python. If you fall outside those two groups, the consolidation note is the whole review.

Five Recipes, Five Papers, One Version Pin

The recipes directory is the part of the repository with continuing value. The README lists five papers with corresponding recipe paths: streaming_convnets for Pratap et al. (2020) on scaling online speech recognition with ConvNets, sota/2019 for Synnaeve et al. (2020) on end-to-end ASR from supervised to semi-supervised learning, self_training for Kahn et al. (2020), lexicon_free for Likhomanenko et al. (2019) on lexicon-free recognition, and seq2seq_tds for Hannun et al. (2019) on sequence-to-sequence recognition with time-depth separable convolutions.

Pre-trained models are mentioned as included. Data preparation for training and evaluation is said to live in the data directory.

The constraint that matters most is stated in a single line: all results reproduction must use Flashlight <= 0.3.2 for exact reproducibility. That is an upper bound, not a floor. It means the recipes are welded to an old Flashlight API surface, and any attempt to run them against a current Flashlight checkout is outside what the documentation promises. The build instructions reinforce this by requiring the 0.3 branch of Flashlight specifically, alongside the ASR application.

That pin is the honest engineering choice for reproducibility, and it is also the repository's main cost. You are not adopting a maintained dependency graph. You are adopting a snapshot of one, and the recipes are only as reproducible as that snapshot stays fetchable.

How the Build Actually Works

The build path in the README assumes Flashlight with the ASR application is already installed. The recipe build itself is a standard CMake out-of-source flow:

mkdir build && cd build cmake .. && make -j8

Dependency discovery is the part that trips people up. If Flashlight or ArrayFire sit in nonstandard paths because you used a custom CMAKE_INSTALL_PREFIX, the README says to pass both prefixes explicitly when running cmake:

-Dflashlight_DIR=[PREFIX]/usr/share/flashlight/cmake/ -DArrayFire_DIR=[PREFIX]/usr/share/ArrayFire/cmake

Note that both flags are needed. ArrayFire is the tensor backend underneath, and a Homebrew or source install that lands outside the default search path will not be found without that second flag. The README does not enumerate the full dependency list beyond Flashlight and ArrayFire, so treat the cmake configure step as the place where missing pieces surface.

The repository also carries a CircleCI badge, which tells you continuous integration existed at the time the README was written. It says nothing about whether that pipeline still passes against the pinned Flashlight 0.3 branch today.

The Version Pin Is Also the Failure Mode

Pinning to Flashlight <= 0.3.2 buys reproducibility and sells everything else. The practical consequences are worth spelling out.

First, the recipes cannot follow upstream fixes. If a bug in Flashlight 0.3.2 affects your training run, the documented path does not let you take the fix. Second, the surrounding ecosystem moves on. Compiler versions, CUDA versions and ArrayFire releases all drift, and the README offers no compatibility matrix for any of them. A build that worked when the recipes were published may need patching purely to compile. Third, the recipes are described as reproducing research results, not as a supported training pipeline. There is no statement about production hardening, latency targets or serving.

The wrong-tool case is clear. If your goal is to fine-tune an ASR model on your own audio and ship it, this repository gives you no supported route. The consolidation note already tells you where active work happens, and the version pin tells you the recipes are not meant to travel. Using them as a starting point for a new system means inheriting a dependency freeze on day one.

Where It Sits Next to ESPnet and Kaldi

The obvious comparison is Kaldi, and the difference is architectural rather than cosmetic. Kaldi is built around a traditional pipeline with explicit acoustic, pronunciation and language model components, and a lexicon sits at the centre of decoding. The Likhomanenko et al. recipe here is titled Who Needs Words? Lexicon-free Speech Recognition, which is the opposite stance: the acoustic model maps audio to output units without a pronunciation dictionary. That is a real fork in approach, not a packaging difference.

Against a Python-first toolkit, the distinction is language and deployment. wav2letter++ is C++, and the README's framing as an end-to-end toolkit built on Flashlight and ArrayFire reflects that. If your team lives in PyTorch and wants to modify model code interactively, a C++ codebase with a pinned backend is friction you are choosing deliberately. If you need a C++ inference path or you are studying how the published architectures were implemented, the language is the reason to look here at all.

The honest summary: choose wav2letter++ when the paper is the point. Choose something else when the product is the point.

Maintenance Cost and the Licence Question

Maintenance cost here is not a subscription, it is a one-time archaeology bill. You will spend it on locating the right Flashlight branch, getting ArrayFire discovered, and patching whatever no longer compiles against your toolchain. After that the stack is static, which is either reassuring or alarming depending on whether you need it to change.

The README states that wav2letter++ is MIT-licensed, as found in the LICENSE file. The repository metadata, however, reports the licence as NOASSERTION, meaning the automated classifier could not confirm a standard licence from the files it inspected. Those two signals disagree, and the disagreement is worth resolving before you rely on either. Read the LICENSE file in the tree yourself, and if the licence terms matter to your organisation, have someone qualified review them. Nothing here is legal advice.

One more cost that is easy to overlook: the community channels listed in the README are a Facebook group, a Google group and a Gitter chat, plus a list of individual contact addresses. Gitter in particular has fallen out of favour for many projects, and there is no statement about how actively any of these are monitored now that development has moved to Flashlight.

What to Check Before You Clone

Three checks decide whether this repository is useful to you, and all three are cheap.

Confirm the recipe directory you need exists on the main branch. The README names five paths; verify the one you care about is actually there rather than trusting the list.

Confirm your Flashlight checkout resolves to 0.3.2 or the 0.3 branch. The README is explicit that the 0.3 branch is required and that reproduction must use Flashlight <= 0.3.2. If your environment already has a newer Flashlight, you have a conflict to resolve before the first cmake call.

Finally, decide in advance how you will handle the ArrayFire path. If it is installed anywhere other than a standard prefix, you need the -DArrayFire_DIR flag at configure time, and you should plan for that rather than discovering it from a failed configure. If your work depends on the Likhomanenko et al. lexicon-free recipe or the streaming ConvNet recipe, this repository is the documented route to it. If it does not, the consolidation note is the answer, and the answer is Flashlight.

Editorial conclusion

Adopt wav2letter++ only if you need to reproduce one of the five listed papers, in which case pin Flashlight to 0.3.2 or the 0.3 branch and accept that you are building a frozen stack. Do not adopt it as the base for a new ASR system, because the README states that future development occurs in Flashlight and the last release, v0.2, dates from December 2020. Before committing, verify three things: that the recipe directory you need is present on the main branch, that your Flashlight checkout resolves to 0.3.2 rather than a newer tag, and that your build finds ArrayFire through the documented -DArrayFire_DIR flag if it lives outside a standard prefix.

Official sources

1. flashlight/wav2letter on GitHub
2. Issues
3. Project website
4. README
5. Releases