ref: c38987e8d20505621b8d872863afa7d233ed1096
parent: 588d6473c6a822af95a4e288f6a66de4fe5c0082
author: cbagwell <cbagwell>
date: Wed Dec 12 23:38:26 EST 2001
Added raw inverse-bit u-law and A-law support. Updated *.txt files.
--- a/Changelog
+++ b/Changelog
@@ -60,6 +60,9 @@
o Added uninstall rules to Makefile. Added new ststdint.h to define
*int*_t typedefs.
o Added internal strcasecmp for OS/2.
+ o Added support for swapping "bit" order (MSB becomes LSB) for raw u-law
+ and A-law data. Some ISDN equipment prefers it this way. Use -x flag
+ or new .la or .lu file extensions.
o Annonymous patch submitted to fix types and spelling problems in
various files. Also, updated VOC files to have u-law and A-law
support as well as able to read in VOC files using a pipe. More
--- a/sox.1
+++ b/sox.1
@@ -236,7 +236,8 @@
.br
U-law (actually shorthand for mu-law) and A-law are the U.S. and
international standards for logarithmic telephone sound compression.
-When uncompressed it has roughly the precision of 12-byte PCM audio.
+When uncompressed u-law has roughly the precision of 14-byte PCM audio
+and A-law has roughly the precision of 13-bit PCM audio.
.br
ADPCM is a form of sound compression that has a good
compromise between good sound quality and fast encoding/decoding
@@ -264,6 +265,8 @@
be swapped according to the word-size given above.
Only 16-bit and 32-bit integer data may be swapped.
Machine-format floating-point data is not portable.
+This flag is also used to invert the bit ordering of u-law
+and A-law data (MSB becomes LSB).
.TP 10
\fB-c \fIchannels\fR
The number of sound channels in the data file.
@@ -577,15 +580,15 @@
of the sample file must be given.
The number of channels defaults to 1.
.TP 10
-.B ".ub, .sb, .uw, .sw, .ul, .al, .sl"
+.B ".ub, .sb, .uw, .sw, .ul, .al, .lu, .la, .sl"
These are several suffices which serve as
a shorthand for raw files with a given size and encoding.
-Thus, \fBub, sb, uw, sw, ul\fR and \fBsl\fR
+Thus, \fBub, sb, uw, sw, ul, al, lu, la\fR and \fBsl\fR
correspond to "unsigned byte", "signed byte",
"unsigned word", "signed word", "u-law" (byte), "A-law" (byte),
-and "signed long".
+inverse bit order "u-law", inverse bit order "A-law", and "signed long".
The sample rate defaults to 8000 hz if not explicitly set,
-and the number of channels (as always) defaults to 1.
+and the number of channels defaults to 1.
There are lots of Sparc samples floating around in u-law format
with no header and fixed at a sample rate of 8000 hz.
(Certain sound management software cheerfully ignores the headers.)
--- a/sox.txt
+++ b/sox.txt
@@ -9,12 +9,17 @@
sox infile outfile
sox [ general options ] [ format options ] infile
- -e effect [ effect options ]
+ [ format options ] outfile
+ [ effect [ effect options ] ... ]
- sox [ general options ] [ format options ] infile
+ soxmix infile1 infile2 outfile
+
+ soxmix [ general options ] [ format options ] infile1
+ [ format options ] infile2
[ format options ] outfile
[ effect [ effect options ] ... ]
+
General options:
[ -h ] [ -p ] [ -v volume ] [ -V ]
@@ -82,12 +87,18 @@
apply one or more sound effects to the file during this
translation.
+ soxmix is functionally the same as the command line pro�
+ gram sox expect that it takes two files as input and mixes
+ the audio together to produce a single file as output. It
+ has a restriction that both input files must be of the
+ same data type and sample rates.
+
There are two types of audio files formats that SoX can
work with. The first are self-describing file formats.
These contain a header that completely describe the char�
acteristics of the audio data that follows.
- The second type are headerless data, or sometimes called
+ The second type are header-less data, or sometimes called
raw data. A user must pass enough information to SoX on
the command line so that it knows what type of data it
contains.
@@ -109,13 +120,13 @@
data. Mono and Stereo are the two most common.
Please refer to the soxexam(1) manual page for a long
- description with examples on how to use sox with various
+ description with examples on how to use SoX with various
types of file formats.
OPTIONS
The option syntax is a little grotty, but in essence:
- sox file.au file.wav
+ sox File.au file.wav
translates a sound file in SUN Sparc .AU format into a
Microsoft .WAV file, while
@@ -127,17 +138,22 @@
hertz, and applies the mask sound effect to the audio
data.
+ The following will mix two sound files together to to pro�
+ duce a single sound file.
+
+ soxmix music.wav voice.wav mixed.wav
+
Format options:
- Format options effect the audio samples that they
- immediately preceed. If they are placed before the input
- file name then they effect the input data. If they are
- placed before the output file name then they will effect
- the output data. By taking advantage of this, you can
- override a input file's corrupted header or produce an
- output file that is totally different style then the input
- file. It is also how sox is informed about the format of
- raw input data.
+ Format options effect the audio samples that they immedi�
+ ately precede. If they are placed before the input file
+ name then they effect the input data. If they are placed
+ before the output file name then they will effect the out�
+ put data. By taking advantage of this, you can override a
+ input file's corrupted header or produce an output file
+ that is totally different style then the input file. It
+ is also how SoX is informed about the format of raw input
+ data.
-t filetype
gives the type of the sound sample file. Useful
@@ -144,26 +160,27 @@
when file extension is not standard or for spec�
ifying the .auto file type.
- -r rate Gives the sample rate in Hertz of the file. To
+ -r rate Gives the sample rate in Hertz of the file. To
cause the output file to have a different sample
rate than the input file, include this option as
a part of the output options.
- If the input and output files have different
- rates then a sample rate change effect must be
- ran. If a sample rate changing effect is not
- specified then a default one will internally be
- ran by sox using its default parameters.
+ If the input and output files have different
+ rates then a sample rate change effect must be
+ ran. If a sample rate changing effect is not
+ specified then a default one will internally be
+ ran by SoX using its default parameters.
-s/-u/-U/-A/-a/-i/-g/-f
- The sample data encoding is signed linear (2's
- complement), unsigned linear, U-law (logarith�
+ The sample data encoding is signed linear (2's
+ complement), unsigned linear, u-law (logarith�
mic), A-law (logarithmic), ADPCM, IMA_ADPCM,
GSM, or Floating-point.
- U-law (actually shorthand for mu-law) and A-law
- are the U.S. and international standards for
- logarithmic telephone sound compression. When
- uncompressed it has roughly the precision of
- 12-byte PCM audio.
+ U-law (actually shorthand for mu-law) and A-law
+ are the U.S. and international standards for
+ logarithmic telephone sound compression. When
+ uncompressed u-law has roughly the precision of
+ 14-byte PCM audio and A-law has roughly the pre�
+ cision of 13-bit PCM audio.
ADPCM is a form of sound compression that has a
good compromise between good sound quality and
fast encoding/decoding time. It is used for
@@ -175,7 +192,7 @@
ferent meanings in different file handlers. In
.wav files it represents MS ADPCM files, in all
others it means G.726 ADPCM. IMA ADPCM is a
- specific form of adpcm compression, slightly
+ specific form of ADPCM compression, slightly
simpler and slightly lower fidelity than
Microsoft's flavor of ADPCM. IMA ADPCM is also
called DVI ADPCM.
@@ -192,7 +209,9 @@
order than yours and must be swapped according
to the word-size given above. Only 16-bit and
32-bit integer data may be swapped. Machine-
- format floating-point data is not portable.
+ format floating-point data is not portable.
+ This flag is also used to invert the bit order�
+ ing of u-law and A-law data (MSB becomes LSB).
-c channels
The number of sound channels in the data file.
@@ -219,7 +238,7 @@
-h Print version number and usage information.
-p Run in preview mode and run fast. This will
- somewhat speed up sox when the output format has
+ somewhat speed up SoX when the output format has
a different number of channels and a different
rate than the input file. Currently, this
defaults to using the rate effect instead of the
@@ -229,7 +248,7 @@
decreases, greater than 1.0 increases. May use
a negative number to invert the phase of the
audio data. It is interesting to note that we
- percieve volume logarithmically but this adjusts
+ perceive volume logarithmically but this adjusts
the amplitude linearly.
Note: see the stat effect for information on
finding the maximum value that can be used with
@@ -237,7 +256,7 @@
clipped.
-V Print a description of processing phases. Use�
- ful for figuring out exactly how sox is mangling
+ ful for figuring out exactly how SoX is mangling
your sound samples.
FILE TYPES
@@ -321,18 +340,18 @@
and decoded multiple times. This format is used
by some voice mail applications. It is rather
CPU intensive.
- GSM in sox is optional and requires access to an
+ GSM in SoX is optional and requires access to an
external GSM library. To see if there is sup�
port for gsm run sox -h and look for it under
the list of supported file formats.
.hcom Macintosh HCOM files. These are (apparently)
- Mac FSSD files with some variant of Huffman
- compression. The Macintosh has wacky file for�
- mats and this format handler apparently doesn't
- handle all the ones it should. Mac users will
- need your usual arsenal of file converters to
- deal with an HCOM file under Unix or DOS.
+ Mac FSSD files with some variant of Huffman com�
+ pression. The Macintosh has wacky file formats
+ and this format handler apparently doesn't han�
+ dle all the ones it should. Mac users will need
+ your usual arsenal of file converters to deal
+ with an HCOM file under Unix or DOS.
.maud An Amiga format
An IFF-conform sound file type, registered by MS
@@ -351,14 +370,14 @@
tency.
.ogg Ogg Vorbis Compressed Audio.
- Ogg Vorbis is a open, patent-free codec designed
+ Ogg Vorbis is a open, patent-free CODEC designed
for compressing music and streaming audio. It
is similar to MP3, VQF, AAC, and other lossy
- formats. sox can decode all types of Ogg Vorbis
+ formats. SoX can decode all types of Ogg Vorbis
files, but can only encode at 128 kbps. Decod�
ing is somewhat CPU intensive and encoding is
very CPU intensive.
- Ogg Vorbis in sox is optional and requires
+ Ogg Vorbis in SoX is optional and requires
access to external Ogg Vorbis libraries. To see
if there is support for Ogg Vorbis run sox -h
and look for it under the list of supported file
@@ -366,18 +385,18 @@
ossdsp OSS /dev/dsp device driver
This is a pseudo-file type and can be optionally
- compiled into Sox. Run sox -h to see if you
+ compiled into SoX. Run sox -h to see if you
have support for this file type. When this
driver is used it allows you to open up the OSS
/dev/dsp file and configure it to use the same
- data format as passed in to /fBSoX. It works
- for both playing and recording sound samples.
- When playing sound files it attempts to set up
- the OSS driver to use the same format as the
- input file. It is suggested to always override
- the output values to use the highest quality
- samples your sound card can handle. Example: -t
- ossdsp -w -s /dev/dsp
+ data format as passed in to SoX. It works for
+ both playing and recording sound samples. When
+ playing sound files it attempts to set up the
+ OSS driver to use the same format as the input
+ file. It is suggested to always override the
+ output values to use the highest quality samples
+ your sound card can handle. Example: -t ossdsp
+ -w -s /dev/dsp
.sf IRCAM Sound Files.
Sound Files are used by academic music software
@@ -389,13 +408,14 @@
mat defined by NIST (National Institute of Stan�
dards and Technology) and is used with speech
audio. SoX can read these files when they con�
- tain ulaw and PCM data. It will ignore any
+ tain u-law and PCM data. It will ignore any
header information that says the data is com�
pressed using shorten compression and will treat
- the data as either ulaw or PCM. This will allow
- SoX and the command line shorten program to be
- ran together using pipes to uncompress the data
- and then pass the result to SoX for processing.
+ the data as either u-law or PCM. This will
+ allow SoX and the command line shorten program
+ to be ran together using pipes to uncompress the
+ data and then pass the result to SoX for pro�
+ cessing.
.smp Turtle Beach SampleVision files.
SMP files are for use with the PC-DOS package
@@ -416,11 +436,11 @@
sunau Sun /dev/audio device driver
This is a pseudo-file type and can be optionally
- compiled into Sox. Run sox -h to see if you
+ compiled into SoX. Run sox -h to see if you
have support for this file type. When this
driver is used it allows you to open up a Sun
/dev/audio file and configure it to use the same
- data type as passed in to Sox. It works for
+ data type as passed in to SoX. It works for
both playing and recording sound samples. When
playing sound files it attempts to set up the
audio driver to use the same format as the input
@@ -451,55 +471,59 @@
data with a new sample rate is rejected.
Silence with a different sample rate is gener�
ated appropriately. On output, silence is not
- detected, nor are impossible sample rates.
+ detected, nor are impossible sample rates.
+ Note, this version now supports playing VOC
+ files with multiple blocks and supports playing
+ files containing u-law and A-law samples.
vorbis See .ogg format.
.wav Microsoft .WAV RIFF files.
- These appear to be very similar to IFF files,
- but not the same. They are the native sound
+ These appear to be very similar to IFF files,
+ but not the same. They are the native sound
file format of Windows. (Obviously, Windows was
- of such incredible importance to the computer
- industry that it just had to have its own sound
+ of such incredible importance to the computer
+ industry that it just had to have its own sound
file format.) Normally .wav files have all for�
- matting information in their headers, and so do
- not need any format options specified for an
- input file. If any are, they will override the
- file header, and you will be warned to this
+ matting information in their headers, and so do
+ not need any format options specified for an
+ input file. If any are, they will override the
+ file header, and you will be warned to this
effect. You had better know what you are doing!
- Output format options will cause a format con�
- version, and the .wav will written appropri�
- ately. Sox currently can read PCM, ULAW, ALAW,
- MS ADPCM, and IMA (or DVI) ADPCM. It can write
+ Output format options will cause a format con�
+ version, and the .wav will written appropri�
+ ately. SoX currently can read PCM, ULAW, ALAW,
+ MS ADPCM, and IMA (or DVI) ADPCM. It can write
all of these formats including (NEW!) the ADPCM
encoding.
- .wve Psion 8-bit alaw
- These are 8-bit a-law 8khz sound files used on
+ .wve Psion 8-bit A-law
+ These are 8-bit A-law 8khz sound files used on
the Psion palmtop portable computer.
.raw Raw files (no header).
- The sample rate, size (byte, word, etc), and
+ The sample rate, size (byte, word, etc), and
encoding (signed, unsigned, etc.) of the sample
- file must be given. The number of channels
+ file must be given. The number of channels
defaults to 1.
- .ub, .sb, .uw, .sw, .ul, .al, .sl
- These are several suffices which serve as a
- shorthand for raw files with a given size and
- encoding. Thus, ub, sb, uw, sw, ul and sl cor�
- respond to "unsigned byte", "signed byte",
- "unsigned word", "signed word", "ulaw" (byte),
- "alaw" (byte), and "signed long". The sample
- rate defaults to 8000 hz if not explicitly set,
- and the number of channels (as always) defaults
- to 1. There are lots of Sparc samples floating
- around in u-law format with no header and fixed
- at a sample rate of 8000 hz. (Certain sound
- management software cheerfully ignores the head�
- ers.) Similarly, most Mac sound files are in
- unsigned byte format with a sample rate of 11025
- or 22050 hz.
+ .ub, .sb, .uw, .sw, .ul, .al, .lu, .la, .sl
+ These are several suffices which serve as a
+ shorthand for raw files with a given size and
+ encoding. Thus, ub, sb, uw, sw, ul, al, lu, la
+ and sl correspond to "unsigned byte", "signed
+ byte", "unsigned word", "signed word", "u-law"
+ (byte), "A-law" (byte), inverse bit order "u-
+ law", inverse bit order "A-law", and "signed
+ long". The sample rate defaults to 8000 hz if
+ not explicitly set, and the number of channels
+ defaults to 1. There are lots of Sparc samples
+ floating around in u-law format with no header
+ and fixed at a sample rate of 8000 hz. (Certain
+ sound management software cheerfully ignores the
+ headers.) Similarly, most Mac sound files are
+ in unsigned byte format with a sample rate of
+ 11025 or 22050 hz.
.auto This is a ``meta-type'': specifying this type
for an input file triggers some code that tries
@@ -579,9 +603,9 @@
delay/decay/speed/depth gives the delay in mil�
liseconds and the decay (relative to gain-in)
with a modulation speed in Hz using depth in
- milliseconds. The modulation is either sinodial
- (-s) or triangular (-t). Gain-out is the volume
- of the output.
+ milliseconds. The modulation is either sinu�
+ soidal (-s) or triangular (-t). Gain-out is the
+ volume of the output.
compand attack1,decay1[,attack2,decay2...]
@@ -609,18 +633,18 @@
-inf,-inf and 0,0 are assumed; the latter may be
overridden, but the former may not.
- The third (optional) parameter is a postprocess�
- ing gain in dB which is applied after the com�
- pression has taken place; the fourth (optional)
- parameter is an initial volume to be assumed for
- each channel when the effect starts. This per�
- mits the user to supply a nominal level ini�
- tially, so that, for example, a very large gain
- is not applied to initial signal levels before
- the companding action has begun to operate: it
- is quite probable that in such an event, the
- output would be severely clipped while the com�
- pander gain properly adjusts itself.
+ The third (optional) parameter is a post-pro�
+ cessing gain in dB which is applied after the
+ compression has taken place; the fourth
+ (optional) parameter is an initial volume to be
+ assumed for each channel when the effect starts.
+ This permits the user to supply a nominal level
+ initially, so that, for example, a very large
+ gain is not applied to initial signal levels
+ before the companding action has begun to oper�
+ ate: it is quite probable that in such an event,
+ the output would be severely clipped while the
+ compander gain properly adjusts itself.
The fifth (optional) parameter is a delay in
seconds. The input signal is analyzed immedi�
@@ -637,11 +661,11 @@
dcshift shift [ limitergain ]
DC Shift the audio data, with basic linear
- amplitudate formula. This is most useful if
- your audio data tends to not be centered around
- a value of 0. Shifting it back will allow you
- to get the most volume adjustments without clip�
- ping audio data.
+ amplitude formula. This is most useful if your
+ audio data tends to not be centered around a
+ value of 0. Shifting it back will allow you to
+ get the most volume adjustments without clipping
+ audio data.
The first option is the dcshift value. It is a
floating point number that indicates the amount
to shift.
@@ -723,10 +747,10 @@
windows a more gradual cutoff.
The beta, if unspecified, defaults to 16. This
- selects a Kaiser window. You can select a
- Nuttall window by specifying anything <= 2.0
- here. For more discussion of beta, look under
- the resample effect.
+ selects a Kaiser window. You can select a Nut�
+ tall window by specifying anything <= 2.0 here.
+ For more discussion of beta, look under the
+ resample effect.
flanger gain-in gain-out delay decay speed < -s | -t >
@@ -745,8 +769,8 @@
for a highpass effect with sharper cutoff.
highpass frequency
- Butterworth highpass filter. Description com�
- ming soon!
+ Butterworth highpass filter. Description coming
+ soon!
lowp frequency
Apply a single pole recursive low-pass filter.
@@ -797,7 +821,7 @@
pick [ -1 | -2 | -3 | -4 | -l | -r ]
Select the left or right channel of a stereo
- sample, or one of four channels in a quadro�
+ sample, or one of four channels in a quadra�
phonic sample. The -l and -r options represent
either the left or right channel. It is
required that you use the -c 1 command line
@@ -831,11 +855,11 @@
dow. Default is nut.
-width long / short / # : specify the (approxi�
- mate) width of the filter. long is 1024 sam�
- ples; short is 128 samples. Alternatively, an
- exact number can be used. Default is long. The
- short option is not recommended, as it produces
- poor quality results.
+ mate) width of the filter. long is 1024
+ samples; short is 128 samples. Alternatively,
+ an exact number can be used. Default is long.
+ The short option is not recommended, as it pro�
+ duces poor quality results.
-cutoff # : specify the filter cutoff frequency
in terms of fraction of frequency bandwidth,
@@ -889,7 +913,7 @@
the -q* options.
Following is a table of the reasonable defaults
- which are built-in to sox:
+ which are built-in to SoX:
Option Window rolloff beta interpolation
------ ------ ------- ---- -------------
@@ -1011,7 +1035,7 @@
that must be below a given threshold before
stopping to process audio data. A count of
periods that occur below the threshold may also
- be speficied. If this options are not specified
+ be specified. If this options are not specified
then data is not trimmed from the end of the
audio file.
Duration counts may be in the format of time,
@@ -1066,7 +1090,7 @@
print out a hex dump of the sound file from the
internal buffer that is in 32-bit signed PCM
data. This is mainly only of use in tracking
- down endian problems that creep in to sox on
+ down endian problems that creep in to SoX on
cross-platform versions.
@@ -1185,7 +1209,7 @@
The syntax is horrific. Thats the breaks when trying to
handle all things from the command line.
- Please report any bugs found in this version of sox to
+ Please report any bugs found in this version of SoX to
Chris Bagwell (cbagwell@sprynet.com)
FILES
@@ -1193,12 +1217,17 @@
play(1), rec(1), soxexam(1)
NOTICES
- The version of Sox that accompanies this manual page is
+ The version of SoX that accompanies this manual page is
support by Chris Bagwell (cbagwell@users.sourceforge.net).
Please refer any questions regarding it to this address.
You may obtain the latest version at the the web site
http://sox.sourceforge.net/
+AUTHOR
+ Chris Bagwell (cbagwell@users.sourceforge.net).
+ Updates by Anonymous
- July 24, 2000 SoX(1)
+
+
+ December 11, 2001 SoX(1)
--- a/soxexam.txt
+++ b/soxexam.txt
@@ -8,27 +8,27 @@
CONVERSIONS
Introduction
- In general, sox will attempt to take an input sound file
- format and convert it to a new file format using a similar
- data type and sample rate. For instance, "sox monkey.au
- monkey.wav" would try and convert the mono 8000Hz u-law
- sample .au file that comes with sox to a 8000Hz u-law .wav
- file.
+ In general, SoX will attempt to take an input sound file
+ format and convert it into a new file format using a simi�
+ lar data type and sample rate. For instance, "sox mon�
+ key.au monkey.wav" would try and convert the mono 8000Hz
+ u-law sample .au file that comes with SoX to a 8000Hz u-
+ law .wav file.
If an output format doesn't support the same data type as
- the input file then sox will generally select a default
+ the input file then SoX will generally select a default
data type to save it in. You can override the default
data type selection by using command line options. This
- is also useful for producing a output file with higher or
+ is also useful for producing an output file with higher or
lower precision data and/or sample rate.
Most file formats that contain headers can automatically
- be read in. When working with headerless file formats
- then a user must manually tell sox the data type and sam�
+ be read in. When working with header-less file formats
+ then a user must manually tell SoX the data type and sam�
ple rate using command line options.
- When working with headerless files (raw files), you may
- take advantage of they pseudo-file types of .ub, .uw, .sb,
+ When working with header-less files (raw files), you may
+ take advantage of the pseudo-file types of .ub, .uw, .sb,
.sw, .ul, and .sl. By using these extensions on your
filenames you will not have to specify the corresponding
options on the command line.
@@ -48,8 +48,8 @@
___________ _________
unsigned byte 8-bit
signed byte 8-bit
- u-law 12-bit
- a-law 12-bit
+ u-law 14-bit
+ A-law 13-bit
unsigned word 16-bit
signed word 16-bit
ADPCM 16-bit
@@ -79,43 +79,70 @@
sox -r 8000 -u -b -c 1 filename.raw filename.wav
+ SoX may even be used to convert sample rates. Downcon�
+ verting will reduce the bandwidth of a sample, but will
+ reduce storage space on your disk. All such conversions
+ are lossy and will introduce some noise. You should
+ really pass your sample through a low pass filter prior to
+ downconverting as this will prevent alias signals (which
+ would sound like additional noise). For example to con�
+ vert from a sample recorded at 11025 Hz to a u-law file at
+ 8000 Hz sample rate:
+
+ sox infile.wav -t au -r 8000 -U -b -c 1 outputfile.au
+
+ To add a low-pass filter (note use of stdout for output of
+ the first stage and stdin for input on the second stage):
+
+ sox infile.wav -t raw -s -w -c 1 - lowpass 3700 |
+ sox -t raw -r 11025 -s -w -c 1 - -t au -r 8000 -U -b
+ -c 1 ofile.au
+
+ If you hear some clicks and pops when converting to u-law
+ or A-law, reduce the output level slightly, for example
+ this will decrease it by 20%:
+
+ sox infile.wav -t au -r 8000 -U -b -c 1 -v .8 output�
+ file.au
+
+
SoX is great to use along with other command line programs
by passing data between the programs using pipelines. The
- most common example is to use mpg123 to convert mp3 files
+ most common example is to use mpg123 to convert mp3 files
in to wav files. The following command line will do this:
mpg123 -b 10000 -s filename.mp3 | sox -t raw -r 44100 -s
-w -c 2 - filename.wav
- When working with totally unknown audio data then the
- "auto" file format may be of use. It attempts to guess
- what the file type is and then you may save it in to a
+ When working with totally unknown audio data then the
+ "auto" file format may be of use. It attempts to guess
+ what the file type is and then you may save it into a
known audio format.
sox -V -t auto filename.snd filename.wav
- It is important to understand how the internals of SoX
- work with compressed audio including u-law, a-law, ADPCM,
- or GSM. SoX takes ALL input data types and converts them
- to uncompressed 32-bit signed data. It will then convert
- this internal version into the requested output format.
- This means unneeded noise can be introduced from decom�
- pressing data and then recompressing. If applying multi�
- ple effects to audio data it is best to save the interme�
- diate data as PCM data. After the final effect is per�
- formed then you can specify it as a compressed output for�
- mat. This will keep noise introduction to a minimum.
+ It is important to understand how the internals of SoX
+ work with compressed audio including u-law, A-law, ADPCM,
+ or GSM. SoX takes ALL input data types and converts them
+ to uncompressed 32-bit signed data. It will then convert
+ this internal version into the requested output format.
+ This means additional noise can be introduced from decom�
+ pressing data and then recompressing. If applying multi�
+ ple effects to audio data, it is best to save the interme�
+ diate data as PCM data. After the final effect is
+ performed, then you can specify it as a compressed output
+ format. This will keep noise introduction to a minimum.
- The following example is to apply various effects to an
- 8000 Hz ADPCM input file and then end up with the final
- file as 44100 Hz ADPCM.
+ The following example applies various effects to an 8000
+ Hz ADPCM input file and then end up with the final file as
+ 44100 Hz ADPCM.
sox firstfile.wav -r 44100 -s -w secondfile.wav
sox secondfile.wav thirdfile.wav swap
sox thirdfile.wav -a -b finalfile.wav mask
- Under a DOS shell, you can convert several audio files to
- an new output format using something similar to the fol�
+ Under a DOS shell, you can convert several audio files to
+ an new output format using something similar to the fol�
lowing command line:
FOR %X IN (*.RAW) DO sox -r 11025 -w -s -t raw $X $X.wav
@@ -127,53 +154,55 @@
Introduction:
The core problem is that you need some experience in using
- effects in order to say "that any old sound file sounds
- with effects absolutely hip". There isn't any rule-based
- system which tell you the correct setting of all the
+ effects in order to say "that any old sound file sounds
+ with effects absolutely hip". There isn't any rule-based
+ system which tell you the correct setting of all the
parameters for every effect. But after some time you will
become an expert in using effects.
- Here are some examples which can be used with any music
- sample. (For a sample where only a single instrument is
- playing, extreme parameter setting may make well-known
- "typically" or "classical" sounds. Likewise, for drums,
+ Here are some examples which can be used with any music
+ sample. (For a sample where only a single instrument is
+ playing, extreme parameter setting may make well-known
+ "typically" or "classical" sounds. Likewise, for drums,
vocals or guitars.)
- Single effects will be explained and some given parameter
+ Single effects will be explained and some given parameter
settings that can be used to understand the theory by lis�
tening to the sound file with the added effect.
- Using multiple effects in parallel or in sequel can result
- either in very perfect sound or ( mostly ) in a dramatic
+ Using multiple effects in parallel or in series can result
+ either in a very nice sound or (mostly) in a dramatic
overloading in variations of sounds such that your ear may
follow the sound but you will feel unsatisfied. Hence, for
- the first time using effects try to compose them as less
- as possible. We don't regard the composition of effects in
- the examples because to many combinations are possible and
- you really need a very fast machine and a lot of memory to
- play them in real-time.
+ the first time using effects try to compose them as mini�
+ mally as possible. We don't regard the composition of
+ effects in the examples because too many combinations are
+ possible and you really need a very fast machine and a lot
+ of memory to play them in real-time.
- And real-time playing of sounds will speed up learning the
- parameter setting.
+ However, real-time playing of sounds will greatly speed up
+ learning and/or tuning the parameter settings for your
+ sounds in order to get that "perfect" effect.
- Basically, we will use the "play" front-end of SOX since
+ Basically, we will use the "play" front-end of SoX since
it is easier to listen sounds coming out of the speaker or
earphone instead of looking at cryptic data in sound
files.
- For easy listening of file.xxx ( "xxx" is any sound format
- ):
+ For easy listening of file.xxx ("xxx" is any sound for�
+ mat):
play file.xxx effect-name effect-parameters
- Or more SOX-like ( for "dsp" output ):
+ Or more SoX-like (for "dsp" output on a UNIX/Linux com�
+ puter):
- sox file.xxx -t ossdsp -w -s /dev/dsp effect-name
+ sox file.xxx -t ossdsp -w -s /dev/dsp effect-name
effect-parameters
- or ( for "au" output ):
+ or (for "au" output):
- sox file.xxx -t sunau -w -s /dev/audio effect-name
+ sox file.xxx -t sunau -w -s /dev/audio effect-name
effect-parameters
And for date freaks:
@@ -185,16 +214,16 @@
Notes:
- I played all examples in real-time on a Pentium 100 with
+ I played all examples in real-time on a Pentium 100 with
32 MB and Linux 2.0.30 using a self-recorded sample ( 3:15
- min long in "wav" format with 44.1 kHz sample rate and
+ min long in "wav" format with 44.1 kHz sample rate and
stereo 16 bit ). The sample should not contain any of the
- effects. However, if you take any recording of a sound
- track from radio or tape or cd, and it sounds like a live
- concert or ten people are playing the same rhythm with
- their drums or funky-grooves, then take any other sample.
- (Typically, less then four different instruments and no
- synthesizer in the sample is suitable. Likewise, the com�
+ effects. However, if you take any recording of a sound
+ track from radio or tape or CD, and it sounds like a live
+ concert or ten people are playing the same rhythm with
+ their drums or funky-grooves, then take any other sample.
+ (Typically, less then four different instruments and no
+ synthesizer in the sample is suitable. Likewise, the com�
bination vocal, drums, bass and guitar.)
Effects:
@@ -201,33 +230,33 @@
Echo
- An echo effect can be naturally found in the mountains,
- standing somewhere on a mountain and shouting a single
- word will result in one or more repetitions of the word (
- if not, turn a bit around ant try next, or climb to the
- next mountain ).
+ An echo effect can be naturally found in the mountains,
+ standing somewhere on a mountain and shouting a single
+ word will result in one or more repetitions of the word
+ (if not, turn a bit around and try again, or climb to the
+ next mountain).
- However, the time difference between shouting and repeat�
+ However, the time difference between shouting and repeat�
ing is the delay (time), its loudness is the decay. Multi�
ple echos can have different delays and decays.
- Very popular is using echos to play an instrument with
- itself together, like some guitar players ( Brain May from
- Queen ) or vocalists are doing. For music samples of more
+ It is very popular to use echos to play an instrument with
+ itself together, like some guitar players (Brain May from
+ Queen) or vocalists are doing. For music samples of more
than one instrument, echo can be used to add a second sam�
ple shortly after the original one.
- This will sound as doubling the number of instruments
- playing the same sample:
+ This will sound as if you are doubling the number of
+ instruments playing in the same sample:
play file.xxx echo 0.8 0.88 60.0 0.4
- If the delay is very short then it sound like a (metallic)
- robot playing music:
+ If the delay is very short, then it sound like a (metal�
+ lic) robot playing music:
play file.xxx echo 0.8 0.88 6.0 0.4
- Longer delay will sound like a open air concert in the
+ Longer delay will sound like an open air concert in the
mountains:
play file.xxx echo 0.8 0.9 1000.0 0.3
@@ -238,12 +267,12 @@
Echos
- Like the echo effect, echos stand for "ECHO in Sequel",
- that is the first echos takes the input, the second the
- input and the first echos, the third the input and the
+ Like the echo effect, echos stand for "ECHO in Sequel",
+ that is the first echos takes the input, the second the
+ input and the first echos, the third the input and the
first and the second echos, ... and so on. Care should be
- taken using many echos ( see introduction ); a single
- echos has the same effect as a single echo.
+ taken using many echos (see introduction); a single echos
+ has the same effect as a single echo.
The sample will be bounced twice in symmetric echos:
@@ -253,27 +282,27 @@
play file.xxx echos 0.8 0.7 700.0 0.25 900.0 0.3
- The sample will sound as played in a garage:
+ The sample will sound as if played in a garage:
play file.xxx echos 0.8 0.7 40.0 0.25 63.0 0.3
Chorus
- The chorus effect has its name because it will often be
- used to make a single vocal sound like a chorus. But it
+ The chorus effect has its name because it will often be
+ used to make a single vocal sound like a chorus. But it
can be applied to other instrument samples too.
- It works like the echo effect with a short delay, but the
- delay isn't constant. The delay is varied using a sinu�
- soidal or triangular modulation. The modulation depth
- defines the range the modulated delay is played before or
+ It works like the echo effect with a short delay, but the
+ delay isn't constant. The delay is varied using a sinu�
+ soidal or triangular modulation. The modulation depth
+ defines the range the modulated delay is played before or
after the delay. Hence the delayed sound will sound slower
- or faster, that is the delayed sound tuned around the
- original one, like in a chorus where some vocal are a bit
+ or faster, that is the delayed sound tuned around the
+ original one, like in a chorus where some vocals are a bit
out of tune.
The typical delay is around 40ms to 60ms, the speed of the
- modulation is best near 0.25Hz and the modulation depth
+ modulation is best near 0.25Hz and the modulation depth
around 2ms.
A single delay will make the sample more overloaded:
@@ -282,11 +311,10 @@
Two delays of the original samples sound like this:
- play file.xxx chorus 0.6 0.9 50.0 0.4 0.25 2.0 -t
+ play file.xxx chorus 0.6 0.9 50.0 0.4 0.25 2.0 -t
60.0 0.32 0.4 1.3 -s
- A big chorus of the sample is ( three additional samples
- ):
+ A big chorus of the sample is (three additional samples):
play file.xxx chorus 0.5 0.9 50.0 0.4 0.25 2.0 -t
60.0 0.32 0.4 2.3 -t 40.0 0.3 0.3 1.3 -s
@@ -326,30 +354,33 @@
Reverb
The reverb effect is often used in audience hall which are
- to small or to many visitors disturb the reflection of
- sound at the walls to make the sound played more
- monumental. You can try the reverb effect in your bathroom
- or garage or sport halls by shouting loud some words.
- You'll hear the words reflected from the walls.
+ to small or contain too many many visitors which disturb
+ (dampen) the reflection of sound at the walls. Reverb
+ will make the sound be perceived as if it were in a large
+ hall. You can try the reverb effect in your bathroom or
+ garage or sport halls by shouting loud some words. You'll
+ hear the words reflected from the walls.
The biggest problem in using the reverb effect is the cor�
- rect setting of the (wall) delays such that the sound is
- realistic an doesn't sound like music playing in a tin or
- overloaded feedback destroys any illusion of any big hall.
- To help you for much realistic reverb effects, you should
- decide first, how long the reverb should take place until
- it is not loud enough to be registered by your ears. This
- is be done by the reverb time "t", in small halls 200ms in
- bigger one 1000ms, if you like. Clearly, the walls of such
- a hall aren't far away, so you should define its setting
- be given every wall its delay time. However, if the wall
- is to far away for the reverb time, you won't hear the
- reverb, so the nearest wall will be best "t/4" delay and
- the farthest "t/2". You can try other distances as well,
- but it won't sound very realistic. The walls shouldn't
- stand to close to each other and not in a multiple integer
- distance to each other ( so avoid wall like: 200.0 and
- 202.0, or something like 100.0 and 200.0 ).
+ rect setting of the (wall) delays such that the sound is
+ realistic and doesn't sound like music playing in a tin
+ can or has overloaded feedback which destroys any illusion
+ of playing in a big hall. To help you obtain realistic
+ reverb effects, you should decide first how long the
+ reverb should take place until it is not loud enough to be
+ registered by your ears. This is be done by varying the
+ reverb time "t". To simulate small halls, use 200ms. To
+ simulate large halls, use 1000ms. Clearly, the walls of
+ such a hall aren't far away, so you should define its set�
+ ting be given every wall its delay time. However, if the
+ wall is to far away for the reverb time, you won't hear
+ the reverb, so the nearest wall will be best at "t/4"
+ delay and the farthest at "t/2". You can try other dis�
+ tances as well, but it won't sound very realistic. The
+ walls shouldn't stand to close to each other and not in a
+ multiple integer distance to each other ( so avoid wall
+ like: 200.0 and 202.0, or something like 100.0 and 200.0
+ ).
Since audience halls do have a lot of walls, we will start
designing one beginning with one wall:
@@ -362,39 +393,39 @@
Next two walls:
- play file.xxx reverb 1.0 600.0 180.0 200.0 220.0
+ play file.xxx reverb 1.0 600.0 180.0 200.0 220.0
240.0
Now, why not a futuristic hall with six walls:
- play file.xxx reverb 1.0 600.0 180.0 200.0 220.0
+ play file.xxx reverb 1.0 600.0 180.0 200.0 220.0
240.0 280.0 300.0
- If you run out of machine power or memory, then stop as
- much applications as possible ( every interrupt will con�
- sume a lot of CPU time which for bigger halls is abso�
- lutely necessary ).
+ If you run out of machine power or memory, then stop as
+ many applications as possible (every interrupt will con�
+ sume a lot of CPU time which for bigger halls is abso�
+ lutely necessary).
Phaser
- The phaser effect is like the flanger effect, but it uses
- a reverb instead of an echo and does phase shifting.
- You'll hear the difference in the examples comparing both
- effects ( simply change the effect name ). The delay mod�
- ulation can be done sinusoidal or triangular, preferable
- is the later one for multiple instruments playing. For
- single instrument sounds the sinusoidal phaser effect will
- give a sharper phasing effect. The decay shouldn't be to
- close to 1.0 which will cause dramatic feedback. A good
- range is about 0.5 to 0.1 for the decay.
+ The phaser effect is like the flanger effect, but it uses
+ a reverb instead of an echo and does phase shifting.
+ You'll hear the difference in the examples comparing both
+ effects (simply change the effect name). The delay modu�
+ lation can be sinusoidal or triangular, preferable is the
+ later for multiple instruments. For single instrument
+ sounds, the sinusoidal phaser effect will give a sharper
+ phasing effect. The decay shouldn't be to close to 1.0
+ which will cause dramatic feedback. A good range is about
+ 0.5 to 0.1 for the decay.
We will take a parameter setting as for the flanger before
- ( gain-out is lower since feedback can raise the output
- dramatically ):
+ (gain-out is lower since feedback can raise the output
+ dramatically):
play file.xxx phaser 0.8 0.74 3.0 0.4 0.5 -t
- The drunken loudspeaker system ( now less alcohol ):
+ The drunken loudspeaker system (now less alcohol):
play file.xxx phaser 0.9 0.85 4.0 0.23 1.3 -s
@@ -408,59 +439,85 @@
Compander
- The compander effect allows the dynamic range of a signal
- to be compressed or expanded. For most situations, the
- attack time (response to the music getting louder) should
- be shorter than the decay time because our ears are more
- sensitive to suddenly loud music than to suddenly soft
+ The compander effect allows the dynamic range of a signal
+ to be compressed or expanded. For most situations, the
+ attack time (response to the music getting louder) should
+ be shorter than the decay time because our ears are more
+ sensitive to suddenly loud music than to suddenly soft
music.
- For example, suppose you are listening to Strauss' "Also
- Sprach Zarathustra" in a noisy environment such as a car.
+ For example, suppose you are listening to Strauss' "Also
+ Sprach Zarathustra" in a noisy environment such as a car.
If you turn up the volume enough to hear the soft passages
- over the road noise, the loud sections will be too loud.
+ over the road noise, the loud sections will be too loud.
You could try this:
- play file.xxx compand 0.3,1
+ play file.xxx compand 0.3,1
-90,-90,-70,-70,-60,-20,0,0 -5 0 0.2
- The transfer function ("-90,...") says that very soft
- sounds between -90 and -70 decibels (-90 is about the
- limit of 16-bit encoding) will remain unchanged. That
- keeps the compander from boosting the volume on "silent"
- passages such as between movements. However, sounds in
+ The transfer function ("-90,...") says that very soft
+ sounds between -90 and -70 decibels (-90 is about the
+ limit of 16-bit encoding) will remain unchanged. That
+ keeps the compander from boosting the volume on "silent"
+ passages such as between movements. However, sounds in
the range -60 decibels to 0 decibels (maximum volume) will
be boosted so that the 60-dB dynamic range of the original
- music will be compressed 3-to-1 into a 20-dB range, which
+ music will be compressed 3-to-1 into a 20-dB range, which
is wide enough to enjoy the music but narrow enough to get
around the road noise. The -5 dB output gain is needed to
- avoid clipping (the number is inexact, and was derived by
- experimentation). The 0 for the initial volume will work
+ avoid clipping (the number is inexact, and was derived by
+ experimentation). The 0 for the initial volume will work
fine for a clip that starts with a bit of silence, and the
- delay of 0.2 has the effect of causing the compander to
+ delay of 0.2 has the effect of causing the compander to
react a bit more quickly to sudden volume changes.
- Other effects ( copy, rate, avg, stat, vibro, lowp, highp,
- band, reverb )
+ Changing the Rate of Playback
- The other effects are simple to use. However, an "easy to
+ You can use stretch to change the rate of playback of an
+ audio sample while preserving the pitch. For example to
+ play at 1/2 the speed:
+
+ play file.wav stretch 2
+
+ To play a file at twice the speed:
+
+ play file.wav stretch .5
+
+ Other related options are "speed" to change the speed of
+ play (and changing the pitch accordingly), and pitch, to
+ alter the pitch of a sample. For example to speed a sam�
+ ple so it plays in 1/2 the time (for those Mickey Mouse
+ voices):
+
+ play file.wav speed 2
+
+ To raise the pitch of a sample 1 while note (100 cents):
+
+ play file.wav pitch 100
+
+
+
+ Other effects (copy, rate, avg, stat, vibro, lowp, highp,
+ band, reverb)
+
+ The other effects are simple to use. However, an "easy to
use manual" should be given here.
- More effects ( to do ! )
+ More effects (to do !)
- There are a lot of effects around like noise gates, com�
- pressors, waw-waw, stereo effects and so on. They should
- be implemented making SOX to be more useful in sound mix�
- ing techniques coming together with a great variety of
- different sound effects.
+ There are a lot of effects around like noise gates, com�
+ pressors, waw-waw, stereo effects and so on. They should
+ be implemented, making SoX more useful in sound mixing
+ techniques coming together with a great variety of differ�
+ ent sound effects.
- Combining effects by using them in parallel or sequence on
- different channels needs some easy mechanism which is
- real-time stable.
+ Combining effects by using them in parallel or serially on
+ different channels needs some easy mechanism which is sta�
+ ble for use in real-time.
- Really missing, is the changing of the parameters, start�
- ing and stopping of effects while playing samples in real-
- time!
+ Really missing are the the changing of the parameters and
+ starting/stopping of effects while playing samples in
+ real-time!
Good luck and have fun with all the effects!
@@ -470,6 +527,11 @@
SEE ALSO
sox(1), play(1), rec(1)
+AUTHOR
+ Juergen Mueller (jmueller@uia.ua.ac.be)
+ Updates by Anonymous.
- December 10, 1999 SoX(1)
+
+
+ December 11, 2001 SoX(1)
--- a/src/g711.c
+++ b/src/g711.c
@@ -104,6 +104,7 @@
*/
/* pcm_val = pcm_val >> 3; */
+ /* A-law using even bit inversion */
if (pcm_val >= 0) {
mask = 0xD5; /* sign (7th) bit = 1 */
} else {
@@ -205,6 +206,7 @@
*/
/* pcm_val = pcm_val >> 2; */
+ /* u-law inverts all bits */
/* Get the sign and the magnitude of the value. */
if (pcm_val < 0) {
pcm_val = -pcm_val;
--- a/src/handlers.c
+++ b/src/handlers.c
@@ -93,6 +93,18 @@
(char *) 0
};
+/* inverse a-law byte raw */
+static char *lanames[] = {
+ "la",
+ (char *) 0
+};
+
+/* inverse u-law byte raw */
+static char *lunames[] = {
+ "lu",
+ (char *) 0
+};
+
/* Amiga MAUD */
static char *maudnames[] = {
"maud",
@@ -272,6 +284,12 @@
{hcomnames, 0,
st_hcomstartread, st_hcomread, st_hcomstopread,
st_hcomstartwrite, st_hcomwrite, st_hcomstopwrite, st_format_nothing_seek},
+ {lanames, ST_FILE_STEREO,
+ st_lastartread, st_rawread, st_rawstopread,
+ st_lastartwrite, st_rawwrite, st_rawstopwrite, st_format_nothing_seek},
+ {lunames, ST_FILE_STEREO,
+ st_lustartread, st_rawread, st_rawstopread,
+ st_lustartwrite, st_rawwrite, st_rawstopwrite, st_format_nothing_seek},
{maudnames, ST_FILE_STEREO,
st_maudstartread, st_maudread, st_maudstopread,
st_maudstartwrite, st_maudwrite, st_maudstopwrite, st_format_nothing_seek},
--- a/src/raw.c
+++ b/src/raw.c
@@ -38,11 +38,47 @@
#define MIN(a,b) ((a)<(b)?(a):(b))
#endif
+/* Lookup table to reverse the bit order of a byte. ie MSB become LSB */
+unsigned char cswap[256] = {
+ 0x00, 0x80, 0x40, 0xC0, 0x20, 0xA0, 0x60, 0xE0, 0x10, 0x90, 0x50, 0xD0,
+ 0x30, 0xB0, 0x70, 0xF0, 0x08, 0x88, 0x48, 0xC8, 0x28, 0xA8, 0x68, 0xE8,
+ 0x18, 0x98, 0x58, 0xD8, 0x38, 0xB8, 0x78, 0xF8, 0x04, 0x84, 0x44, 0xC4,
+ 0x24, 0xA4, 0x64, 0xE4, 0x14, 0x94, 0x54, 0xD4, 0x34, 0xB4, 0x74, 0xF4,
+ 0x0C, 0x8C, 0x4C, 0xCC, 0x2C, 0xAC, 0x6C, 0xEC, 0x1C, 0x9C, 0x5C, 0xDC,
+ 0x3C, 0xBC, 0x7C, 0xFC, 0x02, 0x82, 0x42, 0xC2, 0x22, 0xA2, 0x62, 0xE2,
+ 0x12, 0x92, 0x52, 0xD2, 0x32, 0xB2, 0x72, 0xF2, 0x0A, 0x8A, 0x4A, 0xCA,
+ 0x2A, 0xAA, 0x6A, 0xEA, 0x1A, 0x9A, 0x5A, 0xDA, 0x3A, 0xBA, 0x7A, 0xFA,
+ 0x06, 0x86, 0x46, 0xC6, 0x26, 0xA6, 0x66, 0xE6, 0x16, 0x96, 0x56, 0xD6,
+ 0x36, 0xB6, 0x76, 0xF6, 0x0E, 0x8E, 0x4E, 0xCE, 0x2E, 0xAE, 0x6E, 0xEE,
+ 0x1E, 0x9E, 0x5E, 0xDE, 0x3E, 0xBE, 0x7E, 0xFE, 0x01, 0x81, 0x41, 0xC1,
+ 0x21, 0xA1, 0x61, 0xE1, 0x11, 0x91, 0x51, 0xD1, 0x31, 0xB1, 0x71, 0xF1,
+ 0x09, 0x89, 0x49, 0xC9, 0x29, 0xA9, 0x69, 0xE9, 0x19, 0x99, 0x59, 0xD9,
+ 0x39, 0xB9, 0x79, 0xF9, 0x05, 0x85, 0x45, 0xC5, 0x25, 0xA5, 0x65, 0xE5,
+ 0x15, 0x95, 0x55, 0xD5, 0x35, 0xB5, 0x75, 0xF5, 0x0D, 0x8D, 0x4D, 0xCD,
+ 0x2D, 0xAD, 0x6D, 0xED, 0x1D, 0x9D, 0x5D, 0xDD, 0x3D, 0xBD, 0x7D, 0xFD,
+ 0x03, 0x83, 0x43, 0xC3, 0x23, 0xA3, 0x63, 0xE3, 0x13, 0x93, 0x53, 0xD3,
+ 0x33, 0xB3, 0x73, 0xF3, 0x0B, 0x8B, 0x4B, 0xCB, 0x2B, 0xAB, 0x6B, 0xEB,
+ 0x1B, 0x9B, 0x5B, 0xDB, 0x3B, 0xBB, 0x7B, 0xFB, 0x07, 0x87, 0x47, 0xC7,
+ 0x27, 0xA7, 0x67, 0xE7, 0x17, 0x97, 0x57, 0xD7, 0x37, 0xB7, 0x77, 0xF7,
+ 0x0F, 0x8F, 0x4F, 0xCF, 0x2F, 0xAF, 0x6F, 0xEF, 0x1F, 0x9F, 0x5F, 0xDF,
+ 0x3F, 0xBF, 0x7F, 0xFF
+};
+
#define ST_ULAW_BYTE_TO_SAMPLE(d) ((st_sample_t)(st_ulaw2linear16(d)) << 16)
#define ST_ALAW_BYTE_TO_SAMPLE(d) ((st_sample_t)(st_alaw2linear16(d)) << 16)
#define ST_SAMPLE_TO_ULAW_BYTE(d) (st_14linear2ulaw((int16_t)((d) >> 18)))
#define ST_SAMPLE_TO_ALAW_BYTE(d) (st_13linear2alaw((int16_t)((d) >> 19)))
+/* Some hardware sends MSB last. These account for that */
+#define ST_INVERT_ULAW_BYTE_TO_SAMPLE(d) \
+ ((st_sample_t)(st_ulaw2linear16(cswap[d])) << 16)
+#define ST_INVERT_ALAW_BYTE_TO_SAMPLE(d) \
+ ((st_sample_t)(st_alaw2linear16(cswap[d])) << 16)
+#define ST_SAMPLE_TO_INVERT_ULAW_BYTE(d) \
+ (cswap[st_14linear2ulaw((int16_t)((d) >> 18))])
+#define ST_SAMPLE_TO_INVERT_ALAW_BYTE(d) \
+ (cswap[st_13linear2alaw((int16_t)((d) >> 19))])
+
static void rawdefaults(ft_t ft);
int st_rawseek(ft_t ft, st_size_t offset)
@@ -125,31 +161,63 @@
void st_ulaw_read_buf(st_sample_t *buf1, char *buf2, st_ssize_t len,
char swap)
{
- while (len)
+ if (swap)
{
- uint8_t datum;
+ while (len)
+ {
+ uint8_t datum;
- datum = *((uint8_t *)buf2);
- buf2++;
+ datum = *((uint8_t *)buf2);
+ buf2++;
- *buf1++ = ST_ULAW_BYTE_TO_SAMPLE(datum);
- len--;
+ *buf1++ = ST_INVERT_ULAW_BYTE_TO_SAMPLE(datum);
+ len--;
+ }
}
+ else
+ {
+ while (len)
+ {
+ uint8_t datum;
+
+ datum = *((uint8_t *)buf2);
+ buf2++;
+
+ *buf1++ = ST_ULAW_BYTE_TO_SAMPLE(datum);
+ len--;
+ }
+ }
}
void st_alaw_read_buf(st_sample_t *buf1, char *buf2, st_ssize_t len,
char swap)
{
- while (len)
+ if (swap)
{
- uint8_t datum;
+ while (len)
+ {
+ uint8_t datum;
- datum = *((uint8_t *)buf2);
- buf2++;
+ datum = *((uint8_t *)buf2);
+ buf2++;
- *buf1++ = ST_ALAW_BYTE_TO_SAMPLE(datum);
- len--;
+ *buf1++ = ST_INVERT_ALAW_BYTE_TO_SAMPLE(datum);
+ len--;
+ }
}
+ else
+ {
+ while (len)
+ {
+ uint8_t datum;
+
+ datum = *((uint8_t *)buf2);
+ buf2++;
+
+ *buf1++ = ST_ALAW_BYTE_TO_SAMPLE(datum);
+ len--;
+ }
+ }
}
void st_uw_read_buf(st_sample_t *buf1, char *buf2, st_ssize_t len, char swap)
@@ -408,21 +476,43 @@
void st_ulaw_write_buf(char *buf1, st_sample_t *buf2, st_ssize_t len,
char swap)
{
- while (len)
+ if (swap)
{
- *(uint8_t *)buf1++ = ST_SAMPLE_TO_ULAW_BYTE(*buf2++);
- len--;
+ while (len)
+ {
+ *(uint8_t *)buf1++ = ST_SAMPLE_TO_INVERT_ULAW_BYTE(*buf2++);
+ len--;
+ }
}
+ else
+ {
+ while (len)
+ {
+ *(uint8_t *)buf1++ = ST_SAMPLE_TO_ULAW_BYTE(*buf2++);
+ len--;
+ }
+ }
}
void st_alaw_write_buf(char *buf1, st_sample_t *buf2, st_ssize_t len,
char swap)
{
- while (len)
+ if (swap)
{
- *(uint8_t *)buf1++ = ST_SAMPLE_TO_ALAW_BYTE(*buf2++);
- len--;
+ while (len)
+ {
+ *(uint8_t *)buf1++ = ST_SAMPLE_TO_INVERT_ALAW_BYTE(*buf2++);
+ len--;
+ }
}
+ else
+ {
+ while (len)
+ {
+ *(uint8_t *)buf1++ = ST_SAMPLE_TO_ALAW_BYTE(*buf2++);
+ len--;
+ }
+ }
}
void st_uw_write_buf(char *buf1, st_sample_t *buf2, st_ssize_t len, char swap)
@@ -684,6 +774,42 @@
STARTREAD(st_alstartread,ST_SIZE_BYTE,ST_ENCODING_ALAW)
STARTWRITE(st_alstartwrite,ST_SIZE_BYTE,ST_ENCODING_ALAW)
+
+int st_lustartread(ft_t ft)
+{
+ ft->info.size = ST_SIZE_BYTE;
+ ft->info.encoding = ST_ENCODING_ALAW;
+ ft->swap = ft->swap ? 0 : 1;
+ rawdefaults(ft);
+ return st_rawstartread(ft);
+}
+
+int st_lastartread(ft_t ft)
+{
+ ft->info.size = ST_SIZE_BYTE;
+ ft->info.encoding = ST_ENCODING_ALAW;
+ ft->swap = ft->swap ? 0 : 1;
+ rawdefaults(ft);
+ return st_rawstartread(ft);
+}
+
+int st_lustartwrite(ft_t ft)
+{
+ ft->info.size = ST_SIZE_BYTE;
+ ft->info.encoding = ST_ENCODING_ALAW;
+ ft->swap = ft->swap ? 0 : 1;
+ rawdefaults(ft);
+ return st_rawstartwrite(ft);
+}
+
+int st_lastartwrite(ft_t ft)
+{
+ ft->info.size = ST_SIZE_BYTE;
+ ft->info.encoding = ST_ENCODING_ALAW;
+ ft->swap = ft->swap ? 0 : 1;
+ rawdefaults(ft);
+ return st_rawstartwrite(ft);
+}
void rawdefaults(ft_t ft)
{
--- a/src/st_i.h
+++ b/src/st_i.h
@@ -216,6 +216,12 @@
st_ssize_t st_hcomwrite(ft_t ft, st_sample_t *buf, st_ssize_t len);
int st_hcomstopwrite(ft_t ft);
+int st_lastartread(ft_t ft);
+int st_lastartwrite(ft_t ft);
+
+int st_lustartread(ft_t ft);
+int st_lustartwrite(ft_t ft);
+
int st_maudstartread(ft_t ft);
st_ssize_t st_maudread(ft_t ft, st_sample_t *buf, st_ssize_t len);
int st_maudstopread(ft_t ft);