peek~ versus poke~ accuracy problem

Mar 21, 2007 at 2:37pm

peek~ versus poke~ accuracy problem

hi
I’m having trouble understanding how values are written into various file types. writing a value such as 0.5 or 1 into a buffer~
seems to get written to disk as a value slightly less than those numbers, unless a choose a filetype float32 or float64. i want to use standard int16 filetype, to write values that will be stable when i write and read the file! at the moment every time i write and read a value to disk it seems to change, i don’t understand why, especially with a number like .5 or 1 which i would have thought could be accurately represented by a 16bit write, or 8bit write. does this mean my audio files are degrading every time i resave them? confused

james

heres an example

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 219 62 23 196617 0 1;
#P user ezdac~ 56 176 100 209 0;
#P message 187 62 26 196617 0 0.5;
#P window setfont “Sans Serif” 12.;
#P user number~ 188 167 285 186 12 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P newex 190 142 48 196617 index~ z;
#P newex 190 120 38 196617 sig~ 0;
#P message 117 75 48 196617 read zed;
#P message 116 56 53 196617 write zed;
#P user umenu 45 95 53 196647 1 64 111 0;
#X add int8;
#X add int16;
#X add int24;
#X add int32;
#X add float32;
#X add float64;
#X add mulaw;
#X add alaw;
#P newex 45 116 89 196617 prepend samptype;
#P newex 45 136 67 196617 buffer~ z 10;
#P newex 190 90 44 196617 peek~ z;
#P connect 11 0 0 0;
#P connect 9 0 0 0;
#P connect 7 0 8 0;
#P connect 5 0 1 0;
#P connect 4 0 1 0;
#P connect 2 0 1 0;
#P connect 6 0 7 0;
#P fasten 3 1 2 0 93 113 50 113;
#P window clipboard copycount 12;

#30953
Mar 21, 2007 at 3:08pm

sorry title of post is wrong

#99653
Mar 21, 2007 at 3:58pm

On 21 mars 07, at 14:37, bin ray wrote:

> I’m having trouble understanding how values are written into
> various file types. writing a value such as 0.5 or 1 into a buffer~
> seems to get written to disk as a value slightly less than those
> numbers, unless a choose a filetype float32 or float64. i want to
> use standard int16 filetype, to write values that will be stable
> when i write and read the file! at the moment every time i write
> and read a value to disk it seems to change, i don’t understand
> why, especially with a number like .5 or 1 which i would have
> thought could be accurately represented by a 16bit write, or 8bit
> write. does this mean my audio files are degrading every time i
> resave them? confused

I’m not sure I’m understand. Max is working with 32 bits floating
points number for the signal part. If you play an int16 file it’ll
automatically be “converted” as 32bits fp. When you save a file you
just convert a 32 bits fp into something else.

Cheers,
ej

#99654
Mar 21, 2007 at 4:45pm

firstly. i don’t really understand the difference between an int32 file and a float32 file. they both seem to be the same size, i’m assuming each sample is a value containing 32 bits of binary data, so what is the difference?

how would the number 0.5 be represented in 32 bit float? and how is it represented in a 16 bit int file?

if i save the value 0.5 into a 16bit int file, then read that file, max tells me the value is 0.499969. if i then write that file again as 16bit int, and read it again, max now tells me its 0.499939, every time i save it the value seems to change.

sorry i can’t find anything in the documentation that explains this

james

#99655
Mar 21, 2007 at 5:09pm

> sorry i can’t find anything in the documentation that explains this

That’s because the standards for representing in32 and float32 have nothing to do with Cycling ’74. That’s a standard data representation problem. I’d try something like IEEE for explanations of that sort of tweakiness.

#99656
Mar 21, 2007 at 5:34pm

i’m not clear why you think this isn’t a problem relevant to maxmsp.

i’m trying to write a value into a 16 bit int file from what is apparently a 32 bit float buffer~. all i want is that its the same value when i read the file again.
i’m expecting the value to be quantized to 16bit when its written to the file, but i don’t understand why it keeps decreasing every time i write and read the file.

in the following patch try entering a value into the buffer~ z and then writing and then reading the file (as 16 bit int)alternately. every time you read the file the value decreases a little.

i dont understand why. doesnt this mean all my 16bit int audio and data files are degrading as i rewrite them?

#P window setfont “Sans Serif” 9.;
#P window linecount 4;
#P comment 193 251 100 196617 value read from file into buffer loses about 2ms for each write /read;
#P window linecount 2;
#P comment 39 179 100 196617 write then read alternately;
#P window linecount 1;
#P newex 198 65 52 196617 / 65536.;
#P flonum 198 34 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user ezdac~ 200 322 244 355 0;
#P message 198 91 31 196617 0 $1;
#P newex 198 119 44 196617 peek~ z;
#P user number~ 194 225 369 240 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 194 203 59 196617 *~ 65536.;
#P newex 195 180 48 196617 index~ z;
#P newex 195 158 38 196617 sig~ 0;
#P message 99 153 48 196617 read zed;
#P message 39 152 53 196617 write zed;
#P user umenu 42 51 53 196647 1 64 67 0;
#X add int8;
#X add int16;
#X add int24;
#X add int32;
#X add float32;
#X add float64;
#X add mulaw;
#X add alaw;
#P newex 42 72 89 196617 prepend samptype;
#P newex 42 92 85 196617 buffer~ z 10000;
#P comment 242 34 100 196617 enter a value;
#P connect 7 0 8 0;
#P connect 8 0 9 0;
#P connect 14 0 11 0;
#P connect 13 0 14 0;
#P fasten 3 1 2 0 90 69 47 69;
#P connect 5 0 1 0;
#P connect 4 0 1 0;
#P connect 2 0 1 0;
#P connect 6 0 7 0;
#P connect 11 0 10 0;
#P window clipboard copycount 17;

#99657
Mar 21, 2007 at 7:30pm

ok i did some tests, and yes i am gradually eroding all my sound files as they get converted to and fro from 32 bit float to 16int and back, during read/write. so now i will have to use 32 bit float as file type i guess, since all my metadata is in sound files, and i don’t want my audio to get degraded. if theres any other solution i’d be interested to know. i still don’t understand *why* this happens

#99658
Mar 22, 2007 at 10:59am

Gregory Taylor schrieb:
>> sorry i can’t find anything in the documentation that explains this
>>
>
> That’s because the standards for representing in32 and float32 have
> nothing to do with Cycling ’74. That’s a standard data representation
> problem. I’d try something like IEEE for explanations of that sort of
> tweakiness.

The problem is the way how it is converted: you map 16-bit integer, a
range going from -32768 to + 32767 (non symetric)to -1.0 to +1.0.
(symetric)… Just to get an idea.
If you want to store to disk and later load it in again, just save as
32-bit float, you have to set the fileformat before saving… (I guess
for that purpose the additional space needed doesn’t hurt too much… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#99659
Mar 22, 2007 at 11:30am

>The problem is the way how it is converted: you map 16-bit >integer, a
>range going from -32768 to + 32767 (non symetric)to -1.0 to >+1.0.
>(symetric)… Just to get an idea.
>If you want to store to disk and later load it in again, just >save as
>32-bit float, you have to set the fileformat before saving… (I guess
>for that purpose the additional space needed doesn’t hurt too >much… ;-)

i thought it was something like that. i’d assumed there would be values common to both file formats i could use that would be stable, but apparently not. strange to think of my old files being worn away smooth as pebbles over the years of not knowing this

thanks
james

#99660

You must be logged in to reply to this topic.