Hacker News new | ask | show | jobs
Show HN: Simpler access to your music from the web that looks nice (github.com)
86 points by iron4o 1706 days ago
13 comments

My current solution is Navidrome[0], which is a similarly lightweight music server (also written in Go and FOSS [1]), with a similary nice Web UI that works well as a responsive webapp / PWA.

Probably the biggest difference however is that, instead of a custom API, it supports the somewhat-standard Subsonic API, which makes it usable via a large collection of native clients. It also has a few more features like multiple user accounts, etc.

TBH, the overlaps are big enough that I'm not seeing the space for Euterpe. I suppose the installation is a little bit simpler if you don't use Docker?

[0] https://www.navidrome.org/about/

[1] https://github.com/navidrome/navidrome/

never heard of navidrome! 10 minutes later I have it all setup and its amazing! thanks for the suggestion for anyone looking to do this on their home setup take a look here, save you a lot of time: https://github.com/navidrome/navidrome/issues/103
Wow! Even the website looks the same. With the vinyl in the background and everything ;D
I appreciate all these players and server thingeys and what not, but what is extremely needed right now is a robust tagger, library db type thing. As far as I know, there are two solutions beets https://github.com/beetbox/beets and picard https://github.com/metabrainz/picard. Beets is maintained, but relies on plugins which are not; but mainly it is slow as to be unusable for a decent size library. Picard is better, but limited in functionality (I want it to have a persistent db of my music too).

I just want a thin wrapper around an sqlite db that can do rudimentary tag detection and have functionality like "Import this folder into my library, moving the files and adding the songs to the table"

Beets’ strength is as a tagging solution more so than a way of accessing music. For the latter I use mpd.

From a tagging perspective beets works great. It’s hugely configurable out of the box and the fact it’s written in Python means it’s easy to extend or write plugins for your own purposes.

FWIW beets has worked really well for me. I would recommend it to anyone who is comfortable enough in the command line to navigate its interface
My problem is, all my music is:

a) WAV files with no internal metadata (there is a metadata file alongside though and a album-cover.jpg) (My ripping process pre-dates the ubiquity of FLAC playback support)

b) stored on a central file server currently only accessible via SMB/CIFS.

And what I want is some remote head-unit solution connected to [powered] speakers running a touch screen UI that presents the lot as a music jukebox.

There's a lot of Android and Linux based front-ends but most of them insist on only indexing locally stored music, and also only supporting file types with built-in metadata support, even though my music is stored in a logical Artist/Album/Track.wav folder/file naming convention.

So I'm stuck. It feels like I need to hand-crank my own solution... but that would take a lot of time I don't have, and never be as nice as some of these established open-source projects.

Sounds like you need to

a) transcode to flac, at least for the file size limits b) use beets.io or Musicbrainz to match your music and write metadata to them.

Updating your library will make it much easier to use with any sort of streaming frontend.

>a) WAV files with no internal metadata (there is a metadata file alongside though and a album-cover.jpg) (My ripping process pre-dates the ubiquity of FLAC playback support)

Converting your entire .WAV library to .FLAC should be extremely quick on any CPU made in the last 10 years. A good converter will also allow you to tag it while converting. I converted from .APE to .FLAC a few years ago and it took no time at all.

> there is a metadata file alongside though and a album-cover.jpg

Is the metadata file in a format that you made yourself or was it produced by a third-party piece of software? And is it text based or binary format?

> There's a lot of Android and Linux based front-ends but most of them insist on only indexing locally stored music, and also only supporting file types with built-in metadata support, even though my music is stored in a logical Artist/Album/Track.wav folder/file naming convention.

Ok, so if we start off with that part of it, and we ignore the additional metadata file for now.

> stored on a central file server currently only accessible via SMB/CIFS.

Can you SSH into the server? Or alternatively, manage the server with a locally connected keyboard and monitor? Or is this some kind of NAS box that does not allow you to do any of those kinds of things?

Because I have a couple of ideas but it will depend on the specifics of your setup.

Metadata is XML, but could be easily converted post ripping (as a scheduled batch process I guess)

It's currently a file share on a Windows Server box, but at some point will probably move to a dedicated NAS (due to rising energy costs)

> It's currently a file share on a Windows Server box

I see. I don’t know if the following will really be helpful since there may be some nuances that will differ a bit. But if that installation of Windows has WSL then hopefully the following might be helpful.

In summary, my idea is as follows: If you have enough space on the server for it, you could create a new top-level directory next to the one that you currently have for your music, and then create a script that loops over all of the files, transcoding them to flac with ffmpeg and adding metadata with a flac metadata edit tool. (ffmpeg can edit flac metadata too, but I think a dedicated flac metadata edit tool will be more straight forward to use).

So on KDE Neon Linux and other Ubuntu based distros, here’s what I’d do, and hoping this might be somehow useful even though you are using Windows:

First install ffmpeg, lltag and mediainfo if you don’t have them already:

    sudo apt install ffmpeg lltag mediainfo
Then let’s say that the directory hierarchy for your music was at /data/Music/ so you’d have "/data/Music/Steppenwolf/For Ladies Only/3. Shackles and Chains.wav" etc.

Then I’d create a new directory next to the Music directory and name that one "flacs" for example:

    mkdir /data/flacs
Transcoding and tagging. For now we include only artist name, album name and track names, extracted from the directory names and file names in your hierarchy, omitting other metadata such as for example the album cover art. But since we retain all of your original data, you can at a later point delete these flac files and do a transcoding and tagging run where you include more metadata (or do a run that keeps the transcoded files and only edits the metadata of them if you'd like). The idea for now is to do something simple as a first step, and then you can refine it in the future.

    origdir="/data/Music"
    flacdir="/data/flacs"
    find "${origdir}" -mindepth 1 -maxdepth 1 -type d | xargs -I{} basename '{}' | while IFS= read artist ; do
      mkdir -p "${flacdir}/${artist}"
      find "${origdir}/${artist}/" -mindepth 1 -maxdepth 1 -type d | xargs -I{} basename '{}' | while IFS= read album ; do
        mkdir -p "${flacdir}/${artist}/${album}"
        find "${origdir}/${artist}/${album}/" -mindepth 1 -maxdepth 1 -type f -name '*.wav' | xargs -I{} basename '{}' | while IFS= read trackwav ; do
          tracktitle="${trackwav%.*}"
          ffmpeg -i "${origdir}/${artist}/${album}/${trackwav}" "${flacdir}/${artist}/${album}/${tracktitle}.flac"
          lltag --clear -a "${artist}" -t "${tracktitle}" -A "${album}" --yes "${flacdir}/${artist}/${album}/${tracktitle}.flac"
        done
      done
    done
And now if we look at one of the transcoded files with mediainfo:

    mediainfo "/data/flacs/Steppenwolf/For Ladies Only/3. Shackles and Chains.flac"
Then we see among the lines of the output the following, showing us that we have successfully tagged the transcoded file with artist, album and track title:

    Album                                    : For Ladies Only
    Track name                               : 3. Shackles and Chains
    Performer                                : Steppenwolf
And likewise for all of the other files. All transcoded to flac and tagged with artist, album and track title.

And your original wav files and other data remains unchanged where they were, so that you can do more detailed tagging etc in the future.

Thanks for your detailed response! I'll certainly look into creating a mirror copy of my music library as this seems the best way to be compatible with commercial and open source front ends. I'll favourite your comment, and come back to it when I need to.

Also, how did you know that I like Steppenwolf?! :D

> Also, how did you know that I like Steppenwolf?! :D

I figured that anyone that appreciates music so much that they maintain a collection of music files on their machine would probably appreciate Steppenwolf :)

Is there a sort of universal format for music metadata? I know image metadata has XMP.
id3 is the standard for music metadata

https://id3.org/

Looks like it's a standard for embedding within MP3 files. But ss there ecosystem support for reading it from a "sidecar" file? I know digikam can read XMP data from a file that lives alongside image files that don't support such embedding.
I'm reasonably sure that Jellyfin could handle this setup. For music, it normally uses in-file metadata, but lacking that, I think you can give it enough info through paths and filenames for it to look up the metadata online (this is what it does for movies and TV shows). It definitely uses a text-based metadata format (.nfo) internally to cache this metadata, and it probably would be easy to programatically convert your metadata file to this format.
Sounds like something a shell script could fix.
I'm just gonna wait for "Show HN: Simplest access to your music from the web".
“That looks nicest”
Definitely looks nicer than mine! ^_^ (but not simpler)
I couldn't resist the play ;D
It looks nice, and I’ve used similar solutions in the past. The problems are; when you update your server’s local library to a new version of iTunes or the operating system gets updated, the web app breaks. Webserver goes down, breaks. Sneeze, breaks. 2 years from now, project unsupported, breaks.

Music is one of those things that you just want to work 100%, all the time. For this reason I don’t have any Wi-Fi speakers. Everything is hardwired, except the remote.

For the last 10 years I’ve been using apple remote on top of iTunes. This allows me to create persistent connections between my iPhone iPad to my Remote iTunes sever which is an old MBA in a closet. It has a battery backup for power outages, I can play any music in the 16,000 song library, buy and download new music from my iPhone and instantly be able to play it on the server and the interface looks nice. This system has been more robust than some of my client’s AV systems designed by a pro audio team with whole-home solution costing $$$$$. Let’s just hope Apple continues to support Remote.

My problem is all my music isnt actually my music at all :(
This is something that I would like to consider this one if the UI looks more of a modern minimalist touch.
You could combine this with PageKite or a similar service to make your library web accessible.

Really cool in any case!

Cool idea and execution. The problem is cloud services like google drive can do this.
Really looks very nice. Thanks. What about copyrightes?
Great stuff!