Mark Raudonis
Forum Replies Created
-
Here’s what we’re using.
https://www.eegent.com/hardware/hd-vanc-data-insertion/
Since you’re dealing with :30’s your idea may work too. In long form, it’s not so easy to
pass back and forth the full rez 90 minute show.Mark
-
Ernie,
I can only speak for our workflow and using captionmax.
I know that they can basically handle anything you send them and that they have their own
dubbing facilities.We have our own “caption inserter”, so we FTP to them a low res “off-line” reference QT with TimeCode
that matches the final master. They create the caption files and email us back a “.cap” file. We load that
into our “caption inserter” and when we output from FCP, the master has captioning on it. No dubs, no fuss. There are other ways to do this, but that’s how we do it.If you’re planning on outputting the caption info from FCP, make sure that your “i/o” box can do it. Not all can. (When it comes to HD… few can. Which is why we have an outboard “inserter” between the FCP and the mastering deck.
Hope this helps.
mark
-
We use: https://www.captionmax.com/
for much of our work. Very professional, competent. You know they’ll get it done right.Don’t know what the cost is for :30’s. We only do long form.
Mark
-
[Hans Hoffman] “Though we have a sizeable XSAN, there is currently no space on it for the show that I am in charge of posting”
Couple of questions: Does the person running your shop know that you’re doing this? Are you the person managing the SAN?
If you’ve answered “NO” to both of these, then go to that person and tell them to spend a couple of hundred bucks on two 1.5 terrabyte “bare” drives and install them in a local client system. Then you should off-load the least current media from the SAN and put YOUR STUFF on the SAN.
If you have a working SAN and you’re still struggling with this kind of convoluted workflow, you’re wasting time… yours and everyone else’s.
Mark
-
[Seb Ratcliffe] “As ever, a tight deadline so minimal conversion time would be a plus. “
Well, then perhaps they would have considered that before choosing to use five widely different formats.
There’s no easy answer to this. You’re in for a whopper of a render/conform session.Your best bet is to convert EVERYTHING to a single, common format, creating essentially new submasters from which you’ll edit AND conform. I’d suggest proresHD, and work in that resolution/timeline downconverting the final delivery master. That way you retain all of the benefits of working in HD, and you’ll have an HD master for future use. You’re going to have to up convert the film transfers… unless you can have the film retransfered to HD.
Good luck with this!
mark
-
[Mike Most] “And, in general, he’s right. “
Don’t agree. What about Vancouver? Atlanta? Chicago? DC? Knoxville? Nashville? I’ve spoke with people in each of these cities that have very large shared storage systems. The price and technology is enabling many shops that couldn’t perhaps justify the “shared work group” environment to now jump into the pool.
Plus, there are so many cable channels out there that the “home base” for many of them is no longer just LA and New York. The work IS spread around the country.
mark
-
[Bob Zelin] “The very fact that anyone can own 15 systems in a “secondary market” is amazing.”
Bob,
I think this will soon become quite commonplace. With the cost of storage continuing to go down, and the cost of ethernet based connectivity continuing to drop, the notion of a “secondary” market having
dozens of systems is NOT that far fetched. That’s actually my point of posting my previous comment.As price and technology enables a higher number of systems, you have to be careful that the connectivity
you choose can handle the (inevitable) growth. Of course, (anticipating Bob’s response) for the low cost of these systems, you can buy TWO when you need it.mark
-
What Mr. Zelin fails to mention is that almost all of the solutions
mentioned only work well for a limited amount of seats… usually less than 12.So, if you have a large number of seats, all pulling HD streams, ethernet may NOT
be your best choice. HD over ethernet works… but in it’s current form it doesn’t
scale well to a large number of seats.It’s encouraging to see the advances in connectivity that have enabled video over ethernet, but
if you’re specifying a system that’s expected to grow… you need to consider what happens when
your needs exceed the handful of streams currently available via ethernet.mark
-
[Rafael Amador] “Some times I spend weeks sleeping in huts and eating rats and bamboo-shots. “
For that, you can own it!!!! 🙂
On the other hand, this “ownership” argument really splits between those who work with a contract specifically spelling out their rights and those who don’t. Any person or company doing work for
a major network is going to have a phone book sized contract that goes into excruciating detail as to
who owns the copyright and what’s expected for delivery. End of story.It’s these smaller projects where nothing was put in writing that keeps the lawyers happy.
Mark
-
Soren,
From your questions it sounds like you’ve never been through this process before.
Let me cut to the chase: Translating your “speed changes” to the online process is going to be
more of a manual process than an automatic one. Unless you’ve done extensive testing to
confirm what translates accurately and what doesn’t, you can count on chaos in on-line IF you assume it’s going to go automatically. It won’t.If you’ve done any “speed ramping” you’re totally F*ckd!
What everyone seems to be telling you is that the “in point” will be accurate… the out point is NOT.
If the on-line editor knows what they’re doing, they can calculate the “slow down %” by using a “fit to fill” on the duration.
There’s no substitute for testing your workflow BEFORE you need it! This is why so many people have
taken to FINISHING on FCP and NOT trying to go out of the box for an on-line. With so many tools now available (color, After Effects, motion, etc), there’s less to be gained by going to the classic “on-line finish” other than a hefty invoice for services rendered.Mark