kew: a terminal music player for people who want their library back

What kew replaces, and for whom

kew is a music player that lives in a terminal. The README calls it "a terminal music player" and the name is pronounced /kjuː/, a variant of cue. The problem it addresses is not playback, which is solved many times over, but the layer above playback: browsing a local collection, building playlists, and doing both without a window, a mouse, or a service deciding what you hear next.

The stated audience is anyone with files on disk. The README lists Linux, FreeBSD, Android, macOS, Windows and others, and the Makefile detects Termux by looking for /data/data/com.termux/files/usr, so Android is treated as a first-class build target rather than an afterthought. Two features define the intended workflow. The first is auto-generated playlists from words in the artist, album or song name, with the README giving 'kew nirvana' as the example. The second is privacy: the README describes kew as "Private and offline", with the single exception that it can display listening status in Discord, which it says is now opt-in.

That combination is a deliberate position. A player that generates playlists from your own tags is making a claim that your library is the recommendation source. If you mostly stream, kew has nothing to offer you.

How kew plays: C, a Makefile, and feature flags that change the binary

The repository is C, built with a Makefile that exposes most of the interesting decisions as variables. USE_DBUS defaults to 1 on Linux, FreeBSD and similar systems, and to 0 on Darwin, Termux and MinGW or MSYS, which is how desktop integration is wired per platform. USE_MACOS_MEDIA defaults to 1 only on Darwin, and USE_SMTC defaults to 1 only under MinGW or MSYS, so Windows media key integration is a compile-time choice rather than a runtime one.

Two flags deserve attention before you build. USE_FAAD=0 disables faad2, which is the AAC decoder, so turning it off removes support for the AAC-family formats the README lists. ENABLE_CAP_SYS_NICE=1, passed to make install, grants CAP_SYS_NICE for real-time scheduling, and the Makefile comment states plainly that this breaks MPRIS on some systems and points to the real-time scheduling section of docs/MANUAL-INSTALL-INSTRUCTIONS.md. That is an honest trade-off documented in the build file itself: lower scheduling latency in exchange for desktop media controls that may stop working.

The dependency surface is wider than the flag list suggests. The Makefile uses pkg-config and sets PKG_CONFIG_PATH to /opt/homebrew/lib/pkgconfig and /opt/homebrew/share/pkgconfig on Apple Silicon, which tells you the project expects Homebrew-provided libraries on macOS. Audio output, decoding, cover rendering and desktop integration are all external concerns the build resolves at compile time. A kew binary is therefore not a single portable artifact; it is a build configuration.

Installing kew and playing your first track

The README does not contain install instructions. It says to visit the website for information on how to install, use and contribute to kew, and points to https://kewplayer.com. The README also carries a Repology packaging status badge, which is the signal that distribution packages exist for at least some platforms. Check that badge against your distribution before building from source.

The repository does ship a manual install path. docs/MANUAL-INSTALL-INSTRUCTIONS.md is referenced from the Makefile comment about real-time scheduling, so that file is where the build flags are explained in prose. The top-level Makefile is the entry point:

make
make install

make with no arguments builds with the auto-detected defaults. make install places the binary under PREFIX, which defaults to /usr/local. If you want the real-time scheduling capability, the Makefile documents the variant:

make install ENABLE_CAP_SYS_NICE=1

For a debugging build, the Makefile comment gives make DEBUG=1. To build without desktop notifications on a system where DBus is present, the documented form is:

make USE_DBUS=0

After installation, the first real use is the playlist generator the README describes. If your library contains tracks by an artist whose name you remember, the README's example is:

kew nirvana

What you should see is a generated playlist drawn from matches on the artist, album or song name, not a search results list. The README does not document the exact matching rules, so treat the first run as a way to learn how your tags behave. If your files are untagged, this feature has little to work with, which is the practical argument for a tagged library before you adopt kew.

Formats, and the three the README will not promise you

kew supports m4a, raw aac, mp3, flac, wav, webm, opus and ogg. That covers the common lossless and lossy cases, and flac support is explicit, which matters because it is the format people ask about when choosing a Linux player.

The README then lists three formats under a heading that reads "With caveats, not supported": HE-AAC, E-AC-3 and ALAC. This is unusually direct. Most players either support a format or omit it from the list; kew names the gap. ALAC is the notable one, because it is Apple's lossless codec and it is common in libraries ripped through iTunes or Apple Music. If your collection is ALAC, kew is the wrong tool and the README says so before you install it.

HE-AAC and E-AC-3 are the other two. Both are AAC-family variants used in broadcast and streaming contexts rather than in personal rips, so their absence is unlikely to affect a library of purchased or ripped albums. It will affect archived video audio tracks. The decoder flag matters here: USE_FAAD=0 removes faad2, and faad2 is the AAC decoder, so building with it disabled narrows the supported list further than the README's caveat section implies.

