I'm trying to dump Railroad Tycoon 2 but I'm not able to get a consistent gap detection in EAC.
In the cue sheet generated by CloneCD I get 1.74 for all tracks.
I've also attached subs.
Thank you for your help.

Post's attachments

sub1.rar 1.56 mb, 16 downloads since 2010-03-21 

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

2 (edited by TAurus 2010-03-21 19:39:51)

... and second sub

By the way, is there a guide available on this forum or anywhere on the internet on how to analyze the subs ? I want to learn so not to upload subs anytime I have this kind of issues.
Thx.

Post's attachments

sub2.rar 1.56 mb, 15 downloads since 2010-03-21 

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

hi TAurus

basically you would have to read ECMA-130 (chapters: 20, 21, 22) and examine .sub with Subcode Analyzer
here's a brief example with Mode 2 section (most often cause) affecting EAC's gap size detection

I did not have the time to study the documentation, so I appreciate if someone can analyze the subs.
Thank you.

UP

which are problematic tracks?
briefly checking 1st file it looks like data->audio gap = 2s; audio->audio gaps = 1.74s
which is not uncommon pattern
btw for some reason RAR complains about unexpected end of archive for those attachments

7 (edited by TAurus 2010-04-06 20:08:19)

The problematic track is the first one (data->audio). I get 2.74 or 1.74. I've attached again the subs.

Post's attachments

sub1.rar 1.56 mb, 13 downloads since 2010-04-06 

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

second sub

Post's attachments

sub2.rar 1.56 mb, 13 downloads since 2010-04-06 

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

9 (edited by TAurus 2010-04-06 20:19:29)

The files gets corrupted when attached to forum. sad(

Using a 2.74 sec gap I get -588 write offset.
If I use 3 sec gap I get 0 write offset.

I finally read the documentation and did a check with subcode analyzer and I get 2.0 sec for the first track and 1.74 for the rest of them. The problem now is that I have only zero's if I go back 2.0 seconds. I need to get back at least 2.74 to find some data. This is with a +667 drive. If 2.0 sec is the real gap I suppose I need a drive with even larger read offset... Is this correct ?

alright, if you get junk when going back 2.74 sec and valid data sector at  3 sec
(look for '00 ff ff ff ff ff ff ff ff ff ff 00' sync pattern)
it would almost certainly be 2.74 then
to be completely sure about this offset you could check this CD with d8 capable drive
or do CD swapping thing

On my +667 drive I have the following.

I get only zero's if I move back 2 sec (150).
http://lh4.ggpht.com/_WwCu7fWVlXw/S7yIVD-ziRI/AAAAAAAADLY/VCFeqvhALg4/s800/Untitled.jpg

I get some data if I move back 2.74 sec (224)
http://lh6.ggpht.com/_WwCu7fWVlXw/S7yIVLxxPHI/AAAAAAAADLc/wyG0t65ewvY/s800/Untitled1.jpg

On my other drive with +102, I have again zero's when moving back 2 sec and an error when moving back immediately more than 2 sec.
http://lh5.ggpht.com/_WwCu7fWVlXw/S7yIVe_jjgI/AAAAAAAADLg/D68lVvUTxbQ/s800/Untitled2.jpg

on 2nd image it is data from the end of sector 130443
so that would mean 0 offset and 3.0 s gap after all i guess

Here is the gap detection in EAC. I have 2 sec for the first track and 1.73 for the 11th. As I already stated if I go back 2 sec, I get only zero's but if I go 3 sec back I have data, resulting in 0 Write Offset. Let's assume EAC is wrong and I have 3 sec for the first track. The issue now is with the 11th track. I've also attached the sub screenshot and it seems to have only 73 sectors (224616 - 224468 = 148). Is this possible ?

http://lh3.ggpht.com/_WwCu7fWVlXw/S7zWtb0RgjI/AAAAAAAADME/4ihpW4yrBjg/s800/weird_gap.jpg

http://lh5.ggpht.com/_WwCu7fWVlXw/S7zWtOKIKxI/AAAAAAAADMA/sgyFpI74FkQ/s800/Untitled-2.jpg

it does look so indeed from channel Q

some CDs are very messed up in this regard
with all gaps weird and stuff
usually older ones
equipment must have had some threshold for error tolerance when mastering i guess
larger at first, since consumer hardware wasn't that accurate those days too
e.g. PSX would position to requested second not frame
so 1:74 or 1:75 marker in subcode would mean little to it