Random error in runtime

[paritosh-gupta]

I was doing processing of a large number of 10 second audio clips. One of them gave the error

 File "/deploy/app/application.py", line 49, in f0
    pitch = pyaapt.yaapt(signal, **params)
  File "/usr/local/lib/python2.7/dist-packages/amfm_decompy/pYAAPT.py", line 362, in yaapt
    parameters)
  File "/usr/local/lib/python2.7/dist-packages/amfm_decompy/pYAAPT.py", line 586, in time_track
    phi = crs_corr(signal_frames[frame, :], lag_min0, lag_max0)
  File "/usr/local/lib/python2.7/dist-packages/amfm_decompy/pYAAPT.py", line 930, in crs_corr
    x_jr_matrix = stride_matrix(x_jr, lag_max-lag_min, N, 1)
  File "/usr/local/lib/python2.7/dist-packages/amfm_decompy/pYAAPT.py", line 1008, in stride_matrix
    strides=(vector.strides[0]*hop, vector.strides[0]))
  File "/usr/local/lib/python2.7/dist-packages/numpy/lib/stride_tricks.py", line 102, in as_strided
    array = np.asarray(DummyArray(interface, base=x))
  File "/usr/local/lib/python2.7/dist-packages/numpy/core/numeric.py", line 531, in asarray
    return array(a, dtype, copy=False, order=order)
ValueError: negative dimensions are not allowed

This is how I compute

def f0(data,rate):
    params = {'f0_min' : 100.0,'fft_length': 1024 ,'frame_length' : 35.0, 'frame_space' : 30.0}
    floatarr = []
    try:
        floatarr = basic.pcm2float(data)
    except:
        floatarr = data
    floatarr[floatarr < -1.00] = -1.00
    floatarr[floatarr > 1.00] = 1.00
    signal = basic.SignalObj(floatarr,rate)
    pitch = pyaapt.yaapt(signal, **params)
    return pitch,signal

Some kind of arithmetic overflow?

Btw I love your package. It's helped me build oraiapp.com (My apologies about the previous issue I lost track of it. I will try searching for the file for that as well as for this issue. Just updated my logging to log filename too.)

[bjbschmitt]

Hi Paritosh Gupta,

thanks again for your feedback. It's good to know that the package has been employed in real world applications, it means a lot to me.

According to your error messages, the issue is probably being caused by the stride_matrix function (pYAAPT.py line 1005) receiving a negative value for the "hop" variable. Tracing back its call at line 930 inside crs_correlation function, it seems that for some particularly reason, (lag_max-lag_min)<0, which is wrong.

So I will really need that you to send me the problematic audio clip in order to find out why these lag_min and lag_max values are not being correctly calculated. This bug seems to be a bit more difficult to solve than the last one.

[paritosh-gupta]

Hi bjbschmitt, I will try to get this within the next week. If not I might not be able to get it since I was not which audio file part caused this. Thanks, Paritosh

[bjbschmitt]

Ok Paritosh, I'll be waiting then for the audio file.

[paritosh-gupta]

Hey I ran the process on a new dataset. However the error did not occur. I will keep watch for it happening again. You can close this if you like. I will report back with a file if it occurs again.

[bjbschmitt]

Ok, no problem. I will keep this report open, because eventually someone else may face the same issue.

[puffkan]

Hi bjbschmitt,

I recently got the same issue and I also found that, in my case, it occurred because the data length in a particular frame was shorter than lag_max so N = data_len-lag_max became negative and raised an error.

Puff

[bjbschmitt]

Hi Puff, thanks for your feedback!

Could you please send me your problematic wav file? I also need your running parameters, to check if you are using any parameter different from the default values (for example, Paritosh used params = {'f0_min' : 100.0,'fft_length': 1024 ,'frame_length' : 35.0, 'frame_space' : 30.0} in his tests).

I suspect that the bug should be at line 583 from pYAAPT.py, where lag_max is calculated. It could be something related with the signal itself, but it could also be something related with the parameters that you've used.

[tuanad121]

Hi I have the same problem with pYAAPT.py. At x_jr_matrix = stride_matrix(x_jr, lag_max-lag_min, N, 1) in crs_cross(), N becomes negative. I'm not sure how to fix it. I ran my script on Python 3.6. I realized function like interrupt_main() doesn't work. I attached my script and data file below. Thanks for spending your time on my case. I appreciate it. problem.zip

[bjbschmitt]

Hi tuanad121, thank you very much for your feedback and your data, it was very useful. I was able to recreate the issue here, so I'll be working on a solution. I hope to fix the problem as soon as possible. I'll take a look on interrupt_main() too and try to find a better replacement for it.

[tuanad121]

@bjbschmitt thanks for your reply. Maybe we can use assert instead of interrupt_main()

[bjbschmitt]

@tuanad121 indeed, assert seems to be a nice replacement, I'll probably commit it. Well done!

[bjbschmitt]

Ok, the issue is fixed, but it will take one more day for me to publish the new version. I still have to follow some standard procedures like updating the files and documentation, testing the package in both Python 2 and 3, testing the installation in both Windows and Linux, etc.

Meanwhile, here's the new modified version from the pYAAPT.py file that tuanad121 sent. His script is now running fine in my laptop, please check if the issue was solved in your PCs as well. pYAAPT.py.zip

The problem was in the algorithm itself. The current time_track function from pYAAPT uses the frame_length parameter in its calculations. So, altering its default value may eventually cause the N value at line 922 in crs_corr to become negative (although I was not able to find out exactly which combination of frame_lenght+frame_jump+fs+fmax+fmin causes the issue).

In order to solve this problem, the guys from the original MATLAB code added a new parameter called frame_lengtht (pay attention to the extra "t" at the end) to the most recent YAAPT 4.0 version. This new frame_lengtht is used solely in the time_track function and helps to avoid this problem. So I made the proper alterations and now everything is running fine in pYAAPT.

[tuanad121]

It works. Thank you so much. I appreciate it. It's out of scope. After QHM decomposition, can we re-synthesized speech? I hope I can use AMFM_decompy in analysis/synthesis of speech.

[bjbschmitt]

Ok cool.

Yes, you can re-synthesize the speech from the modulated components. Take a look at the ModulatedSign.synthesize() method here.

[bjbschmitt]

Ok, I have already uploaded the new AMFM_decompy 1.0.7 version to both PyPi and github and updated its documentation. Please upgrade the package in your PCs through pip.

Technically speaking, we cannot say that the problem is REALLY solved, since we just implemented a workaround. For example, if you run tuanad121 script using the following parameters

pitch = pYAAPT.yaapt(signal, **{'f0_min': minp, 'f0_max': maxp, 'frame_space': 5.0, 'frame_length': 10.0, 'tda_frame_length': 10.0})

the bug will pop up again. Therefore, I still want to re-read the YAAPT paper in another occasion and run a more intensive set of tests. Eventually we could identify which are the necessary conditions for the problem to happen and try to design a better solution. Like, for example, add a routine that would automatically re-adjust some parameters values if it detects that the algorithm will crash.

Nevertheless, I believe that the current solution is satisfactory, since it allows everybody to keep working with the package. So I'll consider this issue solved and will close it by now.