Ripping guide for Mixed-Mode CDs with data sectors in Track 2 pregap

[Sotho Tal Ker]

ECM and similar tools do only discard redundant data, that is the point - this data can be reconstructed

EAC itself does not do many magical things: offset correction and reading the audio sectors multiple times

[F1ReB4LL]

Yes, ECM won't touch any unusual/corrupted/whatever sectors, audio sectors, etc. Haven't checked its source, but I'm sure it reads 2048 bytes from each sector, then generates ECC/EDC fields, then compares with the ones in the sector - if matched, it cuts them out and leaves a mark that they should be regenerated during the UNECM routine. Anyway, it's a safe tool.

Feltzkrone, try to join our IRC channel and contact me there.

[Rocknroms]

or maybe start all over again as Rockrnoms doesn't find it easy to read

I think it's quite complicated to understand for most of people, moreover take a look at the forums also for reMove tool, you can find it in quite every forum faq by me. It can be more useful while moving sectors.
It will be great if you can code a tool that will avoid all those exceptions and that can handle them in a while.

[ssjkakaroto]

Feltzkrone may I suggest that you go for Java command-line because in the future it would be easier to port the program to other OSs.

[Feltzkrone]

because in the future it would be easier to port the program to other OSs

Seconded. The only problem I have with this choice is that I'll have to familiarize myself with JNI which is used to glue native DLLs and the JVM together. But it shouldn't be too hard either and will make things easier in the end as Java does provide a lot of classes and functions to the programmer which are not available in Delphi 7. The critical point in this is that programs which require an installed Java runtime are not that widely accepted by the end users as native Win32 applications are (the same drawback goes for .NET). I'd like to see other opinions on this topic before committing myself to one or another.

I guess it would be sufficient to implement device enumeration and device access (send CDBs to a device and pass data buffer and data direction) in the native DLL. I don't have anything with to do with e.g. Linux, but I guess it shouldn't be a problem for some Linux programmer to build an analogous shared object (I think this is for Linux what DLLs are in Windows) which can be used then.

[F1ReB4LL]

Feltzkrone may I suggest that you go for Java command-line because in the future it would be easier to port the program to other OSs.

Unless he's interested to modify PerfectRip (which is written on Delphi) instead of writing everything from scratch.

[Feltzkrone]

Unless he's interested to modify PerfectRip (which is written on Delphi) instead of writing everything from scratch.

First I don't have the feeling the author would hand out the source (I didn't ask and might be completely wrong here) and second rewriting from scratch gives us the possibility to do everything as we think should be done.

By the way, there is a not so unimportant thing to consider when rewriting from scratch: Many drives are able to disable error correction when reading data sectors. I believe if e.g. one bit in user data is wrong (on pressed CD) but ECC/EDC is intact, the drive would correct the wrong bit. If those wrong bits really are on CD shouldn't it be considered to write them (wrong) as they are into the image file, i.e. disabling error correction when dumping? Ofcourse, when disabling error correction more than one read per sector would have to be performed to really get sure we got what's on CD - as EAC does with audio data.

I already came over a CD (Al Unser, Jr. Arcade Racing) where a wrong bit is in subchannel data in one sector which is read as it is regardless what drive I used - meaning it really is on CD and not just a random error dropped in by the drive. I guess 1:1 preservation (which is aimed at redump.org AFAIK) should preserve this wrong bit, too. What's your opinion on this?

[Rocknroms]

I already came over a CD (Al Unser, Jr. Arcade Racing) where a wrong bit is in subchannel data in one sector which is read as it is regardless what drive I used - meaning it really is on CD and not just a random error dropped in by the drive. I guess 1:1 preservation (which is aimed at redump.org AFAIK) should preserve this wrong bit, too. What's your opinion on this?

Data is on CD only if it's in disc sector viewer. If the disc has some signs or scrathes and the drive is not good you will get errors, so if you cannot dump properly a disc, there's nothing to preserve.
If this error is something really on CD and if we are talking about PC stuff it could be some kind of protection so it has to be dumped differently.

[F1ReB4LL]

Of course, there are random errors in subchannels, there are random errors already pressed on the disc and random errors when reading them. That's why fixing the subchannels isn't a perfect idea in terms of preservation.

About error correction - still waiting you on the IRC channel (or ICQ) to discuss the details and algorithms. IMO, discs should be dumped in scrambled form via D8, then descrambled via software (to bypass any firmware error correction). No C2 errors - good dump.

[Feltzkrone]

I'll install ICQ or an IRC client on weekend. I have already finished the thin JNI DeviceIO DLL for Win32/SPTI and used it successfully in Java (plain dump of all sectors of a disc using READ CD CDBs). First I'll need to read and interprete TOC properly, I'll care about that until weekend, so I guess we won't lose any time when waiting (with knowledge exchange) until then.

Regarding D8 scrambled reads... It's another thing left to be defined: What about drives which are unable to read data via D8 command? I think we can't just exclude all users with average drives from submitting dumps - instead I would suggest something like a dump quality measurement where too low quality levels exclude dumps from being added as first-time dumps.