<p>Hello everyone. I'm currently developing an idea for a multi-platform music player since I have <strong>at least</strong> one issue with the (several) options I've used over the years. Take as example the following applications: </p>
<ul>
<li><p><a href="http://www.foobar2000.org/">Foobar 2K</a>/<a href="https://www.getmusicbee.com/">MusicBee</a>: Both are extremely customizable (the former more than the latter), tons of functionality, the footprint of both is ridiculously low, performant as hell (even with big libraries) but the UI/UX is not modern (unless you invest a lot of time on it, and even if you spend a lot of time of it, that should be an out-of-the-box experience), Windows-only.</p></li>
<li><p><a href="https://www.apple.com/lae/itunes/">iTunes</a>: The most bloated, useless piece of software Apple has ever shipped. Memory hog, non-performant, barely customizable, not available on Linux.</p></li>
<li><p><a href="http://www.digimezzo.com/software/dopamine/">Dopamine</a>: Modern and beautiful UI, but limited functionality, RAM usage is above 150MB --compared to Foobar 2K/MusicBee, it's quite high, some issues with big libraries, Windows-only.</p></li>
<li><p><a href="https://www.clementine-player.org/">Clementine</a>: Finally a multi-platform player, but ugly, UI/UX feels clunky and not intuitive enough, limited functionality.</p></li>
<li><p><a href="http://gnumdk.github.io/lollypop-web/">Lollypop</a>: Beautiful, modern UI/UX, handles big libraries (over 100GB; 10000+ files) really well, but limited functionality, RAM usage is similar to Dopamine (see above), no gapless playback (try to listen to your Pink Floyd records without it), Linux-only.</p></li>
<li><p><a href="https://wiki.gnome.org/Apps/Rhythmbox">Rhythmbox</a>: Looks like a Excel spreadsheet, limited functionality, Linux-only (?)</p></li>
<li><p><a href="http://www.winamp.com/">WinAmp</a>: Dead, not available on Linux.</p></li>
</ul>
<p>This is not, by any means, a rant of the sorts. I appreciate one and every developer who has worked on these music players, and while some of them have been great (MusicBee is my current option on Windows and I'm in love with Dopamine's UI), I still haven't found the silver bullet for this issue. And, instead of ranting and complaining, I decided to invest my time into something I really want. Which brings us to the following thread.</p>
<p>I've been considering Golang (as well as Scala and Rust) as the language to develop this idea, although few questions surround my head w/r/t this:</p>
<ul>
<li><p>I'm aware there are <a href="https://github.com/therecipe/qt">Qt bindings</a> for Golang available and it seems that project is mature enough for this idea. I also feel inclined to use Qt to build the GUI for this project as <a href="https://github.com/telegramdesktop/tdesktop">Telegram Desktop</a> uses it and the UI/UX between Windows/Linux (the 2 OS I work with) is the same for both and looks modern and gorgeous. Anyone here has worked with it? How was your experience? Any thoughts about it you consider worth mentioning?</p></li>
<li><p>Are there any GStreamer ports on Golang? Google shows up a few results, but none of them seem mature enough. They're either abandoned or on an early development stage.</p></li>
<li><p>Any library available on Golang to read/write audio tags? Like artist, album/song title, track number, album cover, ReplayGain tags, etc.</p></li>
<li><p>Should I be worried about performance with Golang handling this? AFAIK, memory footprint is really low with it and CPU loads should be minimal but since I really don't have experience with Golang I would like an insight on this.</p></li>
</ul>
<p>That should be all by now. I'll be x-posting this on <a href="/r/rust">/r/rust</a> and <a href="/r/scala">/r/scala</a> with questions similar to those here, but regarding the issues I've found with those languages for this development.</p>
<p>Thanks in advance for all the help you guys can throw this way :)</p>
<p>P.S.: I don't know what libraries beside the ones aforementioned above are needed for a project like this, so if you could shed some light on this, it would be greatly appreciated. :)</p>
<hr/>**评论：**<br/><br/>exch: <pre><p>I've worked on something similar for an embedded audio system. I went with a custom build of <a href="https://wiki.videolan.org/LibVLC">libvlc</a> bindings for Go, to take care of all my encoder/decoder needs. The custom build part entailed removing all the video encoding/decoding, as well as the UI code, as I had no use for it.
Alternatively, you could go for <a href="https://ffmpeg.org">ffmpeg</a>, but it is considerably lower level than libvlc and leaves a lot of work in your hands. Either one will give you support for all the formats you could possibly wish for though. So I highly recommend using this route, as opposed to manually collating all sorts of third party libraries for different media formats.</p>
<p>My setup involved an API server on the embedded device. it maintained the media library (optionally spread out over a network) and provides the API for various modules like: user/playlist management, playback control, configuring audio hardware, recording/upload/download of custom audio data, and some other bits and bobs i forgot.</p>
<p>As for the UI, since our primary application is a headless server, we can implement clients in any platform or framework we wish to support. And even let third party contributors provide client implementations. All they need do, is talk REST to the API server.</p>
<p>This is all way over-engineered if you want a simple audio player on your desktop system, but I still think the server approach is useful. <a href="https://www.musicpd.org">MPD</a> has always been a favourite of mine in this respect. Though I would have chosen a different API implementation.</p></pre>aitbw: <pre><p>Thanks for the reply! So, with either libvlc or ffmpeg, you got encoding/decoding needs covered. I assume playback is also covered here, acc. to the first link you posted, right?</p>
<p>A friend also suggested the <strong>headless server</strong> approach, which makes it something à-la-Electron. This seems like the best bet in regards to a modern, good-looking, consistent UI/UX all over Windows/Linux/macOS, but what about performance? I remember there was a Electron-based music player, and while it looked gorgeous, the performance was terrible, especially with big libraries.</p>
<p>Of course, the <strong>headless</strong> approach would be different w/r/t this since the server would be written in Golang and it would handle all the heavy stuff, but I'd like to know the performance trade-offs of it.</p>
<p>Also, which API implementation would you have chosen and why?</p>
<p>Thanks again for your time!</p></pre>exch: <pre><p>Playback is covered by libvlc, including forward and backward seeking (where the media supports it). With ffmpeg, you will have to implement all this yourself.</p>
<p>With a headless server, the client can be implemented in anything from a web-app (à-la-Electron). But also any other native UI framework in a programming language of your choosing. As long as it supports API calls to your server, you are good to go. As far as performance goes, this is largely dependent on the platform your client runs on and the UI framework/language you end up using. A web app will be slower than a native client, but it should still be more than good enough for a music player. Even with large playlist datasets.</p>
<p>The project I worked on had no problems with performance and the primary client was written for an older generation android phone, which connected to the server over WIFI. Write a barebones client for a few different frameworks/platforms and do some profiling to see what works best.</p>
<p>As for the API implementation, I am partial to a compact binary format, if you have that option. But otherwise something JSON encoded will do just fine. MPD, at the time, had a non-standard text based protocol which was a bit of a pain to parse and not particularly consistent. This is why I would have preferred they used something different.</p></pre>aitbw: <pre><p>Seems like libvlc is the way to go, will look into it later.</p>
<p>Oh, I wasn't aware you could implement a native UI framework with a headless server. I always linked this with Electron-like concepts, where you would inject the necessary HTML/CSS/JS on the client-side. So, on Windows, I could develop a client, let's say, with WPF, as long as it supports API calls to my server implementation?</p>
<p>I also wasn't aware of the <strong>compact binary</strong> format, will look into it later as well.</p>
<p>Thanks for the much-appreciated advice, mate.</p></pre>Sythe2o0: <pre><p>You'll probably need encoders/decoders/players for all the audio types you want to support, and those projects are going to be very scattered/outdated. Off the top of my head you should be able to find flac, mp3, wav, and ogg but each one is probably going to be at least one library to incorporate. (I assume you'll be able to google for these but if you want me to link some projects I can dig for what I've gone through) (disclaimer: I am in the middle of developing a project to unify these libraries, the project is not functional enough / stable enough for use right now)</p>
<p>As long as you aren't doing intense particle or 3d graphics effects your UI will perform fine, you shouldn't worry about CPU or memory usage.</p>
<p>Those are all the questions I can answer!</p></pre>shazow: <pre><p>You might be interested in <a href="https://mogg.io/">moggio</a>.</p>
<p>It's written in Go, it's a full-fledged music player but also the components are highly reusable for your own music player too (I've used pieces of it for other projects).</p></pre>aitbw: <pre><p>I didn't know about <em>moggio</em>, looks pretty great, thanks for linking it!</p>
<p>How has been your experience with it? Any thoughts worth sharing?</p></pre>Chillance: <pre><p>How about Audacious - <a href="http://audacious-media-player.org" rel="nofollow">http://audacious-media-player.org</a> ?</p>
<p>Something like that in Go would be cool. :)</p></pre>aitbw: <pre><p>Forgot about it, but I haven't used it. I'll try it to see how it goes.</p>
<p>Thanks! :D</p></pre>robvdl: <pre><p>I looked at doing something similar at one point, though I didn't get that far with it unfortunately. I did look at libraries that handle tags in audio files and I did run into a snag that most (all) of the libraries were a binding to a C library (taglib I think it was) that did not support the "album artist" tag which was absolutely crucial to me. I was going to send a patch to this C library to add this support for the album artist tag but got half way through it then sort of gave up on it.</p>
<p>I came up with the conclusion I wanted to build a pure Go tag reading/writing library as it was a bit of a pain to link to this C library, but I haven't really got time for that so that is where my project ended.</p>
<p>I also quite like the idea of headless music players like mpd, but I tried this many years ago and it also lacked support for album artist at the time which made it useless to me. I am not sure if mpd supports this now.</p></pre>robvdl: <pre><p>Just as a bit of an explanation why I didn't finish the patch to taglib is because it required you to add support for the album artist tag for all the different formats that taglib supports at the same time, mp3, flac, ogg + other more obscure formats. I got it working with some of the formats but never finished it.</p></pre>
