256x smaller values using "native" format

[christianhauschel]

Compared to scipy's read and MATLAB's audioread, the "native" format seems to have a 256 times smaller integer values. Why is that?

Wouldn't it make more sense to make the wavread behave the same?

[mgkuhn]

Can you please provide (as a file attachment to a message here) a very short example file that shows this problem, along with what values you expected to be in it, and the Julia REPL lines you used to reproduce that observation, such that we can very easily exactly reproduce on our own computers, without any guesswork, what you observed on your computer?

There are several different data types and encodings that can be stored in a WAV file, and without seeing your concrete example, it will be difficult to reproduce what you saw.

[mgkuhn]

Wild guess, without having seen any actual example: if writer and reader disagree about the endianness (i.e, use of LittleEndian versus BigEndian) of the encoding, then this could easily manifest itself as a roughly factor 256 difference in values: e.g. 0x0012 becomes 0x1200 and vice versa.

[christianhauschel]

Julia:

using WAV

fname = "test.wav"

y, fs, bits, in_chunks = wavread(fname, format="native")
y = y[:,1] * 256
maximum(y)

MATLAB:

fname = "test.wav";

[y, fs] = audioread(fname, "native");
max(y)

Python:

from scipy.io.wavfile import read, write
fname = "test.wav"
fs, y = read(fname)
max(y)

These snippets give the same max value. Note the 256 factor in the Julia code.

[christianhauschel]

test.zip

[dolphins4all]

@christianhauschel Did you get this sorted?

With your test file, when WAV.jl normalizes the file, then Matlab and Wav.jl agree. Maybe there is something in the file header that allows an endian issue to resolve that the "native" flag ignores? I'm guessing though....not an expert.