Rip your files the NAIM way...or else???

Posted by: Geoff P on 01 August 2012

On another thread here which discussed limitations to file transfer and storage on the UnitiServe outside of ripping in the box (and by reference also the HDX/NS0x series swell)  the following responses were given to questions suggesting bit perfect rips by commercial software such as dB Poweramp or EAC should be accessible and transferrable with the same results as the internal Naim controlled rips.


Paul Stephenson:-


"Easy naim rip via our server easy db and eac good but our rip and our drive choice usually outperforms"


Phil Harris:-


"The point here is that the UnitiServe (and HDX / NS0x) are designed as a hardware and software combination that gives a good set of results without the end user having to work out and put together their own combinations of hardware - i.e. the rips should be as good as it is possible for them to be - bit perfect.

EAC or db *CAN* also achieve bit perfect rips but EAC or db are only part of the solution - there's hardware that they sit on top of and that too has to support the process. Just throwing EAC or db at a CD on its own does not guarantee a bit perfect rip if the hardware tey're running on doesn't support that.

If there are differences in the rip then there *WILL* be differences in the payback of those rips and if a rip produced by EAC or db isn't bit perfect then there's nothing that any utility written by anyone can do to make them so...


Paul Again:-


"....as Phil replies its the combination of hardware and software, the files will look identical from,db,eac or itunes but from the experiences we have had here the sound is not."


The issues for the larger digital ripping community that this raises should be answered if the above statements are taken to be correct.

 

1) By implication the US has a hard disk /hardware chain inside it that confers some quality of performance that is specific to Naim. Does this also apply to the SSD version and if so that MUST eliminate the HDD inside the US from this argument.

 

2) If the statements above are correct then by inference the use of a NAS will change the situation. Naim apparently does not say to get the best results with a digital audio chain that includes the US ( or HDX etc) a specific make of NAS hardware is required to preserve the 'Naimness' of rips made on the US. Does this mean that Naim does not include the wider field of NAS hardware in their claim.

 

3) Does this mean that the ripping process in a Naim server box is necessary to obtain the full benefit of the Naim rip strategy and that therefore systems without a Naim ripper in them are compromised in some fashion.

 

4) When it is stated the EAC or dB CAN produce bit perfect rips, but only if the hardware there running on allows it, by implication the manufacture of some CD Rom drives is so unusual that the Accurate rip database can be cheated by them and that whole section of the data storage industry happily accepts non-bit perfect archiving of files may occur.

 

5) How does the Naim label create its download files and are they also going to sound the same as ostensibly the same music files ripped off CDs on a US. For that matter when we download audio files from other respected sources are we missing out again.

 

I find it hard to believe the above is true. But if it is then it implies the wider world of ripping/storage and transfer of audio is inferior in some way.

 

Posted on: 01 August 2012 by Claus-Thoegersen
Originally Posted by AndyPat:

Some listen and they hear............others listen and they cannot hear.

Unhappy are they who cannot hear for is it not said that if you can't fully explain it it cannot be so?

Lucky am I that Sir Isaac explained gravity. I would care not for a floating existence.

 

Unlucky am I who have not a floating Snaxo!

 

Claus

 

 

 

Posted on: 01 August 2012 by Simon-in-Suffolk

This topic always makes me snigg-er  as it comes up quite reguarly. But those that remember some of us performed some tests last year, and I analyzed several wav rips of the same CD track. One on a mac with iTunes, one a naim unitiserve, one a PC with EAC and one with a PC with dBpoweramp.

I analyzed the files using specialist  debugging and data analysis software and the DATA chunk of the WAV file on all files was identical. That is every single  sample on each file of many tens of millions of them was identical. (and incidentally they sounded identical to). The length was identical. The sample data was absolutely identical, that is it was word perfect - rather than bit perfect. We put this to bed once and for all - thank goodness.

 

Those that feel there are still differences and vaiations, that's fine but it has absolutely nothing to do with data in the rips, but perhaps more to do with the spiritual vibes that resonate around the psychic aura that eminates from a ripped CD track that might happen to intersect with nearby lay lines.

 

Ripping solutions are  about process choices, compiling metadata and strategies for handling damaged discs. Unless your software or hardware is faulty or incorrectly setup the sample data is identical and 'sounds' the same. Luckily we have the principle of Entropy that underpins this and stops us loosing  our sanity, apart from that poor sole who re ripped his 5000 CDs

 

