Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[darichman]

I've been reorganising my library a little bit lately - mainly to test and properly take advantage of Carnac, metadata lookup and some other video features which seem to be trickling their way into MC. I've always had a heavily customised library, with lots of user-generated fields etc to fit my workflow and media catalog.

One thing I realised a while ago was that I've never used the [Series] field. Firstly, because I had my own custom field for this long before it was added as a default field, and secondly because I use it for the titles of video works other than series.

Why do we need a stand-alone field limited to series, guys? I'm probably missing something, but doesn't this limit it's use to only... well, series? Why not call it [Title] or something similar so that it can be used with series, TV shows, comedy shows, theatre etc. Or would this be too ambiguous?

A generic title field for movies, for example, would allow us to use the name field for extras and special features etc without having all these files appear in your video views as separate 'movies'
[Title]=Titanic
[Name]=The Making of Titanic
(to me this should still belong to 'Titanic' not as a separate movie entity)

All this would really require would be changing the name of series to something which more broadly encompasses video titles.

To summarise the advantages of having a more generic title field as I see it:

• allowing mixed views of multiple video titles (series, miniseries, features, shorts, stage etc) through use of a single title field
• allowing use of the [Name] field for other things like special features, trailers etc
• you can tag music files (soundtracks), posters etc with the movie they belong to as well

[rjm]

I'd like us to standardize on using Artist, Album, Name for all media types as follows:

Type: Artist, Album, Name

Movie: Series, Title, Part # or Extra
TV: Series, Season, Episode
Documentary: Producer, Title, Episode
Music: Artist, Album, Track
Audiobook: Author, Title, Chapter
eBook: Author, Title, null
Photo: Photographer, Topic, Image Name

This permits the construction of views that work for multiple media types, and eliminates media specific fields like Series and Title.

[rick.ca]

All this would really require would be changing the name of series to something which more broadly encompasses video titles.

Why don't you just change the display name of [Series] to "Title"?

I'd like us to standardize on using Artist, Album, Name for all media types as follows...
This permits the construction of views that work for multiple media types, and eliminates media specific fields like Series and Title.

Although creating views for multiple media types would be a little easier, this is a minor benefit that wouldn't be of much interest to most users. It certainly doesn't outweigh the inconvenience of either having to get used to referring to (as just one example) series, season and episode as artist, album and name, or customizing the captions in every view so they make sense.

The fact there may be a similarity in the nature of the categories across media types doesn't mean that they're the same thing or there's any advantage to treating them as if they are. There is an advantage to using the same set of fields for different record types—if a significant number of values in each type actually refer to the same thing. This does happen when an "artist" is a person who has created different types of media in the same library. On the other hand, when music groups, movie series, TV series, documentary producers, authors and photographers are 99% mutually exclusive across media types, there's no significant data management advantage to be had.

There are significant disadvantages and risks to mixing them together as if they were the same. For the most part, these are minimized in an environment where only one media type is being worked with at a time, but will still be there in various forms. Suggested values in edit lists, for example, will include those from other media types—which are completely irrelevant for most editing situations and will therefore increase the risk of error. For that reason alone, it's more effective to keep music artists, authors and photographers separate. In the relatively rare cases the values are the same and they need to be brought together in the same view, this can done by joining the fields with an expression.

[darichman]

Why don't you just change the display name of [Series] to "Title"?

That's not a half bad idea I will actually.
I'll just have to remember to reference 'Series' in any expressions/searches etc.
It just seems counter-productive to me.

I'd like us to standardize on using Artist, Album, Name for all media types as follows:

I can see what you're getting at, but this isn't quite what I had in mind... I do think that fields should appropriately describe what it is we're tagging, and agree with much of what rick posted.

[rjm]

The focus of my library is non-fiction so having a common structure across all media types is very beneficial. I can see that if your library focus is pop culture then it does not matter.

[rick.ca]

The focus of my library is non-fiction so having a common structure across all media types is very beneficial. I can see that if your library focus is pop culture then it does not matter.

You said...

I'd like us to standardize on using Artist, Album, Name for all media types...

...and I attempted to explain why that would not be a good idea.

I have no objection to removing all restrictions on field use that's not absolutely necessary for database integrity. We should be able to select or create the fields we want to use—whether to use the same set of fields for different data types, or to deliberately use separate fields. In other words, you're currently suffering from the imposition of unnecessary "standards." Adding more such standardization is not the answer.

[bytestar]

Full agree 

I'd like us to standardize on using Artist, Album, Name for all media types as follows:

Type: Artist, Album, Name

Movie: Series, Title, Part # or Extra
TV: Series, Season, Episode
Documentary: Producer, Title, Episode
Music: Artist, Album, Track
Audiobook: Author, Title, Chapter
eBook: Author, Title, null
Photo: Photographer, Topic, Image Name

This permits the construction of views that work for multiple media types, and eliminates media specific fields like Series and Title.

[Matt]

I don't think we're going to move in this direction.

We actually tried pushing audio-named fields on all media types some years ago, and I think it was a mistake.

It's not intuitive for a user to think "Artist" when describing a television series, for example.

The database is designed so that it's quite efficient to have discrete fields, even if they only apply to certain media types.

[rjm]

I understand. Perhaps something could be done about one issue that has bugged me for years.

The field Name has some special properties. For example, default views assume that the title is in Name for Video and Documents. In addition, Name is populated with filename on import. I use Album for title and I'm forever fighting the default behavior.

It would be great if we could configure the default field for title.