CD audio (CD Player / MCICDA) broken on USB CD-ROM drives since the SweetLow USB stack became the base driver library

[iTechMedic]

Since the SweetLow USB 2.0 stack was promoted to the base driver library (v1.0.0 changelog: "SweetLow USB2.0 stack promoted to base driver library"), analog CD audio playback on USB CD-ROM drives no longer works. The Windows CD Player lists the tracks fine, but pressing Play does nothing (the play position never advances and no PLAY command reaches the drive). Digital audio extraction (e.g. Winamp reading the disc via READ CD) works on the same machine, and data discs work normally, this is specific to the MCICDA analog playback path.

On a stock Windows 98 SE install (native Microsoft USB storage stack) on other hardware, the same drive and disc play fine.

Reported by other users as working on releases before the SweetLow stack became the base library. We tested the 1.0.1(a) installer

Wire-level evidence

We captured the SCSI command stream inside the drive (the drive is a USBODE CD-ROM emulator with a built-in command tracer) while pressing Play in CD Player on both systems, same audio disc:

Stock Win98 SE (working):

MODE SENSE(10)  page 0x0E current     5a 00 0e .. 00 18   <- read volume
MODE SENSE(10)  page 0x0E changeable  5a 00 4e .. 00 18
MODE SELECT(10)                       55 10 0e .. 00 18   <- write volume
PLAY AUDIO MSF                        47 00 00 26 13 16 47 0b 0d  <- playback starts
SEEK / PLAY AUDIO MSF ...                                 <- track skips
READ SUB-CHANNEL (0x42) x170                              <- position polling during playback

Win98 QuickInstall (broken):

MODE SENSE(10)  page 0x0E current     5a 00 0e .. 00 1c   x5 in 16 ms
(6 s pause)
SEEK (0x2B)
MODE SENSE(10)  page 0x0E current     5a 00 0e .. 00 1c   x5 again
(nothing further - no MODE SELECT, no PLAY AUDIO of any form, ever)

Every command in the broken capture was accepted by the drive with GOOD status and full data returned, so the device side is answering correctly. The host stack retries the audio-control page read five times, gives up, and never issues MODE SELECT or PLAY AUDIO MSF. It looks like the MCICDA/CDVSD analog-play path doesn't survive the translation into the SweetLow (Windows 2000 SP4-derived) storage stack, while the data path does.

Decoded (plain text) and raw trace captures attached. Happy to run further captures if that helps debugging.

usbode-cdaudio-traces.zip

[oerg866]

Best bug report so far :) I will investigate it as soon as I can, but it may take a while as I'm busy with other things. Thanks for your help!

…

