r3datamanger checksums really that important?

[I Bloom]

Ian - obviously you are a more advance computer user. You probably have your system tuned in, do regular checks of your drives, etc. However, most people are not. Ive had a people call me out on my software telling me it was crap and that other methods were better - because my software was always failing their transfers. Then a week later they reply that their new harddrive failed or the card reader was not up to spec. Turns out that R3D Data Manager was identifying a problem that other software was missing or didnt check at all.

I wasn't making a criticism of R3D data manager, I was speaking of checksuming in general. I hear good things about your software and I know how hard you must have worked on it.

But on another level, you didn't write your own copy command did you (I hope not.) You are just calling a Unix command to make a copy. So is Finder when you drag and drop a group of files. So am I when I type cp -R into the terminal. We are all using the exact same code in fact. We'd be foolish not to.

Most software is also relying on the old unix infrastructure to calculate checksums. So in fact any criticism I make about this is really talking about the underlying technology. R3D Data manager, like Crimson, is mostly a front end.

In addition, most people on set simply dont have time to read the output of complex copy commands or check data sizes. After a 14 hour day, all I want to do is go home, thats for sure. So R3D Data Manager has a simple success/fail - and if you want more info, you can check the report. If you want even more info, you can see the activity log.

The end of a 14 hour day is when bad things happen to footage, whether we are clicking one button or a few.

But more importantly, R3D Data Manager removes a lot of area for human error. Select the root of the Red Media on set, and it will copy all the footage, every time. It will make sure everything was copied, and copied correctly. It will do 90% of the checks you should do as a DAS/DIT in an automated fashion, with one click. This way, you can click copy and do other more important tasks.

If you don't go yourself and look at the filesystem after you think you've made a transfer, you are in for real trouble. It doesn't matter what software you use or how tired you are.

Like I said I don't have an issue with R3D data manager, I think it's great and I've considered buying it. (Actually I have something we can barter maybe Knowing something about software I think it might be better to use a general syncing tool instead. The addressable market for Red workflow is pretty small compared to the number of users using some of the most popular syncing apps (Lets say by several orders of magnitude.). Software is like airplane designs, the more popular they are the more chances they've had to crash.

My main issue is with the idea that not being directly involved in the transfer process and looking closely at the results is ever a good idea. In other words, it's not possible to write software to solve the main risks to footage on set since these are mainly human mistakes.

Checksuming while theoretically helpful, costs a lot of time, that in my experience can create more problems than it solves. Like I said, it's easy to prove me wrong, show me the files that passed my test and failed a checksum.

Ian

 

[Steve Sherrick]

I'll throw my .02 cents in here. I think there are valid points all around.

R3D Data Manger has provided me with a nice interface for setting up data transfers on RED jobs where I can choose to do checksumming if there is time allowed in the schedule for this or to bypass it and do straight copies. I like the interface, I like being able to create a text file that stores information about the shoot, which files were copied, etc. The program has identified copy problems and allowed me to retransfer those files. It also has provided access to the render engine if I want to use it to transcode.

Now, as I understand it, isn't it possible for a transferred file to seem okay, but could in fact have corruption that can manifest itself more in later generations? Wouldn't these types of corruptions have a better chance of being caught in checksum process?

My goal is to provide the production as close to a failsafe backup method as time and money will allow. I have used the straight copy method without issue, but never feel as good about it. Maybe that's false fear. But I always feel good after seeing that big green checkmark come up in R3D Data Manager. I feel like the drive is ready to go back to the camera department.

I will say, I am hearing about shoots that have skimped on the DIT/Data Manager and running into all kinds of problems. Human error having a lot to do with this. Scary to me.

 

[Conrad Hunziker]

I wasn't making a criticism of R3D data manager, I was speaking of checksuming in general. I hear good things about your software and I know how hard you must have worked on it.

To be clear Ian - I wasnt commenting negatively on your abilities or computer savvy. Clearly, being a software author, you have a better command of the computer than most.

