Halcyon

I've written this question to another forum already, so I'm not going to repeat it at length, but just ask shortly:


Is there an accurate, repeatable and fool-proof way to test for accurate stream, C2, accurate gap detection and read into leadin/lead out?

Before you answer anything profoundly self-evident, please read my whole question at:
http://www.cdrlabs.com/phpBB/viewtop...?p=14893#14893

Halcyon

I used the CD-Check disc from Digital Recordings, which has black stripes of various widths painted on the reflective side of the cd to simulate scratches of various lengths.

I then proceeded to rip this album with Plextor 12x10x32x SCSI / ASPI 4.6.xxxx => Lots of errors reported, but copy reported OK, Sounds perfect, even the last track with the biggest amount of error painted on the disc

I did the same with my Hitachi GD-7500 DVD-ROM (with supposedly inaccurate C2 info): lots of error reported by EAC, much slower rip, copy NOT reported ok -> Listenint reveals lots of artifacts even with the most narrow error strip track (track 2, which should be passed BY ANY cd player or it should be considered defective).

Any comments?

cheers,
Halcyon

Pio2001

C2

When they say that "track 2 should be passed BY ANY cd player or it should be considered defective", they talk about audio players. Extraction is a different thing.

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.

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.

Besides that, you're right, EAC only reports the presence of C2 pointers, not their accuracy.
____________________________________
EDIT : the below part is wrong : CRC mismatch with no errors occured doesn't mean that the drive is not C2 accurate, because error corection doesn't rely on C2 info !
To test C2 accuracy, use the DAEquality package from http://www.exactaudiocopy.de , and ensure that the report says 0 skips

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.

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).

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 !

________________________________________

When I was testing CDP32 (http://www.compactgear.com/cdp32.htm), the programmer, on r3mix.net, told me that I couldn't get accurate results from the Hitachi GD-7500, because it was known to have a buggy firmware http://66.96.216.160/cgi-bin/YaBB.pl...num=1007171343
(the "link at CD-RW.org" has mysteriously disappeared, but it was only about the subchannel reading ability, it seems : http://www.compactgear.com/schdrives.htm).

Gaps
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. I can't access the mailing list archive right now (http://groups.yahoo.com/group/eac) , so I can't search. It's a pretty old post, one year ago, at least, I think.

Overread
You must find a CD with audio noise running before first track and after last track. Ideally an old AAD CD. You must then have a wav editor allowing you to vertically zoom until the quantization noise level (the "pixel" level). EAC could do that (adjusting the vertical zoom to the window displayed), but you can't open two wavs at once, and there can be some problems with fade-outs, the zoom being adjusted too wide on the loud part, masking silent parts.
Avoid SoundForge 4.5, it stops just before the noise level (though it could work if your noise is more than two "pixels" high). CoolEdit is a good one. A demo version will do, you don't need to save.
Wether your drive have positive or negative read offset doesn't matter as long as you find a CD that was "over-recorded" enough.

Lead-in : detect gaps, you must try to overread before the gap of track one. A zero gap for track 1 is perfect.
Extract by range, without offset correction, the very beginning of track one. Open the wav in CoolEdit, zoom to the extreme left, and zoom vertically until the levels 1,2,3... out of 32000 are visible. If there is silence, find another CD.
If there is noise, return in EAC, set the offset correction to -1000, overread enabled, and copy range again.
Look in CoolEdit : the previous extraction is visible 1000 samples from the beginning. If the 1000 extra samples on the left are silent, your drive can't overread, if the noise go on from sample 1000 to the left, then your drive can overread.


Same thing for the lead out, exept that the gaps are not important (there's no gap after last track), the range to be extracted is the end of last track, and the read offset must be set to a positive value (+1000) for the second copy range, in order to overread into the lead-out.

Accurate stream
I don't know exactly what accurate stream means. I think it mean "constant offset", as far as I understand it (same data returned each time).
Feurio is quite accurate at detecting variable offsets, in its drive test. (ten tries over 1 minute, the 500 tries over one sector).
EAC should be accurate too, if you run the detection several times.
I wonder if a configuration change (IDE port, DMA setting) can change the acurateness of the stream. I though someone reported his drive having switched from accurate to non accurate, or cache to no cache or the opposite, reinstalling the computer (changing OS ?). It could have been the firmware being upgraded, though (I know some Plextor switch from no cache to cache upgrading the firmware).

__________________
Pio2001

Halcyon

Pio2001,

thank you for taking the time to answer my questions. Let's continue more...

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?

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?

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).

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.

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

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

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

Pio2001

When an error occurs, the C1 and C2 processes can recover exactly the info. This occurs inside the drive, and can't be accessed from outside.
The only thing viewable from outside is the C2 flag, that is 'right' or 'wrong'.
'Right' means that either there was no error, either there was a perfectly corrected error.
'Wrong' means that the C2 info couldn't be used to reconstruct the missing data.

From here, the processes of audio playback and audio extraction differs.
Audio extraction stops there, and a wrong data is returned.
Audio playback then perform "error concealment" : wrong data are interpolated from neighborous valid samples. That's why in most cases, a scratched CD clicks when extracted, and doesn't when played.

EAC beta is the first soft that tries to simulate the error concealment, that is missing on the hard side, in the soft side. It interpolates the data when the C2 info says that an error wasn't recovered.
Andre could explain better, but I guess that isn't not very efficient yet, because it must just perform a regular "deglitch" process when a C2 error is returned, instead of searching for the nearest neighborous valid samples and interpolate.

That's why the test CD comments don't apply : error concealment is part of the required specs to play an audio CD. Therefore if they took that into account, a Digital Audio Extraction can clic while the drive performs as well as an audio player that doesn't click (thanks to error concealment).

I mean that a regular deglitch must be run on C2 error instead of a real emulation of error concealment, leading to low quality error concealment. Is it right Andre ? I though I heard deglitch artifacts when listening to a double C2 corrected wav from a scratched CD.
That doesn't tell if C2 works well. The point is to "test and copy selected tracks", not to "copy". Then the test CRC and read CRC are displayed, and in the CRC column, "OK" means that the CRC match : the copy is OK, and "#" means that the CRC don't match : there were errors. Then you can compare these reports to the log window. A high number of C2 errors resulting in "copy OK", then confirmed with CRC OK is the secure way to test C2 accuracy.
The fact that the wavs sound perfect is no proof. The C2 problems with the Hitachi GD-7500 are in fact completely unaudible. The errors don't go higher than two or four elementary steps (I cut and inverted-pasted the wavs) that is -84 or -90 db !

That's not the case for me. It really starts error correction each time a scratch is encountered.
It seems to be accurate 90 (for the 'wrong' reports) to 99.999999 % ('right' reports) of the time.

The point was that the index number is written at given time intervals in the subcode channel, and that this subcode channel can be used for other infos. EAC searches for the point where the index number changes. If some other info replaces the index number right on the transition, then the transition can't be defined with accuracy.
Example :
000001111
The gap is 5 steps long.
0xxxxxx111
The gap is between 1 and 7 steps long.
I don't know how long are the steps, nor how long the subcode channel can be used by other infos.


No idea... But everybody's talking about Toshiba

Thanks for the interesting questions !

__________________
Pio2001

Unregistered

Ok, so my description was ok, except that the C2 correction happens inside the drive and not inside EAC.

EAC only checks for C2 success/failure flags and interpolates ('error concealment' as you put it) if drive reports C2 failure.

So, it's a new feature since 0.9b2 and it will get better, hopefully. Great!

So, I cannot test for C2 accuracy with just copy, because 'error concealment' in EAC may be able to deglitch/interpolate C2 unrecoverable errors.

Ok, I did as you suggested and tried the CD-Check disc again in my Sony UDD1621 with C2 ON (both checks in drive options). The results remain the same: Sony passes the test with flying colours in CRC, in EAC "copy ok" report and in audible quality.

To me this is a good indication that the C2 data is accurate.

Hitachi fails this same test miserably on all accounts while producing a high number of C2 errors to EAC: different CRC data, EAC reports "copy not ok" and ripped wavs sound horribly distorted.

Here are the complete results for my Sony UDD1621 dvd-rom with C2 on:

EAC extraction logfile from 17. March 2002, 21:30 for CD
Sony_UDD1621 / CD-Check C2 ON
Used drive : SONY DVD-ROM DDU1621 Adapter: 1 ID: 1
Read mode : Secure with C2, accurate stream, NO disable cache
Read offset correction : 594
Overread into Lead-In and Lead-Out : No
Used output format : Internal WAV Routines
44.100 Hz; 16 Bit; Stereo
Other options :
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Installed external ASPI interface


Track 1
Peak level 99.9 %
Track quality 99.9 %
Test CRC 03CA185B
Copy CRC 03CA185B
Copy OK

Track 2
Peak level 99.9 %
Track quality 100.0 %
Test CRC B601AA2C
Copy CRC B601AA2C
Copy OK

Track 3
Peak level 99.9 %
Track quality 100.0 %
Test CRC B601AA2C
Copy CRC B601AA2C
Copy OK

Track 4
Peak level 99.9 %
Track quality 99.9 %
Test CRC B601AA2C
Copy CRC B601AA2C
Copy OK

Track 5
Peak level 99.9 %
Track quality 100.0 %
Test CRC A6596AF8
Copy CRC A6596AF8
Copy OK

No errors occured
End of status report

To me they are definitely not inaudible.

If you go back and read what I said, Hitachi GD-7500 (at least my drive) FAILS UTTERLY on the CD-Check test and the glitches are HORRIBLY AUDIBLE distortion on all the error test tracks (even the one with really small error stripe). You cannot go on without hearing these glitches, they are FAR from subtle.

I think everyone is talking about Toshiba, because it's good for copying copy-protected CD-roms. It reads sub-channel data alright, but it's not very fast (and it's noisy as hell as a drive).

Thanks,

Halcyon

Pio2001

Nothing to do with error concealment, you can copy and test and copy with or without error concealment.
The point is to check that C2 turns on each time an error occurs, otherwise, there will be unnoticed errors.
So we need errors. But we need correctable errors. This way, using the CRC comparison of the test and copy mode, we can check if unnoticed errors occured.

On your Sony test, the red lights lit up, therefore there were errors.
The CRC were all the same, therefore all errors were detected with C2. Therefore your C2 is accurate.

I'm talking about unreported errors.
If EAC tells me "there were errors", no problem, I don't burn.

My problem is when the Hitachi rips brand new CDs without red lights, tells "copy OK", and there still were errors according to the CRC !
Those errors (two or three per perfect CD, according to compare wav) are completely unaudible.

__________________
Pio2001

Unregistered

Damn, I'm learning all the time from you

Yes, EAC did NOT report report any errors for the first test audio track that I ripped with Hitachi (C2 ON), but the resulting file IS horribly distorted.

All the rest of the tracks had C2 errors in the (and the copy was NOT OK according to EAC -> lots of audible glitches).

Doesn't this mean that C2 error correction in Hitachi GD-7500 is inaccurate and cannot be trusted?

Cheers,
Halcyon

Pio2001

Oh yes it does !
(No errors and a distorded wav). I've never seen such a behaviour with my Hitachi

The CRC didn't match for the "no errors" track, did they ?
That's the key symptom of inaccurate C2.

__________________
Pio2001