Roll Eyes
Lips Sealed
<- 12
List results:
Search options:
Use \ before commas in usernames
Edit history:
VorpalEdge: 2012-12-12 06:46:23 pm
VorpalEdge: 2012-12-12 06:45:41 pm
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?
All the things
Just to note that AmaRec framerates are not hard-set, and instead a "best effort" measure. I will need to re-test this at some point later, but I think it also has to do with your capture device. Two of the devices that I use capture at around 30.04 in AmaRec, which matches up with the SNES output. I have not looked into how or if this affects recordings. I am fairly certain that a 3rd device that I formerly used only returns the 29.97 fps feed when used in the same manner. So it could be setup-dependent as well.
welcome to the machine
I've got a dazzle dvc-100 (white) and all of the recordings are 29.97.
Edit history:
VorpalEdge: 2012-12-14 09:28:01 pm
welcome to the machine
It's a gradual thing.    Ran an hour-long test and compared amarec recording to realtime every 10 mins or so.  The speedup is fairly constant -- about 1.2/1.4s per 10 mins, methodology isn't good enough to say more precisely.  Recording ended up being 8s faster at the hour mark.

I'm out of ideas.  tried dscaler to see if it would be accurate but it crashed pretty much instantly, so fuck that.  May end up just buying an easycap to stream with. =/
I am in the exact same situation - amarec/xsplit to record/stream and the same capture device (dvc 100). Would it suffice enough to simply *know* the recordings aren't completely accurate, with the potential to manually do the maths afterwards or something? I don't particularly want to include a second capture card into my hardware setup either.
Can anyone confirm or deny the fact that a modded PAL SNES has an inferior framerare than a native NTSC SNES ? Thanks.
I can confirm to you that my test from last year was correct and my console was professionally modded Wink
I don't know anyone else who has both a modded PAL SNES console and the hardware to measure exact video frequency, so it might be just an outlier. But my guess is that the PAL crystal just can't get the exact same frequency as the ones used for NTSC. Theoretically you could switch the crystal (losing the exact PAL timings), but even without that the mod for a PAL console is more expensive than buying a used NTSC console.
Really ? The mod I saw here didn't seem expensive at all. But I might need to get a NTSC console if the framerate is indeed different. Thank you very much.
The one you linked is an older version. The current form for the mod is the "switchless mod". I guess I remember it as being expensive cause I shipped it to a professional. Just checked the parts again: PIC (1,89€), 3 resistors, 1 LED, wire, Nintendo bits and the Hardware to write the chip. So if you have an epromer and are confident in soldering you could do it for a few Euros. Difference to an NTSC console isn't that far, but it might matter for speedrun timing.
I love YaBB 1G - SP1!
I recorded my zombies and metal warriors runs on vdubmod, but dont recall if it had the timing option on or not, anyway how much % is added if it isnt?
Okay, this is a weird problem.  My totally 2:17:56 real-time run is about 1:55:00 of video.  I'm using composite cables and an Honestech vhs-to-dvd capture device with the software that comes with it.  That doesn't have any options to change the framerate--which I can only assume is the problem.  Will this persist if I switch to virtualdub?
Quote from blizzz:
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

Does that also accord to the switchless mod (SuperCIC mod)? Because I have a Super Famicom and a PAL SNES with the previous mentioned switchless 60 Hz mod and I compared them but I couldn't notice any difference. I played Duck Tales GB on Super Gameboy 2 and and it ran at the same speed. Timing method: I used livesplit as a timer and started it with the level select (Moon stage) and ended it after time up. I did that for both consoles, Super Famicom and PAL SNES running on 60Hz. Maybe I am doing something wrong at this point, I am not sure. Or could it be that the switchless mod is actually pretty accurate nowadays and a modded PAL SNES is running at the same speed as a Super Famicom.
That's not a good way to test - Super Game Boy devices run at their own frame rate, independent of the console they're plugged into.

An SGB is basically a full-fledged Game Boy, with the LCD replaced with a custom video capture device and some hardware added for the SNES interface.
Quote from Grygor:
Super Game Boy devices run at their own frame rate, independent of the console they're plugged into.

Well that's a point I haven't thought about but makes everything seem logical now. I thought the whole time that the slightly lower framerate of the modded PAL SNES would also affect the speed of the SGB2. Thanks for clarifying that up.
pld, my console was modded with the SuperCIC mod. There's a new mod for 1CHIP PAL SNES consoles that adds a second timing crystal for 60Hz. That mod should show no differences to a real NTSC console.

There's also a way to add a timing crstal switching circuit to other modded consoles like the PS1, but I haven't seen that actually being implemented by modders. I've only seen some prototypes.
That sounds interesting. Since the SGB 2 is not using the consoles frame rate, is it known at what frame rate it is actually running? Original Game Boy frame rate (59.73 Hz)?
SGB2 I believe does run at the regular gameboy frame rate.
does the PS2's 62fps make a difference?
(or is that an emulation error?)
B+Left, Left, Up+B, ★
I've been curious about the framerate on a few consoles, but had no idea where to look for this info for anything other than NES/SNES/GEN. I talked to Pasky/ConHuevos about it a little and he linked me to the source code for BizHawk, which has many of the precise framerates for various consoles.

