Headerless audio files on a SPARC computer are likely to be of format ul; on a Mac, they're likely to be u8 but with a sample rate of 11025 or 22050Hz.

See .ima and .vox for raw ADPCM formats and .cdda for raw CD digital audio.

AIFF-C is defined in DAVIC 1.4 Part 9 Annex B. This format is referred from ARIB STD-B24, which is specified for Japanese data broadcasting. Private chunks are not supported.

	sox_ng infile -t alsa
	sox_ng infile -t alsa default
	sox_ng infile -t alsa plughw:0,0
	sox_ng -b 16 -t alsa hw:1 outfile

AMR-NB audio has a fixed sampling rate of 8kHz and AMR-WB of 16kHz and they support encoding to the following bit rates, selected by the -C option:

The filename is used to determine which libao plugin to use and normally, you should specify `default'. If that doesn't give the desired behavior, you can specify the short name for a given plugin (such as pulse for the PulseAudio plugin). Examples:

	sox_ng infile -t ao
	sox_ng infile -t ao default
	sox_ng infile -t ao pulse

SoX can only autodetect this type of file from its filename extension; if it is read from `standard input' (stdin) or from a file whose name does not end in `.aptx', you will need to prefix it with `-t ffmpeg'.

Some .au files are known to have invalid AU headers; these are probably original Sun μ-law 8000 Hz files and can be dealt with using the .ul format.

It is possible to override AU file header information with the -r (sampling rate) and -c (number of channels) options, in which case SoX will issue a warning about the mismatch.

Examples:

	sox_ng infile -t coreaudio
	sox_ng infile -t coreaudio default
	sox_ng infile -t coreaudio "Internal Speakers"

	sox_ng infile outfile.cvu rate 28k
	play -r 28k outfile.cvu sinc -3.4k

Values are normalized so the maximum and minimum are 1 and -1. This file format can be used to create data files for external programs such as FFT analyzers or graph routines. SoX can also convert a file in this format back into one of the other formats.

Example containing only 2 stereo samples of silence:

    ; Sample Rate 8012
    ; Channels 2
                0	0	0
    0.00012481278	0	0

SoX can only autodetect this type of file from its filename extension; if it is read from `standard input' (stdin) or from a file whose name does not end in `.dfpwm', you will need to prefix it with `-t ffmpeg'.

SoX can only autodetect this type of file from its filename extension; if it is read from `standard input' (stdin) or from a file whose name does not end in `.dts', you will need to prefix it with `-t ffmpeg'.

SoX can read native FLAC files (.flac) but can only read Ogg FLAC files (.oga) if ffmpeg is installed.

See .ogg below for information relating to support for Ogg Vorbis files.

SoX can write native FLAC files according to a given or default compression level. 8 is the default compression level and gives the best (but slowest) compression; 0 gives the least (but fastest) compression. The compression level is selected using the -C option (see sox_ng(1)) with a whole number from 0 to 8.

   sox_ng music.wav -t gsrt ring.bin
   play ring.bin

When reading MP3 files, up to 28 bits of precision is stored although only 16 bits are returned. This is to give the default behavior of writing 16-bit output files but you can specify a higher precision for the output file to prevent loss of this extra information. MP3 output files use up to 24 bits of precision while encoding.

MP3 compression parameters can be selected using SoX's -C option as follows:

The primary parameter to the LAME MP3 encoder is the bit rate. If the value of the -C value is a positive integer, it's taken as the bitrate in kbps (e.g. if you specify 128, it uses 128 kbps).

The second most important parameter is "quality" which allows balancing encoding speed vs. quality. In LAME, 0 specifies highest quality but is very slow, while 9 selects poor quality, but is fast. (5 is the default and 2 is recommended as a good trade-off for high quality encodes.)

Because the -C value is a float, the fractional part is used to select quality. 128.2 selects 128 kbps encoding with a quality of 2. There is one problem with this approach. We need 128 to specify 128 kbps encoding with default quality, so 0 means use default. Instead of 0 you have to use .01 (or .99) to specify the highest quality (128.01 or 128.99).

LAME uses bitrate to specify a constant bitrate but higher quality can be achieved using Variable Bit Rate (VBR). VBR quality (really size) is selected using a number from 0 to 9. Use a value of 0 for high quality, larger files and 9 for smaller files of lower quality. 4 is the default.

In order to squeeze the selection of VBR into the the -C value float we use negative numbers to select VBR. -4.2 would select default VBR encoding (size) with high quality (speed). One special case is 0, which is a valid VBR encoding parameter but not a valid bitrate. Compression value of 0 is always treated as a high quality VBR, as a result both -0.2 and 0.2 are treated as highest quality VBR (size) and high quality (speed).

SoX does not use twolame's VBR encoding yet, only CBR.

SoX can only autodetect mp2 files from their filename extension; if they are read from `standard input' (stdin) or from a file whose name does not end in `.mp2', you will need to prefix them with `-t mp2'.

See Ogg Vorbis for a similar format.

The NSP file format was also used for the Phonetic Database (PDB) from Speech Technology Research who had a free NSP Player, SpeakNSP. CSL NSP file reading and writing is supported by the WaveSurfer package.

SoX can decode all types of Ogg Vorbis files and can encode at different compression levels/qualities given as a number from -1 (highest compression/lowest quality) to 10 (lowest compression, highest quality). By default the encoding quality level is 3 (which gives an encoded rate of approx. 112kbps) but this can be changed using the -C option with a number from -1 to 10; fractional numbers (e.g. 3.6) are also allowed. Decoding is somewhat CPU intensive and encoding is very CPU intensive.

See .mp3 for a similar format.

SoX can only read Opus files, not write them.

	sox_ng infile -t oss
	sox_ng infile -t oss /dev/dsp
	sox_ng -b 16 -t oss /dev/dsp outfile

Note: SoX support for SHOUTcast PLS relies on wget(1) and is only partially supported: it's necessary to specify the audio type manually, e.g.

	play -t mp3 "http://a.server/pls?rn=265&file=filename.pls"

SoX can only autodetect this type of file from its filename extension; if it is read from `standard input' (stdin) or from a file whose name does not end in `.rso', you will need to prefix it with `-t ffmpeg'.

SoX can only autodetect this type of file from its filename extension; if it is read from `standard input' (stdin) or from a file whose name does not end in `.sbc', you will need to prefix it with `-t ffmpeg'.

The main one was by NeXT, essentially the same as Sun Microsystems' .au format. See .au

Apple made another .snd format in which the first two bytes are a 16-bit integer representing the numbers 1 or 2 but which can often be read as a raw format.

Akai had an audio file format for its MPC range of samplers of which the first byte contains the number 1 and the second the number 4. See .mpc2k

There are also Sounder and SoundTool files from MS-DOS/Windows in the early '90s. See .sndr and .sndt.

Lastly, the HOM-BOT Robot Vacuum Cleaner and the V.Flash Home Entertainment System use .snd audio files which are raw single-channel 16-bit 16kHz PCM and the Unity Game Engine uses a compressed format called .snd.

See the section `Special Filenames' in sox_ng(1) for examples of using the .sox format with pipes.

