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

First time: R3D Workflow correct?

M

Moritz_R

Member
Joined
Jun 7, 2010
Messages
12
Reaction score
0
Points
0
Location
Germany
Hello redusers,

for a student short we got the task to develop an (mobile) AVID workflow on our on. Never worked with RED before, we started from scratch.

This is what we come up with:
Backup R3Ds on set on HDDs
=> transfer files onto the disks connected to our mobile AVID
=> transcode rushes in RedAlert with burn-ins in DHxHD.
=> Export an ALE from rushes => import that into AVID
=> connect DNxHD files in AVID
=> sync sound, sort an name everything, make a backup.

The editor will then take over the project an do the editing. Finally he exports an EDL for the finishing process (as I understood the offline files will then be replaced with the r3ds for precise colorcorrection).

As far as our testing goes, everything seems fine. Metadata shows up in AVID thanks to the ALE. :smile:

Not having a finishing software, we are not able to check if the last 50m of the marathon really work. We absolutly want to avoid that the finishing software doesn't "know" the connection between off- and online-files!
Any suggestions what we could have overseen? Anything what we must not do?
And: As we check the metadata in AVID, we see the path where the R3D was, when we rendered out the DNxHD.
Originally we wanted to copy the R3Ds of one day of shooting on the AVID-HDDs, so that we can develop the DNxHDs thenwithout the Source-HDDs having to be connected to the laptop all night.
When the rendering is successfully finished, we the would have erased the source-R3D-material from the avid-laptop (not from the source-HDDs of course!).
But knowing that the path of the R3D is know written into the ALE while exporting, and then erasing the R3Ds would bring us in real trouble, because the connection between off- an online would be lost.

Am I correct?

Why I'm asking this question? If we have to render the offlines from the original "place" (source-hdd) overnight any anything goes wrong, I cannot take the HDDs to the set next morning.
Secondly, I don't like the idea that the source HDD is running all night long...

Thank you for your replies!

Greetings,

Moritz
 
How are you planning on finishing?

If you use the latest version of REDCINE-X, you can skip the QuickTime files and import step reducing your hard drives needs by half.

Michael
 
MichaelP said:
How are you planning on finishing?

If you use the latest version of REDCINE-X, you can skip the QuickTime files and import step reducing your hard drives needs by half.

Michael
Click to expand...

Hi Michael,

I assume you refer to the fact that Redcine does export MXFs directly - and Rushes puts out QTs which need to be rewrapped (=copied).

We decided in favour of Redrushes because the workflow was easier to understand. We are using the AVID/RED stepbystep-guide.

But the rewrapping does not seem to be a problem (apart from the fact of creating the double amount of data). But converting R3Ds to DNxHDs directly from source-HDD is.

Greetings,

Moritz
 
If it works, it works. As an FYI, you can look to the RocketCine-X guide for how it would work with REDCINE-X. While the apps are a bit different, the back end import into Avid is pretty much the same.

Michael
 
I'd strongly second Michael's suggestion to check out RedCine-X. If you follow the guide for RocketCine-X, you'll figure out the missing pieces in 10 minutes. But using this method is so much faster than the "old" RedRushes method, that any time you spend figuring this out is actually time you gain back.

Also, note that you could now use Media Composer 5 to instantly open the R3D files in Avid, then transcode (without burnins, though) into DNxHD.
 
Job ter Burg said:
I'd strongly second Michael's suggestion to check out RedCine-X. If you follow the guide for RocketCine-X, you'll figure out the missing pieces in 10 minutes. But using this method is so much faster than the "old" RedRushes method, that any time you spend figuring this out is actually time you gain back.

Also, note that you could now use Media Composer 5 to instantly open the R3D files in Avid, then transcode (without burnins, though) into DNxHD.
Click to expand...

I just went through it again. The manual says I have to save the project as XML-file instead of rcx. But RCX won't let me do that. Renaming the file from rcx to xml and opening it in the texteditor just results in an awful bunch of chaotic letters. The guide also says that the textfile has to be converted several times.

