Sega Saturn cp talk (Page 1 of 3)

I do? no, I don't

Are they similar to PSX?

themabus, what do you make of this? - http://forum.redump.org/viewtopic.php?id=3349
xenogears' dumps in the last post should be identical to the other 2, right? or can it be a mastering difference again

ok, i'm posting here, thanks
Vigi, i think one cd could be the same, other probably isn't
i've posted details in that other topic

sector range, it's a bit different for every game i tried (not many about 5)
i only have Japanese cds
but i think the sectors you'd get will be always the same.
we could compare crc afterwards.
i dumped with CD Tool, because it does dump subcode
and subcode on ring  so far was always with same offset as on data track.
so it's interesting imo, because it means each ring is different on pit level
and they were most likely generated at the same time when data tracks,
on the same machine (not pre-pressed).

T-15025G
Readable (uncorrected sectors):
Data: 000000..297034 Subcode: 00 02 00..66 02 34
Ring: 298990..330743 Subcode: 66 28 40..73 31 68

T-1505G
Readable (uncorrected sectors):
Data: 000000..297000 Subcode: 00 02 00..66 02 00
Ring: 298583..328251 Subcode: 66 23 08..72 58 51

T-20301G
Readable (uncorrected sectors):
Data: 000000..296994 Subcode: 00 02 00..66 01 69
Ring: 298759..330743 Subcode: 66 25 34..73 31 68

I managed to rip the main channel data, from sector 297704, 30199 sectors long, but the subchannels are giving me problems.. I want to be sure that they don't contain any protection bits, but I can't get them cleaned 100% with cdgtool..  there are always some differences left in the crc bytes.. I already tried 100b and 001b, compared them, etc, but think we'll need a tool that rereads every sector a couple times, like psxt001z --libcryptdrv does...

Have you examined your subs for any possible protection data?

ok.. I suppose 100b is always better than 001b and no real data is lost (only random errors).. so I'll do several 100b sub dumps, and clean those as much as possible

Here are the mk2 ring img and sub.. maybe I can still squeeze more sectors out of the cd, but it's gonna be tough...

http://www.speedyshare.com/843465866.html

Here are my first observations:

- Main channel data appears to start @ 297700 (maybe your discs do to if you go back more?)
- I managed to extract 30326 sectors of main channel so far, subchannel a bit less.
- CDReader is good for extracting multiple sectors at once, but it's unable to extract some of the first and some of the last sectors of the area. The D8 command seems more suitable, so maybe Truong can mod cdtoimg so it can extract sector ranges.
- Use px_d8 to read more sectors at the start and at the end (you can append them to the cdreader image using hex editor)
- px_d8 has more trouble reading sectors with subchannels enabled, for example: I can read sector 297700 without subchannels but not with.
- subchannels only contained read errors, no actual protection data (did several 100b extractions at different speeds and it only left me with some random errors at the end).

I'll try installing a different drive tomorrow to get some of the missing subchannels sectors and then construct an image with the unreadable sectors and ring area etc added (hopefully I can make it a burnable image so that someone with a saturn console can try to boot it).

It's possible that the saturns reads this data (at least the main channel), but I don't think it does it right from the first to the last sector, and possibly it only reads the user data.. so as long as the 595959 bytes are present in that range on the CD there's a chance it might work?

ok, about microscope data,
i've gave up on matlab... can't convert them to binary images -
ther's too much noise, or i suck @matlab, so i've cut out fragments and converted them to grayscale
>full images are here<
(they cover much larger scale and are uncompressed, so if you find this interesting,
please download this archive instead.)

so i've asked professor from local university, could i take a look at cd with optical microscope
that they have there (Nikon ECLIPSE L150)
and he said ok, and actually was very kind and did most himself, i only got to click mouse few times

this is how data loolks x800, near the edge of datatrack. (tracks go verticaly at slight angle)

transition area from data to ring x800

background x800

block, that form letter pattern x800 (it's out of focus and looks like toning in plastic, but no - it isn't)

upper right corner of the same block x2000

zoom in x4000

so it certainly does look like the transition area is empty.
background really is $59 (01011001 |EFM> 10000000000100)

1000000000010010010000000000100100
___________---___-----------___---
-----------___---___________---___

11T        3T 3T 11T

if there is 11T-6T-11T in bg pattern - it's much more rare, but i could not find one.
(on these photos, i only was for about an hour at microscope so this is all i got)

