Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Big Problem with 4.5K Footage - Help needed!!!

D

Daniel von Herzen

Member
Joined
Oct 4, 2010
Messages
14
Reaction score
0
Points
0
Location
Munich, Germany
Website
www.vonherzen.org
Hi there,

we shot a short film on the RED MX (Build 32) in 4.5K WS and try to get our workflow with CS5 going but we experience huge problems with our footage. We first thought the problem might be Premiere CS5 but now we fear that the problem might be the data itself. Many clips can't be viewed properly in Premiere CS5, but also in RED CINE-X or Quicktime. Premiere for instance crashes after a couple of minutes of editing while Quicktime shows green frames and crashes then. These problems don't occure while scrubbing through the footage only while playing it in realtime. That is why we are hopeful that our material still exists even in the possibly corrupt files.

We figured out that some clips are OK and some are broken in some way. We don't know wether the camera dropped frames (which we should have recognized in the playbacks) or if it happened during the copy process of the footage. Some clips that seem to be corrupt on one of our hard drives are OK on the other one (and the other way around.)

If somebody has experienced similiar problems or knows anything about corrupt r3d-files, we'd be very thankful for help. Does anybody know a way to test corrupt r2d-files or even fix the corrupt parts of the data? We still hope that the problem is some kind of software or 4.5K-kind-of issue...

Thanks in advance
Daniel
 
Build 32? As far as I'm aware build 31.6.9 is the latest?

Is your CS5 updated to 5.0.2?

Also, are you using the latest RedCine-X build 346?

My first instinct would be that your data is ok. Still, what I'd do is make a backup and store it somewhere safe, then continue to work with the main copy.

Can you upload a shorter clip you are having trouble with to see if others can replicate the issues? It could be something on the Mac side too, especially if you're having issues in different software programs?

I'm happy to test a clip for you if you want to upload it to me. I'm on Windows 7 x64 so it would eliminate the Mac variable if it helps....

HTH

Paul
 
For me it sounds like corrupt files from the backup- process.
Are the files ok on the original RED- Media?
Do you use R3D- Manager to copy the data?
I've also experienced this kind of problem. You can't
repair the corrupt frames (maybe you can interpolate
the frame from the surrounding frames). I could export
the corrupt files via RED Cine X and the RED- Rocket.
It also played the files back, and i could saw broken
frames.

Gerhard
 
Thank you for the reply, Paul. It surely helps us and your first instinct gives us hope on top. I'm uploading a file we're having drouble with right now but I'm afraid it'll take a while (the smallest file I could find is about 750MB and my upload speed is not overwhelmingly fast). Thanks for your offer to test a clip, we appreciate it a lot.

I just doublechecked our data and found out that we actually shot on build 30.6.0 and not on some fictitious build 32. My bad :) Furthermore I checked my REDCINE-X-build: I was checking the files with build 261. I just downloaded build 346 and checked some files. Sadly they were still crashing the program sooner or later. Strange thing is that the frame that crashes isn't always the same (and differs from build 261 to build 346 as well). I surely don't know if this is a good or a bad sign.

One more thing I forgot to post: I also work on Windows 7 x64 but we tested the material on a Mac as well.

I'll send you a PM with a download link to the file. It might take until tomorrow though, I hope that's fine with you.

Thanks again
Daniel
 
To me this sounds like a faulty copy-job, too.

Fortunately you have two copies and if - as you say - one copy is good where the other is bad you could possibly edit yourself around the problem through splicing the media with the r3d export.

Just as a warning:
This may create some issues for you downline in the conform, so I'd have tested that before following the path I am suggesting.

Do you have access to the original media? Or is it all formatted and gone?
 
I'm going along with the faulty copy as well. If you want, I'll take a look at the uploaded clip too and will see what I think. Hopefully the original media was copied to more than one place and at least verified somewhere.
 
Hi Gerhard, thanks for your reply. It's kind of a relief that we are not the only ones experiencing this kind of problems. I guess corrupt files would be the worst case scenario but somehow a problem that could be solved somehow. By cutting around corrupt frames, oh dear... A bit of a problem is that we can't identify the broken frames (if there are any) properly.

We didn't use the R3D-Manager as far as I know. (Hope that wasn't our big mistake.)

Thanks
Daniel
 
Hi Jeff, thanks for your quick answer. Corrupt frames are the worst case scenario. We are not sure how anything like that could have happened and how we possibly could solve this problem. We are uploading one of the smallest files that are making problems and if possible, we will provide you with a link and are very interested in your opinion. It may take till tomorrow, till we are able to send the link. We appreciate your offer very much. Thank you for your help.
 
I could take a look, too.

You know that you can crop the r3d with RC-X?

If you play and see (ca) where the app goes down, you could just export a couple of secs on either side...
 
Hi Gunleik, thanks for your quick reply, unfortunately the original media files are gone in the process of formatting and using the cf cards again as source. Corrupt frames would be a real disaster. Is there any way to get media out of these files even if there are dropped or damaged frames? Maybe we could replace these frames with the material from the second backup volume.
Thank you for your help. It's very nice to know some caring people out there.
All the best.
Daniel
 
Hi Gunleik, sorry I read your second post after answering the first one. We can provide you with the link to the uploaded file and appreciate your help. It may take til tomorrow to upload the media and send out the link. Hopefully there might be any way of saving the files.
 
If you have a second backup, you should definitely restore a couple files from there to see if they have the same issue. Unfortunately, if the data was corrupted during the initial copy, or even on the original RED media itself, there is not a whole lot you can do. Perhaps some usable footage can be salvaged, I can't say without seeing the files. RED may have some techniques of their own to try, but if the data is corrupted or gone, then that may just be all there is to it.. It's corrupted and can't be recovered.

You don't need to use R3D Data Manager to copy files. But it is always good to visually verify footage after copying and also use a checksum or verification pass on the copy. R3D Data Manager is popular because it simplifies the checksum-verified copy procedure. Which will catch most issues with a faulty card reader or cable.

If the original media is being written with faulty data, there isn't much that can be done to check for that, other than to visually inspect the footage or to run it through a workflow scenario. The R3D files do not store checksum or verification info within the files, so if the CF module in the camera is causing corruption, you may never know it and this can even pass through R3D Data Manager or other tools that only verify they copy exactly what is on the RED media. And don't verify if that data is actually good to begin with.

If you were just doing a straight copy from the media over to the offload system, a faulty CF reader or faulty cables can cause corruption that may not trigger an OS error on the copy operation. This is why people do verification.
 
Isolate the problem.

If you are playing back the same R3D well from one HDD that is corrupt on another then likely it is a backup issue and boils down to poor on set data workflow.
Collect all the good R3D files from the various HDD to one master copy and create a redundant backup of that. Then find all shots that have only a corrupt version and find out the nature of their corruption.

Play them back on a few other systems Mac and PC see if there are any consistencies between the file corruptions.
If the R3D is intact and playing back well on one system but not on another may be a problem with the system.

I have experienced faulty CF modules before if this is the case you should be able to play the proxies in QT. If the R3D was written corrupt the corresponding corrupt frames may well play back through the proxy in QT player as either a distorted image or a green or black frame. To that matter you can extracte stills of the corrupt frames in a QT environment or from the R3D in RedcineX and post to show us.

If the corruption occurred during backup there is a good chance the proxies won't play back at all.

Lastly I have found with corrupt R3D files that some of them play more frames in Redalert than RedcineX. Try opening the R3D files with various Red software you may still be able to play a good portion of the clip before it reaches a corrupt bit of data. This means you may well be able to export an HD version of the clip around the corrupt parts.

Hope this helps, good luck.
Nir.
 
Hello again,
we try to specify our problem by trying some of the analysis you recommended. Meanwhile we are uploading one file which is a good example for our problem.
We are not sure, if a backup workflow or a wrong firewire cable or card reader can cause this kind of problem. Wouldn't it be logic, that the data is not accessible at all?
It doesn't make sense yet, but we are looking forward to read your opinion about the example file we are uploading.

Best regards and thank you
Daniel
 
I've found out that the RED Rocket (with RED Cine X) is able to play back the corrupt files and show the broken frame. It appeared as a kind of relief on only one half of the frame. I also was able to export the faulty clip via RED Cine, so the files was usable. If this was also your problem, then there is hope ;)

In my case the faulty frames were caused via the backup- process (the original media was ok). After using a verified copy (R3D- Manager) the problem was solved. Although you still have to check visually (as Jeff stated), but only scrubbing through the footage didn't help to catch broken frames.

Best
Gerhard
 
Hi Daniel
If the insulation of the cable connecting the card reader to the computer port was faulty. There is a good chance that the external environment influenced the flow of energy i.e data through the cable. This could be from the magnet of a near by audio speaker or a field spread out by another faulty cable. Or fluctuations in the energy supply, if you didn't use a UPS, could have disrupted the destination HDD or power supply to the card reader.
The signal itself could have been randomly altered by these external influences.

Either way the power supply wasn't cut the operations didn't terminate and there for data packets continued to move down the bus you used. The computer sampled them regardless of their integrity and as a result wrote data to the destination that was different to that at the source.
I certainly hope that isn't the case, though sounds like it is. We will see once the test R3D has been uploaded/downloaded.
Nir.
 
Just wanted to give you guys an update on our "situation": We figured that we have just about 85 corrupt clips in our material and right now we're trying to save what can be saved. Actually we're pretty optimistic since we can use Redcine-X to locate the bad frames and cut around these frames. It's good that the material is damaged differently on our two backup-hdds. Well anyways: Thanks again for your help!

Cheers
Daniel
 
You must log in or register to reply here.
Back
Top