First Film Scoring Report WIth 7.2/Possible Problem?

[Armageddon]

I've just started my latest feature-length scoring project and am using 7.2 for the first time as the means to score it. I've already hit a tiny snag, and am curious if anyone else here is experiencing the same thing. After loading up my movie file, making sure the frame rate and movie start time were set properly (23.957, 1:00:00:00) and setting up my Chunk Start Time for my first cue, I noticed a very disconcerting thing. My Transport counter was exactly one frame ahead of the TC window in the movie (this is why you ALWAYS ask for a QT movie with a window burn!).

At first, I was rattled, I prowled through my Prefs, double-checked to make sure I had everything set right, and even remembered that, when I first set everything up, the TC window in the movie and my Transport counter were in sync. I went back to the beginning of the movie and started playing it, then paused it to see if everything was in sync. Sure enough, it was! I then stopped the movie/DP project via the Transport controls and shuttled forward a bit in the QT movie using the movie's shuttle control. Now, everything was a frame off. I hit "Play" in the Transport controls. Hit Pause. Everything was now in sync.

Via using a mix of letting the movie play, pausing, shuttling to the vicinity of where I wanted my first cue to start and jogging everything forward frame-by-frame, I was able to get to the right frame I wanted to start at, set the Chunk time for my first cue, and moved on. However, going back to Measure one, DP was now, once again, one frame ahead of the movie. I hit Play, then paused. Back in sync. I was able to lay in my end time marker, but depending on how I hit, it's either in sync or DP is one frame ahead.

So ... what gives? Fortunately, it's a workable problem, since I believe it's actually in sync, it just seems like it requires some catch-up (reminding me of the golden days of scoring to VHS, where you had to pre-roll in order to allow your SMPTE-to-MIDI to lock to the SMPTE TC). It is kind of unnerving when you need to be frame-accurate in order to lay in your markers and to be able to provide dead-on TC numbers to the sound guy. The movie file is completely defragged, as is the rest of my 7200 rpm drive, so there shouldn't be any lag there. And the last project I scored was in 5.13, minus the pre-gen mode or the ability to score to HD (23.957 fps), so I had to go by its window burn, rather than the DP counter and I have no idea if this has even been the norm for my rig all along. If anyone has any idea why it might be doing this, or how to correct it, or if I should just learn to live with this quirk, please share!

Otherwise, so far, scoring in 7.2 is about what I expected it to be: excellent. MOTU didn't eliminate or change any of the film-scoring essentials, so I didn't have a lot of relearning to do (though I miss the Transport scrub control!) and if I can somehow figure out this one small quirk, it'll be a dream to work with.

[claude]

Hi Armageddon,

every project i've done in DP for many years needs for me to add or subtract sub frames in the movie's start time. It's really a hit/miss thing i don't know why but it's not a DP thing.

I think that it has to do with the Quicktimes actually not starting exactly on a frame but rather a few sub-frames ahead or late.

HTH

Claude

[Kubi]

Yes, when you are stopped and there is a discrepancy between the window burn-in and the counter, try advancing the counter (or delaying, as the case may be) manually by a single tick. You'll find that you are "off" exactly by a tick, so not really at all. Spotting to video etc. still works exactly as you'd expect it to, so I simply ignore the occasional discrepancy between the burn-in and the couter readout when stopped, and rely on the window burn-in for navigation.

Never thought of changing the start time by a subframe or so. I may try that.

And yes, for me too this is not a new issue.

[Mr_Clifford]

Could it be related to the crazy xx.957 frame rate?

I'm lucky enough to live in a PAL world where all my projects tend to be either 25 or 24 frames, and have very rarely struck the '1 frame out' situation.

[Armageddon]

