INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2   Go Down

Author Topic: Adding New Database Fields [FEEDBACK WANTED]  (Read 13825 times)

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 41953
  • Shoes gone again!
Adding New Database Fields [FEEDBACK WANTED]
« on: October 01, 2008, 03:05:21 pm »

We're going to add some new stock database fields.  Please review this list (and the naming) and let us know if you have any changes or additions.

Our list of additions:
UPC
Catalog #
Orchestra
Soloists {list style field}
Style
Instrument
Custom
Period

AlexB's list of additions:
Grouping
Total Tracks
Total Discs
Encoding Settings

Changes
Make "Copyright" editable

Discussion
Should "Artist" be switched to a list style field?  Or should a field "Supporting Artists" be added?
Should "Total Tracks" and "Total Discs" be calculated automatically, or be filled in by a user?
Logged
Matt Ashland, JRiver Media Center

datdude

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2215
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #1 on: October 01, 2008, 04:15:28 pm »

This is sort of a DB related issue.  Are semi colon delimited lists still not supported when trying to find a single field out of it in a smartlist, for example when trying to generate a smartlist for a single 'style', in previous versions of MC, it wouldn't work because it would just pick a single or set of files that had a unique 'string' for the 'style' field rather than separating out the individual styles them-selves.
Logged
"You are not a beautiful or unique snowflake." -  Just a very big snowball

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1570
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #2 on: October 01, 2008, 04:31:00 pm »

If you're adding a Catalog # field, the logical extension to that would be Publisher (Broadcaster would also be nice; I use a single field for both of these though)

Cheers

-Leezer-
Logged

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4565
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #3 on: October 01, 2008, 04:32:19 pm »

Discussion
Should "Artist" be switched to a list style field?  Or should a field "Supporting Artists" be added?
Should "Total Tracks" and "Total Discs" be calculated automatically, or be filled in by a user?
most albums have one 'artist', dont know if list there is really necesary, but i guess in some case it makes sence. but on every cd there are songs with more than one composer, in my opinion it makes more sence to make that field a list.

and i wonder if the proposed instrument field should also be a list.

about the total tracks, well.. calculated  :).. and maybe some more calculated total/average fields.. i dont rate but i guess there is a big market for av rating. how about av number plays...  :)

besides that, maybe the possebility to change the flags for all standard fields.. tracks could then be used for videoos also, and other fields could be taken out of sight.

 :)
gab
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #4 on: October 01, 2008, 04:34:13 pm »

Can [Media Sub Type] either be editable or have a bunch of new choices made available?

I need:

TV Show
Movie
Music Video
Podcast

Home: Home Video or Personal
Clips: For short clips, youtube-esque sillyness, etc.
Stock: For stock video for editing
Projects: For video editing projects
Comedy: For stand-up comedy routines and similar things
Other: Would be good to have a catch-all other category.

As far as your questions...

Discussion
Should "Artist" be switched to a list style field?  Or should a field "Supporting Artists" be added?
Should "Total Tracks" and "Total Discs" be calculated automatically, or be filled in by a user?

I don't have a strong feeling on the Total fields.  IMHO it'd be easiest to have it Auto-Calculate, but allow manual override.

I have a LOT of mixed feelings about list-type Artist.  Here's where I come down on it.

1) It would be nice to have the ability to add multiple artists to a track and have it show up in the Panes (or whatever) under multiple artists.

2) This needs to be accomplished with a minimum of headache, without affecting any of the existing tagging functionality for the [Artist] field.  The current List Type system does NOT offer enough flexibility for this.

The percentage of my tracks where I want multiple artists is very low.  At one time I attempted to switch to a custom-created Multi-Artist field, but I ended up abandoning it because it created much more problems than it solved.  For example, with a list type field, it becomes much more difficult to tag large batches of files that with the Artist field when 99.9% of them only have one Artist.  Drag-Drop tagging with List Type Fields is additive (meaning when you drop the items onto the tree, it adds the item to the field, rather than replacing what is there).  This is troublesome for the Artist field though.  There are other similar issues with using the Tag AW (editing List Type Fields is very slow).  It also becomes difficult to keep this special custom field "in sync" with the standard [Artist] field, which is the only thing supported by most other players and handhelds.

I think the best possibility would be for Artist to be a new special hybrid type of field type, that is specially designed to work just like the existing normal string fields in most cases, but which allows multiple entries via some special mechanism (that works differently from how you want "keywords" to work, for example).  The user should have to "try" a bit to expose this functionality, but otherwise not even realize that [Artist] is any different than any other string-type field.

If this isn't possible, and great alternative would be to allow us to link fields together and to give us a new [Multiple Artist] list type field (or Supporting Artists if you want).  By "linking fields" I mean this... Allow us to "pre-fill" fields with the contents of another field in the Edit Field dialog.  So, we could have a [Multiple Artist] field which is a regular List-Type field but which always "automatically contains" the contents of the regular [Artist] field in addition to whatever other items are added to the list.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

rjm

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 2699
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #5 on: October 01, 2008, 04:47:47 pm »

One significant gap in MC's management of media is dvd support. The total disc size and playing time of dvds is not captured in the database and thus library statistics are wildly inaccurate if you have many dvds in your collection.

Can we add and populate fields for dvd size and play duration?

