That’s a sensible move. In my case my dealer offered me a loan of what I thought was a ridiculously over priced piece of hardware, but as soon as I heard what it did I bought it immediately.
3 Likes
I borrowed from my dealer, ripped a lot of discs. Sat back and then after a few weeks decided to buy and re-rip the entire collection. Thought i might then resell……nope, still worth it to me.
Please can you both describe how you ripped the original cd and how you ripped with the melco d100 (melco library, pc software etc.). Software used and format eg wav or flac. Also how you compared the two files when you listened.(running on which media server etc) Thanks.
Demoed the Innuos Statement today using the best demo room and high end equipment the dealer had available.
Unfortunately, the dealer has the Innuos feeding the whole shop network system/demo rooms and thus configured to use Roon and refused to re- configure to use the Innuos Sense App for my demo.
Through roon I compared the Dire Straits & Mark Knopfler Private Investigations Album one locally stored wav 16/44 and one Tidal stream FLAC 16/44 and could not really tell them apart sound quality wise with maybe the wav being very very marginally a bit better.
I also compared Dire Straits Brothers In Arms Album, the 20th Anniversary DSD64 locally stored against Tidal Streamed 1985 Original Album in FLAC 16/44 and the DSD was easily better sound quality wise but thats really Hi-Res vs CD so not a fair comparison but it was good to test it.
Based on my demo today I wont be buying a cd ripper/music server and will continue with my CD Transport and streaming Tidal direct on my Lumin P1 especially as many professional reviews of the P1 said that direct Tidal streaming had better sound quality than streaming via Roon.
Its been a very interesting and worthwhile experience investigating CD ripping and music server’s and Ive really appreciated everybody’s contributions to the thread, thank you very much.
4 Likes
Glad you enjoyed it. FYI, Roon is transcoding both feeds to pcm/wav.
I’ve lost the plot somewhere trying to follow this. Can someone remind me of how to simply compare two ripped files. If I rip a file from a cd on one device and then rip a second file from the same cd on a different device, where do I go to make a technical comparison. Thanks.
(I’ll use my ears for the audio comparison.)
The old forum archive should be back now.
Nice system, my usage is about the same. We have collections based on different interests we look after and try to keep under control. There is more joy in listening and learning than searching. Not much can be found on the streaming services, the music may be there but their search functions is not very good.
Mostly CD:s but also downloads and other recordings. Public service music radio here is lossless, transmits their own concert recordings and from other EBU-countries. I record and rip on the Melco (using Minimserver/streamer for radio). I also buy from Bandcamp and use a USB-memory to transfer to avoid enabling SMB on the Melco.
And the quality is excellent, relaxing and engaging. The setup (using GentooPlayer streamer, JPLAY and no-oversampling ladder-dac) is optimized with UPnP, one can probably optimize the quality on Roon and Audirvana Studio more than I managed but I am happy as it is right now!
1 Like
Richard thanks
Totally agree there. I’m so lucky that music (playing and listening) plays a big part in my life. I truly believe that it’s a very healthy passion to have.
This is playing now, just beautiful!
SACD - great recording and mastering.
3 Likes
There is very little else in the World that can give you access to such a rich range of intense feelings and emotions
4 Likes
There are various tools available on Unix (Ubuntu, RPI) which can perform operations such as
- hash FLAC bitstream and compare to AccurateRip
- review container blocks (audio, metadata etc.)
- dump file structure (in detail)
- inspect compression levels etc.
Presuming the same software is used to rip the CD via two different physical CD drives you’d presume most of this would be the same.
Files will NEVER be the exact bit identical same since most software includes timestamps etc. So your metadata blocks might differ slightly.
Both WAV and FLAC allow various constructs, but if same ripping software is used that should be irrelevant.
On the old forum, and on other sites where this has been debated, other factors such as file construct and packaging have been postulated as reasons for the “better” rip.
However I’m only aware of one forum where a D100 rip was compared to a 20 quid Amazon USB special, and expectation bias was proved (files were to all intents and purposes identical, both bitstreams passed AccurateRip, containers were same).
Thanks. I will use accurate rip via EAC or DB PA to ensure copy integrity but following on from the thread I was wondering how to check for additional noise generated artefacts. The cddb comparison seems to compare other home rips to establish the database, It seems to suggest that the database itself may be compromised as those ‘home rips’ may of themselves be second rate. How do I find an original ‘clean’ file to compare against? I will have three separate rips of the same track taken on different kit. I would like to find which rip is closest to ‘clean’ without any added artefacts.
Hash the FLAC bitstream of the 3. They should all agree with AccurateRip and each other.
There are no noise artefacts in the “crowdsourced” AccurateRip bitstream hash. Multiple people across the world on different devices at different times have ripped the CD and got the EXACT same bitstream (allowing for CD drive head offset which simply pads intro blocks - an AccurateRip configured ripper/drive ignores this offsets). Same 1s n 0s.
It’s trivial to configure your drive - you just need to rip 3 CDs everyone and their dog owns (Dido/Adele say) and your ripper confirm offset from that. Simples.
Chances of a an error in your AccurateRip bitstream are infinitesimally small for same hash (1 in 4,294,967,296).
“Noise” occurs after this - ethernet/SPDIF to streamer/DAC etc,
2 Likes
You suggest then that the ripping process on each device is comparable? ie. The noise is only added after the rip is completed and verified. The ripper adds no noise at all. The discussion around Melco or cheap ripper is redundant?
A cheap USB and a Melco D100, using the same ripping software, would be expected to produce an identical FLAC bitstream if both pass AccurateRip (that’s the point of AccurateRip).
There have, as Simon and others have said, been questions around file structure and packaging.
But you’d expect if the same ripping software was used that those would be the same.
As I said, I’m only aware of one forum where files were compared in detail and they were technically identical.
2 Likes
Thanks.
Unless there are un recoverable read errors (skips, ticks, and silences), there will be no added artefacts in the rip.
So I would check the CD being ripped and ensure there are no deep scratches etc, and you should be fine. AccurateRip is a convenient tool to determine this so you don’t have to listen through to detect errors.
Differences in file structures don’t add artefacts, however they may invoke a different code execution path in the rendering software that is reading and parsing the file. This code execution path change might subtly change the noise ‘shape’ in certain streamers that have less advanced EM noise decoupling. This will be streamer product dependent.
3 Likes
Good to hear I am not missing out MoonDrifter.
I have a 64 GB thumb drive plugged in the back of my P1 with about 100 excellent recordings that many dealers use at demos. Mostly though, Qobuz is what I listen to, or internet radio.If you are not using it already, I would look into fibre input on your P1, it is what I am using.
1 Like
When I did a similar exercise in 2013 (I think. It’s started to fade into the fogs of time), I had a different goal but similar methods that could be modified very easily. I was trying to determine the number of deviant samples from a burst read by Media Player versus an EAC secure rip. I hadn’t really thought much about the packing at the time with the flexibility around WAV timecodes etc.
I wrote a program that simply opened the WAV file, isolated the data block and then fed it to a standard open source audio library. For the two files I then just did a sampleFetch() sequentually and started comparing each sample after leading zeros had stopped (to account for differences in the ripping software offset calibration). Then merely collected statistics on total deviations from the EAC rip and average deviations per second (88.2k samples in stereo).
Like I said, it wasn’t really looking at packing stricture. The audio lib didn’t really expose any of that. But it could be modified.
FWIW, deviant samples were seemingly infantisimal. Like 0.0001% or something similar. But that translated to hundreds per second. And remember, each sample changes how the DAC reconstructs everything around it too. I was trying to understand at the time, why an EAC rip sounded better than a Media Player rip. Bigger to my ears than the difference between an EAC rip an a hi res download of the same track.
To me, at the time, it seemed like reason enough. I hadn’t really considered the impact of packing at all back then.