Topic: Primary Volume Descriptor timestamps

I have noticed something peculiar on some date and time entries. For example http://redump.org/disc/36653/

Creation     31 39 39 39 30 32 32 32 31 39 32 37 35 34 37 31 B9  1999-02-22  19:27:54.71 +46:15
Modification 31 39 39 39 30 32 32 32 31 39 33 32 32 34 31 37 E6  1999-02-22  19:32:24.17 +57:30
Expiration   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ....-..-..  ..:..:..... +00:00
Effective    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ....-..-..  ..:..:..... +00:00

A GMT offset of more than two days is a time zone I’ve never heard of.
The binary dump is the same as mine, but I suspect the GMT offset calculation is off.

The time stamps in the Primary Volume Descriptor are represented by 4 17-byte fields.
The ECMA-119 / ISO 9660 standard states that the 17th byte must be interpreted as the

Offset from Greenwich Mean Time in number of 15 min intervals from -48 (West) to +52 (East) recorded according to 7.1.2

So the offset must be between -48 times 15 minutes and +52 times 15 minutes. That’s -12:00 to +13:00 GMT.
A GMT offset of +46:15 falls outside this scope.

Chapter 7.1.2 of the standard states:

8-bit signed numerical values. A signed numerical value shall be represented in binary notation by an 8-bit two's complement number recorded in a one-byte field.

It looks like the 0xB9 is interpreted as an unsigned integer (values between 0 and 255). B9 in hex is 185 decimal. 185 times 15 minutes corresponds with +46:15. But the byte must be read as a signed integer (values between -128 and 127) which makes it -71. The GMT offset would then be -17:45.

I’ve made a quick and dirty tool which reads the time stamps from a dump and displays them.
https://mega.nz/#!mB90QDRK!L770pvDcAzsQ … h4jzsdhTnY

pvd_timestamps.exe "South_Park (Track 01).bin"
Creation     31 39 39 39 30 32 32 32 31 39 32 37 35 34 37 31 B9  1999-02-22  19:27:54.71 -17:45
Modification 31 39 39 39 30 32 32 32 31 39 33 32 32 34 31 37 E6  1999-02-22  19:32:24.17 -06:30
Expiration   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      -  -      :  :  .   +00:00
Effective    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      -  -      :  :  .   +00:00

In short; Is it possible that the GMT offset calculations used by this site mistakes signed integers for unsigned ones?

Re: Primary Volume Descriptor timestamps

Hi, first of all thanks for a notice on this. To be honest I was not paying any attention to the 17th byte because the GMT offset value was not of a much use to me, so i left it as an unsigned integer. But you are right, it should be a signed int. Thanks for the heads up, i will change it smile

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Re: Primary Volume Descriptor timestamps

No problem. Glad I could help.

Would it be ok if I used my tools for new dumps and can I adjust the output in any way to speed up the processing of those posts?

4 (edited by Jackal 2016-02-06 10:21:30)

Re: Primary Volume Descriptor timestamps

I'm hoping that the site is just translating the binary data instead, so that this error will be fixed after changing the code? tongue

Re: Primary Volume Descriptor timestamps

Jackal wrote:

I'm hoping that the site is just translating the binary data instead, so that this error will be fixed after changing the code? tongue

This is just a cosmetical error, there has no raw data been modified.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Re: Primary Volume Descriptor timestamps

I was talking about the ideal way for me to submit the pvd timestamps for my new dumps.
Should I post them as pure binary, with or without spaces, mimic the IsoBuster output or the site format etc.

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 31 39 39                199
0330 : 36 31 31 31 34 31 34 32  36 31 34 30 30 30 31 39   6111414261400019
0340 : 39 36 31 31 31 34 31 34  32 36 31 34 30 30 30 30   9611141426140000
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0360 : 31 39 39 36 31 31 31 34  31 34 32 36 31 34 30 30   1996111414261400
0370 : 30 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   0...............
Creation     31 39 39 36 31 31 31 34 31 34 32 36 31 34 30 30 30  1996-11-14  14:26:14.00 +12:00
Modification 31 39 39 36 31 31 31 34 31 34 32 36 31 34 30 30 30  1996-11-14  14:26:14.00 +12:00
Expiration   30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000-00-00  00:00:00.00 +12:00
Effective    31 39 39 36 31 31 31 34 31 34 32 36 31 34 30 30 30  1996-11-14  14:26:14.00 +12:00
31 39 39 36 31 31 31 34 31 34 32 36 31 34 30 30 30
31 39 39 36 31 31 31 34 31 34 32 36 31 34 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
31 39 39 36 31 31 31 34 31 34 32 36 31 34 30 30 30
3139393631313134313432363134303030
3139393631313134313432363134303030
3030303030303030303030303030303030
3139393631313134313432363134303030

Re: Primary Volume Descriptor timestamps

I think the site only accepts the first input option (IsoBuster format)

Re: Primary Volume Descriptor timestamps

Jackal wrote:

I think the site only accepts the first input option (IsoBuster format)

Yes, i did it to assure that the correct offset value will be used.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Re: Primary Volume Descriptor timestamps

InsideTheVoid, any chance you could modify your program to output IsoBuster formatted PVD data? Or is there a program out there that does so?

Plextor PX-708A | sarami's DiscImageCreator | CloneCD | CDManipulator | Protection ID v6.8.5 | edccchk v1.26
PVD_Dumper.py

Re: Primary Volume Descriptor timestamps

Could you give this build a try?

11 (edited by hiker13526 2017-02-12 04:57:00)

Re: Primary Volume Descriptor timestamps

InsideTheVoid wrote:

Could you give this build a try?

Thank you for the addition!

What language is the program in? Any chance you'd open source it?

There is a bug for some printable bytes like 2D which is a hyphen -. Perhaps your program is only checking for alphanumeric characters and spaces to display them? It should check if a character is printable.

edit There is another bug where the input file is a DVD which has empty PVD data like http://redump.org/disc/13213/. I attached the top 40 KB of the iso to show you an example of a header which the program can not read. I hope it is helpful.

Post's attachments

MOHAirborne_head.bin 40 kb, file has never been downloaded. 

You don't have the permssions to download the attachments of this post.
Plextor PX-708A | sarami's DiscImageCreator | CloneCD | CDManipulator | Protection ID v6.8.5 | edccchk v1.26
PVD_Dumper.py