solderdude
Grand Contributor
EQ/manipulation of files or something a reclocker/resampler could do ?
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Can you review a Synchro-Mesh S/PDIF re-clocker?
- Thread starter Empirical Audio
- Start date
- Status
EQ/manipulation of files or something a reclocker/resampler could do ?
- Joined
- Feb 23, 2016
- Messages
- 20,706
- Likes
- 37,444
Seems too uneven to be eq manipulation. But I don't know how the reclocker could cause it.
I’m a native Australian speaker - not sure if that’s the same thing
Of course it is - you just live on a bigger island with deadlier animals. As I have never been Down Under I'm not sure how beer quality compares but would certainly like to check it out!
Exactly. All your fancy graphicons are not good enough argument to change Steve's mind. But we knew that in advance, right?
Beer aint bad. My favouriteOf course it is - you just live on a bigger island with deadlier animals. As I have never been Down Under I'm not sure how beer quality compares but would certainly like to check it out!
https://www.jamessquire.com.au/craft-beer/one-fifty-lashes/
You get used to red backs in the garage.
even though harmless these Huntsmans are terrifying, especially when you pull down the car sun visor and one falls in your lap.
but then we also have the cutest critters
Quokkas. Quokka selfies are now de rigour
Last edited:
Veri
Master Contributor
- Joined
- Feb 6, 2018
- Messages
- 9,597
- Likes
- 12,039
Well that's a damn cute Quokka
Quoakka is very cute but I wouldn't hold that giant spider on my hand for a million bucks!
KSTR
Major Contributor
I checked the 24/96 files, there is a 200 samples time offset, that's it. When adjusted, the difference is a perfect digital null (all the 24-bit samples have the *exact* same values in both files). The whole task did take about 30 seconds with a wave editor.... therefore I really find it remarkable you had to seek help for this. Checking/manipulating .WAV files should be your day job if you test your digital audio stuff, shouldn't it?
Anyway, we know that the DAC gets the identical bit stream in both cases.
This does *not* automatically mean the analog output must be the same. It *should* be the same when the DAC implementation is any good.
If the DAC heavily reacts to different packeting of the identical sample stream in SPDIF frames (or USB frames, for that matter) it simply is mediocre.
In application, that would also mean a track sounds different each time, in a random fashion, depending on tracks played before it, in a player's tracklist and with gapless playback where the stream isn't restarted as long as playback continues.
I've tested a cheap bus-powered USB ADC/DAC in loopback with only the packeting being different and got a pretty huge difference in the residual, and that was pretty nolinear. The different input data stream packeting had affected the internal voltage references/clock, led to different rails/gnd pollution, some unknown things along this line caused measureable distortion in the difference when measuring some 40dB down below the analog noise floor, very repeatable.
A good DAC like the RME Adi-2 Pro FS does not show any slightest hint of this "logic induced disturbances", at least nothing that can be found in loopback tests (which are mostly blind to any change of refs/clock/etc that both DAC and ADC in the same way at the same time).
I'm pretty sure that even the cheap modern Chinese DACs (like Topping D10) that are USB powered doesnt' suffer from that effect as if they don't filter and stabilise power from USB port that would show in the measurements. As pretty much all modern DACs use the same USB receivers and DAC chips (cheap ones use mobile versions while expensive use PRO versions but even the mobile versions have respectable specs) I simply cannot imagine packeting would affect analog output of Topping D10 (for example).
KSTR
Major Contributor
The device tested was a TASCAM US144 Mk.II. With that one (not HiFi by any standard) the modulation is there. I've tested this with two different units (happen to have two of them and a US122 Mk.II, as well) and in a series of experiments to make sure what I'm seeing is correct. It's real. But, mind you, it's only visible once you climb below the analog noise floor.
[side note]
The hard part was the manual nulling (Paul's DW software would have been of great help). The recordings to obtain the block averaging from were made sequentially (not interleaved as I would do it today) and that caused that even the most minute on-average changes of ref and clock make the residual explode from linear (trivial) differences. Effect of V.Ref change is easy to explain, clock change less so: when the clock is, on avgerage, marginally higher in the second take vs. the first one this means all the analog filters shift corner frequencies accordingly, being a bit low in effect (as seen from the clock rate). That causes minute phase differences even when magnitude difference from this in the passband is really low. The phase differences are most prominent at the passband outer edges, giving the residual at bath-tub shape. I could perfectly model the apparant analog filter change in LTspice and get the same exact shape of the residual.
This effect is also seen with the RME, though to a much lesser extent because the analog filters, notably the high-passes, are at lower (or higher, for low-passes) frequencies, plus the clock seems to have a better absolute long-term stability. With this test I also see that the clock in the RME needs about 1 hour to settle, that is, until thermal equlibirium in the device is reached (it get's hot, that thing). This shows the extreme resolution that can be had from heavy time-domain block-averaging.
That's why I had to develop the interleaving method which greatly removes the effects of clock and ref drifts, after all.
[/side note]
[side note]
The hard part was the manual nulling (Paul's DW software would have been of great help). The recordings to obtain the block averaging from were made sequentially (not interleaved as I would do it today) and that caused that even the most minute on-average changes of ref and clock make the residual explode from linear (trivial) differences. Effect of V.Ref change is easy to explain, clock change less so: when the clock is, on avgerage, marginally higher in the second take vs. the first one this means all the analog filters shift corner frequencies accordingly, being a bit low in effect (as seen from the clock rate). That causes minute phase differences even when magnitude difference from this in the passband is really low. The phase differences are most prominent at the passband outer edges, giving the residual at bath-tub shape. I could perfectly model the apparant analog filter change in LTspice and get the same exact shape of the residual.
This effect is also seen with the RME, though to a much lesser extent because the analog filters, notably the high-passes, are at lower (or higher, for low-passes) frequencies, plus the clock seems to have a better absolute long-term stability. With this test I also see that the clock in the RME needs about 1 hour to settle, that is, until thermal equlibirium in the device is reached (it get's hot, that thing). This shows the extreme resolution that can be had from heavy time-domain block-averaging.
That's why I had to develop the interleaving method which greatly removes the effects of clock and ref drifts, after all.
[/side note]
Last edited:
I replied to your post as some guys could get an impression that you wanted to say that only top-class DACs like RME are not affected by packeting which I'm sure is not what you wanted to say. I believe you stated this only because you have RME on hand to measure it, as was the case with that cheap TASCAM unit. As I said, I firmly believe that modern cheap DAC like Topping D10 are not affected by packeting but it would certainly be interesting if @amirm can confirm it with measurement.
Are you saying it is lower than analog noise floor?
Btw, if packeting affects clock that device is quite poorly designed.
KSTR
Major Contributor
It is extremly hard to see this effect in standard measurements. Take your typical 1kHz sine test or 19+20Khz IMD. The "packeting error" affects the dominant regular distortion only very slightly (and it averages out, typically) plus any changes are covered by deviations just alone from the analog noise floor.
This type of error can only be isolated with heavy block-averaging, and a pre-requisite is 100% sample-synchronous record-while-playback.
With the AP or a DSO and a trigger signal on the other channel one can use block-averaging on non-synced streams as well but any trigger jitter/uncertainity causes high-frequency roll-off. RME have used this technique to verify the bit error I found in their firmware and that I could display in a spectacular clarity (measurement noise floor way below the LSB of 24 bits). This error, for example, is outside the measurement resolution of the typical "standard tests", using the latest AP or what have you. More elaborate techniques have to be used.
This type of error can only be isolated with heavy block-averaging, and a pre-requisite is 100% sample-synchronous record-while-playback.
With the AP or a DSO and a trigger signal on the other channel one can use block-averaging on non-synced streams as well but any trigger jitter/uncertainity causes high-frequency roll-off. RME have used this technique to verify the bit error I found in their firmware and that I could display in a spectacular clarity (measurement noise floor way below the LSB of 24 bits). This error, for example, is outside the measurement resolution of the typical "standard tests", using the latest AP or what have you. More elaborate techniques have to be used.
Last edited:
I see.. Nice to be informed about it, but that is definitely well beyond audible threshold. Not sure about Steve though, he might be able to hear it.
KSTR
Major Contributor
Well, audibility can only be assessed in blind tests (at least, most people here would agree). I can hear a difference between the TASCAM and the RME but of course cannot attribute this to any specific ill-effect in isolation. I happen to have another 100$ USB bus-powered DAC, the SMSL Mini DAC SD-1955+, a model from a few years back.
I might try to measure "packeting-induced errors" of both of them in asynch using the RME only as recorder, running on its own clock. But it makes the block-averaging (which is required, presumably) much more complicated, given that the diff-test method is very fragile. DeltaWave might be able to still find differences on the raw takes, after a succesful baseline null test with different takes of the same packeting to determine the possible resolution.
I might try to measure "packeting-induced errors" of both of them in asynch using the RME only as recorder, running on its own clock. But it makes the block-averaging (which is required, presumably) much more complicated, given that the diff-test method is very fragile. DeltaWave might be able to still find differences on the raw takes, after a succesful baseline null test with different takes of the same packeting to determine the possible resolution.
Last edited:
- Joined
- Nov 6, 2018
- Messages
- 1,448
- Likes
- 4,813
Yes! Here are the other ones.
and the difference (the footer and nothing else)
As I said above, the only differences you can coerce out of them at god knows how many dB down only depend on the limits on the accuracy of the number representation used/computation method/approximations within the visualization library.
I a listening test shows a difference, it is the hard proof, at infinite sigmas, about the self-delusional nature of those differences. And I don't mean it in a mean or aggressive way as it can happen to me as well.
And yes, as @KSTR said, it is beyond crazy that people calling themselves engineers in the digital world are unable to understand or check what a file contains...
[EDIT] and one thing I need to add is that if you know precisely what you do, there are ways to change a single bit in a file and create "trick" audible differences depending on the format and target device. But that would be in the realm of intentionally misleading stuff, not an honest comparison.
Last edited:
Since we are talking about reclocking here -> I came accross this test while reading about Mutec MC-3+ which I just got. This test measures jitter with and without reclocking and the results seem pretty clear in favor of the Mutec. Have a look. This is a translated text from German and there's a link to the original test at the end.
https://www.mutec-net.com/artikel.php?id=1441822741
https://www.mutec-net.com/artikel.php?id=1441822741
svart-hvitt
Major Contributor
- Joined
- Aug 31, 2017
- Messages
- 2,375
- Likes
- 1,253
Another engineering driven firm that sells clocks:
https://www.grimmaudio.com/pro-products/master-clocks/cc2/
And they just introduced a digital music player MU1 at €10k:
«Needless to say that the MU1 features our trademark ultra low jitter clock. This is a music player worthy of the name Grimm Audio»
Source: https://www.grimmaudio.com/hifi-products/music-players/mu1/
Are they all making it up, i.e. selling tech that in no way can contribute to audible improvements?
https://www.grimmaudio.com/pro-products/master-clocks/cc2/
And they just introduced a digital music player MU1 at €10k:
«Needless to say that the MU1 features our trademark ultra low jitter clock. This is a music player worthy of the name Grimm Audio»
Source: https://www.grimmaudio.com/hifi-products/music-players/mu1/
Are they all making it up, i.e. selling tech that in no way can contribute to audible improvements?
NAD started to manufacture C 542 cd player back at 2003 and stopped at 2007. I have no problem believing that a modern reclocker can help the old NAD with jitter but judging if such jitter decrease will be audible is another issue. I also strongly believe that most of the cheap DAC devices manufactured in last 5 years don't suffer from jitter issue, especially in the scenario when you are feeding it via USB instead of SPDIF where you can have jitter only between USB receiver and DAC chip.
- Status
Similar threads
