Which size for DCP subtitles?

A question about the "best" size of DCP subtitles piqued my curiosity. Since I have access to a sample of DCP folders from a distributor, it was easy to do some statistics and find out what others felt was the right size for subtitles.

Executive summary: the answer is 42, which seems perfectly appropriate since it also happens to be "the answer to life, the universe and everything". (If you didn't know, you may be interested to see that Google's calculator does, and gives you the correct answer when asked this essential question).

 

All the DCP's I had access to used the CineCanvas (or Interop) standard for subtitles, which is described in the "Subtitle Specification for DLP Cinema" published by Texas Instruments. The document doesn't give an "official" size recommendation for subtitles, but it does provide a default size if the file doesn't specify it. The default is 42.

It also explains what the number 42 is supposed to mean (in the context of subtitles, not in that other more profound meaning):

"Size is given in points. Fonts are rendered as if the screen height is 11 inches, so a 72pt font would be 1/11 screen height.
Default Size = 42"

And that also seems to be the preferred size for the 124 feature length movies in my sample:

Font Size	Number of DCPs
36	1
37	2
38	7
39	21
40	10
41	3
42	68
44	6
45	3
46	1
47	1
48	1
Total	124

 

That disk also had 40 trailers with subtitles. For these, the preferred font size seems to be smaller at 39:

Font Size	Number of DCPs
39	31
40	1
41	1
42	6
44	1
Total	40

 

Points and pixels

There are 72 points per inch, so the screen height is 11 * 72 = 792 points.
In 2K, the DCP sizes are:

• 2048 x 1080 pixels for full frame
• 1998 x 1080 pixels for 1.85
• 2048 x  858 pixels for Cinemascope (2.39)

(In 4K, the sizes would be 4096x2160, 3996x2160 and 4096x1716 pixels)
So in full or 1.85:

• 792 points = 1080 pixels
• 1 point = 1.3636... pixels
• 1 pixel = 0.7333... points
• 42 points = 57.3 pixels

In Belle-Nuit Subtitler, the subtitle size appears to be set in pixels, which it then converts to points when exporting to "DLP Cinema".
I'm not sure about Cinemascope. Would 42 points be rendered as 45.5 pixels (42x858/792) ? Or still as 57 pixels ? Or would it depend on the projector ?
 

Adding subtitles to a DCP

There are several extremely expensive tools to do this sort of stuff, and there is an open source one (OpenDCP) which could certainly also do it. But it can also be done "by hand" quite easily.

The subtitle XML file can be exported from Belle-Nuit Subtitler (it is called "DLP Cinema" in the export menu). Since it is just an xml text file, it can also be produced in any text editor, or converted from another format with a few regular expressions. Examples of the format are easy to find on the net.

I had a non-encrypted DCP of a trailer, and the subtitles xml exported from Belle-Nuit. After many tries I finally ended up with a DCP folder which EasyDCP Player+ plays without complaining. (Well, the demo version plays the 15 first seconds in psychedelic XYZ colors. If you have a few thousand Euros lying around you can get the full version).

• Open the subtitle.xml file, and copy the UUID from the SubtitleID tag near the top.
• If needed, also adjust the MovieTitle, ReelNumber and Language.
• Take note of the exact size of the file in bytes.
• Edit the CPL file (the .xml file which starts with "<CompositionPlaylist>") to add the subtitle section. It goes into the AssetList, next to MainPicture and MainSound. Use the UUID you copied from the subtitle.xml, and set the right durations and language. In the end, it looks similar to this:

<MainSubtitle>
   <Id>urn:uuid:CBEB439E-AA36-4B87-975D-2776A268A9AF</Id>
   <EditRate>24 1</EditRate>
   <IntrinsicDuration>3167</IntrinsicDuration>
   <EntryPoint>0</EntryPoint>
   <Duration>2927</Duration>
   <Language>de</Language>
 </MainSubtitle>

• Edit the PKL file (the file named "....PKL.xml" which starts with "<PackingList>"). The subtitle Asset section looks like this:
  

  <Asset>
    <Id>urn:uuid:CBEB439E-AA36-4B87-975D-2776A268A9AF</Id>
    <Hash>7jzdoZCDXGet6tPWSv2htztPlw4=</Hash>
    <Size>12161</Size>
    <Type>text/xml;asdcpKind=Subtitle</Type>
    <OriginalFileName>melancholia-trailer-dcp-stfr.xml</OriginalFileName>
  </Asset>

  The hash value is a SHA1 hash of the file, Base64 encoded. It can be produced with this command in Linux or Mac:
  

  openssl sha1 -binary "Your_Subtitle_File.xml" | openssl base64 -e

  On Windows, if you have Perl, you can get the hash with
  

  perl -M"Digest::SHA1 qw(sha1_base64)" -e "open(F,shift) or die; binmode F; print sha1_base64(<F>), qq(=\n)" "Your_Subtitle_File.xml"

  Maybe you can also just leave the hash out. It appears to work in EasyDCP.
