Redump Forum

Guys, it doesn't contain any garbage in pregap, there is just some data in the 3rd sector of the track that "may" look like garbage, but it's not!

He has just to add 2 secs silent data to the 2nd track dumped in EAC and it's DONE!

Nobody said it's garbage... by the way ghost made a lot of confusion.
If track01 is 105762 sec, those sectors (105915 and 105935) are part of track02 and are not in pregap so it can be dumped without any problem.

RetroGamer wrote:it isn't better to extract the data track and the audio track and use the ReMove program to move the gap from the end of track 1 to the beggining of track 2? Maybe we should always use this program in discs with only one audio track.

It's possible, but the gap in the end of track 1 in 99% cases is incomplete. Basically, you should skip the (1st_track.size+combined_offset.size*4) and cut 150 sectors (150*2352=352800 bytes) after that. combined_offset.size*4 = garbage.size (in bytes). But any regular track 1 dump contains only (150*2352 - combined_offset.size*4) bytes of gap.

Imagine the 2MB CD, where 1st data track is 1MB and the 2nd audio track is 1MB, first 2 secs of 2nd audio track is pregap. The disc is burned with +100 offset and the drive has +30 read offset. CloneCD dump will contain: 1MB data track, then (100+30)*4 bytes of garbage, then 1048576-(100+30)*4 bytes of the 2nd audiotrack, total size of the dump = 2MB, the last (100+30)*4 bytes of the audio track will be missing. Track 1 dump from IsoBuster will contain: 1MB data track, then (100+30)*4 bytes of garbage, then 352800-(100+30)*4 bytes of the gap, the last (100+30)*4 bytes of the gap will be missing. (The example isn't very good, though, because 2097152 bytes can't be divided to 2352, so there can't be a 2MB disc, but I've wanted some rounded numbers).

There are 3 ways to cope with that.
1 - to write a proper dumping tool, if someone is interested, I'll help with technical docs, algorithms and testing (don't have enough time for coding).
2 - to extract the sector range in IsoBuster/CD Reader/CD tool/whatever (the next sector after the data track, length should be (352800+combined_offset.size*4)/2352 sectors (150,22 should be rounded to 151, 154,678 to 155, etc.), then you should cut the gap, skipping the garbage bytes: skip the combined_offset.size*4, the rest should contain the complete gap.
3 - to extract the bytes range from CloneCD dump - skip the (1st_track.size+combined_offset.size*4) and cut 150 sectors (150*2352=352800 bytes) after that.

Then I will keep my dump as is and submit it soon. that data on the 3rd sector of track02 maybe it is a manufacturing error I can hear it on the actual cd. I thought maybe I could fix that.

Now i understand... and after all, the bytes that we use to count the offset are in the begging of the gap (if we use ReMove), just one more thing to clear this up: if those bytes (the rows we use to calculate the offset) are removed from the data track and if they are not present in the first audio track then what's the deal? those bytes don't exist in the real disc and are generated by the drive?

Anyway thanks for the explanations, i had this idea bugging me since i started dumping discs with audio tracks  lol

All the data is shifted - data and audio sectors. But any drive fixes the offset for data sectors automatically during the descrambling process.

For example, combined offset is +100, the drives reads the sector #0, then tries to descramble it. Data is shifted and first 100*4=400 bytes contain garbage (the last 400 bytes of the sector #-1, which is actually a 1st track pregap, which is written in sectors #-150 to #-1 and usually ignored by all the dumping tools), so the drive automatically reads 400 more bytes from the next sector, then descrambles it, then the drive reads the sector #1, first 100*4=400 bytes are garbage again, so it reads 400 more bytes from the next sector, etc. Afterall, the drive reads the last data sector, first 400 bytes are garbage again, so it reads 400 more bytes from the next sector (first audio sector, also 400 bytes of garbage in the beginning) to descramble the last data sector properly. Then, the drive reads the next sector (audio) "as is", then it reads the next sextor, the next, etc. But, if you remember, the first audio sector contains the last 400 shifted bytes, which belong to the previous data sector - so that's your "garbage".

The whole image is affected by the offset, but it's compensated for the data part and ignored for the audio. As a result, the last 400 bytes of the last data sector are written twice in the image - first, in descrambled form, as a part of the last data sector; second, in scrambled form, as a part of the first audio sector. Therefore, the last 400 bytes of the last audio track are totally missing, coping with that is the goal of Redump.org.