Post subject: About the "time" of a TAS...
Active player (322)
Joined: 1/15/2012
Posts: 343
There always been something that bothers me the world of the TAS, it's the measure of time... I always heard that the time of the run was measured by the power on to the last input... But if we take for exemple the TAS of Zelda : Oracle of Seasons in 1:25:57.22 ( http://www.youtube.com/user/SwordlessLink?feature=g-u-u#p/u/1/fSb8J3sghxo ), we can see that the last input is way after. at around 1:29:10. I'm assuming I'm wrong, but can someone please explain to me how the time of the run is calculated ? (PS : I looked on the rules of making a movie, I didn't found it :( )
Skilled player (1742)
Joined: 9/17/2009
Posts: 4984
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Well, the movie must have input added at the end. Since you can just download the input file, why not check if that certain input is winthin the file, or added later? Nevermind, I see what you mean. Youtube's timer is glitched up.
Active player (322)
Joined: 1/15/2012
Posts: 343
Oh... Ok :p
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
jlun2 wrote:
Well, the movie must have input added at the end. Since you can just download the input file, why not check if that certain input is winthin the file, or added later? Nevermind, I see what you mean. Youtube's timer is glitched up.
Are you so sure it's youtube? I'm in the process of re-encoding 415M right now. The indicated VBM length in frames is 65215, or 18:06.90 if we assume each frame is exactly 1/60th of a second (and the first frame is at time 0). 18:06.90 is what the site displays for movie length. But the avi dump from VBA-RR v23.5 svn421 has input stop at frame #65581 at time 18:13.017 (again assuming each frame is exactly 1/60th of a second, as that's what the AVI file that is dumped claims) Viewing the output files in various viewers, including youtube and JWplayer, gives an end time of approximately 18:15 (expected with +2s from the logo insertion). I'm pretty sure my encodes are frame accurate to the dump and that the various players are all interpreting them correctly. It seems like the discrepancy here is that the movie file has 65215 frames but the dump by VBA stops at 65581, which I cannot explain directly. Time to look through that source code I guess..
Skilled player (1417)
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
That's a known issue in VBA. Certain frames around loading spots will be held abnormally long. The opening of Daikatana has a frame that lasts at least a second. Also, the timing of some emulators isn't exactly 60 fps. FCEUX, from my understanding, is a touch faster than that.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Ferret Warlord wrote:
That's a known issue in VBA. Certain frames around loading spots will be held abnormally long. The opening of Daikatana has a frame that lasts at least a second.
Interesting that it's able to maintain audio sync through that. Out of curiosity, is this a recent regression? I don't have any examples handy, but I know in the past when I've obsoleted some old GBA encodes, I was unable to get my replacement encode and the obsolete encode to line up exactly timing-wise.
Ferret Warlord wrote:
Also, the timing of some emulators isn't exactly 60 fps. FCEUX, from my understanding, is a touch faster than that.
The GBA itself is something like 59.7fps, but I guess that's not how VBA treats it.
Guga
He/Him
Joined: 1/17/2012
Posts: 838
Location: Chile
FCEUX FPS are 60.100 approx.
Editor, Emulator Coder, Active player (264)
Joined: 10/17/2010
Posts: 124
Good emulators will not output at exactly 60 or 50 fps, because the real hardware also doesn't.