ROM Hack Metroid: Other M Redux (Based on Maxximum Edition)

[Hu555h]

update, it did work using wiiBaFu, using no-unlocks.dol and the gecko codes is what worked, other .dol files didn't even boot up

 

[Nintendo Maniac]

Are there supposed to be a bunch of PNG, MP3, and FLAC files in the bgm and ost folders? (I downloaded using the torrent)

Also, do you know if using v1.0 or using v1.1 of Other M makes a difference?

 

[ShadowOne333]

Are there supposed to be a bunch of PNG, MP3, and FLAC files in the bgm and ost folders? (I downloaded using the torrent)

Also, do you know if using v1.0 or using v1.1 of Other M makes a difference?

Those aren't supposed to be there.
You should only have the .aix files. All the PNG, MP3 and FLAC files are auto-generated by Archive.org upon file upload.
The same happened with the sfd files. it autogenerated an MPEG file out of them.
You can safely remove those.

All my testing was done using v1.1 of Other M, the one with the "UPDATE" folder in the files.
I haven't tested v1.0, so that could be another test setup to try out.

 

[Nintendo Maniac]

Less obvious is that there's a bunch of .afpk files in the root of the "DATA" partition as well as in the "bgm" and "ost" folders that also don't exist in the original game. Presumably those files are also unnecessary?

EDIT: Forgot to say, using an uncompressed ISO does indeed work via NTFS, so the WBFS conversion isn't actually necessary.


That being said, I can also confirm that I managed to make a 1.8GB xdelta patch using WiiScrubber's individual file "replace" file function that similarly "just worked", turning an unmodified copy of USA v1.1 Other M into redux. Currently it only contains what is my impression to be the baseline "required" files which means no modified main.dol (I added it into the resulting patched ISO, again via WiiScrubber, in order to actually do the testing) nor the optional ost, title sceen music, and subtitle file.

...but I was not able to replace the following four "movie" files because the custom files are larger than the originals. I don't suppose you could make a special one-off copy of these four files with greater compression so that they can have a file size equal to or smaller than the originals? (ideally recompressed from the "master" copies presumably stored on your PC rather than the already-encoded versions currently on archive.org):

• dm09_02.sfd
• dm46to49.sfd
• dm61to63A.sfd
• dm63Bto64.sfd

Also, can someone do a sanity check and make sure these are the minimum required files? (save for the aforementioned main.dol and the above-listed too-large 'movie' files of course) These are all of the files I included in my preliminary xdelta patch file I used for testing (the following SHA1 and SNA256 checksum files will be automatically deleted in a few months):

• SHA1 checksums
• SHA256 checksums

 

[ShadowOne333]

Less obvious is that there's a bunch of .afpk files in the root of the "DATA" partition as well as in the "bgm" and "ost" folders that also don't exist in the original game. Presumably those files are also unnecessary?

EDIT: Forgot to say, using an uncompressed ISO does indeed work via NTFS, so the WBFS conversion isn't actually necessary.


That being said, I can also confirm that I managed to make a 1.8GB xdelta patch using WiiScrubber's individual file "replace" file function that similarly "just worked", turning an unmodified copy of USA v1.1 Other M into redux. Currently it only contains what is my impression to be the baseline "required" files which means no modified main.dol (I added it into the resulting patched ISO, again via WiiScrubber, in order to actually do the testing) nor the optional ost, title sceen music, and subtitle file.

...but I was not able to replace the following four "movie" files because the custom files are larger than the originals. I don't suppose you could make a special one-off copy of these four files with greater compression so that they can have a file size equal to or smaller than the originals? (ideally recompressed from the "master" copies presumably stored on your PC rather than the already-encoded versions currently on archive.org):

• dm09_02.sfd
• dm46to49.sfd
• dm61to63A.sfd
• dm63Bto64.sfd

Also, can someone do a sanity check and make sure these are the minimum required files? (save for the aforementioned main.dol and the above-listed too-large 'movie' files of course) These are all of the files I included in my preliminary xdelta patch file I used for testing (the following SHA1 and SNA256 checksum files will be automatically deleted in a few months):

• SHA1 checksums
• SHA256 checksums

Wow fantastic work there, thank you so much!
Did you end up testing an uncompressed ISO with both the redux.dol and/or redux-no-unlocks.dol?
That kind of patching looks promising, and way better to avoid any kind of conversion hassles. I might even do a BPS patch if it is indeed within possibilities down the road, since I think that one has better compression than XDelta.

