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 :)

RED audio timecode issue. . . will it be an issue for us?

Stephen Pruitt

Stephen Pruitt

Well-known member
Joined
Sep 14, 2007
Messages
3,309
Reaction score
40
Points
48
Website
www.thetreemotionpicture.com
Hi all. . .

I'm trying to figure out if the known R3D/multi-track audio timecode issue is going to be a problem for our production or not. Many (most?) of our R3D files have multiple embedded audio tracks, and these audio tracks are sometimes the only audio available.

We intend to send the completely edited film (a 2 1/2 hour feature) to a colorist for finishing. This will involve reaccessing the R3D files on their system. Since the color work will likely be done on Resolve or Scratch or. . . I want to know if an EDL file created in Premiere Pro will cleanly transfer to another system without any syncronization incidents.

We had exactly zero issues going from FCP 6 to Scratch, and I'm hoping that we can do the very same thing with Premiere Pro, as well. If there is going to be an issue, I want to know now, before we begin editing the film, so that we can just stick with FCP.

Thanks.

Stephen
 
Audio and Timecode

Audio and Timecode

I'm trying to figure out if the known R3D/multi-track audio timecode issue is going to be a problem for our production or not.
Click to expand...

What known audio timecode problem are you referring to Stephen?
 
Audio and Timecode

Audio and Timecode

That thread suggests it's an Adobe display issue, not a camera accuracy issue.
 
I know it's not a camera issue, Stuart. . . I'm trying to find out if this timecode issue is going to bite me if we go with Premiere and then do a final finish on a Scratch system. I don't have the expertise to color this film myself, and I don't want to get backed into a situation where I'll have to.

Stephen
 
I can't believe that no one is having to deal with this issue.

Is there anyone out there who can tell me what the issues involved will be in working in CS5 environment with a Resolve or Scratch coloring finish? Our R3D files definitely have multi-track embedded audio and while I truly want to work with CS5, I'm quite concerned that the timeline won't be stable in a move across programs/platforms.

Thanks.

Stephen
 
and you can't test it out?

worst case scenario, unless you need the colorist to grade your audio waveform, export that separately and link it back in scratch... pretty simple stuff.

is it a silly problem that adobe should have already fixed? yes. but for the time being just do what works. and if you just don't feel good about it, don't use adobe.
 
Hey there, Paul. . .

I can't test it out because I don't have CS5 yet and don't want to buy it until I am certain it will work.

I'm not certain but it does not sound like your solution will work, though. Apparently, the problem goes with any R3D that has more than one embedded audio tracks. That's true of many (but not all of our clips). So stripping out the audio separately won't work.

But, surely, someone here has used CS5 to edit a film with audio tracks attached to the R3D files and then went out to Scratch or Resolve or something.

Man. . . if the world were only simple.

Stephen
 
Stephen, my suggestion is to use an external Sounddevice that slaves the RedOne. This way you don't have to deal with this issue and sound- and cameraman will be happy as well because they are not tethered to each other, plus there are many other advantages. Most productions work this way.

We are working with R3Ds and TC corresponding BWF files every day. Premier Pro CS 5.03 has a wonderful TC syncing tool that always, I say again: always delivers perfectly synced clips.

The best thing is that the Adobe way of synching makes an XML or EDL conform as easy as it gets because it does NOT create like FCP virtually "merged" clips that are not pictured by EDL/XML but uses the original sound files in the timeline any finishing application understands.

I conform my projects this way in Smoke and it works flawlessly (although I have to round trip via FCP because Smoke cannot read PremierPro XML). For a Scratch conform you will use an EDL anyway because Scratch cannot read XML yet, as far as I know.

With Premier Pro CS5.03 Adobe made a big jump.

As a side note I have to say that there are often uncertainties on set. Even if the chain symbol confirms that the Sounddevice and RedOne are in sync TC on the displays on both devices tend to differ a second or so. One has to over see this... and believe in Red. Re-syncing after every battery change is mandatory, otherwise you are not synced. I found that Red's TC generator is pretty accurate. Sounddevice and RedOne hold sync over 2 hours. Longer than that I never tested.

Hans
 
Hey there, Hans and Brad. . . thanks for your posts.

Unfortunately, it appears I'm apparently not making myself clear. I'll try again.

I don't have Scratch. I don't have Smoke. I don't have DaVinci. What I currently have is FCP 7.

I was hoping to move to CS5 because it is easy to work with without doing any transcoding, etc.

Now, my R3D files often have multiple audio tracks on them. According to things I'm reading, Premiere Pro has a glitch whereas R3D files with multi-track audio files attached to them yield false time codes in the system and are off by 1 to 3 frames (randomly). Files without multi-track audio are read and reported without TC issues.

All is well and good so long as I edit AND FINISH in CS5. The trouble is when one leaves the CS5 environment to head over to a finish in Scratch/Smoke/Resolve/etc.

