The Logic Off Topic list

Does anybody know if it is impossible for a PC to read the 'resource' fork
of Mac files? I dont mean is there an application that will do it, I mean
can a PC even 'see' the resource fork?

Thanks in advance
--
Mark Lennox
Technical Consultant
ENDUSER
Suite 40
Guinness Enterprise Centre
Taylors Lane
Dublin 8
Ireland
Tel: +353 1 4100 665
Fax: +353 1 4100 985
web: http://www.enduser.com
--

Thoughts from the mind of Mark Lennox, 18-06-2002:

>Does anybody know if it is impossible for a PC to read the 'resource' fork
>of Mac files? I dont mean is there an application that will do it, I mean
>can a PC even 'see' the resource fork?

If you get a mac file in e.g. stuffed form (stuffit format), it is 
completely "intact" and so potentially contains a resource fork (not 
all mac files have resource forks -- typically data files don't and 
applications do).

[Note: when sending files unpacked through email for instance, and 
using uuencode as the transfer mechanism, the resource fork gets 
stripped off -- hence the previous proviso for using some sort of 
archiver which is the safest way to guarantee complete transfers 
through whichever medium, be it internet or hardware like CDs and 
such.]

Since it's all in one big file anyway and not something like two 
separate files, the answer must be yes: some of the bytes of the file 
are what the mac calls resource-fork, and others are data-fork.  You 
just won't be able to access the resource fork in any meaningful way 
I suppose.  The PC will just see it as one big file which has no 
particular meaning to it.  There won't be a way for the PC to 
distinguish between resource-fork bytes and data-fork bytes.

Is there a particular reason you ask this?

-- 
Hendrik Jan Veenstra  <h@...>
Omega Art: http://www.ision.nl/users/h/index.html

> Since it's all in one big file anyway and not something like two
> separate files, the answer must be yes: some of the bytes of the file
> are what the mac calls resource-fork, and others are data-fork.  You
> just won't be able to access the resource fork in any meaningful way
> I suppose.  The PC will just see it as one big file which has no
> particular meaning to it.  There won't be a way for the PC to
> distinguish between resource-fork bytes and data-fork bytes.

Hmm thats the first problem, preserving the resource fork, or at least
recognising it as such....

> Is there a particular reason you ask this?

JUst thinking about useful utilities and the like Hendrik (dont know who put
that idea in my head ...) and I thought all the talk of SDII files and the
like. It would be nice to write a little util (probably in perl, maybe in
c++ but I have a lot to learn there...) to strip out the resource fork and
save it in a useful format for PC users, like a MIDI file or something,
maybe you and I could petition Emagic to tell us the format of their song
files....??

Despite that, I am currently working 12+hours every day so I dont think I'll
have much time to implement this, just nice to get the idea composted in to
let it ferment a bit...

Is there a spec/white paper/whatever on SDII anywhere on the web that I
could look at (for some bedtime reading you understand ;) ) - I'm about to
look anyway but it always helps to have a few pointers from all you folks
--
Mark Lennox
Technical Consultant
ENDUSER
Suite 40
Guinness Enterprise Centre
Taylors Lane
Dublin 8
Ireland
Tel: +353 1 4100 665
Fax: +353 1 4100 985
web: http://www.enduser.com
--

>JUst thinking about useful utilities and the like Hendrik (dont know who put
>that idea in my head ...) and I thought all the talk of SDII files and the
>like. It would be nice to write a little util (probably in perl, maybe in
>c++ but I have a lot to learn there...) to strip out the resource fork and
>save it in a useful format for PC users, like a MIDI file or something,
>maybe you and I could petition Emagic to tell us the format of their song
>files....??

the forks are actually 2 seperate files - I haven't looked at it on a 
PC - but have often seen the structure when I saved .KRZ  files from 
a mac to a dos floppy for transferring to my old K2000 - when you 
look at this in the Kurzweil - you can see the entire directory 
structure for what appears on the mac as a single file