That being said, the comment was directed at those who dont realize that the Red is nothing but a computer with a lens attached. In that way, the resulting footage must be treated differently than the traditional methods used for film. In film, you just had to make sure it was kept in the dark until developed in the lab. However with these new-fangled computers, its quite a bit more complex, and there are thousands of little gotchas that will ruin footage.

With users that are less computer savvy each of these gotchas will present itself as a opportunity to ruin footage and cost tens to millions of dollars depending on the shot, scope, and budget.

So, while I didnt write the code for copying, I did write the code that includes "cp -R" with all the other checks: filesystem, copy results, disk space, copied files, copied size, etc. Knowing you Ian, all these checks are the ones you are doing already with your eyes, scanning the copy results. But for the less computer savvy, they may not even know, or much less have the time, to accurately decipher the results. Other software, such as finder, doesnt do any of that, or fails silently when errors do occur.

The end of a 14 hour day is when bad things happen to footage, whether we are clicking one button or a few.

Agreed. However, if you have one button to press, theres 1/30th the risk than if you have 30 keystrokes. Either way, the less chance for human error, the better.

If you don't go yourself and look at the filesystem after you think you've made a transfer, you are in for real trouble. It doesn't matter what software you use or how tired you are.

Agreed. Proper data management consists of 3 aspects: verify that all the data was transferred, that all data was transferred correctly, and is valid image data. R3D Data Manager will only accomplish 2 of those.

The addressable market for Red workflow is pretty small compared to the number of users using some of the most popular syncing apps (Lets say by several orders of magnitude.).

This is true, however, every syncing app Ive encountered to date fails to provide at least one aspect that R3D Data Manager provides - which is why I wrote the first version when camera #30 was released. The majority of the tools dont provide some way for re-verification of data once the original is destroyed (as it will be for all red media, unless you have deep pockets or are Jannard's friend, "Mr SS" ).

My main issue is with the idea that not being directly involved in the transfer process and looking closely at the results is ever a good idea. In other words, it's not possible to write software to solve the main risks to footage on set since these are mainly human mistakes.

I agree- the overwhelming majority of mistakes that cause loss of data are human errors. But again, data management is risk mitigation. If your method for copying requires 30 keystrokes, there is 30 chances for human error. If my software only requires one click, there is one chance for human error to do exactly the same thing. Now, a tired user is still just as likely to mistake a red X (symbolizing a bad copy) as a green checkmark, but thats 1/30th the amount of human error that is involved than if you have to scan 30 lines of text to see if there was an error. And that tired user has the exact same chance for driving off a cliff with the footage after working a long day - but hopefuly he was smart and left a copy back on the truck.

Point is, the less chance of human error the better. You will always have humans doing stupid things - Ive done enough of them to know Ill never be perfect. However, the easier you can make it for the end user, the better we all will be.

Checksuming while theoretically helpful, costs a lot of time, that in my experience can create more problems than it solves. Like I said, it's easy to prove me wrong, show me the files that passed my test and failed a checksum.

Sure- Ive attached 2 files. They are RTF files that I just created, out of the blue. I typed a bunch of junk, and then copied it bunch of times. I then went in and changed a letter in the text. Both file sizes are 3361 bytes exact, and are valid RTF files. But they hash out differently.

MD5 (/Users/Photocon/Documents/test1.rtf) = 94265a688643012dec3e678eab0f72a5
MD5 (/Users/Photocon/Documents/test2.rtf) = 6ceeffb2c9c6ae485b0adc02804861f9

So which file is valid?

***
EDIT: Because of upload restrictions, I had to change to .doc files. I cant upload rtf files to the board. So, the files are exactly 19,456 bytes each, and hash out as follows:

MD5 (/Users/Photocon/Documents/test1.doc) = 988bcb68ed6c387bf18e616cd131dc90
MD5 (/Users/Photocon/Documents/test2.doc) = b3972284c47e3c54b002605debb8fead

