My First Scratch session with Redcode Raw: No Joy

[Chase Gordon]

When I originally posted this I was very frustrated. I should have waited a day to calm down.

In retrospect, there were three areas of frustration.

The one you don't need to hear about: Scratch is hard to use and my operator was too green to know how to use it effectively. Beyond saying to anyone thinking of getting their own Scratch system that it's hard to use and requires training, there was no productive value to that part of my post. So I've cut that out (you can read what I said in other people's posts where they quoted me).

The second was that there were serious bugs in the version we were using, which was the latest released version at the time, version 3.8, build 443. I understand now that at least some of these bugs have been fixed in beta versions, but I'll leave those complaints in.

The third was the performance of the system. This was a serious Scratch installation where they do 2K DI all day. The fact that there was some problem with the transcoding speed, to me, speaks of poor support from Scratch.

So on to the (edited) original post.

--


Well, today I had my first online session with Scratch (version 3.8) and Redcode footage, bringing over and EDL from FCP. Short story: disaster.

The workflow in Scratch is to load all the footage, then load the EDL, then "assemble" the EDL from the loaded footage.

First problem: every time we tried to load the footage, Scratch crashed. We could load individual shots, but when we tried to load a whole reel, Scratch just crashed. Every time. Really inexcusable. (Workaround, remove all .rdx and .mov files from all the folders.)

Stuck Frames: Even on this full blown Scratch system on Windows, we still had some shots that only showed the stuck first frame through the entire clip, just like people have been complaining happens with Redcine export. (No explanation so far)

No Stabilization: I tried to use the shot stabilization tool to remove a camera bump, but no joy. The tracking target marker came up, but I couldn't select it and I couldn't move it, so obviously I couldn't set it up correctly. (Confirmed that this tool is not supported on REDCODE footage.)

SLOW: OK, maybe it had to do with this specific computer, but it could only export 1 DPX every 5-8 seconds! Granted it had to do scaling and cropping (4096x2048 -> 2048 x 1080), but still. And this computer was on a mega-fast SAN, so it wasn't disk IO. (No explanation so far.)

So at the end of an 8 hour session, I had one (ungraded) DPX file to show for it, as when I stopped the render only the first DPX file was to be found in the output folder. :angry01:

 

[Tai Wah Lim]

Wow, Luki - any comments?

 

[Harry Clark]

Anyone beginning to feel that the boys at Red chose poorly when they looked for an off-the-shelf solution for software?
Harry

 

[Chris Burket]

At HD Expo, Plaster City Post showed a demo where they cut the 2k qt proxies in FCP, then played them out on an HD monitor in 1920x1080. They have said that they can't see a difference on a high quality HD monitor between the proxie, and the 4k raw processed through redcine and shown in 1920x1080.

 

[Bastiaan Houtkooper]

May be it's time for a professional operator????
Scratch can do all you want, it's you that is the problem.....

Bastiaan Houtkooper NSC

 

[Fredrik Callinggard]

I just did a test where we rendered the files out to DPX from REDLog in REDCine and the graded in Lustre. Short story.... GREAT SUCCESS!

