A single minute of RED 8K rolls in at roughly 1.5 GB. A ten-minute interview take you cut around but never actually used is 15 GB sitting on your NAS doing nothing. Multiply that across a season of unused selects and you understand why R3D cleanup is the highest-value reclaim target on any drive that's ever touched a RED body.

The problem is that R3D is also the format editors are most afraid to delete. So nobody touches it, and it accumulates forever.

Why R3D Hurts More Than Anything Else

Think of R3D files like 35mm film cans in a vault. Each one is heavy, expensive to store, and you never throw them out without being absolutely sure they're not needed for a reshoot. That caution made sense for celluloid. It does not make sense when the vault is a $400/month NAS and 70 percent of the cans are empty B-roll takes from a job that wrapped two years ago.

The math is brutal in a way other formats aren't. At 1.5 GB/min:

If you've been hoarding R3D for three or four projects, you're almost certainly sitting on multiple terabytes you could safely return to the pool.

R3D Metadata Quirks That Trip Up Cleanup

R3D isn't just a video file. It's a clip family. A single take from a RED camera can produce:

Delete the .R3D and orphan the .RMD and you've thrown away the colorist's work. Delete the .RMD and keep the .R3D and you've kept the heavy file but lost every decision attached to it. Any cleanup workflow that doesn't understand the family relationship is one wrong click from disaster.

How Premiere Actually References R3D

Premiere treats R3D the same way it treats any other media. It builds a MasterClip that points at the file on disk and then references that MasterClip from any sequence the clip is cut into. The wrinkle is spanning. A long take split across _001.R3D, _002.R3D, and _003.R3D is a single MasterClip in Premiere's eyes, but three separate files on the NAS.

If you only check the first segment, you might assume the take is in use and protect all three. Fine. But if you check the third segment in isolation and don't follow the spanned-clip relationship back to the MasterClip, you might delete the segment containing the only frames that actually made the cut.

The reference chain has to be walked all the way through, sequence by sequence, before anything gets deleted.

The Real Workflow

Step one is admitting you can't do this by eyeballing the bin. RED shoots produce too many takes, the filenames are camera-generated and unhelpful (A001_C042_0815BC.R3D tells you nothing about what's in the shot), and the spanned-clip behavior makes manual checking unreliable.

What actually works:

  1. Walk every .prproj on the drive, not just the one currently open.
  2. For each project, follow every sequence's clips back through the SubClip and MasterClip references to the actual files on disk, including all segments of any spanned clip.
  3. Build a union set: every R3D file referenced by any timeline in any project on the drive.
  4. Compare that set to the full list of .R3D files on disk.
  5. The difference is your reclaim list. Verify the .RMD sidecars travel with the .R3D files when you delete or archive.

R3D's family structure and span behavior raise the stakes. You want a tool that understands both, not a script that diffs filenames.

Reclaim Math

Run the numbers on your own drive before you do anything. At 1.5 GB/min for RED 8K:

If your drive has held three RED projects and you've never cleaned any of them up, a 3-5 TB reclaim is normal, not optimistic. Plug your numbers into the calculator and look at what 3 TB of cloud storage actually costs you per month. It's usually more than the price of a tool that can find the files for you.

Before You Buy More Drive Space

Clip Sweeper was built around this exact reference-chain walk, with R3D spanned clips and .RMD sidecars handled as first-class citizens. Before you buy another 8 TB drive to make room for the next RED job, it's worth seeing how much of your current storage is actually carrying its weight.