SabreTools / MPF

Redumper/Aaru/DiscImageCreator GUI in C#
GNU General Public License v3.0
437 stars 34 forks source link

Wrong PSX executable date extraction #193

Closed superg closed 4 years ago

superg commented 4 years ago

Affected games: Crash Bandicoot - Warped (USA) Final Fantasy VII (USA) (Disc 1) Final Fantasy VIII (USA) (Disc 1) Grand Theft Auto (USA) Legend of Dragoon, The (USA) (Disc 1) Triple Play 2000 (USA) Triple Play 98 (USA) Eidos Demo CD Volume 3 (USA) Interactive CD Sampler Disc 6 (USA) (Rev 1) - BIG DIFFERENCE Interactive CD Sampler Disc Volume 4 (USA) - BIG DIFFERENCE Interactive CD Sampler Pack Volume 3.5 (USA) (Rev 1) R4 - Ridge Racer Type 4 (Japan) (R4 + JogCon) Ridge Racer - High Spec Ver. & Namco Catalogue '98 (Japan, Asia) WCW Backstage Assault (USA) Ridge Racer - High Spec Ver. & Namco Catalogue '98 (Japan, Asia)

Two problems here:

  1. Time offset is still incorrect, most of the games from this list are 1 day later than what is stored in !submissionInfo.txt. I think it comes from time zone conversion introduced by windows (as DICUI is reading the date by accessing the disc directly) so we have to properly convert it "back" to what is actually stored in ISO9660 filesystem. Also windows clock can be configured using either UTC or localtime, so that has to be taken into account, I'm not 100% sure though. I double checked everything using redump database and IsoBuster with local time stamp setting.

  2. "Interactive CD Sampler Disc 6 (USA) (Rev 1)" and "Interactive CD Sampler Disc Volume 4 (USA)" have very different dates because both PSX.EXE and valid SYSTEM.CNF / EXE combination is found on the filesystem. DICUI choose PSX.EXE whereas it should have chosen EXE date from SYSTEM.CNF.

mnadareski commented 4 years ago
  1. I'm not changing this. The tl;dr is that I'm using UTC and not local time. The times being "a day off" is pretty common in that sort of situation. This is a particular issue with Redump as they did not hold UTC as the standard before, so local timezones are what are in most EXE date fields
  2. Interesting that it contains both. Thought it was an either/or scenario. That is an actual issue that needs to be addressed. I can move the PSX.EXE check to after. Though honestly I thought I had that already.