Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jazzrome]

I have ripped files in FLAC (0) and WAV have testing the files on a FIIO X3 and I notice a slight difference in sound quality -(more depth) a more neutral sound. Has anyone else noticed this. I would like to rip my entire collection to my NAS but if I use WAV I lose the metadata when I transferred the files to another location. I have considered AIFF but there is a lot of people say it does not sound as good a FLAC. See link http://thewelltemperedcomputer.com/KB/WAV-FLAC.htm it provides some interesting insight. Any feedback or suggestion would be appreciated.

[6233638]

FLAC and WAV created from the same source are identical.
FLAC is a lossless compression format, so it does not discard any audio like lossy formats such as MP3 or AAC do.

[astromo]

I have ripped files in FLAC (0) and WAV have testing the files on a FIIO X3 and I notice a slight difference in sound quality -(more depth) a more neutral sound. Has anyone else noticed this. I would like to rip my entire collection to my NAS but if I use WAV I lose the metadata when I transferred the files to another location. I have considered AIFF but there is a lot of people say it does not sound as good a FLAC. See link http://thewelltemperedcomputer.com/KB/WAV-FLAC.htm it provides some interesting insight. Any feedback or suggestion would be appreciated.

Did you look at the posts I suggested from your other thread, here?
Why compress files?

If you can hear a difference, then go with your own ears. They're what matter. Personally, I'm not able to hear a difference. So, I apply the methodology for audio files as previously stated in the link noted.

[AndyU]

I have ripped files in FLAC (0) and WAV have testing the files on a FIIO X3 and I notice a slight difference in sound quality -(more depth) a more neutral sound. Has anyone else noticed this. I would like to rip my entire collection to my NAS but if I use WAV I lose the metadata when I transferred the files to another location. I have considered AIFF but there is a lot of people say it does not sound as good a FLAC. See link http://thewelltemperedcomputer.com/KB/WAV-FLAC.htm it provides some interesting insight. Any feedback or suggestion would be appreciated.

I haven't heard any difference in sound quality between FLAC and WAV. If I did, I'd be quite worried about my DAC for it certainly is the case that JRiver will send exactly the same bits to it whether the source is FLAC(0), FLAC(5), WAV or any other lossless format. So if there is a difference it must be caused by some mysterious extraneous factor. People online speculate that it's the alleged extra CPU overhead of FLAC that causes it to (in their view) to sound worse. If that is the case, their DAC must be wide open to RF or some other extraneous factor, and so not be worth keeping. And in any case,why would it be that the extra CPU load of decoding FLAC causes it to sound worse, but not the reduced disc and bus overheads of retrieving FLAC causes it to sound better? Check your CPU load when playing FLAC compared to WAV - my quite ordinary laptop runs at around 1 or 2% when JRiver is playing either - scarcely flat out!

I suppose if you have a streamer then things might be different. In this case the decoding is done very close to the DAC itself and it is more conceivable that poor screening or power supply design could cause some degradation. But even then, a FLAC (5) is half the size roughly of the equivalent WAV, so the streamer has half the network traffic to deal with - unless the tags are enormous.

[fauxfreshness]

I have ripped files in FLAC (0) and WAV have testing the files on a FIIO X3 and I notice a slight difference in sound quality -(more depth) a more neutral sound. Has anyone else noticed this. I would like to rip my entire collection to my NAS but if I use WAV I lose the metadata when I transferred the files to another location. I have considered AIFF but there is a lot of people say it does not sound as good a FLAC. See link http://thewelltemperedcomputer.com/KB/WAV-FLAC.htm it provides some interesting insight. Any feedback or suggestion would be appreciated.

FLAC compresses on what appears to be the "dead space" between the top of a wave point and 0dBFS.  I believe this is also why it didn't support (at least as of their site's description of the CODEC) 32/64-bit float, as these allow samples to go beyond 0dBFS, and is why most DAWs work in 32-bit float so the meters can show how far beyond redline the peaks are.  So, if you have a relatively quiet track (say, something that ReplayGain would classify as "84 dB," like the Violent Femmes "Blister in the Sun") then it would compress easily at any value other than 0.  At 5, it would probably get reflect something like 550 Kbps, due to the time of the track versus the file's compressed size.

