Audio loses sync after separating fields

[AQUAR]

@ Jan it was to hot (temperature wise!) for me to finish my thought so here is part 2.

First though, when you play back the .ts in ADM you will see that there is combing, because the two fields are coming from 2 progressive frames that of course have a different instance in time. Thus the recording/capturing is interlaced and the source is progressive (being computer generated graphics?).
This is different than splitting a progressive frame into 2 fields for interlaced storage, here playback in ADM will simply weave the fields back together for full recovery of the progressive frames (no combing). Doesn't matter if the console outputs 30 progressive frames per second interlaced format or 30 progressive frames per second progressive format (in this case!).
There doesn't seem to be other processes taking place like field shifting or telecining to suit NTSC transmission but not sure about that.
Hence I was curious as to what does this game console actually output.
I think you are right in saying that its some analogue NTSC transmission but is it standard?

Anyway if the game outputs 30 progressive frames per second (interlaced or not) my maths is out by a factor of 2 (since we get 60 fps).

Using dgbob mode=1 order=1 threshold=0 gives 60 frames per second, as it should (given what is contained in the .ts).
The steps in the process of the OP are essentially the same as the steps used by dgbob, but it results in a frame rate of 120 fps and gets resampled back to 60 fps. Again the maths is out by a factor of 2 given what is taking place.

Question is - what am I missing? (update I'll try and answer myself!!)
- ADM writing the wrong meta data because it confuses field rates with frame rates for interlaced material!
   Does the frame resampling actually take place or is it a do nothing other than to change fps meta data?
- What is the game console creating in terms of the 240P specification.
  I think its progressive frames with a SAR of 360 x 240 @ 60 fps that are packaged as NTSC interlaced @ 30 fps.
  Its non standard NTSC in terms of extra wide "analogue pixels" . These are sampled twice by the capture device
  to give a digital frame with a SAR of 720 x 480i @ 30 fps. That just leaves scaling for a 4:3 DAR on pc monitors.   

I should really compare the dgbob product with the OP product and see if there is a difference with and without the fps resampling.
Anyway it kind of makes sense to me now and I learned a new thing "transparency by flickering".

[modoversus]

I hope this does not confuse things further, but in theory, all older game consoles output 240p at 60 fps progressive. My TS file shows in property as 29 FPS, but when recording, there is a setting in El Gato Gamecapture HD that I select labeled "Enable 60 fps recording". This video was recorded from a NTSC Sega Saturn console, if that helps somehow.

Also the screen resolution that the game console is working on should be 720x240p at 60fps, but when shown on a standard definition TV or monitor, it fills the screen by alternating between drawing a line of the game display and then an empty black line. By alternating black lines and lines of the game display image,  it achieves complete 480 lines of resolution. 

I assume that by separating fields, we obtain the real progressive frame as it was created by the game console. Then it is necessary to scale it to 480 as we do not have scanlines to fill the other half of the screen resolution.

[AQUAR]

@ modoversus

Thanks for that.
Part of that is entirely consistent with what I deduced from the video stream in the transport file.
The theory thus seems to fit the reality.

Something for you to consider:
TV's from the analogue era only work with interlaced signals (NTSC or PAL).
The screen pixels on these displays are defined as a section of a scan line (kind of virtual pixels shaped by scan line frequency and number).
The composite video output of the game console is an NTSC signal with a Display Aspect Ratio (DAR) of 4:3.
The capture process actually records that the DAR is 4:3 in the meta data of the .ts.
As you said - the content of those virtual pixels comes from "weaving" together 2 progressive digital frames (if you like the second frame fills in the black scan lines left after painting with the first frame!).
These digital frames have a Stored Aspect Ratio (SAR) of 360:240 (note SAR not DAR).
The conversion from digital to analogue translates that to 720x480 virtual pixels and because virtual pixels (TV pixels) aren't square pixels that in turn translates to a DAR of 4:3.

Straight up, the 720x480 capture (analogue to digital) is not a DAR match for digital PC monitors, as these have square pixels.
You have to take note of that DAR meta data if DAR is to be preserved on a digital PC monitor.
That requires resampling the "new" progressive frames to suit (eg to 640X480).
If you don't the final picture will have a DAR of 3:2 (round things no longer look round!).
You should only resample after deinterlacing (or on the separated fields!) else it will be a mess.

The transparency effect on the PC monitor is also not entirely to same as when using a TV as display (TV = smoother).

Hope that helps explain a bit how I perceive the 640 from 720 from 360 (its crazy!).
These are just my thoughts and as I am no expert I may well have it all wrong.

Do try the Dgbob filter and see if it works.

[modoversus]

Aquar, I tried Dgbob as you suggested, and while the image looks very colorful and sharp (better than what I end with the method I am using), there are interlacing effects (see attached screenshot), and the motion feels less smooth. What would you suggest be a good setting to us with Dgbob?

Straight up, the 720x480 capture (analogue to digital) is not a DAR match for digital PC monitors, as these have square pixels.
You have to take note of that DAR meta data if DAR is to be preserved on a digital PC monitor.
That requires resampling the "new" progressive frames to suit (eg to 640X480).
If you don't the final picture will have a DAR of 3:2 (round things no longer look round!).
You should only resample after deinterlacing (or on the separated fields!) else it will be a mess.

This certainly matches what I have heard about anologue to digital video. Can you please suggest me a way to achieve this in Avidemux?

[AQUAR]

Its like that because you're combining 2 "progressive" fields to try and create a single progressive frame (wrong approach for your objective).
Is this combing in moving parts throughout? If so, then you are just weaving these two fields together.
You have to treat that 240P capture as true interlaced video (as opposed to telecined film for example).
Meaning you are required to de-interlace and Dgbob has various settings to taylor the process of deinterlacing.

Some interlaced video has 2 fields holding one progressive frame (eg film to video @ 24 fps).
Weaving works great for that type of interlaced video.
The console output isn't like that, it holds 2 progressive frames (not standard but allowed for consumer grade devices, I believe).

I tried the .TS sample you provided with dgbob mode=1 order=1 threshold=0.
That way you get "360 x 240 game pixels" (from a field) plus "360 x240" black pixels that are filled in by interpolation.
The interpolation with these settings are constrained by only looking at the nearest "game pixels" in that field.
And each field is treated that way as opposed to only half the fields (hence the doubling of frame rate from 30 to 60 fps).

If you use smarter de-interlacing then you may loose the transparency effect because of blending the rainbow present in one field and rainbow not present in the next (not verified if that happens!).

Try Dgbob with:
tick in in top field first
mode: double nb of frames and fps
threshold set to 0
no tick in extra

Downscale to 640x480 by using the swscale resizer filter.
(use after the Dgbob filter)
Something else - the 720 pixels wide may well include overscan (unseen "pixels" on the TV / black vertical borders in the capture).
Might want to investigate cropping any vertical black borders before rescaling.