Print

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

[darichman]

Hi guys... Big post but just thinking out loud In just a few years, MC has gone from pretty much an audio only app to my primary organiser of video and photos as well. I can now use it to browse and organise web media, organise my photos and post them online and *gasp* rip DVDs. I can't watch TV unfortunately but that's there as well! I've yet to find another program that supports as many forms of media as MC or is as versatile in terms of plugins, functionality and customisation.

This isn't a request thread! There is certainly no expectation here and some of these would probably take tremendous resources, i'm sure. Just thought it would be fun to explore some of the possible directions for MC and media players in general... if time, resources and $ weren't so much of an issue

1. Video encoding. Support for major codecs, including newer mp4 stadards. 'Nuff said.

2. Video Editing. MC is perfect for organising my photos, videos and music. They are all in one place and are easily found and organised. What better program to offer a "Movie Maker" mode or similar? Basic slideshows, timelines, text overlays, transitions, effects and encoding to a variety of outpur formats would be fantastic. Ability to then burn projects to DVD would make MC a nero killer

3. Online Reference Database. Kingsparta's Datamaster has come close to what I'm thinking about here. We have YADB. We have coverart lookup and submission. At the moment this is only really for audio, and at that rate, only audio CDs. The lookup isn't all that useful if I'm dealing with files already on my hard drive. What we need is something like allmusic.com's database, which contains extended data such as genre, style, mood etc. aTagger when it was around was perhaps the most useful thing I've ever used in MC.

What we really need is the ability to submit more information than standard artist, album, track, name etc and to choose which information I wish to receive from other users. Any fields we can create in MC should be available to submit and share with other users. If User X has a custom field for his classical music, I would like to see this in the lookup dialogue and add it to my library if I want. What would be ideal is a universally agreed upon standard for submission (yeah contentious I know...) Standard fields for each type of media that we agree on. Like composer, performer, conductor etc etc for classical music ~ or Series, Network, Season, Episode, Name for TV shows.

DVD/Movie/TV submission would be great as well and it would seem that this is in the works. Either use IMDB or incorporate similar functionality into YADB. Please

4. Streamline expressions. Expression editor is great and the applications of expressions are almost limitless. What would be great is a more user friendly interface for entering them. I'm terrible with expression language ~ have managed to write a few that are over a page long in word and it was a logistical nightmare. Something along the line of excel's "point and click" way of doing it would be ideal. If i want an IF expression, I should be able to click on IF and select the fields and enter values I want. Ability to save expressions is a must, and integration into all aspects of the program, including fields, views, renaming, filters, searches, theatre view would be great. We're almost there. Some way to share our expressions with other users would be useful and quickly expand the functionality of the program. And hey you guys could kick back and let your users code the program for you! haha

5. Document handling. The organisational capacity of MC (at least as far as I can see) vastly exceeds that of windows... I've started using MC to organise documents and journal articles as well as eBooks. The ability to create fields and have multiple list entries is great for cross-referencing. More intimate support of documents could help MC to create useful and functional databases for research articles, personal files, projects etc.  At a minimum, would we'd be looking at text searches, preview thumbnails of major formats (office, pdfs, html etc) and reading metadata (author, etc etc).

6. Dammit I lost my tags! I can't count the number of times I've had to move my library or parts thereof to a new machine and, oh no, the metadata from my avi, mov, flac, mp4, bmp, tiff, document files is gone. Crap. I know it's stored in the database, but it's not always possible to retain that data if you're a) moving your files somewhere else b) sharing your files with a friend. It's just not practical to migrate the database in pieces just to retain tag information. If MC can't write metadata to a file, we should have the option to save it to the folder as a separate .tag file or something. Just like saving a coverart file. Each folder, if we choose, could have it's own .tag file which contains all of the field entries for the files in the folder. When the folder is imported on another machine, this data could be recovered. I know, I'm excited too.

7. Hierarchical Database. This one's my favourite, but I don't know if that's necessarily the best way of describing it... at the moment we have fields, but these fields have no relationship to each other. Fields are only linked to the file. What would be ideal would be the ability for certain fields to be linked to each other within the database. For example, bio is generally a field that we use to describe the artist. Each time I get a file from artist X, I have to manually add the bio. Again and again. We should be able to make [Bio] a tag that is linked to [Artist]. A "tag for a tag" if that makes sense. That way every new file for "The Beatles" will have the same bio tag, and this will happen automatically. I could also do this with things like [Artist Nationality] or [Artist Members] etc etc. Think about it, this would be incredibly useful... and would save incredible amounts of time. The data could still be written to the files, it just wouldn't have to be done manually each time.

