EX3 workflow
 

Before I start I really like Craig Seeman's analogy of "I have never used a seatbelt and been okay". We recently had an agency client who prefers to work with the EX3 and after visiting the forum and working with a loaner camera I determined that their suggested transfer method from SxS cards was flawed. They suggested just drag and drop from SxS to Portable HD. Due to time limitations that is the method we used and upon checking clips it did in fact work. Much like the seatbelt analogy I knew I was taking a chance, but was able to check clips on the HD before returning the SxS cards.

I did have post shoot time to experiment with the clip viewer with the recorded clips from the HD. The only method available to copy the clips was to go into each BAV folder and copy each individual Mp4. (I was curious to learn that using the clip viewer copy method it copied the whole BAV folder, maybe its BPV...still very new to this media handling don't quite have lingo down). Which was somewhat labor intensive vs the straight drag and drop copy.

So, is this the process for copying shot footage from the SxS cards and does it always involve these steps?

When using the drag and drop method, which I know is flawed, what is the worst that can happen happens. This method may be used from time to time and then when more time is available the proper method will be used.

ClipBrowser ONLY for copying. NEVER touch anything inside the BPAV unless you're using the equivalent of the "jaws of life" to rescue a victim because someone wasn't wearing a seat belt.

Point ClipBrowser to the parent folder of the BPAV folder and COPYALL to the destination you target in its preferences. Make sure CRC is also on in preferences.

As long as you don't mess around with the file structure drag and drop copying is fine - like copying any other data files. There's nothing 'special' about the media on the cards but the file structure is important.

Not not like any other data at all.

These are your camera masters. Bad copies happen just like any other data when you do that. Bad file equals reshoot, lost client, lost business. There's very good and sound technical reason why ClipBrowser offers CRC as well as ShotPutPro. Copy programs verify the copy matches the original.

I back up to a NexTo DI and USB drive which is expensive but safe and I also have enough SxS cards so that I don't have to reformat on a shoot, so I am in no way cavalier about this - all I'm saying is that the OS will copy data as safely as ClipBrowser or anything else, otherwise how could you move data from one place to another without constant errors?

Errors, like car accidents, don't have to be constant. They are rare but they can be fatal. That's why people wear seat belts. CRC was designed for a reason and is used by Sony and Imagine Products for a reason. The forums are filled with way too many stories of drag and drop only to discover the copy has an issue and the source long since been erased. If you're a professional it's simply not worth the risk. It's a risk measured in thousands of dollars/pounds/euros. You can drive for years without using a seat belt and claim you never had an accident. It's not safe.

I'm not really disagreeing with you Craig, it's just that I'm not convinced that errors are introduced in the drag and drop process, although I guess it's not impossible. Of course there might be errors in the recorded media but CRC won't detect these as far as I'm aware.

There's no point taking risks I agree, I'm very risk averse myself which is why I spend a lot of money on backup technology both in the field and in the edit.

But you are right - using ClipBrowser is safer as it removes the human error element if nothing else and preserves the file structure. The safest workflow is not to reformat in the field and BU asap to 2 separate drives.

I guess I've come full circle on this one :-) Use ClipBrowser or a NexTo DI if you must reformat on the shoot!

As I've said before, I'm not sure the CRC check isn't a placebo.

Your operating system will do a CRC check during any copying process. Its part of the OS. If you copy a Word document, you expect it to be copied identically. If your computer didn't copy files identically, you'll soon know about it.

Nobody has ever been able to explain what the Sony CRC does above and beyond what the computer does at OS level.

"Nobody has ever been able to explain what the Sony CRC does above and beyond what the computer does at OS level."

The Sony ClipBrowser lets you preview the MP4 files, my OS doesn't. That alone is a good enough reason to use it. I don't actually see what the problem is with using the ClipBrowser, it gets the job done.

I'm not saying don't use, what I am saying is that the OS will perform CRC checking as part of any copy process. So unless someone can say exactly what ClipBrowser does above and beyond the OS level copy, nobody should feel obligated to use it.

Or indeed using XDCAM Transfer instead, which gives me a nice convenient mov file at the end of the process (although we have done that debate to death many times).

CRC checking from my CNE for Novell days, (if anyone can remember that networking OS), was separated into two parts. One is a read CRC check, the other is a write CRC check. The OS will do a read CRC check on copy, and does write CRC check, but does not compare them unless instructed to do so. So the copy process will not generate and error, but will still be incomplete, or faulty.

We always used the XCOPY function with the "/V" argument set, for read/write and verify. It was the only way to guarantee that all the files were copied in their entirety and correctly. The OS was instructed to do a bit by bit check of each file copied.

FWIW, I believe that a copy using either explorer or finder not only doesn't do a write verification, but also does not even guarantee that every file will be copied. To make matters worse, I have never been able to figure out how to generate a log to be sure the copy was complete.

I think the Sony Clipbrowser will take longer to make a copy with the CRC turned on, because it is doing a destination to origin file for file check. So it will need to do a read from source, write to destination, and then read from source, and read from destination and compare.

Although now that I think about it, I'm beginning to like XCOPY again. It doesn't just check CRC, but checks bit for bit of every single file, and doesn't add that much to the copy overhead in my experience.

BTW Microsoft also make a free utility called RichCopy which can do all of this for you automatically. When I tested it, it worked great.

Don't forget about Shotput Pro for copying as well. Way faster than Clipbrowser and can do all kinds of conversions.

Thanks...
 

In a "hurry up and get it done" industry and time hurdle is often cleared in the fastest way possible. That was my experience on this project, I had to hand over a HD with files but had time to check the later and keep a copy to be sure everything was in tact and have a backup if things went wrong. So although I did use the drag and drop method I had a backup parachute. All this discussion is very helpful in grasping the workflow. Since this was a short term lease and I had little time to really work with the program and SxS cards I never really had time to get comfortable with Clip Browser. But in the little time I did use it, it felt awkward and somewhat clunky. From what I have read about ShotPut Pro this sounds like a more viable option. On occasion we also lease P2 and with this program doing both for $100 it appears to be a wise investment.

Hurry up and do the reshoot and you're not getting paid for it because the most important clip is bad and so is your backup. ClipBrowser with CRC is still much faster than real time. The ONLY time I can EVERY think of foregoing CRC is if you're doing a VNR (Video News Release) with an inflexible and impossibly tight deadline. "Hurry up" otherwise NEVER means sloppy and risky workflow.

The CopyAll function in ClipBrowser takes a minute to learn. Set destination in Preferences. Select the Card. CopyAll.