I think it is the best to stick with Rushes as we are now familiar with it, and also the rewrapping process only takes little time in comparison to the conversion of R3Ds.

Can anybody tell me if we must convert them from there original folder? I would love to just copied the data of one day to the avid-computer and unplug the source-hdds instead of them running all night long.

Thanks again for your help.

Regards,

Moritz
 
Yes, look to the Rocketcine-X one for now, not REDCINE. The older REDCINE that was developped by Assimilate needed XSL conversions back and forth. REDCINE-X uses Avid's SDK and exports MXF, AAF and ALE directly.

Michael
 
Job ter Burg said:
Moritz, did you go to avid.com/red?
That should have pointed you to this PDF: http://www.avid.com/static/resources/documents/solutions/ROCKETCINE-X_FN_sec.pdf. This shows you how to open files in RocketCine-X, and set an export format. RedCine-X works more or less the same as RocketCine-X (which only works with a Rocket Card).

It's so much faster, please do check it out.
Click to expand...

MichaelP said:
Yes, look to the Rocketcine-X one for now, not REDCINE. The older REDCINE that was developped by Assimilate needed XSL conversions back and forth. REDCINE-X uses Avid's SDK and exports MXF, AAF and ALE directly.

Michael
Click to expand...

Great news! You guys convinced me and my collegue to knock over our entire little workflow.

With this genious little guide provided, we get along slowly but constantly.

We skipped the point with the AAFs and do the ONE STEP ALE RELINK (p. 15)

But as some questionmarks vanish, new ones appear:

1) I deselected Audio completely in RC-X (as we record sound externally), but it does produce AFFs anyhow? Why? Can I erase them?
2) I created a look-preset in RC-X, applied it to all clips (RMD are created in source folders), but it seems that it does not alter the offline-DNxHD. Are the RMDs only for online?
3 and MOST IMPORTANT) While import is working we get following error-message while playing back:embarassed:

<className>::<methodName>(89CONSISTENCY CHECK FAILURE !?! : [ <idNum>]

Help!

Greetings,

Moritz

EDIT: Our HDDs are the opposite of fast, can this be the cause of the error? Does it help if we reduce the level of quality in the relinking options?
 
Last edited:
Do the ALE files still show A tracks in the Tracks column? Try dragging the AAFs into the bin as a test first. They should just link to the media with no need to for extra steps. See if that gets rid of the error message.

Michael
 
MichaelP said:
Do the ALE files still show A tracks in the Tracks column? Try dragging the AAFs into the bin as a test first. They should just link to the media with no need to for extra steps. See if that gets rid of the error message.

Michael
Click to expand...

Thank you Michael, there was the mistake. Now everything seems to work fine.

Do you know what reference does RC-X take for the conversion (concerning colorspace/gammaspace)? I assume it is the metadate taken from the camera. Can you confirm this?

Assuming that a wrong whitebalance is selected on set, and I corrected afterwards creating an RMD automatically, what do I have to do that RC-X does take these corrections as preferences for the DNxHDs. (RedAlert did this well with the RSXes.)

Thank you alot for your help, Michael, I really appreciate it.

Greetings from Northern Ireland,

Moritz
 
REDCINE-X should transcode all color settings to DNxHD as you have set in the viewer and application. Keep in mind that DNxHD being an HD format works on the SMPTE "constrained" 16-235 (8bit values). While you can cheat and work in full range for REC709 color space, your hardware downstream may crop or scale these values giving you a different looking image. In v5 of Media Composer, the histogram adds white bars for you to use all of RED's color parameters to bring into that range. I hope that RED adds a similar approach to REDCINE-X's histogram.

If you continue working full range, there is a SMPTE constrain check box in REDCINE-X to take a full range 0-255 and scale it to 16-235.

So.. REDCINE-X should deal with all your color choices, white balance, etc. when transcoding you can choose to have it scale to SMPTE.

Michael
 
So with that, every problem is ruled out and hearing the news the dop was very happy.

Which of course made me happy, too.

Thanks again!

Cheers,

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