I don't see any improvement windows 10.
I'm sorry I can't reproduce this autoscrolling bug. Can you provide more details ? thanks
Thank you for your response. Sorry for my late reply -- I was on holiday and was not able to reply.
Since your message, I have been unable to reproduce the auto-scrolling (bug?) within your plug-in. My attempts to induce it have been unsuccessful. When I have more information I will contact you as soon as possible.
What is are your other settings, especially the setting for "Group"?
It sounds like DPC latency issue that bothers some system configurations. You can verify with LatencyMon.
Thanks: that's close to the kind of diagnostics I was looking for, though its report sadly doesn't match with reality:
Quote from: LatencyMon
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:02:11 (h:mm:ss) on all processors.
Computer name: LNGLEEL7034125
OS version: Windows 10 , 10.0, build: 17134 (x64)
Hardware: Latitude E7450, Dell Inc., 0Y15C1
CPU: GenuineIntel Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
Logical processors: 4
Processor groups: 1
RAM: 16267 MB total
Reported CPU speed: 2594 MHz
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
MEASURED INTERRUPT TO USER PROCESS LATENCIES
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 316.990994
Average measured interrupt to process latency (µs): 5.298606
Highest measured interrupt to DPC latency (µs): 309.095826
Average measured interrupt to DPC latency (µs): 1.464234
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 35.734773
Driver with highest ISR routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Highest reported total ISR routine time (%): 0.027854
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in ISRs (%) 0.037645
ISR count (execution time <250 µs): 107031
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 252.618350
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Highest reported total DPC routine time (%): 0.265635
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in DPCs (%) 0.434383
DPC count (execution time <250 µs): 410854
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 1
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0
REPORTED HARD PAGEFAULTS
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.
NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.
Process with highest pagefault count: wudfhost.exe
Total number of hard pagefaults 1308
Hard pagefault count of hardest hit process: 473
Number of processes hit: 25
PER CPU DATA
CPU 0 Interrupt cycle time (s): 5.329475
CPU 0 ISR highest execution time (µs): 35.734773
CPU 0 ISR total execution time (s): 0.169211
CPU 0 ISR count: 85501
CPU 0 DPC highest execution time (µs): 252.618350
CPU 0 DPC total execution time (s): 2.193474
CPU 0 DPC count: 396528
CPU 1 Interrupt cycle time (s): 1.403358
CPU 1 ISR highest execution time (µs): 34.459907
CPU 1 ISR total execution time (s): 0.028165
CPU 1 ISR count: 21530
CPU 1 DPC highest execution time (µs): 161.200848
CPU 1 DPC total execution time (s): 0.028946
CPU 1 DPC count: 5070
CPU 2 Interrupt cycle time (s): 1.853777
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 140.857363
CPU 2 DPC total execution time (s): 0.031056
CPU 2 DPC count: 5185
CPU 3 Interrupt cycle time (s): 1.027068
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 188.914032
CPU 3 DPC total execution time (s): 0.024044
CPU 3 DPC count: 4072
Over 2 minutes of execution, it continued to report that the system appears to be suitable (emphasis mine: I like the caveat), as an Ogg file repeatedly skipped.
A simple test is using another audio player.
Apparently Windows Store is blocked on this machine, so I've used VLC, and it too skipped repeatedly within the first 2 minutes of the same Ogg file. So, I took the drive over to another laptop, and the same file played just fine in foobar. This made me realise that on my main machine, I have the USB drive plugged into an extension cable (albeit a short one), so I tried plugging it directly into one of the USB ports on the Windows 10 machine, and I've now played various Ogg & FLAC files for over an hour.
Whilst I'm somewhat frustrated that I didn't think of the cable as a potential factor earlier, it was the suggestions of trying other things that got me thinking a little more systematically, so thanks everyone for input & patience.
Reset buttons should be easy enough to add.
I still can't see small "Reset" buttons for Playback rate Shift / Tempo / Pitch. Can we expect them in not so long future? And how about updating DSP chain config dialogs - to allow there for entering value manually (and then also use "Reset" buttons) ?
The Verge did a piece on hearing damage with ear/head phones https://www.youtube.com/watch?v=zGG3YsKpe88
impossible to tell without having the actual records (and even then it's impossible, for other reasons). if you decompress a mp3 file back to flac, it becomes worse because it's now having a bigger file size and you can't reverse the transform without an additional generation of loss; but it could be that they just used lossy sources when mixing and then flac version could be mathematically closer to the original.
normal records which had not come through a lossy codec don't have these kinds of spectrums so from the sales perspective it could be said that this is a scam, however I doubt that they actually promised anything with regards to recording quality so it's probably tough luck.
also AuCDtect should not be trusted as it often produces false negatives and false positives. (but it seems to be right with these 3 samples)
> Why is some of the music hitting 22?
because it can, at the record time many sounds have a lot of HF content (percussion, for example)
and mp3 encoders usually don't simply delete everything above 16kHz
There can be some nonlinear effects in the human hearing system, but unless the levels are incredibly high (to the point of damage), then there is little way that very high audible frequencies -- because of the required levels -- can be synthesized. (Middle/low frequencies can be synthesized, but that is a totally different environment, and middle frequencies don't need to be improved.)
There is too much snake oil being sold to susceptable individuals. Audio electronics techniques and technology have hit a point of diminishing returns (decades ago), but transducer (I mean real transducers like speakers/microphones) always have room for improvement, even though they have started being very good also. When a very low noise/low distortion microphone with 40kHz bandwidth can be immediately purchased over the counter -- things have gotten pretty good.
It just isn't very worthwhile to try to listen to a previously noise reduced audio recording with incredibly expensive gear -- when a LOT of vintage material has been touched by NR equipment that used two-transistor gain blocks, OpAmps not much better than LM709s (which were actually a little better than some later parts.) DolbyA units used two-transistor gain blocks, and later SR units used parts like LF411 (well, approximately.) No material touched by these devices (or most technology between the '60s through '90s) justify incredibly esoteric gear. (of course, one always wants to minimize distortion no matter where it comes from, and the early simple RIAA preamps were attricious.) Simple, competent up-to-date designs are all that is needed to get the highest usable quality. Maybe it is worth investing in very good quality (not necessarily super-expensive) transducers and being AWARE of truly incompetent electronic designs -- that it is it.
Just my opinion.. K2HD and MQA are gimmicks.
Slightly off-topic but I hadn't realise MQA was a lossy codec. How do they justify slagging off any other lossy codec?