Hacker News Reader

Comment by stego-tech | Hacker News Reader

MusicBrainz and its software companion, Picard, are absolute blessings when it comes to micromanaging a music library in this day and age. It can't find _everything_ I have due to entire artists appearing and disappearing between the closure of Napster and the creation of YouTube, but it gets me to that 95% CI that puts me at ease and lets me enjoy my collection. The fact it's global instead of regional (like a lot of automated DB lookups that cannot find my JP/ZA/DE/FR/etc albums here in AMER) is also a big notch in its belt.

Which reminds me, it's about time for the yearly re-scan and re-tag.

View on HN

I quite like the command line centric application http://beets.io/ as well too.

Are Beets and Picard complementary ? Or can they step on each other's work ? I am forever paranoid about overly "helpful" apps messing up my garden.

I would only use one or the other. I’ve only used Beets but it keeps a database and everything for tagging.

My fondest memory of Picard is the time it cheekily rewrote all my Russian music (Rachmaninoff and all that) into actual Russian with their alphabet, and how I never could find any of it after that.

That's partially why I started learning Japanese...Spotify used to use English translations of JP song titles, or romanizations at the least, but one day a few years ago I opened one of my playlists and found them all in kana and kanji.

I have this problem. Ever ID3 tag or whatever FLAC tag should be localized so you can select what localization you want. It's the only solution.

Or we could expand the spec to contain alternate fields for a given tag. That way the default tag is in the origin language of the content, but alternate tags could surface localizations into search or display.

The only downside is dusting off the ID3 spec, amending it, and then somehow coercing everyone who thought music tagging was “done” to update their software to support it.

The software part of the solution is easy-peasy. The political part, infinitely harder.

This feature is already available in settings.

Always create a backup or snapshot before any major media reorganization :)

And people keep looking weird at me when I tell them I strongly prefer ZFS on the desktop... I really wish it was more mainstream.

To be fair, we (myself included) look at you weird because the ZFS folks haven’t done a great job at extolling its virtues in a way that the average consumer can comprehend. It’s important to acknowledge that the vast majority of consumers simply don’t care about the underlying file system or its capabilities, even if they would benefit immensely from the features of something like ZFS.

It’s a problem of communications as much as it is vendor support. If you get the consumers wanting it, vendors will switch to it. Instead, right now we get companies like Apple reinventing the wheel via their own proprietary FS just to adopt some features of ZFS, rather than _just supporting and contributing to ZFS_.

Which means I get to anxiously eye the Synology with btrfs instead of resting easy with ZFS. It’s better than ext4, but I also know I’m the exception rather than the rule.

my middle name is danger

Hah! Yeah, I whoopsied on some JP soundtracks a few times in the past as well. While world-ending the first time it happened, now I just view it as a glib, "oh _no_, now I have to relisten to the _whole album_ and figure out which track is which!"

It really is an incredible resource, and Picard is a wonderful app. Very satisfying getting a library properly tagged! Takes a while, but totally worth it. Shoutout to ListenBrainz as well, their scrobbling service: https://listenbrainz.org/

If linux people are interested in using listenbrainz and can't find a player with plugin for it (usually media players ignore it in favour of last.fm) I developed a generic scrobbler daemon that works well with it (also with libre.fm and last.fm): https://github.com/mariusor/mpris-scrobbler#authenticate-to-...

MPRIS is an under-appreciated standard and a great example of how different technologies on the open desktop should integrate with one another.

For example, there's <https://github.com/altdesktop/playerctl>, which can control any MPRIS-compatible client: VLC, web browsers, different music players, mpd (with a plugin), etc.

MPRIS can also be used to e.g. allow controlling playback without unlocking the screen - the screen locker itself doesn't need elaborate support, something as simple as slock could be hacked to recognise a key combo and call out to playerctl; more fancy login managers/lockers could talk DBUS/MPRIS directly and even e.g. display album artwork.

Unfortunately, the standard doesn't seem to specify a simple way to indicate whether video is being played back, which could be a saner way to inform the screen locker; the actual protocol to directly inhibit locking is unfortunately a little bit insane.

Read the spec, there's probably some interesting ideas to explore: https://specifications.freedesktop.org/mpris-spec/latest/

Funny you mentioned playerctl. Due to the fact that over time its scope expanded from a simple MPRIS based control application, into a full blown library with various unneeded (by me) features. Therefore as a starting point for the scrobbler daemon I wrote the simpler mpris-ctl: https://github.com/mariusor/mpris-ctl, which does just the control and meta-data output parts that playerctl has, and only depends on libdbus.

And concerning your last point, are you advising someone that built at least one MPRIS tool to read the spec? :P

> And concerning your last point, are you advising someone that built at least one MPRIS tool to read the spec? :P

The whole comment was for the general HN audience who might not be aware of MPRIS.

The general problem I keep seeing is silos; we've had the XDG standards/specs for decades, yet keep reinventing new, stupid, and broken ways to do things. Under X11 it was normal that every window got a border; under Wayland, GNOME doesn't want to adopt a protocol where a window can ask the compositor to paint a basic border, instead tells SDL to link against libadwaita. XScreenSaver has been telling apps to do "while sleep 60; do xscreensaver-command --deactivate; done" which worked well enough for decades; to "modernise" that, we have a DBus protocol which makes an app grab a cookie, and if it fails to return it (e.g. because it crashed) - the screensaver remains inhibited forever. Trying to use (or improve upon) a FOSS desktop is death by a thousand papercuts.

Thank you for your work.

Thank you for the clarification, sorry for the snark. :D

I use it to prepare my mp3/music for my self-hosted Funkwhale. Such a nice combination and it is fun again to really _own_ music.

Somehow I hadn't heard of funkwhale, I'll have to give it a shot. Have you used navidrome? That's what I'm running now, wondering how it compares.

For me my big wish when I have time is create some kind of automated soulseek flow. Keeping my library up to date is a manual pain for now.

afaik, funkwhale and navidrome have overlapping usecases, but don't have the same goals. funkwhale with its federation features wants to be more than a web player for your library

Yes, although I don't use the federation features from Funkwhale. I just enjoy its clean and awesome interface. Funkwhale is a joy to use and fits very well my music habits (listening to selected albums instead of all over the place - though this is supported too, of course).

I pair Funkwhale with Snapcast-Mopidy-Iris stack, in case I want to have multi-room audio or listen to other sources, beyond my own library.

Reply on news.ycombinator.com