More > JRiver Media Center 27 for Windows
Feature Request: Better Support for Classical Music
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:
--- Quote from: wer on March 09, 2021, 11:01:11 pm ---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
--- End quote ---
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: ---=regex([Name],/#(.+(?=: )): (\d+). (.+)#/,1,0)
--- End code ---
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:
--- Quote from: wer on March 09, 2021, 11:01:11 pm ---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
--- End quote ---
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: ---Bagatelles (6) for piano, Op. 126: I. Andante con moto (G major)
--- End code ---
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.
--- Quote from: DJLegba on March 11, 2021, 09:18:40 pm ---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.
--- End quote ---
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:
--- Quote from: wer on March 11, 2021, 07:40:58 pm ---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.
--- End quote ---
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. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version