Covers, themes and the terminal you actually have

The feature list includes full color covers in sixel-capable terminals, a spectrum visualizer, auto-generated themes based on album colors, and custom themes. Sixel is the constraint worth understanding. It is a bitmap graphics protocol supported by some terminals and not others, and the README's phrasing is precise: covers are full color in sixel-capable terminals. In a terminal without sixel, that feature does not degrade gracefully into something else; it simply is not available as described.

Auto-generated themes based on album colors are a related dependency. The theme derives from the cover, so the visual experience of kew is downstream of whether cover art is present in your files and whether your terminal can draw it. A library of untagged files with no embedded artwork will look considerably plainer than the screenshots in the README, which show the player rendering album art.

The rest of the interface is conventional for a terminal player: a music library explorer, playlist editing with add, reorder and delete, search, and lyrics support. There are also layouts/ and themes/ directories at the top level, which indicates that custom layouts and themes are data files rather than compiled-in constants. The README does not document their schema, so editing them means reading the shipped examples.

Gapless, crossfade and replay gain: what is stated and what is not

The README lists gapless playback without qualification, and crossfade as experimental, both automatic and on demand. Marking crossfade experimental is the more informative of the two claims. It tells you the author considers that path less settled than the rest of the player, and it is the feature most likely to behave differently across output backends.

Replay gain is listed without detail. The README does not say whether it is track or album mode, whether it reads gain tags or computes them, or how it interacts with crossfade. Auto-Resume is likewise listed as a feature with no explanation of where state is stored or what happens when a file moves. Import and export of .m3u playlists is stated, which gives you a portable escape hatch: your playlists are not trapped in a proprietary database, and you can move them to another player.

This is the shape of the documentation generally. The README is a feature list and a pointer to the website, not a manual. docs/MANUAL-INSTALL-INSTRUCTIONS.md covers installation and the real-time scheduling caveat, but behaviour of features like replay gain and auto-resume is not described in the documentation the repository points to. If those features are the reason you are considering kew, verify them yourself against your files before you commit.

kew against ncmpcpp and musikcube

The obvious comparison is ncmpcpp, which is a client for the Music Player Daemon. That architecture is the fundamental difference: with ncmpcpp you run MPD as a separate process, point it at your music directory, and the client connects to it. Playback, library indexing and state live in the daemon. kew is not a client of anything; it is the player, built as a single C binary with its dependencies resolved at compile time. There is no daemon to configure, which is why the README can claim kew "Requires virtually no setup", and no daemon to keep running, which is why it starts and stops with your shell session.

The cost of that design is that you cannot detach playback from the terminal or attach a second client to the same session. MPD's separation is what lets a phone app control playback happening on a home server. kew's single-binary model does not offer that, and the README does not claim it does.

musikcube takes a third position: a terminal UI over a client-server core with its own library database, which is heavier than kew and lighter than a full MPD deployment. Against both, kew's differentiators are the word-based playlist generation and the terminal-native rendering of covers and themes. Against both, its documentation is thinner, and that is the honest trade you are making.

Licence and the cost of keeping up

kew is licensed under GPLv2+, and the README links to the LICENSE file for details. The practical consequence for most users is nil: you can install and run it freely. The consequence for anyone embedding kew in another product is that the GPL's copyleft terms apply, and the repository also carries PRIVACY_POLICY.md and TERMS.md at the top level, which is worth noting for a player whose README makes privacy a selling point. This is not legal advice; read LICENSE, TERMS.md and PRIVACY_POLICY.md if you plan to redistribute or bundle it.

On maintenance, the last push to the repository was on 2026-09-23, and the most recent release listed is v4.3.6 from 2026-09-22, preceded by v4.3.5 on 2026-09-21 and v4.3.4 on 2026-09-12. The release cadence in that window is days, not months, and the repository is not archived.

That cadence has an upgrade cost, and it is the build flags. If you compiled with USE_DBUS=0 or ENABLE_CAP_SYS_NICE=1, those choices are yours to reapply on every rebuild, because they are make variables rather than configuration files. Distribution packages absorb that work; a source install does not. If you installed from a package manager, upgrades are whatever your package manager does. If you built from source, keep the exact make invocation you used, since the flags are not recorded anywhere the build can read back.

Editorial conclusion

Adopt kew if you keep local files, work inside a terminal, and want playlists generated from your own tags rather than from a recommendation engine. Skip it if your library lives in a streaming service, if you need ALAC, HE-AAC or E-AC-3, or if you expect the repository itself to explain installation, since the README defers to kewplayer.com and docs/MANUAL-INSTALL-INSTRUCTIONS.md. Before committing, verify that your terminal supports sixel if cover art matters to you, and check the packaging status badge against your distribution, because the build flags USE_DBUS, USE_FAAD and ENABLE_CAP_SYS_NICE change what you get.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. ravachol/kew on GitHub
4. README
5. Releases