peek~ versus poke~ accuracy problem


    Mar 21 2007 | 2:37 pm
    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

    • Mar 21 2007 | 3:08 pm
      sorry title of post is wrong
    • Mar 21 2007 | 3:58 pm
      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
    • Mar 21 2007 | 4:45 pm
      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
    • Mar 21 2007 | 5:09 pm
      > 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.
    • Mar 21 2007 | 5:34 pm
      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?
    • Mar 21 2007 | 7:30 pm
      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
    • Mar 22 2007 | 10:59 am
      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
    • Mar 22 2007 | 11:30 am
      >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