Offsets handling (syncing of audio data vs. Q channel)

reddish

Hi all,

I have been reading up on low-level Compact Disc technique and - being somewhat of a hacker - I have hooked up some electronics that capture the analog response signal from an audio CD player's laser unit into a desktop PC (sampled at 50 MHz), in order to understand the fundamentals of the channel encoding - and also to pass final judgement on the quality of digital audio extractor s/w.

Using my neat hardware setup I now have captured a precious 0.1 seconds worth of 588-bit channel data frames from a pristine audio CD, each frame containing, among other things, a subchannel byte and 24 bytes of audio data. As specified in the Red Book standard, the audio data of 6 samples (6x2x16 bits of data) is really spread out over 108 channel consecutive data frames. I can reproduce the CIRC, get the de-interleaved audio data, and also do the Reed-Solomon C1/C2 stuff in software from my analog laser readouts - showing an error-free read, identical to what I get with my Plextor using somewhat more conventional methods. So far, so good.

However, one has to realize that the 108-frame interleave structure of the audio data is quite independent/different from the 98-frame sequence that comprises a 2352-byte sector, which is what one usually thinks of as the smallest addressable amount of audio data (corresponding to 1/75 seconds). The 98-frame sectors structure, in effect, is determined by the Q sub-channel - the subchannel starting with two "special" values of 14 channel bits (SYNC0 and SYNC1), followed by (for the Q channel) 96 bits of info describing the current audio sector (most of the time this gives track/index nr., time since start-of-track, time since start-of-CD, etc.) - as many of you here will know.

Now to my question.

The Q-channel and the audio data channels are interleaved. What I need to know is where to find, in the audio data channel, the first sample of audio data that corresponds to the start of a 2352-byte (98 frame) sector as defined by the Q sub-channel. This one number is, in effect, the last degree of freedom left in my low-level extraction procedure. I would expect the standard (Red Book) to spell out the correspondence of audio and subchannel data.

