| View previous topic :: View next topic |
| Author |
Message |
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
 Posted: 2008-01-09 23:59:34 Post subject: QuickHex |
 |
|
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:
FCM
SMV (1.43 and 1.51)
GMV
VBM
M64
MMV
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.
Last edited by JXQ on 2008-02-04 00:30:46; edited 7 times in total |
|
| Back to top |
|
 |
Wockes
Active member
Joined: 2007-05-17 13:21:21
Posts: 202
Location: Sweden
|
| Posted: 2008-01-10 01:22:25 Post subject: |
|
|
| Sweet, I have been looking for something like that for almost a week. |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-12 18:18:21 Post subject: |
|
|
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 :) |
|
| Back to top |
|
|
FractalFusion
Active player
Joined: 2005-06-15 07:54:04
Posts: 952
|
| Posted: 2008-01-14 21:39:28 Post subject: |
|
|
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.) |
|
| Back to top |
|
|
Xkeeper
Active player
Joined: 2004-12-23 20:48:31
Posts: 1161
|
| Posted: 2008-01-14 22:48:57 Post subject: |
|
|
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.
_________________
Welcome to Mariovideos! ... Sonicvideos? Metroidvideos? Maybe Megamanvideos? |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-15 00:06:41 Post subject: |
|
|
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. |
|
| Back to top |
|
|
AKA
Active player
Joined: 2006-04-24 11:05:50
Posts: 1735
Location: A little island
|
| Posted: 2008-01-15 16:48:51 Post subject: |
|
|
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.
_________________
z0MG wrote:
That's faggotry.
suggested movies |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-15 18:28:22 Post subject: |
|
|
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 :) |
|
| Back to top |
|
|
AKA
Active player
Joined: 2006-04-24 11:05:50
Posts: 1735
Location: A little island
|
| Posted: 2008-01-15 20:07:47 Post subject: |
|
|
JXQ wrote:
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.
_________________
z0MG wrote:
That's faggotry.
suggested movies |
|
| Back to top |
|
|
Mukki
Active player
Joined: 2006-08-26 13:50:26
Posts: 750
Location: United Kingdom
|
| Posted: 2008-01-15 20:24:37 Post subject: |
|
|
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. |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-15 20:47:54 Post subject: |
|
|
AKA wrote:
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.
Quote:
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.
Quote:
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). |
|
| Back to top |
|
|
upthorn
Active player
Joined: 2006-03-24 11:48:50
Posts: 1141
|
| Posted: 2008-01-15 20:54:39 Post subject: |
|
|
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
_________________
<mmbossman> it's hypocrite limbo! How low can Saturn go?
<Brushy> I have real life with school and eating and girlfriends and dogs and sleeping and stuff :/ |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-16 00:53:49 Post subject: |
|
|
Upthorn wrote:
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. |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-16 04:17:50 Post subject: |
|
|
I've updated this utility to version 3.
Updates:- 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. |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-27 23:46:15 Post subject: |
|
|
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. |
|
| Back to top |
|
|
ZeXr0
Active member
Joined: 2006-08-27 18:04:28
Posts: 479
|
| Posted: 2008-01-28 04:36:32 Post subject: |
|
|
| Could you make an option to make backup automatic ? That way, it could save a couple of mistake. |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-01-29 07:13:05 Post subject: |
|
|
Updated to v5.
Changes:- MMV support.
- Small VBM bugfix.
- Automatic backup feature.
- 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? |
|
| Back to top |
|
|
DaTeL237
Player
Joined: 2008-01-16 16:03:32
Posts: 48
|
| Posted: 2008-02-01 08:45:52 Post subject: |
|
|
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 |
|
| Back to top |
|
|
JXQ
Active player
Joined: 2005-05-06 08:13:43
Posts: 2954
|
| Posted: 2008-02-01 15:51:19 Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
DaTeL237
Player
Joined: 2008-01-16 16:03:32
Posts: 48
|
| Posted: 2008-02-01 19:16:48 Post subject: |
|
|
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.smv
http://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 |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
