Re: [ecasound] lossless conversion broken?
Brought to you by:
kaiv
From: Sergei S. <ser...@ya...> - 2010-10-31 19:45:25
|
--- On Sun, 10/31/10, Dan Muresan <da...@gm...> wrote: > From: Dan Muresan <da...@gm...> > Subject: Re: [ecasound] lossless conversion broken? > To: "Sergei Steshenko" <ser...@ya...> > Cc: "Kai Vehmanen" <kve...@ec...>, eca...@li... > Date: Sunday, October 31, 2010, 10:46 AM > > For low amplitude signals you > have quite enough bits in a float, for > > example, for 5 bit amplitude signal you have all the > 23 (without sign) > > bits of float mantissa, so no precision loss occurs. > > It doesn't appear to be so, for whatever reason. Try this: > > # generate sine wave, -40 db, 100 Hz, 1 second > sox -t null /dev/null -b 16 sine.wav synth 1.0 sine 100.0 > gain -40 > > ecaconvert .wav sine.wav > cmp -l sine.wav sine.wav.wav > # or better, lfhex -c sine.wav sine.wav.wav > > Why are there bit flips for 0x0003 -> 0x0004 or 0x0000 > -> 0x0001? Even > if you go to -60db you will still see these errors. > > But to restate my original question -- does ecasound > convert to floats > when recording (with no processing), or does it not? I'm > not > interested in lossless conversion using ecasound, but I am > interestend > in recording. > > -- Dan > Here is a small test program: sergei@amdam2:~/junk/int_to_float> cat -n int_to_float_and_back.c 1 #include <stdio.h> 2 3 int main() 4 { 5 short i, o; 6 float f; 7 8 fprintf(stderr, "sizeof(i)=%u\n", sizeof(i)); 9 10 for(i = 1; i < 32; i++) 11 { 12 f = (float)i; 13 o = (short)f; 14 fprintf(stderr, "i=%u f=%g o=%u\n", (unsigned)i, (double)f, (unsigned)o); 15 } 16 17 return 0; 18 } sergei@amdam2:~/junk/int_to_float> ~/AFSWD/install/gcc-4.4.5/binsh/gcc -Wall -Wextra -O2 int_to_float_and_back.c -o int_to_float_and_back sergei@amdam2:~/junk/int_to_float> ./int_to_float_and_back sizeof(i)=2 i=1 f=1 o=1 i=2 f=2 o=2 i=3 f=3 o=3 i=4 f=4 o=4 i=5 f=5 o=5 i=6 f=6 o=6 i=7 f=7 o=7 i=8 f=8 o=8 i=9 f=9 o=9 i=10 f=10 o=10 i=11 f=11 o=11 i=12 f=12 o=12 i=13 f=13 o=13 i=14 f=14 o=14 i=15 f=15 o=15 i=16 f=16 o=16 i=17 f=17 o=17 i=18 f=18 o=18 i=19 f=19 o=19 i=20 f=20 o=20 i=21 f=21 o=21 i=22 f=22 o=22 i=23 f=23 o=23 i=24 f=24 o=24 i=25 f=25 o=25 i=26 f=26 o=26 i=27 f=27 o=27 i=28 f=28 o=28 i=29 f=29 o=29 i=30 f=30 o=30 i=31 f=31 o=31 sergei@amdam2:~/junk/int_to_float> -_ no_ loss of precision in case of short -> float -> short conversion. As it should be. I don't know which tool on the way has which bugs - for example, some zero padding might appear, i.e. you might be comparing different samples. But, as I stated, there are enough bits. Regards, Sergei. |