The thing is, it's not actually off by a frame -- it seems to have to do with the method of shuttling to a certain spot. If I hit Play in the DP transport window and then Pause, my Transport counter and the window burn readout are in sync. If I try scrubbing with the QT controls while the movie is stopped and go to a certain spot, it's off by a frame. Sometimes, it's off by a frame even if I use the DP controls. It almost appears as if QT has to "catch up", like what happens with SMPTE locking to VHS from the analog days. Also, the Chunk start time is ahead by one frame, even though I know it actually isn't. If I let the project play from Measure One, then stop it, it's almost always synced. Therefore, I don't know if DP is lying, or the movie's somehow off, so, for the meantime, I'm trusting that I set my markers and Chunk Start correctly and that it'll be okay. It's not a work-killer, but it is highly disconcerting, and should prove very interesting when I attempt to lay in markers and Conductor Track changes on a complex cue.

It could well have something to do with the HD frame rate. My last scoring project was in 5.13 and was also in HD, so I just selected "24 fps" as my frame rate in DP and went strictly by the window burn for SMPTE numbers. Everything synced up fine, insofar as I could tell, but again, I had zero reliance on DP's SMPTE readout. So I have no idea if 5.13 had a similar problem.

[Kubi]

Could well be the 23.98 vs 23.979 (or whatever it is) discrepancy...

But as mentioned, the difference (for me at least) is exactly one tick, WAY less than a frame. In other words, QT says it's on frame X, DP counter says it's on frame X plus 1 (or minus 1, can never remember), but if you move the counter in DP by only one tick ("tick" as in the 480 subdivisions of the quarter note...), boom, you're in sync w QT again.

So i.e. if you're parked at bar 25/1/007 and you *seem* to be a frame off from QT, type in 25/1/006 (or 25/1/008), hit return, and voila, you're back together again.

In other words, its a readout issue more than anything else...

[Shooshie]

So, Armageddon, does this resolve satisfactorily for you? I mean, within the working parameters. I've saved a PDF of this thread and will try to reduce it to a single tip if/when I update the tips sheet. (there's a growing list of such tips; I've got to do this sooner or later) So tell me if this is worthy of using as a tip, or if it's still not working for you.

Shoosh
PS: you guys get the credit, not me, for the tip of course.

[Armageddon]

So, Armageddon, does this resolve satisfactorily for you? I mean, within the working parameters. I've saved a PDF of this thread and will try to reduce it to a single tip if/when I update the tips sheet. (there's a growing list of such tips; I've got to do this sooner or later) So tell me if this is worthy of using as a tip, or if it's still not working for you.

Shooshie, I'm not altogether sure it's even a DP problem or a hardware problem or what, but so far, I'm still a frame off (not really; it catches up after a second or so) and it seems like DP and the QT movie are playing catch-up with each other, further leading me to think my system might be slow, there might be a seek-time problem with the hard drive, or it could even be that ongoing issue between my Konnekt 24D and DP causing a lag. The fact that it "catches up" and isn't a constant almost rules out DP as being the culprit, since I'd assume a bug in DP would cause some ongoing glitch that would keep it always a frame off. That, and 7.2 runs better on my machine than any version since 5.13. The only thing I could think that would make it a DP-side problem is that maybe they haven't perfected the 23.957 fps feature yet (having only been an option since 6) ... but then, this board would be riddled with complaints about it. It could even be due to the fact that the QT movie has been compressed to a smaller size, though it's about standard for post-sound and scoring, and again, missing frames would cause a massive problem with sync, not just a slight one that seems to almost correct itself. Its also possible that pre-gen mode (which I need), DP's general operation and running a movie all at the same time is causing a slight lag in the works. I've got my project setting all the way down to 44.1 kHz/16-bit for the composition phase (which, by the way, has also seemed to kill my ongoing "lag on quit" problem) and every other application, even Dashboard, turned off, but the "catch-up" problem persists.

Rest assured, it's far from being a work-killer -- everything else in DP is working like its usual reliable self, and so long as I make sure the window burn numbers and DP's numbers match when I go to lay in a marker, I just ignore the lag the rest of the time and everything seems to play back okay. Like I said, my last gig, I had 5.13 and I just wound up going strictly by the window burn, since it wasn't HD-capable. Thanks for all your help, gang!

