Welcome to our community

Be a part of something great, join today!

  • 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 :)

Pomfort Silverstack 3

I download and installed the Silverstack 3 trial and ran a test with it and R3D Data Manager and Shot Put Pro, all latest versions. Source was a 63.2GB RedMag from my OWC Qx2 RAID5 drive. Destinations were 2 G-Drives and one Seagate hard drive in an eSATA dock. I used what I had available to me at the moment. All drives were connected via eSATA cables from a Atto H680 SAS card in a Sonnet Echo Express SE connected to a Retina MacBook Pro. I did have an LCD monitor connected to the Echo Express SE and another monitor connected to the other Thunderbolt port. Checksums were all MD5. Between tests I deleted the files off the destinations and emptied the trash so they each had the same starting point with the same amount of free space on the drives.

Silverstack 3 = 23 mins 41 seconds
R3D Data Manager = 26 mins 10 secs
ShotPut Pro 5 = 21 mins 30 secs

That was surprising. I don't really see any reason to use R3DDM anymore. I'm pretty impressed with SPP5, and it's what I've been using for Alexa shoots since Alexa Data Manager can't hand ArriRAW .ari files.

As far as Silverstack goes. I think there's some great features in it. It's really nice to have one app that can backup the media and allow you to watch it all. The reports are nice as well, though I wish there could be more customization of them and some information doesn't show in the reports even though the columns are active and have information in them in the table view.

I did notice that the file transfer speed reported in Silverstack is vastly different (about 30% the speed in the table and then about 75% in the info pane) from what iStat Menus and Activity Monitor report. Also, it doesn't appear to read the Red metadata as I can't see the color or gamma being used, camera model, serial number, etc., even though there are space and columns for that information. Playback of R3Ds is much slower than in RCXP than in Premiere (tested without the Rocket connected).
 
I was excited about this update too as I expected the transfer rates to be improved. However, when I did a side by side comparison with Shotput Pro, I was surprised to see that Shot Put transferred files about 30% faster.

However, I then realized that MD5 checksums are the fastest that Silverstack offers. I was doing byte checksums with Shotput so that accounts for the time difference.

Anyway, I think MD5 is way overkill. On a two or three Epic shoot that can easily add 3 or 4 hours to each day when you consider an additional 5 minutes per mag. I really don't know anyone who actually uses MD5 consistently, unless they're on a gig where money is no object and they like to rack up overtime and extra days.

So unless you're working a Local 600 gig with guaranteed overtime, I'd stay away from Silverstack for now unless that start offering byte checksums.

On a positive note, it does offer some nice features and I really wanted to buy it; however, I cannot justify the cost/benefit because although the features are nice, they are not $500x nicer. Shot Put is $100, Silverstack is $600.
 
I agree. I think it's overpriced for what it is, considering what you get in other software for considerably less. The interface is kind of clunky too. Not very intuitive at all. Certainly not worth $500 more than ShotPut Pro. If the reports were really amazing, then I would consider it as that alone could save a lot of time, but they are mediocre at best and not really customizable like they say on their website.

