@Sajjo THX, fixed to Microsoft Office 2000 Premium - (1999-03) 98F5A4580A1DD904117ABE416A89F99A278A4FF5 *[ENU] en_Office_2000_Prm_FPP_(v2a)_CD4_19990321_PD001CD2_RR.iso the date is now unified from Folder date - RR (BUZZSAW 1) iso's don't have timestamp in prim iso header
@vanelle Not to make to much fuzz out of this. BUZZSAV 1 images is a little tricky and adding proper date in filename is a really good idea for older images with all their variations and updates The Directory Record for Root Directory contains a 7 byte Recording Date and Time - 0x80AE-0x80B4 which i would use for this specific image 98F5A4580A1DD904117ABE416A89F99A278A4FF5 *[ENU] en_Office_2000_Prm_FPP_(v2a)_CD4_19990321_PD001CD2_RR.iso I would in my case use the "Volume dec time string" rather than the folder datestamp but that's just me. Another file that I trust: 4a4569b303163a53927109954a9f30e89cfead29 *EN_WIN2000_PRO_SP4.ISO You can see strings matches, btw, this is not always true so take it as is but if usual date string is missing then Root Directory string is the next best thing imho. Code: Recording Date and Time Interpretation 1 - Number of years since 1900 2 - Month of the year from 1 to 12 3 - Day of the month from 1 to 31 4 - Hour of the day from 0 to 23 5 - Minute of the hour from O to 59 6 - Second of the minute from O to 59 7 - Offset from Greenwich Mean Time in number of 15 min intervals from -48 (West) to +52 (East) recorded
@Sajjal i know all this verry well and i always use the timestamp from ISO 9660 primary volumedescriptor BTW this is wrong see 8.4.26.1 Date and Time Format here are some information (CSY Vanelle ) for all interested Member ISO 9660 is definned by ECMA please read ISO 9660 Ecma-119.pdf 5.2 Other notation Digit(s) Any digit from DIGIT ZERO to DIGIT NINE Code: 0 1 2 3 4 .... 9 <- DIGIT ZERO to DIGIT NINE 0x30 0x31 0x32 0x33 0x34 .... 0x39 <- hex notation (byte) . . . 8.4.26 Volume Creation Date and Time (BP 814 to 830) This field shall specify the date and the time of the day at which the information in the volume was created. It shall be recorded according to 8.4.26.1. 8.4.26.1 Date and Time Format The date and time shall be represented by a 17-byte field recorded as follows. RBP Interpretation Content Code: 1 to 4 Year from 1 to 9999 Digits 5 to 6 Month of the year from 1 to 12 Digits 7 to 8 Day of the month from 1 to 31 Digits 9 to 10 Hour of the day from 0 to 23 Digits 11 to 12 Minute of the hour from 0 to 59 Digits 13 To 14 Second of the minute from 0 to 59 Digits 15 to 16 Hundredths of a second Digits 17 Offset from Greenwich Mean Time in number of 15 min intervals from -48 (West) to +52(East) recorded according to 7.1.2 numerical value If all characters in RBP 1 to 16 of this field are the digit ZERO and the number in RBP 17 is zero, it shall mean that the date and time are not specified. . back to the RR BUZZSAW 1 problem 17-byte field (hex) in case time are not specified. 0x 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 <- valid TIMESTAMP (it shall mean that the date and time are not specified.) 17-byte field (hex) by RR BUZZSAW 1 0x 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 <- invaid TIMESTAMP ( 0x20 is not a Digit(s)) I hope this explains the problem of RR Buzzsaw 1 and why I use folder (somtimes also file) timestamp in case invalid or not not specified timestamp inside the iso header and always keep in mind 0x30 = Digit ZERO 0x00 = Numerical value ZERO
hmm i talking about 8.4.26 Volume Creation Date and Time (BP 814 to 830) and you (probably) talking about ???? 8.5.12 Directory Record for Root Directory (BP 157 to 190) but you didn' say that you talking about this 8.5.12 Directory Record for Root Directory (BP 157 to 190) This field shall contain an occurrence of the Directory Record for the Root Directory. This field shall be recorded according to 9.1 Code: 9.1 Format of a Directory Record Table 8 – Format of a Directory Record BP Field name Content 1 Length of Directory Record (LEN-DR) numerical value 2 Extended Attribute Record Length numerical value 3 to 10 Location of Extent numerical value 11 to 18 Data Length numerical value 19 to 25 Recording Date and Time numerical value (BP 157 + 19 -1 = BP 175) (BP 157 + 25 -1 = BP 181) -> BP 175 - 181 for the CD4 0x 63 03 18 00 1F 07 00 Code: 0x63 > dec 99 + 1900 = 1999 <- 1 Number of years since 1900 numerical value 0x03 > dec 03 <- 2 Month of the year from 1 to 12 numerical value 0x18 > dec 24 <- 3 Day of the month from 1 to 31 numerical value 0x00 > dez 00 <- 4 Hour of the day from 0 to 23 numerical value 0x1F > dec 31 <- 5 Minute of the hour from 0 to 59 numerical value 0x07 > dec 07 <- 6 Second of the minute from 0 to 59 numerical value 0x00 > Signed char = dec range -128 to +127 > dec 00 / 15min = 00 h <- 7 Offset from Greenwich Mean Time in number of 15min intervals from -48 (West) to + 52 (East) recorded result = 19990324 (from Directory Record for Root Directory) <- this is not a file or folder timestamp may be this is a good fallback but first i will check on other old MS CDS
@vanelle I did but I see that I could be more clearly, for this I apologize. Here is a few examples where we can not blindly trust this datestamp btw: Code: BDF06E39ACA1E31AA55DB60C01BB0B9D00A01966 *WIN95_OPKIE.iso WIN95_OPKIE MICROSOFT CORPORATION MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA 98052, (206) 882-8080 CDIMAGE V2.03 (03/28/95 TM) Image master time: 0000-00-00 00:00:00:00 0x00 Image master tz: 0x00 Volume hex time string: d5 01 01 00 00 00 00 Volume dec time string: 213 1 1 0 0 0 0 00008320 20 20 20 20 20 20 20 20 20 20 20 20 20 30 30 30 000 00008330 30 30 30 30 30 30 30 30 30 30 30 30 30 00 30 30 0000000000000.00 00008340 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 30 00000000000000.0 00008350 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 000000000000000. 00008360 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 00008370 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00008380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00008390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Date: 00000000 Time: 000000 -------------------------------------------------------------------------- 4a7469d39d41077e4f479a149aed9ee99b246b74 *en_vs_2005_pro_cd1.iso VSPROD1 MICROSOFT CORPORATION MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA 98052, (425) 882-8080 CDIMAGE 2.47 (10/12/2000 TM) Image master time: 2005-10-20 17:00:00:00 0xE4 Image master tz: 0xE4 Volume hex time string: 69 0a 14 16 2d 2c e4 Volume dec time string: 105 10 20 22 45 44 228 00008320 20 20 20 20 20 20 20 20 20 20 20 20 20 32 30 30 200 00008330 35 31 30 32 30 31 37 30 30 30 30 30 30 e4 30 30 5102017000000.00 00008340 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 30 00000000000000.0 00008350 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 000000000000000. 00008360 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 00008370 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00008380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00008390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Date: 20051020 Time: 170000 First image is, again, what I trust is the real deal. Second image is official, verify by SHA1, you can see datestamp is symmetric but timestamp differs slightly. Indeed it could be a good fallback, I use it if that's all there is available but it can also be a puzzle bit in a larger image so it is what it is.
BDF06E39ACA1E31AA55DB60C01BB0B9D00A01966 *en_win95a_osr1.0_OPK_19960117_WIN95_OPKIE.iso 8.4.26 Volume Creation Date and Time (BP 814 to 830) 0x 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 <- valid TIMESTAMP (it shall mean that the date and time are not specified.) 8.5.12 Directory Record for Root Directory (BP 157 to 190) -> BP 175 - 181 (Recording Date and Time numerical value) 0x D5 01 01 00 00 00 00 0xD5 > dec 213 + 1900 = 2113 0x01 > dec 01 0x01 > dec 01 ... result = 21130101 (from Directory Record for Root Directory) <- does not make anny sence 19960117 (from DOCS\OPKUG-E.DOC) <- max file / folder time and mentiond on the cd itself conclusion for old stuff (from my test's until now) 8.5.12 Directory Record for Root Directory as a fallback in most case does not give a good result (only works on rare eg RR Buzzsaw 1 images) in case 8.4.26 Volume Creation Date and Time is invalid or not defined take Timestamp from max file / folder time,which is the simplest and safest way
you can be shure that tis iso is valid its rip from Microsoft Confidential CD BDF06E39ACA1E31AA55DB60C01BB0B9D00A01966 *en_win95a_osr1.0_OPK_19960117_WIN95_OPKIE.iso
1) Microsoft Office 95 Professional Retail Russian 0296 Part no. 79804. Version: 7.00a.2411 Pro Microsoft Word 7.00.4907 Microsoft Excel 7.00.4915 Microsoft PowerPoint 7.00.994 Microsoft Access 7.00.005 Microsoft Binder 7.00.2616 Microsoft Shedule+ 7.00.417.93 Microsoft Office Manager 7.00.2404 Size: 55 752 704 Bytes SHA-1: D01D092C7C0BA87BDD9409D03196A6AF805D8E20 https ://archive.org/details/offp-95-bsu-01 2) Microsoft Office 97 Professional (SR-0) Retail Russian 0297 Part No. 87146 RU Version: 8.00.3910 Pro Size: 359 946 240 Bytes SHA-1: A1BC2D8684898F2CCDE83A1E129B63C52BFB54A7 3) Microsoft Office 97 Professional SR-1 Retail Russian 1097 Part No. X00-12025 Version: 8.01.4307 Pro Size: 390 187 008 Bytes SHA-1: 8DBCAD12540417549E929A1750F7F3AEFB2DD211 2) and 3) here: https ://archive.org/details/offp-97-su-01 2) OFFP97_SU01.iso - SR-0 3) OFFPSR_SU01.iso - SR-1
Microsoft Office 2000 Professional Retail Turkish Version: 9.0.2812 Disc1: 0499 Part No. X04-78031 TR (O9PROCD01.iso) - Microsoft Word - Microsoft Excel - Microsoft Outlook - Microsoft PowerPoint - Microsoft Access - Microsoft Office Server Extensions - Microsoft Internet Explorer 5 Disc2: 0499 Part No. X04-78035 TR (O9PRMCD02.iso) - Microsoft Publisher [English] - Microsoft Small Business Tools [English] - Paylaşılan Küçük Resimler (Shared ClipArts) O9PROCD01.iso: 599 592 960 Bytes SHA-1: A77F9BEA6A6BDC7866304C37AF8F38AD7CE6DEED O9PRMCD02.iso :639 621 120 Bytes SHA-1: A1451A9B872BE36526948824C13BD4650F12538 https: //archive.org/details/o-9-prmcd-02_202208
@Sajjo Interesting, why russian office images looks like repacks? I leave note about office 95, that it was lazy prepared by Microsoft from floppy version, but i thought that office 97 was okay. "kiot" from old-dos also shared some photos of his collection (unfortunately, only boxes, not discs), and it looks like those dumps are from original media. Maybe he doesn't dump it properly (because i'm removed overdump before uploading to archive.org)?
@archIvarIus3k I may have been a little hasty in my judgement, for that i apologize. The Russian Office 97 images: I can not find any suspicious other than a volume timestamp > 000000 (not datestamp btw) This is same timestamp with the Office 95 image, btw. However: there is also a ISO header date and timestamp, that can be a guideline in this puzzle with older images, and compared to this I do question images. Back to Office 95: I know this mastering version and never seen such binary artifacts in the header area. It could have been remastered with a patched mastering tool, it could also very well have been mastered with a genuine master tool directly to a bad cd burner as well but then again I would expect to see more binary artifacts in total than just in the area known to have been modified/patched with mastering tool. I would very much like too see a secondary redump of true images with all the bells and whistles from a verified source just to compare and confirm that they are in fact the good stuff. Again, files and folders looks correct and I know this seems like nitpicking... Opinions and quantitative research that proves my doubt and opinions wrong is highly appreciated btw. Any questions and doubts should be addressed, like most things in life imho. Kind regards
@Sajjo Unfortuantely, those dumps originated from local collector on old-dos, so i cann't do redump Btw, i'm also founded that weird timestamp "000000" here: https://forums.mydigitallife.net/th...ons-for-collectors.53435/page-11#post-1749383. That disc came from the same person.