Added a seekstart() to WAV.read_header to start at the beginning of t…

[sprague252]

This is a fix for open issue #98 in which a call to wavread with a IOStream that is not at the beginning of the file causes an error. The fix is simple: add a seekstart() command at the beginning of read_header to go to the beginning of the file before reading the header. Since wavread calls read_header, this resets the stream to the beginning of the file when the user calls wavread.

[ATell-SoundTheory]

What if the user doesn't want to parse the WAV file from the beginning of the stream? Embedded files are not that uncommon. I think it's better to remind the user that the seek position needs to be the start of the header before calling the corresponing functions.

[sprague252]

What if the user doesn't want to parse the WAV file from the beginning of the stream? Embedded files are not that uncommon. I think it's better to remind the user that the seek position needs to be the start of the header before calling the corresponing functions.

That is one way to handle this. The problem is that the read_header function errors unless the stream is at the the beginning of the file. Otherwise, it does not read the b"RIFF" at the beginning. If you want to maintain the file position, read_header could read and save the current position, do its thing, and then restore the position. It would be problematic if the file position is not at the start of a sample or something, but you could just let the user assume responsibility for that.

[sprague252]

Also, I am pretty sure the subrange parameter in wavread relies on being at the beginning of the file. (I have not tested this.)

[sprague252]

Embedded files are not that uncommon.

I see your point here. I have never encountered an embedded WAVE file, but I suppose it is possible. In this case, you would want the stream to point to the beginning of the embedded file when wavread is called. wavread then calls read_header, and read_header finds the b"RIFF" at the beginning of the embedded file. My change is not going to give this behavior. I would have no problem if you rejected my push to maintain this behavior as long as there is clear documentation of how to use it.

[ssfrr]

Yeah, from an API standpoint I think it’s reasonable that it’s the responsibility of the caller to have the stream at the beginning of the file being read.

also not all streams are seekable (e.g. streaming over a network socket)