Menu
▾
▴
#497 Rayman (v1.00) Fails CD Check
When attempting to run v1.00 of Rayman in DOSBox, both the installer (CONFIG.EXE) and the main game (RAYMAN.EXE) fail the CD check. Note that this only occurs with v1.00 of Rayman; with future versions the game runs fine in DOSBox. I am using a redump.org verified CD image, which means that this isn't simply a bad dump. I have tested in PCem and the game installs and runs fine there.
(also, the reason this bug has likely gone unreported is that the v1.00 version of Rayman appears to be extremely rare compared to the other versions)
Delete issue, fixed in SVN.
No longer fixed, not sure when it broke again. The installer works with the latest SVN build, but the game itself fails the check and will only run in limited mode (no CD tracks, watermark over gameplay, only a single screen of gameplay before the game force-closes). This happens when using IMGMOUNT, but if using MOUNT -t cdrom on an actual CD drive (or Daemon Tools in SCSI but not DT mode), the game works. And the image is good (I dumped it to redump.org standards, and it works in PCem).
Last edit: RibShark 2019-04-26
Ribshark,
Rayman 1.0 might be sensitive to MSF locations. Skim the first post here then see the 4th post in the thread where I explain it further https://www.vogons.org/viewtopic.php?f=33&t=62417
If you want to try it, the current version of DOSBox ECE includes the latest version of this MSF handling patch.
Even though I have a later version of Rayman, I do recall my version being similarly tempermental with the same behavior you're describing.
Here's my delta changes to dosbox.conf:
Rayman was installed to "c:\rayman", configured with GUS audio, and the CDROM was imgmounted to D:
Audio tracks were compressed with Ogg OPUS and mounted using the following cue
(DOSBox ECE also includes the patch for FLAC, Opus, and MP3 audio track handling).
Note that I'm not using a PREGAP of 2s nor did I have to lock down MSF track locations like I had to with Destruction Derby in the Vogons thread.
Here's my launch batch file:
Unfortunately I don't have access to a 1.0 CDROM to test with.
Last edit: krcroft 2019-04-26
Later versions of Rayman 1 (1.12 and above, which are a lot more common) do not have this issue. With the patch, DOSBox can't even seem to handle the image at all, every file appears to be empty when the image is mounted with it. The CUE is a standard multi-track cue file and can be downloaded here (just the CUE, no copyrighted stuff). I am guessing the patch isn't able to correctly interpret cue files with multiple .bin files, despite that being perfectly to standard.
Last edit: RibShark 2019-04-26
DOSBox does not support multiple .BIN files; only a single .BIN file containing all data and audio tracks is supported, so I suggest making one of those. However, I think krcroft's patch included support for multiple .BIN files, but I could be mistaken.
I do not believe that is correct. Any other game (and even other versions of Rayman) work fine with multiple .bin files.
Please see these vogons threads for context:
https://www.vogons.org/viewtopic.php?f=33&t=62417
https://www.vogons.org/viewtopic.php?f=31&t=62422
Perhaps you have been using the ECE build which includes krcroft's patch, and that is why you've had some success using multiple .BIN files containing audio tracks. Please note that the ECE build, though based on SVN, contains unofficial patches and is not representative of official source.
Last edit: ripsaw8080 2019-04-29
I have looked into this further. DOSBox by default (most recent official build) does work with multiple audio .BIN files, with some versions of the game, however it erroneously reads from INDEX 00 in the .cue file (the pre-gap) rather than INDEX 01 for any such tracks which causes issues with v1.00, and causes sound delay on other versions with a 2-second pregap. DOSBox-ECE actually makes things worse in this case, as at least one version of the game will not pass the check here where it does on official builds.
Does it help to use a "PREGAP 00:02:00" line in the cuesheet in place of "INDEX 00"?
RibShark,
Thanks - the Japanese 1.0 CUE file you sent provides each track's absolute position (INDEX 01's) on the CDROM.
When loaded in DOSBox-ECE, the INDEX 01s pin down each track's MSF position to match the original CDROM's layout.
Here are the intial checks RAYMAN.EXE makes and the MSF values handed back:
After those checks, RAYMAN.EXE queries the CDROM three times, stops playback, and then plays the intro UbiSoft music for a fixed durations (808 sectors).
RAYMAN.EXE also uses hardcoded CDROM absolute offsets to jump to specific sequences, like the voice track after you've enter your three initials to start the first level.
The INDEX 01 MSFs pass the checks, but that doesn't solve the fact that the audio tracks themselves start with 2 seconds of slience; which is part of the audio sequence itself.
The tracks also contain four frames of audio garbage (roughly 0.05s) at the end, which can cause a very brief "hitch" noise if the track is played all the way through.
We could try tweaking the CUE file to "bake out" these sections, which indeed UbiSoft has done in their 1.12 and 1.20 release CDROMs if you inspect those audio tracks. But we would then need our 1.0 RAYMAN.EXE to be aware of the new durations and absolute offsets.
instead, we can fix the audio tracks out-of-band and keep their sizes exactly the same - so the CUE and RAYMAN.EXE can remain as-is.
The following three (Linux/GNU) commands will clean up the
Rayman (Japan) (Track *).bintracks (using GNU parallel, dd, and truncate). These are non-destructive: they only read from original .bin files and create adjacent ".fix" files.Explanation of commands:
Here's the CUE that refrences the fixed audio tracks (using the original INDEX 01 MSFs) :
The above MSF values are only valid for the Japanese 1.0 release of Rayman, confirmed with the following MD5 sums:
This should have the Japanese 1.0 CD loading properly with clean and properly timed audio, similar to the 1.12 and 1.20 releases.
Because we shifted the audio sequences inside the tracks, this could cause voice sequences to start 2 seconds ahead of the animation, given RAYMAN.EXE is still using the unshifted offsets. I haven't played through it enough to get to these areas though. If you notice a problem, then we could try leaving the voice tracks as-is and simply cleanup their trailing garbage.
Last edit: krcroft 2019-07-28
Such a cuefile is nonstandard. INDEX 01 specifies where in the file the track data (excluding pregap) lies, not the place on the entire CD image, and should be 2:00 for any track with a 2 second pregap. I doubt any cuefile like this would work with any other program. The correct behaviour is to use the size of each track file to calculate the MSF up to the track that is being queried, and then add the INDEX 01 MSF to get the correct MSF for that track.
DOSBox and DOSBox-ECE can emulate a physical CDROM that's composed of compressed audio tracks (Vorbis in the case of DOSBox and Vorbis, Opus, FLAC, and MP3 in the case of DOSBox-ECE).
When compressed audio files are used to simulate CDROM tracks, the only way to determine track "sizes" is to use play-time duration, which can be inexact resulting in MSFs values that don't match those found in the original "pristine" single BIN/CUE.
The vast majority of games don't check MSF values, but some care about it. Destruction Derby is one example, and it looks like Rayman 1.0 is sensitive to this as well.
Therefore, to handle these types of games, DOSBox-ECE's audio patch "overloads" INDEX 01 allowing users to specify absolute MSF start times per track.
Last edit: krcroft 2019-07-28
The trouble there being that your patch then invalidates otherwise valid cue-files such as the Redump Rayman ones I provided you. What I would suggest is extending the cue format by, for example, parsing a line such as
REM MSF: MM:SS:FF = LBA:XXXXXunder theINDEXlines and using that as the MSF (this format is already implemented by ISOBuster, which is why I suggest it). That way, existing standard cue files will still work with your patch. Using theREMcommand will mean that other programs can also parse the edited CUE. This is what redump.org does to extend cue files (for example, for multisession discs), and it works quite well.Last edit: RibShark 2019-07-29
Very nice suggestion!
I will remove the MSF changes from my current patch, allowing it to focus 100% on the stand-alone audio codecs and how DOSBox handles the audio streams.
Given this suggestion brings the CUE file back to full compliance without changing the baseline functionality, I wonder if the best place for this is in the mainline of DOSBox (SVN). QBix, what do you think?
I can work on this MSF handling in a separate patch, ideally only minimally touching the code to include detection of this new string pattern and then skipping the MSF calculations.
Last edit: krcroft 2019-07-29
Back to the issue at hand, which is Rayman (v1.00) failing to work on SVN DOSBox with no patches. I took a look at the code in cdrom_image.cpp and noticed a bug in line 583:
Here, the code checks whether the pregap start is greater than the default value 0, and then skips calculating the pregap if so. The error is that there are valid cuesheets that have the pregap starting at exactly 0 in the file, which matches the default. Here is an example of the Rayman cuesheet I was using to demonstrate this:
One solution is to use a different default value for
prestart, such as-1, and check against that instead. I have attached a .patch file with this fix.While this fix is enough to get Rayman v1.00 past the initial text screen, it is not enough to fool the game entirely, as when entering gameplay this text shows: see image.I will look into more detail and see if I can figure out what the additional bug is (or whether my fix is incorrect).
Last edit: RibShark 2019-07-30
Nevermind! It seems the game pulled a sneaky trick and the installer, despite not throwing an error with the mainline SVN build, actually put a flag in the games config file to say it wasn't a legitimate copy. Reinstalling the game with my patch applied removes the watermark and the game runs perfectly.
RibShark,
I reverted the patch's CDROM_Interface_Image::AddTrack() and CDROM_Interface_Image::LoadCueSheet() functions to the baseline (SVN) and applied your prestart changes. The Japanese 1.0 games installs and plays like you noted.
The music starts immediately when the UbiSoft splash srcreen , skipping past the track's 2-seconds (or 150 frames or 352800 bytes) of initial silence. However, from that 352800-byte offset, the game still attempts to play an additional 808 frames, which runs beyond the end of the BIN file by 150 frames (or 352800 bytes). The BIN file itself is only 808 frames in size.
You can also hear the audio glitch out moments before it overruns.
You can see the problem playout in the debug statements as well as when the game runs beyond the end of the track (the patch protectively feeds the mixer zeros).
That said.. the games does play; but I can't help but suspect the CDROM layout or the track content is flawed. Then again, maybe reading beyond a track's end is either undefined or legal on real real hardware and/or MSCDEX, and this this is all just fine? (the more accurate we can make DOSBox, the better!).
Last edit: krcroft 2019-07-30
It is quite possible the track layout is flawed, however this is exactly as it was mastered on the disc. Using the actual CD to play the game (with mount D X:\ -t cdrom) gives exactly the same results. Running the game in PCem also shows identical results, at least audially. So I think DOSBox is doing the right thing here, and the game is just asking the drive to play for the wrong time. You can also test it with the 1.0 European version (the 2nd link that I sent you) and see if that performs the same.
RibShark,
When the BIN files are concatenated (single .bin and single-file CUE), the prestart = -1 patch doesn't solve (or honor) the two-second track start offset. Instead, the game plays two seconds of silence prior to hearing the start of audio.
Last edit: krcroft 2019-08-02