More > JRiver Media Center 27 for Windows
Feature Request: Better Support for Classical Music
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:
--- Quote from: EnglishTiger on March 12, 2021, 05:50:44 am ---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.
--- End quote ---
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:
--- Quote from: EnglishTiger on March 12, 2021, 12:57:13 pm ---To me Option 3 means we end up doing everything manually, which isn't much different from the current situation.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version