• If your PKL is signed, remove all the signature and certificates stuff. (If someone knows how it could be re-signed with a new certificate, please let us know; xmlsign can probably produce the right output if we know which options to use; I didn't investigate this)
• Finally, edit the ASSETMAP file to add the subtitle file and correct the sizes of the CPL and PKL files.

Open questions:

• Do Cinema servers accept unsigned DCPs?
• How compatible is the result with the various server models and versions? There must be a reason why the subtitles are often burned in instead of being in a separate XML.

Why I hate Shotput Pro

Most people I know seem to be fond of Shotput Pro for offloading XDCAM EX cards to hard disks.

I understand why they like it, but I don't. So I'm still looking for a better solution to recommend to people.

For myself, I use custom shell scripts with rsync, but they need to be configured for each project, which is sometimes too much of a hassle, and certainly not something I can recommend to people who have never heard about Terminal.

Shotput Pro isn't all that bad, and is definitely much better than using the Mac Finder for such an important task. But several details drive me mad, especially because they seem so obvious, and should be easy to fix. Here is my list of ...

...Things I Hate About Shotput Pro

(in no particular order)

• It doesn't preserve folder dates and times, so you don't see the shooting date straight away in the Finder listings. Since every shot is in it's own folder, the shot list in the Finder is a mess of meaningless numbers used in the folder names, and just as meaningless dates and times.
• It doesn't find the SxS card automatically, even though it would be very easy (it's a FAT32 partition which is the only one on that disk, and which contains a folder named "BPAV" in it's root; it's also usually labelled "Untitled" by the Mac).
• When you want to offload cards into folders named by date, which is what I always want, it's automatic naming is catastrophic: it somehow uses your system settings for the date format, which in most cases contains slashes ("31/12/2010")! Of course, slashes cannot be used in names, on any current computer, so the Finder will helpfully replace them with colons behind your back, but still show you slashes. So you end up with folders which have different names depending on whether you look at them from the Finder or from another program (like Terminal) or on another system.
  Then Shotput adds the time and timezone, separated by spaces. Not as bad as using slashes, but still very annoying.
  And the " +" or " -" before the time zone isn't a great idea either.
• It cannot continue an interrupted transfer. If you have offloaded most of a card but then had to add a few shots to it, or if you just had to suddenly interrupt the transfer to move to another location (which tends to happen when filming), you cannot finish the transfer at a later time. When you restart the offload, it will actually restart from scratch. It will have noticed that you already have a folder with the same name, and instead of a prompt similar to "You already have a folder named '2010-12-31_14h23'. Would you like to update it?", it will just start over into a new folder after appending a "-2" to your folder name.
  A 32GB card takes a lot of time to be copied twice, and with Shotput, you will often be stuck watching it re-copying files long after wrap time.
• Requires activation over an Internet connection. Well that may look like it's OK, since you do it only once, during preparation. But if you forget it, and rush on a shoot in a remote place without Internet, haviung only your new computer and your fresh Shotput Pro download, you won't be able to use it.
• A much worse scenario is if your computer dies during the shoot. Before you can activate Shotput on your replacement machine, you first need to deactivate it on your old machine over the Internet. That will be hard if the old machine doesn't boot. I'm sure such a situation can be solved with an email to the company, but that will also require an Internet connection, and not be done immediately on a Sunday at 2AM.

  Update: The way I do the transfers (with rsync) is extremely reliable, preserves dates and times, allows restarting interrupted or incomplete transfers, and doesn't require any extra tools (rsync is part of the base install on OS X, and most Linuxes, and is available for Windows).

However, until I find the time to package it all into a nice and fool-proof script, it is not suitable for people who are scared by Terminal. Basically, the rsync command is:

sudo rsync -rt -vi --progress --exclude=".*" "$source" "$dest"

Before that, I had source and dest initialized by a script, which ends with something like

source=/Volumes/Untitled/; dest=/Volumes/Project_1A/2011-12-14_09h18/