Dee-Dee wrote on 2020-08-20, 14:50:

UCyborg wrote on 2020-08-19, 20:08:

There is another bug that exists in all OS from 10 down to XP, possibly on older systems as well. If you pause CD playback via MCI then query its status, you'll get back "stopped" instead of "paused".

DxWnd emulates the bug by default, but has an option to enable proper behavior - "Emulate CD pause capability".

It has worked that way since Win9x so if it is a bug it is a really old one. In any case it seems to have no practical effect since after MCI_PAUSE the music can be resumed from where it left with the following MCI_PLAY command. The fact that the mode says "stopped" instead of really being "paused" may indeed be an oversight but the logic seems to work otherwise.

This problem exists in Grim Fandango and Interstate 76. The music actually stops there, instead of pausing. For Grim Fandango, setting options for MCI Audio in DxWnd doesn't help. It sometimes hold the music then it stops playing anymore.
Another thing I noticed is that some games don't play the next music after 1 is over.

Discrete_BOB_058 wrote on 2020-09-24, 08:20:

For Grim Fandango, setting options for MCI Audio in DxWnd doesn't help. It sometimes hold the music then it stops playing anymore.

The two CD box set I have of Grim Fandango does not have cd music tracks. The music is instead played digitally from files as far as I can tell.

Dee-Dee wrote on 2020-09-24, 12:51:

Discrete_BOB_058 wrote on 2020-09-24, 08:20:

For Grim Fandango, setting options for MCI Audio in DxWnd doesn't help. It sometimes hold the music then it stops playing anymore.

The two CD box set I have of Grim Fandango does not have cd music tracks. The music is instead played digitally from files as far as I can tell.

Strange, the music stops at menu. I decided to turn on the emulate cd pause capability and some other related options in DxWnd. Suprisingly it holds the music but not when you go one further step in menu. The music sometimes glitches and buffers. Not sure why but that MCI setting has effects.

Discrete_BOB_058 wrote on 2020-09-25, 04:31:

Strange, the music stops at menu. I decided to turn on the emulate cd pause capability and some other related options in DxWnd. Suprisingly it holds the music but not when you go one further step in menu. The music sometimes glitches and buffers. Not sure why but that MCI setting has effects.

I tested Grim Fandango and the issue is not related in any way to cdaudio or MCI_PAUSE capability. The game mutes all sounds if you access the main menu (F1) key.

You can fix it by patching the game to v1.1. The patch is available at the ResidualVM web site under "Extras downloads":
https://www.residualvm.org/downloads/

It's basically a timing issue. Running in single core affinity may also help...

Dee-Dee wrote on 2020-09-25, 21:44:

I tested Grim Fandango and the issue is not related in any way to cdaudio or MCI_PAUSE capability. The game mutes all sounds if […]
Show full quote

Discrete_BOB_058 wrote on 2020-09-25, 04:31:

Strange, the music stops at menu. I decided to turn on the emulate cd pause capability and some other related options in DxWnd. Suprisingly it holds the music but not when you go one further step in menu. The music sometimes glitches and buffers. Not sure why but that MCI setting has effects.

I tested Grim Fandango and the issue is not related in any way to cdaudio or MCI_PAUSE capability. The game mutes all sounds if you access the main menu (F1) key.

You can fix it by patching the game to v1.1. The patch is available at the ResidualVM web site under "Extras downloads":
https://www.residualvm.org/downloads/

It's basically a timing issue. Running in single core affinity may also help...

I fixed it, thanks.

Btw I found Midtown Madness and MM2 using CD Audio and MM sound pauses in Pause Menu. MM2 music doesn't work at all but Audio is playable on WMP. I think it has that issue seeing similar MCI_PLAY problem for MM

For those of you who still use real genuine physical CD's to play old games on modern operating systems the cdaudio-wimm project might also be of interest. It aims to restore track repeat on Windows Vista - Windows 10 for games that use music tracks on the CD.

https://github.com/dippy-dipper/cdaudio-winmm

The main benefit here is that you do not need to rip the music from the CD.

I post a feedback today about this bug, but i think that Microsoft will never see it...

I want to use hexen II with CD Audio feature (is GOG version) and i don't want to use Source Port to "fix" it...

FulValBot wrote on 2021-03-02, 09:43:

I post a feedback today about this bug, but i think that Microsoft will never see it...

I want to use hexen II with CD Audio feature (is GOG version) and i don't want to use Source Port to "fix" it...

It is important to distinguish between issues caused by Microsoft's mcicda driver bugs and issues caused by modern re-packgaging of old games into digital distributions.

The original game playing from an original physical disc will have the mcicda bug which causes the music tracks to not repeat.

Digital redistributions from GOG, etc. do not of course have cdaudio tracks but instead use some kind of wrapper to play the music from digital files on the hard drive. For example .mp3 or .ogg files. These wrappers may not be compatible with Windows 10 (this was an issues affecting many older GOG releases) or might be affected by installed audio codecs, etc.

For example the GOG releases may use a plethora of different solutions for cdaudio music emulation. They may use the old _inmm program which modifies the game executables and makes the changes difficult to reverse. They might use a custom winmm wrapper that is renamed to sound.dll. They might even use a heavily modified game executable that implements the music playback in some custom way.

In some cases you may be able to replace the winmm wrapper provided by a GOG release with some other build that may work better. In most cases when dealing with a modern re-release of an old game you are better of using a source port.

Finally I have received reports that the winmm wrapper is not loading on some systems. This is a peculiar thing which I have not been able to reproduce. In theory Windows may be configured to reject local dll files and use system files instead and therefore bypassing any wrappers.

