F1ReB4LL wrote:

you should get at least 2x confirmations on at least 2 different drives to get a somewhat reliable result

Agreed for this. But the same argument (that it will take hours to properly dump sub-channel data) might be used for claiming that reading subchannel data (and give susicious positions -one- re-read) along with main channel data on a regular dump is a good thing, because you save at least one complete dump of the disc (in order to read sub-channel). Btw. as subs reading mode I have used 001b.

However, the problems I've written about led me to the decision to first concentrate on helper classes and conversion routines etc. so that later changes or extensions of the utility won't be such an annoyance to do (the main code can be kept clean better the more lower-level stuff is moved to separate classes). This additionally will help non-coders to read and understand the main code i.e. what the utility does.

Just to inform you that work is still in progress... big_smile

No, I didn't made any mistake while posting the dumps and Plextor ones are not the same: There are three 01s in the D8 dump (channels R-W) where in the READ CD dump are 00s. The only mistake I made is that XORing as explained does NOT result in Plextor's READ CD result but in LG's one. Tonight I will burn a test CD with some data on subchannels R-W and read that one out using D8 - should give some clue about what Plextor really returns on D8 as I don't have trust anymore that it really returns raw subchannel data for P-W. I deeply hope that it's a fault in my interleaving code but I don't believe so.

EDIT: If everything goes bad, a plain D8 dump wouldn't be sufficient. The proposed C2 reporting still needs a check and for now returned subchannel data doesn't look like being proper and as themabus set D8 along with code 08 can be guessed not to be supported by all D8-capable drives. I'm afraid we run into real problems here and have these variants:

1. We can choose between D8/08 and D8/02 for either receiving C2 pointers or correct subchannel data, the first one probably not supported by all drives.
2. If we go for D8/02 immediate re-read with normal READ CD command (and C2 pointer selection) might return the wanted C2 pointers, but only if the drive caches data, so this method is pretty unsafe IMO - but how to get C2 pointers for our D8-read data then?
3. As for audio sectors I believe READ CD pretty much should return the same data as D8 - shouldn't we switch to plain READ CD (+C2+SUB) after receiving the first audio sector with D8?
4. Are C2 pointers really needed when reading data sectors using D8? Wouldn't descrambling, calculating ECC/EDC and re-reads (maybe multiple times like EAC) on ECC/EDC differences between stored and calculated data be sufficient?

Thanks for testing the command. I'm afraid I run into bigger problems right now: PX-716A returns inconsistent subchannel data between the mentioned D8 and normal READ CD commands.

D8 on PX-716A using my tool, viewing .sub file with HxD:

000D3C20  00 00 00 00 00 00 00 00 00 00 00 00 41 01 00 02  ............A...
000D3C30  00 35 00 02 02 35 6F FE 00 00 01 00 00 00 00 00  .5...5o.........
000D3C40  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000D3C50  00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00  ................
000D3C60  00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
000D3C70  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

READ CD on same sector (still PX-716A) using cdtool:

00000000000000000000000041010002  ............A...
0035000202356FFE0000000000000000  .5...5o.........
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................

Same sector with my LG drive using cdtool:

00000000000000000000000041010102  ............A...
0035000202356FFE0000000000000000  .5...5o.........
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................

Note how the dump using LG drive looks fine and how the dumps using PX-716A using D8 and normal READ CD command differ (look at those 01s and especially the INDEX = 00 values). If you XOR the first 0x30 bytes from the D8 dump with the second 0x30 bytes you get the same 0x30 bytes as using PX-716A along with READ CD. By the way: The results are 1:1 reproduced, even if medium removed and re-inserted.

This is very strange and in my opinion there are only two possibilites:
1. The LG drive cleans the data (maybe using the Q channels 16 bit checksum)
2. PX-716A does some hocus pocus or has problems when reading subs
2a. With D8 possibly the second 0x30 bytes act as error pointers (???)
2b. With READ CD those errors are partially cleaned, as INDEX is still returned as 00 instead of 01

