musikcube: a terminal music player and streaming server in C++

What musikcube does that a graphical player does not

musikcube is a music player that runs in a terminal. The README describes it as a cross-platform, terminal-based audio engine, library, player and server written in C++. That combination is the point: the same binary that plays audio locally also indexes a library, and can serve that library to remote clients.

The intended user is someone with a local music collection who works in a console and does not want to switch to a windowed application to change tracks. The README also notes that it runs well on a Raspberry Pi with Raspbian, and can be set up as a streaming audio server. That second role is where the project differs from most terminal players: a Raspberry Pi connected to a home stereo becomes the source, and the Android client called musikdroid can stream from it and remote control it.

There is also an SDK. The README describes it as a set of small, pure-virtual C++ classes plus enums and constants, and says it is still being slimmed down. So the project is not only an application; it is a platform other frontends can be written against, with API documentation linked from the README.

The audio engine, the indexer and the two servers

The architecture visible in the README and repository is layered. At the bottom is an audio engine with platform-specific outputs: ALSA and PulseAudio on Linux, Core Audio on macOS, and WASAPI and DirectSound on Windows. Decoding is handled by ffmpeg, with libopenmpt for tracker formats and libgme for game music emulation. Metadata comes from taglib.

The library index is stored in SQLite. That is what makes the terminal interface usable with a large collection: the player queries an index rather than walking directories on every launch. The README lists kissfft among the core dependencies, which is a signal-processing library, and the related searches include a query about a visualizer, so the engine is doing more than passing bytes to the output device.

The server side is two processes in one. A websocket server runs on port 7905 and is used for metadata retrieval. An HTTP server runs on port 7906 and serves optionally transcoded audio data to clients. The websocket layer uses websocketpp and the HTTP layer uses libmicrohttpd, with libcurl for outbound networking. The README states the streaming server is enabled by default.

The important design decision here is that remote control and audio delivery are separate services on separate ports. A client can browse metadata over the websocket connection without pulling audio, and only open the HTTP stream when it actually plays something.

Installing musikcube and playing a first track

The README points to the releases page for binaries and to the installation guide on the wiki. On macOS, Homebrew is the documented route. Run:

brew install musikcube

After installation, the README says macOS users can also use the provided binaries directly. On Windows, the documented route is Chocolatey:

choco install musikcube

The README states that after installation you run it from a shell, from the Win+R dialog, or by typing musikcube or mcube in the Start Menu. On FreeBSD the package is installed with pkg install musikcube, and on OpenBSD with pkg_add install musikcube.

For a first real use, launch the binary in a terminal. The README does not walk through adding a library directory in the main text; it directs readers to the user guide, which describes the navigation paradigm and lists all the default keyboard shortcuts. That guide is where to look for the key that opens the library settings and the key that starts playback, because the README itself only links to it. What you should expect after adding a directory is that the tracks are indexed into SQLite and become browsable from the terminal interface.

If you want the server side, the README says it is enabled by default, so the websocket listener on port 7905 and the HTTP listener on port 7906 come up with the application. Clients then connect to those ports on the host running musikcube.

The streaming server is explicitly not internet-safe

This is the limitation the project states most plainly. The README warns that out of the box the server and remote API should not be considered safe for use outside a local network. The websockets service only supports a simple password challenge. The audio HTTP server just handles Basic authorization. Neither provides SSL or TLS. The password is also stored in plain text in a settings file on the local machine.

That is a deliberate scope decision rather than an oversight, and the README offers a mitigation: a reverse proxy can provide SSL termination, with details in the wiki's ssl-server-setup section. Even so, the README says you should exercise caution exposing these services over the internet.

The practical consequence is that musikcube's server role belongs on a trusted LAN. If your use case is streaming your library to a phone while you are away from home, you are building that on top of a service the authors describe as local-network-only, and the reverse proxy is not optional in that scenario.

A second limitation is the interface itself. Everything is keyboard-driven, and the README defers the entire navigation model to the user guide. If you are not comfortable learning a set of shortcuts before you can play a song, this is the wrong tool. The README does not document a way to configure the player through a graphical settings dialog.

musikcube compared with cmus, ncmpcpp and termusic

The related searches show people comparing musikcube with cmus, ncmpcpp and termusic, so the honest comparison is about scope. cmus and ncmpcpp are terminal players. ncmpcpp is a client for the Music Player Daemon, which means it depends on MPD running separately and speaks the MPD protocol. cmus is a standalone player with its own library.

musikcube overlaps with both on the local playback side but adds a streaming server and a remote API in the same binary. That is the real difference in approach: with cmus or ncmpcpp you get a player, and if you want to stream to another device you add a separate server component. With musikcube the server is part of the application and is on by default.

The cost of that integration is the security posture described above. A separate streaming stack can be chosen and hardened independently. musikcube's server is convenient, but its authentication is deliberately minimal and its transport is unencrypted.

The Android client, musikdroid, is also part of this picture. The README says it can be downloaded from the releases section, and that it streams audio from and remote controls musikcube. That gives the project a first-party mobile client, which is not something a bare terminal player offers.

Building, licensing and what upgrades cost you

musikcube is licensed under BSD-3-Clause, per the repository. That is a permissive licence, and the repository also carries a LICENSE.txt at the top level. This is not legal advice; if you plan to redistribute a modified build, read the licence text and the licences of the bundled dependencies, because the README's dependency table mixes permissive libraries such as SQLite, taglib and nlohmann json with platform APIs from Apple and Microsoft that carry their own terms.

The release history is uneven. Version 3.0.3 and 3.0.4 shipped in July 2024, roughly two weeks apart, and 3.0.5 followed in September 2025. The last push to the default branch was on 2026-03-23. That is a project that moves in bursts rather than continuously, which matters if you are packaging it for a distribution and need to track upstream changes.

Building from source is documented on the wiki rather than in the README. The repository layout shows a CMakeLists.txt, a Visual Studio solution file, a .cmake directory and a musikcube.spec, so there are at least three build paths to maintain: CMake for the general case, the solution file for Windows, and the RPM spec for packaging. The README notes the SDK classes are still being slimmed down, which is a warning for anyone writing a plugin against them: the interface is not frozen.

Editorial conclusion

Adopt musikcube if you keep a local collection and want a console player that can also serve that collection to a phone or another machine, and if you are comfortable with the fact that its server is designed for a local network. Do not adopt it if you need a player with a graphical interface, or if you intend to expose the streaming server directly to the internet, because the README states the websocket service only supports a simple password challenge and the audio HTTP server only handles Basic authorization, with no SSL or TLS. Before you commit, verify that your platform has a package or binary available, and read the user guide for the keyboard navigation, since the README does not describe the interface.

Frequently asked questions

Official sources

1. clangen/musikcube on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases