After some more testing with vanilla DOSBox r4168 I figured out that it does happen but only after running my AUTOEXEC.BAT. Then I narrowed it down to DOSLFN.COM. So, this is not specific to ECE, but somehow r4168 is not playing well with DOSLFN.

DOSLFN has never really worked with DOSBox's emulation of DOS -- internal DOS structures are not sufficiently emulated. However, r4168 adds enough emulation of the DPB that DOSLFN is actually trying to work now; whereas before it decided the drive is an unsupported type and did nothing. The moral of the story: don't use DOSLFN unless booting real DOS. There are unofficial builds of DOSBox that feature LFN, but those aren't supported here.

Yesterplay80 wrote:What's the use of ISO/WAV/CUE images anyway? Why not just use BIN/CUE?

I would like to be able to hot swap the music in the Heroes of Might & Magic II game (I have images of the original Succession Wars game and the addon Price of Loyalty). This can be done, switching of the CDs works with Ctrl+F4. Unfortunately, with BIN/CUE format the music tracks are not played from the beginning after hot swapping of the CD (I suppose DOSBox caches information about the locations of the tracks after start of the game). It is the main reason of my question.

And ISO/WAV/CUE format is more convenient for me personally because I rip music tracks (from mixed mode CDs) separately with Exact Audio Copy. But it is minor reason.

I have memsize set to 64 and I get a message in the console about it being out of the accepted range of 1-63 and using the closest accepted number which is 63. Huh? Why can't I set the available memory to 64mb? The site of ECE says "Supports up to 384 MB of memory, required for running Windows 9x on top of DOSBox ECE"

And a second question, I think I have stuff in my conf files which are obsolete or depend on patches that ECE may not have, for example the [vsync] section ... does it do anything? Is there a reference conf file for the ECE build so I am not confused?

AlexRK wrote:Unfortunately, with BIN/CUE format the music tracks are not played from the beginning after hot swapping of the CD (I suppose DOSBox caches information about the locations of the tracks after start of the game). It is the main reason of my question.

The MSCDEX interface plays red book audio tracks using an absolute CDROM sector position (measured from start of the CDROM) and a duration, measured in in number of sectors.

Some games only query the CDROM's table of contents once to get each track's absolute sector positions, and they use those track sector positions for all subsequent playback events (regardless if DOSBox cached them or not). These games as-programmed won't query the TOC again. This is the majority of games.

Some games are pre-programmed with their CDROM's track positions (or hardcoded), and some even go a step further and compare their expected positions to those queried from the current CDROM - as a form of copy protection (Destruction Derby).

Other games, like Jazz Jackrabbit, perform many checks after every playback event: asking MSCDEX where the current read position is at, asking MSCDEX if the CDROM had been changed/cycled, and, regardless if the tray was cycled or not, requerying the CDROM's TOC (which DOSBox does cache for BIN/CUE and ISO/AUDIO-FILE/CUE).

DOSBox currently doesn't have a "cycle CDROM" function that would mimic a hardware tray cycle for the same CDROM drive letter, and thus flush and regenerate the active TOC. If it did, you could hot-swap audio files of different length or change the CUE and, assuming your game behaves like Jazz Jackrabbit, achieve correct playback of tracks after the swap.

If however the game is like the first two types that don't requery the TOC, then your only option is to hot swap a BIN of identical track layout (but with different audio content) to ensure tracks still play from their starting positions.

Essentially yes; games eventually started storing large volumes of PCM music, effects, and speech in files instead of being limited to CD Red Book audio tracks. This allowed them to store more content at lower bit depths, lower frequencies, and single-channel. It allowed for "fat installs" to HDD where seek latency is orders of magnitude better than CDROM. It also let them play and mix multiple audio tracks simultaneously (ie: music + speech), where as previously they might be held as separate Red Book tracks.

krcroft wrote:If however the game is like the first two types that don't requery the TOC, then your only option is to hot swap a BIN of identical track layout (but with different audio content) to ensure tracks still play from their starting positions.

Thank you very much for the detailed answer. I checked HoMM 2 behavior with separate OGG tracks (from GOG distributive) and it looks like the game query the table of contents only once.

I've got Tomb Raider setup with a file that allows me to choose between the regular version, unfinished business, the regular version w/ 3dfx, and unfinished business w/ 3dfx.

When running through ECE, all versions work except the base Tomb Raider 3DFX (Unfinished Business 3DFX works fine). If I run Tomb Raider 3DFX, the game starts (eidos/core logos), 3dfx splash screen, then main menu. When I choose laura's house or the game, the screen goes to black and dosbox closes.

What's odd, is if I run the exact same files with DAUM, the game works. It just stutters like crazy. So it has to be somewithing with the way ECE and my files are getting along.

edit: as I was typing this, I changed my output from direct3d to opengl, and then suddenly the game worked. I hadn't thought to try this since the expansion pack worked fine under direct3d. It seems overlay and surface work as well.

Is that something specific to this game? I haven't had that issue with other 3dfx games.

Hello Yesterplay80, I'm sorry to bother you again. I searched for a bit and found this small patch: viewtopic.php?f=32&t=38187#p341728. It looks like this patch brings support for separate sound files (not just OGG) to the DOSBox. If I understand correctly, in the current implementation, the problem of playing separate audio tracks is the incorrect operation of the "Sound_Seek" SDL function (which this patch replaces with the "Sound_GetDuration" function). Tell me please what do you think about including this patch in the DOSBox ECE? Thanks.

P.S. I know that support ot the ISO/wav_mp3_etc/CUE format is implemented in DOSBox-X, but I vastly prefer the ECE because of its non-redundancy and absence of bells and whistles.

AlexRK wrote:Hello Yesterplay80, I'm sorry to bother you again. I searched for a bit and found this small patch: viewtopic.php?f=32&t=38187#p341728. It looks like this patch brings support for separate sound files (not just OGG) to the DOSBox. If I understand correctly, in the current implementation, the problem of playing separate audio tracks is the incorrect operation of the "Sound_Seek" SDL function (which this patch replaces with the "Sound_GetDuration" function). Tell me please what do you think about including this patch in the DOSBox ECE? Thanks.

P.S. I know that support ot the ISO/wav_mp3_etc/CUE format is implemented in DOSBox-X, but I vastly prefer the ECE because of its non-redundancy and absence of bells and whistles.

Unfortunately SDL_Sound's FLAC and MP3 backends have their own issues beyond the seek and get duration calls. (see here for a similar FLAC attempt that Yesterplay80 added back in 2016 but had be backed out of the ECE build due to issues: viewtopic.php?f=32&t=49999)

You also mentioned keeping dosbox simple and elegant, which this patch does by eliminating the need for libFLAC, libMp321, libVorbis, and libVorbisFile, resulting in a much smaller statically linked DOSBox binary.