Rune: a Zune-inspired music player with local audio analysis and dynamic mixes

The Zune question, and why it produced this application

Rune is described as a UX experiment inspired by the question: What if Zune had continued to evolve? The README is explicit that it draws from the design highlights of various Windows products since the Windows XP era, including Windows Mobile and Windows Media Center.

That framing tells you what kind of project this is before any feature list does. It is not a new music player built from a blank brief, it is an argument that a specific design language, the one Microsoft applied to hardware that was supposed to be beautiful rather than merely functional, was worth preserving and could be revived with a modern stack underneath.

The motivation section gives the second half of the reasoning. With the rise of streaming services, localized music players have become less common, and many well-known media players have stagnated. Rune aims to offer a clean, consistent and efficient audio playback experience, and the distinctive design is described as respecting user intent with no intrusive ads or unnecessary UI elements.

So the product has two layers. There is the player, which is a local library player with a particular aesthetic. And there is the analysis engine, which is where the interesting engineering sits: the ability to analyse your entire music library and derive recommendations from it, and to build dynamic playlists from rules. The second layer is what makes Rune more than a skin.

The primary language of the repository is listed as C++, though the tree shows a Dart and Flutter front end alongside a Rust workspace, and the description calls it a modern tech stack. The homepage is rune.not.ci, and the project is published on Steam, the Microsoft Store and the App Store, with support stated for Windows, SteamOS, macOS, Linux, Android and iOS.

Dynamic mixes, and the analysis layer that feeds them

The features that distinguish Rune from a conventional player are the audio analysis and the dynamic mix, and they are worth understanding together because the second depends on the first.

The analysis feature lets a user analyse their entire music library to receive recommendations based on tracks, albums or playlists. That is library-wide, not per-track, so it is a batch operation over the whole collection.

The dynamic mix is the more interesting idea, because it is a rule rather than a list. A user creates a mix from customizable rules, and the README gives four examples: Similar to this album, Top 100 most played tracks, Tracks similar to my favorites, and Playlists including specific artists. The key property is that these mixes automatically update as users listen to and add new tracks. A conventional smart playlist updates when you add a track; a dynamic mix in Rune updates as your listening changes what similar to my favorites means.

That last point is what makes the analysis layer load-bearing rather than decorative. The rule Tracks similar to my favorites is a statement about a taste profile that has to be computed from what you play, and it has to be recomputed as the profile shifts. The rule Playlists including specific artists is the ordinary case, and it is the one that needs no analysis. The interesting ones all need a similarity relation over the library.

The repository tree shows where this lives. There is an analysis/ directory and a playback/ directory, a metadata/ directory, a discovery/ directory, a sync/ directory, a tag-editor/, a lyric/ directory, a scrobbling/ directory, and an arroy/ directory, which is a vendored patch of a Rust crate used by the analysis code. The Cargo.toml explains the vendoring: arroy is patched to fix compilation for 32-bit x86 on i686-linux-android, where a use of core::arch::x86_64 inside a cfg(any(x86, x86_64)) block breaks the build.

The other vendored patches are equally specific. core-graphics is patched from a local path, and fdk-aac-sys is vendored to fix MSVC ARM64 on aarch64-pc-windows-msvc, where FDK_archdef.h does not recognise _M_ARM64 under Visual Studio 18, so the preprocessor falls into the warning branch and MSVC 14.51 promotes that warning to a fatal error C1188. The patch adds an _M_ARM64 architecture case without defining __arm__ or __aarch64__, which would pull in GCC-only ARM intrinsics headers.

A Flutter front end over a Rust workspace, with Nix holding it together

The repository layout is unusual enough that it is worth walking through, because it explains how a project with six platform targets stays buildable.

There is a pubspec.yaml and pubspec.lock, which is the Dart and Flutter side, along with analysis_options.yaml and devtools_options.yaml for the Dart tooling, a l10n.yaml for localisation, and a .metadata file. The Dart code lives in lib/.

Alongside it there is a Cargo.toml with a Rust workspace, and the workspace members list names ten crates: native/hub, native/requests, cli, tag-editor, discovery, sync, fsio, fsio-media-source, playback and http-request. The names describe the decomposition: a native hub and a native requests crate, a command line interface, the tag editor, discovery, synchronisation, filesystem input and media source handling, playback, and HTTP requests. Each of those has a matching top-level directory, which suggests a Dart and Rust split where the Rust crates handle the work that needs to be close to the metal and the Dart side handles the interface.

The build tooling is Nix-first. There is a flake.nix and a flake.lock, a nix/ directory, a windows.nix, and the README carries a Nix Flakes badge. There is also a Justfile, a rune.iss file which is the Inno Setup script used to build the Windows installer, and a .circleci/ directory alongside the .github/ workflows.

The platform directories are android/, ios/, linux/, macos/, web/ and windows/, with a native/ directory holding the Rust side, and a database/ and migration/ directory pair for the storage layer, with the migration directory indicating a schema that is versioned over time rather than created from scratch.

There are also several files that say the project uses AI tooling deliberately: CLAUDE.md and GEMINI.md at the repository root, and a .claude/ directory. Those are instructions for automated agents working in the repository, which is a fairly common practice now and worth noticing as a signal about how contributions are expected to be made.

The support model: MPL source, paid licence for real use

This is the part of the project that most needs to be read carefully, because it is unusual and because a reader skimming a badge will get it wrong.

