Show HN: Musikcube, a terminal-based music player, library, and streaming server | Hacker News Reader

Show HN: Musikcube, a terminal-based music player, library, and streaming server

musikcube.com

340 points_avatar82 comments

Unfortunate naming - I used this other graphical MS Windows music player back in high school: https://en.wikipedia.org/wiki/MusikCube

EDIT: oh, same developer, so all links are "legitimately" taken over for the new version, and the old version homepage is https://musikcube.com/old/

The Wikipedia page is in serious need of updating. For instance, it's cross-platform with multiple front ends now. clangen seems to be a reliable head developer as well too, so dev status is active.

The thing that really chaps my hide about the proliferation of these terminal based apps is that now I have all these terminal instances open.

For each cool app like this or terminal based chat apps or terminal slack that's another 2.4mb just for overhead! I'm looking at my process monitor right now and I have 250, 250mb, allocated to terminal apps. It's insane!

For people who aren't being sarcastic: tmux is great. It even allows you to ssh into your machine, do `tmux attach` at the command prompt, and get all your terminal programs right there, from anywhere in the world.

And when you're done with the ssh session, detach and log out, and everything stays running.

Some terminals (like urxvt) also support running as a daemon and spawning a new window just attaches to that terminal daemon. Faster and it saves you a megabyte or two over actually opening a whole new terminal.

Wouldn't a GUI app have much, much more overhead though? Right now, the _Dock_ on my laptop is taking ~250MB on its own. A simple app that allows me to control when my monitors sleep is another 100MB. Both of those are way more that a simple terminal instance of 2.4MB.

I guess OP's post is just an irony about all the recent Electron apps bloat.

Yes. The OP is being sarcastic.

tmux or screen?

Or maybe even just tabs?

Would love to see a Spotify integration.

Yes, I know. Thats probably not the devs bad, but Spotify makeing it impossible to write a legal integration. Happy new DRM world.

I'd like to add support for various streaming services in the future. There is already a preliminary API that allows plugins to add music to the data store, which can be paired with other plugins that control downloading and decoding of audio data. It should be technically possible with the current system, but I haven't had the time to implement any services yet.

https://github.com/mopidy/mopidy-spotify

You can live in the future...TODAY!

I might be out of date, but it was possible to integrate for premium accounts. Free users couldn't use that, of course, because then they wouldn't get the ads.

So it can only play a handful of the most popular formats and it requires a metric ton of dependencies. Why are you not using ffmpeg? It can handle decoding, encoding, streaming, tagging, filtering and output without any external libraries.

This is a great question. Unfortunately I don't have a good answer, at least from a technical standpoint. ffmpeg is super stable, battle tested, and does just about everything.

I think there were a couple reasons we (myself and the original developers) didn't go with ffmpeg initially: (1) we really wanted to learn how to build a medium-sized C++ app from scratch. Passing everything through to ffmpeg sounded boring. (2) it was difficult to build ffmpeg on Windows in 2007, when we started work on the audio engine. (3) ffmpeg is LGPL/GPL licensed. We originally planned on statically linking everything into a single executable, and were worried the LGPL license would require us to change our license to LGPL. We really wanted BSD.

I don't think any of these are concerns anymore. To be honest, I've sat down a couple times to write an ffmpeg decoder plugin, but always get distracted by missing features and end up working on those instead.

All of that said, I think we should consider looking into ffmpeg again sometime soon, for exactly the reasons you've listed.

This is semi-unrelated, but would a more robust/portable playlist format be of interest to your project? I wrote a spec for one and am trying to work with projects to implement it in one:

http://universalplaylist.stavros.io/

I tried to write a beets implementation, I got rather far but it was cumbersome because beets is more of a library manager than a playlist manager. That meant it lacked playlist functionality, which meant I'd have to write my own playlist manager, which was quite a bit more work than just the import/export plugin :/

How does this compare to mpd, the Music Player Daemon?

https://www.musicpd.org/

Really nice looking app.

I installed it and the UI is absolutely amazing. Would love to make this my main music player.

