Downconvert 720p 23.976 issue

[Gary Adcock]

[Matt] “Has anyone successfully output 720p 23.976 to a stand definition tape and were they able to keep the timcode exactly the same.”

No
because you cannot, 24p is always non drop and your SD master is going to be drop frame I imagine.

gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows

[Matt Bishop]

So if this isn’t possible, how are people deliverying 720p 23.976 footage to a exact broadcast time for a standard definition delivery?

Thanks
Matt

[Walter Biscardi]

[Matt] “So if this isn’t possible, how are people deliverying 720p 23.976 footage to a exact broadcast time for a standard definition delivery?”

We would capture to 720/59.94 (60) and edit that way for delivery to SD.

Walter Biscardi, Jr.
https://www.biscardicreative.com
HD Editorial & Animation for Broadcast and independent productions.

All Things Apple Podcast! https://cowcast.creativecow.net/all_things_apple/index.html

Read my blog! https://blogs.creativecow.net/WalterBiscardi

[Matt Bishop]

Thanks for the response Walter, with this in mind is it possible to convert the 23.976 to 59.94 then downcovert to 29.97 via the KonaLHe. I have tried this using Cinema tools, but this only sped up the actual file.

Thoughts?
Matt

[Matt Bishop]

Hey Walter, the only problem is that 720p 59.94 is still a non-drop timecode and when outputing for a broadcast master they are requesting drop frame.

This downconvert is forcing the episode to run longer then the orginal non-drop 720p timeline. I was able to convert the 23.976 to 59.94 but again the problem still exists with the Dbeta running longer. Does anyone have any light they can shed upon this problem?

Thanks
Matt

[Jeremy Garchow]

Shane Ross explains it on his blog:

https://lfhd.blogspot.com/2006/09/online-workflow-overview.html

Jeremy

[Gary Adcock]

[Matt] “This downconvert is forcing the episode to run longer then the orginal non-drop 720p timeline. I was able to convert the 23.976 to 59.94 but again the problem still exists with the Dbeta running longer. Does anyone have any light they can shed upon this problem?”

A get a timecode calculator, first off.
<https://siliconcolor.com/downloads/TimecodeCal.zip>

Apple supports the SMPTE spec, which states that progressive content was meant to stay as non drop to faithfully match the film editing process.

The spec was not modified to allow for DF,which is still required by the networks since all of the satellites that broadcast our content are over 10 years old and not capable of understanding the the digital signal no longer need to maintain the differing timing signals between audio and video to alleviate bleed over.

While the timebase of the clip appears to be DF (23.98 or 95.94) in actuality the record/play heads are physically slowed down to better accommodate the realtime conversion process to SD.

gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows