IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Plextools Pro + Premium undetected errors, Extraction is not secure.
Pio2001
post Feb 21 2005, 00:07
Post #1


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



I've come across errors undetected by Plextools, with a Plextor Premium drive.

Track 1 of the CD is destroyed, there is a hole in the reflective layer. However, track 3, that was extracted looks OK.

Plextools reported 1216 CU errors in sector 65514 (MSF 00:59:72 in track), as well as many other CU errors. Only the 1216 ones in MFS 00:59:72 were not recovered.
Here's the full log : http://perso.numericable.fr/laguill2/pictu...0_23h23m17s.txt

However, the whole wavs suffers from clics all along. Here's an isolated error :

http://perso.numericable.fr/laguill2/pictu...ium_error00.png

No other click less than 32,000 samples away.

Zoom :

http://perso.numericable.fr/laguill2/pictu...ium_error01.png

It is an isolated erroneous sample. It was not interpolated, thus, assuming that the Plextor Premium interpolates, it was undetected by the CIRC stage. It means that it's not Plextools Pro's fault, the problem would have been the same with EAC's C2 detection.

Here is another error :

http://perso.numericable.fr/laguill2/pictu...ium_error02.png

This time, the waveform is unsynchronized, it is a synch error.

All the above are claimed by Plextools to have been properly recovered.

The track plays flawlessly in my standalone CD Player.
I'll perform more trials, with EAC + the Premium drive, and with the standalone player, to try to get it right.
Go to the top of the page
+Quote Post
westgroveg
post Feb 21 2005, 00:53
Post #2





Group: Members
Posts: 1235
Joined: 5-October 01
Member No.: 220



Interesting smile.gif .

This post has been edited by westgroveg: Feb 21 2005, 01:05
Go to the top of the page
+Quote Post
AtaqueEG
post Feb 21 2005, 01:44
Post #3





Group: Members (Donating)
Posts: 1336
Joined: 18-November 01
From: Celaya, Guanajuato
Member No.: 478



Damn it!
I was about to buy a Plextor!
Please keep us posted, Pio2001!


--------------------
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseņas de Rock en Espaņol: www.estadogeneral.com
Go to the top of the page
+Quote Post
p0wder
post Feb 21 2005, 02:46
Post #4





Group: Members
Posts: 347
Joined: 22-July 02
From: USA
Member No.: 2721



Thanks for the test pio2k1!
Go to the top of the page
+Quote Post
westgroveg
post Feb 21 2005, 03:38
Post #5





Group: Members
Posts: 1235
Joined: 5-October 01
Member No.: 220



QUOTE (AtaqueEG @ Feb 21 2005, 12:44 PM)
Damn it!
I was about to buy a Plextor!
Please keep us posted, Pio2001!
*

This is no reason not to buy a Plextor, lets not start saying that PlexTools is insecure or the drives are inaccurate, it's obviously just a hardware bug concerning 1 particular model.
Go to the top of the page
+Quote Post
Pio2001
post Feb 21 2005, 12:46
Post #6


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



The "C2 accuracy" being inferior to 100% is rather the rule than the exception. In fact, when the drive skips and produce synch errors, it is difficult to detect all of them. C2 accuracy analyzers can't always distinguish between CU errors and synch errors in a ripped file.
And while C2 accuracy can reach 100%, synch error detection accuracy seems far behind.
Go to the top of the page
+Quote Post
bobwood
post Feb 22 2005, 17:23
Post #7





Group: Members
Posts: 23
Joined: 10-April 04
Member No.: 13372



If I understand the original post correctly, Plextools did report 1216 errors for track 3. The problem is in the number of places in the track where there were errors and the exact location of those errors. If I only want a binary result, track extracted Ok or track not extracted OK, it looks like Plextools is reporting correctly. Am I missing something?

I tried an experiment using my Plextor Premium, Plextools Pro, and a CD that I new would get errors if I turned off retries but would extract OK if I allowed retries, mode 5.

With no retries, mode 1, there were 91871 errors reading track 1, no errors on tracks 2-4. The interesting part is that Plextools reported "4 track(s) successfully extracted" at the end of the log. There were 4 tracks on the CD so to me that means all tracks successfully extracted. How could all track be successfully extracted if one had 91871 errors? What does it take to make an unsuccessful extraction?

