Currently, this is just a placeholder.
I intend to populate this page with WIP information regarding 4K dumping and frame timing correction methods for Mupen. My intention is to replace the old dumping guide with the information here once it is thoroughly tested by others.
I've given this information to Stovent over a period of time, but changes have been made during this process. It worked well for his Glover encode, so it is probably time for me to start considering publishing this information.
If all goes well, this page will be filled with useful information soon. Until then, feel free to PM me if you have any questions regarding this.
Here's the existing guide for reference, with some personal notes that I plan on writing into the updated guide. The notes are intended specifically for my own reference, so if they're incorrect or difficult to understand I apologize:

Mupen64

Target settings

ResolutionSound
variable, normally 320x240 (or multiple thereof)[2] This can be identified via GLideN64's OSD now, and can also vary depending on plugin settings44.1KHz stereo Do any games actually use 44100hz? Commonly games output 22047hz or 32006hz but it looks like the RSP handles resampling to 44100hz or 48000hz, more research should be done
RSP Research has begun: http://level42.ca/projects/ultra64/Documentation/man/pro-man/pro20/index20.2.html
Confirmed hardware sample rates: 22047hz, 32006hz, 44095hz
Un-confirmed hardware sample rates (will be removed when tested and added to the above list if true): 19196hz, 22077hz, 21617hz, 21998hz, 26807hz, 44016hz, 44050hz
WARNING: Mupen64 is notoriously unstable and difficult to work with. If you are new to encoding, you should try working with different platforms first. This text is not necessarily true and has given a lot of people the wrong impression about Mupen. With some planning, it's not a very difficult emulator to capture (compared to the problems of Gens splitting, Dolphin's sync and config issues / broken builds or PCSX-RR). Maybe rephrase this to explain the difficulty comes from the amount of steps?
http://code.google.com/p/glidehqplusglitch64/downloads/detail?name=Glide64_Final.zip---
Glide64 is outdated and has been for half a decade. This should be replaced with a link to an updated build of GLideN64 http://rustedlogic.net/wikiold/index.php?title=Nintendo_64_Emulation_plugins--- 404 not found. Strongly consider a local mirror for Azimer's HLE Audio 0.56 as it is getting increasingly difficult to find, and updated versions do not work for what we are doing here.

Guide

Windows