I'll think some more about your above proposals and questions and will respond if I have anything intelligent to say.
Logged

jgreen

  • Citizen of the Universe
  • *****
  • Posts: 2419
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #6 on: October 01, 2008, 05:43:22 pm »

I'm glad to see more fields added for symphonic works, etc, but I really think that TV shows are in most urgent need of a rationalized set of fields.  I know Glynor and ChriZ have banged the gong for some time on this, and have proposed some great suggestions along the way. 

Secondly, I think it's high time a few of the various things that get called "Documents" get pulled out of the closet and dressed up.  Books (made out of printed words) would be my first choice, but I'll bet there's some other "new media" in there waiting to be exploited.  Fields for things like chapters, etc, and something to differentiate fiction from fact, short story from novel, etc.

On a personal note, the ongoing effort to differentiate fact from fiction consumes most of my waking hours, FWIW.

Logged

darichman

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1350
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #7 on: October 01, 2008, 05:49:41 pm »

This is exciting news :)

As far as artists go... these are the 'artist' fields I use:

[Artist] - Catch all field which you'd generally classify as the 'main' artist or artists for a song. I would very much prefer this to be a list - there are many instances where a second artist isn't simply a supporting artist (duets are a good example)
[Artist Alias] - Some artists have (or have had) multiple names
[Arranger] - Common in classical music. Someone who has altered work composed by another.
[Composer] - The primary artist in classical music... useful in popular music as well.
[Conductor] - For orchestral music etc
[Featuring] - Like your Supporting Artist field... someone else featured in the song who is not the primary artist
[Lyricist] - I rarely use this, but it's in there
[Performer] - Classical: the person playing the music or singing the vocals. Eg
[Orchestra/Ensemble] -

The alternative here is to have a single "artist" field and provide a means to "tag" each artist (eg ask the user "is this a composer? performer? supporting artist?") ... this would provide a single list of all the "people" involved in a project with the ability to qualify this role. The advantage is that clicking on "Artist X" will bring up a list of all the songs Artist X was involved in, whether the primary artist or not. The disadvantage is a messy artist field when we're dealing with interaction with external devices etc. Food for thought!

How about classical music? There are a bunch of additional fields here. Some can be mapped to current fields, but some just don't really fit anywhere in the current setup. I've described my fields here: http://yabb.jriver.com/interact/index.php?topic=45824.msg314108#msg314108
Logged

rpalmer68

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2639
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #8 on: October 01, 2008, 05:59:18 pm »

Can [Media Sub Type] either be editable or have a bunch of new choices made available?

I need:

TV Show
Movie
Music Video
Podcast

Home: Home Video or Personal
Clips: For short clips, youtube-esque sillyness, etc.
Stock: For stock video for editing
Projects: For video editing projects
Comedy: For stand-up comedy routines and similar things
Other: Would be good to have a catch-all other category.


I'd like media subtype to be editable, I ended up creating a new field "Video Classification" so I could use that to tag my videos as
- Home Movies
- Kids DVDs
- Kids TV Shows
- Live Entertainment
- Movies
- Music Videos
I then use Genre to break each classification down into comedy, family movies, action etc.

In terms of other fields, I probably wouldn't use too many of the suggested new ones myself, but here are some custom fields I have setup for my system if you'd like to take these into consideration.

- Classical Work Name - I use this field to tag a number of tracks so I can group tracks by the actual work rather than album name. So I have a view scheme \Audio\Composer\Classical Work Name. I find this the best way of browsing/finding classical music when using theater view.

- Featured Performers - I guess Soloists could replace this although in my mind soloists indicates something different, I use this when there are duets and the like to record each performer.

I've also added a number of fields for photo management, but I'm not convinced I've got that right so won't inflict my thoughts on anybody yet :)

Richard
Logged

GHammer

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1930
  • Stereotypes are a real timesaver!
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #9 on: October 01, 2008, 09:43:50 pm »

I'd rather the 'total' be a user selectable item.
I can usually look at the album and guess if the last track is '15' that the second selection is 2 of 15.

Later, after I graduate the Jethro Bodine School of Ciphering, I'll share my theory of gazintas with you.
Logged

marko

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8945
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #10 on: October 02, 2008, 01:54:47 am »

I've never really found the need for 'total tracks / total discs' type tags. Am I missing out on something? If not, I wouldn't like to be forced down this route for my tags.

As for making [artist] a list type field, I think it's an absolute, 200% no-no unless you first sort out this issue from my bug report, also touched upon by DatDude above...
Search Wizard & Search Rules
The search wizard changes list type search rules. [keywords]=vada is changed to [keywords]=[vada] which is, of course, something else entirely. More info here

Please forgive my ignorance, but what is 'UPC' and what is the difference between 'Custom' and the 'Custom 1, 2, & 3' that we currently have?
I assume that the '1, 2 & 3' variety are legacy things, I can't imagine what use they could be otherwise. Why would you use them when it's so easy to add your own, more informative custom fields? In case you hadn't guessed, tags are not exactly a forté of mine. My video library is a mess and I can barely spell 'jonra' :)

A couple of thoughts from someone who doesn't use anything else to manage their media...

I've got a custom expression based field here called "Current Date"... formatdate(now(),dd//MM//yyyy)
It's handy for listing things that really did happen today, as opposed to in the past 24 hours. Every MC should have one of those, don't you think?

