Considering it's about 2 AM in the morning it's a bit rich expecting one of the Sony guys to be awake, after all they do have a day job, and unlike posting here it's one they get paid for.

I'm not 100% certain though that I understand what your problem is. Maybe because I've never had a problem with field order and I don't quite see how I'd ever get one either although I know there are some apps that render in the wrong order I've never used one to have to address the problem.

With regard to DVDs I THINK they're encoded as frames so field order is irrelevant. The player splits the frames into fields on playback. That's only a theory though as it would seem more bandwidth economical to do that and everything mpeg-2 talks about frames not fields.

Now maybe the encoder when reading the source file can be told which field is which just in case, so if your source is uff then it reverses the field order so on playback it comes out lff.

Does that make any sense?

Why not do a quick experiment with a DVD-RW?

It' NOT that simple as descibed in the other thread by johnmeyer.
My project was about 64% finished when I read the post.
I stoped the project just to check johnmeyers method and gues what, jerky playback after test encode 20 sec clip which means wrong field order, and proves again that changing the field order in custom options in Vegas will NOT do the line shifting corectly.If the line shifting was corectly done in Vegas then seting tff interlaced in Procoder Express(or any other encoder) will result in smooth motion video and propper field order.
BUT,
doing exatly the same line shifting with AVIsynth (DoubeWeave.SellectOdd) script, results with smooth motion video and propper field order, again the same settings in Procoder(tff,interlaced).
To make the long story short THIS IS NOT WORKING PROPPERLY IN VEGAS.
Another bug or "feature in DVD-A" is recompress video and why is happening to so many people.
SoFo or Sony expert recomendations " if you go with default settings in Vegas or DVD-A, or choose default presets you"ll be fine" are just too demanding for me(read : do it in this way or else).
One of the reasons why DVD-A wants to recompress video is this:
If you audio is only 100 miliseconds longer than the video DVD-A will want to recompres the video,why>? to match the video with the audio(sync).
Example:
Last night I dont know how it happend, render video PAL DV AVI template came out:
00:51:21:22, and the audio 48 kHz stereo 16 bit came out 00:51:22:22.
After full transcoding stereo to 5.1(Ambisonic Method) and importing the files
in DVD-A(video+ac3) DVD-A wants to recompress the video.
After adjusting the audio lenght retranscoding (againg the same procedure) to match the video, everything is fine in DVD-A and NO warning messages.
I'm just wondering why they've implemented such feature in DVD-A,all of the other DVD Authoring apps are not recompresing video.Please include in the list of the DVD Authoring apps these:
Sonic Scenarist
ReelDVD
DVDMaestro
Ulead DVD Workshop/Movie Factory
DVDLab......
an so on
Anyway I've sorted all out and the DVD Disk came out with briliant quality,
I'm amazed, I've used other encoders but Procoder Express , oh man,
just perfect.
Thanks for the reply farss,

AudioIvan

I think part of the problem with DVDA is they've released a simplistic program to a mostly highly educated user base. One of the other issues I've had with DVDA is it cannot handle elemental streams. I had about 20 DVDs already mastered as streams but the audio tracks have an offset from the video, the multiplexer should be able to handle this but it cannot.
Now the problem then became that this audio was ac3 stereo and after being accused of being a pirate and other suhc nonsense I found the only way I could make DVDs from these files was to run the ac3 through BeSweet to convert back to wav, dial in the offsets and then encode back to ac3 so DVDA would be happy.

For the price DVDA is OK but I think Vegas users are in general a bit more sophisticated than where they targeted the product.

As for your field dominance problem I'll have a further look into it, I'd like to get some input from some of the experts on this, maybe your problem was more complex than we though because I'm certain more than a few people have had to cope with media with the wrong field order and Vegas has coped OK. I'm not certain what the "Double Weave' setting in AviSynth is doing, it sounds like more than just reversing the field order.

CCE Basic was my primary encoder until i bought Procoder Express.
So, DV it's always bff(interlaced) unless you've got progressive cam.
After editing I export(render as) DV-AVI default template, no audio.
About CCE from Doom9 forum:

"What's the deal with the "Upper Field First" option in CCE? I heard it has a bug?

The confusion about this option arises from that it works different from what you think. Naturally, you'd think that you set this option according to the field order of the video to be encoded, that is, deactivate it if source is bff (bottom field first) and activate it if source is tff (top field first). However, when you do this the encoded video plays back jerky with artifacts typical for incorrect field order.

So how do we set it right? First, you have to know that CCE (SP as well as Basic) always outputs video that is flagged "top field first" (there is a flag in the MPEG header that tells the player which field of the decoded frame to display first on a TV screen). There is no way in CCE to change this. According to Custom Technology, this is not a bug but a feature of CCE... Actually what happens if you check "Upper Field First" is that CCE assumes that source is bff and converts it to tff so it complies with the always set tff flag. It does so by shifting each frame up by one line, ensuring that the previously bottom fields are now top fields and the video is played back correctly. This is not the most sophisticated way to handle the situation, but it works and you won't notice the missing line at the top.

So here is the rule of thumb: Always uncheck "Upper Field First" unless your video is interlaced AND bottom field first. Progressive material is always top field first.

If for some reason you want to encode bff video without that line shift, there are two ways to do this:

Frameserve bff video into CCE via AVISynth and convert it to tff "the right way". Here is a basic AVISynth script that does this:

AVISource("E:\Video\holiday.avi")
DoubleWeave.SelectOdd
Uncheck "Upper Field First" in CCE and encode.

Uncheck "Upper Field First" and encode bff video directly. Then use ReStream to clear the top field first flag in the MPV file CCE generated. Load the MPV into ReStream, uncheck "top field first" and click "Write!"."
About your audio,going back and reencoding again you lose quality,as with MPEG.
Oh, and I agree that DVD-A doesn't match the quality and sophistication of Vegas,it's like not mature enough.

AudioIvan

I'm now even more confused than ever I was.
Lets see if I've got this right.
I take a standard DV clip (bff) and encode to mpeg using CCE and it will set a flag that causes the decoder to send tff video to my TV. It does this by line shifting during encode. All should work OK as I don't think the TV will actually give a damn about this, it'll just display whatever it's given.

However you're not happy with this situation, you want to force it set the flag so that the decoder outputs bff to the TV, right?
Now the problem is that you've got to shift the lines before hand to compensate for what CCE will do., am I correct so far?

If I am then firstly I don't know why you'd want to do this, you seem to be assuming something is broken when it isn't and then have all sorts of trouble because you managed to break it in the process of fixing that which wasn't broken.

But be that as it may. I think you're right, Vegas will not do the conversion that you want. I'm not 100% certain about this but I think there's two not one variables to deal with.

Each frame has to be displayed in the same order that they were taken in like so: Camera record frames a,b,c,d and display device has to display frames a,b,c,d but they could get mixed up like b,a,d,c. That's one issue. However each frame only contains half the lines and in the previous example field "a" could contain all the even or the odd lines . Normally the first field contains even (or lower) lines and the second field the odd (or upper) lines. Now as I understand it Vegas can swap the field sequence i.e. convert from b,a,d,c to a,b,c,d BUT maybe what you need to do is keep field sequence the same but within each field shift the lines between odd and even.
I don't think Vegas can do this because there's never a need to do it normally.
I'd sure appreciate some input from someone who really knows what they're talking about because I'm guessing a lot of this and with PAL there's a lot of other issues although they don't affect DV so much (I think).