Since the EDL/XML produced by Premiere Pro MUST serve as the basis for the post work that follows, and since this code is WRONG for clips that contain multi-track audio R3Ds, it looks to me like it will not be possible to cleanly color/finish any R3D files that have multi-track audio on them (which, in our case, is almost all of them!).

What I need to know is if this is, indeed, the nightmare it currently seems to be. Colorist John Tissavary (who uses a Scratch system) has been on here complaining about this issue, calling it "HUGE" (his emphasis). I don't know, since I've never before done any of this work before myself and I have no capability to do so myself (not having any program other than FCP).

What I need to hear from are people who do post work using CS5 on R3D files with multi-track audio embedded in them and then attempt to output their edit files into a finishing program like Scratch or Resolve.

Thanks.

Stephen
 
Stephen Pruitt said:
...I don't have Scratch. I don't have Smoke. I don't have DaVinci. What I currently have is FCP 7....
Click to expand...

Stay with your current workflow and safe money. This are the reasons:

Premier Pro CS5 needs a powerful box and a Cuda enabled graphics board by Nvidia to work well with R3Ds. You might find out that your box is not performing as snappy as you expect.

This multi track TC bug is not solved yet. Because you want to record audio internally this problem will not go away today, perhaps tomorrow, perhaps when...? Will an Adobe update solve it? We don't know.

Currently CS5 does not support the latest colour science. No RedColour2 and no RedGamma2. For offline edit this might be no obstacle, though.

Last but not least, when Adobe will address this issue it can likely happen that a new FCP is on the road which upgrades your Red workflow significantly, or not.

Your question is hard to answer because only Adobe can give you a meaningful answer.

Again, I guess staying with FCP makes the most sense.

Hans
 
Stephen Pruitt said:
Hey there, Hans and Brad. . . thanks for your posts.

Unfortunately, it appears I'm apparently not making myself clear. I'll try again.

I don't have Scratch. I don't have Smoke. I don't have DaVinci. What I currently have is FCP 7.

I was hoping to move to CS5 because it is easy to work with without doing any transcoding, etc.

Now, my R3D files often have multiple audio tracks on them. According to things I'm reading, Premiere Pro has a glitch whereas R3D files with multi-track audio files attached to them yield false time codes in the system and are off by 1 to 3 frames (randomly). Files without multi-track audio are read and reported without TC issues.

All is well and good so long as I edit AND FINISH in CS5. The trouble is when one leaves the CS5 environment to head over to a finish in Scratch/Smoke/Resolve/etc.

Since the EDL/XML produced by Premiere Pro MUST serve as the basis for the post work that follows, and since this code is WRONG for clips that contain multi-track audio R3Ds, it looks to me like it will not be possible to cleanly color/finish any R3D files that have multi-track audio on them (which, in our case, is almost all of them!).

What I need to know is if this is, indeed, the nightmare it currently seems to be. Colorist John Tissavary (who uses a Scratch system) has been on here complaining about this issue, calling it "HUGE" (his emphasis). I don't know, since I've never before done any of this work before myself and I have no capability to do so myself (not having any program other than FCP).

What I need to hear from are people who do post work using CS5 on R3D files with multi-track audio embedded in them and then attempt to output their edit files into a finishing program like Scratch or Resolve.

Thanks.

Stephen
Click to expand...

Cutting a feature length film ( I imagine Low budget) with R3D's Is not a very smart move, regardless of what system you use, be it Smoke, FCP, Avid, Quantel, etc Native editing is best suited for short form projects. R#D's are system hogs by nature and you can't do much with them but one light CC. The are many Log intermediary codecs you can use. Transcoding to those codecs through Redcine-X will always maintain the Audio sync.

Also just like Color correction Audio tools in PPro like all NLE's, except Smoke are not conducive for mixing, sweetening and Mastering.
You are on the right path Asking the right Questions. There is just no right answer, because some folk record Audio into the camera, but most people don't. Some people Jam sync code, others clap slate, some Denecke slate etc. Like paul said, it would be wise to stick with FCP, proxie Edit using clip-finder, then CC with Apple Color, which has A solid RED room. At which point you wont have to worry about sound sync.

R3Ds are hands down the best Raw acquisition format out there, but most colorist will tell you, there is very minimal loss in transcoding to a Log format. The Key issue is consulting with your colorist and having them do the One light debayering for you. Look into a system like the Foundry's Storm, which even allows you to trim your R3Ds.
 
shashbugu said:
Cutting a feature length film ( I imagine Low budget) with R3D's Is not a very smart move, regardless of what system you use, be it Smoke, FCP, Avid, Quantel, etc Native editing is best suited for short form projects. R#D's are system hogs by nature and you can't do much with them but one light CC. The are many Log intermediary codecs you can use. Transcoding to those codecs through Redcine-X will always maintain the Audio sync.

Also just like Color correction Audio tools in PPro like all NLE's, except Smoke are not conducive for mixing, sweetening and Mastering.
You are on the right path Asking the right Questions. There is just no right answer, because some folk record Audio into the camera, but most people don't. Some people Jam sync code, others clap slate, some Denecke slate etc. Like paul said, it would be wise to stick with FCP, proxie Edit using clip-finder, then CC with Apple Color, which has A solid RED room. At which point you wont have to worry about sound sync.