Any ideas how to handle this properly? Ofcourse the dumping tool might make use of the 16-bit CRC value as generating Q channel data like it -should- look like, calculate CRC for that data and compare CRC with returned CRC. If there's a match and the returned data is suspicious, take the generated instead. I personally don't like recovery methods like these but if nobody else has an idea 1) what might be the reason for this strange behaviour and 2) how to handle it properly I wouldn't know what to do.

Thanks in advance.

EDIT: Perhaps this behaviour is related to Rocknrom's PerfectRip gap/index problem (here) as my PX-716A returns the very same (wrong) data with both subchannel mode 001b and 100b. I guess what Plextor returns here -should- really be handled as errors, since I would have to write index changes on the dumped sector aswell if the data would be taken seriously.

EDIT2: I have done a dump using PerfectRip and it doesn't produce any wrong INDEX entries, but look at this log extract...

Info    | 22:50:52 | Pause found: 410200000300001555597822
Error   | 22:50:52 | Error while burst reading sectors: 071590 to 071615 (15:54.40 to 15:54.65)
Info    | 22:50:52 | Retrying with 1 sector reads from: 071590 (15:54.40)
Error   | 22:50:53 | Error reading sector: 071609 (15:54.59)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071609 (15:54.59)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071610 (15:54.60)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071610 (15:54.60)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071611 (15:54.61)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071611 (15:54.61)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071612 (15:54.62)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071612 (15:54.62)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071613 (15:54.63)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/15/00 - Random positioning error
Error   | 22:50:53 | Error reading sector (ignoring): 071613 (15:54.63)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/15/00 - Random positioning error
Info    | 22:50:53 | 1 sector reads were ok, setting back to burst reading from: 071616 (15:54.66)
Info    | 22:53:48 | Total corrupt Q subcode blocks: 233
Warning | 22:53:48 | Replaced sector: 071609 (15:54.59)
Warning | 22:53:48 | Replaced sector: 071610 (15:54.60)
Warning | 22:53:48 | Replaced sector: 071611 (15:54.61)
Warning | 22:53:48 | Replaced sector: 071612 (15:54.62)
Warning | 22:53:48 | Replaced sector: 071613 (15:54.63)
Info    | 22:53:48 | Reading process completed successfully.

The sectors PerfectRip replaced (because it couldn't read them) are fully readable with CDTool. And please take a look at the Q subcode error count. I guess these come from exactly the strange subchannel data that I've read before.

A little update on this topic: I will first concentrate on dumping discs as F1ReB4LL suggests, need to get hold of a scratched CD (I think some bullshit early 90s audio CD which I have plenty of and a nail will do) in order to verify that the D8 command I found out probably returning subchannel data and C2 error pointers really does it. For anybody interested here is the CDB: D8 00 XX XX XX XX YY YY YY YY 08 00, where X = starting LBA and Y = number of sectors.

Would be nice if anybody could confirm this, I just increased the value at the second last position until the drive returned C2 pointers and subcode. As mentioned before, I personally prefer reading subchannel data aswell because there might be data to be preserved but not possible with CUE format, such as pause styles and MCN and ISRC interleaving and "errors" actually on disc.

By the way, this "document" is the only one found with Google which is at least telling a little about the D8 command. In fact it tells you how things where done back in 1995... ;-)
http://www.isomedia.com/homes/isomedia/ … aq_37.html

Nevertheless, once finished D8 ripping, which might take a few weeks due to proper handling and file output, I will extend the program to work with MMC-compliant and Accurate Stream capable (= no jitter) drives as good as possible (= as good as with IsoBuster + EAC, but a bit better regarding pregap detection).

I'll install ICQ or an IRC client on weekend. I have already finished the thin JNI DeviceIO DLL for Win32/SPTI and used it successfully in Java (plain dump of all sectors of a disc using READ CD CDBs). First I'll need to read and interprete TOC properly, I'll care about that until weekend, so I guess we won't lose any time when waiting (with knowledge exchange) until then.