I am having some issues though, the audio quality of the playback is suspect. I'm playing back an mp3 file and comparing it to cmus and iTunes play it fine, however musikcube has some weird audio artefacts (especially during heavy bass sections). I'm guessing(hoping?) it's some weird config, but this makes it unusable for me. I'm not an audiophile and I'm not being overly sensitive, there's some weird distortion that does not happen in cmus or iTunes.

MacBook Pro 13" 2015.

I remember there were some glitches prevalent in early downloaded MP3 files, which fancy decoders were able to smooth out somehow. Been a few years though.

I've been a pretty big fan of CMUS and CLI based based audio playback for a long time..

This is absolutely amazing— much more polished than the alternatives—it feels like christmas.

Now I can't wait to contribute a pull request :) Thank you so much!

Very interested in this as I've tried every terminal music player under the sun. As others have mentioned, how does this differentiate itself from the main players .... mpd and cmus??

mpd and cmus are both awesome. I found mpd cumbersome to setup, and couldn't find a frontend I liked. cmus was closer to hitting the sweet spot, but I didn't find a remote control (or streaming) solution that worked the way I wanted it to. I also wanted something super lightweight that I could use in Windows without needing to install something like WSL or Cygwin.

In a nutshell: musikcube probably has fewer features than these alternatives, but packages everything together with a clean, straight forward user interface.

Do you know if musikcube has any intention of supporting the mpd protocol? I don't think it should be terribly hard to support, the protocol itself is fairly simple and stable. It would allow musikcube to integrate into tons of applications that already support mpd integration - I've even written a few of my own for my needs, the various libraries make it very easy to do. That integration is the main reason why I'm hesitant to move away from mpd even though musikcube looks appealing.

Looking at the video, I want to immediately (i.e., without switching to a mode) type "can" and have "Cannonball Adderley" highlighted at the bottom of the focused "artists" tab.

Does it work that way?

Not yet, unfortunately. This is on my list of things to do.

You can however, in most contexts, switch to the "category filter" view by pressing "f" without explicitly engaging command mode. This will switch the view, then focus the search field. So you can type "fcan" and get artist, album, and genre search results for "can". Not ideal, but does work and is still pretty quick.

I'd love this feature too. Should we open an issue for it?

Would be great if it could somehow drag & drop, or have a hack to load the currently selected track in another app such as Traktor. I know this is a weird feature to ask, but I'm looking for something keyboard based to efficiently organize & tag my collection for DJing. Simply bring down a terminal window and select the next song.

For tagging and organizing you should definitely check out "beets": http://beets.io

I use Resonic for that, really fast, not terminal based, but pretty good with waveform support. You can move tracks by drag&drop to folders.

This looks great. Clearly a labor of love. Congratulations.

This looks fantastic, thanks for working on it! Especially the ability to act as a streaming server / client.

I have to ask though, when streaming protocols are fragmented already, why create a new one, and not use one of the existing / well supported ones, such as Subsonic?

I think this is really nice :)

Nice UI and UX, lightweight and straightforward, will try it out for a bit!

Off topic a bit, but what were you using to show the keypresses?

I tried to find some external tooling to help with this, but was unsuccessful. In the end, I just built a (hidden) feature into the app that intercepts and displays the key presses in that little bar on the bottom before dispatching the events to the actual handlers.

# How to compile from sources via Ubuntu 16.04 64-bit (missing from README.md)

## Install build dependencies

sudo apt-get install build-essential cmake libboost-all-dev ncurses-dev libncursesw5-dev libcurl4-openssl-dev libfaad-dev libmad0-dev libav-tools libvorbis-dev libflac-dev libmicrohttpd-dev libmp3lame-dev libasound2-dev libpulse-dev;

## Building

mkdir ~/Applications

cd ~/Applications

git clone https://github.com/clangen/musikcube.git

cd musikcube

cmake .

make

# Running

./bin/musikcube

(edits: clarity)

Efficient music players remain elusive | https://news.ycombinator.com/item?id=14634658 (~250 comments & points last month)

Not sure what the general consensus is regarding connecting recent discussions but several lightweight players were recommended; most were platform-specific.

Clickables:

- Permissively licensed: https://github.com/clangen/musikcube/blob/master/LICENSE.txt

- CMake: https://github.com/clangen/musikcube/blob/master/CMakeLists....

