CDA-II Options

[LordSyl]

CD Audio, specially but not only backups, have the big problem to do not last forever.
Specially if poor quality discs are used.

As some copy-protections like Cactus Data Shield use the available disc space on a 2nd session for that EVIL purpose, we could use a similar way to do a GOOD job.

I'm no coder yet, but hope some developer looks this. I find that's a good idea.

I though it would be useful to create a CDaudio, readable on regular CDaudio players, but using a 2nd session (if there is enough space available) for enhaced ECC codes and sector&track' CRC values, as CDaud¡o's error correction ain't very good.

So, if a backup disc is dying, a computer could restore the track by reading the "external" ECC codes.

If even the ECC codes couldn't restore a small portion of the data by any reason (a few bytes only), the system would engage a brute force attack mode to match the sector' CRC by changing the non-coincident bytes along on the sector until it matches.

If EAC implemented such a feature, it would be even better than now it is, specially if it allowed to copy the added-on ECC session!

So, you could successfully rip your backup disc, making it even more secure than the original, specially if y're using reliable discs.

This post has been edited by SyeltH: Dec 8 2002, 15:24

[spoon]

Why not rip your disc to Monkeys Audio? - it will be half as small and write the files out twice to the disc, or even better spread the files across two discs...

[LordSyl]

Because this purpose of this is to create a disc readable on any standard CD player, car player or portable. Only computers -or players that support this CDA extension- would be able to read the ECC & CRC session to help on ripping.

This post has been edited by SyeltH: Dec 8 2002, 15:12

[rc55]

IIRC, the session overhead would be as such that some CD's would have to be overburned.

Not a bad idea though! Worth checking out the Mode2 Video project thing thats floating around the doom9 forums, if you want to hack something together.

Ruairi

[LordSyl]

IIRC, the session overhead would be as such that some CD's would have to be overburned.

As I said before, CDS protected discs spam with a crappy player with 128kbps junk (useless space waste). On most discs, there won't be need of overburning, on others maybe.....it depends on how many tracks are on the disc.
Almost every disc I know is anything but completely full, but, as you say, there are some discs that would require overburn to do this.

[Thor]

Why not rip your disc to Monkeys Audio? - it will be half as small and write the files out twice to the disc, or even better spread the files across two discs...

Cause hard drives die.
Physical solid state storage is way more secure, surely when we're talking longterm backups (+10 years).
And because cdroms with APE files don't read on CD players.
I think adding extra security to the CDA format would be an ideal way to go about it, while keeping the cd playable on normal players.

Excelent idea!
Someone code that please :-)

-Thor

[LordSyl]

With this method a CDA-II will be even MORE secure than a data CD: while data CDs have ECC codes, this method would have 3 protections:

1- The CIRC algorithm inherent to the CD audio standard.
2- ECC codes.
3- CRCs of each sector and entire track. This is for checking integrity or engaging the last thing you can do......try a brute force attack on the wrong bytes in order to match CRC.... >_< .

I think with the ECC codes should be enough, but CRCs are not a waste of disc space so they're useful for a very last chance. Better that, getting always a digital-exact copy, than using software error correction or even having the disc dead, don't ya think?

This post has been edited by SyeltH: Dec 8 2002, 01:46

[Pio2001]

This is a good idea. However it's not trivial to code. Not only ECC must be added, but reference for offset detection, and an algorithm to detect skipping, that can occur when the CD gets bad. It is possible, Andre Wiethoff's programs, for example, already handle these two problems.

It would not be superior to a CD ROM. If I'm not mistaken, a CD ROM already use CIRC, does it ?

And CRC can't be used to correct any error. When there are 10,000 errors in a track, even if we could detect them all, which is not the case yet, exept, alledgedly with a sony crx220e1 or an asus crw5224, there would be 2^16^10000 possibilities to try, that is much more than any of my calculators can handle (and they can easily compute the total number of elementary particles in the observable universe, that is about 10^80). There would be virtually an infinity of wrong corrections giving the right CRC.

And sorry to add this, but CD ROMs are not so much secure, data CDR die too, a bit slower than audio CDRs, but CDRs decay so fast that they turn completely unreadable after a short decaying time. One more year should be enough to finish off a CD ROM burned the same day as an audio CD already dead. I've got dead audio CDRs 2.5 years old, and dead data CDRs 3.5 years old.

