You are dancing around the root cause of the probem.......
There are basically 2 different Chipsets used in 95% of all the burners made, the Sanyo and the Phillips. There are a few others, but they are not really worth mentioning.
The Phillips chipset is the chipset that is able to make working backups of SD2 protected disks that will work in any Writer or CDROM. This chipset is used in the following drives; Acer's, Artec's, Fujitsu's, Seimen's, HP 8250i, Iomega ZipCD's, Lifetec's, Medion's, Tevion's, Phillips, TraxData's, & Waitec's.
The Sanyo chipset is the chipset that seems to allow many burners to make copies that will work in the burner that made it, many times in other writers, and rarely in other CDROMS. This chipset is used almost all the other drives except those mentioned above(including Plextors, Creative Labs, HP's, Imations, Ricoh's, Yamaha's, etc).
Now one interesting fact is that Sanyo changed the version of their chipsets roughly midpoint of the Plextor 1210a run. The older chipset seemed to be able to make working backups of the SD2 discs a little more often than the newer chipset does. Thus the reason why many people with certain Plextor 1210a's seem to be able to make working copies of the SD2 discs more often.
But neither Sanyo chipset CAN NOT make working backups of SD2 discs that will reliably work on ANY other CDROM drive 100% of the time, where the drives using the Phillips chipsets can.
Yes, depending on the chipsets capabilities some of the problems with the SD2 discs may be able to be compensated for in the firmware. But it truly comes down to the chipsets physical capabilities when reading the various protection types. You can only do so much with software and are always limited by the hardwares capabilities.
Try to get Sanyo or Phillips to release the technical specifications of their chipsets, or even better yet the internal design schematics, or even the FULL undisclosed command sets. Never happen.....been there, done that.
People talk about Plextor being in bed with Cdilla (creators of SD2 protection). It would be far more likely that Sanyo may be doing a little collaborating with Cdilla, since EVERY drive that uses the Sanyo chipsets are unable to produce reliable, working backups that will run on ANY CDROM, not just Plextor's.
Now on the other hand, why can the Sanyo chipsets read/write sub-channel data and the Phillips chipsets can't? Lookout another conspiracy theory here, hmmm? Is someone in bed with the makers of SecurRom protection (hehe). No, I doubt it, again it comes down to the physical characteristics of the chipset design along with the internal command set.
When you say:
"There are a few others, but they are not really worth mentioning. "
But if what you say is true, the chipset in the plextor 8/20 and 8/2/20 TLA #0100 must be in the other category to be able to have the following capabilities:
Perfect SD2 copies
Best Supported Write Mode:
Best supported Read Mode for Data:
Best supported Read Mode for Audio:
And they'd also have to have solid conversion-tables within their firmware versions specifically for these special "other" chipsets? If this is true then the Plextor 8/2/20 #TLA 0100 is amazingly unique. Thanks for your info, please follow up.
I found this in the Blindwrite F.A.Q.:
Safedisc 2 is very hardware orientated CD copy protection. In addition to all the safedisc 1 tricks, SD 2 uses a mathematical suite of data which requires, for reading, a very well contrasted CD. the explanation is far beyond the scope of this FAQ, the result is that only a few CD readers can read the backup of these mathematical sectors. Both a good reader and a good cd writer are required to produce a working backup, and a SAO RAW writing mode shall be preferred, as SAO writing offer more contrast than DAO on the backup CD.
I guess he is into the contrast theory too.
LocutusofBorg brings more info...
This is all from http://www.daemon-tools.com/ikonboard/topic.pl?forum=8&topic=39 written by LocutusofBorg:
I've posted this under the name "LocutusofBorg2K" in CloneClinic in December 2000. I'm started a "Firmware Project" with some teammembers, but we never reached the goals, instead we invest tons of money.
DOTC (one member) figuered out, that it is all sync-related.
It has nothing to do with the EFM, cause the datapattern is intact. The difference between f.e. Plextors and drives that can't READ the "bad burns" is that plextor implement additional circuits to position the laserpickup exactly.
You can proof this by yourself: Plextordrives can position even on audio-cd's exact due to additional circuits.
They don't need (in lower read-speeds) the syncsignature.
But try to read this discs with f.e. clonecd: this program use special commands, so it's unable to read the "bad burned" cd's exact. Start a sectorscanner and try to read the weak sectors. surprise, surprise: no problem. Some TEAC drives use the same technology so they are able to read the "bad burns" from plextor, too.
After increase of laserpower it seems that some of our "testburns" turned to audio-cd's ?!?! No idea why this happens we concluded it's better to stop the further development, cause noone think it's funny to destroy other devices and additional to that we got mail from "friends" that developing and manipulating firmwares is illegal, they are copyrighted. You surely can imagine what "friends" I mean.
I've then send email to Olli Kastl to ask about the possibilities of a copyright lawsuit against us, but he never answered.
But the point is: NO ONE! and I mean NO ONE, knows for sure!!! what causes the "badburns" on most cd-recorders.
There's also rumour that "Philips" burners write "raw" other than most burners. We've a philips-employee (from r&d), he's a good friend of mine but he's sure that there is nothing "special" about the philips/acer burners except 2 things. Our team now develop more "constructive" software and it's real funny.
before I forget:
We never found indices (but after all we never take a look at Plextor 8/20 firmware cause nobody own's one) that there's a "mathematical" algorithm for the efm encoding
And besides this Olli K. posted that there is a overflow! of the scrambler device. If you're interested in the exact function of this efm-device, write a mail. (My Opinion on that: Quote from Olli K: "The sectors I have mentioned above try in fact to overload the EFM encoder of the CD-Writer, because AFTER passing the scrambler the poor device has to write REGULAR BIT PATTERNS - something it really doesn't like."
--> BUT THAT'S THE EXACT REASON THE EFM IS MADE FOR!!
Just my 2c
PS: The EFM is Chipset related, not Firmware-related
HELP GET TO THE BOTTOM OF IT!