[Scummvm-tracker] [ScummVM] #9580: SCI: Bad AV sync in some VMDs

[Colin Snover]

#9580: SCI: Bad AV sync in some VMDs
----------------------+-------------------------
  Reporter:  csnover  |      Owner:
      Type:  defect   |     Status:  new
  Priority:  normal   |  Component:  Engine: SCI
Resolution:           |   Keywords:  sci32
      Game:           |
----------------------+-------------------------

Comment (by csnover):

 As it turns out, not quite as “confirmed” as I initially thought. (Note to
 self, don’t rely on Let’s Play videos as an exclusive source to determine
 bugginess!)

 The 1.1 version of GK2 from GOG has mostly (~80%) different VMDs than the
 1.00 release, and these videos do not exhibit any of the serious AV sync
 problems seen in ffmpeg with the 1.00 videos. So it seems that the assets
 in the original release of GK2 are, in fact, broken, and were re-encoded
 for future releases.

 Comparative analysis of some known bad & known good videos (bad videos are
 1.00):

 7180.VMD header differences

 ||=field=||=1.00=||=1.1=||
 ||video codec||0x7F24||0x7724||
 ||sound slice size||0xF76A||0xF763||
 ||sound slice count||0xE||0x1D||
 ||frame table offset||0x33727C6||0x3372672||

 20.VMD header differences

 ||=field=||=1.00=||=1.1=||
 ||audio sample rate||22050||22222||

 Phant1 videos don’t actually seem to be affected in this way; it looks
 like there were probably some unrelated issues with the VMD playback code
 affecting Phant1 that have since been fixed.

 Now, speculations on what might be used to fix the 1.00 videos:

 The different audio rate in 1.1 20.VMD makes me wonder if perhaps the
 audio sample rate of these bad 1.00 videos isn’t right, and should be
 overridden to
 [https://wiki.multimedia.cx/index.php?title=PCM#DOS.2FWindows 22222Hz] or
 22157Hz (a magic number I found in some of the VMD code). I am not sure
 what the ramifications for the decoder would be if this is the problem
 since I would imagine that there would not be enough audio data in the
 frame data to keep up, and we would need to steal audio from future
 frames. I guess we’ll find out…

--
Ticket URL: <https://bugs.scummvm.org/ticket/9580#comment:3>
ScummVM <https://bugs.scummvm.org>
ScummVM