I saw your work on the PR (#3312) a few months ago and I like the approach.
Navidrome is seriously awesome software but unfortunately it doesn't quite fit my use-case of having a completely untagged library (the metadata of my library is defined in directory and file naming so duplicating and syncing that information into the file metadata simply never made sense to me).
Untagged libraries will not be supported directly in Navidrome which is totally fair enough (https://www.navidrome.org/docs/faq/#-can-you-add-a-browsing-by-folder-optionmode-to-navidrome).

So my intention (#560) was to create a fallback method of inferring metadata when Navidrome encounters an untagged file but I never found the time to look into it (I rarely work in Golang with any intensity so it takes me a while to grok unfamiliar codebases). Your PR has given me inspiration and the entry points on how to get moving on my idea... thanks!

Okay, I may be going it alone with this, but I've been using my tagfiles/sidecar implementation for months now, and since my initial draft PR (#3312) have enhanced the implementation and merged in the BFR updates from master.

My implementation is currently on the tagfiles-bfr branch here: https://github.com/mgdigital/navidrome
Compare my changes to current Navidrome master branch: 0d42b9a...mgdigital:navidrome:tagfiles-bfr

I'm closing my previous draft PR for now. I fully understand that not everyone will want this and that the implementation introduces a new standard along with a maintenance burden, but @deluan will perhaps be interested to take a look anyway.

Examples

1. An artist compilation has not been tagged with albumartist, and so is appearing as a separate album for each track.

Solution: place the following tags.yml file in the album's folder:

albumartist: DJ Yoda

2. A multi-disc album has a different album tag for each disc, and has been placed in subfolders CD1 and CD2.

Solution: place the following tags.yml file in the album's root folder. This file uses the syntax of a top level glob pattern, with overridden key values for each pattern:

"CD*/*.flac":
  album: Physical Graffiti
  totaldiscs: 2
"CD1/*.flac":
  discnumber: 1
"CD2/*.flac":
  discnumber: 2

3. Albums by the same artist have variations of the artist name (e.g. alt-J and Alt J), leading to duplicate entries for the same artist. Some albums have been tagged with album artist, and others with albumartist.

Solution: place the following tags.yml file in the root folder for the artist, to set albumartist on all files in all subfolders, and remove any album artist tags:

albumartist: Whatever
"album artist": null

NEW: Arbitrary tag transformations using CEL expressions

Media files from disparate sources can sometimes have tagging anomalies that would be labourious to fix using the above methods. I therefore added the possibility to use CEL expressions to apply scripted tag transformations.

A key of $ under a tag name indicates that the value is a CEL expression.

Here is just 1 example that I recently dealt with. It concerns a DJ mix where the DJ name has been put in the artist tag of every track, with the title tag containing a concatenation of the actual artist, for example:

This can be fixed with the following tags.yml file:

albumartist: Name of DJ
artist:
  $: tags["title"][0].split(" - ")[0].split(" & ")
title:
  $: value.split(" - ")[1]

You'll then end up with artists split correctly, and the title no longer containing the artist name.

This can be very flexible, for example it could be used for path-and-filename-base tag inference, which although I wouldn't personally want it has been requested a few times. Here's an example of this:

https://github.com/mgdigital/navidrome/blob/38efb691a3643f7a1c9640bacfe33549e6236ef3/scanner/metafiles/parse_tags_file_test.go#L147-L169

If there's interest I can provide more documentation on the expressions - for now you'd have to look at my code and the CEL docs to work out what's possible with this.

@29821632 Thanks for being the only person to respond on this discussion, and please see my comment about about path-and-filename-base tag inference - perhaps you could become the second user of my fork!?

it doesn't quite fit my use-case of having a completely untagged library (the metadata of my library is defined in directory and file naming so duplicating and syncing that information into the file metadata simply never made sense to me).

The problem with this is that the directory/filename can't always encode all the necessary info; for example some characters are not allowed in directory/folder names. But either way it would be possible with my implementation.

I've been looking for something like this for a while, so it's nice to see it implemented here.

Referencing my two use cases at #2853 (comment) and #2853 (comment)

this is a great contribution.