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.
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: