Why another sample browser?

I didn’t set out to build a company. I set out to fix my own library: thousands of samples across old Splice downloads, a couple of hard drives I’d half-organized during a lockdown, and folders full of files named things like new_sounds_FINAL_v2. Every “smart” sample manager I tried promised to fix this, and most of them just read filenames a little faster than I could scroll through Finder myself. That’s not intelligence, that’s a faster spreadsheet.

The actual problem is that most tagging in this category is still filename-and-folder-first. It works fine if your file is named Kick_808_DarkTechno.wav, and falls apart the moment you hit Audio_49.wav. So I built the opposite: analyze the sound itself first, and treat the filename and folder as a supporting signal, not the source of truth. A few things followed from that one decision:

Genre and instrument had to come from listening, not from guessing at a path
A badly organized library couldn’t be a dealbreaker
The whole thing had to work fully offline, because tagging your own audio shouldn’t require sending it anywhere

None of that is revolutionary by itself. Semantic search and a visual map of a library get you part of the way there, and by now plenty of tools do some version of both. What I haven’t seen yet, and what I keep thinking about, is what comes after filtering: a way to actually browse a library that isn’t just narrowing down a list. That’s still an open problem, and probably worth its own post. For now, Curate is my attempt at getting the fundamentals right first: audio-first tagging, no subscription, and yes, it runs on Linux too.