[3DS, possibly other systems] Trimming is not correctly recognized

[d0k3]

Paste the command

(from my .sh script)

eval "$IGIR $igir_command_options
--dat "$dats_path"/*.dat
--input "$roms_path"
move zip test clean report
--output "$roms_path"/{es}
--clean-backup "$BACKUP_PATH"
--input-checksum-max CRC32
--input-checksum-archives never
--overwrite-invalid
--cache-path "$CACHE_PATH"
--report-output "$log_file""

Describe the bug

I see that trimming recognition is built in now, but it does not work for any of my 3DS images (48 images tested). I checked one and noticed the padding was 0xFF (trimmed size 91,917,824 byte, full size 134,217,728 byte). The last few bytes in the checked rom were all 0x00 (contrary to the correct padding, so that's where the error may come from).

Expected behavior

igir should try both, 0x00 and 0xFF to pad to the next power of 2, and use both checksums for checking.

Debug logs

As this is somewhat of a followup-bug, and as I'm still struggling with the caching issue (#1596, meaning one complete run with my script takes hours), I'm taking the freedom of not providing this right away. Let me know if you really need it, I can add it at a later point.

DAT(s) used

Nintendo - Nintendo 3DS (Decrypted) (20250803-001242).dat

igir version

4.1.2

Node.js version

22.17.0

Operating system

Linux Mint

Additional context

On another note and also completely unrelated here, the file extension is very important for 3DS dumps. Alhazar uses .CCI and nothing else, while the dat has all .3DS. I think there is already some command line option for that (i.e. keeping the original extension) buried inside igir, but I'm not completely sure.

[emmercm]

Can you provide a few examples of trimmed files and the expected untrimmed file, specifically: file name, file size, and CRC32?

---

See https://igir.io/output/options/#fixing-rom-extensions for the docs on extension fixing. The default behavior is that Igir only changes extensions when you don't provide any DATs.

[d0k3]

Here's one (small file size) example:

Cubic Ninja (Europe) (En,Fr,De,Es,It,Nl).cci

Trimmed (checked, this is identical with the untrimmed one, except the padding): 91,917,824 byte e88ec4a2

Untrimmed: 134,217,728 byte cb0a45c5

If I add 0xFF up to the end of the untrimmed file, I get the trimmed file as a result.

[d0k3]

I did another test with a small set of 50 trimmed game dumps. I untrimmed each of those manually, by adding 0xFF until the size is the next biggest power of 2, and used igir and Nintendo - Nintendo 3DS (Decrypted) (20250803-001242).dat to check and rebuild the files (using move and zip).

Observations:

• In trimmed state, 0/50 were recognized by igir
• In (manually) untrimmed state, 49/50 were recognized by igir
• The only file not detected is "Mega Man Legacy Collection (USA).cci", which, despite having an a size (of the actual data) below 512 MiB, uses a 1024 MiB gamecart. A case such as this one should be pretty rare, but it shows the limits of trimming detection.
• Despite not specifying --fix-extension, the extension inside the ZIP files was changed to .3DS