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

There are many possibilities for two files sounding different, perhaps they were being played from different memory sticks via the USB inputs (and it has been discussed on here before that different memory sticks can sound different due to their differing EMC characteristics), however, as it wasn't really important at the time then it was never fully investigated.

(Perhaps you would care to try this for yourself and see? Your input into this discussion is more than welcome.)

As such we have never made any specific claims that a bit perfect rip taken from one of our servers sounds BETTER than a bit perfect rip taken from any other source. Pauls statement was that our ripps generally sound better - I think that we can validly stand by this as our platform has been optimised to produce the best rip possible and therefore it should equal or better the results from other platforms. 

Cheers

Phil

Right  I completely accept  WAV files can sound different depending on how they are *parsed and played back* - for a whole host of reasons including my favourite EMI and RFI. However for the benefit those still following this thread, this is quite different from how they ripped and the integrity of the rip which is the matter as far as I am concerned  that has been put to bed. No problem with this at all - and my expierience bears this out as with for most people.

Likesmusic if you search back - you will see that I decoded the headers of an EAC, DBPoweramp, a Naim WAV and an Itunes wav. At the time itunes used the old canconical header (developed in the 1980s) and the dBPoweramp and Naim used the extensible header that is better suited to multicahnnel and hidef. The last two headers were identical apart from two obseravations. (i honestly cant remember what EAC had..)

The overall length value of RIFF fiile chunk with dbpoweramp that encapsulates all chunks including the sample DATA chunk  was margianlly longer, (as DBPoweramp uses info chunks and a bespoke 'ID3' chunk, both at the end of the wav file).

The Naim header at the time seemed to have an anomolie of a single padded 0Hex byte at the end of the  header. All lengths were valid however, so might have been a 'feature' that has since been removed.

However the values and constructs in the header itself were all identical - no difference at all. The DATA chunks were also identical in length and in values. 

I must admit I can't find any statement from Paul Stephenson or others saying there are unique type / value pairs in the Naim header. It is, or was when I checked last year, clearly not the case

Simon

> As such we have never made any specific claims that a bit perfect rip taken from one of our servers sounds BETTER than a bit perfect rip taken from any other source.

Phil I think that should be the definitive statement. 

I think people can rest easy with that knowing rips they have made with their Mac or PC or US will all give first class results and as long as they are bit perfect will all sound the same when played back through the same system. 

I'm sure Paul only meant that as Naim sets up its ripping engine for you and gets it right then it will be better than one somebody has not been able to set up correctly and is therefore not making bit perfect rips (e.g. inadvertently setting iTunes to rip to MP3). 

My view is that ripping is easy and a Mac can do it as well (not better) as anything for a standard undamaged CD. Nothing special is required. 

I like the idea that a ripping solution should report back to the user if the rip was unsuccessful ... but otherwise they are all much or a muchness. 

As someone who has never checked a "ripped" file for its accuracy, but has rejected a CD after ripping, deleted the rip, bought a new copy and then ripped that, I think this is an interesting topic to read about from the perspective of a top manufacturer as much as anything else.

To my mind, the importance of a precisely unchanged file is crucial at the mastering stage, and of course when a master may be cloned so that it could be pressed for CD in different territories.

But surely the slight differences that people claim to hear between different rips are vastly less significant either than the quality of the music contained or as a secondary consideration the quality of the actual version of the recording contained in the CD.

What always tickles me about this is that with LPs the differences between different [vintage] pressings and different turntable arrangements is discussed with glee and the differences not being regarded as a sign that the LP medium really does have audible flaws. If there were none with vinyl then all records and turntables would sound identical on any given recording!

But with digital the differences, where they can be perceived at all, are taken as being quite serious!

To my mind, if a rip sounds fine, then it is fine - bit perfect or not!

The quality of the DAC and subsequent analogue signal handling is vastly more significant and is clearly audible in my experience.

ATB from George 

Very true George

I think our main point in this thread was to dispel the myths that led to some poor soul re-ripping 5000 CDs ... a strange belief that you can improve the sound with a magic ripper ... but legend days are over and now everything is different 

It would be interesting to know what exactly compelled this guy to re-rip.  I can only assume he did something very wrong, because as you say Guido, it just isn't that hard to get bit-perfect rips.

Or, to put it more accurately, if one uses a ripper that supports Illustrate's Accuraterip, you can easily enable enough error checking to make sure that your rips look like exactly like those that the vast majority of owners agree are, in fact...bit-perfect. 

For those who have ripped a lot of CD's without checking the Accuraterip database, there is a tool from Illustrate called "perfecttunes".  It can be downloaded from the dbpoweramp web site, and it will check any rip -- even those made by a US or HDX  -- for accuracy.

Hook

I have been looking at this site:

http://flac.sourceforge.net/index.html

and came across this in the FAQ section:

Why doesn't the same file compressed on different machines with the same options yield the same FLAC file?

It's not supposed to, and neither does it mean either encoding was bad. There are many variations between different machines or even different builds of flac on the same machine that can lead to small differences in the FLAC file, even if they have the exact same final size. This is normal.

I assume that the authors of this website are the "FLAC" people themselves - how does this stack up with what everyone has been discussing here?

I have followed this topic with great interest, because I have realized that I need to rip my CDs, but I am not sure what format to choose, and what type of device I should store them on, and allow for the mobility of moving them to a higher level Naim-type solution (e.g., HDX, US, or whatever if/when the time comes...or better, if/when the $ comes.)

I will have more questions for the experts later, but they will likely be on a separate thread when I have more of a grip on the topic so I can ask as expediently as possible.

copy a well known album on two identical sticks one flac one wav play through nds 5 and direct into dac result no difference in sound quality . ndac used has the hub in both cases. ndac as power supply.. try it

DrMark,

I will try and help...

FLAC uses a non lossy compression algorithm (a bit like ZIP files for computer software). There are Mutiple way to compress the file as chosen by the algorithm, ie there isnt a unique compression for each file, BUT when expanded it will provide the original uncompressed sample data. Therefore FLAC files of an identical sample file can look different, but the decoded uncompressed FLAC files all look the same again.

Your question on what to rip to? Really you can use any non lossy format, and a format that uses metadata to store the attributes of the media/artist etc.

Therefore valid options are WAV, ALAC, FLAC and AIF.

Somepeople say WAV doesn't support metadata, which confusingly is incorrect. WAV supports an industry standard LIST INFO method and an unofficial consumer oriented ID3 method. Most rippers (excluding Naim and iTunes) create the metadata in WAV files. ALAC, FLAC and AIF use the ID3 method. iTunes has only partial support for WAV files. If iTunes is important to you, you might want to avoid WAV.

I use a mixture of 90% WAV and 10% FLAC, but tell my streamer server to transcode on the fly to WAV, if not already, for my Naim and MP3 for my mobile wifi network players scattered around the house.

I transcode everything to WAV for Naim, not because I need to, but because I prefer the sound that way.. It's a personal thing.

Finally once you have ripped to a lossless format you have created a backup of your CD, and you can convert to another format if you ever want to for some teason without loss of info without having to re rip,  there are several softwaretools for this. The comment about that bizarre behaviour of that person re ripping 5000 CDs is really unexplainable and is probably more to do with  the individual rather than the rips. Try not to let it spook you.

Regards

Simon

Rich I have tried, many times and with different FLAC compression settings other than 0, and I do hear a difference and I honestly prefer the WAV rendition of the track It sounds more natural, analogue and appealing. This has been the same for NDS, NDX and nDAC.