I then tried extracting just track 1 with mode 5. This time Plextools did slow the drive down and retry. The log shows all errors were recovered. This was pretty much what I expected except that the drive did not speed back up after it passed the bad section of the track. It took 3:36 to extract the track.

The next step was to extract all 4 tracks with mode 5. This time the drive did speed up after the bad section was extracted. Only 56 sec to extract track 1. The log shows several attempts to recover from CU errors. They did not appear to work. The log then shows speed being reduced, then speed being increased then the end of the track. There is no mention in the log of what retries were done while the drive was slowed down. There were no errors reported at the end of the track.

If I compare the .wav files from the 2nd and 3rd test, they are the same.

It looks to me like I can trust Plextools for a good/not good report, as long as I look at the individual track reports, but not the details.
Go to the top of the page
+Quote Post
JeanLuc
post Feb 22 2005, 18:12
Post #8





Group: Members
Posts: 1311
Joined: 4-June 02
From: Cologne, Germany
Member No.: 2213



Now I know why I always extract twice with two different Plextor drives when I'm using Plextools and perform an EAC wav compare afterwards. biggrin.gif


--------------------
The name was Plex The Ripper, not Jack The Ripper
Go to the top of the page
+Quote Post
AtaqueEG
post Feb 22 2005, 19:38
Post #9





Group: Members (Donating)
Posts: 1336
Joined: 18-November 01
From: Celaya, Guanajuato
Member No.: 478



QUOTE (JeanLuc @ Feb 22 2005, 11:12 AM)
Now I know why I always extract twice with two different Plextor drives when I'm using Plextools and perform an EAC wav compare afterwards. biggrin.gif
*


ALWAYS?!?!

rolleyes.gif

Hey Jean-Luc, got that 716 already? Could you please try it with your hardest CD and post results? I am still making up my mind on it. I need a new drive and it is the front runner so far, but not if it is not going to do that much better than my Litey.


--------------------
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseņas de Rock en Espaņol: www.estadogeneral.com
Go to the top of the page
+Quote Post
Pio2001
post Feb 22 2005, 21:36
Post #10


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



QUOTE (bobwood @ Feb 22 2005, 06:23 PM)
If I understand the original post correctly, Plextools did report 1216 errors for track 3.  The problem is in the number of places in the track where there were errors and the exact location of those errors.  If I only want a binary result, track extracted Ok or track not extracted OK, it looks like Plextools is reporting correctly.  Am I missing something?
*


What you say is right. However, imagine that I had only extracted the 30 first seconds of track one, or even that the same CD would have one track of 30 seconds at this place.
Plextools would have said that all errors were recovered, while the wav file is completely unusable.
Go to the top of the page
+Quote Post
JeanLuc
post Feb 22 2005, 21:41
Post #11





Group: Members
Posts: 1311
Joined: 4-June 02
From: Cologne, Germany
Member No.: 2213



QUOTE (AtaqueEG @ Feb 22 2005, 06:38 PM)
QUOTE (JeanLuc @ Feb 22 2005, 11:12 AM)
Now I know why I always extract twice with two different Plextor drives when I'm using Plextools and perform an EAC wav compare afterwards. biggrin.gif
*


ALWAYS?!?!

rolleyes.gif

Hey Jean-Luc, got that 716 already? Could you please try it with your hardest CD and post results? I am still making up my mind on it. I need a new drive and it is the front runner so far, but not if it is not going to do that much better than my Litey.
*



I got my 716A yesterday, TLA#0203, Manufactured 01/2005 ... I will post results as soon as possible.

And yes, I always do test & copy ... because I have encountered some strange Plextools behaviour in the past, too.

This post has been edited by JeanLuc: Feb 22 2005, 21:42


--------------------
The name was Plex The Ripper, not Jack The Ripper
Go to the top of the page
+Quote Post
Pio2001
post Feb 22 2005, 22:03
Post #12


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



I've scanned the CD two times :
With Plextools Pro / Plextor Premium, 10-24x CAV
With JLMS XJ-HD165H / KProbe, max speed



(200 is the widest vertical scale available)



(Sorry, I didn't think about scaling the C2 report)

Using the JLMS drive, accurate, no cache, C2, EAC extracts perfectly the bogus track : no C2 error, CRC OK.
With the Premium, accurate, cache, C2, the drive constantly spins up and down, and it takes 20 seconds to light up one red square. I canceled the extraction.

Here are the scans of a brand new pressed CD :





This Plextor Premium I got is completely out of use. It doesn't even burn properly past 8x.
The above scan shows 192 CU errors. If the CD is ok, it means that the drive is not even within red book specs.

I should see this problem with Plextor.
Go to the top of the page
+Quote Post
bobwood
post Feb 23 2005, 17:19
Post #13





Group: Members
Posts: 23
Joined: 10-April 04
Member No.: 13372



QUOTE (JeanLuc @ Feb 22 2005, 09:12 AM)
Now I know why I always extract twice with two different Plextor drives when I'm using Plextools and perform an EAC wav compare afterwards. biggrin.gif
*


JeanLuc

You may have already answered my questions in past posts but I have been unable to find them.

What percent of the CDs you rip fail the comparison test?
How do you determine which extraction is correct, or if neither one is correct?
Most importantly have you ever had Plextools Pro incorrectly report a successful extraction using the Plextor Premium?

Thanks
BobWood
Go to the top of the page
+Quote Post
JeanLuc
post Feb 23 2005, 17:34
Post #14





Group: Members
Posts: 1311
Joined: 4-June 02
From: Cologne, Germany
Member No.: 2213



QUOTE (bobwood @ Feb 23 2005, 04:19 PM)
What percent of the CDs you rip fail the comparison test?


0 of ~150 failed so far since I begun to rip with PTP ... including some damaged CD's that EAC was unable to rip in secure mode and some CDS protected discs.

QUOTE (bobwood @ Feb 23 2005, 04:19 PM)
How do you determine which extraction is correct, or if neither one is correct?


I use Plextools mainly for its speed ... so if I run into trouble as being described by you, I will use EAC (secure, no C2, test & copy) with one of my various drives

QUOTE (bobwood @ Feb 23 2005, 04:19 PM)
Most importantly have you ever had Plextools Pro incorrectly report a successful extraction using the Plextor Premium?


Not yet ... my Premium and 712A have always been dead-on thus far.

FYI, I believe that PIO's unit is indeed defective (or his PTP installation is corrupted which is unlikely to me) ... a Premium should not behave that way.


--------------------
The name was Plex The Ripper, not Jack The Ripper
Go to the top of the page
+Quote Post
Never_Again
post Feb 26 2005, 01:17
Post #15





Group: Members (Donating)
Posts: 698
Joined: 31-March 04
From: NYC
Member No.: 13152



QUOTE (Pio2001 @ Feb 22 2005, 05:03 PM)
(200 is the widest vertical scale available)
<...>
I should see this problem with Plextor.
*


Under Preferences you can actually type in your own value into the Graph Options -> Scale Limit drop-down box. That blinking cursor in there is very easy to miss. =)

Too bad about your Plextor. Fortunately, since you are in the EU, I hope your two-year warranty didn't expire yet. Check your PM.
Go to the top of the page
+Quote Post
bobwood
post Apr 26 2005, 08:19
Post #16





Group: Members
Posts: 23
Joined: 10-April 04
Member No.: 13372



After reading this thread I came to the same conclusion as some of the others, Pio2001 probably had a bad drive. Later I got to wondering if I could devise an experiment that would demonstrate Plextools Pro reporting all errors recoverd when there really was bad data in the ripped file using my supposedly good drive.

I briefly thought about doing what JeanLuc did, rip each CD on two drive. Since most of my CD collection is in good condition this seemed like looking for the proverbial needle in a haystack. I did have one CD that had consistently given me problems ripping. So I got it out and ripped it on the Plextor Premium. No errors reported and I did not hear any errors when listening to the ripped files. I then tried ripping it on my Pioneer DVD/CD drive. No errors reported by Plextools but lots of obvious errors when listening to the ripped files. There did not seem to be any point in comparing the files.

So on to plan B. I thought I would rip a good CD as a single wave file then deliberately induce errors by scratching or marking up the CD. I did not want to damage my purchased CDs so I burnt a CD-R using the Plextor Premium then ripped that CD to a single wav file. I assumed this rip was accurate and used the resulting wav file for comparing against subsequent rips after the CD was scratched or marked to induce errors. I then proceeded to try scratching the CD with the end of a paper clip, marking it with a Uniball pen, scratching with sandpaper and so on. I actually did this to three different CDs. I quickly found out that it was difficult to get just recovered errors. I either got no errors or unrecovered errors. After scratching a couple of CDs to the point of getting unrecovered errors, I switched to just using a Sharpie ultra fine tip pen. If I got too many errors I could just wipe off some of the marks and try again.

It did not take long to get some interesting results. I found that anytime I had unrecovered errors there would be recovered errors on nearby sectors. In every case some of these supposedly recovered errors would show up as miscompares when compared with the master rip. Here are some results from my first attempt.

C1C2 plot of 1st test disk

Plextools Pro DAE log from rip

EAC wav compare against master rip

I edited the EAC results to a single column and then added the results from the DAE log for the same time. Note that the times in the DAE log are MSF, minute second and frame. The EAC report is minutes and seconds. To match them up I converted the DAE frame number to fractions of a second by dividing the reported frame number by 75(frames per second). For what its worth all the miscompares I found were within a second or two of the unrecovered error reported by Plextools
Not all the lines in the EAC compare results have corresponding entries from the DAE log added, I just did not take the time to track them all down.

The second set of results if from a disk I marked and remarked with the Sharpie pen. After about 8 tries I got the following. Plextools only reported recovered errors but the EAC compare still shows errors.

C1C2 plot for 2nd test disk

DAE log from same disk, all errors recovered.

EAC wav compare for 2nd disk

I listened to this disk but did not hear any problem. However after searching through the waveform I found the following little blips at the points EAC reported miscompares.

EAC wav of 2nd disk

While I was doing this testing I was also listening to my ripped collection in the background at the office. Much to my suprise I heard a very non-musical little splat of noise on a file I thought had ripped OK. I ripped the CD again. Plextools did show an unrecovered error where I heard the noise. I expect I just missed the error message when I ripped the CD the first time.
The next challange was how to get a known good rip of this comercial CD. This turned out to not be too hard. I ripped it on my Pioneer drive using Plextools. Plextools did not report any errors and when I listened to it the splat was missing. This still left some uncertainty as to whether the rip was really good or not. I was also suprised that the Pioneer appeared to do a better job than the Plextor. I then remembered the Pioneer rip was only about 4.5X. So I set the speed on the Plextor to 8X and ripped again. No errors reported. I then compared the Plextor 8X rip and the pioneer rip and they were identical. Later I tried ripping the track with EAC. At about the point where the splat had been, EAC slowed to a virtual standstill. I canceled the rip and compared what I had been able to get. That did cover the area where the errors were and the compare was Ok as far it went. I decided to let the Plextor 8X rip be my master for this CD.
I then did a bit of cleaning on this CD and ripped it again. The original unrecovered error and the splat was gone but I did see recovered errors at a different point in the same track. I ripped the CD several more times, probably 30 or more. Sometimes I got no errors, sometimes I got recovered errors. When there were no errors reported by Plextools the resulting wav file always compared exactly with the master ripped at 8X. If Plextools reported recovered errors the compare usually but not alwasy had miscompares.

C1C2 of test disk 3

DAE log disk 3 rip, one of many

EAC cmp, disk 3

EAC wav from disk 3

So in summary
If Plextools has no errors the rip is probably OK, it was in all my attempts.
If Plextools reports an unrecovered error, there are probably recovered errors nearby some of which may not have correct data.
If Plextools only reports recovered errors, the data may or may not be correct.

Not what I had wanted to see crying.gif
Go to the top of the page
+Quote Post
JeanLuc
post Apr 26 2005, 08:46
Post #17





Group: Members
Posts: 1311
Joined: 4-June 02
From: Cologne, Germany
Member No.: 2213



bobwood

these are definitely interesting (and, to some extend, frightening) results. Thanks for your effort !

From the Q-Check test graphs you linked to, I think one can safely deduce that these test CD's of yours must be very hard to rip since the reported C2 error rates are way off specification. What is strange to me is that no CU errors have been reported which is strange when you consider that

1. the reported C2 peaks are that high & broad so CU should theoretically occur during Q-Check and
2. there are CU errors being reported in the DAE logfile.

Maybe you should have ripped at an equal speed of 10-24x CAV.

