Cheat Engine

[Peppe90]

Hi man I have a question for you:

if I set the speedhack to 0,5 and try to capture an video with fraps, i get video in slow mode and normal audio. If I try to change framerate (like from 30 to 60fps) for speed up the video to "normal speed" the audio is out of sync; so i have tried to speed up the audio for sync with new video, the audio speed is in sync yes, but is too fast...

There isn't a way to speedhack game and audio in the same time? Because if I speedhack at 0,5 or 2.0 the audio is in sync with video, but the game is fast and audio is normal and when i capture an video with fraps i don't know how to sync it, beacuse if i speed up the video, the audio isn't in sync, and if i speed up both, the video is good but the audio is too fast.

I don't know if you have understand me, sry for my bad english

[Dark Byte]

Not possible. Sound is played back through hardware and is thus not affected by the speedhack

[Peppe90]

an possibile way is to slowly all the file audio thet will be played? maybe it function...

[Erez Zrihen]

I think that the game invokes some known functions to play audio either in memory or from a file, but since these functions are known they are general and when you invoke them you have to specify as a parameter which audio you want to play.

This parameter is a pointer to a buffer in memory most of the time.
This buffer is the data of the audio that is going to be played by the function.

For example, the PlaySound function plays the audio in memory that the pszSound first parameter points at memory when the SND_MEMORY flag is set in fdwSound last parameter, though PlaySound is rarely, if not never, used in modern games.

You can use both ReadProcessMemory and WriteProcessMemory functions to modify the audio in memory before the function that plays this audio is invoked.

Of course that this is very inefficient to do that every time before the playing audio function is invoked, but you can do that every time an audio file is read or loaded from disk (HDD or SSD) to the memory (RAM).

There are many known algorithms to change the speed of any audio (with and without pitch change) if the data, length (number of bytes) and format (wav, mp3 and etc) of the audio is known.

[striker_man1]

I agree that audio speed would make the usability of the speed hack feature universally more versatile/useful.

As a software engineer myself, my theory is that speedhack works by intercepting OS calls (made by a program/process) for fetching system time and scales them proportional to the integer you set as your speed. This causes the program/game/process to believe more/less time has passed than what has actually passed in real life, and will therefore do more in a shorter period of time in an attempt to maintain a consistent internal frame rate such as those used in physics engines or rendering to know where you should be at a particular point in time based on your previous position, speed, etc etc. It all uses the same basic patterns, and the speed is limited only by how well your hardware can keep up relative to how well optimized the application is.

Similarly, my theory for why sound doesn't work is that sound must be processed or streamed from a separate process (not the one/game being intercepted). I suspect this is not a simple task, as your application likely just gives an MP3 to some other application over a port, and the rate at which the audio is streamed is not likely to modify the speed of playback. Audio is also not likely to be standardized in most ways (this is an assumption given how and usually non-functional most audio software is). It's probably very complex and how to speed/slow the audio isn't likely something the OS makes simple to do at a low enough level to work for all the different ways that audio might be handled/delivered. Hooking in and intercepting audio for transformation (to make it faster/slow) at a high level (such as the application-level) must be too varied and ever-changing to justify investing time in it, as it likely wouldn't work on most machines or even at all by the time it was finished.

These are theories however, and I would love to hear a more reputable source speak on the matter, as it is a very high wishlist item for me as well, and I would be more than willing to help fund any type of kickstarter or buildout of such a feature. And even if its not possible, would be more likely to support future endeavors from a source that keeps it's community well informed on it's future direction and decisions so that they can trust and understand the authors point of view.

[Dark Byte]

With audio the audiosample gets loaded on the sound hardware and then played.
The sound hardware will let the game know when it has finished playing and accepts command to interrupt the current playback, adjust playback pointer

Timing API's have no effect on this. At best you can tell the audio device to playback at a different speed, or if that's not possible, replace the audio buffer with an adjusted sample

[STN]

Sort of a workaround is you can adjust the speed in an editing software, i assume that's what you are trying to do, for some youtube video or something. If not then SOL