this is not about any wrong behaviour I would have noticed, but something that puzzled me when reading the code.
At https://github.com/go-audio/wav/blob/v1.1.0/decoder.go#L318 , since we're not returning nil, and we are returning m, and not explicitly 0, I assume that the call to Read above, could have partially succeeded until we hit the EOF, right?
If not, and if m is always 0 here, then you can forget about this issue (except I would explicitly return 0 to make it clear).
But if yes, then it means there possibly indeed is some data in tmpBuf at this point, right? And if yes, then I'm wondering why we are not copying the data from tmpBuf into buf.Data ? Shouldn't buf.Data always be populated as soon as m >= 0 is returned?
Hey,
this is not about any wrong behaviour I would have noticed, but something that puzzled me when reading the code.
At https://github.com/go-audio/wav/blob/v1.1.0/decoder.go#L318 , since we're not returning nil, and we are returning m, and not explicitly 0, I assume that the call to Read above, could have partially succeeded until we hit the EOF, right? If not, and if m is always 0 here, then you can forget about this issue (except I would explicitly return 0 to make it clear).
But if yes, then it means there possibly indeed is some data in tmpBuf at this point, right? And if yes, then I'm wondering why we are not copying the data from tmpBuf into buf.Data ? Shouldn't buf.Data always be populated as soon as m >= 0 is returned?