Evidence note: this article rests entirely on what three public GitHub listings say about themselves. Every capability described below is a self-description by the project that published it — the equivalent of a vendor announcement, not an independent test. No one outside those projects has confirmed the claims, none of the three was installed, built, or benchmarked for this piece, and no audio was separated. Where a specific feature is named, the source of that claim is marked on the spot. Statements about what the listings do not say are statements about the public pages themselves.
StemDeck, as described: a free, open-source, local AI stem separator
Searching for "StemDeck" surfaces a project that presents itself in one line: a free, open-source AI stem separator that runs locally (source: the project’s own GitHub listing; not independently verified). Each of those four words carries weight for a musician or a developer evaluating it. "Stem separator" means splitting a finished mix into its parts — typically vocals, drums, bass, and everything else. "AI" points to a learned model rather than classical filtering. "Free" and "open-source" describe the distribution terms. "Local" is the one that matters most in practice, because the alternative in this category is uploading copyrighted audio to someone else’s server.
What the listing does not establish is anything about how well it does that. No separation quality figures, no runtime, no hardware floor, and no named model architecture appear in the description this article examined. A project description is a promise about scope, not a measurement of performance.
Where the code is said to live: the stemdeckapp organization on GitHub
The source code for that separator is published on GitHub under an organization account named stemdeckapp, in a repository called stemdeck (the project’s own repository; claim attributed to the listing itself, not independently audited).
The organization-account detail is a small signal worth noting and worth not over-reading. Publishing under an organization rather than a personal account usually suggests an intent to present the work as a product with a stable home, and it keeps the URL portable if maintainership changes hands. It does not, on its own, indicate team size, funding, release cadence, or maintenance status — none of which the public description settles. Likewise, "open-source" in a project’s own summary describes intent; whether a license file is present and which license it is are things only the repository contents can answer, and this article did not check.
A second listing under the same name: AlexanderLiteplo’s stemdeck
The name is not unique. A second GitHub repository, AlexanderLiteplo/stemdeck, describes itself as an open-source desktop DJ application with AI stem separation built in (source: that repository’s own description; not independently verified).
That is a meaningfully different product category. The first listing describes a tool whose output is files. This one describes an application whose output is a performance — stem separation as a feature inside a DJ interface rather than as the whole program. The two listings do not state any relationship to each other, and nothing in the public descriptions examined here indicates whether one is a fork, a rename, a successor, or an entirely unrelated project that arrived at the same name.
What that desktop app claims to do: keylock pitch and tempo control, and beat sync
The desktop DJ listing names specific features: keylock pitch and tempo control, and beat sync (source: the repository’s own feature description; no independent testing).
For readers outside DJ software, these are the two hard problems of the format. Keylock means changing a track’s tempo without dragging its pitch along with it — speed a record up naively and the vocals go chipmunk, so keylock decouples the two. Beat sync means aligning two tracks’ grids automatically so they play in time, which requires the software to detect tempo and downbeats reliably enough to trust mid-set. Both are well-understood problems with mature commercial implementations, and both are notoriously sensitive to edge cases: live drumming, tempo drift, ambiguous time signatures, and heavy time-stretch ratios.
Naming these features establishes ambition, not quality. Nothing in the listing quantifies stretch range, sync accuracy, or latency, and no third-party evaluation of them was located for this article.
The strongest claim in the set: runs 100% locally, on the user’s own music files
The desktop DJ listing also states that the application runs 100% locally and works with the user’s own music files (source: the project’s own description; not independently verified).
This is the most consequential claim of the three listings, and the one most worth testing before trusting. Fully local operation would mean no upload of copyrighted audio, no account, no per-track cost, no service that can go dark mid-set, and no dependence on venue Wi-Fi — a genuinely different risk profile from cloud separation services. It would also mean the separation model runs on the user’s machine, which implies real hardware demands that the description does not specify.
Crucially, "100% local" is an architectural assertion that is checkable but has not been checked here. A developer can verify it directly by watching outbound network traffic during a separation run, or by disconnecting the machine entirely and confirming the feature still works. Until someone does that, it remains the project’s own statement.
A third stemdeck, and it runs in a browser
A third repository, oric432/stemdeck, is described as a web application for musicians practicing songs (source: that repository’s own description; not independently verified).
The delivery model is the distinguishing fact. A web application implies nothing to install and a URL that works across operating systems — but it also raises the question the desktop listing answered explicitly and this one does not: where the audio is processed. The public description examined here does not state whether separation happens in the browser or on a server, and that gap is open. Browser-side inference for audio is increasingly plausible rather than exotic — as covered in PlayAgit’s look at Hugging Face’s WebGPU kernel library for running AI locally in the browser — but plausibility is not evidence about this particular application.
What the practice web app offers instead: stem separation, a mixer, synced chords, tempo and pitch control
The browser project’s stated feature set is AI stem separation, a mixer, synced chords, and tempo and pitch control (source: the repository’s own description; no independent testing).
Read against the DJ app, the overlap is partial and the intent is clearly different. Both claim separation and both claim tempo and pitch control — but a DJ app uses those to blend two tracks, while a practice tool uses them to slow a passage down without detuning it. The mixer here is for muting the guitar to play along, not for crossfading. And the synced chords feature has no counterpart in the other two listings at all: it implies chord recognition aligned to the timeline, which is a separate analysis task from source separation. No accuracy figures for that chord detection appear in the description.
One name, three different promises
Stated plainly, the three listings promise three different things:
| Listing | Form | Stated purpose |
|---|---|---|
stemdeckapp/stemdeck |
Local application | Free, open-source AI stem separation |
AlexanderLiteplo/stemdeck |
Desktop application | DJ deck with keylock, beat sync, local processing |
oric432/stemdeck |
Web application | Practice tool with mixer, synced chords, tempo/pitch |
All three descriptions are the projects’ own. The shared name appears to be convergence on an obvious compound — "stem" plus "deck" — rather than evidence of a shared codebase, and no relationship between the three is asserted by any of the listings. This pattern of one recognizable name spreading across independent implementations is familiar territory; it also shows up when official platforms and unofficial clients share a label in cloud gaming, where the name tells the user much less than the source does.
How to tell which StemDeck you are looking at before you clone it
The account namespace is the reliable discriminator, and it is visible before any download. stemdeckapp is an organization; AlexanderLiteplo and oric432 are personal accounts. Reading the full path rather than the project name is the entire trick.
Three checks, in the order they cost the least:
- Read the owner segment of the URL, not just the repository name. The three differ only there.
- Match the delivery model to the need. Desktop DJ performance, a standalone separator, and a browser practice tool are not substitutes for one another, and the descriptions state which is which.
- Confirm the license and the local-processing claim in the repository itself. Both are asserted in summaries; both live in the code and the network behavior, and neither was verified for this article.
Developer takeaway: what the public listings settle, and what only installing each one would
The public listings settle identity and intent. They establish that three distinct repositories named stemdeck exist, under three different accounts, describing a separator, a DJ deck, and a practice tool respectively — and that is enough to pick the right clone target without guessing.
They settle nothing about quality. Separation fidelity, CPU and GPU requirements, processing time per track, beat-sync accuracy under live tempo drift, chord-detection precision, actual license terms, maintenance status, and whether the "100% local" claim holds under packet inspection are all open. Every one of those is answerable by a bounded, reproducible test: run the same source track through each of the three, on recorded hardware, with the network monitored, and publish the method alongside the numbers. That comparison has not been run here, and no figure in this article should be read as though it had. It stands as the obvious follow-up — and the honest position until then is that three projects share a name, and only one of them is the one a given reader wants.