R3D Problem

[Alexandra Curran]

I am working on a Red 3D shoot at the moment and we have run into a problem. After we had dumped the footage I noticed that, for the last two card dumps, the first clip of every roll Camera A(left eye) had filmed had been corrupted. The first couple seconds flipped in between a green screen and the footage accompanied by a high pitched screeching noise. We tried to fix the metadata by using Clipfinder, RedcineX, and any program we could think of to open the file and trim it. It wouldn't open.
At first we thought it was the camera's fault because the proxies were playing but not the raw file. We were using cards so we switched to RAM to be safe. Then it happened again.
This time it was to Camera B(right eye) to the first clip of the roll as well. We were able to play it back in the camera and the file was fine. The proxies had the same look as the previous corrupted files. Now we think it might be the dumping process, which is dragging and dropping, but wouldn't all of the files be corrupted if that was the case? I have never had a problem with it.
It is a very bizarre and dangerous mystery. If anyone has any answers or suggestions for us that would extremely helpful. We need figure this out to have a successful shoot. Thank you for your time.

 

[Scott Snare]

It's likely your card reader getting hot. It's a good idea to have several on set and rotate them. I used ice packs on the last feature to keep readers cool while shooting in the desert.

 

[joe hedge]

Dragging and dropping R3D's is a big no-no, break out your credit card and download either R3D Data Manager or ShotPut Pro immediately.

Hopefully you're using enterprise-class drives like G-Techs, OWC's, CalDigit, and not Western Digital My Books: Home Edition that the producers bought at Target

And they're either brand-new, or empty and freshly reformatted

And you're not net-surfing or playing Halo on the same system your backing up with while it's backing up

just askin'

 

[Alexandra Curran]

I am using internal drives for this shoot.
I will try the ice pack thing for the drive readers. Thanks for the suggestion.

No, I am not playing halo or anything at the same time. I do not even go on the internet with the same computer.

 

[Tim Sutherland]

This is 100% a result of drag-and-drop data management. As soon as I read the first frame was corrupt then I knew it was a bad transfer. Whatever you do, stop using drag and drop. You need a program with checksum verification if your data is important to you. R3D data manager is a lot cheaper ($79 I think) than re-shooting lost footage.

Please do more than put ice packs on the CF readers, as that cannot ensure that your data is safe. At least scrub through all your footage before erasing the Cards to be sure that your copy is good before losing your data. Do that even if you are using checksums.

Tim

 

[Conrad Hunziker]

Im working on a multiple-rig 3D shoot right now, and we have 2 dedicated downloaders, using my software, and watching all takes in real time for each eye. So far, not a lost frame. If theres even a question, the card is taken out of rotation until further inspection.

 

[Alexandra Curran]

Thanks to all of you. This is my first 3D shoot and I am learning more as I go. Nothing really prepares you for the real thing. We bought the R3D data manager. It is working well.
We are watching the cards, but since we only have 2 pairs of them so we can't take them out of rotation.

 

[Alexandra Curran]

We did take the cards out of rotation for a while when we first found the problem and used RAM. But when I saw that it was playing right in the camera I redumped the footage and the raw file was fine. It was decided that it was a dumping problem and not a card or camera problem so it was decided to go back to using the cards.

 

[Kim Frank]

This is 100% a result of drag-and-drop data management. As soon as I read the first frame was corrupt then I knew it was a bad transfer. Whatever you do, stop using drag and drop. You need a program with checksum verification if your data is important to you. R3D data manager is a lot cheaper ($79 I think) than re-shooting lost footage.

Please do more than put ice packs on the CF readers, as that cannot ensure that your data is safe. At least scrub through all your footage before erasing the Cards to be sure that your copy is good before losing your data. Do that even if you are using checksums.

Tim

Excuse me Tim, but its not 100% a result of dra-and-drop.
But Yes it's some component (Hardware) in the data transfer.
Even a program with checksum varification can't save you corrupt frames, cause it just verifies the data, that can even with corrupt frames be the same on every copy.
It may be a hot or faulty CF reader but it's also suggested to check your cables, drives, ports, etc. all Hardware that's part of the offloading pipeline.
Yes it's best to verify your copy before reformatting the original media, but scrubbing through the Footage isn't enough, cause this way you can still have corrupt frames, that you didn't recognize. You need to really playback the Clips in RedcineX for example (not just the proxies) and visually verify them start to finish. Only if you transcode than do a visual verification before reformatting the original media, you can be 100% sure your footage is fine.
But I thnk it would be a big help for users like the OP to simply know this issue it's causes and solloutions and am not getting tired of asking RED to take this simple thing of education into account.