musicat: a Tauri music player that tags the files already on your disk

A player for a folder of files, not a streaming catalogue

Musicat is described as a desktop music player and tagger for offline music, and the introduction explains the motivation more precisely: it was built for personal use, with the goal of reconnecting with a local music library in the age of streaming.

The stated design reference points are classic desktop players, Winamp, foobar2000 and iTunes, and the goal is a modern interface that feels familiar next to them. The technical stance is a linked library, using the original files on disk, which means the app is a view over your collection rather than a second copy of it.

That single decision shapes everything else. The tagger writes to the real files, the smart playlists query the same metadata, the folder watcher notices when you add files, and the waveform and stats views are derived from what is actually there. Formats listed in the README are MP3, FLAC, WAV, AAC and OGG, and the metadata work covers reading and writing ID3v2 and Vorbis tags.

For someone who already curates a library by hand, this is the point of the project. For someone whose music lives in a streaming account, there is nothing here to attach to.

Gapless playback, with the sample rate caveat stated up front

Gapless playback is listed as a feature, and the README immediately qualifies it: same sample rate only.

That parenthesis does real work. Gapless playback removes the silence between tracks, and doing that correctly requires the decoder and the output device to agree on the format. When consecutive tracks differ in sample rate, the player has to resample one of them, and the result is either a discontinuity or a gap, which defeats the purpose.

So for a library that was ripped from a single source, or one that was normalised once by a tagger, gapless works as expected. For a mixed library assembled from CD rips, lossy downloads and web sources, the same sample rate restriction means some album boundaries will not be gapless, and the app gives no indication in the feature list of which transitions qualify.

The rest of the playback feature set is more conventional. The library view, an albums view, a queue, and a mini-player are all present, and the screenshots confirm that each is a first-class screen rather than a menu. Keyboard control is thorough rather than partial: Cmd or Ctrl with F to search, Up and Down to move the highlight between tracks with Shift for multi-select, Enter to play the highlighted track, Space for play and pause, I for the info and metadata viewer, Alt with Q for the queue, Alt with A for albums, Alt with L for the library, and Cmd or Ctrl with L for lyrics.

The tagger writes to your originals, which is the point and the risk

Track Info and Tagger is presented as a screen of its own, and the README is direct about the metadata scope: it reads and writes ID3v2 and Vorbis tags, and the library is linked, using original files on disk.

Writing tags in place is the useful behaviour for a curator, because the tags survive whichever player you use next, and they can be read by a file browser, a media server or a command line tool. It is also the behaviour with the most ways to go wrong, since a bad write touches the only copy of the metadata.

Two mitigations are visible in the project structure rather than promised in prose. The repository contains dexie and dexie-export-import as development dependencies, and dexie is the browser-side IndexedDB wrapper, which suggests the app keeps a local database of its own state that can be exported and imported. The app directory also has a base16 directory with its own builder, a theme schema generated from a TypeScript type by typescript-json-schema, and a watcher that rebuilds the theme when the base16 sources change.

What the README does not state is whether the tagger writes to a temporary file and renames, or writes in place, nor whether it can undo a change. For a library you have spent years curating, that is the question to answer before the first bulk edit.

The map view and stats as a meta-layer over the collection

The README has a section for melomaniacs, and its argument is that Musicat should be a meta-layer on top of the library rather than a player with extra screens. The question driving it is how to connect more with a music collection.

The features that fall out of that are unusual for a player. There is a World Map view that shows the library on a map, which comes from artists having an origin country pulled from Wikipedia. There are album art downloads, lyrics fetched for the current song, a Stats screen, an album timeline, and a waveform view. The repository topics list jsvectormap, which explains how the map is drawn, and the dependencies include three with its type definitions, which points to a WebGL based waveform renderer rather than a canvas sketch.

There is also one feature in the list that reads as a joke and is best treated as such: U2's latest album automatically added to your library. It is a statement about the project's playful side, not a requirement.

