Emulator

this would be excellent

this would be great for the TAS community and I expect it to be fairly useful as a
debugging tool for the development of the emulator

You should totally build a TAS input plugin for Dolphin

I would also like to see a movie recorder that (just like crysis), renders the movie
to be at full speed (30/60fps).

How would you do that??

You guys are just crazy :D
Never heard about TAS before. Very strange feature imo.

If it's suppose to be frame driven, the "easy" lowlevel way to do this would be to
handle your SI stuff from VI callback. And the "easy" "highlevel" way would be to
handle emulated inputs from frame buffers swap. In both cases it would pollute either
Core or videoPlugin. Plz, at least, don't touch the core for this. :)

Frame forward is a useful option, without any connection to TAS.
And it can be done with going to pause after frame rendering.
I think input is already handled per frame no?
IMPORTANT NOTE: we talk about SC only.

P.S
There is always another way

If frame advance is implemented, then implementing the input recording is relatively
simple. You dump the controller(s) input to a binary file (movie file). There's a bit
to get the re-recording aspect working, but that is simply storing the entire movie
in a savestate. The final step is having an option of overwriting controller data
with data from the movie file. These aren't trivial, but compared to frame advance
and stabilizing savestates, it is much, much easier.

nakeee: Go Mutexes!

Xtra, won't help. DC is not deterministic enough

if you look in padsimple there is some (old and unhappy) code that was put there for
rerecording. I think it was copied from Dolwin (maybe the other way around)?

Anyways, SerialInterface->UpdateDevices() gets called once per frame (supposedly on
vblank?). This is when the devices do GetData (ie when the current gccontroller class
checks the pad plugin for the SPadStatus), and updates interrupts.

The call is from SystemTimers.cpp, but it would be just as easy to put the
rerecording in SI_DeviceGCController.cpp:GetData() if you didnt want it in SystemTimers.

Yep, that is exactly what I'm planning to do,
I'm just waiting for "someone" to finish the SI changes :p
Once it's done we'll add setRecording(filename) and save the state to disk if
filename != null (or maybe compile time option).

Yeah, I agree with nakee. Don't use DC.
Caution: SerialInterface->UpdateDevices() isn't quite synchronized with frames even
in SC. More or less 60 SICallBack per "sec" whereas we can have 60,30,50,25 FPS.

Serial Interface it is!

In any case and on another note, what about capturing video from the output and
saving it as a constant 30FPS video file? We could use this frame-by-frame
(henceforth, fbf :P ) mode to take each frame and stream it out to some video format,
which we have to determine.

mb2 argg.. any idea how we can sync it? can we make it once per frame somehow?
XK We can't even make screen shot work....

Is there a video format which would support metadata like recorded input and stuff
per frame? (mkv would probably do this easily...but might be a bit of work on our
side, idk)

The binary movie file generated should not be linked at all to the resulting avi. You
should be able to later play back the binary file of controller inputs, and dump the
resulting game output to AVI.

Including the two is not the intention. Sorry if I made it seem this way.

Keep this statement from the first post in mind:

"The movie [input file, not video] should store the player's input, not the emulation
results (CPU state changes or video frames). If the emulator is robust, only the
input and the game are required to reproduce the playing session."

Another aspect of input recording that needs to be kept in mind is that one must be
able to go back to somewhere in the middle of the movie file (whether it's just a few
frames from the end or near the beginning) and play from there, overwriting the input
that came after that position in the movie. You must also be able to append to the
end of an input file since a TAS is never completed in one go. These features would
require the input file to stand on its own so video is not needlessly rendered just
to be deleted or appended to later.

Sure. Complete separation of input and video file (each one's generated by another
plugin).

I've always thought that the TAS requirements are way too high. Rewinding?
"Scrolling" an emulation to the middle/near end? Speeding it up over 100%? We are not
emulating a NES here, show some respect :P

nakeee: We should work on screenshots ASAP :)

Please notice that many of those features are suggested. Obviously, rewinding and
super speed are not feasible for this emulator, at least not for many years. I'm not
sure what you mean by scrolling, but it sounds like what you mean is saving a save
state at some point while watching a movie and being able to load it with the movie
later. That feature shouldn't be too difficult, as long as read-only (play back the
movie) and record (write over everything after that save state is loaded) modes are
handled properly.

In reality, you should first follow the requirements page. It gives the bare bones
requirements for the emulator. The features page gives a list of the requirements
plus more features that are helpful, but not required. Notice that many are marked
as low priority. There is also a chart at the bottom of that page showing the
features that all of the emulators that the site accepts or may accept have.

Basically, following the requirements page gives you what you must have to get the
emulator accepted. The features page shows all of the bonus features that either
help a lot or open new possibilities for glitches (such as soft reset).

At some point, the person who worked on the latest NES emulator will either write a
wiki page or discuss about the more technical details of making an emulator
rerecordable.

By the way, you may want to look at the PCSX Rerecording emulator that was just
accepted at the site (somebody modified the source code to make it rerecording
capable). It doesn't have most of the features stated on the page, but it had all of
the essential requirements and it's fairly stable for many games (nowhere near most
of them, but that should improve later). However, it has been deemed to be working
well enough to accept movies created by them at the site. Check out the discussion
thread for it: http://tasvideos.org/forum/viewtopic.php?t=7271 To jump directly to
where the consideration for accepting this emulator began, see this: http://tasvideos.org/forum/viewtopic.php?p=188949#188949

When I wrote scrolling I meant seeking in the Speedrun
"one must be able to go back to somewhere in the middle of the movie file"

Every uncompressed save-state weighs ~50-60MBs, while compressing it using the fast
LZO library takes a couple of seconds and still weighs about 17MB. The save-states
are large and accumulating them all will probably weigh a whole lot.

I saw this video as a reference on how to create TAS videos in a proper 3D console
(N64): http://www.youtube.com/watch?v=fdDA6dnhUiQ
And first of all I have to say that I'm impressed -- The advanced UI which delicately
controls the input. Secondly, it's possible for dolphin to have the same
functionality, as the FBF rendering speed can be quite satisfying (as long as the
final result is played at 30FPS, that is).

What do you have to say about the save states?

P.S. About coherency of emulation, GC and Wii use some functions such as RTC and
timing, so it's obvious that coherency is not possible for some cases, even FBF
input. And of course Dolphin must be in SC mode in order for this all to be feasible.

Going back to somewhere in the middle of the movie file is achieved using manual save
states. So whenever a movie maker hits a milestone, they generally would want to
make a save state at that point so they could jump backwards if they found a new
glitch somewhere. They also would want to keep a save state at the end whenever they
stop so they can resume their progress. This way it won't take a long time to get to
where they want to be, unless they missed making a save state. Generally this is
achieved by loading the movie and then loading a save state that was made while
creating the movie. I believe that such a save state needs to save a copy of the
movie embedded inside, but don't quote me on that, someone who developed one of these
rerecording emulators can say for sure. Oh, and loading a save state while paused
should keep the emulator paused too.

This brings up a new point. The movie playback needs to have a toggleable read-only
and recording mode as described here: http://tasvideos.org/EmulatorResources/Features.html?#9 This way you can choose to
play back a movie (with or without loading save states) and then decide to record
over everything after a desired frame.

Oh, by the way, what are these modes that you guys keep talking about? If it takes
too long to explain, you can just point me to a page that explains it.

This thread is becoming too busy, and I see enough other people are working on it.
Please whoever wish to implement it assign it to yourself

Well, the rerecording is there (but is slightly buggy, see issue 585), and it has
perfect sync-robustness. The frame advance should be pretty easy (Just a hotkey to
press the play button, wait one frame, and press the pause button). Then this will
be practically done.

never mind...the sync-robustness is the problem with rerecording...

Of course the sync-robustness was bad...I did it on DC mode, so of course it was
messed up...I tried it in SC, and it worked fine :). Sorry...

The sync-robustness still isn't very successful. I tested using developer mode in
SSBM (you can go frame by frame) and many of my movies desynced at the very beginning.
Frame by frame will most likely show up any errors in input synchronization...

Some did work though. Good job so far

??? I thought it worked...it seemed fine on SMS in SC mode...

Perhaps because you are playing in real-time, a frame or two of bad synchronization
may go unnoticed.
It does work, but for the majority of the time it has synchronization issues.
Perhaps you should try using saves and loads while recording? The issue could stem
from a bug in rewinding the input file or something..

hmmm...yeah, I wasn't really doing anything complex. Oh well. Scientific sync-
robustness will take a while to get done, then.

Frame advance is done, even though you need to build it specially...
See r2273 log message.

also, another problem is that when pressing Save, it seems to save the next frame. It
should save on the present frame.

Maybe someone can explain it better than me..

The only major things we need now sre starting a movie from a savestate and sync-
robustness...

the latter being very important^^

And very, verrrrry difficult to achive.

People earlier on were talking about adding a movie exporter for saving 60fps videos,
and I've coded a patch that takes a step towards that: http://pastebin.com/f25af7564

(NOTE: Because TourtiseSVN couldn't add it to the patch file, you have to manually
create the folder Data/User/Dump/Frames)

Instead of saving an actual movie, it just dumps all the individual frames recorded
into its own folder. Obviously, this is nowhere near good enough for recording stuff
more than a couple minutes long, but it works, and it when put together in a movie,
it's full-speed. Somebody with more experience with say, FFMPEG or VfW could probably
make this export it directly into a movie folder with some real-time compression, but
that's beyond what I know. It's also currently all in the OpenGL video plugin, but
can easily be ported over to the DX9 one, or can be moved elsewhere to make way for
both video and sound capture.

I noticed something when coding this though: Some games (Luigi's Mansion, in my case)
use different framerates for different parts of the game. (Gameplay seems to be
30fps, while the small shots of Luigi trying to open locked doors are 60.)

Interesting. Somebidy code a video encoder!

Great to see someone work on that! :)

From the looks of it (haven't actually tried it), you're dumping bitmap images. For
Linux, it would be best to dump the raw streams (video and audio) into a file. This
way mencoder could easily read and encode them on the fly. Raw, in this case, means
that there's no header, padding or anything, just a message on the log saying
something like "dumping video stream to Frames/videolog.raw, 800x600, RGB32" and the
bits written to that file so that people could take that information and pass it to
mencoder. I don't actually know how this would do on Windows or if it even supports
fifos, but imho it'd be the best for Linux folks.

About the fps changes: are the frames actually displayed longer (1/30th of a second
insted of 1/60th) or are they displayed twice? If it's the latter, it's no big deal,
mencoder can just drop them. If the actual rate changes, a message like "frames
0-5500: 60 fps\n5501-5700: 30 fps\n 5701-6000: 25fps) would be great. The mkv
container supports variable framerates just fine, the major players should do fine as
well.

Double-checking the fps issue; the actual FPS changes. Although the mkv container
does support variable framerates like you said, this makes any sort of
post-processing on the video a huge pain to do.

Also, I'm trying to aim for this to pipe the raw frames directly into a video
encoder, so hopefully we never have to handle raw stream dumps, since outputting into
a lossless coded is just as good for most situations. I could try to come up with a
VfW implementation of this, but that will be Windows-only, and we will probably have
to use FFMPEG or something similar for Linux/Mac(?)

Is it possible to make a forced 60 (50 for PAL games) output that just duplicates
frames if necessary? I believe so, since Mupen (N64 emulator we are using to record
TASes currently) produces exactly that result regardless of the actual game fps
rate, and the tv sets refresh 60 times per second as well regardless of the content.

Duplicated frames by themselves won't be an issue; they can be dropped altogether by
using decimate filter in MEncoder upon the initial capture.

Any thoughts?

I'm not sure exactly how the HLE plugin limits the FPS right now (only just started
looking at it), but duplicate frames is definitely the way to go for handling stuff
like that.

baby.lueshi: Actually, that's just what the fifo files are for. Dolphin would "pipe"
its frames into that file and mencoder/ffmpeg reads from it. It's like "./Dolphin |
mencoder [options]", just with a file instead of a direct pipe. The encoders could
then either directly encode it with x264, xvid or the like or save it lossless as
well, only compressed (huffyuv and ffv1 come to mind). This also works with audio
samples which can be handled at the very same time. A nice example of this can be
found at http://nopaste.org/p/amgy2a21h

shinydoofy: I actually didn't know about that! In that case, a raw dump would be the
best choice for Linux. (And Mac? I have never touched one in my life and have no idea
how they do things. Can a Mac buddy help me out here?)

Windows will still need a special way to do things, but after looking at the API,
Videos for Windows is pretty simple from the looks of things.

Note that if you just dropped every other frame of the 60fps bits (idk how you would
figure out where the 60fps bits are, though), you would half the size of the video
file without a (noticable) drop in video quality. Just a thought, but it would be
better than just having duplicates of 95% of the frames.

Believe me, duplicates are absolutely no problem. Redundancy is better than data
loss, anyway.

