QuickHex v5.1
This utility is used for quick pasting one segment of a movie file onto another file in another location without needing a hex-editor.
Currently supported formats:
FCMSMV (1.43 and 1.51)
GMVVBMM64MMV
I believe the program is self explanatory. The input file (file to copy from) is on the left, and the output file (file to copy to) is on the right. Select the frames to copy and the frame location to paste, and click Insert.
The "Offset" button will insert blank frames before inserting the copied data. This can work in many games with frame rules or areas with different "states" depending on the frame of arrival. The offset value is currently not supported with FCM.
An automatic backup is made by default of the original file before pasting, of the name "Originalfile_QuickHexBackup#.ext". (This can be disabled, if desired)
If you have suggestions or bugs to report, please post them here.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Version 2 is completed, now with FCM support. I anticipate some errors, but I've tested it in quite a few weird cases and gotten good results. What a horrible format.
I'll try M64 support next, assuming I don't have huge corrections to make with FCM.
If you find a problem with an FCM the following would be extremely helpful for debugging:
1) Input FCM
2) Output FCM
3) Frame ranges and durations used
Thanks for any feedback :)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Seems good so far. Sure beats my "QuickHex" VBM program I posted at
http://tasvideos.org/FractalFusion/Source.html.
The thing that bothers me is the duration specification requirement. Surely you want to copy as much as possible, right? (Though for GMV, it doesn't have a frame count, so it might matter.)
A quick example of not wanting to copy everything would be copying a walljump out of one movie and into another. You don't want the rest of the movie as well.
You can also enter the value into the Ending Frame field, and it will auto-calculate the duration (instead of the other way around).
Perhaps I should change the default for the input movie's ending frame, though. I do agree that in many cases, the desired range is through the end of the input movie. Currently these defaults have been lifted from the Input Animators, so they probably don't apply in the same way.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
I hope you can sucessfully incorporate .m64 at a later date. Although I feel confident enough that I don't need any sort of hexing programs like this, but I certainly would have benifited greatly from this in the earlier days. It should be very helpful to people with little or no experience in the field of hexing.
I'm working on implementing M64 today, and I have a couple questions about the format that hopefully those with N64 experience can answer.
For this particular format, I'm going by Input-Frame count, rather than actual frame count. I'm told that this is the way to go for accuracy when hex-editing M64 files.
Currently, when a segment is pasted late enough that it extends the length of the movie, I update the frame counts in the other formats. For M64, I can update the input-frame count with accuracy. However, as the real frame count is not always consistent with the input-frame count, I don't know of a way to make it accurate.
The reason it is (possibly) important to make both accurate, is due to the way that submissions are handled by the script on TASvideos. If you've read one of my complaints about FCM, one problem is that the amount of frames given in the metadata of the movie file doesn't have to correspond to the actual number of frames given by the controller data - so you can fake-out the submission script by hex-editing that value. This is one of the reasons I wrote FCMFix.
Anyway, I would imagine that the M64 submission script looks to this same value to get its time (I have no idea how else it would get it). The emulator also might stop playback when it hits the frame given, even if there is more controller data. (SMV does this, for example)
The best "solution" I have come up with at this point is the following:
When opening the files, calculate the ratio between regular frames and input frames for both files. After psting, if the new movie's input-length is longer, re-"calculate" (estimate) the number of actual frames by multiplying the new input-frames by this ratio.
Obviously not perfect..but hopefully close in most cases. I'd also throw in a pop-up advising the user to re-record the end of the movie to ensure a correct frame count.
I'm also putting in a check to make sure that all the controllers are set the same (same number, same rumble pak/memory card settings..). Does this sound like a valid safeguard? Or are there scenarios where you may want to copy data from one movie to another with different controller settings?
Blahblahblah..I'm talking too much.
To summarize, I have the following questions:
1) Is there an accurate / semi-accurate way to calculate the real-frame count based on the input-frame count?
2) If the real-frame count in the metadata is set at a shorter value than it should be for the particular movie, does the emulator stop short at that frame? Does the submission script display the wrong time?
3) Does preventing pasting between two files with different controller settings sound like a good safeguard?
Thanks for any input :)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
To summarize, I have the following questions:
1) Is there an accurate / semi-accurate way to calculate the real-frame count based on the input-frame count?
2) If the real-frame count in the metadata is set at a shorter value than it should be for the particular movie, does the emulator stop short at that frame? Does the submission script display the wrong time?
3) Does preventing pasting between two files with different controller settings sound like a good safeguard?
Thanks for any input :)
1. For most games yes since the majority of games seem to run at 30fps, and usually you need to press frame advance twice in order update the graphics. For something like SM64, you won't get an accurate real frame to input frames conversion. In order to do this universally for every N64 game you'll need to find a way to read the real frame count from the header format.
2. Yes, there seems to be a bug where the last 5 seconds go missing on odd occasions. Also when input is terminated the last frame gets replaced as all F's i.e 1's intead of 0's. This means that all the buttons and directions will get pressed and can be frustrating when you try to end the input in the middle of gameplay as it causes the game to pause.
3. Controller input doesn't matter too greatly. The only problems I've had with this is when someone uses a controller and enables the rumble feature. To be on the safeside its probally best to only allow controller inputs to be the same. On the side note I would avoid preventing users from hexing input when they have different video plugins.
Joined: 8/26/2006
Posts: 1139
Location: United Kingdom
JXQ wrote:
1) Is there an accurate / semi-accurate way to calculate the real-frame count based on the input-frame count?
It may be worth noting that whilst frame rate differs between games and may cause problems I have seen frame rates differ within games themselves. For example, in Majora's Mask the game in open play runs at 20fps, the start menu runs at 30fps and the song of soaring screen runs at 60fps.
In order to do this universally for every N64 game you'll need to find a way to read the real frame count from the header format.
The dilemma is that this header value is what I need to replace with a new value that represents the new length of the movie, which looks to be estimatable, but not certainly accurate.
Yes, there seems to be a bug where the last 5 seconds go missing on odd occasions.
I remember hearing a bit about this before, it sounds like an emulator bug during ending a recording, nothing that I could detect or fix with this utility, but perhaps it's caused by a faulty real-frame value. I'll test out the hacked-frame-count thing later today to see what the emulator does.
Controller input doesn't matter too greatly. The only problems I've had with this is when someone uses a controller and enables the rumble feature. To be on the safeside its probally best to only allow controller inputs to be the same. On the side note I would avoid preventing users from hexing input when they have different video plugins.
Ah, I forgot about plugins. I suppose what would be best is to warn the user if anything doesn't match, controllers or plugins, but still give them the ability to do copy-pasting if they really wanted.
Mukki wrote:
It may be worth noting that whilst frame rate differs between games and may cause problems I have seen frame rates differ within games themselves. For example, in Majora's Mask the game in open play runs at 20fps, the start menu runs at 30fps and the song of soaring screen runs at 60fps.
I got this impression from the M64 format page. My only idea is to get the ratio of (real frames / input frames) for both movies, and average them on the new pasted movie depending on which percentage was from which movie.
What I'm ultimately trying to avoid, is to have someone use this utility and end up with an M64 file that is submitted and gives an incorrect time, without the author even realizing that the time is incorrect (because the movie could still play in its entirety, for example, if the emulator treats it similary to FCM).
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
How about having the user enter the ratio of input frames/real frames after editing? It's their movie, so they should know what the rate is at the spot they're modifying
How fleeting are all human passions compared with the massive continuity of ducks.
How about having the user enter the ratio of input frames/real frames after editing?
Eloquent it is not, but the most accurate solution it is.
The good(?) news is that I just tested, and if the real-frame value is shortened, the movie does end early.
So I think I will ask for the number of frames, and if the user doesn't know, try to estimate it with the ratio method.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
M64 support. I tested "pasting" the Mario 64 0-star onto the 1-star, and vice versa. Both worked, though the estimated ending frame for the 0-star -> 1 star was a few frames short. Besides that, I haven't tested this format, so there may be some bugs in it. Different controller setup will disable pasting; different plugins will give a warning.
Default value to copy until the end of the input movie. I tried to make this intuitive as possible for whatever values someone might enter. If the input starting frame is blank, and a value is entered, "All remaining" will be placed in the duration field. This can also be deleted and filled in with a specific number like before.
A couple UI changes.
FCM still doesn't support offsets (M64 does). Pending that, and bugfixes, I don't think there is too much left to do. Suggestions are welcome, though. I could implement MMV.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Small update to v4.
I fixed a bug that was giving a blank Output Ending Frame if you typed in the output movie's frames before the input movie's.
I removed the FCM "beta" warning, as I haven't found any bugs during my use, and none have been posted either. I also disabled the Offset field for FCM. Currently, I am not in a big hurry to support it.
Changed the tab order and focusing a bit. New things are bolded in this common scenario:
Open input movie
Open output movie
Input starting frame now receives focus
Type the input starting frame, assuming the full duration should be copied
Tab now moves to the output starting frame
Type output starting frame
Press Enter to Insert
So a few keypresses or mouse clicks are saved in the most common case.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Error/success messages placed on main form instead of on pop-up (important errors are still on pop-ups).
Insert button becomes disabled after a successful use for about one second. It helps to see that the insert really happened.
Radio buttons on the open dialog, to filter which types of files to see (in case you keep all your files across multiple emulators in the same folder..?)
In regards to the auto-backup, I would like to get other opinions on this. I am in a huge habit of backing things up whenever I do some type of hex-editing, so the feature is actually redundant for me. I left it on as default, do others agree with this call?
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
I tried several different field-values (including using 'offset'), but all it does for me is extend the output SMV file with frames that don't have any input
example:
I want to use frames 0-37079 from file 'front'
and frames 706-4000 from file 'back'
and have them in a single SMV file right after eachother
so i enter
[from/lefthand side]
<select>
706
3293 (autocompleted)
4000
[to/righthand side]
<select>
offset = 0
startframe = 37079
it does calculate the correct ending frame... just there's no content in the second/new part
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
JXQ wrote:
I'm unable to reproduce this bug; would you mind uploading or PM-ing me SMVs that you're able to reproduce the bug with?
oops i'm sorry, i thought i added them already :P
http://dehacked.2y.net/microstorage.php/info/694924329/front.smvhttp://dehacked.2y.net/microstorage.php/info/455657786/back.smv
edit: I checked if it worked without the use of any save-states btw.. just playing it all from frame 0 onward
this front-file is actually the result of an attempt to hex-edit it, but frames 0-37080 are still valid and so is the back part, and if i try to hex these it won't work.
I'm using QuickHex v3 btw, but i dont suppose the inner workings changed
and I'm recording in snes9x v1.51
Updated the link to v5.1.
Thanks. SNES9x 1.51 was what I wasn't using to recreate the bug.
The number of controllers was being read incorrectly because of some extra bit that 1.51 sets, and because I was using a 4-byte variable for some reason instead of a 1-byte. I changed this and was able to use the program to move the data from back.smv to front.smv, but they didn't appear to sync when I watched them.
Thanks for the help in spotting this bug, DaTeL237 :)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
There are a couple isolated bugs with FCM pasting that I haven't been able to fix yet.
One happens if the input movie frame range starts at 0. This causes "Bad record number" error and crash.
The other happened to me when using QuickHex on parts of SMB3. I don't know the specific circumstances but it was related to pasting very far into a movie, so the bug probably won't show up unless your movie is larger than 65535 frames, and even then it's spotty. This also caused a crash.
I'll try to investigate these at some point, but it's not a huge priority to me right now, so... yeah.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Joined: 12/25/2007
Posts: 86
Location: Muhos, Finland
What error #70 means? My .fcm work'd on FCU whithout any problems :\.
<small>Big signature cleared by admin; read <A>forum rules</a>.</small>
<small>-Me:..and big sig. was just small picure(two row's), It dont even lag my 3660's web browser >_></small>