But, you can re-create the test on your own with 4kb files and see it works down to that level also
***

If I can do that with simple 4kb files, how many times can that happen when you are running 2Gb per minute? Add in the risk of hardware failures and misreads, and its not pretty. R3D Data Manager (when using checksums) would catch it. Simple finder copies would not catch it. Depending on what exact bits are out of order, it may not show up in a scrub of the footage in quicktime.

Checksums have been at the core for verifying data for some time now. This is not a new concept for those in the computer industry. Checksums were invented in the 1960's as a means to verify data on tapes. Today checksums are used in RAID 5 and RAID 6 setups all the time, and are a part of the code that resides in each ECC stick of computer memory. If you download software from the internet, checksums are THE way to verify your download was correct, and not modified in transit or by a hacker (in fact MD5 and SHA1 are the types of checksums used for that purpose). This is not a new concept, but one that has proven itself over time.

One final point - there seems to be a tendency these days on shows to try and do more with less people. So if on the big budget shows you wish to use your own workflow that works for you, thats great. I do hope you include some sort of checksum in the process (and most likely whoever is funding the project will require it). But for those that are truly re-defining the definition of multi-tasking, R3D Data Manager should fit the bill pretty nicely.

To be clear, I am not attacking any user for any method they choose to use. Whatever method you wish to use that works for you, great. That being said, I do believe down to the very core of my body that you must always include a checksum for data that is this important. If I didnt believe that, I wouldnt have spent the thousands of hours coding software trying to make it easy for people to do exactly that. And honestly, I believe that if you dont checksum your data, dont bother taking the camera out of the box for a client.

 

[Conrad Hunziker]

Now, as I understand it, isn't it possible for a transferred file to seem okay, but could in fact have corruption that can manifest itself more in later generations? Wouldn't these types of corruptions have a better chance of being caught in checksum process?

It is entirely possible for a transferred file via finder to actually not be an exact copy. Depending on where the data differs, the data may still be valid image data, but it is not an exact copy.

Checksumming will catch each time a file is mis-read. A file could be correctly written to disk and later mis-read, or it could be incorrect data written to the disk that was correctly read (ending up in incorrect data). Either way, a checksum will catch both scenarios. If one bit is different - as shown in my example in the previous post - the checksums will be wildly different.

As for a simple corruption magnifying in later copies, I suppose it would depend on your exact methodology and process as to if that were to happen. For example, I can imagine an instance where a hard drive was starting to fail, and you used that drive as a source for copies A, B and C. Copies B and C may have more errors than A as the drive dies.

Strictly speaking, an error in the data would just be repeated in each generation of the copy. Say you had a drive and made copy A from it, and from A made B and from B made C. If the error was in copy B, then copy C would have the same error, but not copy A (assuming that copy C correctly wrote all of copy B). So in each generation you would be repeating the errors, not magnifying them (again, assuming no hardware/user issues).

And in the last example, checksums would identify copy B and C and invalid and copy A as valid. You would then know to make more copies of copy A and to ditch copies B and C. By interpolation, you would also know that there may be hardware errors on the systems that touched copies B and C, and could start to diagnose those (or at least carefully watch).

 

[Conrad Hunziker]

Now, this is very much in theory, in reality I guess other things come into play. As said before: faulty card readers, bad hard disks, quirky firmware on CF cards which could make the risk on a certain shoot much higher, up to the point where is it almost inevitable. But that's where a DIT's skill come into play, detecting faulty hardware and keeping up to date with developments.

But thats exactly the point about checksums. How else would you know that any data was bad data? Just because the data may be valid image data, or at least playable, doesnt mean it is an exact copy. And unless you are doing checksums, how else would you know when your hardware is starting to fail?

The reality I have experienced doesnt match up against your numbers. Three of the errors I had personally happened on one 2 day shoot, with less than 500Gb of footage. Turns out that the clients hard drives were bad. But by your numbers (1 in 9000) I would have a 0.01% chance of failure. But it happened 3 times in 2 days, for a 4.1% chance (72 copy runs (36 mags * 2 copies each) in 2 days).

