Welcome to our community

Be a part of something great, join today!

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

Send to Color - Clips are nothing but frozen frames

Matthew Rogers

Matthew Rogers

Banned
Joined
Mar 9, 2007
Messages
1,497
Reaction score
0
Points
0
Age
44
Website
www.macvilleproductions.com
So I have a timeline which I have sent to Color from FCP. It's all _M proxy files that have worked great up until a section of clips. It's a section of clips which were shot all in one day, build 17. Everything else on the timeline plays fine except these clips. Basically color has chosen a random frame from the clip (not necessarily within the clips I/O points) and is frozen on that. I checked to see if any of the clips span the 2GB limit, but they are all single .R3D files. So what could possibly be the issue that all my other clips work, but those don't work?

Matthew
 
Have you tried running ColorFixer on the project?
 
ColorFixer or importing as an EDL instead of sending to color should fix that problem for you. ColorFixer is easier because it retains the benefits of using the send to color command.
 
  • Thread starter
  • Banned
  • #4
Yeah, I ran colorfixer on it to begin with. That's why I am confused. Not to mention that colorfixer shouldn't matter because none of the clips are spanned files. But it is ONLY the clips from that shoot. All my other clips work fine. I guess I might try sending an EDL over, but the send to color is much easier and quicker.

I may try deleting the proxy files and remaking them. Maybe somehow that's the issue.

Matthew
 
  • Thread starter
  • Banned
  • #6
ThomtheEditor said:
did you make sure your sequence was in redcode b4 sending?
Click to expand...


The sequence is set for ProRes HQ, but since it's only clips from one day of shooting on a certain shoot, I think something else is up. I would think if it has to do with the sequence settings that none of the clips would work.

Matthew
 
  • Thread starter
  • Banned
  • #8
I've now tried redcode, colorfixer, changing folder names, going via EDL which couldn't even find the files correctly. The only thing that I notice is different between these R3D files and my other R3D's is that these files have all 4 audio channels on. All my files with 3 and 2 channels work fine. I don't have another file that I can find with 4 channels enabled, but I may try shooting a test with 4 channels on this afternoon.

Matthew
 
try deleting the audio from the sequence you're sending to color; obviously save a version of the timeline with correct audio and then just copy and paste the audio to the colored timeline when finished
 
This is a basic question, I'm sure the answer is no, but do your clips have any speed changes or time remapping? That can cause similar behavior.
 
I've already tried deleting the audio, so that wasn't the issue. One of the clips from that day has a speed ramp, but other clips in my sequence have speed ramps and Color now handles them correctly. Does anyone know of a program that lists ALL the metadata for clips?

Matthew
 
We've the same problem with several clips also, everything has been shot in the same settings though.

Also ran our colorproject through colorfixer, removed all effects etc. didn't help, created new quicktimes...

Anyone got a solution for now?
 
Ha! Today while looking for why this could be I found that all the clips which have the "still frame" problem do have a RSX file attached... more to come.
 
I have now managed to screw my settings up in a way that every sequence I send to Color with RED footage in it will only show still frames haha.

I seem to have found what's the problem on the surface, but changing it doesn't bring the clip back, so here's what I've found:

at legal clips, that play, the timecode is something like this:

<sourceframe>
<in>01:33:37:15</in>
<out>01:34:20:01</out>
</sourceframe>
Click to expand...

but in the "broken" clip, it's something like this:

<sourceframe>
<in>01:04:43:05</in>
<out>20:58:51:03</out>
</sourceframe>
Click to expand...

obviously the clip isn't 20 hours, so I don't know where that error happens.

I hope I can solve this soon as we desperately need this.

cheers, Xax
 
I may have nailed down the error...

Matthew, did you by any chance had new Quicktimes generated for those Build 17 clips in the NEW RedAlert or NEW clipfinder?

Since I generated new Quicktime files for those clips they don't work anymore! It may be that since the new RedAlert and thus new clipfinder uses new quicktime, but those clips were shot with an older build, this problems appears.

So I am going to download an older version of Redalert and try with that. Good luck to both of us I guess.

Cheers, Xax
 
YES! FOUND THE BUG!

So what I did to get the clip back to work in Color:

I downloaded an older version of RedAlert, deleted the Quicktimes I generated with the newer version of RedAlert, ticked "use edge code" (not sure if necessary), then generated proxies with 3.50 BETA of RedAlert, and after another "send to Color", it WORKS!

So if in the future you are working with footage from pre-build-20, but want to roundtrip with Color and R3Ds, DO NOT CREATE NEW QUICKTIMES FROM REDALERT v20+, this will kill the usability of those clips in COLOR!

It would be great if Matthew could confirm this.

Debugging sucks.
 
You must log in or register to reply here.
Back
Top