Mousai: a native Linux song identifier built on GStreamer and LibAdwaita

One button, one API call, and a song title back

Mousai is a simple application that can recognize songs similar to Shazam. The interaction is one click on a listen button and a wait of a few seconds, and it returns the title and artist of the song.

The application is a native Linux desktop program, not a web page and not a script. The repository is Rust, with a `Cargo.toml` at the root and a `src/` directory, and the UI is GTK4 through the `gtk4` Rust bindings with the `gnome_50` feature enabled, plus `libadwaita` at version 0.9 with the `v1_9` feature. The topic tags confirm it: `gnome`, `gtk`, `gtk-rs`, `linux`, `shazam-like`.

The feature list in the README describes the shape of the application rather than its internals. Identify songs within seconds, or save them for later when offline. Recognise from desktop audio or from the microphone. Build a repertoire of recognised songs. Quickly preview the song within the interface. Browse and listen to the song from different providers.

That last item is worth pausing on, because it is the point where the application stops being a recogniser and becomes a small music player. Once Mousai knows what it heard, it can show you the song, and the preview comes from different providers rather than from AudD, which is a recognition service rather than a catalogue.

The README also includes a preview screenshot in `data/resources/screenshots/preview.png`, and the repository has a `data/` directory with the application icon at `data/icons/io.github.seadve.Mousai.svg`, which is the same identifier the Flathub listing uses.

AudD does the recognition, and the trial limit is the real constraint

The dependency on a third-party service is stated plainly in the README, and it is the single most important fact about the project for an adopter.

AudD is a music recognition API that makes Mousai possible, and the documentation points to their privacy policy and terms of service. The application note is more direct: this uses the API of audd.io, so it is necessary to log in to their site to get more trials.

That last clause is the practical constraint. The application is not a self-contained recogniser. It sends an audio sample to a hosted service, that service matches it against a catalogue, and the service meters how many times you may do that. Running out of trials is a login problem, not a bug, and the documentation says so before you install rather than after.

The acknowledgements section is equally clear about the stack underneath, naming the open-source software projects, libraries and APIs used in developing the app, such as GStreamer, GTK, LibAdwaita and AudD.

So there are three distinct audio paths in this application, and it is worth separating them. Recognition goes out to AudD over the network. Capture comes from GStreamer, which is a local pipeline. Playback and preview are local, served through the same GStreamer stack.

The privacy consequence follows from the first one. Whatever the local pipeline does, a short sample of what you are hearing leaves the machine, and the application is not the component making that decision. That is a design choice the project has made explicit rather than hidden, and the links to AudD's policy and terms are there so a user can check it before relying on the tool.

The dependency set says what the application actually does

The `Cargo.toml` is a good map of the implementation, and every entry corresponds to a visible feature.

`gst` and `gst_play` at version 0.25 are GStreamer and the GStreamer Play library, which handle capture and preview respectively. `soup3` at 0.9 is the GNOME networking library, which is what the HTTP calls to AudD go through. `gtk` at 0.11 with the `gnome_50` feature, and `adw` for `libadwaita` at 0.9 with `v1_9`, are the interface layer, using the current GNOME widget set rather than an older one.

`mpris-server` at 0.10 is the media player remote interface, which is how the application integrates with the desktop's media controls, so a recognised song can be played or paused from the system media menu rather than only from the Mousai window. `fuzzy-matcher` at 0.3 is for searching the local history, and `gettext-rs` with the `gettext-system` feature is the translation machinery, which matches the Weblate translation platform the README points at.

The local storage is `heed` at 0.22 with the `serde-bincode` feature, which is a pure-Rust embedded key-value database, with `serde` and `serde_json` for serialisation and `indexmap` for ordered maps. The `strum` derive macros and `async-trait`, `async-lock` and `anyhow` handle the async plumbing and error types, and `tracing` with `tracing-subscriber` provides the logging.

Two details are worth noting for anyone building it. The release profile sets `lto = true`, and the package requires Rust 1.90 with edition 2024, so a recent toolchain is needed. The dev dependencies add `bincode` for the storage format, `futures-util` for async test helpers and `tempfile` for tests that need a scratch directory.

Two build paths, and only one of them is supported

The build instructions are short, and the recommendation is explicit.