The Artist's Toolkit is the other idea in this family, and the author is honest about it: a prototype feature you enable in Settings, described as half-baked, that captures the idea of using the app to build your own discography and a knowledge base of song ideas and lyrics. That framing tells you what to expect from the more experimental corners of the app, and it is a good sign that the boundaries are labelled rather than hidden.

Building locally: Svelte, Vite and the Tauri shell

The build steps are short. Set up the Tauri framework and its prerequisites for your platform, install the dependencies, and run the development build:

npm install
npm run tauri dev

Node 22 or newer is required for the install step. The package.json shows the Svelte side in the scripts: build runs vite build, dev runs vite --host, preview runs vite preview, and check runs svelte-check against tsconfig.json for type checking. The tauri script proxies to the Tauri CLI, and the tauri-apps plugins in the dependency list are the ones that give a desktop app its native edges, namely clipboard-manager, dialog, fs, global-shortcut, http, opener, os and shell.

Two details say something about how the project is organised. The repository has a pnpm-workspace.yaml and a pnpm-lock.yaml even though the quick start says npm install, so the workspace definition is what actually governs a multi-package install. And there is a mdsvex.config.js, which means documentation and the UI can share Markdown, plus a .typesafe-i18n.json for the translation layer.

The build:pvr script runs a shell script at src-tauri/lib/build.sh, with a linux-specific variant that targets x86_64-unknown-linux-gnu, so the native side has its own build path separate from the JavaScript one.

Two platform prerequisites the README flags directly

Two environment details are documented because they block a first run, and both are worth knowing before you download a binary rather than after.

On macOS, the app is not signed or notarized yet, so macOS shows a Musicat.app is damaged popup when you open it. The workaround is to remove the quarantine attribute, which the README gives as a terminal command:

xattr -d com.apple.quarantine /Applications/Musicat.app

This is a bypass of a security check, so treat it as a decision rather than a step. The reason for the popup is stated plainly in the README: the app isn't signed or notarized yet. If your organisation has a policy about running unsigned binaries, there is no in-app alternative here.

On Linux, Musicat uses ALSA, and the README asks you to install it if you do not already have it:

sudo apt-get install libasound2-dev

That is a development package rather than the runtime library, which fits a from-source build. The presence of a PKGBUILD at the repository root points to Arch Linux packaging being maintained separately from the app itself.

A 0.x project that warns you about itself, under GPL-3.0

The README carries a warning block that any adopter should read before installing: musicat is currently in major version zero, in active development, features are being added regularly, and things may break or change at any time.

That warning is consistent with the numbers. The version in package.json is 0.17.2, the latest release is v0.17.2 dated 2026-04-05, and the two most recent releases before it were v0.17.1 on 2026-04-04 and v0.17.0 on 2026-04-03. Three releases in three days suggests a burst of work rather than a stable cadence, and the last push to the default branch main was on 2026-08-08, several months after that tag.

So the code base is receiving work, but the tagged releases are not tracking it closely. CHANGELOG.md and RELEASE-NOTES.md at the repository root are where to look for what changed, and the author asks users to keep an eye out for new releases, report bugs and give feedback.

The licence is GPL-3.0. For a personal music player that is mostly irrelevant, but it matters if you plan to modify the source and distribute a build, and it is the reason the license badge sits next to the release badge at the top of the README. Contributions are welcome, with a request to open an issue first for major changes.

Editorial conclusion

Adopt musicat if your music is a folder of files you own and want to keep, you want to tag that library properly rather than in a streaming service, and you are willing to accept a 0.x application that the author warns may change under you. Do not adopt it if your listening happens in a streaming catalogue, if you need a signed macOS build without the gatekeeper workaround, or if you rely on gapless playback across tracks of different sample rates, since the README restricts that to the same sample rate. Verify first that the formats in your collection are covered, the README lists MP3, FLAC, WAV, AAC and OGG, that you install libasound2-dev on Linux before the first run, and that you read CHANGELOG.md and RELEASE-NOTES.md at the repository root before upgrading, since the last release v0.17.2 is from 2026-04-05 and the last push was on 2026-08-08.

Frequently asked questions

Official sources

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