Crash when evaluating a particular recording
paulrosen opened this issue · 14 comments
I have incorporated "@spotify/basic-pitch": "1.0.1"
into my website.
I'm getting good results from most of my test files, but this one particular file crashes: https://production--endearing-hamster-0de147.netlify.app/audio/paul_001.mp3
(Note that this URL is good for a while but will eventually go away.)
In the console I see:
webgl_util.ts:116 Couldn't parse line number in error: ERROR: 0:140: 'getT1' : no matching overloaded function found
#version 300 es
precision highp float;
precision highp int;
precision highp sampler2D;
in vec2 resultUV;
out vec4 outputColor;
const vec2 halfCR = vec2(0.5, 0.5);
etc...
Then it throws the following error:
Error: Failed to compile fragment shader.
at createFragmentShader (webgl_util.ts:106:11)
at compileProgram (gpgpu_math.ts:113:26)
at backend_webgl.ts:942:25
at _MathBackendWebGL.getAndSaveBinary (backend_webgl.ts:997:31)
at _MathBackendWebGL.runWebGLProgram (backend_webgl.ts:941:25)
at concatImpl2 (Concat_impl.ts:123:26)
at concatImpl2 (Concat_impl.ts:103:26)
at Object.concat3 [as kernelFunc] (Concat.ts:49:10)
at kernelFunc (engine.ts:644:22)
at engine.ts:710:23
Thanks for this amazing library!
It does the same thing when I drop that file onto https://basicpitch.spotify.com/
Hi @paulrosen , can you provide the audio that you're using? In the future, please use basic-pitch-ts for issues related to the typescript library.
The audio is here: https://production--endearing-hamster-0de147.netlify.app/audio/paul_001.mp3
(With some experimenting, I found that if I shorten the mp3 just slightly it works fine.)
Thanks! Should I close the issue?
Well, it would be nice if the original audio worked. I will be submitting random audio so it will fail periodically. What my workaround looks like is:
- catch the error
- shorten the audio by 0.3 seconds
- retry
- repeat until it works
The drawback of that is:
- there is a huge amount of info dumped to the console, which I'd rather not have,
- redoing the audio will take a little time, so the user will have to wait,
- there is probably a little bit of extra space at the end of the file, but chopping it off might get rid of part of the last note.
Also, I've tried about 30 recordings so far and 3 of them failed like this, so this isn't a particularly rare case.
If you change the encoding or resample the file does it still fail? Also has it always been files of this length?
I just tried resampling the file to 22050Hz and 44100Hz and converting the file to ogg. I'll take a deeper look.
Note, you could alternatively add 0's to the audio instead of removing the audio. That works at the minimum, but doesn't admittedly solve the root cause.
All the files tend to be different lengths. I didn't see any pattern having to do with file length.
Adding zeros is a better idea for a workaround, thanks!
Here's another example: https://production--endearing-hamster-0de147.netlify.app/audio/mBpJ9URFpMuTXg1HuOaG.mp3
Is there any progress on this? Is there anything I can do to help? I don't know anything about tensorflow so I'm not sure if I could get up to speed.
No progress. I've been a bit busy on #100 and admittedly forgot about this issue. Hopefully, I can get to this issue in a week or two. I do wonder if tfjs has been updated with a fix since you posted this issue. I can check sometime next week.
This sort of issue tends to be an edge case for whenever an audio file is chunked up and processed that way. Most likely, some chunk (probably a trailing chunk) is too small for some part of the code. This is why it doesn't have to do with any specific file length, but instead has to do with multiples of some chunk length with a tail chunk that's too small.
If I catch it I'll see what I can do as well.