Low Level Detail: An experimental search and test.

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
BTW, maybe not exactly for this thread, but I think some mention should be about "hidden detail" and "perception of hidden detail", as they aren't likely to be the same. Different things might make music seem more detailed, and some won't have anything to do with more accuracy or S/N. So something that shows more perceived detail might even have less "detail" that might be determined mathematically. A good example is SET tube amps and my system speakers. The SETs distort like hell (all that "clean first watt" stuff, when measured, is still miles from even approaching a chip amp's distortion on any harmonic), and their response changes with speaker load. But either the distortion or the change to eq gives more perceived detail, small things just get noticed more.

BTW, what would happen if all the reviewers (the ones who "heard things" they'd "never heard before" on their old records, after using a new component), would they hear those same things now if they listened again with the system restored to how it had been before? Would those thing in the recordings be inaudible, unheard, again? I doubt it. I think with ears, it's a matter of getting things noticed as much as it is about getting noise and distortion down.

I'll stay tuned...
Bill

I think may be the small detail is being artificially enhanced by highly distorting SETs.

An externally hosted image should be here but it was not working when we last tested it.

(I hope this works and the image is from and presumably owned by Rod Elliott of ESP.)

The way waveforms add it is the higher frequencies which clip first.
In the case of SETs if I remember correctly that is mostly 2nd harmonic and generally even order which is musically related to the 1st harmonic (aka fundamental). Basically a new signal not present on the recording is generated one octave up from the original and the 4th harmonic would be two octaves.

Musically the equivalent would probably be playing chords when the composer asked for single notes.


As for newly discovered details and just speaking for myself once I hear a previously missed detail when replaying a tune on another system I hear it all the time on most systems. Probably not as clear or obvious but it is still there usually.
 
Hi Mitch, I just ran into this post. Something in the DiffMaker help files tends to be almost always overlooked. The length of the tracks sampled should usually be on the order of WELL under 60 seconds (I usually used 10 seconds), because the memory required and the likelihood of complications gets astronomical quickly. DM oversamples (a lot), does scads of transforms, comparisons, and all that, so memory gets eaten up at a rate on the order of many video editors. Besides, for comparisons done without locked record/play clocks (on all signals), the biggest difficulty is usually sample rate wandering. DM handles to about 3rd order wobbles (such as a "increasing, decreasing, then increasing again" case), but beyond that all bets are off. 60 seconds of recording with unlocked clocks is unlikely to vary in such a simple way and it only takes a ridiculously small sample time error to blow the whole deal. Also the frequency response correction trick (EQ) it can do doesn't do well with rate variations of any type, really.

(BTW, I'm not developing DM anymore since about 7 years, it did what I needed it to do then for my own investigations, and further work or support isn't really in the cards. But thanks to all for trying it!).

Just a comment on DiffMaker...

I have used DiffMaker and Audacity several times for null or difference testing with equal results. Here is one example:
Computer Audiophile - JRiver Mac vs JRiver Windows Sound Quality Comparison

There seems to be a few quirks using DiffMaker that many using the program have run into. I documented details here and here, but in summary, one issue for me was processing recordings greater than 60 seconds can randomly crash the program.

Another is in order for the time/sample alignment automation to work reliably, somewhere in the beginning of each set of samples must be an identifiable transient so the software can pattern match the two tracks, and it's within a limited time window as well. Otherwise, the software gets confused, even off by one sample will render the results useless.

Archimago found similar issues and came up with his own test protocol to bypass these: Archimago's Musings: PROTOCOL: [UPDATED] The DiffMaker Audio Composite (DMAC) Test.

Hope that helps.
 
Hi Mitch, I just ran into this post. Something in the DiffMaker help files tends to be almost always overlooked. The length of the tracks sampled should usually be on the order of WELL under 60 seconds (I usually used 10 seconds), because the memory required and the likelihood of complications gets astronomical quickly. DM oversamples (a lot), does scads of transforms, comparisons, and all that, so memory gets eaten up at a rate on the order of many video editors. Besides, for comparisons done without locked record/play clocks (on all signals), the biggest difficulty is usually sample rate wandering. DM handles to about 3rd order wobbles (such as a "increasing, decreasing, then increasing again" case), but beyond that all bets are off. 60 seconds of recording with unlocked clocks is unlikely to vary in such a simple way and it only takes a ridiculously small sample time error to blow the whole deal. Also the frequency response correction trick (EQ) it can do doesn't do well with rate variations of any type, really.

(BTW, I'm not developing DM anymore since about 7 years, it did what I needed it to do then for my own investigations, and further work or support isn't really in the cards. But thanks to all for trying it!).

Hey Bill, thanks for your DM software! Many folks have used it with good success. Sure, understood on the 60 seconds. I have been getting reliable and repeatable results with around a 30 second test file as did Archimago. It has been fun! And very revealing :)

Have you considered open sourcing the software on GitHub? As a fellow software developer, I know other software developers and audio enthusiasts would be interested in carrying the DM flag forward, if you fancy that.

All the best, Mitch
 
Administrator
Joined 2004
Paid Member
I let this drop because of a sudden move of location of about 8000 kilometers. :) I never picked it up again because I remembered the results as inconclusive and the process as difficult. If anyone else went on with the tests, they can report them here.
 