The variations of course arise from how  the wave files are read and then how they are subsequently rendered to the DAC.

 

Posted on: 01 August 2012 by pjl2

I have yet to get into the pleasures of hard disc replay or streaming. However  I find all this talk of bit perfect copies (or not), different ripping software/hardware and concern over whether files ripped by one solution sound different to those ripped by another, to be rather odd. So what if apparently identical files sound different because they were ripped differently? 

 

I wonder how many supposedly identical LP pressings sounded different all those years ago? In fact every time an LP is played the sound is changed very slightly due to record, stylus and cartridge wear, yet nobody seems particularly concerned about that. I wonder how many supposedly identical LP12's sound slightly different due to the differing abilities of the people that set them up?

 

What I'm trying to get at is that this sort of variation is nothing new, we have all lived with it for decades without worrying. Just like when CD was launched and wrongly claimed to offer the perfect sound, clearly no ripping software or hardware can do so either. There are variations, despite claims or even evidence that the ripped files are bit perfect.

 

Clearly we still have some way to go before we can claim to have reached perfection!

 

Peter

Posted on: 01 August 2012 by Hook
Originally Posted by Simon-in-Suffolk:

...

I analyzed the files using specialist  debugging and data analysis software and the DATA chunk of the WAV file on all files was identical. That is every single  sample on each file of many tens of millions of them was identical. (and incidentally they sounded identical to). The length was identical. The sample data was absolutely identical, that is it was word perfect - rather than bit perfect. We put this to bed once and for all - thank goodness.

 ...  

 

 

+1.  Yup, I was paying close attention Simon.    Not sure what all the fuss is about -- thought we had gotten to a consensus on bit-perfect ripping ages ago.

 

Not saying the US isn't a fine solution.  In fact, had I discovered that I had made some major setup mistake, and that my rips were nowhere close to bit perfect, I might have been tempted to turn over the keys to Naim and let them drive.

 

At about the same time Simon was doing his proofs, I became concerned because I had ripped a bunch of CD's to FLAC level 0 with MediaMonkey 3.x, and MM did not start supporting Accuraterip until release 4.  So I re-ripped a few CD's using EAC/Accuraterip and sent the A/B's off to a tech-savvy friend from work.  He confirmed that the PCM data was identical between my early and later rips.  It left me wondering just how hard it is to get ripping...wrong.  Or wrong enough where the differences would be audible, and re-ripping would be justified.

 

Anyway, there are lots of good solutions these days for accurate ripping, and MM is as good as any. I also like MM because of its integrated, multi-database support for tagging.  Can't remember the last rip that required any manual intervention at all.

 

Hook

Posted on: 01 August 2012 by DrMark

Peter - I know precious little about ripping & streaming, but the analogy of creating a vinyl disk vs. a computer file (which is nothing more than 1's & 0's in the correct order) breaks down - because the physical media is "removed" from the equation in the digital world (assuming it can at least accurately store the bits.)  That is the whole point of digital vs. analog...which is of course, a completely separate (and well worn on this forum) discussion.

 

Thus, any accurately reproduced sequence of bits that comprises a file (in this case a piece of music), when played on identical systems, must sound the same, irrespective of the means by which those bits were placed on the storage media.  The discussion appears to have centered around whether there is more than one way to arrive at that result, which it appears all concerned have said "yes" to the possibility...the question is merely one of execution in the ripping process.

Posted on: 01 August 2012 by pjl2

DrMark,

 

Agreed. My point really was why worry if different ripping protocols result in files that, whilst they may appear identical, sound slightly different? As long as a file sounds OK surely that's all that matters. The obsessive may wish to try any number of different software/hardware configurations, and having ripped thousands of CD's may re-rip them if something better comes along. For most people though I suspect that a rip on something like iTunes is perfectly adequate, even though perhaps it may sound fractionally less airy in the treble or lighter in the bass compared to a Naim rip. I would suggest that any such differences are likely to be insignificant in terms of enjoyment of the music.

 

Peter

Posted on: 01 August 2012 by likesmusic
Originally Posted by Simon-in-Suffolk:

 

I analyzed the files using specialist  debugging and data analysis software and the DATA chunk of the WAV file on all files was identical. That is every single  sample on each file of many tens of millions of them was identical. (and incidentally they sounded identical to). The length was identical. The sample data was absolutely identical, that is it was word perfect - rather than bit perfect. We put this to bed once and for all - thank goodness.

 

