When playing the opening cinematic in Rayman, there are moments where the CD track appears to pause for 1 or 2 seconds, while the video continues on. This causes a noticeable desync between the audio and video. The moments where the audio pauses is consistent every time the cinematic is played. A friend with a real machine tested this and this audio desync does not occur there.
Note that the CPU selected does affect the playback of the cutscene, with the game detecting the CPU and limiting the framerate for anything below a Pentium. The bug occurs regardless of what CPU is selected in DOSBox and the framerate of the cutscene.
The game deliberately pauses CDDA playback four times during the intial cinematic cutscene.
See the attached, and search for "state=paused". Of the four pauses, the first two and last pauses are extremely short (on my system), however the third pause is roughly 2 seconds and is very noticeable.
The duration of these pauses might be progammatically controlled by game logic attempting to synchonize the disparate CDDA stream against the video stream. No doubt some form of pacing would be needed given the physical variations in how quick or slow some CDROMs could seek / start / stop / resume playback (especially if the disk had spun-down).
Of course, DOSBox performs these CDROM fuctions without any delay, so perhaps we're seeing the cummulative "benefit" of zero delay adding up - such that the audio eventually runs ahead by roughly 2 seconds and the game compensates by pausing it. Just a guess though..
Interestingly, after compiling DOSBox myself (following the MSVC guide on the Wiki), the cutscene actually plays (more) correctly on my own build, even with no edits, with only one very short pause, and remains in sync with the video. On other builds, with the pauses, the cutscene is clearly desynced. So somewhere the logic behind deciding how long to pause the track is failing; since on an actual DOS machine it is known to work I would assume the error is in DOSBox (either that or the game isn't equipped to deal with a low delay, which I feel is less likely).
Last edit: RibShark 2019-07-30