I always do MD5 checksums unless something is not allowing me to (too many cameras and media for one DIT or the number of DIT's working for example) and I make sure production is aware of it. It protects me from any blame should they later say footage is missing or corrupt.
 
I always do MD5 checksums unless something is not allowing me to (too many cameras and media for one DIT or the number of DIT's working for example) and I make sure production is aware of it. It protects me from any blame should they later say footage is missing or corrupt.

I can assure you that if footage is missing or corrupt, MD5 checksums will not protect you from anything...

At that point, it will have turned into some sort of blame game among the suspected parties and your name and reputation will be on the line... The DIT will be the first one thrown under the bus... producers will dispense with you and your reputation without thinking twice because they'll be afraid of litigation from the client.

You'll be standing there with your MD5 checksum in hand and nobody will give a damn because they have no idea what that even means, let alone care. Once the footae is gone, it's gone and anyone involved is blamed.

Have you ever met a producer, let alone a client, who even knows what a MD5 checksum is? I haven't.


d
 
Actually what it does is ensure and show that corrupted shots were not caused by the backup process because the data is proven to be identical to what was on the camera recording media. So if there was a corrupted shot it was caused by the camera or bad media, relieving the blame from the DIT. As far as being blamed for corrupted shots later, I review every shot that comes through me and if there is a problem I let the director and DP, and anyone else I should, know immediately. If something happens much later down the post line then they can run a MD5 checksum verification on the files to see if they match. If they don't, then I have logs showing that when I copied the files the checksums matched, so I am not to blame. There's also always multiple copies so they can recover the non-corrupted files from one of the other backups.

And yes, I have worked with/for producers and clients that are aware of what checksum copies are. I've had some even make sure that it's what I was doing and hired me because I assured them that I would only do checksum copies and that I would review every single shot as it came through.
 
Actually what it does is ensure and show that corrupted shots were not caused by the backup process because the data is proven to be identical to what was on the camera recording media. So if there was a corrupted shot it was caused by the camera or bad media, relieving the blame from the DIT.

The only way to prove that is if you still have the mag, not with the checksum - in which case the checksum doesn't matter. On a lot of shows they don't allow reformatting of the mags until the next day, when you get the OK from post.

Checksum doesn't know if the files on the mag are corrupt or not. If it did then you wouldn't have to do the review you mention.
 
The only way to prove that is if you still have the mag, not with the checksum - in which case the checksum doesn't matter. On a lot of shows they don't allow reformatting of the mags until the next day, when you get the OK from post.

Checksum doesn't know if the files on the mag are corrupt or not. If it did then you wouldn't have to do the review you mention.

But at least you only have to review one of the copies. A review plus checksum is as safe as it's possible to be if media is reformatted during the day - which dependent on the production, does happen.
 
Actually what it does is ensure and show that corrupted shots were not caused by the backup process because the data is proven to be identical to what was on the camera recording media. So if there was a corrupted shot it was caused by the camera or bad media, relieving the blame from the DIT. As far as being blamed for corrupted shots later, I review every shot that comes through me and if there is a problem I let the director and DP, and anyone else I should, know immediately. If something happens much later down the post line then they can run a MD5 checksum verification on the files to see if they match. If they don't, then I have logs showing that when I copied the files the checksums matched, so I am not to blame. There's also always multiple copies so they can recover the non-corrupted files from one of the other backups.

Yes, I understand how MD5 checksums work. I understand how the production blame-game works too, which is why I think you missed the point of my post...

It doesn't matter if you did your job well; if you reviewed every single shot; if you did a MD5 checksum. If footage ends up missing or corrupted further down the pipeline, it will come back to you. Your name will be called into question and it simply doesn't matter if you're "not to blame."

If you've ever been on a production where something goes wrong, I'm not even talking about as a DIT, but something in production, G&E, props, camera, whatever... the blame gets spread all over. Everyone struggles to cover their ass and you'll see people outright lying and throwing others under the bus to protect their job. The clients or producers get to be the judge whether thats fair or not. And if you get labeled the one at fault, all the checksums in the world aren't going to help you.

I witnessed this recently when an AC decided to do a system restore on B cam on the last roll of the day without notifying anyone. I discovered the mismatched timecode and file names after I downloaded all the footage. As usual, I was the last person on set so I couldn't bring it up until the next day when I called the 1st and 2nd AC to figure out what went wrong...

You don't have to be Nostradamus to predict what happened... each one blamed the other! They each said that the other one had done a system restore, must have forgot to sync timecode and redo the file naming convention! WTF?

As I explained to them, it wasn't that big of a deal. I wasn't looking to blame anyone. I just wanted to know what happened, why it happened, and how it could be prevented in the future as I'm sure to be working with them again.

We're talking mismatched timecode and inaccurate file names on just one roll... not the end of the world here. I renamed the files, problem solved. The editor would simply have to manually match the last roll by eye (it was MOS). Bit of a headache for him, but nothing insurmountable.

Anyway, it made me sick that I couldn't get a straight answer from two people who, until then, I thought were pretty solid.

Long story short, the only way to truly cover you ass is to keep an offsight back up of the footage for 2-4 weeks.


dezzy
 
Last edited:
And yes, I have worked with/for producers and clients that are aware of what checksum copies are. I've had some even make sure that it's what I was doing and hired me because I assured them that I would only do checksum copies and that I would review every single shot as it came through.


By the way, your last comment does not inspire much confidence...

Do they understand the actual difference between MD5, Byte or SHA 1 checksums? Or are they just parroting terminology?

Just because they know the catchword/phrase doesn't mean much. I still have producers asking me what my red rocket rental fee is for the upcoming Alexa job!
Rest assured, I always give them a good deal. :devil:


dezzy the lil devil
 
You'd be surprised how many people understand checksum copies. Maybe it's different in NY, but here in LA there are producers that do know some of the tech stuff. Not all of them, but there are some that do. And if they don't I explain it to them. It gives them confidence that they've hired the right person for the job (me). If you explain what a checksum copy is to a producer so they understand what you're doing they may appreciate it and they'll understand why they're paying the rate they are. It's a new field and a lot of producers may not understand why they need a DIT. It's up to us as DIT's to educate them and let them know what we're actually doing. If you do that, they'll be more likely to hire you again and refer you to other producers. Over 90% of my work comes from referrals and producers hire me again, so I must be doing something right.

If someone blames you (the DIT) for corrupted or missing shots, you should have as much proof as possible to get the blame off you. Otherwise they won't hire you again.

When I work as a DIT I review all the shots after the offload. The DP knows this, the director knows this, and the producers know this. They know because I tell them that's what I do. If there's a problem that I find with a shot, whether it's an exposure issue, corruption issues, or anything else, I let them know immediately. I also verify that the problem exists on the original camera media as well, as I don't return the camera media to the AC's until I've confirmed the copy is successful and verified and all the shots are good.

Later down the post pipeline, if a producer comes to me and claims that I caused their footage to be corrupted because some other person is telling them it's my fault, I can defend myself. I can tell them all the footage was good when I turned over the drives or can even say I let them know that particular shot was found to be bad during production and that I let the director and DP know and included that information in my log. I can show them the logs, which will prove that the files I copied onto the hard drive were exactly the same as the files that were on the camera media (or that I let them know about the issue with the shot at the time).

Byte checks/file size verification aren't proper proof or verification. There can still be bits in the wrong place. Matching checksums verify that every bit is exactly the same and in the right place. And they'll know at that point that the corruption happened as some other time after I turned over the drives. Furthermore, I can tell them to restore the corrupted shot(s) from one of the backups and they'll be good to go. Problem solved, blame deflected.
 
This thread seems to have veered off track a little so I'll bring it back to the issue of Silverstack. I's misleading to compare Silverstack to Shot Put Pro based on the fact they both offer a means to offload to multiple drives with checksum verification. Shot Put Pro is a very simple application and is priced about right for what it is. If a loader or god forbid a production runner is being asked to offload using a laptop, then Shot Put Pro is a bare minimum requirement.


Where as Silverstack is very much a central hub where all cards or drives are offloaded and all metadata stored. I work mostly with the Alexa, RED Epic and Canon C300 and all capture using different formats and within Silverstack you can play back each clip with no problem at all, no encoding required. You can also watch with a LUT applied, zoom into specific areas within the frame, apply focus assist, check for clipping, exposure range and false colour if required. A HUD can be toggled on or off to easily add scene, shot and take and then at the end of each day produce an individual report for each camera including thumbnail image and individually set data. I used to use Microsoft Excel to produce camera reports, which was very labour intensive. Now I click a couple of buttons and a smart looking PDF is available to attach to the transit drive for edit and email to production. I send a separate report at the end of each week detailing how much we have shot and how much storage we are getting through. This allows production to supply me with extra back-up if required without really needing to go ask for it.


Silverstack has room to develop, syncing sound would be an excellent start. It has the potential to enter into the world of dailies but considering how good DaVinci Resolve 9 Lite is at producing dailies, I very much doubt the Pomfort will bother. But as I said, there is room to develop and the guys at Pomfort do seem to be on their toes. I have sent bug reports, asked questions, sent feedback and suggestions and they have replied in good time. As a DIT it is great to know there are folks developing tools specifically for us.


REDCINE-X PRO and DaVinci Resolve Lite are freebies and damn fine ones at that but everything else comes at cost and I think Silverstack is reasonably priced for what it is. If anyone is thinking about trying it out I'd say it is a solid application and decent addition to any DIT's toolkit. I've used it for about 18 months now and can only see it getting better.
 
Hey...

I'em doing some testing in Silverstack 3.3 and I noticed that wav support is a bit lacking or em I doing something wrong?
No way to preview and to add information (metadata) to the files?
 
Back
Top