GOG's Hexen II release is also one of their most recent releases and shouldn't really have any issues (certainly doesn't here).

ZellSF wrote on 2021-03-06, 12:41:

GOG's Hexen II release is also one of their most recent releases and shouldn't really have any issues (certainly doesn't here).

Hexen II HAS this problem... this happen when CD is selected in options

They have released a fix, but it doesn't work here... music still doesn't loop with CD selected; this patch has installed _inmm.dll in Hexen II folder but it doesn't work properly here; i don't know why they have included inmm and not winmm

this problem happen with both CD & GOG releases (steam version has only MIDI musics included)

edit: for some reason i see in details section "GOG.com winmm wrapper" but this is _inmm.dll not winmm.dll

GOG's Hexen II release does not have this problem. I have tested this. It must be something wrong with your setup. Are you sure it's playing music through GOG's wrapper (there should be no Hexen II CD in your drive and no winmm.dll file in your Hexen II folder).

_inmm.dll was included with patch "1.11 music fix" released by gog some day's ago

and when i say CD it means that in game options there are MIDI music and CD music, and when you select CD that uses .ogg files that are included in Hexen II folder (i don't have a CD version of game) music will not loop

old 1.11 version has not _inmm.dll included

All I can say is, it should work. There's something specifically on your computer that breaks it. I don't have any guesses as to what.

Dee-Dee wrote on 2021-02-08, 14:28:

For those of you who still use real genuine physical CD's to play old games on modern operating systems the cdaudio-wimm project might also be of interest. It aims to restore track repeat on Windows Vista - Windows 10 for games that use music tracks on the CD.

https://github.com/dippy-dipper/cdaudio-winmm

The main benefit here is that you do not need to rip the music from the CD.

Tested with Pitfall: The Mayan Adventure but didn't work. Still no track loop 🙁

FIXED MUSIC LOOP
Finally fixed music tracks loop and play/pause for Pitfall The Mayan Adventure, and Earthworm Jim SE Win95/98 CD games:
https://github.com/ayuanx/ogg-winmm/issues/12 … ment-1447326685

How to:

• using cdaudio-winmm as suggested by YELLO-belly, renamed as wincd.dll and hex-edited the single occurrence inside the game exe of winmm.dll -> wincd.dll as suggested by ayuanx
• mixed-mode* full CD game image mounted with DAEMON Tools Lite
• running first "Pitfall\mcicda\cdaudioplr.exe" as admin
• running the game with "AdditiveRunAsHighest" MS-ACT shim to enable CD detection (or the game will run without CD support when "RunAsInvoker")

My own shims (MS-ACT available from https://learn.microsoft.com/it-it/windows-har … nstall#adkwin10, install just the first component "Application Compatibility Tools" 8.2MB):

IgnoreMessageBox shim: Parameters:Commandline: "*,Pitfall" (without quotes)

I can finally enjoy these two old Win95-98 CD games as they should on modern Windows 10/11! 😊
Hope the instructions above will help other nostalgic players too!

* mixed-mode: data track01 + audio track02...

I spent the past week figuring out what the actual reason for this is, and this is one of the main threads you can find on google about this issue, I thought I'd answer here. Funnily, like this thread (Fixing CD Audio with source code) I also stumbled upon this via Frogger.

Frogger had another issue, that was creating the device id with mciGetDeviceID in a different thread than it was used, but that's not relevant for the looping issue.

Since Windows Server 2k3 source code has leaked, we can easily look up what's going on under the hood (anyone who wants to work on the WINE project, stop reading here).

mcicda.dll has a function "CD_MCI_Handler" which handles the incoming messages.

This calls an internal "notify" function, which registers a "TimerProc" that runs every 100ms.

This "TimerProc" calls "CDA_drive_status", which returns a status which can be:

DISC_PLAYING, DISC_PAUSED, DISC_READY - at least are these are the ones that "TimerProc" cares about.

If the status is not "DISC_PLAYING", but is "DISC_PAUSED" or "DISC_READY" then it sends an "MCI_NOTIFY_SUCCESSFUL", which our game/program gets and then can restart the track. The issue of course is, that this never happens on Windows Vista.

So let's dig deeper. Windows XP had 3 drivers for reading CDs. cdaudio.sys (not used, gone in Win2k3), redbook.sys (used for audio playback into the xp mixer), and cdrom.sys, used for reading data discs, but also handles the playback related IOCTLs. Windows Vista only has cdrom.sys.

"CDA_drive_status" calls into "CdStatus", which sends the "IOCTL_CDROM_READ_Q_CHANNEL" with format "IOCTL_CDROM_CURRENT_POSITION" to the cdrom driver (redbook on XP). redbook on XP properly sets an "CurrentPosition.Header.AudioStatus" in a "SUB_Q_CHANNEL_DATA" struct. cdrom.sys does NOT do this.

This AudioStatus is part of the SCSI-2 spec, and is used for *audio playback* from CD drives, which of course we're not doing with our virtual drive or external drive or whatever.

https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-14.html - 14.2.10.1 Sub-Q channel data format

So redbook.sys fixed this up to pretend it's actually playing audio from a CD.

cdrom.sys doesn't fix this up, but instead passes the struct back untouched.

So now "CdStatus" never receives back anything other than "AUDIO_STATUS_NO_STATUS", because we're not actually playing audio as per SCSI-2 spec, and the whole notify logic is broken.

You can see this here: https://github.com/selfrender/Windows-Server- … da/cdio.c#L1497

So as the main post mentions, the solution would probably be keep the last and current position between 2 calls of your own TimerProc, and if it hasn't changed, your track is done and you can send the NOTIFY message yourself ... but I just wanted to know what exactly is happening here.

Vista's mcicda.dll is just a half cooked update (for Vista we have symbols from the MS symbol server), because they did change many other functions, like CdSeek, CdStop, to accomodate the IOCTLs like "IOCTL_CDROM_READ_Q_CHANNEL" being deprecated with Vista, but not CdStatus.