Mupen64's built-in dumping is very unreliable and should not be used at all (It's not so much "unreliable" as it is "instantly crashing". Aktan has developed the following alternate dumping method using a modified build of .kkapture. Replace this link with the new and improved .kkapture Aktan has compiled when our tests are completeIt is recommended, where possible, to use the Glide64 'Final' video plugin Use GLideN64 instead, see above and Azimer's audio plugin (both plugins are mirrored on that page); some segments of the following set of instructions may assume the use of those plugins The audio plugin is NOT optional for a correct audio dump.
  1. Make a backup of your plugin directory so that your old settings are preserved, as necessary. Also backup glide3x.dll in your Mupen64 root directory.Instead of "make a backup", perhaps starting with a fresh extraction is a better idea here
  2. Place the above plugins into your Mupen plugins directory, and glide3x.dll from the "wrapper" directory in the Glide64 package into the Mupen64 base directory. Wrapper hack is not needed for GLideN64
  3. Edit Plugins/Glide64.ini; change instances of "filtering = 1" to "filtering = 0", and "hotkeys = 1" to "hotkeys = 0". More Glide64 specific stuff that is no longer required
  4. Start Mupen. Good advice.
  5. Options -> Settings -> General -> uncheck "Limit FPS (auto)".
  6. Options -> Settings -> Config Plugins -> select Glide64 Napalm WX Swap this out for GLideN64. Also, this is not the version of Glide64 that was linked previously. as the video plugin and Azimer's audio plugin for audio.
  7. Go into the Glide64 configuration dialogue, check "show advanced emulation options", and close and reopen the dialogue.
  8. Set video options as seen here and here. (Note: "use frame buffer objects" may be necessary for some video cards).Some of this information is incorrect, but it will be replaced with GLideN64 so that doesn't matter. Consider compiling a list of GLideN64 settings for accuracy, and optional enhancements (along with when they should be used)
  9. Select a video resolution that is a multiple of 320x240 (or 342x256) Does N64 ever use 342x256? Investigate. Also, GLideN64's OSD tells you the native resolution, so rather than using a predefined, stick to a multiple of that, but smaller than your screen size This is only true for windowed mode. Fullscreen mode can capture up to 2x your screen resolution, for instance I have a 2560x1440 monitor which can enable capturing at 5120x2880 (5K).(antialiasing).
  10. Load your game ROM, and observe the Glide64 text at the bottom of the screen. You should see "Filtering: Automatic" specified. If it's not, you will need to exit Mupen64 and edit Glide64.ini as described in step 3. More Glide64 steps that can be removed
  11. Before doing this, wait until after the game has reached a situation where something visual has been displayed and ensure the game is NOT paused Utilities -> Movies -> Start Movie Playback Suggest familiarization with CTRL-SHIFT-P as the hotkey for this, as fullscreen doesn't have menus. Select the movie to play back, check "Open Read-Only", and enter 1 for "Pause at frame:". Click OK. The movie should now be paused on the first frame.
  12. Make a save state. CTRL-F5. Also, after making the savestate the game must be unpaused, otherwise the state can fail to create. This ensures no crashes later.
  13. Close Mupen.
  14. Check that there are no .eep files for your game in the Save directory in the Mupen root directory (playback from .kkapture as follows doesn't clear these files out, and their presence can cause desyncs). Maybe expand this to cover other save data types?
  15. Start .kkapture; configure it as seen here. Note in particular the frame rate (120fps); this is to ensure that all frames in 60fps segments are captured. Update this to the new configuration. Likely 480fps. Don't worry, it's actually a faster process now. There will be a lot of duplicate frames in the output; as such, use of a codec such as Lagarith that can store null frames is STRONGLY suggested.
  16. Set "Demo" to your Mupen executable and set "Target" to a target filename, then click "kkapture!". Mupen will start.
  17. Load the game ROM; wait for the Glide64 text to disappear (and ideally for a recognizable action to appear on the screen, so that you know when playback of the movie starts) This is no longer an ideal situation, this is a requirement as loading the movie before the game has initialized will lead to an instant freeze. See my new note below..
  18. Pause Mupen.Pause/Break key if in fullscreen
  19. Utilities -> Movies -> Start Movie Playback CTRL-SHIFT-P if in fullscreen; select the movie as earlier, check "Open Read-Only", and click OK (don't specify a pause frame). Depending on your system, you may need to alt-tab to the Mupen window (even if it's already in focus) to bring this dialog box to the front in fullscreen
  20. Load your save state from earlier. CTRL-F7 if in fullscreen
  21. Unpause Mupen - you are now capturing. Before leaving this for a long period of time, it's recommended you wait for something to happen on the screen visually to ensure the process has begun successfully Do not attempt to move any part of the emulator window off-screen - it will ruin rendering on the off-screen area.
  22. At the end of desired playback, highlight a non-Mupen window the new version of .kkapture doesn't seem to mind if Mupen is highlighted and press the right CTRL key. (WARNING: this means you can't use right CTRL during video capture!) Mupen will exit upon doing so. The new version uses RIGHT-CTRL, RIGHT-SHIFT and ? as a three-key combination, to prevent unintended termination of the capture. This was a problem I frequently experienced after several hours of capturing in the past.
This is probably where I'll add a note on the downside to .kkapture. Once Mupen loads the game window, capture starts. If for any reason Mupen reloads this window, both Mupen and .kkapture will freeze in an effective crash and the Mupen process will have to be terminated via Task Manager. This is why savestates are used on movie load, as otherwise the emulator reloads the window. Games with resets will also need special explanation on how to get around this problem, as a reset will result in a reload. This is where majority of the perceived difficulty of capturing with Mupen arises. Really, beyond configuration, you're just creating a savestate prior, and then loading the movie, then savestate afterwards for each capture.
Some notes on this method:
  1. The capture may have an extra 20 pixel border at the bottom, which should be cropped out. This only true for Windowed mode and is because Mupen renders black underneath the status bar. This means regardless if the resolution, it will always be exactly 24 pixels. For fullscreen mode, black bars will be added to pad the game video to your monitor's aspect ratio. In cases of 16:9, this means you'll have to crop off 1/8th of the width from either side. I'll likely make something automatic for this, explained below
  2. The audio plugin may add a audio delay of around 192 ms (could be a function of the sound card). This a hard value to pinpoint. 192 looks right and has continued to look right across several PCs. Could be buffer related, maybe?
  3. Duplicate frame removal is strongly recommended for captures using this method, given the number of duplicate frames in the video dump. Incremental deduplication, followed by FixFPS is the preferred method here. 480fps > Dedup > FixFPS with a divisor of 2 > 240fps > Dedup > FixFPS with a divisor of 2, etc. I have an automatic script for this process that I'll likely make public alongside this page when the time comes.
  4. The sound output may not be 44.1kHz. In fact, due to either the current state of RSP emulation or how the RSP functions - research is required - it's almost certainly not going to be. Outputs currently are not resampled and therefore unless the most likely candidates seem to be 22047hz and 32006hz. If it is not, it will generally be a very odd sampling rate, and you may resample the sound track to be 44.1kHz. Is this wise? How does the RSP handle this? Should the sample rate be kept at it's native value orhould it be resampled to some global value such as 48000hz? Or should it be rule based, with 22047 be resampled to 44100hz and 32006 resampled to 48000hz perhaps? Again, RSP research is required
  5. On certain games, the capture FPS can be set to 60 FPS for a smoother capture. It is very doubtful that any game would capture without significant audio problems at 60fps.

