• Registered: 2009-10-13
  • Posts: 34

I've recently had contact to DJoneK who asked me to dump Manic Karts CD following the redump.org guide. The Manic Karts CD is obivously badly mastered, the pregap of the first audio track is 02:74* (EAC returns 02:00 which is wrong here), all others are 01:74, most of the audio tracks have noise in the beginning and the last audio track doesn't contain audio data at all, just uniform low-volume noise - so it's a very interesting disc in many aspects.

My drive (LG GSA-H55N, read offset +102) is usually capable of returning those scrambled bytes in the first pregap sector on Mixed-Mode CDs, but it can't read that sector on this disc (unreadable sector). So my problem is that factory write offset determination is simply not possible. Is there any other chance to determine it without having to buy a D8 read command capable drive?

Thanks for any help in advance and I hope to be able to submit results for that disc soon.


* I've determined this pregap using CD Tool made by a CDFreaks member using raw read with subchannel data

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

Please post .sub taken only with cloneCD, it's the only way to verify real pregaps.
If you got errors while checking offset you have to try another drive and if possible (if you have a drive that support read command) use px_d8

My patch requests thread
--------------------------------
  • Registered: 2009-10-13
  • Posts: 34

First of all thanks for your help. I checked the drive built into my notebook and found out that it's capable of reading all sectors in the first audio track's pregap, effectively returning the first sector full with scrambled bytes and the second one scrambled partly only. Determining the correct factory write offset shouldn't be any problem now. I will submit the results in the next days when I have some more spare time, before that I'll cross-check everything again as I didn't use that drive for any dumping purposes before.


Regarding your suggestion of posting a .sub file created by CloneCD I have an interesting story to tell...

In my opinion (feel free to convince me of being wrong if that's the case) CloneCD can't read more information from a CD than CDTool can, it's all about interpreting the results which come from the drive. Manic Karts uses Sony style pregaps which start at (-)XX.XX and end at (-)00.00 in contrast to Philips style pregaps which end at (-)00.01. The first sector returning pregap subchannel data for Track 2 contains 02.73, the last one 00.00, so it's obvious that pregap length is 02.74.

There exist subchannel data read offsets (READ CD on sector X returns subchannel data from sector X+Y, where Y is the offset) and when using my primary drive it has a subchannel read offset of +2 on Mode 1 sectors which turns into +1 when entering Audio sectors, effectively returning the very same subchannel data for two subsequent sectors. The drive in my notebook behaves the same but instead has +1 on Mode 1 and zero on Audio sectors.

The last time I tested CloneCD it was unable to compensate that: The subchannel data which is returned twice was kept in the .sub file and as CloneCD entered the first sector of Track 2 it decided to realign subchannel data, effectively dropping the last pregap sector's subchannel data.

So in effect the .sub file would contain the following relative positions in Q channel for the pregap:
02.73, 02.72, 02.72, 02.71 ... 00.03, 00.02, 00.01

Just for helping remeber, my drive returns this data:
02.73, 02.72, 02.72, 02.71 ... 00.03, 00.02, 00.01, 00.00

The problem here is that there isn't a unique method to both interpret .sub file contents and drive responses correctly. Counting number of sectors which contain pregap subchannel data leads to 03.00 for my drive and 02.74 for .sub file. Measuring the difference between the minimum and maximum relative position in Q channel data leads to 02.74 for my drive and 02.73 for the .sub file.

I've posted some more details on CDFreaks:
http://club.cdfreaks.com/f52/clonecd-en … ds-245875/

Anyway, I hope that I could (at least a little bit) convince you of CDTool used by a discreet person is really sufficient for securely detecting pregap lengths (and style, which is unluckily not preserved in a CUE sheet file btw).
smile

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

Trust me, cloneCD sub is the only sub suitable to get right gaps. Simply post it and me or Fireball will tell you the right pregaps.
We already checked many cdtool subs and they are not suitable for our dumps.
Relative positions in Q channel has nothing to do with gap lenght, the lenght is determined by INDEX00 lenght and nothing else. I read your post on CDFreaks, I found similar kind of subs taken also with cdtool and if you check them better you'll find a missing sector that is exchanged with the double one so the lenght is the same. Normally these are bad taken subs (no right option in CloneCD, you have to read both data and audio subcodes without error correction) or simply best ones when cd has mastering errors.

My patch requests thread
--------------------------------
  • Registered: 2009-10-13
  • Posts: 34

No problem anyhow - may everybody have his own opinion. smile
By the way I didn't use CDTool do create a subchannel data file, instead I used the "View Sector" utility.

I'll create .sub files with CloneCD using all my three drives as it'll generally be interesting what differences CloneCD will produce here. Is it ok to pack them together using 7-Zip, uploading it to e.g. Rapidshare (can be 10 times downloaded then) and then posting the link?

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

No problem, if you can please post them on mediafire.com

PS: ops, I see you used sector viewer, so this data is on real cd if I understand well? If yes this double sector has to be dumped as it is but has nothing to do with gap lenght. Let's see the subs and I will try to give a better explanation, unless it's a new exception never found here until today.

My patch requests thread
--------------------------------

7 Reply by Feltzkrone (edited by Feltzkrone 2009-10-16 12:19:34)

  • Registered: 2009-10-13
  • Posts: 34

I have uploaded .sub files made with all my three drives at MediaFire, .log files from CloneCD are included:
http://www.mediafire.com/?mumoc1kyoym

Both .log and .sub files are quite interesting. CloneCD seems to generate subchannel data for a (non existing) 02.00 length pregap on Track 2 but keeps the first pregap sector's subchannel data (with relative position of 02.73). Additionally it drops the last sector's subchannel data (relative position (-)00.00) of the pregap, shifting the sectors before that by one position ahead. CloneCD obviously is mad. And don't wonder about the read errors - my first drive is unable to read some audio sectors of a CD when reading subchannel data is enabled. As long as I use EAC for reading audio tracks (which won't read subchannel data at the same time) everything is fine.

