The golang-users thread you announced this in suggests you used to have a float32 interface, but replaced it by float64, right? I'm asking because Im currently writing float32tofloat64 and float64tofloat32 array conversion routines and Im wondering why. The wav package produces float32s, but the other packages consume float64, which feels a little weird for two packages from the same repos.

I'm trying to tie it into some opus unit tests and libopus also works with float32, as I assume many others do.

Im curious to know: what made you drop float32?

I'm sure this is my fault, but I can't see what I'm doing wrong.

Given the following simple program, when the input is a 440Hz sine wave, I expect to see a single peak in the frequency domain. Giving the same input to an online FFT calculator, the expected output is obtained.

Can you point out my mistake, or is go-dsp doing something strange?

The Program

package main

import (
    "bufio"
    "fmt"
    "github.com/mjibson/go-dsp/fft"
    "github.com/mjibson/go-dsp/window"
    "math"
    "os"
    "strconv"
)

func main() {
    file, err := os.Open(os.Args[1])
    if err != nil {
        panic(err)
    }

    scanner := bufio.NewScanner(file)
    values := make([]float64, 0)
    for scanner.Scan() {
        line := scanner.Text()
        value, e := strconv.ParseFloat(line, 64)
        if e != nil {
            panic(e)
        }
        values = append(values, value)
    }

    fftComplex := doFft(values)
    fftReal := realize(fftComplex)

    for _, freq := range fftReal {
        fmt.Println(freq)
    }
}

func doFft(data []float64) []complex128 {
    window.Apply(data, window.Hamming)
    return fft.FFTReal(data)
}

func realize(data []complex128) []float64 {
    realVals := make([]float64, len(data))
    for i, comp := range data {
        rel := math.Pow(real(comp), 2)
        img := math.Pow(imag(comp), 2)
        realVals[i] = math.Sqrt(rel + img)
    }
    return realVals
}

It's run like:

go run fft.go awave.dat > awave-dsp.fft

The Input

Data is here, it's 440Hz sine. Plotted it looks like:

gnuplot -e "plot 'awave.dat'; pause -1"

The Output

Data is here. Plotted it looks like:

The x-scale here isn't Hz, it's just the bin numbers from FFTReal.

gnuplot -e "plot 'awave-dsp.fft'; pause -1"

Expected Output

Using the same input, and the online FFT mentioned above, I get the expected output:

Changes in this commit:

1. Changed Wav.Data8, Wav.Data16, and Wav.Data to be indexed by sample and then by channel.
2. Added API to stream a wav from an io.Reader rather than loading all data into memory.
3. Added unit tests for 'wav' package.

Change #1 is a breaking change to the current API.

Use stdlib functions for converting little-endian bytes to single values Fix indexing of sample/channel in readSample. Use int for sample index to avoid overflow for wav files with greater than UINT16_MAX samples

Hoping its possible to have more examples of common usage of the library. For example, it would be interesting to have a sample program that reads a wav file and segments the file into meaningful features perhaps providing a recognition example?

HI. I am new in golang.

I want open file and do HPF and save the file after HPF.

the file format is 1 28.00000 2 29.00000 3 28.00000 4 30.00000 5 28.00000 ..... .....

it has two column (time well_height)

the sample rate is 0.0166Hz (60 seconds interval well height recording) It has very very long term noise more than 200 sec So I want to High pass filter with cutoff frequency 0.005 Hz

I looked over your golang code very carefully with 1 week but Still I failed with your code.

Is there any sample form with open file and do HPF and save to file with HPF results ?

please help me. I am graduate course student.

Thanks for all.

TaeRhee sample_part_small.txt

Swap indexes of data exposed by wav package. Data is now indexed by sample then channel, e.g. [sample0[ch0, ch1], sample1[ch0, ch1], ...]

Two reasons for this:

1. Sample is more natural to index on. Data capsulation makes more sense when data for a discrete instance is contained in a discrete structure.

2. Client code is cleaner. Clients get an array of all data per sample rather than iterating through channels and pulling out the sample data.

Invoking fft.FFT() many times for large wav files (~10MB) couses program to panic because of out of memory. I have tested my program with and without that single line. Without computing fft it occupies ~300MB for very long time. When I enable fft computing it will be 3GB of RAM occupied pretty fast.

I would love an example of using the Fourier transform utilities on one of the sample wav files. In fact, there are several algorithms here that could use a usage demonstration.