How does the fibre connection sound quality wise compare to a back to back test with a copper ethernet connection from the same network switch into your P1?
To go fibre I would have to buy a suitable network switch or a copper to fibre converter like ADOT or similar, plus a very good LPSU for either, so either option is not cheap.
Also the jury is out whether fibre is better than copper into the Lumin P1 so your comparison experience would be very interesting and valuable information.
Im using a Chord EE1 Network Noise Isolater directly into the P1 which made a small sound quality improvement on my copper ethernet connection, which is directly from my Internet Modem.
There is no such thing as time codes in the a wav chunk. What are you referring to ?. There is simply a sequential data stream, with a sample rate, and a data byte rate value in the header chunk. WAV - Waveform Audio File Format
CDDA itself has a TOC, which is an index of track locations in the data stream, but that is not at all related to WAV files.
The CDDA standard is very resilient and includes massive entropy, ie there is huge overhead to allow reliable recovery. If the read can’t be made the data is typically dropped, micro pauses, or any deviant sample that gets through results in a tick. In reading two or three CDs you might expect a single static tick.
The nice thing about digital, a deviant sample is super obvious …it’s not a subtle thing like with an analogue signal… it smacks you in the face….
If error recovery was not there, listening to a CD would be like listening to a very dusty vinyl… it would be littered with ticks and snaps.
From a data perspective, obviously fibre and twisted pair are identical. They are just physical layer variation choices.
Twisted pair is typically limited to 100 metres. Some fibre variants can go to 10s of kms.
In the home network environment the only real difference will be if using double insulated home network products, that is non mains earthed products like some consumer or audiophile switches, they can be sources or relays of common mode high frequency currents. A fibre connection would prevent common mode currents flowing. It’s like using Toslink connection between your TV and your DAC.
However if you used earthed components, like mains earthed network switches, then typically there no or minimal common mode currents, so no real or minimal advantage.
However with audio, fibre brings its own challenges, being very microphonic, and so introduces its own serial clock modulation affected by the sound pressure in the room. I have seen some tests where voices in a room were recovered from a received data stream passing through a fibre in that room. Ie the fibre acted as a microphone, and modulated the data.
In the real world a good modern streamer should not be affected by this data serialisation phase modulation (jitter). But some seem to notice these subtle minutiae when it comes to hifi.
1 Like
I’m not referring to those markers for location. I just meant the presence or absense of framing bits depending on whether they might pack LPCM in return-to-zero or not. It’s not something I’ve given much thought to (as I mentioned).
Of course the other thing, I’ve not really considered but suppose is possible, is that wav will let you pack audio other than LPCM. I think there are a bunch of codecs that can be used. While it seems unlikely that any audiophile ripper would pack other than LPCM, a voice in the back of my head reminds me what assumtion is the mother of.
Ok, I see, but in a WAV there are no framing bits or such like. It’s a simply a data chunk of the designated codec type as defined in the file header. WAV is simply a series of samples for each channel in turn until the end when encoded as PCM.
When CDs are ripped into WAV files, typically the header codec type in the constructed WAV files is 1 - PCM, but you can use lossy compressive codecs such as G.729 … but that is not used in hifi, that’s more for other commercial/industrial uses of wav files.
Wav files are simply RIFF container format for storing multimedia objects. We in consumer hifi replay only use a small part of the wav format capability.
I’m aware of all that. But maybe I’ve misunderstood the purpose of the exercise. I thought it was to:
- Determine that both rips are in fact choosing LPCM to pack the wave block (assumed but perhaps we shouldn’t be - and I think some of the alternay codecs are also lossless).
- Confirm and investigate extended processing flags if any.
- Assuming both are LPCM, compare the packing.
The latter still proving some scope for variation as I understand it. If packing is non return-to-zero then framing bits would have to be present to make a signed sample of say (for the sake of easy explanation) -100 evaluate to +400 following a +500 sample as opposed to -100. Both are LPCM and if processed correctly return the same sample but generate different workloads (if ever so subtly) to get there and different representations of exactly the same data in file.
I don’t believe so, none of that is in question as far as I am aware, as there are not really any other options if creating WAVE files from CDDA. It’s about, or at least I was referring to, comparing different RIFF constructs (layout of chunks and their IDs ) leading to different renderer code path execution as it parses the WAVE file… that may lead to a different noise profile and possibly different audio response from certain renderers.
There is no concept of ‘packing’… but there is the header chunk (fmt) , that has either the limited canonical values, or the extended ‘extensible’ values to allow High Def audio and surround sound. There are no processing flags, other than size of sample, sample rate and number of channels… and payload time ie wav/pcm or other such as compressive codecs.
One can add bespoke meta data, than could be read by a renderer that was looking for that bespoke metadata and it could adjust the rendering, but that would be bespoke/proprietry and ripper/renderer dependant.
Contrast that with HDCD which embeds flags into the least significant bit of the audio (which can be encoded in any lossless format)… so a compliant renderer can adjust the resultant audio… such as companding and EQ.
But isn’t even pre-emphasis a valid flag on both CDDA and the wav file?
How can there be sample deviation if both rips pass AccurateRip? That would suggest the exact same bitstream is somehow being reconstructed differently?
They didn’t. Media Player had no AccurateRip back then. Clearly the rips I got in burst mode wouldn’t have passed.
As I said, I wasn’t trying to do anything like what this thread is discussing or answer the same questions. I was trying to determine how much better an EAC rip was to something else that did produce “different” output.
Ah ok got ya. Makes sense now.
Indeed, if two rips ARE different then they COULD sound different….
Pre emphasis is a flag in the disc subcode (bit 4 in subchannel Q)… for CDDA (Redbook)… but doesn’t exist and has no meaning in WAV. Pre emphasis and de emphasis would have to be handled outside of wav. Remember the subchannel interleave is excluded from digital audio interleave. A ripper focuses on the digital audio data interleave when creating the ripped sample data.
A ripper might read the pre emphasis flag from the CDM and apply a digital filtering function to the ripped sample data audio using SOX or similar, or leave it alone… and simply build the wav file without any alteration which I think what most rippers would do. Kind of like how HDCD is handled.
Pre emphasis I understand is very rare in recent decades, but less so at the dawn of CD, with less capable / noisy 14 bit DACs.
A ripper / renderer combo might if setup to, if it detected the pre emphasis in the subchannel from the CDM, it might create a bespoke meta data value in List-Info or similar in the corresponding wav file, such that a matching renderer when parsing the meta data of the wave file apply a filter on rendering … but again this would be bespoke/proprietary… and I am not aware of anyone doing that.
Hi Simon,
Many thanks for the informative response.
Some owners of the Lumin P1 prefer optical connection for sound quality reasons and others copper connection.
There are quite a few owners who originally preferred optical and then changed back to copper because they then preferred the sound quality of copper more.
So, it’s really a mixed bag on which option is best and probably dependent more on the quality of your network upstream of the streamer.
I’ve only used copper on my very basic network which is now direct connection from my modem to the streamer with an EE1 just before the streamer which slightly improved the sound quality than not having it in circuit.
I’ve considered the optical option, but cant loan the equipment to try and others have tried it and gone back to copper so no real incentive to buy all the optical kit just to try with the possibility that it is not better sound quality wise in my system, so not really worth the cost and effort to try.
Hi… yes it’s probably more accurate to say that there is no difference between fibre or twisted pair… however when connected to an audio player of some sort, they may for a specific audio player/renderer cause it to create side effects from that player/renderer itself
If you’re curious you could pick up a switch with an SFP port and a couple of SFPs for £50 off ebay. Of course, this is not reassuringly expensive enough for some, but it would allow you to make a direct comparison between copper and fibre quite easily.
2 Likes
I think pre-emphasis requires EQ dsp on the higher frequencies of the audio, specifically a high pass type filter? If thats happening consistently we should see traces of it easily in all the files, both in the header and a simple comparison of the data in say an RX spectrogram. Presumably an accurate rip database comparison would fail in that situation too. I think it was part of the redbook specification so renderers should theoretically be coded to handle it as some of the older cd’s may well have been encoded that way. I expect the boost to high frequencies would sound bad without the corresponding low pass filter? With a cd encoded without it in the first place, would the sound change for the better once the high pass then low pass filter is applied? 
dunno.
Edit - having re read simon’s post above, I think he is right. I don’t think a pre emphasis flag is part of the wav standard and it is left to the cd ripper to cope with those few cd’s that deployed it.
When you compare 2 bit perfect rips of a CD done on different hardware, there are 2 potential variables……
the logical structure and the physical makeup of the files.
When it comes to 2 different servers presenting the same bit perfect file to a DAC, the same 2 potential variables apply….the logical and physical structure of the files.
When 2 different servers present the same bit perfect file with the same logical structure, potential variables are reduced to 1, namely the physical makeup of the file
If you take 2 different servers from the same manufacturer presenting the same bit perfect file in the same way and they sound different, there is only one variable……the physical makeup of the file.
If you examine the difference between the same bit- perfect-file-based outputs of say an Innuos Zen and a Statement into the same DAC, the Statement sounds superior by a large margin, commensurate with its price difference. Again there is only one variable of the output, namely the physical makeup of the file. Why? The Statement has superior vibration isolation, power supplies, oscillators, EMI screening, internal EMI generation, cabling, magnetics, SSD, RAM buffer etc. all of which contribute to give an output with superior physical characteristics (Less noise of all types, improved timing (jitter), improved square wave accuracy, etc, etc.
Given that the above will not change the response of an IT application one iota then the conclusion must be that for the music to change, DACs are to a greater or lesser degree susceptible to both the logical and physical quality of the incoming file.
In my experience, using the entire network to improve the quality of the physical layer has a major positive impact on the quality of music produced by the DAC. Stated differently, everything that improves the quality of the network’s physical layer improves the quality of the music, while everything that reduces the physical layer’s quality causes music quality to deteriorate. From an IT perspective, as long as files are bit perfect, further improvements to the physical layer will have no effect whatsoever, whereas in network music streaming systems, the opposite is true.
So to answer questions like:
Why do different servers outputting the same bit-perfect file sound different?
Why do the bit-perfect outputs of 2 rippers sound different?
Why do 2 network switches sound different?
How do power supplies affect the final sound?
Why do network cables change the sound?
Why do different disc drives sound different?
Why do different routers change the sound?
The answer is always the same……
Every one of the above has an effect on the physical layer of the file delivered to the DAC.
And why is that so counterintuitive and argued against so vehemently?
Because non of the above, unless faulty, have any affect whatsoever at the IT level of a system. It’s only when a file is fed into a DAC that the ultimate quality of its physical layer plays a role.
This is the basis on which all audiophile network streaming devices generate improvements. A top-of-the-range power supply used on a streaming system switch or server will improve sound quality immensely. That same power supply won’t make an iota of difference to the output an any IT application.
Digital’s initial promise of perfect sound forever was based on the misconceived premise that a DAC responds in exactly the same way as an IT device. It doesn’t
That misconception has spawned an entire audiophile industry based on improving the quality of the stream’s physical layer. Claims of improvements made by that industry are disqualified by IT experts applying IT standards, hence the lack of acceptance.
I spent 5-6 years making as many improvements as I could think of (and afford) to improve the physical layer of my system. The results I got were both repeatable and utterly breathtaking….until a lost my hearing. Now it’s just something I write about in the hope that other audiophiles will try what i did and get results that they, like I, never dreamt were possible from digital based music systems
1 Like
By the above rationale, you can go to WiFi and do away with all that and break the noise coupling altogether.
1 Like
Hi Blackmorec. I just read your post a couple of times. When you say the physical layer of the file I assume you are referring to electromagnetic frequencies from the various devices on the network including the innuous server entering the dac? Also em noise generated by the cpu in the digital streamer?
To clarify this noise is not likely to change the data that is sent to the streamer one bit due to the asynchronous nature of that stage of the delivery process. What happens when the streamer cpu processes that data and feeds it into the DAC is a different question - that is a synchronous timing critical process.
I think most experienced IT professionals here do understand that it is physical noise not data loss that is mostly at play in these differences. The path you describe to reduce this electromagnetic noise is understandable and will clearly make a difference to the sound. There is an alternative path involving physical distance, network decoupling and electrics with dedicated spurs feeding the hifi to a common ground earth that can achieve similar improvements. Possibly better? Who knows. As was said, wifi in theory can fully decouple the streamer from all this noise, though with tradeoffs of a new source of noise in the streamer.
We are investigating if different ways of organising the cd rip into a file can have observable differences in the sound. Some servers do this for example by re-constructing the file as pcm/wav if it was stored as flac. And in some streamers that can have an observable difference.
This I feel hits the nail squarely on the head. The only qualification I would make is that it’s not only IT experts applying IT standards - it’s everyone and their aunt who can’t accept these sorts of phenomena and therefore dismiss them as imaginary on the part of the observer. “If I can’t understand how it can happen then it can’t happen”.
1 Like