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

[Nintendo Maniac]

I was doing that, but the way I am doing it is by exporting directly to the format that's closely tied to the SFD, which is mpeg1 (.mpg) at 480p.

Oh so is it the .MPG that you uploaded to YouTube?

Also it's worth mentioning that MPC-HC includes the ability to step frame-by-frame (it's the |▶ icon), therefore you can look for any sort of frame-dropping issues without having to upload the video.

 

[ShadowOne333]

Oh so is it the .MPG that you uploaded to YouTube?

Also it's worth mentioning that MPC-HC includes the ability to step frame-by-frame (it's the |▶ icon), therefore you can look for any sort of frame-dropping issues without having to upload the video.

Yep, correct.
I'm uploading the .MPG that I export, which is the exact one I will be using for the MPG2SFD conversion.
I should probably attempt doing .mp4 and then .mpg using ffmpeg, probably that would give better results.

 

[Nintendo Maniac]

I should probably attempt doing .mp4 and then .mpg using ffmpeg, probably that would give better results.

I know that encoding MPEG1 can be a bit funky compared to newer codecs due to various limitations that nowadays would be considered odd, but I can't help but mention that encoding into one lossy format only to then encode into a second lossy format is only going to result in worse visual fidelity than if you encoded straight to the final video format directly... or, at least that would be what would normally happen when you're not dealing with wacky frame-dropping issues.

One thing you could try is if you're able to encode to an MP4 with either a CRF or quantizer set to "0" which is lossless (assuming that the MP4 encode in question contains an h.264 / AVC video stream and not MPEG4-Visual aka Xvid / DivX) - that would then give you the most pure 1:1 copy of whatever edits you've made which should then be able to be much more easily encoded into whatever other format with ffmpeg like you said without worry of any shenanigans going on.

 

[ShadowOne333]

I know that encoding MPEG1 can be a bit funky compared to newer codecs due to various limitations that nowadays would be considered odd, but I can't help but mention that encoding into one lossy format only to then encode into a second lossy format is only going to result in worse visual fidelity than if you encoded straight to the final video format directly... or, at least that would be what would normally happen when you're not dealing with wacky frame-dropping issues.

One thing you could try is if you're able to encode to an MP4 with either a CRF or quantizer set to "0" which is lossless (assuming that the MP4 encode in question contains an h.264 / AVC video stream and not MPEG4-Visual aka Xvid / DivX) - that would then give you the most pure 1:1 copy of whatever edits you've made which should then be able to be much more easily encoded into whatever other format with ffmpeg like you said without worry of any shenanigans going on.

I'm using Shotcut, with a custom profile I made for exporting Other M videos.
It also has other profiles setup, I chose one called "H.264 High Profile" for exporting to MP4, but even then I'm noticing some slight drag when the rock slides into frame at 1:13 (which is my reference for the framedrop). At this moment, I'm not sure what the issue might be.

 

[Nintendo Maniac]

So I just discovered that a lot of my usual programs actually can read the SFD files, or at least the video stream (I'm not using the newest version for all of them, so maybe the newest versions could read the audio as well).

In particular, VirtualDub2 (a more simplistic video editor/encoder; you can almost think of it more as an ffmpeg front-end) is able to read both the audio and the video of an SFD file, so perhaps you could try opening the original SFD file in VirtualDub2 and, with no edits, doing the following:

1. go to Video -> Compression...
2. select x264 8 bit - H.264/MPEG-4 AVC codec
3. click the Configure button
4. set the drop-down menu under "Rate control" to Single pass - lossless
5. set the drop-down menu under "Preset" to whatever you want (slower will take longer to encode but will give you a smaller file size).
6. make sure the drop-down menu under "Profile" is set to Auto
7. click all of the OK buttons
8. go to File -> Save video...
9. for the "Save as type" drop-down menu, select Matroska (.mkv)
10. input whatever filename you want and click Save

Then try editing that newly-created MKV in Shotcut.


And as a side bonus, VirtualDub2 is also able to step frame-by-frame on the opened video (simply use the left and right arrow keys) which is yet another way that one could check for frame duplication and therefore the subsequent frame-drop issue.

Do note however that this method with VirtualDub2 seems to re-encode the audio into LPCM, but I'm going to go out on a limb and guess you're re-encoding the audio anyway rather than just splicing it (in which case it being converted to LPCM for the MKV shouldn't hurt anything as LPCM is straight-up uncompressed audio) ...though, according to ffmpeg, the source audio in the SDF files are "adpcm_adx" rather than plain MPEG1/2 audio.

Speaking of which, directly using ffmpeg would normally be able to automate that process but, for whatever reason, encoding in lossless x264 via ffmpeg directly gives me weird macroblocking that isn't present when doing what should be the exact same thing I just described in VirtualDub2, so...


Regardless, one alternative thing to try is if the newest version of mkvtoolnix is able to also read the audio stream and not just the video stream of an SFD file, then perhaps just try directly re-muxing the SFD into an MKV and then editing the resulting MKV in Shotcut.

 

[ShadowOne333]

So I just discovered that a lot of my usual programs actually can read the SFD files, or at least the video stream (I'm not using the newest version for all of them, so maybe the newest versions could read the audio as well).

In particular, VirtualDub2 (a more simplistic video editor/encoder; you can almost think of it more as an ffmpeg front-end) is able to read both the audio and the video of an SFD file, so perhaps you could try opening the original SFD file in VirtualDub2 and, with no edits, doing the following:

1. go to Video -> Compression...
2. select x264 8 bit - H.264/MPEG-4 AVC codec
3. click the Configure button
4. set the drop-down menu under "Rate control" to Single pass - lossless
5. set the drop-down menu under "Preset" to whatever you want (slower will take longer to encode but will give you a smaller file size).
6. make sure the drop-down menu under "Profile" is set to Auto
7. click all of the OK buttons
8. go to File -> Save video...
9. for the "Save as type" drop-down menu, select Matroska (.mkv)
10. input whatever filename you want and click Save

Then try editing that newly-created MKV in Shotcut.


And as a side bonus, VirtualDub2 is also able to step frame-by-frame on the opened video (simply use the left and right arrow keys) which is yet another way that one could check for frame duplication and therefore the subsequent frame-drop issue.

Do note however that this method with VirtualDub2 seems to re-encode the audio into LPCM, but I'm going to go out on a limb and guess you're re-encoding the audio anyway rather than just splicing it (in which case it being converted to LPCM for the MKV shouldn't hurt anything as LPCM is straight-up uncompressed audio) ...though, according to ffmpeg, the source audio in the SDF files are "adpcm_adx" rather than plain MPEG1/2 audio.

Speaking of which, directly using ffmpeg would normally be able to automate that process but, for whatever reason, encoding in lossless x264 via ffmpeg directly gives me weird macroblocking that isn't present when doing what should be the exact same thing I just described in VirtualDub2, so...


Regardless, one alternative thing to try is if the newest version of mkvtoolnix is able to also read the audio stream and not just the video stream of an SFD file, then perhaps just try directly re-muxing the SFD into an MKV and then editing the resulting MKV in Shotcut.

Interesting.
I did some more digging, and it seems that the culprit of the slowdowns/framedrops seems to be the original SFD2MPG conversion.
I tested this by converting an SFD with VirtualDub2 and another with the SFD2MPG tools (with two different commands and one with a tool that merges the audio), and interestingly enough, both tests with SFD2MPG gave the same results, laggy video at some parts.

So with that, I think I might have to migrate to VirtualDub2 or another tool that can convert the SFDs to another format without loss.
Here's the result with using the mkv from VirtualDub2 and then exporting the mpg from it:


I have also exported back the Ian Malkovich scene, as i noticed that by the end (when Anthony's face appears and afterwards) there was some lag as well.


I wanted to ask though..
Is there any other conversion or way in which I can convert the SFDs with VirtualDub2 to a video format or config so they don't become as size-heavy?
Most videos I'm working with seem to generate 500+MB files for mkv, and both machines where I'm working for have very limited size already (one has around 20GB free, and the other 40 or so), but with all the duplicates and video files I'm working with, I can see this being an issue later on.

If it's not possible with VirtualDub2, then perhaps with another tool you might know?
All this is kinda new to me, I'm mostly working with the little experience I have in audio and video editing, so I'm all up for suggestions and recommendations, mostly for SFD stuff.

 

[Nintendo Maniac]

Is there any other conversion or way in which I can convert the SFDs with VirtualDub2 to a video format or config so they don't become as size-heavy?

The only other way I can think of is if the source SFDs can be directly repackaged into an MKV rather than re-encoded. However, mkvtoolnix is only able to see the video stream and not the audio stream, so you'll need to first convert the audio via the following:

1. open the original SFD file in VirtualDub2
2. go to Audio -> select Full processing mode
3. go to Audio -> Compression
4. select FFMpeg FLAC lossless
5. click the Configure button
6. set the compression value to at least 8 for maximum compatibility with high compression or, alternatively, set it to 12 for maximum compression with reduced compatibility
7. click all of the OK buttons
8. go to File -> Save audio
9. set "Save as type:" as Matroska Audio (.mka) with whatever file name you want and click Save

From there, open mkvtoolnix (the GUI version ideally) and drag both the SFD and that exported .mka file into the mkvtoolnix program window and export them into a single combined .mkv file. That will give a much smaller file size, but there's no guarantee that it'll work without issue since we're still retaining the source video codec.



Nevertheless, even if that doesn't work, is there a reason you need to retain the lossless copies of the videos? They're basically just copies of the original SFDs anyway, so don't you only need a given lossless re-encode when you're in the middle of editing a given video?

Even then, there are two things in VirtualDub2 that you can do to reduce the file size and possibly a third. #1 would be to set the x264 "Preset" to a slower value ("Placebo" being the slowest).

#2 is to do the same as #1 but also making sure to do the process I described above to set the audio to "FLAC" compression when you save that .mkv file.

#3 is that, when selecting the video compression format, rather than selecting x264, select FFMPEG / x265 lossless, click the Configure button and then set the profile to whatever speed you want (again, slower = smaller file size). I say "possible" because, despite x265 widely known for giving smaller file sizes at a given level of visual quality, that's not really quite the case for lossless so it might actually give a larger file size while taking like twice as long to encode.

 

[ShadowOne333]

The only other way I can think of is if the source SFDs can be directly repackaged into an MKV rather than re-encoded. However, mkvtoolnix is only able to see the video stream and not the audio stream, so you'll need to first convert the audio via the following:

1. open the original SFD file in VirtualDub2
2. go to Audio -> select Full processing mode
3. go to Audio -> Compression
4. select FFMpeg FLAC lossless
5. click the Configure button
6. set the compression value to at least 8 for maximum compatibility with high compression or, alternatively, set it to 12 for maximum compression with reduced compatibility
7. click all of the OK buttons
8. go to File -> Save audio
9. set "Save as type:" as Matroska Audio (.mka) with whatever file name you want and click Save

From there, open mkvtoolnix (the GUI version ideally) and drag both the SFD and that exported .mka file into the mkvtoolnix program window and export them into a single combined .mkv file. That will give a much smaller file size, but there's no guarantee that it'll work without issue since we're still retaining the source video codec.



Nevertheless, even if that doesn't work, is there a reason you need to retain the lossless copies of the videos? They're basically just copies of the original SFDs anyway, so don't you only need a given lossless re-encode when you're in the middle of editing a given video?

Even then, there are two things in VirtualDub2 that you can do to reduce the file size and possibly a third. #1 would be to set the x264 "Preset" to a slower value ("Placebo" being the slowest).

#2 is to do the same as #1 but also making sure to do the process I described above to set the audio to "FLAC" compression when you save that .mkv file.

#3 is that, when selecting the video compression format, rather than selecting x264, select FFMPEG / x265 lossless, click the Configure button and then set the profile to whatever speed you want (again, slower = smaller file size). I say "possible" because, despite x265 widely known for giving smaller file sizes at a given level of visual quality, that's not really quite the case for lossless so it might actually give a larger file size while taking like twice as long to encode.

I found another way to make this work.
This the original SFD -> MPG conversion is the one that's screwing things up, I made a workaround to use your method alongside mine:

1. Convert the original SFD file to MKV following your instructions.
2. Once the MKV is converted, open the MKV in Shotcut
3. Select the default settings I have for Other M
4. Convert the MKV to MPG with the OtherM settings, which should give a clean and appropriate conversion to a smaller video file (MPG).
5. Use the newly created MPG as the base file, basically replacing the old .mpg files I had for editing.
6. Re-export all of the video edits I made with the new file as base.

I think this has worked nicely so far. I have yet to encounter an issue in any of the converted videos.
If it's okay with you, I might consider going forward doing this.

As a side note, I found out that mkvtoolnix is available in my Gentoo laptop, which is where I was doing all my Shotcut editing at home.
Does this one also allow for SFD -> MKV conversion? That one would ease up the process. If not, I can still use VirtualDub2 through Wine (albeit rather slow and prone to crash).

----

Aside from that, I also have worked above 12 hours in adding the Gravity Suit to the Ending cutscene of the game.
I used ColorDirector by CyberLink to make this possible, and some tutorials and fucking things up on my end, and I think the final product is quite nice to me.
Here's what I have for the Ending cutscene with the Gravity Suit implemented:



I'm all up for comments on how do you guys feel about the edit.
If this one gets a positive view, I'll do the first encounter between Samus and the real Madeline in the same vein, as by that point the Sector Zero event has occurred and the Gravity Suit is already activated, so it makes sense sequence-wise.

 

[Nintendo Maniac]

As a side note, I found out that mkvtoolnix is available in my Gentoo laptop, which is where I was doing all my Shotcut editing at home.

You know, mkvtoolnix is also available on Windows... but yes, it's on Linux as well (in fact that's how I had to test the newest 64.0 version as none of my Windows PCs run anything newer than Win7 which had the slightly-older version 55 of mkvtoolnix instead...but from my testing v55 handled SFD files no differently than v64).

Does [mkvtoolnix] also allow for SFD -> MKV conversion? That one would ease up the process.

That's kind of what I was suggesting in my previous post, but one point of clarification - mkvtoolnix doesn't actually convert anything and instead it just repackages the existing video stream from the SFD into an MKV file (therefore no guarantees that it'll work without any frame-drop//repeat issues, so make sure it works properly first).

Speaking of which, it can only read the SFD's video stream for whatever reason and you still need to use VirtualDub2 to convert the audio stream which I outlined how to do so in my previous post (it should take a lot less time to convert just the audio than the video + audio, even more so if you instead decide to leave it as VirtualDub2's default of uncompressed LPCM rather than using the compressed FLAC that I suggested).


To streamline the process, do the audio conversion first to a .mka and then, in mkvtoolnix, open the SFD and additionally append your newly-exported .mka and export them into a new combined .mkv file, and then use that .mkv as the basis of your edits.

In other words I'm suggesting to forgo converting to a separate MPG file altogether (which would reduce visual fidelity anyway, no?＊) and do the following instead:

• SFD_source --VirtualDub2-> .mka (audio)
• .mka (audio) + SFD_source --mkvtoolnix-> .mkv (video+audio)
• .mkv (video+audio) --OneShot-> SFD_final

Unless I'm misunderstanding how you're using OneShot to make these edits...? (I've never used the program before)


(＊when encoding to non-lossless formats, quality will almost always be reduced every single time you re-encode them even when encoding to the source format, and this is basically guaranteed to be the case if edits were applied before re-encoding)

 

[ShadowOne333]

You know, mkvtoolnix is also available on Windows... but yes, it's on Linux as well (in fact that's how I had to test the newest 64.0 version as none of my Windows PCs run anything newer than Win7 which had the slightly-older version 55 of mkvtoolnix instead...but from my testing v55 handled SFD files no differently than v64).


That's kind of what I was suggesting in my previous post, but one point of clarification - mkvtoolnix doesn't actually convert anything and instead it just repackages the existing video stream from the SFD into an MKV file (therefore no guarantees that it'll work without any frame-drop//repeat issues, so make sure it works properly first).

Speaking of which, it can only read the SFD's video stream for whatever reason and you still need to use VirtualDub2 to convert the audio stream which I outlined how to do so in my previous post (it should take a lot less time to convert just the audio than the video + audio, even more so if you instead decide to leave it as VirtualDub2's default of uncompressed LPCM rather than using the compressed FLAC that I suggested).


To streamline the process, do the audio conversion first to a .mka and then, in mkvtoolnix, open the SFD and additionally append your newly-exported .mka and export them into a new combined .mkv file, and then use that .mkv as the basis of your edits.

In other words I'm suggesting to forgo converting to a separate MPG file altogether (which would reduce visual fidelity anyway, no?＊) and do the following instead:

• SFD_source --VirtualDub2-> .mka (audio)
• .mka (audio) + SFD_source --mkvtoolnix-> .mkv (video+audio)
• .mkv (video+audio) --OneShot-> SFD_final

Unless I'm misunderstanding how you're using OneShot to make these edits...? (I've never used the program before)


(＊when encoding to non-lossless formats, quality will almost always be reduced every single time you re-encode them even when encoding to the source format, and this is basically guaranteed to be the case if edits were applied before re-encoding)

Ah that's a good way to go about it as well.
I didn't catch it at first, but now I understand the process you mentioned properly.

The tool I'm using is called "Shotcut" (you wrote it as OneShot I think). It's basically a video editing tool that was recommended to me back in some pages ago, which by recommendation give the best result in terms of quality when exporting videos from a base video source, as with a good amount of filters that cover my needs. Audio-wise I'm doing it all in Audacity with some help by online tools where possible.

So far it has given really nice videos, as those are the very ones I've been using for the YouTube uploads.
Basically, Shotcut is where I have all the re-edited cutscenes done, with only one base MPG file as source, that's why I was mentioning converting the MKV to MPG, so the whole edits I've done until now detect the newly updated MPG, and then simply re-export the whole project without having to redo the video trimming and edits, so it's easier on me to export the files again. (Hopefully I'm explaining myself well enough).

Additionally, I've noticed that the MPG files I get doing it that way are a fraction of what the original SFD/MPG was in size, around 1/2 at least from a 1:1 conversion, and with the edits I have managed to lower other files to around 1/3 of the original size (dm03to04 is originally 199kB, my edited video is 62 kB).
This makes me think that perhaps it's possible to lower the SFD file size to (in theory) be able to lower down the Other M ISO from bein a double-layer game into a single layer ISO of 4.2GB. Of course, this is all theoretical, as I haven't really seen if the converted MPG -> SFD retains this file size, or if the game will have any issues reading such reduced-size files.

I have also been able to setup your Riivolution patch alongside the Gecko code, and I can easily run Maxximum Edition without rebuilding the ISO, no issues whatsoever!
I do need to find which file adds the "Maxximum Edition" subtitle though, I want to remove that.

With this, I should be able to start out testing the edited cutscenes in game, more so since the game nicely gives you access to a Theater mode where I can watch them easily with my 100% save.

-----------------------------------------

I should have tested this earlier.
PES Media Converter (the tool that supposedly converts MPG to SFD) isn't working for me.
It seems to crash with a "TCP/IP Services Application has stopped working" message, and then it gives an error about Buffer Overflow "Please decrease bitrate or select a smaller video", even though the default is the lowest bitrate possible, and I've tried files as little as 50MB (smallest I have) and still does the same.

Guess I'll have to find another way to convert the videos to SFD.
I tried with "sfdmux", but the output SFD doesn't load in-game, it might have something to do with the Streams of the MPG being inverted to what the SFD is expecting? SFDMUX seems like the most feasible option right now. If someone knows what to do with this so it works, let me know.

Here's the final MPG for the First Boss cutscene (dm03to04) for testing purposes:
https://www.dropbox.com/s/gp4hxr35x0mzrds/FirstBoss.mpg?dl=0
I need to find a proper way to convert it into SFD, and then use the Riivolution patch by Maniac to load it inside /movies/dm03to04.sfd
Then, in-game, go to Theater -> Load the second movie from the list (from a completed save file).

 

[Nintendo Maniac]

The tool I'm using is called "Shotcut" (you wrote it as OneShot I think)

Yup, I derped up the name.

Basically, Shotcut is where I have all the re-edited cutscenes done, with only one base MPG file as source, that's why I was mentioning converting the MKV to MPG, so the whole edits I've done until now detect the newly updated MPG, and then simply re-export the whole project without having to redo the video trimming and edits, so it's easier on me to export the files again.

So uh, this still to me sounds like you're basically going MKV -> MPG -> MPG (that is, encoding to MPG twice) and I still can't quite understand what the benefit of this is.

That being said, I've not really ever done any proper video editing before outside of basic stuff that you could do with the likes of FFMPEG anyway, so my impression is always that, outside of a basic trim, all edits always require re-encoding and the more times to re-encode to a non-lossless format such as MPG, the greater quality loss you will experience.

Additionally, I've noticed that the MPG files I get doing it that way are a fraction of what the original SFD/MPG was in size, around 1/2 at least from a 1:1 conversion, and with the edits I have managed to lower other files to around 1/3 of the original size (dm03to04 is originally 199kB, my edited video is 62 kB).

I would imagine that you're just encoding to a lesser bitrate for the video and/or audio stream(s) since bitrate directly determines the file size.

This makes me think that perhaps it's possible to lower the SFD file size to (in theory) be able to lower down the Other M ISO from bein a double-layer game into a single layer ISO of 4.2GB. Of course, this is all theoretical, as I haven't really seen if the converted MPG -> SFD retains this file size, or if the game will have any issues reading such reduced-size files.

If you're going to reduce the total file size of the game, then it might be better to target getting it under the ~4GB file size limit (specifically 4,294,967,295 bytes) used for FAT32-formatted drives commonly used for softmodded Wii consoles, especially since Riivolution isn't compatible with USB ISO loaders anyway.

 

[ShadowOne333]

So uh, this still to me sounds like you're basically going MKV -> MPG -> MPG (that is, encoding to MPG twice) and I still can't quite understand what the benefit of this is.

That being said, I've not really ever done any proper video editing before outside of basic stuff that you could do with the likes of FFMPEG anyway, so my impression is always that, outside of a basic trim, all edits always require re-encoding and the more times to re-encode to a non-lossless format such as MPG, the greater quality loss you will experience.

I would imagine that you're just encoding to a lesser bitrate for the video and/or audio stream(s) since bitrate directly determines the file size.

Oh well the main reason why I'm doing MKV -> Base MPG -> Edited MPG is because of storage reasons, as I really run out of space with the MKVs. One of them got saved up to a 1.5GB video file, which is way too much for my little limited space to handle, that's why I converted the MKVs to base MPGs. That way I ensure that the SFD -> MKV conversion is nice and at smooth fps, and then the MKV -> MPG for keeping and saving up as base videos for the editing.

I'm mostly eye-seeing the quality after each conversion, and I can at least see that it maintains the quality of the picture just fine in the several conversions.
It's possible the bitrate might be lower, but with 480p videos, I'm not too worried for the best 1:1 quality, mostly that it looks as close to the original SFD as possible, and nothing as abhorrent as some of the SFDs that were converted for Maxximum

If you're going to reduce the total file size of the game, then it might be better to target getting it under the ~4GB file size limit (specifically 4,294,967,295 bytes) used for FAT32-formatted drives commonly used for softmodded Wii consoles, especially since Riivolution isn't compatible with USB ISO loaders anyway.

The base game with all its data; models, stages and audio sums up to about 2+GB.
The whole video folder is the one that takes up most of the game's size, with an almost absurd 4+GB for the whole movies alone. If I go by the file sizes I'm getting, where some of the videos are about 1/3 to 1/2 of the original's size, it might be within possibility to size it down to aroudn 4 gigs.
If I somehow manage to convert my finished MPGs properly to an SFD that the game can read just fine, I'll see about converting the rest of the videos of the game into a smaller size so that they hopefully fit into a single-layer 4.2GB disk. It'll be huge if possible.

 

[Nintendo Maniac]

Oh well the main reason why I'm doing MKV -> Base MPG -> Edited MPG is because of storage reasons, as I really run out of space with the MKVs. One of them got saved up to a 1.5GB video file, which is way too much for my little limited space to handle, that's why I converted the MKVs to base MPGs

Wait wait wait, you realize that an MKV doesn't have to contain a re-encoded video stream, right? MKV as a format is more like a ZIP archive more than anything as it can hold a whole slew of different video codecs.

So my point in my previous post was, what if you take the SFD file, open it in mkvtoolnix, and re-package (no re-encoding!) the SFD's video stream in to an MKV file?

Doing that will result in a file size that's basically the same as the SFD and it should also process much faster; the one main niggle is that it won't have any audio if you don't separately convert the audio beforehand which, again, is why I mentioned doing the File -> Save audio... (NOT video! AUDIO) in VirtualDub2 so that you can then also combine the video and audio in mkvtoolnix while you're re-packaging the SFD's video stream.

 

[ShadowOne333]

Wait wait wait, you realize that an MKV doesn't have to contain a re-encoded video stream, right? MKV as a format is more like a ZIP archive more than anything as it can hold a whole slew of different video codecs.

So my point in my previous post was, what if you take the SFD file, open it in mkvtoolnix, and re-package (no re-encoding!) the SFD's video stream in to an MKV file?

Doing that will result in a file size that's basically the same as the SFD and it should also process much faster; the one main niggle is that it won't have any audio if you don't separately convert the audio beforehand which, again, is why I mentioned doing the File -> Save audio... (NOT video! AUDIO) in VirtualDub2 so that you can then also combine the video and audio in mkvtoolnix while you're re-packaging the SFD's video stream.

Oh I see.
I haven't tried out mkvtoolnix yet, but I'll try doing some tests with it.

In other news, I have incredible results.
I have managed to successfully convert one of the final MPGs I had (Sector Zero) to SFD, and best of all, the end SFD can be side-loaded with Dolphin with your Riivolution patch with no issues at all!

And the quality is very good as well, I played both the MPG I had as final alongside the cutscene in Dolphin, and my oh my they look almost the same in terms of quality.
Nothing to do with the awful quality conversions used in Maxximum.

The original Sector Zero (dm52to56) cutscene is 612.8MB from Other M.
With my edited cutscene, and the final version of the Sector Zero cutscene, the size came down to an astonishing 170.8MB in size!!!
That's around 27.87% the size of the original file!

If you want to try it out on your side, @Nintendo Maniac , here's the link to the SFD:
https://www.dropbox.com/s/mscpywv4js6yf0x/dm52to56.sfd?dl=0
Simply put it inside the /movies/ folder where you are loading the Riivolution stuff for Other M.

Perhaps with you testing it, you could give some feedback on the quality, you have a more trained eye when it comes to this sort of things.

As for the steps done for converting my MPGs to SFD, all I did was simply make use of SFDMUX and FFMPEG, which was recommended by me by Albert, one of the developers from another hack/mod currently being developed (and almost finished), being the RE4HD project, which upscaled all of RE4's cutscenes into a proper HD format.
I ended up using the final MPGs I used for the conversion with a 8M bitrate for the conversion, and then I had to split the MPG and the audio from the main MPG.
So basically:

• Prepare the final edited MPG videos for conversion.
• Split the main video, which contains two streams of media, video and audio, into two files: One for the standalone MPG video with no audio and another for the audio separately
• SFDMUX help command recommends using the following FFMPEG commands for the conversion of the video:
  

  ffmpeg -i FINAL.mpg -an -c:v mpeg1video -b:v 8M -pass 1 -f mpeg /dev/null
  ffmpeg -i FINAL.mpg -an -c:v mpeg1video -b:v 8M -pass 2 -f mpeg video.mpeg

  (I think I only did the first directly into an mpeg file, and then the second again)
• SFDMUX also recommends another command for the audio, exporting it directly into ADX:
  

  ffmpeg -i FINAL.mpg -vn audio.adx

• Once I got both files, I can now run SFDMUX to merge both files into a single working SFD file for Other M using the following command:
  

  sfdmux.exe audio.adx video.mpeg movie.sfd

• Now simply rename the SFD file to the proper naming used in Other M for the appropriate cutscene (in this case, for the Sector Zero cutscene it was dm52to56.sfd), or rename it properly while typing the SFDMUX command, and then put it in the proper Riivolution folder, inside /movies/

That's it!
With this, I can now continue with the rest of the cutscenes with no issues.
Gotta say though, the Riivolution patch you made, Maniac, has certainly come in handy for easily testing the mods and what they do in-game.
It's a life saver when it comes to saving me a lot of time screwing up with ISO files and such (which I might still do at the end of the day for my own build, but at least I will only need to do it once).

There's only 4 remaining cutscenes left to be touched, dm01to02 (Intro up to the Training), dm46to49 (Samus talks to MB), dm61to63A (Real Madeline encounter) and dm63Bto64 (Ending).
For the Intro cutscene, the only thing I want to modify is to add an image or video that plays briefly in the monitor when the scientists are checking Samus', which says the suit was damaged with Hyper Beam and will enter auto-repair mode, and for the other 3, I need to do some monologue-checking and remove/rework some of them so they reduce the cringe dialogues to a minimum.

After that, I think we should be done with the videos!
I also have the audios done, I just need to convert the WAV files to proper AIX files for use in Other M.
Finally, I might have to edit BRRES models 252 253, 254, 255 and 337 (rtm_samus* cutscene models) so they use the updated textures from Maxximum's updated stuff.

 

[Nintendo Maniac]

EDIT: Forgot to ask from your previous post...

hopefully fit into a single-layer 4.2GB disk

Is there an actual benefit to using a single layer disc for USB loaders and/or Dolphin?

Again, the only file size-related benefit I know of is that FAT32 (commonly used by USB drives) is limited to 4.0GB minus one byte (AKA 4,294,967,295 bytes), so wbfs games tend to be split into multiple files when going above that limit.

I don't suppose you're mixing up the file size limit of FAT32 with that of a single-layer disc? This is an important distinction because you can definitely have a single-layer disc that is still split into 2 wbfs files on a FAT32 USB drive.


----------------

I haven't tried out mkvtoolnix yet, but I'll try doing some tests with it.

For similar reasons, if you end up not just re-packing the SFD video into an MKV and actually doing some sort of re-encode like your SFD -> MPG -> MKV, you can skip the SFD -> MPG step and instead encode to a much newer lossy format during the SFD -> MKV step whether that be h264, h265, etc

For example, in VirtualDub2, rather than selecting lossless on the x264 configuration window under "Rate control", set it to "Single pass - ratefactor-based (CRF)" and set it to some value and experiment with the resulting file size (smaller value = larger file size & higher quality), and the same stuff that a slower "Profile" will also give higher quality also applies; also for non-lossless it can be ideal to set the profile to "High" instead, and make sure it's also set to YUV 4:2:0 rather than RGB!

You might also get a bit of a "free" quality boost without taking any longer to encode if, on VirtualDub2's Video -> Compression selection window, you instead select x264 10 bit - H.264/MPEG-4 AVC codec; other than that everything I just said in the paragraph above applies except that the profile needs to be set to High 10.

Speaking of which, also on VirtualDub2's Video -> Compression selection window, you can instead select FFMPEG / x265 for results that give better quality with a smaller file size in exchange for longer encode times.

you have a more trained eye when it comes to this sort of things.

Err... kind of. It's mainly audio that I have an ear for this sort of thing (I've been able to successfully ABX things multiple times in a manner that "rational" audio experts on the internet would proclaim to be straight-up impossible) and the methods for preserving audio quality just happen to generally apply to video as well. Furthermore I have an eye for motion resolution which is why I was able to see the judder from the dropped/repeated frames instantly, but still-image resolution is... definitely not as much of a strength of mine.

I do actually know a guy that very much has a strength with still-image visual acuity from the Fate/stay night Ultimate Edition project... I could ask him, but I'm a bit concerned about whether it'd be rude of me to ask as this is extremely off-topic in relation to that and, unlike another member of that team who's been there for a couple of years now that I've previously asked about various unrelated Linux things (cause the guy is like a Linux guru), the "visual acuity" guy has only been on the project for a couple of months.

Nevertheless, I am definitely a bit OCD with regards to maximizing visual quality for a given file size (e.g. I'm the kind of person that encodes using the "placebo" preset), and I know that encoding to a non-lossless format twice (whether its MPG, non-lossless x264, etc) will definitely hurt that... whether it's to a level that a human can actually perceive is a different story though.

https://www.dropbox.com/s/mscpywv4js6yf0x/dm52to56.sfd?dl=0

At least for stand-alone playback (I used mkvtoolnix to put it into an MKV and then played that MKV in MPC-HC) the motion resolution looks perfect.

For reference, one "trick" I do is actually apply motion interpolation via SVP with its settings absolutely cranked while outputting to a CRT monitor refreshing at 120Hz. This did get me kind of wondering about if the Wii would be capable of decoding 60fps CG movie cutcenes... (it's my impression that it's all being decoded in software by the not-exactly-fast CPU, hence why they're using the old MPEG1/2 video format).

Regardless, I know that some people (such as my sister) dislike high framerate cinematography despite being fine with 60fps for in-game gameplay so, even if it's something worth pursuing (in which case it'd probably be best to use RIFE for the motion interpolation), it'd probably be best to get the base mod sorted and out of the way - especially since higher framerate video tends to require higher bitrate and therefore larger file sizes as well.

All of this similarly makes me wonder if the game engine could handle higher-resolution CG movie cutscenes (such as being upscaled using something like RealSR) if the game were ran in Dolphin with IR scaling set to a value of at least 2x, or if the game always just outputs at 640x480 for those CG movie cutscenes. Similarly to the frame rate, there's also the performance decoding concerns (though technically in Dolphin you could crank up the CPU clock override, but that also might have the chance of breaking in-game stuff).

One thing I do know however in terms of general video decoding performance is that, at a given frame rate and/or resolution, encoding a video to a lower bitrate will reduce the CPU requirement to actually decode that video (similarly, increasing the bitrate will increase the CPU requirement to decode it).

 

[ShadowOne333]

EDIT: Forgot to ask from your previous post...

Is there an actual benefit to using a single layer disc for USB loaders and/or Dolphin?

Again, the only file size-related benefit I know of is that FAT32 (commonly used by USB drives) is limited to 4.0GB minus one byte (AKA 4,294,967,295 bytes), so wbfs games tend to be split into multiple files when going above that limit.

I don't suppose you're mixing up the file size limit of FAT32 with that of a single-layer disc? This is an important distinction because you can definitely have a single-layer disc that is still split into 2 wbfs files on a FAT32 USB drive.

More or less, just that... Make the game compatible with single layer disks.
The Wii was prone to struggle with dual layer disks like Smash, Other M (and for some reason Black Ops too?), so perhaps by making the game small enough to fit within a single layer disk it could be burned into a disk and played with little to no risk to damage the lasers of the Wii for those that want to play it on an original console.
Other than that, there's not any other reason for doing so.

For similar reasons, if you end up not just re-packing the SFD video into an MKV and actually doing some sort of re-encode like your SFD -> MPG -> MKV, you can skip the SFD -> MPG step and instead encode to a much newer lossy format during the SFD -> MKV step whether that be h264, h265, etc

For example, in VirtualDub2, rather than selecting lossless on the x264 configuration window under "Rate control", set it to "Single pass - ratefactor-based (CRF)" and set it to some value and experiment with the resulting file size (smaller value = larger file size & higher quality), and the same stuff that a slower "Profile" will also give higher quality also applies; also for non-lossless it can be ideal to set the profile to "High" instead, and make sure it's also set to YUV 4:2:0 rather than RGB!

You might also get a bit of a "free" quality boost without taking any longer to encode if, on VirtualDub2's Video -> Compression selection window, you instead select x264 10 bit - H.264/MPEG-4 AVC codec; other than that everything I just said in the paragraph above applies except that the profile needs to be set to High 10.

Speaking of which, also on VirtualDub2's Video -> Compression selection window, you can instead select FFMPEG / x265 for results that give better quality with a smaller file size in exchange for longer encode times.

Oh very interesting.
I will for sure play around with those settings you mentioned, perhaps this could help a lot to avoid the huge filesizes while still retaining the best quality possible in the SFD export.

Err... kind of. It's mainly audio that I have an ear for this sort of thing (I've been able to successfully ABX things multiple times in a manner that "rational" audio experts on the internet would proclaim to be straight-up impossible) and the methods for preserving audio quality just happen to generally apply to video as well. Furthermore I have an eye for motion resolution which is why I was able to see the judder from the dropped/repeated frames instantly, but still-image resolution is... definitely not as much of a strength of mine.

I do actually know a guy that very much has a strength with still-image visual acuity from the Fate/stay night Ultimate Edition project... I could ask him, but I'm a bit concerned about whether it'd be rude of me to ask as this is extremely off-topic in relation to that and, unlike another member of that team who's been there for a couple of years now that I've previously asked about various unrelated Linux things (cause the guy is like a Linux guru), the "visual acuity" guy has only been on the project for a couple of months.

Nevertheless, I am definitely a bit OCD with regards to maximizing visual quality for a given file size (e.g. I'm the kind of person that encodes using the "placebo" preset), and I know that encoding to a non-lossless format twice (whether its MPG, non-lossless x264, etc) will definitely hurt that... whether it's to a level that a human can actually perceive is a different story though.

Oh no don't worry about asking anyone else.
Mainly if people think it looks and sounds good enough, I might most likely continue that way.
As I said, I'm not too worried for the best HD/4k quality stuff, as this is desired to be played on original hardware, so 480p will be the top quality in here, and as long as it looks close enough to the original SFD, I'm good with it.

At least for stand-alone playback (I used mkvtoolnix to put it into an MKV and then played that MKV in MPC-HC) the motion resolution looks perfect.

For reference, one "trick" I do is actually apply motion interpolation via SVP with its settings absolutely cranked while outputting to a CRT monitor refreshing at 120Hz. This did get me kind of wondering about if the Wii would be capable of decoding 60fps CG movie cutcenes... (it's my impression that it's all being decoded in software by the not-exactly-fast CPU, hence why they're using the old MPEG1/2 video format).

Regardless, I know that some people (such as my sister) dislike high framerate cinematography despite being fine with 60fps for in-game gameplay so, even if it's something worth pursuing (in which case it'd probably be best to use RIFE for the motion interpolation), it'd probably be best to get the base mod sorted and out of the way - especially since higher framerate video tends to require higher bitrate and therefore larger file sizes as well.

All of this similarly makes me wonder if the game engine could handle higher-resolution CG movie cutscenes (such as being upscaled using something like RealSR) if the game were ran in Dolphin with IR scaling set to a value of at least 2x, or if the game always just outputs at 640x480 for those CG movie cutscenes. Similarly to the frame rate, there's also the performance decoding concerns (though technically in Dolphin you could crank up the CPU clock override, but that also might have the chance of breaking in-game stuff).

One thing I do know however in terms of general video decoding performance is that, at a given frame rate and/or resolution, encoding a video to a lower bitrate will reduce the CPU requirement to actually decode that video (similarly, increasing the bitrate will increase the CPU requirement to decode it).

Ah neat!
Glad to know you find it to be fine
I'll try converting the handful of other finished videos I have into SFD, and then I'll try to finish up the other 4 that are pending.
I'll try to stay within the limitations of the original hardware, as the Wii only had up to 480p playback, so I don't think I'll be attempting anything beyond that.
How does the bitrate affect the video playback? I have never delved into that, so I'm pretty much unfamiliar with it.
I am quite happy with the results tho, and if the lower framerate seems to help the CPU speed, then I think it's a feasible option, I'll consider converting the most heavy SFDs into this smaller format, and I'll see how much space can be saved by doing that.

Interesting thing about your sister not liking higher frame rates.
I'm also on the same spot. I really can't stand higher frames on movies or series. I can barely stand it on games, but even then, if the frames get too high I start to dislike it.

 

[Nintendo Maniac]

More or less, just that... Make the game compatible with single layer disks.
The Wii was prone to struggle with dual layer disks like Smash, Other M (and for some reason Black Ops too?), so perhaps by making the game small enough to fit within a single layer disk it could be burned into a disk and played with little to no risk to damage the lasers of the Wii for those that want to play it on an original console.

...you've never soft-modded a Wii before, have you?

In order to read burned discs, you must at least soft-mod it. But loading ISO files on a real Wii console using homebrew software also requires a soft-mod (and, at least for GameCube games, it takes considerably fewer steps as well).

Furthermore, even if you make a successful burned disc, there's no guarantee that the console will actually read the disc - I experimented with this around a decade ago before GameCube USB loaders were a thing and, between two different brands of burned DVDs, only one brand worked.

And to make matters worse, I even recall a warning that using a burned disc a lot could possibly hurt your disc drive, but I don't know if that was just theoretically or in actual practice.

Lastly, I'm not sure there's even been a laptop sold in the last 7 years that has an optical disc drive; even desktop pre-built PCs no longer always have them, and custom desktop PC cases rarely even include the mounting cage to fit an optical disc drive.


Oh speaking of real hardware, I do actually have a soft-modded Wii console that still sees active use. The main reason I've not done any testing with it is due to the aforementioned 4.0GB FAT32 file size limit that my USB drive uses＊; if the total game size could get under that, then one could even use Dolphin to create the modded ISO which is substantially easier... but Dolphin only creates single-file ISOs, hence the 4GB issue.

＊AFAIK Wii game USB loaders require either NTFS or FAT32, but GameCube game USB loaders require either exFAT or FAT32. So if you want both types of games on a single partition, then FAT32 is the only option.

I will for sure play around with those settings you mentioned, perhaps this could help a lot to avoid the huge filesizes while still retaining the best quality possible in the SFD export.

Just be sure to try the SFD -> mkvtoolnix method first because, even ignoring any possible quality reduction from using VirtualDub2 to re-encode the video steam, the mkvtoolnix method will take less time without blowing up the file size at all (not counting the converted audio track - that'll technically add a couple 10 or so megabytes).

(and of course the mkvtoolnix method will also retain 100% of the source visual quality but, as I said, that was kind of besides the point)

The main idea is that, if the mkvtoolnix method "just works" then there's no point in spending time experimenting with the x264 or x265 video quality settings as the mkvtoolnix method skips that step altogether.

I am quite happy with the results tho, and if the lower framerate seems to help the CPU speed, then I think it's a feasible option, I'll consider converting the most heavy SFDs into this smaller format, and I'll see how much space can be saved by doing that.

...I think you've misunderstood what I've said.

First off, the original SFD files are in 30fps.

As you may or may not know, the in-game gameplay runs at 60fps.

So I was just pondering out loud if the game engine actually allows the ability to play 60fps videos without them becoming too demanding for the console or being handled incorrectly in some manner (playing in slow-mo, dropping frames, etc). And if it can do it without bogging-down, then it's technically something that could optionally be played around with in the future.

This is why I then mentioned bitrate in that, technically one could "cheat" by simply lowering the bitrate in order to make any hypothetical 60fps video encodes be less-demanding on the console.

 

[ShadowOne333]

...you've never soft-modded a Wii before, have you?

In order to read burned discs, you must at least soft-mod it. But loading ISO files on a real Wii console using homebrew software also requires a soft-mod (and, at least for GameCube games, it takes considerably fewer steps as well).

Furthermore, even if you make a successful burned disc, there's no guarantee that the console will actually read the disc - I experimented with this around a decade ago before GameCube USB loaders were a thing and, between two different brands of burned DVDs, only one brand worked.

And to make matters worse, I even recall a warning that using a burned disc a lot could possibly hurt your disc drive, but I don't know if that was just theoretically or in actual practice.

Lastly, I'm not sure there's even been a laptop sold in the last 7 years that has an optical disc drive; even desktop pre-built PCs no longer always have them, and custom desktop PC cases rarely even include the mounting cage to fit an optical disc drive.


Oh speaking of real hardware, I do actually have a soft-modded Wii console that still sees active use. The main reason I've not done any testing with it is due to the aforementioned 4.0GB FAT32 file size limit that my USB drive uses＊; if the total game size could get under that, then one could even use Dolphin to create the modded ISO which is substantially easier... but Dolphin only creates single-file ISOs, hence the 4GB issue.

＊AFAIK Wii game USB loaders require either NTFS or FAT32, but GameCube game USB loaders require either exFAT or FAT32. So if you want both types of games on a single partition, then FAT32 is the only option.

I've been homebrewing consoles back in the Xbox days, and each console since then I have hacked
I have both a hacked Wii and WiiU, and I started hacking it way before USB loaders were a thing, hence why I mentioned burned disks and the possibility of using single layer to avoid laser damage. Even the original disks for the games I mentioned caused that kind of issues, there was even trouble between Activision and Nintendo due to Black Ops fucking up the lasers back in the day.
The good old times.

That said, I'm a sucker for space saving, so if there's room for saving space, I'm all up for it, that's why I want to at least attempt seeing how much I can reduce the file size of the final ISO image.

 

[ShadowOne333]

...you've never soft-modded a Wii before, have you?

In order to read burned discs, you must at least soft-mod it. But loading ISO files on a real Wii console using homebrew software also requires a soft-mod (and, at least for GameCube games, it takes considerably fewer steps as well).

Furthermore, even if you make a successful burned disc, there's no guarantee that the console will actually read the disc - I experimented with this around a decade ago before GameCube USB loaders were a thing and, between two different brands of burned DVDs, only one brand worked.

And to make matters worse, I even recall a warning that using a burned disc a lot could possibly hurt your disc drive, but I don't know if that was just theoretically or in actual practice.

Lastly, I'm not sure there's even been a laptop sold in the last 7 years that has an optical disc drive; even desktop pre-built PCs no longer always have them, and custom desktop PC cases rarely even include the mounting cage to fit an optical disc drive.


Oh speaking of real hardware, I do actually have a soft-modded Wii console that still sees active use. The main reason I've not done any testing with it is due to the aforementioned 4.0GB FAT32 file size limit that my USB drive uses＊; if the total game size could get under that, then one could even use Dolphin to create the modded ISO which is substantially easier... but Dolphin only creates single-file ISOs, hence the 4GB issue.

＊AFAIK Wii game USB loaders require either NTFS or FAT32, but GameCube game USB loaders require either exFAT or FAT32. So if you want both types of games on a single partition, then FAT32 is the only option.

I've been homebrewing consoles back si CE the Xbox days, and each console since then I have hacked
I have both a hacked Wii and WiiU, and I started hacking it way before USB loaders were a thing, hence why I mentioned burned disks and the possibility of using single layer to avoid laser damage. Even the original disks for the games I mentioned caused that kind of issues, there was even trouble between Activision and Nintendo due to Black Ops fucking up the lasers back in the day.
The good old times.

That said, I'm a sucker for space saving, so if there's room for saving space, I'm all up for it, that's why I want to at least attempt seeing how much I can reduce the file size of the final ISO image.

 

[Nintendo Maniac]

Even the original disks for the games I mentioned caused that kind of issues, there was even trouble between Activision and Nintendo due to Black Ops fucking up the lasers back in the day.

I wasn't referring to dual-layer discs but rather burned single-layer discs.

The good old times

I mean, I'm one of those people that soft-modded their Wii back on the old 3.1U (or was it 3.2U?) firmware with the Twilight Hack, and the only substantial use-case I recall for burning physical discs rather than using a USB loader was 1. very early on (~15 years ago) when USB loaders weren't even a thing yet and you had to even use a modchip (wiikey, wiinja, etc) and 2. ~10 years ago when only Wii game USB loaders were a thing and GameCube USB loaders weren't there yet (e.g. all you had was DIOS MIOS and the like; not even Devolution was around yet)

But I was never willing to use a modchip on hardware that was still within its officially-supported lifetime as, around the same time-frame, I was running into the infamous non-working shoulder button(s) on not just one but two separate Nintendo DS systems.

And by the time the system was no longer getting updates (somewhere around the time that Other M launched IIRC), softmodding was all you needed, so... yeah... never saw the need to hard-mod.


EDIT: With all of that being said, since you're someone that apparently used burned discs, I must ask - within the last 7 or so years, has there been any benefit to burning optical discs rather than using a USB loader? (not counting warm fuzzies from physically inserting a disc into a game console... which isn't really something I know about anyway since I grew up with cartridges on consoles and discs on PC, and the GameCube was top-loading with small discs and therefore "feels" very different; the GameCube and Wii are the only disc-based consoles I own, and I guess a PS4 that a friend is perpetually loaning to me)

Thing is, being quite the hardware computer geek (not software - I can't code worth a darn!) that tends to get all of my friends and relative's older PC parts through the motto of "don't throw it away, throw it my way!", I'm kind of spoiled for choice when it comes to spare 2.5" SATA drives that I have just laying around unused, so all it took was a known-working $10 USB-SATA adapter and I was set to use whatever drive I wanted (...though not before I went through like 6 different USB flash drives of extremely hit-and-miss compatibility which is actually why I bit the bullet and went the USB-SATA adapter route instead which "just worked" first try).