On Sun, Jul 19, 2026, 19:56 David Hauf ***@***.***> wrote: *iTechMedic* created an issue (oerg866/win98-quickinstall#151) <#151> Since the SweetLow USB 2.0 stack was promoted to the base driver library (v1.0.0 changelog: "SweetLow USB2.0 stack promoted to base driver library"), analog CD audio playback on USB CD-ROM drives no longer works. The Windows CD Player lists the tracks fine, but pressing Play does nothing (the play position never advances and no PLAY command reaches the drive). Digital audio extraction (e.g. Winamp reading the disc via READ CD) works on the same machine, and data discs work normally, this is specific to the MCICDA analog playback path. On a stock Windows 98 SE install (native Microsoft USB storage stack) on other hardware, the same drive and disc play fine. Reported by other users as working on releases before the SweetLow stack became the base library. We tested the 1.0.1(a) installer Wire-level evidence We captured the SCSI command stream inside the drive (the drive is a USBODE CD-ROM emulator with a built-in command tracer) while pressing Play in CD Player on both systems, same audio disc: *Stock Win98 SE (working):* MODE SENSE(10) page 0x0E current 5a 00 0e .. 00 18 <- read volume MODE SENSE(10) page 0x0E changeable 5a 00 4e .. 00 18 MODE SELECT(10) 55 10 0e .. 00 18 <- write volume PLAY AUDIO MSF 47 00 00 26 13 16 47 0b 0d <- playback starts SEEK / PLAY AUDIO MSF ... <- track skips READ SUB-CHANNEL (0x42) x170 <- position polling during playback *Win98 QuickInstall (broken):* MODE SENSE(10) page 0x0E current 5a 00 0e .. 00 1c x5 in 16 ms (6 s pause) SEEK (0x2B) MODE SENSE(10) page 0x0E current 5a 00 0e .. 00 1c x5 again (nothing further - no MODE SELECT, no PLAY AUDIO of any form, ever) Every command in the broken capture was accepted by the drive with GOOD status and full data returned, so the device side is answering correctly. The host stack retries the audio-control page read five times, gives up, and never issues MODE SELECT or PLAY AUDIO MSF. It looks like the MCICDA/CDVSD analog-play path doesn't survive the translation into the SweetLow (Windows 2000 SP4-derived) storage stack, while the data path does. Decoded (plain text) and raw trace captures attached. Happy to run further captures if that helps debugging. usbode-cdaudio-traces.zip <https://github.com/user-attachments/files/30169074/usbode-cdaudio-traces.zip> — Reply to this email directly, view it on GitHub <#151?email_source=notifications&email_token=AAISOPKOQLXLOCNTJEIVXTT5FUDTRA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBZGIZTOOBQHA4DJJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAISOPIWCFO7R4ZWCHSJYML5FUDTRAVCNFSNUABFKJSXA33TNF2G64TZHM2TQNJZGI4DOMRQHNEXG43VMU5TIOJSGM3TQMBYHA2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAISOPLBL7P3Y5QDS4DRROD5FUDTRA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBZGIZTOOBQHA4DJJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAISOPN36MY6V5OGAVTDTIT5FUDTRA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBZGIZTOOBQHA4DJJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LordOfMice]

1. What USBNTMAP.SYS is used? If patched then try to take original from ME for test (check this first).
2. Does this emulator work in Windows XP/2000 (in analog mode, of course)?

[iTechMedic]

Tested both.

For USBNTMAP.SYS, instead of isolating that single file I reverted the whole USB driver set on the QI install back to the original Windows 98 files in place of the SweetLow patched set that QI bundles. I did not need to pull anything from a Windows ME install; the stock Windows 98 files were enough. With those original files in place, analog CD audio through CD Player worked correctly again. That tells me it is not a Windows 98 versus ME file mismatch. Putting the stock Windows 98 USB stack back in fixes it, which points at the SweetLow patch set itself as the cause of the regression. I am happy to narrow it down to USBNTMAP.SYS specifically if that would help you track it down further.

For Windows XP and 2000, both are confirmed working in stock form. Analog CD Player playback through USBODE works correctly on both, with no patched drivers involved.

So the emulator's SCSI and analog audio handling checks out on every system I have tested it on: retail Windows 98, XP, 2000, and the QI install once I substituted the original Windows 98 USB drivers back in. The failure only shows up with QI's bundled SweetLow patch on Windows 98.

[LordOfMice]

1. There is no such thing as "stock Windows 98 USB stack" for storage devices.
2. You (as usual) misunderstand that SweetLow and LordOfMice is the same entity.
   So please, do what I asked, not what you think I asked.

[iTechMedic]

You are correct on both points, and I misspoke.

What I installed was NUSB 3.6e, which uses Windows ME storage components. Therefore, there is no original Windows 98 version of USBNTMAP.SYS for me to restore. I also did not realize that LordOfMice and SweetLow were the same person, so my description of the driver provenance was incorrect.

I will reinstall Win98QI, identify the version of USBNTMAP.SYS that it includes, extract the original USBNTMAP.SYS from Windows ME installation media, and replace only that file while leaving the rest of the QI installation unchanged. I will report back with both file versions and the test results.

Windows 2000 and Windows XP both work correctly with the emulator in analog mode using their stock drivers, with no patched drivers involved.

Thank you for the corrections and clarification.

[iTechMedic]

I pulled the original USBNTMAP.SYS out of a retail Windows ME disc and compared it to the one in a clean Win98QI install. They're both 7136 bytes and both say version 4.90.3000, so they look the same, but two bytes are actually different. One is just the file checksum. The other is a real code change at offset 0xBD3, where a value got changed from 2 to 0.

I tested it two ways on a clean QI install. Swapping in the original ME file fixes CD audio. And just flipping that one byte back to 2 in QI's own file (leaving everything else alone) also fixes it. So it's definitely that single byte.

I disassembled the spot to see what it's doing. It's in the code that runs when a USB storage device gets plugged in, and it sets a flag on the device. The original ME driver turns this flag on, the patched one turns it off. That flag controls how commands get sent to the device, and with it off, optical drives get treated like plain USB sticks. The CD specific commands (like PLAY AUDIO) never get sent, which is exactly why CD Player says "data or no disc" and you get no sound. My USB traces show the same thing, the drive gets MODE SENSE and SEEK but never a PLAY AUDIO.

My guess is this was done on purpose to make regular USB drives (flash drives, card readers, hard disks) more reliable, since that's what almost everyone is using. The downside is it breaks CD drives, which is what USBODE shows up as.

Since it's literally one byte and the two versions help different people, maybe it'd be worth making it a choice in the installer? Keep the patched one as the default for general USB storage, and offer the unmodified ME version for anyone who wants working CD audio, like USBODE users or folks with real USB optical drives. That way nobody has to pick between them.

Happy to send the files or the diff if you want them.

[LordOfMice]

So it's definitely that single byte.
My guess is this was done on purpose to make regular USB drives (flash drives, card readers, hard disks) more reliable, since that's what almost everyone is using.

Because I'm the author of this patch I definitely know why I did it. So when I asked to test this single byte I did this for problem insulation, not for my curiousity. And yes, this patch done because it resolves conflict with SMARTVSD.

Since it's literally one byte and the two versions help different people, maybe it'd be worth making it a choice in the installer?

With high probability I already know how to do the patch that will fix this problem but OTOH will not bother SMARTVSD. Original USBNTMAP.SYS from ME is too disastrous in this area to be used. Wait one or two days.

But I need to say you thanks right now! You really found WHY MS programmers wrote such code. This code is completely wrong in realisation (and buggy too), but its idea is now understandable.

[oerg866]

Nice job getting to the bottom of this. I eagerly await your patch, thank you both :)

