welcome to the machine
Been doing some testing on my own to make sure I can record properly when the time comes. I've run into a problem that may or may not be related to mismatched framerates.
My setup right now is pretty simple. Amarec and xsplit. Since amarec recordings are at 29.97 fps instead of the console's native framerate, and I could find no documentation on whether or not amarec inserts or drops frames to keep recordings in sync, I did some comparison testing. In short, I recorded with amarec, and then I also ran wsplit to get the realtime and see i they mathed.
I've run a couple tests. Wsplit gave me a time of 29:26 for the first test, and 31:13 for the second. The amarec recordings came out to be 29:21, and 31:09. I ran amarec v2.10b_en for the first, and 2.20c for the second. For the first trial, I had wsplit and the game up in xsplit as if I was streaming, and then just saved a local copy of that. For the second, I just started wsplit when I unpaused at the beginning of the game, and paused wsplit and the game when I reached the end. I didn't use xsplit on that one, since I was wondering if the problem was overtaxing my harddrive by saving two recordings at once. That didn't help, as you can see.
I was testing RKA, a genesis game. The genesis internal framerate is 59.92, or 29.96 interlaced. If amarec was recording 29.96 and then labelling it as 29.97, that only works out to be a difference of about one second faster over half an hour, which still leaves some number of seconds unaccounted for. It's not my hardware either. Following krystal's settings for vdub, I got realtime equal to recording time with no dropped frames. vdub is not a viable streaming solution tho.
No idea where I'm magically shaving these seconds. Anyone have any ideas?
My setup right now is pretty simple. Amarec and xsplit. Since amarec recordings are at 29.97 fps instead of the console's native framerate, and I could find no documentation on whether or not amarec inserts or drops frames to keep recordings in sync, I did some comparison testing. In short, I recorded with amarec, and then I also ran wsplit to get the realtime and see i they mathed.
I've run a couple tests. Wsplit gave me a time of 29:26 for the first test, and 31:13 for the second. The amarec recordings came out to be 29:21, and 31:09. I ran amarec v2.10b_en for the first, and 2.20c for the second. For the first trial, I had wsplit and the game up in xsplit as if I was streaming, and then just saved a local copy of that. For the second, I just started wsplit when I unpaused at the beginning of the game, and paused wsplit and the game when I reached the end. I didn't use xsplit on that one, since I was wondering if the problem was overtaxing my harddrive by saving two recordings at once. That didn't help, as you can see.
I was testing RKA, a genesis game. The genesis internal framerate is 59.92, or 29.96 interlaced. If amarec was recording 29.96 and then labelling it as 29.97, that only works out to be a difference of about one second faster over half an hour, which still leaves some number of seconds unaccounted for. It's not my hardware either. Following krystal's settings for vdub, I got realtime equal to recording time with no dropped frames. vdub is not a viable streaming solution tho.
No idea where I'm magically shaving these seconds. Anyone have any ideas?