A file consists of:
A leader is just 128 bytes of $55 (binary 01010101). There should be no gap at all between the end of the leader and the beginning of the block that follows it. In fact, If the "gap" flag in the filename block is $01, I think there should be no gap at all between any two blocks, with only two exceptions: the gap that precedes the file, and the gap following the filename block. There must be a leader after each of those gaps to re-establish timing. If that gap flag is $FF, then there seems to be a 1/2 second gap and another leader before every data block and before the end-of-file block.
A block contains:
The three different types of blocks contain different amounts of data. A filename block contains fifteen bytes of data; an EOF (end-of-file) block contains no data bytes at all; and a data block may contain anywhere from 0 to 255 bytes, as indicated by the length byte.
The data in a filename block:
I have now verified that bytes are stored least-significant bit first. (Thanks to Simon South for first pointing this out to me).
Each bit is recorded as a single cycle of a sine-wave. The frequency of the wave distinguishes a "0" from a "1" bit. A "1" is a single cycle at 2400 Hz, while a "0" is a single cycle at 1200 Hz. So the average bit rate is about 1500. But this "baud rate" depends on the data; a file containing all 00 bytes would take about twice as long as a file containing all bytes of FF's. (It is not exactly twice as long, because the overhead in each block will contain bytes with both 0's and 1's.)
The CoCo recognizes bits by detecting zero crossings - those places where the sine wave crosses from positive to negative or visa-versa. This means that it is independent of the volume (or loudness) of the signal, except that smaller signals are easier to mess up with noise. It is also independent of inversions - the tape can play the signal back upside-down and the computer won't even notice the difference.
Back to my top-level CoCo page