I reported a similiar bug almost three years ago... If I remember correctly the problem is that the tracks start 150 sectors (2s) later than they should. I had attached a patch, but it probably wont apply anymore...
See: http://sourceforge.net/tracker/index.php?func … 551&atid=467232

I forgot to mention that I'm running DOSBox 0.65 under Windows 2000. The 150 bytes is standard under Windows, but now I'm wondering, this problem had been reported as a problem under SDL? So DOSBox gets a sector address that is shifted by 300 bytes from SDL under a Windows system, but SDL compensates for this shift in its own library?

The reason for my confusion is that during my fiddeling around, I thought this can't be right???, so then I made my SDL-SPY override the standard SDL_CDPlay so that it corrected the values to the standard value, by subtracting 300 from start. After correcting my SDL-SPY called the original function with the corrected values. This in fact improved the sound, because when Tomb Raider started with the old SDL parameters, the sound went directly to the high pitched sound without the interval of a smooth tone and crackled a bit. By doing the method with my SDL-SPY, DOSBox did everything normally, it started smoothly without crackling.

So now I'm wondering, or this is a SDL problem or a DOSBox problem, or no problem at all, but just a shifted value. I'm going to check the SDL DLL for what parameters it sends to DOSBox, if these are standard, then it is a DOSBox problem otherwise its an SDL problem or shift.

The ISOBuster values are also compensated for the 150 bytes gap. So by SDL or DOSBox there are really 300 bytes added to the 150 standard gap.

But why would there be a 300 bytes shift and not a 150 bytes one if Linux suffers under the 150 bytes gap?

Erik.

Well, this time I've got evidence of both SDL and DOSBox doing something wrong.

This test was done under DOSBox with a harddrive mounted and a CDROM mounted under IOCTRL. Under Windows 2000. DOSBox 0.65 standard from the DOSBox site.

I started DOSBox with my SDL Spy to get all parameters send and gotten from the SDL. This is what I got back :

SDL_CDStatus called, with results
- cdrom->tracks[1].offset = 88642
- cdrom->tracks[1].length = 14745

ISOBuster reported, with the "- 150 bytes" in place
- offset = 88492 ( SDLVAL - 150 )
- length = 14745

My TOC builder reported, "Self built and compiled"
Idem for ISOBuster, returned offset from DEVICEIOCONTROL API - 150 bytes

SDL_CDPlay called for track 1, with
- start = 88792 ( SDLVAL + 150 )
- length = 14745

So the evidence is telling me that SDL ,in Windows, doesn't compensate for the 150 bytes gap when calling SDL_CDStatus. SDL doesn't internally subtract 150 bytes from the offset reported.

Then looking at the values for the SDL_CDPlay, there are 150 bytes added extra to the value SDL reported with SDL_CDStatus.

The evidence now states that DOSBox in Windows overcompensates the 150 bytes gap. Suspecting this I wandered around through the code and got the following results back. See the doc for extra info in the attachment.

In the function CDROM_Interface_SDL::GetAudioTrackInfo
DOSBox calls the SDL_CDStatus function witch reports back the none altered offset for the tracks. But DOSBox also compensates for the 150 bytes gap and thus, together with the SDL not compesating the 150 bytes gap, creating the 300 bytes gap I was talking about in the first post.

Now only rests us the question, does SDL_CDPlay need to be called by the values returned by SDL_CDStatus or does it need to be called by the offset reported by SDL_CDStatus - 150?

My guess would be, after listening for hours to the same song over and over, trying differant values, that SDL_CDPlay needs to be called by the ISOBusters values, so DOSBox has a problem that can be fixed.

I'm going to release D.O.G. with my SDL-SPY the coming month set to compensate the wrong values, fixing the wrong values from the SDL and fixing the overcompensation of DOSBox. So this will be my present to you guys.

Hope this helps,

Erik.

Erik.

well it might be wrong. (our shift).