Redump Forum

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

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

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).

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.

No problem anyhow - may everybody have his own opinion.
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?

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.

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.

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).

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.

EDIT: Here is the TOC of the CD...
PS: Just for interest... Are you using the program Subcode analyzer by nue for inspecting the .sub files?

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):
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.