Feature suggestion: customise abum, title inside groups

[simoncn]

(17-04-2013 10:17)classical11 Wrote:  The new version fully handles what I was after. I didn't even have to retag my library: by setting Title.displayFormat={$movement}, the movements appear as I want them when browsing the contents of a work.

I particularly like the fact that <upnp:album> is now sent to the control point with the Group tag for the tracks that are under a group.

This also has the nice added benefit that the Album and Title tags shown in the Now Playing screen of the control point are much shorter but without losing any useful information.

Thanks very much for the changes and for implementing them so quickly!

I'm glad this is working well for you. Another benefit is that tracks are grouped on the playlist (with control points that support this) by group/composition rather than by album.

[bbrip]

HI,

I am playing with adapting the Group tag concept for my Live-recitals. i.e. if I have a Chopin recital, and as apart of it the 3rd Sonata is being played, I group those 4 tracks together. Works well with a control point like Songbook Lite or Kinsky. Doesnt work yet with LUMIN as LUMIN then cuts the Album into 2 Albums, one with the Sonata, one with all other tracks... But that appears to be a problem of LUMIN.

However, where 2 compositions are "grouped" on a CD more or less artificially (like the example quoted by classical11 above), I will continue to tag those as two separate albums to start with.

But with that new control over what is being displayed using the tagFormat property the Group property is definitely becoming a true option for me.

Many thanks
bbrip

[Oliviander]

(15-04-2013 21:55)simoncn Wrote:  I've made a few changes to how this is implemented. I hope this will give you what you need.

1) You can now create a Group.displayFormat setting in addition to Title.displayFormat and Album.displayFormat

2) You can now specify the value $group in a format item. This has the following meaning:
For a track that's a member of a group, it's the group name
For a group, it's the group name
For everything else, it's ignored

3) The $album value in a format item has been extended, as follows:
For a track that's a member of an album, it's the album name
For a group that's a member of an album, it's the album name
For an album, it's the album name
For everything else, it's ignored

4) For a track that's a member of a group, the DIDL-Lite presented to the control point has the <upnp:album> value set to the group instead of the album.

Hi Simon,
I am playing around with these features for two days now,
and they are great.

But I have got 3 little things missing to get everything out of it
i hoped for:

1. Maybe I didn't get it:
but am I right that I can't displayFormat the ALBUMARTIST
entry of an ALBUM ?
I would like to do that.

2. Obviously the ALBUMARTIST entry is used for
the Group too.
I would like to format that in anotherway as
the ALBUMARTIST entry.
Meaning there should be GROUPARTIST Tag too
(Standard behaviour of course GROUPARTIST = ALBUMARTIST)

3. (your 4.) Sending the Group Value to the controlpoint
very is useful in most cases.
BUT I have one instance aof MinS running
wheer this behavior is not useful.
So it would be good to make this optional
(but actual I can live with it as it is now)

BUT 1 and 2 would be really great to see soon!
as it would complete the format possibilities of
the output to the CP.

Addition:
I just discovered that I can do format
the entry by
aliasing Albumartist:nil
and then formating the artist tag.
So only my 2 is still of concern to me

[simoncn]

(20-04-2013 08:01)Oliviander Wrote:  Hi Simon,
I am playing around with these features for two days now,
and they are great.

But I have got 3 little things missing to get everything out of it
i hoped for:

1. Maybe I didn't get it:
but am I right that I can't displayFormat the ALBUMARTIST
entry of an ALBUM ?
I would like to do that.

You are correct, and I will investigate adding this. At the moment, I don't think it would cause any problems.

Quote:2. Obviously the ALBUMARTIST entry is used for
the Group too.
I would like to format that in anotherway as
the ALBUMARTIST entry.
Meaning there should be GROUPARTIST Tag too
(Standard behaviour of course GROUPARTIST = ALBUMARTIST)

You can define GROUPARTIST yourself and tag your groups with this. If you do this, you would need MinimServer to provide a way to use GROUPARTIST if it is defined, and use ALBUMARTIST if GROUPARTIST isn't defined.

This capability could be supported by adding the following syntax:

AlbumArtist.displayFormat={$groupartist|$albumartist}

The or sign '|' indicates that the value(s) following it should be used only if the previous value(s) aren't present.

Quote:3. (your 4.) Sending the Group Value to the controlpoint
very is useful in most cases.
BUT I have one instance aof MinS running
wheer this behavior is not useful.
So it would be good to make this optional
(but actual I can live with it as it is now)

Could you explain the scenario where this isn't useful? Would it be possible to get what you want by aliasing Group to something else?

[Oliviander]

(20-04-2013 20:46)simoncn Wrote:  You can define GROUPARTIST yourself and tag your groups with this. If you do this, you would need MinimServer to provide a way to use GROUPARTIST if it is defined, and use ALBUMARTIST if GROUPARTIST isn't defined.

This capability could be supported by adding the following syntax:

AlbumArtist.displayFormat={$groupartist|$albumartist}

The or sign '|' indicates that the value(s) following it should be used only if the previous value(s) aren't present.

Hi Simon,
I will try how this works, but I don't think this is what I meant.
Because in my scenario I have always a GROUPARTIST
and an ALBUMARTIST TAG existent.
And therefore i guess the Groupartist would always be used.
But I still want to see the original ALBUMARTIST
in the ALBUM list view. (details see below)
But as I said, this is not a major concern.

Quote:Could you explain the scenario where this isn't useful? Would it be possible to get what you want by aliasing Group to something else?

Hi Simon,
ok you asked for it:
I think to really make someone understand
what I'm thinking and doing, I have to tell the whole story:

I have 2 MinS instances running serving my classical Collection.
(Classical Music only, I have other instances for the other music).

I have done this because in my opinion it is very different if

1st case, I call it "AlbumSearch"
I want to select an known Album. (in this case most of the time
I visualize a CD when selecting the music and in physical means
I would know how the CD looks like and where its place in the shelf is.)

Or if 2nd case, I call it "WorkSearch" :
I am searching for a something I don't know whether it is buried
in my collection or not.

The first MinS instance is strictly for AlbumSearch
and I have only 2 Search indexes
(Last but not least I do this because of the Wife Acceptance Faktor)
ALBUM_ARTIST_SORT
ALBUM_COMPOSER_SORT

I have these 2 Tags (multiple entries possible) always identical for all tracks of an album.
(For these TAGS I strictly use only the big lettered Front Cover info)
So the selection always leads to the complete album.
In this case I like to have the ListViewAlbums at rather
large value (like 50).
So this is like going to a row of my shelves and the picking the album.

For Display purposes of a playing file I have aliased WORK:GROUP
(alias Tags = WORK:Group)
so in the playlist I don't have the Album any more but the Work
as a Header.

So for this use of Group it is great to send the Group Tag
instead of the Album Tag to the Control point, like it is now.

But I have some problems with the ALBUMARTIST TAG.

I have the following TAGS for View prposes

ALBUM_ARTIST : multiple entries and identical for all tracks of an album
ARTIST : multiple entries and identical for all tracks of a group (WORK)

When I set ALBUMARTIST to display ALBUM_ARTST
and see an Album list to select from
I have the ALBUM_ARTIST Tag in the second line (Kinsky)
which is exactly what I want.

But when I play a Track it is still the ALBUM_ARTIST Tag
displayed below the Group in the playlist.
And sometimes this might be either a wrong information.
(When not all ALBUMARTISTS are ARTISTS too)
Or rather incomplete Information
(When there are ARTISTS I want to see displayed that
are not ALBUMARTISTS)
The same problem occurs when I select a GROUP out of an ALBUM
it is still the same ALBUM_ARTIST displayed while the ARTIST
would be the correct information.

