Print

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

[mountainfair]

I was checking out the Library options,

Looking at editing the library fields and the 'store in filetags' checkboxes, so that I could see what fields would be updated in my tags if I turn the option 'update tags when file info changes'.

My concern is that I dont want to add a whole bunch of unneeded tags to my files, particularly I dont want to add new tag fields to my files that will remain empty. 

It would be great if you could see next to the list of library fields the checkboxes for 'store in filetags'.  Then you could see exactly which fields will be updated, and change them if you want, without having to go thru individually clicking 'edit' to do this.

Does anyone else have insights, workarounds, thoughts?

Any chance that this could be implemented in the next version?

[marko]

what a great idea!

currently, you either turn them all off globally, or do the edit/save shuffle. as far as I'm aware, that's as good as it gets atm.

[GHammer]

I'd like to have this idea implemented.
I'd be great to have the list of fields shown with the checkbox.

[runemail]

That would be very nice, better and easyer handling of whats stored in tags!

[Matt]

Empty fields won't get stored to a tag, so no worries there.

[mountainfair]

Matt -

Thanks for replying.

So, with blank tags:

say I have update tags turned on, and have the bios field checked to update.  If I update a file that doesnt already have a bio field in the tags, and I update only the existing tags, NOT the bio field, then the file will NOT have a blank bio field in the tags when I save it?

In other words, only the fields that are updated are changed in the file, and no fields are added unless they are updated?

[Matt]

say I have update tags turned on, and have the bios field checked to update.  If I update a file that doesnt already have a bio field in the tags, and I update only the existing tags, NOT the bio field, then the file will NOT have a blank bio field in the tags when I save it?

Correct.

In other words, only the fields that are updated are changed in the file, and no fields are added unless they are updated?

Not exactly.  After a change, MC will write all of the non-blank fields to the tag to ensure the library and tag are fully synchronized.  Still, you won't get blank fields in the tag.

Remember that Action Window > File Properties > File Type Info will give a full tag dump for most file types so you can see just what MC is doing.

[mountainfair]

Matt -

thanks for the confirmation.  I feel much more comfortable with editing tags in MC now.

So, can you clarify what the checkbox 'store in file tags' is for? 

If this is not enabled, this tag field will never be updated in the tags, and if its enabled, it will be updated in the tags IF this specific field is updated in MC AND 'update tags when file info changes' is turned on?

This is an additional level of control so that if I want to have MC update my tags, but dont want anyone to ever be able to update, say, the bios field in the tags, I turn that one off with the checkbox?  When would you actually use this and how?

I am a little confused.

[marko]

I got a little confused reading the posts above.

My understanding\interpretation is that:

the box is ticked.
Any changes made to the bios field in MC's library will be saved in the file. If the tag does not exist, it will be created.

the box is unticked
Any changes to bios field will be saved in the library only. if the tag exists, it will be removed the next time you change any other tag.

mountainfair, what this means, is that if someone changes another tag, rating for instance? that is saved to the file, MC does an "update tags from library" on the file, so, if the tag exists, and that box is unticked, the tag is removed.

What I'd like, and what I thought you were after, was to be given the ability to 'write protect' any given tag. So that if that box is unticked, existing tags were not removed by the "update library from tags" tool (or changing the rating of a track)
-marko.

[mountainfair]

the box is unticked
Any changes to bios field will be saved in the library only. if the tag exists, it will be removed the next time you change any other tag.

Whoa!

Deleting my tags?!!?  this is not what I understood it to do.  This is very concerning to me that it is not clear exactly what it does.

I have hesitated to do any tag editing with MC becuase of this lack of clarity. 

It should be obvious to new users and in the help files what exactly this function does and exactly how MC works when editing tags.  AMT it is not.

Matt or other admins, can you please clarify this for us?

[marko]

mountainfair, you can clarify it yourself using the 'file type info' tool described by Matt above (action window > file properties > file type info)

it displays the tags contained in the file.

create your own library field. call it anything you want, test, for example, and tick the save in file box.

now select a file. see its file type info? no test tag, right? change the rating of that track. still no test tag? refresh the window by selecting a different file, then re-selecting the test file. see it now?

I think this is all good.

now, go back and edit your test library field. untick the save files box, ok, go back to your test file and follow the steps above to see the tag removed.

