Combining multiple DCP's into 1

[Jeff]

It seems to me like there is a misconception on what is the effect of making one package (DCP) for more than one compositions (CPL).
Making one DCP, does not mean:
Smaller data volume (the total difference will be a few kilobytes among a multitude of gigabytes)
That one will be ingesting them with one go (the ingestion process will be separate by a cinema media server, it may make a difference on a TMS)
A player will play them together, and/or in a particular order (when ingested, the original CPLs/DCPs will be counted as different)

So, there is no time saving that one wouldn't achieve similarly by grouping more than one DCPs as subfolders to another (folder).

With the resulting package being the same size (practically) as the three packages, storage or transfer would cost the exact same. The only remote possibility for saving money there would have been a service that would count the package list files (instead of the composition playlists or total data volume) to charge for storage and/or transfer.

I would consider making a package out of different CPLs (that one is not an alternative version of another in some manner), increasing complexity. Not a wise thing to do.

Thank you Ioannis, yes, I did have a quick look and no real file size difference between calculating x3 individual DCP's and the x1 combined package. Do you know - more out of curiosity - if DCP packages are/have been zipped (after creation) - does that make much of a difference to transferring or does it mess with the data at all?

[Carsten]

Can you supply three of your original full CPL names here?

Also, I think StephW is wrong (or understands your intention wrong). When combining a Multi-CPL package, the CPLs do not have to have identical image and audio parameters - they are allowed to be all over the place. Because it's only a package, there are no OV/VF dependencies within such a package as such. For instance, I know that in the US it is/was common habbit to wrap hundreds of different movie trailers into one DCP, all from different sources. The only thing they were not able to mix were IOP/SMPTE packages. Exhibitors were able to pick individual CPLs from that Multi-CPL packages as they wanted during ingest.


ZIP should only be done for trailers or shorts. In general, ZIP is a solid method as long as the ZIP does not grow larger than 4GB in size. ZIP software often can not deal with archives larger than 4GB. You really need to dig into special aspects of ZIP on different platforms in order to get this straight.

We load hundreds of ZIPed trailers every year - but these are small files, and we use 7-ZIP in Windows because it can deal with files larger 4GB.


For large/feature length DCPs, ZIP should be avoided - for the same reason as above, plus, it's a pain in the ass to ZIP and UNZIP such large files. It takes ages, let's swap and temporary files grow until discs are filled, etc. Don't ZIP DCPs larger than a few GBytes!

[IoannisSyrogiannis]

I will agree with Carsten. It's true that a zipped file will require resources to unzip and -when not controlling who and how unzips- it could cause issues. I wouldn't rule it out completely, but one should know that they will eventually need to support that choice technically. It won't be a straightforward procedure. Again, complexity is increasing.

When working for festivals, where you get a lot of stuff in a plentitude of ways, I -for one- have asked for the text-based files (.xml or no file-extension for interop/IOP DCPs) to be sent to me via email, zipped. That was scarcely, after I found corruption on files due to unintentional changes in code page, when transferring or storing in the "cloud" or on a hard drive formatted in a specific way that may not be 100% compatible with the file system where the DCPs were created. Most of the times, that worked for the text-based files that wouldn't check out on the hash-check.

What is useful to understand is that the benefits of compressing/zipping appear only on the text-based files (that are minimal size either way) and on the audio .mxf files, since DCP audio is (uncompressed) PCM in MXF packages. The video files, are quite efficiently compressed already and their size will not be reduced at all by zipping. So, depending on what your gain will be, out of the audio compression, you should take an educated decision.

(P.S. Some cloud storage services, like gdrive, are already zipping before downloading, even when the files are not zipped on the cloud. Whenever I had deliveries through that service, or any other that zips to download, I would really preferred it if I was downloading an already zipped file. Those services are not convenient for that kind of distribution may probably cause issues with downloads.)

[Jeff]

Hi Carsten, Ioannis,

Thank you very much for your replies, I really appreciate it.

So clarity came today and I'm not supposed to do a "combined" package as I've been trying to, but the individual DCP's will be copied onto a single hard-drive (copymaster). It's not combining DCP's per se, as I initially attempted.

Thank you again!