GNOME Builder is the environment used for developing this application, because it can use Flatpak manifests to create a consistent building and running environment cross-distro. The README calls it highly recommended. The steps are: download GNOME Builder, click the Clone Repository button at the bottom using `https://github.com/SeaDve/Mousai.git` as the URL, then click the build button at the top once the project has loaded.

For a manual build, the project uses Meson:

git clone https://github.com/SeaDve/Mousai.git
cd Mousai
meson _build --prefix=/usr/local
ninja -C _build install

The repository supports that with `meson.build` and `meson_options.txt` at the root, a `build-aux/` directory for the auxiliary build scripts, and a `po/` directory for the translation files, which pair with the `gettext-rs` dependency.

The distribution story is where the project's position is clearest. Unlike Flatpak, take note that these packages are not officially supported by the developer. The table lists one entry, a Snap package named `mousai` maintained by soumyaDghosh. And the documentation says you can also check out other third-party packages on Repology.

So the officially supported route is Flatpak, from the Flathub listing at `io.github.seadve.Mousai`, with a Flathub downloads badge in the README. The Snap and any Repology packages exist, and the project points you at them, but they are community maintained.

For a Linux user who wants the application on their system, Flathub is the answer, and the Meson path is for a developer working on the code. The GNOME Builder route exists to keep the Flatpak build reproducible across distributions, which is the whole point of the manifest approach.

What the local storage buys, and what it does not

The save-for-later feature is the one that distinguishes Mousai from a bare Shazam clone, and it is worth being precise about what it stores.

The build-a-repertoire feature is backed by the embedded `heed` database, so recognised songs are kept locally in a small key-value store rather than only being shown once and forgotten. The dependency list has no HTTP client for a music service, no cloud sync component and no account system, so the repertoire is a local file on the machine.

What that gives you is offline listening of things you already identified. The README's phrasing is that you can identify songs within seconds or save them for later when offline, and the preview comes from different providers, which is a separate mechanism from the local record.

The limitation follows from the design. The list is per-machine. There is no account, no sync between machines and no shared library, so a second computer starts empty. And the local store is a cache of recognitions, not a music collection: what you get back is the metadata and a preview, not a local copy of the audio.

For a user who wants a searchable history of what they heard and a quick way to hear it again, that is a reasonable trade. For a user who expected a synced music library, the design is not aiming there, and no amount of configuration changes it.

What you give up, and what you get instead

The honest comparison is not Mousai against Shazam, because Shazam is a closed service with a proprietary client and Mousai is a front end onto a different one. The comparison that matters is Mousai against the other ways to identify a song on Linux.

The first alternative is running the recognition service directly. AudD has a plain HTTP API, so a shell script or a small Python program that captures a few seconds of audio and posts it would do the same job with no desktop integration, no history and no preview. That is a meaningful amount of code to write and maintain, and Mousai's value is precisely that it is already written, packaged and translated.

The second alternative is doing nothing. A Linux desktop has no built-in song identification, and a phone running a Shazam-style app is a different device with its own privacy trade-offs.

What Mousai gives up in exchange is the closed nature of the service. The recognition quality, the catalogue and the trial allowance all belong to AudD, and the application is a well-built client rather than an independent recogniser. It also gives up the possibility of working with no network at all, except for the part of the workflow that has already happened.

The GPL-3.0-or-later licence is the last piece of the picture. For a desktop application distributed through Flathub this is a common and unremarkable choice, and it has no practical effect on an end user. It does mean that anyone who wants to modify Mousai and distribute their own build has to do so under the same terms, which is the normal arrangement for this kind of GNOME application.

Editorial conclusion

Mousai fits a Linux desktop user who wants a native song identifier in the style of the rest of their GTK applications, who does not mind one click sending a short audio fingerprint to a third-party service, and who wants their recognised tracks kept in a local history. It does not fit a user who needs identification to work without an internet connection, and it does not fit anyone who considers sending audio to a hosted API unacceptable. Verify first that you are signed in to audd.io and have trials remaining, since the documentation states this is required, that your system can capture desktop audio through the PipeWire and GStreamer path the application expects, and that the Flatpak build's sandbox permissions cover the audio devices and the network calls the app makes, because the documentation recommends GNOME Builder and the Flatpak manifest as the consistent route.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. SeaDve/Mousai on GitHub