logo really is made of $A8 (10101000 |EFM> 01001001001001)

0100100100100100001001001001001000
_---___---___-----___---___---____
-___---___---_____---___---___----
 3T          5T

dsv looks unmanipulated, i think, because on one track same bit can be set with pit->land and
on the other with land->pit change (hece the chessboard look of background).
it's a good thing, i guess.
also i guess this means - every cd would form a bit different drawing - large elements would be the same,
but pit land sequences would be often inverted, because of unique subcode.
on 5th image (pattern x2000), in the upper right corner it does look like T11-T11 sync pattern. so it probably
sync bytes also form radial structures of their own, going across whole ring.
this precision, how one byte ends up atop another on neighboring tracks - this is what's scarry.
i'm not sure how it's happening on cd-r/rw.
it would be interesting to burn ring or just some sequences of $59 and $a8 and take a look on microscope -
how they align, it could be sega's machine manipulated lenght of pits/lands to achive this, but it's a guess.

also, probably it's all meaningless and the last check is not on photos at all. maybe it's something else?
but it's a guess again.
it's, because while taking photos there were actually some spots on plastic, that i thought were a dust but professor,
he was very sure, it isn't. he said it's inside plastic (could be toning). at those places pits looked slightly darker
and out of focuss.
they were round and uniform and about where logo goes (with size of around half of pattern forming block x800),
and i think there was none @segment, without log - wher's just background.
but it's most probably just a fault in production or aging effect. i've found very similar images here: [figure3]
http://www.andraste.org/discfault/discfault.htm
also RPS said something about area with no EFM, and hologram only being used for tracking. and it looks like
he was right about pre-ring, would it be toned plastic - it could probably work, i guess. but to be honest -
i don't quite understand what he said, and am probably missinterpreting.
so anyway, it would be very, very interesting if somebody could examine another cd and confir this true or false.

so if someone can get to microscope at university or lab, please try, ok? it's probably enought with about x600.

Looks like I made an error there? are you sure it starts @ 297694? that would mean that there the ring is 550 sectors long.. could you correct the image that I uploaded plz?

Themabus, here's the first sector after the ring that I'm able to read (plextor reads it @ 297700, and there's no sector offset difference between trap disc > normal disc..) it has some extra bytes before the sync/header so I guess they should be included also?: http://www.speedyshare.com/936172809.html

But you say the MSF indicates that it's sector 297694.. that may be.. but I think this sector really is sector 297700 and it belongs @ offset 700190400?

The reason I 'predicted' the rest of the sector (including the sync/header) before these bytes is that I thought the drive cut off the rest of the sector and the bytes before the sync/header that you see in the file actually belong to a previous sector?

Would be nice if you could upload a fixed image

the thing is, i have saturn only for about half of the year and never tried to rund non Japanese CDs,
but i think you're right. probably it would act different from copy.

Vigi, ok, i'll check you'r sector.
i tried to burn your image yesterday as an audio cd on 650mb rw, so that ther's no need for scrambling.
but nothing is visible, not even change from erroneous zone with $55s to ring. i guess contrast is too low, after all.
edit:
oh, ok i did
yes, those bytes, i think they are from previous sector. it's not different from how rest cd is made and so we get
sector with some offset, instead of requested one. but from your cd it looks different, form data track.
it's 222 in db, but here difference is several sectors, i'll have to check my cd's on this again.
so meanwhile i've uploaded you'r MK2 image (from yesterday) here:
http://www.mediafire.com/?81ynydnbmd1

also from image with data block x2000, i'm now almost sure it's sync up there. i belive, little lower,
it's 4 parity bytes, then 12 bytes forming block, 4 parity again...
but ther's no sync formed arrays on data track, so i guess they've manipulated with speed/pit lenght @ring.
i guess it means trying to get visible logo, it's useless - it's not going to happen.
but i think it should be possible to get ring with software, so we would know at least it's properties
and maybe we could synthesize it later on (if sector content does not matter, maybe it's possible?).
...but i'm not even sure, it's logo, that matters, i think that's what RPS said. and he said it's not possible to reproduce
but it's at least interesting to understand 'how?'.

also i got those saturn CDs and will try to check ranges again on d8.

With offset difference you mean that MK2 has +222 before ring and +150 (180-30) after?

Anyway, I was thinking.. maybe there are actually some readable sectors inside the ring? is there any way we could check this accurately? (ddump resets the drive after every sector read, I'm not sure if this makes any difference or if other tools do this as well?)