Search options (Page 3 of 16)

i guess CD have some scraches or fingerprints on it.
you could try to clean it and set lower reading speed, before dumping with IsoBuster.

does data track have EDC for Form2 sectors?
if it does, you could run it through CDMage and likely 'Light Scribe' image will report some errors.
repairing those probably will make it match to the other images.

yes, you're right Specialt1212,
you shouldn't use --fix on those tracks and offset is indeed not needed in this case.

it would be little more difficult, would there be gap between those tracks.
then you'd have to determine it's size from subcode and transfer it manually.
but afaik USA release hasn't got one.

yes, it could be that EAC doesn't overread with drive that is fully capable to do this
for instance it won't with Mediatek based Lite-Ons that i tried
you could extract sector range then with IsoBuster (include few sectors after LO)
and after correcting offset this file should match to one extracted with EAC but have more meaningful data
i.e. where ther's 0x00s at the end of EAC file, there still be some data in this one
like in image you provided

on 2nd image it is data from the end of sector 130443
so that would mean 0 offset and 3.0 s gap after all i guess

which are problematic tracks?
briefly checking 1st file it looks like data->audio gap = 2s; audio->audio gaps = 1.74s
which is not uncommon pattern
btw for some reason RAR complains about unexpected end of archive for those attachments

hi TAurus

basically you would have to read ECMA-130 (chapters: 20, 21, 22) and examine .sub with Subcode Analyzer
here's a brief example with Mode 2 section (most often cause) affecting EAC's gap size detection

hi marzsyndrome

remove can do this
syntax is a bit wacky though:
remove --size=150sec --direction=left "Track 02.gap" "Track 02.bin"

where 'left' says data will be moved from 2nd file to 1st
and so 1st doesn't have to exist, you can name it whatever you like
if name of existing file is given, data will be appended to it

and '150sec' is size in sectors
alternatively it can also be specified in samples or bytes or as hex value too

since CD-ROM decoding is skipped, all of those methods would give scrambled output
so data track should be passed through descrambler manually afterwards
http://www.mediafire.com/?q1mbksntoje
in this pack you will find 'remove' & 'unscramble' programs
so after you have output from cdtoimg
assuming CD offset is +2 and Plextor's +30, resulting in +32 or 0x80
and 'rawdata' was the name of cdtoimg output file
you could try following:
remove -size=$80 -direction=left trash rawdata
unscramble rawdata

resulting file 'rawdata.scr' will have 128 bytes missing from the end
(corresponging to offset)
but should match to image extracted with other drives up to that point, so
fc /b rawdata.scr "Track 01.bin" |more
should result in:

it's a strange coincidence with motherboards and i would use IDE2USB converter too
but i've just tried it on older Gigabyte GA-8I915ME with almost clean XP SP3 (through USB)
and AFAIR this problem initially occured when drive was connected to internal IDE controller
yet symptoms remain - must be Plextor's firmware after all
but still it would be really great if you could check this CD on a different system - to be absolutely certain

yea, i just changed parser string in original plug-in
http://www.mediafire.com/?ym2acwgr3dn
place it in nullDC 'plugins' directory and it should show up with [quotes hack] tag
for GDIs without quotes you should switch back to unmoded plugin

yes, CD = factory offset

it doesn't have to be @0, mostly it won't be
there is this freedom left in definition of CD medium
i wouldn't reallly know why
i guess maybe data synchronization, when mastering, the way they did it
was rather complicated process back then
so this would allow to overcome certain technological difficultties

generally CDs for older systems, like SCD, will have those offsets more random at wider range
most extreme values currently in DB must be around several thousands

ok, 0.5.2:
- Corrected handling of standard DVDs
  (type should be forced to 3, when dumping or unscrambling).
- Better response to 'speed' parameter.
- Uniform raw output for all devices: unscrambled data + headers.
- Slight performance increase (~1650 MB/h on LH-18A1H).
- Added LH-18A1P, LH-20A1H, LH-20A1P to list of supported devices.

so raw output now also depends on disc type, i.e. --type (-T) parameter
default is Nintendo layout, but for regular DVDs always should be forced to 3

and i couldn't actually test dual-layer DVDs, because of lack of free space

yes

readbuf_tool reads data in 64kb chunks, if it's more than that, it would loop until criteria is met
friidump does the same, actually about everything i know does
(e.g. CD tools would usually read 26 sectors at a time which is 26*2448=63648 )
as this is the size that all devices should support, larger than that does not have to work and often it doesn't
drive is not only thing responsible for this limit, ther's also controller, drivers and such
for example my IDE controller is weird - picky on data alignment
and older PC i have in other room wouldn't read buffer at all from this very same LH-18A1H

DVD drives would return either 2064 or 2384 byte RAW sectors
sectors are grouped in blocks by 16
all this is taken into account when doing reads with those methods, so that's why i said it's non linear
100 sectors, it's more than 5 blocks, that best Hitachi method has
friidump's author had ~1250 MB/h with it and some guys would get as much as 2500 MB/h
Lite-On would do about ~1100 on 27 sector requests (27*2384=64368 - about full page); ~2000 on PC DVDs
so further it wouldn't matter really, it would mean drive has to fill this amount of cache inbetween reads,
while calculations are done - it's very unrealistic

dumping fails because there are numerous checks done on data sequence and integrity
therer's likely incorrect content returned from cache, e.g. garbage or sectors from previous reads

yeah, we have to disable those error corrections
i'll send you a program later tonight to try some things out, ok?