So I just installed the new GC Loader - nkit.iso does seem to work with it. Quick question, is there a difference in speed/loadtime for the nkit.iso vs the regular iso? Is nkit.iso compressed and it would take the gamecube longer to uncompress the data in realtime (similar to cso in PSP)? Thanks for the great work nanook!
The disc file system is compacted by shrinking the gaps, so seek times are reduced. The file ordering is preserved however. Nearly all redump (untouched) images have the files pushed to the outside of the disc for better read speeds. Dolphin emulates hardware seek (and load?) times. So there will be differences. Not sure how this affects USB loaders. Probably not much.
Last edited by nanook,
Thought I'd report this error I got recently:
Failed processing RecoverReaderWii -> IsoWriter : Partition alignment error, this could be a bug when adding missing partitions
Let me know if you'd like more information...
Failed processing RecoverReaderWii -> IsoWriter : Partition alignment error, this could be a bug when adding missing partitions
Let me know if you'd like more information...
O.K., I'm not hip to any of this, I just want to shrink Wii iso's from the CLI, so...
1. How do I use the CLI without having to input [RETURN]? Should I use something like < yes to negate that hiccup?
2. --help isn't present, so does it have switches? The only help I see refers to a XML text file, so unless I cp dozens of different XML files, I'll have to use a SAX parser, grep, or something enstranged to configure a CLI program.
3. Are reference tables (.dat's and maybe other things) a requirement?
4. What am I doing :-P. I'm looking for 2 things: 1. The smallest fully preserved image. 2. The absolute smallest, fully playable image.
Being that --help is absent, I'm a little lost on how to start trial and error. I thought per source image I'd just create 1 of the best preserved images and loop through a few different configurations to find the smallest image possible.
1. How do I use the CLI without having to input [RETURN]? Should I use something like < yes to negate that hiccup?
2. --help isn't present, so does it have switches? The only help I see refers to a XML text file, so unless I cp dozens of different XML files, I'll have to use a SAX parser, grep, or something enstranged to configure a CLI program.
3. Are reference tables (.dat's and maybe other things) a requirement?
4. What am I doing :-P. I'm looking for 2 things: 1. The smallest fully preserved image. 2. The absolute smallest, fully playable image.
Being that --help is absent, I'm a little lost on how to start trial and error. I thought per source image I'd just create 1 of the best preserved images and loop through a few different configurations to find the smallest image possible.
The command line will process files based on any masks.There is help here: https://wiki.gbatemp.net/wiki/NKit
The .config file has an option that you can set to false: <add key="WaitForKeyAfterProcessing" value="true"/>
You need the dats to verify if images you're processing are good.
1: Smallest preserved image is nkit.iso (then 7zip it). Not playable
2: Smallest playable is currently nkit.gcz
Hope this helps
The command line only supports masks for files to process. All other options are modified by setting the config file. If you're using Linux it has been reported that mono might have trouble reading the config file (It's still unconfirmed). This will need to be looked at.
Well, I haven't tried Wii yet, but I tried some GC images and ultimately you might as well use gcz. Using 3 different images, the average from the resulting iso was....
iso = 100%
gcz = 96.4%
7z = 94.5% ; for 7z I didn't test, I simply used the highest values of everything and set CPU threads to 1 (Largest image took at most 34GB of RAM to compress).
I've written a simply python script to handle the "appSettings" and "gamecube" sections (just paths need attention in "gamecube"). If I continue to Wii I'll finish it and post the script so the CLI is usable. But yeh, for Gamecube, just use .gcz.
iso = 100%
gcz = 96.4%
7z = 94.5% ; for 7z I didn't test, I simply used the highest values of everything and set CPU threads to 1 (Largest image took at most 34GB of RAM to compress).
I've written a simply python script to handle the "appSettings" and "gamecube" sections (just paths need attention in "gamecube"). If I continue to Wii I'll finish it and post the script so the CLI is usable. But yeh, for Gamecube, just use .gcz.
Last edited by Targi,
Just wanted to say thanks for this tools. I had used NASOS Beta 2 to compress a set of Gamecube ISO's I had quite a while ago. But this tool seems so much more useful. So I spent my time uncompressing, verifying, then compressing using NKit. Now I just need to decide how I want to store them. Not sure if I want to keep them in a usable format like nkit.gcz for dolphin or nkit.iso.7z for maximum compression. I made a little chart on a single game so I can get an idea of what kind of space saving you could get. I know not all games will compress as well as this one did. But you can see you will save more space by choosing one over the other.
Code:
┌────────────────────────────────────────────────┐
│ Gamecube NKit v1.4 Compression Test By AmyGrrl │
├──────────────────────────────┬─────────────────┴───┬────────┐
│ 4x4 Evo 2 (USA).iso │ 1,458,978,240 bytes │ 100.0% │
├──────────────────────────────┼─────────────────────┼────────┤
│ 4x4 Evo 2 (USA).nkit.iso │ 579,272,704 bytes │ 39.7% │
├──────────────────────────────┼─────────────────────┼────────┤
│ 4x4 Evo 2 (USA).nkit.gcz │ 275,959,121 bytes │ 18.9% │
├──────────────────────────────┼─────────────────────┼────────┤
│ 4x4 Evo 2 (USA).nkit.gcz.rar │ 268,290,363 bytes │ 18.4% │
├──────────────────────────────┼─────────────────────┼────────┤
│ 4x4 Evo 2 (USA).nkit.gcz.7z │ 267,911,372 bytes │ 18.3% │
├──────────────────────────────┼─────────────────────┼────────┤
│ 4x4 Evo 2 (USA).nkit.iso.rar │ 210,310,214 bytes │ 14.4% │
├──────────────────────────────┼─────────────────────┼────────┤
│ 4x4 Evo 2 (USA).nkit.iso.7z │ 194,336,290 bytes │ 13.3% │
└──────────────────────────────┴─────────────────────┴────────┘
Last edited by AmyGrrl,
How well does this work with the GCloader ODE? I have full redump ntsc/u set to work with on a 256gb card that I would like to compress to save some space.
@nanook Any update on Mario Kart Fun or Super Paper Mario? Also can you please open source the code before you completely abandon this project?
Not as yet, but now that I know how to accommodate it, it will be fixed in the next update which is being worked on now.
New features so far are:-
- WIA Read Support (inc LZMA, LZMA2 and BZIP2 support)
- CISO Read Support
- WBFS Write support - this will be NKit.Wbfs and will be a verified block removal format. Think Wbfs crossed with how Nasos works
I'm looking to add:-
- Mario Kart Fun support
- Convert to Iso when the Recovery Partition is missing, but the image fine
The SPM issue requires a fundamental change. JosJuice has a new format in the workings based on WIA. NKit will support the creation of this format and will likely replace the NKit format. It will support compression at greater levels than GCZ and be playable in Dolphin. With this on the horizon it doesn't seem right to adjust the NKit format just yet (or ever if the new format takes off)
Edit: Code has been on GitHub for a while. https://github.com/Nanook/NKit
New features so far are:-
- WIA Read Support (inc LZMA, LZMA2 and BZIP2 support)
- CISO Read Support
- WBFS Write support - this will be NKit.Wbfs and will be a verified block removal format. Think Wbfs crossed with how Nasos works
I'm looking to add:-
- Mario Kart Fun support
- Convert to Iso when the Recovery Partition is missing, but the image fine
The SPM issue requires a fundamental change. JosJuice has a new format in the workings based on WIA. NKit will support the creation of this format and will likely replace the NKit format. It will support compression at greater levels than GCZ and be playable in Dolphin. With this on the horizon it doesn't seem right to adjust the NKit format just yet (or ever if the new format takes off)
Edit: Code has been on GitHub for a while. https://github.com/Nanook/NKit
Last edited by nanook,
@nanook Thank you for the update, haven't heard from you in quite a while so I got worried. What's preventing you from adding support for other compression formats in NKit? And would that even make sense considering that at some point the decompression could potentially take too long and would result in lag in emulators?
NKit format is kind of a stealth format. It is basically making a known format have the ability to restore back to the full source image. So ISO, GCZ and soon - WBFS.
NKit can support other compression methods, but they aren't supported by Dolphin. Meaning you may as well convert to nkit.iso and 7zip it.
The new format JosJuice is working on will bring LZMA and hopefully ZSTD to a Dolphin playable format.
If you want Wii hardware support you can use NKit.WBFS although it will have larger file sizes.
Something for everyone hopefully
NKit can support other compression methods, but they aren't supported by Dolphin. Meaning you may as well convert to nkit.iso and 7zip it.
The new format JosJuice is working on will bring LZMA and hopefully ZSTD to a Dolphin playable format.
If you want Wii hardware support you can use NKit.WBFS although it will have larger file sizes.
Something for everyone hopefully
Last edited by nanook,
I think that’s a good way to look at it. The original goal of NKit was to create an archival grade format that was playable in Dolphin NOW. And that goal was achieved.
If all goes well then JosJuice’s work will likely render NKit ISO and GCZ obsolete for Wii. NKit ISO will still be the best choice for GC hardware.
In the end the NKit format and restoring capabilities have helped and will continue to help with cleaning up the mess of bad images out there.
On that note, looking forward to NKit WBFS since there isn’t a single wbfs creator that doesn’t destroy data permanently. WBM, WIT, etc all have edges cases that we discovered during the creation and testing of NKit.
Cheers and thanks for the hard work!
Sent from my iPhone using Tapatalk
If all goes well then JosJuice’s work will likely render NKit ISO and GCZ obsolete for Wii. NKit ISO will still be the best choice for GC hardware.
In the end the NKit format and restoring capabilities have helped and will continue to help with cleaning up the mess of bad images out there.
On that note, looking forward to NKit WBFS since there isn’t a single wbfs creator that doesn’t destroy data permanently. WBM, WIT, etc all have edges cases that we discovered during the creation and testing of NKit.
Cheers and thanks for the hard work!
Sent from my iPhone using Tapatalk
If there are edge cases in the WBFS format that destroy data when used with WIT, the best way would be to describe the issue, provide a test file that gets corrupted by WIT, and tell Wiimm so it can be fixed. Not inventing yet another new file format like nkit-wbfs, for absolutely no reason. I can understand the reasons for NKit, but making yet another variant of NKit for WBFS is pretty useless.
People have asked for hardware usable / wbfs to be created from NKit. It's not a new format, just regular WBFS created in a guaranteed way (like Nasos does it). Only removing junk that's verified to be so.
Similar threads
-
@
RedColoredStars:
DiGiorno Crispy Pan Pizza tasted pretty dang close to Pizza hut pan pizza, but Im not sure if theyve been discontinued or not. Havent seen them locally for a couple of months now. -
-
-
-
-
-
@
RedColoredStars:
Never even seen a tiger crust pizza in any stores around here. Walmart, Cub, or otherwise.
-
-
-
@
RedColoredStars:
Last thing I told her is how much I love her, and that Im not leaving her there forever and I promise to come back and take her back home with me.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
