Search options (Page 11 of 16)

thanks, p_star!

it would be too simple...
on those forums ther's at least two people, who knew how this ring is made: Bexster/RPS (i think it's same person) @cdfreaks and HI_Ricky @segaxtreme/assemblergames.
they would have figured it out, i guess.
only way i can now imagine this to pass is if saturn rotates cd at some speed and checks laser wave, e.g. time for how long ther's short/long waves from pit/land blocks assambling logo pattern. but if it does something more - it would not. and i think it does more. pinchy said his cds pass all checks except the last one. and he's very determined it's before ring, maybe it is gap, like you said, after all. like absence of efm in there.
but anyway i won't give up on this until i try 650mb cd with corrected MSF/subchannel, skipped sectors before ring and ring done in several possible ways (scaled/padded etc.)

here i've redone 1st of those programs:
http://www.mediafire.com/?6zwrdyuz9pt
it interleaves/deinterleaves binary data.

i hope to do rest soon.

yeah, that's what we do

maybe it's not there, maybe CAV is used only because it's easier to write logo this way
but many people talked about it being logo.
so i want to be sure if we can not draw it - it's ok, but let's check and see.
in a few days we will know, i think

i recalculated sectors per track, and it looks pretty close to CLV. on Saturn logo takes ~3mm (height)
it's about 2..3 sectors per track difference @CLV from top / bottom of logo. for 1400 tracks it's not that bad, i guess.
i'll make circ encoder and i want to to try to draw some cubes and rays and such on cd firs
if it's possible, maybe logo is too.

edit:
oh, sonic's logo start at the same MSF, where ChuChu Rocket, when leading sectors are removed.
and my rocket dump was desynchronized in middle, so thanks. if i can draw those cubes i'll try dc 1st, because it's closer to centre - can do faster.

thanks!

yes,
when console boots up saturn will drive laser to this area and do few readings and if it's a backup - will fail.
so this final protection, it's very likely to be somewhere there.
i'm now very sure it's actually this logo, like RPS and few other people said (years ago ). because it's in CAV, this area is unlike the rest of cd.
every track consists of the same amount of frames (tracks do not get longer, closer to outer edge)

Console: SS
Tracks=~1460
FPT=2058 (2058/98=21 sec.) <|Frames Per Track

Console: DC
Tracks=~1226
FPT=1078 (1078/98=11 sec.)