Another custom field I use quite often is one I call [Import Date]. It's just [Date Imported], but without the time. I often find that when sorting by date imported, it can jumble some things up if there's a time difference, despite the date being the same. An 'Ignore time' option on the [Date Imported] field would be easier than a custom field.

-marko.

ThoBar

  • Citizen of the Universe
  • *****
  • Posts: 992
  • Was confishy
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #11 on: October 02, 2008, 05:47:11 am »

How about:

Period
Opus #
Opus (Name)

Also, how about making Episode and Series open to all media types. They're useful for eBooks, audiobooks etc

I also agree with darichman's requests, with the following notes
[Artist] - Catch all field which you'd generally classify as the 'main' artist or artists for a song. I would very much prefer this to be a list - there are many instances where a second artist isn't simply a supporting artist (duets are a good example)
[Artist Alias] - also good for common name searches
[Arranger] - yup yup
[Composer] - This already exists...
[Conductor] - This already exists...
[Featuring] - nyeah, I could use this instead of [performer] or [soloist] i guess
[Lyricist] - I rarely use this, but it's in there
[Performer] - Agreed. I use [Performers] and [Soloists]
[Orchestra/Ensemble] - is this not [Band]? (I prefer the name orchestra for sure, but given this exists...)

Also, I'll just take this opportunity to reiterate my desperate plea for standard fields to be configurable. Given that I could significantly cut down the number of my custom fields if i could just tweak some standard ones to use multiple values, make them calculated, or make them usable for other media type (see episode/series above). This for me would be one of the best feature additions since about version 8 :D. I'd suggest restricting the changes to be within the same data format (i.e. String/Binary), but aside from that I have no idea why you want to prevent these sorts of manipulations. (Feel free to educate me, seriously.) Surely a semi-colon delimited [Artist] field would be written the same way? Or an [album] field that was composed of [composer] + [simple album name] + [year]? Imagine the bliss of being able to get a meaningful album name on an iPod from all my very concise and neat custom fields... ahhhhhh  ;)
Logged

zxsix

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1753
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #12 on: October 02, 2008, 11:29:30 am »

Would like a Rating2 field that uses the 5-star format.  Better yet, let us create user-definable fields with a 5-star format.
Logged

hit_ny

  • Citizen of the Universe
  • *****
  • Posts: 3310
  • nothing more to say...
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #13 on: October 02, 2008, 02:33:47 pm »

What about Graphic tags, no need to read text when 'looking' at custom graphics will do the job in certain situations. I think its best if they were not allowed to expand past the height of a line item unlike cover art. I expect these types of tags could be more informative along the horizontal axis.

Should "Total Tracks" and "Total Discs" be calculated automatically, or be filled in by a user?
Totals in other areas is better ie grouping, with MORE than just one total to be displayed, on the same line. But then i digress :)

Disc number i already have a convention, append (xCD) to the [Album] tag, want to find which albums are xCD, search for xCD ;)

Total tracks i can't seem to think of a need for  ?

For example, with a list type field,

- it becomes much more difficult to tag large batches of files that with the Artist field when 99.9% of them only have one Artist.  

- Drag-Drop tagging with List Type Fields is additive (meaning when you drop the items onto the tree, it adds the item to the field, rather than replacing what is there).  This is troublesome for the Artist field though.  

- There are other similar issues with using the Tag AW (editing List Type Fields is very slow).  It also becomes difficult to keep this special custom field "in sync" with the standard [Artist] field, which is the only thing supported by most other players and handhelds.

Good summary on the current shortcomings of List type fields. Have to nail these down before said field types can be used more.

1) It would be nice to have the ability to add multiple artists to a track and have it show up in the Panes (or whatever) under multiple artists.
How will it be displayed in a pane when searched for ?


allow us to link fields together and to give us a new [Multiple Artist] list type field (or Supporting Artists if you want).  By "linking fields" I mean this... Allow us to "pre-fill" fields with the contents of another field in the Edit Field dialog.  So, we could have a [Multiple Artist] field which is a regular List-Type field but which always "automatically contains" the contents of the regular [Artist] field in addition to whatever other items are added to the list.
Hmm, this sounds interesting, little more subtle than a Calculated field,  it would make it easier to search for just 'a' artist and have it come up in every instance of said artist in whatever field that was 'linked-in'.

[Artist Alias] - Some artists have (or have had) multiple names

I have a few artists like this, so i expect you put the real name in [Artist] but do you then use the [Alias] field in any viewschemes at all ?

[Featuring] - Like your Supporting Artist field... someone else featured in the song who is not the primary artist

This is another, that i've wanted to do but like Alias where to use it in a meaningful way ?

my workaround atm is to append to [Name] ie  Track 1 (feat. Artist A)

Should "Artist" be switched to a list style field?  Or should a field "Supporting Artists" be added?

As far as extending the [Artist] field goes,  i'm not sure how else to do it other than to create custom list type fields. WMP makes the [Artist] field,  list type by default i think, breaking the std, not something that troubles its vendor but unless this is a defacto std i think its dicey to go down this route.
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 41953
  • Shoes gone again!
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #14 on: October 02, 2008, 04:57:16 pm »

Tonight's build adds many stock fields.

