DOS ain't dead

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!

Does it have the jitter correction feature?

---
DOS-u-akbar!

> 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!

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!

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