First off, you need to fully comprehend exactly what
EFM (
Eight to
Fourteen
Modulation) encoding is:
Eight to Fourteen Modulation is used during encoding, because the 8-bit 'magnetic' byte has to be modulated to a 14-bit 'optical' byte. Technically, this modulation is necessary to allow encoding of two consecutive 1s--which would be impossible with the scheme of pits and lands using 8-bit bytes (1s and 0s). In fact, the changes in reflectivity (as the laser light moves along the sequence of pits and lands) are coded as 1 channel bits. Two consecutive 1s are therefore not possible. Moreover, the 'lands' in between the 1s are represented by 0 channel bits, and the number of 0s represent the run-length. The bits in an optical byte are known as 'channel bits' to avoid confusion, and because they are transferred to the controller board through a specific channel. Furthermore, the fourteen-bit optical byte is provided three additional channel bits, known as merging bits--to eliminate transition conflicts between consecutive optical bytes. During the read process, the interface card demodulates the 14- bit optical code to the 8-bit code used by the computer--and all channel bit-level modulation and processing remain transparent to the user.
Now with that in mind, this is how SD2 works:
A regular bit pattern (such as XYXYXYXYXYXY...) fed into the EFM encoder can cause large values of the Digital Sum Value in case the merging bits cannot reduce this value. The scrambler (something found in every CD-ROM/CD-RW) reduces this risk by converting the bits in byte 12 to 2351 of a Sector in a prediscribed way. The sectors 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. Thats how SD2 works. [Plextor recorders *CANNOT* write SD2.51 correctly due to additional weak sectors added by MacroVision, whereas SD2 *PRE* v2.51.021 the Plex 24X & and 40X could cope with those weak sectors.]
Technically, this is why Plextor's (and many other "recognised" SD2 < v2.51.021 killers) fail in producing a backup that is readable in *every* drive.
However, CloneCD's
Ampliy
Weak
Sectors (and other programs) have introduced sector amplification techniques, that try (and most times do) overcome the havic that weak sectors (and regular bit patterns) cause to EFM encoders in CD-RW drives.
Sometimes AWS setting can produce wokable backups that play eveywhere (in some recorders) --> this cannot be warrented.
Drives capable of writing regular bit patterns correctly are on the increase, most drives supporting this feature are based apon MediaTeK chipsets, although, there are other chipset manufacturers out there that also support this *important* feature.
Fingers crossed that the upcoming PLEXTOR PleXWriter 48/24/48A (PX-W4824A) will support this! [^]
I hope that you finally understand the importance of a device to write "correct EFM encoding of regular bit patterns" when copying a SD2 protected CD.
_________________
You get what you pay for... Questions? Problems? Search for fast results!
You can click here to see
Today's Posts
|
Most Active Topics
|
Posts Since Last Visit
Printable Version
All Forums >> [In-House] >> FAQ >> Why can't my Plextor copy SD v2.51.021+ perfect? 
Why can't my Plextor copy SD v2.51.021+ perfect? - 
It was written for people wondering why their Plextor's (and others) couldn't perfectly backup newer SD revisions *without AWS*. And as we all know/should know, AWS is not perfect as it changes the data ("weak" sectors), and modifies these in a way that all CD readers can revert it back, so it is recognised as the original... 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread