MD5 hash on the fly please!

[Les Dittert]

I just thought of this, and it seems pretty obvious and easy for Red to add :

As the camera is recording an r3d, the camera is also calculating the MD5 checksum for the file ( easy ).
when the r3d is closed, the hash is stored in meta data sidecar file.

This simplifies the ssd copy operation and associated and recommended verify pass.

I disclose this idea here, and grant Red full use of the method.

 

[Andrew Gentle]

Love it! Are you sure it's possible to calculate MD5 progressively?

 

[Martin Weiss]

I remember in the early days there was talk about each frame getting its own checksum...

 

[Adrian T.]

Love it! Are you sure it's possible to calculate MD5 progressively?

if the file is written in sequential order, then it's easy. But maybe there's stuff updated in the header structure, either constantly or before closing the file.

 

[Les Dittert]

if the file is written in sequential order, then it's easy. But maybe there's stuff updated in the header structure, either constantly or before closing the file.

Red could make their own checksum 'RedSum' to handle the case if the r3d header is updated as the file is closed. ( there could be a seperate hash for the non-header data , and a second hash for the header ).

This would make verification of DIT copies a breeze, as the data would not have to be read off the ssd just to calculate the checksum.

 

[Gavin Greenwalt]

+1 .

 

[Adrian T.]

Red could make their own checksum 'RedSum' to handle the case if the r3d header is updated as the file is closed. ( there could be a seperate hash for the non-header data , and a second hash for the header ).

Any non-standard solution makes its usefulness more difficult.

But they could calculate proprietary hashes on the fly and add them to the file itself. And then the RED SDK could include a proprietary hash check feature which could be used by third party tools.

This would make verification of DIT copies a breeze, as the data would not have to be read off the ssd just to calculate the checksum.

And verification happens against the data that was originally written to the SSD, and not against potentially wrong data that's read from the SSD. This would be a huge plus over any current data verification systems.

 

[Jeff Kilgroe]

I remember in the early days there was talk about each frame getting its own checksum...

Yes, there was something like that. The camera was supposed to generate checksum or error-control data as it recorded. Hopefully that is still on the table... There are so many features that have been proposed, discussed or announced / mentioned for EPIC it's difficult to keep track. And RED is a lot more quiet about these things now.

 

[Nils Ruinet]

Love that idea !