Print

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

[CSB]

I'm looking to update my photo and video repository with keywords to allow searches by person, places, events etc.
When the image keywords are updated in the file the file changes so my automated backup/replication will end up copying and replacing every image file to every repository.
(Let's hope I don't change my mind on any keywords...)
I'd like to see an option to sidecar the tag data (or just the updated tag data or keywords) for all files, image and video.
That way the image files would never change and only the sidecars would get backed up/replicated as is the case for video files.

Searching the forums I see this has been requested as far back as 2010 but I didn't find any discussion of it.
Thanks

[glynor]

I'd like to see an option to sidecar the tag data (or just the updated tag data or keywords) for all files, image and video.

+1

[RoderickGI]

What happens if you write protect the files? Does that force MC to save the tags to a Sidecar file instead of in the file, or does it just fail? I haven't checked.

Another partial solution is just to go into "Library & Folders > Manage Library fields" then select "Only fields saved in tags" from the drop-down list in the top right of the dialogue, and uncheck "Save in file tags (when possible)" for any tags that you don't want to save to the files. The tags would then only be stored in the Library, so you would want to make sure that you backup your library very regularly, and probably point those backups to the same safe location your image file backups are stored. But that would (should, again I haven't checked) stop tags being written to the files.

Of course, if the image files have in fact changed you would want to back them up in the new state. If the real issue is that you are getting continuous backups of files as you work through the tagging process, then turn off the file based tagging for the fields you are using, then when finished turn that back on and run "Update tags form library" for the affected files. All updated files would then be backed up just once, and you could run the "Update tags form library" progressively for groups of files so that all files aren't backed up at once, but instead you get progressive backups in smaller lots.


QED.

[glynor]

What happens if you write protect the files? Does that force MC to save the tags to a Sidecar file instead of in the file, or does it just fail? I haven't checked.

It fails. Does the attempting to Save Tag Changes in the Status Bar thing, and eventually pops up the failure message.

You can turn off tag writing entirely. But that puts a lot of pressure on your Library backup scheme, and doesn't allow any kind of metadata interchange.

FWIW, my +1 is less about not wanting to modify files that do support embedded tags, than:

• I want to be able to "embed" tags (for exchange and external use) in file types, other than video, that don't support embedded tags in MC. PSD, DOCX, and PDF files, for example.
• Even for file types that do support embedded tags, in many cases the support (aside from audio files) is quite limited and doesn't support all of the metadata you might want to interchange with other copies of MC.

[RoderickGI]

doesn't support all of the metadata you might want to interchange with other copies of MC.

Ah yes, you have some special requirements in that regard, don't you? Multiple copies of MC to support for work or something?

I was just offering an alternative. But I guess it would be nice to have, keeping the original file "pristine" if you like.

Carry on.

[Daydream]

Since we're talking about images... I wish MC supports a proper IPTC standard first, and then we can worry where to save the respective metadata.

[JimH]

Since we're talking about images... I wish MC supports a proper IPTC standard first, and then we can worry where to save the respective metadata.

Please start a thread with details.

[MusicHawk]

MC needs to support the modern metadata standards.

And, if there's an option to force image file sidecars, it must be an option, not disabling embedded tags, because having an image contain its metadata is wonderful. Relying on an external app or related file to explain the image is not wonderful or even reliable.

As photo files get shared, and then handed down through generations, it is essential that they be self-descriptive. So many old paper/scanned and even digital photos are mysteries -- who, what, where, when is unknown, a tragedy really. Standard embedded metadata is the solution.

[glynor]

And, if there's an option to force image file sidecars, it must be an option, not disabling embedded tags, because having an image contain its metadata is wonderful. Relying on an external app or related file to explain the image is not wonderful or even reliable.

To be clear, I totally agree. I'd like the sidecars to be available for file types other than Video, but just like video files, not to be exclusive (to still allow embedded tagging where embedded tags are supported).

Ah yes, you have some special requirements in that regard, don't you? Multiple copies of MC to support for work or something?

In almost all cases, the special work stuff I use MC for is all about video files, and so MC's existing sidecar support for those works fine. My desire for this is not really that special, and not for work purposes at all, generally.

Here's a use-case I encounter frequently: Copying files to a laptop for travel use.

If I am going on a trip and I have a set of files I want to take with me for use "offline" when I won't be able to connect back to my home server (or where such access will be inconvenient or intermittent), I'll often load up a set of files onto the local disk of my laptop and take them with me.

When I copy over video files, it works brilliantly. MC imports the files, and all of their metadata comes in intact. They fill into my Views just as they would at home, and everything is wonderful. Similarly, most music files come in fine with their metadata intact, because these file types generally support embedded tags.

But, for lots of other file types, they import completely fresh and lose all of their metadata. In particular I encounter this frequently with eBooks, Images, and other "document" file types. But, there are even some music files I have that don't support embedded tags because they're in a weird file format. If these files had sidecars, I'd copy them over, and they'd import with all their metadata. But, since they don't support (much, if any) embedded metadata, when I copy them over, I have no easy way to preserve the metadata for this independent copy.

[Yaobing]

I am working on this, and propose the following:

Change the option "General\Importing & Tagging\Store tags in external sidecar files if the file type does not support tagging" to

"General\Importing & Tagging\Store tags in external sidecar files" and offer three exclusive choices:

1. Use sidecar when a file can not be tagged.
2. Use sidecar even if the file can be tagged, and write data in both places
3. Use sidecar even if the file can be tagged, but only write to sidecar.

We will also need to add a new option

"General\Importing & Tagging\Apply the above rule for", with choices video, audio, and image.