While I actually wrote Lucas at Assimilate asking him for an workflow explanation (I had a Scratch lined up for the test, but the guys running it said thew were not sure of the workflow and that the "Scratch" people themselves hadn't come back to them, so they needed to figure it out first hahaha), I also asked Lucas for a price tag for me if I was to buy Scratch.

Short story..... Assimilate never bothered to come back to me, so one customer less.

I'm now looking in to Nucoda Filmmaster that one of the guys on this forum introduced me to. Looks very interesting! A little more expensive (not that much with discounts etc) then Scratch but also more of a grading system.

My suggestion is that you edit in FCP, use REDTrip to get a REDXML list, render DPX files through REDLOg in REDCine and take those files in any other system than Scratch, why bother if they don't?

fred

 

[Fredrik Harreschou]

Well, today I had my first online session with Scratch (version 3.8) and Redcode footage, bringing over and EDL from FCP. Short story: disaster.

The workflow in Scratch is to load all the footage, then load the EDL, then "assemble" the EDL from the loaded footage.

First problem: every time we tried to load the footage, Scratch crashed. We could load individual shots, but when we tried to load a whole reel, Scratch just crashed. Every time. Really inexcusable.

Next problem: it's a Scratch system. I've never used Scratch before, but man is that user interface horrid. We never did manage to get the reference movie to play alongside the timeline movie. Nor did we find a vector scope for color correction. Nor did we find a way to set things like sharpening, detail level, and noise reduction to be the same for several shots all at once.

Likewise, while the output choices for DPX were Log or Lin, I couldn't find a way to select RedLog or PD Log 685 even though I could verify they were installed. So I don't know *what* Log colorspace Log meant.

Stuck Frames: Even on this full blown Scratch system on Windows, we still had some shots that only showed the stuck first frame through the entire clip, just like people have been complaining happens with Redcine export.

No Stabilization: I tried to use the shot stabilization tool to remove a camera bump, but no joy. The tracking target marker came up, but I couldn't select it and I couldn't move it, so obviously I couldn't set it up correctly.

SLOW: OK, I expect this had to do with this specific computer, but it could only export 1 DPX every 5-8 seconds! And this computer was on a mega-fast SAN, so it wasn't disk IO.

So at the end of an 8 hour session, I had one (ungraded) DPX file to show for it. :angry01:

I feel pretty well screwed now about trying to get to 1080p with any kind of quality. The only viable path on my budget looks like going through the QT proxies via FCP or Compressor and blowing up the 2048 x 1024 to whatever x 1080, which just looks awful by comparison to going from the 4K via a high-quality debayer.

Are you serious? Can you define online session? Do you or any other persons involved have any training or experience with Scratch?

The crash on Load Layers is caused by the QT reference files. If your Scratch operator didn't know this he/she hasn't really been doing his/her homework.

Same with the LUTs. RTFM!

Not knowing how to use something doesn't make the product bad. You seem to have the idea that you can sit down on any system without having read the manual or have any training and make great work instantly with no workflow issues.

If you have a demo license and try to do this yourself - why not ask questions? You need help and instead you post this?

Regards,
Fredrik

 

[Fredrik Harreschou]

Anyone beginning to feel that the boys at Red chose poorly when they looked for an off-the-shelf solution for software?
Harry

Posts like this is the reason I stick with the scratch-list from now on.

 

[Mark L. Pederson]

Well, today I had my first online session with Scratch (version 3.8) and Redcode footage, bringing over and EDL from FCP. Short story: disaster.

The workflow in Scratch is to load all the footage, then load the EDL, then "assemble" the EDL from the loaded footage.

First problem: every time we tried to load the footage, Scratch crashed. We could load individual shots, but when we tried to load a whole reel, Scratch just crashed. Every time. Really inexcusable.

Next problem: it's a Scratch system. I've never used Scratch before, but man is that user interface horrid. We never did manage to get the reference movie to play alongside the timeline movie. Nor did we find a vector scope for color correction. Nor did we find a way to set things like sharpening, detail level, and noise reduction to be the same for several shots all at once.

Likewise, while the output choices for DPX were Log or Lin, I couldn't find a way to select RedLog or PD Log 685 even though I could verify they were installed. So I don't know *what* Log colorspace Log meant.

Stuck Frames: Even on this full blown Scratch system on Windows, we still had some shots that only showed the stuck first frame through the entire clip, just like people have been complaining happens with Redcine export.

No Stabilization: I tried to use the shot stabilization tool to remove a camera bump, but no joy. The tracking target marker came up, but I couldn't select it and I couldn't move it, so obviously I couldn't set it up correctly.

SLOW: OK, I expect this had to do with this specific computer, but it could only export 1 DPX every 5-8 seconds! And this computer was on a mega-fast SAN, so it wasn't disk IO.

So at the end of an 8 hour session, I had one (ungraded) DPX file to show for it. :angry01:

I feel pretty well screwed now about trying to get to 1080p with any kind of quality. The only viable path on my budget looks like going through the QT proxies via FCP or Compressor and blowing up the 2048 x 1024 to whatever x 1080, which just looks awful by comparison to going from the 4K via a high-quality debayer.

Sorry you has such a bed experience. We have the opposite experience every single day.

Sounds like WHO and did you session with was not experienced enough with RED in SCRATCH. Sounds like you tried to do it yourself - never having used the application before ... without any training? A well documented bug, crashing due to the .rsx files, is being fixed as we speak. Remove them, and you are fine.

As far as scopes go - the deal is this - you can NOT have DEAD ACCURATE scopes without additional hardware. Period. You can get VERY close - but you can't do it in a software package. So Assimilate's takes the position that if you are serious about color grading, you will have a hardware scope, so why put something 80-90% accurate in the software package.

We use the stabilization tool practically every day.

Again, I am sorry you had a bad experience, but Scratch delivers to our clients day in and day out with RED footage. IMHO it takes two to three days to learn the application, depending on your skill level.

 

[M Most]

Well, today I had my first online session with Scratch (version 3.8) and Redcode footage, bringing over and EDL from FCP. Short story: disaster.

Did you consider actually trying to learn the program before using it on a "real" job?

Every single item you mention here (with the exception of a software scope) works just fine. We use it every day, just like Mark. I really don't know what you were expecting, but one needs to learn how something works before deducing that it doesn't.

As far as a software scope, Mark explains that pretty well. I would add that the overhead involved in real time updating of a scope display is very wasteful in a color correction application. Not to mention the screen real estate it occupies. Even if one was present, I would use an external scope set for signal monitoring. Of course, if you're not set up with SDI output, then you're likely not in a high end professional situation that requires such accuracy anyway.

 

[M Most]

At HD Expo, Plaster City Post showed a demo where they cut the 2k qt proxies in FCP, then played them out on an HD monitor in 1920x1080. They have said that they can't see a difference on a high quality HD monitor between the proxie, and the 4k raw processed through redcine and shown in 1920x1080.

Then they're not looking very closely, or on a professional monitor. And they probably don't have much movement or diagonal lines in the material.

 

[Mark L. Pederson]

And they probably don't have much movement or diagonal lines in the material.

Difference is HUGE in my opinion.

 

[Michael Lindsay]

Couple of thoughts..

Assimilate should contact 'weirdcrew'... he is a serious guy and they should try and facilitate his interest..

The world is full of people who can't see, or articulate, differences... I don't worry so much anymore... if forced I'll take money of them in blind tests (always good fun) but the arguments are otherwise impossible to win (without way too much effort)

External scopes are the way.. Software scopes are very very difficult to trust and the CPU/GPU demands mean it is not worth it... (tektronics make great easy kit)


Regards

Michael

 

[M Most]

The world is full of people who can't see, or articulate, differences... I don't worry so much anymore...

You should worry if you're trying to complete a project that's being sold to a major (or even minor) distributor, because the people who work in QC facilities do see the differences. And once reported, those differences need to be addressed. Which can get very expensive if they're inherent in the processing used. And which can get very embarrassing if fixing them is going to require more time than you have to deliver an acceptable version.

 

[Lucas Wilson]

Well, today I had my first online session with Scratch (version 3.8) and Redcode footage, bringing over and EDL from FCP. Short story: disaster.

Before I go into any of the other stuff - first of all - I am really sorry that your first experience was such a bad one. Please contact me offlist, or PM me your email address and I'll try and make it right. If nothing else, it sounds like the SCRATCH facility you chose could use a little bit of training for their artists.

The workflow in Scratch is to load all the footage, then load the EDL, then "assemble" the EDL from the loaded footage.

First problem: every time we tried to load the footage, Scratch crashed. We could load individual shots, but when we tried to load a whole reel, Scratch just crashed. Every time. Really inexcusable.

Depending on what build you used, this is probably due to RSX files or QT Ref files in the load directories. It was a very well-documented bug, has been 100% fixed, was explained on the SCRATCH forum, the Beta SCRATCH forum, and in the Release Notes. If your artist wasn't aware of this and was doing a RED job, then they really aren't keeping up very well.

Next problem: it's a Scratch system. I've never used Scratch before, but man is that user interface horrid.

Sorry you don't like the UI. Unless you were the artist, does that really matter?

We never did manage to get the reference movie to play alongside the timeline movie.

That's because the Reference movies are generated from an OSX Quicktime component, and SCRATCH runs on XP. Chase, again - sorry about your experience - but this is very basic, Operator 101 stuff.

Nor did we find a vector scope for color correction.

That's because SCRACTCH doesn't have an onboard vectorscope. It has a histogram. If you want to use a scope, then use a real scope. Software scopes *always* take dangerous shortcuts and are a bad use of CPU/GPU cycles for a realtime program.

Nor did we find a way to set things like sharpening, detail level, and noise reduction to be the same for several shots all at once.

There are two places to set sharpening - one as a product of R3D metadata, and one as a sharpen filter in the color section (MATRIX) of SCRATCH. Details and Noise are part of R3D metadata.

To do what you want, Copy and Paste All.

Likewise, while the output choices for DPX were Log or Lin, I couldn't find a way to select RedLog or PD Log 685 even though I could verify they were installed. So I don't know *what* Log colorspace Log meant.

Right click in the Player section, and go to LUT. Load the RedLog or PD Log 685 LUT.

Stuck Frames: Even on this full blown Scratch system on Windows, we still had some shots that only showed the stuck first frame through the entire clip, just like people have been complaining happens with Redcine export.

This is most likely a product of how the Assemble was done. There are lots of ways to screw up a conform if you're not very familiar with the Edit Module.

No Stabilization: I tried to use the shot stabilization tool to remove a camera bump, but no joy. The tracking target marker came up, but I couldn't select it and I couldn't move it, so obviously I couldn't set it up correctly.

Right now, the tracker/stabilizer only works on the Full Rez decode.

SLOW: OK, I expect this had to do with this specific computer, but it could only export 1 DPX every 5-8 seconds! And this computer was on a mega-fast SAN, so it wasn't disk IO.

Then something was *really* wrong, either with system setup, or processing options.

I feel pretty well screwed now about trying to get to 1080p with any kind of quality. The only viable path on my budget looks like going through the QT proxies via FCP or Compressor and blowing up the 2048 x 1024 to whatever x 1080, which just looks awful by comparison to going from the 4K via a high-quality debayer.

Chase,

Again - let me apologize for what sounds like an awful first experience. But to be fair, it really sounds like you had a *very* inexperienced SCRATCH operator. Most of the stuff you list here is really really basic stuff. Please contact me offlist. I'd like to do a couple of things here:

1) Find out what facility you used. Having an artist that untrained does nobody any good. I want to arrange for them to get more training, because yours was just one session. I'm sure there are others.

2) Hook you up with several LA facilities that are doing RED work with SCRATCH day in and day out successfully with happy clients.
(your sig says you're in LA...)

Best,

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA
lucas at assimilateinc dot com

 

[Lucas Wilson]

While I actually wrote Lucas at Assimilate asking him for an workflow explanation (I had a Scratch lined up for the test, but the guys running it said thew were not sure of the workflow and that the "Scratch" people themselves hadn't come back to them, so they needed to figure it out first hahaha), I also asked Lucas for a price tag for me if I was to buy Scratch.

Short story..... Assimilate never bothered to come back to me, so one customer less.

Fred,

Sorry about that. I get about 200 - 250 emails a day, and as hard as I try, some things (and people) do slip through the cracks. It's not that I "never bothered to come back" to you, it's that my organizational abilities sometimes fail me.

Since you seem to be on the list today, drop me an email and I'll get you what you need in terms of info.

Best,

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA

lucas at assimilateinc dot com

 

[Chase Gordon]

Before I go into any of the other stuff - first of all - I am really sorry that your first experience was such a bad one. Please contact me offlist, or PM me your email address and I'll try and make it right. If nothing else, it sounds like the SCRATCH facility you chose could use a little bit of training for their artists.

Lucas,

Thank you for your detailed response.

Actually, my colorist, who was considering buying a Scratch system, called you that day but couldn't reach you. I'll PM you in a bit. In short, not being able to afford my own Scratch installation or a full priced rental at a major facility, I went someplace less expensive. I grant that some of these problems I complained about would have been solved by a highly trained (and expensive) operator, but for me the promise of the RED camera was inexpensive in-house post, and I'm finding that to simply not be the case.

mmost, Mark (Offhollywood), yes, this facility had not done a RED project before which is why I was not having to pay $500/hr to use the system. And toward the end, as the operator couldn't figure out the problems, I started digging through the manuals to try to figure it out myself. We did remove the .rsx files and that still did not eliminate the crashing.

Fredrick, we started off with a trained Scratch operator in a facility that does 2K DI every day. We were to conform my FCP edit, grade it, and output DPX files. This is how I define "online session." The Scratch operator, though, was not a colorist and my colorist was not a Scratch operator. The fact that we had to bail on the grading due to lack of a vector scope was actually the least of my frustrations.

The issue of stuck frames (on top of having to manually remove 3 QT proxies for every take we shot) was want sent me through the roof.

First problem: every time we tried to load the footage, Scratch crashed. We could load individual shots, but when we tried to load a whole reel, Scratch just crashed. Every time. Really inexcusable.

Depending on what build you used, this is probably due to RSX files or QT Ref files in the load directories. It was a very well-documented bug, has been 100% fixed, was explained on the SCRATCH forum, the Beta SCRATCH forum, and in the Release Notes. If your artist wasn't aware of this and was doing a RED job, then they really aren't keeping up very well.

We were using version 3.8, the latest build we could get our hands on as of March 7, 2008. We expected those bugs to be, as you say, 100% fixed, but they weren't. Going through and removing all of the QT proxies (over a thousand files, some of which we're still using in FCP) just to load layers in Scratch seems like a lot of prep work for a professional tool.

I'm not saying you won't get this fixed eventually, I'm saying that as of today, taking the footage off of the camera and trying to load it into Scratch without special prep causes Scratch to crash. I think that's unacceptable for a professional tool that is supposed to be the gold standard for RED.

We never did manage to get the reference movie to play alongside the timeline movie.

That's because the Reference movies are generated from an OSX Quicktime component, and SCRATCH runs on XP.

No, we got the movie to play on its own (it was encoded using a DV codec). It's just that the operator couldn't manage to get the split screen to show the reference movie in the reference tray, and despite searching both the "complete" manual and the "users guide" I couldn't figure it out either. Every time we went into split screen we just got two copies of the timeline.

Nor did we find a vector scope for color correction.

That's because SCRACTCH doesn't have an onboard vectorscope. It has a histogram. If you want to use a scope, then use a real scope. Software scopes *always* take dangerous shortcuts and are a bad use of CPU/GPU cycles for a realtime program.

I completely accept this explanation. I'm sorry that my frustration with the whole session got a little out of hand here. I agree that the facility should have had an outboard vector scope. In fact I believe they did but it had been moved to another system for some reason.

Stuck Frames: Even on this full blown Scratch system on Windows, we still had some shots that only showed the stuck first frame through the entire clip, just like people have been complaining happens with Redcine export.

This is most likely a product of how the Assemble was done. There are lots of ways to screw up a conform if you're not very familiar with the Edit Module.

We loaded the footage into construct 1, loaded the EDL, and hit Assemble...
There shouldn't be a way to get a clip to be stuck even on purpose, let alone by accident. And if there is, again I'd say this is a UI issue.

I agree that a bunch of my complaints were grumbles about the system being not user friendly and that would be fixed with training, but this is not one of those. This was, even when we brought in the Scratch expert, not something we could fix and was a real show stopper.

No Stabilization: I tried to use the shot stabilization tool to remove a camera bump, but no joy. The tracking target marker came up, but I couldn't select it and I couldn't move it, so obviously I couldn't set it up correctly.

Right now, the tracker/stabilizer only works on the Full Rez decode.

Yes, I expected that was the case, and for those of you who chimed in that they use it successfully every day, please take note. I'm not trying to trash Scratch in general, I'm just pointing out the several ways I had problem using Scratch in handling REDCODE files.

SLOW: OK, I expect this had to do with this specific computer, but it could only export 1 DPX every 5-8 seconds! And this computer was on a mega-fast SAN, so it wasn't disk IO.

Then something was *really* wrong, either with system setup, or processing options.

As I said, I'm more than willing to believe it was this specific computer, which was set up primarily to conform and grade 2K DPX files and not to do heavy duty transcoding.

Chase,

Again - let me apologize for what sounds like an awful first experience. But to be fair, it really sounds like you had a *very* inexperienced SCRATCH operator.

To be fair, yes, that is true, we had an newly trained operator and me, completely untrained, in a facility that had not done a RED project before. I don't want to give anyone the impression that they'll go to a $500/hour professional studio and have all these problems. I do want to say, though, that to those who thought RED post would be cheap and easy, so far it's not.

 

[John Brawley]

Well, today I had my first online session with Scratch (version 3.8) and Redcode footage, bringing over and EDL from FCP. Short story: disaster.

Scratch works fine. It sounds like you were doing the operating ? That's like getting into the cockpit of a 747 and complaining that it crashed when you tried to fly it.

I have done several projects with it. The last one was in fact a 35mm 4K DI anamorphic job. I graded using 2K proxies and had multiple windows going. I did a feature last year (on film) and stablized many shots that weren't even menat to be stablized (no markers)

It all comes down to the operator.

There's a reason you pay top dollar sometimes. It's actually because you'll get the job done faster (and better) than if you try to take shortcuts.

jb

 

[Lucas Wilson]

Actually, my colorist, who was considering buying a Scratch system, called you that day but couldn't reach you.

Hey Chase,

We have a support email alias, a SCRATCH forum, a Beta SCRATCH forum, several local employees in LA, and several other employees worldwide that monitor support and the SCRATCH forums. I'm glad that he thought to call me, but if that's where he stopped...

The issue of stuck frames (on top of having to manually remove 3 QT proxies for every take we shot) was want sent me through the roof. We were using version 3.8, the latest build we could get our hands on as of March 7, 2008. We expected those bugs to be, as you say, 100% fixed, but they weren't.

Chase, I just checked our build history and the build that 100% fixed this issue came out on Feb. 27, and was released publicly to our beta sites on the 28th. If your artist/facility had contacted support, they could have gotten the correct build, and you wouldn't have had these issues. Either that, or they *did* have the correct build and didn't know how to use it.

Going through and removing all of the QT proxies (over a thousand files, some of which we're still using in FCP) just to load layers in Scratch seems like a lot of prep work for a professional tool.

You know this takes about 5 seconds in Windows Explorer with Search and Move, yes?

I'm not saying you won't get this fixed eventually, I'm saying that as of today, taking the footage off of the camera and trying to load it into Scratch without special prep causes Scratch to crash. I think that's unacceptable for a professional tool that is supposed to be the gold standard for RED.

Again, I really am sorry for your experience, but this was fixed 10 and released 10 days before your session.

No, we got the movie to play on its own (it was encoded using a DV codec). It's just that the operator couldn't manage to get the split screen to show the reference movie in the reference tray, and despite searching both the "complete" manual and the "users guide" I couldn't figure it out either. Every time we went into split screen we just got two copies of the timeline.

1) Player -> Settings -> Dual View.
2) Once Dual View is turned on, open the Tray and select the Clip you want to see in the right-hand side.
3) Settings -> select "Reference" in the Dual View setting.

It is on page 98 of the 3.5 Users' Guide, under the "Verify Conform" section. Our PDFs are indexed and searchable, and you can find it by searching for "Conform," "Dual View," "Tray," or "Quicktime."

Sorry dude... I can't see your point on this one.

We loaded the footage into construct 1, loaded the EDL, and hit Assemble... There shouldn't be a way to get a clip to be stuck even on purpose, let alone by accident. And if there is, again I'd say this is a UI issue.

With due respect, I'd say that based on the apparent level of skill of your operator, I don't think it's a UI issue.

Yes, I expected that was the case, and for those of you who chimed in that they use it successfully every day, please take note. I'm not trying to trash Scratch in general, I'm just pointing out the several ways I had problem using Scratch in handling REDCODE files.

I really do get that... you're not bashing, you just had a really bad experience. No harm, no foul.

To be fair, yes, that is true, we had an newly trained operator and me, completely untrained, in a facility that had not done a RED project before. I don't want to give anyone the impression that they'll go to a $500/hour professional studio and have all these problems. I do want to say, though, that to those who thought RED post would be cheap and easy, so far it's not.

To be equally fair, if you had one newly trained operator and one completely untrained operator, ummm.... how easy did you expect it to be?? : )

I got your PM - thanks. Will respond shortly.

