bugGNU Octave - Bugs: bug #59149, [octave forge] (signal) Resampling...

 
 

bug #59149: [octave forge] (signal) Resampling from 22050 to 48000 Hz introduces strange and unexpected artifacts

Submitted by:  None
Submitted on:  Sun 20 Sep 2020 06:37:54 AM UTC  
 
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Patch Submitted Assigned to:  None
Originator Name:  Marc René Schädler Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  5.2.0
Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 10 Oct 2020 12:21:08 AM UTC, comment #48: 

@Mike Miller in comment #47:

Hg patch attached. I've tried to replicate the spacing and indentation in the rest of the file. Please let me know if it should be changed. Not seeking attribution for this edit.

(file #49957)

Anonymous
Fri 09 Oct 2020 10:43:11 PM UTC, comment #47: 

The changes look functionally correct to me. Can we get this rewritten to use the preferred code formatting style?

I can't tell how many different anonymous have commented here, does someone want attribution for this bug fix?

Best would be a hg patch that can simply be applied to the project. Any less than that is incrementally more work for us. Thanks for any more anyone can do to help fix this.

Mike Miller <mtmiller>
Project Administrator
Fri 09 Oct 2020 04:57:14 PM UTC, comment #46: 

Attached fully patched version of upfirdn.cc that gives correct results and has redundant loops refactored.

(file #49954)

Anonymous
Thu 08 Oct 2020 07:33:02 PM UTC, comment #45: 

The expression for n uses a division. The one for p uses a remainder.

That entire do-while loop with continue and break inside can probably be refactored into this one-line loop:

for (octave_idx_type k = n-rx+1; k <= n && k*p + Lm < Lh; k++
  accum += h(k*p + Lm) * x(n-k,c);

Anonymous
Thu 08 Oct 2020 06:46:00 PM UTC, comment #44: 

Should it be (m * q) % p then? And if so what is the difference between n and lm?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 08 Oct 2020 06:29:50 PM UTC, comment #43: 

Verified and improved to avoid doubles entirely. A diff to patch the file src/upfirdn.cc in the signal package is:

46d45
<   const double r = p/(static_cast<double> (q));
58c57
<           const octave_idx_type n = floor (m/r);
---
>           const octave_idx_type n = (m * q / p);

This version gives correct values out of the box without special compiler flags.

Please verify and push if good.

Anonymous
Thu 08 Oct 2020 05:59:44 PM UTC, comment #42: 

No, that is dubious. This may be better:

const octave_idx_type n = floor (double(m) * double(q) / double(p));

Anonymous
Thu 08 Oct 2020 05:52:48 PM UTC, comment #41: 

Replacing

  const octave_idx_type n = floor (m/r);

with

  const octave_idx_type n = floor ( double(m) / r + 1e-3 );

fixes the rounding problem, and both versions give the same result irrespective of compiler flags.

But is this sound reasoning?

Anonymous
Thu 08 Oct 2020 05:24:46 PM UTC, comment #40: 

Added cout statements to upfirdn.cc (modified version attached).

The version with Ofast and without Ofast use different ranges for ix (file "delta" attached), because it starts with different values of n.

The correct output value for that should be 0.793431 but with the different range of ix it becomes 0.932585, hence a spike.

It looks like the culprit may be this line (possibly):

       const octave_idx_type n = floor (m/r);

which gives different results for n depending on compiler flags.

How should n be rounded in that line?

(file #49941, file #49942)

Anonymous
Thu 08 Oct 2020 04:23:51 PM UTC, comment #39: 

You are right.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 08 Oct 2020 03:54:11 PM UTC, comment #38: 

Other than standard Octave functions, these are the package-specific calls:

sample.m calls kaiser.m and upfirdn.cc

kaiser.m calls besseli(), a standard Octave function.

Neither seems to call ultrwin.m or _ultrwin_.cc or medfilt1.cc-- is this correct?

Anonymous
Wed 07 Oct 2020 10:07:18 PM UTC, comment #37: 

Thank you, I can reproduce the notch in the resampled output. Marking as confirmed.

My compiler flags do not include -Ofast or -ffast-math. I can also confirm that adding either one of those options and rebuilding makes the artifact disappear.

Mike Miller <mtmiller>
Project Administrator
Wed 07 Oct 2020 09:49:13 PM UTC, comment #36: 

I think the suspect code is in _ultrwin_.cc

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 07 Oct 2020 09:45:48 PM UTC, comment #35: 

@Comment #34: Based on everyone in this thread so far, here is an attached file (tst_bug.m) to demonstrate the (potential) error.

Correct behavior: two sine waves as shown in Comment #9.

Incorrect behavior: one of the sine waves has a bogus notch, as shown in Comment #8.

Almost everything after that has been a discussion about compiler flags for building the signal package, some of which fix the behavior but for murky reasons. It is not even clear if any code in the signals package should be changed or not.

(file #49934)

Anonymous
Wed 07 Oct 2020 09:33:56 PM UTC, comment #34: 

First it would be helpful to identify the actual cause of the error that this bug report describes.

The code in medfilt1.cc that uses '==' to identify NaN values is arguably not good, but it can't be to blame for this bug report that has nothing to do with medfilt1, can it?

Other than playing with compiler options, has anyone written a patch that addresses this bug yet?

Can someone post a clear example that demonstrates this bug, steps to reproduce, what the expected result is, what the observed result is?

Mike Miller <mtmiller>
Project Administrator
Tue 06 Oct 2020 02:11:23 PM UTC, comment #33: 

It is possible to replace the "(a == a)" code with a call to std::isnan(). That code gives the same results independent of the compiler or compiler flags. But whether it gives correct numerical results needs to be tested.

Anonymous
Mon 05 Oct 2020 04:04:05 PM UTC, comment #32: 

What can we do about it?

Anonymous
Thu 24 Sep 2020 03:20:52 PM UTC, comment #31: 

It gets more insidious. The signal package uses several instances of this pattern:

if (target == target) // not nan
    // do something
else // nan
    // do something else

Here's what happens when testing for nan with -ffast-math:

$ cat test.cpp
#include <iostream>

int main()
{
        double a = 0.0/0.0, b = (a + 1e-3) - 1e-3;
        std::cout << "a = " << a << "\nb = " << b << '\n';
        if (a==b)
                std::cout << "Equal\n";
        else
                std::cout << "Unequal\n";
}
$ g++ test.cpp && ./a.out
a = -nan
b = -nan
Unequal
$ g++ test.cpp -ffast-math && ./a.out
a = nan
b = nan
Equal
$ clang++ test.cpp && ./a.out
a = nan
b = nan
Unequal
$ clang++ test.cpp -ffast-math && ./a.out
a = nan
b = nan
Unequal

Anonymous
Thu 24 Sep 2020 02:56:06 PM UTC, comment #30: 

And here's some fun stuff just to make life more interesting!

$ g++ test.cpp && ./a.out
Unequal
$ g++ test.cpp -ffast-math && ./a.out
Equal
$ clang++ test.cpp && ./a.out
Unequal
$ clang++ test.cpp -ffast-math && ./a.out
Unequal

That was with g++ 10.2.0 and clang++ 10.0.1.

Anonymous
Thu 24 Sep 2020 02:49:48 PM UTC, comment #29: 

It turns out that this problem is completely independent of Octave.

Here's a very small test that shows the effect of -ffast-math.

#include <iostream>

int main()
{
        double a = 1.0, b = (a + 1e-3) - 1e-3;
        if (a==b)
                std::cout << "Equal\n";
        else
                std::cout << "Unequal\n";
}

With -ffast-math they're equal. Without it they're unequal.

The use of == with floating point is unwise, but somehow -ffast-math makes the intended logic work properly.

The quick workaround that a user can do to get usable results is to use -ffast-math when building packages that use == on doubles. The better fix for the package is to change "a==b" with "abs(a-b) <= 1e-4" or a similar tolerance, which will then work without -ffast-math.

Anonymous
Wed 23 Sep 2020 10:04:40 PM UTC, comment #28: 

Concur. The == and != operators should ideally not be applied to floating point values. If all instances of "(a == b)" are replaced with "abs (a-b) <= 1e-4" will it affect the rest of the package code?

Anonymous
Wed 23 Sep 2020 09:39:31 PM UTC, comment #27: 

I looked at c++ code in signal and see few instances of "==" applied to doubles. I suspect those could be broken by "-ffast-math"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 23 Sep 2020 09:12:26 PM UTC, comment #26: 

I can verify that compiling signal with gcc 8.3.1 and CXXFLAGS="-O2 -ffast-math" removes the artifacts.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 23 Sep 2020 08:53:08 PM UTC, comment #25: 

Okay, this is what happens on my machine:

With "-O3" the error is present,
with "-O3 -ffast-math" it disappears,
with "-O2 -ffast-math" it also disappears,
with "-O1 -ffast-math" it also disappears,
with "-ffast-math" it is present again.

Marc René Schädler <mrs>
Wed 23 Sep 2020 08:41:17 PM UTC, comment #24: 

I can try -O3 and combine it with the mentioned additional flags:

-Ofast

Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math, -fallow-store-data-races and the Fortran-specific -fstack-arrays, unless -fmax-stack-var-size is specified, and -fno-protect-parens.

Marc René Schädler <mrs>
Wed 23 Sep 2020 08:37:01 PM UTC, comment #23: 

Okay, with "-Ofast" I can confirm that the artifact disappears.


Marc René Schädler <mrs>
Wed 23 Sep 2020 08:17:49 PM UTC, comment #22: 

@OP in comment 20:

run "mkoctfile -p CFLAGS" at the Octave prompt. It will tell you what flags it will use for building packages.

If you want to change it, exit Octave, export new values of CFLAGS (and CXXFLAGS and FFLAGS to be safe) then restart Octave and run mkoctfile -p CFLAGS again. After verifying it, you can do pkg install -forge etc.

Anonymous
Wed 23 Sep 2020 08:14:37 PM UTC, comment #21: 

I did a long series of experiments for some hours. The clincher is not the march=native, but using -Ofast to build the packages. The base Octave installation can be compiled with O0, O2 or O3, with or without march=native -- it doesn't make much difference. But before running "pkg install -forge", set  the environment variables CFLAGS, CXXFLAGS and FFLAGS to include -Ofast. I verify that it works without march=native, at least with GCC 10.2.0.

As always, -Ofast will likely break strict standards-compliance. The fact that it gives the correct answer when plain -O2 and -O3 cause problems in this case might point to a numerical bug hidden somewhere that is being "optimized away" with -Ofast but is present with safer optimizations.

Anonymous
Wed 23 Sep 2020 08:09:01 PM UTC, comment #20: 

How do I control the compiler flags during the package installation?

Marc René Schädler <mrs>
Wed 23 Sep 2020 06:13:21 PM UTC, comment #19: 

I tried native and I tried -mavx and I still get the artifacts.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 23 Sep 2020 05:52:49 PM UTC, comment #18: 

What about "-march=native"? Will that get the compiler to pick up AVX or other CPU instructions?

Anonymous
Wed 23 Sep 2020 05:47:33 PM UTC, comment #17: 

I guess it is possible that with -march=znver2 it will use AVX instructions instead of SSE and get different results.

I tried different flags and I get the problem all the time, but
my Fedora's computer is an old i7-2600 and the Ryzen computer has an old gcc compiler that does not have -march=znver2.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 23 Sep 2020 04:50:31 PM UTC, comment #16: 

I reproduced the error! I had to compile Octave and the two packages (control and signal) with no extra options passed to configure. But then I could get the extra dots. Results attached.

This likely means that certain configuration and compilation flag combinations are safe, and the generic ones more typically used by distro package repositories are unsafe, at least for this resample operation on this hardware. You can "diff unsafe.txt safe.txt" to see the differences. The most plausible changes are to use the compiler flag "-march=native" and to use the config options "--enable-64" and "--enable-openmp" if they are not already switched on by default.

If you are in a position to build Octave and those two packages with the "safe" configuration and compilation flags, please try it and see if you get better results.

Dmitri and others: Is it possible to rebuild only the packages with the new compiler flag, instead of having to build Octave?

file #49854, file #49855)

Anonymous
Wed 23 Sep 2020 01:14:57 PM UTC, comment #15: 

Yes, of course!

Neither

export OMP_NUM_THREADS=1

nor

export OPENBLAS_NUM_THREADS=1

changed anything.

Marc René Schädler <mrs>
Wed 23 Sep 2020 01:08:45 PM UTC, comment #14: 

Those extra dots would definitely account for the peaks showing at odd locations.

Running ldd on the .oct files inside the signal package, most of the linked libraries are very standard. One thing to try is that since it links to libgomp, it is worth ruling out multi-thread behavior as a potential cause. Could you run "export OMP_NUM_THREADS=1" before running Octave, and see if it changes the output? If the problem persists at least we will know that it's not because of threading.

Anonymous
Wed 23 Sep 2020 08:40:53 AM UTC, comment #13: 

Yes, almostm, but there are still differences to what you get.
I ran:

fs = 22050;
s = sin(linspace(0,1000.*2*pi,fs+1));
sr = resample(s,48000,fs);
figure;
plot (s, 'b.'); axis tight;
print('-dpng','dots1.png')
figure; plot (sr, 'r.'); axis tight;
print('-dpng','dots2.png')


Marc René Schädler <mrs>
Tue 22 Sep 2020 10:11:54 PM UTC, comment #12: 

I noticed something else that's odd. Please try the following:

plot (s, 'b.'); axis tight; figure; plot (sr, 'r.'); axis tight

The sr values in red are all clustered into 25 discrete layers, which is not the case for the raw data in s. Do you observe the same behavior? Pictures attached.


Anonymous
Tue 22 Sep 2020 09:44:07 PM UTC, comment #11: 

I see the artifact on both dev and stable versions compiled on either Fedora 32 (gcc 10.2.1) or RHEL/CentOS 8.2 (gcc 8.3.1)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 22 Sep 2020 08:46:55 PM UTC, comment #10: 

I rebuilt the packages from the forge:

octave:1> pkg list
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control *|   3.2.0 | /home/marc/octave/control-3.2.0
     general *|   2.1.1 | /home/marc/octave/general-2.1.1
      signal *|   1.4.1 | /home/marc/octave/signal-1.4.1
    symbolic  |   2.8.0 | /usr/share/octave/packages/symbolic-2.8.0

But the result is still the same, the extra peak remains.

My system is a AMD Ryzen 3 3200G on Ubuntu 20.04.1 LTS.
But I don't think this matters.
I use Octave and from the official repository.

Marc René Schädler <mrs>
Tue 22 Sep 2020 08:26:30 PM UTC, comment #9: 

I deleted and reinstalled all packages manually from Forge. Now the upfirdn function works. (The entire subdirectory with the .oct files was missing previously from the signals toolbox).

Also the graph does NOT have the extra peak for me (figure attached). My Octave version is 7.0.0 (hg id 903fe321649b).

Will rebuilding the packages help you?


Anonymous
Tue 22 Sep 2020 08:08:43 AM UTC, comment #8: 

Here's the figure which shows the result of the code in the first post.
The problem is the "outlier" sample of the purple line.
There are more of these outliers, the figure only shows one of them.


Marc René Schädler <mrs>
Tue 22 Sep 2020 03:25:12 AM UTC, comment #7: 

octave:2> pkg install signal -forge
For information about changes from previous versions of the signal package, run 'news signal'.
octave:3> pkg load control signal
octave:4>  fs = 22050
fs = 22050
octave:5> s = sin(linspace(0,1000.*2*pi,fs+1));
octave:6> sr = resample(s,48000,fs);
octave:7> whos sr
Variables visible from the current scope:

variables in scope: top scope

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        sr          1x48003                 384024  double

Total is 48003 elements using 384024 bytes

octave:8> whos s
Variables visible from the current scope:

variables in scope: top scope

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        s           1x22051                 176408  double

Total is 22051 elements using 176408 bytes

octave:9> pkg list
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control *|   3.2.0 | /home/dima/octave/control-3.2.0
      signal *|   1.4.1 | /home/dima/octave/signal-1.4.1
octave:10> which upfirdn
'upfirdn' is a function from the file /home/dima/octave/signal-1.4.1/x86_64-pc-linux-gnu-api-v55/upfirdn.oct

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 22 Sep 2020 02:07:35 AM UTC, comment #6: 

I'm still getting the same error about an unimplemented function "upfirdn". Can someone verify?

octave:1> pkg load control general signal symbolic
octave:2> fs = 22050;
octave:3> s = sin(linspace(0,1000.*2*pi,fs+1));
octave:4> sr = resample(s,48000,fs);
error: 'upfirdn' undefined near line 121, column 121

The 'upfirdn' function belongs to the signal package from Octave Forge
but has not yet been implemented.

Please read <https://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
error: called from
    resample at line 121 column 9
octave:5> pkg list control general signal symbolic
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control *|   3.2.0 | /usr/local/share/octave/packages/control-3.2.0
     general *|   2.1.1 | /usr/local/share/octave/packages/general-2.1.1
      signal *|   1.4.1 | /usr/local/share/octave/packages/signal-1.4.1
    symbolic *|   2.9.0 | /usr/local/share/octave/packages/symbolic-2.9.0

Anonymous
Mon 21 Sep 2020 11:56:12 PM UTC, comment #5: 

Changing category to Octave Forge Package since the resample function is located there, rather than in core Octave.

Rik <rik5>
Project Administrator
Mon 21 Sep 2020 09:40:08 PM UTC, comment #4: 

>> which resample
'resample' is a function from the file /usr/share/octave/packages/signal-1.4.1/resample.m

Marc René Schädler <mrs>
Mon 21 Sep 2020 09:09:58 PM UTC, comment #3: 

Ah, sorry, I forgot to mention that I load the following packages:

octave:1> pkg list
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control *|   3.2.0 | /usr/share/octave/packages/control-3.2.0
     general *|   2.1.0 | /usr/share/octave/packages/general-2.1.0
      signal *|   1.4.1 | /usr/share/octave/packages/signal-1.4.1
    symbolic  |   2.8.0 | /usr/share/octave/packages/symbolic-2.8.0

Marc René Schädler <mrs>
Mon 21 Sep 2020 07:26:13 PM UTC, comment #2: 

Different error on trying to reproduce. Which toolboxes are you loading? Where is "resample" from?

octave:1> fs = 22050;
octave:2> s = sin(linspace(0,1000.*2*pi,fs+1));
octave:3> sr = resample(s,48000,fs);
error: 'resample' undefined near line 1, column 1

The 'resample' function belongs to the signal package from Octave Forge
which you have installed but not loaded.  To load the package, run 'pkg
load signal' from the Octave prompt.

Please read <https://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
octave:4> pkg load signal
octave:5> sr = resample(s,48000,fs);
error: 'upfirdn' undefined near line 121, column 121

The 'upfirdn' function belongs to the signal package from Octave Forge
but has not yet been implemented.

Please read <https://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
error: called from
    resample at line 121 column 9
octave:6> ver # output trimmed to show only hg id and signal toolbox version
----------------------------------------------------------------------
GNU Octave Version: 7.0.0 (hg id: ec9efcc717cc)
----------------------------------------------------------------------
Package Name        | Version | Installation directory
--------------------+---------+-----------------------
            signal *|   1.4.1 | /usr/local/share/octave/packages/signal-1.4.1

Anonymous
Mon 21 Sep 2020 08:25:05 AM UTC, comment #1: 

Update: With Matlab 2019b the result is correct. That is, Octave behaves differently.

Marc René Schädler <mrs>
Sun 20 Sep 2020 06:37:54 AM UTC, original submission:  

%I noticed this when preparing listening experiments for listeners with impaired hearing, where these high-frequency components (see result of code example below) get amplified and are producing audible distortions.
% The sox resampler does not produce such artifacts

% Code that produces the artifact for me:

% Generate a sine wave
fs = 22050;
s = sin(linspace(0,1000.*2*pi,fs+1));

% Resample from 22050 to 48000 Hz
sr = resample(s,48000,fs);

% Plot first 100ms of both signals
plot((1:2205)./2205,s(1:2205)); hold on;
plot((1:4800)./4800,sr(1:4800));

% Watch closely and you should see that one sample is "off" a bit
xlim([0.37 0.39])

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49957:  upfirdn.hg.patch added by None (2KiB - text/x-patch)
file #49954:  upfirdn.cc added by None (4KiB - text/x-c++src)
file #49941:  delta added by None (10KiB - application/octet-stream)
file #49942:  upfirdn.cc added by None (4KiB - text/x-c++src)
file #49934:  tst_bug.m added by None (216B - text/x-objcsrc)
file #49857:  nobug.png added by mrs (18KiB - image/png)
file #49858:  nodots.png added by mrs (12KiB - image/png)
file #49852:  dots2.safe.png added by None (9KiB - image/png)
file #49853:  dots2.unsafe.png added by None (9KiB - image/png)
file #49854:  safe.txt added by None (20KiB - text/plain)
file #49855:  unsafe.txt added by None (19KiB - text/plain)
file #49849:  dots1.png added by mrs (57KiB - image/png)
file #49850:  dots2.png added by mrs (13KiB - image/png)
file #49843:  bugraw.png added by None (28KiB - image/png)
file #49844:  bugresampled.png added by None (9KiB - image/png)
file #49841:  bugsignal.png added by None (29KiB - image/png)
file #49836:  bug.png added by mrs (18KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mrs (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-12 mtmiller StatusConfirmed => Patch Submitted
    2020-10-10 None Attached File- => Added upfirdn.hg.patch, #49957
    2020-10-09 None Attached File- => Added upfirdn.cc, #49954
    2020-10-08 None Attached File- => Added delta, #49941
        Attached File- => Added upfirdn.cc, #49942
    2020-10-07 mtmiller StatusNone => Confirmed
    2020-10-07 None Attached File- => Added tst_bug.m, #49934
    2020-09-23 mrs Attached File- => Added nobug.png, #49857
        Attached File- => Added nodots.png, #49858
    2020-09-23 None Attached File- => Added dots2.safe.png, #49852
        Attached File- => Added dots2.unsafe.png, #49853
        Attached File- => Added safe.txt, #49854
        Attached File- => Added unsafe.txt, #49855
    2020-09-23 mrs Attached File- => Added dots1.png, #49849
        Attached File- => Added dots2.png, #49850
    2020-09-22 None Attached File- => Added bugraw.png, #49843
        Attached File- => Added bugresampled.png, #49844
    2020-09-22 None Attached File- => Added bugsignal.png, #49841
    2020-09-22 mrs Attached File- => Added bug.png, #49836
    2020-09-22 mmuetzel SummaryResampling from 22050 to 48000 Hz introduces a strange and unexpected artifacts => [octave forge] (signal) Resampling from 22050 to 48000 Hz introduces strange and unexpected artifacts
    2020-09-21 rik5 Carbon-CopyRemoved 72865 => -
    2020-09-21 rik5 CategoryOctave Function => Octave Forge Package

    Back to the top


    Powered by Savane 3.5