As we all know here, FLAC is 100% lossless. I would like to know is, is there anywhere on the web some independant validation of this. Checksums, verification or whatever that an original .WAV and a .WAV>FLAC>.WAV conversion are bit for bit identical?

I could do with this for attempting to correct people who try to persuade other people in forums that FLAC is lossy. Threads like this:
http://audiokarma.org/forums/showthread.php?t=39576
Though I suspect the offender is the sort of guy who will start waxing lyrical about 'distortion spectra' and such that he knows nothing about to explain how a bit for bit exact copy can sound difference. Shocking? Yes, but this same attempt has been made by a writer in a major hi-fi magazine.

Flac should give bitidentical output. So if they can hear the difference it MUST be the flac decoder,player or something else. If you get bitidentcial output its obvious you cant hear any difference. So if people claim they can, let them provide a sample which shows that flac output is different from the input.

First, cheksums, MD5 or that kind of things do not prove that Flac is lossless.
Second, Flac is lossless. A bit-to-bit comparisson will prove that fact.
Third, if some people think Flac is lossy, who cares ?

most if not all encoders only compute checksums over the original pcm-data
but not on the original file (if you have extra chunks or files with uncommon
headers, be sure that the coder of your choice copies it)

For the guy who can't believe in how a lossless compression is possible, ask him how the heck he thinks .zip (or .rar, .gz, .bz2, .ace, .7z) works. He's not losing letters or numbers everytime he compresses a document, is he?

For the guy who just can't believe why lossless, presumably the holy grail, isn't widely used yet, the reasons are 1. stubborn standards, 2. market analysis that indicates Joe Average simply don't care about quality above listenable levels 3. the ~50% ratio is still too big for now and 4. too much processing power to decode in an economical device for now.

As far as that his claims about hearing a difference in an ABX, there's no hope in correcting that. At least not in a direct confrontation. One needs to direct him here and tell him to read the stickies and the developers' conversations, before he, perhaps, will accept that he knows little about audio quality and would be willing to learn. A long shot by any standard.

My advice... Don't bother. Ignore the idiots. Honestly, if anyone are dumb enough to argue whether lossless compression is lossless or not, they're a waste of oxygene.

I can understand that some idiots would make up pseudo-scientific reasons why their gold plated optical cables are superior, but lossless compression can be verified with anyone with a computer and two or more functional brain cells.

This is just too stupid to waste your time with.

Like this?

http://www.stereophile.com/asweseeit/822/index2.html

It's worth noting that AK appears to allow trolling.

Sure it was, sure it was..

That dude better not touch my cd's

Hopefully I can persuade the other people who read that thread that this guy is propagating rubbish.

On a selfish note, I don't care less. I know lossless encoding is totally possible and even to some extent how it is achieved. I just don't want others taking him at face value.

Well at least someone set him straight.

WOW.

Just.... wow.

Thanks for your contribution, mandel.

It is incredible tha amount of BS you can find in the internet. I wouldn't bother. The guy is an idiot. Plain and simple.

Goosebumps...

Wow. Clearly he needs to take a lesson in critical thinking:

maybe a 2x4 upside the head would help?

Yes they do. Any modification of data will result in a completely different MD5 hash.

I'm guessing this guy is trying to use the point the FLAC doesn't (or so I have read) losslessly preserve a wav file, but it does lossessly preserve the audio in the wav file. He probably thinks pngcrush ruins png files too.

Actually no; his stance is that any compression ruins the sound.

That's not really true. MD5 hashes have constant size but the set of all possible strings are infinite. Therefore hash function cannot be one to one -> It is possible to modify the file and obtain the same MD5. It's just infeasible.

Perhaps he was referring to the extremely rare (but theoretically possible) occurrence of collisions.

EDIT: Yet again, I am too late.

I doubt it, but even if he was, it's almost infinitely improbable that any modification to a file that would cause a checksum collision, is going to cause the file to have less tonal purity, lack of presence, narrow soundstage, muddy bass, unsatisfactory foot-tappityness... pick your favorite.

What we have here is a garden-variety troll. Please do not feed.

And to be especially pedantic for all those in the peanut gallery: if you have a sound card poor enough to be heavily affected by CPU core voltages, then you should be able to ABX FLAC vs WAV just by the change in CPU duty cycle.

That ought to be the only way such an ABX could be accomplished. However, since the duty cycle is at 1khz, the harmonics could in theory be detectable in quiet music pieces, so that a change in sound quality is effected. However, the smallest amount of distortion would be caused by 50% CPU usage, not 0%.

EDIT: After some not-so-careful hindsight, I have come to the conclusion that the highest amount of audible distortion would occur at 50% duty cycle, and the lowest amount of distortion would occur closer to 0%. See post below.

Hmm.

I think he's using a different definition of "data."

The RIFF header can be different before and after the compression/decompression, leading to different MD5 sums between the old WAV file and the new WAV file.

Ignoring the RIFF header in calculating the MD5 sums, or just comparing the PCM samples can be a solution, in such cases.

Yeah, there's a difference between "Data" (Ie bits and bytes of a file") and "audio content".

I'd probably guess on a lower spec computer, processor useage to be about 5% for WAV playback and about 15% for FLAC (and maybe as much as 20% for 320kbit mp3, higher than FLAC as flac decoding is just simple arithmetic). [Note: these are figues pulled out of my ass]

Does this mean on a minor technicality FLAC replay should sound better than WAV replay?

Maybe I should suggest he sticks to mp3, without any of that nasty Joint Stereo of course (joking)

A really easy way to test is to open the wave file and the flac file in Audition, invert and mix paste the flac file over the wave file and it will completely cancel out if it is exactly the same.

