The Spam Club

» The Spam Club - Life, The Universe and Everything - Software Galore - Civilization1 474.01 CRC Check
ReplyNew TopicNew Poll

Civilization1 474.01 CRC Check

Posted at 01:11 on September 22nd, 2014 | Quote | Edit | Delete
Avatar
Member
Student Gumby
Posts: 25
I've recently backed up my copy of Civilization and it ran into three sector errors near the end of the disk (hoped it didn't include any data). Did a CRC check between it and a scene release from back in 1991 and everything matched up except CIV.EXE, ICONPGD.PIC, ICONPGE.PIC, ICONPGT2.PIC. Then did a quick google search and found the scene release cracked the .EXE and that mine matched up with retail, but I'm stumped on the last three files.

ICONPGD.PIC - AB12692C - 11/12/1991 4:19:00 PM
ICONPGE.PIC - 2577DF0B - 11/12/1991 4:20:38 PM
ICONPGT2.PIC - EABAEEF7 - 11/26/1991 5:42:44 PM

Does anyone have access to a copy that they could confirm these for me? Thank you

Also does anyone know if those three bad sectors will negatively effect a 1:1 image even if no data was contained there?
Posted at 08:11 on September 22nd, 2014 | Quote | Edit | Delete
Member
Student Gumby
Posts: 33
Originally posted by comradesean at 01:11 on September 22nd, 2014:
Also does anyone know if those three bad sectors will negatively effect a 1:1 image even if no data was contained there?

If there was no data, it won't affect anything, apart from the images not matching a good dump.

As for your question about the three files: make another backup and compare the three files from both backups. Since bad sectors give random data, the files will be different (again) between the two backups - should they are stored on the bad sectors. If all files match between both backups, the bad sectors are unused.
-----
Edited by batman at 08:12 on September 22nd, 2014
Posted at 14:38 on September 22nd, 2014 | Quote | Edit | Delete
Avatar
Member
Student Gumby
Posts: 25
It looks like these files were located within the bad sectors. The strange thing is that while I'm getting some mismatches between rips, I'm also getting matches across different rips. Shouldn't this be impossible given the randomness of it?

On that note, would knowing the location of the sectors and having the original files on hand help in any way to manually correct this? I could also mount the disk image and overwrite the files over within an VM dos shell. This will keep the date modified correct, but I'd imagine it'd reposition the file/s in the filesystem, right?

EDIT:
Alright, I'm sort of going off on my own here so stop me if I stop making sense. I always considered magnetic media to be more fragile than optical, so I never thought that reading bad magnetic data multiple times would yield any sort of results. I've managed to get two identical disk rips here yielding similar CRCs which I'd imagine would be very improbable if it wasn't an accurate reading. On top of that, ICONPGE.PIC now matches up with the scene release.

ICONPGD.PIC and ICONPGT2.PIC are still the same CRCs I provided earlier. I'm not done yet, because I have an additional anomaly here where this guy linked me 474.04 files w/diff dates and still matched with the scene release, but I'm not sure how to continue without something more substantial to compare my CRCs against.

FURTHER EDIT:
Did some hex compare/editing and I'm noticing very large corruptions in two of my images. Does this sound normal for something with so very few sector errors? I was able to manually correct images 5 and 6 (note: only resolves ICONPGE.PIC), but until I get off work I won't be able to make more images to work with.

Quote:
All images compared against my current image which matches all files except ICONPGD.PIC and ICONPGT2.PIC

IMAGE 1
Address:0011D7D0 Offset:0B,0C,0D,0E,0F
Address:0011D7E0 Offset:ALL
Address:0011D7F0 Offset:ALL
Address:001213D0 Offset:0A
Address:00124FD0 Offset:0A

IMAGE 2
IDENTICAL

IMAGE 3
Address:0011D7D0 Offset:0A,0B,0C,0D,0E,0F
Address:0011D7E0 Offset:ALL
Address:0011D7F0 Offset:ALL
Address:001213D0 Offset:0A,0B,0C,0D,0E,0F
Address:001213E0 Offset:ALL
Address:001213F0 Offset:ALL


IMAGE 4
IDENTICAL

IMAGE 5
Address:00124FD0 Offset:0A

IMAGE 6
Address:001213D0 Offset:0A


IMAGE 1 VS IMAGE 3
Address:0011D7D0 Offset:0A,0B,0C,0D,0E,0F
Address:0011D7E0 Offset:ALL
Address:0011D7F0 Offset:ALL
Address:001213D0 Offset:0A,0B,0C,0D,0E,0F
Address:001213E0 Offset:ALL
Address:001213F0 Offset:ALL
Address:00124FD0 Offset:0A
-----
Edited by comradesean at 17:49 on September 22nd, 2014
Posted at 18:39 on September 22nd, 2014 | Quote | Edit | Delete
Avatar
Member
Student Gumby
Posts: 25
Okay, I did some hex compares on the known files and files exported from the disk image, recorded the differences and then located the problem areas in the disk image. There were 3 values that needed changed which matched up with the number of bad sectors and now the CRC matches up correctly. I'm assuming the more corrupted images were just a result of a poor reading.

Quote:

ICONPGT2.PIC
00124A10 09 = 77
00124FD0 0A = 49

ICONPGD.PIC
0011D7D0 0A = E4


Now, would this still count as a 1:1 disk image since technically the structure was kept intact? Also do you guys mind if I just link to the image on the forums?
-----
Edited by comradesean at 18:46 on September 22nd, 2014
Posted at 18:40 on September 28th, 2014 | Quote | Edit | Delete
Member
Student Gumby
Posts: 33
Originally posted by comradesean at 18:39 on September 22nd, 2014:
Now, would this still count as a 1:1 disk image since technically the structure was kept intact?

If the CRC matches a good dump, then yes. Otherwise, no.

Originally posted by comradesean at 18:39 on September 22nd, 2014:
Also do you guys mind if I just link to the image on the forums?

Personally, I think images that are known to come from damaged disks should *not* be published. People tend to spread things leaving important information aside, so the images may turn up somewhere else with no info that they are from damaged media.
ReplyNew TopicNew Poll
Powered by Spam Board 5.2.4 © 2007 - 2011 Spam Board Team