[Erratic Gravy]

There is this

https://www.thingiverse.com/thing:4836811

But need to find someone with a printer

busy printing first draft of URD operating instructions I think !!

 

[adydula]

There was a point where Dynaco sold more speakers than any company in the US as I recall, many got their audio start with Dynakits.

Over 1,000,000 Dynaco speakers sold.
A true classic...
I use a Van Alstine Ultravalve, Franks last re-iteration on what could be done to make the ST-70 the best it could be...from his perspective.

Stopped making these as well...wonderful pairing.
The Schiit Multibit 2 works well in this chain...

Wonder when Schiit will sell its 1,000,000 device!
Has to be getting close me thinks?
:>)

 

[Paladin79]

Over 1,000,000 Dynaco speakers sold.
A true classic...
I use a Van Alstine Ultravalve, Franks last re-iteration on what could be done to make the ST-70 the best it could be...from his perspective.

Stopped making these as well...wonderful pairing.
The Schiit Multibit 2 works well in this chain...

Wonder when Schiit will sell its 1,000,000 device!
Has to be getting close me thinks?
:>)

I can recall Van Alstine changes to Dynaco gear I used to own. My hearing Dynaco tube gear in the early 70’s made me want to recapture some of that sound with other tube power amps in my retirement. I do keep a Bob Carver solid state amp in my shop whose specs closely match those of the Silver Seven tube amps.

 

[Dr. Cube]

I hate to be the bearer of bad news, but I think Urd probably "supports" MQA. On the first USB input I connected a Fiio M11 for playback with UAPP, and on the USB DAC output I connected a BTR5, the revised ES9219 model with an MQA logo on the back, which I think is the only USB DAC I have with MQA support.

I didn't have any MQA files on hand before, but I was able to find a demo encoding on Blue Coast Music's web shop. The container is 24/44.1 FLAC, but the BTR5 indicates 88.2 kHz playback. Is this just UAPP "unfolding" it and sending normal PCM through the Urd? It's the same with the BTR5 connected directly to the player. I have to admit that the whole MQA thing is pretty complicated and mysterious, and I don't know if the BTR5 is supposed to have a special indicator for MQA other than the sample rate display.

I think it might "support" DSD, too. In this case, the BTR5 reported a lower sample rate when connected through the Urd than it did connected directly to the player. Then again, the Urd specifications page does say that it supports up to 192 kHz, and the BTR5 up to 384 kHz, so it's showing the highest 44.1 kHz multiple available in both cases. Or is UAPP converting it to PCM? Who knows!

I guess the good news is that if you do need to use a USB dongle with Urd, you still have the option of normal Redbook PCM with an R2R DAC. The USB output supplies plenty of power for an RU6:

 

[rkw]

I hate to be the bearer of bad news, but I think Urd probably "supports" MQA. On the first USB input I connected a Fiio M11 for playback with UAPP, and on the USB DAC output I connected a BTR5, the revised ES9219 model with an MQA logo on the back, which I think is the only USB DAC I have with MQA support.

Fiio M11 supports MQA unfolding.

 

[Jason Stoddard]

I hate to be the bearer of bad news, but I think Urd probably "supports" MQA. On the first USB input I connected a Fiio M11 for playback with UAPP, and on the USB DAC output I connected a BTR5, the revised ES9219 model with an MQA logo on the back, which I think is the only USB DAC I have with MQA support.

I didn't have any MQA files on hand before, but I was able to find a demo encoding on Blue Coast Music's web shop. The container is 24/44.1 FLAC, but the BTR5 indicates 88.2 kHz playback. Is this just UAPP "unfolding" it and sending normal PCM through the Urd? It's the same with the BTR5 connected directly to the player. I have to admit that the whole MQA thing is pretty complicated and mysterious, and I don't know if the BTR5 is supposed to have a special indicator for MQA other than the sample rate display.


I think it might "support" DSD, too. In this case, the BTR5 reported a lower sample rate when connected through the Urd than it did connected directly to the player. Then again, the Urd specifications page does say that it supports up to 192 kHz, and the BTR5 up to 384 kHz, so it's showing the highest 44.1 kHz multiple available in both cases. Or is UAPP converting it to PCM? Who knows!


I guess the good news is that if you do need to use a USB dongle with Urd, you still have the option of normal Redbook PCM with an R2R DAC. The USB output supplies plenty of power for an RU6:

I think this is a case of "Urd will just pass through whatever...er, ah, stuff that happens to be on the USB."

 

[Charente]

As @JamminVMI already said, there must be more to it. The sonic differences between the Æon Noir and the Æon 2 Closed are much too drastic to be caused by just a bit of perforation in the pads. At least to me, they sound like different headphones entirely. So different, in fact, that you wouldn't catch me dead with any one of the other Æon models. I know and very much appreciate that they have a lot of avid fans, and I'm sincerely glad and happy that people like and enjoy them. Variety is the spice of life, and all that. But I, personally, find them borderline insufferable, while the Noirs are without any hyperbole my favorite headphones of any set I've ever auditioned — DCA or otherwise, and regardless of price point.

As an owner of Aeon Flow Open (OG), I'm still alive and kicking !! ... about a year ago, time came to replace the pads and I got the perforated ones ... like you say, a different headphone, even on the OG.

BUT, they are second to the Meze Empyreans (to me) ... also with perforated pads (alcantara)

 

[jonathan c]

There was a point where Dynaco sold more speakers than any company in the US as I recall, many** got their audio start with Dynakits.

** Both users and makers. Think of Van Alstine and of Audio Research with their initial ‘workups’, ‘interpretations’ of the Dynaco Stereo 70.

 

[ArmchairPhilosopher]

I think this is a case of "Urd will just pass through whatever...er, ah, stuff that happens to be on the USB.

Proposal for an Urd firmware update:

When an MQA header is detected in the data stream, Urd displays the following…

…and stops forwarding any and all data from that input for the next 24 hours.

 

[DennisLL]

Only thing I currently have to say about my URD, I got a great USB interface for about $1,500.

Oh yea, CD transport seems nice too. Listened to one Cd when I first installed. Rest is 5-6 hrs of streaming from a NUC.

Going to take a while to sort this out. Like I said this USB interface is worth $1,500 or more to me.

Unbelievable.

 

[adias]

Wow! Urd is already in B Stock. Why?

 

[adias]

Question for @Jason Stoddard or someone in this forum knowledgeable about it:

On the playback side Schiit did a great job with Unison, re-clocking the input data stream, correcting network streams and cd playback data streams. Is there a jitter problem on the recording/mastering stage? Is that jitter negligible/inaudible? Depending on the statistics of that jitter, if offensive, it may or may not be correctable.

Comments appreciated!

@Jason Stoddard and others: Please take a look at the post above and comment. Thanks!

 

[ScottFree]

Wow! Urd is already in B Stock. Why?

Cosmetic blemishes probably

 

[AndreYew]

Is there a jitter problem on the recording/mastering stage? Is that jitter negligible/inaudible? Depending on the statistics of that jitter, if offensive, it may or may not be correctable.

Whatever jitter has happened on the recording or mastering side of the CD is baked into the recording: you cannot correct it at home.

 

[ArmchairPhilosopher]

Question for @Jason Stoddard or someone in this forum knowledgeable about it:

On the playback side Schiit did a great job with Unison, re-clocking the input data stream, correcting network streams and cd playback data streams. Is there a jitter problem on the recording/mastering stage? Is that jitter negligible/inaudible? Depending on the statistics of that jitter, if offensive, it may or may not be correctable.

Comments appreciated!

The term jitter describes the deviation of a signal's true sampling interval from its ideal.

If you digitize an analog signal at a sampling rate of 44.1kHz, you will take 44,100 samples per second of the signal's state at that sample's precise point in time. Which means that you would ideally take one sample every 22.675737 microseconds.

In the real world, the sampling interval will deviate from that ideal. Some of your samples will occur a few tenths of a microsecond before that ideal interval, others a few tenths of a microsecond after.

When these samples get saved to your storage medium, they will be written as a continuous stream of values, but without any information as to their actual timing, and/or deviation thereof. And when that stream of your previously stored samples is played back, it will simply be assumed that they should be played back at a constant rate of 44,100 values per second, equally spaced at the same 22.675737 microseconds that they were recorded at.

To understand what role jitter plays during recording, imagine the following:

Imagine a perfectly smooth sine wave drawn on a sheet of graph paper.
Write down the Y-value of the sine wave at every point where it crosses a vertical line on your graph paper.
Now draw a dot for each of the values you've just written down, precisely on the same vertical line that you took the value from, at the appropriate Y-position an inch or so below your original sign wave.
Once you're done, you should end up with a very close approximation of your original sine wave. You have just recorded and played back a jitter-free signal.

Now repeat the above, but instead of writing down the Y-value of the sine wave at every point where it crosses a vertical line on your graph paper, measure each and every value slightly before or slightly after that vertical line on your graph paper, alternating between "slightly too early" and "slightly too late" at random.
Now draw a dot for each of the values you've just written down, again precisely on the same vertical line that you (sort of) took the value from, at the appropriate Y-position an inch or so below your original sine wave.
Once you're done, you should end up with a still somewhat close approximation of your original sine wave — but instead of a continuously smooth sine wave, you will now have something that looks a bit bumpy. You have just recorded a jittered signal, and played it back jitter-free.

The inverse is true as well. Measure your sine wave precisely on the vertical lines, but draw each value slightly before or after that vertical line at randomly changing deviations, and you will, again, end up with a somewhat bumpy representation of your original signal. You are looking at a jittery playback of your perfectly sampled original signal.

In the real world, both happens. So not only do you not have a perfectly regular sampling interval, you also don't have a perfectly regular playback. The trick is to minimize those deviations from the ideal interval on both ends, but you will never be able to get rid of it entirely.

There's also no way to compensate for this or correct the jitter after the fact, simply because the samples in your recording don't contain any information as to when exactly each sample was taken.
You could, of course, "invent" a new recording format that not only stores the sampled values themselves, but also a precise timestamp for each and every sample to the most precise degree that your hardware allows. But that wouldn't solve your problem either, as that time stamp would be informed by the same clock signal as your analog to digital converter; the timestamp values would very likely be just as inaccurate as your sample timings.You will probably make things even worse, since the timestamp is likely to be even less precise (because it's more involved to determine) than your actual samples were to begin with, adding deviations onto deviations.

The easiest way around this is to just use hardware during recording and playback that has a good enough internal clock to stay as close to the ideal interval as physics allows. Which is also why many of your Schiit DACs do a relay click when the sampling rate changes from one track to the next: They have dedicated clocking circuits for each, 44.1 and 48kHz, and their multiples — and whenever you hear that click, your DAC switches from one of them to another one.

And for what it's worth: Jitter doesn't matter at all during storage or during any asynchronous transmission of a digital audio signal, as the values will be buffered before playback, and the playback is controlled by its own clock. The quality of that clock matters, obviously, and so does the jitter within a synchronous digital audio signal where the signal itself directly informs the clock for playback, as is often the case in S/PDIF, for example.