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;

> 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

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

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.

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;

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

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