The XML above got garbled. To be clearer, the timecode part reads:

TimeIn="00:00:-83:21" TimeOut="00:00:-80:10"

Carl, I've emailed you files to reproduce.

I noticed one other thing. The two reels which had subtitles "stolen" from them also have the TTF font file in the MXFs twice (both copies are identical, same hash).

@carl this seems to be due to the fact that the text decoder's position() is the time of the last subtitle that was emitted; in this case we have two bits of subtitle content:

• high emits @ 16:54,480 and so its position is 16:54,480
• low emits @ 16:55:920 and so its position is 16:55,920
• pass() is called on high, as its earlier, and it emits @ 21:24,800, causing the subtitle writer to move onto the next reel
• pass() is called on low, and it emits @ 16:59,400, which is still on the previous reel so causes a -ve time stamp (which is not checked for anywhere yet)

@carl pass() should have been called on low first.

Is using two SRT files in this way even supported?

Or is there an easier way to position some subtitles differently? DOM (at least 2.14.x) seems to ignore {\an8} tags in SRTs.

It's supposed to work, particularly for the use case of adding two subtitle files in different languages and having them both on-screen at the same time. There's a little bug related to that, made worse by the reels, and also there seems to be another bug exposed by having repeated trimmed content and then making reels... phew!

\an8 should work in SSA/ASS but last time I looked the jury was out on whether SRT is supposed to support these tags and I wasn't sure whether it was a good idea to muddy the waters further.

Thanks! Ah so I could work around this by using a single ASS subtitle file. Are other ASS tags like {\pos(20, 300)} also supported?

Can I ask what's the bug related to trimmed content and reels? (i.e. chopping up an existing DCP into sections to make multiple reels in a VF). Have been doing that a fair bit recently and not hit any bugs that I'm aware of. Unless I did hit a bug and just won't find out until the DCP screens!

NB One of those DCPs went to MPS for distribution so I assume they validated it and would have rejected it if it wasn't valid.

By the way, I don't know if there's a formal spec for SRT, but it seems to be a bit wild west. I'd say at least 30% of the SRTs we receive from filmmakers aren't valid in some way or another (overlapping subs, excess line breaks between subtitles etc). It's pretty messy.

Thanks! Ah so I could work around this by using a single ASS subtitle file. Are other ASS tags like {\pos(20, 300)} also supported?

Some tags are supported (\pos \fs \c \an \u \b \i)

Can I ask what's the bug related to trimmed content and reels? (i.e. chopping up an existing DCP into sections to make multiple reels in a VF). Have been doing that a fair bit recently and not hit any bugs that I'm aware of. Unless I did hit a bug and just won't find out until the DCP screens!

As far as I can see if you are trimming the start of DCP content and placing it at a non-zero position in a VF DCP, and referring to it, there may be problems - but I would expect errors rather than bad DCP outputs. Can you share the metadata.xml and CPL files of any DCPs you are worried about?

Agreed on the randomness of SRT. I'm not even sure which program people mostly use to create them - if there was an obvious one I guess using its output as a de-facto "standard" would make some kind of sense.

@carl tests fail, something needs fixing here

@carl tests running again

c8a036eb727ceddc64a0304d781c916eb952c001

I've sent you an example of output when chopping up a 1-reel OV DCP into reels when making an VF.

This VF was made from ASS subtitles file to work around the issue originally described above. In the process, I did notice one other oddity:

In the subtitles XML the subtitles are out of order i.e. in a 2-line subtitle, the top line appears in the XML below the bottom line.

This isn't invalid I don't think as Vposition is set correctly for each line, to position the top line above the bottom line. But it certainly looks weird in the XML. As it's unusual, I guess it's possible it might be more likely to surface a bug in badly-behaved projector which has never encountered this before.

Spot no. 11 in reel 1 in the example I've sent you Carl demonstrates this.

<dcst:Subtitle SpotNumber="11" TimeIn="00:01:01:23" TimeOut="00:01:05:18" FadeUpTime="00:00:00:00" FadeDownTime="00:00:00:00">
  <dcst:Text Valign="bottom" Vposition="8.68056">there was land here and not sea.</dcst:Text>
  <dcst:Text Valign="bottom" Vposition="14.4381">[Girl] 200 million years ago,</dcst:Text>
</dcst:Subtitle>

Oh damn it! Mantis really doesn't like XML/HTML in comments.