The MAME-SHA1 does not match MAME so either this is a bad rip or MAME is off. I'll leave it to the MAME experts for that determination. I wouldn't be surprised if my disc is off as it does have some scratches.
Title: TRF GDROM BOOT UPDATE Media ID: 1F7C Media Config: GD-ROM1/1 Regions: J Peripheral String: 0000000 Product Number: GDT-0011 Version: V1.000 Release Date: 20031110 Manufacturer ID: Mould SID Code: IFPI 39B7 Inner Ring Code: GDT-0011 1MS1 C 3Y Mastering SID Code: IFPI L223 PIC Outer Label: PIC Chip Stamp: PIC Chip Type: PIC16F628A-1/P PIC DES Key: E0B9043E4C4F40BC (Worked for me though not sure it's original!)
Hardware: Dreamcast USA HKT-3020 (1) with Broadband HIT-0400 Software: httpd-ack-20080711 on Windows 10 with Chrome, and custom PowerShell script
A pretty good way to see if your dump is good is to redump it 1-2 more times. If hashes are consistent, it is extremely unlikely that your dump is faulty.
To possibly save some work, try first the track02.raw, as audio tracks are far more prone to errors than data tracks. Any time I had a problem audio track, checksums would change EVERY time I dumped the track again (it's the nature of error correction in audio that makes it behave like that). If you arrive at this crc 288f3d54 3 times in a row, then its' solid IMHO. If it changes, you know what is wrong already.
On the other hand, data tracks usually come back with an obvious error message when faulty, but as there have been historically a few cases where the dump finished but the hash was off, it is worth trying to dump those another couple of times too, but only after you are sure your audio track is correct.
Thank you for the knowledge, it will help going forward. I thought it was odd as the tracks were perfect but the generated CHD SHA1 did not match MAME's SHA1. MetalliC contacted me and he verified the dump is good and turns out MAME was wrong. My updated dumping method turns out to fix all the initial bad track issues I experienced all the time when I first started.
speaking in general, I'd say it is enough to dump data tracks once and check them using "EccEdc" or similar tool, if there will be no errors - I see no good reason to redump these tracks.
only audio tracks should be dumped several times to make sure sectors was dumped stable same.