INTERACT FORUM
More => Old Versions => Media Center 13 (Development Ended) => Topic started by: Matt 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?
-
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.
-
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-
-
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
-
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.
-
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.
-
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.
-
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 (http://yabb.jriver.com/interact/index.php?topic=45824.msg314108#msg314108)
-
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
-
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.
-
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 (http://yabb.jriver.com/interact/index.php?topic=44885.msg307499#msg307499)
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.
-
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 ;)
-
Would like a Rating2 field that uses the 5-star format. Better yet, let us create user-definable fields with a 5-star format.
-
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.
-
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.
-
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
-
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.
-
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...
-
New interface is excellent.
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 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...
-
Love the new Manage Library Fields.
-
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 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
-
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.
-
Copyright field is still not editable.
I'm not sure the copyright field should be editable.
-
The latest build did make Copyright editable. I think this is right, especially for photographers.
Are you sure you've got build 52 installed?
-
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.
-
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.
-
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-
-
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
-
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
-
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.
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.
-
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.
-
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.
(http://www.adart.fi/mc/pix/imagefile.png)
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.
-
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 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.
-
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.
-
Revolt!
-
Revolt!
maybe later! today i'll start one against all those designers who think the on/of switch belongs at the back of equipment.
-
[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]
-
Please Support: ISRC this is the Field TSRC
ISRC – the international standard recording code, use this codes can be a track worldwide uniquely identify.
-
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.
-
That not right you can read it here...
http://www.ifpi.org/content/section_resources/isrc.html
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.
-
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 ?
-
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. ;)
-
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
-
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.
-
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?
-
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.
-
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.
-
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.
-
I'm not sure if this thread is audio only, but I would like to suggest a field that would allow me to display a full description of the video in theater view.
-
Some people have mentioned that having multi-artist list capability is not a big deal since most albums have onle one main artist.
This is very much NOT true of asian music, particularly Indian, which is almost always 2 or more equally important artists.
I have been waiting for a multi-artist list field that can be delimited by semicolon or &.
In fact a MULTI-GENRE list field would be useful. for example a song should be able to tagged as genre "soundtrack" and "rock" so that it shows up in the Genre panel under soundtrack OR rock. Again the '&' symbol or semicolon would be good delimiters.
Preferably the delimeter of your choice would be best.
The MAIN failure of Itunes and Ipod devices is this lack of functionality.
Media Center would be very much more useful if it could accomplish within the native artist and genre fields. Currently I accomplish it in a secondary field called 'Artists' and 'Genres' and it is a lot of extra work to create these fields.
Thanks and I hope you can work this in... massively important for my library!
-
maybe later! today i'll start one against all those designers who think the on/of switch belongs at the back of equipment.
we are two on this one
we may start a boycott campaign ;)
-
[OT]
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]
Here , in France , they say than around 20% of electricity bill is generated by on stand-by gear
-
I assume this post is about TXXX format , not the Comment a la Music Match from before.
In this case i would like very much a Country field [ asking is free , don't it ? :)
I have serious problems with classic
Most of the time the track name only is longer than the Windows allowed x characters
So i put a trunked track name in Name and full track name in Comment or custom tag
I would like to be able to see it in full in library.
On a second line
First line Artist -Album -trunked Name
And below the full track name
Not sure I'm making myself clear
-
Multiple artists are separated by list separator so no need for "Artist A & Artist B = Artist B & Artist A" (unless I misunderstood smth here).
Ahh but the default [Artist] field is not a list type field, so that's one of the workarounds i use for multiple artists.
So i would say Artist A & Artist B but some time later the same artists crop up but the names get reversed, technically its the same artists and should both be incld as the same [Artist] but its difficult to find when this happens.
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.
Not sure i follow what you mean.
Some people have mentioned that having multi-artist list capability is not a big deal since most albums have onle one main artist.
This is very much NOT true of asian music, particularly Indian, which is almost always 2 or more equally important artists.
I have been waiting for a multi-artist list field that can be delimited by semicolon or &.
You can already do this with custom list fields, the default [Artist] field is not of list type as it would be breaking the standard, i don't think there is a single player out there that could recognise MC's list type fields and vice versa with other players that support this functionality. It's all home made cos user's demand it.
Maybe they might include this functionality in an upcoming tag standard but i would not hold my breath for that to happen as there is a considerable lag between de jure standards and the defacto ones.
Most of the time the track name only is longer than the Windows allowed x characters
So i put a trunked track name in Name and full track name in Comment or custom tag
I would like to be able to see it in full in library.
On a second line
First line Artist -Album -trunked Name
And below the full track name
Not sure I'm making myself clear
Ooh la-la, now that's a revolutionary thought :D
-
First Sorry for my poor english.
I think the [Media Sub Type] field is very good. I have tried others fields in MC11 (and <) but sometimes i was blocked. I agree with all posts about this [Media Sub Type]. This field must be customized. Each person have some differents types of files like :
- Kids Films
- Kids TV Shows
- Live Entertainment
- Video Clip
- Live
- Shorts Films
- Series
- family videos
- Advertising
...
For each item the view (pane or not) can (or must) be different, for example series needs "saison", films needs genre, personal video need "people/events/place" ...
Two Ideas :
1 - Why not a pre-configured view for Known [Media sub type] ?
2 - Why not import informations from web Site for Known [Media sub type] like film (dvd picture, name, genre, actors, productors ...), video clip (year, name, genre, info artists ...), series, dvd ...
If those features exist, for each user value in this field you can attach a [Known type], for example "dvd film" or "kid film" or "Old film" will be attach with "Film" to have the same default view and use the same web site for importing informations.
This second point is THE missing feature in your software, I use j.river media center & jukebox for a long time, it's always the best for all his features and performances.
I talk about videos but it's the same for audio with :
- Kids music
- Kids audio book
- Radio talk
- fun
For Photos is certainly the same thing.
Best Regards and congratulations for this MediaCenter
-
Check out allmusic.com - there are some fields I'd like to see leveraged in Media Center. Here's a Mingus album for reference:
http://allmusic.com/cg/amg.dll?p=amg&sql=10:gxfyxqwgldte~T2
- Performance Date
- Recording Date: allow for multiple dates, span of time (*could* Performance Date for live performances, but I would want that field to be a single date. Perhaps this could even be a date select using a mini-calendar)
- Multi-select Genre, instead of free form combinations
- Credits: There was some discussion on this topic, ie other artists. I like "Credits" as it covers multiple ways of including other musicians, etc... But I'd like it to include what they are credited for - Drums, Alto Sax, etc...
- Album Time: ideally calculated from total track time, rather than manually input
- Label: seems obvious since you could get that album from multiple labels and is a staple insignia of the LP
- Styles, Moods and Themes: would be nice to have - also as multi-select
- Notes seems like an appropriate location for Reviews and Liner Notes, but maybe they could be separate
All of this is based on actually using the fields, but I've yet to see a way to customize any playback view so that i can add standard and custom database fields. When is there going to be a way to be able to specify the fields to display on playback visualizations included with this tool? G-Force could do it too, and I've posted the request there as well, but narry a response.
-
What I would like more than anything is an easier way to determine which field gets written to the file. I know that it is possible right now, but going to each field and editing is tedious. I would also like to see the fields divided by media type and a setting whether or not the write the field according to the related media type. For example, I would like for MC to tag my mp3's with standard tags only (no MC custom fields), but under no circumstances do I ever want it tagging my photos. As it is in MC12 (haven't tried 13 yet), I have to go to each separate field and edit this. I hate to see application specific tags in the files themselves, as I think that really deserves to be only written to the database and not the file.
One more thing I would like to have is control over the tag format. Currently I don't let MC write tags to the files, because for device compatibility I need all my tags in ID3 v2.3 ANSI only (no unicode support in my car) and MP3Tag and dbpoweramp let me use this option. I think this should be a user choice in MC as well.
If I am missing obvious options, please feel free to point me in the right direction.
-
Does the IPTC core "creator" field have a mapped version in MC? If not I would like to see that added to the default list.
"Rights usage terms" would also be good. Even better if it had some default values such as the creative commons licenses and a default "all rights reserved". Even even better if this were read and utilized when uploading files to flickr.
I think it's time that MC started allowing metadata templates, so that we could have certain fields filled in by default when files get imported, and so that we could apply premade templates to files for quick tagging. I may start a thread on this.
-
How about a Last Synched field? Could be very useful for those players for which MC can't get play stats. I can't on my new Zen. Combining a Last Synched with a Last Played (on MC at home) could be great to always have fresh playlists.
-
MC 13 desperately needs an easily workable field for classical music. I custom made a field with three parts: "Composer, Work, Performing Artist(s)" eg Beethoven, Symphony no 9, Bernstein/NY Philharmonic" It works like album in that it refers to a groug of tracks, ie movements in a classical work. Could you improve on this by having a default field like this, but one that has standard grammar or spacing so the result will be uniform. You want all the the Beethoven Symphony no 9's to line up together.
-
MC 13 desperately needs an easily workable field for classical music. I custom made a field with three parts: "Composer, Work, Performing Artist(s)" eg Beethoven, Symphony no 9, Bernstein/NY Philharmonic" It works like album in that it refers to a groug of tracks, ie movements in a classical work. Could you improve on this by having a default field like this, but one that has standard grammar or spacing so the result will be uniform. You want all the the Beethoven Symphony no 9's to line up together.
There is a good thread going on Classical somewhere here. It's recent. You can find a link to it in our Wiki on the Main Index page. See above for the Wiki link.
-
I have custom MC12 db field "Style" - semicolon delimited list, like and from discogs. Now this incompatible with MC13.
request - customized Data Type for style tag.. and search by "contains" in semicolon delimited list fields in smartlists if this possible )
-
I have custom MC12 db field "Style" - semicolon delimited list, like and from discogs. Now this incompatible with MC13.
request - customized Data Type for style tag.. and search by "contains" in semicolon delimited list fields in smartlists if this possible )
Could you start a new thread about the problem and describe it a bit more?
List style fields should be fully supported in MC 12 and MC 13.
-
Label would be a useful default field for me, but I could see what it would just be in the way for many people. (It doesn't add much function for most, but for me it would)
I think what I'd really like to see is a way to map a custom user field to its associated data in an ID3 tag. I'm auto-importing from MusicBrainz, and my custom Label field does not import the data saved by my auto-tagger (which also calls the field "Label" in its GUI).
+1 for unlocked [Media Sub Type].
Actually unlocking any fields that won't break the program seems useful too.
-
Didn't notice this thread until now. Mapping of MC db fields to arbitrary tag fields would be my preferred, and in my opinion the most efficient solution.
-
i really would like to see the field timestamp in MC, so you know what file you changed last.. especially important for files that you can NOT write tags to. Also the internal (File Key ID) would be nice (for exporting data)