Rotating memory data recovery

From: John Lawson <>
Date: Sat Sep 11 21:24:26 2004

On Sat, 11 Sep 2004, Tom Jennings wrote:

> On Sat, 2004-09-11 at 14:42, John Lawson wrote:
> I was assuming PC audio cards would not be fast enough. I am an analog
> person too, but not to your extent of expertise.

   What can the actual drum clock be... I dunno... another reason to slow
the drum; see below further...

> The disk has one (or a few) timing tracks. I assumed I would record the
> timing track plus a data track; hence all recordings would have a
> reference. A stereo sound card would do this. There's no physical index
> pulse, it's derived from disk data. I haven't looked at the timing data
> for over a year, I need to RTFM before I open my mouth any more.

   If you could trigger a simple pulse to SMPTE converter, and if the data
rate of the "index" pulse is slow enough, then your synce problems get
solved... SMPTE can resolve 30/100 of a second, BTW - 100 'subframes'
per video frame at 30fps - the highest video rate SMPTE was designed for.
  And yes, the FM needs to be consulted.

[Aside: I always wanted to have a manual entitles: "The Book of

>> if you
>> could get a 'whole drum after this pulse' (sort of like capturing one
>> video frame) sync set up, then you could record each track onto a similar
>> parallel track in the DAW....
> 1) I figured I could capture N seconds, to get N * 1/RPM copies of data,
> and pick the timing::data out.
> 2) What's "DAW"?

  Sorry. Digital Audio Workstation. I lapsed into AudioSpeak by habit.

> Another choice is to simply disable writing electrically, and use the
> computer itself. The biggest worry (at this point) is head/platter
> issues. THe heads contact at rest, then lift. The mechanical issues
> exist no matter the data-recovery method.

Yeah. I'd intercept the 'lift' line and do that manually. before spin-up,
if this is at all possible.

> Well the problem as I see it is deterioration of the magnetic
> surface/circuit, and changing motor speed won't improve that (probably).
> Lost data is secondary to a lost timing track! That would be ruinous, I
> have no idea how I'd re-create that. Certainly, I need a copy of that.

   On a system this old, with (relatively) large data tracks, I think that
there would probably be recognizable pulses at slower speeds...

  Anyway, just Thoughts...


Received on Sat Sep 11 2004 - 21:24:26 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:29 BST