# The repository holds the source; the layout diagram shows a build output

> ARIA turns Windows system audio into live subtitles in a movable overlay, in two builds: a 600 MB one that leans on the operating system's own captioning feature and a 7.6 GB one that brings three recognition engines and four offline models. GPL-3.0, Python, one release tag from February 2026, and a manifest that says version 1.0.0.

**sayksii/Aria** — ARIA - AI Realtime Intelligent Audio | Universal real-time AI subtitles for Windows

- Repository: https://github.com/sayksii/Aria
- Stars: 330 · Forks: 16
- Language: Python
- License: GPL-3.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/sayksii-aria

## The repository holds source, and the layout diagram shows what packaging produces

The project layout section draws a tree with an embedded Python runtime, a models directory holding the offline weights, two batch launchers and a nested lite package with its own runtime, its own source and its own launcher. Compare that with the default branch, which contains a gitignore, a changelog, the licence, two readmes in two languages, a directory for readme images, the project manifest and one source directory. None of the launchers is there. No embedded runtime, no models, no lite package. So every line of that diagram except the source folder is a packaging artefact, and the diagram is describing the shipped archive rather than the repository. Useful information, but filed under a heading that reads like a map of the tree you just cloned.

## The smaller build has the stricter operating system floor

The downloads table puts the requirements side by side and they disagree in an instructive way. The 600 MB build needs Windows 11 version 22H2 or later. The 7.6 GB build needs Windows 10 or 11. So the smaller package refuses to run on machines the larger one would accept, which is the opposite of the usual relationship. The reason is the architecture: the small build contains only the mode that delegates to the operating system's captioning feature, so it inherits that feature's system requirement and has nothing to fall back on. The file states the same fact as advice rather than as a constraint, telling you to choose the small build if the Windows feature covers your use and the large one when you need local recognition, offline models, or more control. The size ratio is twelve to one.

## The single release tag is not where the downloads are

There is one GitHub release, tagged for version 2.0.0 in its lite form, published on 2026-02-08. The downloads table does not link to it. Both builds are hosted on two third-party file services, one general-purpose and one regional, and the regional links carry their extraction password inside the query string of the URL itself. That means the file, in plain text, contains both the location and the key for each archive. So the release page exists, holds a single artefact from eight months before the last commit, and is not on the path a new user takes. The default branch was last pushed on 2026-08-09.

## The mode that uses the Windows feature is driven by four automation libraries

The recognition table describes the third mode as using the operating system's captioning feature and needing no GPU or compute setup. The dependency list explains how. Sixteen runtime requirements are declared, and the last four sit under a comment naming them as the dependencies for that mode: a Windows automation framework, a UI automation library, a bridge to the component object model, and a library that moves the keyboard and mouse. That is the standard stack for scripting another application's interface. So the mode is not an interface call into a captioning service; it is an automated user driving a settings surface. It also explains the otherwise odd packaging fact that a 600 megabyte build ships an embedded Python interpreter, which a native feature would not need.

## A tray library and a model hub client are dependencies the readme never accounts for

Two more entries in the dependency list have no counterpart anywhere in the documentation. One is a system tray library paired with an imaging library, which together are the usual recipe for an icon in the notification area rather than in the taskbar. The readme describes two movable overlay windows and says nothing about a tray. The other is a client for a model hosting service, which is the normal way weights are fetched at runtime. The readme's model table presents four models as included in the large package with their sizes, and describes no download step, no cache directory and no first-run network access. Neither dependency is contradicted outright, since an included model and a hub client can coexist, but both are capabilities a reader would expect the file to mention.

## The manifest says 1.0.0 and Alpha, and the product says v2

Four version-shaped facts do not agree. The project manifest names the distribution after subtitles rather than after the product, gives it version 1.0.0, and classifies it as alpha development status. The readme is titled for version 2. The one release tag carries 2.0.0. And the manifest expresses the licence in the older table form with a text key rather than as a licence expression string, a form that newer packaging tooling reads less reliably than the plain string it replaced. The alpha classifier is the one to think about: a project on its second named version with a single release and an alpha status is a product that has renamed itself more than once, and none of the three signals tells a new user which one to trust.

## No automation directory, a changelog and a configured linter

The manifest configures a linter with a line length of 120 and a target interpreter, and declares both that linter and a test runner in a development dependency group. The repository has a changelog at the root. The default branch listing, which does include a dotfile, has no automation directory at all. So the project has a formatter policy, a test dependency, a changelog and nothing that runs any of them on commit. Whatever keeps those settings and that changelog current is a person remembering to do it. This is the smallest of the observations in the file and the easiest to fix, and it is the one most apt to already be handled outside the branch the listing describes.

## Two ways in, and neither is the one the readme describes

The manifest registers one console script, named after the product, pointing at a run function in the user interface module, and the wheel is built to include one source package directory. So installing from a package index gives you a command you type. The readme instead tells Windows users to start a batch file, with one batch file per build and different names for each. The two paths are not connected by anything the file explains: there is no script that produces the batch files, no note that the batch files are for people who cannot use a terminal, and no statement about whether the registered command is supported. For a desktop overlay application aimed at end users, the batch file is the deliberate choice on any sensible reading, which makes the absence of a sentence saying so the actual gap. The two builds differ there too: the small one starts a file whose name does not contain the word lite, so a user who extracted both archives into one folder has two launchers and only one of them is named for what it does.

## Conclusion

ARIA is worth trying if you need live captions for calls or streams on Windows and want a movable overlay plus a separate translation overlay, since the three recognition modes cover a GPU machine, a CPU-only machine and the operating system's own feature in one interface, and the full build needs no separate Python installation. It is not the right choice if you need an NVIDIA GPU, if you want offline translation, because the local model ships only in the large build, or if you want to install from a package index, because the readme's entry point is a batch file per build and nothing connects that to the registered command. Before you download, check which Windows version you have, since the smaller build has the stricter floor, and check whether the offline mode matters more to you than the download size, because that decision is the difference between 600 megabytes and 7.6.

## FAQ

### Which version of Windows does ARIA need?

It depends on which build you take. The 600 MB build needs Windows 11 version 22H2 or later because it only uses the operating system's captioning feature. The 7.6 GB build needs Windows 10 or 11 because it brings its own recognition engines, and an NVIDIA GPU is recommended for its most accurate mode.

### Do I need to install Python to use ARIA?

No. The readme states that the package includes its own Python runtime, and the project layout confirms an embedded interpreter directory in both the large and the small build.

### What recognition modes does ARIA offer and which engines back them?

Three. An accurate mode backed by a Whisper implementation that works best on an NVIDIA GPU, a fast mode backed by two different speech engines covering Chinese and English with one and Japanese with the other, and a mode that uses the operating system's captioning feature and needs no compute setup.

### Can ARIA translate without an internet connection?

Only in the large build. Recognised text can be sent to three online translation services or to a local translation model that the readme says is included with the large package. The file recommends the local model when offline operation and predictable availability matter, and notes that the online services can be rate-limited or change without notice.

### Where do I download ARIA?

Two third-party file hosts, a general-purpose one and a regional one, with the extraction password for the regional links embedded in the link itself. The single GitHub release, tagged for version 2.0.0 in its lite form and published on 2026-02-08, is not linked from the downloads table.

## Sources

- [Issues](https://github.com/sayksii/Aria/issues)
- [License: GPL-3.0](https://github.com/sayksii/Aria/blob/main/LICENSE)
- [README](https://github.com/sayksii/Aria/blob/main/README.md)
- [Releases](https://github.com/sayksii/Aria/releases)
- [sayksii/Aria on GitHub](https://github.com/sayksii/Aria)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sayksii-aria