Wrong timecode with QT wrapped R3D's and compressor

[Jeremy Newmark]

Hey Guys,

Yesterday I discovered a rather annoying bug with wrapped R3D's. I noticed that after loading wrapped R3D's into Final Cut Server, all of the transcoded files created had incorrect time code. The starting timecode of all the clips had a shift of anywhere between 4 and 40 seconds earlier then the actual file. FCS uses compressor to transcode, so I tested loading wrapped R3D's straight into compressor and it looks like that is were the problem starts. If you transcode from the QT reference or proxy files, the timecode is correct, it's just the log and tranfer created wrapped files that seems to be exhibiting this issue. Anyone else seen this or have any ideas? It's all been 23.976 media.

 

[Jeremy Newmark]

bump - anyone?

 

[Reinhart]

Hey Guys,

Yesterday I discovered a rather annoying bug with wrapped R3D's. I noticed that after loading wrapped R3D's into Final Cut Server, all of the transcoded files created had incorrect time code. The starting timecode of all the clips had a shift of anywhere between 4 and 40 seconds earlier then the actual file. FCS uses compressor to transcode, so I tested loading wrapped R3D's straight into compressor and it looks like that is were the problem starts. If you transcode from the QT reference or proxy files, the timecode is correct, it's just the log and tranfer created wrapped files that seems to be exhibiting this issue. Anyone else seen this or have any ideas? It's all been 23.976 media.

L&T reports the timecode that was set with the user preference during shooting (REDONE offers 2 timecode options). This could be the root of the problem you're seeing. It's something we're looking into but are unsure of the proper solution right at the moment.

Craig

 

[Uli Plank]

Since FCP is supporting an alternative TC, why not transport both of them in the next version?

 

[Reinhart]

Since FCP is supporting an alternative TC, why not transport both of them in the next version?

Easier said than done.

 

[Jack Langer]

Are there plans to offer QT renders with both the TOD timecode track and the EDGCODE that FCP can read as AUX TC? Currently, when importing the r3d wrapped qt's which contain both timecode tracks into FCP, only the main timecode shows up. AUX TC has to be input manually. Is this a RED problem, an APPLE problem or both?

Fixing this could potentially save a lot of time in the sound synching process.

 

[Deanan]

Are there plans to offer QT renders with both the TOD timecode track and the EDGCODE that FCP can read as AUX TC? Currently, when importing the r3d wrapped qt's which contain both timecode tracks into FCP, only the main timecode shows up. AUX TC has to be input manually. Is this a RED problem, an APPLE problem or both?

Fixing this could potentially save a lot of time in the sound synching process.

Only the first TC track is used in all the programs I've checked.

 

[Jack Langer]

Yes, however when adding aux timecode in FCP to a clip with only one timecode track, FCP adds a second timecode track to the actual quicktime. Does anyone know what the difference is between the FCP created timecode track and the second timecode track on the r3d wrapped quicktime? Since there is obviously some difference.

If this was known the second timecode track could be modified in the next build and easily read as aux timecode by FCP.

 

[Deanan]

Yes, however when adding aux timecode in FCP to a clip with only one timecode track, FCP adds a second timecode track to the actual quicktime. Does anyone know what the difference is between the FCP created timecode track and the second timecode track on the r3d wrapped quicktime? Since there is obviously some difference.

If this was known the second timecode track could be modified in the next build and easily read as aux timecode by FCP.

The answer we got back from apple was that it wasn't possible.