I have no idea if I would have caught those errors with just using a finder copy. However, I know I didnt have any errors because I used checksums.

 

[I Bloom]

On a personal note, Ian, will you be at NAB? We should hook up for a brewski....

I'll be in L.A. all next week. You, me and Fasnacht sounds like a plan.

 

[I Bloom]

Sure- Ive attached 2 files. They are RTF files that I just created, out of the blue. I typed a bunch of junk, and then copied it bunch of times. I then went in and changed a letter in the text. Both file sizes are 3361 bytes exact, and are valid RTF files. But they hash out differently.

MD5 (/Users/Photocon/Documents/test1.rtf) = 94265a688643012dec3e678eab0f72a5
MD5 (/Users/Photocon/Documents/test2.rtf) = 6ceeffb2c9c6ae485b0adc02804861f9

So which file is valid?

***
EDIT: Because of upload restrictions, I had to change to .doc files. I cant upload rtf files to the board. So, the files are exactly 19,456 bytes each, and hash out as follows:

MD5 (/Users/Photocon/Documents/test1.doc) = 988bcb68ed6c387bf18e616cd131dc90
MD5 (/Users/Photocon/Documents/test2.doc) = b3972284c47e3c54b002605debb8fead

But, you can re-create the test on your own with 4kb files and see it works down to that level also
***

If I can do that with simple 4kb files, how many times can that happen when you are running 2Gb per minute? Add in the risk of hardware failures and misreads, and its not pretty. R3D Data Manager (when using checksums) would catch it. Simple finder copies would not catch it. Depending on what exact bits are out of order, it may not show up in a scrub of the footage in quicktime.

Checksums have been at the core for verifying data for some time now. This is not a new concept for those in the computer industry. Checksums were invented in the 1960's as a means to verify data on tapes. Today checksums are used in RAID 5 and RAID 6 setups all the time, and are a part of the code that resides in each ECC stick of computer memory. If you download software from the internet, checksums are THE way to verify your download was correct, and not modified in transit or by a hacker (in fact MD5 and SHA1 are the types of checksums used for that purpose). This is not a new concept, but one that has proven itself over time.

To be clear, I am not attacking any user for any method they choose to use. Whatever method you wish to use that works for you, great. That being said, I do believe down to the very core of my body that you must always include a checksum for data that is this important. If I didnt believe that, I wouldnt have spent the thousands of hours coding software trying to make it easy for people to do exactly that. And honestly, I believe that if you dont checksum your data, dont bother taking the camera out of the box for a client.

You missed the second part of my test. Reviewing the footage. Text files don't apply here, we are talking about R3D's that are being copied from one drive to another. An R3D file is a very specifically encoded very large file. While there is some fault tolerance built in, in general the frames won't load if it is at all corrupted. In addition the corruption needs to be created by copying the files from one place to another there by passing the cyclic redundancy checks built into MacOSX/Unix.

I fully understand the math behind MD5 and SHA1. I've stated before that this is the only way to be mathematically certain that two files are the same. There is an astronomically low probability that two files could have the same checksum and be different. It's just also very expensive computationally to get those sums.

I think there is also an extremely low probability that files are corrupted, if they copy properly and you check their playback. Especially when you copy to a master and backup drives. And that probability is low enough (though not astronomically low) to out-way the disadvantages of running a checksum on all of the footage.

The original poster was talking about 36GB taking over 30 minutes to transfer and checksum. He's only talking about going to one drive. That normally happens in less than 10 minutes. Now imagine he's on a shoot where they have multiple cameras filling multiple Red drives each day (That's where I'll be all next week.) Do the math on those transfers and you'll see he needs another way. It's just not possible.

