Timecode Issues

[Grayton hevern]

Hi
I am having all sorts of issues going through the online process, haven't found a way that works every time, am coming across strange issues, importing an edl into scratch a few shots didnt match up, after a while I realized this particular issue wasn't happening because of scratch when I checked the r3d file with the proxies and my red rushes file, the proxies and the red rushes file matched my timecode in my edit but the red file in both red alert and red cine reads different code, so this is not a scratch question its a red question, why are the codes different? and I was under the impression that red rushes accessed the r3d file to do its decode so why has that taken the proxies timecode. Before someone says match the shoot by eye, let me assure you this is the first issue in many I am dealing with, I need to push aside the problems that can be fixed and if I am not able to trust the code on every shot then thats a major issue.
cheers

ok I thought it might have been when I added my ins and out in red alert, I just regenerated my proxies and now that file matches again, why on earth did changing my in and outs affect the timecode, and why on earth is the timecode not locked to the vision? regardless of where you set your in and outs. I think I read about this bug in red rushes, has it been sorted? this project was put through on the first version of red rushes. I emailed red a few months ago and asked if there was going to be any type of papers released on the post workflow and they assured me there was going to be, they also said due to the changing nature of red and the numerous ways to post red that its very difficult to produce such a thing, and I fully understand that, but a proven rock solid pathway that us guys in post can tailor to are own needs is something I would like. I original thought the issues in post were due to lack of knowledge and that the people who are being scared away from red were ill informed, and to a degree they are but cmon we need to iron out the post/online/beta issues, if major features are shooting red then I assume there are very smooth workflows out there, I wouldnt expect people to explain them, but give a dog a bone and give us in post a clear indication of what doesnt work at least. If I sound annoyed then apologies as I like most on this site I love the damn camera, its just I dont know if the issues I have come across are Scratch/Crimson related or Red related.

 

[Deanan]

Which versions are you using?
There was a bug a couple of versions back that had a strange timecode problem that would occur when a number of conditions happened at the same time.

RR/RL/RA/RC/Scratch all take the timecode directly from the R3D.

Timecode in QT wrappers and transcoded Quicktimes take the timecode
from the first frame of the R3D (it's the way QT works).

 

[Grayton hevern]

"Timecode in QT wrappers and transcoded Quicktimes take the timecode
from the first frame of the R3D (it's the way QT works)."

The edit I am working on was generated from the very first public release of red rushes.
So how does moving my in point in red alert move the code in the proxy? or was this the bug you spoke of. The timecode on the proxy and the red rushes file doesnt even occur in the r3d file, so it must be a bug, how did it generate new timecode would be my question. What where the number of conditions that happened at the same time to cause the bug, so I can avoid it in the future.
regards
Grayton

 

[Deanan]

I don't have the details of the conditions that caused the bug at the moment as it was a complicated set of circumstances. The latest release version doesn't have that problem.

If you need to verify which versions had the problem, I'd recommend using the old version of REDline to output a CSV of your files and then use the new version to do the same and compare the timecodes.

 

[Grayton hevern]

thanks Deanan, is their any talk of releasing red official post papers?

 

[Deanan]

We're planning on releasing a paper on color and gamma spaces. The post workflows will be growing tremendously over the next few months so we're working figuring out how to communicate the growing number of options. Everything is improving so documentation quickly becomes outdated.

 

[Grayton hevern]

"Everything is improving so documentation quickly becomes outdated."
Its difficult to have anything against improving, however this is the problem I have found as your continually chasing your own tail, I suppose I have to look at red post closely on every job, it is frustrating not being able to lock a path down for clients, is their a point in the future where the evolution of the camera slows down, I know that goes against the spirit of red, but is there a point where you guys say "this is the camera" and upgrades will become more spread out. It kind of feels like Red is afraid to outline post workflows for fear of being wrong. People might think its not your place to work out my workflow, but if I am going to learn to walk a different way I need some instructions, for example where is rundown on how to use redline, I havent been able to get into it as I dont know where to start. I struggle to see outlined workflows on this board, something that says for scratch do this, for crimson to do this, for final cut do this, anything above the simple cut with the proxies seems to be a long journey to work out. Has anyone on these boards written their own version of software manuals explaining what these programs released by red do in detail, or is the have a go and see attitude is what is needed everytime.
Anyway apologies for my rant, no offense intended
regards
Grayton