The simulations while interesting do not have any relevance to a real system set-up, unless you use broken cables. The bandwidth of cables used for SPDIF is way above that relatively slow transmission speed. interesting there was no mention of signal rise time, knee frequency etc.
So not relevant to real life situations and rather biased to again promote this misheld belief in digital cables having a noticeable effect on the sound, but not drop outs, more subtle. I have even seen a thread where they were correlating the shape of the square wave to the resulting sound...
Here are some parameters on coax cables:
Coax Cable Theory and Application - Standard Wire & Cable Co.
Coaxial cable - Wikipedia, the free encyclopedia
Actually they can, without dropouts. I was surprised. Just for the fun of it I keep a very thin, cheap Toslink optical cable that came with a piece of gear. It sounds awful. Some day I need to measure it.
My day job is digital video. Uncompressed HD video has a much larger bandwidth than any audio we use. Usually it either works or it doesn't. But there are times when a signal is right on the edge and you'll see what are called "Digital Sparkles" in the image. There may be an audio equivalent, I don't know.
There were a couple of people how could pick out the original file by ear, tho they were doubtful of their choice. Other than that, no one could tell copper from mud. I need to redo the test with a lower noise floor. That should make it ever harder. I've built the new test rig, just need to run the tests.
It's very quirky. It uses a lot of memory because it resamples up to a very high rate for the comparison. DiffMaker crashes a lot for me, and as Frank said, it will often show differences that aren't there. I think it's a great concept, just wish that Bill could refine and bebug it. It's free, so what the heck?
All the diff maker does is invert the phase of a sound file, so in practice, the null test can be done with any audio software, or even an extremely simple hardware box. I would imagine he would be more apt to update the software if it actually saw widespread use, however the only way to make it less used than what it is, would be to rename it to makeaudiophilesangry.exe.
To be perfectly honest, we probably wouldn't need it to test the audibility of an analog signal cable...I'd be satisfied if any of the people who claim their audibility could pass even a simple test...like using a hot-snot cable for the right channel and a radio shack one for left and have the person be able to reliably tell me which one I used for which. Orrrrrr..... even more funny...lie to them and tell them the opposite connection scheme was used and have them not sit there and wax poetic about a crap cable merely because they think it's expensive.
This stuff is so funny.
Over processing trying to recover the signal, noise within the equipment, noise pick up...it also as you have said has a wider bandwidth and is addressing pixels, many many pixels. I am sceptical as to whether corruption of the SDIF data can do subtle changes...... Bit drop out with wide band digital transmission such as HD TV will not be as noticeable as a bit drop out with an SPDIF signal, you will get the odd hot pixels, but they are surrounded by many good ones so the overall effect is not as severe.
I need to do some experimentation, if I get the time.....
Last edited:
That's not quite how it went - I got the original, managed to hit Mud, but got Copper and Steel Wool reversed ...
In your dreams, mate. To do this properly is very, very difficult - if only something like Audacity could do this it would be very nice, the reality is that quite a bit of cluey programming is essential, which is why it hasn't been done yet.
I'm not dreaming, pretty much any audio editor that supports multi-track playback and phase inversion can be used instead, some excellent examples exist even in freeware, such as Audacity
Many others exist as well, though.
Edit: I just realized you are specifically calling out Audacity as not being able to do this, so I'm genuinely curious to know how you arrived at this.
Last edited:
Because, the slightest variation in anything alters the waveform: timing, phase, FR, speeding up and slowing down, wow and flutter, subtle amplitude changes - it's a nightmare! IOW, to synchronise the waveforms perfectly over the length of the clip, at each point is a very major exercise. Remember, we are looking for something significant 40, 60 dB, perhaps even 80dB down, that's one part in 10,000!
I've been through the exercise of inverting and subtracting versions of the identical original track, that have been resampled differently, in software only! And just getting those to perfectly lock-step was a major bout of fiddling - the precision with which you need to work with the data, to get a result which contains exactly what is signficant and nothing else is not trivial ...
I've been through the exercise of inverting and subtracting versions of the identical original track, that have been resampled differently, in software only! And just getting those to perfectly lock-step was a major bout of fiddling - the precision with which you need to work with the data, to get a result which contains exactly what is signficant and nothing else is not trivial ...
So, it's timing?
It's really not that hard to both play back and record (multiple instances) at the same time with modern equipment.
Just looking at timing alone, consider a file of a high amplitude 20kHz sine wave - at 44kHz there are just 2 samples per cycle. Two versions of that exact same - considered as the analogue conversion - signal which are sampled at slightly different times - say, the first version has the first sample at the zero crossover, and the second has the first sample 10 degrees later, will look totally different, in digital form. The analogue equivalent, as heard by the ear, are identical - in the digital representation they are very different.
The only way to get around this is to resample to a very, very high rate, so that eventually you can get particular samples in each version to match in time.
The only way to get around this is to resample to a very, very high rate, so that eventually you can get particular samples in each version to match in time.
Last edited:
I'm sorta with you here, but wouldn't this mean that it's nearly impossible to get a summed null?
I think there's a fundamental idea that we're not on the same page about, with regards to how the test is done. Here's how I (would) do it, if I could be bothered to make someone else' point for them:
Take a 4 input USB sound card, something like a Focusrite 6i6 or whatever. 2 lefts and 2 rights. On one set of inputs, connect the source (CD player or whatever) with hot-snot cables. On the other set of inputs, use any old cheap wire.
Pop open audacity and do a 4 track recording.
Invert 3 and 4.
Enjoy your new silent track.
Seems pretty straightforward to me.
You would be getting much closer, but that assumes the ADCs in the sound card are perfectly matched in every area - if there are any differences, was it something in the USB card, or the cables?
In many situations one can't do simultaneous recordings, to do comparisons between 2 scenarios, because of what you're testing - so, back to the previous problem.
To do something like this with 100% confidence that you are really measuring what you think you're measuring is not a trivial thing to set up, many a slip twixt ...
In many situations one can't do simultaneous recordings, to do comparisons between 2 scenarios, because of what you're testing - so, back to the previous problem.
To do something like this with 100% confidence that you are really measuring what you think you're measuring is not a trivial thing to set up, many a slip twixt ...
I agree that in practice there might be circumstances where a hardware issue might affect the results, but that doesn't take away from the fact that the test works.
Something tells me the samples would sum to null even with different timing anyway, because when I say "null" I mean so far down on the db scale that audibility isn't even remotely close to a factor. If you have to play your nulled sample back on a 100db efficient horn driven by a LG FP14000 and the volume at the 4pm position to hear some tiny digital birdie artifact, then what are we even discussing?
It's a non sequitur to say that because the test can be broken that it is broken.
I dunno... It's pretty noticeable to me. But I work with non-compressed signals.
Maybe.
It's way more complex than that. From what I know, it resamples the files to a very high bitrate, then tries to match clock rate, start point and amplitude. Maybe more.
If you don't do those things it can be very hard to get a valid comparison.
Or...you can just record them both simultaneously using 4 channels.
The issue I fail to understand is how an occasional non-null result does anything to disprove the test. Even medical tests for diseases can have false positives, that doesn't mean high risk people shouldn't be tested.
I would, if I was interested in trying to prove someone else' point, but to be honest, I'm not. Who would be? It's a shame that the software crashes and/or is quirky to use, because it'd be the best tool to shut me (and people like me) up forever. I only ever reference it and suggest it as a possible tool for the people who say ridiculous things (like a $100 cable sounds better than a $10 one) to possibly back them up with something - besides anecdotal nonsense and "one time at band camp" stories.
I guess for me I'm hoping even though people still cling to cable myths and the like, will eventually try some type of actual experiment...and take a little momentum off some of these poisonous ideas.
The audio industry needs a high-colonic where most of this stuff is concerned, too much energy and bandwidth is wasted on this stuff, energy that could be devoted to actual research and development.
I mean, look at us, it's 2014 and people are still arguing about how much better $1000 cables are versus $10 ones, yet speakers are still pretty much 90 year old technology with different wrapping paper.
- Status
- Not open for further replies.