redhexagonal

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

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

peek-versus-poke-accuracy-problem

> 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 

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.

> 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.

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

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

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 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?

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. 

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

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


>> 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

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. 

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... ;-)

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


>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. 

>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

>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... ;-)

peek~ versus poke~ accuracy problem