VOGONS


First post, by ClaudeSpeed

User metadata
Rank Newbie
Rank
Newbie

Hi there,

Few days ago I ripped my Destruction Derby CD with DICGUI. Hence getting a .cue and several .bin.

I encountered the same issue discussed in this topic (Destruction Derby IMG file mounted. Asks for CD to play! ) on Ubuntu 18.04 from « normal » Ubuntu repo.

Basically I could install the game by using the following .bat in dosbox:

keyb be
imgmount D "C:\source~1\destr~11.cue" -t iso -fs iso
d:
INSTALL
pause

Then I can set the sound :

keyb be
imgmount D "C:\source~1\destr~11.cue" -t iso -fs iso
cd DERBY
SETSOUND
pause

But finally I can’t run the game:

keyb be
imgmount D "C:\source~1\destr~11.cue" -t iso -fs iso
cd DERBY
DD
pause

As I get this message :

ERROR: This game requires the 'Destruction Derby' CD to run.

Am I doing something wrong with my imgmount command ? Like missing parameters, ... ?

CS

Last edited by ClaudeSpeed on 2018-09-14, 17:47. Edited 1 time in total.

Reply 1 of 9, by ClaudeSpeed

User metadata
Rank Newbie
Rank
Newbie

By mounting the real cd in the drive, I could get the game starting. The mount command I use is:

MOUNT 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:

D CDrom /media/myusername/disk

With my first command, when I check the mounted drives, I can see:

isoDrive <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...

Reply 2 of 9, by ClaudeSpeed

User metadata
Rank Newbie
Rank
Newbie

Hi,

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:
.ccd
.img (containing all the tracks : data + audio tracks)
.sub
And the .cue file that DICGUI is creating for the img.

And my script now works like a charm:

imgmount D "C:\source~1\destru~3.cue" -t iso -fs iso
cd DERBY
DD
pause

Reply 3 of 9, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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.

Here are the correct values the game looks for:

CDROM: GetAudioTrackInfo track=2 MSF 01:03:39
CDROM: GetAudioTrackInfo track=3 MSF 06:39:19
CDROM: GetAudioTrackInfo track=4 MSF 12:00:39
CDROM: GetAudioTrackInfo track=5 MSF 17:24:48
<snip>

Your CUE for the BIN file will surely contain those correct values, like the following:

FILE "DERBY.bin" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
INDEX 01 01:01:39
TRACK 03 AUDIO
INDEX 01 06:37:19
TRACK 04 AUDIO
INDEX 01 11:58:39
TRACK 05 AUDIO
INDEX 01 17:22:48
<snip>

However, here's what DOSBox gives the game when using audio track files:

CDROM: GetAudioTrackInfo track=2 MSF 02:07:03
CDROM: GetAudioTrackInfo track=3 MSF 14:20:02
<game quits after a couple mismatches>

This is despite using a similar Cue with correctly specified MSF values:

FILE data.iso BINARY
TRACK 01 MODE1/2048
INDEX 01 00:00:00
FILE "track02.ogg" MP3
TRACK 02 AUDIO
PREGAP 00:00:00
INDEX 01 01:01:39
FILE "track03.ogg" MP3
TRACK 03 AUDIO
INDEX 01 06:37:19
FILE "track04.ogg" MP3
TRACK 04 AUDIO
INDEX 01 11:58:39
<snip>

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.

Attachments

Last edited by krcroft on 2019-10-07, 18:10. Edited 1 time in total.

Reply 4 of 9, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

ClaudeSpeed,

It was previously mentioned that DOSBox doesn't support multiple BIN files (which you originally mentioned using), where the audio tracks are simply raw rips (ie: not even WAV files).

Good news is this patch fixes that; so you can play Redump-style disks straight away.

Here's my full CUE file - just swap in your filenames. You mentioned using Ubuntu 18.04, so I've attached a static build with the fix included, if you want to try it.

Attachments

Reply 5 of 9, by ClaudeSpeed

User metadata
Rank Newbie
Rank
Newbie

Hi thanks for sharing this.

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.

Reply 6 of 9, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

so dosbox doesn't (or can't) get the right size from the bin/wav files in this case and has to rely on the cue file ? Or the other way around ?

Water flows down the stream
How to ask questions the smart way!

Reply 7 of 9, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 8 of 9, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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).

My chunk-wise circular decode patch, which is in Qbix's review queue, uses this approach:
https://gitlab.com/krcroft/dosbox_audio_updat … _image.cpp#L589

And I suspect the existing code does something similar.

Last edited by krcroft on 2018-11-11, 15:28. Edited 1 time in total.

Reply 9 of 9, by Yesterplay80

User metadata
Rank Member
Rank
Member
krcroft wrote:

So while the game will play with the ~600MB BIN+CUE, it won't when using ISO & audio track files. What's the difference?

Strangely, for me it works just fine with ISO+OGGs.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)