Regarding the idea that you shouldn't be on a set shooting for a client if you don't checksum. I've shot and managed probably petabytes of footage. I've honestly never lost a single clip, I've been toasted by ad executives as the first "red guy" not to fuck their shoot. I believe it's because I have an emotional relationship with the footage, I'm working very hard to keep track of all of it, and using mechanisms involving camera tape and vigalence to protect it from human error. On the other hand I have had clients who fired their original DIT for loosing footage and found out those guys were technically doing it right.... Using syncing software running checksums and still loosing footage... just using the wrong overall method... it happens more than you might imagine.

One final point - there seems to be a tendency these days on shows to try and do more with less people. So if on the big budget shows you wish to use your own workflow that works for you, thats great. I do hope you include some sort of checksum in the process (and most likely whoever is funding the project will require it). But for those that are truly re-defining the definition of multi-tasking, R3D Data Manager should fit the bill pretty nicely.

If you don't have time to be there to supervise the transfer than you shouldn't be doing it on set. You should pack your media up in foam and save it until you are ready. If you can't do that because you don't have enough media, than that's the risk you are taking. R3DDM would be a good choice in that situation.

IBloom

 

[Hans von Sonntag]

I'm reading this thread with great interest because I have the first corrupt R3D that I can view with the RefQTs but cannot copy from the Nexto to another location. The copying process keeps stopping at roughly 1 GB. I've been trying different machines and all have the same issue. My source is a Nexsto 2525 which never let me down until now. Unfortunately the CFs are erased already.

Why did this happen?

Because I have been in a hurry, it was late at 0330 AM and I trusted my Nexto, the computer and Conrad's software I use for copying R3Ds to two different location simultaniously. And I needed the CFs the next morning for the next shoot so I erased them BEFORE I checked the two copies by eyeball.

What I learned: Buy more CFs. The 20 I've got are not enough. I knew that, but I waited because the CF market is currently developing and Red's 16GB are too expensive... or not? I better have bought at least 5 and this mishap wouldn't have happened.

I never use Checksum because it costs too much time. I ALWAYS check the RefQTs - this way I have seen 1 corrupt shot out of 10.000. R3D Menager is a useful app. I like and use but it does not stop you making mistakes.

Hans

BTW: Does anybody has a clue how I can get access to the corrupt R3D? As mentioned above RefQTs are working but copying to another disk is not.

 

[Cüneyt Kaya]

I'm reading this thread with great interest because I have the first corrupt R3D that I can view with the RefQTs but cannot copy from the Nexto to another location. The copying process keeps stopping at roughly 1 GB. I've been trying different machines and all have the same issue. My source is a Nexsto 2525 which never let me down until now. Unfortunately the CFs are erased already.

Why did this happen?

Because I have been in a hurry, it was late at 0330 AM and I trusted my Nexto, the computer and Conrad's software I use for copying R3Ds to two different location simultaniously. And I needed the CFs the next morning for the next shoot so I erased them BEFORE I checked the two copies by eyeball.

What I learned: Buy more CFs. The 20 I've got are not enough. I knew that, but I waited because the CF market is currently developing and Red's 16GB are too expensive... or not? I better have bought at least 5 and this mishap wouldn't have happened.

I never use Checksum because it costs too much time. I ALWAYS check the RefQTs - this way I have seen 1 corrupt shot out of 10.000. R3D Menager is a useful app. I like and use but it does not stop you making mistakes.

Hans

BTW: Does anybody has a clue how I can get access to the corrupt R3D? As mentioned above RefQTs are working but copying to another disk is not.

Hi Hans, just to understand.
did you copy the cf cards to two different nexto hdd`s ?

 

[Hans von Sonntag]

Hi Hans, just to understand.
did you copy the cf cards to two different nexto hdd`s ?

Hi Cüneyt,

I usually copy my CFs to one Nexto on set and erase the CFs only when I have the footage working on two different locations, project raid and tape for instance. I broke that rule and got bitten immediately.

Hans

 

[I Bloom]

