More > JRiver Media Center 27 for Windows
Feature Request: Better Support for Classical Music
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.
--- Quote from: DJLegba on March 11, 2021, 11:55:28 pm ---How would you deal with something like La Poesia Cromatica by Michelangelo Rossi? There's nothing equivalent to a movement or opus or act.
--- End quote ---
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:
--- Quote from: tij on March 11, 2021, 11:29:55 pm ---Maybe reuse TV Series structure then?
Series = Composer
Season = Compostion
Episode = Movement
?
--- End quote ---
Why? MC already provides the Composer and Movement tags, and a more obvious substitute for Composition is the Work tag.
JimH:
--- Quote from: wer on March 12, 2021, 01:14:53 am ---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.
...
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version