What's up with VCDimager, exactly?

[vitualis]

If VCDImager and MPLEX share a common codebase, that code in some way is implicated in the sync drift observed using either program.

That would be true but I don't think they do.

However, NTSC-FILM is a compliant VCD framerate and to the extent that VCDImager is designed to compile both kinds of disc, the underlying problem remains the same.

Until MPLEX is fixed, VCDImager will be broken.

VCDImager doesn't do any multiplexing so I think your assumption is incorrect.

This is evidenced by the fact that the bbMPEG multiplex stream works.

Furthermore, I've made several NTSC-FILM VCDs (compliant settings) and I have not had a problem at all.

Regards.

[kinneera]

The NTSC-FILM field rate is equivalent to the frame rate: 23.976fps in both cases. Progressive encoding is atomic: there are no "fields" per se, so breaking the picture in two for the purpose of display-rate matching is impossible from the decoder's point of view.

Not true, I'm afraid. Progressive frames don't (and shouldn't) cause the decoder any problem, otherwise there would be no reason for the pulldown flag's existence. Many DVDs are encoded in this fashion (progressive with pulldown flag), and the decoder is well-equipped to decode an entire progressive frame at once. I have authored progressive video at both 23.976 and 29.97 fps, and it played back just fine.

Rather than repeating fields it repeats entire frames, outputting them at the nominal frame rate (29.97fps) until the decode buffer is saturated and it literally has no idea what to do next, so the entire system breaks down in an unpredictable way.

Repeating frames is exactly what it is supposed to do. It repeats every 4th frame, converting 4 fields to 5, and thus 24 to 30 (obviously adjusted for the slight NTSC timing inconsistencies). Fields are independent of the framerate, and it would be nonsensical to repeat fields in any sense. Progressive video at 23.976 fps and interlaced at 23.976 are still the same framerate, its just that one splits the image into two fields and plays them with a miniscule time offset, but still fast enough that you get (hold on to your seat here) 23.976 frames per second!

But since I coded them as progressive, i.e., zigzag scanning, they were presented to the decoder wholistically upon reconstruction and it failed because it didn't know how to handle that (admittedly perverse) case.

I encode my movies with zigzag scanning and apply the pulldown utility to them without problems. I don't honestly know what's going wrong for you, though.

[KoalaBear]

Kinneera, you rabble-rouser, you. :)

Whether I happen to be correct or not in this case is irrelevant because it's sheer speculation. Take it at face value or ignore it completely, because it's not worth the effort to either investigate or debate.