File-based audio playback - compressed vs. uncompressed

[AlexM]

Hi,

Following on from the debate in another thread, I thought that it would be best to start a new thread on what is obviously an area in dispute.

As more and more of us move to file-based playback solutions, I think that it would be useful to explore the anxiety about storage of audio files using FLAC containers (as opposed to WAV/AIFF files). For the record, all of my CD rips exist as FLAC files, encoded directly via dbPowerAmp. I have done some a/b testing between WAVs and FLACs without being able to hear a difference, and have compared WAV and FLAC streaming to the SB Touch without really being able to notice a consistent difference.

My take on this issue is this:

1) Some people claim that FLAC files sound different to the source WAV file
2) Some futher claims that converting from WAV to FLAC and back to WAV again affects the sound, despite the files having identical checksums (i.e. every bit in them is the same). I cannot see how this could be possible.
3) If there are audible differences, they are implementation issues with the playback software / audio driver stack / hardware, not the file format or data. If this is so we need to identify and fix the implementation issue not work around the problem (if it really exists).

As choosing a storage format for your audio library is going to be pretty fraught if you believe that subtle degradation is going on at the data level, I think that this should be exploded once and for all and then we can all relax and get on with enjoying the music again.:)

My view is that while the file is residing on a computer, i.e. not being played out, it is simply data, and can be packed or unpacked without changing at all. There is nothing special about audio data on a hard disk compared to any other type of data, and were this not so I wouldn't be able to be posting this now as data corruption would prevent my computer and the internet from working.

Your uncompressed audio files are, in fact, already compressed by the hard drive controller before being stored as magnetic domains on the disk surface by run length limiting, and we seem to accept that there are no issues arising from that process.

I read an interesting post by David Snyder on computeraudiophile.com, which I have reproduced below. I think it sums up the position well.


Hello,

At the heart of this debate over how the handling of digital music files (adding/altering metadata, transfer through email, and conversion among lossless formats, etc.) may have a residual impact on their sound lies each person's definitions for "data" and "music", and if there is a distinction, at what point the transformation occurs.

If one believes that a WAV, AIFF or FLAC file fundamentally is music, then audiophile notions of how that music should handled can come into play. Music is intricate, fragile, and must be handled carefully to preserve as much detail from the original recording as possible. Transfer over wireless networks should be avoided. Before downloading from an on-line music store, be sure to use a high quality Ethernet cable of no more than 5m in length, directly connected between your PC and DSL router or cable modem for shortest signal path. Intel network cards are better at preserving mocrodynamics, but Broadcom NICs tend to deliver digital downloads with a larger soundstage. Save your downloads directly to a firewire or internal SATA hard drive (avoid USB and SSD because of higher noise levels). Downloads done late at night tend to have better sonic purity than downloads in the middle of the day due to less traffic on the network. Make sure that both your computer and your router are connected to a good power conditioner during the download and any subsequent transfer. Do not convert your downloads to other data formats...there's no such thing as lossless conversion or especially lossless compression! Do not attempt to add or correct the metadata since doing so can have a subtle but irreversible impact to the sound quality of your digital music files.

Contrary to the view above, I personally believe that a WAV, AIFF, or FLAC digital music file is just data. It's not music or sound any more than a spreadsheet, expense report, or last year's tax return. All data files are nothing more more than sequences of bits: 1s and 0s. The contents of these data files only have meaning within the context of application software that can read and interpret them. While the physical properties of storage media and signal transfer can have an impact on the integrity of data, modern computer systems and data networks have mature and highly reliable ways of detecting errors and correcting them with bit-perfect accuracy within multiple technology or protocol layers below the application. In the rare event that an error can not be handled transparently, there are facilities to notify the application and user of the failure so that corruption does not occur unnoticed. While it's possible that low level corruption can escape detection, this is so rare that most computer audio systems will not be affected by it during their years of useful service.

Since a digital music file is no different from any other data file on your computer, the same handling rules apply. You can make a copy of a copy of a copy of a copy of...a copy of a file one hundred times and the one hundredth copy of the file will be bit-for-bit identical to the original. There's no generation loss. It doesn't matter if you transfer/store files using wireless or wired networks, USB or firewire storage, SATA or SAS disks, CIFS or NFS network shares, Mac or PC hardware. The mechanisms for protecting data file integrity work the same regardless of the file extension, type or contents. If you find this not to be the case with your particular computer system, you should find out why and have it repaired.

So, at what point does data become music? In a computer audio playback system, at what point in the playback chain does audiophile handling of the music come into play and actually matter? These are important questions. I believe that this transformation occurs when time is applied to the amplitude values in our data files. It's time, after all that makes sound (and therefore, music) possible.

All of the bits in a music data file are frozen in time; they exist in whatever state they are in all at once and unchanging (unless something goes horribly wrong with the hardware). When those bits are interpreted as amplitude values and those values are associated with a uniform series of clock pulses in real time, at that instant the data begins its journey through our playback systems. It's at that instant (and not before) that handling of these delicate signals can have an impact on the sound that eventually reaches our ears.

While the signal is still in its digital form, jitter, or tiny variations in the timing of the clock pulses can have a significant impact on sound. Computer audiophiles use high end USB to S/PDIF converters with ultra high quality clocks, DACs with buffering and re-sampling, audiophile USB and S/PDIF cables, and all sorts of other techniques to minimize jitter before the amplitude and timing information reach the DAC chips. Once the signal leaves the DAC, at least the same level of care is taken to preserve the music in its analog electrical form until it reaches our loudspeakers. At that point, the signal becomes acoustic energy and so acoustic treatment and design become important.

At all steps in the signal path past the point at which time is applied to to the data, audio engineering approaches to signal transmission and handling come into play. Prior to that point, computer science and best practices that apply to data integrity are all that one must concern themselves with in the world of computer audio.

I went over a lot of details here which I hopefully got right. I'm confident that any mistakes will be corrected by folks on this forum in short order and for everyone's benefit, including mine! My purpose in all of this (including the tedious exercise, which I hope you took part in as well) has been to hopefully dispel the notion that modern computer systems are incapable of reliably handing music data files without introducing minute levels of corruption or degradation. If it were true (or commonly accepted as true), this notion would be damaging to the growth of the computer audio industry. Audiophiles who do not currently purchase high resolution digital files or USB DACs may not be willing to even give them a try if they believe that computers can't be trusted to handle these files without loosing bits here and there. Thankfully, computers seem handle data just fine, so let's give the all clear get back to listening and enjoying music.

-- David

Let the debate begin.

Regards,
Alex

[StanleyB]

My take on this issue is this:

1) Some people claim that FLAC files sound different to the source WAV file


I have to take issue with you on your "take".
What you should be writing is how you see it from your perspective. So your sentence should in reality be:

1. Some people claim that there is no sound difference between FLAC and the source WAV file.

By penning it down the way you did, you are automatically giving the impression that your point of view is correct, and the opposing views are claims that should be debunked. Now, obviously that is what is in dispute.

What we do know is that the theory behind FLAC states that there are no losses, whilst the experience of many do not support the theory.

[bobbasrah]

While the signal is still in its digital form, jitter, or tiny variations in the timing of the clock pulses can have a significant impact on sound. Computer audiophiles use high end USB to S/PDIF converters with ultra high quality clocks, DACs with buffering and re-sampling, audiophile USB and S/PDIF cables, and all sorts of other techniques to minimize jitter before the amplitude and timing information reach the DAC chips. Once the signal leaves the DAC, at least the same level of care is taken to preserve the music in its analog electrical form until it reaches our loudspeakers. At that point, the signal becomes acoustic energy and so acoustic treatment and design become important.

At all steps in the signal path past the point at which time is applied to to the data, audio engineering approaches to signal transmission and handling come into play. Prior to that point, computer science and best practices that apply to data integrity are all that one must concern themselves with in the world of computer audio.


Thank you for taking the initiative Alex, hopefully this will confine the debate rather than continue random asides, and facilitate reasonable and productive discussion. :D
OK, perhaps a little too optimistic.... :eyebrows:
Ah, I see, perhaps not...:doh:

Whereas I agree with the article which is logically examined, I have trouble with where precisely timing comes into the process?
:scratch:

[AlexM]

I have to take issue with you on your "take".
What you should be writing is how you see it from your perspective. So your sentence should in reality be:

1. Some people claim that there is no sound difference between FLAC and the source WAV file.

By penning it down the way you did, you are automatically giving the impression that your point of view is correct, and the opposing views are claims that should be debunked. Now, obviously that is what is in dispute.

What we do know is that the theory behind FLAC states that there are no losses, whilst the experience of many do not support the theory.

Stan,

OK, yes I take your point. I have my view, but I have no real issue with putting this either way as I am actually open to the possibility that they are audibly different.

The question is why (if this is so)?. I contend that it isn't because data is lost during compression into or out of FLAC containers. I think we need some other hypothesis to move this forward.

Regards,
Alex

[Welder]

You lot make I larf. :lol:
The very notion that your going to "explode" any audio myth on an internet forum is as delusional as many of the claims made by the hard core subjectivists.

I'll let you lot exercise your keyboard warrior skills and go do something more useful and more entertaining. ;)

[bobbasrah]

That's a bit rich from you to say the least :).
Opinions and experiences are two different things. I speak from personal experience with regards to FLAC, and so do many others. Those that offer the opinion that there is no data lost in FLAC are not speaking from experience, but have the foundation of their argument embedded in what they have read somewhere on the net or a magazine.

Having seen the issue over FLAC v WAV playing surface on a few occasions on the forum, I did wonder whether the effects would be noticed, so tried a few experiments using WAV and FLAC conversions, and could find no noticeable effects.
With the possibility that this was due to my kit being of inadequate reolution, I went so far as to enlist the aid of a local lad (Music Professional) whose equipment is exemplary, and the same tests run. Same result, no difference.
For several hours, we tried, converting other albums and tracks, changing DACs, and even setting up his laptop to see if it was machine related, all to no avail.

From those experiments, my experience gave rise to my opinion that I was searching for something that I could not find.

My conclusion had to be that the player itself could be the only cause for the difference noted elsewhere, where decompaction of the FLAC took place.

[Ali Tait]

Did you try FLAC's of the same track with different compression levels?

[bobbasrah]

Get a better system :eyebrows:.

As above, you will note I took the precaution of not relying on my own fallabilities..

[bobbasrah]

Did you try FLAC's of the same track with different compression levels?

No Ali, I cannot in all honesty say what that level that was otherr than I THINK it was a default.:scratch:

Same album used, then a few others converted on the second test, mainly as these were intimately known by their owner.

[StanleyB]

From those experiments, my experience gave rise to my opinion that I was searching for something that I could not find.

My conclusion had to be that the player itself could be the only cause for the difference noted elsewhere, where decompaction of the FLAC took place.
Since the decoding takes place in your computer, have you considered that to be the source of the problem?

[AlexM]

Thank you for taking the initiative Alex, hopefully this will confine the debate rather than continue random asides, and facilitate reasonable and productive discussion. :D
OK, perhaps a little too optimistic.... :eyebrows:
Ah, I see, perhaps not...:doh:

Whereas I agree with the article which is logically examined, I have trouble with where precisely timing comes into the process?
:scratch:

Bob,

I think the answer is different based on whether the the source device is producing a bit stream or using a packet-based interface, whether the DAC is buffering internally or not, and how/where the data is clocked out to the DAC, i.e. where does the data become synchronous.

Alex

[bobbasrah]

Since the decoding takes place in your computer, have you considered that to be the source of the problem?

Good grief Stan.....:steam: READ MY POST PROPERLY
For several hours, we tried, converting other albums and tracks, changing DACs, and even setting up his laptop to see if it was machine related, all to no avail :eyebrows:

It was not my inadequate computer, and not my inadequate system.:eek:
Are you going to blame my ears next or the musician being tone deaf? :steam:

[StanleyB]

Good grief Stan.....:steam: READ MY POST PROPERLY
For several hours, we tried, converting other albums and tracks, changing DACs, and even setting up his laptop to see if it was machine related, all to no avail :eyebrows:

It was not my inadequate computer, and not my inadequate system.:eek:
Are you going to blame my ears next or the musician being tone deaf? :steam:
Have you considered fatigue? If after trying for several hours, tiredness can creep in and play funny things on the mind. One's ears also becomes less sensitive over time if you listen to music constantly in a session.