That would take care of sidecar writing.  However, when reading from tags, we are faced with the question of where to get data from, the embedded tags or the sidecar (if exists).  A file may have readable embedded tags even if we can not write to the tags.  There may therefore be some messy situation when data from embedded tags are different from data in the sidecar files.

Is it reasonable to always use the sidecar file for reading tags if one exists?

Comments and suggestions are welcome.

[CSB]

Your proposal of the three choices sounds great.

Another reading from tags option.
When reading tags both sources could be used, embedded and sidecar. Preference could be given to the sidecar by reading the embedded first and overwriting. Or the file dates could be used to set the preference. After combining the metadata, the metadata would be updated/stored according to the three options.

A nice to have, would be a utility to write the sidecars to embedded, should a person want to change the scheme (from option 3 to option 1 or 2) at some point.

Thanks

[glynor]

Wow. Thanks, Yaobing! Your basic idea sounds perfect.

However, when reading from tags, we are faced with the question of where to get data from, the embedded tags or the sidecar (if exists).  A file may have readable embedded tags even if we can not write to the tags.  There may therefore be some messy situation when data from embedded tags are different from data in the sidecar files.

Is it reasonable to always use the sidecar file for reading tags if one exists?

IMHO if both a sidecar and in-file tags exist at import, then the Sidecar always wins.

Reasoning:

The sidecar files are basically a MC-only file format, and can be expected to only exist if the file had been previously used in MC itself. They are, by definition, MC-specific, and they can contain data types specific to MC in some cases where the values can't be cleanly embedded in the files. Whereas the embedded tags could have existed from when the file was originally created, and may have dubious value (especially if the user chose option #3 above).

Additionally, if this is the behavior, then working around it for the user if they want the reverse behavior in a particular instance is simple: delete the sidecar file and re-import. On the other hand, if you have MC do the reverse at import (and always trust embedded tags over the sidecar file) then working around it will be very difficult without adding crummy "conflict resolution" logic to MC (which would stink).

[glynor]

This small tweak might be a little cleaner and more easily understood:

"General\Importing & Tagging\Store tags in external sidecar files" and offer three exclusive choices:

1. Use sidecar when a file can not be tagged.
2. Use sidecar even if the file can be tagged, and write data in both places
3. Use sidecar even if the file can be tagged, but only write to sidecar.

Add Option 0: Do not store tags in sidecar files. Default to 1.

We will also need to add a new option

"General\Importing & Tagging\Apply the above rule for", with choices video, audio, and image.

Rename this:
General > Importing & Tagging > Create external sidecar files for Media Types:

Also, please include Documents. The main thing I want these for are for document media types.

And disable this option entirely if Option 0 is selected above. Default to Video-only selected.

[RoderickGI]

Are you proposing that there are separate rules for each file type?

It doesn't sound like it, but that may be what people want to do. Like now, sidecar files for video, and not for audio. Yes for PDF, no for images. Maybe.

It would make the whole thing more complex, but also way more flexible.

[glynor]

It would make the whole thing more complex, but also way more flexible.

That sounds like it would make the UI too complex, and is probably not worth it, IMHO. Also, beggars being choosers and all that.

[JimH]

Maybe something in between might work.  No sidecars for images, for example. 

I believe that the requests for expanding sidecar support have usually been for documents.

[glynor]

I believe that the requests for expanding sidecar support have usually been for documents.

Documents are definitely my primary concern (mainly ebooks, but also other documents I have tracked in MC), though I definitely would also want them for a number of image-type files (PSD files, graphics, and other similar items I use for my desktop, the web, projects, etc).

It doesn't much matter in that regard because the above-described scheme could handle that just fine:

• Enable Option 1, 2, or 3 in Yaobing's option described above as you see fit.
• Enable whatever Media Types you want from the secondary option but DON'T enable Images.

That would allow you to write sidecars for Documents and Videos, but not Audio and Images. Or whatever combination you want. And, the defaults I listed above in my post would exactly replicate the current default behavior.

What RoderickGI was talking about was letting you enable Option 1 for [Audio], Option 3 for [Images], and Option 2 for Documents and Video. That would be a bit more flexible, as he said, but... It seems like such an unlikely edge-case that it isn't worth the UI complexity to me.

But, your app. I'm not the boss. Do it as you see fit. I'm just very excited that I might be able to have persistent tags for my Images and Documents!

[Yaobing]

As glynor said.  I was proposing using the same rule for audio, video and image, which ever is enabled.  I thought about giving each individual file type separate rule but decided it was too complex. 

[JimH]

Let's do documents and video for now, then return to this later if necessary.

[Awesome Donkey]

I'm sure this would come in handy for those who use SACD ISOs.

[JimH]

I'm sure this would come in handy for those who use SACD ISOs.

Ok.  You're right.

[leezer3]

If we're working on sidecars, please can we have the option to store these in a sub-folder?
(e.g. .jriver or something)

Extending the current setup to images etc. is great, but creating one sidecar per file in a folder containing 200+ images (a typical album here) creates a massive mess.

[JimH]

If we're working on sidecars, please can we have the option to store these in a sub-folder?
(e.g. .jriver or something)

Seems reasonable.  Or put them in one directory, similar to cover art.

[Hendrik]

Sidecars are a backup of the database tags, as such one key requirement is to be able to easily associate them to the file they belong to, even if your MC database is empty - that means a central directory like Cover Art is out (already got your MC database as a central storage place, afterall). A sub-directory might work, but it might be tricky.

[JimH]

Yaobing added sidecars for the other filetypes in MC24.

[Yaobing]

If we're working on sidecars, please can we have the option to store these in a sub-folder?
(e.g. .jriver or something)

Extending the current setup to images etc. is great, but creating one sidecar per file in a folder containing 200+ images (a typical album here) creates a massive mess.

The sidecars are called sidecars for a reason