Testing revert of libdcp a18b9d20ac2a0353a4f1b0b78ce7a8e26fdd6aa8 to see if that makes any difference.

Something I think I have seen in dcpomatic generated SMPTE subtitle XML:s is that the last timecode component is out of bounds (one more than the allowed value). Eg. 25 when EditRate is "25 1". This is not allowed, max allowed is 24 in this case. Sorry, can't find a sample right now. This component is called "E+" in 428-7.

From SMPTE ST 428-7:

4.2.5
Subtitle Time Code
Subtitle time code shall be a value of the form HH:MM:SS:E+, or, hours, minutes, seconds and subtitle editable units, respectively. It is a representation of a count of subtitle editable units. The HH:MM:SS portion is an approximation of real time — it matches real time only if the EditRate element’s ratio (see Section 5.8) corresponds to an integer (e.g., “24 1” corresponds to 24 which is an integer, while “24000 1001” corresponds to 23.98 which is not an integer).

The HH field shall be encoded using two digits, with a value between 00 and 23 (inclusive). The MM and SS fields shall each be encoded using two digits, with a value between 00 and 59 (inclusive).

The subtitle editable units field (E+) of a subtitle time code shall have a value between zero and “TimeCodeRate – 1” (inclusive). The number of digits to use for the E+ field shall match the minimum number of digits required to encode the value “TimeCodeRate – 1” (see Section 5.9). For example:

• if the TimeCodeRate element’s value is between 11 and 100 (inclusive), the E+ field shall be encoded using two digits – allowing the encoding of a value between 00 and 99 (inclusive).

• if the TimeCodeRate element’s value is between 101 and 1000 (inclusive), the E+ field shall be encoded using three digits – allowing the encoding of a value between 000 and 999 (inclusive).

All ‘E+’ fields within a given DCDM Subtitle document shall be encoded using the same number of digits.

The maximum value that can be expressed by a subtitle time code shall be 23:59:59:MaxE, where ‘MaxE’ is one number less than the value of TimeCodeRate element - encoded with the appropriate number of digits as defined above.

Note: The formula to convert the above HH:MM:SS:E+ encoded value into the actual count of subtitle editable units is provided below:

Count of subtitle editable units = (((((HH x 60) + MM) x 60) + SS) x TimeCodeRate) + E+

(...)

5.9 TimeCodeRate Element

The value of the TimeCodeRate element shall be equal to the value of the EditRate element rounded to the nearest integer. For example: If the value of the EditRate element is “24000 1001”, then the value of the TimeCodeRate element will be 24. If the value of the EditRate element is “200 11”, then the value of the TimeCodeRate element will be 18. In case where the EditRate ratio corresponds exactly to the mid-point of two integer values (e.g., 23.5), then the value of the TimeCodeRate element shall be equal to the value of the EditRate
element rounded to the nearest higher integer (e.g., 24 in this example).

The TimeCodeRate element shall encode the count of subtitle editable units for each increment of the seconds field (SS) of a subtitle time code — see Section 4.2.5. It shall be expressed as a positive (non-zero) integer value.

Thanks @mhm, this could also be the cause: the bad subtitle file has out-of-range ticks but the good one does not. As it happens the test version I have sent out has both "fixes" (ticks rounding and , so if it works we should get Niclas to try plain 2.13.20.

Hmm, the recent set of subtitle test DCPs I did were still INTEROP. I just installed 2.13.20 on my cinema test machine and will be able to do some testing on our ICMP on sunday. Our ICMP is running the very latest software.

• Carsten

Branch "niclas" which reverts a18b9d20ac2a0353a4f1b0b78ce7a8e26fdd6aa8 in libdcp (but also includes the timing fix for SMPTE ticks) fixes it.

Current test version also works so it looks like the timing fix is the key. Needs backporting to 2.12.x with some urgency.

Applied to v2.12.x and will be in v2.12.5.