Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-141.txt

Text File | 1994-12-08 | 35.7 KB | 935 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 13 Jul 92       Volume 1 : Issue 141

Today's Topics:

    Dynamic Runtime Method Dispatch
    Function or Procedure Type
    Audio CD File Format



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

These digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (P. Hawthorne)
Subject: Dynamic Runtime Method Dispatch
Date: 11 Jun 92 05:53:37 GMT
Organization: Reed College, Portland, Oregon


  P. Hawthorne wonders:
: What good is inheritance without dynamic runtime method dispatch?

  Larry Rosenstein answers:
: What Kent is referring to is the ability to send any message to any object.
: The price for this flexibility is that the message might not be
: understood by the object, and that the dispatching is a bit slower.

  Objective C has apparently adequately addressed both concerns. From
playing fly on the wall in NeXT groups, it sounds to me like there is a
means of determining whether or not a given object understands a given
message, a default method is called when an object is sent a message that
it does not understand, and there are only eight instructions for a method
call. However, I am guessing that the size of their dispatch table can get
pretty big fast.

  Perhaps my intent was not expressed clearly enough. My point was that
inheritance is not nearly as useful without runtime dispatch. A case could
be made that without runtime dispatch, classes become mere placeholders for
code, rather than a functional model of an adaptive system.

  While inheritance permits one to specialize a class in a descendant
class, runtime dispatch permits that class to subsume roles nominally
assigned to the superclass, whenever and wherever circumstances dictate.

  For instance, suppose you have a class for a graph, a subclass for an
adjacency matrix representation and another subclass for an adjacency list
representation. Suppose further that the graph tends to become sparse or
dense as the application runs, making one representation more suited than
the other. Without runtime dispatch, the object could not adapt, and the
resource bounds for methods could be exponential rather than linear.

  Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 11 Jun 92 17:50:05 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (P. Hawthorne)
writes:
>
>   Objective C has apparently adequately addressed both concerns. From
> playing fly on the wall in NeXT groups, it sounds to me like there is a
> means of determining whether or not a given object understands a given
> message, a default method is called when an object is sent a message that
> it does not understand, and there are only eight instructions for a method

I don't know about the number of instructions, but the other stuff is true.
(I'm skeptical that it's as low as 8 in the general case, and I'd be interested
to hear an outline of the exact algorithm.)  In addition, you have the option in
Objective C of using typed objects, which improves dispatching performance at
the cost of less flexibility (I think).

>   For instance, suppose you have a class for a graph, a subclass for an
> adjacency matrix representation and another subclass for an adjacency list
> representation. Suppose further that the graph tends to become sparse or
> dense as the application runs, making one representation more suited than
> the other. Without runtime dispatch, the object could not adapt, and the

There's no reason why you can't do this in C++.  The graph object can delegate
to the appropriate implementation object and change its implementation
dynamically.  I don't see how the dispatching features of Objective C or
Smalltalk would make this any easier.
- --
Larry Rosenstein
Taligent, Inc.
[e-mail]


---------------------------

From: [e-mail] (Christophe Dubreuil)
Subject: Function or Procedure Type
Date: 11 Jun 92 09:18:47 GMT
Organization: CERT, CS Dpt. Toulouse, France


A novice question about Macintosh Pascals (Think and MPW) :

 "Is it possible to pass function, procedure, or methods)
  as a parameter in a procedure, function, or method
  call. And moreover to memoruize it inside a variable
  to recall it later.

  example:

    TSequenceableCollection : Object(Collection)
        data : ....
        order : function (a,b):Boolean
    end;

    I want to be able to initialize order with any
    function, or methods returning a boolean. And
    to be able to call it when I want to insert
    elements in data.
 "

Any Hints ???

Christophe Dubreuil

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 12 Jun 92 18:08:44 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Christophe Dubreuil) writes:

> A novice question about Macintosh Pascals (Think and MPW) :
And a minute's silence for TML, everybody. :-)

>  "Is it possible to pass function, procedure, or methods)
>   as a parameter in a procedure, function, or method
>   call. And moreover to memoruize it inside a variable
>   to recall it later.

Standard Pascal includes the ability to pass a routine (procedure or function)
as an argument to a routine. However, there are no procedure or function
types in Pascal as such, so you can't save such routines in a variable.
You'll find the details about passing routines as arguments somewhere in
your language manual; I can't remember them offhand, and frankly I can't
be bothered with them, as I prefer the following--admittedly more dangerous--
but much more flexible, technique: namely, get the address of the routine
with the "@" prefix operator, pass it around as a value of type ProcPtr
(which you can save in a variable if you want), and invoke it via an inline.

Example: a generic sort procedure which will operate on any kind of data
(whether in memory or on disk), and sort it according to any ordering
you specify. When you call it, you pass it a function for comparing two
records, and a procedure that does the actual record swapping. The sort
procedure itself refers to the records only by their index number; it leaves
all the actual data accesses to your action routines.

The interface to the sort procedure looks like this:

    Type
    ComesBeforeProc = { does First come before Second in the sorted list }
      { Function
          (
        First : Longint;
        Second : Longint;
        Arg : Ptr
          ) : Boolean }
        ProcPtr;
    SwapProc = { swaps the elements identified by First and Second }
      { Procedure
          (
        First : Longint;
        Second : Longint;
        Arg : Ptr
          ) }
        ProcPtr;

    Procedure Sort
      (
    NrElements : Longint;
    ComesBefore : ComesBeforeProc;
    ComesBeforeArg : Ptr;
    Swap : SwapProc;
    SwapArg : Ptr
      );

ComesBeforeArg is an extra argument passed on every call to the
ComesBeforeProc, and similarly SwapArg with the SwapProc; the meanings
of these additional arguments is up to the caller.

Within the Sort routine, you would invoke these action routines with the
help of the following inlines:

    Function CallComesBefore
      (
        First : Longint;
        Second : Longint;
        Arg : Ptr;
        ComesBefore : ComesBeforeProc
      ) : Boolean;

        Inline
        $205F,    { move.l (sp)+, a0 }
        $4E90;    { jsr (a0) }

    Procedure CallSwap
      (
        First : Longint;
        Second : Longint;
        Arg : Ptr;
        Swap : SwapProc
      );

        Inline
        $205F,    { move.l (sp)+, a0 }
        $4E90;    { jsr (a0) }

Note that in every case, the argument list is identical to that you want
to pass to the routine, with the routine address added as an extra argument
at the end. The actual inline code itself is always the same (after many
years of programming in Pascal on the Mac, it's been burned into my brain!).

Here's the body of the Sort routine (it's a Shellsort algorithm, by the way):

     Begin {Sort}
    i := 1;
    While i < NrElements do
        i := i + i;
    m := bsr(i - 1, 1);
    While m > 0 do
      Begin
        k := NrElements - m;
        For j := 1 to k do
          Begin
        i := j;
        Repeat {until left}
            l := i + m;
            If CallComesBefore(i, l, ComesBeforeArg, ComesBefore) then
            Leave;
            CallSwap(i, l, SwapArg, Swap);
            If i <= m then
            Leave;
            i := i - m
        Until
            false
          End {For};
        m := bsr(m, 1)
      End {While}
      End {Sort};

And finally, here's a very quick example of how to use it:

    Const
    MyNrElements = 100;
    Var
    MyArray : array [1 .. MyNrElements] of integer;

    Function MyCompare
      (
           First, Second : Longint;
    Unused : Ptr
      ) : Boolean;

      Begin
    MyArray[First] < MyArray[Second] { change "<" to ">" to sort in reverse order }
      End {MyCompare};

    Procedure MySwap
      (
           First, Second : Longint;
    Unused : Ptr
      );

    Var
        Temp : integer;

      Begin
    Temp := MyArray[First];
    MyArray[First] := MyArray[Second];
    MyArray[Second] := Temp
      End {MySwap};