I made a different version of the patch that dumps a raw file instead of a bunch of
individual images: http://pastebin.com/f203cb22a

Through the use of AviSynth and the RawSource plugin for it, you can get a video out
of it. I think this is more in line with what shinydoofy was talking about before.

I'll test it. Good work!

How to use avisynth?

If you're on Linux, just run "mencoder -ovc xvid -xvidencopts bitrate=1000 -mc 0
Frames/framedump.raw" from another terminal before starting the game and you'll
encode it. You won't need avisynth
If you're on Windows, just download and install it and check the home page for a
first script. You should do fine when googling for avisynth and the keyword you're
looking for. http://avisynth.org/mediawiki/Importing_media might help you out.

ok. but now I can't find the .raw file (I added the Frames directory in User).

The full path to the dump should be User/Dump/Frames/framedump.raw. It should have
popped up an error if it couldn't make the file, but I guess I messed that up.

For AviSynth, you have to download the RawSource plugin:
http://avisynth.org/warpenterprises/#rawsource

Put the DLL in it in the same folder as the dump and the AVS script, and the Script
should look like this:

LoadPlugin("rawsource.dll")
RawSource("framedump.raw", 640, 480, "RGB")
AssumeFPS(60)

Replace the width, height, and FPS with what you used to record.

Found the problem...tortisesvn doesn't like the patch, so it looks like I'll be
stuck with changing the lines manually. This could take a while...

No, that won't work. There's just too many changes. Maybe you could just zip the
files and email them (my email is above, just fill in the letters after you click
it).

Small fix: http://pastebin.com/f40a99ce6

For those wanting to make videos out of the dumps, you can use MEncoder:

mencoder -rawvideo w=640:h=480:fps=60:format=RGB24 -ovc xvid -demuxer rawvideo
-xvidencopts bitrate=1000 -mc 0 User/Dump/Frames/framedump.raw -o test0.avi

Adjust width, height, and fps accordingly.

Another big update: http://pastebin.com/f29815b74

When compiled on Windows, frame dumping now dumps it straight into a .avi file with
the codec of your choice. Next to bringing sound into the this, there's not a whole
lot much more to do here other than handling variable framerates.

marc: Are you trying to apply the patch to the Source folder, or the folder above it?
("dolphin-emu-read-only" for me.)

Sorry, that last patch has an error in it. Use this one instead:
http://pastebin.com/f2694d343

ok. I'll see how your .zip works, and make a patch for that, so you can see any
diffs in the patch syntax.

here's a patch I made from your zipfile: http://paste2.org/p/168019
I'll see if anything's different.

The patch you made looks nearly identical in syntax as the ones I've made.

When saving the patches I make, do you use the download link on the pastebin page? It
looks like it's converting tabs into spaces which might be the reason the patch isn't
working.

Here's he problem:

-69,6 +69,7 @@

in your patch is:

@@ -69,6 +69,7 @@

in my patch.
Looks like your average internal syntax error if you ask me. Theoretically, all you
would have to do is @@ at the beginning of each similar line.

Compiled with the zipfiles, no .raw file. I'll try your newer patch, now I know how
to adapt it.

Ok. Now it's getting mad at me about " " not matching " ", so I guess you'll
have to use something that leaves the tabs alone, I think http://www.paste2.org does.

http://paste2.org/followup/168019

It looks like it wasn't mangled when posting.

ok. I'll try it.

Well it patches!

Was that the AVI version or the raw one?

The AVI one. Just check the checkbox under Utilities in the Advanced tab and it
should output it to an AVI file.

Oh, idk there was a checkbox...THAT SHOULD FIX IT!!!

XD

http://img8.imageshack.us/img8/3638/erroramo.png

Am I doing something wrong?

Two things:

1: I gave you an old patch. Whoops! http://paste2.org/followup/168034

2: The patch doesn't make the necessary folder. Create the folder Frames under
Data/User/Dump and it should make it the next time you build it. Otherwise, just make
the folder "Frames" under User/Dump

Hopefully we've all learned something out of this: we have SVN so things like this
don't happen.

And by "build it", I mean "build DolphinWX"

"Hopefully we've all learned something out of this: we have SVN so things like this
don't happen."

Now that quote will be famous.

1: OK, I'll try the new one.
2: That's the problem. My folder is at User/Frames...

And by "build it", I mean "build DolphinWX"
Not the core as well?

