Archimago wrote: 
> Download the files, have a listen, complete my survey!
> 
> INTERNET
> BLIND TEST: MQA CORE DECODING VS. STANDARD HI-RES AUDIO 
> (\"HTTP://ARCHIMAGO.BLOGSPOT.CA/2017/07/INTERNET-BLIND-TEST-MQA-CORE-DECODING.HTML\")
> BTW: Test will close for survey entries on September 8th, 2017.

Hi Archimago!

I shall certainly give your test a go.

I note your insistence in your accompanying notes that the digital input
to the DAC should not be "capped" at 24/96. Although I normally use a
Transporter in my system, this requirement will not present a problem
since I have a (or 4!) Squeezebox Touch which I can connect to my 24/192
capable external DAC via S/PDIF with an Ethernet link to my NAS running
LMS version 7.7.6-113 (simply because it's the version which Synology
make readily available, & I haven't yet found the need for one of Mr
Herger's more recent updates).

However, this did set me thinking. I know that the question of whether
the Transporter could be upgraded to handle 24/192 material has been
raised on this forum before, & the issue has been dismissed because its
architecture & processing power will definitely not support material of
higher resolution than 24/96: however, I am using my Transporter simply
to supply a digital data stream to my DAC, & do not even need the
Transporter's internal clock function (because I have a word clock link
from my DAC) let alone its DAC & analogue stage functions. It occurs to
me that this might yet be capable of changing things.

I found an interesting series of postings on appropriate digital output
connections by Sean Adams himself, where he was very patiently trying to
explain to someone (who had a clear excess of wealth to grey matter
ratio :D) that feeding the Transporter word clock input from his very
expensive dCs outboard Master Clock before linking to his equally
expensive dCs DAC was a BAD IDEA because of the *-increase-* in jitter
that would inevitably occur:
'http://forums.slimdevices.com/showthread.php?39770-Setting-Transporter-to-Slave-for-World-Clock-Input/page3'
(http://forums.slimdevices.com/showthread.php?39770-Setting-Transporter-to-Slave-for-World-Clock-Input/page5)
& the independently authored digital audio theory exposition that Sean
referenced to support his contention:
http://www.tnt-audio.com/clinica/diginterf2_e.html. Although the latter
discussion is framed in the context of using CD/SACD transports with
external DACs, the same principles will clearly apply to any "2 box"
source + DAC set-up. It is the approved (Sean's post #30 above) "Clock
Backwards" configuration as described in the technical article which I
am using. Of course, back in 2008, 24/96 itself was still considered to
be "hi res", being the DVD-A standard, & I don't think that higher
sampling rates were seriously envisaged back then, although all 3 of the
digital connections types used on the Transporter (AES/EBU, S/PDIF &
TOSLINK) will in fact support data-streams up to a maximum of 24/192.

The in-built DAC (& subsequent analogue stage) of my Transporter
continues to function when the external word clock is selected via LMS
settings, although I do not use its output. I cannot find any LMS
setting option to turn off the in-built DAC hardware if you are only
using the digital outputs to feed an external DAC & this fact might
present an obstacle to my idea. But bear with me...

My understanding is that LMS automatically down-samples 24/192 to 24/96
(& 24/176.4 to 24/88.2) *-before-* passing the data stream onwards when
its target is identified as a Transporter (as opposed to a later
Squeezebox Touch which is 24/192 capable, but lacks the handy word clock
in necessary to establish a low jitter connection to an external DAC). I
am wondering what would happen in my specific configuration if that
down-sampling were*- -**-not-* performed by LMS: after all, the data
being passed on from my Transporter to my DAC is just a stream of bits,
& I have to set the sampling rate to be used to convert it to an
analogue signal on the DAC itself.

I imagine that in the Transporter itself the conversion of 24/192 input
stream would either not occur at all (with silence in the analogue
stage), or that it would be done at the in-built DAC's maximum of 96kHz
resulting in a reconstructed analogue signal running at half-speed.
Neither of these outcomes would be of any significance to me since I'm
not using the Transporter's analogue outputs at all. Nor should they
trouble the Transporter's analogue stage.

OTOH, if passing a native 24/192 signal to my Transporter would cause it
to malfunction in any way or even cause damage, this would clearly be
another BAD IDEA! Does anyone have sufficient understanding of the
Transporter's circuitry to provide clarification on how it *-would-*
handle a 24/192 data stream?

If there would not be any hardware issues, it would seem to be a
straightforward software revision for LMS to disable the automatic
24/192 & 24/176.4 down-sampling for the Transporter -*if*- the word
clock input is selected in LMS settings, since that would appear to
imply _exclusively_ that my type of connection to an external DAC is
being used.

So maybe, just maybe, the Transporter -*could*- be made to handle 24/192
signals, even if only in conjunction with a word clock out equipped
external DAC, with only a small mod to LMS...

If no-one knows how the Transporter would respond to a native 24/192 or
24/176.4 signal, I'll pass the idea over to Mr Herger for his
consideration.

Anyway, I look forward to taking part in your test, Archimago, &
returning my findings together with the other information you have
requested!

Dave :)


------------------------------------------------------------------------
Golden Earring's Profile: http://forums.slimdevices.com/member.php?userid=66646
View this thread: http://forums.slimdevices.com/showthread.php?t=107673

_______________________________________________
audiophiles mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/audiophiles

Reply via email to