Print

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

[wer]

MC is an outstanding music player and organizer, with unsurpassed audio quality.  These qualities make it attractive to people who like classical music.

However, MC's support for classical music is not what it should be. Something is missing, and it makes managing Classical music in MC more of a pain than it should be.

To be able to properly support Classical music, MC needs to be able to support the Composition. I'll digress for a moment into an explanation of why, for those who don't know what I'm on about...

This request is not about tagging classical music. There are as many ways to tag classical music as there are collectors of it, and MC is infinitely flexible in how it allows you to tag and organize your music.  This is about handling that music effectively and efficiently, in a way that's appropriate for the special nature of Classical music, to better facilitate the activities of tagging and playback, and this is where MC has a deficiency.

The issue stems from the fact that Classical music is unlike other forms of music in terms of structure.  For most other forms of recorded music (Rock, Jass, Pop, Country, etc) the fundamental unit is the Track.  Tracks are grouped together into Albums, but generally each Track is atomic: it is a work unto itself and indivisible. Each song on a Rock album is a Track, and each Track is a File. 

But Classical music is different.  The fundamental unit is the Composition. Each Composition is composed of Movements... But we don't listen to Movements. You wouldn't ordinarily pick just the 3rd movement of a piano concerto to listen to; you'd listen to the full concerto.  But when the music is recorded, each Movement is broken out into its own track, and multiple tracks are required to have a complete Composition.  This is how Classical is different.  For other genres, the fundamental unit is one track, but for classical it is a set of several tracks.

And for MC, the fundamental unit is a File.  MC recognizes Files (tracks) and it (sort of) recognizes Albums, but there's nothing in between. A Classical album might have 6 Compositions on it, but 24 tracks. MC just can't handle this properly.

What MC needs is to be able to recognize the Composition as a unit, and be able to handle it like it handles tracks and albums.

So I'm proposing that MC be enhanced to support Compositions.  I think that means the following:

1. The ability to treat a Composition as a unit.


2. Recognize the user-defined Composition field.  All tracks on the same album that have a common Composition field shall be considered part of the same Composition.
2. The ability to automatically recognize the Composition from the track names. I have described this formula before:
[Name]=[Composition]:[Movement]
The [Movement Number] is in dotted notation at the start of [Movement]
So for:
[Name]=Symphony No. 3 in A Minor: 1. Allegro

You get:
[Composition]=Symphony No. 3 in A Minor
[Movement]=1. Allegro
[Movement Number]=1

Movement info is extraneous and not required for Composition support.
Possibility for automatic parsing of Composition has been removed, since people could not agree on a standard.


3. Composition support in Playlists and Smartlists

4. In Views file list (bottom pane) and playlists/smartlists, be able to expand/contract Composition as with Stacks

5. Compositions can have ratings, and composition stats (rating, duration, etc) are accessible from the search language like with tracks, to support "Files to include" in views and lists.

6. Compositions can have relational fields, like an Album can.


With these enhancements, someone could add a composition to a playlist with a single click.  If you rated the tracks that comprised a Composition, the composition would inherit a rating. Someone could make a smartlist that included compositions with a given rating.  If you wanted to play a Composition, you'd know what the total duration was without having to add it up yourself. You'd be able to tag the Conductor or Orchestra for a Composition as a relational field, instead of being able to do it for each track.  You could enter liner notes for the composition once, instead of for each track. Etc.

It would just make everything better for Classical music.

Some of these things can be achieved now, but doing so requires sophisticated knowledge of the expression and search languages.

I suggest it all be made easier by building in better support.  Attracting Classical music lovers is good for JRiver.

[creal]

Yes, I highly support improvements for organising Classical Music too. I have 14k+ Classical files but the way I structure them and display them in MC is not ideal at all. However, I can't think of using another audio software, it's excellent.

[EnglishTiger]

+1

I have always been a Classical Music Fan but for years, out of personal preference, my classical music collection remained in that ancient 12" 33rpm Vinyl Disc Format. Far too often Media Player Authors/Creators forget that the vast majority of Classical Music pre-dates so-called Popular Music and don't provide the level of flexibility to handle it adequately. Let's take just one example of that "lack of attention to detail" that exists in the MC Tag Window - the location of Classical Music related Tags; in the Tag Window there is a section called "Classical" even though most of the tags displayed are common to both Classical and Popular Music, but the 3 tags that are, potentially, unique to Classical Music:- [Movement], [Movement Count] and [Movement #] are further down the Tag Window in the "Advanced" section.
Yes, I know we can customize the Tag Window but a far better approach would be to allow the user to specify which "section" of the tag window a tag they are adding should appear in.

This isn't the only area that needs cleaning up - another is the routine used to determine if an Album is complete or not - https://yabb.jriver.com/interact/index.php/topic,128021.msg889866.html#msg889866

The ability to check that an Album is Complete appears to be unique to MC , but a routine that gets it wrong is not a very good selling point. It certainly gets me wondering just how many more places is MC providing me with wrong/bad info.

Wer is quite right when he said "However, MC's support for classical music is not what it should be. Something is missing, and it makes managing Classical music in MC more of a pain than it should be."

For years I'd been looking for a way to move my Classical Music Collection into MC but didn't like any of the suggested/recommended ways of classifying that collection I found in the wiki/forums, until one day I found a posting by wer outlining a tagging method, that I christened "The Grey Squirrel Tagging Protocol", that seemed more logical and involved a darn sight less work than any other suggestion/recommendation I'd previously seen.
Once I got used to that Tagging Method I discovered I could use it in a way that shortened the file and path names and that some of the additional tags especially [Date (Performance or Orig Recorded)] and  [Recorded At] could be used with Popular Music.

Once I'd read that posting and asked wer to explain how and where to use the additional tags his method used just under 15,000 Classical Music  tracks got added to MC in under 3 months. It may take me ages to properly tag all of them, mainly because a lot of the wrong/inadequate/bad metadata is being added at the ripping the CD to Disc stage; but I don't care about that as long as there enough metadata present to know what is currently playing, being able to listen to the music I like/love is far more important than making sure the metadata is 100% correct.


Another area where MC's support for classical music is not what it should be is TrackInfo Plugins. I've found threads/posts about Tagging Classical Music going back to 2008 but MC has never had a TrackInfo Plugin tailored for Classical Music. That gap is about be filled because, thanks to Matt and wer's help,  MC is about to gain it's 1st set of Classical TrackInfo Plugins. Plugins that, thanks to a revolutionary new TrackInfo Template that Matt made possible, will tell the User more about the Track they are listening to and the Album that track is from than any previous TrackInfo Plugin.

This set of images will give you an idea of what I'm talking about - https://pix01.jriver.com/gallery/F9555BD5-69F7-4CF4-AE7C-C7452A4346FA/ET_Darkness_TrackInfo/
Images 5-7 are for the 3 web-pages that make up the Classical TrackInfo Plugin used with the Modern Cards Dark Edition Skin.

And Yes the "Tags Page" shown in Images 3 & 7 is the plugins doing a very good impersonation of the MC Tag Window, in a more readable way (the user gets to see all the content of every "Audio" related tag). Probably another area that needs cleaning up,

Hopefully once they are available for Downloading from within MC, just like me, Classical Music Fans will find it easier to correct any missing/wrong tag metadata.


Hopefully the MC Management/Development Team will both Read this thread, Absorb the comments and suggestions and Act On Them  so that JRiver Media Center becomes the Media Player of Choice for most Classical Music Fans. Not next year or in the next decade but before somebody else decides to create a Media Player that is Classical Music Fan Friendly.

[drmimosa]

I accomplished grouping compositions in a playlist using track links. I linked tracks 1-5 in a five movement work, and when track 5 appears in a smart list the composition appears as a unit.

I like it, but it took me a while to do across my library. I started with the composer I had the most tracks for, Bach, and went down the list in a custom view. Now I have the 20 most common composers in my library, 80% of my collection, grouped by composition.

Once you do this, smartlists start to resemble actual concert programs.

Posting here in case someone else finds this a useful idea.

[Cinelder]

"...
"...2. The ability to automatically recognize the Composition from the track names. I have described this formula before:
[Name]=[Composition]:[Movement]..."
... "

Love the idea.  Would it be user-customizable? 

For example, I include the composer before the composition (including opus) and use Roman numerals instead of Arabic for movement numbers, so, if I were naming the first movement of Mendelssohn Symphony No. 3, it would be "Mendelssohn: Symphony No. 3 in A Minor, Op.56: I. Andante con moto — Allegro un poco agitato"

[newsposter]

after pulling in nearly 200 classical music CDs the past couple of weeks, I too would like to see enhanced support for cataloging classical music, in particular the complex notation used by prolific symphony composers......

[JimH]

If you can agree on 3 or 4 simple changes that might help, and there are no significant objections, we will make them.

Please write it up in a brief statement of less than 100 words, and work on it until there is agreement.

I suggest you elect a chair first, and at some point, get buy-in from users on other forums.

[wer]

If you can agree on 3 or 4 simple changes that might help, and there are no significant objections, we will make them.

Thanks, but the enhancements needed aren't "simple".  You can't always make significant advancements just by doing simple easy things.

[RoderickGI]

I'm not a big collector of Classical music, but I have to agree that some improvement in native support for Classical would be very good. A documented standardised approach that everyone could use as a starting point for their library, which may become the default for most users, would be brilliant.

A kludge using simple tweaks would fail to gain support. Classical needs a logical approach.

The suggestions seem like a good starting point. Gain consensus and push for the improvements Will.

[JimH]

Thanks, but the enhancements needed aren't "simple". 

OK.  You're the chair.  Do your best.

[hoyt]

I agree with the general synopsis.  I'm not a huge collector of classical music, but my father is.  He has struggled with tagging and playback within MC and when I watch him use it, it is not the easiest or smoothest user experience.  I currently have his library hosted in a VM on my network, so would be happy to walk through some of these items to understand them better. 

As I read your suggestions, two jump out to me that may fall into the "simple" category. 

1) I think I understand that you're asking for tracks which are in the same Album + Composition to be played together as if they were linked tracks.  This makes sense to me and saves you having to go update all of those thousands of items to be linked tracks like drmimosa did. 

2) I also agree with the point about pre-creating the Custom Tag section for Classical.  Maybe as an avid collector you would know to go add those fields and edit the metadata, but as a casual MC user, you would not know to do that.  Presenting it to the user up front makes sense to me.

Some of the others may be more difficult, but seem like a good start.

Recognizing compositions from track names seems like something you could do with an import rule, or a custom column update.  Not user friendly, but possible.  I've done that with my Live Music collection.  I read the files for various items (date performed, microphones used, type - flac, flac24, shn, etc) with a series of regex statements.  If this could be done automatically for classical, that would be great, but the classical metadata and track names that I've seen require some form of user interpretation to properly update.

I do like the idea of making the Composition a relational level field, like Album, Aritst, Series, etc.  More relational fields in general would be helpful - I used the Series and Season fields for the date performed metadata when doing my Live Music items so that I could store certain things at that level, like cover art instead of embedding it into thousands of files.

[BillT]