- Lean n' mean plug-in system to support audio codecs and sound systems? Check, https://github.com/clangen/musikcube/tree/master/src/plugins

- CURSES (TUI) C++ abstraction layer: https://github.com/clangen/musikcube/tree/master/src/musikcu.... Based off https://github.com/clangen/cursespp.

- Indexes (a la mpd?): https://github.com/clangen/musikcube/tree/master/src/core/li...

- Cross-platform audio abstraction interfaces? https://github.com/clangen/musikcube/tree/master/src/core/au...

This could stand a chance of uprooting the mpd + ncmpcpp combo that's been pretty standard for many terminal lovers.

That's not even to mention this app also has an android client (https://raw.githubusercontent.com/clangen/clangen-projects-s...), and something looks like it's being cooked up for windows, too: https://github.com/clangen/musikcube/tree/master/src/musikwi...

Amazing skills. Just 2 main contributors: https://github.com/clangen/musikcube/graphs/contributors. If the git history is pristine (information could have been lost/altered during a cross VCS import), the project was also around since at least 2008: https://github.com/clangen/musikcube/tree/b272bf6

Added a folder location, then it crashed. Now it crashes on launch:

http://imgur.com/a/Sb2hQ

http://imgur.com/a/fKUXO

So add an issue on Github, this isn't the right place.

This is a Show HN...

And before you ask, I'm actually not only preparing the issue details, I'm looking to fix it myself.

Really easy fix.

https://github.com/clangen/musikcube/issues/120

That section of code should be refactored though.

If I have a musikcube server running on my network, can I stream music from my web browser to it?

Not currently; the only client right now is a native Android app[1]. However, the server[2] uses vanilla HTTP (for audio) and WebSockets (for data and eventing), so it should be relatively straight forward to build a web frontend.

[1] https://github.com/clangen/musikcube/tree/master/src/musikdr...

[2] https://github.com/clangen/musikcube/wiki/remote-api-documen...

Even with a web frontend, I'm not clear on how I could get the audio from, say, youtube to go over the websocket instead of to the typical playback device. With something like Pulseaudio, I believe it's possible to stream to a remote host, but then musikcube would need a pulseaudio compatibility layer

You would have to download the youtube audio first (eg. using youtube-dl -x) then add that to your Musikcube library.

Then a web frontend could be served served audio over HTTP and play that back on the remote client.

Pulseaudio is system based audio, whereas here we are just talking about local audio to the musickube app.

Interesting idea to add pulseaudio compatability though..

Too bad it doesn't do youtube.

Anyone knows of a cli app that can play local files as well as youtube?

Probably not what you are looking for, but I hacked this together a while ago just for fun: http://tunetab.us :)

I don't know about local files, but mpsyt is great for listening to music on YouTube.

Yeah, I use it already, it's great. Alas I need to run something else for the local library.

I would have hoped there's a program that can do both.

Mopidy with a cli mpd client.

mpv

Please could someone explain why it's necessary to use 24bit/192k - I thought due to Nyquist/Shannon theory that 192k was overkill. In fact, doesn't it create more ear strain listening to higher frequency sample rates?

DSP works better at a higher sample rates, for obvious reasons, so in a music studio higher is better. Music software will often apply 4x or more oversampling when run at 44.1k which is degrading in the time domain even if the result is better than no oversampling, so recording at high rates avoids that.

Using it as a consumer is pointless, you cant hear those frequencies at all. Adults typically cant even hear up to nyqust at 44.1k. If youre a big music fan youve probably ruined your ears so good luck hearing anything above like 15k tbh.

16 bit was a compromise to do with wanting to keep CDs from being the size of dinner plates, 24 bit is legitimately better, but you're not going to notice with typical music.

For playback, 16 bits / 44.1KHz is fine. No humans have ears that can reliably distinguish more than that.

For editing and production, more bits per sample and more samples per second make it possible to mix sources without reducing quality of the final output.

There is no advantage to that final output being 24/192, or 20/88.

There is no ear strain that comes from higher sample rates, though.

I was just about to reply that using only 44.1kHz means at higher frequencies, you're getting hardly any samples per cycle, and representing a high-frequency sine wave with something more like a square wave - ie not an accurate representation, and really harsh.

