#2260 closed defect (fixed)
SCUMM/SMUSH: out of sync
Reported by: | SF/isaac_a_steiner | Owned by: | eriktorbjorn |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | 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 , 19 years ago
comment:2 by , 19 years ago
Summary: | smush out of sync → SMUSH: out of sync |
---|
comment:3 by , 19 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 , 19 years ago
Definitely. Tool has changed in 0.8.0. Please, recompress and tell me the result if possible.
comment:5 by , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 years ago
ooops... Athlon 1000. I should sleep more...
So, what would be an "ideal" configuration?
Regards, Isaac
comment:19 by , 19 years ago
Owner: | removed |
---|
comment:20 by , 19 years ago
Summary: | SMUSH: out of sync → SCUMM/SMUSH: out of sync |
---|
comment:21 by , 18 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 , 18 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 , 18 years ago
I wonder if bug #1584888 (and its attached patch) has any relevance to this one.
comment:24 by , 18 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 , 18 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 , 18 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → pending |
comment:27 by , 18 years ago
Status: | pending → closed |
---|
comment:28 by , 18 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 , 6 years ago
Component: | → Engine: SCUMM |
---|
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?