Examples: For photos, we have the field [People]. My name is Chris. Imagine the possibilities if I could make a field called [Birthday]. I could tag the entry "Chris" with a birthday of "1984". I could then use this in a custom field (using expressions) to calculate my age in any given photo. Each new person can be tagged with their approrpriate birthday. Marko, I just know you'd like this . And best of all, this would only have to be done once, as it's the [People] tag we're referencing, not the photo. I hope this makes some sense.

Another example: [Movie] (a custom field) could be linked to [Director], [Studio], [Cast] etc etc

This could be done in the options menu under create new field dialogue. We could have the option when creating or editing a field to "Make a child of...." and select the field we want it to be linked to. Done. Then in the Tag AW, under [Artist] for example, there could be a little dropdown with the child fields underneath. Make sense?

9. A direct line to Jim's Office. This is essential. MC should be able to dial up J River HQ so that customers can impart their useful ideas and random musings at any random hour.

So.... any hugely ambitious / unrealistic / impossible ideas out there?
Where do you guys see MC going in the next few years?

Other issues for discussion: Blu-Ray, HD-DVD, PS3/XBox Support, DVD ripping and encoding, Home Theatre Solutions, MC Portable, better photo acquisition and editing, theatre view improvements

[JONCAT]

"We have coverart lookup and submission. "

Are you talking about the built-in MC lookup? I do all my cover art manually; scans or online searches. Used to use Amazon Cover Art Finder app. The MC function oftens returns the wrong file (even for simple expressions that have been VERY slightly modded e.g. "the" is added)

"Direct line to Jim's office"

Ummmm....in my more rebellious days I had to call Jim and convince him I wasn't  a complete jack@ss (I doubt I convinced him then), but I have hopefully proven that I can be amiable, cordial, and downright positive. Although I am sure he still thinks I am insane; using x64....still (but it's stable now after all the changes I made : )

Some great ideas here, especially the Hierarchical Database. I have often thought about this as a macro mode for tags (usually while I am tagging my brains out). Being able to set this up would save a lot of time; to attach Genre, Style, and other custom tag info to another field would be monumental.

DC

[mlefebvre]

7. Hierarchical Database. This one's my favourite, but I don't know if that's necessarily the best way of describing it... at the moment we have fields, but these fields have no relationship to each other. Fields are only linked to the file. What would be ideal would be the ability for certain fields to be linked to each other within the database. For example, bio is generally a field that we use to describe the artist. Each time I get a file from artist X, I have to manually add the bio. Again and again. We should be able to make [Bio] a tag that is linked to [Artist]. A "tag for a tag" if that makes sense. That way every new file for "The Beatles" will have the same bio tag, and this will happen automatically. I could also do this with things like [Artist Nationality] or [Artist Members] etc etc. Think about it, this would be incredibly useful... and would save incredible amounts of time. The data could still be written to the files, it just wouldn't have to be done manually each time.

I REALLY support this!

Michel.

[JimH]

Thanks for the very thoughtful post.

[benn600]

I think J River should start up a monthly podcast.  They could detail the month's major achievements, discuss the top participators on Interact and their ideas, question the audience, etc.  It would only have to be monthly and 30 minutes or less.  It would be a great way for us to hear the subtle comments relating to requests on Interact.  For example, when an individual may request a feature, everyone will hear how unlikely it is for that feature to get added by the tones of voices.

Where can I subscribe?

[dcwebman]

7. Hierarchical Database. This one's my favourite, but I don't know if that's necessarily the best way of describing it... at the moment we have fields, but these fields have no relationship to each other. Fields are only linked to the file. What would be ideal would be the ability for certain fields to be linked to each other within the database. For example, bio is generally a field that we use to describe the artist. Each time I get a file from artist X, I have to manually add the bio. Again and again. We should be able to make [Bio] a tag that is linked to [Artist]. A "tag for a tag" if that makes sense.