...

  { the actual call: }
    Sort
      (
    {NrElements :=} MyNrElements,
    {ComesBefore :=} @MyCompare,
    {ComesBeforeArg :=} Nil,
    {Swap :=} @MySwap,
    {SwapArg :=} Nil
      )

The biggest problem with this technique is that it's not typesafe; there's
nothing to prevent you from calling a routine that requires one sort of
argument list with an argument list of completely the wrong type.

Another thing you can do, of course, if you don't want to give up the
typesafeness of Pascal, is switch to Modula-2. :-)

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

---------------------------

From: [e-mail] (Andrew E Page)
Subject: Audio CD File Format
Date: 13 May 92 14:36:43 GMT
Organization: The World Public Access UNIX, Brookline, MA


    With a CD-ROM drive it is possible to insert an Audio CD and
have the 'tracks' come up as files.  I'm looking at doing some signal
processing experiments with audio and would like to make use of some
of these files as sample data.  Can anyone point me to a document that
will specify what kind of format the audio data in these files is in?

- --
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Jon Rowlands)
Organization: Texas Instruments, SPDC, DSP Technology Branch, Dallas
Date: Wed, 13 May 1992 17:46:41 GMT

In article <[e-mail]>, [e-mail] (Andrew E Page)
writes:
|>     With a CD-ROM drive it is possible to insert an Audio CD and
|> have the 'tracks' come up as files.  I'm looking at doing some signal
|> processing experiments with audio and would like to make use of some
|> of these files as sample data.  Can anyone point me to a document that
|> will specify what kind of format the audio data in these files is in?

I asked a similar question a while back in the cdrom newsgroup. The
short answer is that nearly all CD-ROM drives specifically prevent
reading the audio samples on a normal CD in digital format, for
copyright reasons. You can only access the catalog information.

The only known exception to this is the CD-ROM drive in the Silicon
Graphics 'Indigo' machine, which does allow access to the sample
data.

Jon
- --
Jon Rowlands            email: [e-mail]
Texas Instruments        phone: [phone]
SPDC, DSP Technology Branch      fax: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 14 May 92 14:54:22 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Andrew E Page) writes:
>
>     With a CD-ROM drive it is possible to insert an Audio CD and
> have the 'tracks' come up as files.  I'm looking at doing some signal
> processing experiments with audio and would like to make use of some
> of these files as sample data.  Can anyone point me to a document that
> will specify what kind of format the audio data in these files is in?

Unfortunately, those files are nothing more than "dummies"--they don't
contain any data at all! I recall seeing a utility from Apple that,
when you asked it to open one of those files, would send the appropriate
control commands to the CD drive to play the corresponding audio track.
That's all those files are for.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Terry Weymouth)
Date: 20 May 92 14:16:46 GMT
Organization: University of Michigan Engineering, Ann Arbor


>[e-mail] (Andrew E Page) writes:
>|> I'm looking at doing some signal processing experiments...
>rowlands@ra (Jon Rowlands) replies:
>...You can only access the catalog information.

How about playing the CD into a digitizer (as in MacRecorder). Has anyone
tried this (and lived to tell)?

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 22 May 92 02:57:28 GMT
Organization: Apple Computer, Inc.

In article <0f5+d##@engin.umich.edu>, [e-mail] (Terry Weymouth) writes:
>
>
> >[e-mail] (Andrew E Page) writes:
> >|> I'm looking at doing some signal processing experiments...
> >rowlands@ra (Jon Rowlands) replies:
> >...You can only access the catalog information.
>
> How about playing the CD into a digitizer (as in MacRecorder). Has anyone
> tried this (and lived to tell)?

All the time.  In fact every Mac that has built-in sound input hardware
comes with a cable attachment to do exactly what you're asking about.  Theres
a mini phono plug that goes to a pair of RCA female jacks.  This is also
an impedence matcher for the signals that come out of the CD ROM player.

Just use the adapter to plug into the input jack of the back of the Mac,
and then use a pair of stereo cables to go from the back of the CD player
into the adapter.  Also, if you're using a 3rd party digitizer such as the
MacRecorder it has a line input.  Use a RCA to mini phono cable which will
also combined the stereo signals into mono.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 27 May 92 15:24:11 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jim Reekes) writes:

>Just use the adapter to plug into the input jack of the back of the Mac,
>and then use a pair of stereo cables to go from the back of the CD player
>into the adapter.  Also, if you're using a 3rd party digitizer such as the
>MacRecorder it has a line input.  Use a RCA to mini phono cable which will
>also combined the stereo signals into mono.

Whenever the new sound manager is finished, will we then be able to read in
the audio cd data directly since the new sound manager will support 16 bit
audio? "Damn it, Jim!" (using my best Dr. McCoy voice) I'm sure its a simple
hack you can throw in over a weekend. :-) Actually you probably already did
it.

 I want my "MacCD!"

Matt



- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Date: 2 Jun 92 18:18:44 GMT
Organization: Visix Software Inc., Reston, VA

[e-mail] (Matt Mora) writes:
> Whenever the new sound manager is finished, will we then be able to read in
> the audio cd data directly since the new sound manager will support 16 bit
> audio?

No.  The problem is not the sound manager.

THE PROBLEM IS THE CD DRIVE.  The *only* CD-ROM drive I know of which will
deliver raw digital audio data over the SCSI bus is the one shipped by Silicon
Graphics.  It is a Toshiba drive with custom ROM code which was developed by
Toshiba for SGI.  I understand that Toshiba is allowed to sell the audio data
support to third parties, but I do not think that they have done so yet.

If someone is keep a FAQ list, this should go into it.

Amanda Walker                        [e-mail]
Visix Software Inc.                     [phone]
- --
"It is impossible for human nature to believe that money is not there. It seems
 so much more likely that the money is there and only needs bawling for."
        --Dorothy L. Sayers, _Busman's Honeymoon_

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 3 Jun 1992 15:24:00 GMT

[e-mail] (Amanda Walker) writes:

>[e-mail] (Matt Mora) writes:
>> Whenever the new sound manager is finished, will we then be able to read in
>> the audio cd data directly since the new sound manager will support 16 bit
>> audio?
>THE PROBLEM IS THE CD DRIVE.  The *only* CD-ROM drive I know of which will
>deliver raw digital audio data over the SCSI bus is the one shipped by Silicon
>Graphics.  It is a Toshiba drive with custom ROM code which was developed by
>Toshiba for SGI.  I understand that Toshiba is allowed to sell the audio data
>support to third parties, but I do not think that they have done so yet.

What should be possible (now) is to take the optical digital out available
on many consumer-level CD players and read the raw digital data. The bandwidth
required (~170k/sec) is such that it'd probably have to be a Nubus or SCSI
device that does the "digitizing" (I know LocalTalk does 230k/sec out of the
serial port, but it hogs the machine to a large extent, and we'd like to be
able to write the data to disk as we go, too). Has anyone heard of someone
working on a device like this?

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 3 Jun 92 15:36:48 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Amanda Walker) writes:
>[e-mail] (Matt Mora) writes:
>> Whenever the new sound manager is finished, will we then be able to read in
>> the audio cd data directly since the new sound manager will support 16 bit
>> audio?

>No.  The problem is not the sound manager.

>THE PROBLEM IS THE CD DRIVE.  The *only* CD-ROM drive I know of which will
>deliver raw digital audio data over the SCSI bus is the one shipped by Silicon

THAT SUCKS! Did Apple drop the ball again? Is this the fault of the hardware
and not the driver? You would think that Apple would have had the fore sight
to create a drive that can read audio data. Or is this some evil plot by
the recording industry from preventing me from making perfect CD copies
using my mac. :-)





- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (David E. Sappington)
Date: 3 Jun 92 20:00:54 GMT
Organization: University of Virginia

