Dtype mismatch Error in Effects Module (Remix Function)

35 views
Skip to first unread message

Chapel Heel

unread,
Jan 24, 2025, 10:29:46 AMJan 24
to librosa
I am not a Python expert so if I say something stupid here, do not be surprised.  :)

I'm using the lines from the remix example in the documentation, and the first y_out line throws a mismatch dtype error, expecting float32, not int32.

y_out = librosa.effects.remix(y, intervals[::-1])

The y variable is float32, so that does not seem to be the issue.  The intervals variable is int32, but I tried first converting it (with astype()) to float32 and that does not solve the error.

In the remix function in effects.py, lines 389-393 create a zeros variable (the condition is met because align_zeros is set to True by default in the remix function).  

if align_zeros:
    y_mono = core.to_mono(y)
    zeros = np.nonzero(core.zero_crossings(y_mono))[-1]
    # Force end-of-signal onto zeros
    zeros = np.append(zeros, [len(y_mono)])

The resulting zeros variable is int32, which is where the problem seems to lie.

Then in lines 397-406 of effects.py, the util.match_events function is called, using the y and the zeros variables.  

for interval in intervals:
    if align_zeros:
        interval = zeros[util.match_events(interval, zeros)]

    clip[-1] = slice(interval[0], interval[1])

y_out.append(y[tuple(clip)])

y_out = np.asfortranarray(np.concatenate(y_out, axis=-1))

It gets deep into other modules at this point.  Matching.py contains the match_events function, which needs an events_from parameter, which is y, and an events_to parameter, which is zeros.  This seems to be where the error is thrown, because it must be expecting both the from and to parameters to be float32, and the to parameter (zeros) is int32.  Maybe some of the other modules are supposed to convert it to the correct dtype and that is not happening correctly?

To see if this looks like the inflection point, I set align_zeros=false in my y_out line and ran the script.  I did not get the error, so it has something to do with the zeros variable being set to int32.  

Of course, the remix function works a lot better with the zero crossing parameter set to True, so I am hoping there is a way to keep the align_zeros=True (or default) and not get the error.

(Note my np and librosa libraries are up to date via pip install).

Thanks for any help you can provide!      

Brian McFee

unread,
Jan 24, 2025, 10:39:14 AMJan 24
to librosa
This would be much easier to diagnose if you could provide the data (y, intervals) that triggers the error. The error log would also be helpful to identify where exactly the dtype mismatch is coming from.

For the record, I did just run the example code from the remix docstring and was unable to produce an error.

Chapel Heel

unread,
Jan 24, 2025, 11:32:11 AMJan 24
to librosa
Here is the very short script (omitting the imports), beginning on line 13.  The filename variable is a path to the .wav file.

def remix(newname,y,sr):
    _, beat_frames = librosa.beat.beat_track(y=y, sr=sr,hop_length=512)
    beat_samples = librosa.frames_to_samples(beat_frames)
    intervals = librosa.util.frame(beat_samples,frame_length=3,hop_length=2,axis=-1).T

    y_out = librosa.effects.remix(y, intervals[::-1])
    y_out = librosa.effects.pitch_shift(y_out,sr,n_steps=2,bins_per_octave=12)
    soundfile.write(newname,y_out,sr)

filename = r'[.wav file path goes here]'
newname = f'{filename[:-4]} (python librosa remix).wav'

y, sr = librosa.load(filename)

remix(newname,y,sr)

librosa.cache.clear()

***
And here is the error thrown with line 26 being the remix call, and line 17 being the first y_out in the function.  Do you need the actual music file that generated this error?  This happens regardless of which file or path I choose.  The only way it doesn't happen is if I set align_zeros=False

Traceback (most recent call last):
  File "F:/Users/ChapelHeel66/My Python Scripts/Project Scripts/Music Stuff/remix_librosa_test.py", line 26, in <module>
    remix(newname,y,sr)
  File "F:/Users/ChapelHeel66/My Python Scripts/Project Scripts/Music Stuff/remix_librosa_test.py", line 17, in remix

    y_out = librosa.effects.remix(y, intervals[::-1])
  File "C:\Users\ChapelHeel66\AppData\Local\Programs\Python\Python37-32\lib\site-packages\librosa\effects.py", line 400, in remix

    interval = zeros[util.match_events(interval, zeros)]
  File "C:\Users\ChapelHeel66\AppData\Local\Programs\Python\Python37-32\lib\site-packages\librosa\util\matching.py", line 303, in match_events
    return __match_events_helper(output, events_from, events_to, left, right)
TypeError: expected dtype object, got 'numpy.dtype[int32]'


Thank you for responding!

Brian McFee

unread,
Jan 24, 2025, 11:35:26 AMJan 24
to librosa
What versions of numpy and numba are you running on?

The issue here is that the match_events_helper function is a numba jit-compiled function, which uses type matching to handle dispatching.  For some reason, it's having trouble reconciling np.dtype[int32] with np.dtype, and that to me smells like a compatibility issue between your numba and numpy installs.

Chapel Heel

unread,
Jan 24, 2025, 1:14:37 PMJan 24
to librosa
Yes, you are right.

it's interesting because I was running the script in Python 3.7, and I had used pip install specifically with py -3.7 -m pip install --upgrade and got a response that I had installed 2.1.3 numpy, and did the same to get 0.61 numba.  So I had the latest.

However, when I queried the version from within Idle after running the remix script (using __version__) I got 1.21.6 and 0.49 versions instead.  Apparently even with py -3.7 in my command line, pip install was only updating the packages for the latest Python version on my system (3.12), and not 3.7 as I designated.  I went at it a different way, and now Python 3.7 shows numba at 0.56.4 (with numpy still at 1.21.6).  

And the script now works!

Thank you so much for your help!  I really appreciate it. 

Reply all
Reply to author
Forward
0 new messages