BTW: Does anybody has a clue how I can get access to the corrupt R3D? As mentioned above RefQTs are working but copying to another disk is not.

Are you saying that the file when copied to another drive is corrupt and won't load or the file on the Nexto just won't copy?

IBloom

 

[Deanan]

BTW: Does anybody has a clue how I can get access to the corrupt R3D? As mentioned above RefQTs are working but copying to another disk is not.

Where are you trying to copy to/from? Nexto to computer?

 

[Hans von Sonntag]

Where are you trying to copy to/from? Nexto to computer?

Hi Deanan,

Thanks for thinking!

Yes, Nexto to computer.

Hans

 

[Hans von Sonntag]

Are you saying that the file when copied to another drive is corrupt and won't load or the file on the Nexto just won't copy?

IBloom

The file won't copy though the RefQTs work.

Any help much apprechiated!

Hans

 

[Conrad Hunziker]

You missed the second part of my test. Reviewing the footage. Text files don't apply here, we are talking about R3D's that are being copied from one drive to another. An R3D file is a very specifically encoded very large file. While there is some fault tolerance built in, in general the frames won't load if it is at all corrupted.

Actually, text files do a very good job of illustrating my point here. The point is that it takes very little for files that in every other way appear to be exactly the same to actually not be the same. It doesnt matter if its a DOC or a R3D file - it is still a series of zeros and ones that need to be in the proper order. We could generate R3Ds that have the same amount of data wrong, but unless you are looking at a hex editor you may miss it. The point is not that the file is correct 98% of the time, but 100%.

In addition the corruption needs to be created by copying the files from one place to another there by passing the cyclic redundancy checks built into MacOSX/Unix.

But again thats another reason why I developed the software. CRC checks are not the best at determining if a file is valid. In fact there are computer viruses in the wild right now that operate by infecting a file then padding its length to return the same CRC. To do that with MD5 would take 1E-32. To do that with SHA1 is on the order of 1E-128. Its not yet known how to do that with SHA256 because it hasnt been done yet.

In addition, the CRC checks are usually handled by the drives firmware, which varies by drive to drive and manufacturer to manufacturer. One of the biggest reasons the recent seagate 1.5Tb drives were having so many issues was that the firmware thought the drive was having such a high CRC failure rate that the firmware shut it down to prevent further loss, bricking the drive. Turns out it was a firmware bug, not an issue physically with the drive.

But the overriding point is this. You have your red media and you make your two copies. Now you properly take your one copy and store it, and take your second and use it to edit. Time passes. Days, months, years later you now need access to that footage again. How do you know its valid? CRC checks here wont help you one bit. You could spend days or weeks re-watching all the footage again, but that wont tell you if it is an exact copy. I know that the first footage I transferred shot on build 8 is valid to this day, because I have proper checksums not reliant on any hardware. By the way, those are the things that are required for completion bonds.

It's just also very expensive computationally to get those sums.

Well, perhaps we need to define expensive here. On standard 4k footage, on a 2 year old MacBook Pro, my processors have a 30% utilization during the checksum. Using activity monitor I see its transferring at line speed from the red media. So the processor is sitting waiting for data from the drive. So a read pass is a read pass, and theres not much we can do about that besides make faster hardware. It certainly is not waiting on the processor to add up the data.

Looking at it from the other side, 36Gb is roughly 18 minutes of footage. But the checksums were created in 9 minutes. So this shows that it created the checksums at 2x real time. It would take you 18 minutes to verify that footage visually, but on 9 minutes to validate the checksum.

I think there is also an extremely low probability that files are corrupted, if they copy properly and you check their playback. Especially when you copy to a master and backup drives. And that probability is low enough (though not astronomically low) to out-way the disadvantages of running a checksum on all of the footage.

Ok - theres another gotcha that has happened in the past. Lets say you do a finder copy to 2 destinations. You check destination A and see the footage is valid. Now you must also check footage on destination B to make sure it is ALSO valid.

