Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WriteFrame() could accept a slice #18

Open
ivoras opened this issue Apr 28, 2019 · 0 comments
Open

WriteFrame() could accept a slice #18

ivoras opened this issue Apr 28, 2019 · 0 comments

Comments

@ivoras
Copy link

ivoras commented Apr 28, 2019

I keep my PCM audio samples as []int16, and while learning to use this library, it seemed natural to use it like this:

data := []int16{...}
enc := wav.NewEncoder(f, 44100, 16, 1, 1)
if err := enc.WriteFrame(data); err != nil {
  panic(err)
}
enc.Close()

The reason why this seemed like a good idea is that WriteFrame() calls AddLE() and this ultimately calls binary.Write() which in addition to integers accepts slices of integers. The resulting file has the correct size.

BUT... WriteFrame() (at line https://github.com/go-audio/wav/blob/master/encoder.go#L217) only increments the frame count by one, which makes the WAV headers only recognize a single sample. If this were handled so that WriteFrame() checks for a slice argument, and/or a separate function WriteFrames() is added to write the whole slice at once, it would simplify the library's usage.

Edit:

The alternative approach:

for _, sample := range data {
  enc.WriteFrame(sample)
}

...is horribly slow. It takes several seconds to write a 2 MB buffer! This is because binary.Write() issues a write syscall for every single call, i.e. for every single sample!

Created a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant