1 (edited by ssjkakaroto 2009-10-14 06:00:14)

Hi guys, I'm trying to dump Twinsen's Odyssey, which has the following structure

FILE "Twinsen's Odyssey (Track 01).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Twinsen's Odyssey (Track 02).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:03:00
FILE "Twinsen's Odyssey (Track 03).bin" BINARY
  TRACK 03 AUDIO
    INDEX 01 00:00:00
FILE "Twinsen's Odyssey (Track 04).bin" BINARY
  TRACK 04 AUDIO
    INDEX 01 00:00:00
FILE "Twinsen's Odyssey (Track 05).bin" BINARY
  TRACK 05 AUDIO
    INDEX 01 00:00:00
FILE "Twinsen's Odyssey (Track 06).bin" BINARY
  TRACK 06 AUDIO
    INDEX 01 00:00:00
FILE "Twinsen's Odyssey (Track 07).bin" BINARY
  TRACK 07 AUDIO
    INDEX 01 00:00:00

I used px_d8 to detect the write offset (+2) and I was able to get somewhat consistent results:
Track 1: Plextor 760A = Plextor Premium = NEC 3540A = Pioneer 115D (after using 'resize')
Track 2: Plextor 760A = Plextor Premium <> NEC 3540A = Pioneer 115D
Tracks 3-6: Plextor 760A = Plextor Premium = NEC 3540A = Pioneer 115D
Track 7: Plextor 760A = Plextor Premium <> NEC 3540A = Pioneer 115D (No overread in these two, so I'm not worried)

The problem is this:
If I try to use the Isobuster way to find the write offset, either the drives can't seek to the sector (192504 - 225) or the sector is always full of data, but if I just click on track 2 and use sector view (which leads to sector 192504) I can calculate the write offset.
So I took a look with HxD at what was at those 529200 bytes (3 second pregap) that I was removing with 'resize' and what I got was actual data, as you can see in the attachment (scroll to 2B80).

So what should I do here?

Post's attachments

split.rar 73.66 kb, 25 downloads since 2009-10-14 

You don't have the permssions to download the attachments of this post.

That file looks to be part of one of the files on the disc. I can see the data inside what appears to be a text or ini file (or maybe some other file that has human readable text in it). Maybe if I had a copy of more of the data I might be able to see what is going on.

I'll upload the first part of track 1 and post the link tomorrow (gonna leave it uploading overnight tongue)

http://redump.org/disc/9360/

Similar case. 3seconds pregap, 1 sec data, 2 secs silence.

Here's the first part of the file:
http://www.megaupload.com/?d=Q8DRQC6G

3.00 is correct, subs are also clear. http://redump.org/disc/3872/ and http://redump.org/disc/4032/ -- similar cases with CD32 discs, just a weird mastering, but has nothing to do with the protection. If the gap is marked as data in the subs, it should be descrambled, if as audio (common for Saturn) - should be scrambled. PerfectRip is unable to make the proper dumps of such tracks, btw, EAC also fails in most cases. You should dump the disc with d8 cdtoimg and manually extract the track from it.

PCE CD subs should be read backwards (from the last sector upto the first, then inverted) to get the proper subs and proper gaps, all the current dumps are bad. And please, don't ever give any advices, when you don't understand the case.

So F1ReB4LL, can you post a little tutorial on how I extract the first track after dumping the image with cdtoimg?

You need a chopfile tool or similar. bytes_to_skip = (datatrack_length + combined_offset_in_bytes); length = audiotrack_length.

For example: http://redump.org/disc/6896/ -- datatrack_lenth is 319512144, audiotrack_length is 24025680 (both should be found using the subs only), combined offset for the most plerxtors with +30 read offset would be +30+0=+30=120 bytes. So, bytes_to_skip = 120+319512144=319512264 bytes. But _only_ if the gap is marked as data in the subs. If audio - should be cut from CloneCD dump instead (and in 3 stages). Anyway, upload the subs at first.

9 (edited by ssjkakaroto 2009-10-17 20:30:18)

Subs (Plextor Premium): http://sharebee.com/3b7e318e
Subs (Plextor PX-760A): http://sharebee.com/fec7ea62

Data track is 452240208 bytes, then 3secs of audio pregap. If there are data sectors - should be extracted in scrambled form from cdtoimg dump.

F1ReB4LL, if it's confirmed that there are data sectors in pregap we can simply take them from Isobuster dumping the data track as always and then use remove instead of resize:

remove -size=225sec "track 01.bin" pregap.bin

then cut the lenght of data sectors, example if it's 1 sector:

remove -direction=left -size=1sec data_scrambled.bin pregap.bin

then use Descramble_CDDA (if there's no link around I'll upload it again) to descramble this data.
At last when you have the descrambled sector, like in the example, you have simply to remove first sector of track02 and exchange it with the new descrambled one.
I think it's more speedy and I can confirm you got same result as I recover some of your dumps when I got also right offset.

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

12 (edited by ssjkakaroto 2009-10-18 20:26:37)

If you use Isobuster the pregap will be descrambled, no? Then won't you need to scramble it to put it back on the audio track if the data is marked as audio in the subs?

13 (edited by Feltzkrone 2009-10-18 21:42:26)

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


EDIT:

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?

@whoever added my dump: I think you should leave the comment about the scrambled data in the track 2 pregap.

Feltzkrone wrote:

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?

You cannot represent sectors i CUE correctly at all. This matter was discussed in the past with Fireball, I had the same thoughts of yours but then I change my mind because we cannot fix arbitrary something reported in subcode unless we have a clear reply from someone who mastered those discs. To explain better, if those discs were badly mastered (as it is) we cannot fix them otherwise we have no real preservetion. Eventually it could be discussed again once we have more hints.
Moreover redump is not a DB for burning/pirating/etc., but for preserving data. Those sectors can be switched in any moment, at least we have preserved all data like reported in subcodes.

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.

I'm working on something also because we have no scambling/descrambling faq unless themabus faq on pce discs.

ssjkakaroto wrote:

@whoever added my dump: I think you should leave the comment about the scrambled data in the track 2 pregap.

Can you repost comment you add about un/scrambled sector (I dont understand if is one sector or one second) and someone will add it back.

EDIT: I have to understand too why someone removes comments in PC section when they are necessary. I have already asked it in the past...

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

@Rocknroms: The whole 3 seconds of the pregap are scrambled data sectors.

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.

17 (edited by Feltzkrone 2009-10-19 07:45:59)

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.

Rocknroms wrote:

F1ReB4LL, if it's confirmed that there are data sectors in pregap we can simply take them from Isobuster dumping the data track as always and then use remove instead of resize:

Any drive manages the 1st gap as a part of data track, if there are any scrambled sectors - they will be descrambled. Also don't forget, that you can't get a complete gap in isobuster dump of the first track - with positive combined offset there's always a garbage between the data and audio sectors and, as a result, the very end of the gap is cut.

Feltzkrone wrote:

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?

In my opinion, we shouldn't have any descrambled images at all - a dump should represent the unmodified content of the disc. Descrambling gives us lots of problems. Yes, there are images with the data sectors in audio - some of them have those sectors marked as data in the subs (TFX, Base Jumpers, etc.), others - don't (many Saturn ones, like Gunbird; some PC ones, like that Twinsen's Odyssey). I've wanted to split them somehow, that's why in the first case data sectors are descrambled and in the second they are left scrambled. If we want proper dumps, both should be left unscrambled (along with the data tracks) and the subs should be also preserved.

Feltzkrone wrote:

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

First of all, the database can't currently handle them at all -- CDs with different rings and same tracks usually have different subs, so they should be assignable to a ringcode, not to an entry. As for the actual dumping -- yes, subs should be dumped either via multiple rereadings (prepare to wait ~8-12 hours per CD) or cleaned manually or automatically (this can easily ruin any protection).

F1ReB4LL wrote:
Rocknroms wrote:

F1ReB4LL, if it's confirmed that there are data sectors in pregap we can simply take them from Isobuster dumping the data track as always and then use remove instead of resize:

Any drive manages the 1st gap as a part of data track, if there are any scrambled sectors - they will be descrambled. Also don't forget, that you can't get a complete gap in isobuster dump of the first track - with positive combined offset there's always a garbage between the data and audio sectors and, as a result, the very end of the gap is cut.

If you save track or segment with isobuster (or if you take it from bin-cue) there's no garbage inside pregap. Garbage is only present in sector view on real CD (or you can get it with wrong offset dumping audio), it is not dumped otherwise you'll have to move also data offset like we do with audio.
It could be that IB put garbage in pregap of track02 (dumping track01) simply because it cannot handle well scrambled sectors, otherwise for example every SS disc with data+data would be wrong (I always got same result perfectrip=isobuster after moving sectors and they are all disc with positive offset).

By the way my point is always valid, you can use also my tools used to fix DC pregaps, simply find sector count, save and unscramble (all those sectors we are talking about are simply empty data sector with data only headers and thse are always the same if you get the correct data mode).
Moreover you can get all pregap in data mode in IB, sector count it's not cut as it is between low and high density on GDIs.

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

I repeat, any drive descrambles everything in datatrack automatically, including the next audio gap, because it "belongs" to the same datatrack (drive splits tracks by TOC and TOC contains LBAs of all the 01 indexes, 00 index belongs to the previous track, according to this logic), d8 edition of cdtoimg is a must.

F1ReB4LL wrote:

I repeat, any drive descrambles everything in datatrack automatically, including the next audio gap, because it "belongs" to the same datatrack (drive splits tracks by TOC and TOC contains LBAs of all the 01 indexes, 00 index belongs to the previous track, according to this logic), d8 edition of cdtoimg is a must.

I didn's say anything different. We are talking of audio gap and if we have a bad mastering situation (this gap attached to the end of "track 01" has any garbage due to offset correction, the sectors are simply saved as data <---> they are 0x00 audio descrambled to data format so simply empty sectors with mode1/2 headers).
If you have to move sectors as audio, simply use the operation I said above to unscramble sectors (I did this operation to retrieve most of SS dumps if I got right offset correction).

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

No rescrambling of descrambled data, please. We've already seen corrupted scrambled data sectors in the audio gap. Remember, if there are data sectors in audio gap, this is a badly mastered disc and there can be anything, descrambled data can be wrong and rescrambling will make things even worse. We're a database of dumps, not manually rescrambled things. a) Plextor, cdtoimg and chopfile or b) Swap trick, CD tool and chopfile - no more alternatives (yet).