[bobbasrah]

Bob,

I think the answer is different based on whether the the source device is producing a bit stream or using a packet-based interface, whether the DAC is buffering internally or not, and how/where the data is clocked out to the DAC, i.e. where does the data become synchronous.

Alex

Ok Alex, so with async DAC the timing control is from the DAC, that I understood, but does that mean that the data transfer method is changed from that which would apply say for a drive?
Sorry if that sounds a bit thick :scratch:

[StanleyB]

I think the answer is different based on whether the the source device is producing a bit stream or using a packet-based interface, whether the DAC is buffering internally or not, and how/where the data is clocked out to the DAC, i.e. where does the data become synchronous.
I am not quite clear where a DAC comes into this, or why you jumped straight at it. What about the interconnecting cables? Maybe that some are more susceptible to sound variations when fed with FLAC or WAV?

[bobbasrah]

Have you considered fatigue? If after trying for several hours, tiredness can creep in and play funny things on the mind. One's ears also becomes less sensitive over time if you listen to music constantly in a session.

The tests were conducted fresh on weekends so even the Tsoika and beer could not have had an influence the experiment at the time. Later, both flowed, but the test was over....HIC:D
It was raining on both occasions too.... Could that have had an impact do you suppose?:mental:

[Rare Bird]

As i stand now i can hear a difference between the original & FLAC burn, with the streamer i use now i'm happy at that & have no desire to try others (less potential headaches) .I did however try different encoding levels when ripping, i couldnt detect any difference so chose to keep the Default level...

[StanleyB]

It was raining on both occasions too.... Could that have had an impact do you suppose?:mental:
It's funny that you mention this. I have long held the believe that differences in the atmospheric pressure can have an effect on the sound reproduced by a set of speakers. I also think that water droplets in the air can affect the sound at various frequencies. This is not as far fetched as it sounds, considering the speed of sound in water is different to the speed of sound in free air.

[Rare Bird]

Funny you say that Stan i find listerning to headphones in the snow makes them sound eerily different

[StanleyB]

You should try sleet. Nasty listening experience mate.

[bobbasrah]

Funny you say that Stan i find listerning to headphones in the snow makes them sound eerily different

I know that P in snow is silent ;)

[bobbasrah]

Ok, so after that brief diversion of talking wet, we have eatablished that on two different computers on two different systems there were no detectable or notable differences here. So apart from clutching at various straws, the principal variables are resolved, but what is causing this elsewhere?
Stan and Andre have both noted differences, but has this likewise been tested on different computers and audio systems, and if so what are we left with as a cause?
The player ?

[AlexM]

Ok Alex, so with async DAC the timing control is from the DAC, that I understood, but does that mean that the data transfer method is changed from that which would apply say for a drive?
Sorry if that sounds a bit thick :scratch:

No, not at all.

There is no timing information encoded within a FLAC/WAV file, other than symbolic information about sample rate, bit depth etc. in the header. Music stored on a computer’s hard-drive is transmitted using packet-based bus protocols that don't have to be syncronised to the data rate of the encoded file. The timing of the internal busses of are to ensure that the data lines flip at the same time, and their logic levels are read at the same time - nothing to do with music.

Only at playback when audio is streamed through the D/A converter does timing information, and hence jitter, matter. For a DAC this is usually under the control of the local oscillator, along with and reclocking by PLLs or sample rate converters.

USB interfacing has it's own problems, but ayncronous mode USB is employed to remove the dependency of the DAC on the host computer, i.e. allows the local clock to be decoupled from the input clock.

Stan - what USB reciever chip do you use in your DACS?. I'm sure you can give us chapter and verse on this.

Alex

[AlexM]

You lot make I larf. :lol:
The very notion that your going to "explode" any audio myth on an internet forum is as delusional as many of the claims made by the hard core subjectivists.

I'll let you lot exercise your keyboard warrior skills and go do something more useful and more entertaining. ;)

You're probably right, but I'm interested to understand what lies behind the subjective experience that people have. There isn't a worthwhile argument that FLAC compresses without throwing data away, but if the subjective comments are real then there is something wrong with the players or other implementation problems.

Anyway, please don't let me keep you from your more useful and entertaining pursuits!

[bobbasrah]

The frenetic pace seems to have cooled somewhat just as it appeared that the variables were being narrowed down.....

So Alex, while there is a short pause, see if my understanding is clear on this....
The data is transferred to the usb port (in the case examined so far) and onward as normal, but it is at the delivery end (DAC) where timing issues may arise as the data is converted into a digital audio stream (with timing incorporated), for conversion by the DAC into analogue?
This is complicated if the DAC is subject to control by the computer ie non-async?
So this is a data buffering and controlled feed issue ?

[AlexM]

Bob,

I think that the trouble is that there are too many variables to correlate with the subjective observation, i.e. My DAC is jitter insensitive, yours is, mine uses SPDIF from a SB Touch, yours is via async USB, firewire or something else.

I wanted to go through something of a process of elimination to work out which elements of the chain might be influenced by flac encoding/decoding. There is no inherent reason why playing an AIFF, WAV or FLAC copy of the same LPCM data should result in a different data stream being output from the source.

My DAC (or CD player actually) resamples everything to 24/384khz, and the data is deeply buffered to remove jitter. Maybe that is why I can't tell the difference whether FLACs or WAV files are sent to the streamer, even if you accept that local processing overhead has some impact on the timing of the spdif stream from the SB touch.

It would be interesting to see if there is a difference WAV to flac when using the SB Touch via a USB memory stick plugged in the back - at least that takes the server out of the equation. I'll give this a go and see what happens.

Cheers,
Alex

[Ali Tait]

Even the Touch buffers though.

[Welder]

How about approaching this from another angle and researching who says they can hear a difference between Flac and WAV and then consider why it might be in their interest to make such a claim. ;)

Course, if I was manufacturing/selling/promoting a Dac or even another piece of digital Hi Fi equipment and suggested I could hear the difference between a Flac and a WAV file using my equipment might not that generate even a small bit of curiosity in prospective buyers.
Not that I'm a cynic or anything.
Of course, the way to demonstrate its bullshit is to sit the person who claims to be able to tell the difference down with the kit they claim to able to hear the difference on and play them Flac and WAV files.

[bobbasrah]

John, though you had better things to do that listen to this mystery tale ???? Nose itching???? Or it's your inner cynic?

Fair enough on your trial Alex, that is why I have been waiting for over 2 hours now to hear from Stan and Andre what they used to further refine the culprits for the difference they noted.
I think Andre mentioned he was using SB, and noted a difference, although his following statement regarding FLAC compression puzzled me as it implied FLAC was being used in spite of the difference I assumed in favour of WAV. Better go back and re-read that I guess...

Given that there is no theoretical difference between FLAC and WAV, and this is borne out by my own experiments, the only logical conclusion I can come to is that it is some other process, and not the container itself.

PS - I play async usb out to the DAC, but don't have SB or other setup as have no need for them.

PPS - Andre's post - As i stand now i can hear a difference between the original & FLAC burn, with the streamer i use now i'm happy at that & have no desire to try others (less potential headaches) .I did however try different encoding levels when ripping, i couldnt detect any difference so chose to keep the Default level...
My recollection was incorrect.

[Alex_UK]

My boss used to complain that our monthly sales figures were terrible. I stopped using Zip to send him the Excel spreadsheet, and there was an immediate night and day difference in the quality of our figures! Quite remarkable. ;)

[Welder]

My boss used to complain that our monthly sales figures were terrible. I stopped using Zip to send him the Excel spreadsheet, and there was an immediate night and day difference in the quality of our figures! Quite remarkable. ;)

:lolsign::lolsign:

Yep Bob, a bit of both.

Thing is, if some bloke down the pub keeps banging on about how he can do 100mph on his bicycle after everyone has sat around nodding and patting him on the head and saying "yes mate" some arshole like me comes along and says "I think yer full of shit. Get yer bike and lets see you do it".

I realise here on AoS its not accepted practice but that unfortunately doesn't prevent my natural inclination towards aresholism. :eyebrows::lol:

[bobbasrah]

My boss used to complain that our monthly sales figures were terrible. I stopped using Zip to send him the Excel spreadsheet, and there was an immediate night and day difference in the quality of our figures! Quite remarkable. ;)

Well known.....it buggered up the macro in the economics.....:eyebrows:
Once had a boss who up until 2000 when I left, used excel for all his letters so he knew how many lines there were..... Strange people abound....:mental:

[bobbasrah]

:lolsign::lolsign:

Yep Bob, a bit of both.

Thing is, if some bloke down the pub keeps banging on about how he can do 100mph on his bicycle after everyone has sat around nodding and patting him on the head and saying "yes mate" some arshole like me comes along and says "I think yer full of shit. Get yer bike and lets see you do it".

I realise here on AoS its not accepted practice but that unfortunately doesn't prevent my natural inclination towards aresholism. :eyebrows::lol:

Is there not an old joke about that where a guy on a bike kept overtaking a guy's car at increasingly high speed, until his braces snapped off the door handle.....

[AlexM]

Even the Touch buffers though.

Yes, I get about 30 seconds of playback buffering when I disconnect the network cable. It doesn't buffer the output though AFAIK.

Cheers,
A.

[bobbasrah]

It's funny that you mention this. I have long held the believe that differences in the atmospheric pressure can have an effect on the sound reproduced by a set of speakers. I also think that water droplets in the air can affect the sound at various frequencies. This is not as far fetched as it sounds, considering the speed of sound in water is different to the speed of sound in free air.

After 4 hours, still nothing from Stan to further the debate since the above, despite our willingness in trying to get to the bottom of the puzzle that was raised by him.......:scratch:

[dave2010]

Since the decoding takes place in your computer, have you considered that to be the source of the problem?Possibilities:

1. Poor decoding - software errors. Not a FLAC issue, but a player issue.

2. Decoding good, but takes time. If done on computer side this could lead to timing errors, or errors due to improper buffering.

3. Some hardware players, such as the Logitech Touch do FLAC decoding. As 1 - maybe there are errors.

4. Some players, such as the Logitech Touch do FLAC decoding. As 2 maybe timing delays affect the output.

5. Corruption in the communication stream might make a mess of things!

Seems a bit unlikely, but nevertheless corruption in a compressed data stream may cause more errors than corruption in an uncompresssed stream.

[AlexM]

After 4 hours, still nothing from Stan to further the debate since the above, despite our willingness in trying to get to the bottom of the puzzle that was raised by him.......:scratch:

I have discounted Stan's hypothesis - isn't a problem with loss of data through compression/decompression. I'd welcome any further input from him though, if he has one.

Dave,

Some interesting thoughts.

1) most people use the open source libFLAC libraries - these seem to work correctly as proved.
2) Possible, I suppose. I guess the flac is decoded to LPCM data before playout starts, or is it? Do we know if PC audio players put the flac decoder in the audio pipeline, and decode FLACs frame by frame?. If so this could cause software-induced jitter on the output, but again buffering on the DAC should sort it out.
3) As 1)
4) As 2)!
5) Don't know about this.

Cheers,
Alex

[Clive]

I guess the flac is decoded to LPCM data before playout starts, or is it? Do we know if PC audio players put the flac decoder in the audio pipeline, and decode FLACs frame by frame?
For players like Foobar, Jriver etc I believe you'll find it's frame by frame.

For JPLAY it all done before playback starts.

[AlexM]

For players like Foobar, Jriver etc I believe you'll find it's frame by frame.

For JPLAY it all done before playback starts.

Clive,

Thanks - that's useful.

If software-induced jitter is a possible explanation, then predecoding of FLAC before playback should eliminate the effect of this. Anyone compared FLAC to WAV playback using JPLAY?.

Alex

[Clive]

Clive,

Thanks - that's useful.

If software-induced jitter is a possible explanation, then predecoding of FLAC before playback should eliminate the effect of this. Anyone compared FLAC to WAV playback using JPLAY?.

Alex
I listened for it but can't hear a difference. The developers of JPLAY claim they can hear a difference and therefore always use WAV. Sorry, that's not much help!

If there is a difference maybe it's in an area that only some of us are sensitive to?

[sq225917]

If the developers of Jplay can hear a difference then surely they need to work a bit harder on their coding?

[Clive]

If the developers of Jplay can hear a difference then surely they need to work a bit harder on their coding?
Except that I can't hear a difference. Could be their pre-conceptions? Or my hope over reality

[StanleyB]

Stan - what USB reciever chip do you use in your DACS?. I'm sure you can give us chapter and verse on this.
You know something? I looked everywhere on the DAC that I am currently using, but I can't find a USB socket on it.
Do you think that USB could be the problem? Did you say you were using async USB? Might be worth trying optical or coax out from the computer (if possible) to see if the results are still the same. Although a long shot, it could be that the async software is having an effect and not transcribing the data with single bit accuracy?

[StanleyB]

After 4 hours, still nothing from Stan to further the debate since the above, despite our willingness in trying to get to the bottom of the puzzle that was raised by him.......:scratch:
It's a general thread so one should give others the chance to contribute towards the overall discussion ;).


I listened for it but can't hear a difference. The developers of JPLAY claim they can hear a difference and therefore always use WAV. Sorry, that's not much help!

If there is a difference maybe it's in an area that only some of us are sensitive to?
Very interesting that the JPLAY developers have come to the same conclusion as me. Maybe products and software developers do have a higher sensitivity in noticing differences. It cannot be discounted.


If the developers of Jplay can hear a difference then surely they need to work a bit harder on their coding?Why? So that they can also get mp3 to sound just as good as WAV?

[AlexM]

You know something? I looked everywhere on the DAC that I am currently using, but I can't find a USB socket on it.
Do you think that USB could be the problem? Did you say you were using async USB? Might be worth trying optical or coax out from the computer (if possible) to see if the results are still the same. Although a long shot, it could be that the async software is having an effect and not transcribing the data with single bit accuracy?

Haha - very good :). I assumed you were talking about a DAC with a USB output. Which USB receiver do you use in your DACs?.

I think that some DACs will react differently to jitter on frames recieved over USB depending on how they implement FIFO queues internally, and read out the buffer.

I think of it as analagous to a big bucket with a small hole in it at the bottom. As long as the bucket doesn't empty then the rate of outflow will be relatively constant. The timing of the frames arriving into the bucket isn't too critical as long as the average data rate ensures that the buffer never empties out.

I use a coax SPDIF output from the SB Touch into a Cambridge Audio CA840C. The SB Touch outputs data over SPDIF at a constant rate, regardless of what happens to the TCPIP network. In fact, if I disconnect the network cable, the buffer will play constantly for about 30 secs, so tolerance to network jitter and latency is pretty good!.

Cheers,
Alex

[Clive]

I think of it as analagous to a big bucket with a small hole in it at the bottom. As long as the bucket doesn't empty then the rate of outflow will be relatively constant. The timing of the frames arriving into the bucket isn't too critical as long as the average data rate ensures that the buffer never empties out.
It this part that my experience suggests isn't so and I can't explain why. It seems that the better timing of the data arriving with several DACs I've tried, the better the sound quality. Maybe DAC-based re-clocking can only do so much - meaning data only has a narrow window within which it needs to arrive for re-clocking to be optimal.

[Welder]

Clive.
I wondered if you had (assuming you have more than one core) split the core loading so only audio data moves through one core and compared this configuration to loading a complete track to RAM?

[AlexM]

Clive,

Yes I think you are right because my analagy isn't actually how most DACs work, although mine does work like this and so does the SBT that sits in front of it.

I think a lot of DACs have a very shallow FIFO buffer, and use a PLL to slave the local clock to the long term average clock of the incoming signal. One might think that if this is wandering all over the place (quite possible), then the PLL will be skewing the DAC's local clock to track this.

Higher frequency jitter spectrum on the input will be be easily fixable with a small buffer, but low frequency jitter (a few Hz) would need quite a bit more buffering to eliminate.

A digital equivilent of analogue wow? ;).

Cheers,
Alex

[Clive]

Clive.
I wondered if you had (assuming you have more than one core) split the core loading so only audio data moves through one core and compared this configuration to loading a complete track to RAM?
John, I haven't locked the audio process to a core, I would expect that to help. What works so very well with JPLAY is hib mode, this kills the rest of the computer very effectively but it's not very user friendly either!

[bobbasrah]

Well things seem to be moving along apace...
The desktop, laptop and the other laptop used in the tests I mentioned earlier which failed to replicate the issue were all multi-core machines for everyday use, running XP, 7 and 7 respectively.
The USB receiver Stan uses is the PCM2902 according to the website for TC-7520 if that makes any difference.
Stan, can you recollect the equipment used and how it was coupled when you noted these differences? I presume you used your own DAC when you discovered this?
It may or may not be related, but it may help flesh out the circumstance to further isolate the cause.

One other thing I forgot to mention (reported previously on issues over async b adaptive v spdif) for fullness was that we also connected my dac on usb to the optical input on my pal's DAC to see if that made any difference in the test, there was also no change in terms of the FLAC/WAV issue. There was however a qualitative difference for the better over the direct optical to his DAC which we both found surprising from a cheap chinese async DAC.

Could the issue really be as complex as the combination of player, processor and DAC implementation, perhaps even the OS?
If it helps, I can give a full rundown on my desktop and laptop where the problems do not arise?

[StanleyB]

Stan, can you recollect the equipment used and how it was coupled when you noted these differences? I presume you used your own DAC when you discovered this?
It may or may not be related, but it may help flesh out the circumstance to further isolate the cause.
I am having to refrain from comments at this moment in time. Clive mentioned something of significant commercial importance that needs further investigation:eyebrows:.

As I mentioned before, I was not using USB. I mainly use optical or coax. The speakers are the NS1000M. DACs were varied, but not necessarily available on a commercial basis. Some are prototypes.

[ZebuTheOxen]

Why not compare the digital output of all these files? Once post-decoder and once at the output stage?
Inverting signal A and removing it from signal B, and vice versa will give you absolute differences across the entire spectrum being transferred, if there are any.

[bobbasrah]

I am having to refrain from comments at this moment in time. Clive mentioned something of significant commercial importance that needs further investigation:eyebrows:.

As I mentioned before, I was not using USB. I mainly use optical or coax. The speakers are the NS1000M. DACs were varied, but not necessarily available on a commercial basis. Some are prototypes.

Ok, presumably in due course, the investigations of the lads will narrow down the suspects. The considerations are certainly wide ranging.

For the moment we can ascribe the difference noted in your own case between FLAC and WAV to be relate NOT to USB for certain, and using DACs which may or may not be in the marketplace, some of which may have been prototypes.:scratch:
Did Andre not have similar experience presumably in less experimental circumstances? I wonder if there is a commonality?:scratch:

[StanleyB]

Did Andre not have similar experience presumably in less experimental circumstances? I wonder if there is a commonality?:scratch:
I think that some of the more modern DAC chipsets are far better in detecting even minute differences in the audio signal. The compression/decompression process that a FLAC file experiences is probably leaving behind artefacts that are affecting the sound. Less detailed digital to analogue conversions are incapable of noticing these minute differences. I reckon that is why so few people have been able to notice the difference.
I compared the APE audio format against the FLAC and WAV ones. No problem with APE. So it is without any shadow of a doubt an issue solely related to FLAC and no other lossless format. But only the low jitter receiver chips seem to be able to pick out the problem. The common (and higher jitter) SC8416 fails to resolve the difference, whilst the superior low jitter WM8804/5 is far better at it.
But note that these are just my test results. Other DAC designers/testers/owners who have access to DACs with differing receiver chips might be able and willing to disclose their test results in due course.

[dave2010]

I think that some of the more modern DAC chipsets are far better in detecting even minute differences in the audio signal. The compression/decompression process that a FLAC file experiences is probably leaving behind artefacts that are affecting the sound. Less detailed digital to analogue conversions are incapable of noticing these minute differences. I reckon that is why so few people have been able to notice the difference.
I compared the APE audio format against the FLAC and WAV ones. No problem with APE. So it is without any shadow of a doubt an issue solely related to FLAC and no other lossless format. But only the low jitter receiver chips seem to be able to pick out the problem. The common (and higher jitter) SC8416 fails to resolve the difference, whilst the superior low jitter WM8804/5 is far better at it.
But note that these are just my test results. Other DAC designers/testers/owners who have access to DACs with differing receiver chips might be able and willing to disclose their test results in due course.I've followed this with some interest. Firstly, assuming FLAC is working properly, there is absolutely no loss of data, and a round trip of the form:

File1 -> FLAC compression -> FLAC decompression -> File2

should show that the data in File1 is EXACTLY equal to File2.
If this is not the case, then there is a problem with the compression or decompression process.

There is nothing approximate about lossless compression/decompression.

It is the case that some lossless methods may make use of a lossy component, which in the case of audio could be mp3 or aac. Essentially they do something roughly equivalent to a round trip compression/decompression cycle, and then subtract the result from the input to give a residual. The residual is then compressed and then stored and/or transmitted.

Various techniques are used for the digital encoding, such as run length encoding and Huffman encoding, both of which are not lossy.

It is claimed that FLAC files sound different from, for example, WAVs. This could be due to problems in implementation in either FLAC or WAV playback.
If the claim is that FLAC files sound worse than equivalent WAV, then clearly WAV is being used as the reference, and preferred. It does not automatically follow that a difference in perceived sound implies one is better than the other. Let's assume for the moment that FLAC does sound inferior.

With either format, the data is converted ultimately to a data stream which is fed into a DAC. If both FLAC and WAV based systems are working properly, the data stream to the DAC should be identical.

Ways in which they may then sound different should then only be due to timing issues, or possibly corruption in the data. Corruption is unlikely under normal circumstances. If the data is buffered sufficiently just before the DAC, there should be no difference. Note though that if there is any data corruption in compressed format data, that the audible effects could be worse (though not necessarily so) compared with similar corruption in other formats, because it is possible that data corruption in compressed data could lead to error propagation effects. This kind of situation can arise in video encoding/decoding in, for example, MPEG, where if the I frames are corrupted, the errors will propagate through frames up to the next I frame.

It does not follow that such corruption in compressed audio streams will always lead to significantly worse sounding output, as it's possible that the corruption is in part of the signal which has little perceptual effect. In both audio and video encoding and transmission, it is now common to protect parts of the encoded data which are more likely to have a damaging effect if they are corrupted to a higher degree of protection than other components.

[AlexM]

Stan,

Here is an experiment maybe you can try.

Looking at the datasheets of some of the reciever chips, most seem to have a pin that is used to indicate sync problems with the SPDIF frames. typically these are used to light an LED when there is a sync issue.

It would be interesting to connect this output to a counter and play music in wav and flac formats, and see if there is any difference caused by either jitter ourside of the reciever's tolerance or problems with the electrical interface.

Sync is usually locked by successful reception of the preamble bits in an SPDIF frame, and is unlikely to error during reception of the rest of the frame (although not impossible).

Cheers,
A.

[bobbasrah]

I think that some of the more modern DAC chipsets are far better in detecting even minute differences in the audio signal. The compression/decompression process that a FLAC file experiences is probably leaving behind artefacts that are affecting the sound. Less detailed digital to analogue conversions are incapable of noticing these minute differences. I reckon that is why so few people have been able to notice the difference.
I compared the APE audio format against the FLAC and WAV ones. No problem with APE. So it is without any shadow of a doubt an issue solely related to FLAC and no other lossless format. But only the low jitter receiver chips seem to be able to pick out the problem. The common (and higher jitter) SC8416 fails to resolve the difference, whilst the superior low jitter WM8804/5 is far better at it.
But note that these are just my test results. Other DAC designers/testers/owners who have access to DACs with differing receiver chips might be able and willing to disclose their test results in due course.

Stan, I think you can agree that if I can send 24/192 with no detectable difference between FLAC and WAV, the SPDIF receiver is doing it's job in passing forward that 24/192 to the DAC. If lesser SPDIF receivers cannot cope with the datastream that is another matter, but this is not the case.:eyebrows:

Where you said “ Less detailed digital to analogue conversions are incapable of noticing these minute differences”, that was already investigated as I said previously on my mate's esoteric DAC (less than 1 year old), where no differences were noted either. I know his DAC is very serious money Stan, and is as far removed from being “Less detailed digital to analogue conversion” as can be. It is equally unlikley to contain a “common” SPDIF receiver.:doh:

As an aside to the assertion however, if a “superior”SPDIF” receiver such as you cite, lets through something other than the 24/192 datastream, I would seriously question whether that is an advance, irrespective of where the problem arose.:mental:

Out of curiosity, which media player were you using for these tests?

[StanleyB]

As an aside to the assertion however, if a “superior”SPDIF” receiver such as you cite, lets through something other than the 24/192 datastream, I would seriously question whether that is an advance, irrespective of where the problem arose.:mental:
well if you think I am mental or completely wrong then there is no purpose in me continuing with this discussion :).

[bobbasrah]

well if you think I am mental or completely wrong then there is no purpose in me continuing with this discussion :).

No Stan I do not think you are mental, nor inferred it, what I referred to was that is the advanced receiver such an advance if it lets through what is not intended, whereas the previous generation did not, yet fulfilled it's technical purpose?. :)

[synsei]

Perhaps your ears aren't flapping at the right speed Bob, try upping the frequency to 128 flaps per second, that should get you sorted... :D

[bobbasrah]

Perhaps your ears aren't flapping at the right speed Bob, try upping the frequency to 128 flaps per second, that should get you sorted... :D

My ears should be burning judging by the last response from the only one so far to raise the issue on this thread..... :rolleyes:
Neat trick on the flap frequency, and if it helped get to the bottom of this riddle, believe me I would try it.:steam: There, does that look like wings?

Daft though it sounds, it is intriguing what has been claimed. Despite being something that made no sense to me, I was open minded enough previously to investigate it, and found nothing with the variables available.:mental:
Maybe it existed, and I just didn't find it, but thereby it is not the universal truth that was stated. :eek:
Don't get me wrong, I don't want the problem, and don't experience the problem, but if it has a cause, it would be good to get to the bottom of it.....finally...;)
I had thought that this thread might help focus on and identify the claimed phenomenon once and for all but it seems to be intriguingly elusive...:rolleyes:

[synsei]

It is an intriguing issue Bob but not one I'm going to lose any sleep over. The technical side of it is way over my head but just for kicks and giggles I tried a comparison a little earlier and my ears can't detect the difference. I'm sure there are a million reasons as to why not but I couldn't care less as long as that remains the case ;)

[bobbasrah]

It is an intriguing issue Bob but not one I'm going to lose any sleep over. The technical side of it is way over my head but just for kicks and giggles I tried a comparison a little earlier and my ears can't detect the difference. I'm sure there are a million reasons as to why not but I couldn't care less as long as that remains the case ;)

Totally agree on that summation, and thankfully the other lads here are a lot more technically skilled than I to chase this paricular ghost from a more scientific and objective viewpoint.;) I am just observing...
Considering the phenomenon, it is surprising that so few are here backing up the assertion to find the cause....:mental:

[magiccarpetride]

Totally agree on that summation, and thankfully the other lads here are a lot more technically skilled than I to chase this paricular ghost from a more scientific and objective viewpoint.;) I am just observing...
Considering the phenomenon, it is surprising that so few are here backing up the assertion to find the cause....:mental:

Interesting discussion. I've been getting more and more interested in digital music reproduction during the past 12 months or so, which led me to 'discover' that there may be more to it than meets the eye. But it sure does meet the ear.

My inherent flaw is that I am absolutely not equipped well enough with requisite knowledge when trying to explain the differences detected by the ear. Whilst the stuff that meets the eye seems orderly and neat and everything just snaps into focus and obeys the laws of coherent logical reasoning, where things get hairy is at the ear-to-brain level. Of course, what's exacerbating the situation is that those hairy ear-to-brain experiences can oh-so-easily be explained away by generalizations such as 'expectation bias' and 'placebo'.

So we have a very peculiar situation right now where the theory is impotent when it comes to detecting any possibility of differences between extremely wild variety of digital configurations, while the practice is fertile with experiential evidence indicating audible differences. A veritable lose/lose situation when it comes to discussing these things in a civilized forum.

Let me just say this: there is, to my ears, a detectable and not so subtle difference between streaming FLAC straight into SBT vs. decoding FLAC to PCM on the Squeezebox Media Server, and then streaming PCM to the SBT player. Go figure...

As the idiom goes, "seeing is believing and hearing is a bitch."

[dave2010]

Let me just say this: there is, to my ears, a detectable and not so subtle difference between streaming FLAC straight into SBT vs. decoding FLAC to PCM on the Squeezebox Media Server, and then streaming PCM to the SBT player. Go figure...

As the idiom goes, "seeing is believing and hearing is a bitch."Are we to assume that the streamed PCM to the SBT sounds better? Maybe they just sound different. Do you have any recommendations for recordings (CDs) so that we can test this out ourselves? Or can someone provide one or two high quality tracks for such a test?

[magiccarpetride]

Are we to assume that the streamed PCM to the SBT sounds better? Maybe they just sound different. Do you have any recommendations for recordings (CDs) so that we can test this out ourselves? Or can someone provide one or two high quality tracks for such a test?

Better is largely a subjective assessment. If by 'better' we are to assume smaller but more sharply focused soundstage, then yes.

Any FLAC would do, my preference is to listen to something I'm extremely familiar with (for example, Santana "Abraxas").

[bobbasrah]

Thank you Alex....Finally another difference noted....

Not conversant with SBT, but when trying to find out about it, came across a similar note on a review on the Logitech site from last December which contained the following-
"Having said that I noticed that due to incoming jitter from for my nas I could hear a difference in sound quality( same song) between FLAC ( 24b 96KhZ and PCM (24b 96KHz) . With PCM is was better then with Flac. The processing power in the Touch is likely not big enough to do this job right. I converted all my HD Flac music to HD PCM to overcome this problem."
Alex's situation seems similar.

Andre mentioned a difference earlier on a HRT Streamer which is I believe a usb powered DAC (?) but has not clarified it yet.

[AlexM]

About a year ago I experimented with streaming LPCM rather than FLAC to the SB Touch, having read that this change can improve the sound. You do this by decoding the FLACS on the server rather than let the SB Touch do it.

I got my hopes up, I was somewhat disappointed to find that I could find no difference at all. I switched back and forth several times to try to find an aspect that had changed, but failed utterly.

I reverted back again, and have left it like that since. I have a stonking Gigabit network at home, so I wonder if that was a factor in minimising any potential changes?.

I have quite a few 24/96 Vinyl rips in native WAV that I will so some experiemtation over the weekend.

Cheers,
Alex

[dave2010]

One concern I have relates to the symmetry of the encode/decode process with FLAC. There are slightly similar issues with lossy compression, such as MP3 and AAC, but the specifications of those compression/decompression systems are such that errors are allowed, though should be within reasonable limits. There different playback/systems could, in theory, give very slightly different results. Since such systems are designed to be lossy, this should be acceptable, given the applications. Thus if different playback systems are used there could be slight differences on the same source material, within tolerance limits.

For lossless systems the specifications must be such that there is no difference between different playback systems, and the original data should be replicated precisely by the decompressed data following a round trip.

I note that systems such as FLAC contain essentially at least a lossy encoder in the encoder, and a matching lossy decoder within the lossless decoder. Some lossless systems could even have lossy encoders and decoders in the encoder, and also in the decoder. It occurs to me that if these lossy components are not matched, that this will be a possible source of errors. Indeed, the arithmetic used in such internal components could also have an effect. I don't know how well FLAC encoder/decoders have been designed, but if, for example the lossy components use floating point operations, some consideration would have to have been given to accuracy issues. However, the lossy components may have been designed using integer arithmetic, which would presumably ensure consistency across different hardware systems. The point is that for a lossless system there can be no errors, not even small ones. Small errors could arise if internal lossy components are used without sufficient care, and could thus appear at the outputs.

I just don't know enough about how systems like FLAC and Alac have been designed at the implementation level to know how robust these "standards" are. Hopefully they are robust, but I'm not sure how confident we can be of that.

[bobbasrah]

Curiouser and curioser... But so far this appears limited to SBT use, not standalone DAC's hanging off a computer.

Alex, Canada - Were the sources you found the difference with normal CD rips or 24/96. and was this to the Touch to amp or through the Touch to DAC to amp?

Alex, UK - I presume that your previous test was on redbook, but this time you will be trying WAV v FLAC on hirez files? Again is this direct from the Touch or otherwise please?

Assuming as Dave has already raised, that under normal circumstance there should be no change to the decompression process, is that affected by processing power, which demands increased with the higher resolution files perhaps?

[AlexM]

Bob,

Yes, my previous tests were on CD rips to FLAC at 16/44, and played from the Logitech Media Server rather than directly from the SB Touch via USB memory stick.

Over the weekend, I plan to test
1) FLAC vs LPCM @ 16/44 from the SB Touch
2) Hi-res LPCM vs. FLAC at 24/96 from Logitech Media Server
3) Hi-res LPCM vs. FLAC from the SB Touch.

My Hi-res LPCM test files are 24/96 from Vinyl via my CJ PV-15 phono MC preamp, with A/D via EMU 0404 USB.

Regards,
Alex

[AlexM]

One concern I have relates to the symmetry of the encode/decode process with FLAC. There are slightly similar issues with lossy compression, such as MP3 and AAC, but the specifications of those compression/decompression systems are such that errors are allowed, though should be within reasonable limits. There different playback/systems could, in theory, give very slightly different results. Since such systems are designed to be lossy, this should be acceptable, given the applications. Thus if different playback systems are used there could be slight differences on the same source material, within tolerance limits.

For lossless systems the specifications must be such that there is no difference between different playback systems, and the original data should be replicated precisely by the decompressed data following a round trip.

I note that systems such as FLAC contain essentially at least a lossy encoder in the encoder, and a matching lossy decoder within the lossless decoder. Some lossless systems could even have lossy encoders and decoders in the encoder, and also in the decoder. It occurs to me that if these lossy components are not matched, that this will be a possible source of errors. Indeed, the arithmetic used in such internal components could also have an effect. I don't know how well FLAC encoder/decoders have been designed, but if, for example the lossy components use floating point operations, some consideration would have to have been given to accuracy issues. However, the lossy components may have been designed using integer arithmetic, which would presumably ensure consistency across different hardware systems. The point is that for a lossless system there can be no errors, not even small ones. Small errors could arise if internal lossy components are used without sufficient care, and could thus appear at the outputs.

I just don't know enough about how systems like FLAC and Alac have been designed at the implementation level to know how robust these "standards" are. Hopefully they are robust, but I'm not sure how confident we can be of that.

Dave,

You can read about FLAC encoder design at http://flac.sourceforge.net

The site says that all arithmetic operations are Integer to ensure that that they don't create rounding errors in encode/decode, and that only integer sample formats are supported. FLAC has a formal test suite, so it is quite robust, at least if the devices are using the reference implementations of the encoder/decoder. Even if they don't the lossless nature of the encoder/decoder can be verified. The FLAC encoder compresses the signal by approximating a simple polynomial function or using linear predictive coding. The residual error isn't lost or discarded - the residual from the modelling is encoded using a variant of Huffman encoding called Rice codes. Thus, the original values will be reconstructed perfectly by the decoder or not at all. To be doubly sure, the operation of the encoder can be verified by running the decoder in parallel and comparing the input and output with the -v option.

I am paraphrasing and simplifying the process greatly here, and any errors in the description are mine!.

Here is a section from the FAQ that is relevent to the discussion here.


How can I be sure FLAC is lossless?
How much testing has been done on FLAC?

First, FLAC is probably the only lossless compressor that has a published and comprehensive test suite. With the others you rely on the author's personal testing or the longevity of the program. But with FLAC you can download the whole test suite and run it on any version you like, or alter it to test your own data. The test suite checks every function in the API, as well as running many thousands of streams through an encode-decode-verify process, to test every nook and cranny of the system. Even on a fast machine the full test suite takes hours. The full test suite must pass on several platforms before a release is made.

Second, 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.

Finally, FLAC is used by many people and has been judged stable enough by many software and hardware makers to be incorporated into their products.

Cheers,
Alex

[AlexM]

P.S. my post above is definately my dullest ever.. sorry :).

I do think it is worth understanding something about how FLAC works, if only to end the suspicion that it isn't really lossless!. Your data wasn't harmed in the making of this flac file.

[bobbasrah]

Bob,

Yes, my previous tests were on CD rips to FLAC at 16/44, and played from the Logitech Media Server rather than directly from the SB Touch via USB memory stick.

Over the weekend, I plan to test
1) FLAC vs LPCM @ 16/44 from the SB Touch
2) Hi-res LPCM vs. FLAC at 24/96 from Logitech Media Server
3) Hi-res LPCM vs. FLAC from the SB Touch.

My Hi-res LPCM test files are 24/96 from Vinyl via my CJ PV-15 phono MC preamp, with A/D via EMU 0404 USB.

Regards,
Alex

Sounds good Alex, and results should prove interesting as you will know the test pieces intimately...:D

It is disappointing that nobody is posting the problem with a different computer/DAC combo, since if it is indeed a universal truth as claimed, the power of the computer/OS/Player could be examined and quantified as a contributory element.:scratch:

Shame, but for now, investigation of this issue is of necessity restricted to the Squeezebox.

Good luck in the tests :cool:

[sq225917]

Thank you Alex....Finally another difference noted....

Not conversant with SBT, but when trying to find out about it, came across a similar note on a review on the Logitech site from last December which contained the following-
"Having said that I noticed that due to incoming jitter from for my nas I could hear a difference in sound quality( same song) between FLAC ( 24b 96KhZ and PCM (24b 96KHz) . With PCM is was better then with Flac. The processing power in the Touch is likely not big enough to do this job right. I converted all my HD Flac music to HD PCM to overcome this problem."
Alex's situation seems similar.



The problem is that unless the guy has double blinded it, we don't know if what he says he hears, he really does, and his speculation about incoming jitter is just that-speculation. Does he provide the jitter measurements, no. Does he even tell you if the signal is coming via spdif, or Ethernet, because ethernet is unaffected by jitter as it's async. There's an awful lot of speculation and precious little proof. That's fine, as this is a subjective forum but one should fall into the trap of presenting subjective findings as anything other than opinion.

[AlexM]

The problem is that unless the guy has double blinded it, we don't know if what he says he hears, he really does, and his speculation about incoming jitter is just that-speculation. Does he provide the jitter measurements, no. Does he even tell you if the signal is coming via spdif, or Ethernet, because ethernet is unaffected by jitter as it's async. There's an awful lot of speculation and precious little proof. That's fine, as this is a subjective forum but one should fall into the trap of presenting subjective findings as anything other than opinion.

+1

A server cannot jitter ethernet packet data as it the stream doesn't contain any timing info. If there is an audible difference experienced, it isn't because of more or less jitter FLAC vs. PCM. I don't think that the CPU on the touch is underpowered as I see CPU utilisation of 12-14% playing 24/88Khz FLAC, including it running a terminal session and TOP!.

I think that in some ways an ethernet connection between PC and DAC is possibly a superior scheme to SPDIF/USB connection in that time domain information must be locally generated by the Player or DAC, with less external influences to cause jitter.

[AlexM]

Correction...

That is 12-14% playing a 24/88 FLAC with server decoding to WAV, and 20-27% with FLAC decoding on the SB Touch.

So there does appear to be more variability in CPU load when using FLAC over WAV, but this doesn't necessarily mean more jitter at the SPDIF output and the CPU isn't too busy.

[bobbasrah]

The problem is that unless the guy has double blinded it, we don't know if what he says he hears, he really does, and his speculation about incoming jitter is just that-speculation. Does he provide the jitter measurements, no. Does he even tell you if the signal is coming via spdif, or Ethernet, because ethernet is unaffected by jitter as it's async. There's an awful lot of speculation and precious little proof. That's fine, as this is a subjective forum but one should fall into the trap of presenting subjective findings as anything other than opinion.

I absolutely and totally agree :cool:
Problem is that the same critieria should apply throughout, and the reason for the thread itself is that precise absence of detail and proof which supports the opinion or claim as to the problem in the first place.:mental:

[Chops]

I've seen some concerns expressed over the processing power of the SBT, so I thought I'd do a little experiment.

First, my setup is Netgear ReadyNAS Duo with LMS -> SBT (with all Soundcheck mods applied except -k, buffersize 4000us) -> Chord QBD76 (with full (4 sec) buffering, although this doesn't seem to work on hi-res). 100Mbps wired Ethernet.

I tried a variety of music (all classical) of differing bit rates as you'll see below.

I used 'top' to measure CPU activity. Its fairly lightweight, taking only about 2% max CPU. I used 2 sample rates: 20 secs to get a rough average and 2 secs to try to observe peaks.

Please note that these are all observed so please don't take them as definitive. They are the best I could do quickly (I did take a number of samples of each though).

So the results:


Beethoven Piano Concerto 5 'Emperor' - 1. Allegro - Emil Gilels, Philharmonia Orchestra, EMI Classics


16bit/44.1kHz

FLAC file downloaded to SBT as FLAC - 678kbps VBR



20 sec sample - approx 75-80% idle, 5-10% sirq
2 sec sample - min idle 71%, max sirq 12%


FLAC file converted to PCM on NAS and then downloaded to SBT as PCM - 678kbps VBR (converted to 1411kbps PCM)



20 sec sample - approx 75-80% idle, 10-15% sirq
2 sec sample - min idle 67%, max sirq 22%



Beethoven Piano Concerto 5 'Emperor' - 1. Allegro - Artur Pizaro, Scottish Chamber Orchestra, Linn


24bit/96kHz

FLAC file downloaded to SBT as FLAC - 2467kbps VBR



20 sec sample - approx 25-40% idle, 30-50% sirq
2 sec sample - min idle 38%, max sirq 60%

PCM file downloaded to SBT as PCM - 4608kbps CBR



20 sec sample - approx 10-15% idle, 55-75% sirq
2 sec sample - min idle 0%, max sirq 80%



Pergolesi Concerto Grosso no 12 'La follia' per archi e cembalo, I Musici, Fone Records


24bit/96kHz

FLAC file downloaded to SBT as FLAC - 3024kbps VBR



20 sec sample - approx 20-45% idle, 30-50% sirq
2 sec sample - min idle 0%, max sirq 95%


PCM file downloaded to SBT as PCM - 4608kbps CBR



20 sec sample - approx 5-20% idle, 55-75% sirq
2 sec sample - min idle 0%, max sirq 93%



Mozart Symphony No. 38 in D major (‘Prague’), K.504 - I Adagio - Allegro - Scottish Chamber Orchestra, Linn


24bit/88.1kHz

FLAC file downloaded to SBT as FLAC - 2477kbps VBR



20 sec sample - approx 35-45% idle, 30-40% sirq
2 sec sample - min idle 21%, max sirq 50%


PCM file downloaded to SBT as PCM - 4233kbps CBR



20 sec sample - approx 10-20% idle, 60-70% sirq
2 sec sample - min idle 1%, max sirq 76%

One observation. The sirq-net-rx/0 process made up most of the sirq figure.

I don't feel qualified to comment precisely on the above. Broadly, however, the SBT CPU appears to struggle with hi-res PCM, but maybe its still OK. Is SqueezOs real-time embedded Linux and if so, is it designed to cope? Does its own buffering eliminate these problems?

I normally run my setup with FLAC->PCM conversion taking place on the NAS for 16/44.1 files and, through experience, use hi-res PCM files because the NAS struggles with the conversion. It generally sounds pretty good to me, although I haven't compared FLAC vs PCM on the SBT. One small issue is that I get a very small amount of 'crackling' on the Pergolesi track (above), but not on any other hi-res albums that I've noticed.

Chris

[Ali Tait]

If there is any sound difference due to processor use, would this not be shown up by encoding a track at different compression levels and comparing the result?

[bobbasrah]

If there is any sound difference due to processor use, would this not be shown up by encoding a track at different compression levels and comparing the result?

My recollection of Flac was that decode loading is virtually the same, it is the encode that loads the processor, but I may be mistaken Ali...:scratch:

[AlexM]

Chris,

Good data - thanks for that. I'll comment on the TOP figures in a bit.

What leaps out at me is that CPU utilisation seems to be higher when playing Hi-Res LPCM than when playing Hi-Res FLAC. It seems that managing data coming over the network interface is a greater CPU overhead than decoding the FLACS - I didn't expect that!. Just to clarify, where you say 'PCM file downloaded to SBT as PCM' do you mean that the source FLAC was decoded to PCM by the server, or by you off-line?. What was your subjective experience?.
Cheers,
Alex

[Chops]

That is 12-14% playing a 24/88 FLAC with server decoding to WAV, and 20-27% with FLAC decoding on the SB Touch.

Alex, was that total CPU time or one of the components such as usr? My observations are a bit different, ie for the 24/88.1 track:


WAV (PCM) on the SBT, total CPU 80-90%
FLAC on the SBT, total CPU 55-65%

I bought the file as FLAC and converted to PCM in Foobar.


Quite a difference! Hope I haven't missed something?



Chris

[Chops]

It seems that managing data coming over the network interface is a greater CPU overhead than decoding the FLACS - I didn't expect that!

Agreed. I was quite surprised. On the basis of that, I'm wondering about going back to delivering FLAC files to the SBT and ignore the subject of this thread.:scratch:

Chris

[AlexM]

Alex, was that total CPU time or one of the components such as usr? My observations are a bit different, ie for the 24/88.1 track:


WAV (PCM) on the SBT, total CPU 80-90%
FLAC on the SBT, total CPU 55-65%

I bought the file as FLAC and converted to PCM in Foobar.


Quite a difference! Hope I haven't missed something?

Chris

Chris,

below is my top screenshot while playing Mozart Symphony No. 38 in D major (‘Prague’), K.504 - I Adagio - Allegro - Scottish Chamber Orchestra, Linn (same as you!).

I was misinterpreting what we are seeing, so scratch my previous comments.

The CPU is CPU utilisaton at the time of the last screen refresh, split by process type. process %CPU refers to the percentage of the CPU cycles used by a process since the last screen repaint, excluding idle time (I think). My CPU utilisation for usr processes does range from 20-27 percentage (mainly JIVE), averaging 22% while playing this piece of music, without transcoding on the server. Idle time is 20-38%.

CPU utilisation with the same music does seem to be quite a bit higher when streaming PCM from the server. I conclude that I will go back to streaming FLAC, and that FLAC decoding is pretty light-weight!.

Cheers,
Alex

Mem: 76776K used, 49072K free, 0K shrd, 8736K buff, 19416K cached
CPU: 24% usr 11% sys 0% nic 18% idle 0% io 4% irq 41% sirq
Load average: 3.07 2.06 1.68 4/70 862
PID PPID USER STAT VSZ %MEM %CPU COMMAND
7 2 root SW< 0 0% 33% [sirq-net-rx/0]
731 1 root R 42440 34% 27% /usr/bin/jive
771 731 root S 7148 6% 9% jive_alsa -d hw:0,0 -c default -b 3400 -p 2 -s 24 -f 3
9 2 root SW< 0 0% 7% [sirq-tasklet/0]
49 2 root SW< 0 0% 2% [IRQ-34]
258 2 root SW< 0 0% 2% [IRQ-57]
862 861 root R 2728 2% 0% top
5 2 root SW< 0 0% 0% [sirq-timer/0]
860 635 root S 2532 2% 0% dropbear -i
635 1 root S 2808 2% 0% /usr/sbin/inetd
615 1 root S 2732 2% 0% /sbin/syslogd -S
.
.
.

[Vincent Kars]

Is this testing done using WiFi or is it Ethernet?

[bobbasrah]

Holy Toyah Wilcox...Itth a mithtawee....

[synsei]

:lolsign::lolsign::lolsign:

[AlexM]

Is this testing done using WiFi or is it Ethernet?

Ethernet only in my case!

[Chops]

Alex, looks like you have 0% idle, ie the CPU is fully utilised. What sample rate did you use in top?

I've attached the top output from the same on my system. 6092. It show 7% idle (93% busy). I've found this varies according to what part of the piece you're playing, so later in this movement has a lower idle rate.

Have you applied the soundcheck mods? They change some process priorities. I think the effect of this will be that if there's CPU available (ie %idle > 0) then any process requiring it will get what it wants, but if there's a shortage then those with a higher priority win out. Now, even with a 2 sec sample rate in top, you wont see the real transient peaks in CPU demand - the 2 sec sample will smooth them out. If %idle is getting low (and I'm not sure what that figure is) then SQ could very well be affected.

Just to summarise what I think this means.


16/44.1 files appear to be dealt with comfortably by the SBT regardless of whether FLAC or PCM. This doesn't answer the debate about the ability of the DAC to convert them equivalently.
With hi-res files, the SBT appears to become more stretched, especially PCM. The higher the resolution, the more this is apparant. Even the Pergolesi FLAC file showed 0% idle on a 2 sec sample, although generally it was >10%. This may affect SQ when the device runs out of processing power (here I will defer to someone with greater expertise of how SqueezeOs deals with this kind of situation). This could inform the debate about SQ of FLAC vs PCM.

Chris

[Chops]

Is this testing done using WiFi or is it Ethernet?

100Mbps wired Ethernet.

[AlexM]

Chris,

Does my top output not show 18% idle time?. it does go up when the SB Touch is refilling it's buffer, but I see on average 30% idle time when playing flac decoded on the SB touch (see screenshot).

I do have the Soundcheck mods applied, 3400us buffer, WLAN disabled, digital output only.

Regards,
Alex

[Chops]

Does my top output not show 18% idle time?. it does go up when the SB Touch is refilling it's buffer, but I see on average 30% idle time when playing flac decoded on the SB touch (see screenshot).

I do have the Soundcheck mods applied, 3400us buffer, WLAN disabled, digital output only.


Apologies Alex, you're right about 18% idle - I misread your output.:doh:

30% idle is in the same region as my results (35-45%, 20 sec sample rate). This does seem to vary dependant on what part of the file is being played. For the Mozart, I (generally) saw higher %idle earlier on.

The rest is the same as mine except I'm on 4000us buffersize.

Chris

[bobbasrah]

Chris, Alex, you appear to be finding greater processing requirements for the hirez files but the reverse of what was expected? Is that correct?
But this is not so obviously the case for redbook?

Although this is no measure of the DAC's behaviour, it does imply the processing is stretching albeit for the reverse to what was considered likely.

Have either of you played the output to assess whether this results in any audible difference? Not better or worse, just audible...

[Chops]

Chris, Alex, you appear to be finding greater processing requirements for the hirez files but the reverse of what was expected? Is that correct?
But this is not so obviously the case for redbook?

Bob, the sirq-net-rx/0 process appears to cause the higher CPU requirements of PCM over FLAC on the SBT. This could be offsetting opposite effects in other processes. I'm NOT an expert but some googling does seem to suggest that this process is concerned with the network.

In retrospect, it would have been useful to compare %usr and maybe %sys. Something like 'sar' would have helped but I can't see it on the SBT.

Redbook files are smaller and don't seem to be stressing the SBT at all, PCM or FLAC.

Haven't done any listening comparisons of FLAC vs PCM. When I get a chance ....

Chris

[dave2010]

Alex

Re msg 72 - thanks. You have confirmed what I hoped, that the FLAC designers did think about enough issues to make it all work, and that most implementers should therefore be able to produce encoders and decoders which will give a truly lossless compression/decompression.

I suppose it is not a requirement that two different compressors will produce the same output file given the same input, but it is a requirement that whatever the compressed file, all decoders should decode it to the same original file.

Basically,

For all audio files F which are compressible,
For all compressors C,
For all decompressors D,
D (C F) is exactly equal to F, where F is the input file.

If that is satisfied then the issue is not about the lossless data processing, but about performance issues which affect the playback, which seems to be the way the discussion is now going.

[Welder]

These look to be very high processor loads for Flac and WAV playback.
It might make this slightly more meaningful if the specification of the processor was given, the frequency of the side bus, the amount of RAM available, the amount of RAM in use and by what, and the South Bridge settings.

[bobbasrah]

These look to be very high processor loads for Flac and WAV playback.
It might make this slightly more meaningful if the specification of the processor was given, the frequency of the side bus, the amount of RAM available, the amount of RAM in use and by what, and the South Bridge settings.

For SBT ?????:scratch:

[Welder]

Are all the above using SBT and just SBT streaming?

(Just had a quick read and I see many are ;) )

Oh well, that rules the figures from my server irrelevant then ;)

