| Title: | Multimedia Services |
| Notice: | Latest kit is always in hitujr::"/pub/" |
| Moderator: | BGSDEV::MORRIS |
| Created: | Fri Jul 02 1993 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 505 |
| Total number of notes: | 2097 |
I have a customer who has some questions that are over my head so
I thought that I would pose the questions in this forum. He is
running Multimedia Services V2.2 under Digital Unix 3.2d-1. For
brevity's sake I have left out some of the discussion that preceded
what follows. He basically wants to know if his proposal is reasonable
and has some additional questions. What follows is from the customer.
Thanks,
-Tom Longbotham
I have come up with an approach, and want to run it by you
for sanity, plus a few questions. That is, to record at 8 bit mulaw/8khz
(seems to sound okay, and is at the correct sampling freq we need), which
seems to be more fully supported by your sound platform. I would then
convert the 8bit mulaw to 16 bit (linear PCM). I scoured internet last
nite and found an algorithm from Sun Microsystems for both 8bit mulaw
to 16bit linear PCM and vice versa, which I will test tonite. If it
works okay,
decsound -file - >filename.rawdat
which when saved produces 8bit mulaw data with no header at all (i.e. not
riff, au, etc.). We will then convert to 16bit and tack on the necessary
header for our DAP system.
Questions:
Does my 8 bit Mulaw approach seem the sane way to go?
Can you email me source (C or Ada would be good) for DECs
8bit mulaw <---> 16bit linear PCM conversion algorithms so I can compare
it with what I got off the net in case that doesn't work or is too slow?
Also, concerning au and riff format waveforms, is the only difference
in the headers of those formats; is the format of the 16 bit data
samples themselves between au and riff the same (we may need to know
this for another application)?
It also seems if I invoke decsound by "decsound -file new.wav" where
new.wav is a new file, that it is brought up by default as an au file.
I know this is the default as per the man page, but isn't that default
overridden by the options setup in our sound_editor_resources.dat
file (which I set to riff)? Is V2.2 the latest, and are there any
rev updates in the works?
Finally, concerning 'audiocontrol', if I set 'line in' to 100 via
slider, I notice decsound comes up with line in of 50. As a matter of
fact, any 'line in' value I give in audiocontrol always makes decsound
come up with half that value. The same holds true for output volume.
Why is this? We would like decsound output volume to come up preset
to 80. How do we accomplish this?
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 495.1 | Re:495.0 | BGSDEV::CDANCY | Chip Dancy | Mon Mar 24 1997 16:22 | 78 |
<
<<< I have come up with an approach, and want to run it by you
<<< for sanity, plus a few questions. That is, to record at 8 bit mulaw/8khz
<<< (seems to sound okay, and is at the correct sampling freq we need), which
<<< seems to be more fully supported by your sound platform. I would then
<<< convert the 8bit mulaw to 16 bit (linear PCM). I scoured internet last
<<< nite and found an algorithm from Sun Microsystems for both 8bit mulaw
<<< to 16bit linear PCM and vice versa, which I will test tonite. If it
<<< works okay,
<<<
<<< decsound -file - >filename.rawdat
<<< which when saved produces 8bit mulaw data with no header at all (i.e. not
<<< riff, au, etc.). We will then convert to 16bit and tack on the necessary
<<< header for our DAP system.
<<<
<<< Questions:
<<<
<<< Does my 8 bit Mulaw approach seem the sane way to go?
I suppose that it's the simplest without writing any code. Otherwise I
would just have
used audiorecord to record directly into 16-bit PCM, and thrown away the
file header stuff.
<<< Can you email me source (C or Ada would be good) for DECs
<<< 8bit mulaw <---> 16bit linear PCM conversion algorithms so I can compare
<<< it with what I got off the net in case that doesn't work or is too slow?
The only place we do any conversion is in the support for the base audio
on the
turbochannel machines. And there it's just a straight table lookup.
<<<
<<< Also, concerning au and riff format waveforms, is the only difference
<<< in the headers of those formats; is the format of the 16 bit data
<<< samples themselves between au and riff the same (we may need to know
<<< this for another application)?
No, I believe that au format may allow specification of byte order,
and/or, the byte order
may be different.
<<<
<<< It also seems if I invoke decsound by "decsound -file new.wav" where
<<< new.wav is a new file, that it is brought up by default as an au file.
This doesn't seem to be happening to me. It's coming up as a wave file.
SaveFormat is set to 2.
<<< I know this is the default as per the man page, but isn't that default
<<< overridden by the options setup in our sound_editor_resources.dat
<<< file (which I set to riff)? Is V2.2 the latest, and are there any
<<< rev updates in the works?
There are no planned maintenance/improvements for decsound.
<<<
<<< Finally, concerning 'audiocontrol', if I set 'line in' to 100 via
<<< slider, I notice decsound comes up with line in of 50. As a matter of
<<< fact, any 'line in' value I give in audiocontrol always makes decsound
<<< come up with half that value. The same holds true for output volume.
<<< Why is this? We would like decsound output volume to come up preset
<<< to 80. How do we accomplish this?
<<<
<<<
This isn't happening to me, unless I have the left-right slider set all
the way
to the right or left.
This causes decsound to average the left and right volumes together.
Since one is zero, this is causing what you're seeing.
| |||||