Quote from Bizhawk source code:
                                { "NES", 60.098813897440515532 ,  (19687500 / 11) / ((341*262-0.529780.5)/3),
                                { "NES_PAL", 50.006977968268290849 ,
                                { "FDS", 60.098813897440515532 },
                                { "FDS_PAL", 50.006977968268290849 },
                                { "SNES", (double)21477272 / (4 * 341 * 262) }, //60.098475521
                                { "SNES_PAL", (double)21281370 / (4 * 341 * 312) }, //50.0069789082
                                { "SGB", (double)21477272 / (4 * 341 * 262) }, //60.098475521
                                { "SGB_PAL", (double)21281370 / (4 * 341 * 312) }, //50.0069789082
                                { "PCE", (7159090.90909090 / 455 / 263) }, //59.8261054535
                                { "PCECD", (7159090.90909090 / 455 / 263) }, //59.8261054535
                                { "SMS", (3579545 / 262.0 / 228.0) }, //59.9227434043
                                { "SMS_PAL", (3546893 / 313.0 / 228.0) }, //49.7014320946
                                { "GG", (3579545 / 262.0 / 228.0) }, //59.9227434043
                                { "GG_PAL", (3546893 / 313.0 / 228.0) }, //49.7014320946
                                { "SG", (3579545 / 262.0 / 228.0) }, //59.9227434043
                                { "SG_PAL", (3546893 / 313.0 / 228.0) }, //49.7014320946
                                { "NGP", (6144000.0 / (515 * 198)) }, //60.2530155928
                                { "VBOY", (20000000.0 / (259 * 384 * 4)) },  //50.2734877735
                                { "Lynx", 16000000.0 / ( 16 * 105 * 159 ) }, // 59.89817310572028
                                { "WSWAN", (3072000.0 / (159 * 256)) }, //75.4716981132
                                { "GB", 262144.0 / 4389.0 }, //59.7275005696
                                { "GBC", 262144.0 / 4389.0 }, //59.7275005696
                                { "GBA", 262144.0 / 4389.0 }, //59.7275005696
                                { "GEN", 53693175 / (3420.0 * 262) },
                                { "GEN_PAL", 53203424 / (3420.0 * 313) },
                                // while the number of scanlines per frame is software controlled and variable, we
                                // enforce exactly 262 (NTSC) 312 (PAL) per reference time frame

                                { "A26", 315000000.0 / 88.0 / 262.0 / 228.0 }, // 59.922751013550531429197560173856
                                // this pal clock ref is exact

                                { "A26_PAL", 3546895.0 / 312.0 / 228.0 }, // 49.860759671614934772829509671615
                                { "A78", 59.9227510135505 },
                                { "Coleco", 59.9227510135505 },

                                //according to
                                {"PSX", 44100.0*768*11/7/263/3413}, //59.292862562
                                {"PSX_PAL", 44100.0*768*11/7/314/3406}, //49.7645593576
Thanks for that, interesting numbers. It's a pity Super Gameboy 2 and GameCube GB Player are not included, that would be interesting to know.
Hasn't the SGB2 been confirmed to run at the GB rate?
To be fair, that list is the display rate, which for SGB/GBP is just going to match the frame rate of the host console anyway. (Gameboy frames are repeated/skipped as needed on the host console.)

Also keep in mind there are some (admittedly pedantic, but numbers with 11 to 15 significant figures are already pretty pedantic) inaccuracies because
                // these are political numbers, designed to be in accord with tradition. theyre not necessarily mathematical factualities (although they may be in some cases)
                // it would be nice if we could turn this into a rational expression natively, and also, to write some comments about the derivation and ideal valees (since this seems to be where theyre all collected)
                // are we collecting them anywhere else? for avi-writing code perhaps?

Just as an example, both NES and SNES should have the exact same value ( 6 * fc / ( 1364 * 262 - 2 ) for NTSC ) because they use identical video timing generation, with the only difference being that the SNES also has a rarely-used interlaced mode (NTSC field rate 6 * fc / ( 1364 * 262.5 ) ). ( fc = color subcarrier frequency = 60 * 262.5 * 227.5 / 1.001 plus or minus 0.00003% for NTSC)

Incidentally, since the crystal oscillators used in non-portable consoles (and Sega portables) have a tolerance of 3 parts per million, it's wrong to specify frame rate with more than 7 significant figures.  And the crystal oscillators in non-Sega portables have tolerances of 20 to 100 PPM, so it's a mistake to specify portable frame rate with more than 5 or 6 significant figures.