I have written code that does at least the decoding part (error checking, not error correction yet), and I could probably also provide encoding (this is quite simple).
The main attraction is that one needs to be able to calculate in GF(2^8). Adding is just a XOR, but multiplying is slightly involved; it can be implemented using exponent/logarithm tables for GF(2^8).
Particularly I have a problem with figure C.1 of the EMCA.130 document. It really helps looking at this figure if you read any further.
In a first step half of the bytes from an F1 Frame are feed in Delay Elements.
Then 4 Q Parity Bytes are calculated…
The Question is, if you start Circ encoding, what values are used to claculate the Q Parity bits. Since this is the first F1 Frame for encoding there are no delayed bytes from previous Frames.
Do the delay elements return 0 if there are no previous bytes?
Did I totaly misunderstand the CIRC encoding?
No, you are right. The situation for P-parity is even worse, by the way: you will have to emit P values that depends on data that was from >100 frames ago.
I suspect you are right that you can presume zeros; this is probably one reason why a CD has a “lead-in” area.
In fact, I am in the process of rigging a CD player to get access to the raw channel to answer this kind of questions. I already collected very small samples (0.1 seconds) of raw channel data which has helped me to understand the encoding and helped to verify my CIRC checker; you may want to read the “Offset handling (syncing of audio data vs. Q channel)” and “What makes CD-DA different from CD-ROM” threads to get some info on this work.