In @HungryHalibut example I suspect that the SHAH checksum for each of the 4 files will be different due to metadata and possibly other artefacts so not identical in terms of 1s and 0s. I am not sufficiently knowledgeable to comment on what the structure of a red book compliant audio file is, there will be allocated portions of the file for metadata, file length etc and also a big portion of actual “audio data”. Wiki has a good article if folks are interested. This may cause differences in replay.
Like @HungryHalibut I’m keen to improve my understanding, even if I can’t necessarily hear any differences myself, others can and may wish to pay to remove anomalies they hear.
Exactly. As I don’t want to pursue this debate, what this post means has no more importance to me than those posts explaining that the differences in sound are not possible technically.
„ Maybe or not.
I did ask the head Melco man at a Dealer event a few years ago why there was a difference - given that the compared rips were otherwise identical as measured by error-checks. He did insist that their ripper did extract a more accurate rip - which I still do not believe - but then mentioned something about ‘data-packing’ which seemed to be a low-level storage formatting of otherwise identical accurate ripped files - then quickly changed the subject.
In the end the Melco rips do sound different and IMO better and was one of the most confounding and crazy demoes I had at the Dealer between (1) DBpoweramp rips vs (2) Melco Server rip via cheap USB drive vs (3) Melso Server rip via their own expensice ripper.
We compared rips of the exact same CD that my dealer did at that time and it was clear that for unknown reasons (2) was a lot better than (1) in terms of clarity, lack or murky background and just was more interesting - then (3) was better than (2) by a smaller amount but through the Dealer Statement system it was obviously superior.
Annoying - I borrowed the device and repeated at home - and eventually got one as in context of my system and the fact I was just moving from CD replay via CD555 to streaming via ND555 I wanted to rip my CDs once and the best I could, however that would be done.
No idea what is happening - the conversation did happen a few years back to mass incredulity and I have nothing to say other than whatever is going on I can hear the end-result and it was worth the outlay.
Some friends also interested did do some measurements and as suspected the rip via DB poweramp and Melco were identical in accuracy but there was a small difference in how the low-level data was stored.
That sounds very plausible indeed to me, and if not the whole story then at least a part of it.
It can’t explain why my D100 makes better sounding rips when powered by a Plixir LPS as opposed to the Melco supplied SMPS though. So this implies that something else is going on as well. Presumably the Plixir introduces less noise compared to the SMPS. So less noise is getting into the rips? Is that possible (noise being defined here as anything at all that doesn’t form part of the digital music data)? I’m inclined to think yes, but perhaps someone with far greater understanding than me will say it just doesn’t work like that. In which case - what is going on then?
Hi, Some of us spent quite a lot of time analysing this several years back to get to the root cause of why some rips ‘sounded’ different from others on some renderers. This was at least one reason we found.
In essence a rip is identical assuming no unrecoverable errors and the offset is correctly setup between CD driver and ripper software (remember there are no ‘files’ of the audio in an audio CD) . If the offset is is out - then the start and end of the rip can be out by a few fractions of a second.
The Accurate RIP uses a hash function, it will identify if your rip has tiny unrecoverable errors which are typically pin holes of silence that you don’t notice - or in more crude setup tiny static type ticks that you can hear.
AccurateRIP uses a hash function, I don’t know which one. Some are not so reliable and they can produce collisions - ie the same hash value with different inputs. However the chance of a collision from a rip with the odd unrecoverable error is likely going to be so minuscule - you are more likely to self combust.
The industry standard SHA-2 standard with a SHA-256 hash is going to perfect for this sort of thing, if not a complete over kill - but the older more unreliable hashes like MD5 and SHA-1 will also be totally fine for this application.
Now the interesting bit… we found the file construct produced by the ripper seemed to affect the resultant audio ‘quality’ on some renderers. (remember this was back in the day when the difference between FLAC and WAV playback was quite obvious for many). There are different ways that WAV files can be constructed - and as such the WAV file reader has to handle different WAV files differently in how the file is parsed. WAV files are RIFF files - which means they can be constructed in any order and are segregated using chunks identified with tag IDs of various lengths.
Things like metadata and audio data are completely separate and are in separately tagged parts of the WAV file.
The two popular WAV variants at the time were the ‘Canonical’ construct, and the ‘Extendable’ construct.
So some felt that some WAV file constructs sounded slightly different to other WAV file constructs for a certain renderer/playback device depending on which ripper was used - and therefore which WAV file construct was used. However within these WAV file variants, assuming the offset was correct, the rip itself was bit for bit identical.
However I think playback systems have got a lot better in recent years compared to when we did this and so noise and interference from code execution patterns has become more and more marginal on quality systems.
If one can search the old forum - I believe the old posts and analysis in mind numbing detail is there.
Oh yes this is not related to streaming differences - as servers strip down the file into elements before the parts are sent or streamed. (as opposed to internet Radio streaming) There was other analysis on streamer server differences undertaken - that was more an individual effort and I shared my analysis with Naim when they were developing the Gen 2 streamers - I don’t hear these variations now
A good reason to use a liberal sprinkling of emojis
When we communicate on forums like this, our words get stripped of the all the body language that normally comes along with our words when we are talking face to face in the same room. Add in the british sense of humour and some non native english speakers (let alone the trolls who thankfully mostly play away from here) and the potential for disaster is high! We generally do well!
That’s exactly what I was about to say having thought about it some more.
Seriously though I don’t pretend to fully understand all that but I can understand enough of it to convince me that it’s the reason why bit-identical rips can sound different.
Now why should a quieter power supply on the ripper produce better sounding rips? Any thoughts on this Simon?
Exactly - because it isn’t the rip you are listening to - its the RIP packaged into a file construct and then deconstructed by software - which itself adds noise (out of band interference) - good old systems theory - functions produce an output and ‘error’ in the real world.
I would look at the out of band environment… one case it won’t - in another case it might.
This is an area that some of us did some community blind testing on … the results were interesting - I will refrain from sharing here as some seemed to get quite tetchy/defensive.
Not sure why - as I say one needs to look at the out of band environment.
I am not teasing - but a genuine little experiment. Create multiple pairs of FLAC files of different tracks - one of each pair at compression level 1 (note not 0) and the other of that pair compression level 8. Mix them up and play back those files so you don’t know which is which … what do you notice?
Then do the same - one file pair being FLAC and the other WAV - what do you notice?
You can do the same with rippers, ripper power supplies, etc… just keep the environments the same/static during playout… what do you notice?
I guess some you may notice and others you might not… but I won’t suggest which is which… and some results may surprise you and not what you expect… but it reflects the response from your system and environment.
Hi Simon. I also assumed that it was probable that the wav v flac differences I heard years back had something to do with cpu processing overheads in the streamer - noise or some kind of timing related artefact perhaps. I agree it is probable that streamer designers have taken more steps to minimise this over time.
I had forgotten the offset calibration as it’s now been years since I ripped! I stopped buying CDs around 2016/17. So if you do get a cheaper drive its worth checking which have tolerable alignment. I think I got one of the several drives spoon recommended on their websites.
A potential issue on the file construct is interesting. I had not read that thread so will give it a read. I assume the mechanism through which these encoding differences manifest is the streamer cpu processing overheads again? I had also understood that metadata and audio data is completely separated and although some of that data is sent to the streamer upfront, it is quite unlikely to be causing issues during the delivery of audio data.
I do wonder if all this is one of the reasons Linn switched to fpga circuits to handle their pre-processing of data in the streamer with Organik. I have’t had the patience or inclination to re setup asset upnp and try comparing wav and flac since I upgraded to Organik and see if it has made a difference since I now use roon which handles that flac to wav/pcm conversion in the media server anyway. At the time I just adjusted the asset parameters to convert to wav/pcm and got on with enjoying music
That was certainly the forum consensus back when I had a 272. So I installed Bubble UPnP on my NAS and set it to convert FAC to WAV on the fly, after which the SQ difference disappeared, at least to my ears.
Different software execution. We know code execution whether it be in FPGA, Harvard processors or microcontrollers produces a noise signature. Whether this noise signature makes a meaningful change to the resultant signal will vary from design to design. Naim tune or shape this noise to good effect in their streamer and DAC products.
In worlds very different to hifi and consumer audio - this processing noise signature can be used to reverse engineer or eaves drop into systems…
I think what simon is saying if I get this right is that the software on the streamer cpu is compiled down to machine code and the execution of those software instructions generates a noise pattern based on the cpu instructions executing. So its rather that the processing of the file in the cpu generates a distinctive noise pattern that can change for example if the streamer cpu has to do lots of conversion from flac to wav.