No, the DolphinWX project file has a small script that copies the files from the Data
folder over to the output folder when it builds.

Windows Media Player cannot play the file. The Player might not support the file
type or might not support the codec that was used to compress the file.

Got that both with uncompressed and Microsoft Video 1. What codec should I be using?

I already had Lagarith installed on my computer, so I just used that.

If you can, try downloading VirtualDub and opening it in that. If it opens something,
then it was probably just the file not being closed correctly and I'll look into it.

Also, how large (filesize) is the file?

over 500 meg for 15 sec of video. Won't open in VirtualDub.

Try installing a different codec and using that (Xvid or Lagarith were the two I
tested with.) Also, try recording it at 640x480 if you're not already.

installed lagarith as per readme, and still codec not supported.

By not supported I assume you mean it doesn't show up in the codec selection dialog.

Did you install the 32 or 64 bit one? And are you using 32 or 64-bit Dolphin? That's
the big problem with codecs: You can only use 32-bit codecs in 32-bit programs and
vice-versa.

it was in the dialog, just wmp didn't like it.

That's very odd. This may be a stupid question, but you aren't trying to open the
file when the emulator is on, correct? Otherwise, it may still have control over the
file and the errors may be a side effect of that.

The only thing I can tell you is possibly record a super-short video and try
uploading the AVI it produces so I can look at it. The Microsoft Video 1 codec will
probably make the smallest video.

ok. I'll do that. (and I shut the emulator before opening the file).

I set the compression quality to 5 and recorded like 10 frames and emailed it to you.

The file you sent me was mostly full of null bytes and no AVI header, which doesn't
make sense, because AVIFileOpen automatically creates an empty AVI container.

What version of Windows are you using?

Also, if somebody else could try the patch and post their results, that would help.

WinXP SP2. And I figured the null bytes are because of those frames being mostly
black (but idk much about the inner workings of video files, so it might be
completely unrelated).

Yeah, after attempting to repair the file with the AVI header from a recording I've
made, I was able to recover a broken picture of what is probably the Nintendo logo
and some copyright text: http://img9.imageshack.us/img9/7645/48885025.png

Could somebody else try building the patch and see if they get this bug too?

Yeah. Can you send me the header so I can make a less-compressed video, fix it, and
see if it looks like it's supposed to? I figure that the problem is that the
compression was set so high that it completely distorted it.

My guess is that you need to fix the header...

After a little searching, I think I found the problem. The file was only closed and
finished when the frame dumping box was unchecked during recording, and the file was
closed incorrectly if the emulator was just stopped. During testing, I wasn't making
recordings this way so I overlooked it. This new patch should write the file
correctly if the emulator stops during recording: http://paste2.org/followup/170803

Crashes will probably still produce corrupt dumps.

I also looked at attempting to dump audio, and it looks like there already a small
framework for doing this. However, as of right now, it doesn't work.

OK, thanks for fixing that. I'll test it again and see how it works.

The video dumper has been commited in r2781. If you want to use it, make sure that
the Frames folder exists in User/Dump and that the "Dump Rendered Frames" checkbox
is checked in the video plugin settings.

Please try to use cross platform libs when doing these kind of things.
You are just making us have more work porting it later on...

sorry...

Finally! Awesome work XK, hope you get to fix all the issues that haunt me!

Federelli: That Z:WW camera issue haunts me, but I can't seem to fix it :(

At least I'll work on what I can

How would tas work if dolphin can't run most games at full speed yet? Would audio
still sync in slow motion?

Lol he's right the only game I can get running at full speed on my quad core 2.2 GHz
is Sonic Adventure 2 Battle :P

kevinx0404: The recorder mostly runs the game in slow motion as it is, and when
dumping to AVI there is no frameskipping (all frames are dumped) and re-aligned to
constant 30/60 FPS. Sound will be synced as well.

Once someone gets the sync-robustness working, you won't have to play te game and
record video at the same time. You will be able to record the button presses of a
run, and then play it back while recording video.

If you say audio and video will sync perfectly at slow motion, then why doesn't audio
sync in normal speed? When I play a game like Trauma center, It plays the music at
normal wii hardware speed, but I have to wait before the operation can begin. The
music is finished before when it should have ended. I only get 20fps in game, but the
music is at full speed.

That's called DTK music and it comes from tracks on the CD. Please notice that it's
only streaming music (i.e. background music) and its speed isn't related to emulation
speed.

So will dtk music sync with slowmo?