Since you're probably using a WAV source when ripping and then putting it into a FLAC container, you should get the same data solution set (waveform) as what was put in.  I preferred AIFF initially because of the widespread tagging support after Apple's "SOWT" (TWOS spelled backward) update to it.  The original Amiga and current Apple AIFF formats are still uncompressed, and if they have pretty hot levels running through them, like a brickwall limiter set to -0.003 dBFS, then the resultant FLAC won't seem too far off in size from the original as there isn't much room left to compress with.  In my case, I tend to "remaster," in a fashion, using Platinum Notes the AIFF and FLAC rips that are either too quiet (probably based on vinyl masters) or way, way too hot (almost everything in the last 20 years).  I don't do this with album-sensitive track volumes, like a classical or opera piece, as the quiet passages get cranked up relative to the prior or next track and are no longer cohesive.

As for sound quality issues, it would be more related to playback and possibly CPU and/or storage I/O issues while decompressing an aggressively compressed file.  Having the FLAC set to 0 results in a slightly larger file than the AIFF/WAV would have been to begin with, so there could be some storage I/O issues when queuing tracks.  In my case, using a FiiO X5, a Samsung Galaxy Note 3 (with and without a FiiO E18 Kunlun DAC/Amp), and a Nexus 7 2013, I haven't had any issues with tracks I've ripped, ripped and corrected, converted from WAV/AIFF downloads, or created myself in my own DAW with my own gear.

[bblue]

The FIIO players are seriously underpowered in the CPU department.  When they have to uncompress FLAC files in real time, there can be considerable jitter introduced in the playback.  That's when using analog output like headphones.  For higher speed files such as 96k and 192k FLACs being decoded for output to digital from the FIIO, it for the most part can't decode and playback digital at the same time without serious drops.

If you can tolerate the slight differences in FIIO's presentation with FLAC files, just continue to use them.  But if not, you'll need to upconvert from FLAC to WAV during or before the transfer to FIIO.  This has nothing to do with Media Center.  It's strictly a FIIO issue.  Even the newest ones still suffer.

[Vincent Kars]

To avoid any problems with the tags, stick to FLAC.
If WAV on the FIIO sounds better to you, use the sync function.
Set it to "always convert" and choose "Uncompressed WAV"
All your audio will be converted on the fly to WAV.

[Vocalpoint]

I have ripped files in FLAC (0) and WAV have testing the files on a FIIO X3 and I notice a slight difference in sound quality -(more depth) a more neutral sound. Has anyone else noticed this.

No difference whatsoever. Lossless is lossless.

If you are hearing a difference - it's simply your brain telling you that you must be hearing something different. Just like the guy who buys a 400 power cord and insists that the electricity coming from the wall is now "better". Logically - for someone who just dropped 400 bones on a new cord - there has to be some internal justification to that expenditure - so they allow their brain to reinforce that - of course it has to sound better. Each to their own - but if that mindset works for you - then rock on.

For me - the science and mathematics of it is quite another thing. I trust the absolute purity of numbers, checksums and all other clear, repeatable procedures that indicate that a WAV and a FLAC are identical in every possible technical way. To ensure a proper baseline (and to ensure I do not drive myself crazy) my ears come a very distant second in this regard.

Plus FLAC is so far and away a better metadata carrier - that WAV simply has no purpose to my collection anyway. Even if it did somehow sound better

VP

[Matt]

Just remember that the play from memory option decodes the entire file into memory in the first second of playback.  That means you will have identical everything when you play WAV or FLAC or APE.

[Arindelle]

did you read this? Also linked on Vicent's page http://www.computeraudiophile.com/blogs/mitchco/flac-vs-wav-part-2-final-results-155/

I'd like to have this article stickied.

[Vocalpoint]

did you read this? Also linked on Vicent's page http://www.computeraudiophile.com/blogs/mitchco/flac-vs-wav-part-2-final-results-155/

This says it all. Not sure how anyone could read that and still think there is a difference.

Nice one!

VP

[AndyU]

.. but actually, reading the o/p more carefully, I don't think the o/p is playing the files from JRiver. The FIIO X3 is a stand-alone music player thus it will be decoding the FLACs itself. Given that it is a low-powered fairly cheap device it is not inconceivable that there might be some interaction between the power-supply, processor and DAC when it is decoding.

[Vincent Kars]

It is a portable indeed.
That's why I suggested to sync from FLAC to WAV

[astromo]

did you read this? Also linked on Vicent's page http://www.computeraudiophile.com/blogs/mitchco/flac-vs-wav-part-2-final-results-155/

I'd like to have this article stickied.

This says it all. Not sure how anyone could read that and still think there is a difference.

Nice one!

VP

Yes, I have which is why I directed the OP to that info previously as pointed above.

Agree with both of you, however if a listener hears a difference I respect that and it's also sensible, as mentioned in this thread, to check out the possibility of a hardware issue.

Just remember that the play from memory option decodes the entire file into memory in the first second of playback.  That means you will have identical everything when you play WAV or FLAC or APE.

... which is the way I roll and why I have no problem using maximum compression of my lossless files.

[theoctavist]

if the listener hears differences between two lossless formats, it is all in the mind.  period.

it is called expectation bias.   

fact.

[glynor]

if the listener hears differences between two lossless formats, it is all in the mind.  period.

it is called expectation bias.  

That's generally true, and is certainly true if they're using MC to play the files.

However, I agree that with a portable device there could be problems decoding FLAC that aren't apparent with WAV.  Unlike most everyone above who mentioned this, I'd be extremely skeptical that any difference is from:

there might be some interaction between the power-supply, processor and DAC when it is decoding.

Almost certainly not.  If there is a difference, it is because the software on the device is doing a cruddy job decoding the FLAC files (or maybe a cruddy job with the WAV files, and the result just sounds nicer to the OP).  I'd bet it is something like 1000X more likely that a problem like this is a software bug... Especially on a device like that.  Consumer Electronics companies, with few and notable exceptions, are almost universally crappy at software.

And that's a niche product that probably doesn't have an army of highly-skilled, highly-paid software engineers behind it.  More likely, they're using GPL code running on a Linux OS which is three or four years old, and buggy as heck.

[glynor]

Lending more credence to the fire:

http://www.fiio.net/news/index.aspx?ID=100000163834271

Changes from firmware version 2.1 to 3.0 include the following:
...
Bug fixes and improvements:
1.Optimized mp3, wma, ogg vorbis and flac decoding quality (fixed noise artifacts in left channel of ogg vorbis tracks and low level noise in mp3 tracks)

They "optimized" flac decoding quality?  That's a neat trick.  Flac decoding "quality" is a binary state.  It either works or it does not.  There is no try.

So... What did they fix?  What does "Optimized" mean (always a fiddly word)?  Was it broken in earlier firmware versions, and they've fixed it?  Or, are they applying some kind of well-intentioned DSP to flac files (perhaps to make up for deficiencies in their decoding software, or perhaps just to "make it sound better" for some kind of crazy reason)?

[astromo]

Lending more credence to the fire:

http://www.fiio.net/news/index.aspx?ID=100000163834271

They "optimized" flac decoding quality?  That's a neat trick.  Flac decoding "quality" is a binary state.  It either works or it does not.  There is no try.

So... What did they fix?  What does "Optimized" mean (always a fiddly word)?  Was it broken in earlier firmware versions, and they've fixed it?  Or, are they applying some kind of well-intentioned DSP to flac files (perhaps to make up for deficiencies in their decoding software, or perhaps just to "make it sound better" for some kind of crazy reason)?

Arrow to the target ... bullseye!

I very much suspect you're asking questions the OEM would rather avoid.

[kstuart]

if the listener hears differences between two lossless formats, it is all in the mind.  period.

it is called expectation bias.  

fact.

All posts that end in "fact" are wrong.

Since no one ever goes to links...