Linux

There is no known completely reliable way to get stock builds of Mupen to play back effectively on Linux with video dumping. Some encoders have reported success with Wine; for others it fails miserably. At least two encoders have modified builds of Mupen in order to dump video reliably; ask on the forums for more information.This information is not overly helpful and the emulator is deprecated, does it matter? Would users just ask on the forum anyway?
Additional notes: I'll likely prepare a 4-pass script for automatic frame rate adjustment via ExactDedup and FixFPS, requiring the user to only specify the game's main frame rate (eg. 60fps, 30fps, 20fps). I'll include automatic audio delay correction and resampling, cropping (with a toggle for fullscreen or windowed capture), and maybe proxy support (because repeatedly analyzing a 4K or 5K clip could take significant time, whereas saving a temp 320x240 clip and using that for analysis (but full resolution for the final output pass) would be a much better idea.
Also, given it's retention of pixel-based 2D graphics when downscaling, mention that AreaResize is preferred as the downscaler for SD encodes provided the dumping resolution is a multiple of the destination resolution. It can introduce aliasing though (although not severe) and so for ExtraHQ resolutions (eg. 720p), Lanczos (or equivalant) may be a better option though this can be up to the encoder.

Example script

In the previous section I mentioned a 4-pass script. I'd like to keep track of all my ideas here and so here is a draft of that script (requires AVS+, FixFPS and ExactDedup 0.05): https://pastebin.com/aWf18d76
It assumes the footage has been dumped in 5K (though any large resolution should work fine) and has been merged into a single output file via Virtualdub's "Append AVI Segment" and "Direct Stream Copy" to "dump_5k.avi". It also assumes that a second copy of this video has been resized down to 240 vertical lines and saved to "dump_5k_proxy_240p" for faster processing (though this can be disabled by setting UseProxy to False). Note that for the proxy system to work correctly, both clips need to be identical except for the resizing.
Additionally, for the script to function properly, no trimming should be done to the video prior to FixFPS being applied. This helps prevent incorrect frame timings and large frame drops during gameplay. Instead, there is a dedicated section for trimming at the end of the script that is applied during the fourth (output) pass.
When choosing "GameFPS" be very careful. Do not use the dumped video as a reference for this frame rate as the timnigs can vary wildly. It's a better idea to boot Mupen and load the movie, and see what frame rate it most commonly reports during the gameplay sections of the game. Mupen's values are inconsistent and fluctuate by 1-2fps consistently, so don't take the reading too literally and keep in mind that the frame rate would have to evenly divide into 60 (or 50 for PAL games). Typical values for NTSC games therefore are 60 (Super Smash Bros.), 30 (Super Mario 64) and 20 (Glover).
To use the script, load it up with pass = 0 and ensure everything loads correctly. If not, download and copy the appropriate plugins to your AVISynth directory or add the appropriate LoadPlugin lines if you'd prefer that. Once that has loaded correctly, you may close out and load the script up with Pass = 1 and run an analysis pass in Virtualdub. When that is finished, close out and do the same analysis pass for Pass = 2 and Pass = 3 (in order). Finally, load the final clip up in Pass = 4. This is your final output clip, which should now have a frame rate of 60fps and consistent motion throughout the video. If at any point during Passes 2, 3 or 4 you get a "file not found" error, run the previous pass again. This error occurs when the analysis pass has not written the duplicate information files, which only occurs when the pass finishes succesfully and Virtualdub is closed. Note: This will probably all be automatic via some batch when I get around to it.
HomePages/TheCoreyBurton/Mupen last edited by TheCoreyBurton on 2/12/2019 12:37 PM
Page History Latest diff List referrers View Source