Over the last months, I have read quite a couple of books on CD technology, and I have also scrutinized the ECMA-130 standard (not the Red Book unfortunately, it's a bit too expensive). None of these seems to provide an answer to this question of the exact synchronisation between the audio data channel and the subcode Q channel.

In fact, I suspect that this may precisely be the reason why many CD players employ a different "offset" value - the standard may simply be inconclusive on this (yikes).

I hope any of the more technically inclined folks around here may be able to shine some light on this issue. It's quite frustrating to be so close to being able to make the perfect extraction procedure, but to leave this little issue dangling.

Best regards,

Sidney ( sidney at jigsaw dot nl)

[[PS. if any of you is a regular at the EAC forum: I posted a similar question over there a couple of days ago - I didn't get a satisfactory response up to now. I hope to be more lucky here]]

blackcheck

hmm... according to mmc5 4.3.2.1 exact frame boundaries do not exist due to the physical interleaving. that'd be a good reason for the sync field used in data sectors

hope i didnt get that wrong :s
aah, stop slapping me spath!

btw welcome aboard!

reddish

Ok, what document does this statement come from, and is it publicly available?

I think the "do not exist" statement is a bit weird, although I could (learn to) live with "have not been properly defined."

It would, after all, be completely possible to define the correspondence between subchannel and audio-channel in an unambiguous way, by saying something like this:

"a 1/75 sec 'audio sector' consists of 98 frames, the start of which is defined by the 588-bit channel frame that has a 14-bit SYNC0 identifier for its subchannel. The MSB of the 16-bit left-channel sample value of the audio sample corresponding to the first 1/44100 second of the audio data stream represented by this audio sector, is to be found N frames prior to the SYNC0 frame corresponding to this audio sector."

That's a lot of words (there would probably be a much easier way to define it), but it /is/ unambiguous.

I would suspect N=108 would be a reasonable (implicit) choice, but I would certainly be happy to find conformation in the Red Book or IEC60908. Does anyone here have either of these standards, and care to look it up?

On a related note: I went looking for the Red Book on the Philips "licensing" site only to find one must sign an NDA when ordering the RB standard. Being a sucker for open standards, I'll be damned if I will ever do that ...

Thanks.

blackcheck

http://www.yates2k.net/cd.html
http://www.t10.org/ftp/t10/drafts/mmc5/mmc5r00.pdf

blackcheck

hmm, a lot of people here (especially me ) would love to hear some details on your neat capturing setup. if you read my thread about gc discs... capturing a frame of these discs would answer all my questions at once and a software dvd frame decoder (which i'm willing to code) would make a nice addition to our homemade tools sticky.

spath

Hi Sidney,

> Using my neat hardware setup I now have captured a precious 0.1 seconds worth
> of 588-bit channel data frames from a pristine audio CD, each frame containing,

Hmm, from the analog signal to the frames you still need some signal
processing, an analog to digital conversion, a slicer and run-length
recognition. How do you do that ?

> The Q-channel and the audio data channels are interleaved. What I need to
> know is where to find, in the audio data channel, the first sample of audio
> data that corresponds to the start of a 2352-byte (98 frame) sector as defined
> by the Q sub-channel.

I'm not sure I understand you question here. In a track audio data start when
the start bit of the P channel goes to 0 and the MIN/SEC/FRM in channel Q are
all 0 (before this is the 2s pause). So the first valid audio sample is the one
just after a SYNC0 subcode in a 588 bits frame which satisfies these 2 conditions.
Did I miss something ?

reddish

I used an oscilloscope to find a sweet spot in the analog signal path of an audio CD player (an old Sanyo - the older the better, for this kind of stuff...) where a pre-filtered and amplified version of the laser readout is available - in this particular player, this is basically a test header marked "EFM" (which provides a good hint to its function - it's the last analog stage of the signal, just prior to entering the digital Fourteen-to-Eight demodulator).

This point is probed and fed into a high-speed AD converter (12 bit res, 50 Msamples/sec) that is hooked to an FPGA. I implemented a flank detector and a run-length encoder in VHDL.

Using this setup, I can capture about 10000 pits/lands in one go. This is about 1/1000 of a second worth of data. What I did was performing 40 of such captures, all hand-triggered to a particular drum beat moment in a song on a pristine CD.

After getting these, I translated the flank/run-lengths into 1's and 0's; after this I wrote a small program to match the 40 slices I got in this way (basically, this is the dna sequencing problem, for just 2 bases). This got me a sequence of 1/0's corresponding to cleaned-up pits and lands.

From this point on, I implemented the CIRC decoder circuitry with all delays, interleaving, and Reed-Solomon decoding, which enables me to reproduce audio samples, error checking syndromes, and the subchannel stuff. Back in college I had a few courses in coding theory and algebra, which allows me to understand that kind of stuff (I'm a software engineer by training, with a knack for hardware and maths - this helps!).

That is basically it. I am planning on writing some web pages on the details of this when I'm done; for now, look at: http://ch.twi.tudelft.nl/~sidney/fpga/sanyo.jpg for the rigged CD player (the green wire connects to the EFM header) and http://ch.twi.tudelft.nl/~sidney/fpga/fpga.jpg which shows the FPGA development board and the fast AD/DA daughterboard sitting on top.

From what I am seeing, this is not completely accurate. When looking at combined audio/subchannel rips I make with my Plextor using linux/readcd, the P channel is still '1' in the first 1/75 sec of a track. This is consistent with the Q channel which already shows it's in the next track, when the P channel is still 1. This lasts for 98 frames = 1 "audio sector".

Perhaps. As you know, a frame contains 192 bits of audio data.

However, due to the extensive use of delay lines between the C1 and C2 encoder, 6 consecutive samples of audio data do not end up in a single frame; they are "spread out" over 106 consecutive frames as follows:

L0 = data[i-108][ 0]*256 + data[i-105][ 1]
L2 = data[i-100][ 2]*256 + data[i- 97][ 3]
L4 = data[i- 92][ 4]*256 + data[i- 89][ 5]

R0 = data[i- 84][ 6]*256 + data[i- 81][ 7]
R2 = data[i- 76][ 8]*256 + data[i- 73][ 9]
R4 = data[i- 68][10]*256 + data[i- 65][11]

L1 = data[i- 46][16]*256 + data[i- 43][17]
L3 = data[i- 38][18]*256 + data[i- 35][19]
L5 = data[i- 30][20]*256 + data[i- 27][21]

R1 = data[i- 22][22]*256 + data[i- 19][23]
R3 = data[i- 14][24]*256 + data[i- 11][25]
R5 = data[i- 6][26]*256 + data[i- 3][27]

Here, L0...L5 and R0....R5 are consecutive 16-bit audio samples (not yet subjected to 2-complementing to make them signed). data[i][j] are audio data bytes, with i denoting consecutive frames, and 0<=j<=31 denoting any of the audio+reed/solomon data bytes in a frame. data[i][12 to 15] are the inverted Reed-Solomon 'Q' values (C2), data[i][28 to 31] are the inverted Reed-Solomon 'P' values (C1).

I am very sure that the calculations shown above are correct, i.e., this perfectly represents the delay-and-interleave algorithm of the CIRC decoder, for the audio data (frame sync pattern detection, EFM demodulation, and this would be all you need to play-back - assuming an error-free CD). The reason I am sure about this is that this perfectly reconstructs the audio of the 0.1 second sample I got.

As you see from the above reconstruction algorithm, the consecutive audio bytes come from channel frames that are spread over a total 106 frames.

This suggests the question I'm posing, which is this. We can clearly identify channel frames that start at a particular point by looking at the subchannel data; the subchannel provides the notion of "sectors", which are 98 consecutive frames starting with SYNC0/SYNC1 markers, and the Q subchannel provides an absolute time reference. But how, exactly, do we know which audio data correspond to the first channel frame of a sector? There should be 6 consecutive audio frames that correspond, time-wise, to the first frame of a given sector, but since the audio data is spread out over 106 frames, it is not entirely clear how this choice is made. This is the degree-of-freedom that I would like to resolve.

This is quite a difficult thing to explain, but I hope this helps. If it's still not clear I will have to draw some pictures I suppose :^)

Best regards, Sidney

reddish

Thanks blackcheck. I've looked at the stuff in the first link but couldn't find hints that pertain to my problem. The MMC document has an interesting section about audio CD's.

Regards, Sidney

reddish

Ok, I had a look and this concerns DVD's. I am not quite sure that 50 Msamples/sec will be enough to capture the DVD channel encoding nastiness.... What is the channel bandwidth for DVD?

The setup I am using (FPGA, fast AD - see my earlier post) costs about $500 plus many hours of tweaking. I suppose if I had to do it again I would pick some different hardware which would probably bring the cost down to about $200 - ex. an expendable player (I've blown one in the course of all this, so far).

Now my setup isn't currently good for doing streaming captures of, for example, an entire CD (or even DVD). However, I am looking into adding a USB2 port to my setup which should allow 480Mbits/sec streaming captures - which would be ideal to shift as much of the signal analysis as possible to the desktop computer, where things are inherently /a lot/ easier.

One problem I see for DVD's is that the players are simply "too smart" - i.e., they will do much seeking and re-seeking which prevents one from making the kind of clean start-to-end capture one would ideally want.

Old audio CD players are so amazingly stupid, they will happily "play" CD-ROM discs if you feed it with one. This is truly ideal for analysis purposes. I guess if you wanted to do start-to-end captures on a DVD, you would need to lobotomize it a bit, i.e. force it to do a raw start-to-end read at 1x speed. But then, perhaps you can direct it to do this using proper SCSI commands (I never did low-level DVD or CD programming - I completely skipped that level ;-))

Regards, Sidney

spath

> That is basically it. I am planning on writing some web pages
> on the details of this when I'm done

This is really amazing, I would have never thought somebody would build
his own decoder (especially not a software guy ). Don't forget to tell us
when your pages are ready, we will surely add a news item on front page
for this.

> From what I am seeing, this is not completely accurate. When looking
> at combined audio/subchannel rips I make with my Plextor using linux/readcd,
> the P channel is still '1' in the first 1/75 sec of a track.

This is normal, the red book specifies that P channel encoding is one subcode
block delayed versus Q channel. You always have to take this delay into account
when dealing with channels P and Q.

> But how, exactly, do we know which audio data correspond to the first
> channel frame of a sector?

Now I understand what you mean. The red book does not define any such
correspondance between audio samples and subcode blocks, so it's a matter
of interpretation from manufacturers.

blackcheck

capturing a complete dvd would be awesome but that's not what i itend to do. a few ecc frames would be enough. once i figure out whats so special about these discs i guess i can achieve the writing part by modifying a writers firmware.
i dont know the dvd channel bandwith. maybe i should consult a calculator
hmm since usb2 does 480mbit, maybe there are ready-made ad convertors ? if thats still not fast enough i could be possible to temporarly slow down the motor in order to capture a few frames. on the other hand thats something the drive might be to 'intelligent' for....

reddish

Ok, will do. The ultimate end-point I'm aiming at is a low cost setup that can sample at very high rates, and stream the raw analog data into a desktop PC using USB2. From that point onward, I'd like to do all filtering and processing in software. The hardware design and software will be made freely available.

Using this setup it should be possible to make rips that are comparable in quality to rips using a high-end player, but with a very reliable detection of "questionable" sections - at least better than what any drive that I am aware of could do. Furthermore, I think it will be possible to improve on the syndrome-based C1/C2 error detection correction algorithm, in effect trading accuracy for processing power.

The reason I started all this is that I was very much annoyed by the fact that it seemed nigh-impossible to do reproducible rips of CD's using different CD players. Also, linux/cdparanoia would happily rip a CD with no problems found, then half a year later using the same player and the same CD, it would still be perfectly happy with a rip - but it /would/ yield a non-identical file to the first rip; with some inspection showing instances of sample interpolation that were not detected by the cdparanoia software.

For a digital medium, such things are UNACCEPTABLE (excuse me for raising my voice!) This really pissed me off bigtime, and looking around on the web I didn't find a great deal of very deep analysis of what silliness was preventing good reproducible ripping abilities - at that point I decided to bite the bullet and do the analysis myself.

The bottom line: never underestimate a software guy with an axe to grind ;-)

Hmm, ok ... (?) I direly need a RedBook copy I guess, but I'm not doing the NDA thing. I guess I'll just have to flock out the 167 Euros for IEC60908 (grumble). Is anybody aware of a library that carries electronic versions of this? I checked the university library where I live (Delft, Netherlands) and they have quite a bit of IEC stuff, but not this particular one I'm afraid.

It sure looks that way. I think this is a grave omission in the standard. Even if it is that way in Philips's Red Book, the IEC should have never let this slip by in their ratification process. I think I will get IEC60908, and if I find they leave this unspecified there as well, I may submit a formal clarification request on this (assuming they defined such a procedure). Should be interesting.

Regards, Sidney

blackcheck

dvd channel bitrate is 26.16 MHz
http://www.opticaldisc-systems.com/2...VDBASICS78.htm

reddish

Thanks - that's an interesting chart. I've never looked into DVD's all that much, from what I understand the low-level encoding is simpler than with CD's, the designers seem to have made the valid assumption that costs of digital parts are now so low that you can assume a player to handle a filesystem (compared to the low-level processing of the CD). But I can see that this may be interesting, so when I am going to do a hardware redesign, I will make sure that I'll be able to handle the higher bandwidth, other folks will be able to take it from there (my interest is CDs).

As to the bandwidth requirement, with a channel rate of 26 MHz I guess we could settle for something like an 80 Msamples/sec AD converter - however I would prefer to overspecify this by quite a margin. An AD9480 (250 Msamples/sec at 8 bits) looks tempting. Fun thing is that when you're done reverse-engineering CDs and DVDs you could always turn it into an FM radio that can listen to all stations at once - which would be a worthy exercise, I'd say ;-) Also, this may be enough to repeat the same exercise for Blu-Ray later on (anyone know the channel BR for this?).

Regards, Sidney

Truman

Interesting. Something that I was looking to do a while a go but didn't have the skills (or time) to program a FPGA processor. I wanted to apply it to a modern PC CDROM writer or reader in order to analyse the Playstation 1 wobble (actually E+F) signals. Did you know you can just buy an oscilloscope to do this, but I suppose it's for fun and education - which is well justified.

Concerning the EFM header, I think the modern drives still have a similar set of points marked on the board, e.g. the 24x LiteOn and 32x BenQ writers, which I had opened a while a go have them marked, they even had the 4 optical quandrant sensors marked. If I have time I'll take out my digital camera and post a link of the pictures here.

__________________
Truong Hy-Xpert tools -PerfectRip

reddish

The problem with scopes is that well, while a digital scope can take a time series snapshot, these are mostly limited to a certain number of samples (32K--1M is typical from what I saw). If you want high-speed streaming (my end goal) you either have to use a very very very expensive scope, a very expensive AD-card, or do a roll-your-own (as I am trying). Of course, the fun factor is also important and I really learned a lot doing this so far.

This would certainly be interesting. I did consider rigging a CD-ROM player instead of an audio player, but the nice thing about an old audio player is that you can simply press Play and it will do lead-in to lead-out, no questions asked, at 1-speed. CD-ROM players use caching, may try to read things at > 1-speed (lead-in?) an are generally just more complicated. I would be interested to look into this though, as soon as my current setup can do streaming.

Cheers, Sidney

spath

> Using this setup it should be possible to make rips that are comparable in quality to
> rips using a high-end player, but with a very reliable detection of "questionable"
> sections - at least better than what any drive that I am aware of could do.

Your setup obviously gives better observability and reporting than chipsets, but don't
expect to get better extraction quality. Actual chipsets contain lots more logic than
that to handle bad discs.

> Furthermore, I think it will be possible to improve on the syndrome-based C1/C2
> error detection correction algorithm, in effect trading accuracy for processing power.

Two standard improvements are :
1) use multiple consecutive C1/C2 corrections on the same data.
2) use erasure strategy at C1 stage.

> Also, this may be enough to repeat the same exercise for Blu-Ray later on (anyone know the
> channel BR for this?).

66 Mb/s

By the way, DVD-ROM standard is at
http://www.ecma-international.org/pu...s/Ecma-267.htm

reddish

Observability is by far the most important thing for me - one must accept that some errors are not recoverable, but I want to be able to know exactly which samples are "questionable" - which is feedback that even high-quality players aren't able to reliable provide.

Whether I can get better extraction quality I don't know yet, but I think it isn't completely impossible (see below).
What kind of logic are you thinking about (and how could it impact the extraction quality)? Of course there is also the signal tracking, but I am certainly not planning on interfering with that, I will happily piggy-back on the player's built-in hardware for that.

I am not quite sure what you mean by the first one. The algorithm I am thinking about will effectively use a probabilistic error model of the channel (describing burst errors, random errors, and perhaps also an audio content predictor), then find the "maximum likelihood" solution for the channel content based on the channel observation. By expressing an erasure as a time window where no information is available on the channel data, (a superset of) the Reed-Solomon erasure concept can be handled. There is an impressive body of research on this kind of algorithms (it's still an active topic of academic research) so it has good theoretical foundations but also very practical benefits, such as a quantitative measure after analysis about whether the solution found (i.e., the audio data) are "correct"; I happen to do stuff like this for a living so I should be in fairly familiar territory.

This is a much more advanced approach than one that could be implemented in hardware, if only because it will not be able to meet the real-time constraints that a CD player has to ensure smooth play-back. When you drop this constraint you open up the possibility of CPU intensive offline post-processing, which (I think) has the potential to indeed improve on the rather crude but fast C1/C2 Reed-Solomon codes.

So we may disagree on this, and the ball is now in my court to show that I am right ....

Thanks! With 250 Ms/sec we should even be able to readblu-ray then. The future looks bright.

spath

> Observability is by far the most important thing for me - one must accept that some
> errors are not recoverable, but I want to be able to know exactly which samples are
> "questionable" - which is feedback that even high-quality players aren't able to
> reliable provide.

Keep in mind though that what your setup will report is not what is on
the disc and not necessarily what other drives will see either.

> What kind of logic are you thinking about (and how could it impact the extraction
> quality)? Of course there is also the signal tracking, but I am certainly not planning
> on interfering with that, I will happily piggy-back on the player's built-in hardware
> for that.

For instance, the channel data rate is continuously slightly changing,
even in CLV mode. This is why drives use a PLL to track such changes and
make sure that their runlength decoding is always correct. Or reflectivity and
defects can change the amplitude and offset of your analog signal, which is
usually tackled by additional signal processing.

> I am not quite sure what you mean by the first one.

This is a nice property of the CIRC that you can "refine" your data several
times. Consider for instance a C1 frame with 4 errors ; it will be flagged as
an erasure and no correction will occur at C1 stage. Now if at C2 stage only
2 of these errors can be corrected (because there are too many errors in 2
of the 4 C2 frames), this leaves 2 wrong bytes in our original C1 frame.
If you just run again CIRC on these data, the original C1 frame will be
correctable since it now contains only 2 errors, and in turn this can make
some C2 frames correctable.

> The algorithm I am thinking about will effectively use a probabilistic error model
> of the channel (describing burst errors, random errors, and perhaps also an audio
> content predictor), then find the "maximum likelihood" solution for the channel
> content based on the channel observation.

Hmm, this sounds a bit like the Viterbi decoder that Pioneer is using in their
DVD players. Can you elaborate a bit on these algorithms and maybe
post some links ?

reddish

That's true, and that is mostly due to the fact that the signal I am probing has gone through a small set of analog components for filtering and amplification. These sit between the laser pickup signal (a purple wire that can be seen in the rigged CD picture I posted) and the EFM header. Indeed, if I probe the purple wire signal directly, I get a lot of low-frequency jitter; in fact, the EFM-signal can just barely be seen superimposed on a high-amplitude 'carrier wave'.

I think that many CD players will have a header where a cleaned up 'EFM' signal is available, so it's a pretty good compromise. I like the fact that the analog chain takes care of the filtering up to that point (some things are better done using analog components even in this day and age). Very little information that is useful to reconstruct the channel is lost in the process - the information 'shedded' is mostly irrelevant or positively unhelpful - which is why it is filtered out of course.

Ok. I am assuming that the PLL circuitry is working (it is detectible if it isn't - the player loses tracking and I don't get a well-modulated signal). With regards to amplitude/offset correction, this is filtered out prior to the 'EFM' measurement point. Pre-supposing a player that has a nice 'EFM' signal pickup point, I suppose that they it could have different logic levels voltages, but that is easy to correct in software.

Ok, I see what you mean, and this is a good point. In fact there is the (somewhat theretical) possibility of corrections of data bytes that are not even in the same C1 or C2 set, over distances that exceed even the 106-frame C2 distance. I will have to think a bit about what this means for my approach - it can be very advantageous as you show in your sample, and I should be able to use this as well.

Well yes, quite a bit (I hadn't thought about it in this way, but you are right) Viterbi (and convolutional codes in general) tend to spread out the effects of errors over very large sequences of channel symbols, and as such they move away from the block-code concept of local error correction and detection. They also converge on the maximum likelihood estimator for the source channel if I remember correctly (This is from memory, the last time I studied Viterbi and Trellis codes is about 7 years ago).

What I am thinking about certainly has parallels to this, but I like to think of it as a more general framework.
Ok. What I am proposing is to use ideas from the domain known as "diagnostic health management", which is a set of ideas / research area that tries to determine the health mode of a system, based on a model of the system and the observations.

Below are some links to scientific literature. Some of this material takes a bit of math experience to digest (though nothing excessive, a smart undergrad should be able to follow this).

Some articles introducing the problem domain (these are old but rather accessible):
ftp://publications.ai.mit.edu/ai-pub...df/AIM-394.pdf
ftp://publications.ai.mit.edu/ai-pub...df/AIM-380.pdf

The "model based approach" was introduced by De Kleer and Williams ("Diagnosing Multiple Faults", 1992 - unfortunately this is copyrighted so i cannot post it here). Some other articles that cover this:

ftp://publications.ai.mit.edu/ai-pub...df/AIM-739.pdf
ftp://publications.ai.mit.edu/ai-pub...f/AIM-1059.pdf

... If you don't plan to spend the next weeks studying this ;-), allow me to give a simple example to show you a typical (but very simple) example of this approach. This does not apply to CD's, but it should convey the general idea.

*** A five-minute intro to Model Based Health Management ***

Suppose I have an "inverter" that inverts a digital boolean input if it is "healthy". Its behavior (with x input, y output, and h healthy - a boolean) can be described as:

h => (x = !y) { in words: if the inverter is healthy, x and y are each unequal }

Now suppose that I have 3 inverters; I hook them up in such a way that the output of the first one drives the input of both the second and the input of the third one (i.e., inverter #1 has a "fan-out" of 2).

Now suppose I impose a boolean "true" on the input of inverter #1. At the output of inverters #2 and #3, I should also observe a "true". But now suppose I see that I in fact observe both a "false" at inverter #2 and #3's output.

Considering the "health state" of the inverters, and combining their respective health equations, we get the following list of possible health modes of the system:

inv.1 OK inv.2 OK inv.3 OK -- INCONSISTENT with observation
inv.1 OK inv.2 OK inv.3 FAIL -- INCONSISTENT with observation
inv.1 OK inv.2 FAIL inv.3 OK -- INCONSISTENT with observation
inv.1 OK inv.2 FAIL inv.3 FAIL -- CONSISTENT with observation
inv.1 FAIL inv.2 OK inv.3 OK -- CONSISTENT with observation
inv.1 FAIL inv.2 OK inv.3 FAIL -- CONSISTENT with observation
inv.1 FAIL inv.2 FAIL inv.3 OK -- CONSISTENT with observation
inv.1 FAIL inv.2 FAIL inv.3 FAIL -- CONSISTENT with observation

So we have that either of the following five conditions must be true:

inv.1 OK inv.2 FAIL inv.3 FAIL -- CONSISTENT with observation
inv.1 FAIL inv.2 OK inv.3 OK -- CONSISTENT with observation
inv.1 FAIL inv.2 OK inv.3 FAIL -- CONSISTENT with observation
inv.1 FAIL inv.2 FAIL inv.3 OK -- CONSISTENT with observation
inv.1 FAIL inv.2 FAIL inv.3 FAIL -- CONSISTENT with observation

Assuming that all inverters are equally likely to fail, and that their probability failure exceed 0.5, n-ary failures are much more likely than (n+1)-ary failures. In the above list, there is only one fault mode that has just 1 faulty inverter:

inv.1 FAIL inv.2 OK inv.3 OK

So this is probably the correct diagnosis of the observed system.

Note that we can put all this in a probabilistic framework, quantifying the probabilities of health of different variables. This also has close links to information theory as well, e.g. we can quantify the amount of "bits of information" that could be gained by peeking at the output of inverter #1.

This framework can also be applied to signal processing; here, a "diagnosis" could be that a certain sample in the channel domain is not to be trusted. The potential power of this way of looking at systems is really awesome, and although I may be suffering from the "if you have a hammer, everything looks like a nail" syndrome, I truly believe that the CD signal path could provide a textbook example of succesful application of these sort of techniques.

I hope this clears it up a small bit.

regards, Sidney

data_

Hello,
Back to the original question and since interleaving data is not taking place on the Control&Display symbol (a.k.a subchannel byte), you can reconstruct sectors by using the offsets mentioned on your post dated 24-10-04 (which by the way are very correct). If the interpretation problem was coming from the P been '1' on the 1st subcoding block of a track as mentioned on the same post, Spath gave the answer of P been one subcoding block delayed to Q (red book), so, if I am not missing something, case is closed.
You have a very interesting project running. I do work the other side (sector, TOC, and subchannel analysis through ASPI retrieval of data). Do you have a good reference to Reed-Solomon so I can meet you halfway?

data_

reddish

I can reconstruct both the subchannels and the audio channel; the question is: how are they synchronized. This is still unanswered in general. However, I know now what my two Plextors do;

PLEXTOR RULE: the MSB of the first left-channel sample of the time-interval corresponding to a sector is contained in the first frame of that sector. This uniquely determines the Q-channel to audio mapping.

I determined this by using a CD for which I know what the physical channel looks like. The Plextor rule seems sensible, but other CD brands use a different interpretation (in fact, I tried an older Plextor and it synchronizes differently); there seems to be no clear statement in either the Red Book or IEC908.

I am afraid not ... :-(

Yes, I think so too. Next week I hope to receive some more hardware, that will finally allow me to stream the physical channel contents of entire CD's to my desktop system for offline analysis.

Do you want to understand this mathematically, or just be able to reproduce the calculations? I'd be interested to know if you can get to the C1/C2 bytes (8 per frame, 784 per sector) through software readout - can you do that?

Regards, Sidney

data_

MSB of the first left-channel sample is not interleaved according to red book, but I think there should be a 3frames delay... It is a little bit strange you get it without any delays!! Do you make any use of LI to your calculations?


Lets start with the maths!
As for the C1/C2, data is retreived on sector level, so there is no direct access to frames (and C1/C2 as a result). Theoretically though you have access to flags which mark error data through the use of C1/C2 but there is a total mess from one manufacturer to the other...

reddish

You are probably referring to this picture: http://www.ee.washington.edu/consele...dio2/95x74.gif or its evil twin, the CIRC decoder schematic.

This picture does indeed prescribe a three-frame delay for the left channel MSB of the first-of-six samples. However, this picture doesn't have anything to say on the relation between the audio channel and the sub-channel. If there would be a delay-less line drawn here marked "subchannel", the issue would be settled. But there isn't. The exact correspondence between audio and subchannel data isn't specified.


Where did you get the idea that I get by without any delays?

In the algorithm I quoted earlier, the numbers "-108", "-105", ... , "-3" all correspond to delays:

L0(i) = data[i-108][ 0]*256 + data[i-105][ 1]
L2(i) = data[i-100][ 2]*256 + data[i- 97][ 3]
L4(i) = data[i- 92][ 4]*256 + data[i- 89][ 5]

R0(i) = data[i- 84][ 6]*256 + data[i- 81][ 7]
R2(i) = data[i- 76][ 8]*256 + data[i- 73][ 9]
R4(i) = data[i- 68][10]*256 + data[i- 65][11]

L1(i) = data[i- 46][16]*256 + data[i- 43][17]
L3(i) = data[i- 38][18]*256 + data[i- 35][19]
L5(i) = data[i- 30][20]*256 + data[i- 27][21]

R1(i) = data[i- 22][22]*256 + data[i- 19][23]
R3(i) = data[i- 14][24]*256 + data[i- 11][25]
R5(i) = data[i- 6][26]*256 + data[i- 3][27]

However, my problem is that any frame-wise translation in these delay offsets would reproduce the audio stream perfectly - except at start-of-audio-data and end-of-audio-data, due to another sync with the subchannel.

For example, to describe the algorithm for my Plextors the above is more reasonably re-written as:

L0(i) = data[i +0][ 0]*256 + data[i +3][ 1]
L2(i) = data[i +8][ 2]*256 + data[i +11][ 3]
L4(i) = data[i +16][ 4]*256 + data[i +19][ 5]

R0(i) = data[i +24][ 6]*256 + data[i +27][ 7]
R2(i) = data[i +32][ 8]*256 + data[i +35][ 9]
R4(i) = data[i +40][10]*256 + data[i +43][11]

L1(i) = data[i +62][16]*256 + data[i +65][17]
L3(i) = data[i +70][18]*256 + data[i +73][19]
L5(i) = data[i +78][20]*256 + data[i +81][21]

R1(i) = data[i +86][22]*256 + data[i +89][23]
R3(i) = data[i +94][24]*256 + data[i +97][25]
R5(i) = data[i+102][26]*256 + data[i+105][27]

Then, by "LI" I take it you mean "linear interpolation" (?) Then, the answer is no. I am not cutting corners here, that's the point of dropping down to the hardware level.

Ok, I learned the tricks of the trade from the book "Introduction to coding theory" by Raymond Hill (ISBN 0198538030). It presumes a minimal amount of familiarity with elementary maths (polynomials, linear algebra), and takes you to the level where you can understand RS codes - in fact it covers BCH codes that are a superset of RS codes. I don't know your math skill level, if this would be too complicated or too easy I may be able to suggest something else.

Ah. Pity!

Regards, Sidney

data_

...true but this is evil red book



I was referring only to the MSB of the first word of the right channel of a frame, or: L0(i) = data[i +0][ 0]*256 as you would say. I think I am getting the biggest picture of your quest...
LI stands for LeadIn. The encoded pattern in the lead in area could give you a reference point so you can afterwards work based on your offset tables.

Thank you reddish!