[Table of Contents]


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ARSCLIST] Mass Digitization



There would certainly be numerous technology possibilities here - automation, meta-data,
work-flow, storage systems, etc...

Something for everyone!

Rob Poretti
Sascom - Toronto
vox.905.825.5373    fax.905.469.1129     cel.905.580.2467
www.sascom.com    www.cube-tec.com


> -----Original Message-----
> From: Association for Recorded Sound Discussion List 
> [mailto:ARSCLIST@xxxxxxx] On Behalf Of Marcos Sueiro
> Sent: May 15, 2007 2:09 PM
> To: ARSCLIST@xxxxxxxxxxxx
> Subject: Re: [ARSCLIST] Mass Digitization
> 
> 
> It seems to me that a "Mass Digitisation" panel/session would 
> be a good 
> thing for our next conference. Perhaps someone could update 
> us on things 
> like SAMMA, the PrestoSpace project, and things of that sort. 
> I agree, 
> it really is the only way to go.
> 
> Cheers
> 
> Marcos
> 
> Andes, Donald wrote:
> >  
> > Jim,
> > 
> > Let me add a positive retort here, (before the waves of 
> negative ones 
> > begin)....
> > 
> > I agree with you 100% that most in the archival world are 
> focusing on 
> > the wrong issues, or maybe have been lingering on the same problems 
> > for too long. The issue in my mind is scale because most in the 
> > archival industry are seeing a box, or room full of tapes, and have 
> > not had the opportunity to see over 1 million assets in a single 
> > location, nor contemplated what to do with them.
> > 
> > As the Director of Archives for EMI, I look at all the 
> assets under my 
> > control (over 1 million, just in North America), and think 
> to myself: 
> > "How much sense does it make to preserve these assets in these 
> > formats, when the machines, engineer knowledge base, and 
> media itself 
> > if deteriorating."
> > 
> > Once you scale out and see the big picture, you start to see the 
> > REALLY big problem. If we (the archival industry) can't get a 
> > digitization schema to be cost effective, we simply won't get the 
> > funds to digitize. Worse, if someone outside the archival industry, 
> > gets "their" plans in motion, you can rest assure that it 
> will not be 
> > done anywhere near correct.
> > 
> > As you know, the barriers to digital migration are also far more 
> > complex than the real time transfer that it involves (even if we're 
> > using SAMMA
> > "robots".) Digital files take error checking, redundant 
> copies, naming
> > conventions, metadata collection, metadata hierarchy standards, etc.
> > Figuring all this out UP FRONT, makes for a daunting task 
> that I will
> > venture to say, takes a completely different skill/mind set 
> than analog.
> > Unfortunately people don't change, and no matter how many positive
> > reasons you give to migrate, those entrenched in analog will want to
> > stay there.
> > 
> > I believe there should be communal, parallel thinking in regards to 
> > mass digitization strategies, metadata collection and so 
> forth. I am 
> > aware of library groups focusing specifically on metadata, 
> but I have 
> > my own concern with their focus, and priorities in regards to 
> > collecting metadata on A/V assets.
> > 
> > I'm available for dialog on this topic, and I would hope 
> that others 
> > on the list may open minded enough as well.
> > 
> > 
> > Don Andes
> > Director of Archives
> > EMI Music
> > 
> > 
> > 
> > -----Original Message-----
> > The point is that Analog is over, and the sooner we get to 
> the really 
> > hard job of developing cost effective mass migration techniques to 
> > save the vast corpus the better. Now some of you may say my 
> statements 
> > are self-serving - and I will fully and freely admit that I have 
> > worked very hard to develop these techniques and have worked to 
> > commercialize them - but I do not see any other way to save the 
> > content, and I have been successful in driving the price lower and 
> > lower using new technology. But - we are just one company - and we 
> > need help - yes we need competition because THE point is to 
> save the 
> > content - and to do that - we need to be thinking differently. The 
> > problem is not how do we stop a single troublesome tape 
> from squeaking 
> > - the problem is how do we migrate the millions of recordings fast 
> > enough and cost effective enough and good enough - for the 
> future. I 
> > don't see much of that going on - and it deeply concerns 
> me. We need 
> > more people thinking this way - I want to read about 
> techniques that 
> > can be applied to thousands of tapes that will allow fast and cost 
> > effective transfer. This is something that we ALL need to work on - 
> > the collective brains and expertise on this list and others 
> needs to 
> > focus - we can differ in our individual philosophies but 
> please let us 
> > not get so distracted by esoteric un- scaleable treatments, that we 
> > forget the whole point. Which is - to save the stuff. I am 
> sad to say 
> > that collectively - all of us (including me)- have not been doing a 
> > very good job - we need to do MUCH better. We need to work 
> together - 
> > and smarter. The risk of loss is simply too great.
> > 
> > Ok - I am done - and I am running,,,,
> > 
> > Jim Lindner
> > 
> > Email: jim@xxxxxxxxxxxxxxxxx
> > 
> >    Media Matters LLC.
> >    SAMMA Systems LLC.
> >    450 West 31st Street 4th Floor
> >    New York, N.Y. 10001
> > 
> > eFax (646) 349-4475
> > Mobile: (917) 945-2662
> > Office: (212) 268-5528
> > 
> > www.media-matters.net
> > Media Matters LLC. is a technical consultancy specializing 
> in archival 
> > audio and video material. We provide advice and analysis, to media 
> > archives that apply the beneficial advances in technology to 
> > collection management.
> > 
> > www.sammasystems.com
> > SAMMA Systems provides tools and products that implement 
> and optimize 
> > the advances in modern technology with established media 
> preservation 
> > and access practices.
> > 
> > 
> > On May 14, 2007, at 1:59 PM, Richard L. Hess wrote:
> > 
> >> At 07:48 AM 2007-05-14, Tom Fine wrote:
> >>> Hi Konrad:
> >>>
> >>> Some of what this guy says is simply not right about sticky-shed.
> >>> I can't comment on his "cure". I'll stick with baking 
> tapes, which is
> > 
> >>> proven to work.
> >>>
> >>> I'm hoping Richard Hess posts a long missive on this one. 
> With this
> >>> topic well-addressed many other places, I wonder why so much 
> >>> mythology persists?
> >> Hello, Tom, Konrad,
> >>
> >> Peter Brothers has posted an excellent hypothesis as to why the
> >> chemical technique may work. If we consider that the short 
> (broken) 
> >> chains which is the lower molecular weight, sticky stuff ends up 
> >> partially adsorbing to the magnetic particles when water is driven 
> >> out, then this mystery chemical could also be a water 
> "magnet" and can
> > 
> >> pull the water out of the coating allowing sites for the 
> short chains
> >> to adsorb. This is consistent with the baking process.
> >>
> >> We certainly have seen tapes suffering from binder 
> hydrolysis -- what
> >> I'm starting to call "Soft Binder Syndrome" (SBS). With non- 
> >> back-coated tapes there is a large population (not 100%, 
> but close) 
> >> that do not respond to baking. These are the SBS without SSS tapes.
> >> We used to call them "loss of lubricant" (LoL) until we found out 
> >> there was still ample lubricant in the tapes.
> >>
> >> What we are seeing with the non-back-coated tapes that 
> have SBS (and
> >> squeal) is that they are in a rubbery phase at room temperature 
> >> because the breakdown of the polymers has caused the 
> temperature at 
> >> which the surface turns from smooth to rubbery (called the GLASS 
> >> TRANSITION TEMPERATURE or Tg) has fallen to below room 
> temperature. 
> >> What we do in these cases is play the tapes with the tape and the 
> >> player below the current Tg of the tape.
> >>
> >> Measuring Tg is not easy -- you need to measure the Youngs 
> Modulus of
> >> the Coating (alone not on the basefilm) at various 
> temperatures and 
> >> from that plot you can extract the Tg.
> >>
> >> It all comes down to the tapes decaying and for all of the
> >> polyester-polyurethane tapes it appears that moisture is 
> the catalyst 
> >> for the breakdown -- hence as Peter says, it's all hydroysis.
> >>
> >> Incubation/baking appears to cause enough movement in the 
> tape pack 
> >> to
> > 
> >> break the layer-to-layer bonds that form under pressure (especially
> >> near the hub) that causes pinning and pullouts. I have 
> found that slow
> > 
> >> (1.88 in/s) playback of the tape also helps in that regard.
> >>
> >> I think our goal here is to use reliable, tested processes and
> >> digitize the content. I spent a substantial amount of 
> effort working 
> >> on tapes that squealed and did not respond to baking. My 
> cold playing 
> >> technique (which I encourage all of you to try and respond back) 
> >> should, in theory, work with SSS tape as well as SBS (and 
> I suggest 
> >> that SSS is a subset of SBS), but the massive amounts of debris 
> >> generated by the backcoat/magcoat combination overwhelms the 
> >> capability of cold playback (at least right now) and at pro play 
> >> speeds, pullout is exacerbated due to the bonding between 
> backcoat and
> > 
> >> magcoat.
> >>
> >> I do not think we've yet seen a documented case of LoL so 
> thankfully
> >> that myth is being put to bed. We used to think the squealing Sony 
> >> PR-150 and 3M 175 was LoL, but we now see that it is SBS. 
> By the way, 
> >> the Tg of one sample of 175 was about +8C or about 46F.
> >>
> >> Keeping polyester polyurethane tapes dry (<40% RH) is a good way to
> >> keep them feeling OK. I had a non-backcoated tape of this 
> type that 
> >> had been peaking at 75% RH in storage "heal" after three months 
> >> storage at about 40% RH.
> >>
> >> By the way, it is approximately a minute:day relationship between
> >> thermal and moisture equilibrium--or at least that's a 
> convenient way 
> >> to think of it. In other words if a tape takes 90 minutes to reach 
> >> thermal equilibrium throughout the pack, then it takes 90 days to 
> >> reach moisture equilibrium. This is based on work with 1- 
> inch tapes 
> >> so 1/4-inch tapes might not be as bad, but it seems to match my 
> >> experience.
> >>
> >> My AES paper cites the reference for that.
> >>
> >> In general, I am less happy with a chemical approach than a
> >> physical/state approach (within limits) to the SBS/SSS problem as 
> >> there is a great chance of unknown, long-term damage from 
> any chemical
> > 
> >> approach. With that said, I have tried approaches to SBS 
> based on the
> >> LoL hypothesis and they were abysmal failures.
> >>
> >> Konrad: we did have a belated success in your neck of the 
> woods with
> >> playing a tape in a fridge. Paul or Mike have the details. 
> I think it 
> >> needed 48 hours of cold soak before it played.
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >>
> >> Richard L. Hess                   email: richard@xxxxxxxxxxxxxxx
> >> Aurora, Ontario, Canada       (905) 713 6733     1-877-TAPE-FIX
> >> Detailed contact information: http://www.richardhess.com/tape/
> >> contact.htm Quality tape transfers -- even from hard-to-play tapes.
> > 
> > - 
> --------------------------------------------------------------------
> > 
> > 
> > 
> > 
> > Music from EMI
> > 
> > This e-mail including any attachments is confidential and may be 
> > legally privileged. If you have received it in error please 
> advise the sender immediately by return email and then delete 
> it from your system. The unauthorised use, distribution, 
> copying or alteration of this email is strictly forbidden. If 
> you need assistance please contact us on +44 20 7795 7000.
> > 
> > This email is from a unit or subsidiary of EMI Group plc.
> > 
> > Registered Office: 27 Wrights Lane, London W8 5SW
> > 
> > Registered in England No 229231.
> > 
> > 
> > - 
> --------------------------------------------------------------------
> 
> -- 
> Marcos Sueiro Bal
> Audio/Moving Image Project Archivist
> Preservation Division
> Columbia University Libraries
> 
> 


[Subject index] [Index for current month] [Table of Contents]