From: mark@acorn.co.uk (Mark Taunton)
Subject: Re: Passing on a request about sun au files.
Date: 7 Nov 91 15:19:35 GMT
> I have a large collection of Sun .au files and I want to be able to use them
> on my Archimedes.
I looked again at some Sun documentation on this today. I think the
following is correct....
For .au files created on SparcStations under earlier versions of SunOS
(4.0.3c) there is no header on the files. For later versions, there
is a file header which gives details of the format of the data:
unfortunately the full structure of this header is not documented and
its overall size is said to be variable. Instead Sun supply (the
binary code of) routines to read & write file headers, which is not
specially helpful for use outside SunOS. However they do say that the
format is a subset of that used by NeXT.
It seems likely that the raw data format is the same for all current
.au files, since Sun's standard hardware supports only one sampling
rate, and audio device drivers up to and including 4.1 only support
one encoding method though the SparcStation hardware apparently
supports two.
Here then are the details of the raw data format, as extracted from
the Sun docs:
sampling rate 8kHz (that's 8000 Hz, not 8192Hz)
sample format ISDN m-law companding (8-bits pseudo-log)
(m-law = mu-law = u-law, I believe: it is pronounced "mew-law", i.e.
from the Greek letter mu, which looks a bit like a u, hence the funny
variations)
Happily, mu-law encoding is what is used by the VIDC sound output
system in all Acorn's 32-bit machines. However the order and coding
of the bits is different from Sun's. The Sun format for each sample
byte is:
Bit: 7 6 5 4 3 2 1 0
+----+-------+------+
|Sign| Chord |Offset|
+----+-------+------+
Sign = 1 means positive, = 0 means negative. Both Chord and Offset
are encoded as the 1's complement of the respective binary values,
i.e. for Chord 0, Offset 0, the bits are all 1, whereas for Chord 7,
Offset 15 the bits are all 0. [I won't bother explaining here what
chord & offset mean.]
In VIDC-1a format, as used on all Acorn product machines (but not on
some early prototype hardware) the format is:
Bit: 7 6 5 4 3 2 1 0
+-------+------+----+
| Chord |Offset|Sign|
+-------+------+----+
Sign = 0 means positive, = 1 means negative. Both Chord and Offset
are encoded as direct binary, i.e. Chord 0 has bits 7..4 all 0.
The reason for the different bit ordering is that it makes certain
common signal synthesis computations simpler on ARM (there's the
advantage of designing your own hardware!).
To convert from Sun format to Acorn VIDC format, you need to rotate
each byte left by one bit and bitwise complement the whole byte. This
turns out to be pretty easy. Here is a little program I wrote to do
this: it is written in PCC style C (boo, hiss!) and runs on RISC iX.
Converting to ANSI C, and for use under RISC OS should be fairly
simple.
Obviously, you'll have to work out for yourself where any .au file
header ends and the real data begins...
----------------------------------------------------------
/*
* stov.c: convert SparcStation audio data on stdin
* to Archimedes (VIDC) format on stdout.
*
* Mark Taunton, January 1991.
*/
void *malloc();
#define BSZ 4096 /* Convenient for RISC iX's sound interface */
main (argc, argv)
int argc;
char **argv;
{
/*
* Note that malloc always returns a word-aligned pointer.
*/
unsigned char *buff = (unsigned char *)malloc (BSZ);
int n;
while ((n = read (0, buff, BSZ)) > 0)
{
unsigned int *wp = (unsigned int *)buff;
unsigned int *lim = (unsigned int *)(buff + ((n + 3) & ~3));
/*
* In the following loop we convert 4 bytes at once because
* it's all pure bit twiddling: there is no arithmetic to
* cause overflow/underflow or other such nasty effects. Each
* byte is converted using the algorithm:
*
* output = ~(((input >> 7) & 0x01) |
* ((input << 1) & 0xFE) )
*
* i.e. we rotate the byte left by 1 then bitwise complement
* the result. On ARM the actual conversion (not including
* the load & store) works out to take all of 4 S-cycles, and
* since we are doing 4 bytes at once this really ain't bad!
* Note that we don't worry about alignment on any odd bytes
* at the end of the buffer (unlikely anyway), we just convert
* all 4 bytes - the right number still get written.
*/
unsigned int xm = 0x01010101;
do
{
unsigned int ss = *wp;
*wp++ = ~(((ss >> 7) & xm) | (~xm & (ss << 1)));
} while (wp != lim);
write (1, buff, n);
}
}
-----------------------------------------------------------------
From: mark@acorn.co.uk (Mark Taunton)
Date: 7 Nov 91 16:03:32 GMT
Organization: Acorn Computers Ltd, Cambridge, UK
As a P.S. to my posting on Sun audio file format, here's a little tip.
To make low-sample-rate mono audio data (such as Sun format, at 8KHz)
sound rather better through VIDC, simply repeat each audio sample in
the stream and double the output sample rate. The difference is quite
marked. Further slight improvement is possible through replicating
more times, but going above a factor of 3 probably isn't worth it for
8KHz samples. This sort of thing may perhaps be (and if not, probably
ought to be) available as an option in sample players....
--
Mark Taunton Email: mark@acorn.co.uk
Acorn Computers Ltd Phone: (+44) 223 214411
Cambridge, UK Fax: (+44) 223 214382
From: wsinda@wsintt02.info.win.tue.nl (Dick Alstein)
Subject: Conversion of Sun sound files to Arc format
Date: 11 Nov 91 12:55:29 GMT
Reply-To: wsinda@info.win.tue.nl
It's a bit late, but in response to questions about transferring Sun
sound files to RiscOs, here is a very small Basic program to do the
conversion. The output file can be read by !Armadeus, but you should
set the sample frequency to 8000 Hz by hand. (The file contains raw
data, no header.) After that, you can save it in another format.
----------------------------------------------------------------
REM >SunToArc
REM converts Sun sound files to Arc format
INPUT "Input from file: "in$
INPUT "Output to file : "out$
I%=OPENIN in$
O%=OPENOUT out$
WHILE NOT EOF#I%
B%=BGET#I%
C%=(B%>>7) OR ((NOT (B%<<1)) AND &FE)
BPUT#O%,C%
ENDWHILE
CLOSE#I%
CLOSE#O%
END
----------------------------------------------------------------
Dick Alstein
wsinda@info.win.tue.nl
poppy@poppyfields.net