CIRC encoding

vbimport

#1

hello

could anyone please clarify?
when burning cd, does it depend on drive (offset) and/or this cd how bytes are passed to CIRC and hence in form of pits/lands align on track?
if it does, is sample a smallest step?

TIA


#2

Welcome to CD Freaks, chemabus :slight_smile:

This is a bit advanced for the Newbie forum, so I’ve transferred it to the Optical Storage Technical Discussions forum.


#3

thank you very much, imkidd57!
i’ll try to explain my question more thoroughly

ECMA-130:
16. F1-Frames
Each Scrambled Sector shall be mapped onto a series of consecutive frames. Each frame consists of 24 8-bit bytes,
numbered from 0 to 23. Byte 0 of the Sector shall be placed in byte 4n of a frame, where n is 0, 1, 2, 3, 4 or 5.
Consecutive bytes of the Sector are placed in consecutive bytes of the frames. Byte 2 351 of a Sector is immediately
followed by byte 0 of the next Sector.

so, if i understand it correctly, this is a part responsible for ‘offset’. step is a sample.
so if byte 0 of sector is placed in byte 0 of frame on one drive, and in byte 1 of frame on another drive, both cds would look the same on sector level but way different on physical. and so there ar 5 possibilities. if you pad data by 4 bytes on 1st drive, you’d get aligment similar to the 2nd (ignoring fact that lands=pits and dsv, if only byte sequence matters). padded by 20 more bytes, sequence would be like initialy again.
also position of 1st control byte in section of f3 frames contributes to offset, but does not change byte sequence, because it takes place after circ.

could somebody please confirm, is this correct?
if it’s correct, this sequence, when burning on same drive, would it be always the same if similar cds are used? does cds affect it at all?


#4

Welcome to cdfreaks chemabus.

Ops, not sure if anyone can understand that, but perhaps I can clarify some things…

The quote taken is from the Yellow Book spec equivalent, and basically means is from CD-ROM spec equivalent.

For anyone who doesn’t know yet, a small frame is the physical sector of CDs, i.e. we are looking at a lower level than the logical sector that is normally seen on the PC (2448 bytes per sector).

A small frame layout is like this:

1 synchronisation pattern +
1 byte of sub-channel +
12 bytes of main-channel +
4 bytes of C2 parity +
12 bytes of main-channel +
4 bytes of C1 parity

As you can see a small frame contains a total of 12+12 = 24 bytes of main-channel data. Main-channel is the 2352 bytes per sector part that we see on the PC.

Offset - you’re referring to the read or write offset that we get when reading or writing a CD. A popular subject upon EAC and dBpoweramp users :).

  1. F1-Frames
    Each Scrambled Sector shall be mapped onto a series of consecutive frames. Each frame consists of 24 8-bit bytes, numbered from 0 to 23. Byte 0 of the Sector shall be placed in byte 4n of a frame, where n is 0, 1, 2, 3, 4 or 5. Consecutive bytes of the Sector are placed in consecutive bytes of the frames. Byte 2 351 of a Sector is immediately followed by byte 0 of the next Sector.

What I understand from this is that this allows the writing of a CD-ROM disc track to start at any of the 6 position choices.

By step you mean unit?
The allowable start positions are in units of 4n (as stated), which is same as CD audio sample units (1 stereo sample = 4 bytes). Since n are only of 6 numbers (as stated) the possible start byte positions are:

40, 41, 42, 43, 44, 45 or
0, 4, 8, 12, 16, 20

@chemabus, you wanted to give example of the first 2 start positions: 0 & 4. Yes, padding by 4 bytes of the 1st example would yield the same as the 2nd.

From my understanding of above quote, only the first byte of the track is affected and rest of bytes of the track are all consecutive. So your idea of padding 20 bytes to start position 4 (2nd example) wouldn’t yield the same as position 0 (1st example). It would instead be position 0 of the next frame - which is a total offset of 24 and not 0.

It is also important to mention that the above only applies to CD-ROM tracks or sectors.

I should also mention that a drive reading CD-ROM sectors will search for and align the data found in the sync and address (sync header) in the 2352 bytes per sector part (main-channel), so the offset is always 0 when looking at the logical level.

Contrast this to CD audio tracks - they don’t have such sync header, and so when a drive read these tracks they search and align to the address found in the sub-channel, but sadly they also introduce an arbitrary but constant offset between main-channel and sub-channel (the so called drive offset).


#5

thank you a lot, Truman for explanation.
and i’ve reread what i have posted, and there was errors with numbers, i’m very sorry.

what i was looking for is the way to recreate byte aligment (stream) from the surface of cd, maybe in software. i thought how to reverse process of decoding lands/pits but got lost somewhere.

so how i understand it now:

  1. laser picks up Sync Header (synchronisation pattern) and knows it’s a new Channel Frame.
  2. Channel Frames are scanned until Control (sub-channel) byte in one Channel Frame with EFM patern ‘00100000000001’ (SYNC 0) is followed with Control byte ‘00000000010010’ (SYNC 1) in the next Channel Frame. this way start of Section is determined.
  3. Section consists of 98 F3-Frames. for each Frame bytes are converted 14->8, Control bytes are separated (F3->F2). each Frame is sent to CIRC decoder (F2-F1).
  4. Frame bytes are swapped.
    5a. Section=Sector (98*24=2352) for an Audio CD.
    5b. assuming it’s CD-ROM (data), from Sector Sync field it’s possible to determine offset. offset 4…20 bytes (1…5 samples) represent mapping in F1-Frames different from n=0. offset unit of 24 bytes represent F3-Frame Section’s asynchronism from Sector.

so if ther’s given stream of data on some part of cd surface, i thought - what would affect it (if anything), would it be possible to recreate it?

i think i understand now. the whole cd stream would be about the same only if data enters CIRC exactly the same way.
but if it’s only a small section of cd, that’s of consern. with a large homogeneous buffers on the both sides of this stream? wouldn’t it be, that only this change by a sample from 0 to 5 affect it?
so when entering CIRC from sample 0, 6, 12… stream would change slightly at the start and the end of this buffer, but mostly data pattern remains the same?


#6

Hi themabus, I hope it’s not too late.

when burning cd, does it depend on drive (offset) and/or this cd how bytes are passed to CIRC and hence in form of pits/lands align on track?
if it does, is sample a smallest step?

I guess you’re talking about write offset,
it depends on the drive itself. There shouldn’t
be even 6-sample multiple steps, but if designers
care about write as they care of readout the smallest
step can be the sample or even less (I’ve seen such bad
drives a while ago). Nothing to worry about using a Plexie.

so, if i understand it correctly, this is a part responsible for ‘offset’. step is a sample.
so if byte 0 of sector is placed in byte 0 of frame on one drive, and in byte 1 of frame on another drive, both cds would look the same on sector level but way different on physical. and so there ar 5 possibilities. if you pad data by 4 bytes on 1st drive, you’d get aligment similar to the 2nd (ignoring fact that lands=pits and dsv, if only byte sequence matters). padded by 20 more bytes, sequence would be like initialy again.
also position of 1st control byte in section of f3 frames contributes to offset, but does not change byte sequence, because it takes place after circ.

could somebody please confirm, is this correct?
if it’s correct, this sequence, when burning on same drive, would it be always the same if similar cds are used? does cds affect it at all?

Yes themabus, this is correct, the sequence,
when burning on same drive, it will be the same
even using different CDs, so they don’t affect at all.


#7

thank you a lot! :slight_smile: