This run should be 3 seconds slower.

2013-04-30 04:24:20 pm

welcome to the machine

I wrote about this previously, in cyghfer's mysterious gained seconds topic. See here. Basically, amarec is giving me recordings that are some seconds faster than real time. I'll refrain from repeating all of the details here.

My original solution was to just switch setups and record/stream using vdub. Well, I tried that a few days ago, and after 50 minutes of streaming the sound suddenly decided to delay by a second. Then half an hour after restarting the recording, the same thing happened. That doesn't show up in the file so I could probably still /record/ using that, but I couldn't stream at the same time, so whatever. May as well actually solve the particular problem this topic is focused on, since I suspect others have been hit by it too, unbeknownst to them.

so. I have an Ecco run. The recording comes out to be 18:14.9. The problem is that the final time should be closer to 18:17 or 18:18. This is verified by Wsplit and my xsplit local recording, which both match up. I can't record runs anymore until I get a setup that won't make my final time a lie, soooo yeah.

I recorded using amarectv v2.10b-en. Switching to a later version didn't help, and the program seemed more unstable besides. I screencapped pics of the relevant settings and attached them. I've also attached the MQ encode (from anri) and the anri logs. The source is 11 gigs big; I'm not opposed to torrenting that in but I'd like confirmation it'd be useful to someone first.

links:
ecco mq encode
xsplit local recording

Thread title:

I wrote about this previously, in cyghfer's mysterious gained seconds topic.  See [url=https://forum.speeddemosarchive.com/post/important_analog_capture_frame_rates_and_mysterious_gained_seconds_26.html#important_analog_capture_frame_rates_and_mysterious_gained_seconds_26]here[/url].  Basically, amarec is giving me recordings that are some seconds faster than real time.  I'll refrain from repeating all of the details here.

My original solution was to just switch setups and record/stream using vdub.  Well, I tried that a few days ago, and after 50 minutes of streaming the sound suddenly decided to delay by a second.  Then half an hour after restarting the recording, the same thing happened.  That doesn't show up in the file so I could probably still /record/ using that, but I couldn't stream at the same time, so whatever.  May as well actually solve the particular problem this topic is focused on, since I suspect others have been hit by it too, unbeknownst to them.

so.  I have an Ecco run.  The recording comes out to be 18:14.9.  The problem is that the final time should be closer to 18:17 or 18:18.  This is verified by Wsplit and my xsplit local recording, which both match up.  I can't record runs anymore until I get a setup that won't make my final time a lie, soooo yeah.

I recorded using amarectv v2.10b-en.  Switching to a later version didn't help, and the program seemed more unstable besides.  I screencapped pics of the relevant settings and attached them.  I've also attached the MQ encode (from anri) and the anri logs.  The source is 11 gigs big; I'm not opposed to torrenting that in but I'd like confirmation it'd be useful to someone first.

links:
[url=https://docs.google.com/file/d/0BzM7ti8dj0VdVGRIZElUTnZBTlk/edit]ecco mq encode[/url]
[url=https://docs.google.com/file/d/0BzM7ti8dj0VdUVN3SVJwbC1hSEk/edit]xsplit local recording[/url]

Attachments:

2013-04-30 04:33:07 pm

Not a walrus

If you load it into virtualdub, and go to Video -> Frame Rate, does it give you an option to "Change Frame Rate so the durations match"? And if you do that, does it match your wsplit time?

VorpalEdge

Edit history:

VorpalEdge: 2013-04-30 04:51:59 pm

VorpalEdge: 2013-04-30 04:50:43 pm

2013-04-30 04:50:29 pm

welcome to the machine

the default frame rate is 29.970. that option is there, but then it says the required framerate for the audio and video durations to match is 29.970, and so the resulting framecount is identical.

UraniumAnchor

2013-04-30 04:53:17 pm

Not a walrus

This is one of many reasons I dislike Amarec. Sorry, can't really be of any more help, then.

nate

2013-04-30 05:00:03 pm

do we have a better citation for the genesis field or frame rate?

might be interesting to scan your video for duplicate frames. iirc there's an avisynth plugin that does it but i don't know much more than that off the top of my head.

Omnigamer

Edit history:

Omnigamer: 2013-04-30 05:17:42 pm

2013-04-30 05:15:43 pm

All the things

My understanding of how AmaRec records is that it will take whatever the actual input frequency is, rather than a hardset NTSC frequency. The framerate that you "set" it to is more of a best guess, as the resulting recording rate can differ. When recording SNES footage, AmaRec consistently captures as ~30.04 fps (matches the internal rate), but I'm not sure how this affects the final videos. My guess is that it's using the true Genesis output rate but still trying to play back the file at NTSC speeds. There's also a good possibility that the capture device could play a role in it too.

mike89

2013-04-30 05:20:41 pm

SEGA Junkie

As an aside, both the runs of mine that went up in the Big Push (Quackshot and Wario Land 4) were recorded with Amarec. I went and timed the files against wsplit and the twitch recording and it came up exactly the same on both. So clearly Amarec doesn't perform this way on all machines.

VorpalEdge

Edit history:

VorpalEdge: 2013-04-30 06:03:32 pm

2013-04-30 05:43:18 pm

welcome to the machine

Quote from nate:

do we have a better citation for the genesis field or frame rate?

the source is the bizhawk source, actually. and for what it's worth, if I use record at 29.96 in vdub with the correct timing for fewer drops option on, it works perfectly.

Quote:

might be interesting to scan your video for duplicate frames. iirc there's an avisynth plugin that does it but i don't know much more than that off the top of my head.

you mean running something like the GetDups plugin I just found through googling? yeah, I'll try that now.

[edit]i think it's trying to determine dupes in realtime. plays a few frames, then pauses for 5-10 seconds, then plays another 10 frames...... and it crashed.

omni: playing the video back at 29.96 makes the video time 18:15, which isn't close enough to the true time for me to be comfortable saying that's it.

[quote="nate"]do we have a better citation for the genesis field or frame rate?[/quote]

the source is the bizhawk [url=http://code.google.com/p/bizhawk/source/browse/trunk/BizHawk.Emulation/Consoles/Sega/Genesis/Genesis.cs?r=2235]source[/url], actually.  and for what it's worth, if I use record at 29.96 in vdub with the correct timing for fewer drops option on, it works perfectly.

[quote]might be interesting to scan your video for duplicate frames. iirc there's an avisynth plugin that does it but i don't know much more than that off the top of my head.[/quote]

you mean running something like the [url=http://avisynth.org/mediawiki/External_filters#Duplicate_Frame_Detectors]GetDups[/url] plugin I just found through googling?  yeah, I'll try that now.

[edit]i think it's trying to determine dupes in realtime.  plays a few frames, then pauses for 5-10 seconds, then plays another 10 frames...... and it crashed.

omni: playing the video back at 29.96 makes the video time 18:15, which isn't close enough to the true time for me to be comfortable saying that's it.

bos

ballofsnow

Edit history:

ballofsnow: 2013-04-30 06:11:25 pm

2013-04-30 06:04:30 pm

anri uses the filter "dup" a little. You can look through the code if needed

edit- forgot I had this link saved in the anri to-do: https://forum.speeddemosarchive.com/post/auto_decimate_no_more_f_database.html

VorpalEdge

2013-05-01 02:29:12 pm

welcome to the machine

Frames counted: 63722
Unique: 57378
Percentage: 90

Attachments:

dup.txt

test.avs

bos

2013-05-01 04:00:42 pm

the script is an example and serves a different purpose than what you need. you'd have to fiddle around with the tolerances and check the log that dup creates to inspect for duplicate frames

VorpalEdge

Edit history:

VorpalEdge: 2013-05-02 01:55:16 pm

2013-05-02 01:55:03 pm

welcome to the machine

I'm not sure what I should even be looking for, let alone how to fiddle with it. =/

Would buying an easycap be a reasonable investment at this point? How does its quality compare to a dazzle?

bangerra

Edit history:

bangerra: 2013-05-03 05:17:12 am

2013-05-03 05:16:27 am

Easycaps are hit and miss. They support a limited amount of resolutions, and some resolutions look way worse than others. For example: it captures my SNES, Gen, and SMS perfectly but it shows major heatwaves for the NES for some bizarre reason.
It also doesn't support PAL60 (mine doesn't, it might differ) and it BSODs my pc when I try to record PAL60.
Great device no? It's very cheap though and I use it for streaming through my laptop while I record the raw footage on my desktop using a built in cap card.
I'd say it's a nice tool, but don't use it for capturing actual runs. (I have no easy SD alternative ready besides ezcap and dazzle though).

DJS

2013-05-03 07:02:14 am

torch slug since 2006

i prefer the easycap over the dazzle, mainly cause my dazzle just has been a pain in the ass since i got it, while my easycap (that nate sent me) has worked perfectly, except that the s-video port died.
but yeah, since nate sent me one, he already tested it to see that it was good, so you might get unlucky if you randomly buy one.

i'd say the quality is about the same when it comes to d4 stuff (nes, snes etc) but i think the dazzle has an + when it comes to wii/360/ps3.

getting the EzCap for this guide, and following it might be interesting for you https://forum.speeddemosarchive.com/post/complete_creating_sda_acceptable_videos_ezcap_guide_.html