Discovering length of ZMV

[Romeo]

Any way to do it? Specifically old ones recorded with zsnes 0.990.

[grinvader]

Short answer: specifically for old zmvs, nope. For new ones (after 1.42), sure.

Can the irony get any thicker ? Awaiting new challengers !

[Romeo]

It is ironic because old ZMVs do not use compression, or am I wrong?

[grinvader]

It's unrelated to compression. Old ZMVs are a byproduct of the old netplay code, and were not designed with user-interactivity in mind. The only way to discover how long it lasts is to play it to the end.
No helper programs were made to improve that interactivity (or lack thereof) either.

[Romeo]

Can you elaborate more? If there is no compression, why wouldn't it have a linear bitrate, however many bytes per frame?

I did play it to the end but it wasn't in just one sitting.

[paulguy]

Because it's not a video, really. It's more of a script that describes button presses. I'm not familiar with the format though, so I'm not sure how practical it would be for you to write a program to pick it apart, if you really cared to.

[Romeo]

It's more of a script that describes button presses.

No, it's a series of bytes that represent button presses which should be linear if there is no compression. Snes9x SMV files are 2 bytes per frame. 00 01 is the Right button and 00 80 is B for example, both pressed at the same time is 00 81.

Old ZMV format on the other hand seems 20 bytes per frame which correlates very well to the estimated lengths of all the movies I know. I just wanted to see if any expert here could confirm it.

[paulguy]

I suppose you could experiment, then.

[Romeo]

Have.

[paulguy]

Then I guess if your results are consistent, you have your answer.

[Gil_Hamilton]

It's more of a script that describes button presses.

No, it's a series of bytes that represent button presses which should be linear if there is no compression. Snes9x SMV files are 2 bytes per frame. 00 01 is the Right button and 00 80 is B for example, both pressed at the same time is 00 81.

Old ZMV format on the other hand seems 20 bytes per frame which correlates very well to the estimated lengths of all the movies I know. I just wanted to see if any expert here could confirm it.

Well, your base assumption relies on it actually recording input every frame. Personally, I wouldn't record input for frames that don't have changed input if I was worried about the admittedly trivial file size... assuming the added time code didn't offset the saved inputs.


Though your question could've gotten a more useful answer in a shorter time had you started with "Is it possible to tell a ZMV file's play length by the file size" instead of "is there any way to tell the length of a ZMV?"
In fact, it still hasn't gotten an answer that corroborates your experiment. The only actual answer is "nope, no way to tell" and I don't know if Grinvader was considering raw file length when he offered that answer, or just whether or not the format contained a run-length datum.

[grinvader]

It's more of a script that describes button presses.

No, it's a series of bytes that represent button presses which should be linear if there is no compression. Snes9x SMV files are 2 bytes per frame. 00 01 is the Right button and 00 80 is B for example, both pressed at the same time is 00 81.

Old ZMV format on the other hand seems 20 bytes per frame which correlates very well to the estimated lengths of all the movies I know. I just wanted to see if any expert here could confirm it.

Several pads can have input per frame. Not linear.

[Romeo]

Well, your base assumption relies on it actually recording input every frame. Personally, I wouldn't record input for frames that don't have changed

Then how do you know when it changes, silly boy?

input if I was worried about the admittedly trivial file size... assuming the added time code didn't offset the saved inputs.

RLE compression isn't particularly good. Snes9x movie files don't even use compression and they are way smaller than ZMV.

Though your question could've gotten a more useful answer in a shorter time had you started with "Is it possible to tell a ZMV file's play length by the file size" instead of "is there any way to tell the length of a ZMV?"

I'm unemployed, I got a lot of time and it makes no difference either way. Emulator replay length should be able to be determined by file size if no compression is used. And the method doesn't matter to me, I just wanted to find out how long this huge FF3 replay is supposed to be and see how close my estimates were. I have no intention of watching 50-60 hours of endless turn-based combat either, and even if I did it would NOT be in one sitting so this would be the worst way to determine the accuracy of length.

In fact, it still hasn't gotten an answer that corroborates your experiment. The only actual answer is "nope, no way to tell" and I don't know if Grinvader was considering raw file length when he offered that answer, or just whether or not the format contained a run-length datum.

Raw file length? I thought there was no compression... still confused.

Several pads can have input per frame. Not linear.

Pads?

[odditude]

Well, your base assumption relies on it actually recording input every frame. Personally, I wouldn't record input for frames that don't have changed

Then how do you know when it changes, silly boy?

if there was a separate entry for button-on and button-off, that would be trivial.

Emulator replay length should be able to be determined by file size if no compression is used.

unsafe assumption. example: possible input recording per frame could consist of [button presses],[button releases],[0x00]. if there are no presses nor releases, frame data would only be 0x00.

Pads?

controllers.

[Romeo]

if there was a separate entry for button-on and button-off, that would be trivial.

Yes, and you need to record how many frames the button was off (most commonly 0x00) so... the length is still fixed, otherwise you'll never know on which precise frame you pressed the button again.

unsafe assumption. example: possible input recording per frame could consist of [button presses],[button releases],[0x00]. if there are no presses nor releases, frame data would only be 0x00.

No presses OR releases? You make no sense. The button is either pressed or it isn't. If it isn't, it is most probably released.

controllers.

I've considered that but it would only make sense if ZMV used the exact same 2-byte routine as SMV but counted 9 other inactive controllers. I only know of SNES games that have 3 players so i'll assume there's at least one that has 4, so I don't see the point of having 10.

[Gil_Hamilton]

Well, your base assumption relies on it actually recording input every frame. Personally, I wouldn't record input for frames that don't have changed

Then how do you know when it changes, silly boy?

