Search options (Page 16 of 16)

thank you! i'm glad you gave this link. i remember that site and program from several years back, when there was a discussion on cdfreaks about psx cp :) but then i guess in last years i forgot about them. so i've found a description of scrambling pattern. and so for MSF it would mean XOR 018000; 60 for type. and applying this rule on addresses posted aboove they would unmask in the following way:
LBA:0000:018200=>000200
LBA:0750:019200=>001200
LBA:1500:01A200=>002200
LBA:3600:01D000=>005000
LBA:4349:01D974=>005974
LBA:4350:008000=>010000
is this correct?

-----------------------------------
ok, thank you very much!

it also would stuck in an infinite loop before ID field, when executed on Japanese Ace Combat [SLPS-00061] data track without parameters. label is ACECOMBAT exe is PSX.EXE dated 1995-05-17
also crash on Beyond The Beyond [SCPS-10014] when looking up ID
crash on Wild Arms [SCPS-91306], where exe is in subdirectory "exe":
BOOT = cdrom:\EXE\SCPS_100.28

mmm... i guess then ther's more to that. i've checked what's missing at the end on both drives that don't overread into lo and:

      SAMPLES CUT
 -----------------------
|dirve|  disc offset    |
|off  |+0032|+0970|+1803|
|set  +-----+-----+-----|
|-0024|08240|10942|10011|
|+1828|08328|11030|10099|
|-----+-----+-----+-----|
|diff.|00088|00088|00088|
 -----------------------

the difference of missing samples is 88, not that amount of drive offset diff. or 0. so i guess how far they go into lead out is also somewhat drive dependant. maybe your drive can see +32 cd perfectly but can not large offset? or maybe it can see even large offset, but in that case why EAC would not report it as overread capable? strange. but what's really strange: ~2k cd miss less samples than 1k!? *edit* ah, i guess it's maybe  a postgap, could be it differs in size on that middle cd.

in EAC, under Drive Options menu click 'Detect read sample offset correction'. and also when you read last autdio track with somewhat large positive offset, EAC will give error at the very end if drive does not overread in lead-out area.

no, i'm not oposing what Vigi said. if he says Sony 100E or 120E are good, they must be just that i thought the same. i thought i won't be able to read much audio cds with +6 offset drive because only cd that were in db and that i had was -617 and i could not read it. and i got myself Asus CD-S500/A (+1858). very cheap from ebay. and with that i could dump that European demo disc with -617 offset. but after that all cds i read were +32 or even larger positive offset. and thing is with positive offset that last audio track gets bytes pushed out to lead out. and judging from gigadeath's, p_star's and batleth92 Sega dumps that's far more often than negative offset. so just don't worry, it's lucky you have a Plextor , don't throw it away just yet. but maybe since i guess you have European region cds, maybe they do have negative offset. to recommend anything - i don't have that experience. there was thread like this, where admins commented:
http://forum.redump.org/viewtopic.php?id=641

i can only add to that brief summary about my drives:

Asus CD-S500/A (+1858 ;-30=1828)
+read negative offset audio
+very fast audio extract
-doesn't overread in leadout
-is rom not rw and can't read subchannel
-screws up data tracks so good for audio only

Plextor CD-R PREMIUM (+30 ;-30=0)
+overread lead-out
+somewhat fast audio extract
+read subchannel
-can't see far in pregap

Lite-On DVDRW LH-18A1H HL07 (+6; -30=-24)
+read subchannel
-can't see far in pregap at all
-can't see in lead-out
~most slow read but most precise

no, no after that. after i substract.
but i've found out it's my mistake. i went to check one sector back from first pregap to see if it's data track (wasn't sure about 2sec)
and if i do that, turns out isobuster does not get offset correct afterwards.
it's 1803 after all.
i'll post crcs tomorrow.

hello, gigadeath! i hope to get some of games you listed somewhere next week.

it's hard to tell, it would be easier by hex values but it looks like an empty sector.
00 FF FF FF FF FF FF FF FF FF FF 00 ?? ?? ?? ??
first 12 bytes is sync - afaik it's always the same
next 3 is MSF (sector address)
Minutes
Seconds (0..59)
Frames (0..74)
MSF is in BCD format - if you're 24:56:74 in cd you will see exact values in hex editor (not 18 38 4A)
last byte is Mode. it should be 00 in this case.
(you can find this information in ECMA-130 btw)
and good guess is: last sector from that broken image you have is also filled with 00, so you just append it once
more to have a correct image size and then adjust MSF field with an hex editor (eg. 24 56 74 -> 24 57 00)

hi, Patzik, to be hones i don't know really, maybe ther's some software that rips so, so that they would differ always in a similar pattern like last data track sector missing, but you could try to scan it with dremora's tool or maybe cdmage. if ther's a sector missing - it will show - you'll get a continuous cascade of errors afterwards. and anyhow, you can ask for a patch in the Patches section. try to fix some and you will notice what differs.