Why are the Cyrillic forms of Composer and Lyricist names being used?

Content you’re reporting an issue with

RoonShareImage-637998726756870316

RoonShareImage-637998733367361820

Have you made any edits to this content in Roon?

Yes. That is the point of the post. Why do I have to make these equivalencing edits from the Cyrillic form of artist names to the Roman form?

Is the album identified in Roon?

Yes (both, there are many other examples)

Is this content from local files, TIDAL, or Qobuz?

Qobuz

Screenshot of import settings

N/A

Description of the issue

Cyrillic versions of Russian lyricists and to a lesser extent composers and performers are cropping up quite frequently. Sometimes very famous figures like Tchaikovsky. I haven’t been keeping a record and have just been editing the artist names to their Roman equivalents as I go along. But I notice it more and more. It is very annoying but up until now I have just been editing the affected artists to the Roman equivalent. This often requires an additional editing step of merging the Cyrillic forms with any existing Roman versions of the artist names.

It doesn’t look as if it is deliberate roon policy as it is so inconsistently applied. Sometimes the Cyrillic form is used and sometime the Roman form. But of course I could be wrong. Which is it? Is there a general policy to change metadata alphabets to the source alphabets over time or is it just another untidy metadata issue at the back of the metadata todo list?

In this case, it’s simply that there is a Даниил Максимович Ратгауз credit from MusicBrainz and no “Artist Name” English alias. Incomplete metadata.

Thanks Joel, I assumed it was something like that.

But my real question is why are the cyrillic and roman forms not being equivalenced? With this example you appear to have the roman form for at least 36 albums. There is also a short roman form of “Daniil Rathaus”.

I have also had cases where there is both the cyrillic and roman form for the same track! In these cases, usually one has the role of “text” and the other has the role of “lyricist”. This is a general problem as there can often then be roman duplicates on both the composer detail line and the lyricist detail line in album views.

Equivalence is driven by credit overlap between metadata for the same albums from different metadata providers; but a common name is also required. Either or both are missing in this case.

Are there really obstacles to matching against composition or track from different albums? Or is that even necessary. Wouldn’t a simple translation do? That is all I am doing. Cutting and pasting into google translate. The example I gave may be a little obscure because that was the straw that broke the camels back but I have also come across Cyrillic versions of Tolstoy which could have been translated?

Whilst we are at it. I might be wrong but this looks to me very similar to a long-standing duplicates issue. One of your metadata suppliers credits the poets or sonnet writers usually used by Classical composers as “Lyricists”, whereas another one is crediting them as “Text”. This seems to be a very hard and fast rule as I have so many examples. But taking the above “Night Songs” album as an example that leads to the following situation:

The strange thing is that “Lyricist” is a composer credit whilst “Text” is a production credit. Maybe the original intention was that the “Text” credit was to be used for things like liner note authors? But this now leads to navigation issues as those production “Text” songwriter credits cannot be found in either artists or composers lists and screens. What I usually do is delete the “Text” credits to eliminate the duplicates:

But surely a better solution would be if they were not being duplicated in the first place? Also, I do come across examples where there is a “Text” credit but no corresponding “Lyricist” credit. I change those to “Lyricist” so that those types of production songwriters do show up in artist and composer screens.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.