15 Mar
2005
15 Mar
'05
6:04 p.m.
Coming in on this a little bit late, but if you haven't checked out the
Library of Congress you should.
www.loc.gov/preserv gives you a basic run down of ways to care for archived
materials, and the NIST/CLIR puts out Special Publication 500-252 "Care and
Handling of CDs and DVDs - A Guide for Librarians and Archivists" (e-version
available). Other tips- gold disks, AZO dye are reputed to last longer.
The phenomenon of failure from the outside in has interesting possibilities-
have software write a known pattern in the outermost section of the disc and
pop up a warning when it starts to deteriorate. Hopefully this would give
enough time to move data to another disk.
- Scott Quinn
16 Mar
16 Mar
2:17 p.m.
Scott wrote:
The phenomenon of failure from the outside in has
interesting
possibilities-
have software write a known pattern in the outermost section of the disc
and
pop up a warning when it starts to deteriorate. Hopefully this would give
enough time to move data to another disk.
It doesn't have to be a known pattern. There's so much error correction
going on that as soon as you start detecting read errors (i.e., so many
errors that the error correction fails), you know you've got problems.
Writing all zeros, all ones, alternating bits or bytes, or random bits
would all work equally well for this test, and if they read at all, there's
no point in comparing the data to known values.
The reason all zeros or all ones is a reasonable test is that the data
goes through a scrambling process and is recorded with a DC-free code.
No matter what your write, there ends up being a mix of pit lengths.
(You could construct a pathological case, but it would actually be
quite hard to do so and to write it with any guarantee that it comes
out the way you expect.)
Eric
3:02 p.m.
On Wed, 2005-03-16 at 14:17 -0800, Eric Smith wrote:
Scott wrote:
Actually you want to find patterns (and they do exist) that are
pathological (ie worst case) for the encoder/decoder *and* for the error
correction being used.
Data CDROMs use an 8-14 encoding and 2 CIRSC's (Cross Interleaved Reed
Soloman Codes) for error correction.
An aspect of this is that the error correction that is chosen is
(usually) based on the type and frequency of errors you expect (ie
single random bits, runs of bad bits, etc). Things get dicey when the
errors being encountered aren't what the original design anticipated.
--
TTFN - Guy
The phenomenon of failure from the outside in has
interesting
possibilities-
have software write a known pattern in the outermost section of the disc
and
pop up a warning when it starts to deteriorate. Hopefully this would give
enough time to move data to another disk.
It doesn't have to be a known pattern. There's so much error correction
going on that as soon as you start detecting read errors (i.e., so many
errors that the error correction fails), you know you've got problems.
Writing all zeros, all ones, alternating bits or bytes, or random bits
would all work equally well for this test, and if they read at all, there's
no point in comparing the data to known values.
The reason all zeros or all ones is a reasonable test is that the data
goes through a scrambling process and is recorded with a DC-free code.
No matter what your write, there ends up being a mix of pit lengths.
(You could construct a pathological case, but it would actually be
quite hard to do so and to write it with any guarantee that it comes
out the way you expect.)
4:01 p.m.
Guy wrote:
Actually you want to find patterns (and they do exist)
that are
pathological (ie worst case) for the encoder/decoder *and* for the error
correction being used.
Basically by the time the data has been through three layers of ECC with
interleave, the scrambler, and the EFM modulation, there's no way to
guarantee that your pathological pattern will actually be pathological,
because you don't know the initial phase relationship of any of the
stages. In a carefully controlled lab environment with support from
the design engineers you could do it, but as an end user of a black
box (commercial CD/DVD writer) you can't, even armed with copies of the
revelant standards, because you don't have enough visibility into
the black box.
By comparison, coming up with the pathological test cases for FM, MFM,
M2FM, RLL (1,7) and (2,7), etc. is a piece of cake.
For instance, one of the worst-case test patterns for MFM is the
repeating byte sequence 6D, B6, DB (hexadecimal), which generates
alternating short and long intervals between flux transitions with no
medium length intervals. Though most test programs just repeated the
first two bytes.
Eric
5:02 p.m.
On Wed, 2005-03-16 at 16:01 -0800, Eric Smith wrote:
Guy wrote:
Sure you do. You know every transformation will be performed on the
data to get it onto the media. And in the case of CDROMs I can say with
certainty that the state of all of the stages is explicitly known. The
derivation of the pathological pattern is based upon the transformations
that will be performed on it to get it onto the media. It doesn't
require *any* lab environment (just the right software and suitably
compliant hardware...ie a CDwriter that allows "raw" writes).
I've done this work. It's not easy and the math (finite fields) will
blow your mind but it is certainly possible (obviously, we have an
existence proof...the CDROMs themselves).
Actually you want to find patterns (and they do
exist) that are
pathological (ie worst case) for the encoder/decoder *and* for the error
correction being used.
Basically by the time the data has been through three layers of ECC with
interleave, the scrambler, and the EFM modulation, there's no way to
guarantee that your pathological pattern will actually be pathological,
because you don't know the initial phase relationship of any of the
stages. In a carefully controlled lab environment with support from
the design engineers you could do it, but as an end user of a black
box (commercial CD/DVD writer) you can't, even armed with copies of the
revelant standards, because you don't have enough visibility into
the black box.
By comparison, coming up with the pathological test cases for FM, MFM,
M2FM, RLL (1,7) and (2,7), etc. is a piece of cake.
Agreed, mainly because the error correction in CDROMs is very strong
(mainly because the raw error rate is relatively high). However, it
still amazes me that CDROMs work at all! A 1X CDROM has 6Mb/s at the
optical pickup (and don't start that it's 150KB/s or 170KB/s because
both of those numbers are wrong)!
For instance, one of the worst-case test patterns for MFM is the
repeating byte sequence 6D, B6, DB (hexadecimal), which generates
alternating short and long intervals between flux transitions with no
medium length intervals. Though most test programs just repeated the
first two bytes.
Yes, simple interfaces with little error correction have simple
pathological patterns.
--
TTFN - Guy
5:43 p.m.
Guy wrote:
It doesn't
require *any* lab environment (just the right software and suitably
compliant hardware...ie a CDwriter that allows "raw" writes).
I was assuming a "normal" CD-writer, which can't be assumed to
support raw writes. Many CD-writers don't, and some that do claim
to support raw writes do so incorrectly.
If you can do raw writes, you can guarantee the alignment of the
"data" to the subcode framing. Otherwise (with a non-raw-write-capable
drive, you cannot, and thus you can't predict the complete details
of the actual EFM sequence that will be written to disc. Though to
be fair, that only will affect 14 channel code bits out of every 1372.
But even after you've done all that, you're not going to find a way to
generate any channel data pattern that is significantly more succeptible
to externally induced error (e.g., oxidation) than what you will get
from random data. That was my original point.
I've done this work.
Why?
I hacked my own software to read a CD based on raw preamp output, in
order to investigate copy-protected discs, but what would the point
be in developing anything that could generated a desired EFM channel
pattern from application-level data, unless you were developing or
validating a CD writer?
Eric
5:59 p.m.
On Wed, 2005-03-16 at 17:43 -0800, Eric Smith wrote:
Guy wrote:
The one's I've used have done a reasonably good job of it. In many
cases it's the software that gets it wrong.
It doesn't
require *any* lab environment (just the right software and suitably
compliant hardware...ie a CDwriter that allows "raw" writes).
I was assuming a "normal" CD-writer, which can't be assumed to
support raw writes. Many CD-writers don't, and some that do claim
to support raw writes do so incorrectly.
If you can do raw writes, you can guarantee the alignment of the
"data" to the subcode framing. Otherwise (with a non-raw-write-capable
drive, you cannot, and thus you can't predict the complete details
of the actual EFM sequence that will be written to disc. Though to
be fair, that only will affect 14 channel code bits out of every 1372.
Yep.
But even after you've done all that, you're
not going to find a way to
generate any channel data pattern that is significantly more succeptible
to externally induced error (e.g., oxidation) than what you will get
from random data. That was my original point.
It was a while ago (1997). A certain company (who shall remain
nameless) said that certain things w.r.t. CDROMs could only be done with
their media and their writers. I took that as a challenge and was able
to reproduce what they were doing with generic media and writers that
were available. It required that I delve deeply into how the CDROM
format worked and specifically the Reed-Soloman codes (since I was
writing "raw", the writer wouldn't generate them, so I had to). I was
able to write whatever I wanted (well there were limits) onto the CDROM.
Even after I had done this and showed that my results were identical to
theirs, I had their engineers telling me that it was impossible.
Which only goes to prove: "The possible we do immediately, the
impossible takes a little longer".
--
TTFN - Guy
I've done this work.
Why?
I hacked my own software to read a CD based on raw preamp output, in
order to investigate copy-protected discs, but what would the point
be in developing anything that could generated a desired EFM channel
pattern from application-level data, unless you were developing or
validating a CD writer? 
17 Mar
17 Mar
4:19 p.m.
Guy Sotomayor wrote:
Along with 2 quotes I always liked :
'Nothing is impossible -- apart from ski-ing through a revolving door'
and
'Somebody these days claiming something is impossible is apt to be
interrupted by some fool doing it'
-tony
Which only goes to prove: "The possible we do
immediately, the
impossible takes a little longer".
Well lets get the quote right.
"The difficult we do right away...the impossible takes slightly longer."
Philo T. Farnsworth -- inventor of television.
7220
days inactive
7222
days old
8 comments
5 participants
participants (5)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
eric＠brouhaha.com -
ggs＠shiresoft.com -
Saquinn624＠aol.com