well I say it won't. It's just too much work for too little gain.

It could be implemented but I'd prefer it wouldn't be.

What's so important about slowmo music?

so that it would sync in tas videos?

If TAS videos play in full speed, the music will also play in full speed, and synced.

Ok. Thanks.

wait what? Howzat work?

It just will. ;)

I is for itjustwill, that's good enough for me.

I have two more questions. When you savestate, can you switch between real and
emulated wiimote? It would help to use the emulated wiimote for a game like trauma
center for operations without a defibilator, but you'd need to use the real wiimote
for another operation. Lastly, since the format is .dtm, how would you encode is as a
file with the avi container and the x264vfw encoder? Will that be released with
dolphin too?

btw, is there a speedup option for tas to skip the boring story parts in some games?

speedup? more than what we try? No.

I think you may want to try the "tab" key :)

I have throttling disabled by default :P

@kevinx0404: frameskipping.. just for you.

haha. Thanks XTra.KrazzY.

Well.. not sure it's a TAS-related thing but anyway... Screenshot feature doesn't
work in D3D. A remind.

Don't work fine. When I play the movie (example ssbb), the tas don't select the
character (I selected Link) and if moving in all the places (becouse I move to Link
to the Right, left, etc). Somebody can fix this problem, please?

I have a question.

I wanted to build the TAS version of Dolphin and I heard, that I just have to
uncomment the TAS thingie in setup.h, but it doesn't work.
I always get many mistakes, when trying to build.

Are there any other things to do, or does anyone have advices for me.

Just file a bug that says that the rerecording build is broken in rXXXX...

Does ANYONE know how to make a TAS for ANY emulator for MAC?!? It seems like there aren't any because nobody cares!!! I CARE!!!

fceux or mupen64 might compile on mac. Be a man, don't cry because there's no magic "it's all so simple" dmg file and AVOID CAPSLOCK AT ALL TIMES!!!1

I was playing with r6352 just now and have a few comments on the current state of rerecording.

• With at least one game I tried (Luigi's Mansion) I seemed to be able to record (and rerecord, i.e. make use of save states) and play back a DTM properly (subject to e.g. not using multiple cores, though I didn't actually check to see if it would work in that case - prior experience suggested it won't). That having been said, at least one game (Twilight Princess) consistently fails to provide recordings that sync.
• Memory cards aren't cleared between runs; this can mean that playback isn't starting back from exactly the same state. (A workaround is to simply not have memory cards be present.)
• I find it unintuitive to have the prompt for the DTM appear at the end of an emulation session - for most other rerecording emulators you have the filename prompt appear at the beginning and have said file be updated as recording is made (or perhaps on making save states or closing the emulator).
• I also find it unintuitive as to how to resume recording from a certain point - having checked the source code I gather a read-only option will be added at some point which will presumably also mean that, if said option is disabled during playback, one will be able to initiate recording again simply by providing the emulator with input during playback.

I look forward to seeing the above concerns addressed.

• Memory cards aren't cleared between runs; this can mean that playback isn't starting back from exactly the same state. (A workaround is to simply not have memory cards be present.)

How about saving a copy of the memory card you used for movie making?

I already made a review on Dolphin here:
http://forums.dolphin-emu.com/thread-12226.html

One last setting: Idle Skipping should be off, since that can mess with RNG values, among other things.

With the settings listed by skidau and lueshi, I can in fact rerecord properly... but only for a few seconds before a desync (playback misses a beat and the character's position no longer matches the user's input). By slowing down the Dolphin (safe accurate texture cache, disable EFC, etc), I can manage to record for a little longer before the inevitable desync.

Also, I can't get Read-Only Mode to work at all. Check or unchecked seems to have no noticeable effect when loading a save state while playing back a movie.
This is all as of the latest revision, r7243.

Thank you for the fantastic progress that has been performed on this issue thus far, but I don't think it's quite ready to be closed yet.

Desync's and save states will continue to be an on-going issue. We have those tracked in other issues. This issue was to track the addition of the minimum required TAS features and those have been added.

Also, I wanted to note that even if the recording/playback were made with No Audio Output, dumping audio should still emit sound.

Using No Audio Output helps with sync in certain situations, however, the majority of the time, recording/playback will still work with audio.

Wiimote recording still have some syncing issues with it, which might be causing your problems. Are you recording a Wii game, and if so, does it still happen as often with Gamecube games?