I've pushed a fix, which will be in 2.0.3. If you happen to be in a position to test this from the repo in the mean time, it would be great to verify that it solves the problem for you. And thanks again for the clear report.
Thanks for reporting this! I think the problem is that it tries to seek back to the start, but flac is not seekable (via libsndfile at least). We should instead close and reopen the file. I'll look into it.
I have downloaded your test file, just in case I need it.
Versions prior to 2.0 always ignored clipping, so
--ignore-clippingseems like a reasonable workaround since it just puts you back where you would have been with 1.9.x anyway!
Fixed in commit:6085f4a60296 and release 1.3.
A remote access failure during update (authentication failure, certificate failure, host down, etc) doesn't prevent Repoint from querying and rewriting the lock file based on the status of the local repo at the end of the update procedure.
This has two nasty consequences:
- If the repo hasn't been created locally at all yet, then the revision id written into the lock file will be that of the parent repo (if it uses the same version control system) or an invalid id - the result is super-confusing
- If the repo exists locally but was out of date, the lock file will be rewritten with the outdated revision id, producing wrong results for subsequent install/status operations and causing potential merge conflict/confusion
Both are obviously wrong - review.
I've reviewed the code and run some quite intensive tests, and I am fairly sure that this can only happen if a
NaNhas found its way into the moving-median filter.
There is a test for
MovingMedian::push, but it won't work if
-ffast-mathis used to compile the code. In that situation, any
NaNfound at the input will go straight into the filter and cause this assertion to fail on retrieval shortly afterward.
So I'd say first question is whether you are in fact building with
-ffast-math. If you are, try rebuilding without, and see if the problem goes away or is replaced by stderr output from the line in
MovingMedian::pushthat checks for
NaNvalues. (It should be fine to build Rubber Band with
-ffast-math, it's just that some safety checks like this are lost.)
MovingMedianfilter contains spectral summary data from the input, which has been through windowing and a forward FFT but not much else - no phase manipulation and, certainly in the case of the
study()call, it has not encountered the complexity of a resampler yet. If there are
NaNs in the signal at this point, I think the most likely - and hopefully easiest to test - explanation would be that a
NaNvalue has actually been passed to Rubber Band as input. Can you readily check this?
Thanks - this is concerning. I'll see if I can work out what might be going on.
If there is any way you can extract the value of
valueand the contents of the array at
m_size, which will be 19) at this point, that might be enlightening.
Fixed in commit:eeacebb65fa5
Fixed by removing
cinst meson- latest update to the VS2019 image in AppVeyor CI includes Meson 0.57 already (https://www.appveyor.com/docs/windows-images-software/)
cinst meson Chocolatey v0.10.15 Installing the following packages: meson By installing you accept licenses for the packages. Progress: Downloading meson 0.55.0... 100% meson v0.55.0 [Approved] meson package files install completed. Performing other installation steps. Downloading meson 64 bit from 'https://github.com/mesonbuild/meson/releases/download/0.55.0/meson-0.55.0-64.msi' Progress: 100% - Completed download of C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\meson\0.55.0\meson-0.55.0-64.msi (8.65 MB). Download of meson-0.55.0-64.msi (8.65 MB) completed. Hashes match. Installing meson... WARNING: Generic MSI Error. This is a local environment error, not an issue with a package or the MSI itself - it could mean a pending reboot is necessary prior to install or something else (like the same version is already installed). Please see MSI log if available. If not, try again adding '--install-arguments="'/l*v c:\meson_msi_install.log'"'. Then search the MSI Log for "Return Value 3" and look above that for the error. ERROR: Running ["C:\Windows\System32\msiexec.exe" /i "C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\meson\0.55.0\meson-0.55.0-64.msi" /qn /norestart /l*v "C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\meson.0.55.0.MsiInstall.log" ] was not successful. Exit code was '1603'. Exit code indicates the following: Generic MSI Error. This is a local environment error, not an issue with a package or the MSI itself - it could mean a pending reboot is necessary prior to install or something else (like the same version is already installed). Please see MSI log if available. If not, try again adding '--install-arguments="'/l*v c:\meson_msi_install.log'"'. Then search the MSI Log for "Return Value 3" and look above that for the error.. The install of meson was NOT successful.