Search options (Page 10 of 16)

i'll add, that you can see full final sizel here:
From image: 583331280
so 583331280-538655040=44676240 <| audio tracks should total to this. since ther's only one this is the size it should be.
it's great to verify yourself

new version:
http://www.mediafire.com/?gnc2zyddi1n
everything's better now

gap size can be redefined by 3rd parameter in form 'xx-yy'
default is set to 150-150
'225-150' means 3 seconds for data, 2 for audio
'0-0' cuts by TOC - no gaps at all
it's a simple parameter - there is no distinction between data following audio or data
and similarly it does not matter what track precedes audio.

ice.exe "E:\!dc\dreamon\CD Segment.bin" 45000 0-0

ice @20090110 / bill.gates@microsoft.com
---------------------------------
E:\!dc\dreamon\CD Segment.bin
---------------------------------
Accessing                       : ok
Seeking valid Mode1 sector      : ok
 Offset                         : $0000004C
 Scrambled                      : TRUE
 LBA                            : 45000
Seeking LBA 45000               : ok
 Combined offset (samples)      : 19
Parsing IP.BIN                  : ok
 Writting 'ip.txt'              : ok
Parsing TOC                     : ok
 TOC entries                    : 9
 Writting 'redump.cue'          : ok
---------------------------------
03  Data    45000   59896   14897 ok (150)
04  Audio   59897   63612    3716 ok
05  Audio   63613   68847    5235 ok
06  Audio   68848   76246    7399 ok
07  Audio   76247   90700   14454 ok (150)
08  Data    90701  549149  458449 ok
---------------------------------
done

in brackets after 'ok' is amount of foreign sectors - ones that don't pass ecc for data,
and those that do for audio. its for self control - to see if gaps were predicted correct
also if there are ecc errors in data track program will not abort now but add those here

.dll is still required, it would take me longer than a day to rewrite that.
edit: ImgBurn use ElbyCDIO... i guess it's ok.

about those gaps i promised to test today, i'm sorry - i couldn't.
i haven't used xcdtool since autumn when i switched pc and it turns out it does not work now
errors i get are: Win32 DeviceIOCTL with SCSI_PASS_THROUGH command failed. (SPT)
and: Invalid Host Adapter ID:0 (ASPI)
strange, though all rest cd programs work fine

edit:
i've tested some applications to see what differences would 2 <-> 3 second audio->data gap change yield
on recorded media or virtual drive and it does not really seem to matter from this point of view.
though the way i tested was kind of indirect since currently only Lite-On works on this system
and it can not fully read sectors when this area is 3 seconds large (like on PCE - i tested with PCE CD).
it would return sense 05/64/00 - ILLEGAL MODE FOR THIS TRACK on Mode1 part of gap (150 sectors)
so this is what i was looking for.

Record:

Alcohol 1.9.8 (7117)
Messes up TOC

AV Burning Studio v1.1.0
Does not support cue

BlindWrite 6.2.0.3
in both cases return sense 05/64/00 on 150 data sectors, like original
2 second gaps - 75 audio sectors are left intact
3 second gaps - replaces 75 audio silence sectors with empty Mode1 sectors

CDBurnerXP 4.2.3.1110
Does not support cue

CDRWIN 4.0G
2 second gaps - return no errors and gap size now is different from original
3 second gaps - return sense 05/64/00 on those 150 sectors, like original

CloneCD 5.3.1.3
Does not support cue

DeepBurner Pro 1.9.0.228
Does not support cue

DiscJuggler V6.00.1400
Does not support cue

ImgBurn 2.4.2.0
2 second gaps - return no errors and gap size now is different from original
3 second gaps - replaces 75 audio silence sectors with empty Mode1 sectors, does not return errors tho

InfraRecorder 0.46.2.0 (cdrtools/cdrkit 2.01.01)
Unsupported sector size 2352...

MagicISO 5.5 (0273)
Does not support cue

PowerISO 4.3
Does not support cue

UltraISO 9.3.2.2656
Does not support cue

Mount:

Alcohol 1.9.8 (7117)
2 second gaps - TOC is fine, return no errors, didn't check subcode
3 second gaps - return sense 03/02/00 - NO SEEK COMPLETE on 75 audio silence sectors forming gap

DaemonTools Lite 4.30.3
2 second gaps - TOC is fine, return no errors, didn't check subcode
3 second gaps - return sense 03/02/00 - NO SEEK COMPLETE on 75 audio silence sectors forming gap

so it's about the same. closest to original PCE probably are BlindWrite 6.2.0.3 with 2sec (weird..) or CDRWIN with 3sec
but i don't think those differences matter at all.

conspiracy

ok, i'm done (or so i think )
http://www.mediafire.com/?mznzwfynnun
(also you'll need ElbyECC.dll
it comes with CloneCD or just can be downloaded somewhere
mine is v4.0.0.0; crc32: 0d00ed6a)

it is small and simple
i've left those two TOC fields out for now and some other things too
so it could be fairly easy to confuse
in such case, when something strange occurs, it should bail out then
this will probably happen a lot, since i could not really test it myself.
so i don't think it will screw up anything, it should just stop.

syntax is 'ice.exe FileName StartLBAUsedToDumpData'