I didn't try EAC on my notebook's drive yet, but it's the last chance to detect the (for now seeming correct) pregap of length 02.74. I will try this later or tomorrow and post the result.

EDIT: Yes, with sector viewer I did inspect the CD directly - I didn't make a subchannel dump file and inspected that.

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

I took a look at your subs.

LG1 and plextor reports 2.00 and LG2 reports 2.74.
It seems to me that there's something on sector 41735 (CD is unprotected? No securom?) as it change to Q-Control=0x02 and Q-TNO=0x02 (track number). Then LG1 and plextor come back to Q-Control=0x06 and Q-TNO=0x01 indeed LG2 stands on 0x02 for both. It's not an EAN sector as Q-Address=0x01, so I cannot say at 100% which is right but I will bid on 2.00 instead of 2.74 because in the past subs with double sector count entries (0x73 is repeated - sector 41735-41736) are wrong and is a problem normally found with cdtool / perfectrip ccd and so on.

I hope Fireball will take a look at those subs too so we can find a final solution.

PS: your plextor is a real one? I understood you cannot use d8 command,  but if your drive is a real plextor it works (it will be better because in a disc like this you can get wrong offset with normal method / sector count).

My patch requests thread
--------------------------------

9 Reply by Feltzkrone (edited by Feltzkrone 2009-10-17 15:13:34)

  • Registered: 2009-10-13
  • Posts: 34

That Plextor is not a real one, it's just a rebranded BenQ drive, but yesterday I ordered a real one (PX-716A). As soon as the drive arrives I will create a .sub file with it, too and will use px_d8 on those suspicious sectors. If I need futher help on this I'll ask.

I still bid on 02.74 as I still claim that CloneCD is to dumb to handle the gap between data and first audio track properly. The problem is that both for Plextor.sub and LG1.sub drives were used which are simply unable to read the sectors of the pregap. What CloneCD does is nothing other than performing normal READ CD command - the very same command that CDTool executes when using its sector viewer, but how CloneCD interprets the returned data is another thing.

LG1: With CDTool I am unable to read LBA 41734 to 41807, so the contents of the .sub file for those sectors are a best guess from CloneCD I assume, but nothing that actually came from the drive. That would explain the fallback to Q-Control=0x06 as CloneCD might (wrongly) assume that in this range of LBAs is still within the data track and still before the common pregap of 02.00.

Plextor: With CDTool I am unable to read LBA 41734 to 41957, i.e. the entire pregap area (asummed it really is of length 02.74). When Plextor drive reads data sectors it has a subchannel data offset of +1, i.e. returns the subchannel data from one sector ahead. That way CloneCD still receives the subchannel data of the first pregap sector with relative position of (-)02.73 which is saved in .sub file for LBA 41734.


