Homebrew Question Rom Trimming - XCI-Explorer vs XCI-Cutter

[roden]

Hi all,

Just been experimenting with these 2 tools.

I just trimmed minecraft and they both trim a whopping 1gb+ of the rom 1.9gb to 900mb or so.

XCI Cutter seams to write the entire file again witch is quite slow, but trimmed, as XCI Explorer just instantly cuts of the unneeded data. But no Batch Option .

Now my question is as i dont quite understand, why the hell is there 1gb of extra padding that does not need to be there?. and is it safe to do this to all my roms?

Confused...

 

[yusuo]

It's safe, I've been trimming all my roms. It's more than likely it's just on a 2gb card. Alot of 0's to fill up that card. All you're doing is deleting those 0's

 

[roden]

But why do they fill the card and not just write whats needed to it?

 

[huma_dawii]

Anyone knows hot to get a titlekey?

 

[Type_O_Dev]

But why do they fill the card and not just write whats needed to it?

This is done because the game carts are set storage amounts like sd cards 2,4,8 ect... These tools trim unused space

 

[DocKlokMan]

Hi all,

Just been experimenting with these 2 tools.

I just trimmed minecraft and they both trim a whopping 1gb+ of the rom 1.9gb to 900mb or so.

XCI Cutter seams to write the entire file again witch is quite slow, but trimmed, as XCI Explorer just instantly cuts of the unneeded data. But no Batch Option .

Now my question is as i dont quite understand, why the hell is there 1gb of extra padding that does not need to be there?. and is it safe to do this to all my roms?

Confused...

When they write games to the storage chips they fill ALL the space available so it can't be written to with additional data later. When dumped this extra space shows up in the file as padding. It's been a thing with ROMs since dumping ROMs from storage chips was a thing.

Also, it's not the file copying that takes XCI-Cutter so long (though it does add a little bit of time) it's the fact it checks the padding for any unexpected data before trimming it while XCI-Explorer does not. However, there's trimmers that also check for unexpected data but don't take as long. The reason why XCI-Cutter takes so long is that it checks this padded data a single byte at a time rather than in groups of bytes.

 

[Insane]

When they write games to the storage chips they fill ALL the space available so it can't be written to with additional data later. When dumped this extra space shows up in the file as padding. It's been a thing with ROMs since dumping ROMs from storage chips was a thing.

Also, it's not the file copying that takes XCI-Cutter so long (though it does add a little bit of time) it's the fact it checks the padding for any unexpected data before trimming it while XCI-Explorer does not. However, there's trimmers that also check for unexpected data but don't take as long. The reason why XCI-Cutter takes so long is that it checks this padded data a single byte at a time rather than in groups of bytes.

Another issue with speed could also be that the gui progess bar is updated too often. By reducing the number of updates I was able to speed up a tool.

 

[roden]

Cool, what we need now is an auto renamer and trimmer in one

 

[Insane]

Cool, what we need now is an auto renamer and trimmer in one

Well all the xci tools are open source, so we can hopefully have it at some time

 

[Brawl345]

XCI Cutter seams to write the entire file again witch is quite slow

You need to check "fast mode" in XCI Cutter, then it processes the file directly (don't know if it only is available in batch processing mode).

 

[roden]

Fast mode is always on, thats only for bbb releases.

 

[DocKlokMan]

Cool, what we need now is an auto renamer and trimmer in one

This is a bit more complicated. There's only three ways to gather the title of the game. Either do an online lookup to a database like nswdb for the CRC32 hash (takes time to hash and internet connectivity to look up, doesn't work for releases not yet listed or for files that were already pre-trimmed), use an offline downloaded database such as an XML that still suffers from slow CRC32 calculating and missing entries and failing on pre-trimmed files or using hactool and non-distributable keys to decrypt and extract the info directly from the XCI file which makes the program far less user friendly since they need to supply their own keys.

No matter which approach you take you introduce more complexity.