Jump to content

pkane2001

  • Posts

    4418
  • Joined

  • Last visited

  • Country

    United States

Everything posted by pkane2001

  1. Hear what you expect to hear, is more like it: https://www.eurekalert.org/news-releases/609045
  2. You can save your current settings into a file to be loaded back later (File -> Settings -> Save... menu). Then, go to Settings screen and click on the red "X" near the top to reset settings to default.
  3. Generally, the larger the size of the filter, the greater and sharper the attenuation in the transition band. Just use DW defaults (Kaiser, 256k) if you are not sure. That was chosen for a reason. Hope you realize it, Frank, but DeltaWave is my playground :) I add tons of settings to play with, like the 8M and 16M tap FIR filters in the latest version, and a new IIR filter -- as I think of new things, I'll add them as well. And yes, tons of different FFT windows that I've experimented with to learn how they affect the process. FFT Windows are not used in filtering, but they are used in creating the FIR filter, which DeltaWave does on the fly. The window choice affects filter quality, regardless of size you chose.
  4. Frank, Hann is an OK window for measurements, but not for quality DSP. Kaiser is the default in DeltaWave. I included many other windows there for testing so I and others can see what they do, including rectangular, triangular, etc. This doesn't mean every combination of FFT sizes and FFT windows will work. Hann-constructed FIR filters don't reject out of band anywhere close to the way Kaiser does, and have a lot more ripple. DW provides a tool for those interested in exploring different windows: Here's Kaiser 64k window: And here's Hann 64k (an 8k Hann will be much worse): Here's what a much smaller-sized Hann window looks like (from another site):
  5. Not sure what you're saying, Frank. I don't see the glitch with any setting I try, so I'm not sure what's causing it in your case. Small sized Hann window is just not the best choice for creating a FIR filter if you want the best filter with best rejection characteristics.
  6. If you don't let the previous update finish, the new one will be ignored. That's the downside of multithreaded, asynchronous processing in DeltaWave. If anything in the UI is changed while it's still working on something, it'll simply stop the background process and not process your new request. The suggestion is to let it finish and not interrupt :) You can always press the Apply button if your last update didn't get processed.
  7. dB toggle does automatically refresh, but if you click fast enough (or while there is still some processing going on to display the previous request), it will be ignored, as it just interrupts whatever was processing before. This jump looks a bit curious, and I can't reproduce it here with regular settings. What processing did you have enabled in settings? Can you try applying the same filter @end instead of start? And can you try a larger and better FFT window, such as 64k Kaiser instead of 8k Hann?
  8. A quick update to DeltaWave version 2.0.1: Changes in 2.0.1 Fix: regression issue with color scaling of delta spectrograms ( @fas42 ) Changed: IIR filter replaced with the maximally flat in passband Butterworth version Fix: FIR filter could previously cause a small error near DC frequency Added: additional filter sizes (8M and 16M taps)
  9. Hi Frank, Yes, the delta spectrogram was scaled incorrectly in that version. I found the issue and fixed it, but have other things I was waiting to finish before publishing an update. I'll try to get this out ASAP.
  10. Here’s a suggestion for next time: get someone in the field of conducting sensory experiments to design and approve the test plan before you start. There are a few such experts here and some on ASR. An objective test doesn’t have to use perfect equipment but equipment must be tested and measured before the test so that there are no questions about what happened afterwards.
  11. Where is the recording showing that the glitch didn’t occur in the listening chain? All I see is your assurances. There are a number of recordings that show the glitch and another number that don’t. Mani, you are not going to solve the problem by arguing about it. There were flaws in the test, and this is just one of them.
  12. Yes. No. Maybe. The problem is we don’t know. It requires speculation instead of actual objective findings.
  13. No. The chart shows an average, not an instantaneous value.
  14. Mani, this is not the point. In an objective test, the results of the test and the procedure is what counts. Assurances, no matter how certain you are, are not valid, unless they can be confirmed by objective means.
  15. There are some differences at the beginning of the recording, as we discussed, but bit-perfect comparison between the A and B files after that. For example: The result says that the files samples match to 99.86%. For a 14 second recording at 176.4k this is about 3500 samples or about 20ms difference at the start.
  16. That's still strange, as the changes to the original digital file are significant and certainly not even close to being bit-identical between the file and the recording. Attenuation would not account for this, since DeltaWave compensates for level differences.
  17. We should probably switch this to another thread, as this is going completely OT here. Curious about the recording chain. Was there something that was configured in XXHighEnd or was there something else in the digital path between the original file and the digital recorder that caused the recording to be so different in an all-digital chain?
  18. Do you have a key as to what file is what? I certainly don't remember this from three years ago ;)
  19. If you do, use RME ADC at 384k rate with slow filter. This compensates for the effects of the digital filter up to 100kHz or so. At least that's what RME recommends.
  20. I disagree. A 45msec error can’t be safely ignored. To me, this is an error in measurement that needs to be eliminated if we are to trust the test results. Where’s the recording demonstrating that this error was not in the original digital stream? Mani, explaining away bad results and poor measurements after the fact is not the same as performing the test properly.
  21. What? indeed! What does that have to do with anything I said? All I said is that your software player setting (which you were unable to clearly articulate in the original thread) can alter timing sufficiently to make its effects audible. Believe me, I've done this with DeltaWave. I've done this with Distort, often intentionally. I didn't say anything about your software, its design, or whether it sounds better or worse. Could it be that you really are a little biased if you are responding to things that you read into what I posted that I clearly didn't say?
  22. But that's what I mean that it wasn't properly planned, Mani. There should be a test plan worked out ahead of time and adhered to. I'm not blaming you, btw, Mans shares at least half if not more of the responsibility, as he should have known better.
  23. Hmm, no, I’m just recounting what happened from my perspective. Bit identical can sound different, as noise and timing errors can interfere. But maybe that’s all you were trying to prove to Mans. If so, the test design was OK, but the result is really not that surprising, and to me, not that interesting. Maybe it’s just that my expectations were wrong. The digital recorder error was for a number of milliseconds at the beginning. Maybe it was less or more than 150ms, but it was a difference recorded during the test. That’s the only record we have of what was played then, regardless of the explanations that came later. This is what I meant by malfunctioning equipment. The fact that you took two tests and failed one is another procedural problem. In real testing, you can’t pick and chose test results, regardless of what you think caused you to fail. Each test is significant and should count.
×
×
  • Create New...