[bobbasrah]

Are all the above using SBT and just SBT streaming?

(Just had a quick read and I see many are ;) )

Oh well, that rules the figures from my server irrelevant then ;)

No worries John,:)
Despite my engineering background telling me to explore every possibility, and exhaust every avenue of investigation, at the back of my mind, I cannot help but reflect on your 100mph cyclist in the pub.....:steam:

[AlexM]

I for one am going back to flac streaming on the SBT. I think we have proved that you can max or get close to maxing the the CPU when streaming 24/96 PCM - am thinking that the network stack must be not very good to eat more CPU than the FLAC decoder, and/or FLAC decoding is very efficient!.

Certainly if all of these mods are supposed to improve the sound by reducing CPU load, at least we know this tweak does the opposite.

[bobbasrah]

I for one am going back to flac streaming on the SBT. I think we have proved that you can max or get close to maxing the the CPU when streaming 24/96 PCM - am thinking that the network stack must be not very good to eat more CPU than the FLAC decoder, and/or FLAC decoding is very efficient!.

Certainly if all of these mods are supposed to improve the sound by reducing CPU load, at least we know this tweak does the opposite.


So in terms of CPU usage FLAC is more efficient at 24/96, and FLAC is proven 100% to contain precisely the same data.
Is audio output quality really worth examining in such an instance, if there is no stress, or data difference?

[Chops]

So in terms of CPU usage FLAC is more efficient at 24/96
Sorry Bob, you'll have to forgive me for being a little pedantic here. :)

When taking all factors into account, delivering FLAC files via a network connection to a SBT and playing them via digital out appears to place less demand on its CPU than PCM.

I couldn't confirm that simply decoding a FLAC file and pumping it down the digital out on the SBT is more efficient than PCM - I would think the opposite might be true. Others may know better, but I guess that plugging a USB stick into the SBT would be closer to this approach.

Chris

[bobbasrah]

Sorry Bob, you'll have to forgive me for being a little pedantic here. :)

When taking all factors into account, delivering FLAC files via a network connection to a SBT and playing them via digital out appears to place less demand on its CPU than PCM.

I couldn't confirm that simply decoding a FLAC file and pumping it down the digital out on the SBT is more efficient than PCM - I would think the opposite might be true. Others may know better, but I guess that plugging a USB stick into the SBT would be closer to this approach.

Chris

Please be as pedantic as you like Chris, the clearer the findings are the better, although I am totally lost on the SBT setup as I have none.

Ok, so the FLAC is putting less demand on the SBT's cpu via the network than it's WAV version. This may not necessarily mean that bypassing the network would result in the same loadings. I think Alex was looking at a usb stick test.

OK, that I can understand, but is this cycle that you have been measuring for the same delivery mechanism chucking the bitstream at the DAC for both situations. ie - the only variable left is the DAC performance for what should be the same input?

[Chops]

Ok, so the FLAC is putting less demand on the SBT's cpu via the network than it's WAV version. This may not necessarily mean that bypassing the network would result in the same loadings. I think Alex was looking at a usb stick test.

OK, that I can understand, but is this cycle that you have been measuring for the same delivery mechanism chucking the bitstream at the DAC for both situations. ie - the only variable left is the DAC performance for what should be the same input?

Hi Bob

Agreed about bypassing the n/w. I don't know what would happen but it would be interesting to find out.

Sorry, confused about the 2nd para. Could you explain? :scratch: All my tests were done using the same chain: NAS->SBT->DAC. 100Mbps between NAS and SBT, Coax SPDIF between SBT and DAC. I wasn't listening so my pre-amp was not powered up but my DAC was incase any handshaking is involved that might affect load on the SBT (is SPDIF bi-directional?).

Chris

[bobbasrah]

Hi Bob

Agreed about bypassing the n/w. I don't know what would happen but it would be interesting to find out.

Sorry, confused about the 2nd para. Could you explain? :scratch: All my tests were done using the same chain: NAS->SBT->DAC. 100Mbps between NAS and SBT, Coax SPDIF between SBT and DAC. I wasn't listening so my pre-amp was not powered up but my DAC was incase any handshaking is involved that might affect load on the SBT (is SPDIF bi-directional?).

Chris

Sorry about any confusion Chris....I was interested in establishing that the measurements were not cut short of delivery to the DAC which you confirmed it was not. The deilvery and conversion chain is tested complete.

The only variable left now is the external DAC conversion, but since the bitstream should be precisely the same for both cases via SPDIF given that FLAC itself is decoded 100% to what WAV would be, there should be no audible change.

[AlexM]

Hi Bob

Agreed about bypassing the n/w. I don't know what would happen but it would be interesting to find out.

Sorry, confused about the 2nd para. Could you explain? :scratch: All my tests were done using the same chain: NAS->SBT->DAC. 100Mbps between NAS and SBT, Coax SPDIF between SBT and DAC. I wasn't listening so my pre-amp was not powered up but my DAC was incase any handshaking is involved that might affect load on the SBT (is SPDIF bi-directional?).

Chris

Chris,

SPDIF is not bidirectional so nothing will change as a result of the sac being on or not.

Regards,
Alex

[sq225917]

Has anyone just taken a look at the eye pattern with a scope, it's not exactly difficult. If the eye patterns on the spdif out look the same in both instances and the data stream is identical then the only thing left is noise mixed in with the spdif and rejection of that in the dac.

[AlexM]

Has anyone just taken a look at the eye pattern with a scope, it's not exactly difficult. If the eye patterns on the spdif out look the same in both instances and the data stream is identical then the only thing left is noise mixed in with the spdif and rejection of that in the dac.

I have a scope, but I don't expect to see anything different in the eye pattern based on the file type.

I found this text written by J. Gordon Rankin on the Well tempered computer site, which is relevant, and I note his comment on duff USB cables.


I have done more than 10 audio shows where we bootcamped and showed that both with FLAC/ALAC and AIFF/WAV that flat PCM files (AIFF/WAV) always sounded better.

So I setup a test as follows:

MacBook Pro (bootcamp Win764ULT) <==USB={USB Analyzer}==>DAC/Conveter-->Prism dScope III.

Then hanging onto to the DAC was my TEK Scope which can decode I2S and my Wavecrest DTS and a Standford 760 FFT analyzer which I use to test power supplies as it is capable of full range 1nV readings.

So in this test I compared software programs which were bit true and sound different and also some USB cables which sound different and of course file types which sound different. I have like 200 hours in testing.... so far I can't see any difference.

YET!!!!! 82% of the time people picked the Flat PCM file over the lossless.

John Atkinson and Charlie Hansen both said that I could have spent that time designing something cool. So for now that is what I am going to do!

USB Cables was kind of interesting as I did find some cases were the cables caused data errors and excess jitter on the USB side. While this does not have anything to do with Audio related Jitter errors it did seem to effect the data stream. Especially with Async feedback pipe and the host missing some of these which caused buffering errors.

Thanks
Gordon
J. Gordon Rankin

[Chops]

Well, just done some A/Bing on a variety of material and bitrates. Hardly any difference, if at all - maybe something very small on a Pamela Thornby hires track. My SBT will be receiving FLAC.
Chris

[Ali Tait]

Just give up and go back to vinyl! :D

[synsei]

*hands Ali his coat* :lol:

[Ali Tait]

I've got so many coats I don't know what to do with them! :lol:

[synsei]

:rfl:

[bobbasrah]

I found this text written by J. Gordon Rankin on the Well tempered computer site, which is relevant, and I note his comment on duff USB cables.

Excellent find Alex, thank you very much indeed. I could not remember where I had read that piece, and with the subject of this thread, recurring detrimental comments over async usb and claims that only specialist and expensive usb cables would do, it was bugging me....:scratch:
SOME usb cables caused issues. That was what I thought it said, so the memory is not quite as decrepit as I feared.... I will stick with the good but cheapish usb cables I have, which give no problems....:cool:

Thank you Alex, Chris, your probing has been most illuminating, even if some findings appear to run counter to what was considered likely.:doh:

It has been surprising and somehat frustrating to have no computer+Dac users come forward in the last 3 days to reinforce Stan's assertions regarding differing performance of WAV v FLAC, as it would have been interesting to isolate the cause in these instances. Their absence must indicate either the users do not exist, or the problem does not exist.:mental:

At least the assertion that FLAC and WAV contain different end data is proven false, and in the case of SBT users there appear advantages to FLAC for Hirez.:cool:

