Search options (Page 1 of 2)

Generally no,  fireball and themabus's discussion regards the question of wether an improperly mastered disc with subcode that indicates the wrong gaps should be 'corrected' by rounding to get back the expected pre-mastering tracks. If one of these incorrectly mastered discs is read multiple times it would show the same gaps (just arguably incorrect ones).
This only applies to older systems that had this issue. (i.e. Sega CD).

According to greynol in regards to weather CRC with be different:

Gaps won't effect track crcs if "No use null samples for CRC calculations" is checked in EAC, so long as the gap isn't so far off as to push data past the track boundary. We want track timing to be correct as well as the track data, so we include the leading and trailing zeros in our Hash calculations. 

True, but the track timing will deviate resulting in an incorrect gap structure in the cue. In essence the important data on a cd consists of the data and audio tracks and the subcode that indicates track gaps.
Since the subcode can't reliably be dumped with matching crcs we use EAC or other methods to get the track layout and store that information in the cue file. In other words the .cue file captures all the important information from the subcode. Dumping with no gap detection would result in repeatable data and audio track dumps, but we would permanantly lose the subcode information.

You could dump all the audio to a single file and specify tracks in the .cue file, but you'd still have the same gap issues.  It would be easier to correct gap errors in a cue file instead of moving data around,  but the convienience of multiple tracks outweigs this in my opinion. A correct gap structure is part of a good dump so there's no way to get around it.

I couldn't find any mention in the quidelines of color calibrarion. You can get close by hand, but you have the color inacuracy of the scanner compounded by the color innacuracy of the monitor. Do they mention it somewhere else?

It may not be copy protection. It may be that the disc was simply mastered in a non-standard way resulting in false c2 errors. In any case I'd guess it would only effect the audio track extraction. I'd agree the psx probably doesn't use c2 judging from its poor fault tollerence. I'll burn a copy and make sure though.

Welcome! I still use the methods described in the guide. Just be sure to dump the track twice prefererably on two different drives.

A couple notes if and when you dump audio track games:
Drive choice is important. Look around the forum and you'll see various recomendations. See this thread (post 10) for my recomendations.

EAC cannot determine pregap on single audio-track games so you have to find the gap manually. For instance if you follow the guide and go back 150 sectors and find scrambled data, the game has a 2 second gap. If you had to go back 300 sectors to find scrambled data it's a 4 second gap, etc. You'd then generate the appropriate length padding file full of zeros, copy it onto the beginning of the extracted audio track, and delete that number of sectors from the data track. (Only for games with a single audio track!)

PM me if you have any questions along the way :-)

You're right! I didn't notice that. I did check the subcode and it indicates 2.02. However it seems to me the main channel data should take precedence.
Here the hash info for tracks 9-11 with 2.00 gaps. I think a mention of the bad gap data should go in the notes section for anyone dumping the disc in future.

rom ( name "Track 09.bin" size 25081728 crc 5628c115 md5 94dfc125229751d6aaa9ddcfe568e0a4 sha1 c33746fefac948422c1e09b078197f926126db1f )
    rom ( name "Track 10.bin" size 44243472 crc 9d3182e4 md5 1f3dde9fd843b3c0cd3c852a365db331 sha1 4e09abb19a84d538679e511707af1ec803a66ab4 )
    rom ( name "Track 11.bin" size 52945872 crc e518bd5e md5 097ed5cb6a2e3683370aa38a50a33c73 sha1 5fa4d66e21bcaccf8289e586be1ef643fc57df2d )
    rom ( name "Track 12.bin" size 1902768 crc 61aa9edc md5 47fa258e0d27c876d83bb5e07cc039ce sha1 7dd140fd6165c3c9ec67013baad05e2c88b2f1fa )