SoX can only autodetect this type of file from its filename extension; if it is read from `standard input' (stdin) or from a file whose name does not end in `.spdif', you will need to prefix it with `-t ffmpeg'.

	sox_ng infile -t sunau /dev/audio

	sox_ng infile -t sunau -e mu-law -c 1 /dev/audio

Note: some early Dialogic hardware does not always reset the ADPCM encoder at the start of each vox file. This can result in clipping and/or DC offset problems when it comes to decoding the audio. While little can be done about the clipping, a DC offset can be removed by passing the decoded audio through a high-pass filter, e.g.:

	sox_ng input.vox output.wav highpass 10

SoX can only autodetect this type of file from its filename extension; if it is read from `standard input' (stdin) or from a file whose name does not end in `.w64', you will need to prefix it with `-t w64'.

Normally .wav files have all formatting information in their headers, so format options do not usually need to be specified for input files. If any are, they override the file header and you will be warned to this effect. Output format options will cause a format conversion and the .wav is written appropriately.

SoX can read and write linear PCM, floating point, μ-law, A-law, MS ADPCM and IMA (or DVI) ADPCM-encoded samples. WAV files can also contain audio encoded in other ways not currently supported with SoX (e.g. MP3); in some cases such a file can still be read by SoX by overriding the file type, e.g.

   play -t mp3 mp3-encoded.wav

	sox_ng infile -t waveaudio
	sox_ng infile -t waveaudio default
	sox_ng infile -t waveaudio 1
	sox_ng infile -t waveaudio "High Definition Audio Device"

If the given device name is some other number, you get that audio device by its index, so recording with device name 0 would get the first input device (perhaps the microphone), 1 would get the second (perhaps line in), etc. Playback using device name 0 will get the first output device (usually the only audio device).

If the given device name is something other than a number, SoX tries to match it (to a maximum of 31 characters) against the names of the available devices.

The most common use of this file type is likely to be along the following lines:

	sox_ng infile.any -t wavpcm -e signed-integer outfile.wav