this is a tough one because I can see times I'd want this, and others I wouldn't.

Your write-protect tick box idea is probably the best suggestion I've seen so far regarding this problem and I hope it gets taken up.

[marko]

I know that jriver are proudly defensive of their tagging mechanisms, and sometimes, with good reason.
Taking the above limitation into account,

Would a write-protect option be completely out of the question?

[marko]

Did this change recently?

After mucking around with my coverart options this morning, I notice that [bios], [lyrics], and [image file], if present in the files' tags are not removed during an 'update tags from library' when "save in tags (when possible)" is unticked.

This was definately not the case 19 days ago when I did the tests above.

I see that in the file type info window:
[bios] falls under "COMM (MusicMatch_Bio): i am a test bios"
and when "saved in file" it appears down the bottom of the window with all the proprietry MC tags, and when not saved in file, it moves up the list to be amongst the non-proprietry fields. MC doesn't remove it.

same applies for [lyrics], saved in a USLT tag, not removed
and for [image file], saved in an APIC tag, also, not removed.

Unticking the save in tags (when possible) for other proprietry fields, I tested with [rating] and a cutom 'string type' field, does remove them in an 'update tags from library' sweep.

Now I'm confused.
Are [bios], [lyrics], and [image file] now considered safe tags, and so, if MC is asked not to save them in the file, it won't, and at the same time, it will never remove existing tags of this kind unless by way of the 'remove tags' tool?

If I go that right, are there any other fields also protected this way?

and if I got that wrong, would someone please try and explain what goes on for me, one last time?
thanks:)

[mountainfair]

I think we really need a very clear and definitive 'how tagging works with MC, inside and out' guide/additional help section that clarifies all of this.

Otherwise, I will never use MC to do any editing - its just too mysterious to me what it will actually do.

I cant really comment on whether MC's tagging capabilities until we know how they work.

[datdude]

I think we really need a very clear and definitive 'how tagging works with MC, inside and out' guide/additional help section that clarifies all of this.

Otherwise, I will never use MC to do any editing - its just too mysterious to me what it will actually do.

I cant really comment on whether MC's tagging capabilities until we know how they work.

MC's tagging capabilities are pretty full featured so I think starting the other way around would be easier.

What specific questions do you have about MC's tagging?

[marko]

try mine from two posts ago for starters.

I try the same tests 19 days apart and get opposing results.

Is there a bug in the tagging engine, or are the current observations by design?

I was testing using mp3's. I suppose I should go back and do the same tests with each file type in my library.
Some kind of official clarification would be nice though.
I'll install .145 and reboot. see if that helps settle things down. :-|

[mountainfair]

datdude -

can you definitively clarify what the checkbox 'store in file tags' is for, and how it works?

Marko seemed to initially say there was a strong possibility of accidentally deleting tags - any tags that you have that are not 'checked' are deleted when you update OTHER fields.

Now he says that this has changed. 

I also originally had a concern that I might be adding blank fields if boxes were checked, and then the tags were updated without entering something in fields that were checked but did not previously exist. 

I received an anwer here, but there is no clarification or similar answer in the help files.  And it worries me to hear that these features may be changing in function without announcement - could spell disaster.

We need a definitive set of answers that belong in the upgrade info and help files.

[datdude]

My bad, I just looked at this thread again and realised how many posts were on it. For some reason I was thinking your last post before was the first, if that makes any sense.

I was thinking that the 'store in file tags' did what it says, but I guess not?

"I also originally had a concern that I might be adding blank fields if boxes were checked, and then the tags were updated without entering something in fields that were checked but did not previously exist. "

I'm confused, why is adding a 'marker' so to speak, so that MC can sync the DB with the tag a concern?

[mountainfair]

I guess it depends on how much space each marker takes on disk multiplies by tens of thousands of mp3 files...  seems like it could add up. 

And, if I ever want to stop using MC, how do I get rid of the markers?

[datdude]

I guess it depends on how much space each marker takes on disk multiplies by tens of thousands of mp3 files...  seems like it could add up. 

And, if I ever want to stop using MC, how do I get rid of the markers?

I would imagine not more than a few bytes since a Word doc with several paragraphs and pictures in it is not much more than 80 kb.

Good question about getting rid of it.  You could simply wipe clean the comment field of your mp3's within MC easily or I would think JRiver would know best otherwise.