Pio2001,
thank you for taking the time to answer my questions. Let's continue more...
Quote:
Originally posted by Pio2001
C2
From this point of view, audio extraction could be considered as defective from the beginning, if the black strip is wide enough to generate a C2 error. In this case, error concealment could still make the track sound perfect on an audio player.
|
Eh? I don't understand.
AFAIK:
1. on some occasions C2 error information can be used to recover lost data bit-perfect (no data loss)
2. on some occasions error is so big, that C2 cannot recover the lost data (i.e. data loss occurs)
IF 1 happens then the player will report the erroneus stream along with C2 to the reading program, which can fix the errors (my Plextor did this, no audible glitches, EAC reported the copy as OK)
If 2 happens then the player will report errors and C2 to the reading program, but data cannot be recovered and there will be loss of data (program will insert silence, interpolate or do something else?).
However, in some cases C2 error information will be wrongly reported by the transport to the reading program. Errors will be fixed using this erroneus C2 data (if not deemed unfixable by the program) and the resulting badly fixed data will sound bad (This is what happened with my Hitach GD-7500 with C2 turned on both times).
Do we agree on the above? Have I misunderstood something already with the above comments?
Quote:
EAC features error concealment in the beta version (the second C2 checkbox), but it relies on perfect C2 reporting from the drive, and that's not always the case, and it's not perfectly implemented yet, AFAIK.
|
Ok, that has several things.
1) When you say 'error concealment' do you mean what I mean, when I say 'error correction' (i.e. erroneusly read data is corrected mathematically to 1:1 bit perfection using C2 data, IF it can be fixed).
2) 'Perfect C2 reporting' you mean that the player not only send C2 flags, but also CORRECT C2 data of the disc?
3) 'It's not perfectly implemented yet'? Does this mean that the C2 usage inside EAC is not ACCURATE yet, even if the player returns totally accurate C2 data 100% of the time? If so, is there *any* reasong to use C2 features in the current version?
Quote:
To test it, you must use a lightly scratched CD, enough for the error correction to start, not enough for EAC to fail at error correction.
It's the most difficult part : usually, when you're adding scratches to a CD, it jumps from perfectly readable to completely unreadable at once.
Then turn C2 on, and make a "test and copy selected tracks".
You must get some C2 errors, but get "no errors occured" for the test to be valid. Then, if the CRC match, the C2 were accurately reported. If they don't, the C2 were wrong.
|
This is *exactly* what I did with my test cd:
1) On plextor I get some read errors (due to errors on test disc), but the copy if finished OK according to EAC (the errors are corrected). The ripped tracks sound totally flawless.
2) On hitachi I get same read errors AND the copy is NOT finished OK according to EAC. The ripped tracks sound glitchy and problematic (all of the test track of increasing difficulty).
Quote:
I know that the Hitachi GD-7500 is wrong, even though it perfectly report C2 when coming on a big scratch, because CRC mismatch about 1 time out of 10 on perfect CDs with no errors (there are always one or two C2 errors reported for perfect CDs).
|
I suspect that GD-7500 doesn't return *any kind of useful C2 data* as EAC cannot use it to correct even the most slightest of read errors (that can be corrected on other C2 capable drives using the same test disc).
I think GD-7500 probably returns some totally inaccurate C2 data all the time.
Quote:
It's funny that you ask that just now : I was just extracting a Memorex Black CDR with my Hitachi while browsing the forum. This brand gives me a lot of correcteable errors. As a result, out of 12 tracks, there were 9 with "no errors occured", and only one with CRC matching !
|
Funny how things sometime happen at the same time
Yes, I've read the same comment. Wish I had known that, BEFORE I bought my GD-7500
Quote:
Now, about detecting gaps securely, all I know is that it can be impossible in some cases. Andre explaned why in the mailing list once.
|
Impossible? Damn... I was hoping there was some accurate way to detect at least the reader's gap detection accuracy.
Now I'm getting totally different GAP indexes depending on what Gap detection method I use in EAC
Quote:
|
I don't know exactly what accurate stream means.
|
I don't know for sure either, but I've seen references (in Feurio literature) about this meaning that the stream is jitter free (no loss of synch) AND, like you said, offset being constant (another thing that Feurio tests for).
If these two things match, then the stream should be 'accurate'.
Thanks again for you comments and lead-in/lead-out explanation (I checked the web page you made).
One final question:
1. What dvd-rom drive (I need dvd) would be the safest to buy currently for audio extraction at maximum speed?
and further...
2. How can we make sure (through testing like in this thread) that it has the proper features?
cheers,
Halcyon