Corrupt frames - please help

[Gunleik Groven]

It does look like a data xfer bug

One of the reasons I still recomend a transcode, despite "RAW" workflows and r#d datamanager.

Haven't had one single issue with SSD's, though - so I was about to ease up...

[Andrew Gentle]

I've only come across something like this once and unfortunately it was important footage. It started half way through a twenty minute clip and gets progressively worse until the clip starts strobing with dropped frames by the end. The only way I could render it was through DaVinci, RC-X P would crash when trying to render the clip. I transferred that footage from card to MBP through a Sonnet eSATA to ExpressCard adaptor, only with the Mac Finder at that time. My laptop is running OS X Lion so I would guess it's running in 64 bit mode. Since then I've been using a checksum copy utility but I haven't been able to replicate the issue. I'd love to know if it was corrupted in camera or during the transfer and if doing a checksum will catch errors like this in the future if the Sonnet is going to give trouble.

[Conrad Hunziker]

The idea here is that if the footage is important, you should visually verify the first copy. Scrubbing through it is ok, but watching in real time is best. From then on, if you know that all the zeros and ones add up to a valid image, you can confidently rely on checksums to ensure that further copies are accurate without visually verifying again. But before you visually verify the footage, you are relying on potentially faulty cables, faulty host adapters, hot CF cards to all produce an accurate image.

[Tim Bradley]

Thank you for all your suggestions.

The shoot was a two day shoot. The issue was only discovered late on day two by the post house when they were trans-coding the R3Ds into prores for offline. A total of 54 corrupt frames was found in Day One's footage. They were at random intervals and spread across 3 SSDs that were used. The SSDs were cycled through out the day after being back up to two external drives. SSDs were then re-formatted in camera and used again. Most Takes had no corrupt frames other had up to five.

On day two of the shoot the only change that was made was that the second backup drive was swapped as the first drive had gone to the post house. On Day two there were no corrupt frames at all.

The heat in the studio on day two was much hotter than day one.

The camera is running FW3.0.0.

Five different versions of Redcine were tried to see if the corrupt frames appeared on each. Also trans-coding with and with red Rocket. All this made no difference. The issue shows on both the R3D file and the prores file.

[Andrew Gentle]

The idea here is that if the footage is important, you should visually verify the first copy. Scrubbing through it is ok, but watching in real time is best.

Ideally, yes, and I'll keep that in mind for when we have the luxury of time. Unfortunately, in this situation, we were in the middle of an interview and it wasn't practical to watch through the whole mag before offloading and resuming the shoot.

[Nate Clapp]

switch your computer back to 32 bit and try playing your footage. willing to bet it will play back fine, as long as it is a checksum verified file. or connect the drive directly to fw800 connection (bypass the card =) and it should be fine. If I understand your problem. In my situation, to repeat, I was able to get most, but not all files to copy using either shotput or r3ddatamanager (both actually) but did get some errors. skipping ahead- some of the files that DID NOT have errors as reported by copy verification program would have repeatable glitches on playback. Made me think a camera error. A properly copied corrupt file if you know what I mean. Anyway, I got suspicious of the expresscard adapters (both esata and FW800 sonnet) I even returned one. But I realized problems happened around the time I switched my MBP to 64bit. I switched it back to 32 bit and, all the properly copied footage would play properly again. If I remember correctly, holding 3 and 2 down while booting will put your mac back into 32 bit.
So, being in 64 bit and using express card adapters was causing errors in some copies, which were reported by verification software, AND was causing playback problems of stuff that was otherwise properly copied. Essentially the communication was intermittently faulty. switched lots of cables, cards, no resolution. switch to 32bit and all problems went away.

[Conrad Hunziker]

Ideally, yes, and I'll keep that in mind for when we have the luxury of time. Unfortunately, in this situation, we were in the middle of an interview and it wasn't practical to watch through the whole mag before offloading and resuming the shoot.

Well, to be clear, you would watch AFTER the mag was offloaded not before, and from the destination media not the mag. But you should watch it before you reuse it, which means having more than one mag. I wont approach a shoot without enough to allow time for backup with checksums and reviewing footage before having to reuse that card. Some people reply "Well, I dont have that many cards" or "I cant afford that many cards" or "I dont have that type of manpower" - to which my reply would be "thats the risk".

Ive modified the workflow when appropriate to accommodate image verification. Ive even come in with 8 128Gb cards to shoot the whole day and move data management to a better/easier time. Data management is really risk management, and you just gotta stay on top of it.

[Philip Lima]

We had this exact same issue on 3-4 frames of one our recent shoots. We had a DIT cart on the shoot with a RAID, so I went back to the footage on that and found that it was clean. The error occurred when transferring from the DIT RAID to our SAN at the office. Checked all data and everything matched, but for some reason it still had errors. We have done at least two dozen shoots with the same combo (camera/card/DIT cart RAID/SAN/RedcineX to ProRES) and this is the first issue we've had. I happen to be out of the country during the shoot in which we had the issue, so I was not the DIT and don't know for sure if there were any problems on set with the data, but since it was fine on the RAID, I assume all went well.

[Steve Roberts]

I remember having a similar issue in the early RED One days. I found that if I formatted the CF cards in a different camera than the one we were filming on, the footage would come back with similar problems.
The remedy was to format the card on the camera we were using.

Could this be related to the same issue?

[Joe Shemesh]

Well, to be clear, you would watch AFTER the mag was offloaded not before, and from the destination media not the mag. But you should watch it before you reuse it, which means having more than one mag. I wont approach a shoot without enough to allow time for backup with checksums and reviewing footage before having to reuse that card. Some people reply "Well, I dont have that many cards" or "I cant afford that many cards" or "I dont have that type of manpower" - to which my reply would be "thats the risk".

Ive modified the workflow when appropriate to accommodate image verification. Ive even come in with 8 128Gb cards to shoot the whole day and move data management to a better/easier time. Data management is really risk management, and you just gotta stay on top of it.

Slightly different experience but even more scary -
Was downloading one of my 256GB mags to 2 seperate 2TB Lacie external drives. Used R3D data manager as standard practice. Checksum was complete with no apparent issues and I pressed the
accept button. On checking the destination folders, I found that only 14 of the original 33 Red clips were copied. Tried doing the download 4 more times with the same result. Ended up having to drag
and drop then check every one of the 33 clips before reformatting mag.
As Conrad rightly points out - you can't leave anything to chance when transferring media.
If you have any thoughts on this issue, would be good to know Conrad.

best
joe