Combiner, Player and Disc Writer feedback/suggestions

[jdent02]

First off, I love the DCP Combiner app. I regularly swap out about 14 DCPs on our server (because I can't stop tweaking them). Copying each one as a self contained DCP means I have to bob and weave out of 14 different subdirectories when it comes time to ingest. It's a pain in the ass to be blunt. The combiner solved all that and gives me one big DCP with all the playlists selectable from ONE directory. So much nicer. You really need to talk about this app more. I almost considered a paid subscription to EasyDCP until I noticed it. That would've been a waste of money, and if I'm going to do that I'd rather light cigars with $100 bills.

One thing you may want to consider though, just for compatibility, is having an option to keep the PKL packlists as separate files, instead of combining them, as most commercial DCPs I've seen seem to have them as separate files. Also, it would help to have more detail in the progress bar as to what's going on. Consolidating these 14 DCPs took quite a while and I thought the program had frozen at first because all it said was 'combining DCPs' and this never changed.

Next, the disc writer. I've used it twice so far and it has worked, but I've noticed at least one bug and a few things that could use some tweaking.

First off, I'm using a CRU sled on a USB 3 connection. Going through Windows onto an NTFS drive it takes only ten minutes or so to copy 87GB worth of data. Using the disc writer, it took about an hour from start to finish, so it is definitely not running at USB 3 speeds. Also, the finalized disc had a partition for the DCP (which was 200GB large for some reason), but the rest of the disc was unformatted RAW space.

Next, I have a VirtualBox Linux setup. I can access the CRU drive through USB capture normally. However, after running the disc writer I was unable to connect to the CRU drive in VB. It continually gave me an error that the USB connection was still 'executing a previous command'. Even after multiple ejects and re attaches, the error persisted. I was, however, still able to access the drive through Windows. After rebooting my computer, the CRU was accessible from within VB, so a reboot fixed whatever the problem was.

Finally, when I inserted the hard drive into our server, it was recognized, but I noticed that the folder I had originally selected made it into the directory structure, which is a bit redundant since you can only copy one DCP at this time. It would be a quality of life improvement if the writer just put the data files at the root level and discarded the folder.

And to wrap all this up, just one observation on the DCP Player app. When you load up one of these consolidated DCPs, the window doesn't resize when you switch from a scope to flat media file. The aspect of the image itself looks fine, but the overall window stays at scope.

Aside from that it's still surprising (and nice) just how few bugs there are in a project of this complexity with this small of a dev team. Way to go!

[carl]

Hi there,

Firstly, thanks for taking the time to test DCP-o-matic and give such thoughtful feedback

The combiner solved all that and gives me one big DCP with all the playlists selectable from ONE directory. So much nicer. You really need to talk about this app more

I'm glad it's useful for you. Talking about things is always a bit of a challenge, but I'll try to make it more prominent in the publicity for 2.16.0.

One thing you may want to consider though, just for compatibility, is having an option to keep the PKL packlists as separate files

Seems reasonable, I added a note in the bug tracker about that.

Also, it would help to have more detail in the progress bar as to what's going on

I'll try and improve that before 2.16.0, here's a note.

Also, the finalized disc had a partition for the DCP (which was 200GB large for some reason

That's odd, I'll take a look.

Using the disc writer, it took about an hour from start to finish

That's interesting. What version of DCP-o-matic are you using for that test?

Next, I have a VirtualBox Linux setup...

There's quite a lot of layers there for things to get confused in! I'll give that a go myself when I get the chance.

Finally, when I inserted the hard drive into our server, it was recognized, but I noticed that the folder I had originally selected made it into the directory structure

Good catch, I'll do my best to fix that before the final 2.16.0.

The aspect of the image itself looks fine, but the overall window stays at scope.

Right, I'll take a look.

Thanks again!
Carl

[jdent02]

That's interesting. What version of DCP-o-matic are you using for that test?

2.15.151

It may be a USB issue. I work from home so I have remote access to my workstation. I ran disc writer when that was active. When i was running my VB it was similarly slow. When I shut the remote access off the USB speed in the VB shot up pretty quick. I'll try re running the disk writer with the remote access shut off.

Oh, one additional thing on DCP Combiner. When accessing the disc on our server we can view it's package browser by CPL or PKL. The single pack list shows up fine but it says "Created by libdcp 1.6.4devel" since that's all that's in the annotation text field of the file.

[Carsten]

That is right. A combined (MultiComposition) DCP basically means just that - a single PKL.

For the player and a MultiComposition DCP, it's probably a solvable thing to adjust the screen aspect ratio to the active CPL.

However, in cinemas I have never come across a MultiComposition containing different aspect ratio CPLs. Usually they are all variations of one feature with a single aspect ratio. I think in the US, it is common for cinemas to receive so called trailmix drives, containing a huge load of current trailers on a single drive. At least recently, they switched to a MultiComposition DCP for this - for the same reason as you wrote - on some servers, it is easier to just 'check' parts of MultiCompositions for ingest than working your way through folders for every single trailer. On our Sony, every Ingest takes about 10 seconds to get confirmed, and navigating through the individual DCP folders beforehand comes on top of that.

- Carsten

[jdent02]

Carsten, with the GDC SX1000A it's the same issue.

So I borrowed A Quiet Place II and examined the hard drive (phenomenal movie and sound mix, I might add). There are multiple CPLs, multiple PKLs, but only one ASSETMAP and VOLINDEX, and it's all contained at the root level of the drive.

I also looked at the most recent Deluxe Mixer disc (one of those huge discs packed with trailers) and it was a similar situation: multiple CPL and PKL files, but only one ASSETMAP and VOLINDEX and all the video/audio content at the root directory. There were a number of additional folders but it looks like those contain subtitle files.

[Carsten]

Oops, sorry, of course it can be multiple PKLs, I mixed that with Assetmap.

It's a mixed bag and every studio or mastering facility does it their own way.

And even some of the big boys manage to create a complete mess.

https://isdcf.com/papers/ISDCF-Doc3-Delivery-Recs.pdf

https://isdcf.com/papers/ISDCF-Doc12-Re ... 170322.pdf

[jdent02]

Might have discovered some bugs with the combiner, but I'm not sure where the error lies.

I combined those 14 DCPs together, including some supplemental audio versions (VF packages). Initially those VF entries played with no audio, but the video (that it was linking to from a different composition) worked fine. I re-exported both the OV and VF entries and tried again. This time the audio played, but it was significantly louder than it should have been. Our volume was set at 4.5 but it sounded like it was closer to 7, it was that loud. Plus there was some odd glitching on the CP750 front display. Replaced the VF version with an OV version (so a self contained composition again) and it sounded correct. I'm at a loss to explain what happened here. Even playing the VF back through the DOM player sounds 'louder' than the OV version.

Also, some of the titles appeared to ingest fine and appeared to be playable, but they would not play back when queued. Removing them and then re-ingesting led to files with a big red 'X' next to them this time. Goes without saying that they didn't play either. Other titles ingested and played back fine.

Tomorrow I'm going to try ingesting off 14 individually packaged DCPs (like before), including the VF compositions, just to confirm whether the issue is with the combiner or the DCPs themselves. Prior to this I haven't had any issues with DCP's from DOM on these servers (SX2001a with 7.83 software) so I'm inclined to believe it's an issue with the combiner.

[Carsten]

It's hard to think of a technical explanation how audio could actually become louder. Because combiner should only copy the original media assets, not change anything in them. The original DCPs and references should stay completely intact. That said, I haven't done much testing around combining OVs and VFs myself, although I remember it was me who suggested the combining function exactly for the purpose of streamlining OV+VF compositions.
I guess we simply need more testing on this. Maybe it's a good idea anyway if Carl takes out e.g. disc writer and combiner from 2.16 release and puts it back when we are sure they had enough testing.

I guess Carl would be quite interested to see the metadata of your original DCPs, and the combined ones. That should quickly tell him wether something went wrong.

- Carsten

[carl]

I guess Carl would be quite interested to see the metadata of your original DCPs, and the combined ones. That should quickly tell him wether something went wrong.

That would certainly be interesting; just the XML files would be good to see... carl@dcpomatic.com

[Carsten]

A bit of a trouble is that the whole cinema industry has come to a halt for more than a year now. As DCPs can not be used for anything else than cinema playback, there is just not much testing going on currently. Will take a while to pick up pace again.

What I did with Combiner so far did work as expected. What I noticed with 2.15.135 was that the order of DCPs in the combiner CPL/DCP list is different from the CPL list order that shows up in player or DCP-o-matic. However, I need to check that on our cinema servers.

What kind of sorting does combiner apply? A specific order is not too important I guess for the typical OV+VF pair or triple, but for what the TO does with it, many CPLs, keeping the order of the list (and offer to rearrange the list?) could be handy. Maybe even offer alphabetic sorting? I know many projectionist prefer an alphabetic list sorting.

Regarding single vs. multiple PKL - I guess a simple checkbox should suffice? Pure technically it may be irrelevant, but all servers and TMS use different ingest and content display and handling schemes, so, at the cinema, multiple vs. single PKL may make a real difference.

BTW - I noticed that the annotation text of a combined DCP is 'Created by libdcp 1.6.4devel' - maybe we need to offer users a way to give a proper new name to the combined DCP?

No, I don't think we need an option to save combiner projects
not yet...