Language tagging of instrumental recordings of works

MusicBrainz Picard
, , , ,
1

I’m generally quite happy with Picard, but one thing that bothers me is that it sets Language:eng even for works with the “instrumental” relationship attribute; typically I’d rather those use zxx, and that difference may become important if I ever get around to creating a filter for non-lyric files. Is it for safety, where “instrumental” might mean more like “the main vocals have been removed, but not the backing” (along the lines of the “karaoke version of” relationship), or is it just a programming oversight? It’s probably a trivial plugin to fix it, but I’m curious about any reasoning that may have gone into that.

1 Like
2

I’m pretty sure it’s a bug/an oversight, and I’ve been annoyed at it myself in the past. So I went and filed a ticket:
https://tickets.metabrainz.org/browse/PICARD-1117

4 Likes
3

I am looking at the ticket for this and I don’t actually think this should be considered as a bug. Basically Picard is setting the language as it is in the MusicBrainz data. Shouldn’t this be fixed there?

In any way if one wants this behavior of Picard it is easy to do so with a simple script:

$set(language,$if($inmulti(%_performance_attributes%,instrumental),zxx,%language%))

I actually use the following script to remove the language tag entirely for the zxx case:

$if(%language%,$set(language,$if($inmulti(%_performance_attributes%,instrumental),zxx,%language%)))
$if($eq(%language%,zxx),$delete(language))
3 Likes
4

MusicBrainz just tells clients that the Work has a given lyrics language, regardless of whether said lyrics are performed, no? It’d feel weird if MusicBrainz gives different information about a work based on a relationship attribute for a Recording (e.g., what if a Release has multiple Recordings of a given Work and a client decides to cache the Work data… should it then cache the Work for every single variation of the relationships used for the Work?). It should be on the clients (e.g., Picard) to handle this information meaningfully, IMHO.

4 Likes
5

Ok, yes. That makes sense. Doe sone of you see any use case for having the work language set even for instrumentals?

I am asking because if we hardcode that logic to set language to zxx for instrumental recordings this cannot easily be changed. The current dumb logic can be changed with an easy script, but as soon as Picard is more clever here a script cannot easily revert it. But if there is a use case for getting the work language even for instrumentals we could of course also introduce a hidden %_worklanguage% variable. Then people really wanting the old behavior could do:

$set(language,%_worklanguage%)
1 Like