Attached archive of binaries built from maintenance branch of zdoom (4/18/16). Included patches to compile zdoom and openal by mingw32/gcc46/nasm208/dx8. Changes were made to adapt software to Win95. User accepts sole responsibility for use of these unsupported binaries.
The libsndfile v1.0.25 and and mpg123 v1.19 binaries were built from unmodified source code. The libsndfile distribution has instructions for including flac, ogg, and vorbis (configure without largefile support).
Testing in modern Windows and an emulator running Windows 95 OSR2 (with riched20.dll). If testing in an emulator, set display option "rendering interpolation" to off.
The earlier instability in an emulator was likely from inability of the Win95 audio buffer to keep pace with both the midi and sound playback. Alternatively tested with the internal opl midi emulation, but that runs slow and doesn't prevent the issue. However, building binaries with no optimization does avoid the divide by zero and access errors, but zdoom will spontaneously close under audio load or show a midi playback error. Another method was to edit the openal code so that the audio latency is high, and even though it runs relatively more stably, it does lead to high latency under load (probably from the buffer overfilling). This same effect was noted on a forum post I recall where Win98se (a slow cpu along with an atypical sound setup) led to midi playback errors involving memory allocation. This is similar or the same as to what occurred in emulation.
I haven't observed any issues on real hardware. For use in emulation, I would recommend zdoom v220 in PCem for testing against the vanilla game and zdoom mods from 2008 and earlier. A mod like Action Doom 2 will run on that version, but it generally has high system requirements.