#19 rubberband bugreport: output file is not cleared after clipping 4 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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.

REPORTED RESOLVED FIXED

#19 rubberband bugreport: output file is not cleared after clipping 4 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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-clipping seems like a reasonable workaround since it just puts you back where you would have been with 1.9.x anyway!

#1 Doesn't do the right thing when remote access fails 8 months ago

Comment by ~cannam on ~cannam/repoint

Fixed in commit:6085f4a60296 and release 1.3.

REPORTED RESOLVED FIXED

#1 Doesn't do the right thing when remote access fails 9 months ago

Ticket created by ~cannam on ~cannam/repoint

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.

#18 Assertion in MovingMedian::drop 11 months ago

Comment by ~cannam on ~breakfastquay/rubberband

I've reviewed the code and run some quite intensive tests, and I am fairly sure that this can only happen if a NaN has found its way into the moving-median filter.

There is a test for NaN in MovingMedian::push, but it won't work if -ffast-math is used to compile the code. In that situation, any NaN found 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::push that checks for NaN values. (It should be fine to build Rubber Band with -ffast-math, it's just that some safety checks like this are lost.)

This MovingMedian filter 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 NaN value has actually been passed to Rubber Band as input. Can you readily check this?

#18 Assertion in MovingMedian::drop 11 months ago

Comment by ~cannam on ~breakfastquay/rubberband

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 value and the contents of the array at m_sorted (of length m_size, which will be 19) at this point, that might be enlightening.

#15 Generated pkg-config file for macOS lacks Accelerate framework 1 year, 1 month ago

Comment by ~cannam on ~breakfastquay/rubberband

Fixed in commit:eeacebb65fa5

REPORTED RESOLVED FIXED

#17 AppVeyor CI builds failing 1 year, 1 month ago

Comment by ~cannam on ~breakfastquay/rubberband

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/)

REPORTED RESOLVED FIXED

#17 AppVeyor CI builds failing 1 year, 1 month ago

Ticket created by ~cannam on ~breakfastquay/rubberband

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.

#16 Detect lack of GNU sincos() in meson 1 year, 2 months ago

Comment by ~cannam on ~breakfastquay/rubberband

Committed, thank you!

REPORTED RESOLVED FIXED