As for the SFD files, there's a lot of issues with those.
I cannot change the compression because it is tied to the method of conversion I used.
Those files NEED to use the sfdmuxg software, which doesn't provide any kind of compression options to make the files smaller, with two very specific video and audio formats for the output SFD, those being MPEG-1 (M1V iirc, I think M2V is also compatible) and for audio AIX or SFA files, which should be converted with either AIX Maker or the actual Dreamcast Movie Creator.

It is possible to create SFD files through other methods which do reduce the size of the SFD files significally (like more than half the size), but if I use any other software that isn't those one mentioned, the final SFDs end up having a lot of issues during playback in-game.
We went through a lot of testing back some months ago with the developer of the True Japanese mod, and I ended up defining the exact steps and method so the SFDs work properly in-game. Any other way just ends up with frozen video or a crash, so sadly there's not much I can do there other than to wait out on better SFD creation methods. :/

 

[Nintendo Maniac]

Did you end up testing an uncompressed ISO with both the redux.dol and/or redux-no-unlocks.dol?

redux.dol crashes at the "LOADING..." that appears when you select "start game" after choosing a save file, and this happens regardless of whether you had Other M save data present already or not.

However, it turns out that, after that crash, save data gets created on your console. If you subsequently switch over to the redux-no-unlocks.dol, then you'll have everything unlocked and it doesn't crash.

