I know what EFM means, it an Eight-to-Fourteen Modulation that replaces each 8 bits pattern with a 14 bits one in order to have pits and lands at least 3 bits long in NRZ mode.

But what does it mean that a burner supports correct EFM encoding ?

CloneCD says :
Correct EFM-Encoding
= Drive writes regular bit patterns correctly.
= Drive writes regular bit patterns almost correctly.
- = Drive does not write regular bit patterns correctly.

I can't make any sense of it. If a wrong EFM pattern is written on a CD, it is just a coaster.

And there is absolutely no access to EFM from outside of the box.
In EFM, a 2352 bytes sector (i.e. a raw sector with error correction included) would be 4998 bytes (each byte is replaced with 14 EFM bits + 3 parity bits).

Thanks for any technical info.

[off-topic]
Welcome on board, EAC-expert! (If I am not mistaken...)


[/off-topic]

man..you confuse me.....

are you asking something..or explaining something.....

i think that with every modulation that some modulators are near perfect (extreme good modulation without almost no error) and some aren't. Perhaps the modulation algorithm used in the writers are different per ic.

Just like in am/fm things.

Thanks
You're not mistaken about the person, I'm Pio2001. About the status, I would call me an expert if I knew how to use EAC for encoding, or tagging and that's not the case (since I'm not interested in the process anyway) !

I'm confused too.
It started in afterdawn.com, someone asked if he could make his burner write correct EFM codes tweaking the firmware. I foolishly asked him how the hell could he know if his writer could write EFM right or wrong, save if he had plugged a digital oscilloscope on the chips of the burner to record the data sent to the laser...

I knew nothing about the "proper EFM" feature as used in CloneCD. Fortunately, I was not moderator on the forum, otherwise I'd have wanted to hide inside my pocket.

But I found no docs about this EFM feature save that it's necessary to burn Safedisc Copies.
It seems illogical to me that EFM could be accessed in any way, the image files of CDs would be 1.5 GB with all EFM info !

So I wonder if the word EFM is improperly used to speak about some regular error correction codes of the RAW mode, or if there is some high-tech trick I'm not aware of.

If I follow you, you're suggesting that burners don't write secure EFM data (=very low level data), but creates some errors, that are correctable anyway (so there is no consequences for regular use, exept a higher Bler).
And SD2 CDs would, for a given reason, need perfect EFM (=zero bler) in order to work...

It could fit, but it seems a little ad hoc...
Some articles about why SD2 needs correct EFM ?

i think that's indeed the case , but on the other hand it would also need a perfect cd disc (no scratches and stuff like that) to give it always a perfect reading , so i don't think that'll be the solution. There could however always be a percentage on it (say more than 50% correcting is considered an illegal copy or something like that).

I've got no articles and very little knowledge about the safedisc 2 issues so i'm afraid i can't motivate my answers.

They's "merge" bits, not parity bits Sorta eight to seventeen, eh? You might have to recalculate that 4998 bytes computation.

As some people noticed that safedisc 2 protection is based on some sectors called weak sectors with regular patterns content, these sectors when burned become unreadable in a lot of burner .

Some people said that this problem was due to the fact that in the case of this weak sectors, the burner was not able to produce a correct sector with 8 to 14 bits correctly generated and they said that this burner cannot Correctly EFM-Encoding .

Note that as you said if EFM encoding is not properlly done, the result is an unreadable sector (too much peak or too much land) .


But i don't really know if someone has a proof of that .

But is the problem reading or writing SD2 ?

I've got no problem figuring unreadable sectors, that can only be read and burn in raw mode (800 MB image).

I've got no problem figuring wrong EFM either, it's used in SafeAudio protection.

But it's completely unreadable nor burnable, it would be a rawer than raw mode ! (anyone with a 1.5 GB image ?)

Are wrong EFM replaced with "weak sectors" in the copy ? (I assume that a "weak sector" is a sector written in raw mode with wrong error correction code).

Hello OlivierFromFrance, we get lots of questions about D-Tools here How is the D-Tools Beta Team?

The problem is that a lot of burner write incorrectly these weak sectors which become unreadable to read by most of cd readers/writers ; you can see that DAEMON Tool has no problem with it .
So this mainly a writing problem .
I don't know if EFM as something to do with safeaudio .
There is a big misundertanding about 8 to 14 impact, this process is always done by the writer and is due to the norm of writing .
The idea is that as EFM process is not properly done, the sector become physically impossible to read, beta blocker or clonecd modify slightly the weak sector data to avoid that .

Of course Daemon Beta team is still doing some beta tests to check DAEMON tool improvment - wait - wait - wait ...

Aaaah !
So it's a firmware BUG ! Not a un-supported feature ?
Is that it ? A bug that only occurs writing incorrect error correction codes to copy SD2 ?

It makes the sector 'Unweak' by changing certain bits in the data according to a prescribed patch algorithm. The SD2 guard module doesn't read them raw, so the error correction makes up for it.

Does anyone know the patch algorithm for AWS or Betablocker?

How do these errors compare to the errors CloneCD reports (in first 10000 sectors) while reading a SD protected orginal disk?

They probably show up as C2 errors, like the SD2 bad sectors. Will someone check? (This is the first time I've wished my Lite-On wasn't able to copy all weak sectors.)

> They probably show up as C2 errors, like the SD2 bad sectors

I can't find c2 errors in sd2 bad sectors...

if the writer has only a very little problem writing these weak sectors, they might get c2 errors, but usually they're either ok or completely unreadable.

spath found, when he examined the sectors with "special equipment", that they were chock full of C2 errors, and normal drives reported only interpolated bytes.

Let me rephrase my question:

On the orginal there are read errors in the first 10000 sectors. These sectors are the weak sectors, isn't it? Although you get read errors, the weak sectors are still read. (Isn't it?)

But then you try to write the resulting image with a not fully EFM encoding compatible writer. According to OliverfromFrance from D-tools this results in an error which is physically impossible to read.

How do these errors compare to each other? When is an error an error and when is an error that big that you can't read it anymore. What kind of read errors are possible?

So this is not a SafeDisk question in particularly, but more a question about errors in general!

Which error mechanism can report interpolated bytes? I thought interpolation was only used by audio cds... interpolation on data cds wouldn't make much sense, isn't it?

That's not what I'm getting. The weak sectors are 1-500, and bad sectors start around 800.

I mean when using the audio read trick of Blindwrite. I don't know what happens when you do it with CloneCD, but something similiar must happen, since it doesn't get bytes with C2 errors, although they are there.

Perhaps spath knows more (This is a generic statement about CD's, though )?

It usually depends, at least in the tests I did with my AOpen.
Sometimes it would take 2 times to get the data back, and sometimes it would never report back.

I think that each burner has burns of varying correctness, how 'clearly' it can be read.

in my meager understanding of it, the errors are still in the image. however, when they are fed to the writer, and it discovers that it cannot write what it is being given, it replaces this with null code, and this null code is worthless, as no information can be gathered from it.

I don't think this is true because:
[list=1][*]It would disagree with tests that show it has to re-read once or twice.[*]It wouldn't make any sense to do this, from the writers standpoint.[*]Why would drive manufacturers insert code to check the factors to decide if the drive could do it or not?[*]There is no number four, I just like lists .[/list=1]

I dunno, there could be huge amounts of something obvious that I just don't realize.

Sorry..i followed this "discussion"with much interest...but i thougth i read somewere that C2-errors are only interesting when talking about audio...

is that correct??

Sorry..i followed this "discussion"with much interest...but i thougth i read somewere that C2-errors are only interesting when talking about audio...

is that correct??