I claim that CloneCD assumes that the pregap between data track and first audio track being of length 02.00, starting with relative positions (-)02.00 and ending with (-)00.01. Everything falls into place. It seems that once a read error occurs while reading first audio track's pregap sectors CloneCD skips reading further sectors. But regardless of sectors being able to be read or not - CloneCD seems to align the received subchannel data according its assumption. Even in the LG2.sub file, created using a drive which is able to read -all- pregap sectors without any problem, the subchannel data of the first sector in pregap is doubled and the subchannel data of the last sector in pregap is dropped. On drives which fall into a read error during reading pregap sectors CloneCD skips the rest of the pregap and subchannel data for that sector range is regenerated according to CloneCD's assumption, generating Q-Control 0x06 subchannel data until reaching the 150th sector before Track 2 according to the CD's TOC.

Me too hopes for Fireball taking a look at the subs just to be able to take a third opinion about the whole problem into account. smile

EDIT: Here is the TOC of the CD...

Track 01  (Mode 1, LBA: 0)
Track 02  (Audio, LBA: 41958)
Track 03  (Audio, LBA: 70239)
Track 04  (Audio, LBA: 95789)
Track 05  (Audio, LBA: 121439)
Track 06  (Audio, LBA: 156831)
Track 07  (Audio, LBA: 173868)
Track 08  (Audio, LBA: 195981)
Track 09  (Audio, LBA: 217572)
Track 10  (Audio, LBA: 242641)
Lead-Out (LBA: 265118)

PS: Just for interest... Are you using the program Subcode analyzer by nue for inspecting the .sub files?

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

With CDTool I am unable to read LBA 41734 to 41957

This is the main problem with cdtool because it feels those sectors with errors (sometimes is also impossible to understand mode of those sectors), instead of cloncd which tries something.
By the way after you said this it's better to wait to verify a real plextor sub even if it's not a final sentence.

The TOC you reported (from cdtool?) clearly said pregap is 2.00

This a log from your plextor/lg1 I got, simply add 150 for track01 pregap and you got same result for track01 (so your toc says pregap for track02 is 2.00 and not 2.74, but it seems your toc gives also 2.00 pregap for all other tracks losing one sector at the end, so it's quite wrong):

Track   Mode       Flags   Start               Length
-----------------------------------------------------------------
01      UNKNOWN    6       00:00:00 (     0)   09:17:33 ( 41808)
02      UNKNOWN    2       09:17:33 ( 41808)   06:17:07 ( 28282)
03      UNKNOWN    2       15:34:40 ( 70090)   05:40:50 ( 25550)
04      UNKNOWN    2       21:15:15 ( 95640)   05:42:00 ( 25650)
05      UNKNOWN    2       26:57:15 (121290)   07:51:67 ( 35392)
06      UNKNOWN    2       34:49:07 (156682)   03:47:12 ( 17037)
07      UNKNOWN    2       38:36:19 (173719)   04:54:63 ( 22113)
08      UNKNOWN    2       43:31:07 (195832)   04:47:66 ( 21591)
09      UNKNOWN    2       48:18:73 (217423)   05:34:19 ( 25069)
10      UNKNOWN    2       53:53:17 (242492)   05:01:52 ( 22627)
Leadout                    58:54:69 (265119)

Yes, to look at sectors I used Subcode analyzer, to get pregaps I used a beta tool that I don't know if can be shared.

My patch requests thread
--------------------------------

11 Reply by Feltzkrone (edited by Feltzkrone 2009-10-17 18:06:12)

  • Registered: 2009-10-13
  • Posts: 34

At the moment I am finally ripping the audio tracks with my notebook's drive. EAC (configured as described in the guide) in combination with that drive detected a pregap of 02.74 on Track 2, which is what I expected EAC to detect there. At the end I will come up with a redum.org dump - made as described in the guide. Before posting the results in the Dumps subforum I will wait for the real Plextor to arrive and redump the CD with that drive (with the help of px_d8) and hope that the results are the same. If they are the same, i.e. EAC detects 02.74 as the pregap, too + px_d8 leads to the same factory write offset and the checksums of all tracks match... then I'm done, would you agree?
smile

By the way: The reported TOC came from ImgBurn, i.e. the TOC as the drive reports it. The TOC found on CDs usually contain the positions of the first INDEX 01(!) sector of each Track. What the beta tool you are using reports are the LBAs of the first INDEX 00(!) sector of each Track, which perfectly makes sense: For example on Track 5 the TOC says it begins at LBA 121439, EAC says it has a pregap of 01.74 (on all my three drives) and the beta tool reports LBA 121290, which is 149 sectors (=01.74) before the LBA contained in the CD's TOC.

EDIT: I have taken the liberty to override some options in EAC on the Extraction Method tab after Detect Read Features in a way that reactivates EAC's built-in methods of error detection, i.e. my drive said it was capable of reporting C2 errors and having no cache, both may lead to problems if the drive isn't really capable of and only told so.

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

About TOC, ok if it's imgburn so gaps for other tracks is right, by the way it's a wrong toc as it appends gaps to previous track.
I don't know if it's good to change options found by EAC.
As I said it's better to wait what plextor will say also because it can be that offset correction is on 2.00 but pregap is 2.74, so you will have to dump disc with offset taken by d8 command but with pregap from sub (in this situation as those sectors are audio you'll have to descramble 0.74 sectors because they cannot be only 0x00). If the opposite you'll have to take the reverse and scramble. I hope I explained well the matter.

