[Bram Tulloch]

Good to see this fixed your problems.

I’ve just moved over to CS4 and 4.1.1 Xena drivers.

Mixed results.
Had many stability problems with 4.1.1 on all formats (SD PAL, HD 23.98, 24 and 25)

Moved back to the 4.1.0 driver and now everything seems happy again.

Problems I was finding were crashes when attempting to export out an AJA quicktime (yes I used the AJA quicktime exporter). Problems where my timecode offset when capturing would randomly change (usually it would be set at 1 frame offset, but then suddenly I’d have to change it to 5 frames) to get a frame accurate capture.

Also when capturing SD pal, if I clicked off Premiere during capture, then back on again, it would crash. It once even told me to “restart Xena driver”.

So back to 4.1.0 and haven’t had those problems again.

Bram

[Bram Tulloch]

Indeed. I got the QT Pro and have converted and rendered some files. They look very bad, almost out of focus.

If I’m understanding this thread correctly, you’re now exporting from quicktime pro to a dvcpro codec?

If it looks like crap when you do this, you can fix this very easily.
The quicktime file itself is fine.

Try this:
Open the “very bad” quicktimes.
Click Window>> Show Movie Properties
Click on the Video track to highlight it
click on the “Visual Settings” tab
Check the “High Quality” box in the right hand bottom corner.

It should look instantly better.
Now just “save” that and you’re good to go.

This happens to us all the time when we are asked to provide DV PAL quicktimes.

Hope this helps and I’m understanding your problem correctly

[Bram Tulloch]

Hey Ramona

There’s no doubt it’s a great product and I’m aware that it’s an application issue, or AJA’s integration with the application.

I guess my question was more workflow based and it certainly wasn’t implying the AJA was no good. A lot of what we do in my company can allow for illegal values and that suits us just fine, but occassionally we have to make sure stuff is legal and so I just wanted to work out the best (read: easiest) way to do that.

Thanks
Bram

[Bram Tulloch]

Thanks for the responses.
I forgot about Episode. We have taken a look at it and it does look the most likely.
I love the idea of the compressHD card but with all the cards in our current machines (AJA Xena, Fibre channel card etc) I don’t think we have any more room!

Biggest problem we have is a lack of funding at the moment so Episode is probably out of the question for now. Might have to plod along with Cleaner until the bugs we’re seeing become more of a problem.

Daniel, when you say Autodesk will never make a “significant” update to Cleaner, are you suggesting there may be a small update? Like something that will make it work on a 64-bit OS or something? Or perhaps that’s not a “small” change?

We really like Cleaner. It’s old and it’s probably a little slow, but it never lets us down.

[Bram Tulloch]

I should also specify that we are also keen on “multi-pass” for our H.264 to help the quality and minimize files sizes.

We use Premiere CS3 but that doesn’t support multi-pass for h.264 quicktimes.

We’ll be upgrading to CS4 shortly. Doesn’t Adobe Media Encoder CS4 do multi-pass h.264 .movs?

[Bram Tulloch]

Well, no ideas here so I found a goofy work around myself.

Played the material out to tape with it’s illegal range.

Captured the material back in but in an RGB format (i.e. Not YUV)

Set the Xena output to CGR and since the material is now RGB, it now displayed legally.

Annoying work around but… it works.

Bram

[Bram Tulloch]

My first reaction to this is regarding your statement “These problems do not arise using Premiere Pro CS3 on the same system using the 3.5 drivers.”

Might be a silly question, but you aren’t running both drivers at the same time are you?

If not (and I’m not even sure if you can!), you’re uninstalling the 3.5 drivers properly before installing the 4.1.1 drivers? It seems to me like a driver or codec problem you’re having. What’s your project set up? Is it rendering to a quicktime format in an AJA Xena preset? If so, the release notes state you need quicktime 7.6. Maybe this is your problem?

I haven’t seen this problem but I am shortly going to be updating to a similar set up to yours (I’m currently running CS3 on Server 2008) so I’ll be following this thread with interest.

hope this helps.

[Bram Tulloch]

I know that the Xena2k and the Kona3 are exactly the same.
I’m using a “Kona3” as a Xena2k right now.

I would assume it would be the same for the LHe.

[Bram Tulloch]

It’s luminance that’s the problem. On both the low end and the high end.

This stuff isn’t going to a colourist unfortunately. It’s directly from a Nuke artist and it was made for a film output. The conversion from FILM LOG to video REC709, I assume, is just substituting like for like values and not really scaling to legal SMPTE values.

I don’t believe that clipping the top and bottom end affects the “aesthetic of the image”, mostly (dangerous comment but I don’t want to get into a debate over that, I just need some kind of answer about my original question! 🙂 ), but I know what you mean. Although there are differences you can see, I don’t believe the image as a whole is compromised. Going from film to video means a compromise has to happen at some point!

If this was a project that was being paid for, then yes, I would have a colourist check it out, but in this case, I simply need to know that the values that make it to tape are legal. Obviously, if we’re not happy with the results of a “quick fix” then we’ll re-address the offending clips, but if we think the result is acceptable using a hardware scale, then that’s what we want to do.

Any ideas? 😉

Thanks
Bram

[Bram Tulloch]

I guess no one has any ideas with regards to this?

We’re really trying to avoid having to go back to the source material and re-edit them back into the showreel.

Any ideas or advice would be much appreciated. Even if it’s a suggestion of an external box which may fit the bill?

thanks
Bram