4 shows now

    Posted by Gordon Rankin (M) on February 28, 2010 at 11:13:28

    In Reply to: RE: Guys Look!!!!!! posted by Phelonious Ponk on February 27, 2010 at 14:10:18:

    Gang,

    We did double blind testing in the following way;

    1) 2 computers MacBook Pro and MacBook (MacBook Air at last RMAF) both dual boot Vista Ultimate/OSX with J River and iTunes (we did not use amarra).

    2) We would play a WAV and a FLAC of the same song. We would play an ALAC and AIFF. 10 songs total... most of the time like 30-60 seconds these would be randomly mixed (i.e. sometimes FLAT PCM first [AIFF/WAV] sometimes lossless first). Each person was given paper to record the scores.

    Conclusion...

    a) 93% could tell the difference with the slower MacBook/Air. This is over 50 people now at more than 4 shows.

    b) Using a faster machine in the same test brought that number down to 58%.

    Remember gang we are using pretty pricey systems. Last years RMAF the system retail was over $70K

    It's like this... someone asked me today when the Proton would be taken to 24/192. I said probably never.... as you really would not be able to hear any difference when going from 96 to 192. So why bother....

    If you have an average system then none of this applies.

    Hey do your own tests... all of these files were converted to and from and back and compared. They are bit identical...

    An interesting note... I did a 1KHz sine wave in two formats ALAC/AIFF as I was on a mac. I then ran every freaken hog application (PS CS4... etc) I could find on my machine. The THD rose up for the ALAC at a much higher rate than the AIFF.

    I am trying to work on a timing test. But for some reason my WaveCrest will not seem to lock onto a 1KHz square wave... I may have to try running this at 96K or 192K and then run a 10KHz square wave but I think timing is also to blame.

    Either way it seems well evident that the processor performance has a significant determination of decoding on the fly which is a huge component of lossless files.

    Thanks
    Gordon
    J. Gordon Rankin

(Gordon Rankin is a professional DAC designer.)

from http://www.audioasylum.com/forums/pcaudio/messages/7/70925.html

[glynor]

I'd be very interested to see a detailed breakdown of their numbers and their test methodology.

That seems extremely fishy, unless something was badly broken on the Macbook Air.  First of all, it doesn't make sense logically.  Second of all, even if it is absolutely a real effect, 93% is way too high.  I'd be willing to bet you couldn't get 93% of a random selection of people to tell the difference between PCM WAV and a 128kbps MP3 consistently.  Even if they're all enthusiasts, the fact that they're reporting that high of a number screams that something is wrong with their test methodology.  Even if people could tell the difference, you'd expect a high percentage of them to "guess wrong" which is which in a much higher percentage of cases.  You ask a big group of people anything on the spot, in a conference-like environment, there are going to be all sorts of other factors that should contribute substantial statistical noise.  93% is a freaking landslide, and even in clear cut cases in science where you "cure" things, you don't get numbers like that very often at all.  If you're asking human subjects about something subjective in a distracting environment in a group?

It should be way, way lower, even if the effect is real.

Or maybe they were just asking "did it sound different"?  In this case, then that test is completely invalid.  You can't ask that, especially not of an audiophile crowd who Wants To Believe.

The best way, of course, would be to ABX test it, and they didn't.  So, I'm already curious why not?  It isn't hard to do, and if you really want to prove it and you have the stage?  Even if you don't play the reference first every time, the whole thing is odd.

Is there a detailed paper on their study with test methodology, raw results, and a detailed statistical analysis with margin of error calculations and standard deviation?  How do we know the Air had the exact same files?  I'm just curious about a lot of that information.

[AndyU]

.. but actually, reading the o/p more carefully, I don't think the o/p is playing the files from JRiver. The FIIO X3 is a stand-alone music player thus it will be decoding the FLACs itself. Given that it is a low-powered fairly cheap device it is not inconceivable that there might be some interaction between the power-supply, processor and DAC when it is decoding.

Almost certainly not.

Really? I don't see how you can so easily discount this possibility.

For example, naim audio, who make extremely expensive network music players, say in a white paper about their NDX player that:

"Uncompressed audio data will always give better results than compressed. Even lossless compression may not reproduce audio with equivalent quality to the uncompressed original as the processing required to uncompress the data increases the computational load. This raises the power supply noise floor, which detracts from the sound quality."

And an engineer from Linn Products, who also make extremely expensive network music players says here that:

"If we measure the power rail that feeds the main processor in the DS we can clearly see identifiable disturbance patterns due to audio decoding and network activity. These patterns do look different for WAV and FLAC - WAV shows more clearly defined peaks due to regular network activity and processing, while FLAC shows more broadband disturbance due to increased (but more random) processor activity."

