Naim rip vs PC rip

>>>Simon - I am still trying to understand your last post.  I think you are saying that it is possible, in theory, for a Naim network player to make good use of WAV extended header information, but that there is nothing unique to Naim in that extended header, and that the exact same information could be provided by dBpoweramp.   Is that correct?

Hook yes that is exactly what I meant.

Thanks

Simon

Not likely–like music, not busy work. Let 'em fix it at their own schedule.

http://icculus.org/SDL_sound/d...ntation/wavecomp.htm

The fact chunk is not required for WAVE_FORMAT_PCM but is good practice in a properly-formed file, inasmuch as there are a variety of compression types possible within the containerized RIFF WAVE file.

This same data contains information about block alignment, data rate, and other useful information–for example, if the sample rate is explicitly set to a value not supported by the output chipset, the server might re-sample this to 44.1 kHz.

See also

http://netghost.narod.ru/gff/v.../micriff/ms_riff.txt

Dave, I think you might be getting confused with the FMT chunk (format header chunk). That contains the extensible header info. The FMT chunk can precede or come after the data chunk, but it is common programming practice to precede the data chunk, and in all the WAV files I looked at FMT chunk appeared before the data chunk.

The Fact chunk is used when there is compressed data types in the WAV file, or the uncompressed PCM is broken up into Wave list chunks. However this use appears quite contentious and scorned by many programmers. It contains info pertinent to the compressed or wave list data, but is separate from the header info which contains info about the sample data.

http://www.sonicspot.com/guide/wavefiles.html#fmt

Here is an example of WAV files contructs with different fmt chunks for basic header, extensible and compressed data headers.

It also points out that the example Microsoft PCM wav files do not have fact chunks, and for PCM it would contain redundant sample length info.

http://www-mmsp.ece.mcgill.ca/...rmats/wave/wave.html

Simon

Fact Chunk is required if Wave List Chunk is used in tandem with Silent Chunk to append silence to beginning and end of file, e.g., for gapless playback via additive pre-roll / post-roll crossfade of the length defined by the Silent Chunk.

You're absolutely right about Format Chunk.

Commenting on earlier posts, put simply if there was a flaw in the DBpoweramp format chunk (header) it would most likely not even play back on other players or sound very wrong. I have seen nothing wrong with DBpoweramp headers (or iTunes and EAC come to that ) and there are tools (that I have posted before) that validate this info looking for errors.

