Why I Started Building My Own Windows Music Player - Auricle

CaliforniaAlmonds — Tue, 15 Sep 2026 04:54:40 +0000

I wasn’t looking for another project. I just wanted a music player I could leave running while gaming or streaming without wondering how much memory and CPU it was using.

I’d used Spotify and Apple Music’s Windows apps, but their resource usage bothered me often enough that I started looking elsewhere. Not every player uses Electron, and Electron alone doesn’t make an app inefficient. Still, I kept wishing for something that felt like a focused desktop application.

YouTube Music had the catalogue I wanted, but no official native Windows desktop player. The browser and installable web app were options, just not quite the experience I was looking for.

So I tried open-source alternatives.

Some came close. But I kept running into a different compromise: an interface I didn’t enjoy, a missing feature, or a workflow that never quite felt comfortable. Nothing made me want to stop searching and settle in.

Eventually, “there must be something that fits” turned into “maybe I should try building it.”

Starting With a Small Wish List
That became Auricle, a Windows music player built with Rust and Slint.

My goals were straightforward: low resource usage, a good interface, solid autoplay and enough practical features to use it regularly. I chose a native UI rather than an Electron or embedded-webview approach.

That choice isn’t a performance result, though. “Built with Rust” doesn’t automatically mean lightweight. Efficiency still needs to be measured, especially while something else demanding is running.

The Complicated Part Is Everything Around Play
A music player sounds simple until you start thinking about the whole experience.

Search results need to be useful. The queue needs to behave predictably. Playback controls need to respond without freezing the interface. A local library needs to remember what matters.

Then there are the parts outside the UI: stream extraction, optional add-ons, upstream service changes, packaging, and updates. Using native frameworks doesn’t make those problems disappear.

Even distributing an early build brought another complication. The unsigned installer received antivirus detections, while separate scans of the installed and portable application executables reported none.

It’s a reminder that building the application and making it trustworthy to download are separate responsibilities.

Still an Early Project
Auricle isn’t my claim that I’ve solved desktop music players. It’s my attempt to build the experience I kept looking for.

It’s Windows-only for now. I’d like to explore Linux eventually, but first I need to understand how the Windows version behaves beyond my own setup.

The original frustration was simple: I wanted to spend less time thinking about the player and more time listening to music. Now I’m learning how much work goes into making that possible.

Check it out here: Auricle GitHub

An unsigned Windows installer was flagged, but its executable was not

CaliforniaAlmonds — Tue, 15 Sep 2026 04:45:49 +0000

While preparing an early release of my Rust and Slint Windows music player, Auricle, I ran into an antivirus discrepancy: the installer was flagged, but the application inside it was not.

Here is what the investigation established, and what it did not. This is a snapshot from September 15, 2026, not a claim that the software is safe.

Compare the actual artifacts

A fresh VirusTotal analysis reported:

Inno Setup installer: 3/70 detections.
Application extracted from that installer: 0/69 detections.
Application extracted from the portable ZIP: 0/70 detections.

The installer detections were Microsoft Trojan:Win32/Wacatac.B!ml, SecureAge Malicious, and Skyhigh BehavesLike.Win32.ObfuscatedPoly.vc. All three executable artifacts were unsigned.

The two application binaries were not interchangeable test samples. The portable build enabled self-update, while the installer build used --no-default-features. Scanning the portable binary alone would not have tested the actual installed payload.

Inspect without executing the installer

The installer was extracted with innounp after checking the extractor archive against its published SHA-256. It identified Inno Setup 6.7.0 and one application executable. The recovered installation script copied that executable, created shortcuts, and optionally launched the application. No custom Inno [Code] section was found.

The original installer hash also matched the digest in the GitHub release metadata. That establishes which published artifact was inspected, not that the binary is reproducibly built or free of malicious behavior.

Read the event behind a sandbox label

One sandbox result included an 'Unsigned Image Loaded Into LSASS Process' rule. The matching event named a DLL outside the application directory, not a file bundled in the installer. Its origin remains unverified.

That matters in both directions: the label alone did not establish that the application caused it, but absence from the installer did not establish that the event was harmless either. A targeted source search is useful evidence, not an exhaustive audit of a compiled program and its dependencies.

Ask the detecting vendors

Review requests were submitted to Microsoft, SecureAge, and Skyhigh with the unchanged installer or its public download link, exact hashes, and the separate scan results. At the time of writing, no final vendor clearance has been confirmed.

I did not rebuild repeatedly to change hashes or disable antivirus protection. A low detection count is not proof of a false positive; zero detections is not proof of safety.

Signing is a separate step

Code signing is still pending for this project. It can establish publisher identity and artifact integrity, but it does not guarantee antivirus clearance. For a future signed release, the application needs signing before packaging, followed by signing the installer and computing distribution hashes from the final artifacts.

The useful outcome so far is a narrower, reproducible question for the vendors: why is this exact installer classified differently from its extracted payload?

AI disclosure: GitHub Copilot assisted with the investigation and drafting this write-up. The reported observations come from the release artifacts and scan reports; unresolved findings are explicitly identified.