Matt Lyon
Forum Replies Created
-
Great! Thanks Jeremy… works like a charm.
Matt Lyon
Editor
Toronto -
Hey guys,
Thought I’d jump in here with a related question: I’m about to deliver some material in SD, uncompressed 29.97, as a quicktime file. My material is 23.98 progressive (from a film source). So I need to do a software conversion to add proper film-style pulldown. In the past I’ve done this with After Effects, since I didn’t think compressor could do proper AA/BB/BC/CD/DD style field ordering. But some of these posts seem to suggest it can? I did some quick test today with no luck. Any tips on the proper settings? I’m using compressor 3.0.5. Thanks!
Matt Lyon
Editor
Toronto -
Do you have lots of still images in your timeline? Final Cut will give the “preparing video…” progress bar when it is caching your stills into RAM for realtime playback. You can actually stop this by setting the “still frame” cache to 0 … but then you’ll have to render all your still frames (which may be less annoying, depending on your workflow).
I deal with this every day when I’m assembling animatics … it can be super frustrating! Especially because it doesn’t take much to cause FCP to want to re-cache the whole timeline.
Matt Lyon
Editor
Toronto -
Hi Rafael, I think your best bet is to check with the lab doing the film ouput. It may also be you\’ll get better looking subtitles if the film lab does them during the DI phase.
Matt Lyon
Editor
Toronto -
I don’t doubt it at all that H264 is fine for lots of people… that’s why I stressed the importance of checking with your sound studio, because everyone’s needs are different. But try comparing the scrubbing performance of Photo-JPEG vs. H264: Photo JPEG smokes H264!
Matt Lyon
Editor
Toronto -
re: “skipping the compressor part”:
I don’t know if you consider this a “small” format, but I just delivered a show to a mixing facility and they required DV NTSC quicktimes to mix with. So I guess theoretically you could capture DV firewire directly and send to the post facility.
But it’s really important to check with your sound house! Every facility is different. The place I mentioned above probably is using dedicated playback hardware. A smaller shop may not have the luxury.
Also, most facilities will want Burned In Timecode, so unless the material you are capturing has this, you probably at least need to ingest into FCP and apply a timecode filter.
Hope this helps,Matt Lyon
Editor
Toronto -
H264 is often fine, but it is a “modern” codec and as such is more processor intensive during playback. I’ve been using photo-jpeg lately, which is an older codec. It will result in bigger file sizes, but is also is less taxing on the Pro Tools station’s CPU. I find this is a “safer” option — especially if your sound person isn’t running the latest gen hardware (which is often the case, in my experience).
Matt Lyon
Editor
Toronto -
Hi Richard, are you sure the clip that you got to work wasn’t working correctly before you connected it in the database? Simply connecting the media to the database record shouldn’t change anything in the database record. There isn’t really a way to do something “wrong” during this step (short of connecting the wrong clip — but that is easily fixed).
It is entirely possible that some clips might have the correct AUDIO TC, while others do not.
What you really need to do is connect ALL the clips from your final program to their respective entries in the database, then visually verify in Cinema Tools that the audio TC matches the info in the SOUND:TIMECODE field for each clip.
If they don’t, then you need to manually enter new audio timecode in the Cinema Tools database for every shot to match the visual burn in. You also need to verify that the “TC RATE” is set correctly, or else the timecode will drift out of sync.
Do not conform your clips to 24.00, they should remain at 23.98!
Are you currently in the Toronto area? I might be able to help or could recommend someone…Matt Lyon
Editor
Toronto -
Yay Toronto! Deluxe has always had great customer service in my experiences working with them. If they can’t help, they might be able to put you in touch with one of the sound guys at Tattersall across the street.
I don’t think the issue would have anything to do with not using the .flx files to import into FCP. It doesn’t really care about the Audio TC until it queries the Cinema Tools database to generate the EDL. Since the video TCs are all correct, this really points to the Cinema Tools DBase as the source of the problem.
If you can isolate exactly what the issue is, it /may/ be possible to get Deluxe to make new .flx files and then create a brand new Cinema Tools DBase. Export the Audio EDL again, point FCP and the new DBase, and cross your fingers 🙂
Good luck! Please post your findings, I’m curious to hear what the solution is…Matt Lyon
Editor
Toronto -
Hi Richard, I’m can only offer some educated guesses because I’ve never had your exact problem. There are a number of ways that things could have gone wrong. The lab could have simply done something incorrectly during the initial transfer and sync of the rushes. At least you have the TC burn in! So if all else fails, the sound editor can go off that … although you won’t win any friends 🙂
The offset could also be if the timecode was incorrectly set as Drop Frame, and it is really Non-Drop Frame (or visa versa). This type of problem would result in the timecode starting in sync and “drifting” further apart as you reach the end of each rushes tape.
You should be able to open the cinema tools database and examine the individual entries for each clip. Compare the Sound:Timecode field against the visual burn in, and check what the “TC RATE” is set as. If need be, talk to the sound recordist and verify what setting they used. You can manually edit the timecode here and hopefully fix the offset. A big PITA if you have to do every clip in the database, but it might be the only solution.
Hope this helps,
Matt Lyon
Editor
Toronto