New Project old metadata.xml

[Jean Paul]

Hi,
Planning to move to DoM from EasyDCP, for price and some advantages, the option to share the system keys between station feels so safe!
Before taking the leap I wanted to be sure to have understood properly something.
I went through the whole manual and I came to understand that the metadata.xml file is basically what the dcpdigest is for EasyDCP that contains the native key for encrypted files. Not sure if exactly the same since I do not have an example of both at hand to compare.
My question is if I move to a different machine and saved the metadata.xml file of a project I will be able to create a new project set the metadata file with the backuped .xml and be ready to create new KDM? How do I import it?

On a side note metadata.xml is quite a generic name, not great for archiving. I assume it cannot be changed?

Thanks for your help

JP

[carl]

Hi JP

I went through the whole manual and I came to understand that the metadata.xml file is basically what the dcpdigest is for EasyDCP that contains the native key for encrypted files. Not sure if exactly the same since I do not have an example of both at hand to compare.

That sounds right. metadata.xml contains everything about the project, including the "plain" encryption key.

My question is if I move to a different machine and saved the metadata.xml file of a project I will be able to create a new project set the metadata file with the backuped .xml and be ready to create new KDM? How do I import it?

There isn't any direct interface for importing a metadata.xml. But you can just copy it to a new machine, put it inside a folder, then open that project (so long as you have all the media files at the right paths, or you edit the file paths in the metadata.xml). Then you should be able to open the project just as it was before.

However, if your aim is to make KDMs on a separate machine it would probably be neater and easier to use DKDMs; if all your stations share the same KDM decryption certificate chain you should be able to make a DKDM for a project on one machine, copy it to another, then use it to make KDMs there. That's the intended "workflow" for making new KDMs; it means you don't have to copy the whole DCP around everywhere.

There's no current way to change metadata.xml but one could be added - are you imagining a different name for each project?

[Jean Paul]

Hi! Thanks for the clear answer, and really quick.

There's no current way to change metadata.xml but one could be added - are you imagining a different name for each project?

In the manual is advised to save the metadata.xml. I haven't used the software yet, so maybe I got it wrong but if a project is a DCP, the DCP name would be a nice option. Or anything that could help identify it. Even if it doesn't do the KDM on its own but need to restore the whole project structure it is less needed since it won't really exist on its own.

However, if your aim is to make KDMs on a separate machine it would probably be neater and easier to use DKDMs;

Makes absolutely sense. The thought is more for cathastrophy backup. Like we can keep the DCPs on LTO or other long term option, or entrust it to a third party, But retain on cloud, always accessible, a metadata.xml so that no matter what I can whip up a DCP-o-MATIC and create the needed KDM. Clearly I could store the system keys too so that if I make a DKDM I am good too. (In Easy DCP any system with the Digest can generate the KDM without needing anything else, pointing out just to clarify what I am thinking of)
Probably just a different way of thinking indifferent systems.

Thinking in that direction it would be nice at the moment of encrypted DCP creation the option to generate some default KDM, like for my own server for QC and for the system for back-up?

[Carsten]

The idea is that the folder is the project file, not the metadata.xml within it. So, you can always archive the project folder.

[Jean Paul]

But I will need the DCP too to make the project work and create a KDM? Looking into something not too GB intensive as basically open key to store for KDM. But as said also an automatic self KDM would solve any problem. Just a different approach.

[carl]

Yes, at the moment you would need the DCP too. The nice thing about the DKDM is is packages up everything you need to make a KDM. The metadata.xml doesn't quite contain everything; for example, it doesn't have anything about any CPLs that might have been created, so you need the DCP to find that out.

[GOR4N]

I have 3rd party that needs "dcp digest file" delivered alongside with encrypted DCP that has been created using DOM.
They don't want DKDM for whatever reason.

As I can see looking in metadata.xml there are columns like:

<Digest>118eXXXXeb7b141f14d50bf3724ab000000114564620</Digest>
<Key>eXXXXXXXXc6c742b419e1e3100000000</Key>

If I send metadata.xml together with encrypted DCP folder will that work?
Is "dcp digest file" EasyDCP exclusive feature?

[carl]

It looks like a "DCP digest file" is a EasyDCP thing:

https://en.easydcp.com/support-faq.php? ... -kdm-files

easyDCP Creator+ generates a proprietary DCP digest file along with each encrypted DCP.

If anybody has an example of one of these "DCP digest files" we might be able to get DCP-o-matic to create them. At the moment, though, that's not possible.

[GOR4N]

Here is a sample that I found... had to ZIP it

It looks like a plain text file ...

[carl]

Thank you, that doesn't look too hard, I'll try and add it after 2.16.0 is done. Here's a feature request in the tracker.