We didn't add "Total Tracks" and "Total Discs" as most people voted that it wasn't helpful.

If you'd like to help, you might create a blank library and look at the stock fields to see if you have any advice for us.

The build also adds a new interface for creating / configuring fields.

Thanks.
Logged
Matt Ashland, JRiver Media Center

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4565
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #15 on: October 02, 2008, 05:05:12 pm »

i do think it is fine.. more and more fields. but what scares me a bit, is that it is getting more difficult to manage that all. now already, when going through my base, with its custom fields, it is hard to see what is going on. what fields are writing to tags, which have values, and what are the calculated fields. i think the frontpage (in options, library) could be a bit more convenient. not only the names but with some more info behind it, spreadsheet style.

name   datatype  filetag   calculated   hasValues
artist    string        yes       no             yes
album    etc etc


 :)
gab
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 41953
  • Shoes gone again!
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #16 on: October 02, 2008, 05:06:12 pm »

i do think it is fine.. more and more fields. but what scares me a bit, is that it is getting more difficult to manage that all. now already, when going through my base, with its custom fields, it is hard to see what is going on. what fields are writing to tags, which have values, and what are the calculated fields. i think the frontpage (in options, library) could be a bit more convenient. not only the names but with some more info behind it, spreadsheet style.

Tonight's build has a new interface for this.  Feedback welcome.
Logged
Matt Ashland, JRiver Media Center

darichman

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1350
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #17 on: October 02, 2008, 07:40:08 pm »

I like the new field interface.

Do you have a list of what fields were added?
   For audio I can see grouping, conductor, lyricist, orchestra, period, catalog #, soloists, style, publisher
   Images: catalog #, publisher
   Video: grouping, catalog #, publisher, lyricist

I'd like a "show fields with no values" - would be useful to see which fields I'm not really using and for cleanup, to get rid of redundant fields I created and forgot about. Gappie's idea about a table / summary of fields and their attributes is a nice idea.

It is nice to view fields based on the Media Type. Have you given thought to having an ability to group like fields? Eg "Show me all the fields related to people/artists involved in this..." would bring up a logical grouping of artist, orchestra, soloists, lyricist etc. Having the ability to group similar fields in the Tag AW would be quite useful - eg putting all the classical music fields together, all the movie fields together all the photo fields together.

I have a few artists like this, so i expect you put the real name in [Artist] but do you then use the [Alias] field in any viewschemes at all

No, but it's a default search term, and [Artist Alias] is used in a combined field with all the other artist fields I use.

This is another, that i've wanted to do but like Alias where to use it in a meaningful way ?
my workaround atm is to append to [Name] ie  Track 1 (feat. Artist A)

Yes, I append it to the [Name] field as well as having it in its own field. It gets a bit painful, but once again, using a combined master artist field will bring up your supporting artists along with all the other types of artists.

And finally...
Should "Artist" be switched to a list style field?

Please, please, please YES! But don't make it by default... warn the user about possible conflicts re compatibility etc. and allow us to change it to list if we want to. That way it will work the way it does now for new users, but once they've played around and know what they're doing they can decide for themselves. Having Artist as a list would save me an unbelievable amount of time - I wouldn't have to maintain a separate Artists field anymore...
Logged

ThoBar

  • Citizen of the Universe
  • *****
  • Posts: 992
  • Was confishy
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #18 on: October 02, 2008, 09:19:41 pm »

New interface is excellent.

Quote
Yes, I append it to the [Name] field as well as having it in its own field. It gets a bit painful, but once again, using a combined master artist field will bring up your supporting artists along with all the other types of artists.
This is exactly whay I'd love to be able to modify standard fields - They're just so restrictive at the mo'

Quote
Quote from: Matt on Yesterday at 04:05:21
Should "Artist" be switched to a list style field?

Please, please, please YES! But don't make it by default... warn the user about possible conflicts re compatibility etc. and allow us to change it to list if we want to. That way it will work the way it does now for new users, but once they've played around and know what they're doing they can decide for themselves. Having Artist as a list would save me an unbelievable amount of time - I wouldn't have to maintain a separate Artists field anymore...
...what he said...
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #19 on: October 03, 2008, 12:29:44 am »

Love the new Manage Library Fields.
Logged
The opinions I express represent my own folly.

marko

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8945
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #20 on: October 03, 2008, 01:15:19 am »

The new field manager looks promising. Very nice.

The first problem I see is that now, we are unable to stop standard fields being written to file.
At best, I'd like to see the standard fields being editable, but at least, can we have control over whether they're written to file or not?

-marko

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4565
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #21 on: October 03, 2008, 03:38:19 am »

i like the new interface a lot. and the additions of the expression editor is great.

The new field manager looks promising. Very nice.

The first problem I see is that now, we are unable to stop standard fields being written to file.
At best, I'd like to see the standard fields being editable, but at least, can we have control over whether they're written to file or not?

-marko

i agree with marco 100%

thanks
 :)
gab
Logged

rjm

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 2699
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #22 on: October 03, 2008, 10:04:39 am »

i like the new interface a lot. and the additions of the expression editor is great.

i agree with marco 100%

thanks
 :)
gab

I agree with gab 100%. :)

Copyright field is still not editable.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 71418
  • Where did I put my teeth?
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #23 on: October 03, 2008, 10:05:43 am »

Copyright field is still not editable.
I'm not sure the copyright field should be editable. 
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 41953
  • Shoes gone again!
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #24 on: October 03, 2008, 10:07:23 am »

The latest build did make Copyright editable.  I think this is right, especially for photographers.

Are you sure you've got build 52 installed?
Logged
Matt Ashland, JRiver Media Center

rjm

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 2699
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #25 on: October 03, 2008, 10:34:21 am »

The latest build did make Copyright editable.  I think this is right, especially for photographers.

Are you sure you've got build 52 installed?

I am running 52.

I incorrectly reported problem, sorry.

Copyright is now editable, thanks.

I am however still seeing strange behavior. I edited Copyright with 13.0.52 saving changes to tags. I then went back to MC12 and updated library from tags but the Copyright data did not change.

Perhaps this is expected?? I remember using 3rd party tag editor to edit Copyright and MC12 did not recognize these changes either.
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 41953
  • Shoes gone again!
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #26 on: October 03, 2008, 11:42:28 am »

I am however still seeing strange behavior. I edited Copyright with 13.0.52 saving changes to tags. I then went back to MC12 and updated library from tags but the Copyright data did not change.

Perhaps this is expected?? I remember using 3rd party tag editor to edit Copyright and MC12 did not recognize these changes either.

The MP3 tagging system is different between MC 12 and MC 13.  You won't be able to migrate backwards using tags.
Logged
Matt Ashland, JRiver Media Center

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1570
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #27 on: October 03, 2008, 03:38:07 pm »

One I missed from my earlier post is Studio :)
I'm using this for both film production companies, and for some photosets. It's not that unusual for the actual studio and the distributor/ publisher to be different, whether this needs to be included as stock is debatable. (Are people using a single field for these two or not?)

Cheers

-Leezer-
Logged

skeeterfood

  • Citizen of the Universe
  • *****
  • Posts: 779
  • We're all just food for the skeeters.
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #28 on: October 03, 2008, 09:10:40 pm »

I'd also like to see Media Subtype either expanded, or allow us to add custom values.  I currently have created a separate Video Subtype field, since Media Subtype is so limited.

-John
Logged

darichman

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1350
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #29 on: October 03, 2008, 09:23:22 pm »

Yes, Studio is a good one.

Here are some movie related ones which others might find useful

Movie/Show
Actors, Director, Producer, Writers
Review, Synopsis, Tagline
Themes
MPAA
Studio, Released by
Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #30 on: October 07, 2008, 09:54:01 am »

I have been away a few days so I didn't have a chance to comment on this earlier.

In general I would not have requested any new library fields that do not have either certain mapped and commonly used tag fields in one or more of the supported file tag formats (like the standardized ID3v2 tags) or have coded functions that extend the fields' functionality*. For instance, the album, replay gain and track number fields are tied with other functions in addition to just showing the field values.

It has always been possible to define any user fields and I don't see a big advantage of predefining more custom fields unless they really add new functionality.

The changes I suggested followed this logic. The Grouping tag (TIT1) was intended for former iTunes users so that they can import it. I requested the Total # of tracks field because it could be used for checking that also the last track is present. Currently the complete album logic cannot detect a missing last track. Though a missing disc would be more unlikely to occur the Total # of discs field would follow the same logic. For example iTunes, foobar, Winamp and Mp3tag can show these two "total #" fields.

Since the MC12 beta I have written other tag requests in a memo. I intended test a few related things and rewrite it before posting the list here, but since I have not time to do that here's the list as it is now. The ID3v2 user fields part is implemented now.

Quote
ID3v2

Write album gain (would be usable for e.g. Rockbox users, the album peak value is needed for preventing possible clipping when album gain is used):
TXXX replay_gain_album_gain  (add the +6 dB correction)
TXXX replay_gain_albun_peak  - when the album gain value is automatically calculated store the highest track peak value

User fields:
Continue reading the old "comment" frames, but write the user and MC's proprietary tags in the TXXX format.
TXXX "name"  must be the actual field name -- not anything like "Media Jukebox: xxx"


FLAC

Fix the date problem. (Now it writes values like 2008/01/01 instead of 2008)

Change the replay gain tag format to follow the FLAC standard. Add the +6 dB correction to the file tags.


APE

Stop using the "Media jukebox" string in front of the tag names. It makes the tags incompatible in both directions.

Replay gain: You could say that the current JRiver way is Matt's standard. However, it would be better to use the more common other style (i.e. replaygain_track_gain etc). Add the +6 dB correction to the file tags.


Ogg Vorbis

Change to be identical with FLAC tagging.
-- except with embedded cover art which does not have an "ogg standard". Continue using text encoding for cover art.


WMA

Does MS recommend adding a creator sepcific identifier in front of the field name? (MC uses JR/) I have seen some other programs doing similar thigns, so maybe the behavior is correct and should not be changed. WMP does not allow user tags so the proprietary name is probably a non-issue if all WMP generated tags can be read.

Change the Replay Gain tags format. It could be made compartible with Winamp and foobar (these appear to be using the replay_gain_track_gain, etc format).


MPC

Stop using the "Media jukebox" string in front of the tag names. It makes the tags incompatible in both directions.

Change the Replay Gain tags format (MPC has always had its own standard).


*EDIT