The fact chunk is a red herring. It has nothing to do with the header chunk and Iit is not needed for PCM, it makes no difference to the construct of the sample data (other than splitting into shorter PCM segments/chunks if used for PCM, which for CD rips, or music audio files I can't see a sensible use)  and therefore unlikely to affect sound quality in a moderately well designed receiver.  If one wanted to hard encode gapless playback, I would encode all segments as a single PCM data chunk and use the cue chunk mechanism, which I think is what several professional audio editing applications do.

I think it is down to Naim to do the fixing .. or you to make it clear what you believe is incorrect about the dBpoweramp headers. As it stands Naim players apparently can't correctly play bit-correct rips from dBpoweramp. What precisely is the 'flaw' in dBpoweramp rips' headers that you allude to?

Surely if Naim have an error in their WAV encoding process they should fix it urgently.. Assuming there is an error of course, but I have to admit I think I would want some clarification from Naim before I spent a lot of time ripping CDs using Naim equipment given previous posts. Alas I have deleted the Naim WAV files I had when auditioning the US and HDX, otherwise I would parse them myself to see if there are errors (which I tend to think is unlikely).

I wonder if all this talk of possible errors is to cause FUD (fear, uncertainty, doubt) to create an illusion of difference when none exists. But either way all this uncertainty can't be healthy for those who are not technical and wish to get into file playback/ streaming audio with Naim.

Simon

I think if Naim has an error in their WAV process which -- as we all know -- produced a very pleasant effect in several listening sessions, this could be quite a revelation and can be easily capitalized in future Naim players 

David, many thanks for bringing this "Naim rip" issue up on the surface.

I'm still interested to hear the end of this story!

I agree that enjoying the music is all that matters after all.

I shall possibly borrow US one day again and check if it really rips better 

Dave - totally agree, I did exactly that I could not hear any difference at all (between dbPoweramp and Naim) and subsequent examination by Jack and myself showed the data chunk (and clearly therefore the header) had no difference at the byte level in the data chunk (at least for the initial part of the data)  hence why I think this is a little bit of a game of smoke and mirrors which I find irritating and must be off putting for thoe who rely on others to understand this technology.

Simon

Simon....I like your FUD reference

I'm listening to the Naim rip and the EAC rip that we looked at in the previous thread playing through NDX......no difference whatsoever in SQ IMO.

+1.

Dear Simon,

Thx for your patience and hard work.

I too hear no difference between my Rubyripper rips and my NS01 rips.

I DO hear a difference between flac and wav, depending on which digital interconnect I use.

I do like the convenience of the Naim ripping solution.

I do not think that Naim will clarify, as you stated 'smoke and mirrors', IMO too.

M

I'm getting a little lost on the thread here. Are naim claiming that its rips sound better? If so, how is this so, if the data is the same as other rips?

Hi Jon, the somewhat enigmatic comments from Naim on this thread

https://forums.naimaudio.com/di...ent/3960068604537349

could infer that Naim rips outperform other rips. However why this should be the case is not offered, and therefore some of us have physically inspected different WAV files from different rippers including Naim and found, surprise, no differences in the PCM sample data.
Simon

Ah right.

The nonlinear device (ear) coupled to the magnificently unreliable supercomputer (brain) is capable of convincing itself of all sorts of things, both wilfully and unwittingly. And those who diss AB and/or ABX comparisons have almost never done them properly. 1Hz at 1KHz pitch differences can be clearly audible, and statistically proven, when presented in a properly run AB test. As can 0.15dB level differences. 

regarding that thread... i think that when Paul says yes the files are identical but the sound is not - it is exactly that combination of s/w and h/w he is talking about 

I think Phil Harris summed it up correctly......

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...

A bit perfect RIP in EAC and a bit perfect RIP from Naim sound the same in my experience and that of many others. Unlikely to ever have consensus on this issue, listen for yourself.  

David Dever, part of Naim's US distribution, quite clearly says earlier on this thread that he and others can hear a difference between UnitiServe rips and dBpoweramp rips, and this is not confined to Naim players:

..the same difference can be heard on a Linn DS system–therefore it is not player-dependent, but file dependent (header + data). And I'm not the only person who can hear the difference.

Likesmusic

I guess from a copyright perspective then I shouldn't be providing copies of rips, however, in the interests of this discussion if you can provide somewhere for me to host the data I will post two rips for comparison.

I have compared CD rips made with a HDX and CD rips made with my PC using dBpoweramp and a dedicated Plextor CD-ROM drive (Plexwriter Premium 2) and all I can say is that they sound the same when I copied them on a USB stick and listened to them via the Naim DAC. One just need to get the settings for the ripping software right and voila The same test the other way around gave the same results when I copied HDX rips and PC rips to a Mobile Fidelity Sound Lab CD-R using Plex Tools Professional: Same sound quality. Therefore I am very convinced that Naim did not find the one and only holy grail of CD ripping. Not a joke at all: I can easily hear a different sound quality with different USB memory sticks used with the Naim DAC and I can easily hear whether it is FLAC or WAV in a direct comparison, but I can not hear a difference with HDX rips to PC rips. In case you can hear a difference I would suggest to check the settings with your ripping software.

Likesmusic

I suspect you might agree with me this talk of wav header flaws is ridiculous without stating what is flawed or being enigmatic about it. I have parsed the dBpoweramp wav files though an integrity checker and there was no issue in the header shown. If there were I would expect it sounds very wrong or not playable.

I really think that anyone who says anything is flawed they need to put up or shut up if they are to be taken seriously.. otherwise Smoke and Mirrors and pure mischief making.

Therefore to anyone who says a particular Extensible header format is flawed - such as used by Naim and dBpoweramp, show us... we are lets say .. intriqued....

..

Consider sampled data with the following parameters,

• N_cchannels
• The total number of blocks is N_s. Each block consists of N_csamples.
• Sampling rate F(blocks per second)
• Each sample is M bytes long

Extensible Format

Therefore which of these is wrong? Anything funfamental would render the sample data unreadable.. items like padding could be wrong but is not going to affect sound quality until the very end of the sample for one sample!!, and as we have discussed elsewhere the fact chunk is redundnat with PCM data chunks and again no affect on SQ.

+ 1 Put up or shut up.

In general you should always be critical to whatever a salesperson is trying to convince you about, I mean they do their best trying to sell as many units as possible and I would do the same.

In this case I would have liked Naim to simply state that their US/HDX ripping process is a very easy to set up and controlled method for ripping your cd's. That's a good sales argument, and it should end there unless there is something that is yet to be disclosed about their process that affects SQ. Assuming (as others claim) that PCM data is equal I would think it was in Naims interest to publish what header information improve SQ to make sure other rips played on Naim streamers sound just as good as their own.