Redump Forum

pnkiller78 wrote:Well, I think that we have problems with the games with audio tracks, I noticed that with the current info submitted to the database, the last data track starting position doesn't match the same number as the gdi provided by httpd-ack and by using the redump.org gdi file the game doesn't start in nullDC.
In httpd-ack's gdi file the starting position is 150 sectors ahead that the calculated using the tracks sizes currently in the database, I think that this have to do with same issue observed on the first session of the disc, httpd-ack eats 150 sectors at the end of the last audio track, if I manually append 150 at the last audio track the position match and the game start.
So, I think that, at least by now, until somebody comes with better solution or explanation, that for games with audio tracks, the last audio track must have 150 appended to the end of the file, so start position of the last track match with the gdi script and the dump effectively runs on nullDC.

Can you please post tracks sizes and gdi from httpd-ack dump (without any manual corrections) of Sega Rally 2?

pnkiller78 wrote:Also, I found this thread on ngemu.com, I think that the script should consider the control field (third parameter) in the gdi files

ctrl : 4 -> data , 0 -> audio

Fixed.

Dremora wrote:Can you please post tracks sizes and gdi from httpd-ack dump (without any manual corrections) of Sega Rally 2?

Sure, here...

GDI file...
Also, here it is a screenshot of the first session of the disc and the disc properties windows on ISOBuster.

Ok, now I see... httpd-ack makes not full dumps: tracks 2, 4 and 3rd data track (if exists) are missing pregaps (150 sectors). So we should use track 2 from EAC, 150 sectors should be added to the beginning of track 4. The only question is: what's the contents of 3rd data track pregap? I hope Vigi can answer it — he has dumped several GD-ROMs using PC drive.

Well, basically that's what I did..
* Fixed track 2 according to EAC
* Added the pregap to the track 4
* Added the pregap from the 3rd data track (track 21) to the end of last audio track (track 20).

Hope we can discover more soon, anyway, fix any error is easy cause everything here is about pregap info.

pnkiller78 wrote:* Added the pregap from the 3rd data track (track 21) to the end of last audio track (track 20).

I think it's wrong; 150 sectors are missing from here, so moving data from one track to another won't help, it needs to be generated.

Yeah, I agree with you, apparently httpd-ack doesn't dump pregap of the data tracks, that's why track 2 have 150 sectors less, and track 20 too. In the case of track 2 it's easy to fix because it's readable by EAC and PC drives, but in the other case we must guess.

I have not moved any data, I generated 'em using hex-editor (150 sectors filled with zeros), the dump from the last data track (track 21) start with info from files, not pause... and the end of track 20 ends with audio, I'm assuming that what it's missing is the track 21 pregap, so I generate it and inserted at the end of the previous track (track 20).

pnkiller78 wrote:I have not moved any data, I generated 'em using hex-editor (150 sectors filled with zeros), the dump from the last data track (track 21) start with info from files, not pause... and the end of track 20 ends with audio, I'm assuming that what it's missing is the track 21 pregap, so I generate it and inserted at the end of the previous track (track 20).

I doubt 3rd data track pregap has just zeroes (because it's data track, not audio, it should have at least sync and header). Also pregap should be added to the beginning of data track, not to the end of previous audio track.

Oh, I see,
What do you think we could do by now?
Is there a way do dump the pregap for that track?

I am not sure if we can dump it (with this tool), but I think there is no data there except for the sync, header (perhaps also EDC & ECC) — we need to ask Vigi.

Ok, I made this discovery...
In the url in httpd-ack for dumping the last audio track there's a parameter that can be modified to force the daemon to dump the entire track including the pregap
This way the resulting last audio track contains the pregap for the last data track appended to its end.
Analyzing the data in this last 150 sectors, I found that indeed they are empty data sectors, that it's, sectors with no data, just the sectors with the appropriate control fields (Sync, header, EDC, etc), but there's something different in every disc, the first few sectors (5-30 sectors) are shifted by the offset that appear on the audio tracks and the data is not zeros, it's garbage like the one that appears scrambled while calculating disc offsets in ISOBuster sector viewer. Also, I cannot get the same garbage data by reading the track again, if I read the track again, the garbage appear on the same place, but with differente numbers, after the garbage data ends, the zero data sectors appear exactly in the same position with the same control fields every time.
By example, dumping track 20 of Sega Rally, it showed 5 sectors or garbage data in the last data track pregap, after that 145 secotrs were consistent if dumped over and over again.
With Slave Zero, it showed 29 sectors with corrupted info, again with every read, the garbage changed, the remaining 121 sectors of the pregap were the same.

If this pregap it's added to the begging of the last data track, the gdi adjusted properly using the proper values for the sizes of the audio track made the game playable on nullDC.

Also, I made an experiment, if I generate the pregap using zeros, append it to the last data track at the beginning and then fix the sectors using CDMage, the sectors that stayed consistent on the dumped pregaps are the same, that's mean the 145 sectors for Sega Rally and the 121 sector of Slave Zero match their values with the corresponding sectors generated and rebuilded with CDMage.

So, I think that the pregap, it's in fact just zero data in data form1 sectors, that it can be generated, appended to the beginning of the last data track, fixed or rebuilded with CDMage.

What do you think?