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!

Many thanks for implementing my request! And sorry for not getting back in time. I will soon try to test this tool. (Easier for me now that it is included in the AppImage).

On the discussion above: I think it it would indeed be better/more robust for this tool to scan the asset files to get the uuid<->file mapping in the directories specified by -d. For both Interop and SMPTE. (Or at least make it an option.) I would suggest the following:

• mxf files: Straightforward, the uuid contained in the file.

• cpl files: used as is

• cpl files: used as is

• Interop font files (.ttf and .png). the files location could be found by looking at the contents of the <LoadFont> and <Image> elements. The uuids for these files (.ttf and .png) are made up in the original ASSETMAP and PKL files, i.e. the dont really exist in the files themselves. New ones should be made up in the newly created PKL and ASSETMAP files created by dcpomatic2_map (do not reuse the "old" uuids for .tff and .png files!). This is possible because only the subtitle xml (not the font files) are referenced in the CPL.

The above is a useful feature to have because then you can make a complete, self contained package, from DCPs exported from Dolby DSS-servers. Older versions of their software export ONLY .mxf CPL and subtitle files when you offload to an external disks. This make these kind of backups hard to use on other servers. Something that dcpomatic2_map is able to fix if what I describe above is implemented. I know many cinemas that have several "archive" disks created from the DSS gui in this way.

What I describe above is also what the Dolby DSS software does internally and places in the "generatedPackages" directory. If you ftp into a DSS server and navigate to generatedPackages/<cpl uuid>/ you can download from there a complete DCP package: cpl, mxf, subtitle files - unchanged; pkl, assetmap, volindex - regenerated.

To have the same functionality in dcpomatic2_map would be really useful.

Thank you for considering this feature request.

@carl the requests in the previous comment need breaking out into other bugs