Bill Russell
Forum Replies Created
-
Bill Russell
July 20, 2021 at 12:13 am in reply to: Consolidate export, trimming unused portions of each clip, with handlesThank you, John.
Odd to max that FCP can’t do that. FCP 7 of course could do it.
(And Avid and Premiere and Davinci…)
-
Bill Russell
July 19, 2021 at 8:31 am in reply to: Consolidate export, trimming unused portions of each clip, with handlesFantastic reply, thank you.
You’re right that it is quite standard and essential for pro platforms and odd as heck that FCPX doesn’t have it, especially after so much time “maturing”. Avid has always had it (and done it well). Davinci has it. Premiere has it.
FCP 7 (Final Cut “Classic”) could do it.
Still miss it!
* I believe even the best working version, FCP 1 — built from Macromedia’s typically genius tight coding (subsequently sold to Apple and before Apple’s bloaty ways accompanied years of albeit great new features, beginning with a noticeably hoggy FCP2) — could do it.
-
I’m surprised the turnkey projection systems themselves aren’t simply delivered with the ability to read ext2/3. You’d think the manufacturers would be designing around DCI specs. Anyway… I’m curious, what frame rate compliance issues have you run into?
Also, what freeware ext read solution are you offering? I’m only aware of Paragon’s.
“THE LOST SKELETON OF CADAVRA” –
-
Bill Russell
March 31, 2019 at 9:42 am in reply to: Colorbars generated by Resolve far too bright. (Imported color bars line up.)To be sure, whether exported or within, it’s Resolve’s own generated bars that are off with color managing on, visually and on the waveform as well. Imported bars and other media are correct, per scopes as well as seen on the calibrated display or in exported media. It’s the generated bars that are too bright, which is way odd.
“THE LOST SKELETON OF CADAVRA” –
-
Curious. For me super scale applies instantly. However, I never apply it until I’m finished with other work because seems it’s not accelerated and just bogs playback down to a crawl, cooling fans howling. …. but the visual results are great! I haven’t been using an external display, I should check that. Maybe you aren’t seeing it on the timeline as it has something to do with how it encodes realtime to hardware / or in the external hardware itself (HDMI or SDI)?
“THE LOST SKELETON OF CADAVRA” –
-
Frustrating, because ext2(/3) is the only DCI compliant disk format, the only one “guaranteed” in the industry standards to be universally readable by theater projection systems. I recently brought this to the attention of a European cinema, providing both them and the client DCI specifications — purely in self-defense as I was being accused of making a faulty rush DCP overnighted to them from the U.S. at a hefty cost — and believe it or not, after “enlightening” them, the theater easily accommodated! This is a prestigious venue that’s been around for some time, but apparently, nobody knew — that simple — and all these years they have not been informing clients about their NTFS limitation, while turning away perfectly good DCPs as mysteriously “faulty” or “unreadable”.
Was I the first to ever tell them?? Seriously?? That’s all it took? — in an email — and they are changed forever. As a DCP maker, I feel a little cocky and emboldened. I kind of want to take up a sort of “activism” in defense of DCI requirements for everyone’s sake. It asks very little of theaters — asks less of them than they of us by them being non-compliant.
It is perfectly okay to have a PC-based media server/projection system, but to be compliant you absolutely must have software or a device driver for reading ext2/3, OR a linux shell (probably more reliable than something like $35 Paragon), OR a linux workstation on the network. It’s nominal cost — much easier and cheaper in total than forcing clients to generate auxiliary non-compliant DCP kits — and takes very little time to implement. If it’s simply a matter of purchasing Paragon, the easiest option, then it’s literally three to five minutes of time to bring the system up to spec. Viola.
Ok, that’s it, I’m going to include some sort of short and friendly spec and trouble-shooting sheet that makes it very clear that if the theater is unable to read compliant DCPs, they have an issue, and include tips for reading proper DCPs. From now on, also, on my proposals I’m explicitly not responsible for incompatibility IF a venue has not informed the client of special needs (like ntfs only).
That said, outside of activist silliness, I could see making a compliant kit (sata drive as ext2, cart, hard case etc.); then also formatting a thumb drive as ntfs, include a second copy of the DCP on that stick and tuck it inside the hard case along with the “real” DCP. If you want to add a little flair, be snarky — in the right, sure, but snarky — and label it “(backup for non-compliant theaters” ????
– b
“THE LOST SKELETON OF CADAVRA” –
-
Maybe a dumb question — I assume correspondingly when you actually play the imported files in Resolve, only the first nine frames exist / are playable?
“THE LOST SKELETON OF CADAVRA” –
-
A good suggestion in that. Maybe a simple trouble-shooting strategy like this:
On the color page, hit command-Y to create a second version of your grade (and preserve your original). Right-click and reset all notes and grades.
Now, with no node grades at all, do your comparison to make sure that your resolution is back to normal — you may even want to export a snippet for a reliable read of the end result. If it is still soft, then come back and let’s trouble-shoot some pre-grade conditions. (Or otherwise possible issues on the Deliver page.)
If the resolution is back, then recreate your grade, but as suggested, do just one operation on each node (and label each node), such as “log color wheels”; then next node; “saturation”, next node “advanced curves” or whatever. Then you will see easily where in the grading process the clip’s resolution is getting hit….
– b
“THE LOST SKELETON OF CADAVRA” –
-
I’m running 14.2 Studio. 14.1, and then the 14.2 upgrade in an attempt to fix, started crashing. A lot. I’ve found a correlation between the crashes and using all flavors of Prores codecs. I’m not 100% as I haven’t gone back to test it, but here are the clues:
The crashing started about the time I upgraded to Studio. I thought that was it, however, recently I had allowed Apple to do a pro-media codecs upgrade. Hmm, let me try a non-apple codec in Resolve. I changed optimized media and caching to DNxHR flavors. After that, things have been working pretty well. It is now a couple of months later and the beefy Documentary I am mastering — including a lot of editing of AE animation outputs, restorative work of archival, as well as replacements with final masters for archival and stock footage, in other words, heavily layered grading, noise reduction and use of many gpu OFX fx — it’s behaving rather well. It seems it will allow me to have Prores sources, which it then optimizes and caches as DNxHR, and it will allow me to export Prores. But I’ve nixed any internal digestion of Prores and Resolve’s stomach seems to be feeling better.
The way to confirm is to go back and change caching then play around a bit. Haven’t. But the correlation was pretty strong, and I’d done nothing else other than switch to DNx to try to fix things. (Well, I did other things — 14.2, downgrade to Resolve, etc., to no avail — but restored my install, so DNxHR is the only lasting change from initial conditions.)
“THE LOST SKELETON OF CADAVRA” –