By applying some form of time stamp to the input, kiddo. A simple frame-counter would do it, and is probably there for sanity checking in the case of a full controller state per frame anyways. You're just no longer storing the frames where nothing happens.

In fact, your own ballpark estimate of 20 bytes a frame should tell you there's a LOT more going on than just a controller state for each frame, since that takes TWO bytes a frame(actually a byte and a half, but... why sweat the four extra bits?). You have 10x overhead.

input if I was worried about the admittedly trivial file size... assuming the added time code didn't offset the saved inputs.

RLE compression isn't particularly good. Snes9x movie files don't even use compression and they are way smaller than ZMV.

Depends on the application. In this case, only storing changes of state to the inputs could save you a lot of space VS storing every input every frame. How often are select and start down? Sure it's only two bits, but over hundreds of frames, those bits add up.

In fact, it still hasn't gotten an answer that corroborates your experiment. The only actual answer is "nope, no way to tell" and I don't know if Grinvader was considering raw file length when he offered that answer, or just whether or not the format contained a run-length datum.

Raw file length? I thought there was no compression... still confused.

Basically, as of yet, no one's definitively confirmed your hypothesis that file size corresponds to run time.

if there was a separate entry for button-on and button-off, that would be trivial.

Yes, and you need to record how many frames the button was off (most commonly 0x00) so... the length is still fixed, otherwise you'll never know on which precise frame you pressed the button again.

unsafe assumption. example: possible input recording per frame could consist of [button presses],[button releases],[0x00]. if there are no presses nor releases, frame data would only be 0x00.

No presses OR releases? You make no sense. The button is either pressed or it isn't. If it isn't, it is most probably released.

You misunderstand. Assuming the movie system uses the same parsing of input as the macro editor(not an unsafe assumption), it stores controller EVENTS each frame, not controller STATES.

So if someone taps and releases A every frame, rather than having a state bit for A that reads 1010101010101010101, you'd have a series of events and it'd read like APress, ARelease, APress, ARelease, APress, ARelease.
In a more complex and realistic case with a pattern like 11000111100100, it'd be something like APress, delay, ARelease, delay, delay, APress, delay, delay, delay, ARelease, delay, APress, ARelease, delay.

Again, delay can be omitted with time-stamping.
I'm not typing a multi-input example out. Go play with the macro editor for a little bit(in the MISC menu, KEY COMB.), and you'll get an idea of how it works.

[Romeo]

By applying some form of time stamp to the input, kiddo. A simple frame-counter would do it, and is probably there for sanity checking in the case of a full controller state per frame anyways. You're just no longer storing the frames where nothing happens.

In fact, your own ballpark estimate of 20 bytes a frame should tell you there's a LOT more going on than just a controller state for each frame, since that takes TWO bytes a frame(actually a byte and a half, but... why sweat the four extra bits?). You have 10x overhead.

So in the name of compression, you add timestamps and all this overhead to... make the movie 10x bigger than simply not compressing at all? That makes sense.

Depends on the application. In this case, only storing changes of state to the inputs could save you a lot of space VS storing every input every frame. How often are select and start down? Sure it's only two bits, but over hundreds of frames, those bits add up.

Yes, I see this with the highly compressed ZMVs that are 20 bytes per frame and the redundant uncompressed oversized SMVs that are only 2 bytes per frame.

Basically, as of yet, no one's definitively confirmed your hypothesis that file size corresponds to run time.

You propose stupid hypotheses but I appreciate the effort nonetheless.

You misunderstand. Assuming the movie system uses the same parsing of input as the macro editor(not an unsafe assumption), it stores controller EVENTS each frame, not controller STATES.

So if someone taps and releases A every frame, rather than having a state bit for A that reads 1010101010101010101, you'd have a series of events and it'd read like APress, ARelease, APress, ARelease, APress, ARelease.
In a more complex and realistic case with a pattern like 11000111100100, it'd be something like APress, delay, ARelease, delay, delay, APress, delay, delay, delay, ARelease, delay, APress, ARelease, delay.

Again, delay can be omitted with time-stamping.
I'm not typing a multi-input example out. Go play with the macro editor for a little bit(in the MISC menu, KEY COMB.), and you'll get an idea of how it works.

I don't see how this is the method old ZMV uses or how it would save any space. Funny that the newer 1.36 ZMV format that uses compression desyncs after 5 minutes.

[Gil_Hamilton]

So in the name of compression, you add timestamps and all this overhead to... make the movie 10x bigger than simply not compressing at all? That makes sense.

The time-stamping will be there anyways, in all probability. Beyond that, I don't see any real overhead.
All we need is events and what frame they happen on. Omitting non-events adds no overhead. Your assumption that recording input every frame is simpler and obviates the need for some form of time stamping is, frankly, naive.


As you've already noted, the emulator is apparently storing about twenty bytes a frame, so there's a 10x overhead for a 1-gamepad game regardless of what's happening internally. Even if it's storing the state for all 5 possible controllers regardless of actual configured devices, it's still a 2x overhead.

You propose stupid hypotheses but I appreciate the effort nonetheless.

I appreciate your candor, coming as it does from your complete ignorance.

I don't see how this is the method old ZMV uses or how it would save any space. Funny that the newer 1.36 ZMV format that uses compression desyncs after 5 minutes.

It actually probably IS the method used. And it's probably not for the sake of compression, but for the sake of repurposing existing functionality to do something else. Much like how the netplay code repurposes the movie code.

[grinvader]

1.00-1.36 don't desync due to to the semi-new ZMV, it desyncs due to different core.

real new ZMV is 1.42+ (and still desyncs due to core)

[paulguy]

I imagine the extra bytes are probably related to mouse or superscope or somethingg.