Ah well, SNAFU;)

[John]

Where I do hear a difference is between WAV and say something like apple lossless. I have a play around with FLAC at the weekend.

[AlexM]

Just give up and go back to vinyl! :D

Ah yes... Vinyl is not tweaky at all in comparison!! :lol:

[AlexM]

Where I do hear a difference is between WAV and say something like apple lossless. I have a play around with FLAC at the weekend.

John,

I'll be doing some experimentation too over the weekend. Can you tell us what is in your digital replay chain?.

Alex

[John]

Laptop windows 7
Use Jplay in full hibernation mode
Going through HLLY DAC via converter with seperate power supply but will be upgrading all of this

[Ali Tait]

For what it's worth, I don't hear any difference. My kit is - Win 7 laptop with attached Drobo, streaming wirelessly to Touch, thence to valve output dac, WD Pre 3, behringer DCX2496 active crossover, Bantam Golds, diy OB's.

[bobbasrah]

Same here, no issues or differences noted up to and including 24/192, irrespective of what it is being used for. MediaPortal using PureAudio for audio output on desktop.
Desktop Win7/64Pro, 4core 3GHz, 8Gb, 4 Hot-swap Sata. Usb -> Musiland02US->CA 640R
This was also tested 24/96 on 2 other laptops (one XP one 7) and on 1 additional DAC fed audio system, both using Foobar, again no issues.

[Ali Tait]

Ah forgot my processor specs, might be useful - Win7/64 bit, i5 processor 2.7 gig, 6 gig of RAM.

[bobbasrah]

Ah forgot my processor specs, might be useful - Win7/64 bit, i5 processor 2.7 gig, 6 gig of RAM.

:)
With what these lads found testing with the SBT, I would not be so sure as it should not be a struggle Ali....:lol:

What would be interesting is to find someone, anyone, who has the problem so we can home in on cause. The only information we have been told for Stan's situation is that it was fed out over optical, but at least from that we know the transfer limit.:mental:
We know FLAC contains the same data as WAV though.:eyebrows:

[Ali Tait]

Yeah, maybe I need more power! :lol:

[bobbasrah]

Change of lead to the PSU perhaps....

[Ali Tait]

:D My Touch has a MCRU linear power supply. Both Bantams are fed from another linear power supply. Maybe my dac is crap, despite it being by far the best sounding I've had in my system.

[Welder]

:D My Touch has a MCRU linear power supply. Both Bantams are fed from another linear power supply. Maybe my dac is crap, despite it being by far the best sounding I've had in my system.

That must be it Ali. I have the same problem. Now if we had truly transparent and resolving systems where no expense or efforts had been spared then no doubt we would also be able to hear the difference between Flac and WAV.........:eyebrows:

Interestingly I cant hear a difference with my mates file setup either and his is probably the best file system I've heard. Strangely neither his or mine have a laptop or SBT or a Caiman in the chain so that automatically rules us out as deaf. :(

I did mention I would submit my findings from my purpose built server and the rest of my crap kit but I got the impression that my contribution may not be welcome; prolly coz I piss about too much and don't seem to be taking the debate seriously enough; can't really argue tbh. ;)

Oh well, back to a few awful sounding Flac files then.

[sq225917]

Where I do hear a difference is between WAV and say something like apple lossless. I have a play around with FLAC at the weekend.

Can you explain what you mean? Do you mean that the same software player decodes the files so that you can distinguish between identical source files where one has been encoded as Alac and the other left as wav?

That's a little surprising, because and Alac is every single bit as lossless as Flac. Which isn't surprising seeing that they use the same coding algorithms and differ only in that Apple writes none standard file headers as part of the wrapper. That would imply that some bit of software knows a file is in Alac and accordingly treats it differently to Flac on purpose.

I've never heard any difference between the playback of any lossless file formats on any of the dacs I've ever owned, I must suffer from same shit hifi as others. ;-)

[John]

What i hear is mostly when using J play in full hibernation mode
So in terms of sound we talking more air and depth. Perhaps a good example of this is Kate Bush Waking the Witch on Hounds of Love With using WAV in full JPLAY mode I get to hear the full church bells ringing, whilst before it was only just some of this happening
I am compairing using Apple Lossless to WAV files of the music. One recorded from CD the other a Apple Lossless copy

[Ali Tait]

ALAC copy from the same cd John?

[Ali Tait]

That must be it Ali. I have the same problem. Now if we had truly transparent and resolving systems where no expense or efforts had been spared then no doubt we would also be able to hear the difference between Flac and WAV.........:eyebrows:

Interestingly I cant hear a difference with my mates file setup either and his is probably the best file system I've heard. Strangely neither his or mine have a laptop or SBT or a Caiman in the chain so that automatically rules us out as deaf. :(

I did mention I would submit my findings from my purpose built server and the rest of my crap kit but I got the impression that my contribution may not be welcome; prolly coz I piss about too much and don't seem to be taking the debate seriously enough; can't really argue tbh. ;)

Oh well, back to a few awful sounding Flac files then.

Well I'd be interested mate, I'm happy with the Touch, but I know there's better to be had from file audio, so I'd like to know what you've been up to and what you've found.

[John]

Yes
I do not have an expensive DAC in my system its the effects of cutting down on what going on in Windows that makes the difference

[Ali Tait]

Interesting John. I believe John (Welder) has said the same in the past, as have others.

[John]

Yes I think John's path quite an interesting route to take

[StanleyB]

Strangely neither his or mine have a laptop or SBT or a Caiman in the chain so that automatically rules us out as deaf. :(
Come again mate? What has my Caiman DAC got to do with this discussion? You trying to be insulting towards my product or what?

[bobbasrah]

Come again mate? What has my Caiman DAC got to do with this discussion? You trying to be insulting towards my product or what?

Possibly with refernce to what preceded it Stan "Now if we had truly transparent and resolving systems where no expense or efforts had been spared then no doubt we would also be able to hear the difference between Flac and WAV" ??

[bobbasrah]

Come again mate? What has my Caiman DAC got to do with this discussion? You trying to be insulting towards my product or what?

Since you are here, could you contribute to this thread Stan by detailing the circumstances and equipment used at the time please?
We know it was FLAC and optical input but additional information would certainly help.

[bobbasrah]

Since you are here, could you contribute to this thread Stan by detailing the circumstances and equipment used at the time please?
We know it was FLAC and optical input but additional information would certainly help.

Ah well, perhaps not.

The stripped down Win OS and the Linux solutions are all very well, but does Win7 have the same issues to deal with? :scratch:
As I understood it, Win7 is less intrusive to the audio chain. ;)
This system runs flawlessly without any side effects that I know of, or is that wishful thinking? :mental:

PS - Anybody know?

[John]

Ah well, perhaps not.

The stripped down Win OS and the Linux solutions are all very well, but does Win7 have the same issues to deal with? :scratch:
As I understood it, Win7 is less intrusive to the audio chain. ;)
This system runs flawlessly without any side effects that I know of, or is that wishful thinking? :mental:

PS - Anybody know?

Certainly not my experience Windows 7 doing a lot of processing that effect audio

[Welder]

Despite my fun poking at JPlay to my ears it did make an audible difference to sound replay on a Win7 system.

The answer is of course, try it and decide for yourself.
My view is standard set PC's and laptops don't make for ideal audio replay.
If your "serious" about file based audio then at some point you have to leave the general purpose computer doing what it does best and build another computer that concentrates on audio.
I understand that JPlay does a lot of the "virtual audio only" server stuff on a general purpose machine, but you are still left with a few hardware problems that are more easily overcome by a server build.
Using JPlay, your laptop isn't really able to anything else apart from the tasks JPlay allows so in effect you don't have a laptop computer at all.
So' you've paid for a laptop and JPlay and still not got what many would argue is the optimal hardware.
One computer for audio,one for general purpose computing; starts getting expensive and neither is quite fit for either task all the time.

[Clive]

Despite my fun poking at JPlay to my ears it did make an audible difference to sound replay on a Win7 system.

The answer is of course, try it and decide for yourself.
My view is standard set PC's and laptops don't make for ideal audio replay.
If your "serious" about file based audio then at some point you have to leave the general purpose computer doing what it does best and build another computer that concentrates on audio.
I understand that JPlay does a lot of the "virtual audio only" server stuff on a general purpose machine, but you are still left with a few hardware problems that are more easily overcome by a server build.
Using JPlay, your laptop isn't really able to anything else apart from the tasks JPlay allows so in effect you don't have a laptop computer at all.
So' you've paid for a laptop and JPlay and still not got what many would argue is the optimal hardware.
One computer for audio,one for general purpose computing; starts getting expensive and neither is quite fit for either task all the time.
You can't generalise on peoples' computers.....in my situation I have 2 or 3 spare laptops that are 3 to 5 years old. I use 1 of these as a music server, I only needed to buy an extra 2GB of memory and I had jplay running soon after, minutes after. Everyones' situation will be personal to them.

[Welder]

I think you can generalise in these circumstances Clive.
A laptop is still a laptop no matter what age it is. It was designed to multi-task and software changes can only do so much.

[Clive]

I think you can generalise in these circumstances Clive.
A laptop is still a laptop no matter what age it is. It was designed to multi-task and software changes can only do so much.

Clearly not! :) We were at crossed purposes I think....

You said:

So' you've paid for a laptop and JPlay and still not got what many would argue is the optimal hardware.
One computer for audio,one for general purpose computing; starts getting expensive and neither is quite fit for either task all the time.

I was talking about cost because you were.

Interestingly the jplay guys find that laptops sound better than desktop PCs, they reckon there's less RFI.

[Welder]

I think my point got lost a bit. ;) and yes,probably at crossed purposes.

I agree a laptop dedicated to audio replay solves certain aspects.
My point was you are still left with laptop hardware and of course at some point I assume you've bought the laptop and bought JPlay and still not got what many would consider optimal conditions for audio replay.

Yep, I would agree in general that a laptop stands a better chance in standard hardware and software config of producing lovely music than a PC. ;)

I've tried audio on my gaming PC and even with it underclocked and the fans disabled there is just something not quite there.;)

[John]

In time maybe but for myself I am ok with using only Jplay for serious listening so in my view each to their own needs

[Clive]

John (as in Mr Welder)

What's a touch ironic is that you are obsessing over monitor power supplies and the like. It's a bit like a hi-fi obsession with power cables. It all makes a difference. It seems to me whilst your obsession is a well-founded quest for perfection it also is quite time-consuming. Had I the time I'm sure I would be going down a similar route. I resisted returning to record decks for a long time because I knew I'd have to "do it properly". The same is true for a music server.

W7 with Jplay and a really good DAC has got me to the point where for under 600 euros I have a sound that bears comparison with what is a high-end sounding record deck. This is with redbook software too.

I need to devote time to other things in my life, including listening to music. I can learn Linux as I have done with several operating systems in the past but it's not my priority. Actually I question whether even Linux is ideal, something like RT-11 might be better though we'd need a PDP-11 for that but at least I know these things inside out!

[Welder]

I agree John and you can get excellent file based audio from a laptop with optimisations like JPlay, CPlay, Fidelizer and Black Viper configs.

For many people it's a second system; both you and Clive for example I believe have excellent vinyl replay systems.
Unfortunately, maybe, I can't afford in both financial and practical terms a multi source system so naturally I'm interested in getting the best results I can from my only replay source which is file.

[Welder]

Clive.

Did I ever claim not to be as obsessed as the most ardent vinyl enthusiast? :D

I must admit, I have put an awful lot of time into file based audio and a fair bit of money.
I don't think I'm that unusual in this respect for those who have decided file based audio is their way forward. On AoS I'll grant you, I must seem a bit weird, mainly because this forum is predominantly a valve and vinyl site. But, when you look at the lengths the vinyl enthusiasts here go to and the money they spend I don't feel any immediate need to rush out and get analysis. ;)

[John]

John were I am now I am very happy with I have "a laptop based system" that is very close to the performance level of one of the best TT out there I love your passion but I am pretty happy were I am.
The value of such a system is crazy considering it performance

[Clive]

It great this is good-natured banter.

