"Failed to Decode (Corrupt Frame)" error compromised a whole shooting day URGENT

[Victor Trichkov]

"Failed to Decode (Corrupt Frame)" error compromised a whole shooting day URGENT

Yesterday, we upgraded the latest firmware 5.1.23 on our Epic MX and today we had a shooting for high profile international commercial. Everything was fine the whole day, no errors in the camera no messages. After copying the material it turned out that 20% of the material is corrupt (on random principle). The files open in redcine or in any other software compatible with R3D files, but at some point during the playback.decode this error pops up and the rest of the file is unreadable. The bug is very dangerous, because there is no evidence of problem while shooting. Please help, because a client is sitting and a lot of money are on stake. Thanks in advance.
P.s. I wrote to red support couple of hours ago but no response so far.

Victor

 

[Craig Weeding]

Hello Victor

I have had problems in the past where one bae 4gb R3D file in a clip stopped rendering and transcoding.
A quick work around I found for this is since REDCINE always starts with the lowest numbered R3D file in a clip
I drag a copy of the last 4GB file in to a separate folder and try opening that file in that folder with REDCINE if it opens, I then drag the next highest numbered R3D file into the folder and see if that will open,
continue this process untill one of the 4GB R3D files will not open, that is your bad file, take it out of the folder for later use with RED Undead
Depending on the compression ratio you shot at each 4GB file is approx 1-2 min of footage.
So if only one clip is corupted you will be missing only that 1-2 min of footage .
When you render or transcode clip do it from two folders with R3D files in them one folder from the start to the last 4GB R3D file before the bad file and one folder with the first 4GB file after the bad file to the end.

when you have time try running redundead on the bad file.

Good Luck

 

[Andy White]

Do you still have the original SSD's?

If you have them, check against your transfers to see if the error is in the recorded file or via the transfer.

Just a thought.

 

[Craig Weeding]

Hello Victor

Another item I remembered, is in past versions of REDCINE when transcoding R3D clips with problems, The software version (redrocket no enabled) would render files with problems,
the problems would some times show up as artifacts in the image, when the redrocket was enabled the frame had a decode error and just a black frame.
The artifacts were often much less visible or gone at 1/2 or 1/4 debayer display and were worst at full debayer. Sometimes the 1/2 debayer would be usable or if the artifact was in the back ground of the image the background from another image could be comped in.

 

[Tim Bradley]

Do you still have the original SSD's?

If you have them, check against your transfers to see if the error is in the recorded file or via the transfer.

Just a thought.

I have had transfer issues that were all okay when retransfered off the original SSDs if the footage still exists on them.

Good luck.

 

[Gunleik Groven]

RED undead has fixed bad Xfers for me on an occasion.

 

[Victor Trichkov]

Thanks for the suggestions guys, I transferred the files witch checksums and everything is verified. I have the cards and I tried to copy the content over again but with the same unfortunate results. I tried even to open the files in redcine directly from the cards, but again - no luck. I put the cards back to the camera and played back the clips from there, but when the playback reaches the bad frame it just stops or starts over depending on the playback mode set. The issue is not the copy process, the cards or the software (because I tried to open the files in Nuke and some other software that supports r3d files). The issue is the camera or the firmware. What makes this bug very mean is that there is no way for you to understand if anything is wrong before copying and trying to transcode the files and usually at that time it is already too late. I will try the red undead program and see if it fixes anything.

Victor

 

[Marc Berger]

Hi Victor,
copy every clip to another folder. Like that you can figure out which ones are infected by this issue. I had it once only on one clip, but all the following clips did not work too. Once I isolated the bad one(s) in a separate folder I could save all the others.
Maybe this helps you to decrease the 20% lost to a minimum.
I would strongly recommend to go back from beta build to the release one, but it could also be a hardware fault. In my case it was hardware related.
To play a corrupted clip in RCX I would disable the RedRocket.
Marc

 

[Tim Bradley]

I had a copy error that was not detected by check sums. It ended up being an issue that I could not track down the source but after changing laptops to re copy all was fine.
I know this doesn't help you much, but I too was convinced it was a camera or firmware issue. Even sent my camera back to Red twice. It in my case was a transfer issue. An issue that R3Data and double data did not identify.
I finally tracked down and confirmed where the issue was starting (in the transfer via one of my laptops) by having two different cameras and two laptops on set to test with both.
I hope you sort the issue. Feel free to contact me if you want to discuss further.

 

[Victor Trichkov]

I had a copy error that was not detected by check sums. It ended up being an issue that I could not track down the source but after changing laptops to re copy all was fine.
I know this doesn't help you much, but I too was convinced it was a camera or firmware issue. Even sent my camera back to Red twice. It in my case was a transfer issue. An issue that R3Data and double data did not identify.
I finally tracked down and confirmed where the issue was starting (in the transfer via one of my laptops) by having two different cameras and two laptops on set to test with both.

I hope you sort the issue. Feel free to contact me if you want to discuss further.

Thanks for the suggestion Tim, but I tried to play the files directly from the SSD and in the camera. I think this excludes the option of faulty transfer. What do you think?

Victor

 

[Jeff Brown]

Hate to say it but why would you roll to a Beta firmware the day before a high profile commercial?

I hope you sort the problem out but it does clearly state these builds are for testing only.

 

