Woah!! Thanks bill, down & dirty i guess! can anyone for the love of GOD suggest the best NLE to stick with the rest of our lives to edit with the EX1, for richer for poor, yada yada....

Ive read that PP CS3 Maintains source integrity with support for 10-bit video and 16-bit PSD files & a 32bit flot render engine. But i guess PP CS3 cuts slow & isnt as ready as Vegas8 for the EX1 files!

All of my EX1 footage gets cut in Vegas Pro 8.0b, not problems at all. Aside from the camera's two audio tracks I also may have another 4 track of BWF from my field recorder. Sync it once and I'm good to go. Cut, mix and do everything on the one timeline, and with a quad core CPU and 2GB of RAM it's all pretty smooth now even with a few audio FXs going on.

About the only thing I'd agree with Bill on is that 32bit FP is a render hog for precious little gain but that's true in any NLE. The other nice thing about Vegas compared to some other choices is it will not clip your super whites, you're left to do with them what you will.

I believe the "it will not clip your super whites" statement, in reference to vegas, is arguable. Clipping of the superwhites is the result of the fact that many cams, including the EX1, record data above RGB235 and below RGB16. It's incumbent on the editor to:
1- set his/her RGB values correctly
2-make sure the NLE handles the transformation to NTSC RGB properly, i.e. remap the values rather than clip them. In this regard, use of a knee in the gamma correction curve is more appropriate than applying some "legacy" correction factor, which in all likelihood, clips rather than remaps.

So, as usual, it's operator error if your NLE clips superwhites. Vegas is more prone to operator error than "the other NLE's" you refer to, in this regard, because the scopes and preview windows don't operate correctly. Most other NLE's set the values automatically. Inherent in automatic(re: brainless) operation is overlooked errors.

In point of fact, the REAL culprit(s) are the codec software writers. Every codec handles the luma transformation differently, and the way the preview window works, you never see the final output on the preview window. It remains for the editor to do a test render of the footage with all the right codecs, to determine if superwhites will be clipped, or not. I submit to you that Sony Vegas does NOT show the proper final picture in their "preview" window, with regard to luma values. This is a flat incorrect mode of operation. For Vegas to handle this entire mess correctly, it should "sense" which codec you're going to render to and display the RENDERED luma values in the image. Curiously, the PROJECT SETTINGS do NOT allow selection of the codec being used.

For everyone's sake, I won't even go into whether REC601 to REC709 chroma transformations are being done right.

Piotr,

I think they were referring to full HD as being 1080p, not 1080i.

Ok, PAL user here but isn't this HD/rec. 709 to do away with the 16/235 limitations from SD rec. 601 (for NTSC only)?

Tell me if I'm wrong, please.

George/

George...

Perhaps my use of the term "NTSC" is misleading. I'm trying to avoid using Sony's term "studio RGB". It's a fact that TV phosphors are capable of displaying RGB16-235 only, and will clip any values above or below these levels. while computer monitors can display the full gamut of RGB 0-255. "Broadcast" is probably a better term than NTSC, my apologies.

No Bill it's not you, it's me. I'm mixing stuff up here.

I'm going home to clear my head.

George/

so what on earth would diplay the mess im doing with my cut on my monitor correctly? hook it up to a broadcast monitor via component throuhg something like blackmagic etc?

Bill i think your right there with the colors not being 100% accurate in Vegas, it seems that my panasonic tube interlace TV doesnt like the DVDs i make from Vegas8.

EX1 at 59.9 fps, down to 30p NTSC, edit CC, output to 'DVD atchitect 30p DVD file', burn a DVD with nero, Bang! does look sharp & clean, but it strains everyones eyes to watch my videos, but spiderman dvd looks great on my TV!!

whos the culprit here, Vegas8, color space, framerate, CC or ME?

There is a slight "problem" in MPEG2 codec(at least the Mainconcept variety) that most people don't seem to know about. MPEG2 is the codec that is used to burn DVD's. The MPEG2 codec expects a Broadcast Level input, i.e. RGB 16-235. If you encode with a signal that is RGB 0-255, you'll get an RGB 16-235 signal out, and, you'll truncate or clip any info above RGB235 and below RGB16. The resultant MPEG2 output will look washed out and low contrast, with mushy blacks and blown out whites. WMV, on the other hand, will pass thru whatever input signal you give it. So, feed WMV an RGB0-255 signal and you'll get an RGB0-255 signal out. (credit to Glenn Chan for his white paper describing this issue http://www.glennchan.info/articles/v...or/v8color.htm )

The only way I've ever been able to definitavely track the conversion in a codec is to carry along a 2-pop. If the pluge bars in the 2-pop look right after I've rendered, I know the encoding was done correctly.

As for using a broadcast TV for display, before you can judge the TV picture, be very sure you're TV set has been calibrated with an NTSC color chart, especially the pluge levels. I notice you live in the Maldives. Not sure if you're NTSC there, but, most commercial DVD players also add "setup" or "pedestal" to their playback. This will change your black levels, too, and it needs to be accounted for when you render out.

What's a 2-pop?

the wiki is your friend...
http://en.wikipedia.org/wiki/Bars_and_tone

Thanks ! Google was bringing up all sorts of piping hardware.

The mpeg-2 encoder will not clip, clamp or do anything to your levels. Encode a 0-235 ramp to mpeg-2 and bring it back, check with scopes. Result is the same as what went into the encoder.
DVD players do generally clamp to legal levels, at least on their composite outputs.

You mean 0-255, Bob?

This is my experience, too. As long as you don't fool with 32bit, the output of Vegas MPEG-2 encoding is identical to the input. I can only agree with what Bill is saying about the preview window, not showing the right space with HDV (or EX's mxf) in 8bit projects. But there are ways to configure the external (secondary) monitor to make for that, too.

PS. Of course this is not to say the same cannot be achieved with 32bit processing; one just needs to know what he's doing, and have plenty of time and/or a very fast CPU...

Yes, my bad.