Opened 14 years ago

Closed 13 years ago

Last modified 12 months ago

#2260 closed defect (fixed)

SCUMM/SMUSH: out of sync

Reported by: SF/isaac_a_steiner Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game:

Description

the smush movies of DIG and FULL THROTTLE are out
of sync, about 1/4 second. English version.

Using 0.8.0CVS OCT 16 19:58:34, Win32

Was IN sync two weeks ago

Thx,
Isaac

Ticket imported from: #1327891. Ticket imported from: bugs/2260.

Change History (29)

comment:1 by sev-, 14 years ago

Weird. Nothing has changed in that area for a long time. Are
you sure nothing has changed in your system since that? Also
can you test with older version?

comment:2 by sev-, 14 years ago

Summary: smush out of syncSMUSH: out of sync

comment:3 by SF/isaac_a_steiner, 14 years ago

Okay, tested it with 0.7.1
Uncompressed files work okay, no sound with compressed
files.
Tested compressed files on another system, still out of sync

Maybe the compression tools changed?
Nothing changed on my system the past 2 months.

Thanks for you help.

Isaac
BTW: I was using the uncompress files two weeks ago

comment:4 by sev-, 14 years ago

Definitely. Tool has changed in 0.8.0. Please, recompress
and tell me the result if possible.

comment:5 by SF/isaac_a_steiner, 14 years ago

Is there a way to get the version number of
compress_scumm.exe?
I think I used the latest version.

MAny thanks,
Isaac

PS: Keep up the good work, everybody. We all appreciate
your work VERY highly

comment:6 by sev-, 14 years ago

I already see that you're using old tool. Modern name for it
is compress_scumm_sou. Please, get one in a daily CVS build.

comment:7 by SF/isaac_a_steiner, 14 years ago

Now I'm confused. compress_scumm_sou is used for
monster.sou, isn't it?
I was using compress_san dated Oct. 2 2005 for
compressing the *san (smush) files

Isaac

comment:8 by sev-, 14 years ago

Well, compress_san is correct tool. Though in your inital
report you say nothing about your .san files being
compressed, so we wasted few days, since I tested in on
original uncompressed data. Will test today later.

But my request is still valid. May you test with older
version of ScummVM to make sure it is really not your system
what brings this problem.

comment:9 by SF/isaac_a_steiner, 14 years ago

Sorry for the missunderstanding.
The only older version I have is 0.7.1. Compressed SAN
movies have no sound.
I tried an tried again; the problem is with the compressed
files only.
I know this isn't top priority; but it takes away a little fun.
MAny thanks,
Isaac

comment:10 by SF/isaac_a_steiner, 14 years ago

Sorry for the missunderstanding.
The only older version I have is 0.7.1. Compressed SAN
movies have no sound.
I tried an tried again; the problem is with the compressed
files only.
I know this isn't top priority; but it takes away a little fun.
MAny thanks,
Isaac

comment:11 by SF/isaac_a_steiner, 14 years ago

Please add CMI to the list. The smush movies are out of
sync when using compressed *.san files.

thx,
Isaac

comment:12 by SF/isaac_a_steiner, 14 years ago

Just to emphasise: I tested all 3 with 0.7.1 (the only "older"
version I have access to), and there is NO sound at all when
using compressed san-files.

Thx,
Isaac

comment:13 by SF/a60wattfish, 14 years ago

I am also experiencing this problem. I have managed to
narrow it down to a problem with compress_san.exe.

At the start of the intro on the compressed file it starts
playing the first note for a split second then starts again
and it's missed out the last 2 seconds of 2009_10.SAN,
although it has the full file length.

This occurs with both OGG and MP3 encoding.

comment:14 by SF/a60wattfish, 14 years ago

This problem is also noticable in COMI. The audio restarts
at the start of WRECKSAN.ogg.

It is also noticable in most of The Dig files. Most notably
ALCOVE, ASSTUN, TRAM1, TRAM2, TRAM3, TRAM4, TRAM5 and
probably several more.

comment:15 by aquadran, 14 years ago

what is a system (hardware) are you running scummvm on ?
Most propably if sound is out of sync that mean hardware is
too slow. compressed audio track is not synced with movie.
engine trust that speed of both audio and video are enough
for proper playing.