[Victor Trichkov]

There is a new development from today. All bad files can be played in the camera without problem. I can swear that yesterday they were not good in the camera as well, but it was so crazy few days that I might be wrong. I tried again to read the files directly from the cards using two different card readers on two different machines and the results are the same - all files are corrupt at the same marks. For your info all files are smaller than 4Gb, no no sequence of R3Ds

 

[Victor Trichkov]

Hate to say it but why would you roll to a Beta firmware the day before a high profile commercial?

I hope you sort the problem out but it does clearly state these builds are for testing only.

The reason was that I never had a problem with betas firmware and I did full day of various tests before the shooting day without any issues. The bug is very mean it is hard to catch, especially when all files play back fine in the camera...

 

[Andy White]

There is a new development from today. All bad files can be played in the camera without problem. I can swear that yesterday they were not good in the camera as well, but it was so crazy few days that I might be wrong. I tried again to read the files directly from the cards using two different card readers on two different machines and the results are the same - all files are corrupt at the same marks. For your info all files are smaller than 4Gb, no no sequence of R3Ds

So, you have the SSD's and all the R3D's are fine? That's good

In that case, it's at least a 'half win' as you haven't lost the footage! It feels like it's a transfer issue (as was suggested earlier) - so maybe try a different method to copy/back them up... are the two machines you've tried both Macs or PC's... are you running on AC... what software are you running (etc)?

At least, with the SSD's/R3D's working via in-camera playback, you know the footage is there - it's a case of examining your DIT/copy pipeline to try and track the issue.

 

[ericyoung]

There is a new development from today. All bad files can be played in the camera without problem. I can swear that yesterday they were not good in the camera as well, but it was so crazy few days that I might be wrong. I tried again to read the files directly from the cards using two different card readers on two different machines and the results are the same - all files are corrupt at the same marks. For your info all files are smaller than 4Gb, no no sequence of R3Ds

Assume you have you swapped cables?

As Andy White suggested, you need to start systematically eliminating variables. If you were using USB3, try USB2, Firewire800, eSATA.
If using Mac, try a PC. Or vice versa.

What kind of checksums were you using, and which copying program and version?

And so on.

 

[Victor Trichkov]

Assume you have you swapped cables?

As Andy White suggested, you need to start systematically eliminating variables. If you were using USB3, try USB2, Firewire800, eSATA.
If using Mac, try a PC. Or vice versa.

What kind of checksums were you using, and which copying program and version?

And so on.

Eric, this was the first thing to test. I tested on 3 different machines (Macs and PCs) I tested on 2 different card readers with USB3, FW800, USB2 and eSATA. I tested 6 different cables. It is not the reader and the transfer, because as I said even without copying the files and reading the files directly in the file reader I get errors on exact same files at exact same frames every time I test.

I was told from RED that I have hardware fault of the camera and it needs to be returned. I decided before this to install the release build of the firmware and all issues were gone. I spend a whole day of testing and more than 500 clips without single issue. Then I re-installed the latest beta and all "decode errors" re-apear (just after 3 clips shot). It is obvious that the new firmware is the issue with combination of something in my camera. Since nobody complained about this so far, I guess I have a faulty component that was not used before the latest beta was released or something simillar. Thanks a lot for your suggestions

Victor

 

[Christoffer Aldell]

I'm having the same issue. Footage from about half a day is ruined for me from a feature film. Unfortunately it was one of our more expensive days. Once Redcine-X or FCPX reaches a certain frame in some of the takes it quits unexpectedly. I don't know what to do about it.

 

[ericyoung]

I'm having the same issue. Footage from about half a day is ruined for me from a feature film. Unfortunately it was one of our more expensive days. Once Redcine-X or FCPX reaches a certain frame in some of the takes it quits unexpectedly. I don't know what to do about it.

But the clips playback in the camera? If they do, then ask Red Support for help if you haven't already.

Try doing R3D Trim around the particular frame(s) where it stops. You may be able to retrieve most of the footage and then Twixtor/interpolate the missing frames if there aren't too many of them.

Also try disabling Red Rocket for the affected clips, if you are using it.

 

[Christoffer Aldell]

But the clips playback in the camera? If they do, then ask Red Support for help if you haven't already.

Try doing R3D Trim around the particular frame(s) where it stops. You may be able to retrieve most of the footage and then Twixtor/interpolate the missing frames if there aren't too many of them.

Also try disabling Red Rocket for the affected clips, if you are using it.

Thanks for the tips, I really appreciate it. In this case, it seemed to be a bad transfer to one of our external harddrives. I just spoke to another guy who has our back-up drives and the same files were all good on his drive. Let me tell you I was so stoked to find out it was just my copies of the files that were bad. Again thanks for the tips, I'll keep it in mind for future reference should this ever happen again.

 

[ericyoung]

Thanks for the tips, I really appreciate it. In this case, it seemed to be a bad transfer to one of our external harddrives. I just spoke to another guy who has our back-up drives and the same files were all good on his drive. Let me tell you I was so stoked to find out it was just my copies of the files that were bad. Again thanks for the tips, I'll keep it in mind for future reference should this ever happen again.

Glad to hear. Make sure you make another copy of the good clips before doing anything else!

Consider use of MD5 checksum software to help confirm copies are good.