all gaps are assumed 2sec, so it's better to verify them manually at the start & end of each file.
also i'm not sure if shown offset is correct, i've forgotten quite a lot about those things.
and it could be, that last sector of last data track is missing.
so it would be better to try it out on some known gd-s at first.

and please let me know what could be just different.

edit:
from only gd-rom i could test it looks like gap preceding last data track is 3sec long:
75audio/150data, a lot like PCE (from sector content - i haven't checked subcode)
in database currently ther's either 2 or 0 sec gaps at this position.
this program will go for 2 and will freak out if ther's less than 150 data sectors there.

edit:
those two fields hold first/last track no., alike to real TOC.
what's strange: i've dumped my GD completely
and program seems to work fine - cutting everything as intended.
so total size of tracks should always stay constant: 1,185,760,800
since first/last LBA appears to be fixed: 45000; 549149
but in db every game has different size, hmm

hi, Jackal.

yes, basically the same, except it's not automated in any way. 
i used it to experiment with that scrambled data inbetween tracks.

thanks, i'll try to.

EAC won't overread with some drives.
i don't quite remember, but i think it was so that even more data could end up being replaced with 0x00 in those cases.
IIRC, when OR. is enabled on such drive, it was as if EAC would ignore offset, and cut there.
you might try to go at the very end of last track with IsoBuster or such program, that allow sector view, and see if it returns more data than EAC does.

ok, thanks

ther's an easy way to tell CAV/CLV data aligment apart by measuring time it takes for optics to position from one sector to another.
i guess this is about what Alcohol does with DPM on. maybe it could be used to get characteristics of spiral from CD-Rs
but probably it's too rough. i haven't got much time to test it myself and i'll be away for about 2 weeks, so i've included sources too:
http://www.mediafire.com/?0joblmsqvl1

for example Dreamcast GD-ROM: (didn't know much about it but being described as CAV on wiki, i thought it's curious)

1st area - regular CLV

linear decrease in delay is clearly visible here (jump @7000, it's drive dropping speed)
this happens, because same amount of sectors in CLV take more revolutions at the center and less towards the outside of CD,
so less mechanical movement is involved to skip same distance (measured in sectors) as radius increases.

2nd area - logo

for CAV it's constant.

3rd area - high density

here change of delay is a lot less obvious than in 1st area, but still present.

it's possible to keep one of sectors fixed instead of distance, so now revolutions become visible:
@the beginning of  3rd area

towards the end

from last two images it's apparent, that sectors per track in this area aren't nowhere close to being constant.
so even though pitch or T is modified, essentially it's CLV.

edit:
fixed download link

hello, RPS! i'm very glad you're here
actually every tidbit of information would be welcome

but so, to be more specific:
basically as i understand this ring with copyright/logo essentially is an area recorded in CAV.
so, how i see it, on ordinary CLV CD pit/land length (T) would stay fixed (with insignificant deviations)
and hence every revolution, from center to outside, would increase in data capacity (by ~35 channel bits).
in CAV on the other hand T is variable that changes so all revolutions hold same amount of data
and pit/land length increases in direction from center to outside.
is this what you meant when you referred to an area with no EFM?
or was it perhaps this transition area (empty zone on microscope image) from ordinary data to ring?
this is what i'm most puzzled about.
also from my understanding, to simulate this CAV layout one would need to keep spindle motor @fixed RPM
(or RPS i can't stop to think your nick actually being a tongue in cheek like humor, excue me if i'm wrong)
maybe you have performed such experiments before?
i'm currently reading book on cd circuits but it's probably years until i get there.
so the plan is to hack drive and get this ring on CD-R in CAV. and in case of positive result proceed further
from there. this ability to recreate ring at will would allow necessary flexibility for experimentation
and improving method and making it more user friendly and possibly simplify it to level
where drive hacking would not be required at all.
other possible outcome - ring recreated in CAV would not work. then i guess nothing would.
but we would have done all we could, at least.

as i understand you have a lot of experience with hardware hacking, maybe you are interested in this yourself?
but if not, could you, please, point in direction, where to look to get it done eg. from firmware, circuit?...

my pc died today...
it was having problems for about last half month.
would not start often and when it did, was going on defaults only - cmos would hang on save.
the week i didn't wrote 15..24 i was replacing cpu, i thought it was l2 cache, but it didn't help.
so finaly today it's stone cold. even bios doesn't beep.
and i can't afford repair or a new one now.

so i won't be able to do anything for a while.
i'm sorry i couldn't finish those programs.

i was writing simulation on pc. the ray, when you supply wrong parameters form curve what's essentially archimedean spiral.
so i thought that would be interesting to experiment with it on pc screen, rather than reburn cds all the time.

to form a ray - it's not hard. all you need is to take start / end radius, track pitch and channel bit size as variables
(width of ray optionally - it's better to start with at least one sector wide and decrease it gradually, as it gets straighter)
and calc rings with incremental circumference from 2*Pi*r. that's what i did, but maybe ther's a better way.

when parameters of given cd are determined you can draw whatever you like in this model, (or realign data / pad / add headers...)
and then run it through deinterleave routine to form an image,
thogh it will always be distorted by some amount, i guess, because it's an approximation after all
and because of the nature how cds work.

i never tested those images on saturn, myself... i sincerely hope somebody will.