Also somewhat related to my ancient feature request in Issue 0000243

Something I didn't mention that maybe is not obvious. For this dcpomatic2_map command everything except the newly generated PKL, ASSETMAP and VOLINDEX is to be kept untouched. Just (optinally) renamed files and moved/linked to another directory location.

Is it important that this tool is command-line based? I think the DCP-o-matic Combiner might also do some of this stuff, and could probably be extended to do the rest.

For me a CLI tool is essential, yes. As I would probably want to use it in scripts and on headless machines.

What I mean is probably clear by now, but just for completeness here is some explaining of this feature I did some time ago: https://github.com/Ymagis/ClairMeta/issues/188#issuecomment-792380106

As you can see this is functionality I really, really want :)

I've got a basic test version of this ready to go now - what operating system would be easiest for you to test on?

Linux would be the easiest to test on for me thanks!

Which one?

3a1ddb9e182be28a22c5bbc85c06ee6629b72fe6

Can I ask how the "search for assets" step works? Does it look for ASSETMAPs in the directories specified with -d, and locate the picture/sound/subs assets specified in the CPL from those? Or is it finding the assets by some other method based on filename etc.

@mhm mentions in https://github.com/Ymagis/ClairMeta/issues/188#issuecomment-792380106 that ASSETMAP and PKL are redundant information, and CPL contains everything you need to parse a DCP. But I don't quite understand how that works - doesn't only the ASSETMAP contain the mapping from UUID to file path?

Perhaps you can rely on other heuristics to locate assets in well-formed, valid DCPs made by common software. But from my experience on film festivals, we get sent all kinds of weird stuff! I've seen some cases where DCP folders contain detritus from a previous encode. i.e. amongst the "real" assets, you have other files which look like the ones you're looking for, but are actually from some other encode.

This new tool looks incredibly useful. It'd just be good to understand how it's working before putting it into service. I tried to figure it out from the commit, but I'm afraid I got lost where it calls into dcp.read(). I don't speak C++!

Can I ask how the "search for assets" step works

It looks for ASSETMAPs in the directories specified with -d.

@mhm mentions in https://github.com/Ymagis/ClairMeta/issues/188#issuecomment-792380106 that ASSETMAP and PKL are redundant information, and CPL contains everything you need to parse a DCP. But I don't quite understand how that works - doesn't only the ASSETMAP contain the mapping from UUID to file path?

I think you are right, though I think the only part of a DCP that does not contain its own UUID is an interop font file, so for SMPTE I think you could scan files, work out what they are (PKL, CPL, video MXF etc.) then not need the ASSETMAP any more.

Thanks for coming back. OK, that's clear. I'll give it a whirl in next few days.

If I've understood right, this tool also allows adding subtitles to an OV DCP without copying any files, which should be much faster than current method, which requires remaking the video+audio MXFs:

1. Create VF DCP using an SRT, and video+audio from original DCP just as references.
2. Use dcpomatic2_map with -l option to create a new OV with the subs from the VF's CPL.

Should take a matter of seconds, rather than current 0000001:0000001 hour. Nice!

I think that should work, indeed - not to say that the main GUI shouldn't do a better job in these cases!