Regarding D8 scrambled reads... It's another thing left to be defined: What about drives which are unable to read data via D8 command? I think we can't just exclude all users with average drives from submitting dumps - instead I would suggest something like a dump quality measurement where too low quality levels exclude dumps from being added as first-time dumps.

F1ReB4LL wrote:

Unless he's interested to modify PerfectRip (which is written on Delphi) instead of writing everything from scratch.

First I don't have the feeling the author would hand out the source (I didn't ask and might be completely wrong here) and second rewriting from scratch gives us the possibility to do everything as we think should be done.

By the way, there is a not so unimportant thing to consider when rewriting from scratch: Many drives are able to disable error correction when reading data sectors. I believe if e.g. one bit in user data is wrong (on pressed CD) but ECC/EDC is intact, the drive would correct the wrong bit. If those wrong bits really are on CD shouldn't it be considered to write them (wrong) as they are into the image file, i.e. disabling error correction when dumping? Ofcourse, when disabling error correction more than one read per sector would have to be performed to really get sure we got what's on CD - as EAC does with audio data.

I already came over a CD (Al Unser, Jr. Arcade Racing) where a wrong bit is in subchannel data in one sector which is read as it is regardless what drive I used - meaning it really is on CD and not just a random error dropped in by the drive. I guess 1:1 preservation (which is aimed at redump.org AFAIK) should preserve this wrong bit, too. What's your opinion on this?

ssjkakaroto wrote:

because in the future it would be easier to port the program to other OSs

Seconded. The only problem I have with this choice is that I'll have to familiarize myself with JNI which is used to glue native DLLs and the JVM together. But it shouldn't be too hard either and will make things easier in the end as Java does provide a lot of classes and functions to the programmer which are not available in Delphi 7. The critical point in this is that programs which require an installed Java runtime are not that widely accepted by the end users as native Win32 applications are (the same drawback goes for .NET). I'd like to see other opinions on this topic before committing myself to one or another.

I guess it would be sufficient to implement device enumeration and device access (send CDBs to a device and pass data buffer and data direction) in the native DLL. I don't have anything with to do with e.g. Linux, but I guess it shouldn't be a problem for some Linux programmer to build an analogous shared object (I think this is for Linux what DLLs are in Windows) which can be used then.

It's fine that you are willing to provide background info as soon as needed. And here is your volunteer - but with the following drawbacks (at least in the eyes of most coders):
- GUI tool will be coded in Delphi 7 (alternatively commandline-based Java with native DLL usage)
- It will first use SPTI only, so it probably won't work on Windows versions < 2000
- I will only be able to code 1-2 hours per day (employed as programmer, sometimes just being fed up with programming and weekends are there to care for other things)

If you wouldn't mind these drawbacks I'm willing to start, although with the feeling of reinventing the wheel but as all wheels available don't represent a perfect circle I won't care. smile


F1ReB4LL wrote:

This would make many stupid people happy, who think, that our splitted dumps are bad and clonecd ones are perfect.

From what I had to read so far from those people is that they simply don't trust anything other than CloneCD or Alcohol 120%, just because only they can handle newest forms of copy protection etc. If they got knowledge about we would be discarding certain data being present on the CD they immediately would lose their interest. But they don't get the point that tools like ECM discard data, too - in their eyes it's just a stronger form of compression.

I guess because both are common file extensions for the data they contain. The resulting file contains plain 2352 bytes for each sector, no file header, no trailer, nothing else. When talking about files with .iso extension it's more common for them to hold 2048 bytes for each sector, i.e. the user data only.

F1ReB4LL wrote:

Writing a basic proper dumping tool won't take much longer time, so don't see much point in this.

If this really was the case, why don't we already have one? wink

The current guide forces you to use three different tools:

  • IsoBuster

  • ExactAudioCopy

  • Resize

Of course it would make sense to have one tool instead of these three which handles 99% of all cases automatically. Combined offset detection as suggested in the guide is no hocus pocus, generally none of those three do anything which couldn't be automated using one tool. But at the moment we don't have anything like that.

