[Ramona Howard]

Gary is absolutely correct!

We added settings in Rave to handle to frame delays so that HD and SD could be in sync. This was internal coding, not a standard setting within the AJA hardware.

Cheers,
Ramona

[Ramona Howard]

Tom,

This requires an audio rate conversion, which is part of our 3.0 series for Rave, so yes this is very possible using AJA hardware and an app that supports it.

The difference is that Rave works with native DPX files.

Cheers,
Ramona
Rave information can be found at http://www.spectsoft.com

[Ramona Howard]

Rave uses the AJA boards and this is not an issue today (to both D5 and SR). We did have this same problem occurring for a short time (some time ago) but we reworked some deck ballistics code and it is dead on accurate everytime now for both print to tape (assembles and inserts) and inserts and assembles to Rave from other sources.

I make this point only to show that the hardware is excellent and that not all applications are equal. Accuracy is very possible, although quite complicated to get right 🙂

*Rave is a Linux based product that uses the AJA boards and is written entirely in house (drivers , machine control, the whole shabang).

Cheers,
Ramona

[Ramona Howard]

Paul,

AJA support is very helpful 🙂

Could this be a slot issue in regards to how the board is behaving?

We are spoiled in Linux land, many slots to choose from………

As far as conforming from an Avid EDL, that should be straight forward stuff, we do it all the time on Rave. I would break these two questions up and post the EDL part of the question on the FCP forum, you may get a quick response there.

Cheers,
Ramona

[Ramona Howard]

Hany,

Call AJA support, they will help you out. Does Autodesk not provide this kind of help?

Cheers,
Ramona

[Ramona Howard]

Gary,

I was trying to keep it as simple as possible and only explain what the standard was. See no marketing garb…..but since you asked, yes RP188 and RP215 allow us to do a variety of very tricky things that others may not. It is all about understanding the standard and pushing it to the limit, I think that it is what the guys in Hollywood (not all physically in LA) intendend 🙂 Tricky bunch, down there……

Add in (sorry can’t remember the standard number) also being able to pass metadata down an audio channel and this stuff gets even more confusing yet very interesting. Timecode. keyframes, lens info, etc…it’s all metadata and these standards are designed to push more than one.

It is about trying to understand it step by step and to not confuse what the applications can/cannot do, versus what the standards mean. Puts a bad taste in everyones mouth while adding to this crazy confusion (honestly, once you understand all the pieces it really isn’t that confusing).

Bottom line guys, FCP is a great editing program but there are lots of other tools in the box that use these standards fully. We are no exception. Like I said tricky bunch.

The HDCAM does support RP188 as I can’t think of an HD deck that does not but I have seen many SD decks that don’t.

Thanks Gary for the plug. Ha, off to Hollywood today.

Cheers,
Ramona

[Ramona Howard]

That is because more than likely the digibeta doesn’t support it.

I am sure there is information out there somewhere that states if it does/doesn’t.

Anytime on the help.

Cheers,
Ramona

[Ramona Howard]

If it were easy, everyone would do it 🙂

Try giving the SMPTE RP188 doc a read, then you will surely be confused. After that tackle the RP215…..

Here is the tag line:
Transmission of Time Code and Control Code in the Ancillary Data Space of a Digital Television Data Stream

By the way there are numerous was to pass timecode and ancillary data or more than one way to skin a cat.

Cheers,
Ramona

[Ramona Howard]

Boys,

Technically, RP188 is a SMPTE transmission standard

timecode can come via RP188 (embedded), you are correct. Most SD decks don’t support this, which is why I think the confusion is that it is just a HD thing.

Flagged frames are also passed via RP188, so yes it supports variable frame rates.

You both win a ribbon 🙂

Cheers,
Ramona

[Ramona Howard]

Yup, that’s why we recommend it. Makes for a smooth workflow between all platforms and applications. No messy codecs or better yet no worries about what is going on within those codecs 🙂

You know me, just stirring it up. Wording is very important.

> I do not think there is anything superior when we are talking about handling DPX frames within a Final Cut Pro timeline.

That is more reasonable than the first comment and can’t agree more 🙂

Even though this forum revolves around FCP, it is important for users to know that many solutions exist that use the AJA hardware AND not all are created equal, which is why I usually jump in. Wording, especially if it can be interpreted (which is pretty much everything) can lead people to think they are stuck or that it is the only solution, when in fact it is just the opposite. Clarity of information being shared is extremely important so as to not lend to the already wide spread confusion…..

FCP handling DPXs (natively) is very cool….now if only Avid would jump in, we would all have a much easier, well rounded workflow that translates well for both Film and television.

Cheers,
Ramona
Rave – Working natively with DPXs for 8 years