[Feature request] When a file is an "unknown ROM format", display more information to the user
DerekTurtleRoe opened this issue · 11 comments
When a file is an "unknown ROM format", I think it should display more information to the user so they know which file is having the issue if they have a large ROM folder.
It could be anything really, like the file name, or the SHA-1 or MD5 hash, or something else identifiable that ROM64 already knows.
Scanning a folder with potentially hundreds or thousands of ROM files and getting "Unknown ROM format. Invalid file?" for every file isn't very helpful when that is displayed many many times and you don't know which files are causing the message to appear.
Thanks! 😄
Hello and thanks for getting in touch about an issue in the program.
Is this happening when using the ls command? I'll try to reproduce it. I agree that multi-file operations shouldn't fail when one file has an issue.
Hello and thanks for getting in touch about an issue in the program.
Is this happening when using the
lscommand? I'll try to reproduce it. I agree that multi-file operations shouldn't fail when one file has an issue.
Yes, this happens with the ls command. I should clarify that it doesn't stop multi-file operations, it just fills the terminal/command prompt/PowerShell with those error messages and doesn't let you know which specific ROMs weren't able to be verified.
So a nice solution would be to put something along the lines of "ROM.z64 was unable to be verified" so you could know exactly which file it was that wasn't able to be verified, so you can check that ROM specifically for issues.
In my case I usually have things like backup unit firmware, flash cart firmware, and various dumps of accessories and such, and those aren't typical ROMs.
I was about to ask what you had in the directory that was causing these issues. The ls command only tries to read files with certain extensions {"bin", "rom", "d64", "n64", "u64", "v64", "z64"}. I should perhaps remove .bin and .rom from the default finder, though ls is meant to be as generous as possible when finding roms. So yeah, including the filename in the message would probably be good enough here, and/or an option to suppress messages about ROMs that weren't valid.
I was about to ask what you had in the directory that was causing these issues. The
lscommand only tries to read files with certain extensions{"bin", "rom", "d64", "n64", "u64", "v64", "z64"}. I should perhaps remove.binand.romfrom the default finder, thoughlsis meant to be as generous as possible when finding roms. So yeah, including the filename in the message would probably be good enough here, and/or an option to suppress messages about ROMs that weren't valid.
Including the file name and allowing the user to suppress messages about invalid ROMs seems like the best solution in my opinion. 😄
Give v0.5.3 a try :)
This is much better! Thank you. 😄
This will make ROM validation much quicker and easier. 👍
Also the clarifications in the README and such are also good, and I can get the hashes that I want as well (if I use the right flag)!
and I can get the hashes that I want as well (if I use the right flag)!
Out of curiosity, which hashes are you after? I almost didn't add MD5 and SHA-1 since there are dedicated command line utilities for calculating those. (sha1sum and md5sum)
and I can get the hashes that I want as well (if I use the right flag)!
Out of curiosity, which hashes are you after? I almost didn't add MD5 and SHA-1 since there are dedicated command line utilities for calculating those. (
sha1sumandmd5sum)
MD5 and SHA-1 are the main ones I wanted, although having CRC32 and SHA256/512 would be nice to have (but definitely not necessary).
I'm also using romjudge to verify and validate ROMs and I'm trying to hack up a way to output everything to a single text file for adding to a database 😄
I'll probably not add other checksums unless there's an N64-specific reason to do it. The command line apps for doing that and they work great (sample below).
romjudge looks nice! I'm doing a feature comparison now and it seems the only thing rom64 is missing is the pi timings. I don't know what those are.
And rom64 doesn't try to "fix" files since you could easily make the problem worse. Like if the CRC in the header doesn't match the calculated CRC, you probably have a bad ROM dump.
$ sha256sum ~/Downloads/n64/*
5e9d7168e5786ba1bd4b643431ba7100ff3d7a09e558acae15438d426c0f34df /home/mroach/Downloads/n64/1080 Snowboarding (Japan, USA) (En,Ja).z64
bc54fad4dd95c6d701634f24fdbb0328d32f8520eaa10e8a0cdb614c5acbee7c /home/mroach/Downloads/n64/40 Winks (Europe) (En,Es,It) (Proto).n64
899b866a45dfbebc8152a3122f28aa0ba906fb448dc6b2dc7c7442e7622b5442 /home/mroach/Downloads/n64/40 Winks (Europe) (En,Es,It) (Proto).z64
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /home/mroach/Downloads/n64/aaaaaaaaaaa.txt
f9ad43f64c3a38b0ca4067e24f570dcb8f3f8fec077c5c342484bcbec7ff6d22 /home/mroach/Downloads/n64/Banjo-Kazooie (USA) (Rev A).z64
9ec37fba6890362eba86fb855697a9cff1519275531b172083a1a6a045483583 /home/mroach/Downloads/n64/Banjo-Tooie (USA).z64
42e4d8cde3c106637a25bbfa62d74cc2e5c1eed1d64de5bbb0b1c4896b185927 /home/mroach/Downloads/n64/Blast Corps (USA) (Rev A).z64
e6da7c26127788cd894b88b71cc055ff9dec0d0f4f8e10d9b15b40153af2b52a /home/mroach/Downloads/n64/Bomberman 64 (USA).z64
32e6a8b970ec12ac5f782344945aa0c98a193832eefb687529d03bab6948714b /home/mroach/Downloads/n64/Conker's Bad Fur Day (USA).z64
7de1a8fb2a9558cfc3d9ad4497df698c1e89cf7095ac1531557df2af40ba8bcf /home/mroach/Downloads/n64/Diddy Kong Racing (USA) (En,Fr) (Rev A).z64
b6347d9f1f75d38a88d829b4f80b1acf0d93344170a5fbe9546c484dae416ce3 /home/mroach/Downloads/n64/Donkey Kong 64 (USA).z64
I'll probably not add other checksums unless there's an N64-specific reason to do it. The command line apps for doing that and they work great (sample below).
romjudge looks nice! I'm doing a feature comparison now and it seems the only thing rom64 is missing is the pi timings. I don't know what those are.
And rom64 doesn't try to "fix" files since you could easily make the problem worse. Like if the CRC in the header doesn't match the calculated CRC, you probably have a bad ROM dump.
That's fair, I was probably going to have to use an alternative application for checksum generation anyway based on how I'm doing things now. 😄
PI timings are to do with the consoles "peripheral interface" which is input-related I believe. It's basically like a serial bus. At least I am 99% sure that's what it is referring to.