I only wanted to provide a tool which would detect special cases of pregap layouts and simplify the task of determining the combined offset. What's bad about it? Just that we still don't have an all-in-one tool then?

Don't get me wrong, but if such a tool is really wanted you are one of those few people who will have to contribute their knowledge. Coding (half-)blindly might produce a usable all-in-one dumping tool but it won't be perfect then and will cause bad dumps, that's why knowledge is needed to be spread. For example by posting background info on how certain things found on a CD should be detected and interpreted, how errors in audio extraction could be detected and compensated (i.e. figuring out what is so 'magical' about EAC). Once all info needed for coding such a tool we actually can code it and the resulting tool will be reliable. So in my opinion it actually is a lot more work to code such a dumping tool compared to just coding a more or less simple pregap reader.

If you don't mind I'd like to alter the topic subject for something like "Technical discussion for a future dumping tool" and - as the new subject denotes - we could talk about technical backgrounds, tricks and abnormalities here - that the tool should be able to handle properly.

Also we would have to discuss if the tool still should rely on CUE/BIN as with this format mixed-mode pregaps cannot be preserved properly. Subchannel data would have to be preserved aswell where it is non-standard. Apart from that I wouldn't mind discarding Sync and ECC/EDC info in data sectors where they are built the standard way - finally giving an image of the CD which contains user data and abnormalities, from which (if needed) a full and clean CCD/IMG/SUB aswell as a clean CUE/BIN can be reconstructed. What do you think about that?

F1ReB4LL wrote:
Feltzkrone wrote:

How about a tool that just automates pregap (including its subchannel data) analyzing and prints the results - similar to Px_D8 which just prints the combined offset?

What results, exactly?

The tool would analyze Track 2 pregap in case of Mixed-Mode CDs and produce an output like this (example):

Subchannel offset data ... +2 sectors
Subchannel offset audio .. +1 sectors
Q-Channel pregap length .. 225 sectors (-00:02.74 to -00:00.00)
P-Channel flags .......... 225 sectors (-00:02.73 to +00:00.00)
Q/P data matches ......... yes
Combined offset .......... +8 samples

| Pregap layout                                                              |
|  Offset | Length | Type  | Main channel analysis                           |
|    -225 |     75 | Data  | Data (sync found, aligned)                      |
|    -150 |      1 | Audio | 32 scrambled bytes from data sector             |
|    -149 |    149 | Audio | Audio (sync not found)                          |
F1ReB4LL wrote:

I repeat, there are CDs, where those sectors are marked as data in the subs (track is audio, sectors are data AND marked as data in the subs) - I insist on leaving them descrambled and this case suggests different handling

That's why I have asked you implicitly to review the guide: to clarify things. It doesn't matter to me if I (or somebody else) needs to rewrite big parts of it - it doesn't matter if a first proposal might be wrong. All I would like is to see is a proper guide as the result, may it take months, I don't care... So let's use this thread as discussion platform in order to clarify things and simply write down how to detect different cases, what analyzations have to be made and finally how to store data in which form in the image. Once done I'll give it another try. smile

Ok, I understand that things will have to be done differently depending on how the data sectors are marked (as either data or audio), so I hope that I now got it right: If those data sectors are marked as data, keep them unscrambled in Track 2 binary. Is that correct now?

And what if those data sectors are marked as audio? (All following questions refer to audio-marked data sectors...)
1) Are they still in scrambled form on CD or might that depend on the mastering?
2) Does any drive unscramble them automatically if they are scrambled (= drive ignores that they are marked as audio)?
3) If they are not automatically unscrambled, does the factory write offset apply when reading them with READ CD commands, i.e. data is shifted when read, i.e. sync marks are not at the beginning of the returned sector data?
4) How should the data be kept in the image? Scrambled or unscrambled, or depending on certain circumstances?

When you are saying that subchannel data analyzing is necessary in both cases, isn't it that subchannel analysis is first necessary to distinguish both cases from each other and after that (again) necessary to figure out the number of sectors that actually are marked as data?