Rune is divided into two release queues that release independently. The Production Queue is maintained by the Rune development team, ensuring no critical issues affect user experience before being pushed to the stores; only software defects are addressed here and no new features are introduced, and fixes go through Dev, Alpha, Beta and RC stages before release. The experimental queue offers experimental features and is maintained by the community; packages from this queue may be available in community repositories, but Rune will never officially push these to users. If a version in the experimental queue reaches production quality after the RC stage, it will replace the version in the Production Queue and be pushed to users.

The support model is the part with the direct commercial consequence. As MPL-licensed open source, Rune is free as in speech, and you can freely modify and distribute it. However, unlike free beer, full community access requires a paid license. The base price starts at $10 globally, though actual costs may vary due to platform policies and regional adjustments.

The tiers are: Paid Members can submit feature requests and receive priority support; Community Members, meaning users of official binary packages, can submit bug reports; and Self-build Users, those who compile Rune themselves, can access community support channels. The full detail is in the SUPPORT.md policy document.

The installation section repeats the point in a way that is easy to miss. The project encourages purchasing and using Rune through the official store channels, since those are maintained by the Rune team. For users with specific needs you can build your own binary package, download the CI-provided binary builds, or use community-maintained packages like Scoop, Homebrew and Flatpak, with the note that while some of these are acknowledged and supported by the developers, they are not officially maintained by Rune, and Rune does not guarantee their stability or security. And then the line that settles it: when using these unofficial sources, you still need to purchase a license to become a genuine user.

So the practical reading is that the source is open under MPL, the binaries are distributed commercially, and building it yourself does not remove the licence requirement. That is a business model rather than a licence quirk, and it is the sort of arrangement that a company adopting the code should have reviewed before it becomes a dependency.

Where Rune is the wrong tool

There are three limits, and they are of different kinds.

The first is the licence, and it is not a limitation of the software but a limitation on who may use it. The rule stated in the README is that a paid licence is required to become a genuine user, including when using unofficial sources. If your organisation has a policy that software must be free of charge, or that open source means free of charge, this project does not fit that policy regardless of the MPL terms on the source. Note the tension in the wording: the source is MPL, the use is gated. The source can be modified and distributed freely, and the running application is a commercial product.

The second is the stability of the production line, and the release list shows it plainly. The recent tags are v2.0.0-alpha.10 on 2026-09-22, v2.0.0-alpha.11 on 2026-10-02, and rinf-vendor-8.7.1 on 2026-10-11, which is the CLI's vendored dependencies. Every visible release of the application line is an alpha, and the production queue is where defect fixes go, with new features arriving only through the community-maintained experimental queue. In practice, a user of the store build gets a stable application with no new features, and a user of a community package gets features at the cost of the stability guarantee Rune explicitly declines to give.

The third is that a local library player is a local library player. Rune's analysis, its recommendations and its dynamic mixes all operate on files it has on disk. If your listening is on a streaming service, the library is not there to analyse. The project targets the case where you own the files, and the richness of the analysis layer is exactly the richness of what it can compute about them.

A fourth practical note for anyone building it: the source tree carries a set of platform-specific patches in Cargo.toml that exist because of specific toolchain and architecture problems, the 32-bit Android build, MSVC ARM64, and the GNU ARM intrinsics headers. Those are signs of a project that supports a genuinely wide range of targets, and they are also signs that a build on an unusual combination of platform, architecture and compiler version may hit problems the project has not patched yet.

Rune against the alternatives

There are two different comparisons, and the difference in approach matters more than the feature list.

The first is against the streaming clients. A streaming service's client is a thin shell over a remote catalogue: the audio arrives on demand, the recommendations come from the service, and the local library barely exists. Rune's approach is the opposite, the library is local and permanent, the analysis runs on your own files, and the mixes are computed from your own listening. The trade is that a local player needs you to own the files and manage them, and the discovery features are limited to what can be inferred from the collection you have rather than from a global catalogue.

The second is against the classic desktop players and the small open source ones. The difference in approach there is mostly about where the value sits. A conventional player treats the library as a list to be browsed, sorted and played. Rune treats the library as a dataset to be analysed, and builds a second interface on top of it, the mixes, which is a different relationship between the user and their collection. Whether the classic design is better depends on what you want: control and predictability, or a set of surfaces that update themselves.

There is a third option worth naming, and it is the one to consider if the audio analysis is what you actually want. A music metadata scanner with an acoustic fingerprinting database, on its own, gives you genre and mood tags, tempo, and the ability to build smart playlists on those attributes, without a whole player around it. That tool answers a narrower question, it does not need to be the application you listen in, and it is a much smaller thing to adopt. Rune's advantage over that is that the analysis and the playback are one product with one library model and one set of mixes.

The deciding question is therefore what your library is. If you own a large local collection and want surfaces that reorganise themselves as your habits change, Rune is doing something the simpler tools do not. If you want a dependable player that plays a directory of files, the feature set is more than you need, and the licence question is more than you want to deal with.

Editorial conclusion

Adopt Rune if you want a local music player that analyses your own library and builds dynamic mixes from it, and you are prepared to buy the licence that the project requires even from community package sources. Do not adopt it as free software, since the project states plainly that a paid licence is needed to be a genuine user. Verify first that the platform you want has a published build in the store or the community repository you plan to use, that your library format is handled by the bundled metadata and analysis code, and that you are comfortable with an application whose new features arrive through a community-maintained experimental queue rather than the production queue.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Losses/rune on GitHub
3. Project website
4. README
5. Releases