[e-mail] (Amanda Walker) writes:
>No.  The problem is not the sound manager.
>
>THE PROBLEM IS THE CD DRIVE.  The *only* CD-ROM drive I know of which will
>deliver raw digital audio data over the SCSI bus is the one shipped by Silicon

[e-mail] (Matt Mora) writes:
>
>THAT SUCKS! Did Apple drop the ball again? Is this the fault of the hardware
>and not the driver? You would think that Apple would have had the fore sight
>to create a drive that can read audio data. Or is this some evil plot by
>the recording industry from preventing me from making perfect CD copies
>using my mac. :-)
>

Don't laugh.  For some time Apple, Inc. (the mac people) was restricted by
Apple Corp. (the old Beatles record company) from making computers that
were too musically inclined.  With the MIDI Manager and talk of 16-bit audio
Apple Corp was beginning to feel a bit litigous.  I believe that some sort
of settlement was reached last year (vague recollection of a MacWeek
article).

For those in the know, pardon my possible butchering of the facts.  Of
course this might not have anything to do with Apple's CD-DRIVE (at least now)
but you never know..... [hmmmm]

Dave Sappington                     [e-mail]
Institute for Parallel Computation  [e-mail]
University of Virginia

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 4 Jun 92 05:18:27 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Mora) writes:
> In article <[e-mail]> [e-mail] (Amanda Walker) writes:
> >[e-mail] (Matt Mora) writes:
> >> Whenever the new sound manager is finished, will we then be able to read in
> >> the audio cd data directly since the new sound manager will support 16 bit
> >> audio?
>
> >No.  The problem is not the sound manager.
>
> >THE PROBLEM IS THE CD DRIVE.  The *only* CD-ROM drive I know of which will
> >deliver raw digital audio data over the SCSI bus is the one shipped by Silicon
>
> THAT SUCKS! Did Apple drop the ball again? Is this the fault of the hardware
> and not the driver? You would think that Apple would have had the fore sight
> to create a drive that can read audio data. Or is this some evil plot by
> the recording industry from preventing me from making perfect CD copies
> using my mac. :-)

Actually I think it is an evil plot.  Those people are *very* sensitive
to copyright issues.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --  Makers of...        --   San Jose, California USA 95117
- --                      --   voice: [phone] fax: [phone]
- --     SMOOTHIE         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 4 Jun 92 07:58:52 GMT
Organization: Reed College, Portland, Oregon


  Amanda Walker, [e-mail], reveals:
. The *only* CD-ROM drive I know of which will deliver raw digital audio
. data over the SCSI bus is the one shipped by Silicon Graphics. It is a
. Toshiba drive with custom ROM code which was developed by Toshiba for
. SGI. I understand that Toshiba is allowed to sell the audio data support
. to third parties, but I do not think that they have done so yet.

  That's hot.

  I wonder if Toshiba has any English docs for the ROMs yet. I also wonder
if there are any of those drives already manufactured, in stock and ready
to ship that are not on their way to SGI.
  Anyone have a phone number?

  Toshiba sold submarine silencing tech to the Soviets in the Eighties,
I'll bet they'd be willing to sell SGI audio tech to Mac nerds now...

 (Guess I'm not earning any brownie points here, am I? ;^)

                            Theus
                        [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Andy Peterman)
Date: 4 Jun 92 18:17:36 GMT
Organization: The Treehouse

In article <[e-mail]-> [e-mail] (David E. Sappington) writes:
- ->[e-mail] (Amanda Walker) writes:
- ->>No.  The problem is not the sound manager.
- ->>
- ->>THE PROBLEM IS THE CD DRIVE.  The *only* CD-ROM drive I know of which will
- ->>deliver raw digital audio data over the SCSI bus is the one shipped by Silicon
- ->
- ->[e-mail] (Matt Mora) writes:
- ->>
- ->>THAT SUCKS! Did Apple drop the ball again? Is this the fault of the hardware
- ->>and not the driver? You would think that Apple would have had the fore sight
- ->>to create a drive that can read audio data. Or is this some evil plot by
- ->>the recording industry from preventing me from making perfect CD copies
- ->>using my mac. :-)
- ->>
- ->
- ->Don't laugh.  For some time Apple, Inc. (the mac people) was restricted by
- ->Apple Corp. (the old Beatles record company) from making computers that
- ->were too musically inclined.  With the MIDI Manager and talk of 16-bit audio
- ->Apple Corp was beginning to feel a bit litigous.  I believe that some sort
- ->of settlement was reached last year (vague recollection of a MacWeek
- ->article).

I think it goes beyond that!  About a year ago I was talking to one of
the CD ROM manufacturers (Toshiba, I think) and they said that we'd
never see the ability to read the raw audio data.  With all the fear the
record companies have created concerning direct digital copying, the
manufacturers don't want to even approach the issue and allow access to
the digital data.  I guess they fear that computer access to that data could
be a sticky copyright issue.  I suppose it would make it easy to steal
digital samples of sounds.

- --
Andy Peterman
treehouse![e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Fri, 5 Jun 92 13:09:41 GMT

In article <[e-mail]> [e-mail] (Matt Mora) writes:

>You would think that Apple would have had the fore sight
>to create a drive that can read audio data. Or is this some evil plot by
>the recording industry from preventing me from making perfect CD copies
>using my mac. :-)

Yes.

(Heck, even if it isn't true, the recording industry probably deserves
the blame somehow).
>
>--
>___________________________________________________________
>Matthew Mora                |   my Mac  [e-mail]
>SRI International           |  my unix  [e-mail]
>___________________________________________________________


- --
The essence of OOP: "With all this horse manure, I know there's got to be
                     a pony in here somewhere!"
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Fri, 5 Jun 92 13:27:32 GMT

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:

>
>  Toshiba sold submarine silencing tech to the Soviets in the Eighties,
>I'll bet they'd be willing to sell SGI audio tech to Mac nerds now...

Umm, I have no great love for Toshiba, but I wouldn't put the two
activities in the same class. I have nothing but hatred for copy-protection
schemes of any type (and yes, I do purchase the software I use). It seems
to me that making a drive which is incapable of reading the (digital) audio
information while perfectly capable of reading the digital info marked as
data is somehow ... intellectually dishonest? Leave the copyright issues to
the lawyers - data is data.

- --
The essence of OOP: "With all this horse manure, I know there's got to be
                     a pony in here somewhere!"
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Chuck Shotton)
Date: 5 Jun 1992 15:09:07 GMT
Organization: U. of Texas Health Science Center at Houston

In article <[e-mail]>, [e-mail] (Paul Potts) writes:
>
[extra stuff munged]

> schemes of any type (and yes, I do purchase the software I use). It seems
> to me that making a drive which is incapable of reading the (digital) audio
> information while perfectly capable of reading the digital info marked as
> data is somehow ... intellectually dishonest? Leave the copyright issues to
> the lawyers - data is data.
>

Someone in net land correct me if I'm wrong, but it seems to me that it's
simply a software problem. The drive itself can play music AND read computer
data off the same disk. It's very obvious that the data portion (vs. the
music portion) just appears as one or more audio tracks to regular audio CD players.
Therefore, you'd hope that the music portion would just appear as "strange"
computer data to the CD-ROM side of things.

So, why can't a driver (besides the Apple CD one) be written to access the
CD drive as a "raw" SCSI device and read the music tracks as some foreign
file system?

Is there some mutant chunk of hardware (firmware) that actually recognizes
when the head is over music data vs. computer data?

Chuck

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Organization: Visix Software Inc., Reston, VA
Date: Fri, 5 Jun 92 17:21:23 GMT

[e-mail] (Michael Peirce) writes:
> Actually I think it is an evil plot.  Those people are *very* sensitive
> to copyright issues.