As for multiple sources......this is a pain. What I need and have not achieved is a sound from both sources that bear comparison, Indeed it's the mastering of the music now that makes the greatest difference. The problem I had before was that Foobar/ASIO, whilst better a Meridian 588, was miles behind both my record decks. If there's an argument for not tweaking the hell out of a server it because I need to maintain balance between my sources. Should my file-based source get much better it'll give me a big problem as my deck can't get much better!

[Ali Tait]

I'd love to have a top notch vinyl system (in fact I have a 401) but it would cost a fortune for arm and cart etc. not to mention I'd have to start collecting LP's again as I don't have any now, so I'm in the same boat, file audio is the way forward for me whether I like it or not. It's sounding pretty good, but I know how far there is still to go having heard some of the setups at our DIY get-togethers, where I've heard some jaw dropping vinyl systems.

[Welder]

I just don’t have the money for a multiple source system Clive so it’s not a problem I’ll be dealing with. ;)
I do have time; full time employment for good or bad is past for me, I don’t need that sort of money any more anyway. :eyebrows:
I have most of what I need, kids are grown up, ex wife has the house (for now :rolleyes:) don’t do telly, cars, drink, smoke, TV, gadgets and poodle along doing pretty much as I please which is pretty much file audio, sax parping, dancing and friends and family.



I’m pleased you appreciate my passion John and yes, its amazing that for a relatively small outlay a well set up file based system can rival some seriously expensive record players.

[Clive]

Over the last 10 years my net spend on my system has been very low, possibly breakeven. My main investment ripe for selling is my Slatedecked 301 and OL Encounter arm but I won't flog it as the 301 won't depreciate. The problem I have is that I have about 700 LPs and 600 CDs so I need both sources. Currently I'm listening Lorena McKeennitt with my OBs almost as headphones. Exquisite!

[Ali Tait]

Yes, I'd find it difficult to go back to box speakers now. Lot to be said for OB's.

[aquapiranha]

Never had an issue with FLAC, have lots too (1.7TB) and I have no intention whatsoever of changing them all to WAV or anything else at the moment. What I might do is get myself a nice new streamer like the Dune H1 perhaps, and another Tripath amp.

[bobbasrah]

Fair enough,
For the moment I have a good audio and video platform for minimum cost and maximum enjoyment, no file type issues, and can convert everything to hdd. Contrary to what you guys have said re laptops, I have zero problems with this particular desktop build in terms of noise or interference, and no disadvantages over laptops bar size and lack of inbuilt screen. Front access, multiple ports, 6 sata drives, and remote control are just some of the upsides though.......

I just might think again over the old system rebuild along John's ideas, but time enough for that....

Enough thread crapping though....I remain interested in the thread to see where it goes, and look forward to any results, but suspect it has done more damage than good in the long run.....

[Clive]

I thought we were all getting on well!

[bobbasrah]

I thought we were all getting on well!

Indeed Clive we are getting along very well, and the discussions have been friendly, open, informative and constructive, even if sometimes peripheral to the thrust of the thread. There is a very clear concensus on the issues and objectives in all our circumstances, and these discussions inform our opinions.;)

The damage I referred to was in relation to the basis of this thread. Not good.:(

[John]

AOS is famous for going in different tangents then getting back on track its part of our charm

[Ali Tait]

Never had an issue with FLAC, have lots too (1.7TB) and I have no intention whatsoever of changing them all to WAV or anything else at the moment. What I might do is get myself a nice new streamer like the Dune H1 perhaps, and another Tripath amp.

Not seen those before, they look interesting. Only bugbear is no coax S/PDIF.

[Alex_UK]

AOS is famous for going in different tangents then getting back on track its part of our charm

or sometimes not getting back on track! :lol:

The important thing is that even when we don't agree, we always remain civil and respectful of others opinions - by and large there are few punch ups on AoS. :)

[bobbasrah]

or sometimes not getting back on track! :lol:

The important thing is that even when we don't agree, we always remain civil and respectful of others opinions - by and large there are few punch ups on AoS. :)

Tangents I don't mind at all. Obtuse I have difficulty with. I suppose it depends on what the angle is.....;)

[Ali Tait]

This looks interesting. Anyone heard one?

http://www.computeraudiophile.com/content/Auraliti-PK100-File-Player-Review

[Stratmangler]

Maybe my dac is crap, despite it being by far the best sounding I've had in my system.

I think you've hit the nail on the head Ali.
Send it to me and I'll dispose of it for you, while you go off and find a decent sounding one :eyebrows:

[Ali Tait]

Thanks mate, I'll send it off!

[AlexM]

OK, I spent a little time listening to some CDs ripped into FLAC files by DBPowerAMP, and another copy transcoded back to WAV.

Playback is via ethernet SB Touch into my Cambridge Audio CA840. Source FLAC files were compressed at level 5.

I built some playlists for the sample tracks, and then shuffle played the tracks so that i didn't know which track was playing and listened to the first minute or so.

The test tracks were 'My Bass' by Brian Bromberg, 'Bamboo Forest' by Miroslav Vitous, and 'New York Minute' by Herbie Hancock.

To cut to the chase, I didn't notice any differences consistently and couldn't really tell them apart. I did find that the sound appeared to change slightly as I listened more. I think that this was probably as a result of concentrating on details of the tracks in order to discern a difference, but I couldn't tell which was which.

By comparison, I can easily tell a signficant difference between TOSLINK and Co-ax SPDIF inputs, and any differences I spotted were a lot less significant than this. I'm not sure if I could detect any differences, much less tell which was which.

So, in conclusion, at least in my case I can't tell the difference. I guess this is what I was expecting, but at least I now know that I can carry on using FLAC with confidence. i will do some further testing with playback from USB sticks.

Your mileage may vary - at least in this configuration FLAC playback works as well as LPCM.

Cheers,
Alex

[bobbasrah]

Thanks for the update Alex....
Will be interested in the stick experiment simply out of curiosity....

[Welder]

OK, I spent a little time listening to some CDs ripped into FLAC files by DBPowerAMP, and another copy transcoded back to WAV.

Playback is via ethernet SB Touch into my Cambridge Audio CA840. Source FLAC files were compressed at level 5.

I built some playlists for the sample tracks, and then shuffle played the tracks so that i didn't know which track was playing and listened to the first minute or so.

The test tracks were 'My Bass' by Brian Bromberg, 'Bamboo Forest' by Miroslav Vitous, and 'New York Minute' by Herbie Hancock.

To cut to the chase, I didn't notice any differences consistently and couldn't really tell them apart. I did find that the sound appeared to change slightly as I listened more. I think that this was probably as a result of concentrating on details of the tracks in order to discern a difference, but I couldn't tell which was which.

By comparison, I can easily tell a signficant difference between TOSLINK and Co-ax SPDIF inputs, and any differences I spotted were a lot less significant than this. I'm not sure if I could detect any differences, much less tell which was which.

So, in conclusion, at least in my case I can't tell the difference. I guess this is what I was expecting, but at least I now know that I can carry on using FLAC with confidence. i will do some further testing with playback from USB sticks.

Your mileage may vary - at least in this configuration FLAC playback works as well as LPCM.

Cheers,
Alex

Here we go again :doh:

Why didn't you just use the original WAV rip? Why convert to Flac and then back to WAV?

[Chops]

To cut to the chase, I didn't notice any differences consistently and couldn't really tell them apart. I did find that the sound appeared to change slightly as I listened more. I think that this was probably as a result of concentrating on details of the tracks in order to discern a difference, but I couldn't tell which was which.

Exactly the same as my experience, although I fed a different DAC (Chord QBD76) from a similarly configured SBT.

Chris

[AlexM]

Here we go again :doh:

Why didn't you just use the original WAV rip? Why convert to Flac and then back to WAV?

John,

I didn't rip to wav from the cd so I had to convert the flax to wav in order to do this test. I don't think it made any difference to the outcome.

Chops and I have found that CPU utilisation is higher playing LPCM both at 16/44 and 24/88, and if one is to believe that is a bad thing then best not to bother with wavs, especially as they take up more disk space and sound the same!

All in all, a good outcome as I don't have to worry about doing anything to my library..

Alex

[Welder]

John,

I didn't rip to wav from the cd so I had to convert the flax to wav in order to do this test.

Alex

First, oh yes you did assuming you are using Windows computer. ;)
Windows at default will only rip to WAV but I think I understand what you mean, you let the Flac compression run automatically.

If I wanted to carry out a meaningful comparison test between Flac and WAV then I would not want the WAV file to have undergone further processes, compression, decompression, before the comparison otherwise what I would have "tested" is just the ability of the decompresser to return the Flac file to a checksum identical WAV copy.

Given how we/you/us are listening for what are generally acknowledged as inaudible differences then any unnecessary processing of the WAV file renders the test invalid imo.

Just sayin mate, but no sweat if you're happy. :)

[Tim]

I'm a little late to the party on this one, but I have tried varying rips of WAV against the same in FLAC and have not been able to discern any difference between the two, so I'm sticking to FLAC. :)

[Welder]

Yay! Tim :)

Thought you had dropped off the edge of this flat planet we're on mate ;)
Dont spose you've got Mark (Reid) hid in yer skirts have you?

[Tim]

Dont spose you've got Mark (Reid) hid in yer skirts have you?
Nope, not here .... I'll check behind the sofa and see if he's munching on my custard creams ;)

Had no tinternet due to a move John, it shows how much I depend on it really, as I have a pile of catching up to do now.

[Welder]

Oh,I see. I didn't know you had moved.
I hope it all went well.
Really good to see you back anyway. :)

[AlexM]

First, oh yes you did assuming you are using Windows computer. ;)
Windows at default will only rip to WAV but I think I understand what you mean, you let the Flac compression run automatically.

If I wanted to carry out a meaningful comparison test between Flac and WAV then I would not want the WAV file to have undergone further processes, compression, decompression, before the comparison otherwise what I would have "tested" is just the ability of the decompresser to return the Flac file to a checksum identical WAV copy.

Given how we/you/us are listening for what are generally acknowledged as inaudible differences then any unnecessary processing of the WAV file renders the test invalid imo.

Just sayin mate, but no sweat if you're happy. :)


John,

I take your point, but I think we agree that conversion before playback isn't the issue here as I agree that I could have just done a checksum and then called it a day. I was more interested in the possible effects of real time decompression of the flac stream on playback.

I confirmed that there was no audible difference, as have others, so all is well with the world.

Cheers,
Alex

[morris_minor]

FWIW I too have done a comparison with rips to FLAC and WAV from CD, and LP at 96/24.

Playing back from both a Squeezebox Transporter and a SB Receiver with a Metrum Octave DAC I couldn't tell them apart. So from my point of view, FLAC is just fine - especially given the tagging attributes of FLAC files.

[Ali Tait]

How are you getting on with the dac Bob?

[morris_minor]

How are you getting on with the dac Bob?

Ah! I'm loving every moment. Higher, wider, deeper, clearer, and no doubt some more -er words I can't think of right now :eyebrows:.

I haven't got round to doing a head-to-head with my Transporter yet, as they're in different rooms, but I feel music is just that bit more involving with the Metrum. I'm going to be moving my living room rack at some point soon, so I'll probably move the Transporter out to my study (now the main "stereo" room) then and hook up both digital and analogue outputs so I can switch between them.

But, for me, the Metrum DAC is definitely a good piece of kit . . .:)

[Tim]

Oh,I see. I didn't know you had moved.
I hope it all went well.
Really good to see you back anyway. :)
Yep, all went well John and I live a mile from work now, so walk everyday which is great. The place isn't as nice, but I had to move promptly as my landlady sold the last place 2 weeks after putting it on the market! Amazing really and she got the asking price of £250,000 too! There are still some folk with cash out there.....

[Ali Tait]

Ah! I'm loving every moment. Higher, wider, deeper, clearer, and no doubt some more -er words I can't think of right now :eyebrows:.

I haven't got round to doing a head-to-head with my Transporter yet, as they're in different rooms, but I feel music is just that bit more involving with the Metrum. I'm going to be moving my living room rack at some point soon, so I'll probably move the Transporter out to my study (now the main "stereo" room) then and hook up both digital and analogue outputs so I can switch between them.

But, for me, the Metrum DAC is definitely a good piece of kit . . .:)

Like to hear one with a valve output stage. :D

[bobbasrah]

Any results or thoughts from the usb stick experiment Alex?
Curious, not so much as to the flac/wav myth, rather how the network v usb memory injection compares on that logitech device.