Jump to content

pkane2001

Members
  • Content Count

    2749
  • Joined

  • Last visited

2 Followers

About pkane2001

  • Rank
    Galactic Wanderer

Recent Profile Visitors

3190 profile views
  1. I assume you're still running the 32-bit version. There's a good chance of out of memory conditions that could happen randomly, even depending on what else is executing at the time, or possibly due to the prior comparisons before running the test that chewed up some of the available memory. You can enable full logging in DW under Help->Logging->Debug. Once you do, try to reproduce the error. When you succeed, open the log file by invoking Help->Logging->View Log... menu. Save it as a text file, or just post it as an attachment here, and I can take a look.
  2. Looks ok to me. Here's what I get (and this is using the 32-bit version): And now, swapped:
  3. Strange, let me check. It seemed to produce reasonable results when I tested it. By the way there is a swap ref/compare files menu under the file menu that you can use
  4. Yes, the 50% bit match computation is confused by the fact that it needs to increase bit size instead of decreasing it! I thought I had fixed this a long time ago, but looks like the issue is back. PS: glad you like it!
  5. @modmix, @fas42 Please try the latest update, version 1.0.37. It should address the issues you've reported. Fixed an error when applying two filters of the same kind (LP/LP or HP/HP) one at start, the other at the end of processing Changed the choice of FFT Window function to improve Non-linear EQ (level and phase) calculation precision Regards, -Paul
  6. Non-linear matching performs multiple FFTs, averages the results, and then applies the difference to the comparison waveform through another FFT. In the process, a little precision is lost resulting in a small mismatch between the reference and comparison (no processing is done on the reference file). But, the difference you reported seems way too large for a tiny loss of precision... I'm about to post a new version that might help with this. Please check it and let me know what you find.
  7. Ah, that's a bug! Thanks for finding it, Frank. If there are two HP or two LP filters selected, the logic applies the most drastic of the two filters before and after processing, ignoring the pre- and post- selection. When using a mix of HP and LP filters, the logic works as expected... I'll fix this ASAP.
  8. A 15kHz high-pass filter will certainly eliminate most of the recognizable musical content from the file. What remains is noise, filter stop-band, and a few remnants of the real audio signal. Higher frequencies exhibit higher phase noise, so I would expect timing error/correlated-null to be worse when using them to compute a null, as compared to when lower frequencies are included. But that doesn't explain why applying the two filters independently would produce a very different result, so let me test this and I'll get back to you.
  9. OK, new version has been uploaded. It's still 1.0.36, so you'll need to uninstall the previous version from Windows Control panel before installing this new one. Manual Adjustment window should display without errors.
  10. Thank you, Frank. Strange, but it looks like the package I'm using to create the installer is what's causing this particular problem. It doesn't happen before the installer package is created. I'll re-do the installer from scratch and re-upload 1.0.36. That should fix the problem.
  11. That's strange, Frank. I tested all those functions before posting, and the changes I made didn't seem to involve any of the things you're reporting. Just tested again, and still can't seem to break it. The null reference exception may actually be an indication of an out-of-memory condition that's likely with the 32-bit version. Can you please post the results text, so I can see where things went wrong?
  12. Well, I did find some issues based on your logs. Phase EQ was being applied even though Match operation was not selected, and that was causing an error. I fixed this in 1.0.36, and also added an automatic FFT size selector for files that are too short. DW will now reduce FFT size when needed by the phase EQ operation. Your files are fairly short, so I'd definitely recommend longer files and larger FFT size for EQ, if possible.
  13. Hi Arpiben, What size file are you processing and what FFT size did you select for Phase EQ? If you can post the text from the Results tab, that'll help me troubleshoot. Generally, DW tries to detect any part of the process that goes off the rails. In some cases it writes the error to the Results tab, in others it displays a message to the user, when the error is too large. It also writes a lot more detail to the log, if you turn on logging. If the error is not obvious or large in any one step, DW may not report it at all. I can add a check to ensure that the Match results don't make the initial null values worse, but in some cases, the null might be somewhat worse, while the overall match might be better, so it would be a warning rather than an error. With Wander vs Jitter distinction, I'm not sure there's a value to computing these separately for audio. From DW perspective, these are the same -- both are the result of timing errors. In fact, I hesitated to call this value Jitter (I did it only because that made for a shorter screen label . In the results list, I call it a timing error). It represents an RMS timing error over all the samples in the file. The value is computed in the time domain, so separating it into under 10Hz and over 10Hz values will take more work and processing time. Do you see a value to doing this, other than conforming to a naming convention? I'd rather change the label, then
  14. That's fair. There's only so much information available in the processed signal. If two different actions lead to the same exact result, DW will report as the one that's more likely to have been applied.
  15. I get it. There's no need to present studies that demonstrate that nonlinear systems cause subharmonics. That's a proven fact and can be modeled by some math for any nonlinear system, as long as the transfer function is known. What I don't see in any of the referenced studies is that the cochlea nonlinearity actually results in audible, detectable subharmonics from ultrasound. To my mind, until you can show that, all you have is a hypothesis about how it might possibly work. That's an interesting fact, but in no way a convincing proof of audibility.
×
×
  • Create New...