Opened 14 years ago

Closed 13 years ago

Last modified 15 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, 15 months ago

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