PS - It is very possible that this rewriting is not as necessary in the Dragon world. If the Dragon ROM is more efficient and spends less time after the first CAS block is loaded, it is possible that the delays may be less necessary.
I can try converting a CoCo cas file to wav, which creates a wav without delays, and try to load that on a real machine.
As far as I remember, I've done that with the Dragon and works well.
Maybe it works if the rom code stops the motor after the first block and then after processing it, starts the motor again and just takes the data in.
right, any format that doesn't accurately represent delays, or where the files have to tweaked post-conversion to that format, to insert some kind of fake data to simulate those delays isn't fit for purpose IMHO
it's bad enough that most (all?) cassette formats fail to properly represent tape length, so most of the time side a and side b of the same tapes are shown as different lengths, despite being the same amount of cassette tape.
archival formats should not be stripping away delay / spacing / blank are data.
Certainly most these formats don't care about properly representing the tape, but as I said earlier, they weren't designed for that. The interest has been traditionally getting the program to work. For that wav files are the simplest solution (maybe CSW being close, but that already loses some info), but if the original media was flaky then the program becomes unusable even with an accurate representation of the tape.