What are you talking about? Did you understand or not?
Empty data sectors has nothing corrupt, they are simply empty with headers

The following is simply an empty mode1 sector and not garbage:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  00 FF FF FF FF FF FF FF FF FF FF 00 00 02 00 01  .ÿÿÿÿÿÿÿÿÿÿ.....
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000110  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000120  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000200  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000210  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000220  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000250  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000260  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000270  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000280  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000290  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000002F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000300  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000310  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000320  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000330  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000340  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000350  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000360  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000370  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000380  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000390  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000003F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000400  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000410  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000420  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000430  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000440  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000450  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000460  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000470  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000480  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000490  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000004A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000004B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000004C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000004D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000004E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000004F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000500  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000510  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000520  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000530  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000540  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000550  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000560  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000570  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000580  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000590  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000005A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000005B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000005C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000005D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000005E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000005F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000600  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000610  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000620  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000630  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000640  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000650  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000660  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000670  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000680  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000690  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000006A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000006B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000006C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000006D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000006E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000006F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000700  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000710  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000720  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000730  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000740  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000750  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000760  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000770  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000780  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000790  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000800  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000810  C5 13 68 2B 00 00 00 00 00 00 00 00 00 F7 00 F5  Å.h+.........÷.õ
00000820  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000830  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000840  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000850  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000860  00 00 00 00 00 00 52 35 B8 7D 00 00 00 00 00 00  ......R5¸}......
00000870  00 00 00 F5 00 F4 00 00 00 00 00 00 00 00 00 00  ...õ.ô..........
00000880  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000890  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000008A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000008B0  00 00 00 00 00 00 00 00 00 00 00 00 97 26 D0 56  ............—&ÐV
000008C0  00 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00  .........A......
000008D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 2D 17  ..............-.
000008E0  2E 1B B1 48 B2 44 00 00 00 00 00 00 00 00 00 00  ..±H²D..........
000008F0  00 00 00 00 00 00 00 65 00 C2 00 E6 00 43 00 00  .......e.Â.æ.C..
00000900  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000910  00 00 45 3C 53 75 33 2B 25 62 00 00 00 00 00 00  ..E<Su3+%b......
00000920  00 00 00 00 00 00 00 00 00 00 00 90 00 C1 00 12  .............Á..