This post has been edited by Pio2001: Dec 8 2002, 03:55

[LordSyl]

I thought CIRC was only for audio. It seems I was wrong .

This post has been edited by SyeltH: Dec 8 2002, 12:37

[LordSyl]

And CRC can't be used to correct any error. When there are 10,000 errors in a track, even if we could detect them all, which is not the case yet, exept, alledgedly with a sony crx220e1 or an asus crw5224, there would be 2^16^10000 possibilities to try, that is much more than any of my calculators can handle (and they can easily compute the total number of elementary particles in the observable universe, that is about 10^80). There would be virtually an infinity of wrong corrections giving the right CRC.

I already said that CRC method is used only if the ECC leaves a few bytes wrong. Man, I already know that's impossible to handle 10000 errors with that , I meant a maximum of about 8 bytes left on a sector (that's like decoding 64bit ciphered code, it requires time).

The ECC data may also be compressed (track by track), so it would need less space on the session.

It would not be superior to a CD ROM. If I'm not mistaken, a CD ROM already use CIRC, does it ?

This is....weird , but as the ECC data (2nd session) has to be stored on a DATA track, that ECC-for-audio data will have ECC codes protecting them .

Andre Wiethoff's programs, for example, already handle these two problems.

Yes, but it handles errors in another fashion than the way I thought: They try to deglitch when a big problem is found, but the result is not a exact digital copy, even if there is no hearable glitch. It's also much slower than this method when a track is severely damaged.

With this, it will help EAC to use THE SAME ECC codes that a burner would generate for each sector on a data track, which give always exact result, as data cannot allow any bit wrong.

It will also wildly accelerate the correction process.

And maybe it can also have hardware support -for avoid skipping by using ECC data, it requires a few secs of antishock so the laser head can move to the 2nd session and read ECC- who knows .

This post has been edited by SyeltH: Dec 8 2002, 15:15

[Pio2001]

I already said that CRC method is used only if the ECC leaves a few bytes wrong. Man,  I already know that's impossible to handle 10000 errors with that      , I meant a maximum of about 8 bytes left on a sector (that's like decoding 64bit ciphered code, it requires time).

I don't believe in this. Either you store a CRC for each track, and it will nearly never be useful as it's quite impossible to get as few errors as 8, either you store a CRC for each very little part, and so much are needed that it takes as much space as the ECC themselves.
So why bother with CRC ? Just increase a bit the amount of ECC, and the result will be the same.

[LordSyl]

So why bother with CRC ? Just increase a bit the amount of ECC, and the result will be the same.

OK OK y' win!.......
Any coder is interested in this?.......

This post has been edited by SyeltH: Dec 8 2002, 17:24

[theduke]

I remember that some people here on the forum wrote that a few of their CD-Rs were dying and that the outer zone of the discs was already (nearly) unreadable. I don't know if it holds true for the majority of discs that the outer part is affected first by data loss... but if it was so you wouldn't benefit much from storing the ECC in the second session of the CD-R.

[LordSyl]

You wouldn't benefit much from storing the ECC in the second session of the CD-R.

I disagree. Remember that the audio ECC codes will be stored on a DATA track: that means audio's ECC data WILL be protected by the auto-added-by-the-burner data ECCs, resulting on a severely enhaced protection.
Not perfect, but much better than no protection, as when you notice skipping with any player you can rip the disc perfectly...you're then at time to do an exact rip by reading ECC codes before things get worse.

This post has been edited by SyeltH: Dec 8 2002, 23:49

[Pio2001]

Here's the distribution of the C2 errors (in black) on a dying CDR.



Horizontal scale : one minute per line
Vertical scale : logarithmic, x2 per line
Black : C2 errors
Blue : additional undetected errors

CDR : Traxdata80 burned on Yamaha 6416S in 1999 or 2000
Drive : Memorex DVDMaxx 1648

[LordSyl]

Every disc starts crapping from the beginning and outside area? I don't think only one disc from one brand is enough for such a conclusion.........though it's interesting, that graph.

This post has been edited by SyeltH: Dec 9 2002, 00:31

[Pio2001]

100% of my CDRs are dying from the end (I must have got about 20 ones, Mitsui, Ricoh...). Two of them at least from the beginning also (including this Traxdata one).
Other people often report CDRs failing with the last tracks first.