Maybe everyone who's childishly flaming his ass should shut up, we're supposed to be representing the intellectual high ground of the audio scene, not some fuckwits that just like to piss people off.

Wrong. There are no listening tests. You just bit compare using something like foobar - I've said it before.

Slow PC's - what like 486? My PIII550 uses <5% cpu with optimfrog normal mode through directsound.

This is quite old actually. I remember that more than 15 years ago we were already painting our CDs with green EDDING markers at the edges to improve sound quality.

The theory behind is simple ( but of course has never been scientifically proven ) :

When looking at the output current from a laser pickup in a CD player with an Oscilloscope, you recognize that the cavitations in the CD surface, indicating a '1' ( simplified ) are actually only slightly distinguishable from the typical noise level the photodiode in the pickup will collect from light from the CD surface, or other elements in or around the actual light path.

To achieve a usable signal, the normal audio CD is using a very simple Reed-Solomon 16/23 algorithm, which is able to recover the original 16 bit word even with only 13 valid bits. For video and data CD's, more error recovery layers have been added on top of that, improving data safety a lot but reducing the net data volume significantly :

Audio CD : 940 MB
Video CD : 800 MB
Data CD : 700 MB

The idea of the sanded edges, and same goes for the green EDDING Marker, is to increase read-out safety by reducing the level of light noise reaching the laser pickup. It is proven that scattered light, induced by the laser pickup itself, will wander through the Polycarbonate layers of the CD, will get partially reflected by the edges and return to the laser pickup in worst case.

I seem to recall that a well known audio lab in California could measure the reduction of the 'scattered-light-noise-floor' at the laser pickup for the green EDDING. It wasnt much, but they calculated that when looking at the general reading safety of common laser pickups these days ( 15 years ago ! ), the general error rate could be reduced by about 15%. I dont remember anymore if they have also measured the activity of the interpolation processor, normally a good indication that valid data from the Audio CD have been lost. Interpolation IS audible, especially when more than one consecutive sample have been lost.

So much for the theory behind this all ..... but please dont believe i myself would still paint my CDs green, or sand them at the edges .... nor do ask me if i consider that modern laser pickups would really be able to benefit from this at all

Christian

Well said, welcome to the discussion.

The simple answer is from flac's faq (can you say "flac faq" ten times really fast?): "you can always use the -V option with flac (also supported by most GUI frontends) to verify while encoding. With this option, a decoder is run in parallel to the encoder and its output is compared against the original input. If a difference is found flac will stop with an error."

FWIW, the guy who claims to be able to hear the difference also said, "But drop in a good CD or record and play it thru my system and I get goosebumps. Have you ever got any goosebumps listening to a file?"

A CD is a file.

Anyone who claims to be able to abx a flac to the original cd and tell the difference is smoking crack. Anyone who poo-poo's abx should save on penicillin and take a placebo next time they get sick. I'm sure the placebo will give them an "airy" feeling.

Mark

Actually, no, FLAC would probably sound worse in that case. But yes, it is a minor technicality. Because FLAC would run at a higher duty cycle, more of its energy would be concentrated at low frequencies, which in this situation would be more audible.

EDIT: The nature of this audibility would change when the scheduler tick rate of the OS changes. On Windows this is fixed at 1khz but this can be changed arbitrarily on Linux. If you set it to 20khz or above, in theory, the problem dissapears.

It would be an interesting experiment to mention this to an audiophyte and see if they'd actually try it. Their CPU performance would also go down by around 10%


That's kind of missing the point.

I believe it completely addresses the original question proving that the FLAC file format is indeed lossless, and that any audio differences are solely attributed to inadequate hardware or software.

Oh, well, in that context sure. The format itself is lossless (although to answer the original question, I don't think anybody has presented a mathematical proof to that effect). However, formats alone don't define how the speakers are driven. You can't just wish away the hardware and software and completely answer JimmyNeutron.

I agree that the effect ought to be inaudible on any hardware that isn't defective, but it can probably still be objectively measured on all hardware with sensitive enough measurements. Microvolts are microvolts, and power rail modulation has consequences.

<3

Just some foo was blabbing on about how moronic he was, which is getting noone anywhere.

True story:

There's a program I use which does a significant amount of computation every millisecond (but still <1% CPU time), and does a Sleep(1) for the wait. I ran this on a P4 1.7ghz and with my ER-4P I could actually hear a 1khz tone when the program was running, that disappeared when I shut it down.

EDIT: And no, I didn't ABX it.

One can go to his format spec:

Flac Format Page

And see that there's not a lot of magic to the losslessness of it: errors in the prediction are simply corrected for to make it lossless. I.e.: it's lossless by definition. The compression (i.e.: the prediction itself) is lossy, but the presence of the actual data allows the correction to be calculated. If the prediction algorithms are REALLY bad, you could end up with a flac file that is actually bigger than the original, I suspect.

Mark

For a real laugh check out his "homepage"

http://www.rycher.net/Rycher.htm

Well, actually, I was serious in that there was no "mathematical proof" (other than, say, "which part of 1 + 1 = 2 didn't they understand?") necessary.

Any I have to be nice to the guy - I replaced the woofers, midranges, one tweeter (thank you mister clipping), then woofer surrounds on my AR-3a's and got many years out of them. I continued to use them in a "second" system long after getting AR-303's. OTOH, I never cared for any of AR's 2-way systems... and that was all a few years ago...

Mark

Would you care to especify exactly to whom you are referring to with this comment, please?

Yes, but what he said was "checksums do not prove FLAC is lossless". I disagree. If I get identical hashes using a cryptographic hash function I can be certain the files including audio information are the same.

Getting a non-matching checksum result does not necessarily mean FLAC is not lossless, but that does not mean you can't prove FLAC is lossless using an MD5 or SHA1 hash.