so on backup this logo will never show up. it washes along the tracks and becomes garbage.
so i guess it doesn't matter how you pad it - to get logo, whole data would have to be recreated anyway, based on cd geometry.
would that work? - i don't know, it's unlikely, original is very precise (as can be seen in microscope,
i don't belive anyone could do that without proper hardaware)
maybe offset affects this whole process as well - i'm not sure. if it does, ther's 6 possible ways to pass data to circ
(one is correct, on four other ring will shuffle, like in those images i posted earlier).
and probably contrast on recorded media is too low to see anythig, anyway.
and maybe protection is something else after all...

also what's strange, sector count per track seems very low, compared to what i estimated from empty area. but maybe i made a mistake there.

i only had one DC ring, from European ChuChu Rocket. and it looks to be 1sample off. so you must remove 4bytes from the start of data
to get correct logo. but likely it's also my fault could be a bad dump.

Vigi, could you, please, check your DC rings?

i've uploaded the program here that will do circ delay lines and output ring to ASCII.
http://www.mediafire.com/?4hm1xyvojy2

syntax is:
ring2ascii.bat s 2058 10 RING_data.raw >SSRing
ring2ascii.bat s 1078 10 RING_data.raw >DCRing

i'll try to write something to reconfigure this data depending on cd in next few days,
maybe something shows up, some blured franken-image...

also, maybe new burners could write this logo easy, if you could specify CAV mode and speed,
i think, that's pretty much all there is.

i call that logo zone 'ring'
i mean when you check that zone for offset, like you do on data tracks, this offset, it sometimes differ from the rest of cd.
like in your Mortal Kombat. it's +222 for data - ok, but i think it should be higher, for ring, because that sector, you uploaded,
it's MSF:66:11:19 (297694), so difference with requested sector 66:11:25 (297700) is 6 sectors and 180 samples
(those preceding 1st sector with header in your dump), but maybe i'm wrong here

about data in this area, i don't think there is any. on microscope photo it's empty, so there cant be full (round) 'track'.
i've found boundaries of this transition zone between data->logo with Truman's 'cdreader' on the same cd, i did microscope readings.
it's exactly 1350 wide. from photos i'd guess it's about 31~32 tracks in there, so 1350/31=~43 sectors per track.
so there is no 43 continuous sectors in there.
when i looked for zone boundaries earlier today, it's quite hard to get there. if you go from e.g. 300000 to 320000
and data ends @328000, laser can often skip past data and will loose track. and it's thousands of sectors.
so i don't think laser would be able to find anything there. though maybe there could be some pattern, that's not read as data at all.
so that would mean Saturn is way different, but on PC i think it's impossible to verify. i think Cdrwin did reading for very long, until
it get past this area, but i would not trust, if it returns anything. probably junk.
it would show on microscope tho

also i've run logo sectors data through circ delay lines simulation, and looked for a best contrast by statistics.
(and it's a bit strange actually, it wasn't per sample unit)
i did this before, but now i realigned data in tracks, looking for patterns.
and this is what i got:




it's first and last characters of each sentance, later those patterns run onto eachother and become unreadable.
i guess - maybe my circ is wrong. or could be holographic image is made this way? - i would not know.

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.

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.

ok
i've rereaded all discussion yesterday, and i think pinchy said something about subcode acting strange
tho maybe it was somewhere in wip posts and later he could have changed his mind

what i wanted to post on cdfreaks, i got some images from microscope on wednesday
but i'll post them tomorrow, i'm falling apart now

oh those unreadable sectors are ok, it's an empty space.
it's possible to wait for very long until reader skips this zone, or just try to hit ring entering range.

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

i agree with Vigi on serials. but still i'd keep version for every different image, because it shows development hierarchy. it cold be like 1.xx 2.xx for different releases, maybe: major version for when next release has different image and minor for fixes within release, but it isn't so important. i just believe versions are good thing to have. for instance you could tell from name weither it's initial release or latest there is.

could have been me, who said that
thing was that Alcohol did not burn our cue sheets correctly. i then posted this later on Alcohol forum and it turned out - it does not burn any cues correctly ...for like years. but mounts perfect, never had problems with mounting. so it's like strange.
IsoBuster does not burn anything.
CloneCD does not burn cue sheets at all.
EAC does not burn data tracks.
Cdrwin tested (not a lot though, but it's native format...) and burn correct.
so if ther's other software, that supports cue sheets at all, it's quite possible it will work.
joining image togeather again from separate tracks would have to work if software would not support this specific gap placement.
cue sheet with absolute time referencing LBA 0, in such case is necessary, e.g.:
Wakusei Woodstock: Funky Horror Band
FILE "G-6001.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 00 05:28:73
    INDEX 01 05:30:73
  TRACK 03 AUDIO
    INDEX 00 08:22:03
    INDEX 01 08:24:02
  TRACK 04 AUDIO
    INDEX 00 11:14:39
    INDEX 01 11:16:38
  TRACK 05 AUDIO
    INDEX 00 14:26:15
    INDEX 01 14:28:14

would be great, i'd be happy to add them too. they're seldom and perhaps obscure.
tho it's impossible to determine offset directly without data track maybe sometimes there would be similarities to game cd or data would exceed gaps for certain amount of samples.
but we could indeed dump most cds compensating drive offset, like you did.
and for cds that would not fit into this frame we could dump from first meaningful sample or until the last one (shifting frame to cover all data).
and 'offset' field would represent any changes: 0 - drive offset cancellation; -x,+x - shift, so people could verify these cds just like everything else.