[..continue] so if recording_bufsize is the length of the data passed in, then recording_bufsize // 2 + 1 is the output of ftt.rfft . it removes one side of the data. then we have rfft_bufsize = recording_bufsize // 2 so at rfft index 0, this represents a period of infinity at rfft index 1, this represents a period of recording_bufsize at rfft index 2, i suspect this would be a period of recording_bufsize / 2 and at the last rfft index, i.e. recording_bufsize // 2 + 1 - 1, this would be a period of 2 so there's a quotient relationship between recording_bufsize, and the expression recording_bufsize // 2, that yields 2 . one is the numerator, and one is the denominator recording_bufsize / (recording_bufsize / 2) = 2 that works for the others too recording_bufsize / 0 = infinity recording_bufsize / 1 = recording_bufsize recording_bufsize / 2 = recording_bufisze / 2 so I think you divide the original buffer size, by the rfft index, and this simple relation gets the exact period, still not sure. and the reason half is missing in that calculation ... is not stable in me but not super important here ... i think it's because the lowest frequency is the nyquist, which is 2. so, i guess i'll checking: recording_bufsize / rfft_index = equivalent period in indices