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