This goes along with what has been requested for a long time and that's the ability to assign a song to more than one album to avoid duplicates.

"We have coverart lookup and submission. "

Are you talking about the built-in MC lookup? I do all my cover art manually; scans or online searches. Used to use Amazon Cover Art Finder app. The MC function oftens returns the wrong file (even for simple expressions that have been VERY slightly modded e.g. "the" is added)

I find myself trying the cover art lookup first and if it doesn't bring back what I want, I go find it manually. Then I make sure I update YADB so the next person will have the correct cover. I still say there needs to be a way in YADB to allow for multiple cover art images for a single album as there are sometimes multiple covers for the same album. YADB has no way to support this now. This would also solve the problem of people getting the wrong cover because they could see what was submitted for a particular album and select the one they want instead of requiring a manual search later.

[hit_ny]

1. sounds doable in an incremental sort of way

2. would be a waste since there are many, non-linear editors for the job.

3.have done this manually since day one.

4.looking forward to this, but i think it might take another cpl of versions to get right.

5. have no use for atm, i'd think there are better more specialised tools already out there for this.

6.you can already save all the tags MC uses to a file by saving in MPL. So if this is the metadata file you want, then just save the mpl of the album along with it. Transferring to another machine etc, will be harder since MPL stores exact filepaths, if you could recreate it then i guess another MC user will be able to use it. If you use a standard path on both machines it will work.

7.has been discussed in the past but there has not been much movement towards it, you are in effect asking more for a relational database than a hierarchical one. This would hopefully also bring concurrent updates of files so MC becomes more multi-user. A  move that would be welcome by many , but i think its not that simple to roll your own dB. Using some one else's wont really work as it would not be tuned to MC's specifically.

[ThoBar]

7. Hierarchical Database. This one's my favourite, but I don't know if that's necessarily the best way of describing it... at the moment we have fields, but these fields have no relationship to each other. Fields are only linked to the file. What would be ideal would be the ability for certain fields to be linked to each other within the database. For example, bio is generally a field that we use to describe the artist. Each time I get a file from artist X, I have to manually add the bio. Again and again. We should be able to make [Bio] a tag that is linked to [Artist]. A "tag for a tag" if that makes sense.

As discussed in another thread, MC database is Relational in that if multiple items have the same tag/field (be it bio or whatever), then that tag is stored only once.

The subtlety in this request is not so much to do with the database structure, but rather in how it can be used. Rather than having to mass assign a particular tag to a field, MC would be more intelligent and automatically pick up changes across the board. Realistically speaking, what is required here is probably nothing more than a way to edit the database field directly, instead of doing so via selecting all items with the same field data, then editing that field. Sounds simple hey

Cheers,
C.

[darichman]

2. would be a waste since there are many, non-linear editors for the job.

Sure, there's also plenty of other programs that can rip, encode, play music etc... doesn't mean MC shouldn't add new features just because another program can do it. The beauty of MC is that I can use one program to do it all. Currently, I use Adobe Premiere for making videos. But if I move my files in MC, all the entries are lost in Premiere and my project is a mess. MC knows where my files are, and if I move them or change them it won't matter. I would have one program to manage lots of things at once (provided it did them well), rather than lots of programs to manage things separately.

6.you can already save all the tags MC uses to a file by saving in MPL. So if this is the metadata file you want, then just save the mpl of the album along with it. Transferring to another machine etc, will be harder since MPL stores exact filepaths, if you could recreate it then i guess another MC user will be able to use it. If you use a standard path on both machines it will work.

Yeah you're right. And I do use this. I think what I was getting at was something that is more automatic and more transparent. At the moment, every time I make a tag change, I have to save another MPL. Also, you have to do it for the entire album at once. What if I want to change just one file? And as you say, it isn't that useful when moving files due to the file path issue you mentioned.

The subtlety in this request is not so much to do with the database structure, but rather in how it can be used. Rather than having to mass assign a particular tag to a field, MC would be more intelligent and automatically pick up changes across the board. Realistically speaking, what is required here is probably nothing more than a way to edit the database field directly, instead of doing so via selecting all items with the same field data, then editing that field. Sounds simple hey

I think I understand what you mean... it could get confusing. How will MC know whether it's the individual file I want to retag, or all files containing the same field data? *headache*

