Interleaving bug

[cournape]

From Dr. Gabriël J.L. Beckers

"""
If you read a stereo file with "f.read_frames(f.nframes)", then the samples of each channel are in the correct columns, but if you add a dtype argument while reading exactly the same data "f.read_frames(f.nframes, dtype=np.float32)", then samples from both channels end up in both columns, so that each column now has interleaved data.
"""

script + wav in my gmail inbox

[wslihgt]

Hi David,

I just noticed I had this problem as well: passing the dtype argument to read_frames ends up messing the samples, and interleaving them the wrong way around. Not sure where that comes from. Have you found out where the problem was? I must admit I use a fairly old version (0.11.0), and I noticed my issue with dtype=np.int16. Maybe you fixed it already in the mean time... In which case you could maybe drop a few lines here?

Cheers!

[mgeier]

I also experienced this bug in version 0.11.0.
I've illustrated it with an IPython notebook: http://nbviewer.ipython.org/5990729/audiolab_bug.ipynb

[mgeier]

I had a look at the code and I think I know where the error is located.

In the file audiolab/pysndfile/_sndfile.pyx, the function read_frames() is defined which forwards to read_frames_double(), read_frames_float(), read_frames_int() and read_frames_short().

The main difference between read_frames_double() (which is used by default) and the others is that it uses C ordering for the memory of the array while the others use Fortran ordering.

There is also a comment about Fortran ordering, but I think this is obsolete:

# Use Fortran order to cope with interleaving
ty = np.empty((nframes, self._sfinfo.channels),
              dtype=np.float32, order='F')

I tried changing 'F' to 'C' in the 3 functions and my soundfiles were read correctly.