Author Topic: 'composer' incorrectly parsed in virtual tags  (Read 1630 times)

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
When using a virtual tag that references <Composer>, it is not parsing the actual 'Composer' tag but the 'Display composer' tag.
This can cause problems when a track has multiple composers.

(seems somehow related to this: https://getmusicbee.com/forum/index.php?topic=39254.msg212030#msg212030 , what has been solved earlier today)

I am guessing that's a mistake/oversight that can be corrected?
Last Edit: May 06, 2023, 05:20:15 PM by hiccup

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
<Composer> maps to display composer
I would need to add a <Composers> tag (like <Artists>) to make the individuals available

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
<Composer> maps to display composer
Why not to 'Composer?

Quote
I would need to add a <Composers> tag (like <Artists>) to make the individuals available
I can't oversee what that would mean exactly, but in general my opinion is that it is good to always  be clear and consistent about the differences between plural and singular for all tags.

artist vs. artists
album artist vs. album artists
composer vs. composers
etc.

So MB currently parsing 'Display composer' (which can be plural) when a virtual tag is using <composer> (singular) ijust seems wrong to me.

So if your suggestion means that MB would have separate tags for composer and composers I am all for it.
(while at it, perhaps add 'album artists' too?)


The Incredible Boom Boom

  • Sr. Member
  • ****
  • Posts: 1269
I'm ok with this as long as the current functionality of <Composer> remains the same.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
I'm ok with this as long as the current functionality of <Composer> remains the same.
But not the fact that for virtual tags MB currently parses 'display composer' instead of 'composer' I hope?

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
So I finally understand why I have been getting unexpected results with both virtual tags and theater modes (what has been addressed with the latest patch) when using 'Composer'.

MusicBee is preferring a possible present 'Display Composer' tag over the actual 'Composer' tag.
It is not only doing that for displaying purposes at locations where that might make sense, but it is also doing that in the Tag Editor panel, and for virtual tags.
Hm, I now realise I should always check the ... button at the right of the composer field to see what is shown there. Same as with 'Artist'. *



In my opinion that's incorrect and unexpected behaviour.

1. Can it be changed so that the actual 'Composer' tag is always used when a virtual tag uses <Composer>, and does not switch to using Display Composer if that happens to be populated too?
    (perhaps <Display Composer> could additionally be made available for use in virtual tags so to have that option available too? But then again that may not be needed when 3.6 gets <Composers> )
2. Are there occasions where MusicBee will auto-populate the Display Composer tag by itself? (similar to Display Artist)

For now I am deleting all existing Display Composer tags from my library, which solves the current issues, but I am concerned MusicBee might populate them again at some point without me knowing.


* edit

3. A + sign should probably be added to Composer in the Tag Editor to indicate it when Composer has multiple fields.
    Similar to that happening for Artist:

Last Edit: May 13, 2023, 02:02:25 PM by hiccup

Mayibongwe

  • Sr. Member
  • ****
  • Posts: 1014
  • Heal The World
1. Can it be changed so that the actual 'Composer' tag is always used when a virtual tag uses <Composer>, and does not switch to using Display Composer if that happens to be populated too?
    (perhaps <Display Composer> could additionally be made available for use in virtual tags so to have that option available too? But then again that may not be needed when 3.6 gets <Composers> )
2. Are there occasions where MusicBee will auto-populate the Display Composer tag by itself? (similar to Display Artist)
#1
The introduction of <composers> will make it possible to access the actual <composer> value(s) - which wasn't possible prior to you bringing this up.
I'm not so sure if that change should be done now so far in the development as:
<artist> (outputs display artist) and <artists> (outputs the actual value(s)) have also worked on the same basis since inception by the looks of it.

#2
In my testing, <display composer> is only written to the file when the composer field in the Tag Editor is different from the actual value(s) in <composer>, if that make sense.

For now I am deleting all existing Display Composer tags from my library, which solves the current issues, but I am concerned MusicBee might populate them again at some point without me knowing.
Not knowing anything about the classical side of music, are you sure that's a good idea...
Looking at ur screenshot, I don't see C. Richard F. Maunder as a separate <composer> tag.
Do you have that value saved elsewhere? Won't you lose a record of that person in the file once you clear <display composer>?
Favourite song at the moment:   Decode by Paramore

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
Not knowing anything about the classical side of music, are you sure that's a good idea...
Looking at ur screenshot, I don't see C. Richard F. Maunder as a separate <composer> tag.
Do you have that value saved elsewhere? Won't you lose a record of that person in the file once you clear <display composer>?
That is where <Composers> gets in. (which is going to be added for MusicBee 3.6)

For me, then <Composer> will be a singular value (it could be "Composer1, Composer2" though, note the use of a comma instead of a semicolon)
<Composers> will contain all 'composers', which in my case (using Picard) will automatically get populated with all the people that had some significant role in how the composition came to be.

edit
I'm not sure this is interesting to anyone else, but while it is on my mind:
This will also allow me to separately display the 'main' composer and any 'additional' composers. (that have made alterations or additions to the original—or uncompleted (*)—composition)
(by subtracting <Composer> from <Composers>)

(*)  Some composers had the audacity to die before completing some of their works.
B'tards.
Last Edit: May 13, 2023, 05:40:42 PM by hiccup

Mayibongwe

  • Sr. Member
  • ****
  • Posts: 1014
  • Heal The World
Not to be misunderstood: I welcome the introduction of <composers>.
It's the suggested change of getting <composer> to not parse <display composer> that I feel would be consequential to <artist> & <artists> as they both currently use the same behavior.
The suggestion is valid, the way I see it too, but if taken up, won't it necessitate a change in the result/output of <artist> as well? (for uniformity/consistency)

For me, then <Composer> will be a singular value (it could be "Composer1, Composer2" though, note the use of a comma instead of a semicolon)
<Composers> will contain all 'composers', which in my case (using Picard) will automatically get populated with all the people that had some significant role in how the composition came to be.
Will <composers> be a writable tag? I got the impression that it would only be for display purposes in the virtual tag editor and other concerned areas.
I'm most probably confused or uninformed on how composers actually work - I can't understand at the moment why you don't prefer <composer> having multi-values.

If <composers> is to work the same as <artists> (as I've understood it), it will merely be a readable tag that contains all the individual <composer> tags.
The same multiple tags that you plan to add onto <composers>, I don't get why you haven't added them as individual <composer> tags yet.

I have a feeling that I missed the mark completely, but I wouldn't like for you to derail the purpose of this thread by explaining the concept of composers to me.
This wouldn't be the topic for that. Ignore my statements if they are truly missing the point.
Favourite song at the moment:   Decode by Paramore

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
Quote from: Mayibongwe
The suggestion is valid, the way I see it too, but if taken up, won't it necessitate a change in the result/output of <artist> as well?
That may be a valid point, but I have no virtual tags that make use of artist or artists, so I have no opinion on that. Others may want to chip in on that?

Quote from: Mayibongwe
Will <composers> be a writable tag? I got the impression that it would only be for display purposes in the virtual tag editor and other concerned areas.
Absolutely, it will be a regular tag just like all the others.

Quote from: Mayibongwe
I can't understand at the moment why you don't prefer <composer> having multi-values.
I won't go into the details of my over-complicated schemes, but for

1. I value being clear and consistent about the difference between singular and plural. (e.g. Album Artist and Album Artists have their different purposes)

2. For classical compositions you can have a main composer and secondary composers that have added stuff or made alterations afterwards. They are still 'composers' of the piece, but they are not the main composer. It is nice if they can be kept separated.

Quote from: Mayibongwe
Ignore my statements if they are truly missing the point.
I certainly won't ignore any of your comments ;-)
Questioning things is always good. It may bring me to reconsider things I may have overlooked, or help others to understand better what is being asked for/discussed here.

The Incredible Boom Boom

  • Sr. Member
  • ****
  • Posts: 1269
But not the fact that for virtual tags MB currently parses 'display composer' instead of 'composer' I hope?

Unfortunately, yes. My stupidly complex Virtual Tags parse "Display Composer" as it is currently.
If <Composer> remains as it has been, while @Steven merely includes <Composers>, nothing on my end would be affected, I believe.
The above change, however, along with the addition of more Virtual Tags, may allow me to significantly simplify some of my complicated ones in the future!

#2
In my testing, <display composer> is only written to the file when the composer field in the Tag Editor is different from the actual value(s) in <composer>, if that make sense.

Yes, that's how it works. In fact, part of my mp3tag processing explicitly writes the DISPLAY COMPOSER tag to the file so MB doesn't write it to the library.

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
My stupidly complex Virtual Tags parse "Display Composer" as it is currently.
Ok, but you are not actually 'telling' MusicBee to use 'Display Composer' to retrieve the data.
It just 'happens' that you have populated 'Display Composer', and in that case MB switches from parsing 'Composer' to parsing 'Display Composer'.

There may be history for that behaviour, but I still find it odd and unexpected.

If I understand your setup correctly, as soon as <Composers> is available, couldn't you simply copy your <Composer> tags to <Composers>, and then do a search and replace in your virtual tags to replace <Composer> with <Composers>?
That shouldn't be a big operation?


edit:
And out of curiosity, in your case, where does mp3tag retrieve composer data from? MusicBrainz?
Last Edit: May 14, 2023, 07:21:13 AM by hiccup

The Incredible Boom Boom

  • Sr. Member
  • ****
  • Posts: 1269
Ok, but you are not actually 'telling' MusicBee to use 'Display Composer' to retrieve the data.
It just 'happens' that you have populated 'Display Composer', and in that case MB switches from parsing 'Composer' to parsing 'Display Composer'.

There may be history for that behaviour, but I still find it odd and unexpected.

I view it similarly to how @Mayibongwe does <Artist> (which is represented by "Display Artist"), just that @Steven hasn't given us a <Composers> option until now.

Quote
If I understand your setup correctly, as soon as <Composers> is available, couldn't you simply copy your <Composer> tags to <Composers>, and then do a search and replace in your virtual tags to replace <Composer> with <Composers>?
That shouldn't be a big operation?

Not necessarily, because <Composers> will be formatted as
Code
Person 1; Person 2; Person 3
while my use case for "Display Composers" is Person 1, Person 2 and Person 3.

Quote
edit:
And out of curiosity, in your case, where does mp3tag retrieve composer data from? MusicBrainz?

Yup!