.. though he goes on to say that Linn have taken steps to ensure that this noise does not get through to the DAC decoding.

So, seems to me that audio decoding definitely can influence the power supply; in the case of naim they can't keep this noise from influencing sound quality, though Linn seemingly can. Chances of a portable FIIO DAC at a tenth of the price doing a better job?

But I do agree that there's also the possibility that the FIIO decoding is deficient.

Either way, or both, I don't think you can dismiss the o/ps perceptions as impossible.

[Vincent Kars]

I think this thread sums up nicely what can account for possible differences

Testing.
It is very demanding to stage a good test. Experimental design and experimental setup are crucial.
At one hand, we cannot expect the average audio enthusiast to apply the rigor of scientific testing.
Hence we run the risk that reported differences are spurious due to our cognitions influencing our perception unwittingly.
At the same time, we cannot rule out that the perceived difference is real.

Software
Bug free software is a nice illusion.
As the FIIO case shows, they probably do have to compile the codecs for their specific hardware.
Little errors e.g. insufficient precision can cause audible distortion.

Hardware
 Linn/Naim and so many other DAC designers know that all components do create some dirt and if this creeps into a DAC, it might disturb it.
Do observe that today’s average $1500 DAC does have a noise floor of -120 dBFS. This is extremely low; hence the slightest ripple on e.g. the ground plane is a disturbance.
Noise isolation is an important aspect in DAC design.

There is IMHO a nice Q&A with John Swenson about how noise can be generated inside a computer.
http://www.audiostream.com/content/qa-john-swenson-part-3-how-bit-perfect-software-can-affect-sound

He even offers some hypotheses why different media player although delivering exactly the same bits can sound different.
Would love to see JRiver consulting Swenson.
A measurement showing JRiver generating less ground plane noise than JPlay would make my day.
It would also prove that Matt’s paradigm of smooth processing pays off.  
That’s indeed what I believe to be true as systematic jitter is less audible than periodic jitter.

[JimH]

"Uncompressed audio data will always give better results than compressed. Even lossless compression may not reproduce audio with equivalent quality to the uncompressed original as the processing required to uncompress the data increases the computational load. This raises the power supply noise floor, which detracts from the sound quality."

They're wrong.  It's silly to say that.

[AndyU]

When using USB I think all bets are off. You are connecting a potentially very noisy source with a very sensitive converter. Here is a post by Rob Watts, who designs DACs for Chord, where he talks about the differences that isolation can make to the performance of his own designs. To me it follows that if your DAC isn't isolated from your pc it's perfectly possible for noise at the pc end to influence the DAC.

[AndyU]

They're wrong.  It's silly to say that.

Do you  have any measurements of naim's DACs to support your disagreement with their own engineers?

Notice that Linn also can measure differences at the power supply when the processor in their network players is decoding FLAC compared to WAV. Are you saying their measurements are wrong? Do you have different ones? In Linn's case, they evidently have taken steps to keep the power supply noise away from the DAC. In naims case, who knows why, they haven't.

And when it comes to USB, see the remarks of another DAC designer in my previous post.

[glynor]

Do you  have any measurements of naim's DACs to support your disagreement with their own engineers?

This has been something of a refrain in this thread: "DAC-designer X is obviously super-duper-smart and says X."  Their very engineers are the people I'm least likely to accept statements from at face value.

Never trust vague and unsupported statements, especially sweeping ones, from people who have something to sell you.  If they want to disprove math, they better have some hard evidence and repeatable testing procedures to prove it, not the other way around.

[Vincent Kars]

Don’t see what this has to do with math.
Nobody claims the bits are altered.
Noise generated by electronic components has nothing to do with math

[AndyU]

This has been something of a refrain in this thread: "DAC-designer X is obviously super-duper-smart and says X."  Their very engineers are the people I'm least likely to accept statements from at face value.

Never trust vague and unsupported statements, especially sweeping ones, from people who have something to sell you.  If they want to disprove math, they better have some hard evidence and repeatable testing procedures to prove it, not the other way around.

What's 'math' about measuring different patterns of noise? These engineers all say they did so, in one form or another. Their statements are hidden away in obscure corners of the manufacturers website or other forums. There is no commercial benefit in saying your product deals with FLAC less ideally than it ought; there is no commercial benefit in saying your product has an inadequately isolated USB input, or can be improved by adding a third-party product.

But if you mistrust engineers on the forum for the product on which they work ... well it follows that I should mistrust JimHs statements too .. unless of course he (or you) has some "hard evidence and repeatable testing procedures" to prove his assertions about naims DACs!

[glynor]

Don’t see what this has to do with math.
Nobody claims the bits are altered.
Noise generated by electronic components has nothing to do with math

I don't think you can say "nobody" claims the bits are altered.  But my statement wasn't a reply to everyone specifically in this thread.

It was a reply to the "general idea" of an Appeal to Authority...

To answer specifically why I'm extremely skeptical about the "electrical noise" postulation, with anything approaching a modern PC, is that the overhead for decoding FLAC is so absurdly low that if the system was impacted by problems like this, there would be all kinds of other situations where it would be impacted, randomly, regardless of whether you are playing FLAC or WAV.

No matter what you do with a PC, your computer is always doing a whole bunch of stuff in the background.  Even if you go crazy and try to "super-optimize" services and whatnot (which is a terrible idea unless you're a Microsoft engineer), you won't be able to turn it all off.

So... Why would it uniquely happen when playing FLAC versus WAV (versus a wide variety of other lossless formats)?

The only performance tests I've seen with decent numbers show that FLAC decode performance has almost zero chance of of impact.  I've seen one decent set of benchmarks showing CPU usage for FLAC decoding, and that was a contrived test using ancient AMD hardware.  That article was a few years ago, and used a contrived hardware setup to be even able to show a repeatable decode impact measurement (the CPU was a slow AMD low-end part, now years and years old, which was a cruddy one when it was first released, artificially limited to a single core, and so on and so forth).  In all other cases, all of the exact same electrical noise environment stuff would be identical (or indistinguishable from noise) between FLAC and WAV decoding.

And I have seen plenty of test measuring output and doing difference analysis on them and aside from clock skew (which would apply equally to all media types) they came out identical time and time again.  Someone linked one of these tests above.  There are a ton more out there if you look.

The placebo effect is incredibly strong.  It can "cure" serious diseases.  Convincing you that you hear a difference is child's play, unless you are extremely careful with your testing environment and setup.

That's why doing science is hard.

[Vocalpoint]

That's why doing science is hard.

Right arm!

VP

[AndyU]

I don't think you can say "nobody" claims the bits are altered.  But my statement wasn't a reply to everyone specifically in this thread.

It was a reply to the "general idea" of an Appeal to Authority...
...

That's why doing science is hard.

Remind me what you  are an authority on Glynor, so that when you make a pronouncement I can link to that wiki article as a way of dissing anyone who agrees with you!

[mojave]

Several things:
1.  A DSD file or 192Khz FLAC decodes and is in memory in less than a second on my computer. This happens before playback begins.

2.  A modern first person shooter (FPS) video game uses various CPU and GPU amounts up to 100% with multiple fans spinning. The audio is also routed through JRiver. One would think that the sound and video quality would in some way have noticeable glitches, dropouts, noise, etc. If a highly stressed system, playing 8 channels of audio through JRiver, does so without any problems, how can simple playback of FLAC or any other format be affected? One can bring a computer to the point of instability by overclocking and it can crash when playing a video game. It will still play any audio file just fine. How is that even possible?

3.  Pro audio DAC designers typically (from what I've read in the past) have a different view than boutique DAC designers. Here is an excerpt from the Lynx Studios forum:

Hello.
I have long intend to transfer my LynxTwo-A into the external PCI Expansion Box with High-Quality linear PSU (with extremely low ripple), pursuing these two goals - to get rid of EMI interference and to give a clean supply.
How much, do you think, it can improve the sound (and measurements) of my LynxTwo-A ?

not at all...
EMI interference and computer power supply characteristics have almost no measurable impact on the LynxTWO audio performance, by design.
The reason the Aurora has better audio performance has very little to do with the external form factor.

[kstuart]

Generally, people will either read the John Swenson articles linked by Vincent (I've previously posted links to Part One and Part Two on this Forum and no one has read them) or they will prefer to believe marketing slogans about "bit perfect" over the scientific electrical engineering explanation about why a PC designed to never operate in real time, does not always work right in real time.

http://www.audiostream.com/content/qa-john-swenson-part-1-what-digital

http://www.audiostream.com/content/qa-john-swenson-part-2-are-bits-just-bits

http://www.audiostream.com/content/qa-john-swenson-part-3-how-bit-perfect-software-can-affect-sound

[mwillems]

Generally, people will either read the John Swenson articles linked by Vincent (I've previously posted links to Part One and Part Two on this Forum and no one has read them) or they will prefer to believe marketing slogans about "bit perfect" over the scientific electrical engineering explanation about why a PC designed to never operate in real time, does not always work right in real time.

http://www.audiostream.com/content/qa-john-swenson-part-1-what-digital

http://www.audiostream.com/content/qa-john-swenson-part-2-are-bits-just-bits

http://www.audiostream.com/content/qa-john-swenson-part-3-how-bit-perfect-software-can-affect-sound

FWIW, I've read those articles before, and his point basically boils down to: bit perfect software players are not all the same because of 1) jitter/timing errors and 2) electrical interference generated by code execution.  Those are meaningful arguments as far as they go: jitter is real, and audible if it's loud enough; PCs can create electrical interference that varies with internal PC states, which can be transmitted through USB connections (I've experienced variable PC-derived interference personally with a poorly designed DAC).

But noticeably missing from those articles are measurements suggesting that any existing file formats or bit-perfect playback software actually create meaningfully different levels of jitter distortion or electrical interference.  He postulates some mechanisms, but offers no demonstration or measurements that would validate his theory or provide an order of magnitude.  If the effect is as pronounced as he described it, it should be trivially easy to produce measurements supporting his point using different bit-perfect players that differ in the way he describes.  Jitter and electrical noise are readily measurable.  

Absence of proof is not proof of absence, but given the amount of attention this gets, I would think that some enterprising person might have managed to measure a difference in the jitter or electrical noise between, say, JRiver vs. Foobar, or FLAC v. WAV, etc.  I've never seen a difference in my personal noise measurements, FWIW, but I haven't tried to take any jitter measurements.  I'd be very interested in any measurements anyone might have showing meaningful differences either in jitter or in noise after conversion to analog.

For those interested in links, here's an old favorite on the jitter side of things with a slightly more measurement-focused discussion of jitter, it's audibility, and it's relationship (or non-relationship) to file formats: http://nwavguy.blogspot.com/2011/02/jitter-does-it-matter.html

[glynor]

What mwillems said.

[Vincent Kars]

If you like NWAVguy (unfortunately MIA for a long time) you probably like this as well: http://archimago.blogspot.ca/

[mwillems]

If you like NWAVguy (unfortunately MIA for a long time) you probably like this as well: http://archimago.blogspot.ca/

Yep; I especially enjoyed his blind-testing to see if people could tell the difference between 16 and 24 bit sources.  It's small test (only 140 respondents), but the results are very interesting: http://archimago.blogspot.ca/2014/06/24-bit-vs-16-bit-audio-test-part-ii.html  

(spoiler alert: in the aggregate his respondents either could not distinguish the difference, or were more likely to get it wrong than right)

I also miss reading nwavguy, he did a lot of good work for consumers of budget DACs, it's a shame he's vanished.

[6233638]

Yep; I especially enjoyed his blind-testing to see if people could tell the difference between 16 and 24 bit sources.

Properly dithered, and without attenuation, it should be extremely difficult to hear a difference between the two.
With a good dither implementation, the only difference should be an increased noise floor rather than increased distortion.

[Mitchco]

This little $250 Dell Venue Pro 8 tablet http://www.dell.com/us/business/p/dell-venue-8-pro/pd can playback 24 tracks of recorded digital audio, with 16 DSP effect plugins, in real time, without any audible issues whatsoever.
  
The CPU/system utilization is running on average 40 to 50% on the Venue 8.  And this was not using an ASIO driver, but rather the onboard Dell OS Core Audio WaveRT driver.

You can try it yourself by downloading a 30 day trial here: http://www.acoustica.com/beta/mixcraft.htm and opening up Rapunzel.mx6 and listen.

Or hear for yourself as I made a small recording with my phone’s microphone – decidedly low fi, but one can clearly hear that there are no issues whatsoever: https://westcoastdpe.blob.core.windows.net/recordings/Dell%20Venue%20Pro%208%2024%20tracks.mp4   Warning 244 MP4 in size.

Now, if I mixed those 24 tracks down to 2 tracks on the Dell tablet and then did the same on my $1000 HTPC and compared the output.  Do you think they would compare bit perfect?  :-)

Speaking of Archimago and jitter: http://archimago.blogspot.ca/2013/03/measurements-hunt-for-load-induced.html

Might also want to try this jitter listening test: http://www.cranesong.com/jitter_1.html

[glynor]

Remind me what you  are an authority on Glynor, so that when you make a pronouncement I can link to that wiki article as a way of dissing anyone who agrees with you!

I love it.  Attempting to paper over your own Appeal to Authority fallacy with an argumentum ad hominem (and a rude one at that).  Its like a cornucopia of fallacious arguments.

Good job.

I'll end with my own, but I think a better one: This field is so rife with back-and-forth and wild claims (and money), for so long, that if it was true, aside from particular examples of bad software or broken hardware design, there would be good, scientifically rigorous, easily reproducible papers published in peer reviewed journals all over the place proving it.  Because that's what happens when you have a contentious argument over long periods and PhD students who need to write thesis dissertations.

There are not, so there likely is not.

[mwillems]

Speaking of Archimago and jitter: http://archimago.blogspot.ca/2013/03/measurements-hunt-for-load-induced.html

That's an excellent article, thanks for that Mitchco!

Properly dithered, and without attenuation, it should be extremely difficult to hear a difference between the two.
With a good dither implementation, the only difference should be an increased noise floor rather than increased distortion.

In the methodology he explains that he used triangular dither with .5 bit depth to create the 16 bit files, which suggests that he used TPDF, but only 1 LSB?  Not sure how that works exactly, but you're right it's an important point.

I don't think he controlled for people's digital volume settings (although that would have been very interesting if he had).

[kstuart]

I'll end with my own, but I think a better one: This field is so rife with back-and-forth and wild claims (and money), for so long, that if it was true, aside from particular examples of bad software or broken hardware design, there would be good, scientifically rigorous, easily reproducible papers published in peer reviewed journals all over the place proving it.  Because that's what happens when you have a contentious argument over long periods and PhD students who need to write thesis dissertations.

There are not, so there likely is not.

Oh come on, glynor, I know that you come up with a scathing destruction of the fallacious logic in that paragraph if it was written by someone else.

How long it did it take Epicycles to go out of favor, and Elliptical orbits to be acknowledged ?

For that matter, in 1977 a part-time college student invented that "eating fat is unhealthy", and since he worked for a Senate sub-committee, it became Official Government Policy.  20 years later, researchers like Dr. Diana Schwarzbein tried to find the studies on which it was based and was shocked to find zero.  But it was too late, as 7 billion people still believe it and you can still find little pink hearts next to low-fat items on menus....

[AndyU]

I love it.  Attempting to paper over your own Appeal to Authority fallacy with an argumentum ad hominem (and a rude one at that).  Its like a cornucopia of fallacious arguments.

Good job.

I'll end with my own, but I think a better one: This field is so rife with back-and-forth and wild claims (and money), for so long, that if it was true, aside from particular examples of bad software or broken hardware design, there would be good, scientifically rigorous, easily reproducible papers published in peer reviewed journals all over the place proving it.  Because that's what happens when you have a contentious argument over long periods and PhD students who need to write thesis dissertations.

There are not, so there likely is not.

But glynor, surely by your own logic your references to argumentum ad hominem and Appeal to Authority... are simply Appeals to Authority?

As Jim said, authoritatively but with no evidence, "This is silly". Surely it's possible to mention the opinions of people who design DACs for a living without the very fact that they might be thought to know what they are talking about being used to discount their observations.

Would you only allow comments from authority-less people who have no expertise in a field?