or Connect
AVS › AVS Forum › Audio › Audio theory, Setup and Chat › Flacs are inferior to wavs?
New Posts  All Forums:Forum Nav:

Flacs are inferior to wavs? - Page 2

post #31 of 627
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.
post #32 of 627
Quote:
Originally Posted by sivadselim View Post

I'll say! The articles read like crap.

They are not very good experimenters, either.
post #33 of 627
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.
post #34 of 627
That can be due to a difference in WAV file headers. What's needed is a CRC of the data following the header.
post #35 of 627
Quote:
Originally Posted by rock_bottom View Post

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.
post #36 of 627
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.
post #37 of 627
Quote:
Originally Posted by arnyk View Post

It is clearly possible for bit identical files to sound different if there are other problems with the process of moving audio data from where it is stored to the output terminals of whatever DAC is being used (in the PC, in an external converter, in an AVR or headphone amplifier, etc.)

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
post #38 of 627
Quote:
Originally Posted by rock_bottom View Post

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.

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.
post #39 of 627
Quote:
Originally Posted by rock_bottom View Post

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

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.
post #40 of 627
Quote:
Originally Posted by Ethan Winer View Post

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



Not conceptually wrong.
post #41 of 627
Quote:
Originally Posted by rock_bottom View Post

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.

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!
post #42 of 627
Quote:
Originally Posted by amirm View Post

It doesn't matter what percentage of the print magazine is the objective data.

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.

Quote:
As I said, what is there is worth its weight in gold for us objective crowd. Your insistent attitude to put them the whole magazine is tiring and anti-science.

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.

Quote:
I did not sell you on anything but the *objective portion of stereophile.*

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.

Quote:
That you have no use for it and want to put the magazine down constantly

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?
post #43 of 627
Quote:
Originally Posted by arnyk View Post

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.

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?

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

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

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

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

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

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.

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

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

Quote:
You know very well that I even use Stereophile's objective test data for my own purposes!

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

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

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.

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

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

Quote:
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?

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?
post #44 of 627
Quote:
Originally Posted by Ethan Winer View Post

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

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.
post #45 of 627
Quote:
Originally Posted by amirm View Post

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

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]

Quote:
Who cares? I didn't defend or talk about any subjective talk in either magazine.

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?


Quote:
Originally Posted by amir View Post

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?

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.

Quote:
Originally Posted by amir View Post

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



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.
post #46 of 627
Quote:
Originally Posted by amirm View Post

In a recent thread, Arny argued that PC activity can lead to underrun conditions and said in 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.

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.
post #47 of 627
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?
post #48 of 627
Quote:
Originally Posted by arnyk View Post

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.

And I am asking you to describe them please. What do they sound like Arny?
post #49 of 627
Quote:
Originally Posted by amirm View Post

...BTW, at micro level, your data may not be in RAM... The operating system only allocates virtual memory to applications. ...

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.
post #50 of 627
We are in agreement. Just some expansion below.
Quote:
Originally Posted by dlarsen View Post

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.

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.

Quote:


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

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.
post #51 of 627
Quote:
Originally Posted by amirm View Post

I never talked about optical media or magnetic disk for that matter.

???

Quote:
Originally Posted by amirm View Post

If you believe that PC activity can cause fidelity differences, then two files located in two different parts of the hard disk can then result in different fidelity because the operating system acts differently when fetching one vs the other.
post #52 of 627
Thread Starter 
Quote:
Originally Posted by arnyk View Post

It is still possible to garbage up a PC with spyware, viruses, trojan horses, gegaws, games, acessories and toys to the extent that it can't do audio cleanly or a few unfortunate coincidences push the whole house of cards over the edge.

And they say in the first article that they "each used our own systems for these evaluations. . . ."

I haven't read the 2nd article closely (perhaps there is more there), but there doesn't seem to be discussion of what other applications are being run on the computer or what drivers are being used. For all we know these are systems that have tons of stuff running in the background. Norton could be aggressively running file scans during some listening tests. And then some of their other tests are run on both machines--one a 32 bit Vista, and the other 64bit Windows 7 with likely different motherboard audio on each. So this is the limit of their understanding of how the software environment could be different, other than they are testing with different media players (which may respond differently on each machine).
post #53 of 627
Quote:
Originally Posted by amirm View Post


BTW, at micro level, your data may not be in RAM. The operating system only allocates virtual memory to applications.

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.
post #54 of 627
Quote:
Originally Posted by amirm View Post

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

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. ;-)
post #55 of 627
Quote:
Originally Posted by dlarsen View Post

???

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.
post #56 of 627
Quote:
Originally Posted by arnyk View Post

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.

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.
post #57 of 627
Quote:
Originally Posted by amirm View Post

Read my explanation of that post and tell me which part is not clear and I will expand.

No need. It's a semantic nit apparently.

Quote:
Originally Posted by amirm View Post

We are in agreement.
post #58 of 627
Quote:
Originally Posted by arnyk View Post

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.

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.
post #59 of 627
J.... F....C.... Not again.
post #60 of 627
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.)
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Audio theory, Setup and Chat
AVS › AVS Forum › Audio › Audio theory, Setup and Chat › Flacs are inferior to wavs?