>> Whenever I come across something I'm not sure how to categorise, I ask myself the questions -
"What was the creator setting out to do when they made this?" and
"What is the primary focus of this media?"
Interesting comment which illustrates two fundamentally different ways to categorize (and two ways to spell categorise
).
Because I'm a radio station programmer, my focus is on MY use of the music track to serve MY audience, not to serve the original purpose, whatever it might be. Therefore, my categorization MUST have values that identify in the music in ways that let me organize and retrieve it later -- including ways I might not need or envision right now.
I have a few fields that store the original facts of the song/composer/artist/track/album, because if I have the info, why not enter it? But the original creator's purpose/focus doesn't matter to me except as historical perspective. My goal is to organize and PLAY music, so my major use of categorization is to support this.
I divide MC fields into three types:
Standard fields in MC, mostly that also are used by other media managers/players. Where useful I use them, such as Name, Artist, Genre, Tempo, Year, Album, Comments.
Custom multi-value fields that mostly parallel Standard fields but let me store and retrieve multiple values: Artists vs. Standard one-value field Artist, Composers vs. Standard one-value field Composer, etc.
Custom fields that provide key info I need to sort or select by that justifies its own field: Recording (Stereo/Mono/Rechanneled). Music Chart Position, and three fields to identify the source (CD, LP, 45, Tape, Download, TV, etc) plus original ID if applicable (UPC number, Album number or whatever) plus a date code to know when I ripped it.
Custom fields because I don't like MC's built-in behavior: Only one example, Rating. I avoid this field because of the bolted-in stars display which can be changed by a single click in a view/list, unlike other fields that first require entering edit mode. I put in too much work to have this value changed inadvertently, so I store my rating in a custom field. If MC (14?) someday provides control over the Rating field so it can be used as a normal numeric field, I'll switch back to it (this has been discussed several times in other threads).
I slightly customize a track's name to distinguish between different performances of the same song by the same artist, but I don't do this by changing the name itself. Right next to Name I have RecVer (recording version). It might contain VER1 or VER2 or TAKE3 or ALT-TAKE or LIVE-LONDON or LONG-VER or ALBUM or when a song was re-done at various times in an artist's career VER1958, VER1967, VER1992. Etc. Then via a Rename expression I combine this with Name to assure that each file has a unique name. I don't add my RecVer info to the end of the Name value because I use views by Name and I want to see every recording of a given song in one place, regardless of RecVer or Artist or anything else -- so all recordings of a song must have exactly the same Name.
But as I've said, the magic ingredient is MC's Keywords field because it is so versatile. For instance,
I could have a separate field for Decade (my library spans more than 100 years) but, while I enter the original recording year if known, I indicate the decade via Keyword values: 2000s, 1990, 1980s, etc.
I could have a field for primary musical instrument, but instead I have Keywords field values such as piano, guitar, trumpet, strings, brass, accordion, kazoo or whatever.
I identify certain special categories of music by having Keywords such as Beatles (to identify every song done by them OR their music by someone else) and Motown and Cars and Surf and Showtune and Movie and Live and whatever other term strikes me as "I'd like to find this and similar songs later".
I do the same with more Keywords to identify songs that fit special niches, such as Dinner, Lounge, Summer, Party, etc.
I also use Keywords to expand on Genre, though I considered adding a custom multi-value field Genres to do this (would be just as good). Genre gets the one term that most describes the track, but in Keywords I select other genre values as appropriate. Such as Rock, Pop, RB, Folk, EL (easy listening), BB (big band), Historic, Disco, etc -- trying to stick with common categories used by music stores/catalogs, but selecting multiple for some songs. Perhaps the most famous need for this is Ray Charles "I Can't Stop Loving You" because in 1962 it was on ALL the separate music charts, a unique (at the time) situation. So it has Keywords RB, Pop, Country, EL.
There's a bit more but you get the idea.
I know there are other fields that could do some of what I'm stuffing into Keywords, but again it seems faster to do this via Keywords because it lets me use any abitrary value I like, and I'm able to build the precise playlists I want by selecting on specific values. At times when I realize I didn't structure it correctly, MC gives me enough tools to move a value from Keywords to a separate field, or vice versa. Or to change a value across the entire library when I realize it isn't quite right.
The main dividing line between a separate field and a Keywords value is how I need to use it. A separate field is wonderful to build views grouped/sorted by the values in that field, isolated from (or perhaps cascaded with) other values. Where that attribute isn't needed, such as for smartlists, I use filters/expressions based on any combination of fields, including any arbitrary values from Keywords.
My point in detailing this is that MC power users (presumably most people using this forum) probably don't care about defaults. W can use the powerful architecture of MC to build almost any kind of custom system, so we are not the target of default category lists, views, playlists etc. -- we already tend to ignore or hack them. But MC would be a lot more warm and fuzzy to newbies and those who don't care to customize if it presented defaults similar to whatever else users already know -- maybe Amazon or Barnes & Noble music categories, for instance.
Author
Topic: Media categories and organisation (Read 9887 times)