What I am picturing is this. At the moment we can view groups of files based on a field entry. Let's use artist as an example. I create a viewscheme with artist and set it up so I can see thumbnails for each artist in my library. If i double click on an artist, it will display the next field/pane in the viewscheme (eg the albums by that artist). If I right click on the artist, however, I would like to see a little pop up which says "Tag Artist" and "Tag Files". "Tag artist" could bring up all the child fields I have set up for artist (eg Bio, Artist Nationality etc). Editing these would affect all files belonging to that artist (whether in the current view scheme or not). "Tag files" would bring up the standard tag AW for all the files filtered by the current viewscheme.

In this way, each artist is an individual entry which can be tagged with anything we want. Taken to the next level, we could add coverart to artists so that artist coverart is viewable in thumbnail view when viewing by artist. Currently, we see a slideshow of album coverart when hovering over an artist. Then, by opening up one of the artists, I get a thumbnail view of all the albums. Magic! For photos, I could use a similar setup for [People]... I could tag a "person" with things like age, birthday, home. I could also add People Coverart so that when I use a viewscheme with "People" i see a portrait of each person that I have selected myself.

What do you think?

[hit_ny]

Sure, there's also plenty of other programs that can rip, encode, play music etc... doesn't mean MC shouldn't add new features just because another program can do it. The beauty of MC is that I can use one program to do it all. Currently, I use Adobe Premiere for making videos. But if I move my files in MC, all the entries are lost in Premiere and my project is a mess. MC knows where my files are, and if I move them or change them it won't matter. I would have one program to manage lots of things at once (provided it did them well), rather than lots of programs to manage things separately.

You answered this better than i could, rip, encode, play music are essential to an audio player. Video editing is a stretch don't you think. MC has a wav editor, but its so basic that i prefer to use wavlab. I can't help thinking the same would apply with video.

I think, instead of MC being able to perform editing, maybe you are asking that it understand the tags that Adobe Premiere inserts into the files ?

Still, i'm not sure if even this would be feasible. If you are working on a project, then the files in it are in constant flux, the managing program in this case adobe would be best qualified to manage it right ?

I worked on a dvd project recently, in this case the authoring program was dvd-lab, there were lots of files in the project but i just placed them in several folders and did it that way. Of course i was only working on just that one project, if you are doing several it may become more complicated.

You are used to MC's interface to organise files and wished the other progs could have the same. Maybe auto-import could help here, of course if you change files or delete them outside MC then you will get missing links or dupes. Might end up less workable than just letting the managing program look after its own files.

Yeah you're right. And I do use this. I think what I was getting at was something that is more automatic and more transparent. At the moment, every time I make a tag change, I have to save another MPL. Also, you have to do it for the entire album at once. What if I want to change just one file? And as you say, it isn't that useful when moving files due to the file path issue you mentioned.

Don't follow here, MPL is to be used when you want to do an import, so for instance i might listen to an album now, tag & rate it, i then save the album as mpl and import it later. If its just one file then yeah, if you want to have the changes you would need to resave to MPL again.

Otherwise if its imported into MC, then you dont need to use mpl unless you want to move it to another library on another machine,

Now if you wanted to do several specific files/albums, using mpl will get complicated. The only way i can think of in this case is to save relevant information to the files themselves, move them to new platform and then re-import.

I think I understand what you mean... it could get confusing. How will MC know whether it's the individual file I want to retag, or all files containing the same field data? *headache*

If i could phrase it this way

Don't change stuff that i can't see

No Field updates to files that are not in the current selection.

Undo [Ctrl+Z] still does this but for some reason nobody has too much issue with it. Make a change, go to a differenet view make another change, hit undo twice and the change you made in the previous scheme is also gone.

Have to tread carefully...

What I am picturing is this. At the moment we can view groups of files based on a field entry. Let's use artist as an example. I create a viewscheme with artist and set it up so I can see thumbnails for each artist in my library. If i double click on an artist, it will display the next field/pane in the viewscheme (eg the albums by that artist). If I right click on the artist, however, I would like to see a little pop up which says "Tag Artist" and "Tag Files". "Tag artist" could bring up all the child fields I have set up for artist (eg Bio, Artist Nationality etc). Editing these would affect all files belonging to that artist (whether in the current view scheme or not). "Tag files" would bring up the standard tag AW for all the files filtered by the current viewscheme.