My patch requests thread
--------------------------------
  • Registered: 2009-10-13
  • Posts: 34

To be honest: I think I didn't understand what you wanted to tell me. smile

What I don't get is the 02.00 / 02.74 / 00.74 scrambling and offset problem. So you actually say that when there is a pregap of 02.74 (which consists of Audio sectors throughout) it is still possible that sector at -02.00 must be inspected for determining the factory write offset? Hmmm... I get scrambled bytes throughout the whole sector at -02.74 (and a Mode 1 sync), I get a few ones at -02.73 followed by zeroes.

But instead of words let the data speak (each line is 16 = 0x10 bytes):

Dump of Sector 41734 / -02.74:

607028241E9B486B76AF66FC2AC1DF10  `p($..Hkv.f.*...
580C3A85D3231DD9C99A49AFE2E74854  X.:..#....I...HT
36BF56F03EC4175BA9C9F5D1871C6289  6.V.>..[......b.
E9A6CEFAD4431F71C824569B7EEB604F  .....C.q.$V.~.`O
68342E975C6EB9EC72CDE5958B2F275C  h4..\n..r..../'\
1AB9CB32D7559EBF28701EA4087B46A3  ...2.U..(p...{F.
72F9E582CB2197586EBAAC733DE5D18B  r....!.Xn..s=...
F61FE1DAB6CF36D416DF4ED88371977B  ......6...N..q.{
2EA35C79F9E2C2C99196EC6ECDEC558D  ..\y.......n..U.
FF25D029009B9534C713A321B9D872DA  .%.)...4...!..r.
A59B3B2B535F7DF82182700404268EFE  ..;+S_}.!.p..&..
1E23780C2285D9A31AF9CB02D7419EB0  .#x."........A..
68742EA75C7ABDC99B4D2FD188C7D81C  ht..\z...M/.....
5A89FB26C35AD1FB1C4349F1F6C47943  Z..&.Z...CI...yC
37B7215000FFFFFFFFFFFFFFFFFFFF00  7.!P............
089833610028001E80086006A802FE81  ..3a.(....`.....
80606028281E9E886866AEAAFC7F01E0  .``((...hf......
004800368016E00EC80456837EE1E048  .H.6......V.~..H
4836B696F6EEC6CC52D5FD9F01A8007E  H6......R......~
80206018280A9E8728629EA9A87EFEA0  ..`.(...(b...~..
407830229419AF4AFC3701D6805EE038  @x0"...J.7...^.8
4812B68DB6E5B6CB36D756DEBED8705A  H.......6.V...pZ
A43B3B53537DFDE181886066A82AFE9F  .;;SS}....`f.*..
0068002E801C6009E806CE82D4619F68  .h....`......a.h
682EAE9C7C69E1EEC84C56B5FEF70046  h...|i...LV....F
8032E015880F26841AE34B09F746C6B2  .2....&...K..F..
D2F59D8729A29EF9A842FEB180746027  ....)....B...t`'
681AAE8B3C6751EABC4F31F414474F72  h...<gQ..O1..GOr
B425B75B36BB56F37EC5E053083DC691  .%.[6.V.~..S.=..
92EC6D8DEDA58DBB25B35B35FB57037E  ..m.....%.[5.W.~
81E0604828369E96E86ECEAC547DFF61  ..`H(6...n..T}.a
8028601EA8087E86A062F829829EE1A8  .(`...~..b.)....
487EB6A076F826C29AD1AB1C7F49E036  H~..v.&......I.6
C816D68EDEE4584B7AB76336A9D6FEDE  ......XKz.c6....
C058503ABC1331CDD4559F7F28201E98  .XP:..1..U..(...
086A86AF22FC1981CAE057083E869062  .j..".....W.>..b
EC298DDEE5984B2AB75F36B816F28EC5  .)....K*._6.....
A4533B7DD3619DE8698EAEE47C4B61F7  .S;}.a..i...|Ka.
6846AEB2FC7581E7204A98372A969F2E  hF...u...J.7*...
E81C4E89F466C76AD2AF1DBC09B1C6F4  ..N..f.j........
52C77D92A1ADB87DB2A1B5B87732A695  R.}....}....w2..
BAEF330C15C5CF13140DCF4594332F55  ..3........E.3/U
DC3F19D00ADC0719C28AD1A71C7A89E3  .?...........z..
26C9DAD6DB1EDB485B76BB66F36AC5EF  &......H[v.f.j..
130C0DC5C593132DCDDD9599AF2AFC1F  .......-.....*..
01C80056803EE010480C3685D6E31EC9  ...V.>..H.6.....
C856D6BEDEF058443AB35335FDD7019E  .V....XD:.S5....
8068602EA81C7E89E066C82AD69F1EE8  .h`...~..f.*....
084E86B462F76986AEE2FC4981F6E046  .N..b.i....I...F
C832D6959EEF284C1EB5C87716A68EFA  .2....(L...w....
E4430B71C76452AB7DBF61B028741EA7  .C.q.dR.}.a.(t..
487AB6A336F9D6C2DED1985C6AB9EF32  Hz..6......\j..2
CC1595CF2F141C0F49C436D356DDFED9  ..../...I.6.V...
805AE03B0813468DF2E5858B232759DA  .Z.;..F.....#'Y.
BADB331B55CB7F17600EA8047E836061  ..3.U...`...~.`a
E8284E9EB468776EA6AC7AFDE30189C0  .(N..hwn..z.....
66D02ADC1F19C80AD6871EE28849A6B6  f.*..........I..
FAF6C306D1C2DC5199FC6AC1EF104C0C  .......Q..j...L.
35C5D7131E8DC86596AB2EFF5C4039F0  5......e....\@9.
12C40D9345ADF33D85D1A31C79C9E2D6  ....E..=....y...
C99ED6E85ECEB85472BF65B02B341F57  ....^..Tr.e.+4.W
483EB69076EC26CDDAD59B1F2B481F76  H>..v.&.....+H.v
8826E69ACAEB170F4E8434635769FEAE  .&......N.4cWi..
C07C5021FC1841CAB057343E97506EBC  .|P!..A..W4>.Pn.
2C71DDE4598B7AE7630AA9C73ED2905D  ,q..Y.z.c...>..]
AC39BDD2F19D8469A36EF9EC42CDF195  .9.....i.n..B...
846F236C19EDCACD9715AE8F3C6411EB  .o#l........<d..
4C4F75F427075A82BB21B35875FAA703  LOu.'.Z..!.Xu...
3A81D3205DD8399A92EB2D8F5DA439BB  :...].9...-.].9.
52F37D85E1A30879C6A2D2F99D82E9A1  R.}....y........
8EF86442AB71BF64702B641F6B482F76  ..dB.q.dp+d.kH/v
9C26E9DACEDB145B4F7B74236759EABA  .&.....[O{t#gY..
CF331415CF4F14340F57443EB35075FC  .3...O.4.WD>.Pu.
2701DA805B203B58137A8DE32589DB26  '...[.;X.z..%..&
DB5ADB7B1B634B69F76EC6AC52FDFD81  .Z.{.cKi.n..R...
81A0607828229E99A86AFEAF007C0021  ..`x("...j...|.!
C018500ABC0731C29451AF7C7C21E1D8  ..P...1..Q.||!..
485AB6BB36F356C5FED3005DC0399012  HZ..6.V....].9..
EC0D8DC5A5933B2DD35D9DF9A982FEE1  ......;-.]......
80486036A816FE8EC064502B7C1F61C8  .H`6.....dP+|.a.
28569EBEE8704EA4347B57637EA9E07E  (V...pN.4{Wc~..~
C82056983EEA904F2C341DD7499EB6E8  ..V.>..O,4..I...
76CEA6D47ADF631829CA9ED7285E9EB8  v...z.c.)...(^..
6872AEA5BC7B31E35449FF76C026D01A  hr...{1.TI.v.&..
DC0B19C74AD2B71DB689B6E6F6CAC6D7  ....J...........
12DE8D9865AAAB3F3F50103C0C11C5CC  ....e..??P.<....
5315FDCF0194006F402C301DD4099F46  S......o@,0....F
E832CE95946F2F6C1C2DC9DD96D9AEDA  .2...o/l.-......
FC5B01FB40437031E4144B4F777426A7  .[..@Cp1..KOwt&.
5AFABB033341D5F05F0438035281FDA0  Z...3A.._.8.R...
41B830729425AF5B3C3B51D37C5DE1F9  A.0r.%.[<;Q.|]..
8842E6B18AF467076A82AF21BC1871CA  .B....g.j..!..q.
A4573B7E93606DE82D8E9DA469BB6EF3  .W;~.`m.-...i.n.
6C45EDF30D85C5A31339CDD2D59D9F29  lE.......9.....)
A81EFE884066B02AF41F074802B681B6  ....@f.*...H....
E076C826D69ADEEB184F4AB437375696  .v.&.....OJ.77V.
BEEEF04C4435F35705FE830061C02850  ...LD5.W....a.(P
1EBC0871C6A452FB7D8361A1E8784EA2  ...q..R.}.a..xN.
B479B762F6A986FEE2C0499036EC16CD  .y.b......I.6...
CED5945F2F781C2289D9A6DAFADB031B  ..._/x."........
41CB7057643EAB507F7C2021D8185A8A  A.pWd>.P.|.!..Z.
BB27335A95FB2F035C01F9C042D0319C  .'3Z../.\...B.1.
1469CF6ED42C5F5DF8398292E1AD887D  .i.n.,_].9.....}
A6A1BAF87302A5C1BB10734C25F5DB07  ....s.....sL%...
1B428B71A7647AAB633F69D02EDC1C59  .B.q.dz.c?i....Y
C9FAD6C31ED1C85C56B9FEF2C0459033  .......\V....E.3
2C15DDCF19940AEF470C3285D5A31F39  ,.......G.2....9
C812D68D9EE5A84B3EB75076BC26F1DA  .......K>.Pv.&..
C45B137B4DE37589E726CA9AD72B1E9F  .[.{M.u..&...+..
486836AE96FC6EC1EC504DFC3581D720  Hh6...n..PM.5...
5E98386A92AF2DBC1DB1C9B456F77EC6  ^.8j..-.....V.~.
A052F83D8291A1AC787DE2A189B866F2  .R.=....x}....f.
AAC5BF13300DD4059F432831DE94586F  ....0....C(1..Xo
7AAC233DD9D19ADC6B19EF4ACC3715D6  z.#=....k..J.7..
8F1EE4084B46B772F6A586FB22C35991  ....KF.r....".Y.
FAEC430DF1C58453237DD9E19AC86B16  ..C....S#}....k.
AF4EFC3441D7705EA4387B52A37DB9E1  .N.4A.p^.8{R.}..
B2C87596A72EFA9C4329F1DEC458537A  ..u.....C)...XSz
BDE33189D466DF6AD82F1A9C0B29C75E  ..1..f.j./...).^
D2B85DB2B9B5B2F735869722EE998C6A  ..].....5.."...j
E5EF0B0C0745C2B311B5CC7715E68F0A  .....E.....w....
E4070B428771A2A479BB62F36985EEE3  ...B.q..y.b.i...
0C49C5F6D306DDC2D9919AEC6B0DEF45  .I..........k..E
8C3325D5DB1F1B480B768766E2AAC9BF  .3%....H.v.f....
16F00EC40453437DF1E184486376A9E6  .....SC}...Hcv..
FECAC057103E8C1065CC2B15DF4F1834  ...W.>..e.+..O.4
0A97472EB29C75A9E73ECA90572C3E9D  ..G...u..>..W,>.
D0699C2EE9DC4ED9F45AC77B12A34DB9  .i....N..Z.{..M.
F5B2C73592972DAE9DBC69B1EEF44C47  ...5..-...i...LG
75F2A705BA833321D5D85F1AB80B3287  u.....3!.._...2.
55A2BF39B012F40D8745A2B339B5D2F7  U..9.....E..9...
1D8689A2E6F98AC2E7118A8C6725EA9B  ............g%..
0F2B441F734825F69B06EB42CF719424  .+D.sH%....B.q.$
6F5B6C3B6DD36D9DEDA98DBEE5B04B34  o[l;m.m.......K4
375756BEBEF0704424335B55FB7F0360  7WV...pD$3[U...`
01E8004E80346017680EAE847C6361E9  ...N.4`.h...|ca.
E84ECEB454777F66A02AF81F028801A6  .N..Tw.f.*......
807AE0230819C68AD2E71D8A89A726FA  .z.#..........&.
9AC32B11DF4C5835FA97032E81DC6059  ..+..LX5......`Y
E83ACE93146DCF6D942DAF5DBC39B1D2  .:...m.m.-.].9..
F45D8779A2A2F9B982F2E185886326A9  .].y.........c&.
DAFEDB005B403B7013640DEB458F7324  ....[@;p.d..E.s$
25DB5B1B7B4B637769E6AECAFC5701FE  %.[.{Kcwi....W..
80406030CC4DDAF2486436AB56FF7EC0  .@`0.M..Hd6.V.~.
2E403AC90A91C72C529DFDA981BEE070  .@:....,R......p
4824369B56EB7ECF6054283F5E90386C  H$6.V.~.`T(?^.8l
12ADCDBD95B1AF347C1761CEA8547EBF  .......4|.a..T~.


Dump of Sector 41735 / -02.73:

607028241E9B486B76AF66FC2AC1DF10  `p($..Hkv.f.*...
580C3A85D3231DD9C99AE7004F484854  X.:..#......OHHT
36BF56F03EC4175B5DC9F5D1871C6289  6.V.>..[].....b.
E9A6CEFAD4431F71C824569B7EEB604F  .....C.q.$V.~.`O
68342E975C6EB9EC72CDE5958B2F275C  h4..\n..r..../'\
1AB9CB32D7559EBF28701EA4087B46A3  ...2.U..(p...{F.
72F9E582CB2197586EBAAC733DE5D18B  r....!.Xn..s=...
C9D5DC10B6CF36D416DF4ED88371977B  ......6...N..q.{
2EA35C79F9E2C2C99196EC6ECDEC558D  ..\y.......n..U.
FF25F122CEF53DB780F5A321B9D872DA  .%."..=....!..r.
A59B3B2B535F7DF821821504B82657FE  ..;+S_}.!....&W.
1E23780C2285D9A31AF9CB02D7419EB0  .#x."........A..
68742EA75C7A0CA769E91437F0EBD81C  ht..\z..i..7....
5A89FB26C35AD1FB1C4349F1F6C4E943  Z..&.Z...CI....C
7FB7F950000000000000000000000000  ...P............
... rest of sector is zeroes, so I cut it here ...
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

It was an example, obviously you cannot determine pregap on audio sectors, but reverse sentence is possible: offset on 2.74 but pregap on 2.00 --> this will take 74 sectors of audio to data track and they have to take audio mode so you have to move 74sec of 0x00 without changing mode (I know it's weird, but if there's a mastering error that report this we have to save it as it is unless someone who mastered disc will prove the correct one).

Sorry but data you reported doesn't seem scrambled bytes but offset correction garbage. I repeat it's better to wait also Fireball sentence or at least a sub with real plextor.
With a d8 command compatible drive you can also dump disc with cdtoimg (http://vigi.dremora.com/cdtoimg.rar), it will dump all disc in scramble format so you can get the real lenght of track01-02.

My patch requests thread
--------------------------------
  • Registered: 2009-10-13
  • Posts: 34

Ahhh... now I understand as I wanted to dump the CD of "Nick Faldo's Championship Golf"....

EAC detects the pregap as 00.00 (maybe because there is MCN subchannel data in it), the subchannel data itself tells -03.00 (checked with CDTool) but at -02.00 I find the sector with scrambled/garbage bytes which can be used to determine the factory write offset (+80). Well, it just tells us that it's pretty well mastered, according to ECMA-130. In this case we have a pregap of 03.00 consisting of 01.00 of Mode 1 sectors and 02.00 of Audio sectors.

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

Yes, if real pregap is right you have to take offset you'll find at 2.00 but pregap will be 3.00 (it's better to use d8 command to avoid errors) and as you said

In this case we have a pregap of 03.00 consisting of 01.00 of Mode 1 sectors and 02.00 of Audio sectors.

My patch requests thread
--------------------------------
  • Registered: 2006-12-24
  • Posts: 3,847

Looks like you have a very shitty drive(s). Either one of them (DVDRAM GMA-4082N, LG2.sub) "decided" to fix the gap subchannels part after meeting the first gap (00 02 73) sector, or the other two (DVD-RAM GSA-H55N and PX-740A) refused to return the proper data (and according to your words - it's the 2nd case). PX-740A (=BenQ DW1640) - is it able to read the first audio gap on any disc at all? My DW1650 gives read error on 99% when dumping the pre-audio datatracks with IsoBuster - it refuses to read "errorneous" zeroed sectors as a part of datatrack, your case is probably the same.

  • Registered: 2009-10-13
  • Posts: 34

F1ReB4LL wrote:

Looks like you have a very shitty drive(s). Either one of them (DVDRAM GMA-4082N, LG2.sub) "decided" to fix the gap subchannels part after meeting the first gap (00 02 73) sector, or the other two (DVD-RAM GSA-H55N and PX-740A) refused to return the proper data (and according to your words - it's the 2nd case). PX-740A (=BenQ DW1640) - is it able to read the first audio gap on any disc at all? My DW1650 gives read error on 99% when dumping the pre-audio datatracks with IsoBuster - it refuses to read "errorneous" zeroed sectors as a part of datatrack, your case is probably the same.

Yes, PX-740A is the worst one, it can't read any pregap sector at all and with IsoBuster it behaves like you described. The only unusual thing is that this is the first CD on which GSA-H55N refuses to read the whole pregap data. With other CDs it has no problems. I must admit that it's really best to wait for the real Plextor to arrive and create a proper .sub with it. smile

  • Registered: 2006-12-24
  • Posts: 3,847

Feltzkrone wrote:

Yes, PX-740A is the worst one, it can't read any pregap sector at all and with IsoBuster it behaves like you described.

It's very good, though, when you dump CDs using the EAC and IsoBuster (not PerfectRip), because in most cases you don't need to resize the data track (only fix the last sector with cdmage, BenQs fail on reading it). Of course, you need to read the audio tracks with EAC on another drive - benqs don't support C2 errors reporting, no overreading into lead-out and, of course, no post-data-track audio pregap reading.

20 Reply by Feltzkrone (edited by Feltzkrone 2009-10-19 19:50:14)

  • Registered: 2009-10-13
  • Posts: 34

PX-716A arrived today, checked factory write offset with it. First (supposed) pregap sector contains 32 scrambled bytes (i.e. 8 samples), drive has a +30 read offset so factory write offset should be -22. Then I used CloneCD to create a .sub file and I am surprised, CloneCD didn't destroy the subchannel data this time. The reason might be that the PX-716A has a constant subchannel offset of zero.

Here are the subs: http://rapidshare.com/files/295129132/M … 6A.7z.html (mediafire didn't work today)

From what I can see with "Subcode analzyer" the pregap is 02.74. @F1ReB4LL & Rocknroms: Can you confirm this pregap using this .sub file?


EDIT: Usage of PX_D8 returned this

C:\Dokumente und Einstellungen\Feltzkrone>px_d8 r 0
Sector: 0
MSF: 00:02:00
Combined offset: +32 bytes / +8 samples
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

Yes, 2.74 confirmed without any oddities in sub, so it's quite sure that it was a problem of other drives of yours.
Also write offset is right 8 - 30 = -22

As sub has no problem both perfectrip and EAC should detect right pregap 2.74 with PX-716A.

My patch requests thread
--------------------------------