Vegas expresses them as a percentage of the total DV frame.
Are you certain you're working with 14:9, to the best of my knowledge that's not a transmission standard. It is used a bit with TVCs by fitting a 14:9 frame inside a 4:3 frame so things look ok in both 16:9 and 4:3.
Yeah, it was shot on HDV, and I'm cutting in 16:9, but here in New Zealand the uptake on widescreen sets is low because the broadcasters want to please the majority so are still transmitting a 4:3 image. Chicken and egg. They also dislike screening letterboxed content so insist that all 16:9 is ARC'd to 14:9 as a half-baked compromise. I hate it, but those are the delivery standards.
So cutting in 16:9 I have to protect the titles for 14:9 tx and need to know the appropriate numbers to stick in Vegas to make the title-safe guides show appropriately. Any advice on those figuires very welcome.
20% on the sides and 10% top and bottom should be pretty safe.
Easy enough to set that up in Vegas. Set action safe to 10% and title safe to 20%.
My reasoning is they'll crop a bit off the sides and none off the top, 15% is sort of the norm for for title safe but in this case you're loosing less off the top and more off the sides.
If anyone needs to know about 14:9 title safe areas with some authority see the following link. They have downloadable PSD files with heaps of info in the layers displaying 16:9 / 14:9 / 4:3 title and action safe areas, clipping, cropping etc.
You simply select the layers you need, export a transparent PNG and whack it on the timeline in Vegas to give you BBC specification title and action safe areas for just about any format under the sun.
Thanks to the Beeb - nothing like nine billion pounds of funding every year to solve a few technical problems!!
Thanks so much for that link. I've downloaded all those charts but then I had this horrible sinking feeling. Vegas has it wrong, assuming I can believe the BBC.
According to them in square pixels a 4:3 PAL frame is 788x576.
Yet for some reason Vegas thinks it's 787x576.
Now one might think one little pixie is neither here nor there but it's a huge difference when you're trying to match things, like a snapshot from the Vegas T/L back into the Vegas T/L. Man does this explain a lot of the grief I've had over the years.
The reason why Vegas thinks it is 787x576 has been discussed in great detail, or at least it was back in the Sonic Foundry days. It turned out that Sonic Foundry have better mathematicians and engineers than the BBC, in this instance.
787x576 is a more accurate way to round the figures. Or at least, I believed the justification that was made at the time. I think it stems from the rounding of the aspect ratio used in the sum rather than any rounding of the 'result'.
Square pixels can also be calculated with the height being adjusted instead. Which you use can depend on the scene in question.
I'd say that if Sonic Foundry have this wrong, or if this science is only pertinent inside Vegas (with it's PAR setting) then proceed with 787 with caution. As I said, it was all dragged up a long time ago and Sonic Foundry were found to be correct. At least for DV and D1 projects.
I too do recall some discussion about this and there's always been a couple of things that made me far from certain about it:
1) I can't think of any other dimension in video land that's an odd number. Is this just coincidence or is there some technical reason for this, damned if I know. However some specs specifically state there must be an even number of pixels above and to the sides of the centre and that means an even number of pixels. Even the classic quad split doesn't work out quite right.
2) Take a snapshot and use it as a menu background in DVDA and the image 'jumps', I'd assumed this had something to do with going from interlaced to progressive but now...
Well I just checked this and guess what, DVDA reckons the PAL frame is 786x576 !!! Now I know SCS didn't write DVDA but surely, surely they could have dropped a little note to the guys that did!
Odd numbers aren't typical and by the same account, with another spec to throw in - the timing for 704x576 is often the reference for standard def. This is from a different historical origin and for it's attributes where 16x16 macroblocks work better without cropping or stuffing.
The info held in a DVD-Video, or standard def digital format should not really ever be square pixel though. At some point in the procedure the correct proportions from the non-video application are going to be squished, averaged or deleted horizontally in this example to make 720 (or 704 or 352) rectangular shaped pixels.
The Toronto folks may have simply taken the Adobe/BBC approach to how many digits are in the PAL aspect ratio size multiplier.
One further option is to complain to your compositor or art program's author that you want selectable PAR support in preview that will be conveyed when you export/render the original out.
Bob, when you say "jumps" in DVDA, can you explain further? Like an analog vertical sync issue 'jump'?
PAL and 50Hz is such a unloved engineering philosophy. There are 100Hz LCD and CRT TVs and yet you'd have thought they'd be advertised as 100/120Hz TVs to cater for the various PAL60 and HiDef-60i materials that are readily available in the modern home. Also with HDV, panasonic P2 and AVCHD compression formats, given that HD uses the same resolutions groupings the world over it would seem fitting that 25p, 50p and 50i formats would be of higher quality for the same bitrate as the 50Hz is clearly pushing the compressor less hard than it's 59.94Hz cousin. Clearly if it is, then it isn't noticable enough for reviewers to pass comment, or at least not often if at all. It would be nice if us folks in afterthough-PAL land could select a lower bitrate for the same visual compression quality as 30p/59.94i and increase our storage or recording lengths by nearly 20%. Ho hum.
The secret to whether the 787 works better than 786 has to be determined by zooming in and looking for a tell tale error. Quite what pattern you'd use to spot this I'm not sure as whatever the figure is best being there is going to be a good number of pixels thrown or fuzzed through the PAR altering process.
If you render your assets, all of your assets in Vegas then what DVDA thinks of PAL doesn't matter too much. Of course some menu backgrounds are static, yet if you avoid static menus and enough of what you do use is in motion then it is likely you'll not see any issues with 787 vs 786.
As for video land numbers, well I'm hoping that we'll eventually go to powers-of-two resolutions like the digital film folks appear to prefer. Although the film fraternity are rather more crazy on their list of options for PAR.
What is it now, HD has something like 900 combinations of source/project aspect ratios to handle. That was a mentioned a few years back, I'm sure there are even more combinations of authentic video land source/project combinations now based on some of the more proprietary implementations.
Interesting points though. Especially about how DVDA may have a math/engineering difference to Vegas for standard def square pixel source format handling/recommendations.
Bob, when you say "jumps" in DVDA, can you explain further? Like an analog vertical sync issue 'jump'?
Here's the sort of things I used to do.
Build a menu in DVDA. Grab a still from that. Take that into Vegas and composite in some vision. Composited vision fades or whatever leaving just the original menu in the vision. This plays as an into into the real menu. Whole thing should be seamless but between the last frame of the intro and the menu the image shifts, just a tiny amount, no sync loss or anything hideous but just a jump in the size of things.
Of course with DVDA 4 I don't have to do that so the issue has gone away.
All that I'm left with is another way more serious problem.
DVDA 4 creates text highlights at 4:3 when it authors 16:9 PAL DVDs!
Except due to the way the flags work if you view it on a 16:9 monitor it looks just fine. Switch to a 4:3 monitor with the DVD player set to correctly letterbox and there it is. I guess I've authored DVDs that have resulted in around 10,000 duplicates out there with this bug in them.
As for the discussion about bitrates and framerates, I'm not so certain. No one ever seems to have able to decide if a lower frame rate need less bandwidth for temporal compression. Lower fps means more motion between the frames, which ones wins out or if either do seems to be anyones guess.