Ok, here we go...
If the CAS format is "dead simple", then why did you need to submit anything to better reconstruct the wave?
Precisely because it's dead simple it does not contain information about the gaps between blocks, or the frequency of the pulses. It is a raw bit sequence. You can generate a wav file from it that will work on actual machines, but for a couple of titles like Fire Force that do have a slightly more complicated loading scheme and need the empty spaces between tape blocks.
It is correct to say that it is a "bit dump", in that it is a bit dump of the logical file, but it does not directly translate to a waveform. I know this from experience.
You're wrong here. I've dumped over 330 Dragon titles, and if you translate each bit in the cas file to a waveform, the result is a valid wav file that will load on a real machine, except for some titles as mentioned above.
On top of that, I made several tools to recover and repair damaged Dragon/CoCo tapes and can even show you visually the 1 to 1 correspondence between bits in the cas file and the actual waveforms.
![[Linked Image from k3pi.chickenkiller.com]](https://k3pi.chickenkiller.com/files/dragoncas2.png)
As food for thought, I present to the reader a sample from the XRoar source code, specifically tape.c. The fact that any so-called "tape rewriting" is necessary at all is why CAS is a problematic file format.
Code
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.
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.