Compression Level in FLAC
Posted by: Rockingdoc on 29 January 2011
My problem with AccurateRip is that it compares a checksum of your rip with a checksum of the same song that is 'widely accepted'. Thing is why do my AccurateRip verified rips still do not sound *quite* as good as the original CD? I've been using EAC which incorporates AR - and while the results are very good they are a bit *harsh* sounding to the CD direct.
My point is that to me things like AccurateRip do not make ripping an exact science if my ears are anything to go by.
I know everyone espouses it - even Linn, but I don't understand how this can technically be used as a benchmark. Truth is the only 'accurate' rip is the CD itself, and reproducing it digitally to a level which your ears are happy with is a good rip.
However, I just want to point out whatever the cause cd sounds better, it is never because CD is the most accurate read. It is not. I think this is an idea that was bought over from your perception from an analog disc.
For CDs, ripping the data to a harddisk will give you more accurate readout than reading the cd itself.
It is because when you rip to cd, a good ripping program can be set to reread and verify it's rip. So even without accute-rip, your rip version is actually read and re-read until it is exact copy(well, or till the program tells you your disc is dead and can never be accurate.)
This is in fact more accurate and indeed the optimal accuracy your cd transport is trying to match (but can actually fail). This is because your transport has no luxury if time to reread and instead must be read once and make the best guess on that 1 read.
Even reading is 99.999% accurate, your transport is still getting 1 bit error out of 100,000 bits. With sound at 16 bit x 44,100 every second, your cd on average of 7 bit reading error every second. I do not see how this can ever match the accuracy of a properly ripped file ever.
So whatever reason you are getting a better sound, I highly doubt it is from accuracy of reading the data. It is more likely due to the different path the signal goes through to Dax, and any different in interference/crosstalk whatsoever from this difference in flow...
I know different CD pressings can have different checksums etc but it is a good method of ensuring you have extracted the data accurately off the CD, or at least as accurately as everyone else by comparing the checksum gained by other people. However the comparison is absolute - not a measure of proximity to the checksum, so statistically multiple matches of an incorrect checksum is technically possible but extremely unlikely, and the more matches you have the more unlikely it is to be incorrect.
The only weakness I am aware off is when I rip CDs like the Mojo cover CD, the AccurateRip checksum is not yet available - so I need to ensure I have a good ripping process to start with.
I think more variation of perceived difference in audio is how the PCM is packaged up and sent to the DAC or stored as wave file etc.
Simon
>For CDs, ripping the data to a harddisk will give you more accurate readout than reading the cd itself.
This is questionable other than in a brute force point of view, implying if you read an error often enough you could clear it.
CD Red book has superb error detection and more important error recovery using two level of cross interleved Reed-Solomon code, and one of the CIRC is time shifted. This provides a fantastic means of data resilience and data recovery within the stored media with the over head of additional storage. Effectively the PCM data is diced up when stored on the CD and when recovered the data is recovered from multiple parts of the CD at once - thereby aiding error detection and recovery. For archiving puposes therefore CD is a good format. A hard disk however typically does not have this degree of CIRC so if an error occures it is statisitically less likely of being able to recover it, which is why RAID disks are used to accurately store and recover data through striping and mirroring of mutiple disks. This allows a degree of error detection and recovery using multiple discs to aid data recovery. However often this is beyond our consumer setups and so CD can be a better archiving foramt to use in this regard...
Simon
1) This is an inequality Reading from a verified RIP file >= Reading from CD. As far as I know, Ripping not only reread the CD, it also take advantage of the same Red Book error recovery procedure. The recovery procedure is up to a limit (I think 2 bit or so error?) Anything more than that will not be useful. Re-reading and then also accurate-rip comparing is going to get a more stable and correct read, only possibly in the exception of the case where, when the bit should actually be the opposite of the re-read, which in any case, will not make the CD magically more readable when it is read by the CD transport which has only 1 chance to make the best guess on the bit?
2) Well, if a bit is shifted, the Naim forum server containing our writing here would sometimes be read bit shifted (e.g. perhaps "CD" would suddenly be load up as "CE"?) In fact this never happens.
I am referring to the HD's remarkable engineering where you don't get your data file wrong from it (well, unless the HD crashes?). So in this specific application of replaying audio, I see HD is more reliable of the 2 medium given the way the PCM are delivered to a music system like UNITI. Actually I should say that, if the files are stored in a 24x CD rom drive and the music server is UPNPing the music data to a NaimUniti, then perhaps the CD reading from there would be more likely to be bit-perfect when compared with the HD rip. You see my point?
3) I don't know if what you say about CD is correct, but personally I never make my backups on CDs, I always use Raid + Backup HD. I have met so many dead CDs in the past to suggest otherwise.
Anyways, it is nice to have alternative opinion as it really give me more thoughts than I otherwise would think of.
...because they are, in fact, two different files, with different playback processing required.
Let's see if I get this right:
- Linn DS units sound different when playing FLAC vs WAV (confirmed)
- Naim servers rip to WAV (uncompressed PCM), but do NOT use AccurateRip
- Keith Johnson / Reference Recordings utilize WAV on their releases for best quality
Do you have any measurements to support your earlier suggestion that the different CPU loads affect the power supply to the DAC or clock in a DS? Linn cannot detect any difference down to the limits of measurement. Have you made any measurements yourself, or are you just speculating?
Accuraterip verified rips of Naim CDs have the same checksum as the same files downloaded from the Naim store. Does a Naim server get a different rip?
Lhau
Good points - let me respond:
Point 1) Raw CD has an error rate of 1e10-6 and with Red Book error detection and recovery its error rate goes to approx 1e10-12, ie that is one error in one thousand billion, which another way of looking at it is approximately one person out of a population of 160 planet Earths. Therefore the chance of seeing any error unless the media was always faulty or damaged is well pretty remote.. As far as recovery and the number of bits, well its a 2 dimensional reed solomon matrix with interleaving, so the recovery of data depends on the distribution of the errors, and is optimised for burst errors recovery. Errors are far more likely through damage or faulty pressing.
EDIT: I have looked at Seagates latest stats and it would appear they have an unrecoverable error rate of 1 Sector per 1e10+16 bits read, at 512kbytes per sector, therefore the chance of unrecoverable data is less than CD, but the impact of lost data is far greater at 512kbytes - which is a large amount of data to lose as opposed to the CD Redbook which has a minimum addressable area of 1176 * 16 bit samples or 1/75 second of audio data.
Point2) I didn't quite get the point of bit shifting, an error on the disk would result in a data checksum error and if mirroring was in use would be flagged and corrected from the good mirror copy (or striping would aim to recover the error). If there was no backup you would see the error bad file which is uncommon but not enheard of. Finally you mention the PCM - but this is higher up the 'protocol' stack at the applcaition layer- we are down at the physical and framing layers - so they are ultimately conected but are two distinct areas. The job of the supporting layers is to provide an accurate reliable copy of the payload - ie the PCM. I think we are discussing the merrits or otherwsie of the different supporting layers that carry that PCM payload?
Point 3) first - I always try and backup my hard disks at home to CD/DVD, or recently a mirrored disk system. I have learnt the hardway with failed disks, and have lost a few of my professional photograph scans - at least I still have the postives and negatives. The characterisitc of hard disk is often before it fails the rate of failures increase until catostrophic failure, and disk management subsystems look out for these tell tell sign to advise of this before the device fails completely.
Other than through self inflicted damage I have not had a catostrophic failure of a CD/DVD hence my point on archiving, but I do admit hard disk is a lot more convienient... hence why I do use a mirrored fisk for enything that is not really precious to me.
Cheers
Simon
Always from the same Linn KDS review: "... the Linn guys who came to install their Klimax. Based also on their boss Ivor’s opinion, they were convinced that properly executed FLAC files played back with a decent player offer sound as good as WAV."
Also: "So I decided to put this to the test over the Klimax with hi-rez 24/192 material. The file was big and this particular music would have been a real challenge for any player. To be honest I thought that the FLAC version sounded better – the cymbals were better differentiated and the saxophone sounded less nasal. Again the differences were very small but each time I listened to this particular piece of music (and I listened several times), I had the same impression – the WAV files were a bit lifeless. That would have supported Linn's opinion. Before I could declare this universal truth, I would have to listen to the same files using different players. But for the Linn Klimax DS it was a fact – I’d chose FLAC over WAV."
Even though the "universal" fact that Flac requires more overhead (in terms of CPU, memory or A/C consumption) it may well be true that the Linn KDS may be designed in such a way to minimize or even optimize Flac sonic playback. I must admit that I was rather impressed when I saw the pictures of the internals of the KDS; excellent seperation and "protection" of the different phases inside the chasis !
Ok, I am not that technical.
My theory on #2 is this, I either get my file verbatim bit by bit (like I never see my Word file with information changed), I know there are a lot of checksum, data recovery underneath this perfection from the hard disk medium, hard disk controller, file system, operating system etc. to enable this. I have no full understanding of that, but I do believe the sum of all these in the advance of computing is the end result: we always get bit perfect data from our healthy hard-disk?
So base on my observation on #2, I thought it was logical to point out to the other Naimee here that, if he hear a difference from playing CD in a CD player vs playing a lose-less rip on a harddisk, whatever the reason for the difference, it is definitely (or more conservatively: almost certainly) NOT because reading from the CD in a CD player is more accurate then reading a hard-disk file?
I believe we do agree this point?
So the search for the reason and a way to perfect the sound of playback from audio file vs CD lies elsewhere as the potential for high quality playback should be the same as the source is not inferior in anyway as compared with the CD player method?
Can we agree on this? Or is there pitfalls somewhere that I have overlooked?
Man, I missed this chestnut earlier...I think we should use marbles for data storage–then we can accurately verify whether at any one point in time, we've truly lost 'em.
Simon
Can I dare to deduce 1 step further.
If there is difference in CD and HD streaming, it is because one of them is implemented with less care instead of inherent difference (ie they should sound the same as they have the same source to start with)?
Unlike VInyl vs CD where CD is inherently inferior as it is a sample of the original continuous wave?
Is there any thing I missed in the links?
Or at least the Science Club branch of the OCD Society?
No .... Just me then.
Tog
It probably is a bit too much.
Just wanna clear up the concepts while I can, otherwise I would carry this wrong theory and does very wrong thing down the road.
Well most streaming techniques over TCP/IP use a special data packet to carry the PCM, called a datagram and is managed by a protocol called UDP. This protocol prioritises timing over data integrity, so if the datagram is corrupted it is thrown away, hence there is no recovery. So compared to CD and Hard disk, streaming is the format where errors are most likely to become apparent. So if the data being carried is uncompressed PCM then this error should be presented as a brief silence. Our brains tend to do the filling in.
Simon
Now that is very good information.
This means I will always use a USB drive instead of upnp.
"Well most streaming techniques over TCP/IP use a special data packet to carry the PCM, called a datagram and is managed by a protocol called UDP"
Not quite, UPnP AV uses TCP at least for the streaming connection between MediaServer and MediaRenderer, i.e. where the music data goes, as one can see with tcpdump or wireshark. And TCP/IP has checks against lost or corrupted packets built into the protocol. If packets are lost, TCP triggers retransmission. If the packet loss persists you eventually get a spinning sand clock on your DS/MediaRenderer because its local buffer runs low. But packets are not silently discarded like UDP would allow.
Jfritzen
Thanks for this, I removed my earlier post, as I did indeed exactly as you say - and wiresharked twonkymedia streaming to my iPad, and yes I see Twonkmedia does indeed use TCP for strreaming and not UDP. Therefore lost packets will be recovered using the TCP windowing system . Therefore it is safe to assume that Naim do the same.
So Lhau I am I must revise my earlier post, thge PCM is coveyed reliably using TCP on Twonkemdia UPnP media server and so it is dafe to assume Naim wil do the same - so an error or out of sequence packet will be resent in all but the most sever of circumstances.Therefore there might not be any differnece from the USB or streaming becasue of the transport itself, but the side effects we spoke about earlier might still obviosuly exisit.
Simon
you were right in so far as UPnP does allow also for UDP as a data transport as I have just learned. But at least the MediaServers I have tested do it with TCP (MiniDLNA and Synology Media Server), probably because TCP is easier to handle and the extra low latency of UDP is not needed for audio replay.
Rockingdoc,
sorry for abusing your thread
Kind regards,
Jochen
Simon
The case is that noone can post a link to a statement from a Linn engineer stating that, in their experience, FLAC sounds better, different or worse than WAV.
So what is there to take issue with?
I did in fact take issue with David Devers claim that the difference between FLAC and WAV on a DS was 'confirmed'. He didn't substatntiate the claim with either subjective experience or measurement - so neither is at all 'confirmed' in my opinion.
But Naim have said that an NDX is affected negatively by decompressing. js likes to argue that this is evidence of how revealing a source the NDX is. But then does it follow that by adding an nDAC that there is an even bigger difference? Is there still a difference if FLAC is transcoded to WAV server side? Does anyone seriously believe there ought to be a difference?