Though a standardized set of video specific fields would be good for the default video view and for a future online database if you ever intend to create one.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4565
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #31 on: October 07, 2008, 10:38:09 am »

is there a reason why it is not possible anymore to change the 'store is tag' option for the standard library fields. since mc rearranges all list fields i dont want mc to write for instance people to my pics. seems not be possible to protect the files for that and leave them open for other changes.
Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #32 on: October 07, 2008, 11:52:23 am »

is there a reason why it is not possible anymore to change the 'store is tag' option for the standard library fields. since mc rearranges all list fields i dont want mc to write for instance people to my pics. seems not be possible to protect the files for that and leave them open for other changes.

I consider it as an unwanted feature reduction (unless it is just a bug that will be fixed soon). I have currently a few standard fields set to not write tags.

Actually, as I have requested earlier I would like to see the following added:

Just as an additional idea that I had while tagging my files yesterday, I want a large quality image for my music obviously but storing a 500kb image file in all my images resulted in a 5Mb increase in the album size. Doesn't sound like much but when you times this but 100 albums I have suddenly lost 500Mb of space on my mp3 player.

I have suggested a solution that would make possible to keep the linked image file independent from the image that is possibly stored in the file tags:

I have a suggestion. The Image File field has the usual option to store in file tags when possible. In some old version it was possible to enable it and write the cover art link to a file tag as a comment, but the option has not worked for a long time.

Would it be possible to change this tickbox to toggle between the new and the old behavior? When enabled MC would rewrite the tags and remove the embedded image if present. When disabled MC would not rewrite the tags.


By unticking the field specific option you could preserve the embedded image even when you link a different external image file.

My personal need would be to prevent MC from invalidating my media backup sets when I just add or change external cover art (I don't use embedded cover art), but another use could be to have a small embedded cover art image in the file tag for external player devices while MC uses an externally linked high resolution image for the main display.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

jgreen

  • Citizen of the Universe
  • *****
  • Posts: 2419
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #33 on: October 07, 2008, 08:54:55 pm »

I agree with alex, et al, and I would note that marko has also mentioned the issue with writing all-or-no standard tags to file.  He views this as a bug in his post, and I would too.  Hopefully, it is not something baked into the software.  After all, what possible value would this enforced feature reduction have to the user experience?
Logged

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4565
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #34 on: October 08, 2008, 04:47:40 pm »

I agree with alex, et al, and I would note that marko has also mentioned the issue with writing all-or-no standard tags to file.  He views this as a bug in his post, and I would too.  Hopefully, it is not something baked into the software.  After all, what possible value would this enforced feature reduction have to the user experience?
i do not think it is a bug. we would have heard something by now then. i think it is a choice the staff has made. but although they asked for feedback here (and in some other threads), and enough people did give feedback, i find it a pity that they wont feedback when their choices differ from the tendency of the posts in such a thread.
Logged

jgreen

  • Citizen of the Universe
  • *****
  • Posts: 2419
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #35 on: October 08, 2008, 05:23:48 pm »

Well, I'm not ready to predict the end of the world over this, but it is an odd change.  Since the (former) capability to speciify tag write-back was fairly buried in the GUI, there wasn't much risk of it confusing the unwary, and it wasn't even CLOSE to a risk of a "gotcha".  I'd sure like to see it changed back, but like I said, it may be baked in under several layers of merengue. 
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 71418
  • Where did I put my teeth?
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #36 on: October 08, 2008, 05:57:32 pm »

Revolt!
Logged

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4565
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #37 on: October 09, 2008, 02:41:42 am »

Revolt!
maybe later! today i'll start one against all those designers who think the on/of switch belongs at the back of equipment.

Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
[Off Topic] Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #38 on: October 09, 2008, 02:58:00 am »

[OT]
maybe later! today i'll start one against all those designers who think the on/of switch belongs at the back of equipment.

Could you include the designers who do not add a main on/off switch? I just got a new electricity bill and after reading it I roughly calculated how much all the connected power adapters and other stuff without a main power switch around the house use electricity without doing nothing. The total amount wasn't insignificant.
[/OT]
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

bytestar

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1266
  • Alpha/Betatester
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #39 on: October 09, 2008, 12:53:03 pm »

Please Support: ISRC this is the Field TSRC

ISRC – the international standard recording code, use this codes can be a track worldwide uniquely identify.
Logged
Official Microsoft © product tester.
Download the latest language file https://1drv.ms/u/s!AnQ3L_bTnnzv4otXL9-G4rUj9wX6Tw?e=TLGgjb (is constantly updated)

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #40 on: October 09, 2008, 02:49:49 pm »

MC does not read and store the ISRC codes from audio CDs. Many factory made CDs have that info stored in a subchannel, but not all, and not all drives can read the ISRC codes even if they exist.

I suppose JRiver could easily add a new library field that would read and write the ID3v2 TSRC frame in MP3 files, but how would you like to use the field? It would not provide any functionality inside MC.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

bytestar

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1266
  • Alpha/Betatester
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #41 on: October 09, 2008, 03:21:58 pm »

That not right you can read it here...

http://www.ifpi.org/content/section_resources/isrc.html

Quote
The ISRC (International Standard Recording Code) is the international identification system for sound recordings and music videorecordings. Each ISRC is a unique and permanent identifier for a specific recording which can be permanently encoded into a product as its digital fingerprint. Encoded ISRC provide the means to automatically identify recordings for royalty payments.

The International Federation of the Phonographic Industry (IFPI) recommends that all music producers use ISRC.

Would therefore be a field in MC very helpful with its help could man a title uniquely identify.

Using the ISRC codes can be found a copy of a song undoubtedly very quickly, of course only if the ISRC exists but with many sampler it would be useful.

MC does not read and store the ISRC codes from audio CDs. Many factory made CDs have that info stored in a subchannel, but not all, and not all drives can read the ISRC codes even if they exist.

I suppose JRiver could easily add a new library field that would read and write the ID3v2 TSRC frame in MP3 files, but how would you like to use the field? It would not provide any functionality inside MC.
Logged
Official Microsoft © product tester.
Download the latest language file https://1drv.ms/u/s!AnQ3L_bTnnzv4otXL9-G4rUj9wX6Tw?e=TLGgjb (is constantly updated)

bennyd

  • Citizen of the Universe
  • *****
  • Posts: 1307
  • Project Leader
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #42 on: October 11, 2008, 12:58:22 am »

Isn't it possible to have a custom date field where we can enter our own dates and where we can do a search on by date ?
Logged
may U live 2 see the dawn

bennyd :-)

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4565
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #43 on: October 11, 2008, 01:40:44 pm »