a) Plextor, cdtoimg and chopfile or b) Swap trick, CD tool and chopfile

Don't you have to rescrambling something in both situations? Or not? don't you have to use descramble_CDDA or something similar?
I repeat again THOSE SECTORS ARE EMPTY and so they are always the same if they take sector count and mode (the only exception can be fake TOC discs, but I don't see any in DB, did you?).

And I repeat again descrambled data can be wrong ok, if so you can use sector from an empty mode1/2 track to fix it (or simply use this track to create scrambled sectors). And there's no garbage at the end on data track, those are empty dta sectors (you want to call them descrambled audio pregap? Wel is the same thing because this audio is 0x00 and when descrambled you will get empty data sectors like the one above, no garbage this is simply header on 0x00).

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

Rocknroms wrote:

a) Plextor, cdtoimg and chopfile or b) Swap trick, CD tool and chopfile

Don't you have to rescrambling something in both situations? Or not? don't you have to use descramble_CDDA or something similar?

Nope, no need to use. cdtoimg or swap trick + cd tool give the scrambled sectors, you just dump them and that's all. And I mean cases like http://redump.org/disc/7077/ or http://redump.org/disc/8047/ which contain abnormal scrambled data sectors, which sometimes give correct descrambled ones (by a drive's firmware on some drives). Rescrambling them back won't give you proper sectors. That's why I say, that in any case of incorrect mastering you should dump the scrambled sectors properly, because they can be abnormal.

Rocknroms wrote:

And I repeat again descrambled data can be wrong ok, if so you can use sector from an empty mode1/2 track to fix it (or simply use this track to create scrambled sectors).

We don't fix anything, we preserve the data "as is". Or am I misunderstanding you?

This http://redump.org/disc/8047/ is the only exception, the other one is the same of my examples, that is not garbage unless it has wrong offset.

About the other point you don't fix anything, simply speed up the process importing the same sectors from an empty image without redumping it with cdtoimg or trap disc. There's nothing to fix or modify, disc has always the same structure, if it's mode1 for example, all empty sectors will have the same header at same position for any disc with mode1 form unless toc is fake. The sector I write above is the first empty sector of any image, it's always the same in any disc if this sector is empty. So if you know with sub analisys that n sector or sectors have to be scrambled you can simply take these from an empty image (same position, same format) and unscramble them with descramble_cdda. If they don't have to be scrambled they are simply ready as they are.

PS: About your PCE assertions above, today we have probably something more to check real gaps, I'll report something as soon as I have time to take a look.

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