for most files the resource fork contains only mac-specific 
information (icon appearance, windowing, etc) so it is not really 
useful or relevant to the pc

any documents which are intended to go from mac to pc are saved in a 
format where all relevant info is saved in the data fork - MS Word 
"docs" for example.

this is the way AIF works - the raw sound data is interspersed with 
"header" info - the info which tells the app what the sample rate, 
length, size, loops etc etc. WAV is exactly the same (it was 
originally identical to AIF except for reversing the byte order and a 
couple of lo-fi sample formats) idea.

the problem with SDII is that this info is in the resource fork.

it would be possible to construct an app on pc which would read the 
resource file and extract this info (assuming you had made sure that 
the means of transmitting from mac to pc hadn't thrown away the 
resource fork)

but then what would you do with it? - in order to be used by pc audio 
apps it the combined info and raw sound data would have to be 
combined into a single file - like AIF or WAV....

so is there a point to doing it this way? I think not, and apparently 
neither does Digi - in any case if you want to preserve Digi specific 
features like regions, they will point you to OMF - this makes sense 
since it is a much fuller featured format which embraces not only 
audio, but any other kind of media you can imagine.

Thoughts from the mind of Mark Lennox, 18-06-2002:

>Hmm thats the first problem, preserving the resource fork, or at least
>recognising it as such....

When dealing with a specific kind of file, this shouldn't be hard.  A 
generic way to distinguish one from the other, for all filetypes, 
presumably is a bit harder.

>JUst thinking about useful utilities and the like Hendrik (dont know who put
>that idea in my head ...) and I thought all the talk of SDII files and the
>like. It would be nice to write a little util (probably in perl, maybe in
>c++ but I have a lot to learn there...) to strip out the resource fork and
>save it in a useful format for PC users, like a MIDI file or something,

Nice idea.  Something like have note on/off at each region start/end or so?

>maybe you and I could petition Emagic to tell us the format of their song
>files....??

The songfile format has little to do with SDII files.  LSO's do't 
have a resource fork.

>Is there a spec/white paper/whatever on SDII anywhere on the web that I
>could look at (for some bedtime reading you understand ;) ) - I'm about to
>look anyway but it always helps to have a few pointers from all you folks

No idea...

-- 
Hendrik Jan Veenstra  <h@...>
Omega Art: http://www.ision.nl/users/h/index.html

Thoughts from the mind of Mark Lennox, 18-06-2002:

>Is there a spec/white paper/whatever on SDII anywhere on the web that I
>could look at (for some bedtime reading you understand ;) ) - I'm about to
>look anyway but it always helps to have a few pointers from all you folks

http://www.crucial-systems.com/code/SDII_format_specification

-- 
Hendrik Jan Veenstra  <h@...>
Omega Art: http://www.ision.nl/users/h/index.html

> http://www.crucial-systems.com/code/SDII_format_specification

Got that one thanks Hendrick.

I think I may sign up to be a developer with Digidesign, probably the
easiest way, and then I can write MAS and TDM plugins :) ha!

I would appreciate any comments from people who regularly use SDII
describing what they use it for, also any problems people have in porting
from Mac SDII to PC Wav etc...

cheers
--
Mark Lennox
Technical Consultant
ENDUSER
Suite 40
Guinness Enterprise Centre
Taylors Lane
Dublin 8
Ireland
Tel: +353 1 4100 665
Fax: +353 1 4100 985
web: http://www.enduser.com
--

>  > http://www.crucial-systems.com/code/SDII_format_specification
>
>Got that one thanks Hendrick.

You may also want to check out the Computer Music Journal archives. 
You should be able to find an article from the early 90's which gives 
detailed specs for all audio formats.

here it is:

The article is:

Machine Tongues XVIII: A Child's Garden of Sound File Formats by 
Guido van Rossum

Appeared in the Computer Music Journal - spring '95

very extensive, very detailed