i do not think it is a bug. we would have heard something by now then. i think it is a choice the staff has made.

i guess i was wrong about that.  ;)
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #44 on: October 11, 2008, 03:18:34 pm »

Several different lines of thought:

- I've been using MC 11/12 for some time now and am comfortable with defining and using custom fields in Flac files.  None of the proposals for more built-in fields will be essential to me (as a Flac user.)

- I use the Flac format except for an iPod library in MP3 format and MP3 Amazon downloads.  I'd like to see a table that shows the mapping of MC 13 fields to tags in each supported file format.

- I discuss and recommend MC 12 in other forums.  I especially recommend MC 12 to people with a classical music library.  It isn't obvious to newcomers what you can do with MC that is different or better compared to other players.  It is even less obvious to newcomers how to accomplish what they want to do in MC.  If you define more built-in fields, you need to make them understandable and usable to newcomers. This requires additional view schemes and much better how-to documentation.

- I see endless arguments about the one right way to handle compilation Cds and various artist Cds.  MC could provide a superior solution to these situations.  A multi-value performer or soloist field could be a huge win.

- I would hate to see changes to the standard fileds such as Artist cause problems when music files are edited 0or consumed by iPods or even tag editors.

- Someone mentioned wanting a better out-of-box experience for MC 13 in another.  He was talking about skins.  I think that making MC 13's superior functionality accessible and obvious to newcomers and people considering MC is far more important.  Adding view schemes that use these new fields (and the Composer field) would help.  How-to documentation would really help.  Filling out more fields from YADB would help.

Bill

Logged

MrHaugen

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 3774
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #45 on: October 13, 2008, 02:54:17 am »

Please add "Supporting Artists".
Would make things a lot cleaner than it is to day when you have to have many names in the artist field I think.
Logged
- I may not always believe what I'm saying

vkostas

  • Recent member
  • *
  • Posts: 8
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #46 on: October 15, 2008, 02:31:23 am »

Sorting Fields are used by a lot of users therefore would be better to maintain centrally the correspondence of normal values and sorted ones. E.g.
Rod Stewart - Stewart, Rod.
The  Eagles - Eagles, The
In Flames - Flames, In

A (new) function should be used to derive dynamically the sorted value. If a value found in the correspondence values list it will be returned otherwise the normal value will be returned. The search wouldn't take long since the correspondence is accessed using binary search.
Multiple values can be entered to normal value (e.g several artists) the function should be able to automatically build the list of components and for each of those to execute the (same) function and at the end to return all sorted values concatenated and split by list separator.
So function should be of format Sorted value=funcSortedValues(normal value).
normal value: Rod Stewart;Sting;Bryan Adams
funcSortedValues: the (new) function to calculate sorted value
Sorted value = Stewart, Rod;Sting;Adams, Bryan
Should function have one more (optional) parameter List separator On?

This way can be feasible to remove starting articles from sorted values also and not to be limited by the (poor) standard logic (which uses only A and The).

What do you think?
Logged

MusicHawk

  • Citizen of the Universe
  • *****
  • Posts: 796
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #47 on: October 16, 2008, 11:01:41 am »

I use a bunch of custom fields, which are "almost" covered by the proposed new standard fields. But with some subtle but useful differences...

One underlying hope is that all fields, or at least all fields that don't break anything, could be more configurable, as suggested elsewhere by various people including me. Specify how a list pops up, whether stars or values are used, whether the field is read-only, derived via an expression, etc. Many of the desired capabilities exist in MC; the hope is to make them available for every field.

My custom fields:

Rank (instead of Rating) = I don't use the standard Rating field because I discovered it is too easy to mess up the value. One inadvertent click, maybe an unnoticed click, on the stars in the tag window or a column, and the Rating value is changed without confirmation. I spent a zillion hours rating my 80,000+ tracks and can't risk unwanted changes, so I added a custom Rank field that also accepts values 1 - 5. As a "normal" data field, changing the value requires a bit more action which protects it. My big hope is that the Rating field becomes more controllable/protectable so I can copy my Rank values back to Rating and use it. A big improvement would be to allow the Rating field to be set to display just the value rather than stars, so editing it behaves like other fields. And maybe provide this per-column so stars can be displayed read-only. If the Rating field can't be "improved", my second hope is that I could display read-only stars for my custom Rank field.

