Flacs are inferior to wavs? - Page 2

Reading through the article and they are making a lot of assumptions and they are all over the place. It's really messy. I would want to read the first two 'articles' and the remaining 4th.

I don't know how they can make the case for one bit-perfect file vs another with the same checksum.

I would like to also know the definition of 'lossless' as it pertains to the authors.

The ironic part for me personally I use full wav rips and not FLAC. Storage is dirt cheap.

They are not very good experimenters, either.

Playing around with fciv.exe and flac.exe and a 1411Mbit/s file.

Encode to flac with -0 on the encoding. Reconstituted and it doesn't have the same MD5 hash.

That can be due to a difference in WAV file headers. What's needed is a CRC of the data following the header.

Yep. Need to play around with it a bit more. Thinking (need to test) that a file that is zipped and then unzipped should have the same hash.

It might make sense to start with a WAV file that's derived by decoding an existing FLAC, then convert to FLAC and back to WAV again. I assume that once you decode the FLAC at the first step, it will have some standard WAV header that will stay the same on the next pass.

It would be nice if there were a WAV compare tool that only looked at the data after the header.

Maybe my understanding of this stuff is dated, but here's how I always thought sound got from a file to your ears. If this is correct, it disproves an awful lot of claims.

1) The DAW or media player program asks the OS to read the file into RAM, probably in chunks if the file is long.

2) If the file is compressed it's decompressed, also to RAM.

3) The DAW or media player program then deposits the output stream into the sound card's own RAM buffer, and the sound card clocks the data out through its analog line output.

#3 is the key. As long as the computer and OS can keep up with the data stream - and even computers from ten years ago could do that with simple stereo at 44.1 KHz - then whatever happens before the sound card's own buffer is irrelevant.

Is this wrong?

--Ethan

There is one that does even one better in accommodating alignment issues and such: http://www.libinst.com/Audio%20DiffMaker.htm

Alas, it crashes on my Win7 machine or just does odd things. I have never been able to get it working but the design is sound.

Good diagnosis. By default, FLAC.EXE adds tags and other metadata to every file it converts.

Just for grins I tried a .wav minus .flac file subtraction in CEP 2.1 w/FLAC plug-in, and the result was a file of zeroes.

Not conceptually wrong.

All of the above can be accomplished for 44/16 .wav files using CEP 2.1 and the standard FLAC plug in for CEP. The file comparison methodology in this case is subtraction of files. If the coding and decoding is bit-perfect, then the result is a file of zero data.

I in fact just tried this procedure and I obtained the desired file of zero data. No surprises!

Really? It does matter, because if it was zero (a permissible value according to the above) then your favorable comments about their objective test data would be a false claim. The fact that the objective data in Stereophile is a minor component of the magazine is relevant, if you are going to justify them based on it.


Amir, you are obfuscating the fact that both you and Stereophile don't see any use to routine use of properly-run listening evaluations.


Stereophile and TAS are IME about equally troubled when it comes to their subjective testing, which is the vast majority of what they both do.


Then you are beating on a dead horse, Amir. I've made favorable references to Stereophile's objective tests in many posts that you have replied to. You know very well that I even use Stereophile's objective test data for my own purposes! Here you go again, ranting and raving about my comments about a different part of the magazine, trying to confuse them with what they were not. You are polluting this forum with ranting and raving about a controversy that only exists in your mind.


This is a complete and total falsehood on your part Amir because you have replied to posts in which I have used Stereophile objective test results to support my arguments.

Why do you make false claims like these Amir? Is there any truth to be found in you when you are going off like this?

Good grief. You know it is not zero. I know it is not zero. As a matter of fact, there is a ton of measurement data there and you know that. But you want to argue the 0% case?


It is not a minor component. Taking measurements is hard work and every issue has a ton of it in there.


More examples of you fighting the daemons inside you rather than discussing the point in the thread.


Who cares? I didn't defend or talk about any subjective talk in either magazine. As I said, the pain in you runs deep and you can't have any objective discussion otherwise without letting the daemons surface this way. You are so blinded you don't see the good.


Then you have no business complaining when I praise the same.


Then you have no business complaining when I praise the same.


I will fight people going out of their way to slam something when it is not even topic of discussion. You had no business talking about Stereophile where the report came out about TAS. You also have no business arguing when I say they have good measurement data and you confirm the same above.


Then you have no business complaining when I praise the same.


Let's talk about false claim. In anther thread, you claimed PCI Bus Contention causes fidelity problems in PC audio sound. Can you explain what the audible effect of PCI Bus Contention is?

Also, what happens if the system is not able to keep up with playback of digital audio stream? What is the audible effect?

In a recent thread, Arny argued that PC activity can lead to underrun conditions and said effect, causes fidelity issues and can explain why I was hearing my fax machine connected over USB on my Sound cards analog output! He threw around terms like PCI Bus Contention and proof points of cause.

I find his claims as incredulous as the bit that start this thread. But he stood his ground. I never got to finish that discussion with him and hence the questions I just asked him.

BTW, at micro level, your data may not be in RAM. The operating system only allocates virtual memory to applications. What may physically be in memory is for it to decide, not the app (unless the app locks the memory which media players do not). So it is possible after you read a chunk of the audio file into ram, find yourself in a situation where it is not there anymore and needs to be refetched. This is very unlikely though in this scenario of reading and reusing the data immediately.

Not only is the percentage of words and illustrations for the technical tests a small percentage of the whole magazine, but part of it is their usual subjective evaluations, which are on their face, highly suspect.
[/quote]


Amir, if you aren't talking about the TAS subjective tests of FLACs which is what this thread is about, why are you even bothering to post to it?



Been there, done that in a very recent thread. You responded to those posts, so Amir, there's no chance that you can claim you missed them.




Been there, done that in a very recent thread. You responded to those posts, so Amir, there's no chance that you can claim you missed them.

The above is about 80% a false claim. I have been saying all along that under exceptional conditions, PC activity can lead to underrun conditions and they can lead to a variety of non-subtle effects.

Arny, in this thread you again brought up the performance issue as a "clear possibility" of audibility issues. Are you not able to describe the audible effect?

And I am asking you to describe them please. What do they sound like Arny?

If your implying that the u or DACs are acting on the raw data directly from the HD heads or CD laser, I don't think so. It is RAM or Solid State even if it's paged in and out to virtual memory. The HD has buffers, the CD drive has buffers, The u has instruction and data caches, the sound card has memory buffers. It's likely re-registered, moved or copied several times (in SS) before the u or DACs see it.

Making a claim that it can depend on the location of the bits on magnetic or optical media doesn't smell right to me.

We are in agreement. Just some expansion below.

I was not implying that at all. It is possible that at the time that the I/O is initiated the buffer is paged out. The OS will attempt to lock the page and that a) forces RAM to be allocated and data paged back in if it is out and b) the buffer stays locked for the duration of the output operation (so it can't pulled from under the feet of the I/O device). So yes, in all cases the final command to send the bits out starts with real memory. But that doesn't preclude said buffer to be paged out prior to that.


I never talked about optical media or magnetic disk for that matter. I said that Ethan's statement that apps read things into "RAM" is an illusion. The data is read into RAM but may not stay there until it is output. It could get paged out and then needing to be paged back in as explained above.

???

In fact the virtual memory in XP, Win7 etc, is divided into an area for use by the kernel, and an area for use by applications. In 32 bit XP systems the division is half of the virtual memory space (4GB) for the kernel (system) and half for use by the user (application). Linux and Unix are similar in concept.

Again asked and answered in recent times. Asking what data loss due to bus contention sounds like is like asking what noise or distortion sound like - the answer can change on a case by case basis.

But just to repeat, a good running system doesn't have these problems. Setting up a good-running system is not rocket science. As Ethan says, we've been able to routinely and economically build systems that are free of audible bottlenecks for playing audio for at least a decade.

However, if some golden ear starts making all sorts of wild claims, it is impossible to prove that he hasn't screwed himself right in the old PC. ;-)

What you quoted from my response was unrelated to the original post I made here. Read my explanation of that post and tell me which part is not clear and I will expand.

Well then, please describe a few of the cases. Again, the focus is what the distortion sounds like. If you think it is impossible to describe, please demonstrate how that is the case.

Walk us through what happens from start to finish. Ethan started it, I am asking you to finish it.

No need. It's a semantic nit apparently.

This has nothing to do with the topic being discussed. What you are explaining is the maximum amount of virtual address space that can be allocated. There is nothing in this discussion that is in search of that answer.

Arny, so that we are grounded here, how do you classify your knowledge of computer architecture and operating system? Use scale 1 to 5 with 5 being expert level.

J.... F....C.... Not again.

I can answer the original question: No, they are not inferior. (For me at least.)

In fact, in many ways, they are superior. (Smaller file size, for example.)