With the NDS memory stick expierience I was with several people in the room that all agreed with this, ( they didn't know what was FLAC or WAV before hand) so I can say confidentially I am not unique here.

Anyway I have made this matter redundant by simply  transcoding on the fly from my upnp/DLNA server. It simply is not an issue any more for me.

Simon

I still don't get this.

Is it, therefore, possible to rip a CD (without the use of Accuraterip) with a report of "No Errors" and then check against the Accuraterip database and be informed of an error?

If it is - then rips (without the use of Accuraterip) reported as error-free can be misreported.

If it isn't - then Accuraterip provides nothing extra. Apart from unnecessary reassurance.

Adam,

These resources such as Accuraterip really come into thier own for damaged discs or very long audio CDs outside Redbook which is quite common. Certainly for a damaged disc there is sometimes no reliable way of knowing whether the data is correctly recovered. Many rippers use a brute force method and try mutiplestrategies of reading the data and checking for consistency. The Accuraterip allows a third part reference if you like and it usually helps speed up the process by avoiding unnecessary re rips or at least confirming what you have recovered might not be fully error free. Also if the high speed rip throws up a variance to the Accuraterip value, then a slower re rip is executed to check for correlation.

Accuraterip simply provides a confidence response; that is the number of independent rips that correlate. If you match then there is an increased chance of an error free rip. the Accuraterip database also provides a database on the reliability of CDROMs across the market based on acuraterip lookups.

I personally think its a great system and really speeds up the ripping process which lets face it is a bit of a bore.

Simon

But if many people report their rip with the same hash, than those rips are more likely to be correct than the rips with a different hash.

It is all in the numbers of reported rips. If only one other rip of that CD has been reported than the reliability of the comparison is not as high as when hundreds of people have reported their rip of that same CD.

-

aleg

This continues to bother me.

I rip an undamaged CD - the rip is 'perfect' - the software reports 'No Errors'. Accuraterip, redundantly, pats me on the back.

I rip a damaged disc - the rip software has difficulty knowing whether the end result is correct. The result is compared against result/results in Accuraterip.

How likely is to be that the ripping software is able to create an accurate rip, among an infinite number of incorrect ones, if it isn't directed by its own ripping/correction/validation logic?

I suppose it rips "as best it can", can't tell if the result was any good and seeks validation from Accur.... It just seems unlikely that it can both produce an accurate rip AND be incapable of self-validating. If it cannot self-validate then what logic did it use to direct its rip?

As Simon explains, a CD rip in a CD ROM drive is not a single 'read' across the surface of the CD but a multiple 'read' process as a minimum, to check that read repeatability is occurring, which could be viewed as the first level of protection against read errors. 

As Aleg points out assuming all goes well with this check process, in dB Poweramp for example, the checksum of the rip is offered to the Accuraterip database and gets compared to whatever values are already in the database and added in if it matches. 

In the rare event, which is a circumstance that will have the same effect across different rip hardwares, that a CD just won't rip repeatably, at least it is flagged up for the user to decide what to do, by these processes.

We are of course debating here and comparing 'Bit Perfect' ripping which we agree is obtainable for us virtually all the time.

However there will always be the occasional CD that just won't rip right, even if you try several drives, polishing its surface, etc. Often you can hear the CD Drive working overtime as it attempts to re-rip and re-rip over and over again. In the end you may get a set of tracks off the CD after a very elongated attempt which have red error codes against them because the re-rip attempts just don't agree. Regardless of this they may not be 'trash' from an audio point of view. I have a few offenders like this that I stored anyway thinking what the hell its only a bit of NAS space which I can delete. Low and behold they sound just as good as similar music which has been patted on the back as being bit-perfect.

Incidentally I decided from a few test rips for the same reasons as Simon that I would rip to WAV and then I could create converted files in FLAC and MP3 as it took my fancy. Happy with that. 

Interestingly for folk that have a substantial CD collection one of the facts of life is you are going to need serious storage space. For example I have 45,000 + tracks, quite a few of which are HiDef, and have used up over 2 TB of disc space already. I think more and more people are going to have to come to terms with setting up a NAS ( the latest US would be too small for me without a NAS).

Fear not though it is not like climbing Everest just a matter of investing in decent hardware such as a 'real' router, wired connections, a multi disk NAS and a STURDY BACKUP strategy. If you buy that locally to you, you can likely get the hardware seller to set it up for you if you ask nicely.

Geoff

HELP!

We have (no) argument as to whether 2 identical files can sound different and now you suggest that 2 different files can sound identical.
To clarify - your 'trash' track (flagged as containing errors) and the same track ripped and 'patted on the back'.

I suspect my original difficulty arises from a glitch in perceived logic - a glitch only troubling to me.

You all seem to be saying that CD ripper software is not necessarily capable of knowing if it has produced a 'bit perfect' copy - that 'true' validation comes from comparison against a consensus (of equally unself-validated rips).

If so - then it WOULD make, a sad, sense to re-rip rips made without Accuraterip as you, apparently, couldn't be sure they were bit perfect.

i do the same simon, is there a difference maybe. this reminds me on vinyl in the 70s with regard to tracking and vta.  we decide then listen to the music.   and that is what is important.   i rarely listen to cds ,never did like them.

Adam

One reason two different files could sound identical  Is when there is only a difference in offset, a hardware dependent parameter in ripping, and no difference in databits that it has read. The effect would be it starts its reading/writing a few samples too late, but creating on bit level a different file.

-

Aleg

Use perfecttunes to check previously made rips.  Then you need only re-rip those that fail the test.  Or even smarter, re-rip only those that fail and also sound bad to you.

I have not heard anyone say that a rip that fails verification will actually sound bad, or even different from, one that passes.  I imagine that depends on just how imperfect the rip really is....

Hook

Ok guys, here's a challenge... We select a track that we all agree via whatever mechanism is 'bit perfect'. We then deliberately flip one bit - lets say the least significant bit on one sample on one channel. So we now have a file that is no longer 'bit perfect' cos we deliberately corrupted it....

Bet nobody could hear the difference 

Now Dave...don't tempt Simon!  With his knowledge of the internal data structures, he is likely to find the one bit that does matter! 

Hook

Hi Adam

In my first post in this thread I posed the question:

How does anyone know that they have a bit perfect rip of a piece of music regardless of the method used to produce the rip?

This wasn’t intended as a flippant question as I too see the same or similar issues to those you raise.

However, when I started ripping I began using EAC, as my be obvious I have little knowledge of these things compared to many here so found the program far to complicated to accurately setup myself, I accepted its offer to set itself up.

Following a problem with my NAS recently I decided that I had to reinstall the firmware and copy my files back onto it, however I decided I would re-rip those file that I had ripped using EAC prior to finding Dbpoweramp which I found simplicity itself to setup following Mr Spoon’s Guide.

I was frankly staggered at the number of tracks that were reported as faulty, although by using the combination of two drives to rip I managed to end up with ever track copied accurately according to the AccurateRip database. My point is I am not sure that I can tell you that I can definitely hear an improvement; I don’t have the original files anymore.

I can say that we defiantly prefer the rip’s to listening to the CD directly, having seen that some even new CD’s have faulty frames I am not surprised that this should be the case, after all the CD player only gets one chance to read the data.

Regards

Peter

Ah, yes Hook, but it has to be a bit in the data chunk, no messing with header bits which could certainly screw things up.

WHOA Adam !!!

I said in the quote above SIMILAR MUSIC not the same track. That is an important difference to what you thought I said.

All i was trying to say is that when an occasional errant CD refuses to rip smoothly and has errors reported for the rip process it doesn't mean it is automatically 'trash' from an audio listening point of view. It is worth having a listen to the files because even with errors the audio can sound pretty good.

In reality that is often what happens on a CD Player which is much more prone to read errors since it is a real time process which can't go back and re-read a lot of times if things aren't quite perfectly read. on the fly.

Geoff