Redump Forum

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:
then cut the lenght of data sectors, example if it's 1 sector:
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.

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?

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.


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 (https://redump.info/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...

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

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.

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.