The issue has certainly not been put to bed once and for all.

 

As you can see on this thread, Naim are still standing by the claim that there is an audible difference between dBpoweramp rips and Naim rips, even if dBpoweramp rips are correct and bit identical to the Naim ones.

 

While Naim keep that position, the issue will not go away.

 

In earlier incarnations of this argument I can remember David Dever arguing dBpoweramp created different file headers and these in some way upset the Naim playback system. I believe Simon proved that these headers were absolutely within spec. 

 

Posted on: 02 August 2012 by ken c
Originally Posted by likesmusic:
Naim are still standing by the claim that there is an audible difference between dBpoweramp rips and Naim rips, even if dBpoweramp rips are correct and bit identical to the Naim ones.

 

While Naim keep that position, the issue will not go away.

i dont understand enough to understand "the issue" and make a real contribution to this learned banter, but the above is not my understanding of what naim are "claiming"(?)

 

enjoy

ken

Posted on: 02 August 2012 by Adam Meredith
Originally Posted by likesmusic:
.... As you can see on this thread, Naim are still standing by the claim that there is an audible difference between dBpoweramp rips and Naim rips, even if dBpoweramp rips are correct and bit identical to the Naim ones.

... as above, could you post a link to this claim? I missed it and you, obviously, will know where it occurs.

 

General query: - What is the benefit of Accuraterip if your software reports no errors in the rip process?

Posted on: 02 August 2012 by Phil Harris
Originally Posted by likesmusic:
Originally Posted by Simon-in-Suffolk:

 

I analyzed the files using specialist  debugging and data analysis software and the DATA chunk of the WAV file on all files was identical. That is every single  sample on each file of many tens of millions of them was identical. (and incidentally they sounded identical to). The length was identical. The sample data was absolutely identical, that is it was word perfect - rather than bit perfect. We put this to bed once and for all - thank goodness.

 

The issue has certainly not been put to bed once and for all.

 

 

 

It would appear not...

 

 

Originally Posted by likesmusic:
 

As you can see on this thread, Naim are still standing by the claim that there is an audible difference between dBpoweramp rips and Naim rips, even if dBpoweramp rips are correct and bit identical to the Naim ones.

 

 

 

No - I have not said that at all and there has been no further input from Paul on this who was quoted (in isolation) in the OPs original entry. (Paul is away on hoilday at the moment.)

 

 

Originally Posted by likesmusic:
 

While Naim keep that position, the issue will not go away.

 

 

 

No - it probably won't...

 

 

Originally Posted by likesmusic:
 

In earlier incarnations of this argument I can remember David Dever arguing dBpoweramp created different file headers and these in some way upset the Naim playback system. I believe Simon proved that these headers were absolutely within spec. 

 

 

 

Something being "within spec" is not the same as identical ...

 

Oddly for years it was argued that a WAV file and a FLAC file of the same track MUST sound the same as they decompress to the same data. I argued exactly the same with the guys here and I was proved, by my own ears, wrong - now it's fairly well accepted that if you get a device to decode a FLAC file then the actual process of decoding (and the extra computation involved) makes those files sound different and those differences are easy enough to spot to be able to tell a difference and to be able to reliably differentiate one file from the other if not to be able to say "that's the FLAC and that's the WAV". Not only that but FLAC files encoded to different levels of compression sound different due to the same phenomena.

 

We have people debating on here that different Ethernet cables make a difference to how a system sounds even though the data that passes through them is checksummed and error corrected - we can wireshark data transfers and see that there are no significant variations in the number of resent packets yet people still make this claim - should I dismiss this as hokum? As snake oil? Or should I remain open to someone who is actually willing to put their neck on the line and do a proper, blind, back to back test and prove me wrong or even make my mind up for myself?

 

Much as my core "techieness" tells me to dismiss the POSSIBILITY that two WAV files with identical data but slightly different headers can sound "different" and much as I couldn't tell the difference when I listened for myself that doesn't take away from the fact that a bunch of the R&D guys here were RELIABLY able to differentiate between IDENTICAL files but with headers generated by our own ripping engine and headers generated by dbPoweramp when they were doing the development of the DAC (i.e. being played back off a HDX via S/PDIF - this predated the ND and Uniti series products IIRC.) - they even hand generated files using the same identical source data to try to identify why it was at the time.

 

Now, I'm happy enough with my own system and I'm happy enough that I've reached the limits of what I can hear - so should I sit back and as a "techie" say that "bits are bits and that anyone who claims that changing their network cables makes a change in sound quality are insane"?

 

Should I dismiss any reviews of S/PDIF cables where the reviewers make distinctly analogue claims for the differences between one digital cable and another (i.e. "Cable x gives a greater solidity to the lower registers than cable y...") or reviews of HDMI cables where the reviewer claims that one cable "gives much finer detail" than another just because I don't perceive the same difference for myself and because my techie knowledge tells me that the cables are sending digital data and should either produce a valid datastream at the far end for decoding into audio or video otherwise nothing should appear as the random "noise" cannot be decoded into anything valid. To say that an HDMI lead "gives more natural greens" or whatever is a distinctly analogue judgement superimposed on a digital world however I don't presume to tell people what they can or can't hear - I'm happy to let people have their hobbies and accept that just perhaps I don't know or understand everything. (After all - some of my friends can't tell the difference between when I run stereo for movies and when I run full surround - maybe they think I'm insane?).

 

Possibly I take a strange view on things - after all I've been shot down on here previously for daring to suggest that someone went and actually auditioned a couple of different combinations of kit for themselves rather than having me telling them which one sounds better - maybe I've got the wrong idea of things ... after all, I always thought it was about listening to and enjoying the music...

 

Phil

Posted on: 02 August 2012 by Geoff P
Originally Posted by Adam Meredith:

 

General query: - What is the benefit of Accuraterip if your software reports no errors in the rip process?

Well when I rip a CD with dB poweramp it uses the Accurate rip database which is based both on error checks from the ripping process as it proceeds and a statistical  'error free' result based on an database of rips of said CD  made in the world at large . Sounds pretty close to beneficial and offers the opportunity to repeat the rip process in case of reported errors.

 

I am sure rip errors can occur due to the CD in question having faults such as scratches imperfect audio pits even greasy finger marks as well a Murphy's Law.

 

Err.... just out of interest how can Naim prove its rips are error free since there is no report to the user at all, coming from their US rips and presumably the CD faults and Murphy's law will apply equally to a Naim rip attempt as do to the likes of dB Poweramp.

 

Geoff

Posted on: 02 August 2012 by likesmusic

Phil - re your previous post - you are indeed standing by the claim that there is an audible difference between dBpoweramp rips and Naim rips even if dBpoweramp rips are correct and bit identical to Naim ones. In that same post you say that "a bunch of R&D guys here were RELIABLY able to differentiate between IDENTICAL files but with headersgenerated by our own ripping engines and headers generated by dBpoweramp".

 

If that isn't standing by the claim I don't know what is.

 

It is a great pity Naim equipment does a substandard job with other vendors absolutely competent rips.

 

Why didn't your engineers fix the problem in your equipment that gives rise to the difference?

 

I am amazed that you released a product with such a failing.

Posted on: 02 August 2012 by Phil Harris
Originally Posted by likesmusic:

Phil - re your previous post - you are indeed standing by the claim that there is an audible difference between dBpoweramp rips and Naim rips even if dBpoweramp rips are correct and bit identical to Naim ones. In that same post you say that "a bunch of R&D guys here were RELIABLY able to differentiate between IDENTICAL files but with headersgenerated by our own ripping engines and headers generated by dBpoweramp".

 

If that isn't standing by the claim I don't know what is.

 

It is a great pity Naim equipment does a substandard job with other vendors absolutely competent rips.

 

Why didn't your engineers fix the problem in your equipment that gives rise to the difference?

 

I am amazed that you released a product with such a failing.

 

Hi LM,

 

Nowhere in my replies did I state that a Naim rip always or inherently sounds better (or different) and I have consistently maintained that it is possible to get a bit perfect rip using ripping solutions other than our own if you are able to put together an appropriate platform.

 

I also very explicitly said that a group of our R&D engineers were able to differentiate between the two files  - I didn't say that one sounded worse or better than the other - and at the same time I have also stated very clearly that I cannot tell a difference myself and so therefore that discussion I leave to those more appropriate.

 

I am sorry if you feel that we do a substandard job with our products.

 

Best Regards

 

Phil

 

 

Posted on: 02 August 2012 by likesmusic
Originally Posted by Phil Harris:
 

 

Hi LM,

 

Nowhere in my replies did I state that a Naim rip always or inherently sounds better (or different)

 

...

 

I also very explicitly said that a group of our R&D engineers were able to differentiate between the two files  

 

..

 

Best Regards

 

Phil

 

 

 

You contradict yourself in successive sentences.

Posted on: 02 August 2012 by Phil Harris
Originally Posted by likesmusic:
Originally Posted by Phil Harris:
 

 

Hi LM,

 

Nowhere in my replies did I state that a Naim rip always or inherently sounds better (or different)

 

...

 

I also very explicitly said that a group of our R&D engineers were able to differentiate between the two files  

 

..

 

Best Regards

 

Phil

 

 

 

You contradict yourself in successive sentences.

 

You seem to forget to quote this bit ...

 

"I have also stated very clearly that I cannot tell a difference myself and so therefore that discussion I leave to those more appropriate."

 

Best Regards

 

Phil

Posted on: 02 August 2012 by Adam Meredith
Originally Posted by Geoff P:
Originally Posted by Adam Meredith:

 

General query: - What is the benefit of Accuraterip if your software reports no errors in the rip process?

Well when I rip a CD with dB poweramp it uses the Accurate rip database which is based both on error checks from the ripping process as it proceeds and a statistical  'error free' result based on an database of rips of said CD  made in the world at large . Sounds pretty close to beneficial and offers the opportunity to repeat the rip process in case of reported errors.

Is it possible that dBPoweramp could rip a disc, report no errors from the ripping process as it proceeds and yet be contradicted by Accuraterip database information?

 

Or does dBPoweramp not provide an accurate rip analysis - in the absence of Accuraterip information?

Posted on: 02 August 2012 by Guido Fawkes
Originally Posted by Geoff P:
Originally Posted by Adam Meredith:

 

General query: - What is the benefit of Accuraterip if your software reports no errors in the rip process?

 

Err.... just out of interest how can Naim prove its rips are error free since there is no report to the user at all, coming from their US rips and presumably the CD faults and Murphy's law will apply equally to a Naim rip attempt as do to the likes of dB Poweramp.

 

Geoff

Geoff

 

I guess we could argue about how do we know Accurate Rip is correct ... if is based on the results of the ripping engines we commonly use and they are all wrong then .... perhaps Naim is the only truth. 

 

What I would say is that the PCM data produced by Naim is the same as it is from any other reputable ripping engine given the CD is not badly damaged. So my argument is that the player cannot know what did the calculation if all it is told is the answer and if the Naim answer is the same as everybody else's then surely it must play the same. Of course, if one of their engineers play a file and then play it again then he or she may prefer one to the other, but to assert this is because of the way it was created is absurd in my view (I'm sure they don't really say that). 

 

Phil, I think, is implying that it makes no difference which ripping engine you use if the resultant output is the same. 

 

We all agree (I think) that replay is a different matter and a systems sound can change depending on factors like the mains supply, the temperature, RFI and .... 

 

I also think we all agree that US is a good piece of kit and does what it claims and has Naim service and support

 

So for the most part we are all in harmony on this matter. 

 

I, too, think Linn has the right approach to this topic and I don't for the life of me know why kit cannot be optimised for FLAC, which seems the most versatile format. Ideally, I want to forget about file formats and how it was ripped and just play thing in the knowledge that I'm getting the best sound I can. Linn said that on its kit there is no difference between formats or ripping methods .. the same PCM will sound the same. Psychologically this message works well for me.

 

All the best, Guy  

Posted on: 02 August 2012 by DQ

Like Simon et al, I am not sure I understand all the fuss here. This is all dealt with in other threads.

 

Phil said some engineers can hear a difference. He did not say that they found one superior to the other.

 

My own view is that Naim method is fail safe and that with other methods it is possible to make errors. I made mistakes early on and re-ripped 200 CDs as a result. It happens. I have learned and now reliably use DBPoweramp.

 

In comparing two bit perfect rips with different header/tag info (DBPoweramp vs Naim), I hear no difference, though some in my family claim they can. However, no-one claims superiority.

 

My main bugaboo with the Naim rips is the challenge of converting the metadata from WAV to other formats, nothing to do with the sound. If anyone has found a conversion engine that can read the Naim database files and reattach on conversion let me know.

 

Cheers, David

Posted on: 02 August 2012 by Geoff P
Originally Posted by Adam Meredith:
Originally Posted by Geoff P:
Originally Posted by Adam Meredith:

 

General query: - What is the benefit of Accuraterip if your software reports no errors in the rip process?

Well when I rip a CD with dB poweramp it uses the Accurate rip database which is based both on error checks from the ripping process as it proceeds and a statistical  'error free' result based on an database of rips of said CD  made in the world at large . Sounds pretty close to beneficial and offers the opportunity to repeat the rip process in case of reported errors.

Is it possible that dBPoweramp could rip a disc, report no errors from the ripping process as it proceeds and yet be contradicted by Accuraterip database information?

 

Or does dBPoweramp not provide an accurate rip analysis - in the absence of Accuraterip information?

Adam

 

I guess since as part of the ripping process the Accuraterip database is contacted and a checksum is compared for each track as it is ripped it is pretty unlikely that a contradictory report of 'no errors' would occur.

 

As I mentioned earlier I understand that dB Poweramp runs a calibration test on the CD drive and calculates an 'offset' to ensure the read of data from the drive is optimised before beginning the rip process. During the rip of a CD that is not in the Accuraterip database yet ( pretty rare ) the ripping process checksum is examined and assuming it shows successful error free ripping has occured, that goes into the Accuraterip database.

 

regards

Geoff

Posted on: 02 August 2012 by Geoff P
Guy

 

Yes indeed I think we are in harmony. I had already recognised that.

In my post above I was really just trying to answer Adam's question(s). 

 

regards

Geoff

Posted on: 02 August 2012 by Peter_RN
Originally Posted by Adam Meredith:
Originally Posted by Geoff P:
Originally Posted by Adam Meredith:

 

General query: - What is the benefit of Accuraterip if your software reports no errors in the rip process?

Well when I rip a CD with dB poweramp it uses the Accurate rip database which is based both on error checks from the ripping process as it proceeds and a statistical  'error free' result based on an database of rips of said CD  made in the world at large . Sounds pretty close to beneficial and offers the opportunity to repeat the rip process in case of reported errors.

Is it possible that dBPoweramp could rip a disc, report no errors from the ripping process as it proceeds and yet be contradicted by Accuraterip database information?

 

Or does dBPoweramp not provide an accurate rip analysis - in the absence of Accuraterip information?

 

Hello Adam

 

I don’t think so, as if a disc is not in the database Dbpoweramp will read the disc a minimum of twice, if the checksum is identical on both reads and it has not encountered any faulty frames then it will declare the rip ‘Secure’. This information can then be submitted to the database. If after two reads it has different checksums it will read it again, if it still has different checksums it will flag as ‘Insecure’, personally I have never encountered this although I have found even new CD’s with faulty frames. Dbp: is perfectly able to re-read faulty frames and recover the info and still end with a matching checksum to the database.

 

In answer to your other question it may be easier to paste part of Dbp: report where it encountered faulty frames on a track.

 

dBpoweramp Release 14.2 Digital Audio Extraction Log from 29 June 2012 08:09 AM

 

Drive & Settings

----------------

 

Ripping with drive 'E:   [HL-DT-ST - DVD-ROM GDR8161B]',  Drive offset: 102,  Overread Lead-in/out: No

AccurateRip: Active,  Using C2: Yes,  Cache: 1024 KB,  FUA Cache Invalidate: No

Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max

Ultra::  Vary Drive Speed: No,  Min Passes: 1,  Max Passes: 2,  Finish After Clean Passes: 1

Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 60

 

Encoder: Wave -compression="PCM"

DSP Effects / Actions: -dspeffect1="HDCD=" -dspeffect2="ReplayGain="

 

Extraction Log

 

Track 35:  Ripped LBA 302705 to 324033 (4:44) in 0:20. Filename: D:\Music Tracks\Mozart\Mozart; Così fan tutte [Gardiner] - CD 1\35 Mozart - Cosi fan tutte; Act One; N. 17 Aria; Un'aura amorosa del nostro tesoro.wav

  Insecure  [Pass 1, Ultra 1 to 1, Re-Rip 354 Frames]

  Insecure  [Pass 1, Ultra 1 to 1, Re-Rip 354 Frames]

  ** Aborted: Have to ReRip 354 Frames, Re-Rip Limit Set to 100 Frames

 

 

I have Dbp: set to abort if it finds more than 100 faulty frames on a track, as I have a second drive setup I simply swap the CD to this drive and copy the track again so end up with:

 

dBpoweramp Release 14.2 Digital Audio Extraction Log from 29 June 2012 08:18 AM

 

Drive & Settings

----------------

 

