Subject: Re: [ecasound] ecasound 2.0.4 released!
From: Tobiah (toby_AT_tobiah.org)
Date: Fri Jan 25 2002 - 06:42:26 EET
> One possibility is that n-track uses different layout for 24bit
> samples. Ecasound (and ALSA and most soundcards) handle 24bit samples
> as 32bit samples with one zero-padded byte.
That would be it then. With n-track I am able to make samples that
really only use 3 bytes/sample. It can also pad on the right or
left with a byte, but I like the savings in disk space.
Check this out:
//Wave fmt chunck layout
#define FormatID 'fmt '
typedef struct {
ID chunkID;
long chunkSize;
short wFormatTag;
unsigned short wChannels;
unsigned long dwSamplesPerSec;
unsigned long dwAvgBytesPerSec;
unsigned short wBlockAlign;
unsigned short wBitsPerSample;
/* Note: there may be additional fields here, depending upon wFormatTag. */
} FormatChunk;
sine:toby:toby> od -b n-track_24_bit_file.wav
0000000 122 111 106 106 046 374 360 003 127 101 126 105 146 155 164 040
0000020 022 000 000 000 001 000 002 000 000 167 001 000 000 312 010 000
0000040 006 000 030 000 000 000 144 141 164 141 000 374
0000054
sine:toby:toby> od -b ecasound_24_bit_file.wav
0000000 122 111 106 106 040 040 050 000 127 101 126 105 146 155 164 040
0000020 020 000 000 000 001 000 002 000 000 167 001 000 000 270 013 000
0000040 010 000 030 000 144 141 164 141 000 040 050 000
0000054
The 'fmt ' chunk begins on the 13th byte, or #014 by the 'od' counter above.
In the n-track file, bytes 040 and 041 (octal count) make up the short
value wBlockAlign. The wBlockAlign seems to be the integer number of
bytes that it would take to hold an entire sample frame. N-track has
it at 6, which is correct: 2channels of three bytes or 24 bits each.
Ecasound shows 8, which is also correct in that it pads the 24bit sample
with and extra byte, and so 2 channels * 4bytes/sample = 8/frame.
From my version of the spec:
Because most CPU's read and write operations deal with 8-bit bytes, it
was decided that a sample point should be rounded up to a size which
is a multiple of 8 when stored in a WAVE. This makes the WAVE easier to
read into memory. If your ADC produces a sample point from 1 to 8 bits
wide, a sample point should be stored in a WAVE as an 8-bit byte (ie,
unsigned char). If your ADC produces a sample point from 9 to 16 bits
wide, a sample point should be stored in a WAVE as a 16-bit word (ie,
signed short). If your ADC produces a sample point from 17 to 24 bits
wide, a sample point should be stored in a WAVE as three bytes. If your
ADC produces a sample point from 25 to 32 bits wide, a sample point
should be stored in a WAVE as a 32-bit doubleword (ie, signed long). Etc.
Because of the wBlockAlign field in the header,
I don't object to padding 24bit samples to longs, but it is not
clear from the above paragraph that this would be correct, and at least
it suggests that a well behaved interpreter of wav files should catch the
wBlockAlign size and be able to play true 3byte samples.
P.S. Notice that ecasound uses the correct 'fmt' chunck size of 16 (byte 20octal)
while n-track accurately reports that it's chunk size is 18, even though the
spec says that extra parameters should only be used in files with compression.
I'll have to nag the n-track author about that.
Thanks,
Tobiah
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Fri Jan 25 2002 - 06:32:55 EET