Best,

Lucas
------
ASSIMILATE, Inc.
LA, CA, USA

 

[Chase Gordon]

Chase, I just checked our build history and the build that 100% fixed this issue came out on Feb. 27, and was released publicly to our beta sites on the 28th. If your artist/facility had contacted support, they could have gotten the correct build, and you wouldn't have had these issues. Either that, or they *did* have the correct build and didn't know how to use it.

I told the facility that Scratch was being updated weekly if not daily and to please install the very latest version on 3/7. When we had initial problems loading the footage I checked with the tech (called him at home) and he verified the he did upgrade it on 3/7 and on further inspection, we could see dates of 3/7 on some of the files in the Scratch program folder. I confirmed again today that it was version 3.8, build 443.

If I had to guess, it would be that they didn't want to install "beta" software as they are not primarily a RED house. They are primarily a film house.

As for the render speed, I've confirmed it was a dual core AMD 64 bit CPU running some kind of nVidia QuadroFX video card, though probably not the latest.

Going through and removing all of the QT proxies (over a thousand files, some of which we're still using in FCP) just to load layers in Scratch seems like a lot of prep work for a professional tool.

You know this takes about 5 seconds in Windows Explorer with Search and Move, yes?

No, I didn't know that. How do you put them back when you're done?

1) Player -> Settings -> Dual View.
2) Once Dual View is turned on, open the Tray and select the Clip you want to see in the right-hand side.
3) Settings -> select "Reference" in the Dual View setting.

It is on page 98 of the 3.5 Users' Guide, under the "Verify Conform" section. Our PDFs are indexed and searchable, and you can find it by searching for "Conform," "Dual View," "Tray," or "Quicktime."

I know they're indexed and searchable, I spent a lot of time searching them. The operator was under the impression you had to select the reference before switching to what he called "split view", which is what I wasn't finding in the "complete" reference guide.

OK, so I guess the operator was greener than I was led to believe.

To be equally fair, if you had one newly trained operator and one completely untrained operator, ummm.... how easy did you expect it to be?? : )

I was prepared for it to take 4 hours to do what a top pro would do in 30 minutes. I was not prepared to spend 8 hours and not come out with anything useful to show for it.

Honestly, my goal for this session was to render 6 minutes of ungraded footage to send to the VFX house. Everything else was meant to be testing and learning. At the rate it was rendering, though, it would have taken over 12 hours to render once we got the render started, and when I canceled the render I guess it deleted the rendered files because there was only one in the output folder despite the display showing that there were a lot rendered.