Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ferdi]

Feature request: allow multiple values to be entered in the fields 'orchestra' and 'conductor', similar to how the field 'soloist' is managed.

Background: Tagging for Classical music has been discussed much. For me, one of the key features of JRiver is that I have, by standard, fields available that let me help cataloging my collection, and JRemote lets me set up views for smooth browsing:

• Orchestra
• Conductor
• Soloist

For the field 'Soloist', I can enter multiple names, which then appear as different, separate tag values. For example, I have multiples singers for an opera performance, and I can still browse my collection by individual soloists. Awesome!

In contrast to that, the fields Orchestra and Conductor don't allow my to do that: if, for example, I have a 'proper' orchestra accompanied by a choir - which happens fairly frequently -, then I need to maintain both 'orchestras' in the same field. Since I usually maintain the orchestra first, followed, comma separated, by the choir, I can not browse my collection by choir. It also means that I clutter up my list of 'orchestras', since some perform with a larger number of different choirs. (the conductor is not a big problem, only a handful of recordings list two without specifying who conducts which piece)

thanks!

[glynor]

Why not just make a [Choir] field, and use that?

My wife is in a choir, and she'd almost certainly turn up her nose at being lumped in with that rabble! 

[Ferdi]

Nice thinking - and greetings to your wife, didn't mean to offend her -  but choir is only one example of multiple 'orchestras'. and besides, it could be multiples choirs performing together.
So, no    

[glynor]

Yeah... But you could make fields for the others too, if you want, and you can make your fields List-Type fields so you could add multiple values to your custom [Choir] field.  So, you could have a [Quartet] field, or whatever to go with it, and all of those could accept multiple values.

Likewise, if you do want to "group them all together", you can just make your own [Orchestras] field, which is a List-Type field, and just use that instead.  MCs built-in fields aren't "special" in any way. They're just some suggested presets.

The only reason not to make your own is for interchange with other applications that might recognize the [Orchestra] tag, but not MC's custom [Orchestras] or [Choirs] tags.  But, even if you do care about "interchange" with some other application you use, and they do support the regular [Orchestra] tag, they're not going to support multiple values there, and import it as a semicolon delimited string, and so you're back to the same issue with those other applications too.  So that's... Meh.

List-Type fields are handy.  But they also do have a substantial tagging-workflow downside:

When I'm tagging using the Panes, I can very quickly spot an "outlier", and fix it. Maybe Philharmonic-Symphony Society of New York is spelled right on most of my files, but on one or three of them, it somehow got typed as Phliharmonic-Symphony Society of New York.  This will stand out like a sore thumb in a pane showing [Orchestra] (there will be two of them right next to one another), and it is super simple to fix.  All you have to do is click on the badly named pane to select the files, and then check the box on the pane (probably right next to it) where they should be.  Presto-whammo it is fixed.

But list type fields are additive, not replacing, when you tag, so now I have files tagged as Phliharmonic-Symphony Society of New York;Philharmonic-Symphony Society of New York. To fix it, you have to also uncheck the "bad" item after you check the good one.  It is minor, but it can make things sloppy in a big library.  And that's not the only way they're "slower".  It is more steps to tag them in the Tag Action Window, and unwieldy to tag them inline in a View.

The answer isn't always List-Type fields, which is why many of them are not that by default.

But, you can make them.  You did make one, you're just storing it in MC's string type field (and using the wrong delimiter).

None of this is to say one way or the other how I feel about them actually changing [Orchestra] to be a list type field.  I don't really care. But I'm pointing out that it is No Big Deal if you want it that way, they don't have to change it for everyone.  Make your own [Orchestras] field. Switch your Views and columns and whatnot over to using [Orchestras] instead of [Orchestra] and move your existing field data over to it. Done.

I should note, if you ever do this again, use a semicolon to separate your values, not a comma. MC uses semicolons (that's how those List-Type fields work, they're just strings that are semicolon delimited).  So, if you had used semicolons instead of commas, you could just make your [Orchestras] field, and then use Library Tools > Move and Copy Fields tool to move the data over to it, and you'd be done.

As it is, even if they do make [Orchestra] into a list-type field, you're going to have to change all those commas into semicolons.

[Ferdi]

ha - was playing aroudn with that while you answered!
The obvious thing for me to do is, like you say, create a new orchestra field, and define that as list style - that's what I wanted in my original post anyway. Done.

I too use panes, and creating this field immediately showed my more 'outliers', or tags, to fix, as you said. Now wondering if I should call the Italien orchestras by their Italien name, English or German (many recordings). Requires research (correct names).
 
few more thoughts:
1) Since you mentioned it, and since I have created my own (list style) tag now, I am wondering if I should use an additional field 'choir'. Will consider it. Makes the list smaller, but adds a field.
2) I now somehow think about seperating the 'vocalists' from the 'instrumentalists' - in 'soloists'. Totally different ball of game, I am sure your wife would agree   And man have I got a long list of Opera singers! Never really listen much to opera anyway.
3) I'll need a huge monitor only for classical music / pane view, with all the meta data I collect in different columns. My 30" HP is already too small for what I have now
4) coma or slash or semicolon: no problem at all. The find/replace function in library tools quickly turns anytying you want into a semicolon, and thus creates new, individual values for the field.
5) Still, I want music to be my primary hobby, not MC. So I listened to Dovaraks Symphonie No 9 while playing around. Haven't heard it for years, quite enjoyed it along with a single malt

[glynor]

2) I now somehow think about seperating the 'vocalists' from the 'instrumentalists' - in 'soloists'. Totally different ball of game, I am sure your wife would agree  And man have I got a long list of Opera singers! Never really listen much to opera anyway.
3) I'll need a huge monitor only for classical music / pane view, with all the meta data I collect in different columns. My 30" HP is already too small for what I have now

Yeah. Excessive "specialization" has its cost. It is a balancing act. I usually base it on the frequency of "outliers", but also usage. If I'm going to search for the same things "at once", they should be in one field.

So, just sticking with [Orchestras] is a perfectly good tactic, if that system works best for you.

4) coma or slash or semicolon: no problem at all. The find/replace function in library tools quickly turns anytying you want into a semicolon, and thus creates new, individual values for the field.

Right. As long as none of the actual tag data actually contains the character you need to replace, you're good with that. I imagine that's part of why they use semicolons.  They're relatively rare, and not likely to be used in a "name or title" kind of context.

5) Still, I want music to be my primary hobby, not MC. So I listened to Dovaraks Symphonie No 9 while playing around. Haven't heard it for years, quite enjoyed it along with a single malt

Sounds splendid.

[Vincent Kars]

Nothing wrong with creating custom tags as long as you use media players supporting them.
The moment you sync to a portable or use streaming (DLNA) you most of the time can’t access your custom tags.

I solved it this way:
Artist supports multiple values
I add all the performers post fixed with their role  like

Scholl, Andreas [Countertenor]; Bonney, Barbara [Soprano]; Rousset, Christophe [Conductor];

Bit of a job but the MusiChi tagger I use, knows the performers+roles most of the time.
As it is the Artist tag, this tag is supported almost universal so no problems using it on any other device.

[MusicHawk]

My version, evolved over many years:

I require many more multi-value fields than not. Where a MC standard field is not list-type, or it will be the displayed info while playing so I want it to be user-friendly, I use custom fields. Mostly I use list-type fields for the multiple values I want to organize by. I use the standard fields for the displayed info.

For example, if Artist contains "The Philadelphia Orchestra, Eugene Ormandy, Conductor", which is exactly what the album cover says, my custom Artists field contains two values, "Philadelphia Orchesta;Ormandy, Eugene". (Goofy Columbia Records has been inconsistent in stating the artist; a different album says "Eugene Ormandy Conducts The Philadelphia Orchestra" so that is in my Artist field for that album, but the Artists field is the same as the first example.

(My 80,000 track library is a massive mix of every genre of music, so I don't use fields that would be only for a particular type. I can isolate types of music in Smartlists via Genre or more usefully, Keywords. Not the only method, but works for me. I use many custom fields for special purposes, almost always list-type)

[sjgromet]

hello; in the Tags list, I am having trouble getting any entry into the "Soloists" field to save, even if i do a simple "test soloist" entry; I do not have any problems saving to any other fields; anyone else experience this problem?

If I can't figure out how to fix this issue, can I create a custom field (such as "Performers") that is a string field to serve as an alternative?

This is primarily for my classical music collection. thanks.

[Ferdi]

I am using the 'soloist' field a lot, works just fine.
Glynor's suggestion would work, in other words yes you can add a customer field of type 'list' and call it 'Performers'. But since the 'soloist' field seems to work for most, you might try to get this working for you first.