You meant to say "And we're talking .02
frames every second." It's really .024 frames every second, because Appletalk 23.98 fps is really NTSC 23.976 fps. So we're talking .001 sec every second which becomes noticeable to sharp observers after about 20 seconds.
If someone's talking or chopping wood etc., and shot with two cameras, one at 24 fps and the other at 23.976 fps, and your two-camera edit has the sound recorded on one camera running with the picture recorded on the other, you can maintain decent synch for just about 20 seconds. So if your editing is quicker than three cuts per minute, you can ignore speed difference, though you still must re-establish synch as you cut from camera to camera. If the sound was recorded by a third device, you can modify its speed to midway between the two cameras' in order to double your synch maintenance time.
If what you call speed conversion is just "conforming" it can't help at all. If one camera shot 999 frames during a sequence of axe chops, while the other camera shot 1000 frames for the exact same event, this difference doesn't go away on any timeline so long as all the frames survive intact. To really convert the 23.976 fps footage to 24 fps footage you must augment the 999 frames to 1000 frames. Repeating every 999th frame looks a little funny, but it does the job. Or do the opposite conversion by deleting every 1000th frame from the 24 fps footage. A one frame hiatus looks a little funny too, but does the job. In Compressor such rate conversions are called "Fast (Nearest frame)".
Alternatively you can apply "optical flow" speed conversion in either direction. I believe FCP-X can do this, but don't know its quality. See the old strand [
www.lafcpug.org]. Compressor and Motion can do it, with sometimes disappointing quality. Twixtor used to be best, but read Andreas Kiel's wise words in the linked strand.
Dennis Couzin
Berlin, Germany