However! Xiph.org has a video demonstration using oscilloscopes, showing that high-frequencies at 20kHz still are perfectly represented even with just 44.1kHz recording. It's here if anyone is interested, switch the Chapter Selection on the video to the Stairsteps chapter:

https://xiph.org/video/vid2.shtml

Play lower and higher quality encodings through a decent size of sound system (2kW upwards) to discover what all those frequencies do

You might find this interesting: https://people.xiph.org/~xiphmont/demo/neil-young.html

Thanks ! I'll read through that this evening

I think you need to lookup Nyquist/Shannon as already alluded to in this post. Plus it's about the quality of the playback, not how loud it is. Having said that, after spending a weekend in a field in Cambridge, in front of a speaker, my hearing is now pretty shot :)

This is really good, looking forward to supplement my Subsonic and Plex install with this. I will contribute if I can :)

SSL support through a different app. Okay! Will have to finally begin using Nginx then. Good opportunity to learn something new.

This is amazing!

Is there a way to navigate the collections by folders on disk, not by artist/album/genre? I keep my music nicely sorted on disk and I really got used to it.

MOC does that by default.

I'm about to install this on my third machine ... needlesstosay, I really like this project! Thanks so much for putting your efforts into it.

Would love an ubuntu deb for this. That said it builds from source easily enough. But the libs are a bit new for my old version of ubuntu.

I love the asciinema demo! Really data efficient. Wasn't expecting to be able to watch a demo video on the subway :)

I'm using Fedora 26 and

it shows that packages "asound", "pulse" and "libmp3lame" are not available.

What do I do?

These are all common libraries that most distributions should have.

1. "asound" refers to ALSA. 2. "pulse" is PulseAudio 3. "libmp3lame" is LAME

A quick google search looks like these may be the packages you need:

1. alsa-lib-devel 2. pulseaudio and pulseaudio-libs-devel 3. liblame-devel, maybe?

Looks like I'll need to spend some time here soon installing a few more popular distros and figuring out the exact package names.

Would love to see Centos7 included in your distro list.

On Arch same response, tried yaourt with little success.

Nice! Any chance this supports gapless playback for those of us who listen to classical once in a while?

Gapless playback should more or less work out of the box for most file formats (flac, ogg, etc). For MP3 files it's still a bit hit-or-miss, and depends on what settings were used when encoding the files. This should improve over time.

Unfortunately crashes on windows when trying to understand my library. Looks great though.

I'm curious, how does this differ from what mpd tries to achieve?

wow this looks amazing! I finally decided that i must get off iTunes and have been hoping for a terminal based software. I cant wait to try it out.

I also reached my limit on iTunes after it started giving me an error message when I tried to play a song with wifi off.

I've been using Swinsian, and am really, really happy with it. I also want to try this out, but for something similar to iTunes without all the terrible, Swinsian is A+++++.

Has anyone (started to) create(d) a FreeBSD port yet?

Does it have shuffle? It looks amazing.

will it play Apple Music / iTunes Store DRM'd tracks?

I'm definitely going to try this, but I've become fed up with most music players and decided to code my own wrapper around MPV.

I used mpd and cmus for years but the main problem I had with them is that when I changed the directory structure of my music files it would corrupt my playlists. There are a lot of different work arounds but eventually I decided that to build a playlist I wanted to copy the file into a playlist directory instead of just reference the file location in a text file.

Right now I use Ranger (a CLI file manager) as the "front end" to mpv. I run mpv on a unix socket so it can be controlled remotely and I can request things like artist, title, etc.. and use that info in desktop notifications and widgets (if I want). Most of the time I never even look at my music player so this works out really well, and I already have mpv installed for video so I'm finding another way to utilize a program I already have installed instead of using another one.

I wrote a Rust command-line wrapper around libmpv also: https://github.com/sevagh/surge

Uses `youtube-dl` backend.

I want to say that I'm really excited for this, because of a very simple reason: I can comfortably browse by album, not just by artist, or at least that's what I'm reading on the project wiki. Most MPD clients do a bad job of letting me do that, and things like MOC don't appear to let me do it at all. As someone with most of her albums being authored by different artists, it looks useful.

I look forward to using it, and thanks for making it free/open source.

Reply on news.ycombinator.com