The Bluetooth is likely under done by purposeful chips… the SHARC board is on the main streamer board and is used for digital and analogue audio.
I will look to see what the latest Analog Device SHARCs operands include… ie there are hardware blocks of DSP accelerators you instruct it to do in assembly type code, VisualDSP++ or effectively C/C++
Yes the SHARC receives the audio data stream and effectively reclocks it and the stream is processed. Typically the SHARC (21489 and related) supports the following audio streams and timing functions Digital Audio Interface (DAI), S/PDIF, SPI, UART, and precision clock generators. They also include their own processing memory to load the visualDSP source code to signal process the audio stream.
But.. it looks like there are libraries for SHARC you can use to create FLAC to PCM stream converters… with some windowing buffer complexity to look back in time for the the audio stream.
Hey buddy I didn’t mean that the speaker field coil technology is what revealed this difference between WAV and FLAC but it’s very easy to discern the differences when you’re working with a very sensitive speaker. The Naim DBLs are also very revealing speakers so I think it was just so easy for me to notice the differences. Had I been using something like my previously owned Harbeth 30s which are 84db sensitivity, perhaps I would’ve had to pay more attention to notice the difference.
Now on a brief listen the difference may go unnoticed but now that I’ve heard it I cannot unhear it. The WAV file is more coherent. Less noisy and has much better drive and flow to the music. A smidge warmer too but I would consider that just a more natural sound.
Don’t forget that your transport is a MacBook. With a much better transport you would hardly hear noticeable difference.
I prefer AIFF personally, but it’s however very minimal.
Honestly I’d pit my MacBook with the Abbas DDC against any transport.
However I aim to do even better with the SW1X VDT IV or V in the near future. The decision to purchase the S1 has completely depleted my hifi funds so I can’t say exactly when I’ll be able to do it.
I guess my thinking was along the lines of did it make sense to ‘dump’ the compressed file into the buffer from the streaming board and then use the ARM processor in what would need to be a complicated handshake with the DSP and clocks to uncompress and feed the DAC through the DSP… ? In my head it would make more sense for the DSP only to be emptying the buffer… so given that you can absolutely see that the compressed file is put into the buffer, I jumped to the assumption that the DSP would then take over…
However, the fact that the buffer contains the compressed file does in my mind ask the question at least that is there an optimum ‘format’ on the streamers that means most tracks will fit into that 50MB? Does using WAV vs FLAC etc. mean the electronics work harder as you cause more network activity keeping the buffer fed over the network? Does this impact people with noisy networks more? Is 192kHz, 24-bit audio suboptimal for your streamer?
I’m relieved to read that I didn’t get any push back. You know the usual, it’s all in your head. There is no difference FLAC Is lossless. I think we may have filtered out the noisy people from our hobby .
My biggest arguments have always been about cables mind you. The really annoying one- Silver doesn’t sound any different to copper wire. Dr. Floyd Toole said so.
Nothing to ‘push back’ because it is well known that flac and wav can sound different, however some of the replies make clear that flac and wav can also sound the same (which includes in a highly resolving system), whether or not they do in any given system depending on the specific device doing the unpacking of flac before passing to the DAC.
The SHARC buffer is a stream of data, not a file. So the sender such as the Streaming transport board would need to create the stream in a suitable serialised format. Though it appears one can use upto I think 8 bit wide streams via the UART. SPDIF would appear the simplest interconnect in terms of processing complexity that SHARC supports.
We also dont know what processing noise effects such processing would have on the DSP as it would be under software control and not using the native SHARC hardware DSP accelerators from what I can see, which are designed for filtering applications such as sampling filter reconstruction and Sigma Delta to PCM filter processing.
So I’d be surprised if such processing is not done in the streamer transport module board for isolation and simplification purposes.. but I dont know for sure on the new streamers, but I kind of doubt it would have significantly changed.
Exactly, WAV and FLAC carry identical audio information unless you are using faulty software. This is standard entropy and information science. Just like ZIP files and uncompressed files do contain the same information stored or transmitted differently. If this wasn’t the case our digital world would collapse around us, and audio would be the least of our issues.
Its the implementation of the processing for data expansion and de encapsulation that can create a different noise profile on certain systems, therefore differences being detectable in digital audio reconstruction on certain systems. It seems where DACs are on the same system as clocks and streamer core functionality this is more likely. If you separate DACs away via SPDIF or similar from the streamer it seems less likely if using a quality streamer. Effectively you are adding an extra stage of system decoupling.
People readily accept that WAV and FLAC sound different, despite containing identical audio information. Many people however absolutely reject the notion that files can sound different according to the device used to rip them from a CD. Their reasoning being that they are all bit perfect so contain identical audio information so can’t possibly sound different! How is this a rational/logical stance to take?
Similar logic (or rather lack of logic) to the folks that claim that all cables sound the same because “they are just pieces of wire”. Those same people usually then go on to use say a low cost specialist speaker cable. Why not just use the cheapest bell wire you can find from the local hardware store? Could it be by any chance because it won’t sound as good?!
Not trying to be provocative here. It’s just that these inconsistences are rife amongst the audio community. Many of us are probably guilty of inconsistent illogical thinking with regards to hi-fi matters in one way or another at some time and I do find that fascinating. What makes us all tick I wonder?
Identical audio information, packaged to completely different standards.
WAV contains uncompressed audio data, FLAC typically contain compressed audio data for a start. The streamer must decompress, which causes very minimal work, as FLAC is designed so compression is the CPU intensive operation, not decompression. But they are not the same.
There are significant technical differences between the file formats.
Two devices ripping a CD track to a FLAC at same compression level must both generate a FLAC file which meets the FLAC spec. So they can be slightly different, but only within the limits of the FLAC specification.
There are of course considerations like drive offset to consider.
If same software/encoder is used there should be very limited scope for any “significant” difference.
There are freely available tools which can deconstruct a FLAC file showing all headers/blocks etc. so comparison of differences is easy.
WAV vs FLAC is self explanatory. They are completely different, and generate completely different workloads on a streamer.
FLAC vs FLAC from two devices - this depends on how different you believe two FLAC packaged tracks can be, and whether you believe this can materially influence the workload on the streamer such that it introduces a SQ change. And whether you believe the same software/encoder will produce a materially different FLAC based on the physical device used to rip.
There was a whole thread on the Melco D100 covering all this.
I’d suggest readers search and redirect there rather than reopen this can of worms.
Indeed, and masters up stream .. ie to CD pressing plants, vinyl pressing plants or streaming providers are often distributed as FLAC files … as it is an efficient way to distribute PCM.
Although as a RIFF file WAV will allow you to support lossless compressive data chucks I don’t believe it’s commonly supported.
The problem unfortunately is most of the time these more appropriate threads are usually closed.
Personally I think if you accept that any difference between WAV and FLAC is down to the different digital processing noise created while processing them, then I think you have to accept that is the difference between a Melco rip and downloading a FLAC from say Qobuz, or ripping a CD with other software that uses higher compression. The Melco does use a lower level of compression, so the playback system will have less processing load as a result. I’m not sure many people realise you can vary the compression used in a FLAC file, or that different FLAC libraries may produce different files (in terms of absolute size), but because they meet the spec, any decoder will extract the same result. (ZIP files are the same…)
People saying they sound different so the ‘data’ must be better is the illogical stance. Unfortunately the manufacturers and professional reviewers always slip into the better data and integrity stance (because it’s a much easier reason to latch onto) which really does not help. IF digital was as sensitive to getting data from A to B as they’d have you believe we’d still be in the steam age. Linn publish some stats that even on an Audio CD (impossible to read properly according to some) the likelihood of getting an actual read error is something like 1 sector in 750 CDs, or unmeasurable if you use brand new discs. Even Melco if you dig into their website state that other manufacturers (including Naim) can create bit-perfect, archive quality rips, whatever that means.
Indeed, our hobby is littered with commentary with superficial understandings and misinformation encouraged with spurious and often incorrect causation conclusions…
Certain subjects such as FLAC vs WAV sounding different have been discussed to death over the years.. it’s like a merry go around. The fact any differences heard is down to local specific implementation on consumer hifi products seems to be ignored by some.
Sure some products will handle codecs differently in terms of efficiency and side effects so will often sound different in a closed system per data type codec due to out of band artefacts..and so to me the obvious discussion would be about architectural and design considerations and compromises on such products.. that could be interesting… and perhaps understanding causations here could lead to thoughts on integrating a more accurate and naturally sounding system, but instead seems to end up on a vacuous discussion of FLAC vs WAV sounding different. The whole digital world uses lossless compression … we don’t see different balances in our bank accounts depending on what compressive technology is being used in our digital banking systems.
If nothing else it provides entertainment.
Other old faves include differences in CD rippers, Ethernet cables, WiFi vs Ethernet, digital switches and local vs cloud streaming.
I think what disappoints me is that even on a 555 with two power supplies, one digital, one analogue, you still seem to get these interactions. In theory, reading a file into a buffer, and then feeding that to a DAC using a single highly accurate clock should be the best solution, however people seem to find that using an external transport over SPDIF performs better as there’s less noise in the device containing the DAC. In SPDIF you need two accurate clocks and mechanisms in the DAC to adjust your clock as the transport is the master…