Ripping with drive 'H:   [HP       - DVD Writer 940d ]',  Drive offset: 6,  Overread Lead-in/out: No

AccurateRip: Active,  Using C2: No,  Cache: 1024 KB,  FUA Cache Invalidate: No

Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max

Ultra::  Vary Drive Speed: No,  Min Passes: 1,  Max Passes: 2,  Finish After Clean Passes: 1

Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 60

 

Encoder: Wave -compression="PCM"

DSP Effects / Actions: -dspeffect1="HDCD=" -dspeffect2="Audio CD - Hidden Track Silence Removal= -dbsilence={qt}-45{qt} -window={qt}4000{qt}" -dspeffect3="Audio CD - Silence Track Deletion= -dbsilence={qt}-45{qt}" -dspeffect4="ReplayGain="

 

Extraction Log

--------------

 

Track 35:  Ripped LBA 302705 to 324033 (4:44) in 0:09. Filename: D:\Music Tracks\Mozart\Mozart; Così fan tutte [Gardiner] - CD 1\35 Mozart - Cosi fan tutte; Act One; N. 17 Aria; Un'aura amorosa del nostro tesoro.wav

  AccurateRip: Accurate (confidence 2)     [Pass 1]

  CRC32: 1C3BB206     AccurateRip CRC: 714CE438 (CRCv2)     [DiscID: 035-005428e8-08123e2a-1510e023-35]

  AccurateRip Verified Confidence 2 [CRCv2 714ce438]

  AccurateRip Verified Confidence 2 [CRCv1 7f7f69f4]

  AccurateRip Verified Confidence 10 [CRCv1 e7451d93], Using Pressing Offset +801

 

This approach has never failed so far to obtain secure rips. Hope that helps.

 

Regards

Peter

 

Edit: Ah sorry Geoff, I took some time to write this post and you got in first.

Posted on: 02 August 2012 by Adam Meredith
Originally Posted by Geoff P:
Adam

 

I guess since as part of the ripping process the Accuraterip database is contacted and a checksum is compared for each track as it is ripped it is pretty unlikely that a contradictory report of 'no errors' would occur.

Geoff P & Peter_RN,

 

Thank you both for your information.

 

My query came from early days when Accuraterip was not available and EAC would go through re-reads until it convinced itself that the rip was good - or report an error.

 

I used dB P recently and wasn't sure how Accu... was used to aid the rip. It appears that Accu ...acts as a repository of accurate checksums - allowing each track to be ripped and confirmation being given by reference to this external check. Presumably this speeds things up although can give no more accuracy than EAC checking itself. In either case any errors found will be reported.

 

By the way - I liked dB P for its ease of use and access to cover art and tags. EAC (recent release) seemed to have gone up a strange path and lost me.

Posted on: 02 August 2012 by garyi

The beauty of the system is it will play all these files. So why not make your own mind up?

 

Its not as if the naim system will refuse to play your other rips. Surely it just gives you a whole load of other things to lay awake at night over. It will make cables and hifi racks appear so 1990s

Posted on: 02 August 2012 by Simon-in-Suffolk

Honestly what a load of rubbish.  Data streaming and audio data  transmission is a big part of what as I design and debug as a professional engineer, and the wavs that's are ripped and analyzed by myself and posted on here for all to see all had identical data chunks.. Period. There was no  difference in the data at all. If any one wants to believe otherwise  I can't argue, but pleasedon't delude yourself that it is based on reality. True engineers share their  findings for peer review, and I have seen no alternate evidence to the contrary to that  i posted on this very forum using analysis i did willingly in my own time last year. So I say put up or shutup.

 

This sort of  irrational nonsense is probably a right turn off to people looking at streaming and ripping and makes home networks look like a walk in the park.

This has been put to bed, if you want to wake it up again without firm clear reviewable evidence  and  have fantasies about it please don't wake the rest of us, many of us have moved on.... 

Simon

Posted on: 03 August 2012 by likesmusic
Originally Posted by Simon-in-Suffolk:

So I say put up or shutup.

 

This has been put to bed, if you want to wake it up again without firm clear reviewable evidence  and  have fantasies about it please don't wake the rest of us, many of us have moved on.... 

 

Simon

The issue has not been put to bed. Paul Stephenson has not withdrawn his statements. Phil renews the claim on this thread that Naim engineers can hear differences between Naim and dBpoweramp rips, and implies that this is caused by differences in file headers. I would say the issue is still awake.