Artists (in conjunction with Artist) = One of my two MC power-tool fields. This is a multi-value field that lists all the notable artists on track. I use the standard field Artist for the exact artist name as stated on the recording, and Artists to identify the performers in a standard way across all their recordings, bands, etc. The names are in format "Last, First" so this becomes the consistent way to locate recordings by an artist who might have been in a variety of bands, or varied the band's name, etc. Very useful in Jazz and Classical, but also helpful in quite a few rock/pop/folk recordings. The standard Artist field, because it contains the exact artist as stated on the original recording, is nice to display during playback, but otherwise it's never used to group or select music. The custom field Artists does it all.

RecSource = CD, LP, 45, CS (cassette), AT (audio tape), VT (video tape), AC (aircheck), etc.

ID = Used for essentially the same purpose as the new UPC and Catalog # fields. My main purpose is to identify where in my shelves of stuff I got the tracks, in case I have to go back and re-rip. So I enter whatever info I have, preferring UPC but there's no such thing for pre-CD-era recordings, and I often don't know it for purchased downloads. So I use the vinyl album/single's catalog number, for instance.

RipInfo = Helps me know when I ripped, since it is often different than any date tracked by MC. Usually in format 20081016-MH (YYYYMMDD-initials), the same format I've always used for comments in source code of apps I've written.

Recording = S (Stereo), M (Mono), R (Rechanneled), 4 (4-channel), etc. This helps me realize when I don't have a desired recording type, and helps differentiate when I have multiple desired recordings of the same track, sometimes needed because lots of 1950s-1980s recordings were issued in mono and stereo but are different mixes, edits and/or takes (notorious situation with Motown, Beatles, Beach Boys, and many more).

RecVer = Something to distinguish multiple recordings of the same song by the same artist. The RecVer value varies depending, might be ALT or ALT1, ALT2, or LIVE, or whatever.

Performance = Vocal, Instrumental

Tempo = Sort of like fields Mood and Situation and others, just a basic way of knowing the overall feel of the track: B (ballad), M (medium), U (up-tempo)

Chart = highest Billboard chart position (using Joel Whitburn's book).


Keywords = My other MC power tool field. I use this standard field for a variety of dissimilar data that arguably could/should be better in separate fields, but since I then extract it via expressions and smartlists, tossing it all together works. For instance...

Decades -- I have a set of Keywords values for every decade (1990-2000, 1980-1989, 1970-1979, all the way back to 1890-1899). I also use the Year field for the year of the original recording, but I don't always know the exact year, so decades is a useful (if arbitrary) way to group similar music vintages.

Type of music -- Rather loose notion, but with many more values so much more precise than Genre, given the many sub-genres that might be used. Also helpful for other types of "find it later" keywords, such as "car" for songs about cars/driving, surf, live, summer, dining, motown, beatles (beatles songs no matter who recorded them), tropical (my wife's fav), italian, french, and many more. I use these values to build any desired type of smartlist.

Instrumentation -- I'm a musician so like to identify tracks that are primarily piano, guitar, sax, horns, symphonic, kazoo, whatever.

Purpose/Nature of music -- Another loose notion, but useful to identify christmas, comedy, children, novelty, historic, and all kinds of other terms that would help me locate certain recordings among tens of thousands.




Logged
Managing my media with JRiver since Media Jukebox 8 (maybe earlier), currently use Media Center for Audio/Music and Photos/Videos.
My career in media spans Radio, TV, Print, Photography, Music, Film, Online, Live, Advertising, as producer, director, writer, performer, editor, engineer, executive, owner. An exhausting but amazing ride.

hit_ny

  • Citizen of the Universe
  • *****
  • Posts: 3310
  • nothing more to say...
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #48 on: October 25, 2008, 07:19:32 am »

Sorting Fields are used by a lot of users therefore would be better to maintain centrally the correspondence of normal values and sorted ones. E.g.
Rod Stewart - Stewart, Rod.
The  Eagles - Eagles, The
In Flames - Flames, In

What do you think?

or even Artist A & Artist B = Artist B & Artist A

I did think of the exact same thing but wondered whether it might be too expensive in terms of CPU  ?

..so i dropped the idea.
Logged

vkostas

  • Recent member
  • *
  • Posts: 8
Re: Adding New Database Fields [FEEDBACK WANTED]
« Reply #49 on: October 28, 2008, 05:43:56 pm »

or even Artist A & Artist B = Artist B & Artist A

I did think of the exact same thing but wondered whether it might be too expensive in terms of CPU  ?

..so i dropped the idea.
Multiple artists are separated by list separator so no need for "Artist A & Artist B = Artist B & Artist A" (unless I misunderstood smth here).
Sorted fields can be updated on request from their corresponding fields (so no need for calculation on-the-fly of sorted fields) and excessive CPU usage is avoided. I think the idea to keep centrally the link between Normal value and Sorted value is still a good idea.
Logged
Pages: [1] 2   Go Up