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

I'm not sure the rare cases of games that rely on proper MCI_NOTIFY_SUCCESSFUL handling warrants an information topic. I don't think I've run into a single one.

CD audio wrapping solutions in general though, sure.

I don't have much to add, except I think Peixoto's patches is its own implementation and might cover some cases the others don't? I've never used it personally because it requires files to be ripped in a different fashion than all the others.

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.

@ZellSF

The point here is to try and document the reasons why MCI cdaudio no longer functions poperly on modern Windows systems. I am well aware that many games work fine with less than perfect cdaudio emulation.

I also ran some debugger sessions on mcicda.dll to compare the behavior of WinXP to more recent Windows versions. With some breakpoints one can see that on WinXP the loop seems to be working as intended but on later Windows versions there is a sizable part of the code that never gets called due to an unsatisfied JMP condition. I could manually force the notify message with a temporary NOP but that is as far as I could get. There may be some missing logic.

The source code for the Wine implementation of mcicda.dll is available here:
https://github.com/wine-mirror/wine/blob/mast … mcicda/mcicda.c

As can be seen in the comments the Wine team was also aware of the issue:

A design bug in native: the independent CD player called by the MCI has no means to signal end of playing, therefore the MCI not […]
Show full quote

A design bug in native: the independent CD player called by the
MCI has no means to signal end of playing, therefore the MCI
notification is left hanging. MCI_NOTIFY_SUPERSEDED will be
signaled by the next command that has MCI_NOTIFY set (or
MCI_NOTIFY_ABORTED for MCI_PLAY).

Wine team of course aims for as close to native Windows imitation as possible bugs and all. But a custom build of mcicda.dll could be handy. Furthermore older versions of Wine mcicda.dll do not emulate the bug.

I suppose Microsoft might also release their source code for MCI someday seeing as they are into open source nowadays...

I think I was the first who reported this problem to Microsoft more than 13 years ago:
https://social.msdn.microsoft.com/Forums/wind … udiodevelopment

The first response was from an MS developer. Something like this: "Nothing has changed and everything should work the same way. But I will have a look at the problem". Then the thread has never ever been updated by anyone from MS. And at some point the whole thread has become a general topic about anything MCI related so there is no reason to hope anymore 😀

Falcosoft wrote on 2020-08-20, 17:42:

I think I was the first who reported this problem to Microsoft more than 13 years ago:
https://social.msdn.microsoft.com/Forums/wind … udiodevelopment

The first response was from an MS developer. Something like this: "Nothing has changed and everything should work the same way. But I will have a look at the problem". Then the thread has never ever been updated by anyone from MS. And at some point the whole thread has become a general topic about anything MCI related so there is no reason to hope anymore 😀

Complain on the twitters and then send to various news sites. Something like ms broke cd audio and doesn't give a crap, ms becoming apple, etc. Also win 10 worse for games. That should do it

DosFreak wrote on 2020-08-20, 18:09:

Complain on the twitters and then send to various news sites. Something like ms broke cd audio and doesn't give a crap, ms becoming apple, etc. Also win 10 worse for games. That should do it

Emphasis was on 'more than 13 years ago'. It's just a historical anecdote... Yours would have been a bad advice even if sent from the future since twitter did not exist then.

It's still broken is it not? You get the point. Either go through official channels and report the issue correctly or use the hysteria method which appears to be more effective.

DosFreak wrote on 2020-08-20, 18:44:

It's still broken is it not? You get the point. Either go through official channels and report the issue correctly or use the hysteria method which appears to be more effective.

Have you seen the link where I reported the issue then? It was the 'Windows Desktop Pro-Audio Application Development' forum on MSDN led by Larry Osterman who with his team implemented the new Vista audio stack back then. Please , name me the more 'official channel' where it should have been reported to correctly...

It was an important issue for me back then, but time goes on. I tried what I could. I even sent them test programs, but never got a response.

DosFreak wrote on 2020-08-20, 18:44:

It's still broken is it not? You get the point. Either go through official channels and report the issue correctly or use the hysteria method which appears to be more effective.

BTW Please, can we finish this? Don't you feel a little controversial that you (as a forum moderator) are spamming this topic with your irrelevant personal remarks?
(I put this line into new post since I think this post will/should be removed later)

Nothing has been spammed. I can see you getting butthurt for some unknown reason. There were no personal remarks, if you took them that way then that's your problem.

For Vista IIRC there were MS webpages where you could submit issues.
For Windows 10 use the Feedback Hub if no results then use the hysteria method.

DosFreak wrote on 2020-08-20, 19:58:

Nothing has been spammed. I can see you getting butthurt for some unknown reason. There were no personal remarks, if you took them that way then that's your problem.

For Vista IIRC there were MS webpages where you could submit issues.
For Windows 10 use the Feedback Hub if no results then use the hysteria method.

OK, thanks. I really sorry I can't travel back in time since with your valuable help this problem would have been solved easily. In Vista times there were MS webpages. How I wish I had known that. And also that MSDN was just a fake one...

Thank you for the link Falcosoft.

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.

Interstate '76 relies on those queries returning correct state, otherwise, if you tab-out then back in, playback restarts from the beginning instead of resuming. This game starts playback from mission specific track to the last. Status is periodically queried during gameplay and actions are taken as needed.

I suspected the mentioned bug exists in Win9x, I just have no way to verify, so I said "possibly". Is there a PC emulator that lets you mount real CD images, not just ISOs?

UCyborg wrote on 2020-08-22, 06:54:

I suspected the mentioned bug exists in Win9x, I just have no way to verify, so I said "possibly". Is there a PC emulator that lets you mount real CD images, not just ISOs?

I used a physical disc together with PCem and the MCI Command String Tester by Charles Petzold.

Dxwnd's help pages point to a possible hardware difference. E.g. some CD drives supported the returning of a "paused" state. I could not find the MSDN source for this information though.

I would think that pausing happens in software. That is MCI_PAUSE is the same as MCI_STOP with the exception that MCI_PAUSE command also stores the position so that playback can be resumed later. But who knows maybe a hardware pause mode also exists...

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

@ZellSF

The point here is to try and document the reasons why MCI cdaudio no longer functions poperly on modern Windows systems. I am well aware that many games work fine with less than perfect cdaudio emulation.

On the MCI api, when a program calls mciSendCommand, there is the MCI_NOTIFY flag, which means that the MCI device (the cd player in this case) must send a MM_MCINOTIFY message to the program window when the command finishes.
Most games use this message to play a track again after it finishes and keep looping. The problem today is that windows doesn't send this message anymore.

On my system, using virtual clone drive or daemon tools, windows emulates MCI CD playback using the waveout api, but i don't if a MCI driver interface is supported and MCI functions correctly with a real CD drive

Another problem with the windows emulation scheme is that sending the MCI_CLOSE command stops the playback, but it shouldn't. That is why the CD music on shadows of the empire doesn't play at all

Regarding MCI_CLOSE:

On Win9x you could call MCI_CLOSE and the following MCI_PLAY or MCI_STOP would still work. Exception would be if you used the alias in which case you would need to re-open the device with the same alias to gain access to it.

On WinXP things took a turn to the worse as MCI_CLOSE would make it impossible to issue following commands until the device had finished it's previous task. For example if this was MCI_PLAY there would be no way to stop the playback other than ejecting the disc or waiting the track to finish.

On Vista and above they fixed this by making sure MCI_CLOSE would also interrupt the task of the cdaudio device. This was a definite improvement over WinXP but of course not the same behavior as Win9x and therefore breaks compatibility with older software that used MCI_CLOSE after MCI_PLAY.

In terms of cdaudio emulation one can usually ignore the MCI_CLOSE with the possible exception that MCI_CLOSE does reset the time format.