“[pseudo-releases] shouldn’t duplicate all the information already available on the original releases they’re linked to.”
That makes sense.
Unfortunately, what can be expected is when one uses Picard to fill the tag corresponding to the pseudo-release, the (normally unchanged and duplicated) tags must be filled too.
This is currently not the case.
e.g. the date is empty (as the date information is already available on the original releases they are linked to.
The main issue here is that pseudo-releases are linked to a group of releases, and not to a unique release in this group.
Perhaps this issue is more a MusicBrainz one than a Picard one.
The aim is to keep things as much automatic as possible, so conventions must be adopted for easier approaches.
So, two strategies:
Make a script that tries to fill first the tag of the nearest official release, and that fills the tag with the ones of the pseudo-release (as a consequence the first tags are replaced)
Of course, the difficulties are to determine what is the nearest official release, and obtain the tag of this one while we are dealing with the pseudo-release ones.
Change the nature of the link: one pseudo release must be associated with at most one official release: the script in point 1 then can become a default supported feature in Picard, as the question of the nearest official release is solved.
Please let me know if there are scripts that try to answer this issue, or perhaps if there are already some discussions about the nature of the pseudo-release links.
Sources and example
Forum discussions and documentation I used to explain the issue:
As things currently stand, it’s 100% a tagging software problem. The database provides the mechanisms for achieving your goal via the webservice (although you need to make multiple webservice calls and merge the data yourself, since you can’t get both the Japanese/Japanese official release and the Japanese/Latin (or English/Latin) pseudo-release release in a single operation).
Picard, out of the box, has no special support for pseudo-releases.
Ok, I am just understanding the logic behind linking several official release to one pseudo-release, as we sometimes don’t care about the date, but rather about the translation e.g.
Picard, out of the box, has no special support for pseudo-releases.
Unfortunately, this is what I understand from this ticket PICARD-145.
Thank you for your answer.
I’ll just fill in the best I can, for example the date with the remaining ones, otherwise block the modification of some tags.
EDIT
Just in case, for now I have just added this script: $set(date, $if2(%date%, %originaldate%))
Personally I don’t think it’s too much work to right click into ‘versions’ in Picard and hit save twice. But my library is mainly English - for a big library with lots of translations it would be a pain!
Those tickets you’ve linked may not be addressed because there is a replacement planned (who knows when) for pseudo releases:
In theory, you are supposed to be able to use Language and Script to determine what’s in a release, but some people like using “multiple languages” and “multiple scripts” literally instead of for disambiguation purposes, despite Style saying otherwise for Japanese titles.
