Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
12 ->
--
--
List results:
Search options:
Use \ before commas in usernames
Edit history:
cyghfer: 2012-05-25 05:25:00 am
cyghfer: 2012-05-24 11:17:40 pm
cyghfer: 2012-05-24 11:08:10 pm
cyghfer: 2012-05-24 10:46:53 pm
The bottom line of this thread: if you're using a capture card to record your runs and you are not manually setting the capture frame rate, there is a good chance you are recording incorrectly and possibly getting seconds mysteriously added to your final recording time compared to realtime.


The aim of this thread is to bring to the speedrun community's attention various facts regarding analog recording (i.e. with a capture card and VirtualDub, AmaRecTV, etc.) that seem to have been overlooked or otherwise not made public knowledge up until this point. I brought up the issues contained in this thread briefly with nate a little while ago, and he didn't seem to know the actual facts at hand; additionally, I don't remember reading anything in the Knowledge Base that helps with these matters (I wouldn't be surprised if the Knowledge Base and other scattered SDA documentation actually relay false info).

Krystal and I (mostly Krystal) have been doing a lot of tests and general investigation recently into how certain aspects of VirtualDub work, how TVs and consoles work in terms of frame rates, and other things along those lines. (Apologies in advance, but neither of us are knowledgeable about electronics in general, so some fine points that I'll be discussing in here like field rates and shit might be incorrectly named or w/e, feel free to correct anything I say if it's wrong). This investigation was sparked by the fact that a recent Mario RPG speedrun of mine was timed as 2:57:09 in realtime with WSplit, but by VirtualDub's timing the run was 2:57:38. That run was recorded with VirtualDub at 29.97 FPS interlaced through a Dazzle. The problem with this is that the NTSC Super Nintendo doesn't output 59.94 progressive/29.97 interlaced, it outputs 60.0988 progressive/30.0494 interlaced.

First off, yes, the frame rate specification for NTSC TVs is, in fact, ~59.941 FPS. However, apparently TVs are flexible enough to accept frame rates within ~0.3% of 59.941, including the SNES' 60.0988. So when you go to play an NSTC SNES game on your NTSC TV, the TV is actually displaying 60.0988 frames per second, not 59.941. For awhile Krystal and I didn't know about the 0.3% flexibility detail but did know about the SNES' frame rate being 60.0988 (thank you Acmlm), so we were utterly confused how TVs displayed the games accurately when the two frame rates were different. But yeah, it turns out that for the speedrun community's purposes, 59.94 is something of a red herring ...

Anyway, Krystal found out that what happened with my run is that VirtualDub basically alterred a 60.0988 FPS video feed to become 59.94 FPS without removing any frames to "fit" the recording into 59.94 FPS. Fewer video frames contained in every second but the same amount of frames total means you need more seconds to fit all the frames into the recording. So, despite timing the run myself by hand and getting roughly 2:57:09, VirtualDub reported the run being 2:57:38 - nearly 30 seconds were added to the run due to recording 60.0988 FPS video in 59.94 FPS.

Krystal did some very basic tests to find this out: set the frame rate as 60.0988 in VirtualDub, start a recording while preparing the game to loop the title screen, press start or whatever to start the title screen loop and start WSplit simultaneously, and stop WSplit while simultaneously pressing a button to exit the title screen loop. Then she'd save the recording and open it in VirtualDub, determine the exact frame count / length of the title screen loop sequence, and compare that figure to the WSplit timestamp. Doing so yielded WSplit and VirtualDub figures that were within ~0.1 seconds of each other, which accounts for human error. (She later repeated the test with an mIRC timer script, allowing for even greater precision, and mIRC script/VirtualDub figures matched each other to the frame.) She and I did some other variations on this basic test and the results always indicated the same thing: recording in 59.941 is bad, recording in the system's actual frame rate is good.

Now, it isn't necessarily the case that you'll get time added to your recording if you record in the wrong frame rate. VirtualDub has an option under Capture -> Timing... called "Correct video timing for fewer frame drops/inserts." If you have this option enabled, and you record 60.0988 FPS video in 59.94 FPS, you will end up with the case that happened to me, where the program adds time to the recording to include all of the video. However, if you have the option disabled, and you try to do the same thing, VirtualDub will instead periodically drop frames from the recording in order to match the actual real-time of the recording, instead of "elongating" the recording. Apparently, roughly ~400 frames must be dropped during a ~1:35:00 60.0988 FPS realtime video being recorded in 59.94 FPS in order to adjust accurately. If you're curious, this is what a dropped frame looks like in this case: http://notesmash.org/krystal/droppedframe.gif

So, the solution is probably what you're already thinking: record in VirtualDub at the correct frame rate in the first place! For SNES, that means you want to set the frame rate as 30.0494, as you're recording interlaced video. Unfortunately, there are some dumb difficulties involved in doing so. First off, to get this out of the way, AmaRecTV apparently cannot record in any relevant frame rate other than 29.7 or 30.0 (according to Krystal, I have not investigated this myself). To quote her: "that program can only do 29.97 or 30.0 no matter what (trying to set decimal values that aren't 29.97 result in a 15 FPS recording (lol) and even if you set 500 FPS, it still caps at 30.0)." So, if you want recordings of your runs that are actually the correct length, AmaRecTV seems to be a poor option all around (some verification from others about Amarec would be very helpful). Now, you can manually set frame rate of the recording in VirtualDub, but only in some circumstances. If you're using a Dazzle, the only case that Krystal and I know of where you can alter the frame rate from 29.9700 to anything you want is if you're using the most recent Windows 7 64-bit Dazzle drivers. One or the other of us (and I'm sure many more of you) can verify personally that using Windows XP 32-bit and Windows Vista 32-bit Dazzle drivers causes any manually inputted frame rate to automatically change back to 29.9700 when you close the Capture -> Settings... dialog box. We are unsure about Windows 7 32-bit and any other options - some reports from others would be appreciated.

Additionally, I was able to change the frame rate using an EasyCap, so I would guess that you can do it for any EasyCap model (though reports from others would again be appreciated). I haven't heard of this issue arising with any other capture cards, so I suspect it's just an issue with the Dazzle. Anyway, if there is really no feasible way for you to run a version of Windows that allows you to manually set the frame rate, and you want to record via VirtualDub, it is preferable to uncheck the "Correct video timing for fewer frame drops/inserts" option and simply deal with the dropped frames - you'll at least have a recording whose length matches realtime.

About VirtualDub truncating frame rates to 4 decimals/significant digits: for NES/SNES, at least, the difference between this ever so slightly rounded figure and the 100% exact frame rate is pretty much negligible. The longest SNES run I know of, PJ's glitchless 7th Saga run in like 11.5 hours or something, would gain about .92 frames from the recording frame rate being 60.0988 instead of 60.09881387708959. For other systems where the 5th significant digit might be a 5 or whatever, there might be a bigger divergence, so further testing could be useful here.

Now, here's something interesting for the rest of the crowd that this thread otherwise isn't relevant for - people who use DVD recorders. Krystal and I haven't really done any tests with a DVD recorder, but our guess is that at least some (possibly all) DVD recorders automatically record in 59.941 FPS and use the method of dropping/(inserting?) frames to normalize aberrant frame rates! Krystal's examined a bunch of runs downloaded from SDA and everything is either 29.97 or 59.94, some of which I know for a fact were recorded with DVD recorders. In particular, andrewg's Mario 1 run was recorded with a DVD recorder and I know that game well enough to know that 4:58 is very likely what the accurate realtime of that run was when he performed it. So, unfortunately for DVD recorder users, it might be impossible to record runs in the correct frame rate, and consequently you will always have dropped frames in your recordings - though you still get accurate-to-realtime recordings and don't have to worry about fooling around with VirtualDub/capture card bullshit. I'd expect only people that are totally anal about pristine recordings will care about this.

This situation means that for people who utilize analog recording, the exact frame rate of any system you want to record runs for must be known before you start recording. I've collected frame rates for certain systems already, but I'm obviously missing a lot of systems that actively have runs recorded for them (particularly newer ones). Here are the ones I've collected so far with exact formulae and references for where I obtained the figures from:

NES: 21477272.72 / ((262*341*2-1)*2) ~= 60.09881387708959 [http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=22600#Post22600]

SNES: 21477272.72 / (261 * 1364 + (1360 + 1364) / 2) ~= 60.09881387708959 [the quote here, ignore the actual post - http://board.zsnes.com/phpBB3/viewtopic.php?p=28390&sid=ac66de8cbcea31f98a7456ec035befcb#p28390]

(yeah, NES and SNES have identical frame rates apparently, not sure why the formulae are different though)

(also, brief note, bSNES emulates the SNES' frame rate almost perfectly, except it chops off the .72 in that first number of the formula - this is negligible in many cases though)

Genesis (also Atari 2600, SMS, MSX): ~59.9228 Hz (however, this is cited as the system's field rate, so another source verifying the actual frame rate would be best) [http://nesdev.parodius.com/bbs/viewtopic.php?p=71342&sid=2c611d85504bf8009f256fa70e080b78#71342]

GameCube & Wii: 1620000 / 26999 ~= 60.0022223045297973999 [dolphin source code / http://tasvideos.org/forum/viewtopic.php?p=308766#308766]

Now, there's still one big problem with all this - Game Boy runs. Neither the Super Game Boy 1 (well-known to run at ~61.17 FPS), the Super Game Boy 2 (seems to run at the SNES' frame rate, not the GB's frame rate, from some hasty tests of mine), NOR the Game Boy Player (runs slightly faster than an actual Game Boy from a quick test of mine, not sure of the exact frame rate though, help wanted here!) run at the exact speed the Game Boy, Game Boy Color, and Game Boy Advance run at, which is:

262144 / 4389 ~= 59.72750056960583 [bsnes source code] (I've read in multiple locations that the GBA frame rate is the same as the GB/C frame rate, not 100% sure though)

In order to get accurate-length recordings, probably the only solution is to record in 59.7275 anyway (regardless of the device used) and accept the periodic frame drops. I recommend that official timing conversions be determined for all 3 devices, though, for people who may not want dropped frames in their recording for whatever reason (or who record without knowing all this information).

Krystal tested more stuff relating to sound sync, but I think that should be left for another thread. If you're wondering how to stream + record with VirtualDub simultaneously (in lieu of AmaRecTV's live streaming capabilities), you basically need 2 capture cards, yeah, since the program doesn't allow you to screen cap the video preview for whatever dumb reason.

I hope this thread was informative for all, and I hope that the thread gradually eliminates inaccurate-length runs and a lot of problems/headache involving analog recording in general. Big thanks to Acmlm & Ilari for their help with some technical data. Like I said, we should make an effort to collect 100% accurate frame rates for every system that has games being run for it, and I wholly welcome any further testing on anything I've talked about.
Thread title:  
I can't seem to recall, but does norichan have the capacity to specify such a specific frame rate?
I want off the ride....
I stream virtualdub recordings all the time but its tricky

start virtualdub, and setup everything for recording (capture AVI -> settings blah), then start your capture, start xsplit (or pre start it but dont hit OK to the bring up the actual like scene selector thing until now). Then whatever is in virtual dub should be screen cappable until you next reset your recording, or windows decides to screw with aero.

just saying.

as for this... this is intriguing.
Couple of additional thoughts about the theory on DVD recorders periodically dropping frames for NES/SNES.

- (60.09881387708959 / 59.94) is approximately equal to (378.42 / 377.42).  So the DVD recorder should be dropping 1 frame for every 378.42 frames the NES/SNES sends it.
- If the Genesis framerate is 59.9228 (not confirmed yet though), lower than NTSC, then perhaps the DVD recorder would *duplicate* frames instead of dropping frames in that case?
Hi I'm Kryssstal
Quote from RaneofSOTN:
I stream virtualdub recordings all the time but its tricky

start virtualdub, and setup everything for recording (capture AVI -> settings blah), then start your capture, start xsplit (or pre start it but dont hit OK to the bring up the actual like scene selector thing until now). Then whatever is in virtual dub should be screen cappable until you next reset your recording, or windows decides to screw with aero.

just saying.

as for this... this is intriguing.

Oh hey, it works on Aero! It's notably choppy for me though, with both VHScrCap and SCFH DSF...sometimes perfect but then bouts of being unwatchable. The performance dip in VirtualDub's output window (both Overlay and Preview) seems to be just from starting a screen capture, so I assume XSplit wouldn't make it any better on my system.
I can confirm the 15fps problem in AmaRecTV. Too bad it's not an open-source program so we could fix it. The website seems to be gone too. I didn't know that VirtualDub actually support the real framerates. Thanks for the tip.
Edit history:
Marlie Tang: 2012-11-11 04:48:03 pm
Marlie Tang: 2012-05-25 04:50:48 am
Hi I'm Kryssstal
Here's a test recording with 0 drops and 0 inserts at the correct framerate. If you're bored, you can try to enter a level on console at the same time as the video and verify that it's not too slow or whatever (Acmlm did this to initially verify that Snes9x is slower than console due to Snes9x running at like 59.94 FPS to 59.99 FPS, which is an important fact for people using Snes9x to figure out what the best possible time for any given game or level is).

You can see my settings and random explanations here for now, though it's kind of unorganized (which is why cyghfer volunteered to present the information in a much better way). If anything is suboptimal or incorrect, please let me know.

tl;dr version: I recorded SMW on a DVC100 in 640x480 YUY2 (Lagarith), 30.0494 FPS (interlaced), with 48000Hz PCM Dazzle audio (sounds better than my line-in due to no annoying noise at max volume).

As for sound sync, VirtualDub's resampling works for me as long as the sync is adjusted by whatever the recording reports for relative latency. I've verified the sound is synced to the frame via the sword spin in ALttP with the BGM off (a glitch possible by killing yourself with bombs inside a Dark World house on 1.0).

I then loaded an .avs like this (thanks to UA) into Anri-chan 3.3 instead of the .avi itself (just ignore the error message): AVISource("smw.avi").DelayAudio(-0.233).Normalize

If you're connecting both composite and S-Video to something (be it your TV or a second capture card), make sure the composite output isn't making everything look terrible like it does on my ~2006 Mad Catz cable. It's much better to just split the S-Video signal into TV and both capture cards as I've outlined in that guide thing. In fact, those Valley S-Video splitters look much better than the one powered splitter I had the privilege to try, and the recording looks virtually indistinguishable from the Dazzle capturing the unsplit signal.

Last random tidbit: I don't know where else this has been mentioned, but the older SNES model with the white "Eject" print has better S-Video output quality than the later (original, not Jr.) model with the smaller board. See here for more on how to identify your console.
thethrillness.blogspot.com
Quote from blizzz:
I can confirm the 15fps problem in AmaRecTV. Too bad it's not an open-source program so we could fix it. The website seems to be gone too.


I did a quick translation of that and what seems to have happened is that the amarec page was hosted on a free website which is shutting down all websites. I guess we should wait a week for a new official page to be made or we register the amarec.jp domain..... Wink

For now you could use this for download if required: http://www.softsea.com/review/AmaRecTV-Live.html

As for the main posting, interesting finds and knowledge gained I must say. I'd be all in favor of capturing runs with the new framerate but I see some issues. Forgive me if I misunderstood as it is a lot to take in.

1. What happens if a new run is recorded at 60.0988 for a SNES that beats the SDA uploaded run at 59.94 but the only reason it did was because the framerate was correct? Obviously this has no real effect for in game timers but manually timed runs.

2. Will every capture device be able to handle the inserted framerate? Popular cards like the HD PVR cannot do this since it is software locked.

3. What does this mean for the way anri-chan handles encoding? Will it need to be rewritten? How will we handle runs that have been recorded at original frame rate and the new frame rate? It's hard enough to get runners to understand using lossless compression, let alone configuring different framerates for different consoles. I guarantee at least one person will record a super run but have set 29.97.


Waiting hurts my soul...
If the framerate is different, we can always calculate how long the video would have been at 59.94, right? I think this is more of a question of video quality and small amounts of dropped frames.
Edit history:
Marlie Tang: 2012-05-25 10:15:05 am
Marlie Tang: 2012-05-25 10:00:16 am
Marlie Tang: 2012-05-25 09:52:08 am
Hi I'm Kryssstal
The only runs I know of that had seconds added are cyg's SMRPG, tjp's DKC, and UA's Blaster Master. Realtime should be known for all of those runs, so it won't be hard to tell if a new run obsoletes them.

Converting a full 60.0988 NES/SNES capture to 59.94 would just make the video slower than the actual realtime events that transpired (which is exactly what the "mysterious gained seconds" are), so I'm not sure what it would accomplish other than giving a false time.

Anri works completely fine, as can be seen in my sample video.

Someone using a DVD recorder or capture card that records at 59.94 but drops frames to match realtime will technically be accurate to the second, just like a 60.0988 capture that drops no frames. It's not like 59.94 is a disadvantage if people want to use it, so long as they're not specifically using VirtualDub with the correct timing option on while capturing NES/SNES, which will add some seconds to their run. Basically, don't assume that a 60.0988 FPS SNES video is actually by nature faster than a 59.94 FPS run, when they should be identical 99% of the time.

I should note that it shouldn't even be possible to have a NES/SNES recording faster than realtime if you have the correct framerate set, regardless of which timing options you use. The correct timing option should always be on though, to avoid mysterious added frames (seemingly random and only like one per minute at most, but still annoying). Now using 60.0988 on something like NES Battletoads, which runs slightly faster apparently, would probably add some frames to the recording.

The important thing here is that things like WSplit or a physical stopwatch should always be used so you can tell if something went wrong in your recording.
DS Dictator
This is an interesting read.

Quote:
Now, there's still one big problem with all this - Game Boy runs. Neither the Super Game Boy 1 (well-known to run at ~61.17 FPS), the Super Game Boy 2 (seems to run at the SNES' frame rate, not the GB's frame rate, from some hasty tests of mine), NOR the Game Boy Player (runs slightly faster than an actual Game Boy from a quick test of mine, not sure of the exact frame rate though, help wanted here!) run at the exact speed the Game Boy, Game Boy Color, and Game Boy Advance run at, which is:

262144 / 4389 ~= 59.72750056960583 [bsnes source code] (I've read in multiple locations that the GBA frame rate is the same as the GB/C frame rate, not 100% sure though)


I can record some GBA footage from my modded DS phat to know whether or not it is played back as accurate as the real GBA system. I guess you want a raw version with a lossless codec?

I am expecting a unique capture box called the Avermedia Game Capture HD to be delivered on Monday which is pretty much A HDD DVD recorder except:
- No DVD Recording support
- No TV recordings (not that it matters for this case).
+ You can use an internal/external USB hard drive as storage to save recordings
+ Record runs in Component (up to 480p Wii and 1080i PS3/XBOX 360)
+ No PC required.

I will test out whether or not you need to manually change the frame rate like the DVD recorder, etc.
D:
I would happily support adjusting the SDA encoding standards to use the native console framerates.  I hate dropped frames. Sad
apple bapple
Support
Also note that it is not possible to view a video at ~60.0988 Hz due to limitations of graphic cards and LCD monitors. Watching a video that was recorded at the correct framerate would be exactly the same as a recording that dropped / inserted frames to match 59.941 Hz.
Obscure games ftw
so this was tested on Nintendo consoles only then? (aside from some Sega ones)
Are PlayStation output rates known?
Edit history:
cyghfer: 2012-05-30 08:00:47 pm
cyghfer: 2012-05-30 05:56:42 pm
Quote from doicm:
I can't seem to recall, but does norichan have the capacity to specify such a specific frame rate?

idk, nori never worked correctly for me whenever i tried to use it so :x

Quote from RaneofSOTN:
I stream virtualdub recordings all the time but its tricky

start virtualdub, and setup everything for recording (capture AVI -> settings blah), then start your capture, start xsplit (or pre start it but dont hit OK to the bring up the actual like scene selector thing until now). Then whatever is in virtual dub should be screen cappable until you next reset your recording, or windows decides to screw with aero.

that's interesting, i might play around with that because it's more convenient for me to only use one cap card to record + stream instead of two, due to my physical gaming setup. thanks for the tip

Quote from AnubisGI:
1. What happens if a new run is recorded at 60.0988 for a SNES that beats the SDA uploaded run at 59.94 but the only reason it did was because the framerate was correct? Obviously this has no real effect for in game timers but manually timed runs.

2. Will every capture device be able to handle the inserted framerate? Popular cards like the HD PVR cannot do this since it is software locked.

3. What does this mean for the way anri-chan handles encoding? Will it need to be rewritten? How will we handle runs that have been recorded at original frame rate and the new frame rate? It's hard enough to get runners to understand using lossless compression, let alone configuring different framerates for different consoles. I guarantee at least one person will record a super run but have set 29.97.

1. this is only a problem if vdub had that one option checked, and thus was not dropping frames to normalize to realtime. unfortunately i think it has that option checked by default (and it's better to have the option checked when you have the correct frame rate set, not sure why though, that's just what krys told me)

2. possibly not, but i don't think anyone except people who are personally picky with their video quality is going to care about the regular frame droppage thing

3. anri-chan apparently handles stuff fine i guess


@greenalink: the test thing you suggested would be very interesting to see, i'd appreciate if you did it : )

Quote from blizzz:
Also note that it is not possible to view a video at ~60.0988 Hz due to limitations of graphic cards and LCD monitors. Watching a video that was recorded at the correct framerate would be exactly the same as a recording that dropped / inserted frames to match 59.941 Hz.
this might be true, though it'll make a difference when people frame advance through runs for whatever reason. in general i can't imagine why anyone would want to record something in the wrong frame rate if it wasn't a hassle to record correctly, though

@i have no name, no, playstation/xbox outputs are not known. all actual tests were done solely on nintendo consoles, dunno why that would matter though.

@nate, you're honestly the person i most wanted to hear a response from - i'd appreciate if you gave your input on this matter if you have any to give. at the very least the knowledge base needs to be revamped (not only for this, though, it's rather messy and outdated in general). edit: i heard you're on vacation, sorry about being impatient. i just saw you post in the norichan thread and thought you ignored this one - pls take your time to respond whenever : )
Video Games
Quote from blizzz:
I can confirm the 15fps problem in AmaRecTV. Too bad it's not an open-source program so we could fix it. The website seems to be gone too. I didn't know that VirtualDub actually support the real framerates. Thanks for the tip.

This site seems to still be up. I gather they already moved.
n64 works fine, it runs at 29.97.. my 70 run is 49:44 in real time and timed from the recording video
Quote from SirFist:
Quote from blizzz:
I can confirm the 15fps problem in AmaRecTV. Too bad it's not an open-source program so we could fix it. The website seems to be gone too. I didn't know that VirtualDub actually support the real framerates. Thanks for the tip.

This site seems to still be up. I gather they already moved.


Thanks, already saw that site. There's also a newer version 2.20b.
i'm not surprised that the old consoles are like this. i'd be interested in someone testing pal nes. my guess is that it's the most deviant of all.

norichan records the length of one frame in the avi header as 100/2997 seconds for ntsc and 1/25 for pal. unfortunately i can't tell you right now what the frames *are*. my guess is it will depend on the hardware. i wasn't surprised that the old consoles vary from ~the standard~ and one another so much, but i *am* surprised that it's possible to capture every frame with cheap hardware (i.e., the dazzle) when there are "too many" coming in just by changing a value in vdub. i would have expected that hardware to drop them before they reached the pc. i mean i thought that these capture devices had their own internal timers and didn't respect the time base of the analog signal. but apparently they do, or at least the dazzle does.

i can add one more thing about norichan right now which is that the data transfer loop's timing is governed by the device itself, which means that it's very possible that the easycap is sending every frame and norichan recordings will be too long (at least until you use vdub in direct stream copy mode to correct the framerate in the avi header). but again that will need to be tested.

as for the kb, i obviously have no problem with people capturing correct (i.e., the console's native) framerate, but i'm not the author of any of that stuff (except for the very old/obsolete vdub guide), so i'm going to leave it up to yall to make those corrections. remember that anyone can get an account on the kb themselves, i just have to manually approve it because of cyborg spambots.
Edit history:
DJGrenola: 2012-06-01 04:19:59 pm
guffaw
Quote from nate:
i would have expected that hardware to drop them before they reached the pc. i mean i thought that these capture devices had their own internal timers and didn't respect the time base of the analog signal. but apparently they do, or at least the dazzle does..


I would expect them all to. I think chroma decoding is done using a phase locked loop which by necessity locks on to the frequency of the incoming signal.

edit: there's a little bit about it here, in the section entitled Genlocking.
Hi I'm Kryssstal
"Correct video timing for fewer drops/inserts" should be off for VC stuff. If that option is on, then even with 59.94 capture, your recording will actually be faster than realtime due to Wii VC seeming to run at 59.824 FPS or so. The ten-thousandths digit keeps changing, but 59.824 is consistent from my testing so far.

What this means is that there's a decent chance VC is slower than SNES just from framerate differences, and that it should probably just be recorded at default 29.97 interlaced or whatever but WITH a ton of inserted frames so that it matches realtime. I don't know if there's some internal correction going on with the VC emulation, but I assume not, since I can already see a lot of processing lag evident in ALttP. Just because N64 VC is faster than original N64 hardware doesn't mean all VC stuff will be. For example, ALttP loses like a frame for every text prompt, and stuff like the attract mode lost 6 or so frames I think. I don't even know about the big laggy stuff like courtyard.
Hi I'm Kryssstal
DKC2 seems a few seconds faster on VC, at least the title screen loop. ALttP seems noticeably slower on VC. I'm just running them next to each other and making sure they're visually synced well enough after reset to see which one gains a lead. I'm probably going to just ignore VC entirely from here on out, but just know that this guide doesn't really pertain to it at all.
Edit history:
TheThrillness: 2012-06-11 05:04:11 pm
thethrillness.blogspot.com
Quote from Marlie Tang:
I don't know if there's some internal correction going on with the VC emulation


I actually had a think about this when I posted my 240p Blackmagic petition and someone on another forum came up with a good reason as to how 240p implementation is difficult. Basically, as said in first post the old consoles vary so the Intensity products would lose sync when not fed proper NTSC spec. eg Even if you used a 240 to 480 scaler the refresh rate is still different and you would need to unlock the refresh rate to be properly captureable.

However, if you feed say LttP into the Shuttle which can obviously do 480p output you will not lose sync since the Wii VC is following NTSC spec and thus the Shuttle does not lose sync. So yeah, VC does do internal correction from original hardware.
This might not be relevant for most, but I found out that 60Hz modded PAL consoles run at a different speed than the original NTSC consoles.

Super Famicom: 60.10 fps
60Hz modded PAL SNES: 59.56 fps