In this way, each artist is an individual entry which can be tagged with anything we want. Taken to the next level, we could add coverart to artists so that artist coverart is viewable in thumbnail view when viewing by artist. Currently, we see a slideshow of album coverart when hovering over an artist. Then, by opening up one of the artists, I get a thumbnail view of all the albums. Magic! For photos, I could use a similar setup for [People]... I could tag a "person" with things like age, birthday, home. I could also add People Coverart so that when I use a viewscheme with "People" i see a portrait of each person that I have selected myself.

This one sounds interesting, a possible way to tag all items of the same entity at once, a way to have a relational db like function.

Is it better than the current implementation tho ?

Search for a specific item, select all instances of that item and just make one tag change in the action window. No popups

[robydago]

About the relational db topic.

If the current db is not relational and implementing it is too complicatad, what about adding this feature as a "workaround":

- URLs can be used in calculated data fields, where a URL can be anything MC can handle: HTTP, files, etc.


What I mean is that if a calculate data field containts a URL, MC should:

- show the URL content when needed by the current view

- optional: index the URL content to make it searchable in a fast way (this would mean also keep crawling URLs for modified contents...); it's not strictly necessary, but if the external data is to be searchable, I think that not indexing URl content would really slow down any search.

So, for example, if you have an artist bio in an external txt file, all you need is to put
file:///[driveletter]:/[dirname]/[filename]
in all the artist's entries you have, putting the above string in the bio field

It's not at all like having a true relational db, but maybe it can be useful anyway

[hit_ny]

How to fit URL content (as in whats linked to) on one line(!)..cos thats all you have.

Unless you are talking about hyperlinks, click on them and a browser opens up.

[robydago]

i'm not talking about clickable hyperlinks

i'm talking about content directly shown by MC wherever the URL is used.