However, using simple logic, we know that if we used checksums on both destinations and the checksums came back correct, then we can watch only ONE destination and the other must also be fine. We know that we had 2 successful reads on the source, and a successful write and read on each destination and all three checksums matched. Therefore, once we check that one destinations data is valid image data, all copies with that same checksum must also be valid image data, down to a certainty of at least 1E-32 or 1E-128 (depending ont he exact checksum used).

The gotcha here is, I refer to the instance where a clients drive produced 3 incorrect results. If I had only copied via finder and played back on my RAID, I would either ALSO need to playback on the clients drive or ASSUME it was valid data. So, I would need to either spend more time validating image data (watching takes) or I would have made the faulty mistake and lost footage.

The original poster was talking about 36GB taking over 30 minutes to transfer and checksum. He's only talking about going to one drive. That normally happens in less than 10 minutes. Now imagine he's on a shoot where they have multiple cameras filling multiple Red drives each day (That's where I'll be all next week.) Do the math on those transfers and you'll see he needs another way. It's just not possible.

It is possible, and I do it every day.

First, I dont know the exact setup the original poster had. I do know that he should be hitting around the 20 to 25 minute mark. 30 minutes indicates to me there is something there that can still be optimized - some hardware in the chain somewhere isnt putting out full speed.

Secondly, it just takes planning and commitment to a workflow to get it done. If you are planning on having multiple cameras, I doubt youd go into it with just a single lens and a pair of sticks. Here too, you would plan for perhaps a couple of download computers and a couple of red media each. Ive done whole multi-cam features (3 cameras, 2 units, always running) using my software and workflow, and never had to stay more than 40 minutes past wrap, if I kept on top of it. Sure, theres a lot of roll numbers that way, but I know for a fact that the producer 10 years down the road will be able to pick up the footage again and know that his backups are still exact copies of the footage as shot.

Regarding the idea that you shouldn't be on a set shooting for a client if you don't checksum.

Every person and production will require their own workflow. The workflow you have developed works for you and your clients. Im glad that you are the first red guy to not loose footage for your clients - we need more of that to help lift the negative rumors that still swirl around using the red.

But the fundamental question comes down to the same saying used elsewhere in filmmaking: good, fast, cheap; pick two. In this instance I would say secure, fast, easy; pick two. Your method is not secure, but is fast and easy. My software allows people to pick secure and easy or fast and easy.

And again, I am not advocating that this is a simple one step process. I have always said the proper data management means you have to make 3 evaluations on the data. R3D Data Manager will make 2 of those in a automated and precise way. You still need to be involved in the downloading process to make the third, and to overseee the first two.

 

[Conrad Hunziker]

Hi Cüneyt,

I usually copy my CFs to one Nexto on set and erase the CFs only when I have the footage working on two different locations, project raid and tape for instance. I broke that rule and got bitten immediately.

Hans

Hans- Have you used any file retrieval utilities on it yet? What about command line copying with "cp -v"?

 

[Hans von Sonntag]

Hans- Have you used any file retrieval utilities on it yet? What about command line copying with "cp -v"?

Going to try that.

Hans

 

[Deanan]

Going to try that.

Hans

Is it possible that the nexto's drive itself is damaged?

If you do a copy, does the progress bar hang for a while?

Also, try transcoding the file from the QT wrapper to another file
and see if there are any errors in the transcode.

 

[Scott Webster]

Hans,

In what mode were you using the Nexto?
Copy?
Copy and Verify?
Move? (which copies, verfies and deletes the original card)

Have you tried removing the drive from the Nexto and using an external adapter to mount it to another machine? Would you be able to create an image of the drive rather trying to copy? Can you access the problem r3d through Red Alert?

 

[Chris Rupert]

I'm curious about some of your guys procedures for checking the R3D files as to make sure none of them are corrupt. (I have not seen any corrupt files yet).

Is playing the proxy files enough?

And if you find a corrupt file - what is usually the signs (it just not playing)?