-
Advice on docu workflow with SD tape footage, FCPX or not?
-
Just went through something similar. I found myself in a position of having to edit a four camera shoot, that was shot 12 years ago on DV tape… in letterbox, no less. That last part was actually an issue that created some challenges, but I digress.
I have a deck that will play DV, DVCAM, DVCPRO, that happens to have SDI out, which gives a better product than firewire. I really wanted to use FCP X to bring it in, but I wanted the timecode from the tapes to come through. Many of these inexpensive solutions that have been mentioned, don’t give us that. A high-end BlackMagic or AJA would certainly be a good choice.
In my case, some of this had been logged way back when in FCP. I used 7toX to bring the project over to X, to save some time, but it wasn’t necessary. In the end, for a variety of reasons, I ended up using FCP 7 to Capture all the footage and give me all the timecode. That was an important consideration for me. I then brought all the footage over to FCP X and did all the editing there. FCP X is definitely a lot faster, so I was glad I did that. Rendering quality is also higher.
Yes, as others have mentioned, FCP X does slow down on longer projects. The final length was right around 2 hours, but during editing it was around 3-1/2 hours in the beginning… and kept getting cut down as I went. I agree with Bill to a point, that you can do some things to avoid slowing down FCP X. Where I disagree is that it is a fact that FCP X slows down, even without composited graphics or giant stills. It just slows down as the project gets longer. Given the speed of the machine, we can rule that out. I’ll hazard a guess, and say that as the project gets longer, the database approaches some limit… or at least gets overwhelmed more. That’s not a criticism as much as an acknowledgement that this would certainly seem like a reasonable consequence to length and complication.
I also think complication is a factor. If you’re cutting a single track project with lots of cuts and some graphics, then it may not be as noticeable. Having four camera angles, grading, etc. certainly does haul it down. Still, the speed of X is so much higher than many of the alternatives can offset some of that to a point…
Mitch Ives
Insight Productions Corp.“Criticism may not be agreeable, but it is necessary. It fulfills the same function as pain in the human body. It calls attention to an unhealthy state of things.” – Winston Churchill
-
[Mitch Ives] “that happens to have SDI out, which gives a better product than firewire”
Wait… so you’re saying the quality of the 1’s and 0’s being moved was higher than the ones coming through Firewire? 😀
____________________________________________________
Deutsch? Hier gibt es ein umfassendes FCP X Training für dich! -
[Robin S. Kurz] “Wait… so you’re saying the quality of the 1’s and 0’s being moved was higher than the ones coming through Firewire? :-D”
Yep, and the guys at Sony said the same thing as you just did, until I asked them to run the same test on a DSR-1500 deck. I told them I didn’t know why, but it was observable. Maybe it was because you could go 10-bit or something? They were intrigued, because I showed them the same footage done each way.
They came back to me and said… yep, but we don’t know why. They said, component out looks better because the TBC was 10-bit and somehow involved, but didn’t know why the SDI did. They said that this was the source of a lot of amusement in the engineers over this.
Still don’t know why… the only explanation I could come up with must have been a codec difference?
Mitch Ives
Insight Productions Corp.“Criticism may not be agreeable, but it is necessary. It fulfills the same function as pain in the human body. It calls attention to an unhealthy state of things.” – Winston Churchill
-
[Robin S. Kurz] “Wait… so you’re saying the quality of the 1’s and 0’s being moved was higher than the ones coming through Firewire? :-D”
Can’t speak to what Mitch saw but Graeme Nattress (plugin maker, worked at RED developing their codecs, etc.,) wrote an extensive article a long time ago about chroma sampling, and did find benefits to capturing DV via SDI into an uncompressed codec (this predates ProRes). It obviously can’t add any more image detail than what exists on the DV tape, but it seemingly can help smooth out some of the jaggies in the chroma caused by the compression.
https://www.nattress.com/Chroma_Investigation/chromasampling.htm
-
[Mitch Ives] “Still don’t know why… the only explanation I could come up with must have been a codec difference?”
DV is DV is DV. And no version of it is 10bit. If that in fact made some sort of difference, then capturing ANY 8bit 4:2:0 codec as e.g. ProRes 422 would somehow magically breath new, improved life into it. It won’t. It’s purely subjective at best. (and you apparently lose parts of the TC in the process)
– RK
____________________________________________________
Deutsch? Hier gibt es ein umfassendes FCP X Training für dich! -
[Andrew Kimery] ” It obviously can’t add any more image detail than what exists on the DV tape, but it seemingly can help smooth out some of the jaggies in the chroma caused by the compression.
“I agree, I spent a lot of time as an Online Editor in a linear Digibeta suite and we saw this a lot. Perceived difference it may be, but it WAS a difference
-
[Robin S. Kurz] “DV is DV is DV.”
DV all adheres to DV specs, but the quality of the image that ends up on tape depends, in part, on the quality of the encoding done in camera. And once you get out of camera there are different flavors of the DV codec depending on what you are doing in post. Going back to an old post from Adam Wilt, “Some DV codecs, like Avid’s, filter or smooth the chroma on decompression (details here). Others, like Matrox’s, let you turn chroma filtering and interpolation on or off as you see fit. But the Apple codec used in Final Cut Pro doesn’t give you any choice: it’s steppy edges, all the way. ”
https://www.adamwilt.com/SteppyEdges.html
-
[Robin S. Kurz] “DV is DV is DV. And no version of it is 10bit. If that in fact made some sort of difference, then capturing ANY 8bit 4:2:0 codec as e.g. ProRes 422 would somehow magically breath new, improved life into it. It won’t. It’s purely subjective at best. (and you lose the TC in the process)”
Well, I, everyone who’s seen it and Sony disagree with you… but you’re probably smarter than all of us.
Why would I lose TC (he asks, since I don’t)…
Mitch Ives
Insight Productions Corp.“Criticism may not be agreeable, but it is necessary. It fulfills the same function as pain in the human body. It calls attention to an unhealthy state of things.” – Winston Churchill
-
[Mitch Ives] “but you’re probably smarter than all of us.”
Maybe. 😀 But feel free to point to which part of what I wrote is factually incorrect.
But granted, I don’t know what type of post-processing magic they’re (obviously) applying to the one or other port i.e. what the capturing hardware it’s going through could be doing. But then we’re not talking about the original, unadulterated DV stream anymore, no. In which case it’s kinda like saying that my TIFs oddly look better after I run them through Photoshop. 😀
But hey, if in fact something is happening post-wise on the port to improve matters, great! I wouldn’t know, no, since I always just used the (I guess) crappy DV port and cable back in the day.
[Mitch Ives] “Why would I lose TC “
“… to Capture all the footage and give me all the timecode” So parts of it? Though I don’t know what that actually means either, so I guess not? 🙂
– RK
____________________________________________________
Deutsch? Hier gibt es ein umfassendes FCP X Training für dich! -
[Robin S. Kurz] “DV is DV is DV.”
No two independent codec implementations are likely to produce exactly the same bitstream output given the same RGB input, nor exactly the same RGB output given the same bitstream input. That’s because while a codec standard must specify the format of its bitstream, it does not rigorously specify every mathematical detail for creating or interpreting it.
This is especially true with lossy codecs, where decisions must be made about what information to preserve and what to throw away during encoding, or how to try to fill in the missing information during decoding. For example, with DV, two compliant codecs may have different RGB/YUV conversions, or different discrete cosine transform algorithms, or different quantization/inverse-quantization algorithms.
Codecs are a bit like translators. Two independent translations of the same source text can differ, even while both are considered correct.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn]
Reply to this Discussion! Login or Sign Up