|
Tagging classical music
|
|
26-03-2014, 14:53
Post: #31
|
|||
|
|||
RE: Tagging classical music
(26-03-2014 09:14)Dieter Stockert Wrote: I spend a lot of work in tagging my classical music collection. At the same time I have to admit that I browse only in Minim server's folder view. Why that? Because I find it much too complicated (and restricted) to make it fit my needs and that's the same with the control apps. And another reason is that we can only tag in a 'flat' way. We have no 'relational' way of tagging, we don't even have some kind of hierarchy. For example you may have an artist playing forte piano as a soloist on one recording and harpsichord on another plus he is director on that one too, and maybe he's only part of an orchestra on another recording. Instead of having one entry if you browse for artist tag you will have him multiple times in the artist list. The same is with genre. There are dozens of genres for rock, pop and so on, but only one for classical music, but we would need sub genres like sonata, oratorio, concerto, symphony, chamber music and much more, plus additional sub-sub genres like horn concerto, sonata for violin and piano, flute trio, string quartet ... Is this where the unachievable best becomes the enemy of the feasible good? Allowing for the fact that we all have different needs and priorities, there must come a point where the elaboration of any dataset we use becomes self defeating. When I started using networked music, I too tended to use mainly the folder view (and, bearing in mind that folder and file names are just another form of metadata, there is nothing peculiar in that). This was because the arrangement of my folders largely followed the arrangement of the actual CDs on their shelves, which I had been using for many years, and so was a familiar point of reference. Subsequently, I changed to using the browse tree. This was a result of a decision to keep metadata entry, and with it the categorisation of data, as simple as possible. So, for example, I only use a few high-level genre values (Classical, Pop, Jazz, Folk), as experimentation indicates that having many genres (or multiple genre tags, which is technically possible) serves only to complicate the browsing process. The genre tag in my usage is mainly useful for excluding entries from the selection, rather than including entries in it. My scheme is built on the recognition that, in selecting classical music to play, we most often use the sequence (which may be implied or explicit) Genre -> Composer -> Work -> Performance. (It seems to me to be no accident that reference books of CD reviews are typically arranged in this sequence.) However, for recitals and the like we are more likely to use the sequence which is typical for genres other than classical, that is Artist -> Album. For me, it makes sense to optimise (and where appropriate simplify) metadata entry to fit with these sequences. I have tended to concentrate on ensuring that, in addition to reasonably complete Album, Track title and Artist enties, there are also entries for Composer, ComposerSort, Composition and (where needed) Group. Another limiting factor is that there is little or no point in entering metadata which is neither used in the browsing sequence nor displayed in the control point. Do I for instance need separate Artist entries for all 16 vocal soloists in Vaughan Williams' Serenade to Music? Probably not. While others may feel differently in a particular case, the need to avoid self-defeating elaboration is common to all. The same point applies when we look at database structure. I think it is sometimes helpful to consider the set of music files as a database, but it is clear that, in its native form, it is a single 'flat' table and cannot be in any way relational. The MinimServer browsing sequence works to some degree like a sequence of SQL queries of this table, where the result set from one query is in turn queried further to refine the selection. This approach seems to me to be both elegant and easy to understand. Rather than trying to make the data in any way relational, I would like to see a progressive development of UPnP Search. This is more a control point than a server issue (Simon's stated policy on UPnP Search in MinimServer is to support available control point capabilities), but it would be good if search capabilities could be extended to cover a wider range of tags and also to allow searching within the current selection. If searches could include Boolean AND, OR and NOT statements, that would be even better. The question of duplications in lists is, in my perception, less a function of any lack of 'relationality' that a matter of how the control point seeks data from the server; this thread provides some interesting insights into the issue. All in all, therefore, I acknowledge the concerns expressed by Dieter, but would suggest that we should still encourage new users to enter metadata systematically and, having done so, put the data to use via the MinimServer browse tree to improve the quality of their network music experience. David |
|||
|
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)

Search
Member List
Calendar
Help



