C1 Interleaving : to delay or not to delay ?

I've got a problem with the CIRC process as described in this picture : http://www.ee.washington.edu/consele...dio2/95x74.gif

With a process too long to explain here (wait for my webpage), I got a real life descrambling example, but there is no sign of the "Delay of one symbol" showed in that picture, just after the C1 encoder, in it. Is it possible that it doesn't exists ?

EDIT : oops, I assumed it was a "delay of one frame"... What it is meant to be, obviously.

Also, in frames with 5 bad symbols, the fact that some of the bad symbols are parity bytes doesn't seem to prevent the correction of the other audio symbols, that are less than 5 in this case, but in a frame suffering all the same a total of 5 bad symbols.

For the time being, I'm trying to match theory and practice. Do you think the two pieces of theory above can be correct ?

I found two pages where it is called "odd even delay", with one examlple showing that 1,2,3,4,5,6, for example, becomes 2,1,4,3,6,5.
In this case, the picture is wrong, either half of the symbols are delayed by two symbols, either (more accurate) half of them have a 1 symbol delay (as shown), but the other half have also a -1 symbol delay, otherwise, there would be two symbols at the same place.

More confusing, http://www.ee.washington.edu/consele...udio2/95x7.htm speaks about an odd-even delay of one block instead of one symbol !

It must be an odd-even swapping of the symbols, like with the numbers above, isn't it ?

This is what Mode2CDMaker code does:

At first, the byte order is swapped, as in 1,2,3,4,5,6 => 2,1,4,3,6,5. These bytes form F1 frames (after scrambling in case of data). And these F1-frames are fed into the picture you linked.

That's yet another result !!!

If the odd-even symbols are swapped before C2 encoding, the interleaving between C2 and C1, that spreads the data every 4 frames, will not scatter the same symbols in the same frames. In this case, is there still the strange "delay of one symbol" (or rather odd even swapping of symbols (in the picture), or frames (in the text)) at the end, after the C1 encoding, or is it replaced by this F1-frame byte order swapping ?

Are there many other CIRCs around ?

I guess that all CIRCs are the same, and that different "pictures" are just simplified in different ways...

ECMA-130 page 16:
Page 35 clearly says that F1 frames are fed into the CIRC encoder. So the swapping of each 2 bytes is not part of the circ encoder.
The same pages says something like "delay of 2 bytes", but this doesn't make sense to me. It seems to be a delay of 2 F1 frames.

Maybe there is some misunderstanding, I'm working on audio, not data. In the picture linked, the audio data appears at the extreme left, unprocessed.
What causes me headaches is the "delay of one symbol" at the end of the CIRC encoder, not before it.
According to error pattern I got, it is not a delay of one block, as stated in the text http://www.ee.washington.edu/consele...udio2/95x7.htm , so I assume it is one symbol, and that it is an odd even swap. Anyway, the delay showed in the picture (http://www.ee.washington.edu/consele...dio2/95x74.gif) is impossible. If Symbol N is delayed by 1 symbol, and Symbol N+1 is not delayed, there will be a big problem ! Also, the block (frame) delays showed in the last column, just before the symbol number are wrong, since the symbol delay was taken for a frame.

I'm quite OK with this, but I'm still frustated, because my goal was to generate the theoretical audio pattern of a 16 frames burst error and show that it was the same as the experimental one, and I end up correcting the theory using my experimental results

The only difference between data and audio is that audio is not scrambled. I've had a short glance onto the text and realized that this doesn't suffice...I will read it slowly again

OK, they indeed speak about bytes...but this document looks odd to me. If this interleaving took place on byte-level, then a badly written weak sector could never render the sector before and the sector after it unreadable.

It claims that C1 error correction data is generator before C2, but this would require that C2 error correction is performed before C1...

---

Last edited by alexnoe; 20-10-2002 at 22:53.

Yes, I've noticed it too.
Following BobHere's link (http://www.digital-inn.de/showthread.php?threadid=16259 ), I downloaded ECMA-130. It's not better.
All delays are said to be in f1 frames time in the text, but shown as byte in the pictures. The word "time" itself is unclear, we don't know if the delays are 24, 28, then 32 bytes, the frame time staying the same, or always 24 bytes, the bitrate staying the same.

I'll simulate burst errors for all possibilities and see if one matches exactly the experiment.

Thank you very much for your comments so far.