Speeding up R3D Trim?

[ericyoung]

At the moment R3D trim requires the entire clip to be rewritten so that the R3D chunks start with the correct 2GB (or 4GB for Epic) chunk size, and chunk sequence numbers in the RDC folders. Depending on computer speed (without Red Rocket), like my laptop, this may take 1.5hours to trim a 2hour clip down to 1.5 hours.

I've no idea of the R3D clip chunk file structure, so this may not be at all possible. But I was wondering - aren't chunks in the middle of the clip selfcontained and could maybe be left alone. OK, trimming in and out points would delete/alter beginning and end chunks, but maybe Red post tools/SDK could be written that the first chunk could be less than 2GB (or 4GB for Epic), and as long as chunk sequence numbers were correctly rewritten then post tools would just process the chunks in sequence? Would this work?

[Matthew Yaeger]

R3DTrim is completely I/O limited and does not copy the entire clip, it only copies the frames within the in/out points. The Red Rocket is not used for trim at all as there is no transcoding taking place. If your R3D Trim is taking a long time it is probably due to either the drive speed that the media is on or the transfer rate to the drive.

[ericyoung]

Hi Matthew - thanks for your quick answer - your Red user name implies you are a Red employee, so your answer is probably authoritative. However, if what you say is correct, how is it that the trimmed clip RDC chunks start with a whole 2GB chunk when I've trimmed the start of the clip? Or is it that R3D Trim just repositions Start and End bytes of all the chunks?

I was reading and writing from the same 7200rpm external hard drive connected by eSATA expresscard, which obviously isn't the fastest configuration, but would have still expected a faster operation if only the in and out point chunks were rewritten.

[Matthew Yaeger]

Is it possible you trimmed into the source directory?

[ericyoung]

Hi Matthew

No, same drive, but different directories.

[Matthew Yaeger]

What was the source for the trim? Could it have been a bin that had the original clip in it and a duplicate with the in/out set to where you expected it?

[ericyoung]

Thanks Matthew for following this up.

The source directory was a straight Mac Finder copy of an original Red 320GB Drive. No duplicate in same directory. However, there may have been some corruption in this copy.

I will have a go at retrimming with a known verified copy of the clip to see if that makes a difference.