[Thomas Mcnamara]

Thanks for getting back. Yes, I should have clarified; AJA said that clients are doing both frame accurate insert edits and assemble edits on the SRW5000, using our settings and configuration, and that updating would likely have no effect on our issue.

It only happens on crossconversion, and is repeatable. The settings are 720p23.98 8bit crossconverted to 1080psf23.98 10bit. This happens on both an insert edit as well as an assemble edit.

I would’ve thought that changing the offset in FCP or the deck would’ve alleviated this, but changing offset on either end has had no effect, it just moves where the frames are duplicated. This happens also with different shots, with different in points.

The only reason I’m opening this up to the forum is because we work with someone who told us that there was a specific workaround for this very issue, but that he couldn’t recall how they got around it. Otherwise this is just an unfortunate anomaly with the possibility that there isn’t a simple fix, that its something with our system setup. Even though we’re tackling that aspect, if there is a known workaround that would be useful.

As far as the tangent course, I’m interested because if you know of two specific issues, there are always anomalies in the editing process and knowing these issues might explain some of them…if nothing else, it is to satisfy my curiosity. The only issue I’ve heard of is with 10.5.2 leaving tiny gaps of time when switching processing over to other cores, opening up the possibility of dropped frames. I’d be happy to open another discussion here if you want to keep this post on topic. Thanks Gary.

[Thomas Mcnamara]

The AJA tech we spoke to told us that our current configuration was fine as far as he knows, that he has clients with our exact configuration laying back to HDCAMSR all the time. I wouldn’t have listened to them tell us to update and then not update and then come on here to wonder why it still isn’t working.

If you know of 2 issues with this current config, (I am more than willing to do an update at this point.) what are the two issues, and I’m guessing that you mean OSX 10.5.4 with FCP 6.0.4, right?

We do try to follow what AJA recommends. If you know of 2 issues, and can tell me, that’ll be a more compelling reason to do the update now because we’re technically still in the middle of the project. We have a few days to test, so I can clone the existing drives and run what updates we need to.

Your help is greatly appreciated….as far as I’m concerned, this is the most useful aspect of creative cow – we can see what is actually working out there in the field on a regular basis, because each company can’t account for the variables on every end. Thanks.

[Thomas Mcnamara]

Makes sense, my problem was that as I understood it, Cinema Tools does not retain TC info… does it keep the TC because it would originate from the flexfile to batch list to captured media instead of just random media files?

So essentially, you’re saying flexfile->29.97 batch list to FCP -> capture 29.97; load 29.97 dvcam material into cinema tools, reverse telecine, load rev files back into a 23.976 FCP project, edit at 23.976. Export a film list. Makes sense so far.

For the hdcamsr out, use the 29.97 batch list created earlier for the dvcam offline, create an online hd project in fcp, load batch list, capture hdcamsr into fcp, load that 29.97 media into CT, reverse telecine, and reconnect newly created rev files at 23.976 to the offline 23.976 edited project. Correct?

This all makes sense so far, but as far as efficiency I have a follow up question: What if I didn’t want to recapture all the hdcamsr material, only the material that I used? In other words, instead of capturing all the hdcam tapes at 29.976 from the original batch lists, then reversing all the telecine, then reconnecting, is there a better, more space-friendly way to only capture the hdcamsr material, at that time, only what was actually used in the edited offline project?

This all seems to hinge on the question of whether or not Cinema Tools retains accurate TC; if so, I could recapture the 23.976 hdcamsr online project at 23.976, but only capturing what was actually used in the final sequence, a fraction of the original, making the Kona remove the pulldown, and accurately maintaining the keycoded frames. Without needing to reverse the telecine in cinema tools again, which takes up more space and time.

Thoughts? Did I understand your post correctly? Thanks for the response, I appreciate it.

[Thomas Mcnamara]

Don’t forget though – with AIC you lose all timecode information…factor this into your decision. Stick with DVCPROHD or the Prores solution posted above.

[Thomas Mcnamara]

Have you trashed the AJA pref files? This has worked for me time and time again in the past.

[Thomas Mcnamara]

I’ve never really been able to figure out a workaround for this either, so any hints out there would be greatly appreciated.

[Thomas Mcnamara]

AFAIK, MTR will only rip the vob files…still would need another program to generate quicktimes if he wants to upload to an ftp server, especially at more manageable file sizes.

I second the handbrake suggestion; if watching is all that matters, and you don’t really need in/out control over the clips, skip some steps and just rip to a h264 right there.

[Thomas Mcnamara]

MPEG Streamclip -> FCP -> Compressor -> Cyberduck

[Thomas Mcnamara]

Just make sure you recompress the hd stuff only in its own sequence or bin; otherwise you’re adding steps to convert sd dv that’s already in the res you need it in. (Assuming it’s already in there as dv.)

Try tweaking compressor settings if this doesn’t work.

[Thomas Mcnamara]

Recompress using Media Manager. Works like a charm.