MinimServer Forum

Full Version: Multiple composition tags
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I use Group and Composition tags very much as described in the User Guide. After initial hesitation as to whether it was worth the effort, I have found that using this MinimServer capability significantly improves the browsing experience. So thanks again to Simon for another very useful facility.

Very occasionally, I wish to use multiple Composition tags in a track. This happens when part of a larger composition is often played on its own. For example, the second movement of Sibelius' Lemminkäinen Suite is The Swan of Tuonela, which is often recorded separately. Sometimes, I like to browse for the whole Suite, and sometimes I want to look for the all the recordings I have of the movement on its own, whether recorded separately or as part of the Suite.

MP3Tag allows the creation of multiple Composition tags (the process is a little complex, but I can give details if anyone is interested), so I can tag the movement both as a separate work and as part of the Suite. MinimServer reads and indexes these multiple tags without difficulty, so the work I referred to above shows up twice in the list of compositions, once as part of the suite, and once on its own. However, when accessed as a single movement, it is still governed by its Group tag, that is the whole Lemminkäinen Suite shows in the list (with all the tracks at the next level down) rather than just the Swan of Tuonela movement on its own.

I don't know whether this is intended behaviour, or just the way groups work, but ideally when I am browsing for the single movement via its separate composition tag I should prefer to see just that movement in the list, and not the whole group of which it is part. Is this possible?

I assume, by the way, that the behaviour I have described is a function of the browse tree and therefore governed by MinimServer; certainly I get the same results in both Bubble DS and Kinsky.

David
(13-01-2014 19:17)DavidHB Wrote: [ -> ]I use Group and Composition tags very much as described in the User Guide. After initial hesitation as to whether it was worth the effort, I have found that using this MinimServer capability significantly improves the browsing experience. So thanks again to Simon for another very useful facility.

Very occasionally, I wish to use multiple Composition tags in a track. This happens when part of a larger composition is often played on its own. For example, the second movement of Sibelius' Lemminkäinen Suite is The Swan of Tuonela, which is often recorded separately. Sometimes, I like to browse for the whole Suite, and sometimes I want to look for the all the recordings I have of the movement on its own, whether recorded separately or as part of the Suite.

MP3Tag allows the creation of multiple Composition tags (the process is a little complex, but I can give details if anyone is interested), so I can tag the movement both as a separate work and as part of the Suite. MinimServer reads and indexes these multiple tags without difficulty, so the work I referred to above shows up twice in the list of compositions, once as part of the suite, and once on its own. However, when accessed as a single movement, it is still governed by its Group tag, that is the whole Lemminkäinen Suite shows in the list (with all the tracks at the next level down) rather than just the Swan of Tuonela movement on its own.

I don't know whether this is intended behaviour, or just the way groups work, but ideally when I am browsing for the single movement via its separate composition tag I should prefer to see just that movement in the list, and not the whole group of which it is part. Is this possible?

I assume, by the way, that the behaviour I have described is a function of the browse tree and therefore governed by MinimServer; certainly I get the same results in both Bubble DS and Kinsky.

David

Which list are you referring to here?

As previously discussed on the forum, grouping is a containment relationship (unlike tagging). The browsing path that you've used to locate an item can't change what group and/or album contains the item.
(13-01-2014 20:15)simoncn Wrote: [ -> ]Which list are you referring to here?

I'm sorry if this was not clear. In the example previously given, I browsed Genre -> Composer -> Composition, and selected the entry for The Swan of Tuonela. This produced a list of (say) two items. One is a separate recording with the title The Swan of Tuonela, while the other is the whole Lemminkäinen Suite; if I select the latter (which is the group containing the other recording of The Swan of Tuonela), all four movements of the Suite are listed. I suggested that, ideally, this should not happen; only the two recordings of The Swan of Tuonela should be listed against the relevant composition tag. But, as I explain below, I now realise that this ideal is not achievable.

Quote:As previously discussed on the forum, grouping is a containment relationship (unlike tagging). The browsing path that you've used to locate an item can't change what group and/or album contains the item.

I understand the distinction. What I was suggesting is not that the containment relationship should change, but that the second Composition tag should allow the circumvention of the grouping/containment.

I now remember that grouping works in the browse tree by replacing all the grouped tracks with the single group identity, and the individual tracks can only be seen once the group itself is selected. Presumably this is an all or nothing thing; once the grouping has been applied, direct selection of the individual tracks is just not possible unless the grouping is removed. In other words, containment is inescapable.

Although, as I said, this is less than ideal in the case I have described, the case itself is fairly unusual and the limitation is easy to live with now I see how it arises. At least I now understand grouping somewhat better than before I experimented with multiple Composition tags.

David
(14-01-2014 01:23)DavidHB Wrote: [ -> ]I'm sorry if this was not clear. In the example previously given, I browsed Genre -> Composer -> Composition, and selected the entry for The Swan of Tuonela. This produced a list of (say) two items. One is a separate recording with the title The Swan of Tuonela, while the other is the whole Lemminkäinen Suite; if I select the latter (which is the group containing the other recording of The Swan of Tuonela), all four movements of the Suite are listed. I suggested that, ideally, this should not happen; only the two recordings of The Swan of Tuonela should be listed against the relevant composition tag. But, as I explain below, I now realise that this ideal is not achievable.

Thanks for this more detailed explanation. This is happening because MinimServer treats the entire group as a single item when browsing and searching, and all the tags for all the group's contents are merged together and applied to the group as a whole.

To do what you want, it would be necessary to refine the concept of grouping by exposing the individual items with all their tags for browsing and searching operations. Selected items would be "reconstituted" as a complete group if and only if all of the items in the group are selected by the browse or search operation. If some items are selected but not others (as in the case you have described), only the selected items would be shown. It might also be desirable to extend the "Complete Album" selection mechanism to add a similar "Complete Group" concept.

This is an interesting idea, but it would be quite a large amount of work to implement it and it probably wouldn't perform as efficiently as the current mechanism. Given that the case you're describing is rare and only requires one extra click to navigate into the group, I'm inclined to add this to the "interesting ideas to think about" list for now.
(14-01-2014 08:56)simoncn Wrote: [ -> ]Thanks for this more detailed explanation. This is happening because MinimServer treats the entire group as a single item when browsing and searching, and all the tags for all the group's contents are merged together and applied to the group as a whole.

Yes. I twigged that ... eventually.

Quote:To do what you want, it would be necessary to refine the concept of grouping by exposing the individual items with all their tags for browsing and searching operations ... This is an interesting idea, but it would be quite a large amount of work to implement it and it probably wouldn't perform as efficiently as the current mechanism. Given that the case you're describing is rare and only requires one extra click to navigate into the group, I'm inclined to add this to the "interesting ideas to think about" list for now.

This is as much as it is reasonable to hope for. I quite agree that sacrificing performance to implement a change of this kind makes no sense at all.

I have been thinking about the 'rarity' factor, and it seems to me that the case typically arises when the 'contained' track is better known in its own right than the 'container' work. Another example would be the Villa-Lobos "Little Train of the Caipira" from Bachianas Brasileiras No. 2. As such cases are not all that numerous, it might be better to make a separate copy of the 'contained' track with different metadata and no grouping, rather than use multiple composition tags in the original. That would solve the containment problem, such as it is.

David
Reference URL's