forced-alignment-tools is a catalogue of speech aligners, not an aligner

The deliverable is a comparison table, and it is versioned like one

The first thing to understand about forced-alignment-tools is that it contains no alignment code. It is a collection of links and notes on forced alignment tools, and the payload is a matrix that lists sixteen open source programs and libraries for computing forced alignments.

The repository is maintained in a deliberately structured way. The top level holds a LICENSE, a README, a README.template, a VERSION file, a .gitignore, a Python script called data_to_md.py and a data.json file that contains the same information in raw JSON form. The README states that the raw data file can be downloaded in JSON format, and the presence of a template plus a generator script makes the workflow obvious: the data lives in data.json, the script renders it, and the README is the generated view of it.

The README also carries its own version header, version 1.0.12 dated 2026-07-22 with the author named, and the licence field on the repository says Other because GitHub cannot classify the notice. The README spells out which one it is, the Creative Commons Attribution 4.0 International licence, which is the right choice for a catalogue of links and notes about other people's software.

The last push to the repository was on 2026-07-22, the same day as the version stamp, and there are no GitHub releases, so the VERSION file inside the repository is the only version marker a reader gets.

Granularity is the axis that actually decides your tool

The README defines forced alignment precisely, and the definition is the most useful part of the document. Given an audio file containing speech and the corresponding transcript, computing a forced alignment is the process of determining, for each fragment of the transcript, the time interval in the audio file containing the spoken text of that fragment.

The fragment can be defined at several levels: a paragraph, a sentence, a clause or portion of a sentence, a word, or a phoneme, meaning a single sound. What the definition does not say is that these levels are equally hard. The README is explicit that a given aligner might be designed to produce a good alignment only at a specific granularity, while it might produce incorrect results or even no output at all at finer granularities.

That warning is the reason the matrix has a column for the finest supported granularity, and it is the column most worth reading first. The example in the README is a verse level alignment, where each line of a poem is matched to a time interval.

1                                                     => [00:00:00.000, 00:00:02.640]
From fairest creatures we desire increase,            => [00:00:02.640, 00:00:05.880]
That thereby beauty's rose might never die,           => [00:00:05.880, 00:00:09.240]
But as the riper should by time decease,              => [00:00:09.240, 00:00:11.920]
His tender heir might bear his memory:                => [00:00:11.920, 00:00:15.280]

The example comes from the aeneas project, with the text file and audio file linked from that project's test resources. Typical applications listed are audio ebooks, closed captioning and automating the creation of training data for automated speech recognition systems.

Every row records algorithm, interface, licence and activity

The matrix has twelve columns: name, algorithm, finest supported granularity, supported languages, interface, code languages, licence, documentation, mailing list or forum, whether it is active, and notes.

The algorithm column is where the tools genuinely differ. The rows cover dynamic time warping, hidden Markov models from several families, including HTK based models, models built on Kaldi, and recurrent neural network approaches. The README draws one line that cuts across the whole table: all tools except aeneas are based on speech recognition algorithms, and all tools except aeneas and gentle are maintained by research groups or individuals in academia.

Language support is uneven in an instructive way. Several rows list English only, while aeneas lists 30 plus languages, the Montreal Forced Aligner lists 40 plus, and SPPAS lists 12 plus with the note that it can train other languages and ships several plugins. The notes column flags extendability, for instance that CTC segmentation can be extended to any other language where an automatic speech recognition model is available, and that Prosodylab-Aligner can train other languages.

The interface column distinguishes command line, library callable by third party software, and web based graphical interfaces, local or remote. Reading across it, the command line and library rows are where the C, C++ and Python implementations live, while the web entries cluster among the academic tools.

The licence column is where the HTK problem shows up

Licence is the column with the most consequential entries, and the README adds a paragraph about it that no table row can carry.

Most tools are based on HTK, which is not free for commercial purposes, although a commercial licence can be purchased from the University of Cambridge. That is a specific and unusual constraint. A tool can be open source, carry an MIT-like or Apache or GPL notice, and still be unusable for a commercial product because the acoustic modelling stack underneath it is not free for commercial use. Anyone reading the licence column alone would miss that, so the paragraph matters more than the rows.

The rows themselves are mixed. One entry carries an all rights reserved licence, one is AGPL, several are GPL, several are MIT or MIT-like, and some are simply unknown, marked with a question mark. Two entries also lack full documentation and are marked with a README or a README and a tutorial instead of a yes in the documentation column.

The activity column uses a simple yes, no or a qualified no with a question mark, which is an honest way to mark uncertainty about projects that have gone quiet. The maintenance posture of the catalogue as a whole is different from the posture of the tools in it, and the two should not be conflated.

The data behind the table is the actual artefact

For anyone who wants to use this comparison rather than just read it, the data.json file is the point. The README offers it as a download in raw JSON format, and the repository includes data_to_md.py, a Python script, which is presumably the generator that turns that JSON into the markdown table in the README, with README.template holding the surrounding prose.

This structure has a practical consequence. The table in the README is a rendered view, and a downstream tool, a lab wiki page or a paper can consume the JSON without scraping markdown. It also means the content is a database in a very small sense, and that the cost of adding an aligner is a data edit rather than a rewrite.

The maintainer asks for contributions in a specific way: did I miss an aligner, please open an issue or directly fork-commit-pullrequest. Since the repository has no GitHub releases and no CI configuration in the top level listing, the version header in the README and the VERSION file are the only signals of how current the data is, and the last push date of 2026-07-22 is the freshest one available.

What the catalogue will not tell you

The scope is narrow, and the README says so with unusual precision. The matrix contains open source programs and libraries for computing forced alignments that have been actually proven to install and run, albeit the installation procedure for some of them is pretty complex.

So every row is a claim of working software, and the parenthetical is the catch. Proven to install and run is not the same as documented, and the installation procedures themselves are not reproduced in the repository. The catalogue points at the tools, it does not hold them.

There is also no accuracy or speed comparison anywhere in the README. The columns describe what a tool is, not how well it does, so a reader who wants to know which phoneme level aligner is most reliable on a particular accent or corpus still has to run them. Similarly, the finest supported granularity column is a capability statement, not a quality statement.

The table is also English and Western English heavy. A dozen of the sixteen rows list English only, and the rows that cover other languages do so unevenly. For a research group working in a language outside that set, the useful conclusion from the catalogue is negative: the tool you need is either the one that can be trained for your language, the one built on acoustic models you supply yourself, or a tool that is not listed here at all.

Editorial conclusion

Use forced-alignment-tools when you are choosing an aligner and need to know in one place which projects reach phoneme level, which are command line, and which licences will let you use them commercially. Do not use it as an installation guide, since the repository states that the installation procedure for some of the tools is pretty complex and contains no steps of its own. Before you commit, read the licence column closely, because most of the listed aligners are built on HTK, which is not free for commercial purposes unless a licence is purchased from the University of Cambridge, and open an issue if a tool is missing, since the maintainer asks for exactly that.

Frequently asked questions

Official sources

1. Issues
2. pettarin/forced-alignment-tools on GitHub
3. README