(it's possible that you don't have to go all the way to the "LOADING..." crash for save data to be written to your console, but I didn't investigate it that deeply)

That kind of patching looks promising, and way better to avoid any kind of conversion hassles.

WiiScrubber has its own type of hassles, that being you can only replace a single file at a time and, as I listed in my checksum files, there's like 100 files... (this is of course assuming that all of those files are part of the minimum requirement, hence my request for a look-over of them)

I might even do a BPS patch if it is indeed within possibilities down the road, since I think that one has better compression than XDelta.

Last I tried a couple of years ago, all BPS-creation software borks out when you start getting to sizes upwards of 2GB (the current preliminary xdelta patch being 1.8GB, and that's without those 4 missing 'movie' files).

Besides, the theory is that compressing them into a single 7z archive with a very large dictionary size would net much greater savings with regards to what I previously said about how the LZMA compression algorithm takes into account redundant data. This would be especially the case since the xdelta patch was only like 2MB smaller if I used its built-in maximum compression rather than using zero compression at all.

As for the SFD files
...
I cannot change the compression because it is tied to the method of conversion I used.

What about simply making them lower resolution and/or of a lower frame rate? The encoded versions are 640x480 at 30000/1001 fps (commonly referred to as 29.97 fps) - is that a hard requirement?

 

[ShadowOne333]

redux.dol crashes at the "LOADING..." that appears when you select "start game" after choosing a save file, and this happens regardless of whether you had Other M save data present already or not.

However, it turns out that, after that crash, save data gets created on your console. If you subsequently switch over to the redux-no-unlocks.dol, then you'll have everything unlocked and it doesn't crash.

(it's possible that you don't have to go all the way to the "LOADING..." crash for save data to be written to your console, but I didn't investigate it that deeply)

Interesting.
I assume the change in the DOL automatically creates the save data, I don't think entering a game makes a difference, since I remember when I was doing my testing that even with a blank file, as soon as you get to the main menu you see the unlocked features.

The game freezing on the Loading screen sure is one thing to consider since that's consistent among all tests in real hardware with the latest DOL.
I have some other ideas, but that'd have to wait until January sadly since I don't have means to test right now, not even on Dolphin, but I do have some other ideas to try out

WiiScrubber has its own type of hassles, that being you can only replace a single file at a time and, as I listed in my checksum files, there's like 100 files... (this is of course assuming that all of those files are part of the minimum requirement, hence my request for a look-over of them)

That sounds annoying, but possibly could be alleviated by making a script for all the injection of the files. One that recognizes the file names and enters them into the Scrubber command or something similar.

Last I tried a couple of years ago, all BPS-creation software borks out when you start getting to sizes upwards of 2GB (the current preliminary xdelta patch being 1.8GB, and that's without those 4 missing 'movie' files).

Besides, the theory is that compressing them into a single 7z archive with a very large dictionary size would net much greater savings with regards to what I previously said about how the LZMA compression algorithm takes into account redundant data. This would be especially the case since the xdelta patch was only like 2MB smaller if I used its built-in maximum compression rather than using zero compression at all.

How big if a difference does a BPS patch have against an XDelta one in size for general purposes? I can't recall at the moment but it could be worth looking into it for having an easier way to handle the hack.

What about simply making them lower resolution and/or of a lower frame rate? The encoded versions are 640x480 at 30000/1001 fps (commonly referred to as 29.97 fps) - is that a hard requirement?

That's one thing I haven't properly tested.
Possibly making them a lower frame rate could work, but I found that the frame rate tends to get very finicky when doing the conversion to SFD. The resolution could be more open ended, but possibly I could reduce it just a bit so it saves just enough space to cover the existing space.

Thankfully I made a thorough guide for creating everything, from the video file to the audio and then the SFD in the OP, so I can test that rather quickly with the proper ffmpeg commands and converting the file.
I can even test that by extracting the already modified assets from my SFD files to change them accordingly.

 

[Nintendo Maniac]

That sounds annoying, but possibly could be alleviated by making a script for all the injection of the files. One that recognizes the file names and enters them into the Scrubber command or something similar.

That seems unecessary since I've already gotten the "baseline" patch created, no? I'm not planning to keep it all to myself, but my internet upload is slow at ~100KB/s (not a typo) which is why I've not immediately shared it.

How big if a difference does a BPS patch have against an XDelta one in size for general purposes? I can't recall at the moment but it could be worth looking into it for having an easier way to handle the hack.

I honestly have no idea because, once you start getting above 1GB, it becomes irrelevant because I can't even create BPS patches that large without the programs crashing. For years I was a major proponent of BPS over XDelta... until I started trying to make 1GB+ patches. It's my impression that BPS as a format can handle them without issue, but that nobody actually made any software to be able to properly handle such use-case.

Regardless, my idea is to package the uncompressed XDelta patch into the same 7z archive as the stand-alone files which should, in theory, take up the same amount of disk space as if you only has a single copy of those files as long as the 7z archive is configured to have a large dictionary size.

Possibly making them a lower frame rate could work

One thing is that, technically only exact even multiples would look judder-free, like 15fps which is exactly half of 30fps, but 15fps would look rather bad compared to something like 20fps or I guess 24fps which inherently has some judder on 60Hz displays.

We could always use some super-fancy motion interpolation if we wanted to make it judder-free - I did this on the preliminary version of an unrelated project "Fae/hollow ataraxia Ultimate Edition" where the OP videos sourced from the Vita version are 24fps in a 30fps container (every 4th/5th frame was repeated), but there was one scene where it was clearly originally rendered at 30fps but truncated to 24fps before then being packaged in that 30fps container, that is every 3rd/4th frame "jumped" in the way you get when a frame is skipped (only for the 4th/5th to be a repeat of course). So after removing the repeating frames to make it true 24fps, we interpolated that one problematic scene by 8x in order to recreate the removed frame between the 3rd/4th but now at a way higher (interpolated) frame rate so we could properly truncate to 24fps without judder (so three out of every four frames were actually interpolated in the final 24fps video).

Thankfully I made a thorough guide for creating everything, from the video file to the audio and then the SFD in the OP, so I can test that rather quickly with the proper ffmpeg commands and converting the file.

Is this guide available anywhere, like linked on the archive.org page?

I can even test that by extracting the already modified assets from my SFD files to change them accordingly.

This is one case where just using WiiScrubber directly to replace the file would work well - if WiiScrubber complains there's not enough free space, then it's too big. If it doesn't, then the resulting ISO is already "ready to use" and doesn't require reassembling or the like.

...though, now that I've typed that, I just remembered the whole FAT32 4GB file size limitation. I do suppose that would make it a bit more difficult to quickly test on real hardware, but it at least makes it easy to determine how small the resulting files would need to be to make WiiScrubber happy. And while on that subject, I'm not actually 100% sure that the files need to be smaller than the originals, hence my suggestion of doing some trial-and-error.

 

[ShadowOne333]

That seems unecessary since I've already gotten the "baseline" patch created, no? I'm not planning to keep it all to myself, but my internet upload is slow at ~100KB/s (not a typo) which is why I've not immediately shared it.


I honestly have no idea because, once you start getting above 1GB, it becomes irrelevant because I can't even create BPS patches that large without the programs crashing. For years I was a major proponent of BPS over XDelta... until I started trying to make 1GB+ patches. It's my impression that BPS as a format can handle them without issue, but that nobody actually made any software to be able to properly handle such use-case.

Regardless, my idea is to package the uncompressed XDelta patch into the same 7z archive as the stand-alone files which should, in theory, take up the same amount of disk space as if you only has a single copy of those files as long as the 7z archive is configured to have a large dictionary size.


One thing is that, technically only exact even multiples would look judder-free, like 15fps which is exactly half of 30fps, but 15fps would look rather bad compared to something like 20fps or I guess 24fps which inherently has some judder on 60Hz displays.

We could always use some super-fancy motion interpolation if we wanted to make it judder-free - I did this on the preliminary version of an unrelated project "Fae/hollow ataraxia Ultimate Edition" where the OP videos sourced from the Vita version are 24fps in a 30fps container (every 4th/5th frame was repeated), but there was one scene where it was clearly originally rendered at 30fps but truncated to 24fps before then being packaged in that 30fps container, that is every 3rd/4th frame "jumped" in the way you get when a frame is skipped (only for the 4th/5th to be a repeat of course). So after removing the repeating frames to make it true 24fps, we interpolated that one problematic scene by 8x in order to recreate the removed frame between the 3rd/4th but now at a way higher (interpolated) frame rate so we could properly truncate to 24fps without judder (so three out of every four frames were actually interpolated in the final 24fps video).


Is this guide available anywhere, like linked on the archive.org page?


This is one case where just using WiiScrubber directly to replace the file would work well - if WiiScrubber complains there's not enough free space, then it's too big. If it doesn't, then the resulting ISO is already "ready to use" and doesn't require reassembling or the like.

...though, now that I've typed that, I just remembered the whole FAT32 4GB file size limitation. I do suppose that would make it a bit more difficult to quickly test on real hardware, but it at least makes it easy to determine how small the resulting files would need to be to make WiiScrubber happy. And while on that subject, I'm not actually 100% sure that the files need to be smaller than the originals, hence my suggestion of doing some trial-and-error.

The tutorial for making SFD files is in the OP.
Same for the AIX files, I posted the exact commands to use for ffmpge, and then what to do with the files in sfdmux. That should do it.

It's a matter of just taking my modified SFD files, using ffmpeg to extract the video and two audio tracks, then edit the video with another ffmpeg command to change either the frame rate or resolution and redoing the SFD with the modified mpeg file.

 

[Pokemonfan6498]

this mod literally killed my previous wii when i used riivolution files on dolphin when rebuilding the iso

 

[Nintendo Maniac]

Older Wii consoles install bootmii as boot2 (such as on my launch-day unit), so you can unbrick by simply booting straight into bootmii and loading a NAND backup.

(also, you're not supposed to use the riivolution-specific files for rebuilding an ISO, not to mention we already established Dolphin-compiled ISOs don't work on real hardware as it was me that not only came up with the original idea of using Dolphin for ISO creation, but was also me that subsequently tested and confirmed it doesn't work on real hardware.)

While I'm here, just wanted to say I've not yet done anything more with the xdelta patch stuff.

 

[Pokemonfan6498]

this mod should be banned because it completely killed my previous wii

Post automatically merged: Dec 22, 2024

Older Wii consoles install bootmii as boot2 (such as on my launch-day unit), so you can unbrick by simply booting straight into bootmii and loading a NAND backup.

(also, you're not supposed to use the riivolution-specific files for rebuilding an ISO, not to mention we already established Dolphin-compiled ISOs don't work on real hardware as it was me that not only came up with the original idea of using Dolphin for ISO creation, but was also me that subsequently tested and confirmed it doesn't work on real hardware.)

While I'm here, just wanted to say I've not yet done anything more with the xdelta patch stuff.

i used them to rebuild iso in dolphin

 

[ScatlinkSean]

All in all, I think this will be it for the project for a while, unless someone helps out to figure out the out-of-sync subtitles for dm52to56 and dm33to36, and the issue with the Varia Suit still loading in certain in-game cutscenes to swap it for the new Gravity one. These two issues I haven't figured out, as I think they're all related to the game.rel file, which seems to have some custom code for what to do in certain occassions, and it seems like this one handles both the subtitle timings and what models load for certain cutscenes.

Anyway, enjoy everyone!

Hello, it's been a while again and congrats on the V1.0 release! Been having a catchup read and noticed not only the Gecko codes for 3rd-person missiles are now integraded but also what file data the cutscenes for the Gravity suit to be displayed instead of the Varia suit have been found! Has there been any (if at all) progress on getting the Gravity Suit to load instead?
Also, I didn't release there was a hack in the servers from October this year; I hope that doesn't effect things.

 

[ShadowOne333]

Hello, it's been a while again and congrats on the V1.0 release! Been having a catchup read and noticed not only the Gecko codes for 3rd-person missiles are now integraded but also what file data the cutscenes for the Gravity suit to be displayed instead of the Varia suit have been found! Has there been any (if at all) progress on getting the Gravity Suit to load instead?
Also, I didn't release there was a hack in the servers from October this year; I hope that doesn't effect things.

Sadly, no.
I haven't been able to find anything new regarding any of the TODO points left to be done.

We kinda sidetracked a bit when it was found that the current redux.dol file is causing the game to crash with rebuilt ISOs on a real Wii, so that's where we're at the moment.