More > JRiver Media Center 27 for Windows
Feature Request: Better Support for Classical Music
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:
--- Quote from: BillT on March 11, 2021, 12:36:10 pm ---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.
--- End quote ---
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:
--- Quote from: BillT on March 11, 2021, 12:36:10 pm ---my Composition tag is called Work and with 32,000 classical files it won't be changed
--- End quote ---
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.
--- Quote from: BillT on March 11, 2021, 12:36:10 pm ---However I don't see any realistic way of automating this - the naming is so wildly variable.
--- End quote ---
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.
--- Quote from: hoyt on March 11, 2021, 12:47:57 pm ---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.
--- End quote ---
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:
--- Quote from: wer on March 11, 2021, 01:29:55 pm ---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.
--- End quote ---
Yes, point taken.
--- Quote from: wer on March 11, 2021, 01:29:55 pm ---You have to use, and rigorously enforce, a structured naming system. Information is parsed automatically for my files, because I have done so.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version