DigiBeta to Some Place Else

We have been asked to play a DigiBeta tape or two, capture it on the G5 (AJA I/O) and deliver the resulting uncompressed files on some medium that's big enough.

The question is, how? Not mechanically. We got that licked. What's the best file structure to deliver?

The destination is a FCP station very similar to ours, but it's across town.

I know if you start recording FCP 4.5HD "QuickTimes" onto external media, all the resource forks, etc have to go too, or the destination machine isn't going to know what that file is. The files are created without filename extensions and we've run into problems with that.

Or we could save it all out as a high quality Photo JPEG movies. We use those all the time and they work.

Or....what?

Koz

If you put the file in a stuffit archive before delivery it will help solve the resource fork dilemma. This is most often seen between OS9 and OSX though, not so much when both machines are OSX.

that's a lot of space needed for those files.
why not a FW drive?

nick

<<<that's a lot of space needed for those files.>>>

That's what we're expecting, yes.

<<<why not a FW drive?>>>

Why not, indeed. That's probably what we'll do. The question is not the hardware. What do we put *on* the hardware so as to make the trip with the least pain.

I like the Stuffit idea. Can you do that with the programs normally available on a 10.3.8 machine?

Remember the task is to capture to FCP and save it all uncompressed onto a drive so somebody else on a far-away FCP can open it all with no trouble (we think the same version). I think it's 30 minutes or so, and we can capture it in chunks if necessary.

I may have hit one of those "It's so obvious, nobody knows the answer" problems.

Koz

I cant see what the problem is !
Just creat a project on your machine digitise uncompressed onto the firewire drive, then send firewire drive to client i have done this before no problems

yeah, simple uncompressed 10bit on the drive.

i like nickb's idea of an FCP project as well.

i dont see any problem with this.
except...

do they have the same hardware as you?? meaning the io box?
if not will an AJA codec file playback on their machine? probably, but i dont know.
can you capture as the standard Apple 10bit codec?

nick

<<<do they have the same hardware as you?? meaning the io box?>>>

Almost certainly not. That's why we're doing the work--that and our DigiBeta deck. We can probably assume that although the FCP 4.5HD may be the same, all the hardware is going to be different.

Also given that we can't capture directly to a FireWire drive because of the I/O sharing problem, we'll be capturing to an internal drive and moving it over.

The question is, what's "it?" The Capture Clip? Isn't it safer to drag the work onto the timeline and save it out as something known and standard?

We have gotten FCP videos before on a FireWire drive that we couldn't open, so I'm professionally gun shy. We got "that look" from the producers like, "This came from another Final Cut System, what are you doing wrong?"

I don't know, which is why I'm asking.

Koz

Surely if your FCP can run the files, then theirs can too? Does the Aja require additional plugins to work?

If you want, Koz, capture a few seconds and let me FTP the file (or email me), and I'll try to run it on my (non Aja) system. Don't do the stuffit thing, I want to see if there is an OSX to OSX problem too.

Greg,

Create a new project.

Import from the I/o in 10 Bit Uncompressed to an external fw drive (I'd use an 800). 30 mins of DigiBeta in NTSC will give you a qt.mov of about 50GB's. The data rate for 10 Bit is only about 30 Mbs. No problem for firewire. (BTW, there's a free file size calculator over at aja.com that will give you a more precise number.)

Save a copy of the project file also to the external drive.

Send it out. All they gotta do is plug in the external drive, pop open the project file and start editing.

hth,
Clay

<<<Import from the I/o in 10 Bit Uncompressed to an external fw drive (I'd use an 800).>>>

I would too. Unfortunately, we only have FW400s. We also don't even have that. The FireWire service has never worked connected at the same time as the IO. We use one or the other.

We hope to cure that with a FireWire card, but that will take a day or two, so we will be capturing to the large internal "video" drive.

<<<FTP.>>>

Grand idea. I was going to do something similar with the client. Let me bring the machines up and find out the address of the company FTP server..

Koz

Ummm, yes forget to mention, the external fw 800 or 400 drive(s) wants to be on an additional i.e. separate pci card (costs about 50-60 bucks) so as not to conflict with the I/o, the latter being a greedy little beast that can't be made to share the onboard fw bus with anyone ever.

Although, FTP = first class travel if the client can handle the data rate as well as allow large file sizes through.

Clay

<<<I/o, the latter being a greedy little beast that can't be made to share the onboard fw bus with anyone ever.>>>

So we're not the only ones. I was beginning to doubt my sanity there for a minute.

<<<FTP = first class travel...>>>

...for the test. The final will take up 73G which we will send on a FireWire drive.

I sent Jude two emails. One with the description of the work and the second with the FTP address and access info.

My guess is this isn't going to work. We imported these files to another machine and they lost all their personality.

Koz

The first level of tests are in.

Unless proven otherwise....

You may move a FCP 4.5HD capture clip to a foreign machine provided the second machine is also running FCP 4.5HD and it is necessary to append ".mov" to the end of the filename. It doesn't matter who puts the ".mov" on.

This trick doesn' t seem to work between different versions of FCP. Reactions vary, but the dominant one is a blank white screen and a complaint that the machine can't find the appropriate software.

Koz

Yup. Same here. I just got the first test file and FCP refused to recognise it until I added the .mov extension. Once I did this is was all fine though.

I am also in PAL land, and I pulled it into a PAL project for testing so I was happy to see the wonky frame rate was no problem.

Koz - it took me about 6 minutes to download the 78mb file, so I'm thinking that the 780mb file will take in excess of an hour to get! I've got a 1500k connection, but I think there may be lots of gates to open and close between you and me. Do you have enough info to be going on with, or do you need me to test the second file?

The .mov appendation sounds like a good safe bet, even if it turns out it's not required, it causes no harm..

<<<I am also in PAL land, and I pulled it into a PAL project for testing so I was happy to see the wonky frame rate was no problem.>>>

Were you able to pull it into a machine *not* running 4.5HD? I suspect this process is limited to machines running exactly the same version. This makes the technique a good deal less valuable that it might otherwise be.

It also calls into question all the people who claim they "do it all the time". We assume with other people running the same version as well.

There is nothing particularly valuable about the larger file. It's a full motion, 3:2 uncompressed commercial we did for Meowmix cat food. If the video was going to have problems, this would be the file. Any field, compression, transmission, or quality problems would show up immediately. The tape that produces the file is a clone-copy of the client delivered master.

My particular client is delighted with the capture/transfers.

The Operations People gulped a little when I said I wanted to post a file that big in the FTP service, but they did it. I owe them some chocolate.

If you're finished, I'm going to turn the FTP drive space back over to them. If you wanted to download the larger file overnight, it might be fun. Let me know

Cats ask for it by name.

Koz

Pull it off Koz - I can't really justify the bandwith at this end

I will take the bars into another job with me though and give it a shot on their FCP2. I imagine it won't work because I doubt if it is HD capable, but it will be interesting to see it's response anyway!

I know that there is no problem with compatibility going up in versions - we have a woman who often uses the betasp setup on the FCP2 os 9 that I mentioned to capture footage for her FCPHD onto a Lacie. As far as I know there isn't any problem. At least, she still does it, so it must be a profitable exercise...

OK I took the footage to the older system and it was a complete no go. Well, sort of. It did recognise that it was a quicktime movie, but it was unable to recognise the codec - which makes sense given that I think it's Quicktime 5.

Were there any HD capable systems before 4.5? Maybe if the recipient had a modern enough Quicktime player it would work?

Also - while I was there I did a test that I said I would do ages ago to see if my Edit To Tape function was frame accurate.

I pulled eight previous shows randomly out of the vault and checked the in times. Of the eight, seven were dead accurate, and one was 5 frames off.

Soo.. not sure what that means. I'm a bit surprised about such a large slip on the bad one. To date I've always assumed they were accurate because any pickups I have had to do were seamless.

Anyway. Interesting.

FWIW...

exported DV files from FCP4.5 today as Blackmagic 8+10bit.

.mov on the end opend them in Edit Box, no worries.

nick