NEW DUMP INFO AT THE BOTTOM
1 2009-04-15 11:17:56 (edited by pnz 2009-04-22 08:39:09)
Track sizes:
Track 01: 23853936
Track 02: 323853936
those sizes are incorrect
for Track 01 it should be (137842-0+1-150)*2352 = 323853936
so in this log it's right:
File: Track 01.bin
Size (bytes): 323853936
From image: 356175120
Size (sectors): 137693
From image: 151435
maybe you mixed order?
for Track 02 it's still different though: (151434-137843+1+150)*2352 = 32321184
sum of all track sizes should be identical to (last sector from TOC + 1) * 2352
323853936 + 32321184 = (151434 +1) * 2352 = 356175120
checksums for Track 02 are wrong since EAC didn't pick up gap but CRC32 is same as in EAC log
i'm not sure about Track 01, whether it's right
so in this case you should extract tracks as usual with IsoBuster/EAC
remove 150 sectors from the end of Track 01, like always
and then also add 150 empty sectors to the beginning of Track 02 - manually this time
like described here, in point '1)'
http://forum.redump.org/post/16045/#p16045
in your case it's 352800 bytes
also offset look strange
from log it's either 6 or 3 - that's weird
does this program work for you?
http://forum.redump.org/viewtopic.php?id=2468
I screwed up and reported the wrong file sizes:
Track 01: 323,856,936
Track 02: 31.968,384
Total: 355825320
That's off, I had already removed 2 secs from Track 01. Now I added 2 seconds to track 2.
New file size: 32,321, 184
323856936+32321184=356178120
Which is correct matching the reported total from psxt001z.
New CRC's for Track 02:
SHA-160 : 8DC237D0A5D710A9D58CCE5E88624629F5BCC273
MD5 : 862043C0D18ED873F9DDE8E1EB4AA491
CRC-32 : 710F9F17
But the sector view is showing 14 lines of data. 14x16=224. 224/4=56. My drives offset is +48 normally. 56-48=8. What should I do. Also, I tried that program and it gave me this error.
px_d8.exe D: 0
Returned SCSI status code: 02 - Check condition
Sense data, key:ASC:ASCQ: 05:20:00
Failure reading drive D.
5 2009-04-15 21:51:18 (edited by huygens 2009-04-16 20:52:10)
FIrst off thanks for the dumps!
As far as I know that program only works for Plextor drives. Just to make sure what sector is shown in the post? It should be 150 sectors back from the first sector of track 2.
As to your drive, I would recommend investing in a drive that supports overeading. most discs will dump fine without this feature, but some will cut off the end of the last track on multi-track games. This page has a searchable database of drives and features http://www.daefeatures.co.uk/
Also your drive has an offset of +48 so it won't be able to correctly dump multi-track discs with -647 offsets. (data will be cut off the beginning of the audio tracks). I'm using a Plextor UltraPlex 40max (PX-40TS) drive. It over-reads, and has a large positive offset. You can find them on ebay, the only drawback is you need a scsi card to use it.
But the sector view is showing 14 lines of data. 14x16=224. 224/4=56. My drives offset is +48 normally. 56-48=8. What should I do. Also, I tried that program and it gave me this error.
px_d8.exe D: 0
Returned SCSI status code: 02 - Check condition
Sense data, key:ASC:ASCQ: 05:20:00
Failure reading drive D.
Also your drive has an offset of +48 so it won't be able to correctly dump multi-track discs with -647 offsets. (data will be cut off the beginning of the audio tracks).
Only the first audio track will miss some data and the pregap (since EAC thinks the gap belongs to the data track and is not extracting it). All other audio tracks will have the correct data.
To fix the first audio track, you would need to manually extract the last 1 or 2 sectors from the pregap of track02 using Isobuster, and then adding the amount of samples to the beginning of track 02 (in reality it is far easier to do than to explain it here, sorry ^^;;).
Anyway, either a plextor or a big offset drive are needed to detect the offset correctly. Plextors and px_d8 1.01A are the best way to detect combined offset correctly... no counting of bytes and lines, it plainly displays the combined offset value ^-^
But the sector view is showing 14 lines of data
it's samples that matter, ther's 13.5 full lines and ther's 4 samples in each full line
so that's 13.5*4 = 54; 54 - 48 = 6
but the thing is - last 3 samples are sync, which is strange, normally this data would end right before it
(only data sectors have sync and scrambled data you'd examine should be from the last data sectror,
so what is this sysnc from?)
I think I'll start worrying about games with audio after I buy a new drive, which is the best Plextor to get?
9 2009-04-16 14:08:35 (edited by Sotho Tal Ker 2009-04-16 14:09:14)
any _real_ plextor ![]()
The best one is probably the px-760a
Px-755a works too, and the px-716a which i own ^-^
I'd recomend one of these Plextors or a Yamaha.
PX-40 CD-Rom
PX-32 CD-Rom
PX-8XCS CD-Rom
PX-W124TS CD-RW
They all read into the lead-out and have large positive offsets.
Pros: you can use the offset detection program.
Cons: price (sometimes), need scsi card, may need another drive to read subcode (CD-Rom models can't check libcrypt status)
Alternatively yamaha drives are well respected. all these overread and have a +733 read offset. They're also ide drives.
Pros: IDE interface, newer, easy libcryt checking
Cons: Manual offset detection, no C2 error detection (slows down dumping as EAC has to double-check data)
CRW2200E CD-RW
CRW3200E CD-RW
There's a CRW3200 on ebay at the moment (not mine).
11 2009-04-22 08:34:24 (edited by pnz 2009-04-22 08:40:36)
Alright, so I redumped this thing with the correct offset (+6), took 2 secs off track 1, padded track 02 with 2 seconds (since its a 2 track disc) dumped twice.
-Name: Runabout 2
-Region: NTSC-U
-ID/Serial: SLUS-01135
-Edition: Original
-EXE Date: 2000-04-16 [YYYY-MM-DD]
-Language(s): English
-Anti-modchip: No
-Libcrypt: No
-EDC: YES
-Size: 356175120
-Sectors: 151435
-Number of Tracks: 2
-Factory Offset: +6Checksums:
TRACK 1:
Filesize : 323.853.936
SHA-160 : 87810C02B76E4403A81C36131F9CCB1C56B96B7F
MD5 : F0ECDE1345D628092E22347D370AFA80
CRC-32 : CD70112BTRACK 2:
Filesize : 32.321.184
SHA-160 : 652D1773DD5B2A446D6EACD7627288FD1742C00B
MD5 : 4BA8CC79EA7487E3BE1327E149F9A0BC
CRC-32 : 238BBCF1Resize:
C:\DOCUME~1\Jack\Desktop\R2>resize.com -r -352800 "Track 01.bin"
Resizing TRACK0~1.BIN...doneSectors.log:
Original sectors: 64
LC1 sectors: 0
LC2 sectors: 0
Other sectors: 0Adding padding to Track 02:
C:\DOCUME~1\Jack\Desktop\R2>psxt001z.exe --gen pregap.bin 352800
psxt001z by Dremora, v0.21 beta 1File "pregap.bin" with size 352800 bytes was successfully generated!
C:\DOCUME~1\Jack\Desktop\R2>copy /b pregap.bin+"02 - Track02.bin" new_track02.bin
pregap.bin
02 - Track02.bin
1 file(s) copied.SECTOR VIEW:
LBA :1376930000 : C9 9A D6 EB 1E CF 48 54 36 BF 56 F0 3E C4 10 53 ......HT6.V.>..S
0010 : 4C 3D F5 D1 87 1C 62 89 E9 A6 CE FA D4 43 1F 71 L=....b......C.q
0020 : C8 24 56 9B 7E EB 60 4F 68 34 2E 97 5C 6E B9 EC .$V.~.`Oh4..\n..
0030 : 72 CD E5 95 8B 2F 27 5C 1A B9 CB 32 D7 55 9E BF r..../'\...2.U..
0040 : 28 70 1E A4 08 7B 46 A3 72 F9 E5 82 CB 21 97 58 (p...{F.r....!.X
0050 : 6E BA AC 73 3D E5 D1 8B 1C 67 49 EA B6 CF 36 D4 n..s=....gI...6.
0060 : 16 DF 4E D8 34 5A 97 7B 2E A3 5C 79 F9 E2 C2 C9 ..N.4Z.{..\y....
0070 : 91 96 EC 6E CD EC 55 8D FF 25 80 1B 20 0B 58 07 ...n..U..%.. .X.
0080 : 7A 82 A3 21 B9 D8 72 DA A5 9B 3B 2B 53 5F 7D F8 z..!..r...;+S_}.
0090 : 21 82 98 61 AA A8 7F 3E A0 10 78 0C 22 85 D9 A3 !..a...>..x."...
00A0 : 1A F9 CB 02 D7 41 9E B0 68 74 2E A7 5C 7A B9 E3 .....A..ht..\z..
00B0 : 32 C9 D5 96 DF 2E D8 1C 5A 89 FB 26 C3 5A D1 FB 2.......Z..&.Z..
00C0 : 1C 43 49 F1 F6 C4 46 D3 72 DD E5 99 00 FF FF FF .CI...F.r.......
00D0 : FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 ................
00E0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................EAC Log:
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008EAC extraction logfile from 22. April 2009, 2:31
Unknown Artist / Unknown Title
Used drive : Optiarc DVD RW AD-7170A Adapter: 0 ID: 0
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : NoRead offset correction : 54
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 : Not detected, thus appended to previous trackUsed output format : Microsoft PCM Converter
Sample format : 44.100 kHz, 16 Bit, StereoTOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 30:37.68 | 0 | 137842
2 | 30:37.68 | 3:01.17 | 137843 | 151434Track 2
Filename C:\Documents and Settings\Jack\Desktop\R2\02 - Track02.bin
Peak level 100.0 %
Track quality 100.0 %
Test CRC AE678447
Copy CRC AE678447
Copy OKNo errors occurred
End of status report
Psxt001z:
psxt001z.exe --fix "Track 01.bin"psxt001z by Dremora, v0.21 beta 1
File: Track 01.bin
Size (bytes): 323853936
From image: 356175120
Size (sectors): 137693
From image: 151435
Mode: 2
EDC in Form 2 sectors: YES
System area: US EDC
Postgap type: Form 1, zero subheader, zero data
but afaik offset +6 is uncommon for PSX
it would be really great if you could verify it by other means:
d8 or with swapping
but afaik offset +6 is uncommon for PSX
it would be really great if you could verify it by other means:
d8 or with swapping
d8 doesn't work on my drives. what is swapping?
like you would dump Dreamcast's GDs:
put in audio CD (you don't need 'trap disc', any audio will do),
remove cover, replace it with this CD, put cover back
and then, by looking at LBA 0 or close to it with IsoBuster
you should be able to tell offset from position of sector header