By mounting the real cd in the drive, I could get the game starting. The mount command I use is:
1MOUNT D /media/myusername/disk/ -t cdrom -usecd 0 -ioctl
When I check the mounted drives, I can see that it appears as a cd drive, which pleases Destruction Derby:
1D CDrom /media/myusername/disk
With my first command, when I check the mounted drives, I can see:
1isoDrive <path to my cue>/Destruction Derby.cue
So at least to run the game, it seems that the key is to make my .cue mounted as a cd drive instead of an isoDrive and this, I don't manage to do.
Other problem I face (when playing from cd), there is no music. This is probably because the game CD is a mixed one (data + audio). So I already know what the next challenge will be to make this game correctly working...
Issue is solved (thanks Qbix, ripsaw8080 and kode54 for the precious help) !
The root cause was the image was spread amongst several .bin (one for the data track and one per audio track).
So basically, I redumped my game (because I delete all the other image format and only kept the .bin / .cue).
This time, I kept the CloneCD files:
.img (containing all the tracks : data + audio tracks)
And the .cue file that DICGUI is creating for the img.
And my script now works like a charm:
1imgmount D "C:\source~1\destru~3.cue" -t iso -fs iso 2cd DERBY 3DD 4pause
So while the game will play with the ~600MB BIN+CUE, it won't when using individual audio tracks (.wav, .ogg). What's the difference?
It turns out Destruction Derby verifies each audio track's minute, second, frame (MSF) value, which are specified in the CUE file on the "INDEX 01 MM:SS:FF" lines, however DOSBox calculates its own MSF's when loading multi-file CUEs.
Attached is a patch for the latest DOSBox (r4162) that honors MSFs in multi-file CUE sheets, if present, and a Windows binary if you want to try it.
The Windows binary will show you the above MSF diagnostic output.
Also note a subtlety with Destruction Derby is it doesn't use an additional 2-second pregap (it wants PREGAP 00:00:00); I've attached my working cdrom.cue, if you rip your bin/cue to compressed audio tracks.
In fact I'm using dosbox on Ubuntu 18.04 in order to test my setups. End goal is to run the games on a Raspberry Pi 3 running Recalbox distribution.
So I'll continue to use single .bin / .img until the fixes you told me is integrated in the version used by Recalbox.
But anyway, I'll test your fix in the comming week. I don't have my Plextor with me right now to redump it now and keep the .cue + multi bins.
I wonder what will happen when the original MSF length doesn't match the compressed audio. The usual case would be where the compressed track is shorter; e.g. ripping drops the lead-in and/or lead-out, compression drops trailing silence, and so forth. Of course such things can be avoided if one knows to watch out for them, and the software has the capability, but still need to make sure nothing untoward (errors, glitches, noise, etc.) happens in the event of an audio file shorter than what the CUE specifies.
Yes, it seems DOSBox miscalculates MSF positions for all games, not just Destruction Derby. If you compare any BIN/CUE vs ISO+OGG/CUE, the MSF positions differ.
The existing DOSBox code queries the second OGG's track length (plus rounding and padding), which it adds to the second track's start position (the MSF), and so on. Each previous track lengh accumulates to determine subsequent start positions.
This patch uses any provided exact MSF values to "lock down" each track's start time provided the prior track's length fits or is shorter (which is always the case if the CDROM is valid).
To catch invalid cases, DOSBox's existing AddTrack function already has checks to catch over-length scenarios where the prior track would overrun the start position of the subsequent track and will fail the imgmount command.
On the other hand, tracks with shorter-than-expected lengths won't harm the start times (like you mentioned ripsaw), and if the dos program asks to play more frames than the track actually has, then the callback is simply fed silence when the audio decoder fails to hand over those remaining bytes (which might only be a handful of milliseconds).