The Logic Off Topic list

[Redirected from LUG to L-OT:]

From: "Marcus Barczak" <mjb@...> 
Date: Fri Apr 5, 2002 2:27am 
Subject: RE: [LUG] RE: [LAM] firewire drive  



> SDII files can be read on a PC by Awave Studio and 
> Quicktime also recognoses them though I don't know 
> if that helps.

Why do people still spout information about process that they have not
tried!  

1)  AWAVE supports SDII files in the guise that it will open in a file
in MOTOROLA binary format you physically CANNOT read the resource fork
of a file on an HFS formatted partition on a PC irrespective of
MacOpener/Conversions Plus or any other "mount a mac disc on a PC" type
utility.  It is up to YOU to specify sample rate, bit-depth and number
of channels.

2)  AWAVE will crash on large files ... sure it's cool for small samples
but give it a 3 minute+ 24-bit/44k1 file and it will barf

3)  Any application that can open RAW audio files and specify then
endian'ness (ie. motorola/intel big/little endian) can open an SDII file
provided you specify the bit depth, sample rate and number of channels -
sound forge 5.0 can now do this since it is now 24 bit, shame they made
batch converter an additional plugin :( boo hiss

Hendrik Jan Veenstra then said:

> The resource fork is a typical Mac invention, and is just an "extra 
> part" of the file, which PC files don't have.  Indeed, as you say, 
> they make 3-letter filetype extensions unnecessary & all, but the 
> disk format has nothing to do with that.

The resource/data fork concept was a great idea aside from it being
incompatible with every other filesystem format under the sun.  Aside
from eliminating the need for file extensions most importantly it
provided a means for mac programmers to extrapolate the raw data from
the information describing the data.  In SDII terms the resource fork
aside from citing the creator and file type also contains pertinant info
such as the bit depth, sample rate, number of channels, time stamp etc
... it's a great idea but not portable unfortunately :(  ProTools (pre
5.1) stored the entire data in a session file entirely in the data fork
making it a right royal pain in the ass to open in a PC ... this
thankfully has been rectified :) in 5.1 onwards :)

nuff of my rant

cheers,
marcus

[Redirected from LUG to L-OT:]

From: "jamie+howarth" <jamie@...> 
Date: Thu Apr 4, 2002 8:27am 
Subject: !!Thread getting too OT I think(OM)!!Re: [LAM] firewire drive  



Quoting Salient Bits
> > SDII files can be read on a PC by Awave Studio and 
Quicktime also 
 II data fork.
> 
> So, it cannot read the other part of the SDII file - which is the 
> Resource Fork (which has channel and bit depth info etc.) - the 
reason 
... PC's don't have an equivalent - 
> btw, this is one reason why in the past mac files didn't need 
extensions 
> like .exe as the necessary info was in the resource fork. With 
Mac OS X, 
> extensions are being used much more however than the 
resource fork 
> stuff - though it is still in use.

This is one of the substantive differences ( as contrasted to the 
religious wars) that differentiates the two platforms. Apple saw 
this coming years and years ago, and imbedded an identifying 
creator code and filetype within the file's header, which makes 
files self-identifying to their host apps, and obviates the need for 
the clumsy .jpg or.qtv or.doc or .whatevah extensions. It is also a 
really really good idea, and part of why Mac users get so crazy 
over the platform wars is that most of the really really good ideas 
that the Mac OS clearly provided are undermined by the 
economic necessity to adopt  less sophisticated (dumber) 
conventions still required  by the Windows OS's stubborn 
reliance on vestiges of the antiquated MSDOS. It is truly 
paradoxical that a culture that kids itself that it is progressive still 
allows the droppings of this dinosaur to litter the landscape, 20 
years after it was rendered technologically obsolete by the 
alternative methods of building apps the MacOs provided.

"Martin, Jeremy" <sadus@i...> wrote:
> [Redirected from LUG to L-OT:]
> 
> 
> From: "jamie+howarth" <jamie@j...> 
> Date: Thu Apr 4, 2002 8:27am 
> Subject: !!Thread getting too OT I think(OM)!!Re: [LAM] firewire 
drive  
> 
> 
> 
> Quoting Salient Bits
> > > SDII files can be read on a PC by Awave Studio and 
> Quicktime also 
>  II data fork.
> > 
> > So, it cannot read the other part of the SDII file - which is the 
> > Resource Fork (which has channel and bit depth info etc.) - the 
> reason 
> ... PC's don't have an equivalent - 
> > btw, this is one reason why in the past mac files didn't need 
> extensions 
> > like .exe as the necessary info was in the resource fork. With 
> Mac OS X, 
> > extensions are being used much more however than the 
> resource fork 
> > stuff - though it is still in use.
> 
> This is one of the substantive differences ( as contrasted to the 
> religious wars) that differentiates the two platforms. Apple saw 
> this coming years and years ago, and imbedded an identifying 
> creator code and filetype within the file's header, which makes 
> files self-identifying to their host apps, and obviates the need 
for 
> the clumsy .jpg or.qtv or.doc or .whatevah extensions. It is also a 
> really really good idea, and part of why Mac users get so crazy 
> over the platform wars is that most of the really really good ideas 
> that the Mac OS clearly provided are undermined by the 
> economic necessity to adopt  less sophisticated (dumber) 
> conventions still required  by the Windows OS's stubborn 
> reliance on vestiges of the antiquated MSDOS. It is truly 
> paradoxical that a culture that kids itself that it is progressive 
still 
> allows the droppings of this dinosaur to litter the landscape, 20 
> years after it was rendered technologically obsolete by the 
> alternative methods of building apps the MacOs provided.

Can I tell u a story? I develop information systems for companies. A 
couple of months ago I was introduced to a transportation company. We 
had to install an SQL Server system for them since they changed their 
mind of doing things in Access; things were becoming too slow for 
them due to performance of that databases system. I couldn't believe 
my eyes when I saw people around still working in these ugly dos 
windows that used to be used in the late 80's, early 90's. Those 
Turbo Pascal OWL windows.
Anyway, this is going to be a big client to coming years, :). And we 
are talking a middle large company here, probably over a bilion euro 
turnover a year. And they still are working with a couple of these 
DOS programs. They tell you: "As long as it's working, why bother". 
The only way to get them to invest is when they can enhance their 
output, due to automation changes.
These are exactly the companies M$ makes the most money on. You won't 
see any Apple machines around these kind of companies. Apple is more 
something for designers, audio people and video people.

I agree with you that there are a lot of fine technology into Apple 
stuff( more or less nicked somewhere else, but hey, who doesn't do 
that, :)). But it's not cool stuff that sells. It's the way you can 
sell it that counts. And if it can integrate with the stuff you 
already have. Companies can't buy a complete bunch of new stuff 
without getting time to get used to the new stuff. So, things have to 
go in phases. And during these phases the company still has to keep 
doing it's activities. This is exactly where M$ will keep it's 
customers happy, and maybe gain a couple along the way.

We audio people are the ones that probably demand the most from our 
systems. Majority of systems are used for simply doing some writing, 
some emailing and some gaming. You could do that on one of the 
earliest Pentium processors too.

My point: it's business that keeps old technology alive. As long as 
these old dos files can run on a newer OS by M$, people will keep 
buying M$. Until M$ does not support this old technology. And I can 
keep making money on the problems they need to have solved with these 
newer OSes, like rewriting of programs and introduction of newer 
information systems, : ).
Yoonchi.