comment:16 by SF/isaac_a_steiner, 14 years ago

Okay, I just tested it with
ScummVM 0.8.0CVS (Jul 27 2005 09:26:14)
Features compiled in: Vorbis FLAC MP3 zLib MPEG2

And the same probs.

The System I'm testing on is a AMD Athlon.
gfx card is a TNT2 Pro
sound card: dunno, something with legacy

Ya really think it is the system?

Isaac

comment:17 by sev-, 14 years ago

AMD Athlon what? Speed of processor is the thing which
matters. Other parameters do not have any impact on ScummVM
in this case.

comment:18 by SF/isaac_a_steiner, 14 years ago

ooops...
Athlon 1000. I should sleep more...

So, what would be an "ideal" configuration?

Regards,
Isaac

comment:19 by sev-, 14 years ago

Owner: sev- removed

comment:20 by fingolfin, 14 years ago

Summary: SMUSH: out of syncSCUMM/SMUSH: out of sync

comment:21 by SF/headb, 13 years ago

I wish to help audio-outta-sync scummVM users.

doing the ff. helped me. it's may be the "true solution" to
the problem, or it may just be one of the infinite work-
arounds to the problem.

this is what i added to the scummvm.ini (located in windows
folder if ur using windows), under [comi]:

output_rate=44100

so that my [comi] section looked like this:

[comi]
description=The Curse of Monkey Island (Windows)
music_volume=256
speech_volume=256
path=C:\GAMES\LucasArtsAdventures\Monkey Island 3- The
Curse of Monkey Island\Game\
aspect_ratio=false
music_driver=auto
subtitles=true
platform=windows
gameid=comi
fullscreen=true
sfx_volume=256
talkspeed=85
speech_mute=false
output_rate=44100

version .9 of scummvm has a readme that states:

The output sample rate tells ScummVM how many sound samples
to play per channel
per second. There is much that could be said on this
subject, but most of it
would be irrelevant here. The short version is that for
most games 22050 Hz is
fine, but in some cases 44100 Hz is preferable. On
extremely low-end systems
you may want to use 11025 Hz, but it's unlikely that you
have to worry about
that.

so scummvm recommends 11025, 22050, and 44100Hz

in my case, the cutscene from comi had a lagging video and
a leading sound, so increasing the output sample to 44100Hz
(or maybe correcting it, for i do not know what freq. it
was resampling the *.san file) more or less "synced" the
audio with the video. increasing this value even more would
yield a leading video and a lagging sound. Decreasing this
would yield a lagging video and a leading sound.

hope this helps. i presume this is the result of a non-
standard compressed sound file (?); althoough i did
download a torrent of a supposed;y original CD image. my
original copy of MI3 was stolen btw. still have the box and
goodies though.

comment:22 by SF/headb, 13 years ago

hmm... my hypothesis needs a bit of testing. any feedback
from those who would test this is welcome. all i could
reaffirm is that when i set the output rate to 11025Hz, i
end up with a lagging video again. if i put a 44100Hz
frequency, the video and audio sync

comment:23 by eriktorbjorn, 13 years ago

I wonder if bug #1584888 (and its attached patch) has any
relevance to this one.

comment:24 by fingolfin, 13 years ago

The fact that changing the sample frequency affects this issue indicates a timing related problem. It might be necessary to add code that adjusts for clock drift -- the typical cause for sync problems in videos. After all, the audio is driven by one thread (called with a frequence of 44.1kHz, or 11.024kHz), while the graphics are drawn by a timer running at a different frequency...

Anyway, we had some fundamental changes in this code recently, and we no longer use a timer for the graphics drawing. This might affect this issue. Could somebody please confirm whether it is still present with a current build (post 0.9.1).

comment:25 by fingolfin, 13 years ago

According to other sources, it seems indeed as if the issue has been resolved, but it would be nice if you, Isaac, could confirm this...

comment:26 by fingolfin, 13 years ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newpending

comment:27 by SF/sf-robot, 13 years ago

Status: pendingclosed

comment:28 by SF/sf-robot, 13 years ago

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

comment:29 by digitall, 12 months ago

Component: Engine: SCUMM
Note: See TracTickets for help on using tickets.