Indeed.  SGI manages to get around the current music industry thought police
because their machines do not count as "consumer products," but "professional
engineering workstations."  So, both their CD-ROM and their DAT drive have
audio mode (including recording for the DAT), which is way cool.  I can run
csound on my Indigo, generate a sound file in 2-channel 44.1KHz, and dump
it directly to DAT without any analog stage at all.

The fact that I can also use it to make perfect digital copies of CDs and DATs
is balanced by the fact that it costs much more than a pro DAT deck which will
do the same thing.  I don't know if Apple could get away with the same
capabilities in a more consumer-oriented product line.


Amanda Walker                        [e-mail]
Visix Software Inc.                     [phone]
- --
"Do not meddle in the affairs of wizards, for it makes them soggy and hard
 to light."    --Robert Anton Wilson

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 9 Jun 92 11:01:39 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Chuck Shotton) writes:
>
> Someone in net land correct me if I'm wrong, but it seems to me that it's
> simply a software problem. The drive itself can play music AND read computer
> data off the same disk. It's very obvious that the data portion (vs. the
> music portion) just appears as one or more audio tracks to regular audio CD players.
> Therefore, you'd hope that the music portion would just appear as "strange"
> computer data to the CD-ROM side of things.

In my limited experiments, this doesn't seem to be the case. CD-ROM data
does indeed look like an audio track--it always seems to be the first track.
If you have any actual audio tracks, they come after the CD-ROM data track.
My CD player is indeed fooled, and will play the CD-ROM data as an audio
track (it sounds *awful*). I gather there is actually some flag bit that
identifies that first track as CD-ROM data, so smarter CD players won't
try to play it.

But it doesn't work the other way round. CD-ROM data involves an extra
level of encoding on top of the regular CD audio encoding. This cuts the
error rate from something like 1 in 10**6 (that's an S/N ratio of 120dB,
which is terrific for audio, lousy for data reliability) down to 1 in 10**12.
I think. Anyway, the CD-ROM drive circuitry does the data decoding; in
order to get raw digital CD audio data out of the drive, you'd need some
kind of bypass of that second decoding stage. It doesn't sound like much
to ask, but it's a bit hard to patch into an IC after the fact...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (Julian E. Gomez)
Date: Thu, 11 Jun 92 23:55:23 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Amanda Walker) writes:
" No.  The problem is not the sound manager.
"
" THE PROBLEM IS THE CD DRIVE.  The *only* CD-ROM drive I know of which will
" deliver raw digital audio data over the SCSI bus is the one shipped by Silicon
" Graphics.  It is a Toshiba drive with custom ROM code which was developed by
" Toshiba for SGI.  I understand that Toshiba is allowed to sell the audio data
" support to third parties, but I do not think that they have done so yet.

As an extension to this post:

There are CDROM drives that will deliver the digital audio, such as the
Phillips CM2xx series.  There are two formats for this data: S/PDIF and
AES/xxx (sorry, forgot what the xxx is). These are Sony/Phillips
Digital Interface Format and Audio Engineering Society ...  You
strongly prefer a drive that uses one of these two. Surprisingly, the
CM2xx series are some weird, unique format, rather than S/PDIF.

On the Mac, you can interface with the old DigiDesign Sound Tools board
or one of their high end professional products.
- --
"We must grasp the bull by the tail, and look the matter squarely in the face!"

    Julian "a tribble took it" Gomez
    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Julian E. Gomez)
Date: Thu, 11 Jun 92 23:57:43 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Matt Mora) writes:
" THAT SUCKS! Did Apple drop the ball again? Is this the fault of the hardware
" and not the driver? You would think that Apple would have had the fore sight
" to create a drive that can read audio data. Or is this some evil plot by
" the recording industry from preventing me from making perfect CD copies
" using my mac. :-)

Actually, yes, it is. They fought hard and they fought long and now
there is a bit in the digital audio stream that says "don't copy this
data" and all consumer decks have to obey.
- --
"We must grasp the bull by the tail, and look the matter squarely in the face!"

    Julian "a tribble took it" Gomez
    [e-mail]

---------------------------

End of C.S.M.P. Digest
**********************