I also think that it might be a good idea to really let another Plextor drive do the actual comparison (this is what I always do because as far as I know, Plextools does not support error recovery on anything else but Plex drives ... additionally the FUA command for cache circumvention may not work with Pioneer drives which could lead to false results) ... maybe you can get hands on a 2410TA or something similar ... or you could always use your Premium for a second extraction (which is comparable to what EAC does in secure mode with C2). Especially on test disc No.1, this could be interesting.

This post has been edited by JeanLuc: Apr 26 2005, 08:47


--------------------
The name was Plex The Ripper, not Jack The Ripper
Go to the top of the page
+Quote Post
Pio2001
post Apr 26 2005, 23:10
Post #18


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



Thank you for sharing your work, Bobwood. It's very interesting.

QUOTE (bobwood @ Apr 26 2005, 09:19 AM)
Not what I had wanted to see  crying.gif
*


Don't forget that a synch error will never be detectable by C2 analysis only. Only multiple reads can track down synch errors, and even this way, the detection accuracy will never be exactly 100 %.
Go to the top of the page
+Quote Post
westgroveg
post Apr 27 2005, 00:28
Post #19





Group: Members
Posts: 1235
Joined: 5-October 01
Member No.: 220



Don't also forget that there is no such thing as 100% accuracy in detecting audio errors when using statistical methods. You will however find PlexTools missing an error is as hard as finding a problem sample for MPC.
Go to the top of the page
+Quote Post
spoon
post Apr 27 2005, 10:26
Post #20


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2725
Joined: 24-March 02
Member No.: 1615



I would hazard a guess that AccurateRip with its one hash for an entire CD which has to match with other hashes on a confidence basis is as close as you can get to 100% accurate (other than having the whole rip online to compare against...).

The problem with C2 and such is they are calculated on small blocks, with 100,000's of blocks over a CD, that is where errors can creep through mathematically.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Supacon
post Apr 28 2005, 06:19
Post #21





Group: Members (Donating)
Posts: 543
Joined: 19-March 04
From: Alberta, Canada
Member No.: 12841



Oh my god... I feel sick.

I just ripped 50 brand new CDs with Plextools Pro XL 3.0, and I had a little trouble on the last one. It reported some errors, but it recovered all of them. I thought it would be worth comparing it with another rip, and that's when I noticed something very wrong.

The rip had a 99 second pregap on the last track (which is insane), and when I listened to the disc, the last song was cut off right in the middle. I had been ripping to single files, and it turns out that it was cutting every rip off at the length of the first CD I ripped!

Plextools needs to be manually refreshed after every disc is inserted, or it gets the times wrong and f*cks everything up! I am so mad!

At least ripping is a very fast process, and it didn't take that much time, compared to using EAC, for example. What a piss off!

This totally turns me off of Plextools. There are just some things in it that need to be fixed.
Go to the top of the page
+Quote Post
paulgj
post Apr 28 2005, 07:10
Post #22





Group: Members
Posts: 105
Joined: 5-July 04
From: Bellevue, WA,USA
Member No.: 15075



PIO2001 I notice that you have firmware version 1.05.

Maybe you could try updating to firmware version 1.06 and seeing if this makes any difference? Just a thought!

Good luck


--------------------
Foobar 9.6.9, FLAC 1.2.1b, EAC 0.99 pb 5
Windows 7 Pro 64-bit
Go to the top of the page
+Quote Post
Pio2001
post Apr 29 2005, 22:56
Post #23


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



QUOTE (spoon @ Apr 27 2005, 11:26 AM)
The problem with C2 and such is they are calculated on small blocks, with 100,000's of blocks over a CD, that is where errors can creep through mathematically.
*


I don't think so. I don't know the real number. I've always been told that it was so small that it could be discarded in any situation. In fact, it is probably given by the number of possible error detection codes for a given frame.
There are 8 bytes of EDC per frame, thus 64 bits.
So one block might be erroneous once every 2^64 erroneous blocks, that is 18,446,744,073,709,551,616 blocks in average. There are 32,634,000 blocks on one CD. If the CD is entierely unreadable, it leads statistically to one missed error every 600 billions of completely damaged CD entierely read.

So in practice, we can consider that undetected errors are not caused by statistics wink.gif
Go to the top of the page
+Quote Post
bobwood
post Apr 30 2005, 19:16
Post #24





Group: Members
Posts: 23
Joined: 10-April 04
Member No.: 13372



QUOTE (Pio2001 @ Apr 29 2005, 01:56 PM)
QUOTE (spoon @ Apr 27 2005, 11:26 AM)
The problem with C2 and such is they are calculated on small blocks, with 100,000's of blocks over a CD, that is where errors can creep through mathematically.
*


I don't think so. I don't know the real number. I've always been told that it was so small that it could be discarded in any situation. In fact, it is probably given by the number of possible error detection codes for a given frame.
There are 8 bytes of EDC per frame, thus 64 bits.
So one block might be erroneous once every 2^64 erroneous blocks, that is 18,446,744,073,709,551,616 blocks in average. There are 32,634,000 blocks on one CD. If the CD is entierely unreadable, it leads statistically to one missed error every 600 billions of completely damaged CD entierely read.

So in practice, we can consider that undetected errors are not caused by statistics wink.gif
*



While I was the experiments I reported on earlier, I was also perusing the web trying to determine what the probability of an undetected error might be. I found a few articles that claimed uncorrectable errors could happen about once every 10^9 bytes. Undetected errors were supposed to be really rare but I could not find any numbers. In my searching I found several references to "The Compact Disc Handbook" by Pohlmann so I bought a copy to see what he had to say. He also talks about one uncorrectable error every 10^9 bytes. For undetected errors he relates the probability to the BER, Block Error Rate. For a BER of 10^-3, less than one error every 750 hours of playing time. For a BER of 10^-4, probability of an undetected error is negligible.

I have a problem with the 1 uncorrectable error in 10^9 bytes. Thats one uncorrected error every CD or two. I think if this were the case all of us who have ripped many CDs would have observed it. I don't know for sure but I think he may be talking about audio CD players. I don't think audio players do the retries that a computer CD drive would, they just attempt to mask the problem and go on. The book was last published in 1992 and drive technology surely has improved since then.

I don't know how to determine the BER of the disks I am using for my experiments. Pholmann gives some examples, 3.3X10^-4 for a clean disk, 5.6X10^-4 for a disk with a fingerprint across the entire disk, 4.5X10^-3 for a disk that had been rubbed on a wooden table for approximatly a minute. I don't consider the last two numbers very useful. I think I could get an order of magnitude variation in the results of rubbing a disk on a wooden table depending on what kind of wood, how it was finished, how clean it was, how hard I pressed, how fast I rubbed etc.

I concluded that its possible the discs I was testing with did have an error rate that made undetected errors possible. I was and still am surprised at how easy it was to get them.

One more note. In all my tests Plextools Pro did report an error at the same point that EAC reported a compare error. The descrepency is that Plextools reported it recovered by doing retries, the compare says it did not. So its possible the the drive had an undetected error on the retry. Its also possible that Plextools just bungled it, got its error reporting wrong or wrote the wrong copy of the data to the file. In my 35 years of software development I have seen, and done, stranger things.
Go to the top of the page
+Quote Post
Pio2001
post May 1 2005, 20:22
Post #25


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



Thanks for the info. If undetected errors are so common in CIRC, then the error detection codes are not or cannot be used as efficiently as I supposed.
We can see that that there is about 2 chances out of 1000 to get an error undetected by the CIRC ripping a CD with fingerprints and light scratches on it. It doesn't give us an idea of the number when the CD have a damaged part, because as I understand them, these numbers are valid for a homogeneous distribution of BER across the track, aren't they ? When a CD have a scratch or something, the BER is not constant, it jumps from a low value to a very high one, and falls down to its initial value immediately after.
Moreover, the CIRC, as described in Pohlmann's book in 1992 must be the E21-E32-uncorrectable model (two errors uncorrectable in C1, three errors uncorrectable in C2). None of the CD-ROM drives I tested used this model, but rather E42 or E52-uncorrectable models (four or five errors uncorrectable in C2). These models increase the risk of undetection.

It is difficult to interpret your Plextools results because we can't know if your errors were caused by mistracking. If it is not the case, then the CIRC handles them one way or another. But if it is, the CIRC has nothing to do with their correction, and the numbers above don't apply at all.

By the way, what's the unit of measurment of the BER figures you quote ?
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th April 2014 - 04:06