home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / rec / audio / 15036 < prev    next >
Encoding:
Text File  |  1992-11-12  |  1.6 KB  |  34 lines
  1. Newsgroups: rec.audio
  2. Path: sparky!uunet!comp.vuw.ac.nz!canterbury.ac.nz!betelgeux!deanaj
  3. From: deanaj@elec.canterbury.ac.nz (A. J. Dean)
  4. Subject: Re: Defeating SCMS
  5. Message-ID: <Bxn2x7.61@cantua.canterbury.ac.nz>
  6. Nntp-Posting-Host: betelgeux.canterbury.ac.nz
  7. Organization: Electrical Engineering, University of Canterbury, New Zealand
  8. X-Newsreader: TIN [version 1.1 PL6]
  9. References: <1992Nov11.023239.2744@nntpd2.cxo.dec.com>
  10. Date: Fri, 13 Nov 1992 05:22:18 GMT
  11. Lines: 21
  12.  
  13. Paul S. Winalski (winalski@adserv.enet.dec.com) wrote:
  14. : No.  Wenever a consumer DAT deck that enforces SCMS records from its analog
  15. : inputs, it writes a SCMS code of 11 onto the resulting DAT.  The analog input
  16.  
  17. When they do something that stupid they're asking for it to be broken.
  18. Perhaps the DAT manufacturers deliberately made SCMS worse than it needed to
  19. be just so that the necessary little black boxes will proliferate, and the
  20. SCMS will simply 'cease to exist' in a virtual sense once supply and demand
  21. has taken care of things. And perhaps timed perfectly for when DAT comes
  22. into its own, like PCs did when people realised how easy it was to copy
  23. software _especially_ when there was the additional excitement of using your
  24. new protection disabling thingie... Or would such collective cunning be
  25. impossible in the manufacturing industry!
  26.  
  27. Defeating SCMS seems pretty simple to me - remember your first "Hi there"
  28. program? I rekon I could do it with a few PLLs and some delays. Perhaps in
  29. years to come people will have little competitions thinking up the most
  30. obscure ways to defeat SCMS. Hey, a mechanical design (cogs and all) would
  31. be neat.
  32.  
  33. Antony.
  34.