I'm convinced now that for those cases subchannel data inspection generally must be done. I still find it annoying to rely on CloneCD .sub files as their quality (remember Manic Karts) heavily depends on the quality of drives, i.e. as soon as a drive has changing subchannel data offsets when switching from data to audio sectors the resulting .sub file is crap when produced with CloneCD. But actually all you'd need is a drive just capable of reading pregap sectors.

How about a tool that just automates pregap (including its subchannel data) analyzing and prints the results - similar to Px_D8 which just prints the combined offset?

EDIT: If I may ask in all innocence - are F1ReB4LL and Rocknroms the only ones willing to discuss and clarify more complex cases like these or are other members, moderators and admins just very busy at the moment? (Don't get me wrong - no offense!)


(2 replies, posted in General discussion)

I once dumped a data track using CD Tool and it didn't match the one extracted with IsoBuster, but that's an exception as I disabled the drive's error correction in CD Tool. As long as the software used for dumping the data track does not disable the drive's error correction the checksums should match. And as Sotho Tal Ker said before: Be sure that the software produces a RAW and headerless dump, i.e. plain 2352 bytes per sector.

I could help translating English guides to German aswell.

What's far more annoying is that with the current dumping guide for CD-based games about a quarter of Mixed-Mode CDs which I tried the guide simply is not sufficient. As soon as things are getting complicated it's left to technically more versed members reviewing posted .sub files and telling results, but they don't tell much about the technical backgrounds so newbies could learn from it. Additionally EAC (at least on my PC) has been wrong several times when detecting the first audio track's pregap, regardless of what quality the used drive is. In my case it was unable to detect a pregap of 02.00 and instead showed 00.00 - just happened with a Plextor PX-716A and a disc with clean subchannel data in pregap.

Members who are strictly following the existing guide have no chance at all to detect these pregap oddities, logically won't write a word about it as for them everything is as normal as could be, and finally will post checksums for Track 1 and Track 2 binaries which simply are wrong, which then might be added to the database without any further review.

Currently Rocknroms is discussing with F1ReB4LL on this thread about the special case of mixed-mode pregaps. I've posted a first guide proposal for this case in this thread.

What I just wanted to say is that before translating existing guides to different languages so more people can contribute dumps, I first would want to see airtight new guides combined with additional new utilities making things more secure and easier - and then see those guides translated to other languages. The question is: Do we really want to cause a run of new members contributing more and more first-time dumps which might be bad due to current guides being imperfect?

That's how I do see things - but in general I would welcome translated guides, too.

EDIT: Okay, there's still much things left to clarify - it seems the guide proposal is partially simply wrong as Fireball depicts here. I haven't yet fixed it but will do and rewrite parts (or maybe start all over again as Rockrnoms doesn't find it easy to read) once everything is clear.

---- Original text starting here ----

After heaving read what's going on in the thread "data inside pregap?" I believe we are heavily in need of a proper step-by-step ripping guide for producing correct dumps of CDs which have a pregap in front of Track 2.

The guide aims at producing dumps which contain scrambled pregap data sectors taken from CD in Track 2 binary file, which is, from what I understood so far, the form of preserving such CDs as F1ReB4LL would like to see them. Here is my proposal for such a guide and this guide involves the following tools:
Exact Audio Copy, IsoBuster, CDToImg (D8 hack), Px_D8 and HxD (any other hex editor properly used should be OK, too)

This proposal is built upon a notional example with easy to follow values. I don't know if this is the preferred style of explaining things, at least it is mine. smile

It would be nice if technically versed persons like F1ReB4LL for example read this guide and could confirm that it's correct and judge if it is easy to follow. For the case of something being wrongly described please post corrections and also please post additions when you think that something important is missing.

---- "Ripping guide for Mixed-Mode CDs with data sectors in Track 2 pregap" - proposal in original form ----

1. Getting knowledge of how the pregap is made up

We have a CD-ROM with one data track and two audio tracks. It has the following TOC.

Track 1 - Data  - LBA 0
Track 2 - Audio - LBA 10500, Pregap 00:03.00 (225 sectors)
Track 3 - Audio - LBA 21000, Pregap 00:02.00 (150 sectors)

We first try to determine the combined offset by using either IsoBuster's (or CDTool's) sector viewer. When browsing sectors we always keep in mind that whenever we see unexpected data or get read errors, we go some sectors forward then back to the wanted sector - or first go backward some sectors and then forward to the sector in question.

We substract 225 (as pregap is 03.00) from 10500 and seek to sector 10275. The sector looks like a normal data sector (easiliy recognized because of its sync mark - 00 FF FF FF...). So we go forward using the sector viewer in order to find the sector partially containing scrambled bytes and we finally find 408 scrambled bytes at sector 10350 (the last 408 bytes of the previous data sector in scrambled form).

At this point we know the following: The first 75 sectors of pregap are data sectors, the remaining 150 sectors are audio sectors. The combined offset which will be used to read the audio tracks is +408 bytes / 4 bytes per sample = +102 samples.

2. Doing things as they are normally done

Both audio tracks are read using EAC and the combined read offset of +102. We keep in mind that the first 75 sectors of Track 2 dump must be considered as containing undefined garbage. After that we dump the data track using IsoBuster. We remove the last 225 sectors from Track 1 dump using HxD. Number of bytes to remove is 225 sectors * 2352 bytes per sector = 529200 bytes.

For that purpose in HxD we open the Track 1 binary file, jump to its end by pressing Ctrl+End, choosing Edit / Mark block from the menu. In the dialog we first switch from hex to dec so our input is interpreted as decimal values. We then take the value shown as the start address (which is actually the size of the file), substract the number of bytes to remove from it and finally enter the result as start address and hit OK. By pressing the Del key the block is removed and we now can save the file.

At this point we have already partially finished the dump: The data track dump is correct and all audio track dumps are correct, but Track 2 is still not proper due to the mixed-mode pregap.

3a. Getting a dump of Track 2 as is present on CD: Deleting the current pregap data in Track 2 dump

The first thing we want to do is getting rid of the undefined pregap data contained in Track 2 dump made with EAC. We start by using HxD (or any other hex editor) and opening the Track 2 binary file. We then calculate the length of the pregap in bytes as follows:
Pregap length = number of pregap sectors * 2352 bytes per sector

On this particular disc the formula works as follows:
Pregap length = 225 sectors * 2352 bytes per sector = 529200 bytes

In HxD we now mark the block (Edit / Mark block) using 0 as the start address and the calculated pregap length as the length (after having selected decimal value format in the dialog). We now delete the block (by pressing del key) and don't close or save the file yet - just leave it open and modified as is for now.

3b. Getting a dump of Track 2 as is present on CD: Extracting real pregap data from CD

This step involves the usage of the D8 hack of CDToImg, Px_D8 and a drive capable of processing D8 vendor read commands (such as real Plextor models).

We use Px_D8 to determine the combined offset for the drive used (which is different to the one used in the previous steps, but doesn't matter at all). The combined offset is +30 samples = 120 bytes (or 0x78 in hex). Then we use CDToImg and make a full dump (we choose dump.raw as filename) which contains all data as is present on disc, i.e. all data sectors in this dump are present in scrambled form.

We now calculate the start address of the block/range containing the pregap data in the raw dump as follows:
Start address = (Track 2 LBA - number of pregap sectors) * 2352 bytes per sector + combined offset in bytes

In the current case this leads to the following value:
Start address = (10500 - 225) * 2352 + 120 = 24166920

We now use HxD to copy the wanted block to clipboard. We open the raw dump file (dump.raw) and again mark the wanted block/range using Edit / Mark block. This time we use the calculated start address as start address for this dialog and reuse the previously (step 3a) calculated pregap length as length. Again, before entering the values we check that decimal number format is selected.

Now in HxD we copy the selected block of dump.raw, then change to the still opened Track 2 binary file and insert the copied block right before the very first byte of it. We are now ready to save Track 2 binary file and so we do.

4. Recapitulation of what we have done

  • we extracted all tracks as usual using IsoBuster and EAC

  • we truncated the data track as usual because we had a pregap at Track 2 (audio)

  • we made a full disc dump with CDToImg

  • we removed the (wrongly read) pregap data from Track 2 binary file

  • we then extracted the correct pregap data from the full disc dump

  • we inserted the correct pregap before the remaining Track 2 binary data

In effect we replaced the bad pregap data in Track 2 (which has been read by EAC) with proper pregap data which has been read using CDToImg. That proper pregap data contains several data sectors in scrambled form (as on CD).

5. Handling EAC pregap detection oddities (*not sure if this should be included)

It might happen that EAC is unable to detect the correct pregap length and just returns 00:00.00. In exactly that case we need to use CDTool to browse the sectors as (opposed to IsoBuster) it's able to return subchannel data when viewing sector contents. When using the sector browser in CDTool we'll always have to choose subchannel reading mode "P-W RAW Interleaved (Code 001b)" and select "Deinterleave subch data".

At first we will have to determine the drive's subchannel read offsets for both data and audio sectors. So we start the sector viewer and view sector 75 (a confirmed data sector). In the subchannel data are (the bottom data area) we look at the first four digits of the second line and see "0102" which should be read as 1 second, 2 sectors. We now know that the subchannel data the drive reports is 2 sectors off, i.e. we have a subchannel offset of +2, in the following steps refered to as DSO for data subchannel offset.

Next we take Track 2 LBA from TOC and add 75 (=> 10575) then view that sector. We now read "0101" so we know that the drive has a subchannel offset of +1 when reading audio sectors, in the following steps referred to as ASO for audio subchannel offset. Note that this offset generally can be different to the DSO (and is in this example).

Generally DSO and ASO aswell might be negative. In this case you will find e.g. "0074" as a value in the second row of subchannel data, which reads as 0 seconds, 74 sectors and represents a subchannel offset of -1.

We now go to sector (Track 2 LBA - ASO - 2), in this case (10500 - 1 - 2 = 10497). Again we look at the second row in subchannel data and should find either "0001" or "0002" - and we find "0001". If additionally the last two digits of the first row in subchannel data is "00" there is a pregap on disc which EAC was unable to detect. In general as long as you the "00" at the end of the first line, it is an indicator for being in pregap.

Pregaps usually have lengths of 2, 3 or 4 seconds, in some cases these lengths are one, two or three sectors smaller or greater. These possible lengths should cover 99% of all cases, so instead of going backward sector by sector in the sector viewer, we go backward by 75 sectors. By the way: We do count the number of times we go backward 75 sectors. We now see "0101" which tells us that we still are in pregap and are one second ahead. As we want to find the beginning of the pregap we repeat this step.

Again we go back 75 sectors resulting in "0200" and we see a sync mark in the sector data in the text area above. We still are in the pregap but now the pregap contains data sectors so now the formerly calculated DSO applies instead of ASO. That's why we get "0200" and not the expected value of "0201". To compensate this, we calculate the difference from ASO to DSO as follows: +1 - (+2) = -1. That's the number of sectors we will go foward. In this case the number is negative, so we go one sector backward.

We now get "5357" which has nothing in common with the previously seen values. Additionally we don't see "00" anymore at the end of the first row, so it's an indicator for having left pregap => now being before pregap. We have gone backward 75 sectors for three times. That is 75 * 3 = 225 sectors.

The final step is moving forward (and counting) sector by sector until the last value in the first row becomes "00" again. We have to do this 2 times and now find "00" and in the second row "0274". Now we calculate the pregap length...

1. We have gone three times 75 backward => 225 sectors.
2. We have gone two times one sector forward => - 2 sectors => 223 sectors.
3. We started at Track 2 LBA - ASO - 2, so we skipped the last 2 sectors of pregap => + 2 sectors => 225 sectors

Just for proof we check our calculation by using the "0274" value that can be seen in subchannel data. It shall be read as 2 seconds, 74 sectors. Our first value was "0001" and guess what: We build the difference which is 2 seconds, 73 sectors. Then we add two sectors as we skipped the last 2 sectors of pregap and the circle closes => 3 seconds, 0 sectors.

Finally we go one sector forward and we should notice all those "00000..." values at the beginning of the first row in subchannel data change to "FFFFF...". That's the P-Channel indicating the end of the data track has been entered. The P-Channel usually switches to "FFFFF..." exactly one sector after the beginning of a pregap. So another indicator for having correctly determined the pregap length.

In this case we figured out that the pregap length is 03.00. As EAC left out the pregap completely when reading Track 2 we just skip step 3a and instead we have to manipulate the CUE file made with EAC and will replace "INDEX 01 00:00:00" with "INDEX 00 00:00:00 [CRLF] INDEX 01 00:03:00".

Please note that the remaining steps have to be performed as described. Step 5 is not ment as an addition to the regular dumping guide!


(20 replies, posted in General discussion)

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


(27 replies, posted in General discussion)

ssjkakaroto wrote:

The way I see it, for full preservation, in this cases, we'll need to store the subchannel file with the dump information. Luckily, 7zipped compressed subchannel info can be less than 1 MB.

In subchannel data unluckily there is no error correction involved as far as I know, most drives drop in random errors occassionally when reading subchannel data. Additionally the drive used should be of higher quality. So I guess we would need a utility to read out the subs which re-reads sectors which gave suspicious results (CloneCD doesn't compensate those random errors). Does such a utility exist? Even better: Something like ECM for subchannel data could be useful, I guess this would take a .sub file's size down to some KB if the subchannel data is made up according to the normal rules.

Rocknroms wrote:

Moreover redump is not a DB for burning/pirating/etc., but for preserving data.

Well, if data is preserved in CUE/BIN format only some data (like I described, in thise case) is actually lost. According to the CUE file the data sectors are told to be audio data and will be handled like audio data by all applications, regardless of mounting, burning etc. Moreover who wants do prohibit someone making a copy of a self-bought unprotected CD? In this case reading out the original CD according to redump.org guide, then burning the resulting image would not bet sufficient in means of preservation.


(20 replies, posted in General discussion)

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


(27 replies, posted in General discussion)

It would be nice if a guide for exactly that situation (pregap consists of both data and audio sectors) with explanation of technical background could be added somewhere by a person who really understands it. In my humble opinion it's generally a bad idea to make people do things they don't understand (me included) - else it just frightens. wink


By the way, what happens if there is a pregap of 03.00 of which the first 01.00 are data sectors (even the Q subchannel denotes this) and the remaining 02.00 are audio sectors (Q subchannel denotes this clearly, too). Probably those data sectors have to be moved to the binary file for Track 2, but as ssjkakaroto asks, too, don't they have to be scrambled then?

And whatever the right choice on this question is: How can we represent the sector mode switch at relative -02.00 in Q subchannel with CUE sheet syntax properly? At least I don't find a way to do this. Isn't it that when CUE sheet denotes Audio sectors the subchannel will be (re)generated accordingly, i.e. the 75 data sectors in Track 2 will be marked with Q-CONTROL 0 (Audio) instead of 4 (Data)? So how can the CD properly be preserved using CUE/BIN then?

EDIT #2:

At least when creating a CUE sheet like the one in Base Jumpers (http://redump.org/disc/3872/) with unscrambled data sectors from pregap moved to Track 2 binary file it won't work (for a good reason). I burnt the image with ImgBurn to a CD-RW, then inspected it with CDTool and the reading drive (just logically) interprets those data sectors as audio sectors, so shifting equal to normal audio data applies here (combination of write offset and read offset). Wouldn't it be better to preserve the data sectors in favour of preserving the gap information?


(20 replies, posted in General discussion)

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.


(20 replies, posted in General discussion)

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


(20 replies, posted in General discussion)

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?

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.


(20 replies, posted in General discussion)

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?


(20 replies, posted in General discussion)

I have uploaded .sub files made with all my three drives at MediaFire, .log files from CloneCD are included:

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.


(20 replies, posted in General discussion)

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?