I think the idea of having a tag property which links files is a good one, although maybe it could be a property that could be added to any custom tags (my Composition tag is called Work and with 32,000 classical files it won't be changed).

However I don't see any realistic way of automating this - the naming is so wildly variable.

I started using JRiver to tag my music rips in 2003. There were no classical related tags then so I had to create my own; online databases had almost no information about classical music either so it was DIY tagging or nothing.

There was also the issue of displaying the data. As remote players only display a small subset of the tags (the only reliable one is name and it's usually truncated), my naming convention has varied dramatically in an effort to get a comprehensible name to display, so sometimes it has the composer, but maybe not, sometimes it has the work, but maybe not, etc. Of course all the information is in the database, but it's in separate tags, but, owing to the non-configurability of the remote players display it's mostly useless for playing information purposes. In my experience the online databases are just as much of a mess, although I haven't had to rip any classical music recently so they may have miraculously improved.

[hoyt]

There was also the issue of displaying the data. As remote players only display a small subset of the tags (the only reliable one is name and it's usually truncated), my naming convention has varied dramatically in an effort to get a comprehensible name to display, so sometimes it has the composer, but maybe not, sometimes it has the work, but maybe not, etc. Of course all the information is in the database, but it's in separate tags, but, owing to the non-configurability of the remote players display it's mostly useless for playing information purposes. In my experience the online databases are just as much of a mess, although I haven't had to rip any classical music recently so they may have miraculously improved.

This is a very valid point.  As a audiophile playing classical music, you will likely be sitting in front of your stereo using JRemote2, Panel, or Gizmo.  So in order to accomplish the larger request of "better support", it seems necessary to consider updating the fields and displays within all of the JRiver consumers.

[wer]

my Composition tag is called Work and with 32,000 classical files it won't be changed

I'll point out that copying the contents of [Work] to [Composition] can be done in 1 step. It's the work of a moment, whether it's 32 files or 32,000.

However I don't see any realistic way of automating this - the naming is so wildly variable.

Only if you make it so.  I have automated it.

You have to use, and rigorously enforce, a structured naming system.  Information is parsed automatically for my files, because I have done so. I've done tutorials about this before, and I was recently asked for an update so there will be another soon.  But indeed, if you don't, and refuse to, use systematized naming, then your situation is beyond all hope.   Systematized naming is essential.

But the fact that some people have not used systematized naming in the past, and might not want to do so, is not a valid reason for denying the entire rest of the user base the opportunity to benefit from the improvements that can be achieved.

So in order to accomplish the larger request of "better support", it seems necessary to consider updating the fields and displays within all of the JRiver consumers.

There are two kinds of consumers: the handful written by JRiver, and all the other devices in the world, that just use file tags. Every other device will just use the [Name] tag and is beyond the scope of any improvement.

For JRiver-written apps, like Gizmo or JRemote, they currently display [Name], and I think it's wise to leave changes to that for the future. We need to focus on the JRiver app first.

Because the simple fact of the matter is if we ask for too much, we'll get nothing.

The top priority has to be decent standardized support in the main app. Which we do not currently have.  Without that, improvements to other apps don't matter.  So those changes can trickle out later.

[BillT]

I'll point out that copying the contents of [Work] to [Composition] can be done in 1 step. It's the work of a moment, whether it's 32 files or 32,000.

Yes, point taken.

You have to use, and rigorously enforce, a structured naming system.  Information is parsed automatically for my files, because I have done so.

Yes, that's fine for you, but the point of an automated system to make life easier for newcomers is that they will be using automated data scrapers using data from inconsistent sources. Where is this rigorously enforced structured publicly accessible data? It would be nice if it existed, but I'm not convinced. If everyone has to do their own, rigorously structured, tagging then not much work is saved.

Edit:
You just have to look at the issues that people have with TV and Video data, which is much better collated and more widely used than classical music.

You're idea would be great if it works, but I'm doubtful.

[wer]

Bill, if you don't think a solution like this is for you, or if you don't want to have to do any work at all to take advantage of automation, then just don't participate.  You'll be able to ignore and continue living without any improvements.

But as the saying goes "There's no such thing as a free lunch."

People get their tag information from lots of different databases, inconsistent sources, the data in which has been input by other users, or they make them up themselves.  And so those tags may be messy and all over the place.  That's the real world.

It's also the real world that software doesn't work by telepathy.  Systematized naming is what makes it feasible for JRiver to deliver a bit of automation, so that further work is saved.  If your standard for acceptance is "It must be fully AI, and figure out the correct info no matter what so that I never need to do any work" then just forget it. 

I get my metadata from the same sources as everyone else.  When I rip CDs, I use the expression language to adjust the metadata into a standardized format. Many other people do the same. And they go back to systematize tags they created before they adopted a system.  When you rip a disc, do you just accept whatever metadata you retrieve from the internet regardless, or do you clean it up?  I clean it up. If anyone wants it to be consistent, they clean it up. People who are too lazy to clean up their tags have sloppy tags.  So the work of ensuring their tags adhere to some structure is going to be on the user.  That's just the real world.

If you don't want to put in the work to systematize your tags, don't. No one's forcing you.

You keep saying you doubt it can be done, but there is no debate if automation can be achieved, because I have done it, as have others. The earth is round. Google my other tutorial. Or look at my example above.  It is very common usage, even in the sloppy databases we all have access to, that a colon is used to separate the composition part of the track name from the movement part. If there's no colon there, it's pretty easy to add.  Do that and boom, you can automate composition and movement. It doesn't take a lot of complex structure to yield results, it just takes some.

One of the goals is to introduce a bit of built-in automation that will prevent some work. Not ALL work, because that is not possible.  Some work.  And some work is still going to have to be done by the user, if they are willing. If they are not, too bad.  A lot of people spend a lot of time tagging their classical music well, so ANY effort that is saved for them would be welcome. Perfect is the enemy of good, and I'm not interested in getting nothing by demanding perfection.

More importantly, this is about more than just automatically filling in a couple of fields, as I pointed out in my original post.  I hope you can get behind that without throwing cold water on it by asserting it can't be done or won't work; that's counterproductive. Everything that I described in my original post is very achievable.

If you have some concrete and achievable ideas as to how this can be made easier or better, we'd love to hear them.

[hoyt]

2. The ability to automatically recognize the Composition from the track names. I have described this formula before:
[Name]=[Composition]:[Movement]
The [Movement Number] is in dotted notation at the start of [Movement]
So for:
[Name]=Symphony No. 3 in A Minor: 1. Allegro

You get:
[Composition]=Symphony No. 3 in A Minor
[Movement]=1. Allegro
[Movement Number]=1

I messed around with this a bit today, if your initial name field is that clean, you could achieve this with a bit of Regex:

Code: [Select]

=regex([Name],/#(.+(?=: )): (\d+). (.+)#/,1,0)
Group 1 would be your Composition, 2 is Movement, and 3 is Movement Number (I striped the "1." out of the movement).  If you have a whole host of items tagged properly, you could pretty easily apply this to create/ update the other fields.  In many cases, the movement appears to be Roman numerals in my metadata though, and in some there are no movement numbers noted ("Concerto for 3 Trumpets and Orchestra in D Major: Allegro Moderato").  I'm sure that can all be worked out, but I'm by no means a regex pro.

[wer]

Yes, that's one way to do it. It can also be done without regex. I've shown people how to do those things before, and another tutorial will be coming.  But here in this thread, we don't need to establish the mechanism for parsing. JRiver can do it however they want, using methods that have already been demonstrated or something new.

What we have to establish here is the pattern they need to parse, if there's going to be one.

Keep in mind, automatic parsing is only one part of this. But that said...

The way I see it, one of three things can be done in terms of automatic parsing:

1. MC can have a standard parsing. This will be built in, and turnkey. The user will not need to know how to do anything. Just make your [Name] fields comport with the standard, and it will work.

2. MC can implement customizable parsing. Take the default, or set your own preferences in the UI.

3. MC can implement no parsing at all, but provide special significance to the [Composition] field.


These each have pros and cons:

1. Easiest for users to leverage, in terms of knowledge required. Easy easy for JRiver to implement.  But users must ensure their [Name] fields comply with the standard.

2. Flexibility for users: They can take the easy way and accept the default system, but it also allows users to adapt the parsing to their personal naming system. Much harder for JRiver to implement. There will have to be options and user interface elements to allow the configuration.

3. Easiest for JRiver to implement, but hardest on the user. MC will recognize the significance of the [Composition] field, but how that field and the others get populated is totally up to the user. If they don't know enough of the expression language to populate it with calculated data, they won't benefit from any automation and will have to enter it manually.  This will push users to ask on the forums for solutions beyond their abilities. "Please give me expressions that will work for my personal naming system." 

Obviously, #3 is essentially what we have now in terms of automation, none unless you do it yourself. But of course now the [Composition] field has no significance in MC either.

If it is to be #3, we need not discuss either the system or the method, since JRiver will implement none of it.

If the approach is to be #1 or #2, we have to establish what the convention will be, but not the parsing mechanics.

And again, everyone needs to keep in mind that automatic parsing is only 1 point out of 7 in the proposal, so we shouldn't focus on that to the exclusion of the rest of it, which is actually more important.  Parsing without the rest, you can have now if you put the expressions in yourself.  The other 6 points are impossible for users to achieve.

The point of the automatic parsing is to make a bit easier for users to enjoy the features provided by the other 6 points. It's those other 6 points that are the real benefit.

[DJLegba]

2. The ability to automatically recognize the Composition from the track names. I have described this formula before:
[Name]=[Composition]:[Movement]
The [Movement Number] is in dotted notation at the start of [Movement]
So for:
[Name]=Symphony No. 3 in A Minor: 1. Allegro

You get:
[Composition]=Symphony No. 3 in A Minor
[Movement]=1. Allegro
[Movement Number]=1

This works well for symphonies, but it doesn't cover everything. You could force fit operas with the opera name, act, and aria name (or scene name), but there's nothing like a Movement in an opera, and there are single-act operas which would not normally use a concept like "Act I". And a collection of Beethoven piano bagatelles really needs an opus number, which again is not a movement.

I ripped a 70-disc set of Bach cantatas, and I just accepted the track names that dbpoweramp found in whatever online database. I have a few different performances of several cantatas, some of which I ripped and some of which I purchased as downloads. In every case I had to do custom tagging, but if I had to manually rename all 1,595 files I would not have bothered. I have 3,336 opera files and the names don't follow any convention. I'm willing to work to make the tags useful, but 3,336 file names is a hill too steep to climb.

I think I ended up with the same solution that BillT uses. I added a "Work" field (I know I should have named it something better as technically a composition and a work can be different). I always have to edit tags whether I rip or download, but selecting some or all tracks and adding the composition name is much easier than editing each track name.

Also, I agree with BillT that adding a lot of information to the name makes almost all control software very difficult to use. I had to abandon JRemote2 because it just can't show a useful name length for most classical music. Fortunately MO 4Media works very well, but loading up the name field will definitely create problems with other software that may or may not ever be addressed.

[wer]

Can you post some [Name] fields for an Opera and whatever other data is necessary to demonstrate what you mean?

But if you feel that "Movement" information is inapplicable to Opera, why are you worried about it? Wouldn't you just ignore the Movement fields for Opera the way you evidently do now?  The Composition field still applies: Don Giovanni

I have the Beethoven bagatelles. You can deal with them one of two obvious ways. You could consider each an individual work, with no movement information (because each is in effect a single movement). But Beethoven indicated they were to be played in order as a single piece, which means each of the 6 parts of Op. 126 is in essence a movement. That's how I have done it.  So I think the system works fine for pieces like that, if one doesn't obsess over the word "movement".  Here's the [Name] for one of them:

Code: [Select]

Bagatelles (6) for piano, Op. 126: I. Andante con moto (G major)
But show me some data/concerns about an Opera and let's try to puzzle it out.

I honestly don't understand your concerns about filenames, or why you're talking about it as an obstacle.  Nothing in what I am talking about depends on the filename in any way. We're talking about the [Name] field, which is a tag.  And even if you did need to rename your 1595 files, why in the world would you think about doing it manually? That's why MC has RMCF, so that files can be automatically renamed based on tags.  So we're talking about tags only. Filenames are a non-issue.

I always have to edit tags whether I rip or download, but selecting some or all tracks and adding the composition name is much easier than editing each track name.

Not by much. If you have already typed in the Composition name, then F2 on [Name] and:
=[Composition]: [Name]
Just adds the Composition to it, if you want to do that.

And if you don't want to update your tags, there's nothing wrong with that. These improvements that benefit others will do you no harm.

It's perhaps also worth mentioning again, if it wasn't clear already, that if we focus on the issue of the scope of the automation, as described earlier:

The way I see it, one of three things can be done in terms of automatic parsing:

1. MC can have a standard parsing. This will be built in, and turnkey. The user will not need to know how to do anything. Just make your [Name] fields comport with the standard, and it will work.

2. MC can implement customizable parsing. Take the default, or set your own preferences in the UI.

3. MC can implement no parsing at all, but provide special significance to the [Composition] field.

Then in cases 2 and 3, even the [Name] field can be irrelevant, because you can do whatever you want, with whatever fields you want.

I think we need to focus on that question.

If would be good if it was able to handle as much as possible, but again, perfect is the enemy of good.  Would you rather have some or nothing? 

I'd rather have better support for some, than nothing. 

[tij]

https://sfopera.com/contentassets/4b94c3eaecdb46a8af825f4d889b3e1a/how_operas_work.pdf

Opera are divided into Acts and those are divided into Scenes

Here is Carmen https://www.naxos.com/education/opera_libretti.asp?char=ALL&composer=Bizet&opera=Carmen&libretto_file=00_Synopsis.htm

Then there are Arias (a self contained musical piece) that are part of Scene ... like famous Habanera from Scene 5 of the First act from Carmen

... some ppl might collect whole operas (some might even do it in Video format) ... while others will just collect Arias (with some prefer to properly label them ... while for some "Toreador Song" is sufficient)

... then there is Ballet ... i think also with Acrs and Scenes ... here is Swan Lake https://www.classiccat.net/tchaikovsky_pi/20a.info.php

... there are probably variations and exceptions ... but thats beyond my knowledge atm

[wer]

Yeah, I know operas have acts and scenes.  I think everyone does.

I was interested in seeing the syntax he was actually using in his Name field.

[tij]

Yeah, I know operas have acts and scenes.  I think everyone does.

I was interested in seeing the syntax he was actually using in his Name field.

My bad ... misunderstood your previous post

[tij]

Maybe reuse TV Series structure then?

Series = Composer
Season = Compostion
Episode = Movement

?

[DJLegba]

I honestly don't understand your concerns about filenames, or why you're talking about it as an obstacle.  Nothing in what I am talking about depends on the filename in any way. We're talking about the [Name] field, which is a tag.  And even if you did need to rename your 1595 files, why in the world would you think about doing it manually? That's why MC has RMCF, so that files can be automatically renamed based on tags.  So we're talking about tags only. Filenames are a non-issue.

Yes, sorry, I meant the [Name] field, not filenames.

Not by much. If you have already typed in the Composition name, then F2 on [Name] and:
=[Composition]: [Name]
Just adds the Composition to it, if you want to do that.

Sometimes [Name] already includes the composition. Sometimes it's in English, but not always.

But show me some data/concerns about an Opera and let's try to puzzle it out.

Here are the names of the first three tracks from a rip of a Maria Callas 1955 recording of La Trviata, as acquired by dpba during the rip:
Preludio
Act 1 - Dell' Invito Trascorsa É Già L'Ora (Coro, Violetta, Flora, Marchese, Gastone, Alfredo)
Act 1 - Libiamo Ne' Lieti Calici (Alfredo)

Here are the same tracks from a 2005 recording with Anna Netrebko (again, as acquired by dbpa):
Prelude (Act 1)
Dell'invito Trascorsa É Già L'Ora (Act 1)
Libiamo Ne'lieti Calici Brindisi (Act 1)

Here's how the Canadian Opera Company identifies the Libiamo aria on their "sampler":
Brindisi: Libiamo, Act 1 - La Traviata


Here are a few randomly selected [Name] values from some of the Bach cantatas:

O Thou Lovely Wiederau - Coro Bwv 30a
Bwv 1046a No.01: Recitativo - Was Mir Behagt, Ist Nur Die Muntre Jagd!
Recitativo (T)
Bwv 007, Cantata 7, 7. Chorale
Coro: Ach Gott, Vom Himmel Sich Darein Bwv 2

How would you deal with something like La Poesia Cromatica by Michelangelo Rossi? There's nothing equivalent to a movement or opus or act.

Jim asked for a few simple things. A [Composition] tag in the Classical group, a canned Composer/Composition view, and the ability to treat compositions like albums would have done it for me. I set those up myself, but only after having used MC for several years.

[wer]

Thanks for the detail.

For the examples you gave, you're never going to get anywhere because they're completely unstructured. As I said earlier, people with totally unstructured data can't be automated.

If you have Act and Scene data in other tags, it's easy to reformat the name with an expression.

If you get to something like this:
La Traviata: Act 1 Scene 1. Libiamo Ne' Lieti Calici (Alfredo)

Then you have something sufficiently structured that it can be automated.

How would you deal with something like La Poesia Cromatica by Michelangelo Rossi? There's nothing equivalent to a movement or opus or act.

What's your goal in asking this question?  Is it to prove you can think of pieces of music that don't have any traditional or recognized structure?  There are lots of those. Who cares.  My answer is: I don't have to deal with it.  I have zero interest in, and this thread is not about, imposing structure on music, or tags, that won't support it.  That piece probably won't get movement information. A lot of pieces won't get movement information. Who cares?

I never said we could do 100% of everything for everyone. We're trying to do something that will provide benefit to many people who have classical music collections.  This does nothing for people who collect jazz - is that a reason to not do it?

Like I said before, we shouldn't be trying to cure world hunger here.  So the fact that there's no solution for totally unstructured data isn't important.

[wer]

So let's set aside the minutia of the mechanics of automatic parsing, and look at the bigger picture.  We need to refocus this discussion.

So to reiterate from before:

Keep in mind, automatic parsing is only one part of this. But that said...

The way I see it, one of three things can be done in terms of automatic parsing:

1. MC can have a standard parsing. This will be built in, and turnkey. The user will not need to know how to do anything. Just make your [Name] fields comport with the standard, and it will work.

2. MC can implement customizable parsing. Take the default, or set your own preferences in the UI.

3. MC can implement no parsing at all, but provide special significance to the [Composition] field.


These each have pros and cons:

1. Easiest for users to leverage, in terms of knowledge required. Easy easy for JRiver to implement.  But users must ensure their [Name] fields comply with the standard.

2. Flexibility for users: They can take the easy way and accept the default system, but it also allows users to adapt the parsing to their personal naming system. Much harder for JRiver to implement. There will have to be options and user interface elements to allow the configuration.

3. Easiest for JRiver to implement, but hardest on the user. MC will recognize the significance of the [Composition] field, but how that field and the others get populated is totally up to the user. If they don't know enough of the expression language to populate it with calculated data, they won't benefit from any automation and will have to enter it manually.  This will push users to ask on the forums for solutions beyond their abilities. "Please give me expressions that will work for my personal naming system."

Obviously, #3 is essentially what we have now in terms of automation, none unless you do it yourself. But of course now the [Composition] field has no significance in MC either.

If it is to be #3, we need not discuss either the system or the method, since JRiver will implement none of it.

If the approach is to be #1 or #2, we have to establish what the convention will be, but not the parsing mechanics.

If it can get people to stop arguing about their data and focus on the goal, I'm totally willing to just drop automated parsing and go with #3, which eliminates everyone's concerns.  Except of course, the concerns of those people who don't know how to do it themselves in the expression language... They'll suffer under #3.  Maybe more advanced users don't care.

But there only needs to be a discussion about syntax or structure if #1 or #2 are chosen.

So which of these three approaches should be adopted? Or if anyone has an additional approach not listed, please chime in with it.

[EnglishTiger]

The act of achieving good consistent tagging doesn't start with MC or the software used to rip the discs, they are simply the tools you use to get your music onto your PC in a format your Media Player of choice understands.

The first action should always be to decide what information (metadata) you want/need to know to be able to recognize/name what you are listening to. Next you look to see what tools are around to help you acquire that information, armed with the knowledge that a lot of "scrapeable metadata web-sites" do not present information in the same consistent format and a lot of it can be wrong.

Next you switch on the most, allegedly, powerful computer in the world "Your Brain" and use readily available data sources, the CD Track List, Insert, Booklet etc, to work out a set of rules that can help you achieve your goal using the least amount of time/energy.
Next you look to see what tags/fields are already available for use in MC and their are loads of them, MC have attached an Audio Media designation to that can be redeployed for a purpose other than it's original designation. How many of us have ever seen a Music CD that would use things like the Season and Series tags?

Most of us already know that Symphonies use Movements; Operas, Ballets, Mass's and Oratorio's usually use things like Acts, Scenes and Parts; whilst other Composition Types don't use Movements, Acts, Scenes, Parts or any other designation the composer/publisher has decided to deploy.

My copy of "Pyotr Il'yich Tchaikovsky's The Sleeping Beauty" contains 63 individual tracks all with the relevant Act and Scene designations in their name. The source data for things like Ballet's, Opera's, etc, make it look like  multiple naming rules were being deployed but considered analysis revealed that I didn't need a different set of tags or rules for Opera's, Ballet's or Oratorio's etc, I could use the existing "Movement", "Movement #" and "Movement Count" tags.

How to go about tagging your tracks/albums?
Remember listening to your Music should be more Important than making sure all tags you have decided to use contain the right information/data. Isn't being able to listen to it the reason why you added it to MC in the first place? I actually find that watching what data/tags are being displayed while playing my Classical Music a good way of spotting tracks that do not use the same consistent tagging style I prefer to use and can correct them there and then.

The "Name" is considered to be the most important tag of the lot, especially if you are daft enough to purchase a device that tells you even less about the track/album you are listening to than the amount of visible information on that Bank Debit Card siting in your wallet.
But it should be the last Tag you alter, because if you got your rules/methodology correct it can be constructed from the Information/Data  contained in your other tag.

I don't need to use things like regex instead all I have to do is select which of the 3 following patterns I need to use and paste the relevant one into the "Name" tag at either the Track or Album level:-
=[Composition], [Composer's Catalog #]: [Movement Number]. [Movement]
=[Composition], [Composer's Catalog #]
=[Composition]: [Movement Number]. [Movement]

Unlike it's competitors and "Scrapable Metadata Web-Sites, MC does not impose a rigid set of rules and tags, that even the music companies don't use, on you. With MC we are free to choose how we do things, if you decide to make yourself dependent on scrapeable web-sites to provide your info/data it is you that decided to tie yourself into using an unreliable source of metadata.
I prefer to get my data/info from multiple sources, it may take me longer to achieve my aim but I can guarantee my information will be more "correct" than if I took the "let's just scrape it approach" where I would be letting somebody else decide what is right and what is wrong.
Why scrape something that I'm probably going to have to correct when all I need to do is use my keyboard to ensure what data/info ends up in a tag is correct.

Yes deploying a consistent tagging methodology will involve manual effort, but so does getting dressed, eating food, drinking coffee or using that "smart device" you insist on using.

[EnglishTiger]

Maybe reuse TV Series structure then?

Series = Composer
Season = Compostion
Episode = Movement

?

Why?  MC already provides the Composer and Movement tags, and a more obvious substitute for Composition is the Work tag.

[JimH]

So let's set aside the minutia of the mechanics of automatic parsing, and look at the bigger picture.  We need to refocus this discussion.

So to reiterate from before:

Keep in mind, automatic parsing is only one part of this. But that said...

The way I see it, one of three things can be done in terms of automatic parsing:

1. MC can have a standard parsing. This will be built in, and turnkey. The user will not need to know how to do anything. Just make your [Name] fields comport with the standard, and it will work.

2. MC can implement customizable parsing. Take the default, or set your own preferences in the UI.

3. MC can implement no parsing at all, but provide special significance to the [Composition] field.


...

I may move this and the following to a new thread, so you have a nice clean start.

I appreciate your work on this, wer, Englishtiger, and others.  We won't make changes until there's general agreement.

[EnglishTiger]

wer - my personal preference would be option 1 but with the following modifications:-

I think the linking/parsing should be based on a combination of the "Composition", CompositionType" and "Composer" fields/tags and not the "Name" tag/field.

Based on the simple fact that it is easier/quicker to ensure those 3 fields contain the correct data in the required format using something MC is very good at - Bulk Tagging.

For my 160 CD Haydn Edition Boxset
All I have to do is select all 2557 tracks and then in the Tag Window select the Composer tag and paste "Franz Joseph Haydn" into it.
For the over 100 symphonies he wrote, thankfully post ripping they all had the phrase "Symphon" in the track name, I can set up a smartlist that lists only those tracks select them all and make sure that only the the word "Symphony" is in the "CompositionType" tag. Using that same smartlist I can then select the movements for each symphony to make sure that all have the same content in the "Composition" tag.
That's around 110 edits to get 414 tracks into a state the "Standard Parsing Routines" should be able to handle. Not the countless number of edits I would have to make to get the contents of the "Name" tag to conform to the requirements.
Because MC is able to do it's magic earlier I can then do any further tagging/editing at my leisure, where the risk of getting something wrong is a heck of a lot lower than it would be if I had to get the "Name" tags right before I could get MC to link them.

[whoareyou]

I like WER's idea for this because it somewhat follows Apple's style guide for classical metadata. 
There may be other guides, but Apple's is the only one I've seen.   I understand that keeping this simple is the key, but I believe standardization would also offer additional benefit to users. 

Other than interpreting Apple's standards, which would be tedious, I think their classical format is very similar to what WER is proposing.

If I decided to fix my mess of classical music, I would want it to conform to an existing "standard" as much as possible. 

https://help.apple.com/itc/musicstyleguide/en.lproj/static.html

I also ran across this site
https://www.dailyrindblog.com/classical-music-metadata-101/

[wer]

I think the linking/parsing should be based on a combination of the "Composition", CompositionType" and "Composer" fields/tags and not the "Name" tag/field.

The Composition can't be the source for interpreted data, because it is the destination.

Files that are on the same Album, that have the same Composition field, MC would treat as a single Composition.

The idea behind automatic parsing of a Compositions is to automatically build the Composition field that will be used.

If people won't agree about automatic parsing, then I guess there won't be any. Less knowledgeable users will suffer.

Since the parsing can be done by a knowledgeable user, it is the least important part of the proposal.

[EnglishTiger]

Looks like I mis-interpreted what you were saying,  but that doesn't change my Preference for Option 1. Making sure the only : in the "Name" is between the Composition and Movement is something that can be achieved easily.

I would love to see Option 2 implemented but if too many people ask for changes to what MC are prepared to provide there could come a point where MC say "we are not going to make any more changes".  Or they may decide that providing the sort of flexibility that option would need is more work than they are prepared to do.

To me Option 3 means we end up doing everything manually, which isn't much different from the current situation.

[wer]

To me Option 3 means we end up doing everything manually, which isn't much different from the current situation.

It's exactly like what we have to do now.

Except for the actual support of Compositions in the other 6 points, which is where all the benefit will be.

[newsposter]

Weekend plans here are to rip in another dozen or two classical CDs.  Will chime back in on preferences / suggestions after that fresh experience.

Also doing some research into Apples best practice recommendations as well as anything the multitude of library and professional music associations might have.

The wikipedia article on music cataloging is a pretty good primer on the meaning/usage of catalog notations that are composer specific.

No sense in reinventing the wheel if there is a real/defacto standard or three that could be implemented.

[HaWi]

I am very much in favor of what @wer suggests for [Composition] support.

[hoyt]

The Composition can't be the source for interpreted data, because it is the destination.

Can you explain your workflow with this, or link to your prior discussion?  I searched around a bit, but didn't find something that I thought was step-by-step enough to understand why you would rather go from Name -> Composition, Movement, Movement # vs the other way around.  Or are you saying that when you rip the CD and use YADB, it is automatically formatting the name like you're stating?  I'm going through the classical albums I have now and am finding it much easier to shift+click 6 tracks, note them as Composition = Cello Suite No. 1 in G Major, Catalog Reference = BWV 1007, then go through each one and enter the Movement and Movement #.  Once I'm done with that, I enter the Name as =[Composition]: [Movement Number]. [Movement].  I find that easier to make the name consistent, but you've put more thought and work into this, so I'd like to better understand your reasoning.  Plus my CDs are all already ripped and I don't recall how it named things.

[wer]

Hoyt, I'd be glad to, but I don't want to do it here because it further sidetracks the discussion.

Here are links to tutorials I've done that deal with this subject.  I've responded to your question in the newer one, so let's follow up there if you want.  Thanks...

newer   How to Automatically Parse Composition and Movement info in Classical Music

older   Here's how to get Album Ratings in your views

[wer]

A few days have passed and no one has refocused on the bigger issue, so I have edited the original proposal to remove any automatic parsing to fill out the Composition field.

People could not agree on a standard for automatic parsing for Composition, even when the standard proposed was the simplest, easiest one possible: using a single colon.  People focused on their personal issues with automatic parsing to the exclusion of consideration of all the other points of the proposal. 

When asked to refocus to choose between automatic parsing, customizable parsing, or no parsing at all, people would not focus on that question.

So I have removed automatic filling of the Composition field from my proposal, so that people can try and focus on the remaining benefits of MC recognizing Compositions.

I've also combined points 5 and 6 for clarity since they were closely related.

I feel it's a shame to not be able to provide any automation of this to users, but oh well.  Users who are incapable of writing their own expressions to populate the Composition field will have to fill it out manually, or do without.

That leaves us with this:

So I'm proposing that MC be enhanced to support Compositions.  I think that means the following:

1. The ability to treat a Composition as a unit.

2. Recognize the user-defined Composition field.  All tracks on the same album that have a common Composition field shall be considered part of the same Composition.

3. Composition support in Playlists and Smartlists

4. In Views file list (bottom pane) and playlists/smartlists, be able to expand/contract Composition as with Stacks

5. Compositions can have ratings, and composition stats (rating, duration, etc) are accessible from the search language like with tracks, to support "Files to include" in views and lists.

6. Compositions can have relational fields, like an Album can.

[dtc]

So a composition has properties similar to an album but defined by  [Composition] and [Composer] rather than by [Album] and [Album Artist] , and  you can have more than one composition on an album.  Some tags are unique to the composition and some are shared with the album.  Maybe just create a new full set of tags with a unique identified (e.g. prefaced by comp.  (e.g. comp.date, comp.rating, etc.)) with those tags inherited from the track tag unless overriden by a input value.  Then, pretty much any operation that can be done with [Album] can be done for [Composition].  And automatically link any tracks in a composition by track number.

Or something like that.

[wer]

It couldn't just be Composition and Composer.  Album has to be considered, since you might have different recordings of the same Composition.  How many recordings does one have of Beethoven's 5th?  They all would probably have the same Composer and Composition tags, but they would each be on different Albums.

In terms of other tags, I don't see any tags being shared with the Album. That would be new functionality wouldn't it? I don't think there are any tags share between tracks and Album now, aside from Album-relational tags.  I do see tags at the Composition level being inherited from constituent tracks: date, composer, genre, etc. Maybe that's what you meant, but if not please expand on that.

What are the tags, or properties, a Composition would have to have exposed to the search language? In other words, you'd want to be able to include Compositions in a smartlist based on what properties?

[Ferdi]

I am late to join the discussion.
For some composers, a 'catalog of work', or 'werksverzeichnis' has been created, for example the BWV for Bach. All compositions are assigned a number, number intervals often represent a specific date range for the individual composer. For me, this is a very relevant field, would see this as important part of a design for meta data handling.

[MikeO]

I use Catalog # , I assume it’s designed for the Album Catalog, ie record label number etc

The alternative is to use Opus No, some composers have both, indeed sometimes multiple cataloged eg Chopin, I tend to select one. Opus if it exists or for Mozart, K, Schubert D , Bach BWV etc

It depends how comprehensive you want your naming to be. Personally I just want it to unique and simple.


Works for me

[dtc]

It couldn't just be Composition and Composer.  Album has to be considered, since you might have different recordings of the same Composition.  How many recordings does one have of Beethoven's 5th?  They all would probably have the same Composer and Composition tags, but they would each be on different Albums.

In terms of other tags, I don't see any tags being shared with the Album. That would be new functionality wouldn't it? I don't think there are any tags share between tracks and Album now, aside from Album-relational tags.  I do see tags at the Composition level being inherited from constituent tracks: date, composer, genre, etc. Maybe that's what you meant, but if not please expand on that.

What are the tags, or properties, a Composition would have to have exposed to the search language? In other words, you'd want to be able to include Compositions in a smartlist based on what properties?

Yes, you probably need [Album] or something like that to define the composition. The point was that once you have a definition that uniquely defines a composition, then the rest of the MC functionality should follow pretty easily. Whatever you can do for an album you should then be able to do for a composition. There may be a few special cases, but most everything should work if it is set up correctly.  The idea is to be able to use most of the existing code for a composition, not to define it in such a way as to have to change pretty much all MC functionality.

As to tags, the same basic tags that are used for each track in an album can probably be the same for a  composition.  Things like file size, compression, bitrate, number of channels, last played, even conductor, composer, and a whole lot more do not have to have unique values independent of the track values.  The values can be inherited from the standard track values. Then there are only a few tags that the user has to re-enter.  If all tags could be shared it would make the task even easier. It might make more sense to create a small number of new tags, than trying to maintain two separate sets. The new tags can be blank for tracks that are not part of a composition.

I just wanted to suggestion some structure that would be easy to handle, rather than inventing a completely new one that does not fit easily into the existing code. Hence the comparison to [Album].

[PhDSM]

Here is my contribution to this subject

I've been able to tag most of my Classical library (over 15000 tracks) using existing fields and add a few more  like opus,  composition, composition type, composition #,ToneNote(A..F) , ToneAlteration (Sharp/Flat), ToneType(Maj/Min), ....
You can do a lot from there, however one key missing feature is the one mentionned at the begining of this subject, which is to have the ability to treat composition as relational item like for Album.

Phil

[wer]

It's been several days, so I wanted to make one more check...

Are there any further comments, suggestions, or messages of support or dissent for the latest version of the proposal?

There is no automation included, so all users will have to manually fill the [Composition] field or write their own expressions to do so.


SUPPORT IN MC FOR COMPOSITIONS:

1. The ability to treat a Composition as a unit.

2. Recognize the user-defined Composition field.  All tracks on the same album that have a common Composition field shall be considered part of the same Composition.

3. Composition support in Playlists and Smartlists

4. In Views file list (bottom pane) and playlists/smartlists, be able to expand/contract Composition as with Stacks

5. Compositions can have ratings, and composition stats (rating, duration, etc) are accessible from the search language like with tracks, to support "Files to include" in views and lists.

6. Compositions can have relational fields, like an Album can.

[DJLegba]

Are there any further comments, suggestions, or messages of support or dissent for the latest version of the proposal?

I support this version of the proposal.

[timwtheov]

+1 from me on this proposal as well. I'm also good with any [Composition] automation too, just in case that ever comes back to the table.

[MikeO]

I agree with the above , there is simply too much variation to automate much.