So while this is rather a minor nuisance for me, I think
you should consider a distinctive treatment of these 2 cases
as I understand that you want to encourage
different and creative uses of the GROUP functionality,
and therefore it is not consistent to combine the display
an ALBUM property with a GROUP property in a list.

My second MinS instance is strictly for WorkSearch.
here I have aliased the Works to an Album,
so the original Albums do not show up anymore.
alias Tags = WORK:Album
for easier selection I have some WORKS
Grouped in parts with a PART Tag
alias Tags = PART:Group

This can have different uses
as Acts of an Opera or Part of an Oratorium.
But it is not used where one Track
contains 1 Movement (too much work for too much redundance)

In this case I have no problems with the artist line,
as in the Album list and in the Group List
the ARTIST tag is used and correct for both cases.

But now when a track is selected

WORK: Parsifal (as album)
PART: 1.Akt (as group)

only PART is send to the controlpoint as a header
while here still the WORK would be that what I want.

I know how to, and I do for now circumvent this
by Tagformating the
Group to ($Work - $Part)
but then I do this, it is the formatting in the Albumview too
and there it is rather a nuisance because the group entries
are now all including the header.

But I would prefer :

Parsifal
1.Akt
2.Akt
3.Akt

over the now displaying

Parsifal
Parsifal 1.Akt
Parsifal 2.Akt
Parsifal 3.Akt

especially with much longer WORK names as
"Die Meistersinger von Nürnberg"

on the other hand I have no real use for the
PART suffix which now shows
in the playlist.
As I have these Info already as a Prefix in the TITLE Tag

Conclusion for Elegance Purposes:

With a seperate GROUPARTIST handling
and the OPTION to send the ALBUM or the GROUP as
a header to the Playlist I would be able
to let show up the items of the Playlist
in exactly the same form not depending
whether they are selected by my
AlbumSearch or my WokrSearch instance

And I think this freedom could encourage uses
of groups I am not even thinking of

[Oliviander]

(20-04-2013 20:46)simoncn Wrote:  

Quote:3. (your 4.) Sending the Group Value to the controlpoint
very is useful in most cases.
BUT I have one instance aof MinS running
wheer this behavior is not useful.
So it would be good to make this optional
(but actual I can live with it as it is now)

Could you explain the scenario where this isn't useful? Would it be possible to get what you want by aliasing Group to something else?

Ok I gueass my last post was too long to read
and in the meantime
I have some more experience with grouping

I still think this should be optional:
In an abstract level you can say sending the group instead of an
Album entry to the playlist is useful when the grouping
is used to group the items based on content.

I do this, and I am quite satisfed with the results.

In Another MinS instance I want to use group to group
all Multidisc albums in single discs.
In this case I want to tagFormat the group with a rather long name
to indicate the contents of the group.
Therfore the album name as a header would be redundant and not helpful
for selecting purposes.
But I still would like to have it for displaying purposes.

You now could ask why I am not using discsubtitle for this
intent, and the answer is
1. You can't select a subtitled disc for playing and
2. My largest multidisc album has 75 discs, therefore
an ungrouped list would be very long.

[bbrip]

Why do you want to use Group to group mutlidisc Albums? Particulary with operas (your example above) disc is a pretty meaningless 'tag' and no more then a physical storage limitation that goes away as soon as you put the opera on a NAS.

So I rellay dont care about disc in those instances but just tag tracks 1 to 69 ( or whatever it may be in your Parsifal recording) as one album. Because its one opera, isnt it

The act I usually tag as part of the title but of course you could use group for that. I prsonally find that too cumbersome.

bbrip

[Oliviander]

(24-04-2013 19:47)bbrip Wrote:  Why do you want to use Group to group mutlidisc Albums? Particulary with operas (your example above) disc is a pretty meaningless 'tag' and no more then a physical storage limitation that goes away as soon as you put the opera on a NAS.

So I rellay dont care about disc in those instances but just tag tracks 1 to 69 ( or whatever it may be in your Parsifal recording) as one album. Because its one opera, isnt it

The act I usually tag as part of the title but of course you could use group for that. I prsonally find that too cumbersome.

bbrip

Hi bbrip,
you are completely right regarding operas.

But there are some cases where it is the other way round.
when you have an Multidisc with many different works on it
or you have the booklet in your hand that is referring to the cds
and original track numbers then the pyhsical storage just doesn't
want to go away.

But in the meantime I am wondering if it mght be a better solution
to tagformat the original disc and tracknumbers as Prefix to the title tag

[bbrip]

I appreciate what your saying about the booklet referencing to CD tracks. I've just choosen to ignore that slight inconvenience as I usually find it reasonably straight forward to find the right track in any case and find it more disturbing to have my control point referring to CD-numbers - but thats of course a personal choice

But particularly in large operas like Wagner or Berlioz it does help to have a clear indications of Act and Scene as part of the track title to navigate easily

bbrip

[simoncn]

(24-04-2013 18:53)Oliviander Wrote:  Ok I gueass my last post was too long to read

I did read it (several times), and I've been thinking about how MinimServer can provide more flexibility without adding more complexity.

I think it would be useful to add displayFormat support for albumArtist, subject to the constraint that the albumArtist value for a track (<item> in DIDL-Lite) must match the albumArtist value for the containing group or album (<container> in DIDL-Lite).

This constraint is needed to ensure correct functioning of control points that use DIDL-Lite albumArtist values to group tracks on the playlist.

The current fixed formatting of albumArtist in DIDL-Lite is as follows:

i) If the album has an AlbumArtist tag, send the value of this tag

ii) else, if the album has multiple artists, send the combination of all the artist names

iii) else, don't send an albumArtist value in DIDL-Lite

This would continue to be used as the default if no AlbumArtist.displayFormat setting is specified.

The albumArtist value for a group container in DIDL-Lite is currently the same as the albumArtist value for the containing album (if any). This should be customizable (for both album groups and nonalbum groups) using a new tagFormat setting AlbumArtist.group.displayValue={format-string}.

The default if this isn't specified would be as above for album groups, and as follows for nonalbum groups:

i) If the group has multiple artists, send the combination of all the artist names

ii) else, don't send an albumArtist value in DIDL-Lite

Quote:and in the meantime
I have some more experience with grouping

I still think this should be optional:
In an abstract level you can say sending the group instead of an
Album entry to the playlist is useful when the grouping
is used to group the items based on content.

I do this, and I am quite satisfed with the results.

Isn't grouping always based on content? I'm not sure what other kind of grouping there might be.

If you need a more flexible kind of grouping, I'd recommend using another tag. For example, you could use CONTENTGROUP, which corresponds to the Grouping field in iTunes. You could use $contentgroup in your tagFormat values, and you wouldn't get an a DIDL-Lite container for the content group.

Quote:In Another MinS instance I want to use group to group
all Multidisc albums in single discs.
In this case I want to tagFormat the group with a rather long name
to indicate the contents of the group.
Therfore the album name as a header would be redundant and not helpful
for selecting purposes.
But I still would like to have it for displaying purposes.

Please clarify what you mean by 'displaying' and 'selecting'. If these values are created by the control point from the same DIDL-Lite value, it's not possible for them to be different. If the 'selecting' value is a MinimServer index selection, you should be able to make these values different by using a suitable Title.displayFormat setting.

Quote:You now could ask why I am not using discsubtitle for this
intent, and the answer is
1. You can't select a subtitled disc for playing and
2. My largest multidisc album has 75 discs, therefore
an ungrouped list would be very long.

You can select a subtitled disc for playing. Select the ">> subtitle" entry under the album, and then "select to play" the second item (after ">> Hide Contents"). Try it!