201 Reply by themabus

(76 replies, posted in General discussion)

http://anonym.to?http://www.ifpi.org/co … -guide.pdf
this document describes 2 different SID codes:
1. IFPI xxxx - Mould code (like for PSX - completely useless, imho http://redump.org/disc/1155/)
2. IFPI Lxxx - Mastering code (like here - indeed associated with master)
so likely those Mastering codes could be used to determine an Audio CD offset as F1ReB4LL hypothize,
but other than that they would provide no further information, imho.
adding those codes for every Mixed Mode CD to current db would make them unsearchable and difficult to access
and would only increase noise.
if their only purpose for us is to be used as Audio CD mastering equipment identifier,
maybe it's beter to keep an Mastering code -> Offset relation table instead

edit:
my Saturn CDs. last two are Dreamcast.
ther's some matches and some new ones
it's interesting that those Mould codes actually still somewhat hint on offset
(also it seems like Sega pressed good half of CDs on a single machine?..)
so we could make an table that would associate two first digits from Mould codes with corresponding Mastering codes
and 2nd table that would list offsets for each Mastering code with their frequencies.

N/A
Offset: 18  (= 12345 ?)
3Q02        T-  32510GP- 02369   A
3Q0C        T-  3107GP-  01161   A
Offset: 222 (= L221 or L223 ?)
3901        GS- 9005P-   00268A  2A2   C 4Y

12345
Offset: 18
3Q0D        GS- 9140P-   01434   A
3Q0C        T-  27903GP- 01716   C

L221
Offset: 222
3901        T-  1505GP-  00295   1M2   C 52

L223
Offset: -607
3928        GS- 9066P-   00550   2M4   C 5Y
Offset: 0
N/A         T-  17401GP- 00547   1M1   C 5Y
3902        T-  20610GP- 01841A  13MB2 C 79
3904        T-  31101GP- 01156   2M2   C 6Y
3904        T-  7612GP-  00741   2MM1  C 63
3904        T-  20205GP- 01087   1MM1  C 6X
3905        GS- 9134P-   01373   2M1   C 71
3905        T-  26405GP- 00800   4MM1  C 65
3905        T-  15035GP- 02199   1M6   C 82
3907        T-  1202GP-  00715   2M3   C 62
3908        GS- 9084P-   01101   2MB1  C 6X
3910        T-  27907GP- 02368   1M1   C 88
3910        GS- 9168P-   01946   3MM1  C 7X
3911        GS- 9138P-   01459   1M3   C 73
3912        T-  20106GP- 02075   1M1   C 7Z
3913        GS- 9097P-   01195B  23MB2 C 81
3914        T-  15035GP- 02200   2MB2  C 82
3915        GS- 9133P-   01313A  11MM1 C 6Z
3916        T-  15035GP- 02201   1MM1  C 82
3925        T-  26405GP- 00801   3MM1  C 65
3925        GS- 9037P-   00958   8MB7  C 74
3925        GS- 9037P-   00959   9MB8  C 75
3925        GS- 9096P-   00915   1M5   C 67
3926        T-  4507GP-  02008   1MC2  C 7Y
3927        T-  4502GP-  00698   1M7   C 62
3938        T-  20612GP- 02239A  10MM1 C 84
3965        T-  20106GP- 02076   4MM1  C 7Z
3979        GS- 9097P-   01195   2MB3  C 6Y
3980        T-  9522GP-  01654   1MB3  C 76
3984        T-  15035GP- 02202   2M1   C 82
Offset: 222
3901        GS- 9039P-   00348   5MM1  C 55
3901        GS- 9039P-   00348   4M7   C 56
3901        GS- 9015P-   00298   3B2   C 52
Offset: 1176
3905        T-  9517GP-  01435   1MM1  C 72

L231
Offset: 666
4011        T-  15009GP- 00899-  P1C   V
4011        T-  13306GP- 01007-  P1C   V
4011        T-  2103GP-  00887-  P1C   V
4021        GS- 9129P-   01412-  P3C   V
4011        T-  30001GP- 01272-  P1C   V
Offset: 672
4111        T-  20301GP- 01276-  P3C   V
4011        GS- 9169P-   02229-  P1C   V
Offset: 1254
4011        T-  14301GP- 01281-  P2C   V
4011        T-  17004GP- 01052-  P1C   V
4011        GS- 9169P-   02230-  P1C   V
4011        T-  35504GP- 02298-  P1C   V
4011        GS- 9034P-   00693B- P1C   V
4011        T-  14304GP- 01751-  P1C   V
4011        GS- 9194P-   02221-  P1C   V
Offset: 1260
4011        GS- 9101P-   01012A- P1C   V

L237
Offset: 390
4001        T-  13301GP- 00418-  P1K   V
4011        GS- 9051P-   00697-  P1K   V
4011        GS- 9159P-   01823-  P1K   V
4011        T-  14301GP- 01280-  P2K   V
4011        T-  14304GP- 01750-  P1K   V
4011        T-  14304GP- 01752-  P1K   V
4011        GS- 9194P-   02222-  P1K   V
4011        T-  30001GP- 01270-  P2K   V
4011        T-  30001GP- 01271-  P1K   V
4011        T-  30001GP- 01273-  P1K   V
4011        T-  5305GP-  01098-  P1K   V
4011        T-  13322GP- 02013-  P1K   V
Offset: 396
4011        GS- 9169P-   02228-  P1K   V
Offset: 684
4011        T-  15025GP- 01461-  P1K   V
4011        GS- 9079P-   00579B- P2K   V
4011        GS- 9057P-   00416A- P2K   V
4011        GS- 9099P-   01150-  P1K   V
4011        T-  2103GP-  00886-  P1K   V
4011        T-  22101GP- 01013-  P1K   V
4011        GS- 9050P-   00611-  P1K   V
4011        GS- 9126P-   01302-  P1K   V
Offset: 1860
N/A         T-  1301GP-  00299-  P1K   V
4011        GS- 9013P-   00310-  P3K   V
Offset: 2154
N/A         GS- 9001P-   00259-  P1K   V
N/A         T- 10601GP-  00258-  P3K   V

------------ Dreamcast ------------

L262
Offset: 13
4429        610-7817-0332 MT B03

L046
Offset: 13
6-5-19-NL    MK-51049-0160SS EMI CD HOLLAND @ 6

Go to forum: General discussion

202 Reply by themabus

(14 replies, posted in General discussion)

nice find F1ReB4LL!
also likely sample offsets from the start and the end of file could hint on factory offset,
on a condition that any of those would be common
like for PCE audio would usually start @0, 4000 or 4800
but more generally it's rare to extend over gaps so one could probably guess an offset after correction
so maybe we could set up an system based on such fingerprints

Go to forum: General discussion

203 Reply by themabus

(14 replies, posted in General discussion)

ok, thank both of you!
i've updated database entry to green and added additional offset -294 for now, not to alter existing data
but this general problem remains open
maybe admins could express their opinion

Go to forum: General discussion

204 Reply by themabus

(14 replies, posted in General discussion)

oh i'm sorry. i didn't mean it's an mistake.
this could indeed be an similar CD but with different factory offset.
so it would be great if you could compare at what file offset data starts in Track 01.bin.
if that is the case, we should think of a mechanism to prevent such differences in future.

Go to forum: General discussion

205 Reply by themabus

(14 replies, posted in General discussion)

fuzzball's dump wouldnt match tho AFAICT they look exactly the same.
it's likely to be offset related. i guess canceling drive offset isn't sufficient for Audio CD
and we should think of something else
like we could note first data byte offset for example
also i think it would be better to check that no samples are left out at the start and the end of CD.

Akumajou Dracula X: Gekka no Yasoukyoku bonus disc.
title:
Akumajou Dracula: Music Collection
alt. title:
悪魔城ドラキュラ ミュージック コレクション
ring:
VX010-J1-2F V IFPI L232
barcode:
4988602008111
size 68701920 crc 4330eec4 md5 3c073abfac247dbc0f9e80f39f7099c8 sha1 e7cd470976b333934648336683d76ef73967cf80
size 16600416 crc d27692e9 md5 0cbad78e4386767854ad24b57aa3599c sha1 5de2b0fc157d671dfb06bc2dca340f7182e8885d
size 63555744 crc 4c237c5d md5 47045ec8934e10ca5fd8433eab5ff26c sha1 20505f5cb688a57ac55b75640cd4adff60d133d1
size 41251728 crc f5f79b35 md5 b68d76346dd8c4e269ba571a91aeb23c sha1 8030f2feeace094fcf2214c153f392c9fb9dd631
size 54883920 crc df9eb21b md5 7b0bcb49f8ffbcd77dbaa7ae00e31ca1 sha1 87bab0facd9c65cec2f68accbc1804e8e85408d1
size 41550432 crc c484dead md5 c62b532731855faf94ab8e4c9ad8808b sha1 80c5c82003a204b371574cdeb5ca3ddd197a541c
size 45541776 crc f59c10a4 md5 3d00322f36d08eb1833d331b71004f5b sha1 4b8605e0cbf691e2fc4824ca36c9a82d14f47ec8
size 82719840 crc 6885a335 md5 2a9ad037238337f15bb7a3b2d79b517e sha1 92cc69229df4d23d1c759c560406ee640b958d12
size 31164000 crc 48c12b2f md5 318fb8c6d89bd11a1c9fa739eb19311a sha1 f565328b621a8bf4810d38198d2af06242287faa
size 56426832 crc d22e8d1b md5 3ede1a5fdee775535a0fce0af0f8e5f1 sha1 804d8d233fe2b386cd86a6d644203f8a4a91bd4d
size 57374688 crc 3438226e md5 557d2f25fab550db13fe101cc2df12a3 sha1 a5614e868fc4965a9d85ec3292d0ee93978d8b40
size 36578304 crc 20583728 md5 496fad3e6f6088bfa9728ca41b2412a8 sha1 bc1d6f98f223c20e621757452527926249dfcc67
size 70124880 crc 1c3ca905 md5 cef7bf2e3675ac937b6bdf1d6be56399 sha1 0e5a204de2d2751d0ff03ea06868209feac3fc6e
size 34809600 crc a3910e39 md5 510967e814a805a91f2538e3f2eb5b02 sha1 4527a3376fd4e84db008c7030b9be6ee68cbabac
size 41905584 crc 92309bf6 md5 35d74ecb749314c75d3bc898f7650f96 sha1 a157597373fad185d2277bfb2ac94f6733b53260
size 35785680 crc 81169cd5 md5 7e4bc3ab8eaf6f6d8c3cd3d188ed9ef9 sha1 a0069cbb9d73475ad202fd345391e710d27ffafd
FILE "Track 01.bin" BINARY
  TRACK 01 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:37
FILE "Track 02.bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:49
FILE "Track 03.bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:29
FILE "Track 04.bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:74
FILE "Track 05.bin" BINARY
  TRACK 05 AUDIO
    INDEX 01 00:00:00
FILE "Track 06.bin" BINARY
  TRACK 06 AUDIO
    INDEX 01 00:00:00
FILE "Track 07.bin" BINARY
  TRACK 07 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:69
FILE "Track 08.bin" BINARY
  TRACK 08 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:11
FILE "Track 09.bin" BINARY
  TRACK 09 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:24
FILE "Track 10.bin" BINARY
  TRACK 10 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:29
FILE "Track 11.bin" BINARY
  TRACK 11 AUDIO
    INDEX 01 00:00:00
FILE "Track 12.bin" BINARY
  TRACK 12 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:51
FILE "Track 13.bin" BINARY
  TRACK 13 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:24
FILE "Track 14.bin" BINARY
  TRACK 14 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:00:49
FILE "Track 15.bin" BINARY
  TRACK 15 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:62
FILE "Track 16.bin" BINARY
  TRACK 16 AUDIO
    INDEX 01 00:00:00
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 15. February 2009, 21:34

- / -

Used drive  : PIONEER DVD-RW  DVR-111L   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 48
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to next track

Used output format : Microsoft PCM Converter
Sample format      : 44.100 kHz, 16 Bit, Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.37 |  6:29.47 |        37    |    29258   
        2  |  6:30.09 |  1:33.63 |     29259    |    36296   
        3  |  8:03.72 |  6:00.67 |     36297    |    63363   
        4  | 14:04.64 |  3:52.65 |     63364    |    80828   
        5  | 17:57.54 |  5:11.10 |     80829    |   104163   
        6  | 23:08.64 |  3:56.35 |    104164    |   121898   
        7  | 27:05.24 |  4:18.30 |    121899    |   141278   
        8  | 31:23.54 |  7:48.08 |    141279    |   176386   
        9  | 39:11.62 |  2:56.55 |    176387    |   189641   
       10  | 42:08.42 |  5:19.37 |    189642    |   213603   
       11  | 47:28.04 |  5:25.70 |    213604    |   238048   
       12  | 52:53.74 |  3:28.00 |    238049    |   253648   
       13  | 56:21.74 |  6:36.65 |    253649    |   283413   
       14  | 62:58.64 |  3:18.38 |    283414    |   298301   
       15  | 66:17.27 |  3:55.55 |    298302    |   315981   
       16  | 70:13.07 |  3:22.65 |    315982    |   331196   


Track  1

     Filename C:\redump.org\Track 01.bin

     Pre-gap length  0:00:02.37

     Peak level 95.7 %
     Track quality 100.0 %
     Test CRC 4330EEC4
     Copy CRC 4330EEC4
     Copy OK

Track  2

     Filename C:\redump.org\Track 02.bin

     Pre-gap length  0:00:00.49

     Peak level 90.7 %
     Track quality 100.0 %
     Test CRC D27692E9
     Copy CRC D27692E9
     Copy OK

Track  3

     Filename C:\redump.org\Track 03.bin

     Pre-gap length  0:00:00.29

     Peak level 95.5 %
     Track quality 99.9 %
     Test CRC 4C237C5D
     Copy CRC 4C237C5D
     Copy OK

Track  4

     Filename C:\redump.org\Track 04.bin

     Pre-gap length  0:00:00.74

     Peak level 84.0 %
     Track quality 100.0 %
     Test CRC F5F79B35
     Copy CRC F5F79B35
     Copy OK

Track  5

     Filename C:\redump.org\Track 05.bin

     Peak level 99.6 %
     Track quality 99.9 %
     Test CRC DF9EB21B
     Copy CRC DF9EB21B
     Copy OK

Track  6

     Filename C:\redump.org\Track 06.bin

     Peak level 96.0 %
     Track quality 100.0 %
     Test CRC C484DEAD
     Copy CRC C484DEAD
     Copy OK

Track  7

     Filename C:\redump.org\Track 07.bin

     Pre-gap length  0:00:00.69

     Peak level 92.8 %
     Track quality 100.0 %
     Test CRC F59C10A4
     Copy CRC F59C10A4
     Copy OK

Track  8

     Filename C:\redump.org\Track 08.bin

     Pre-gap length  0:00:01.11

     Peak level 88.8 %
     Track quality 100.0 %
     Test CRC 6885A335
     Copy CRC 6885A335
     Copy OK

Track  9

     Filename C:\redump.org\Track 09.bin

     Pre-gap length  0:00:00.24

     Peak level 92.9 %
     Track quality 99.9 %
     Test CRC 48C12B2F
     Copy CRC 48C12B2F
     Copy OK

Track 10

     Filename C:\redump.org\Track 10.bin

     Pre-gap length  0:00:00.29

     Peak level 89.9 %
     Track quality 100.0 %
     Test CRC D22E8D1B
     Copy CRC D22E8D1B
     Copy OK

Track 11

     Filename C:\redump.org\Track 11.bin

     Peak level 93.8 %
     Track quality 100.0 %
     Test CRC 3438226E
     Copy CRC 3438226E
     Copy OK

Track 12

     Filename C:\redump.org\Track 12.bin

     Pre-gap length  0:00:00.51

     Peak level 91.4 %
     Track quality 100.0 %
     Test CRC 20583728
     Copy CRC 20583728
     Copy OK

Track 13

     Filename C:\redump.org\Track 13.bin

     Pre-gap length  0:00:01.24

     Peak level 81.8 %
     Track quality 100.0 %
     Test CRC 1C3CA905
     Copy CRC 1C3CA905
     Copy OK

Track 14

     Filename C:\redump.org\Track 14.bin

     Pre-gap length  0:00:00.49

     Peak level 96.2 %
     Track quality 100.0 %
     Test CRC A3910E39
     Copy CRC A3910E39
     Copy OK

Track 15

     Filename C:\redump.org\Track 15.bin

     Pre-gap length  0:00:01.62

     Peak level 82.6 %
     Track quality 100.0 %
     Test CRC 92309BF6
     Copy CRC 92309BF6
     Copy OK

Track 16

     Filename C:\redump.org\Track 16.bin

     Peak level 95.3 %
     Track quality 99.9 %
     Test CRC 81169CD5
     Copy CRC 81169CD5
     Copy OK

No errors occurred

End of status report

Go to forum: General discussion

206 Reply by themabus

(2 replies, posted in General discussion)

i've checked how those programs read sectors and they basically do the same:

IsoBuseter 2.5

Sector View ([ ] RAW)
 READ (10)         28h
Sector View ([x] RAW)
 READ CD           BEh F8h (Requested sector)
Extract RAW Data
 READ CD           BEh F8h (0..26) <| 64K buffer - 27 sectors at a time
 READ CD           BEh F8h (27..53)
 ...
 READ CD           BEh F8h (Last-26..Last)

CDRWIN 4.0G

Sector Viewer
 TEST UNIT READY   00h
 READ CD           BEh F8h (Requested sector)
Extract Disc/Tracks/Sectors to Image File ([x] Select Tracks)
 TEST UNIT READY   00h
 START STOP UNIT   1Bh
 TEST UNIT READY   00h
 REZERO UNIT       01h
 TEST UNIT READY   00h
 START STOP UNIT   1Bh 'Analyzing Disc Layout... Please Wait...'
 TEST UNIT READY   00h
 READ TOC/PMA/ATIP 43h
 READ CD           BEh F8h (Sector 0)
 READ TOC/PMA/ATIP 43h
 READ CD           BEh F8h (Last-75)
 READ CD           BEh F8h (Last-75) <| last second of track is checked, one sector at a time. 
 ...                                    even tho it's single-track CD.
 READ CD           BEh F8h (Last)
 REZERO UNIT       01h
 SET CD SPEED      BBh
 MODE SELECT (10)  55h
 READ CD           BEh F8h (0..2) 'Copy Progress'
 READ CD           BEh F8h (3..5) <| 8K buffer - 3 sectors at a time
 ...
 READ CD           BEh F8h (Last-2..Last)
 MODE SELECT (10)  55h
 SET CD SPEED      BBh

ImgBurn

Sector Viewer ([ ] RAW)
 READ (10)         28h
Sector Viewer ([x] RAW)
 READ CD           BEh F8h (Requested sector)
Read
 TEST UNIT READY   00h
 GET CONFIGURATION 46h
 READ CAPACITY     25h
 GET CONFIGURATION 46h
 READ TOC/PMA/ATIP 43h
 READ TOC/PMA/ATIP 43h
 READ TRACK INFORM.52h
 READ CD           BEh F8h (Sector 0)
 READ CAPACITY     25h
 READ CD           BEh F8h (0..26) <| 64K buffer - 27 sectors at a time
 READ CD           BEh F8h (27..53)
 ...
 READ CD           BEh F8h (Last-26..Last)
 READ CD           BEh F8h (Sector 16) ?
 ...
 READ CD           BEh F8h (Sector 21) ?
 GET CONFIGURATION 46h
 READ TOC/PMA/ATIP 43h
 PREVENT ALLOW MED.1Eh
 SET CD SPEED      BBh
 SET CD SPEED      BBh
 READ SUBCHANNEL   42h <| sub-channel is read after main channel has been saved already.
 SET CD SPEED      BBh    likely at lower speed
 ...

IsoBuster does less checks on read, but sector view - it's about the same.
in Sector Viewer always one sector at a time is read,
when making backup - multiple, depending on buffer, but it's the same command.
also CDRWIN always communicate through ASPI and sometimes would use
IOCTL_SCSI_PASS_THROUGH instead of IOCTL_SCSI_PASS_THROUGH_DIRECT
rest programs would prefer _DIRECT unless ther's errors

sometimes CDRWIN would actually return subheader in Sector Viewer, like IsoBuster does
it's strange, it seems to happen when drive is spinning up.

i suspect this all has something to do with my IDE controller  - Jmicron JMB36x, rather than Plextor

Go to forum: General discussion

207 Reply by themabus

(17 replies, posted in General discussion)

here is a list of difficulties we would run into (imho) when moving to no-intro:

1. only lower ASCII in Title/Disc title/Edition ..everywhere
2. all Demos, -bans -> Sample
3. vX.X -> vX.XX
4. AltX -> REV X
5. No-Intro Convention does not define flag for Original releases
6. records with no edition would look the same way as Original edition
7. since flags with default value are omitted some entries would look rather strange -
as if record with no edition (shown) isn't Original

Gran Turismo 2 (Disc 1) (Arcade Mode) (Japan) (Original, PSone Books)
Gran Turismo 2 (Disc 2) (Gran Turismo Mode) (Japan)
Gran Turismo 2 (Disc 2) (Gran Turismo Mode) (Japan) (v1.10) (PSone Books)

Tekken (Japan)
Tekken (Japan) (v1.10) (Original, PlayStation the Best)

but fortunately ther's not too many such records.

8. 'Additional' flag would not work for records with multiple editions
if there would be a way to tell apart PSX releases further than edition, by ring for example, it would be like:

Tekken (Japan) (ring1)
Tekken (Japan) (v1.10) (Original, PlayStation the Best) (ring2)

this flag would relate to whole entry, not just Original edition,
but at least for PSX i don't think those flags would be used at all

9. no-intro do define possibility of multiple regions.
IF there would be record with multiple regions AND multiple editions
relation between those two would be unclear

10. SCPS-45xxx range releases for Asia (ther's about 500 of those)
would be absorbed by matching Japan releases becoming invisible
it means - when such release is added or removed, in .dat nothing would change.
i believe every other release would show, reprints and what-not.
in this case it's different region with different serial and it wouldn't, so i think it's wrong.

.
.
.

so maybe we could start to gradually adapt to those rules.
first 4 conditions could be implemented right now
and then it would only require changes in db parsing to output decent/actually usable .dat
the rest difficulties we would resolve with time.

Go to forum: General discussion

208 Topic by themabus

(2 replies, posted in General discussion)

there were some PSX games for Japan region that would have subheader field modified.
i can't remember all now, but i would mark them having errors in db.
Space Griffon VF-9 is one of those.
it's interesting that Plextor and Lite-On results from IsoBuster (Alcohol, ImgBurn, CloneCD, etc) would not match.
difference is in sectors that have Sync + Header + modified sub-header + everything else set to 0x00
Plextor would not return this modified subheader in such case, but replace it with zeros instead,
so those sectors would look like Mode0.
when trap disc or d8 is used - results would match.
i've made a short sequence of modified sectors to test this further http://www.mediafire.com/?trtzmmmzimn
and results are interesting imho:
ther's only 6 sectors (this violates minimum track length, but i didn't have problems with it)
with 3 different subheader sequences:
2 with 01 02 03 04 - 01 02 03 04
2 with 01 00 02 00 - 01 02 00 00
2 with 01 00 e4 00 - 01 e4 00 00 <| seq. from Space Griffon
recorded it with Alcohol on Lite-On
on Lite-On IsoBuster would in Sector Viewer replace 1st and 2nd sequence with zeros but display 3rd correctly.
on Plextor it would replace 1st and show correctly 2nd and 3rd
(it's strange, because it does not show correctly similar sector from Space Griffon).
but when backup is made from Plextor all 3 sequences are replaced with 0x00 (d8 work correct, however).
also ImgBurn and CDRWin would not display any subheaders in sector viewer on Plextor (so just like backup).

so would such CD (eg. Space Griffon VF-9) be checked multiple times on Plextor (with everything but PerfectRip/CD Tool) -
it would end up in db different from original.
or at least on my PC. maybe it's just my Plextor. it's Premium model.
also - maybe ther's subheader sequences that would return correctly only on d8 or with trap disc.

so would be great if somebody could verify this.

edit:
actually it seems that sector can have data and it will be set to 0x00 as well.
so conditions are: no EDC/ECC, messed up sub-header.

edit:
it's more complex, i've forgot there was modified sub-headers in Imadoki no Vampire: Bloody Bride
there only 4th byte changes, always the same way:
01 08 64 e0 - 01 08 64 f0
and Plextor reads it fine
so last byte doesn't seem to matter

Go to forum: General discussion

209 Reply by themabus

(4 replies, posted in General discussion)

it is indeed a rare case, but i think - not the first one.
one CD is likely more, recent even tho exe date does not differ, it could even be that exe is the same.
ther's some cosmetic changes, maybe, or small fixes, that could be made in data files without recompiling.

Go to forum: General discussion

210 Reply by themabus

(4 replies, posted in General discussion)

hello hardrider

when it's single data track PSX CD, all you need to do is extract it with IsoBuster.
(resizing is for CDs that contain CDDA only.)
calculate CRCs at this point.
then you can do psxt00lz --fix or scan it with CDMage (or such),
if you want to be certain (but don't fix with Mage - just scan)
and would you recalculate CRCs now they should match to previous
(in other words - there should not be errors in last sectors of image
if there are logical errors in other sectors - they should not be fixed)

if this CD isn't in DB yet or if it is but your CRCs differ -
dump it atleast twice and verify that your CRCs always match among themselves

when you do 'psxt00lz "Track 01.bin"' or 'psxt00lz --fix "Track 01.bin"', output should look like:
File: Track 01.bin
Size (bytes):   545120688 (OK)
Size (sectors): 231769 (OK)
and so on
output you got is because physical track size differs from the one stored in image. (because you did resize)

don't worry about having different size from db, when ther's only one track - ther's practically nowhere to go wrong,
so what you have is likely a different version

Go to forum: General discussion

211 Reply by themabus

(22 replies, posted in General discussion)

hello amarok
to fill this field you don't need ClrMamePro.
database will parse specifically formatted strings there (eg CMP output),
but it's enought by such pattern:

size 388790304 crc 94ef1ff8 md5 3b6932e4d5f49ba1b9f16e71f7e3509a sha1 3dd27e476804e2623a7a51e219808d0e1d7f499b
size 10678080 crc 7c51bb00 md5 1101f4e0338390301ddc9f9778b9fe19 sha1 0939872cc375a6457326ac9a478265dc59220cc0
size 7328832 crc 9529a93f md5 f9fda92f05c530b1bb6ddd04a6057b66 sha1 eae19bf80275fc84a66888582dd362395da1816c
size 33167904 crc 337d3287 md5 d461826ca0da4791f660b4ec54e6080c sha1 4b55f5f2d026d08fb55af9de2ad462fa8b8abd0a

Track 01 is 1st entry; Track 02 - next ..and so on
number of entries must match to nr. of tracks in cue-sheet

Go to forum: General discussion

212 Reply by themabus

(76 replies, posted in General discussion)

F1ReB4LL wrote:

It's not needed. Your 'premium' drive also gives shit. So, I'm afraid your theory about PCE CD layouts is beaten smile 'Premium' subs (both normal and 'audio' ones) have either missing or doubled sectors in certain places, that affects pregap length. 'LH-18A1H' subs look reliable, I'll send you all the cues/logs/comments later.
Edit: or maybe the theory is not beaten completely yet...

yes, i'm aware of that. those .SUBs i've sent you were taken on Alcohol or CCD -
both those programs would return slightly 'improved' subchannel info.
AFAIR this could be witnessed most dramatically,
when an ordinary Audio Trap CD with multiple tracks is used to dump other CD
and there would be marks in returned subcode, matching to TOC entries from Trap CD.

edit:
i tried and could not reproduce this on current versions of CCD or Alcohol.
here is fragment from my older post:

Alcohol and CloneCD both masked some problems with subchannel, Alcohol seems to do it somewhat less but it has problems (track data actually gets damaged) with at least saturn data tracks when gap is large - 6 seconds (maybe 5) or more (mode changes on saturn, maybe it does not affect psx, i think i did not test, don't remember really). also when swapping toc with audio cd i think both Alcohol and CCD will output gaps in subcode from audio cd's toc. so it's strange, they like insert gaps in subcode instead of reading, i don't trust them at all after that. CDTool seems to be most accurate.

i used to report bugs like this, so maybe it was fixed with version updates, but i'm nut sure.

but it would be very difficult to convince me, that genereal
Audio->Data 3:00; Data->Audio 2:00; Audio->Audio 0:00
layout is incorrect
or for example, that each CD should have some random gaps instead of all audio - 0:00

on the other hand, i like very much how currently tracks on DC are separated:
all audio sectors in one file; data sectors in other
even though i think it's incorrect regarding INDEXes - i could not check
but i believe gap from Audio->Data it's still likely to be 3:00 seconds large difference, not 2:00.
well but i kind of regret now keeping 3:00 gaps for PCE - where data file would start with audio silence.
only application reproducing correctly CD from such cue sheet is CDRWIN anyway
and even though INDEXes are correct - probably Q-TNO aren't.
so 2:00 in cue sheet, reproduced on different application, might get incorrect Q-Index but correct Q-TNO.
it's as good as 3:00 but much better looking, IMHO.
so it's really more a philosophical thing.

edit:
to avoid confusion:
previously i've mentioned some PCE CDs having this gap set to 2:00, not 3:00 and that i think they should be 3:00.
well what i meant - i think they should not be different from the rest CDs, whichever pattern is chosen.
but i personally prefer Audio->Data being 2:00, so that audio and data sectors would end up separated one from another.

currently dumping by layout would be difficult and tedious unless such gap managment is implemented in imaging application.
so this is my understanding of problem.

Go to forum: General discussion

213 Reply by themabus

(12 replies, posted in General discussion)

AFAIR 'IMAGE.*' were from CCD; 'Audio CD.*' - from Alcohol
it could have been that subcode marks did not reach TOC entries and got corrected.

        1  |  0:00.00 |  0:47.65 |         0    |     3589   
        2  |  0:47.65 |  2:11.15 |      3590    |    13429   
        3  |  2:59.05 |  3:25.63 |     13430    |    28867   
        4  |  6:24.68 |  3:24.69 |     28868    |    44236   
        5  |  9:49.62 |  3:32.67 |     44237    |    60203   
        6  | 13:22.54 |  3:43.54 |     60204    |    76982   
        7  | 17:06.33 |  3:23.06 |     76983    |    92213   
        8  | 20:29.39 |  3:26.68 |     92214    |   107731   
        9  | 23:56.32 |  3:27.47 |    107732    |   123303   
       10  | 27:24.04 |  4:16.54 |    123304    |   142557   
       11  | 31:40.58 |  3:22.18 |    142558    |   157725   
       12  | 35:03.01 |  3:10.66 |    157726    |   172041   
       13  | 38:13.67 |  0:32.04 |    172042    |   174445   
       14  | 38:45.71 |  0:17.21 |    174446    |   175741   
       15  | 39:03.17 |  0:15.39 |    175742    |   176905   
       16  | 39:18.56 |  1:05.64 |    176906    |   181844   
       17  | 40:24.45 |  3:37.40 |    181845    |   198159   
       18  | 44:02.10 |  0:17.56 |    198160    |   199490   
       19  | 44:19.66 |  0:15.32 |    199491    |   200647   
       20  | 44:35.23 |  0:43.66 |    200648    |   203938   
       21  | 45:19.14 |  1:04.03 |    203939    |   208741

i think weird things would happen in that case
but unfortunately i can not verify with 'CD tool' now.
if not, then LH-18A1H likely is wrong - it has various different issues too,
like i think, when taking complete image, it would scramble gaps on PCE CDs
and sometimes everything that's beyond Track 02
but anyway amount of silence @the start of audio tracks is $4000 which is a most common value -
not different from CDs with certain layout

Go to forum: General discussion

214 Reply by themabus

(76 replies, posted in General discussion)

F1ReB4LL wrote:
themabus wrote:

what's the point of checking every CD manually

It's not needed anymore, there's a tool almost ready. 2themabus: i'd like to have some PCE CD ones, if possible (better some tougher ones).

that would be really great. i hope it will solve many things.
but i think - ultimately it's still a person that should make a certain decision.
for example ther's some PCE CDs that have 2:00 Track 01->02 gap, when all the rest have it @3:00.
and it is the only difference: no audio silence part of the gap marked as such in subchannels.
back then i kept those CDs @2:00 but today i would go for 3:00, as with all the rest CDs.
i think such differences has no meaning - they're mostly result of immature mastering equipment (hardware or software)

i hope, that some day there will be an option to reconfigure gaps included in PerfectRip.
for example: if you get 2:00, 1:74, 2:00, 2:01, 2:00, 2:00 - you would be able set them to 2:00 before dumping starts.
so there would be no need of moving sectors or dumping with no gaps,
no difficulties because of different drives returning different layouts.

Go to forum: General discussion

215 Reply by themabus

(76 replies, posted in General discussion)

i'm sorry, but imho regarding gap sizes this is going way too far.
what's the point of checking every CD manually, when in the end it means so little - it's the same data anyway...
why not just take single pattern for gap layout (like data->audio 2:00 audio->audio 1:74)
and go with it whenever deviations from this pattern are small enought, say 01-02 sectors

if ther's some really strange gaps, like KOF'95 - ok, it's different then.
but what's the point of investing time to check whether gap should be 2:01 or 2:00
and after all this, probabbly end up with something like:
0:00
2:00
2:00
2:01
2:00
...
imho it does not make sense anyway...
why not have all neat 1:74 or 2:00 gaps instead?

edit:
i mean - if ther's difficulties with drive and it reports some gaps wrongly because of subcode
i don't think it's a problem really - just go with pattern, no need to analyze thoroughly
(except maybe take a look at sector content at the end of 1st track; beginning of 2nd, where data changes to audio.
but everyone should be doing this anyway)
and when gap structure is analyzed and decision made to keep one or more little different gaps
(because it says so in subcode) - it's still wrong imho

Go to forum: General discussion

216 Reply by themabus

(2 replies, posted in General discussion)

thank you, ulugabi!

about track numbers, i guess it's a bug.
concerning serials - i don't think you could ever find a PC game by serial.
afaik ther's no unitary logic or structure, that would describe timeline or producer or anything.
i also don't believe they would show changes that other fields do not,
like if images of two CDs would differ and the only way to tell this would be by serial.
so it's pretty much useless imho.

Go to forum: General discussion

217 Reply by themabus

(1 replies, posted in General discussion)

it's likely a Joliet file system.
it does not affect CD physically in any way, so dumping - it's the same.

Go to forum: General discussion

218 Reply by themabus

(2 replies, posted in General discussion)

that would be great

Go to forum: General discussion

219 Reply by themabus

(17 replies, posted in General discussion)

thanks.
in various sets there are some records with 'Special Edition' but sometimes it's after dash, like a part of the title,
sometimes in brackets, after title.
i wonder would Original & Special Edition appear something like (Original, Special Edition), perhaps?

Go to forum: General discussion

220 Reply by themabus

(17 replies, posted in General discussion)

about No-Intro
i'm sorry. i've downloaded some .dats from http://datomatic.no-intro.org/ and they do have editions.
it looks a-ok to me, except like Jackal said ther's too many letters.
all those long terms could be expressed with abbreviations.
i don't see a reason to state 'Europe' or 'Limited Edition' all the time when it could be 'E' and 'LE' respectively.
but it's a good compromise.
edit:
i guess the reason is most tags being optional. so that makes sense
it looks like it solves all my objections to .dat. except, i'm not sure how they represent multiple editions for single record.
could somebody provide an example please?
(particularly when original edition match to some other.)
but in any case i like it way better than a current pattern.

still what about differentiation of serials into multiple fields?
edit:
never mind. i guess if we decide to go with No-Intro serials won't matter any longer

Go to forum: General discussion

221 Reply by themabus

(17 replies, posted in General discussion)

thank you for discussion smile

Jackal wrote:

The current logic is that it only uses the first serial that is entered in the db (for easy identification), so if you put a different serial first it will use that one. I'm not sure what's the point of having 4 serials in a filename. It would be the same as having the barcode or publisher or languages or whatever imho. For this information we have the db.

Jackal wrote:

IMHO we should
- only use internal serials in filenames and put any other 'external' information in the db.

yes i understand that. and currently serials for Japanese records are arranged in a such way so exe name always comes first.
if by internal serial you meand exe name, then i disagree.
all this stir up is because i believe currently Japanese records are corrupted.
all other regions would get only one serial for a title - initial (and only).
Japan get as much serials as there are exe names. those exe names has nothing to do with releases. they're nothing to do with anything.
if our aim would be to have name<=>serial relation
then we would have to instead of exe names assign initial serials to all releases of same title in Japan
(thus artificially recreating the same pattern that's used in the rest of the regions)
but i honestly do not see a reason for this. in Japan serial identifies release why can't we just go with that?

Dremora wrote:

Internal serials + disc/box serials.

yes thank's. but wouldn't you agree that ther's certain logic by which Sony assigns serials  to relases.
and everything else - internal serials (exe names? if i understand right) and serials assigned by developers do not belong there
not on the same level. it's additional information the same way ring codes or bar codes are.
and so to keep the same logic we would have to separete those to a different levels.

Jackal wrote:

I also think that for v1.1 etc. dumps that perhaps it would be good to have the # or whatever's printed behind it on the disc in the filename (if such characters are possible in filenames)..

i agree that if that's the serial printed on covers or cd then it should relate to record not exe name.
but as you can see, i don't think serials are really neccessarry in .dat
compromise could be an additional field assignable by offline manager like Rocknroms suggested.

Jackal wrote:

IMHO we should
switch to the No-Intro naming convention and have new issues (like too long filenames) to keep us busy big_smile

Dremora wrote:

I have always been against serials in dat files, so switching to the No-Intro naming convention seems to be a nice idea for me smile

Dremora wrote:

Dat files do not have to contain all the information from the db. Their only purpose is to identify dump, so any information which doesn't participate in making filenames unique is redundant in dat.

well ok. i'm not sure what No-Intro naming convention is but i suspect it has nothing to do with releases more like with languges.
well ok so bare minimum for record would be:
Name (Region) (version)
it's understood - the serial it's redundant information, not really needed.
so changing serial to languages it's better from point of view of database structure - it's not redundant it describes record in more detail.
but ther's problem currently - this bare minimum, given above, it is enought to keep unique records
but it's not enought to identify record on it's own without additional information from db.
adding edition or abbreviation of it to .dat would largely solve this.
unfortunatelly ther's no any more means of what i'm aware to identify records further than edition.
would rings work (like on PCE), i'd vote to include those too (or a part of a ring that's different) - but well they do not.
so edition is as far as we can get. and i believe .dat should provide those means - to get as close to original source as it's possible.
so in other word's syntax like:
Name (Region) (version1)
Name (Region) (version2)
Name (Region) (version3)
it separates record's but it's cryptic. it does not identify source of material.
imagine if we would assigne serial to each record and keep only those serials in .dat (about like Sony)
current situation is an extention of that principle.
we have serials for records within same title and region which is version.

Go to forum: General discussion

222 Reply by themabus

(17 replies, posted in General discussion)

any arguments please.

1. what is the logic behind current assignation of serials to Japanese titles?
2. why are serials relevant at all in .dat file?
3. what is the purpose of .dat?
to provide summary of current state of db and allow people to verify their backups from originals: release with release
this way encouraging participation in project
OR
to comfort people that have downloaded some title somewhere that it match with some backup from unidentifiable original and to encourage redownload of those that don't
OR
something else?

Go to forum: General discussion

223 Reply by themabus

(17 replies, posted in General discussion)

btw if you take a look at Akumajou Dracula X - Gekka no Yasoukyoku (J) (v1.2)
http://redump.org/disc/4684/
it's already wrong in db
both 'PlayStation the Best' and 'PSone Books' are listed, but sole serial (not counting exe name) is: SLPM-87328
this can not be right so either ther's too many editions or too few serials - we have to guess, ther's no way to be certain...
wouldn't there be exe name in serial list - such errors would be easy to notice since there would be as many serials as releases.

Go to forum: General discussion

224 Reply by themabus

(17 replies, posted in General discussion)

according to sonyindex thers ~370 Japanese CDs in PStB/PSOB range alone.
ther's a lot more with all Limited/Special Editions and smaller sets of budged re-releases.
roughly it would be ~10% of whole PSX Japan set

Go to forum: General discussion

225 Reply by themabus

(17 replies, posted in General discussion)

edit:
imo current aiming for single serial only confuse people.
.dat is final product of our effort. it's what the rest of the people will see - not online db.
so it's important for this information to be as descriptive as possible. redundancy is unacceptable.
we should squeeze in there as much differences as possible, not similarities. <| that's how databases work - whole concept.
also maybe ther's currently not that much re-releases in db but it will change as db evolves.
i have quite a lot of 'PlayStation the Best' myself yet unverified so it's not like just few exceptions at all.

Go to forum: General discussion