I let this drop because of a sudden move of location of about 8000 kilometers. :) I never picked it up again because I remembered the results as inconclusive and the process as difficult. If anyone else went on with the tests, they can report them here.

I did something with my mixing desk a few years back. It has multi-track recording capabilities, so it's easy to loop and re-loop things - just move the slider back to the start and you've got the same section of pink noise over and over again. Handy.

So how about this as a test:

- Record a section of pink noise within the desk (that way, we're using the same bit each time)
- Play that pink noise through a speaker while recording the mic input
- Seperate channel - mix the pink noise with a swept sine, or whatever else
- Play noise + sweep through the speaker, record the mic input
- Import into Audacity
- Invert one recording, and sum
- Ought to leave you with a sine sweep
- Import into REW
- ????

I think the think to do there would be to also record the speaker playing the swept sine tone without pink noise, and then you've got a comparison - low level sweep vs low level sweep plus high-level noise.


From what I can tell, that's holding as many things constant as possible - all we're doing is introducing (repeatable) pink noise while doing a sweep.

I'd probably do it close-mic'd so SNR improves with regards to outside acoustics, noise, etc. Anything that gets recorded will screw up the measurements.

Not really in a position to do much audio-related stuff right now, but once things settle down this is something I'd like to get back to.

Chris
 
Administrator
Joined 2004
Paid Member
That seems like a good idea Chris. I like the idea of recording the low level signal alone as a comparison. :up: The main stumbles I found were getting the files lined up at the correct staring point and also getting them level matched. Level isn't too hard, if you record one after the other.

Yes, close miking is required if you don't have an anechoic chamber. We are really just concerned with how well the driver can reproduce low level detail. In this test it is low level detail buried inside a higher level signal - but maybe just a very low level comparison of a single signal would tell us a lot.
 
A very interesting topic.

I have noticed a fading detail effect. When a single driver gets increased lower frequency power (and movement) it appears to diminish the detail of the higher + lower amplitude frequencies. It looks like superposition problem. I was never sure if it was me or the driver.

Would the level of detail the driver is capable of be indicated by it's HD (THD or even harmonics ) ?
 
The main stumbles I found were getting the files lined up at the correct staring point and also getting them level matched.

Hey Pano,

A lot of that can be sorted within the desk - move the recording slider back to the start, press "track" on the pink noise and "record" on the mic input, and I'll be able to subject the speaker to the same section(s) of pink noise as many times as I like, with other things mixed in as needed.

In theory, that'd get everything to work perfectly.

In practice, I expect the increased noise levels present in the difference file to swamp any changes in the distortion from driving the speaker with other signals.
We'll see.

I suppose this'd be a good way to test amplifiers, too.

Chris
 
It certainly would be easier with power amps and line level circuits. I had pretty good success with line level signals.

You could compare two circuits to find if one "preserves" low level detail better than another.

Sounds like a fun game.

For power amps, we could take it up a notch - low-level detail vs load impedance vs voltage output.

... and now I need to build another load bank.

Chris
 
......The main stumbles I found were getting the files lined up at the correct staring point and also getting them level matched. Level isn't too hard, if you record one after the other.
I used Reaper with ASIO in multitrack mode, track one playing the signal and subsequent individual tracks recording the loopback events.
Comparisons of recorded tracks showed automatic perfect time alignment.



Dan.
 
Administrator
Joined 2004
Paid Member
Picking this up again, and still not getting the results I was hoping for.

I was wondering just how much detail is "thrown away" by the MP3 conversions at different sample rates. Inspired by Bill Waslo's brass band that is hidden 70dB down in another file but can be extracted with Diffmaker software, I set out to do a similar test of MP3s.

Basically I took a Frank Sinatra track and buried a classical wind ensemble 60dB down in the mix. When this is saved as a 24 bit file, the extraction of the very low level wind ensemble is rather good. When saved as a 16 bit file, it's not so great and rather noisy, but still there, recognizable and surprising, considering how buried the signal is. The hidden signal lies at an RMS value of 85dB below peak. That was my proof of concept and it works.

From there I moved on to MP3 encoding of the Sinatra song with hidden wind quintet. But even at 320 Kbps what's left over after extraction is so loud it hides the wind quintet. In other words, the difference between the wav file and the MP3 is so great that it still hides the low level signal.

That leaves me at an impasse. Is there perhaps a way to further extract the hidden signal and pull it out of the noise?
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.