As you say, the times are stored in seconds multipled by 96000, so a time of 96000 is 1 second.

Position is stored at the DCP rate.
Trim is stored at the content rate.

Also, when you set position it is rounded to the nearest DCP frame boundary.
Start trim is rounded to the nearest content frame boundary.

I think this explains why you are seeing the differences in position depending on the DCP rate.

Finally, it looks like there's a bug where it uses the DCP frame rate (rather than the content one)
when it reads the frames part of start/end trim. I've fixed that in my local copy.

As to the overlapping thing; I'm not sure. I suspect it may lead to problems but we can test it and work that stuff out if you need.

Does that make sense?

Thanks. That does make sense.

Can you clarify one thing: Is the bug you mention the reason why I'm seeing TrimEnd of 40000/38400 for 10 frames (rather than 40040)?

Also, two other related questions, if you have time to explain:

1. When calculating TrimStart value based on content frame rate, does DCP-o-matic calculate this simply as 96000 / frame rate x number of frames? Or does whether the file uses drop frame/non-drop frame timecode come into it? i.e. are timestamps in the video file taken into account, or is it purely about number of frames?

2. For WAV files, does value of <Length> depend on the sample rate of the WAV? Or is it always calculated as 48000 x number of seconds? I haven't had a 96k WAV file recently to test this.

Overlapping: I was only asking as I'm worried with my miscalculations of Trim etc, I might have done this by accident. If I can figure out the correct values for trim fields, this will be a non-issue. We've checked all DCPs we've made with non-24/25fps content and not seen any glitches as yet.

Sorry, one last question:

To work around TrimEnd bug (it only seems to apply to TrimEnd, not TrimStart, as far as I can see):

• Should I emulate the bug's behavior and calculate TrimEnd value based on frames part at DCP frame rate rather than content rate i.e. so my script produces same XML as DOM GUI?
  or:
• Should I calculate it correctly, ignoring the bug?

Put another way: Is the bug just in the DCP-o-matic GUI writing miscalculated trimEnd values, or does the encoder also have same bug and therefore will miscalculate where to cut the content when reading the TrimEnd field? I assume the former, but just want to make sure.

I know this is all severe nit-picking. I just want to get it exactly right to avoid any glitches due to overlapping content.

Can you clarify one thing: Is the bug you mention the reason why I'm seeing TrimEnd of 40000/38400 for 10 frames (rather than 40040)?

I think so, yes.

When calculating TrimStart value based on content frame rate, does DCP-o-matic calculate this simply as 96000 / frame rate x number of frames? Or does whether the file uses drop frame/non-drop frame timecode come into it? i.e. are timestamps in the video file taken into account, or is it purely about number of frames?

It's just about the number of frames.

For WAV files, does value of <Length> depend on the sample rate of the WAV? Or is it always calculated as 48000 x number of seconds? I haven't had a 96k WAV file recently to test this.

<Length> is in samples. So for a 48kHz file 1 second would be 48000; for a 96kHz file it would be 96000.

To work around TrimEnd bug (it only seems to apply to TrimEnd, not TrimStart, as far as I can see):

Should I calculate it correctly, ignoring the bug?

Yes, I would do this. It's just the GUI writing incorrect values.

Thanks for all the answers.

Would you be willing to merge the bug fix for trim calculation into stable branch and make a release? (feel free to say no - I have no idea how much work it is to cut a release, or whether you fear this change might have other knock-on effects and so don't want to merge into stable yet)

I think that would be fine. I am still without a build server for another few days (or could be longer) so I can't do it immediately.

OK great. Thank you.

By the way, have you considered building in the cloud using something like Travis CI? It's free for open source. Maybe something I could help with if you wanted to try it.

I'll have a look at travis. I didn't know it was free...

I had a go with travis. A build for even one Linux target overran their 50 minute limit, so I think that's a no-go.

Thanks very much for including this in stable release. I'll give it a go and see if I can fix my trimming malfunctions!

I had no idea DCP-o-matic build would take so long. 50 mins+ is crazy. Sorry that was a red herring with Travis.