[frankf]

I'm not altogether sure it's even a DP problem

Do you get the same discrepancy when playing the movie in QT? Does burn in of movie in DP agree with DP when entering frame location in transport? I agree with the single tick comment. DP has much finer resolution than QT at any supported frame rate, so locating will at times force to round the display by subframe or tick when necessary. Drop your markers with confidence!
Frank



Sent from my iPhone using Tapatalk

[dp-user]

Quicktime movies can have what is called a "long" or "short" frame as their first and/or last frames. This happens when the movie was output via a capture card, and/or captured via a capture card, and the card needs to synchronize the first frame to its internal sync. This "long" (or "short") first frame can really screw up apps like DP that expect the first frame to be, well, erm, frame-sized...

As Claude posted, this can be resolved by adjusting the start frame by some sub-frame amount. You do this by choosing "Set Movie Start Time" in the Movie window's mini-menu, and then set "plus <n> timecode bits" field, where each "timecode bit" is an 80th of a frame (i.e. the number goes from 0 to 79). If you need to adjust negative, just set the frame back by one (i.e. 00:59:59:23, if you're at 23.976) and then use positive timecode bits to compensate.

The reason you see this when shuttling via the Movie window, and not by play/stop in the transport is that the discrepancy is small, but when you step in the Movie window, you are moving to exact frame times in the Movie, which will (due to the long/short first frame) not be exact frame times in DP. However, since the discrepancy is sub-frame, the chances of hitting the exact times necessary to be off between frame time and movie time when using the DP transport are very minimal.

You can determine how far the QT movie is off from actual frame time by stepping in the Movie window, and then setting DP's two counters to Samples and Frames (respectively), and write down the sample count. Then zoom way in (to the sample level) in the SE, and drag the DP playhead back a bit until the QT movie's TC burn-in shows the same frame time as the DP counter; rock back and forth over the sample, to make sure you've got the exact sample where the Movie window shows the TC burn-in that matches DP's counter. Subtracting the current Samples time from the time you wrote down (the time that corresponds to the frame boundary in the QT movie file) will tell you how far off the movie time is from actual frame time, i.e. how much longer the first frame is.

Note that I wrote the above assuming you have a long first frame, if you have a short first frame, then TC burnin will show as one more than the DP counter, so you just go the other direction when determining the offset.

Once you know the sample offset, you can figure out how many timecode bits to use, because there are 2002 samples per frame in 23.976 (aka 23.98, both are approximate anyways, as the actual frame rate is 23.976023976023976...) and 80 timecode bits per frame. So divide your sample delta by 2002, and then multiply by 80, and you have the number of timecode bits.

Hope this helps...

[Armageddon]

I agree with you guys -- DP and QT seem to match up, and I'd swear it's either QT lagging or some sort of internal reconciliation happening during the mismatches. I've resolved myself to, once I get DP and QT to match up, by trickery, frame advancement or fast-pause, lay in markers or my Chunk start time and ignore the discrepancy from that point forward. DP is behaving exceptionally well and everything seems to match up, sound-wise. The worst case scenario is, I'm a frame off, which (knock on wood) no one will notice but me.

By the way, shortly after reading and re-reading James's tips on how to set up an M-Audio controller to use its transport controls in DP, just so I could use my Keystation Pro-88 to record without having to run over to my mouse and click it, then run back during my two-bar countdown and discovering that, for some reason, it just wasn't going to happen ... the controller died. Middle D's key-weight either became dislodged or broke, making the key bounce three or four times every time it was hit, then the Db key next to it went dead. At that point, I attempted to crack it open, only to discover the Keystation Pro-88 was either not designed to be repaired, or not designed to be repaired by an idiot. I won't be able to snag a replacement for a spell, so I'm forced to use my Korg K61 to score this flick. It's like playing a toy. Needless to say, my next weighted comtroller is either gonna be an Akai MPK or a CME UK -- I'll bite the bullet and get something that hopefully won't break for a while.