if the only chance now is one line text, then jriver could start adding the capability to manage just urls to txt files (it doesn't matter if they contain CRs & LFs, those can be ignored)

but I think that cover art too could be managed in this way

[hit_ny]

Cover art can be displayed this way already.

Try to add a Large Icon and it shows up as a column in Playing Now, or any other viewscheme.

I guess you are talking about that taking that idea and applying to URLs.

[darichman]

This sounds like a decent idea for a workaround. I guess it would require significant effort in terms of creating individual txt files for each artist though

Is it better than the current implementation tho ?

Search for a specific item, select all instances of that item and just make one tag change in the action window. No popups

Well I definitely think so! Apart from the other advantages described above (artist specific coverart, artist specific fields), it would cut out both the searching and selecting that you mentioned! I would just need to select an artist in artist view and tag it. Easy.

If i could phrase it this way

Don't change stuff that i can't see

No Field updates to files that are not in the current selection.

I see no reason why we wouldn't want changes to affect all files belonging to the same artist entry... Don't forget we're talking about fields we've set up to be linked to artist, or "child" fields to use the terminology above. Because the fields we're talking about are in reference to the artist, not the individual files. Why would I not want a change in bio to be reflected in all files belonging to that artist. Naturally this would be something we could choose -- whether we want field changes to be saved to the file tags or whether we want artist fields to be stored only in the database. Just like the current implementation with tag storage.

To be honest, I have no understanding of the complexities involved in implementing something like the relational database mentioned above (I'm a doctor, not a software engineer ) Is it something that would have to be done from the ground up, or would it just be a matter of changing the way MC handles fields in the existing database. In other words, I guess I'm asking how ambitious or realistic this really is.

[hit_ny]

I suppose one way of tackling this, one-change-affects-all-of-the-same would be to provide a right-click menu item (or pupup as you suggest) that says update all of the same, where you get to designate the "same" in this case the bio field of an artist, when you were filing it in,  would allow you to designate all bio fields for said artist to be filled in.

Technically i doubt this would be very hard to implement, but i still have a preference for seeing the changes happen in front of my eyes, as is the current way.  It acts as visual feedback so little bit safer, if ever you made an error, mistakenly chose the wrong field(s), you see it immediately.

OK why might you make an error, think of such a relational-db like functionality working across any or all fields. You would be able to designate several "same" fields as well.

Imagine a similar Dialog to Library Tools->Clean file properties, where you get to pick which field(s) you want to be "same" for the said artist. Select them and you are done. But you must be very careful you only select the right fields or you might corrupt other fields. In the Clean file properties example, i only use it when i have all files in playing now, so i can at a glance, that only the right fields were updated, a visual check.

But if you cant see the files since it would be doing this same-fields-update behind the scenes in the library, an error would be harder to catch. Unless you went and checked each of them yourself, in which case you might just as well, add all the files you want to update to PN and do the select all+ field update.

With a tags based system, like MC, i need some protection from the biggest bug, between the chair & the keyboard

I can see your point tho, in the situation when you want to incrementally update tags, say you get more bio info that you want to update, select one field and its updated across all. So long as its done in a way thats intuitive and obvious i guess i would be fine with it.

[darichman]

Maybe what would work best is a move from a file-centric system to something which treats groups of files as individual entities. Files could then be assigned to these group entries. In a system like this I could develop a database of artists for example... I could tag these artists as if they were individual entries and they could exist even if I had no files belonging to that artist (or I could specify "hide empty artists" in view schemes or whatever). When dealing with files, I simply assign them to a particular artist, and the artist information will automatically show for these files. In this way, the information is already there contained in the artist "tag" and by associating a file or group of files with the artist, the artist tags naturally apply to the files as well.

That way I could create tags for groups of files and not have to reproduce them each time I import files which belong to that group, whatever the group may be (artist, people, movie, TV show, album...)

There's no need to worry about how changes affect "files I can't see", because we have to make the choice to assign the files to a particular group anyway (eg an Artist, or a Film, or a Person etc). The changes will only apply if we add files to a group... And really, we're talking about group-specific fields, not file-specific fields. This would require the ability to link certain fields to other fields though, as described above...

Applications
#### I could tag artists with artist-specific fields like [Bio], [Artist Genre], [Nationality], [Year Formed], [Years Active], [Members] ala AMG and MP3.com. This information could be used both in view schemes or in displaying a summary of the artist in question. Ideally we could output it as a html or to YADB where other users could access the info. Artist coverart is a must!!

#### I could tag an album with album-specific fields like [Album Genre], [Album Year], [Album Charts], [Label]

#### I could tag people with people-specific fields like [Association] (eg friends, family, colleagues etc), [Birthday] (could be used to output [age] using calculated expressions)

#### I could create a field called [Show] or [Movie], and assign child fields [Network], [Actors], [Genre] etc. We're talking IMDB fields. That way each time I obtain new episodes for a particular TV show, I need only to assign it to that TV show (using the [Show] field or whatever) and the Network, Actors, Genre etc etc will automatically apply. This would save a lot of redundant and duplicative tagging.

In it's ultimate evolution, in not much time, MC could develop a databse that trumps AMG/mp3.com, IMDB, TV.com etc, because fields like those mentioned above could be user submitted and shared. I call it MCDB. Media Center Database. But you can use it if you want to

[hit_ny]

An entity/group based system (with inheritance) rather than files centric has been proposed numerous times in the past. Its certainly interesting to reduce redundant tagging, could also be very useful with photos etc.

We might get lucky with the next version, they usually add lots of new features to odd numbered versions. This one will be a major change, if they go ahead with it.

Is anyone aware of any media mgmgt software that can do this already ?

WhereisIt allows categories which i suppose are like groups, but you can do that with MC now anyway, by assigning custom tags. I don't think it allows inheritance, where a file inherits attributes/tags from its group.

[darichman]

Sounds like inheritance is the word I'm after

Been thinking about this a lot! The things that would need to happen for this ever to become a reality...

1. Setting Up fields to be relational
2. Databse handling of relational fields
3. Implementation into current Tag AW
4. Implementation into view schemes
5. Implementing online submission and lookup

Here are some ideas I had.

1. Setting up relational fields
We need a way to tell MC that we want one field to be subordinate to another. Eg. We want [Nationality] as a field to describe [Artist]. Or we want [Association] as a field to describe [People].

Option 1: In the create new field / edit field dialogue, have a tick box for “Make Child Field of…” and then select the field you wish to link it to. Eg. Create a field called [Nationality] and make it a child field of [Artist]. Each child field should only be linked to one parent field.

Option 2: In the create new field / edit field dialogue, have a button saying “Add Child Fields”. Eg. Click on edit field for [Artist] and add a child field called [Nationality]. This is essentially the reverse of option 1. Ideally we could do it either way and the end result would be the same. We’d need the ability to add more than one child field.

2. Database handling of relational fields.
Relational fields should be available as per regular fields in view schemes, panes, columns, the tagging window etc, with a few minor differences as described below.

Editing child fields will be reflected in any files belonging to the parent field.

3. Implementation Into Tagging AW
Parent fields should display as per the current implementation, but subordinate fields need to appear under the parent field. They can be viewed or hidden with a drop down to the left of the parent field (just like tree entries). We should be able to treat child fields as regular fields in terms of selecting which ones to show in the Tag AW and in terms of editing them. The only difference is how they are viewed in the Tag AW (as subordinates of parent fields, to denote the fact they are describing another field, as opposed to the file itself.

Here is an example of what the Tag AW might look like

>   Artist: AC/DC
            Bio: … (extended field)
            Nationality: Australian
            Members (a list field): Bon Scott; Malcolm Young
            Year Formed: 1973
>   Album: Stiff Upper Lip
            Album Genre: Pop/Rock
            Album Year: 2000
            Record:
>   Rest of the fields etc etc

4. Implementation Into View Schemes
Child fields should be available to use as panes in view schemes, filters etc just like any other field. For example, I could create a scheme [Nationality] -> [Artist] to navigate. If we are viewing “artists” in a view scheme, it might be nice to see a summary of any child fields pop up if I hover over it. Double clicking on an artist will drill down into the next pane in the view scheme. Right clicking might bring up options like “Play all files” , “Show albums by this artist”, “Show artist info” etc etc. Tagging would bring up the Tagging AW as described above. If I try to retag a child field (eg using column view) it might be wise to bring up a popup “Are you sure you wish to change the Artist: AC/DC” or something similar, so that the user knows they are changing all references to AC/DC, and not just the file in question.

It would also be really great to right click on an artist (or whatever field we’re talking about) and say “add coverart”. This artist coverart could replace the moving slideshow of album images when in artist mode. I would personally find this really useful for tagging different [People] with portraits… these could then be used as a visual way of navigating through people by their faces, not a random slideshow of photos they appear in.

5. Implementing online submission and lookup
This is probably something that would come much later, but wouldn’t it be great if we could submit artists, or movies, or TV shows or books etc as we currently do albums? An online MC database like this with lookup and submission would be incredibly powerful and would be a major selling point of MC (at least in my humble opinion). We’d be submitting child fields for each of the major categories described above.

I rip a dvd (which I own!!!) and convert the movie to divx or something. I enter fields like [Director], [Composer], [Studio], [Actors] etc (which I’ve set up as child fields of [Movie]) and upload them. Then if another user has the same movie… he need only match it by title and can download the above info!

A database like this could grow really quickly… and doesn’t rely on recognising the exact same DVD or audio album. We just need to compare a field like [Artist] or [Movie] and the information is accessible. A “closest match” option might be useful!


Wow I’m bored. Any opinions?

[0239666]

I think a monthly podcast is an excellent idea. In a video podcast JRiver could display how to use the new features.

[benn600]

Way to take my idea step further!  I would like to officially go on record requesting a J River Podcast.

J Ronthly

J Monthly

JR Monthly

MCM (Media Center Monthly)

[JimH]

We tested this.  JRiver came in second after the "Paint Drying" podcast.

[hit_ny]

That's another long time request

Extending the concept of group to container, in this case track and encapsulating several other tracks in it, so that MC will treat it as one. So one could in theory send x numbers of albums to playing now, and have  it shuffle the order the Albums were played, but NOT the track order within the album. Ipod already does this.

[darichman]

haha it would seem that this has, in fact, turned into a request thread

Sorry guys!

[hit_ny]

I'd prefer it stay within the theme of groups, there is still much more to say on this topic.

How will the the existing library operations have to adapt to accomodate it ?

[Mr ChriZ]

We tested this.  JRiver came in second after the "Paint Drying" podcast.

Still missing the cupcake reporter from New york.  She was cute! 

[JimH]

haha it would seem that this has, in fact, turned into a request thread

Sorry guys!

Thanks for your thoughts though.  I'll close the thread.