R3Ds are hands down the best Raw acquisition format out there, but most colorist will tell you, there is very minimal loss in transcoding to a Log format. The Key issue is consulting with your colorist and having them do the One light debayering for you. Look into a system like the Foundry's Storm, which even allows you to trim your R3Ds.
Click to expand...


We have had several people use PPro to shoot feature length native RED stuff. It is working pretty snazzy in the field. Need a good machine but it works great. Wait to you see whats next....

Cheers

Dave
 
David McGavran said:
We have had several people use PPro to shoot feature length native RED stuff. It is working pretty snazzy in the field. Need a good machine but it works great. Wait to you see whats next....

Cheers

Dave
Click to expand...

Nothing to do with PPro David. I have overseen two R3D features cut with Prepro cs4 and cs5, I'm fully aware of its capabilities. My post must have been worded wrong. I was only referencing issues beyond the edit the native Edit.

oooooh!!! Now you've got me super excited, I know you have something powerful in the works, you've been in stealth mode for a few months. Keep up the good work.
 
shashbugu said:
R3Ds are hands down the best Raw acquisition format out there, but most colorist will tell you, there is very minimal loss in transcoding to a Log format.
Click to expand...

Yes. No loss actually if you use DPX, for instance. No colourist I know would work without a gamma curve off linear R3Ds, all chose either RedLogFilm or RedGamma2. It doesn't matter when you transcode RAW to RGB, prior or after grading. All you want is to keep all available information. And that will be the case either way.

Hans
 
David McGavran said:
We have had several people use PPro to shoot feature length native RED stuff. It is working pretty snazzy in the field. Need a good machine but it works great...

Cheers

Dave
Click to expand...

Yes. We've done it with a lengthy documentary based on R3Ds and separate sound, edited on 2 edit bays with PremierPro and ending up in Smoke. We never had before such a smooth editing and finishing experience with Red footage. Premier Pro made a big, big jump.

Hans
 
It all sounds terrific. Now, if they could just fix the multi-track R3D audio bug we'd all be in seventh heaven. Or almost.

Stephen
 
David McGavran said:
We have had several people use PPro to shoot feature length native RED stuff. It is working pretty snazzy in the field. Need a good machine but it works great. Wait to you see whats next....

Cheers

Dave
Click to expand...

Well, Dave, it works great as long as you don't want to import or export a list for use with some other system, then its not so great. I love PPro, and it does work great on its own, but I have had nothing but problems with importing or exporting useful TC since CS4. I've come to think of PPro as an "island" that doesn't play nicely with others.

Todd Kopriva at Adobe support says that it is a known issue that you're working on. He says that it only affects clips with multiple audio tracks. (I always record audio, so perhaps that's why I always have this problem.) The TC is off by a large measure, and as far as I can tell the error is random, so you can't do an offset to fix it.

Now here's the really odd bit: If you shoot at 23.976 and tell PPro to interpret the footage as 24 fps, PPro seems to read the TC properly. I don't know whether it's a usefully accurate solution for a timeline as long as a feature, I just learned about this workaround tonight from the Adobe forum. But it did work well enough for me to hand-enter a list for a 30-second spot tonight.

I think this is something that ought to be at the top of the list for stuff to get fixed. The ability to hand a project off to someone at a different facility is an essential need for pro workflows.
 
D Fuller said:
Well, Dave, it works great as long as you don't want to import or export a list for use with some other system, then its not so great. I love PPro, and it does work great on its own, but I have had nothing but problems with importing or exporting useful TC since CS4. I've come to think of PPro as an "island" that doesn't play nicely with others.

Todd Kopriva at Adobe support says that it is a known issue that you're working on. He says that it only affects clips with multiple audio tracks. (I always record audio, so perhaps that's why I always have this problem.) The TC is off by a large measure, and as far as I can tell the error is random, so you can't do an offset to fix it.

Now here's the really odd bit: If you shoot at 23.976 and tell PPro to interpret the footage as 24 fps, PPro seems to read the TC properly. I don't know whether it's a usefully accurate solution for a timeline as long as a feature, I just learned about this workaround tonight from the Adobe forum. But it did work well enough for me to hand-enter a list for a 30-second spot tonight.

I think this is something that ought to be at the top of the list for stuff to get fixed. The ability to hand a project off to someone at a different facility is an essential need for pro workflows.
Click to expand...

Thank you David for clarifying what I was trying to explain.

Premiere pro at the moment is an Island with native workflows. My point I was trying to get across to Stephen was, once you have to transcode to a Log format, PPro CS5, has only one advantage over other NLE's, "screaming fast speed".

But I do strongly believe all of these little bugs and quirks will be a thing of the past. I truly believe in Adobe's efforts and quick response.
 
You must log in or register to reply here.
Back
Top