…

On Tue, Jul 21, 2026, 08:27 SweetLow ***@***.***> wrote: *LordOfMice* left a comment (oerg866/win98-quickinstall#151) <#151 (comment)> So it's definitely that single byte. My guess is this was done on purpose to make regular USB drives (flash drives, card readers, hard disks) more reliable, since that's what almost everyone is using. Because I'm the author of this patch I definitely know why I did it. So when I asked to test this single byte I did this for problem insulation, not for my curiousity. And yes, this patch done because it resolves conflict with SMARTVSD. Since it's literally one byte and the two versions help different people, maybe it'd be worth making it a choice in the installer? With high probability I already know how to do the patch that will fix this problem but OTOH will not bother SMARTVSD. Original USBNTMAP.SYS from ME is too disastrous in this area to be used. Wait one or two days. By I need to say you thanks right now! You really found WHY MS programmers wrote such code. This code is completely wrong in realisation (and buggy too), but its idea is now understandable. — Reply to this email directly, view it on GitHub <#151?email_source=notifications&email_token=AAISOPJ3ZGE7VHCE6IWIL6T5F4EOTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBTGA4DGNJQHAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5030835083>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAISOPM7R7RJMSN554ZM3635F4EOTAVCNFSNUABFKJSXA33TNF2G64TZHM2TQNJZGI4DOMRQHNEXG43VMU5TIOJSGM3TQMBYHA2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAISOPK7EI6ZKXZIGJIKJQ35F4EOTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBTGA4DGNJQHAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAISOPMWGA3DRU33UJZQFML5F4EOTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBTGA4DGNJQHAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[iTechMedic]

Thanks for confirming. The SMARTVSD conflict explains it, I could see what the byte was doing but not why anyone would write it that way. Take whatever time you need on the patch, you know that code way better than I do. When you have something to try I'd be happy to test it on real hardware with a USBODE drive. I can throw a couple of regular flash drives at it too if you want to make sure SMARTVSD is still happy. Thanks again!

[LordOfMice]

http://sweetlow.orgfree.com/download/usbcdhlp.zip (copy link directly to browser address line if you will get error on the first attempt)
Copy USBCDHLP.VXD to %windir%\SYSTEM\IOSUBSYS\ and reboot or reconnect drive.
P.S. And use the patched USBNTMAP.SYS for test, of course.

[iTechMedic]

That did the trick. To be safe I started from a clean Win98QI install, left its own patched USBNTMAP.SYS exactly as QI ships it, and the only thing I added was USBCDHLP.VXD in %windir%\SYSTEM\IOSUBSYS. Analog CD audio now works perfectly with USBODE. I also tested a couple of plain flash drives on the same install and they work fine, so nothing regressed on the storage side.

Thank you for turning this around so quickly, and for fixing it without giving up the SMARTVSD side. I will update the USBODE README to point people at the helper.

One more question. Would you be willing to let us distribute USBCDHLP.VXD along with USBODE, credited to you with a link to your site? It would save Windows 98 users having to track it down separately. If you would rather it stayed on your own site only, that is no problem at all, we will point people to your page instead.

[iTechMedic]

I need to correct my last message, I spoke too soon about flash drives.

They work normally at first. If I leave one plugged in, the machine eventually bluescreens. The timing is not consistent, sometimes a couple of minutes, sometimes longer, with no set interval. Once it starts happening though, it crashes again almost immediately every time until I unplug the drive.

USBODE turns out not to be involved at all. I unplugged it completely and still reproduced this with nothing but a flash drive attached, and I tried a couple of different drives with the same result.

An exception 0E has occurred at 0028:00000009 in VxD ---.
This was called from 0028:C181830C in VxD CDVSD(03) + 0000234C.

Removing USBCDHLP.VXD stops it. Worth noting that renaming the file in place was not enough, it kept loading and kept crashing. Only deleting it outright from IOSUBSYS made it stop. Since deleting it I have restarted several times and plugged in a few different drives with no crashes at all.

In the failing configuration there is no USB CD device in the machine at all, so USBCDHLP.VXD should have nothing to act on. That makes me wonder whether the ATAPI bit is being applied to USB storage devices generally rather than only to the ones reporting as CD-ROM, with CDVSD then picking them up as CD devices and following a path that was never initialised for them. That is a guess and you will know far better than I do.

CD audio itself does still work with the driver installed, so this looks like a question of which devices the bit gets applied to rather than anything wrong with the approach.