Originally Posted by robcfg
I fail to see how a specific emulator implementation is a problem of the format. MAME supports cas files and doesn't have a 'tape rewriting' option.

You're right - MAME doesn't have an option to rewrite the tape; it does it all the time:
https://github.com/mamedev/mame/blob/master/src/lib/formats/coco_cas.cpp

Originally Posted by robcfg
In a nutshell, the Dragon/CoCo CAS format (and it's important that is the file format for these machines, as other machines also use the CAS extension for their formats, but are completely different files) is barely a format because it's a 1 to 1 bit dump and nothing more. It wasn't designed with reconstruction of the original wave in mind, even though you can create a functional wave from it in a majority of cases.

I suppose this is precisely the point I was trying to make. Any emulator trying to simultaneously trying to accurately emulate the hardware, and be compatible with the CAS file format has to apply a set of gymnastics and heuristics to (in the case of reading the format) generate an accurate waveform, or (in the case of emitting the format) parsing the waveform into bit pulses. Or one can "cheat" and patch the ROMs - but this is an unacceptable solution given MAME's goals. Admittedly, its been a while (e.g. - ~18 years) since I've sampled CAS files from the wild to gauge how many of them actually needed such processing; my recollection is that postprocessing was necessary much more often than you describe.

I call this nightmarish; not because of some fiendish complexity but rather the amount of heuristics that are involved.

It would be an interesting exercise to try to grab a large amount of CAS files from www.colorcomputerarchive.com, and see how many of them fail to load if one changes coco_cas.cpp to interpret the CAS format as a straight series of bit pulses. Any takers?

And if the CAS files that you've dumped don't need this processing, well my hat is off to you.