Derived tags
October 03, 2017 in bliss by Dan Gravell
The introduction of the tag accuracy rules have helped fix a lot of music libraries. But there are edge cases... (there are always edge cases)
Sometimes, having the canonical album name, for example, is not enough. I'll allow a recent poster to the support inbox describe:
I can't get a way to resolve different releases like vinyl, DSD or hi-res, so I would like to put that in the name field. For example: John Williams - Close Encounters of the Third Kind (SACD remastered edition in DSD format), and a separate MP3 album. If I put the same name bliss merges them in the same folder and if I change the name album bliss says they are non-compliant.... is there any way to resolve this?
It seems a quite common requirement is for music collectors to have multiple versions of an album in their collection, and only want to play one version of it. If you've invested in some high quality audio gear, it makes sense that you'd rather play the FLAC version rather than the lossy MP3 version you encoded for your phone.
The trouble with bliss's canonical tag accuracy checks is that both albums will end up being tagged in the same way, and as a result there's no way for a lot of music players to distinguish between the two albums. Indeed, in bliss the two albums will be combined by default.
Ideally, your music player (and bliss) would be able to separate albums by bitrate if you so wanted. Unfortunately that's not always a possibility. The backstop solution is to change the album name to a common format, consistent through your library. For example, to have two distinct albums, maybe one called Loveless and the second Loveless [MP3]
Sounds like a fix
Derived tags are my way of describing a solution for this. Derived here means that the resulting tag should be derived from other sources, for example the canonical source of data, or the existing tag. Imagine being able to define an album title tag as so:
Album name: <album name> [<format>]
Look at it as a way of programming your music tags. Instead of them being static data, they could be evaluated (and re-evaluated) changing with time. That sounds like a powerful concept.
Another example... imagine you have multiple releases of the same album. You could include the year in the album name like this:
Album name: <album name> (<year>)
Or:
Track name: <track name> (featuring: <track artists>)
Or:
year = <% timeformat field=year format=YY %>
It really comes down to the templating engine we choose to use.
Won't this just fail the tag accuracy checks?
Makes sense; the canonical sources of data do not have these "[MP3]" (or whatever) decorators, so wouldn't the comparison bliss makes fail?
The answer is no, because the derived tags will be inserted into the evaluation pipeline. The pipeline is basically the sequence of manipulations bliss makes to a label (album name, genre, artist, whatever) to derive the final desired, compliant, label.
In a similar way, derived tags would interplay with case rules, such that the capitalisation manipulation gets applied after the derived rule evaluates, meaning you still get, say, loveless [mp3].
Because the derived tag manipulation is in the pipeline, the result passes the comparison tests and is judged compliant.
Conditional derivation
Bit of a mouthful...
An obvious question that comes to mind when considering, for example, <album name> [<format>] is: what if you only want that for certain file formats? For example, your collection maybe generally FLAC, and you just want to identify and separate the MP3 albums, leaving the FLAC album names "pure" and canonical.
A naive implementation may be to add conditional clauses to the templating engine, like so:
Album name: <album name><% if format<>'flac' %> [<format>]<% end if %>
That works, but it's messy in the sense that the template needs careful reading and more attention. Furthermore it doesn't scale; what if the rule is different again for OGG files? What if lossy files should also include the bitrate, but 24bit files should just have the sample rate?
I think the best solution demonstrates the power of rulesets again. By choosing a selector to apply to certain albums, and overriding the rules for those albums, the derived syntax would be much cleaner:
Lossy album names: <album name> [<format>] HD album names: <album name> [<sample rate>] All other album names: <album name>
Let the people decide
I've created a new idea on the ideas forum to track feedback and popularity of this. Let me know what you think, either here or in the ideas forum, and if you agree click Vote!
Thanks to Quino Al for the image above.
