DOS ain't dead - PlayCD, SB16CD and RippCD

Japheth

Germany (South),
30.07.2026, 07:41

PlayCD, SB16CD and RippCD (Announce)

Hello,

I forgot to announce some additions that were done to the old PlayCD tool:

- PlayCD uses the "Play CD" command to render sound; - that is, it expects a existing connection between the CD drive and the sound card. - SB16CD renders sound by reading the audio disk and writing the data into the sound card's sample buffer. Thus it doesn't need a physical connection between CD drive and sound card. Requires the optical device to support "long reads". - RippCD may be used to 'rip' Audio CDs. Emits .cue and .wav files.

https://github.com/Baron-von-Riedesel/PlayCD

For SATA optical devices running in AHCI mode, you'll probably need the preliminary Jemm v5.87 with included JLM AHCICD.DLL - AFAIK it's the only AHCI CD driver for DOS that supports the audio functions.

---
MS-DOS forever!

Laaca

Czech republic,
30.07.2026, 09:50

@ Japheth

PlayCD, SB16CD and RippCD

Post reply

Does it have the jitter correction feature?

---
DOS-u-akbar!

Japheth

Germany (South),
30.07.2026, 10:06

@ Laaca

PlayCD, SB16CD and RippCD

Post reply

> Does it have the jitter correction feature?

By using the word the you do signal that you mean a specific "jitter correction feature" - I have no idea which one.

Generally, tool SB16CD uses a triple buffer for sound output and a 1 MB XMS buffer for input. That's no 100% guarantee that everything works smoothly ( there are huge differences on how the devices handle "long reads" ), but my experiences are satisfying so far.

---
MS-DOS forever!

Laaca

Czech republic,
30.07.2026, 23:39

@ Japheth

PlayCD, SB16CD and RippCD

Post reply

I mean similar interpretation of jitter correction like for example in MPXplay.
I don't know the situation with long reads but if you read sector by sector there is not quarranted that the new stream of data will start exactly one byte after previous sector. The laser may be not so accurate.
So the common technique is to read at least two consequent sectors and to look for overlaps.

---
DOS-u-akbar!

Japheth

Germany (South),
31.07.2026, 07:45

@ Laaca

PlayCD, SB16CD and RippCD

Post reply

> ... but if you read sector by sector
> there is not quarranted that the new stream of data will start exactly one
> byte after previous sector. The laser may be not so accurate.
> So the common technique is to read at least two consequent sectors and to
> look for overlaps.

That sounds quite a bit like pure nonsense. Perhaps the term "jitter correction" isn't exactly hard science?

What I can say: long reads are used, that are 2352 bytes per sector ( 98 frames * 24 bytes ), ignoring the extra sub-channel byte - which is pretty useless for CDDA, since the 96 bits [12 bytes] of subchannel Q (the only one defined by the standard ) give no extra information. Reading error statistics ( which might give some info about the disk quality ) isn't implemented.

---
MS-DOS forever!