Sound quality between wav and flac

[Louishlomador]

Has anyone noticed sound quality differences between a flac and wave file? I am certainly aware that flac is "lossless" however playback of flac files sound flat and dont seem to have great imaging effect on the sound than Wav. anyone?

[JJZolx]

Has anyone noticed sound quality differences between a flac and wave file? I am certainly aware that flac is "lossless" however playback of flac files sound flat and dont seem to have great imaging effect on the sound than Wav. anyone?

I don't hear any difference. Some people have claimed FLAC sounds better.

But if you do prefer WAV, there's no reason not to use FLAC for your library with Squeezebox. You can stream WAV (PCM, actually) to your player by having Squeezebox Server decode the FLAC files instead of doing it at the player. It will be equivalent to storing WAV files, with the added benefit of full tagging ability and reduced storage space. The downside is the increased network bandwidth needed.

[Louishlomador]

Its a strange one. I have squeezecenter 7.2.1 before upgrading to 7.4.1. There seem to be a difference when you play both versions of the file and listen to it instrument by instument. I'm have a strong feeling the firmware has been modified in a way for the SB to play in flac mode, maybe due to bandwidth issues with wave files. I have my music ripped in 24bit 48khz in wave. When you convert to flac and play it sounds flat, and you notice the stereo imaging is not that great. Very strange

[JJZolx]

I have my music ripped in 24bit 48khz in wave.

You rip 44.1 kHz redbook CDs to 48 kHz?

[Louishlomador]

Yes, there is a bit of a grey area here as if you had a cd player that was capable of playing at 24bit 96khz it will sound better than a CD player equiped with a dac capable of only 48khz, hence I rip at this resolution to extract every as much info as possible from the CD. The site below seems to do some great comparisms

http://www.tweakheadz.com/16_vs_24_bit_audio.htm

[pfarrell]

Louishlomador wrote:
>>You rip 44.1 kHz redbook CDs to 48 kHz?

> Yes, there is a bit of a grey area here as if you had a cd player that
> was capable of playing at 24bit 96khz it will sound better than a CD
> player equiped with a dac capable of only 48khz, hence I rip at this
> resolution to extract every as much info as possible from the CD. The
> site below seems to do some great comparisms

This is very hard to believe. You can't just claim that since 48 is
bigger than 44.1 then it sounds better if you convert from 44.1 to 48.

I would expect it to sound different, and worse than just using RedBook
rates.


--
Pat Farrell
http://www.pfarrell.com/

[Louishlomador]

you have a point there, however my understanding of how the Squeeze box works is all about the processing of whatever data contents you have in the file, whiles I believe the CD player will pickup the data in a different way. Maybe I'm wrong but the sound seems much better with a higher resolution, compared to 44.1 especially when you have an expensive audiophile kit. I use Shure E530 and the SB is connected to a headphone amp
Lehmann blackcube linear. They are all high end products. I will encourage you to try these formats. I'm very keen for someone to try these different formats.

[pfarrell]

Louishlomador wrote:
> you have a point there, however my understanding of how the Squeeze box
> works is all about the processing of whatever data contents you have in
> the file, whiles I believe the CD player will pickup the data in a
> different way. Maybe I'm wrong but the sound seems much better with a
> higher resolution, compared to 44.1 especially when you have an
> expensive audiophile kit.

It may sound different, and you may prefer that sound, I can't argue
with that part.

But there is nothing good about pretending that something can get 3.9
kHz of signal out of the air, 44.1 kHz is not 48kHz.

There is some claimed benefit to oversampling to an integer multiple of
44.1, say 88.2 or higher. But if the multiple is not an integer,
whatever is added is not music.

And any real benefit from oversampling or upsampling or other stuff is
because when you are working with higher rates, you can use simpler
analog filters that don't screw up phase as badly as the normal brick
wall filters used for anti-aliasing at 22.05 kHz


--
Pat Farrell
http://www.pfarrell.com/

[Louishlomador]

Very good point. It raises soo many questions as to why soo many ripping applications have these features of ripping CDs to this format readily available at that resolution, such as DB poweramp, or why some dacs will play normal CD at say 24bit 96khz resolution. I believe the squeezebox transporter and squeezebox touch can play at this format. I'm confused.

[pfarrell]

Louishlomador wrote:
> I believe the squeezebox transporter and squeezebox touch can play at this format. I'm confused.

Yes, they will play files in 48 kHz as well as 44.1kHz, and perhaps 88.2
and 96kHz as well (I don't keep up) but the question is not if the
devices can play the specific files, but rather if there is anything in
them that should sound better.

Long ago, Stereophile took a bunch of SACD and DVD-A releases, and did
spectral analysis on them. Most of them had exactly the same signal as
the RedBook audio versions, nothing over 20 kHz, even though the format
could have signal up into 40Khz or above.

As to why some software has features that do no good, well that is
another topic, just use MS Word as an example, it has zillions of
features and 99% of the users use less than 5% of them. The rest are
there for various reasons.

A DAC reporting RedBook at 24/88.2 makes sense, that is simple wider
oversampling. Saying it is 96Khz may be real or may be marketing puff.

--
Pat Farrell
http://www.pfarrell.com/

[bhaagensen]

I have my music ripped in 24bit 48khz in wave.

You do know that by doing this you're rips are by definition lossy (you could do perfect 88khz rips though). I would never do this. I'd like to keep at least one copy of my rips as true to the originals as possible. Its possible that you're 48khz rips sounds better, or at least different; this is obviously dependend on the resampler used. But this is the point, since who knows what better resamplers could appear in the future. In which case one is likely to want the resampling done on the original files rather than on some already resampled files. Of course you could re-rip, but ripping is not that fun imo.

[Themis]

Has anyone noticed sound quality differences between a flac and wave file? I am certainly aware that flac is "lossless" however playback of flac files sound flat and dont seem to have great imaging effect on the sound than Wav. anyone?
If you think there's a difference, you can still store in FLAC format and do the conversion on the server side. ;)

[Louishlomador]

On the server side the flac to wav option only gives you flac options and no native wav format. The wav option is fine on the server side as i've set it to play in native wav for both versions of the server software.

[Themis]

On the server side the flac to wav option only gives you flac options and no native wav format. The wav option is fine on the server side as i've set it to play in native wav for both versions of the server software.
I don't understand. You mean you can't transcode flac to wav on the server ?
Even if you put FLAC->Disable and PCM->flac ?

[Phil Leigh]

This keeps coming up. Repeated tests with AudioDiffmaker have confirmed there is NO measurable difference in either the digital or analogue outputs when replaying FLAC vs WAV. This was with an SB3 and the Touch (as I can now reveal - couldn't mention it before under NDA).

[Louishlomador]

Yes the only available from flac to another format is mp3, wave or flac, however when converting to wave the option available is flac.See the attached picture of my settings

[bpa]

when converting to wave the option available is flac.


The name in the drop down box is the application which does the conversion so the application called "flac" will convert FLAC to WAV. Look at other setting and you will see other applications like mov123 or mov123/flac and mppdec.

[Louishlomador]

This keeps coming up. Repeated tests with AudioDiffmaker have confirmed there is NO measurable difference in either the digital or analogue outputs when replaying FLAC vs WAV. This was with an SB3 and the Touch (as I can now reveal - couldn't mention it before under NDA).


Strange stuff, maybe Adiodiffmaker is not as good enough to pickup the sound diffirences, than the ear. This might sound a bit strange but i can definately tell the diffirence. Flac just sounds flac, not much stereo imaging, compared to wave. This is noticeable especially music with some kind of echo imaging. Its much more pronounced in wav than in flac.

[Themis]

The name in the drop down box is the application which does the conversion so the application called "flac" will convert FLAC to WAV. Look at other setting and you will see other applications like mov123 or mov123/flac and mppdec.
Exactly. So, what you send to the SB is a pcm, not flac. ;)

[Louishlomador]

Another reason why I'm thinking a lot of people are not able to pick this up is
1. By default the slim server or squeeze center software is set to play wave files in flac mode by default. This is a fact. So if you haven't changed the settings in "files types" to play in native wave then you will not notice a diffirences in Flac or Wave files. If you set flac files to play flac and wav to play wave in native modes respectively I can tell the difference in squeezecenter 7.2. In the latest version 7.4.1, the sound quality sounds like Flac even if you change these settings. I'm hoping someone can do these tests and post results.

[Themis]

1. By default the slim server or squeeze center software is set to play wave files in flac mode by default.
Seriously, I dont know what it is a "wave file in flac mode"... You seem to think that the server sends PCM and the SB re-compresses into FLAC on-the-fly ? Can you please provide a link or tell us where did you get this information from ?

[Louishlomador]

Seriously, I dont know what it is a "wave file in flac mode"... You seem to think that the server sends PCM and the SB re-compresses into FLAC on-the-fly ? Can you please provide a link or tell us where did you get this information from ?


This is what I know and have been told in the past by Slim devices. All I know for sure is that the wav file is converted to flac to save bandwidth at playback. This is based on the fact that you have a wave file. I had bandwidth issues in the past when I was streaming music from my network wirelessly. There was a lot of buffering issues etc. On a hard wired network its fine without any problems, or on the wireless if you have it set to Flac conversion mode which is the setting by default. you can certainly confirm this with them directly. I have posted another picture and if you check the wave settings on my server its set to native, while the default is Flac. According to Slim devices or logitech there are no audio differences between Wav and Flac, hence the prefered setting is flac and flac files use less bandwidth than wav files.

[pfarrell]

Louishlomador wrote:
> This is what I know and have been told in the past by Slim devices. All
> I know for sure is that the wav file is converted to flac to save
> bandwidth at playback.

I have never heard this in many years of using Slim Devices. It may be
true over wifi, but not over ethernet, and there are controls for it.

I had a lot of problems with streaming over wifi, which is why I ran
Ethernet cable to my Transporter.

It wasn't a Transporter or SqueezeBoxServer problem it was the WiFi in
my house.

With real wire, the problem disappeared.

I don't see audiophiles, who have many thousands of dollars in their
setup, speakers, etc. using WiFi if they have problems. Its not worth
it, even if you have to pay a contractor to drag the cable.

It is true that wav/pcm files are about twice as big as flac, and that
puts a huge load on WiFi networks. And if you are double hopping Wifi
(using WiFi from server to router and again from router to Transporter)
then your use of double sized files causes at least double if not four
times the problems.



--
Pat Farrell
http://www.pfarrell.com/

[Louishlomador]

[QUOTE=pfarrell;484781]Louishlomador wrote:
> This is what I know and have been told in the past by Slim devices. All
> I know for sure is that the wav file is converted to flac to save
> bandwidth at playback.

I have never heard this in many years of using Slim Devices. It may be
true over wifi, but not over ethernet, and there are controls for it.

I had a lot of problems with streaming over wifi, which is why I ran
Ethernet cable to my Transporter.

It wasn't a Transporter or SqueezeBoxServer problem it was the WiFi in
my house.

With real wire, the problem disappeared.

I don't see audiophiles, who have many thousands of dollars in their
setup, speakers, etc. using WiFi if they have problems. Its not worth
it, even if you have to pay a contractor to drag the cable.

It is true that wav/pcm files are about twice as big as flac, and that
puts a huge load on WiFi networks. And if you are double hopping Wifi
(using WiFi from server to router and again from router to Transporter)
then your use of double sized files causes at least double if not four
times the problems.

I totally agree with you pat, and this is why I had to connect the SB to my Lan via Wire, rather than wireless as I only stream in Wav/PCM only. I was informed my slim to use the network cables, rather than the wiresless network, if i had the wave settings set to native. I can understand why they wouldn't make this public though, as I'm thinking it might be seen as a mulfunction, when not knowing the technicalities of file formats etc..

[Themis]

This is what I know and have been told in the past by Slim devices. All I know for sure is that the wav file is converted to flac to save bandwidth at playback. This is based on the fact that you have a wave file. I had bandwidth issues in the past when I was streaming music from my network wirelessly. There was a lot of buffering issues etc. On a hard wired network its fine without any problems, or on the wireless if you have it set to Flac conversion mode which is the setting by default. you can certainly confirm this with them directly. I have posted another picture and if you check the wave settings on my server its set to native, while the default is Flac. According to Slim devices or logitech there are no audio differences between Wav and Flac, hence the prefered setting is flac and flac files use less bandwidth than wav files.
The default setting IS to convert WAV to FLAC, true. But if you specify as you do (FLAC>FLAC=disable, FLAC>WAV=flac, WAV>FLAC=disable, WAV>WAV=Native, then you send WAV to the SB, trust me.
There's no chance that anything on the way will re-compress it to FLAC. ;)

[radish]

By default all lossless formats (including wav) are transcoded to flac by the server, that's been the case for a long time IIRC. But it's easily changeable as has been pointed out. Whether it makes a difference, well we all have our opinions on that ;)

[Louishlomador]

I am certainly not doubting that version 7.2.1 does send wav directly to the squeezebox. That is 100% correct, however the latest version 7.4.1 whether you do the conversion or not, sounds just like playback of Flac. Believe me there are sound differences between server versions even when set to wave native. As said already version 7.4.1 sounds less detailed. Dont know why and this is why I'm in the forum. If you have both versions of the software i think you should test and tell me what you think. Of course you have to rip your music in wav and compare. Lets also not forget that flat doesn't give you the option to rip music in 24bit format, while wav does, in 16bit or 24bit, depending on the rip sofware. All i want is someone to do a similar test and post the results.Lets also not forget that the SB firmawre is upgraded anytime you change bewteen different versions.

[andynormancx]

Lets also not forget that flat doesn't give you the option to rip music in 24bit format, while wav does, in 16bit or 24bit, depending on the rip sofware.
Wrong.

- FLAC files can be 24 bit
- FLAC doesn't rip anything, FLAC is a file format

[Stratmangler]

I am certainly not doubting that version 7.2.1 does send wav directly to the squeezebox. That is 100% correct, however the latest version 7.4.1 whether you do the conversion or not, sounds just like playback of Flac. Believe me there are sound differences between server versions even when set to wave native. As said already version 7.4.1 sounds less detailed. Dont know why and this is why I'm in the forum. If you have both versions of the software i think you should test and tell me what you think. Of course you have to rip your music in wav and flac and compare. Lets also not forget that flat doesn't give you the option to rip music in 24bit format, while wav does, in 16bit or 24bit, depending on the rip sofware. All i want is someone to do a similar test and post the results.Lets also not forget that the SB firmawre is upgraded anytime you change bewteen different versions.

What OS is your computer running.

Chris:)

[Louishlomador]

What OS is your computer running.

Chris:)


Tried it on Vista, and Windows Server 2003 on both versions, still the same issue.

[Stratmangler]

Tried it on Vista, and Windows Server 2003 on both versions, still the same issue.

Clean install or overwrite ?

Chris:)

[Louishlomador]

Clean install or overwrite ?

Chris:)

Both versions of operating system, with both versions of slim server. Completely removed, including deleting the actual folder and log files. Still the same.

[Stratmangler]

Both versions of operating system, with both versions of slim server. Completely removed, including deleting the actual folder and log files. Still the same.

Just checking - I've had issues myself and now completely remove installed versions before installing the latest version.

Can't say that I noticed any audible differences on the journey from 7.2 through to 7.4.1 , and at one stage I was doing A/B comparisons (2 machines, same OS, different versions of SC).

Chris:)

[Louishlomador]

Just checking - I've had issues myself and now completely remove installed versions before installing the latest version.

Can't say that I noticed any audible differences on the journey from 7.2 through to 7.4.1 , and at one stage I was doing A/B comparisons (2 machines, same OS, different versions of SC).

Chris:)

Mate, you may have the key to the answers. I really love Squeezebox, I intend to purchase the touch when out in the UK, however I have a have a strong feeling there is some kind of bug in the latest version but cant proof this obviously. Maybe you can do the test at your spare time or something.

1. Rip a CD in wave, say 24bit 44.1khz

2. change the file format to stream wave files in native format as I've already explained above.

Listen to it very carefully, preferably pick a track with lots of cymbals, and detailed background instruments.

3. Upgrade the software back to the latest version.
4. Make sure the file type for wave is still set to native and the other formats disabled.

5. Listen to the same track.

I would be surprised if you dont notice any differences. If anyone can try this and post results that will be great. Then we can put pressure on Slim to fix.

[ralphpnj]

Yes, there is a bit of a grey area here as if you had a cd player that was capable of playing at 24bit 96khz it will sound better than a CD player equiped with a dac capable of only 48khz, hence I rip at this resolution to extract every as much info as possible from the CD. The site below seems to do some great comparisms

http://www.tweakheadz.com/16_vs_24_bit_audio.htm

Hi Louis,

I'm not really trying to muddy the waters any further then they already seem to be but....

The link you posted is all about RECORDING not RIPPING. There is a big, big difference between the two.

When one is recording to digital or even converting an analog recording to digital (like an LP) things like bit depth and sample rate are very important and will have an effect on the audio quality of the recording.

Ripping, on the other hand, is an entirely different process. When one rips a standard CD, the digital audio on the CD is ALWAYS has a bit depth of 16 and a sample rate of 44.1kHz, regardless of the marketing BS stating otherwise. So ripping to anything other than 16/44.1 is NOT going to result in a "better" sounding recording, period. Again, marketing may say other wise, as is the case with many high end CD players and DACS which claim that "upsampling" the either the bit depth or the sample rate or both improves the sound of a CD.

Of course SACDs and DVD-Audio discs often have higher bit depth and sampling rates than standard CDs and so ripping them to bit depths and sample rates which match that of the recording can be of some benefit.

As far as digital recording is concerned using 24 bit instead of 16 bit gives one greater flexibility with respect to editing since the noise floor of a 24 bit recording is much greater than that of a 16t bit recording. In any event the article given in your link does a fairly good job of explaining all this but does fail to mention the difference between recording and ripping.

[Louishlomador]

Hi Louis,

I'm not really trying to muddy the waters any further then they already seem to be but....

The link you posted is all about RECORDING not RIPPING. There is a big, big difference between the two.

When one is recording to digital or even converting an analog recording to digital (like an LP) things like bit depth and sample rate are very important and will have an effect on the audio quality of the recording.

Ripping, on the other hand, is an entirely different process. When one rips a standard CD, the digital audio on the CD is ALWAYS has a bit depth of 16 and a sample rate of 44.1kHz, regardless of the marketing BS stating otherwise. So ripping to anything other than 16/44.1 is NOT going to result in a "better" sounding recording, period. Again, marketing may say other wise, as is the case with many high end CD players and DACS which claim that "upsampling" the either the bit depth or the sample rate or both improves the sound of a CD.

Of course SACDs and DVD-Audio discs often have higher bit depth and sampling rates than standard CDs and so ripping them to bit depths and sample rates which match that of the recording can be of some benefit.

As far as digital recording is concerned using 24 bit instead of 16 bit gives one greater flexibility with respect to editing since the noise floor of a 24 bit recording is much greater than that of a 16t bit recording. In any event the article given in your link does a fairly good job of explaining all this but does fail to mention the difference between recording and ripping.

Fare play, but still doesn't answer my conscerns though, about the versions of SC or slim server. Hopefully someone will test and post results

[andyg]

Hi, if you want to verify the transcoding using (to see if there is a bug such as WAV transcoding to FLAC even if you turn it off), go to Settings -> Advanced -> Logging, change player.source to INFO, play a file, and then view the server.log file. Buried among many log entries will be the command-line used for transcoding, if any.

[Louishlomador]

Hi, if you want to verify the transcoding using (to see if there is a bug such as WAV transcoding to FLAC even if you turn it off), go to Settings -> Advanced -> Logging, change player.source to INFO, play a file, and then view the server.log file. Buried among many log entries will be the command-line used for transcoding, if any.

Does it matter the version of Slim server or SC??

[andyg]

No, that logging option is generally the same.

[Louishlomador]

No, that logging option is generally the same.



ok, I'll try this. So to understand this my expectation will be when set to native based on a wave file, I'll expect streaming in Wav/PCM to the SB? does the logs will show this? and when set to the default, thus Flac it will show a different log?

[andyg]

ok, I'll try this. So to understand this my expectation will be when set to native based on a wave file, I'll expect streaming in Wav/PCM to the SB? does the logs will show this? and when set to the default, thus Flac it will show a different log?

Correct.

[Louishlomador]

Correct.

Ok, I'll test this for both versions 7.2.1 and 7.4.1 and keep you posted at the weekend.

[JohnSwenson]

A couple thoughts on the subject. I HAVE been able to hear differences on an SB3 between streaming flac or PCM (wav). A couple times I have thought something was amiss, things were sounding "flat". It turned out to be the file type settings had been changed (I certainly didn't change them)

In general I have not been able to tell any difference between flac or WAV files as long as both are streamed as PCM. There was one case where it made a difference. At one point streaming flac files was sounding much worse (much bigger difference than what I hear between flac and PCM streaming). It turned out the FLAC files had replay gain tags and of course the wav files did not. Somehow replay gain had been turned on so it was applying digital volume control. The particular firmware in the SB3 had a bug such that it was not properly implementing digital volume control. This has been fixed for a long time, so even with replay gain on, there is very little difference now (other than the volume!).

I've had many different versions recently (I'm a beta tester for the Touch) and have not heard any degradation in sound between any version. When I switched from 7.3 to 7.4 the firmware on the touch updated to version 130 but its remained the same for a long time now.

What version of the firmware are you running? If somehow it didn't upgrade when you changed SC versions that MIGHT cause a problem, but even thats doubtful.

The sound coming out of the SB3 with firmware 130 and the recent SBS versions have definately not been any worse and maybe slightly better than what was there before. (the Touch on the other hand has improved its sound significantly as things progressed, its now REALLY good).

John S.

[Phil Leigh]

You do know that by doing this you're rips are by definition lossy (you could do perfect 88khz rips though). I would never do this. I'd like to keep at least one copy of my rips as true to the originals as possible. Its possible that you're 48khz rips sounds better, or at least different; this is obviously dependend on the resampler used. But this is the point, since who knows what better resamplers could appear in the future. In which case one is likely to want the resampling done on the original files rather than on some already resampled files. Of course you could re-rip, but ripping is not that fun imo.

This is the key post so far.

Louis,

If you are ripping normal redbook CD's you must do it at 16/44.1. That's "lossless". Anything else introduces information that is NOT part of the original recording. Whether ripping at 24/48 makes things sound better or worse is debateable and only applies to your ears and your system.

However, the inescapable fact is you are not starting from a clean source.

By the way, I assume you are not using Replaygain?

Saving redbook as 24/48 on hard disk just wastes space, network and CPU.

If you wanted to you could use SOX (if your server is a PC) to upsample on the fly from 16/44.1 to 24/48 - that would only waste CPU and network.

Also, using WAV as the storage format makes little sense for many reasons. What you store as and what you stream as are, or can be, two different things as you have found.


That site you linked to by the way has nothing at all to do with ripping CD's...nothing.

Phil

[Louishlomador]

A couple thoughts on the subject. I HAVE been able to hear differences on an SB3 between streaming flac or PCM (wav). A couple times I have thought something was amiss, things were sounding "flat". It turned out to be the file type settings had been changed (I certainly didn't change them)

In general I have not been able to tell any difference between flac or WAV files as long as both are streamed as PCM. There was one case where it made a difference. At one point streaming flac files was sounding much worse (much bigger difference than what I hear between flac and PCM streaming). It turned out the FLAC files had replay gain tags and of course the wav files did not. Somehow replay gain had been turned on so it was applying digital volume control. The particular firmware in the SB3 had a bug such that it was not properly implementing digital volume control. This has been fixed for a long time, so even with replay gain on, there is very little difference now (other than the volume!).

I've had many different versions recently (I'm a beta tester for the Touch) and have not heard any degradation in sound between any version. When I switched from 7.3 to 7.4 the firmware on the touch updated to version 130 but its remained the same for a long time now.

What version of the firmware are you running? If somehow it didn't upgrade when you changed SC versions that MIGHT cause a problem, but even thats doubtful.

The sound coming out of the SB3 with firmware 130 and the recent SBS versions have definately not been any worse and maybe slightly better than what was there before. (the Touch on the other hand has improved its sound significantly as things progressed, its now REALLY good).

John S.



John,

I can understand all the points you've listed above. I dont have my CD's ripped in FLAC. I only have them ripped in Wave, however, you may be aware that slim server software by default is set to stream in flac as I've already mention, which is a fact. The very first generation of the software originally had it by default set to stream in PCM/Wave, that is if you use wave files. Things quickly changed. I have all the different versions, 7.2.1, 7.3, and 7.4.1. I even have 7.5 which as you know is not supported or made official yet. Install 7.2 on 1 machine, then install 7.4.1 on another. Play the same wave source on both versions making sure the files types for wav is set to native rather than the default flac. There is a difference between versions. Ofcourse the firmware will be updated on SB3 when you switch between versions. The point I'm trying to make which the slim device developer has picked up and requested I do the test with the logs is when you play wave files and stream in wave/PCM, in theory there shouldn't be any difference in sound quality for the versions of sofware. The dac hasn't changed, or harware, hence i expect the same sound reproduction regardless of software or firmware if not better. My argument is its worse with the new sofware rather than better. My suspicion is maybe the Flac conversion on the server packed with the firmware upgrade is not working properly. As I've already said the default is streamed in Flac and not PCM even if you have a wave file. Normally when you change to native you will notice the difference in sound quality for 7.2 because its now streaming in PCM mode, in 7.4 there are no differences and the sound is poorer. I hope this is now very clear. Maybe you could do the test and post your findings. Also as some people are not able to tell the difference in sound quality between flac and wave makes it even more difficult. As least you can. Hopefully your postings and findings will help make a better sofware. I love the product so much I'm inputing a lot of my energy to get it right, because I think the touch will even be a bigger sucess. Lets also not forget that the older you are the less sensitive your ear becomes. This is a fact too.

[Louishlomador]

This is the key post so far.

Louis,

If you are ripping normal redbook CD's you must do it at 16/44.1. That's "lossless". Anything else introduces information that is NOT part of the original recording. Whether ripping at 24/48 makes things sound better or worse is debateable and only applies to your ears and your system.

However, the inescapable fact is you are not starting from a clean source.

By the way, I assume you are not using Replaygain?

Saving redbook as 24/48 on hard disk just wastes space, network and CPU.

If you wanted to you could use SOX (if your server is a PC) to upsample on the fly from 16/44.1 to 24/48 - that would only waste CPU and network.

Also, using WAV as the storage format makes little sense for many reasons. What you store as and what you stream as are, or can be, two different things as you have found.


That site you linked to by the way has nothing at all to do with ripping CD's...nothing.

Phil

Phil,

This has already been pointed out. I think the focus now should be on the original question. Your findings between Flac and Wave in terms of sound quality on SB3 using different versions. I've already explained the test process. Maybe you can post your findings.

[Phil Leigh]

There is a very good reason why the default setting is to stream as FLAC, namely that for most people this will minimise issues with wi-fi bandwidth.

I've long abandoned the SB3 as I now have a Touch and as far as I am concerned the sound of the Touch (via s/pdif) is noticeably different and better (for me) than the SB3.

Several people in the past have been caught out by the Replaygain thing (including myself and JS) which is why I mentioned it - you should check that.


The storage format is irrelevant to sound quality (flac vs wav).
If you prefer to stream wav over flac that's fine. My data point is that on the Touch (7.5/latest nightly firmware) via s/pdif there is no audible or measurable difference to what comes out of my external DAC.

[Louishlomador]

There is a very good reason why the default setting is to stream as FLAC, namely that for most people this will minimise issues with wi-fi bandwidth.

I've long abandoned the SB3 as I now have a Touch and as far as I am concerned the sound of the Touch (via s/pdif) is noticeably different and better (for me) than the SB3.

Several people in the past have been caught out by the Replaygain thing (including myself and JS) which is why I mentioned it - you should check that.


The storage format is irrelevant to sound quality (flac vs wav).
If you prefer to stream wav over flac that's fine. My data point is that on the Touch (7.5/latest nightly firmware) via s/pdif there is no audible or measurable difference to what comes out of my external DAC.



Correct, the sound on the touch will sound better than SB3 mainly because its using a better DAC compared to the SB3. maybe as you are using an external DAC should make a difference. The bandwidth issue has already been mentioned too. Thanks for the advice.

[Stratmangler]

Hi Louis

When you have a WAV file at 16/44.1 you can use this tool to do a flac conversion http://members.home.nl/w.speek/flac.htm

The default settings should be ok - just make sure that "Delete input files" is unticked.

Then you can switch between files and compare.

It is also possible to convert the flac back to WAV - you may be interested in comparing the original with the decompressed version.

Chris:)

[Phil Leigh]

Phil,

This has already been pointed out. I think the focus now should be on the original question. Your findings between Flac and Wave in terms of sound quality on SB3 using different versions. I've already explained the test process. Maybe you can post your findings.

Louis, I presume you have studied this thread?

http://forums.slimdevices.com/showpost.php?p=396062&postcount=1

[Louishlomador]

Correct.

Hi Andy,

Please find attached the logs. I have labelled them accordingly to help diagnose. If any. I noticed the playback mode being different to both versions.

Thanks

[andyg]

Thanks. I'll just highlight the key lines from these files:

flac-SCV7.2.txt, WAV transcoded to FLAC:


[09-11-13 13:19:11.3793] Slim::Player::Source::openSong (2083) This is an wav file: file:///E:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav
[09-11-13 13:19:11.3798] Slim::Player::Source::openSong (2084) file type: wav format: flc inrate: 2304 maxRate: 0
[09-11-13 13:19:11.3803] Slim::Player::Source::openSong (2085) command: [flac] -cs --totally-silent --compression-level-0 --skip=$START$ --until=$END$ -- $FILE$
[09-11-13 13:19:11.3808] Slim::Player::Source::openSong (2104) Streaming with format: flc


wav-SCV7.2.txt, WAV streamed natively:


[09-11-13 13:39:13.6363] Slim::Player::Source::openSong (2083) This is an wav file: file:///E:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav
[09-11-13 13:39:13.6368] Slim::Player::Source::openSong (2084) file type: wav format: wav inrate: 2304 maxRate: 0
[09-11-13 13:39:13.6373] Slim::Player::Source::openSong (2085) command: -
[09-11-13 13:39:13.6377] Slim::Player::Source::openSong (2104) Streaming with format: wav


flac-version-SSv7.4.1.txt, WAV transcoded to FLAC:


[09-11-13 13:09:42.1565] Slim::Player::TranscodingHelper::getConvertCommand 2 (433) Matched: wav->flc via: [sox] -q -t wav $FILE$ -t flac -C 0 $RESAMPLE$ -
[09-11-13 13:09:42.1567] Slim::Player::Song::open (403) Transcoder: streamMode=I, streamformat=flc
[09-11-13 13:09:42.1569] Slim::Player::Song::open (451) Opening stream (no direct streaming) using Slim::Player::Protocols::File [file:///C:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav]
[09-11-13 13:09:42.1576] Slim::Player::Protocols::File::open (78) duration: [242.333] size: [69792156] endian [] offset: [44] for file:///C:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav
[09-11-13 13:09:42.1578] Slim::Player::Protocols::File::open (95) Opening file C:\Music\Watley, Jody\Flower\02 Watley, Jody - Flower.wav
[09-11-13 13:09:42.1584] Slim::Player::Protocols::File::open (173) Seeking in 0 into C:\Music\Watley, Jody\Flower\02 Watley, Jody - Flower.wav
[09-11-13 13:09:42.1588] Slim::Player::Song::open (472) URL is a song (audio): file:///C:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav, type=wav
[09-11-13 13:09:42.1596] Slim::Player::Song::open (548) Tokenized command "C:\PROGRA~1\SQUEEZ~2\server\Bin\MSWin32-x86-multi-thread\sox.exe" -q -t wav "-" -t flac -C 0 -
[09-11-13 13:09:42.1625] Slim::Player::Pipeline::new (93) Launching process with command: "C:\PROGRA~1\SQUEEZ~2\server\Bin\MSWin32-x86-multi-thread\socketwrapper.exe" -d -i 50206 -o 50205 -c "\"C:\PROGRA~1\SQUEEZ~2\server\Bin\MSWin32-x86-multi-thread\sox.exe\" -q -t wav \"-\" -t flac -C 0 -"


Wave-Version-SSv7.4.1.txt, WAV streamed natively:


[09-11-13 12:43:08.6924] Slim::Player::Song::open (362) file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav
[09-11-13 12:43:08.6934] Slim::Player::TranscodingHelper::getConvertCommand 2 (433) Matched: wav->pcm via: -
[09-11-13 12:43:08.6937] Slim::Player::Song::open (382) seek=false time=0 canSeek=1
[09-11-13 12:43:08.6942] Slim::Player::TranscodingHelper::getConvertCommand 2 (433) Matched: wav->pcm via: -
[09-11-13 12:43:08.6944] Slim::Player::Song::open (403) Transcoder: streamMode=I, streamformat=pcm
[09-11-13 12:43:08.6947] Slim::Player::Song::open (451) Opening stream (no direct streaming) using Slim::Player::Protocols::File [file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav]
[09-11-13 12:43:08.6954] Slim::Player::Protocols::File::open (78) duration: [218.293] size: [62868642] endian [] offset: [44] for file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav
[09-11-13 12:43:08.6956] Slim::Player::Protocols::File::open (95) Opening file C:\Music\Watley, Jody\Flower\01 Watley, Jody - Lovin' Youso.wav
[09-11-13 12:43:08.6962] Slim::Player::Protocols::File::open (173) Seeking in 44 into C:\Music\Watley, Jody\Flower\01 Watley, Jody - Lovin' Youso.wav
[09-11-13 12:43:08.6965] Slim::Player::Song::open (472) URL is a song (audio): file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav, type=wav


Everything looks normal and is working as intended. We did make a change in the transcoding binary used between these 2 versions though. We now use sox to transcoded to flac instead of the flac binary. This is because sox supports resampling (although it's not being used in your test). The flac output from sox is identical to the flac output from the flac binary.

[Louishlomador]

Louis, I presume you have studied this thread?

http://forums.slimdevices.com/showpost.php?p=396062&postcount=1

I have, Unfortunately I am not a fun of this software, as there are other things to take into considuration when doing the measurement. Believe me, even the quality of your internal computer sound card for doing the test will play a big role, or the connectors at the end of your PC. I am also sure we both agree on the type of Interconnects you use for the testing will play a role as well as some interconnects will handle the signal in a different way due to the caracteristics of the wire being used for the testing. I'll go with my ears. this might sound strange, however, at least i'm not the only person that has noticed the difference, so there you go. I'll recommend you test different music tracks. That will be the key. I will agree that with some music track you may not be able to tell the difference, depending on the instruments. I'm also not sure how vetted this software is. There you go mate

[Louishlomador]

Thanks. I'll just highlight the key lines from these files:

flac-SCV7.2.txt, WAV transcoded to FLAC:


[09-11-13 13:19:11.3793] Slim::Player::Source::openSong (2083) This is an wav file: file:///E:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav
[09-11-13 13:19:11.3798] Slim::Player::Source::openSong (2084) file type: wav format: flc inrate: 2304 maxRate: 0
[09-11-13 13:19:11.3803] Slim::Player::Source::openSong (2085) command: [flac] -cs --totally-silent --compression-level-0 --skip=$START$ --until=$END$ -- $FILE$
[09-11-13 13:19:11.3808] Slim::Player::Source::openSong (2104) Streaming with format: flc


wav-SCV7.2.txt, WAV streamed natively:


flac-version-SSv7.4.1.txt, WAV transcoded to FLAC:


[09-11-13 13:09:42.1565] Slim::Player::TranscodingHelper::getConvertCommand 2 (433) Matched: wav->flc via: [sox] -q -t wav $FILE$ -t flac -C 0 $RESAMPLE$ -
[09-11-13 13:09:42.1567] Slim::Player::Song::open (403) Transcoder: streamMode=I, streamformat=flc
[09-11-13 13:09:42.1569] Slim::Player::Song::open (451) Opening stream (no direct streaming) using Slim::Player::Protocols::File [file:///C:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav]
[09-11-13 13:09:42.1576] Slim::Player::Protocols::File::open (78) duration: [242.333] size: [69792156] endian [] offset: [44] for file:///C:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav
[09-11-13 13:09:42.1578] Slim::Player::Protocols::File::open (95) Opening file C:\Music\Watley, Jody\Flower\02 Watley, Jody - Flower.wav
[09-11-13 13:09:42.1584] Slim::Player::Protocols::File::open (173) Seeking in 0 into C:\Music\Watley, Jody\Flower\02 Watley, Jody - Flower.wav
[09-11-13 13:09:42.1588] Slim::Player::Song::open (472) URL is a song (audio): file:///C:/Music/Watley,%20Jody/Flower/02%20Watley,%20Jody%20-%20Flower.wav, type=wav
[09-11-13 13:09:42.1596] Slim::Player::Song::open (548) Tokenized command "C:\PROGRA~1\SQUEEZ~2\server\Bin\MSWin32-x86-multi-thread\sox.exe" -q -t wav "-" -t flac -C 0 -
[09-11-13 13:09:42.1625] Slim::Player::Pipeline::new (93) Launching process with command: "C:\PROGRA~1\SQUEEZ~2\server\Bin\MSWin32-x86-multi-thread\socketwrapper.exe" -d -i 50206 -o 50205 -c "\"C:\PROGRA~1\SQUEEZ~2\server\Bin\MSWin32-x86-multi-thread\sox.exe\" -q -t wav \"-\" -t flac -C 0 -"


Wave-Version-SSv7.4.1.txt, WAV streamed natively:


[09-11-13 12:43:08.6924] Slim::Player::Song::open (362) file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav
[09-11-13 12:43:08.6934] Slim::Player::TranscodingHelper::getConvertCommand 2 (433) Matched: wav->pcm via: -
[09-11-13 12:43:08.6937] Slim::Player::Song::open (382) seek=false time=0 canSeek=1
[09-11-13 12:43:08.6942] Slim::Player::TranscodingHelper::getConvertCommand 2 (433) Matched: wav->pcm via: -
[09-11-13 12:43:08.6944] Slim::Player::Song::open (403) Transcoder: streamMode=I, streamformat=pcm
[09-11-13 12:43:08.6947] Slim::Player::Song::open (451) Opening stream (no direct streaming) using Slim::Player::Protocols::File [file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav]
[09-11-13 12:43:08.6954] Slim::Player::Protocols::File::open (78) duration: [218.293] size: [62868642] endian [] offset: [44] for file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav
[09-11-13 12:43:08.6956] Slim::Player::Protocols::File::open (95) Opening file C:\Music\Watley, Jody\Flower\01 Watley, Jody - Lovin' Youso.wav
[09-11-13 12:43:08.6962] Slim::Player::Protocols::File::open (173) Seeking in 44 into C:\Music\Watley, Jody\Flower\01 Watley, Jody - Lovin' Youso.wav
[09-11-13 12:43:08.6965] Slim::Player::Song::open (472) URL is a song (audio): file:///C:/Music/Watley,%20Jody/Flower/01%20Watley,%20Jody%20-%20Lovin%27%20Youso.wav, type=wav


Everything looks normal and is working as intended. We did make a change in the transcoding binary used between these 2 versions though. We now use sox to transcoded to flac instead of the flac binary. This is because sox supports resampling (although it's not being used in your test). The flac output from sox is identical to the flac output from the flac binary.

Any explanation on the playmode for both version. I believe the playmode is 403 for 7.2 and 93 for 7.4. What are these figures??

[Louishlomador]

Everything looks normal and is working as intended. We did make a change in the transcoding binary used between these 2 versions though. We now use sox to transcoded to flac instead of the flac binary. This is because sox supports resampling (although it's not being used in your test). The flac output from sox is identical to the flac output from the flac binary.[/QUOTE]

I give up guys. If any further logs is required I will willingly provide. My ear is definately not deceiving me for sure. So If anyone wants any further logs or diagnostics etc then I will be very happy to provide all necessary details. For now it feels like a dead end to me.

Ta

[andyg]

Sorry to say but if you're not willing to use a tool like AudioDiffMaker to provide concrete evidence of the problem, there isn't much we can do to help. Your ears are not a good tool for measuring this, the placebo effect is too great.

[Louishlomador]

Sorry to say but if you're not willing to use a tool like AudioDiffMaker to provide concrete evidence of the problem, there isn't much we can do to help. Your ears are not a good tool for measuring this, the placebo effect is too great.

That is fine Andy. Surely I'm not the only person that has noticed the diffi
erence. Well if "nothing can be done" apart from using this software, which has already been used for the same testing and been proofen as having no difference in sound between flac and wav then my input using the same process is pointless I guess. There you go.

[andyg]

Yep, extraordinary claims require extraordinary evidence.

[pfarrell]

andyg wrote:
> Yep, extraordinary claims require extraordinary evidence.

Actually, we have heard zero evidence in this thread that there is a
real difference. We have heard an opinion that there is a difference.

Science and engineering don't work on opinions.

--
Pat Farrell
http://www.pfarrell.com/

[andyg]

Thanks Pat. :)

[Louishlomador]

Yep, extraordinary claims require extraordinary evidence.

Maybe they are extraordinary, for me they are not. Flac has only been in existence for 8 years, Fact whiles the wav has been in existence for much longer. Its not really about the length of time, to me its about the credibility of the product, i mean the file format. Some people can tell the difference, others cannot and its only now that more manufacturers are using the product. The issue is not really about the file format. Its about the version of software I guess. It may be doing everything as you said but surely not all the logs have been taken. Look, maybe I just have to accept its extraordinary. Thanks for your help anyway.

[andyg]

It's trivial to verify that FLAC is able to reproduce the original WAV file... but yeah, if you're not even willing to do that, you should stick with WAV.

[Louishlomador]

It's trivial to verify that FLAC is able to reproduce the original WAV file... but yeah, if you're not even willing to do that, you should stick with WAV.

Yes, certainly sticking to wav,and version 7.2 as 7.4.1 to me sounds different to 7.2. Maybe not, but we agree to disagree on this.

[cliveb]

Louis seems to be looking for a scientific explanation as to why he hears a difference between FLAC transcoded to WAV then streamed, versus streaming of native WAV, in spite of having been presented with lots of scientific evidence as to why the actual sound being made by the hardware is the same.

There is a huge body of scientific research that satisfactorily explains why Louis hears these differences, but it's not in the domain of engineering. It's psychological - if you expect to hear a difference, you will.

[Louishlomador]

Louis seems to be looking for a scientific explanation as to why he hears a difference between FLAC transcoded to WAV then streamed, versus streaming of native WAV, in spite of having been presented with lots of scientific evidence as to why the actual sound being made by the hardware is the same.

There is a huge body of scientific research that satisfactorily explains why Louis hears these differences, but it's not in the domain of engineering. It's psychological - if you expect to hear a difference, you will.

Maybe its psychological, however that is your view. others have heard the difference and i believe strongly there are so many factors, such as The quality of your system, Even the circuutry of your electronic component, what ampifier you are using, what DAC etc. We can go on and on. The issue is not about Flac. I can tell the difference between flac and wav in terms of how they sound. others cannot. My issue is the difference between the softwares. That is the main conscern. The only reason why FLac and Wav is part of the discussion was my original thought that version 7.4.1 was transcoding in Flac. whiles 7.2 was in PCM. This has been proofen by the slim developer as not the case when set to native and playing a wav file, hence no need to go on. Check the logs. We agree to disagree that flac sounds the same as wav. Yes i know when you covert flac back to wave you do get the same number of bytes as the original wav file. Definately not doubting the maths behind this, however to me the file formats sound different. To you its psychological, to me its not. Hope this finally explains where i stand on this.Surely you will accept that some people find vynyl recordings sounding different from CD recordings. Some prefer Vynyl recordings compared to CD, athough technically CD recordings seem the better option. Some vynyls will even sound better than CD players. Technical, yes Flac files as far as it goes are lossless. However to me it doesn't mean they dont sound different. I still have my conscern for 7.4.1. I'll stick to 7.2

[Robin Bowes]

On 13/11/09 17:25, Louishlomador wrote:
# We can go on and on.

You certainly seem to be doing so.

R.

[Phil Leigh]

I have, Unfortunately I am not a fun of this software, as there are other things to take into considuration when doing the measurement. Believe me, even the quality of your internal computer sound card for doing the test will play a big role, or the connectors at the end of your PC. I am also sure we both agree on the type of Interconnects you use for the testing will play a role as well as some interconnects will handle the signal in a different way due to the caracteristics of the wire being used for the testing. I'll go with my ears. this might sound strange, however, at least i'm not the only person that has noticed the difference, so there you go. I'll recommend you test different music tracks. That will be the key. I will agree that with some music track you may not be able to tell the difference, depending on the instruments. I'm also not sure how vetted this software is. There you go mate

I agree that you need to use a variety of music as some shows differences more clearly. This is definitely true. However, the cables etc are a constant and we are looking for a delta here.


Your ears (and mine) are the most unreliable tools on the planet. Actually it's not our ears, but our brains...

Just because a thousand people "noticed" a difference doesn't mean there actually is one.

The software works just fine. This is easily proven by using a control test.

Anyway, the good news is that this afternoon I have retrieved my SB3 from the loft and wired it up. I can run some fresh tests with SB3 and Touch.

The quality of the ADC in my soundcard in my PC is not going to be an issue here. I have owned and used some of the very best soundcards available. Certainly more than the average audiophile.

The rest I'm afraid is just maths.

I'd love to know what else there is to "take into consideration" ?
Your ears are better than the software? - anyone making this claim is going to face VERY stiff opposition. If this is the basis for your remarks, then I have a little test for you :-)

[Phil Leigh]

To you its psychological, to me its not.

I'm not sure we are going to make any progress with this... Everybody's perception of better/worse is "psychological"! (or at least psychoacoustic)

[Themis]

Louis, I don't understand what you're talking about.

I have 7.4.2 installed, I put the parameters as I explained for transcoding to WAV at the server, and the server transcodes normally (to WAV/PCM). An sends this PCM to the client.

Now, you seem to say that you have some kind of difference between WAV transcoded at the server and the WAV sent directly without transcoding ?

Is that what you're saying ? oO

[Louishlomador]

Louis, I don't understand what you're talking about.

I have 7.4.2 installed, I put the parameters as I explained for transcoding to WAV at the server, and the server transcodes normally (to WAV/PCM). An sends this PCM to the client.

Now, you seem to say that you have some kind of difference between WAV transcoded at the server and the WAV sent directly without transcoding ?

Is that what you're saying ? oO

Certainly not. my original thought, was that 7.4.1 transcodes in flac no matter whether you've changed it from native to flac, however Andy has profen not to be the case. I was thinking maybe that is the reason for the differences bewtween 7.2 to 7.4. I still prefer 7.2, to 7.4.1. Yes 7.4.1 on the logs transcodes the wav to PCM on the player. Still cannot figure out why there is the difference in sound when running both applications to stream wav in native format.

[Themis]

Certainly not. my original thought, was that 7.4.1 transcodes in flac no matter whether you've changed it from native to flac, however Andy has profen not to be the case. I was thinking maybe that is the reason for the differences bewtween 7.2 to 7.4. I still prefer 7.2, to 7.4.1. Yes 7.4.1 on the logs transcodes the wav to PCM on the player. Still cannot figure out why there is the difference in sound when running both applications to stream wav in native format.
Well, it does not seem to do this on my 7.4.2
The log is:

[09-11-13 19:00:45.4328] Slim::Player::TranscodingHelper::enabledFormat (199) Checking to see if flc-flc-*-* is enabled
[09-11-13 19:00:45.4331] Slim::Player::TranscodingHelper::enabledFormat (207) There are 2 disabled formats...
[09-11-13 19:00:45.4334] Slim::Player::TranscodingHelper::enabledFormat (213) Testing flc-flc-*-* vs flc-flc-*-*
[09-11-13 19:00:45.4336] Slim::Player::TranscodingHelper::enabledFormat (217) ** flc-flc-*-* Disabled **
[09-11-13 19:00:45.4339] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-aif-squeezebox2-00:04:20:12:29:44
[09-11-13 19:00:45.4342] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-aif-*-00:04:20:12:29:44
[09-11-13 19:00:45.4345] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-aif-squeezebox2-*
[09-11-13 19:00:45.4348] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-aif-*-*
[09-11-13 19:00:45.4350] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-pcm-squeezebox2-00:04:20:12:29:44
[09-11-13 19:00:45.4353] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-pcm-*-00:04:20:12:29:44
[09-11-13 19:00:45.4356] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-pcm-squeezebox2-*
[09-11-13 19:00:45.4359] Slim::Player::TranscodingHelper::checkBin (232) Checking formats for: flc-pcm-*-*
[09-11-13 19:00:45.4362] Slim::Player::TranscodingHelper::enabledFormat (199) Checking to see if flc-pcm-*-* is enabled
[09-11-13 19:00:45.4365] Slim::Player::TranscodingHelper::enabledFormat (207) There are 2 disabled formats...
[09-11-13 19:00:45.4368] Slim::Player::TranscodingHelper::enabledFormat (213) Testing flc-flc-*-* vs flc-pcm-*-*
[09-11-13 19:00:45.4371] Slim::Player::TranscodingHelper::enabledFormat (213) Testing wav-flc-*-* vs flc-pcm-*-*
[09-11-13 19:00:45.4374] Slim::Player::TranscodingHelper::checkBin (240) enabled
[09-11-13 19:00:45.4377] Slim::Player::TranscodingHelper::checkBin (242) Found command: [flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$

[andyg]

Please note that there is no transcoding going on from WAV -> PCM. PCM is just WAV with the first 44 bytes removed. The firmware does not read the WAV header, so we don't send it.

[Louishlomador]

I'm not sure we are going to make any progress with this... Everybody's perception of better/worse is "psychological"! (or at least psychoacoustic)

Mate,

I'm certainly not doubting your findings. Would you say a Vynyl recording sounds different from CD recording? Would you say a philips DAT recording sounds similar to the source of recording,say CD? If you can tell the difference then its big enough for your brain/ear to pick this up, without having to use other forms to differentiate. The version of software isssue is a grey area as I dont think everyone has the same issue. However if you have 7.2, why dont you do some test? Try it, then i know for sure maybe this could an issue technically on my side. The difference is big enough for my brain/ear to pick up.

[Louishlomador]

[QUOTE=Themis;485124]Well, it does not seem to do this on my 7.4.2
The log is:




Maybe because its a different version. I dont think you can argue too much on that as this version is probably not official yet. But i agree, it definateley looks different. Same for 7.2 and 7.4.1

[Themis]

I guess that if there are differences with prior versions, you can open a bug ?

[Louishlomador]

I guess that if there are differences with prior versions, you can open a bug ?

Very debatable. You are right though. Maybe if more people notice the difference in sound quality between 7.2 and 7.4.1 then that will be justified. For now i havent got a leg to stand on. Its only 2 people that have noticed some change.

[Themis]

I don't think the question of sound quality plays a part here : if the server is supposed to transcode to PCM (due to the setup) and it does not, it is definitely a bug. ;)

[Louishlomador]

I don't think the question of sound quality plays a part here : if the server is supposed to transcode to PCM (due to the setup) and it does not, it is definitely a bug. ;)

Is this based on your log?

[Louishlomador]

Please note that there is no transcoding going on from WAV -> PCM. PCM is just WAV with the first 44 bytes removed. The firmware does not read the WAV header, so we don't send it.

for which version?

[Themis]

Is this based on your log?
My log seems to do the right thing : send PCM to the Client with the appropriate setup (although I have mainly FLACs).
If yours does something else (ie does not send PCM when it should), then it is a bug.

[cliveb]

To you its psychological, to me its not. Hope this finally explains where i stand on this.
You're missing the point I was trying to make. Let me try a different tack:

You hear a difference between two setups. It doesn't really matter whether we're talking about WAV v FLAC or 7.2 v 7.4 both streaming WAV. What is absolutely not in any question is that you hear a difference. Now we need to figure out why.

All of the engineering evidence suggests with extremely high probability that there is no difference in the sound being reproduced between the two setups.

Meanwhile there is a large body of *scientific* psychological research which explains very well why you perceive a difference.

You seem unwilling to acknowledge the overwhelming liklihood that the reason for your perception of the difference is due to psychological rather than engineering issues. Audiophiles often take this position - that admitting their brains can be fooled in matters auditory is some kind of character flaw. But it is nothing of the sort. It happens to everyone, we are all susceptible. Indeed, if you *weren't* susceptible to these psychological influences, *then* you would be a freak.

[Phil Leigh]

Just want to clear one part of this up: with the correct File Types settings, WAV definitely streams as PCM whilst FLAC definitely streams as FLAC.

I use a special custom_convert.conf file that upsamples FLAC but not WAV and I can see on the display on my TACT exactly what is happening. WAV streams as PCM and FLAC streams as FLAC.

A quick Audiodiffmaker test on an SB3 (analogue outputs recorded at 24/192) using the Linn Sanctus file (16/44.1) saved to disk and streamed as both flac and wav gives a -83dB correlation which is pretty good given the noise floor of the SB3 analogue outs. In other words, no difference. This is with SBS 7.5, FW 130.

I'm going to install 7.2.1 on another PC and repeat the test.

By the way, please don't suggest that the Audiodiffmaker software might not pick up tiny differences - it is trivial to prove that the software works "perfectly" - give it 2 identical files and it produces digital silence. change just one sample in one of the files and it detects it! You can change the gain or the sample rate/time offset/length of one of the files and it will still find that one sample. It's really very good.

My audio card can repeatedly detect the tiny rise in the SB3 noise floor with brightness on 2 vs brightness on 3 so that's out of the equation too.

It will take a while to do the 7.2.1 test...

[Phil Leigh]

In theory, all of the following should produce nearly identical results:

7.2 FLAC vs 7.2 WAV -71dB correlation difference track inaudible
7.2 FLAC vs 7.5 FLAC -86dB correlation difference track inaudible
7.2 WAV vs 7.5 WAV -75dB correlation difference track inaudible
7.2 WAV vs 7.5 FLAC -71dB correlation difference track inaudible
7.2 FLAC vs 7.5 WAV -51dB ... difference track is audible (with boost)
7.5 WAV vs 7.5 FLAC -88dB correlation difference track inaudible

hmmm... I can't explain result #5
Will repeat the tests tomorrow.

[Louishlomador]

In theory, all of the following should produce nearly identical results:

7.2 FLAC vs 7.2 WAV -71dB correlation difference track inaudible
7.2 FLAC vs 7.5 FLAC -86dB correlation difference track inaudible
7.2 WAV vs 7.5 WAV -75dB correlation difference track inaudible
7.2 WAV vs 7.5 FLAC -71dB correlation difference track inaudible
7.2 FLAC vs 7.5 WAV -51dB ... difference track is audible (with boost)
7.5 WAV vs 7.5 FLAC -88dB correlation difference track inaudible

hmmm... I can't explain result #5
Will repeat the tests tomorrow.


Cheers Phil, much appreciated

Maybe you can do the test for 7.4.1 as well compared to 7.2. Are you doing these tests with wave streaming natively when playing a wave file and then changing the server settings to stream the wav file as flac? Lets not forget by default the server software is set to stream wav files in flac. Basically you
1. Test outputs with Diff software when playing a wav file to stream as Wave/PCM then change the settings on the slim server to the default, which streams wav files in flac by default then test the outputs with Diff software again.


Reapeat the same for 7.4.1. I am also interested to see the difference for 7.5 as well. So far it seems with boost there is a difference. If this stands then that will explain a few things guess. Just logged in quickly to catchup on any interesting postings. Cheers

[JohnSwenson]

I tried to do some AudioDiffMaker tests this weekend on a Touch and was not very successful. I could not get a decent null on even the same track played with identical settings. I did this many times with several different ADCs and could not get a decent null (26dB!) when using the adaptive gain. When I turned that off I could get a 70dB null but that was it, I could still hear the music in the diff track so I don't think it was just due to noise.

At this point I don't know why I'm having so much trouble with this. The software is supposed to be able to get a BETTER null with the adaptive gain than without, but that does not seem to be happening, so there seems to be something wrong either with the software (or more likely) my use of it.

BTW you can read my listening impressions of these tests in the Touch forum in the TinySC audibility thread.

John S.

[Phil Leigh]

I tried to do some AudioDiffMaker tests this weekend on a Touch and was not very successful. I could not get a decent null on even the same track played with identical settings. I did this many times with several different ADCs and could not get a decent null (26dB!) when using the adaptive gain. When I turned that off I could get a 70dB null but that was it, I could still hear the music in the diff track so I don't think it was just due to noise.

At this point I don't know why I'm having so much trouble with this. The software is supposed to be able to get a BETTER null with the adaptive gain than without, but that does not seem to be happening, so there seems to be something wrong either with the software (or more likely) my use of it.

BTW you can read my listening impressions of these tests in the Touch forum in the TinySC audibility thread.

John S.

John - are you using version 3.2?

You will need to have Gain Alignment and Time Alignment checked on the settings page.

As a test, what happens if you rund the SAME file as the reference and compared tracks?

[Louishlomador]

John - are you using version 3.2?

You will need to have Gain Alignment and Time Alignment checked on the settings page.

As a test, what happens if you rund the SAME file as the reference and compared tracks?

Any new developement guys?? on the testing front?

[Phil Leigh]

Any new developement guys?? on the testing front?

Things are progressing nicely. There should be some results we can share soon. This is an International effort now ;-) so timezones are a problem.

We've been sidetracked into testing the Touch. I expect before too long we will have a comprehensive set of results for Touch, SB3 and Transporter.
Sorry for the delay.
Phil

[Louishlomador]

Things are progressing nicely. There should be some results we can share soon. This is an International effort now ;-) so timezones are a problem.

We've been sidetracked into testing the Touch. I expect before too long we will have a comprehensive set of results for Touch, SB3 and Transporter.
Sorry for the delay.
Phil

ok

[Themis]

Things are progressing nicely. There should be some results we can share soon. This is an International effort now ;-) so timezones are a problem.

We've been sidetracked into testing the Touch. I expect before too long we will have a comprehensive set of results for Touch, SB3 and Transporter.
Sorry for the delay.
Phil
We expect nothing less than quality from you, Phil, so take your time. ;)

[Louishlomador]

It will take a while to do the 7.2.1 test...[/QUOTE]





Hi Guys,

I guess you've given up on this? or no time to deal with it?

[Phil Leigh]

It will take a while to do the 7.2.1 test...





Hi Guys,

I guess you've given up on this? or no time to deal with it?

Been sidetracked... see other posts.

However, the news (in brief) is that there is NO difference between streamed WAV or FLAC on SB3 or Touch with any recent version of SBS (7.3, 7.4 or 7.5)

[Stratmangler]

Been sidetracked... see other posts.

However, the news (in brief) is that there is NO difference between streamed WAV or FLAC on SB3 or Touch with any recent version of SBS (7.3, 7.4 or 7.5)

Good to hear that Phil, 'cos I couldn't hear any differences between the two file types either.

Chris;)

[marcoc1712]

Hi All,

After reading your posts, curiosity moved me to try, so i spent the long Week end (from friday to tuesday, was Holyday in Italy) lissening to different music and looking for differences.

I was skeptic, becouse i knew and i'ìve personaly verified that you can convert from wave to flac and viceversa any time you want, but if you compare the two wave files are BIT PERFECT, so i was realy surprised about the results:

in my personal experience, limitetd at SB+ and 7.4.1, there is a little but audible difference in playng Wave or Flac files, more strange (to me) is that the same type of differences (reduced) still remain if you play a flac file 'converted' in wave at the server side.

In few words those are the major difference to me:

a) Stereo Image:

Playng the Wave file, the scene is more focused and deeper, but smaller, means that if you play i.e. "Old Love" from Eric Clapton Umplugged album, mr. Clapton seems to be 10 cm shorter, the bass is behind and not on top of the voice, the piano asolo is not so far in the left.

b)Sound 'color':

Playng Flac, voices, arcs and cimbals are a little bit 'harder' and cold, some 'electric' take place, in wave they are smoorher, some more air around and more 'natural'. No big differences in bass, maybe a bit more control in wave.

All above IMHO and i want to point that differences are small but auidible in my system, if you pay attention to details in a critical lissening session. Also in 'blind test' I always recogniced the WAVE (non always the flac and the flac converted in wave)if played in sequence.

Last point: often in the past, after a long listening session (I love Wagner, so you can imagine how long they are...) I founded myself claiming about some roughness and "nasality" (hope is correct in english)in the sound, that make me tired, my first impression today, but i've to try for much more time, is that playing wave files make this point better (far away form LP's, anyhow).

At the end of the day, and just to give you an idea, changes are similar to the one I had using an AC insulator transformer on the Amplifier power line.

I personaly think is not a matter of file format that is proven to be truly lossless, but some difference is in, maybe some tech guy could think about?

My library is FLAC and now i'm thinking to move it back to WAVE, payng the cost of more disk space.

Hope to be usefull, some other guy had similar experience?

regards, Marco.

[Phil Leigh]

Hi All,

After reading your posts, curiosity moved me to try, so i spent the long Week end (from friday to tuesday, was Holyday in Italy) lissening to different music and looking for differences.

I was skeptic, becouse i knew and i'ìve personaly verified that you can convert from wave to flac and viceversa any time you want, but if you compare the two wave files are BIT PERFECT, so i was realy surprised about the results:

in my personal experience, limitetd at SB+ and 7.4.1, there is a little but audible difference in playng Wave or Flac files, more strange (to me) is that the same type of differences (reduced) still remain if you play a flac file 'converted' in wave at the server side.

In few words those are the major difference to me:

a) Stereo Image:

Playng the Wave file, the scene is more focused and deeper, but smaller, means that if you play i.e. "Old Love" from Eric Clapton Umplugged album, mr. Clapton seems to be 10 cm shorter, the bass is behind and not on top of the voice, the piano asolo is not so far in the left.

b)Sound 'color':

Playng Flac, voices, arcs and cimbals are a little bit 'harder' and cold, some 'electric' take place, in wave they are smoorher, some more air around and more 'natural'. No big differences in bass, maybe a bit more control in wave.

All above IMHO and i want to point that differences are small but auidible in my system, if you pay attention to details in a critical lissening session. Also in 'blind test' I always recogniced the WAVE (non always the flac and the flac converted in wave)if played in sequence.

Last point: often in the past, after a long listening session (I love Wagner, so you can imagine how long they are...) I founded myself claiming about some roughness and "nasality" (hope is correct in english)in the sound, that make me tired, my first impression today, but i've to try for much more time, is that playing wave files make this point better (far away form LP's, anyhow).

At the end of the day, and just to give you an idea, changes are similar to the one I had using an AC insulator transformer on the Amplifier power line.

I personaly think is not a matter of file format that is proven to be truly lossless, but some difference is in, maybe some tech guy could think about?

My library is FLAC and now i'm thinking to move it back to WAVE, payng the cost of more disk space.

Hope to be usefull, some other guy had similar experience?

regards, Marco.

Marco,
The differences you describe do not show up in testing with AudioDiffMaker.
The analogue output from both SB3 and the new Touch are identical with WAV vs Flac, as is the spdif via an external DAC.

[garym]

Assuming there is truly blind testing going on here, I'd assume the difference is the typical case created when there is even a slight volume difference in the playback of the two files. It is well documented that this preference bias can exist with even tiny volume differences.

In this particular case, do the FLAC files have replaygain info and is the SB player set to use such info in playback? If so, there certainly could be imperceptible volume differences between the FLAC and WAV files on playback, but these differences could be affecting your preferences between the two files.

[Phil Leigh]

Assuming there is truly blind testing going on here, I'd assume the difference is the typical case created when there is even a slight volume difference in the playback of the two files. It is well documented that this preference bias can exist with even tiny volume differences.

In this particular case, do the FLAC files have replaygain info and is the SB player set to use such info in playback? If so, there certainly could be imperceptible volume differences between the FLAC and WAV files on playback, but these differences could be affecting your preferences between the two files.

I think that expectation bias may also play a part...
RG (which has caught me out in the past too) would typically give quite large differences in output...

[garym]

I think that expectation bias may also play a part...
RG (which has caught me out in the past too) would typically give quite large differences in output...

Yep, agree on both counts. If this not a true ABX test on the part of the OP, then these results are hardly worth discussing given the typical expectation bias. Re the RG adjustments, I do have some files (typically from older CDs) that have very, very small RG adjustments. On one of these files, I would probably prefer the louder version without realizing that the volume was even different.

[Phil Leigh]

Yep, agree on both counts. If this not a true ABX test on the part of the OP, then these results are hardly worth discussing given the typical expectation bias. Re the RG adjustments, I do have some files (typically from older CDs) that have very, very small RG adjustments. On one of these files, I would probably prefer the louder version without realizing that the volume was even different.

My RG tag for the track mentioned earlier is -3.66dB - should be very audible?

[garym]

My RG tag for the track mentioned earlier is -3.66dB - should be very audible?

sorry, was not referring to one of the files mentioned in this thread (but one of my own files with a small RG adjustment).

[marcoc1712]

Hi all,

I do not use RG (disabled), so i think is not a matter of volume.

By the way, every difference in audio is a matter of "Volume difference" depending on "where" and "how" the difference is, you have good or bad sounding devices!

Anyhow, I think that IF there is a volume difference, it will be clearly detectet by AudioDiffMaker, Phil have you detected any in your test? If Yes, you can't say the results are identical, but just that in your evaluation the difference is inaudible, correct? If not, than is a good point:

a. I'm a placebo effect victim (99% probabylites).
b. difference are not in the measure focus of the software (1% probs).

I don't Know the software and how it works, have you tried if it's able to detect differences as little as the one due, for instance, to a different digital cable or power suply?

At the end, as Socrates did, i want to post you a dubt:

IF for SB is exactly the same to play a WAVE or a FLAC converted to WAVE in the server side, why in the first case the FF/REW is disabled and is working in the second?

Im not an expert, but to me this mean that the signal flow at least into a one more 'logical' if not 'fisical' block, so by definition is not 'exactly' the same. I'm not stating that this is the cause, i realy have no idea about, but just to let you think maybe something different is in place...

Please, spend half an hour lissen at beethoven Piano concerto - Anne Sophie Von Mutter - Herbert Von karayan - BPO, second movment and tell me if the Solo violin approach sound exactly the same to you or if is only a volume matter, in the worst case, you'll listen to some very good music, and I'll be happy to know that I can save undreds Euros in HD space (more music to buy!)

Thanks, Marco.

[snarlydwarf]

IF for SB is exactly the same to play a WAVE or a FLAC converted to WAVE in the server side, why in the first case the FF/REW is disabled and is working in the second?


Because transcoding makes it hard for the server to know where exactly it is in the bitstream.... it doesn't have a fullblown API to talk to flac's decoder to say, "okay, decode the next 20930 samples", nor is it possible to tell the flac decoder "hey, please go back 20930 samples" or get samples of the samples to do the fast-forward with sound.

So FLAC -> FLAC works with FF/REW.

So does WAV -> WAV.

You can run the flac decoder yourself to create a WAV file on your disc, and then you can seek -that- file.

You just can't seek transcoded material because that is FAR more complex and flac.exe does not allow it, nor does SBS have a way to tell it how/where to seek while decoding.

[marcoc1712]

So FLAC -> FLAC works with FF/REW.

So does WAV -> WAV.


This sound like a good explanation to me, but...

Actualy (7.4.1) you could not operate FF/REW in WAV -> WAV (at least if you are using a .cue file, you can in a single wav file - just tried after your post, strange, is'nt it?), but is possible in FLAC converted to WAV (regardless results...)

So what? Is WAV, WAV (.cue), FLAC or FLAC -> WAV playback "Exactly the same" for SB? Are you 100% sure?

PLEASE NOTE:

I Know and I've personaly tested that the conversion process beetween WAV and FLAC is BIT PERFECT both ways, this is not the point, I'm using (static) converted files for the trials, so I completley agree that playng a WAV or a converted FLAC to WAV after the conversion had place is NOT causing any difference in sound.

IF (remember, 99% probs is up to my suggestion) there is a difference should be generated by the process (from the conversion in the server/SB to the playback in SB, or somewere else in the system, maybe due to different signal path, ingenerated EMI or else, I'm not qualified to investigate this).

Maybe is an issue only in my system, that's why i'm asking if you can ear it in other systems, if noboby can, OK, it's just my problem and i'll solve someway, if yes, maybe could be pointed and solved sooner or later.

p.s.

I'm (or better I was...) an IT engineer now managing my consulting company, but in the past I was operating in the software quality assurance, I know very well the first role about users claims... but often the bug IS somewere, normaly in place were you ever think it never flows in!

Regards, Marco.

[snarlydwarf]

This sound like a good explanation to me, but...

Actualy (7.4.1) you could not operate FF/REW in WAV -> WAV (at least if you are using a .cue file, you can in a single wav file - just tried after your post, strange, is'nt it?), but is possible in FLAC converted to WAV (regardless results...)


For much the same reason: the cue sheet confuses SB, it would then have to apply offsets to each and every seek. In this case it would be doable, but is very very low priority considering how many people use cue sheets to begin with, let alone with WAV's...



IF (remember, 99% probs is up to my suggestion) there is a difference should be generated by the process (from the conversion in the server/SB to the playback in SB, or somewere else in the system, maybe due to different signal path, ingenerated EMI or else, I'm not qualified to investigate this).


If running flac on your PC to convert a file to or from flac/wav generates sufficient EMI to alter the sound at your SB, you should evacuate your house: it will have serious health effects.



Maybe is an issue only in my system, that's why i'm asking if you can ear it in other systems, if noboby can, OK, it's just my problem and i'll solve someway, if yes, maybe could be pointed and solved sooner or later.


The issue is in your brain: the effect you are experiencing is entirely psychological.



I'm (or better I was...) an IT engineer now managing my consulting company, but in the past I was operating in the software quality assurance, I know very well the first role about users claims... but often the bug IS somewere, normaly in place were you ever think it never flows in!

And often the bug is with the user.

Your assertions make no sense: the TCP packets from flac decoding on the fly -must- equal those made from the wav or it would not work. And, if EMI output from your PC varies enough to create serious EMI in your house, you have much greater concerns than audio quality.

Your brain is a very complicated audio processor: the catch is that it is VERY easy to fool your brain.

[Phil Leigh]

Hi all,

I do not use RG (disabled), so i think is not a matter of volume.

By the way, every difference in audio is a matter of "Volume difference" depending on "where" and "how" the difference is, you have good or bad sounding devices!

Anyhow, I think that IF there is a volume difference, it will be clearly detectet by AudioDiffMaker, Phil have you detected any in your test? If Yes, you can't say the results are identical, but just that in your evaluation the difference is inaudible, correct? If not, than is a good point:


Thanks, Marco.

Marco,
the whole point about ADM is that it does indeed detect and correct for very tiny differences (< 0.001dB !) in level.


So, here are my test results with my new M-Audio 24/96 card:

Test 1: Playback of 16/44.1 WAV file vs FLAC file recorded via SB3 analogue @24/96:

Result 1: -110dB null, content= white noise, no trace of music at all, zero sample drift


Test 2: Playback of 16/44.1 WAV file vs FLAC file recorded via Touch analogue @24/96:

Result 2: -111dB null, content= white noise, no trace of music at all, 0.02ppm sample drift


All tests averaged over 10 runs (20 mind numbing tests, restarting ADM each time to avoid spurious results.)

Ambient Temperature averaged 20.5 degrees throughout.

[marcoc1712]

Hi All,

the discussion drive somewere i'm not interested to go, let's fix some BASIC point following a 'logical' path:

1. I've NEVER STATED the TCP/IP packet are different anyhow - I really don't Know- ,i've just stated that SB behave in different ways depending on the file type IN origin (FLAC or WAV), not on the incoming "TPC/IP package structure" (more over if they are supposed to be exactly the same).

I think You could agree with me on this, at least regarding FF/REW.

Again I'm not stating FF/REW is the cause of ANY difference in sound, but just that IS a difference.

Could we agree those two point are right? Or - again - are only in my brain?

Forget about EMI and other, was only a paradox example to figure out that I DO NOT Know the relationship - if one - between different behaviour and different sound, I could wrote about vibrations or whatever else(please don't tell me that i need a tellurical safe house now :-), the point is: DIFFERENCE ARE IN PLACE.

2. Phil measured the output from SB playng FLAC and WAV and detect no or very little differences, out of the audible range in his opinion. By the way, this EXCLUDE any gain difference.

For sure I do belive in Phil report (the only thing missing is umidity ratio and altitude :-).

So, the "unified" statement resulting from the discussion could sound like:

"Playng FLAC converted to WAV and WAV files, SB operate in different ways at least regarding the FF/REW options, depending on the file type. From the tech point of view, those differences should not affecting the sound at all , in fact some measure taken at the ouptut stage, confirm no or very little differences, out of the audible range, indeed someone claim to ear some difference in the sound".

Could we agree on that form?

If Yes, ok, is quite different to me than "IS EXACTLY THE SAME" and "IS EVERYTHING ABOUT YOUR BRAIN" (that still think is true at 99%!!!), and my original question make sense (at least to me), so please, could you report your listening opinion?

Thanks.

Marco

[garym]

So, the "unified" statement resulting from the discussion could sound like:

"Playng FLAC converted to WAV and WAV files, SB operate in different ways at least regarding the FF/REW options, depending on the file type. From the tech point of view, those differences should not affecting the sound at all , in fact some measure taken at the ouptut stage, confirm no or very little differences, out of the audible range, indeed someone claim to ear some difference in the sound".

Could we agree on that form?

If Yes, ok, is quite different to me than "IS EXACTLY THE SAME" and "IS EVERYTHING ABOUT YOUR BRAIN" (that still think is true at 99%!!!), and my original question make sense (at least to me), so please, could you report your listening opinion?

Thanks.

Marco

Hi Marco. Interesting discussion (and I agree that there is potential for differences when the playback chain is not identical, as in the potential software or hardware conversion going on here). I'd agree with your statement above if we could say instead that "someone reported the results of 10 trials in a blind ABX listening test and was able to detect differences in the SB playing a FLAC vs WAV file."

But I'm not sure this is actually the case here. Maybe I missed it in an earlier post, but it has never been clear to me if you've done any sort of blind testing (ABX or not) to insure unintended biases are not sneaking in to your perceptions. Many people that swear they detect differences in playback discover that they can't do any better than random in blind ABX tests.

http://wiki.hydrogenaudio.org/index.php?title=ABX

[Themis]

Maybe is an issue only in my system, that's why i'm asking if you can ear it in other systems, if noboby can, OK, it's just my problem and i'll solve someway, if yes, maybe could be pointed and solved sooner or later.
Hi Marco,

at one point (at version 6.something) , there was a slight difference indeed. It disappeared on the next version.

Since then, I've been tracking differences (I'm a bit fussy, and don't care about bandwidth as my SB is hard-wired through an Eth switch), and I haven't noticed any difference. I'm currently at 7.5 (beta), but I stayed at 7.4.1 for months without noticing anything.

No point in wondering : if you don't feel convinced, simply convert to WAV on the server. A doubt will spoil your pleasure. ;)

[Mnyb]

The output of the digital out is bit identical wav vs flac .

That you can prove for yourself with DTS or HDCD material should one bit go astray then the decoding of dts or hdcd would break down .

[marcoc1712]

Hi all again,

curiosity will kill the cat (...me...), i've downloaded Audio diffmaker then attached my SB to a ALESIS IO2 USB Sound card (analog output), then played 1 min of "OLD LOVE" in WAVE and the same 1 Min in FLAC converted in WAVE on the server, then compared.

This is the result:

parameters: -61,6msec, -0,004dB (L), -0,005dB (R)..Corr Depth: 32,7 dB (L), 21,6 dB (R)

If you play the diff file is very audible (in same point you can undestand is Eric Clapton singing), I would like to post it or to send it to someone who can lissen to and Help me (what about Phil?), I can't post it on this forum, so please Ask!

I feel the difference between what Phil measured and what I did is too big, so or i've made some mistake or maybe something is realy wrong in my system, and this, by the way, could explain why I hear differences...

Any Help is welcome.

Thanks, Marco.

[marcoc1712]

Same test as before but "inverted" (wave-flac) comparation:

parameters: 61,6msec, 0,005dB (L), 0,006dB (R)..Corr Depth: 80,2 dB (L), 65,1 dB (R)

If someone could explain me how, i'll be glad to post fhe DIFF file (is 10 MB).

Thanks.

[marcoc1712]

Hi Gary, Thamys and Mnyb

no i did not run an "ABX" test, but my wife was playng with files on the server in the adiacent room, and i had to recognise them, so is nearly a blind test I suppose.

Anyway, looking at the measure results, i think is anymore so important the way I noticed differences, also ADM detected it, so probably is a fault in my equipment if nobody else could.

Now my question become, someone could help me analize the results and found the wrong in it?

To Thamis, for sure I'll run Wav, at least until I'll found the fault in my system and I'll be sure flac will be realy the same (in my system too). P.s. Assuming Wav is the 'correct' one...

By the way, I'll loan a SB from a friend of mine and I'll repeat the test, you never Know...

To Mnyb, not sure to could do what you suggest, anyway everything is suspended until I'll "reach the truth" on my SB.

To everybody, any suggestion on how to proceed?

Thanks again and regards.

Marco

[garym]

I can't help you with the tests, but others here probably can. And your "blind" test does answer my question. But at this point I think you've discovered something else altogether which is likely driving the differences. I would have guessed this all along, as it is very unlikely that one could be so consistent in detecting differences between FLAC and WAV files without something other than source files themselves driving the difference. Good luck with narrowing down the issue. And if you do track this down, I'd be very interested in what you find.

[marcoc1712]

Thanks Garym,

I realy hope Phil or someone else more expert than me in ADM measures could help me, I think that just liestening to the diff file will clarify why I was so obstinate in my opinion, but i've no idea in how to post a 10 MB file.

For sure I'll post next results.

Thanks, Marco

[NewBuyer]

Good luck with narrowing down the issue. And if you do track this down, I'd be very interested in what you find.

I too would be very interested in whatever you find is producing differences - good luck Marco, and please keep us posted...

[Phil Leigh]

Thanks Garym,

I realy hope Phil or someone else more expert than me in ADM measures could help me, I think that just liestening to the diff file will clarify why I was so obstinate in my opinion, but i've no idea in how to post a 10 MB file.

For sure I'll post next results.

Thanks, Marco

I have that track - will test tonight!

[marcoc1712]

Hi all,

i've just uploaded the DYF File containing the resullts of my test in rapidshare, thisi is the link to download it:

http://rapidshare.com/files/319330443/Old_love.dyf.html

Please note that max 10 DWL are allowed, so please use it only if you have DiffMaker in your system and want to look at the files.

Hope is usefull.

Bye, Marco.

[marcoc1712]

Hi All,

As I promised, i've loan a SB DUET form a friend of mine and i did the same measure.

This is the result:

parameters: 18,8msec, 0,004dB (L), 0,001dB (R)..Corr Depth: 86,1 dB (L), 85,2 dB (R)

And if you lissen to the difference file, Is quite the same as the SB+ One!

So If something is wrong in my system IS NOT the SB (unless both have the same fault, ...mmmh....)

Remember that I'm comparing a WAV FILE vs the FLAC version of the same file, converted "on the fly" in WAV by the server.

Paranoia caught me, so I tryed again to convert the flac file in wave and viceversa using FLAC front end, then compare the wav files with FC /B: no difference.

Confused...I'm waiting for the Phil results, then other steps I could plan are:

1. install SBS onto another PC from scratch, just to see if is a server side problem or not.

2. catch the DIGITAL OUT from SB, just to avoid the D/A converter, but then the one in the USB Soundcard will be involved, so i'm not sure is a good test. Someone Know how to 'save' and compare directly the bitstreams?

3. Change the network cable/device (router and switch) but this will sound realy, realy, realy strange to me, as if file transfert from a computer to another could fail, depending on the file type...

Any other test you think could be helpfull?

Thanks

Marco

[marcoc1712]

Hi All,


I've tried the same test using the SPDIF OUT of the duet and this is the result:

Parameters: -501,6msec, 0,000dB (L), 0,000dB (R)..Corr Depth: 138,0 dB (L), 139,4 dB (R)

Very similar to the one Phil detected (maybe I was testint dig out too...).

The DIFF File is INAUDIBLE (at least to me)!!!

So, in my opinion is the A/D Converter section IN SB (both Duet and SB+) that is somehow influenced from the file type in origin, don't ask me How, but for shure till the SPDIF Out, signals are allmost equal, at least to ADM and my Ears.

Good new: If You are using an external DAC, no matter using FLAC or WAV (BUT I've not tested yet what realy happen at the out connectors of the esternal DAC), if you are using the SB internal DAC you HAVE differences in the output sound.

Some tech could make more accurate mesure and try to explain the why, but now i'm sure is not a problem in the server nor in the net, but located in between the SPDIF OUT and the ANALOG OUT in SB (both the 2 model i've tested).

Could be intresting if someone else could try the same in His own SB and report.

I'm going to resume my old AR DAC 1/20 and try!

P.s.

Many thanks to Phil, you open me to ADM, that is a very powerfull tool, i'm going to use it in many other situation, EARS (and brain) are questionable, but if you get the same results by a software is easyer.

Many thanks and regards to all.

Marco.

[Phil Leigh]

Hi All,


I've tried the same test using the SPDIF OUT of the duet and this is the result:

Parameters: -501,6msec, 0,000dB (L), 0,000dB (R)..Corr Depth: 138,0 dB (L), 139,4 dB (R)

Very similar to the one Phil detected (maybe I was testint dig out too...).

The DIFF File is INAUDIBLE (at least to me)!!!

So, in my opinion is the A/D Converter section IN SB (both Duet and SB+) that is somehow influenced from the file type in origin, don't ask me How, but for shure till the SPDIF Out, signals are allmost equal, at least to ADM and my Ears.

Good new: If You are using an external DAC, no matter using FLAC or WAV (BUT I've not tested yet what realy happen at the out connectors of the esternal DAC), if you are using the SB internal DAC you HAVE differences in the output sound.

Some tech could make more accurate mesure and try to explain the why, but now i'm sure is not a problem in the server nor in the net, but located in between the SPDIF OUT and the ANALOG OUT in SB (both the 2 model i've tested).

Could be intresting if someone else could try the same in His own SB and report.

I'm going to resume my old AR DAC 1/20 and try!

P.s.

Many thanks to Phil, you open me to ADM, that is a very powerfull tool, i'm going to use it in many other situation, EARS (and brain) are questionable, but if you get the same results by a software is easyer.

Many thanks and regards to all.

Marco.

Marco - I'm about to start the tests...

[Phil Leigh]

Marco - here is my dyf fileset:
http://rapidshare.com/files/319458897/old_love_sb3_sbs_7.5_r29568.dyf.html

I just used the first 15 seconds. I can't hear any music in my diff file (unlike yours).
I have the soundcard locked to the spdif stream clock of the sb3 (but I am recording the analogue outs) so I have zero sample rate drift - and perfect cancellation. What's left is white noise from the SB3 dac output stage + white noise (very very low) from the Analogue input stage of the card.
These are 16-bit recordings so the lowest level is -96dB and I get null correlation down to -88dB so that's in the bottom 1.5 bits!

That's very close to theoretically perfect.

You have sample rate drift between your Alesis and the SB because your soundcard clock is free-running - hence your ADM results are not as good. Also, your ADC has slightly higher self noise than mine.

[marcoc1712]

Hi Phil,

Two think I could not understand in your explanation:

1 what's the matter of the clock of my USB card till we are measuring the Analog out? Means You could never measure a Turntable or any other surce with no digital out? Is not meant like this, looking at ADM documentation!

2. In wich way could noise, clock or other 'digital' fault in the USB Card could be involved in different way depending on format files were in origin, AFTER the DA conversion in SB? I suppose you mean my USB Card will measure this order of differences also if I mesure twice the same file playback. Is not that way!

By the way, I do confirm your difference file has no audible diff in it (to me).

Becouse I could not replicate your conditions, could you please try the configuration i was running tests (1 min, no digital link at all) and see what happen?

Thanks.

Marco

[Phil Leigh]

Hi Phil,

Two think I could not understand in your explanation:

1 what's the matter of the clock of my USB card till we are measuring the Analog out? Means You could never measure a Turntable or any other surce with no digital out? Is not meant like this, looking at ADM documentation!

2. In wich way could noise, clock or other 'digital' fault in the USB Card could be involved in different way depending on format files were in origin, AFTER the DA conversion in SB? I suppose you mean my USB Card will measure this order of differences also if I mesure twice the same file playback. Is not that way!

By the way, I do confirm your difference file has no audible diff in it (to me).

Becouse I could not replicate your conditions, could you please try the configuration i was running tests (1 min, no digital link at all) and see what happen?

Thanks.

Marco

Marco,
ADM works by aligning the two files exactly in time (and level) - sample by sample. If there is ANY variation in the sample timing between two recordings it will not be 100% accurate. There are two clocks - one in the SB and one in the soundcard. They have to be made the same. ADM can compensate for level differences and it does its best to compensate for clock drift but it is not perfect - especially when the clock drift is changing over time... it can only do an average correction.

If you don't lock to spdif, the SB3 and soundcard will operate at slightly different, changing (drifting) rates.

If you read the help file within ADM carefully this is all explained.

It also explains why you can't measure turntables accurately for the same reason!

If you want to prove this, make two "identical" WAV (or flac) recordings and compare them. They will be different.

If I repeat your test setup I get similar results to you - but they aren't helpful or meaningful.

Try comparing one WAV recording to another using your method and see what happens...

[marcoc1712]

Hi Phil,

I see, your explanation is now clear to me, as I supposed you mean that also 2 wave taken in different time but in the same condition will sound different and ADM will report this differences, becose difference in time (clock). I did not realise this in ADM documentation, sorry.

I've tried and those are the results:

WAV2 to WAV1: -122,3msec, -0,001dB (L), 0,000dB (R)..Corr Depth: 75,1 dB (L), 75,6 dB (R)

FLAC2 to FLAC1: -1,154sec, -0,002dB (L), 0,000dB (R)..Corr Depth: 88,2 dB (L), 85,8 dB (R)

FLAC1 to WAV1: 1,479sec, 0,004dB (L), 0,000dB (R)..Corr Depth: 83,4 dB (L), 102,6 dB (R)

All three diferrence file are audible, someone could argue about type and amplitude of differences, but not me.

Then now we Know that:

1.Until the SPDIF OUTPUT of SB there is ANY difference in FLAC or WAVE (tested).

2. At the Analog output of SB - If you don't lock SPDIF Clock - AMD detect differences, but is not meaningful, differences are also between two WAV files! (tested).

3. If you lock SPDIF Clock, differences detected by AMD are null or very little, so we could probably say they are not audible (tested).

But Phil, please be patient, what I can't figure is how you can operate in my lissening chain to trow away clock drifts, looks to me as you operate ALWAYS in a point 2 like situation. If not, could you explain?

Thanks, Marco.

[Phil Leigh]

Hi Phil,

I see, your explanation is now clear to me, as I supposed you mean that also 2 wave taken in different time but in the same condition will sound different and ADM will report this differences, becose difference in time (clock). I did not realise this in ADM documentation, sorry.

I've tried and those are the results:

WAV2 to WAV1: -122,3msec, -0,001dB (L), 0,000dB (R)..Corr Depth: 75,1 dB (L), 75,6 dB (R)

FLAC2 to FLAC1: -1,154sec, -0,002dB (L), 0,000dB (R)..Corr Depth: 88,2 dB (L), 85,8 dB (R)

FLAC1 to WAV1: 1,479sec, 0,004dB (L), 0,000dB (R)..Corr Depth: 83,4 dB (L), 102,6 dB (R)

All three diferrence file are audible, someone could argue about type and amplitude of differences, but not me.

Then now we Know that:

1.Until the SPDIF OUTPUT of SB there is ANY difference in FLAC or WAVE (tested).

2. At the Analog output of SB - If you don't lock SPDIF Clock - AMD detect differences, but is not meaningful, differences are also between two WAV files! (tested).

3. If you lock SPDIF Clock, differences detected by AMD are null or very little, so we could probably say they are not audible (tested).

But Phil, please be patient, what I can't figure is how you can operate in my lissening chain to trow away clock drifts, looks to me as you operate ALWAYS in a point 2 like situation. If not, could you explain?

Thanks, Marco.

Marco,

I think you understand it all now :-)

My soundcard has both analogue and spdif inputs and they can both be used at the same time. So I can connect the analogue AND spdif outputs of the SB to the card. I then set the card to take its clock from the spdif - but to record the sound ONLY from the analogue. This way, everything is locked perfectly together in time and ADM works perfectly.

This is the ONLY test setup that proves there is NO difference between wav and flac, because you cannot get a null / white noise difference result any other way.

And Nulls like that cannot happen by chance.

This is why I am happy to state with absolute certainty there is no difference between wav and flac playback. I sure can't hear any difference either!

Regards
Phil

[marcoc1712]

Hi Phil,

Just to resume:

We Know there is no difference in the two bit stream coming out form the SB spdif output, that's finaly clear also to me.

I'm with you stating there is THE SAME ORDER of difference between wav and flac PLAYBACK, that the one is between two different playback of the same file.

Thanks to your tests and explanation, we Know that those difference are in playback becose some 'time error' (drift), that you can correct converting back and recording, but NOT just playng the analog output via PRE, AMP and Speaker. In other words, You'll always have difference in playback! (...hard to realize!).

We(both)and anyone could lissen to those differences.

So, IF difference between A and B and those beetween A and C are almost the same, could you say B = C ?

NO, and for sure less than ...almost!

To be REALY SURE we should:

a. trow away "time errors" ALSO when you play via PRE, AMP and Speakers, but I undestand there is no way to, correct?

or

b. be sure that difference between FLAC/WAV and WAV/WAV due to drift are systemic and EXACTLY the same, Are we?

Otherways we can only BELIVE on that, we are only almost sure, and how important is "almost" in Audio is a new discussion that we could open if you like.

Back to block, but at least now we Know that "exactly the same" is a "chimera", from the listening point of view.

Very Instructive and amazing discussion, shall we continue focusing on how to get better the playback reducing "timing errors" influences?

Have a good Week end.

Marco.

[Phil Leigh]

Marco - let's summarise where we are:
1) wav vs flac via spdif = identical
2) wav vs flac via analogue = identical

So let's move on... to your bigger question. In normal playback, what are the effects of the SB clock drift and the design of the DAC and final analogue stage?

To answer this, we need to do a different test. For this we need to compare in ADM an original WAV rip from a CD with a recording of playback from the analogue outputs of the SB. To eliminate errors in the recording process we again need to lock the ADC to the spdif so that both ADC and SB are running from the same (SB) clock. However this will not eliminate any clock drift between the original recording and the SB clock.

To be clear, this is as close as we can get to comparing exactly what was written to the CD vs what is coming out of the SB DAC and will tell us how accurate the DAC is in retrieving the original music.

Any errors will caused by one of two things:
1) frequency/phase response errors in the analogue output stage of the DAC
2) clock drift (sample rate) errors between the clock used to create the CD
and the clock in the SB

plus of course any noise and frequency response anomolies in the ADC card itself

This is a very hard test - it is brutal.

More later...

[Phil Leigh]

If you do this test it will probably produce 19-25 dB Nulls - not great.
However, this is not the whole story. Open the difference file in Audacity (or similar) and look at the frequency spectrum plots. You will find that actually the difference is more like -50dB, but with large differences at the low end of the spectrum (<100 Hz) which is skewing the result.
Also you will see that ADM cannot compensate for the SB clock drift and you can still hear (bits of) the music.

What does this mean in practice?

To improve playback quality and getter it closer to the original CD, we must:

1) use an external DAC with a better clock and more accurate (frequency/phase response/noise) analogue stage - ideally use a linked clock so that the DAC can drive the SB - this requires mods to DAC and SB.
or
2) put a much better (more stable/accurate/low noise PSU) clock in the SB and mod the analogue stage to improve its transient and self-noise performance - presumably the SB+ already does this?
or
3) upgrade to a Touch or TP which have better clocks/outputs stages and which measure better in this test (well, the Touch certainly does, others are looking at the TP as I don't have one).

IMO Most of the "problem" lies with the analogue stage of the SB3. Those electrolytic caps can't be helping here and the driver IC can surely be improved?. Not sure what an SB+ looks like in this respect.

[marcoc1712]

Hi Phil,


Marco - let's summarise where we are:
1) wav vs flac via spdif = identical
2) wav vs flac via analogue = identical


i'm a bit confused now, your point 2 should be:

2) wav vs flac via analogue = identical, unless clock drift (same as 2 different playback of the same wav file).

Is it correct?

What i'm not sure to understand is: If you think a block skema like this one:

[1.ANALOG ORIGINAL] -> [2.AD CONVERSION] -> [3.CD PRODUCTION] -> [4.CD RIPPING} -> [5. STORAGE ] -> [6.SBS + NET + SB DIG OUT] -> [7.DA CONVERSION] -> [8.PLAYBACK] -> YOU.

The drift problem is caused by the different clocks in step 2 and step 6, correct? So is not practicaly possible to eliminate, i'm wrong?

Steps in between we assume are 'error free' or better errors are eliminated in the digital domain (is quite a hard simplification, but please forget it for a moment).

In our test we replaced step 8 with a new step 1 to step 6 short cicle, with Your link you could eliminate the drift IN this cicle, so we Know drift is the major (if not the only) cause of errors, just becose two istance of this cicle provvide NULL differences, we can assume the remaning kind of errors (if any) are at least systemic.

I'm wrong with this?

Now, if we compare the WAV file in storage (step 5) and the wav file you recorded, the difference we are going to detect (if any) are due only to the DA conversion (step 7) and the reverse AD conversion we introduced, plus the Analog IN and OUT stage involved and cables, cleaned by Clock Drift, rigth?

As stated before, those difference appear to be systemic.

For sure we could point those differences (or distortion) using better quality gear, design or else as people do from the realy beginning, but let's say they will always be in place in some measure, SB+ introduce some changes over standard SB3, they claim to make better, other do the same in other ways, maybe TP or Touch will be even better.

What I could not figure is how you could point to difference that are 'randomic' as Drift seems to be?

If - just for drift - i'm getting differences between 2 playback of the same file (and that means, by the way, is the DA clock that is changing, the one in the RECORDER AD is fixed once for ever!) the only think you could do is Make better the DA Clock, but this will not eliminate the problem, since also if error free, you never change the original in AD, but at least we will measure a SYSTEMIC error!

Are Touch o TP getting better in this matter? How?

Thanks a lot.

Marco

[Phil Leigh]

Marco - not quite. We can never know what the clock variability was in step 2, since all we have is the CD. We don't have the analogue original. In some cases, there is NO analogue original (think of DDD or ADD recordings).

Since we have no way of knowing what it was, we just have to live with it.

When the CD is ripped we get the samples exactly from the CD at an IMPLIED definite, fixed rate (44.1kHz) with no drift - because there is no clock, just bytes of data - like any computer file.

As you have seen from your tests of WAV/FLAC files via spdif, with a linked clock there is NO error - none!.

When we playback the rip/wav, the DAC clock drifts slightly and the results create (part of) the difference between the original WAV rip and the analogue recording of the DAC. This is "systemic" in that we can't eliminate it completely - or even measure it. All we can do is assume that the clock in step 2 (which we cannot know anything about) was "perfect".., and that any difference we record is down to the quality of the DAC clock.

So, we can and try and use a more accurate/stable/less jittery DAC clock. and hope that gets us closer to the original wav file.

The other part of the error in the DAC comes from noise and frequency response errors in the DAC analogue stage, plus artifacts from the DAC and filtering process itself... ringing, pre-echo, aliasing etc. Different DAC's (NOS, Oversampling, Upsampling, Ring, etc) handle these in different ways and personal choice plays a part here too.

This is where the science stops and the ears start...
Regards
Phil

[marcoc1712]

Phil,

you summarize better than me, but is exactly what i think:

You could never Know how was the original, so you use a convenction (44.100 Hz) and try to be as close as you can to it.

Maybe is not the perfect word in English, I apologize for this, but whit Systemic I mean a factor that reproduce exactly the same each time in same enviromental conditions, not simply "connate".

Then Drift is not Systemic if 2 playback of the same file are different in same system boundary, but connate unless you lock the two clock.

Other factor are systemic, just becose you get null difference over 2 playback 'cleaned' by Drift errors.

If it was not like this, we had clear differences between FLAC and WAV Playback, but you showed to me.

I'm with you: what we could only do is try and use a more accurate/stable/less jittery DAC clock, and hope that gets us closer to the original (as is for all the other Audio gear, anyway).

Science - today - stops here, as you stated.

...But, as for all the other gear, is not possible in your opinion that "external" factor as Power supply quality, RFI, EMI, Vibration,... could affect the job of the existing Clock ?

Then, back to the original question, could You exclude for sure that the operation involved in SB to play a Flac file (not the file itself) as for instance the FF/REW, could affect somehow the job of the clock, then produce different drift respect the Theorethical 44.100Hz?

Is quite unlikely, I still think Placebo effect is more likely (95%) but I think you could agree with me that we could not say is impossible!

Keep on listening!

Regards, Marco.

[Phil Leigh]

Phil,

you summarize better than me, but is exactly what i think:

You could never Know how was the original, so you use a convenction (44.100 Hz) and try to be as close as you can to it.

Maybe is not the perfect word in English, I apologize for this, but whit Systemic I mean a factor that reproduce exactly the same each time in same enviromental conditions, not simply "connate".

Then Drift is not Systemic if 2 playback of the same file are different in same system boundary, but connate unless you lock the two clock.

Other factor are systemic, just becose you get null difference over 2 playback 'cleaned' by Drift errors.

If it was not like this, we had clear differences between FLAC and WAV Playback, but you showed to me.

I'm with you: what we could only do is try and use a more accurate/stable/less jittery DAC clock, and hope that gets us closer to the original (as is for all the other Audio gear, anyway).

Science - today - stops here, as you stated.

...But, as for all the other gear, is not possible in your opinion that "external" factor as Power supply quality, RFI, EMI, Vibration,... could affect the job of the existing Clock ?

Then, back to the original question, could You exclude for sure that the operation involved in SB to play a Flac file (not the file itself) as for instance the FF/REW, could affect somehow the job of the clock, then produce different drift respect the Theorethical 44.100Hz?

Is quite unlikely, I still think Placebo effect is more likely (95%) but I think you could agree with me that we could not say is impossible!

Keep on listening!

Regards, Marco.

Marco - Now I understand what you mean by systemic...

So, yes unless you lock the clocks when recording the results will not be "systemic". Also, each time you play something back it will be very slightly different...

...and yes, it is possible for external factors to affect the clock. However, changing the plug-in power supply does not do this (I've tested this to death). I haven't tested vibration.

The FF/REW issue is nothing to do with this - that is just a functional coding matter, it has no impact on the sound.

As I said, there is no measurable evidence to support the idea that flac vs wav playback are ANY different. To me they absolutely sound identical too.

If you can afford it, I would look into the Touch when it is available.
It sounds (and measures) better than the SB3. It may outperform the SB+.

[marcoc1712]

Phil,

for sure I'm going to try the Touch.

About FF/REW it was only an example, just becouse is a evident one, i'm not qualifyed for such a tech question, forget about it.

The point is there is no reason (and is not to you, who was realy Kind, honest and patient with me in the discussion) to mock someone who say he could eard those kind of difference, even if is likely a placebo effect, we could not honestly say is impossible, but only that we have no instrumental evidence and - maybe - we could not eard it in our system.

Is completely different!

By the way, you could not realy measure any difference using a linear PSU instead of the original Switched One? And you could not eard any difference in sound too?

I moved to SB+ after first changin PSU to a very cheap commercial one and was good, then I bougth a Paul Hynes One and was better, SB+ Is very good, and PSU as his part I suppose. (...always to my brain...)

To me SB with original PSU was even not comparable to my CD Player and DAC, Now I almost don't use them anymore (still using tourntable).

My brain should be realy bad!!!

Regards, Marco.

[Pete Fowler]

If you do this test it will probably produce 19-25 dB Nulls - not great.
However, this is not the whole story. Open the difference file in Audacity (or similar) and look at the frequency spectrum plots. You will find that actually the difference is more like -50dB, but with large differences at the low end of the spectrum (<100 Hz) which is skewing the result.
Also you will see that ADM cannot compensate for the SB clock drift and you can still hear (bits of) the music.

What does this mean in practice?

To improve playback quality and getter it closer to the original CD, we must:

1) use an external DAC with a better clock and more accurate (frequency/phase response/noise) analogue stage - ideally use a linked clock so that the DAC can drive the SB - this requires mods to DAC and SB.
or
2) put a much better (more stable/accurate/low noise PSU) clock in the SB and mod the analogue stage to improve its transient and self-noise performance - presumably the SB+ already does this?
or
3) upgrade to a Touch or TP which have better clocks/outputs stages and which measure better in this test (well, the Touch certainly does, others are looking at the TP as I don't have one).

IMO Most of the "problem" lies with the analogue stage of the SB3. Those electrolytic caps can't be helping here and the driver IC can surely be improved?. Not sure what an SB+ looks like in this respect.

Hi Phil,

Your findings re the clock drift below 100Hz confirm what Pat at AR-T has been pounding into me for months. A quiet clock is critical to getting correct playback. The trick is what he means by "quiet". What he means is low noise below 100Hz. Actually his target is below 1Hz. I believe the correct term is reduced flicker noise (1/f noise)?

Even if one has a high quality XO it will be noisy below 100Hz unless the PS is designed specifically to reduce 1/f noise. Interesting how your results tie into what I'm finding whist ditzing with the Duet receiver.

Injecting a clean clock made a huge improvement in the SQ - far more than all the cleanup work I did on the DAC analog outputs. My guess is a low 1/f noise PS for the DAC chip would help below 100Hz, too.

Again, apologies for jumping in here...

Pete

[JohnSwenson]

I finally got around to doing some more tests (incredibly busy these days). I still can't get decent repeatable results ADM so I tried a different approach.

I have a very good HP spectrum analyzer which is very good at looking at clock spectra. Its quite sensitive at showing clock jitter as sidebands around the main clock peak.

So I took the Touch apart and hooked the analyzer up to the clock going into the DAC chip. I was stunned, this is the best looking clock spectrum I've seen in a commercial product. Almost a perfectly flat line right at the measurement limit. Not quite perfect, there are a few little squiggles, but they just barely peak above the floor.

So I tried sending flac and PCM to the Touch, no discernible difference. There might be but I can't see it with this test equipment.

Then I remembered that I was hearing the difference over headphones, so I tried plugging the phones in. Wowa! That made a big difference. Now there were significant sidebands on the clock spectrum. Interestingly enough mostly at multiples of 120Hz. Which is interesting because the PS is a switcher! It certainly looks like the current drawn by the headphone amp actually driving phones is somehow causing some increase in the clock jitter. I did try flac and PCM with the phones plugged in and again I could not see any difference.

I also tried connecting to the analog outs and got the same results as no connections: almost perfectly flat line.

So the spectrum analyzer could see no difference in jitter between flac or PCM. That doesn't mean its not there, it still could be lower than what this instrument can detect.

BTW the theoretical limit of this instrument for measuring jitter comes out to somewhere around 10-20ps, so if its right at the edge, the Touch is phenomenal.

Jitter was one of the possible mechanisms by which sound could be changed by different streaming formats. Another is power supply noise directly into the DAC supply or other analog devices, since the Touch has no devices between the DAC and the analog outputs, that pretty much limits it. But the headphone jack does have an amp that does seem to affect things internally so next is to look at the PS rails at the DAC chip and especially the headphone amp and see what can be seen.

BTW I did do some simple blind listening tests (simple to do because someone else can switch the stream format remotely and there is no indication on the Touch's screen which is in effect). I had a very good rate at hearing the difference in these tests. My wife didn't want to sit still long enough to do the tests so I don't have someone elses ears as well. I know it was not scientific at all, etc etc. But for me at least its lending a little bit of evidence that I'm not completely imagining this.

John S.

[marcoc1712]

Hi John,

About the ADM differences, the tryals with Phil explained to me that they are caused by the cloks drifting between the DA converter of SB and the AD converter of USB soundcard, He could 'lock' them in his system and reported that this eiminated any differences.

The point is in 'real life' playback you could not lock the clock!

Anyway, could you please report wich differences in sound you heard (maybe you already did, but i can't find...sorry).

I resume mime, are yours any silimar?

a) Stereo Image:

Playng the Wave file, the scene is more focused and deeper, but smaller, means that if you play i.e. "Old Love" from Eric Clapton Umplugged album, mr. Clapton seems to be 10 cm shorter, the bass is behind and not on top of the voice, the piano asolo is not so far in the left.

b)Sound 'color':

Playng Flac, voices, arcs and cimbals are a little bit 'harder' and cold, some 'electric' take place, in wave they are smoorher, some more air around and more 'natural'. No big differences in bass, maybe a bit more control in wave.

Intresting to know.

thanks.

Marco.

[Louishlomador]

Hi Guys, As the original owner of this post, I have read through some of the technical measurements Phil and others have come up with. Would we all say its fair to say that the reason we are having these discussions is because there may be too many factors to consider when doing these tests? such as type of sound card being used for the measurements, type interconnects, as they all have different characteristics, Whether diffmaker has been installed properly on the respective PCs. The list could be very lengthy here. I have taken some time to do some research on codecs, file formats. It seems some codecs do a better job than others. Everybody agrees without a doubt that the flac files are identical to wave, in terms of what information each file holds. There is absolutely, without a doubt that the CD converted, whether in FLAC or WAV is the same as the original source. As we all agree with this, lets move forward, what else could be the reason why some can tell the differences, others cannot? My question to everyone is what version of codec software was used in the firmware, when using squeezecenter 7.2. I'll tell you why I'm asking these questions. I recently converted a few of my CD's to AIFF which is the wav file version of apple. Strangely AIFF will play in native mode for 7.2. Unfortunately it doesn't work for 7.4, 7.4.1, or even 7.5. It only plays for 7.4, 7.4.1 or 7.5 when you have "flac/SOX" turned on. It doesn't play natively. Bandwidth is not an issue for some of us, hence we want the full spectrum of the file streamed naturally, not converted to FLAC by the decoder. Why does 7.2 work perfectly and all other versions I have tested doesn't? I will be very happy if one of the slim devices team can answer these questions. You only get a loud audible sound, similar sound to when searching for TV channels on an old TV, say in the 1980's. I think there is a serious flaw in the firmware or software that i am more than happy to input my findings and get this fixed. The only reason why i decided to convert some of my music CDs to AIFF was because the new software versions by default converted wav files to flac. Me thinking by ripping my CDs in AIFF I could get away with streaming the file naturally as its supposed to didn't work for the new versions. It only works for 7.2. How can an older version of software do a better job than the new versions? Can someone also test and come up with the results. I'm confident that this has been missed in the new software. If a wave file is designed to be streamed as wav then i believe it should, same for flac or other formats, rather than using some codec to convert at the background to allow the file to play. In my view i think the software engineers will have to come up with a better solution to this flac, wave, or AIFF issue that will never go away. Not everyone has bandwidth issues, hence i believe strongly the software should be flexible enough to allow you to setup how you want your files streamed, knowing the consequence could be bandwidth. Please do the tests , thus rip a CD in AIFF format, then in the file types section in Squeezserver set the AIFF to play natively, disable "flac/sox". It just wont play the music, It only plays natively in 7.2. I hope this posting will help develop a better software, then there will be no diffmaker tests etc.. if every file is streamed as its supposed to using the right codecs Thanks guys

[garym]

See this thread (final message posted). You should still be able to stream WAV > WAV with the right settings.

http://forums.slimdevices.com/showpost.php?p=393216&postcount=16

[Stratmangler]

Hi Guys, As the original owner of this post, I have read through some of the technical measurements Phil and others have come up with. Would we all say its fair to say that the reason we are having these discussions is because there may be too many factors to consider when doing these tests? such as type of sound card being used for the measurements, type interconnects, as they all have different characteristics, Whether diffmaker has been installed properly on the respective PCs. The list could be very lengthy here. I have taken some time to do some research on codecs, file formats. It seems some codecs do a better job than others. Everybody agrees without a doubt that the flac files are identical to wave, in terms of what information each file holds. There is absolutely, without a doubt that the CD converted, whether in FLAC or WAV is the same as the original source. As we all agree with this, lets move forward, what else could be the reason why some can tell the differences, others cannot? My question to everyone is what version of codec software was used in the firmware, when using squeezecenter 7.2. I'll tell you why I'm asking these questions. I recently converted a few of my CD's to AIFF which is the wav file version of apple. Strangely AIFF will play in native mode for 7.2. Unfortunately it doesn't work for 7.4, 7.4.1, or even 7.5. It only plays for 7.4, 7.4.1 or 7.5 when you have "flac/SOX" turned on. It doesn't play natively. Bandwidth is not an issue for some of us, hence we want the full spectrum of the file streamed naturally, not converted to FLAC by the decoder. Why does 7.2 work perfectly and all other versions I have tested doesn't? I will be very happy if one of the slim devices team can answer these questions. You only get a loud audible sound, similar sound to when searching for TV channels on an old TV, say in the 1980's. I think there is a serious flaw in the firmware or software that i am more than happy to input my findings and get this fixed. The only reason why i decided to convert some of my music CDs to AIFF was because the new software versions by default converted wav files to flac. Me thinking by ripping my CDs in AIFF I could get away with streaming the file naturally as its supposed to didn't work for the new versions. It only works for 7.2. How can an older version of software do a better job than the new versions? Can someone also test and come up with the results. I'm confident that this has been missed in the new software. If a wave file is designed to be streamed as wav then i believe it should, same for flac or other formats, rather than using some codec to convert at the background to allow the file to play. In my view i think the software engineers will have to come up with a better solution to this flac, wave, or AIFF issue that will never go away. Not everyone has bandwidth issues, hence i believe strongly the software should be flexible enough to allow you to setup how you want your files streamed, knowing the consequence could be bandwidth. Please do the tests , thus rip a CD in AIFF format, then in the file types section in Squeezserver set the AIFF to play natively, disable "flac/sox". It just wont play the music, It only plays natively in 7.2. I hope this posting will help develop a better software, then there will be no diffmaker tests etc.. if every file is streamed as its supposed to using the right codecs Thanks guys

Louis

Would you please sort this out into paragraphs ?

Chris:)

[Louishlomador]

Hi Guys, As the original owner of this post, I have read through some of the technical measurements Phil and others have come up with. Would we all say its fair to say that the reason we are having these discussions is because there may be too many factors to consider when doing these tests? such as type of sound card being used for the measurements, type interconnects, as they all have different characteristics, Whether diffmaker has been installed properly on the respective PCs. The list could be very lengthy here.


I have taken some time to do some research on codecs, file formats. It seems some codecs do a better job than others. Everybody agrees without a doubt that the flac files are identical to wave, in terms of what information each file holds. There is absolutely, without a doubt that the CD converted, whether in FLAC or WAV is the same as the original source. As we all agree with this, lets move forward, what else could be the reason why some can tell the differences, others cannot?

My question to everyone is what version of codec software was used in the firmware, when using squeezecenter 7.2. I'll tell you why I'm asking these questions. I recently converted a few of my CD's to AIFF which is the wav file version of apple. Strangely AIFF will play in native mode for 7.2. Unfortunately it doesn't work for 7.4, 7.4.1, or even 7.5. It only plays for 7.4, 7.4.1 or 7.5 when you have "flac/SOX" turned on. It doesn't play natively. Bandwidth is not an issue for some of us, hence we want the full spectrum of the file streamed naturally, not converted to FLAC by the decoder. Why does 7.2 work perfectly and all other versions I have tested doesn't?


I will be very happy if one of the slim devices team can answer these questions. You only get a loud audible sound, similar sound to when searching for TV channels on an old TV, say in the 1980's. I think there is a serious flaw in the firmware or software that i am more than happy to input my findings and get this fixed. The only reason why i decided to convert some of my music CDs to AIFF was because the new software versions by default converted wav files to flac. Me thinking by ripping my CDs in AIFF I could get away with streaming the file naturally as its supposed to didn't work for the new versions. It only works for 7.2. How can an older version of software do a better job than the new versions? Can someone also test and come up with the results. I'm confident that this has been missed in the new software.

If a wave file is designed to be streamed as wav then i believe it should, same for flac or other formats, rather than using some codec to convert at the background to allow the file to play. In my view i think the software engineers will have to come up with a better solution to this flac, wave, or AIFF issue that will never go away. Not everyone has bandwidth issues, hence i believe strongly the software should be flexible enough to allow you to setup how you want your files streamed, knowing the consequence could be bandwidth.

Please do the tests , thus rip a CD in AIFF format, then in the file types section in Squeezserver set the AIFF to play natively, disable "flac/sox". It just wont play the music, It only plays natively in 7.2. I hope this posting will help develop a better software, then there will be no diffmaker tests etc.. if every file is streamed as its supposed to using the right codecs Thanks guys

NB: I am aware that you can stream wav in its native format for all versions, however i'm afraid to say 7.2 wav streaming sounds better than all the other versions natively and this is why my question is what codec is being used for 7.2? is streaming done the same way with the other versions? what has changed between the different versions

[Phil Leigh]

Hi Guys, As the original owner of this post, I have read through some of the technical measurements Phil and others have come up with. Would we all say its fair to say that the reason we are having these discussions is because there may be too many factors to consider when doing these tests? such as type of sound card being used for the measurements, type interconnects, as they all have different characteristics, Whether diffmaker has been installed properly on the respective PCs. The list could be very lengthy here.


I have taken some time to do some research on codecs, file formats. It seems some codecs do a better job than others. Everybody agrees without a doubt that the flac files are identical to wave, in terms of what information each file holds. There is absolutely, without a doubt that the CD converted, whether in FLAC or WAV is the same as the original source. As we all agree with this, lets move forward, what else could be the reason why some can tell the differences, others cannot?

My question to everyone is what version of codec software was used in the firmware, when using squeezecenter 7.2. I'll tell you why I'm asking these questions. I recently converted a few of my CD's to AIFF which is the wav file version of apple. Strangely AIFF will play in native mode for 7.2. Unfortunately it doesn't work for 7.4, 7.4.1, or even 7.5. It only plays for 7.4, 7.4.1 or 7.5 when you have "flac/SOX" turned on. It doesn't play natively. Bandwidth is not an issue for some of us, hence we want the full spectrum of the file streamed naturally, not converted to FLAC by the decoder. Why does 7.2 work perfectly and all other versions I have tested doesn't?



Louis,

The reason we are having these discussions is that various people have asserted that there is an audible difference in wav vs flac playback.
As far as I am concerned this is untrue for SPDIF playback. There is NO difference - none.

In ADM you simply cannot get an accidental null >100dB.

With analogue playback it is harder to be absolutely sure because of the clock issue, however my tests and listening lead me to conclude that the same is true.

If I am following your thinking correctly, you are now looking at the codec that does the translation of flac or wav into PCM before tcp/ip transmission to the SB?

Clearly these codecs works perfectly otherwise the diff tests would fail... and DTS and HDCD replay would fail too.

wav-pcm and flac-pcm are both LOSSLESS transformations. There is no ambiguity or doubt here.

The unfortunate fact that AIFF will not play natively post 7.2 has no bearing on any of this.


There are only 2 factors in play, the bits and the clocks. The bits are always the same - can we agree on this?.

The clocks only come into play at the spdif transmitter/receiver and/or DAC. Codecs don't know about clocks.

[cliveb]

There are only 2 factors in play, the bits and the clocks. The bits are always the same - can we agree on this?.
There are two more factors I can think of.

One is that receiving and decoding WAV versus FLAC inside the Squeezebox will place differing loads on things like the CPU, network adaptor, etc, and this might conceivably alter things like noise on the power rails, RFI flying around inside the device, etc. There have been other threads in the past that speculated on this as a possible source of influence on the performance of analogue circuitry (eg. the Squeezebox's DAC).

The other factor at play (and my money is on this one) is the listener. There is an overwhelming body of scientific research which proves that expectation affects perception. Anyone who claims to have heard a difference between WAV and FLAC has to back it up with a properly conducted blind comparison.

[Phil Leigh]

There are two more factors I can think of.

One is that receiving and decoding WAV versus FLAC inside the Squeezebox will place differing loads on things like the CPU, network adaptor, etc, and this might conceivably alter things like noise on the power rails, RFI flying around inside the device, etc. There have been other threads in the past that speculated on this as a possible source of influence on the performance of analogue circuitry (eg. the Squeezebox's DAC).

The other factor at play (and my money is on this one) is the listener. There is an overwhelming body of scientific research which proves that expectation affects perception. Anyone who claims to have heard a difference between WAV and FLAC has to back it up with a properly conducted blind comparison.

Clive - I was quite prepared to believe #1 until I tested it with ADM
I completely believe #2 !

[JohnSwenson]

There are two more factors I can think of.
The other factor at play (and my money is on this one) is the listener. There is an overwhelming body of scientific research which proves that expectation affects perception. Anyone who claims to have heard a difference between WAV and FLAC has to back it up with a properly conducted blind comparison.


As I've stated before I can hear the difference over headphones on the Touch. I've done simple blind tests and can tell the difference. I'd be willing to participate in an "official" blind test of this, so do you have a testing protocol that you would consider "proper"?

I don't want to spend time on this and then have a whole bunch of people say "it wasn't proper", so what IS proper?

John S.

[ralphpnj]

As I've stated before I can hear the difference over headphones on the Touch. I've done simple blind tests and can tell the difference. I'd be willing to participate in an "official" blind test of this, so do you have a testing protocol that you would consider "proper"?

I don't want to spend time on this and then have a whole bunch of people say "it wasn't proper", so what IS proper?

John S.

Without fanning the flames of what may well turn into yet another heated thread of DBT versus subjective testing, what is more likely to be said by the true believers of all things DBT at the conclusion of such a "properly" conducted test is that your ability to reliably hear the difference between wav and flac files (as verified by the results of the DBT) is statistically insignificant and therefore doesn't prove anything, regardless of the fact that you may have gotten things right 100% of the time.

In other words, if a statistically significant percentage of the people say that the emperor has clothes then the emperor has clothes, his sunburned behind not withstanding damn it.

[Themis]

As I've stated before I can hear the difference over headphones on the Touch. I've done simple blind tests and can tell the difference. I'd be willing to participate in an "official" blind test of this, so do you have a testing protocol that you would consider "proper"?

I don't want to spend time on this and then have a whole bunch of people say "it wasn't proper", so what IS proper?

John S.
As far as I understand, the only "proper protocol" is the statistical hypothesis testing framework (Bayesian). But it is not used in audio, we use null hypothesis framework, instead (which produces very poor results).

I guess we are bound to believe/not people we trust on this. Or our own ears.

[marcoc1712]

Hi All,

#1 Phil, you could not say that after the ADM measuring you KNOW there is no difference betweeen the 2 playback from Analogic output, you teached to me those kind of difference are also in 2 playback of the same file in the same format, remember? Maybe You Belive they are NOT depending on the file format.

#2, You know I think is likely the first probability, but since I'm not the only one AND you could not for sure exclude any difference, we could only 'belive' is unlikely there is any auidible difference but is a 'placebo' effect.

So, I'm with John, let's we Know the "proper" protocol (I assume my Wife is not...shhh don't tell her...) and ask as many people is possible to run it!

But I'm with Ralph too, people who could not Heard the difference between MP3 and FLAC (or LP and CD) will probably detect no differences And more ABX or DBT is not the only (nor the better) way to evalueate SQ, so the reliability of results will probably in dubt too, but is still intresting to me.

What is much more intrestingto me is to know if people could hear differences, and wich kind of.

I've posted my impressions, John, Ralph and others, please let me Know if yours are similar, this will NOT prove ANYTHING to nobody, but will help to understand.

P.S.

Why S.B. when playng FLAC streamed as WAV by the server report BITRATE: XXX Kbps VBR Converted to 1411,2 Kbps ABR? Should not be 1411 Kbps CBR as WAV/PCM is? Is only in my system?

Regards, Marco

[marcoc1712]

I guess we are bound to believe/not people we trust on this. Or our own ears.

Sorry, is my fault (I'm Italian) but I can't understand the real meaning of your statement (also google transaltor could not help), would you please esplain it in other words to me?

Thanks, Marco

[Themis]

Sorry, is my fault (I'm Italian) but I can't understand the real meaning of your statement (also google transaltor could not help), would you please esplain it in other words to me?

Thanks, Marco
All we can do (except measuring) is to believe (or not) what certain people (whose opinion are worthy for us - whom we trust) may say about eventual differences they may hear. Then, of course, try to listen for ourselves.

I hope it's clearer, Marco, otherwise, I can try once more : you know English is not my mother-tongue either. :)

[marcoc1712]

Thanks Themis,

now it's clear.

Were are you from? My english is "maccheronico" (means like a kind of spaghetti), i'm realy suprised that you could even understand it!

Sorry about that.

[Themis]

Were are you from? My english is "maccheronico" (means like a kind of spaghetti), i'm realy suprised that you could even understand it!

Sorry about that.No worry, Marco. My English is not that much better than yours... I simply practice more.
I'm Greek, living in France and English is my forth language.
But I insisted that my son studies Italian: it is one of the most important languages necessary to understand modern culture, along with English.
Unfortunately, I don't have the time to study Italian myself. :(

[marcoc1712]

Great place Greece,

I'd like to study (ancient) Greek and you Know we say "Una faza una raza", but unfortunatley is not to me, i'm from the nothern Italy, the Keltic one (fog and snow, too much snow in this days).

καληνύχτα, Marco.

[cliveb]

As I've stated before I can hear the difference over headphones on the Touch. I've done simple blind tests and can tell the difference. I'd be willing to participate in an "official" blind test of this, so do you have a testing protocol that you would consider "proper"?

I don't want to spend time on this and then have a whole bunch of people say "it wasn't proper", so what IS proper?
Proper blind tests require that neither the listener nor the tester knows which is being played, and that levels are perfectly matched.

In the case of FLAC v. WAV, level matching is a given, so the only thing that remains is to ensure nobody involved knows what is being listened to. If we can arrange for a computer to be the tester it makes the logistics much simpler:

1. Select a file that exhibits the difference you hear.
2. Make two copies: one WAV, the other FLAC.
3. Listen to them both, as often as you like, in order to acclimatise yourself to their differences.
4. Get SqueezeCenter to build a random playlist from the two files.
5. Listen to the playlist and note down what you think each one is. Make sure the Squeezebox's display is set such that it does not reveal the file type. To be statistically meaningful you'll need to audition about 20 instances.
6. Now compare your results with the actual playlist.

I've never bothered to conduct such a test myself, because I don't believe there will be an audible difference and therefore my own expectation will almost certainly force me into not hearing one (even if there is). But you are in the other camp - you do hear a difference, and a blind test enables you to gather the evidence to demonstrate whether it is down to your expectations.

[Themis]

Proper blind tests require that neither the listener nor the tester knows which is being played, and that levels are perfectly matched.

In the case of FLAC v. WAV, level matching is a given, so the only thing that remains is to ensure nobody involved knows what is being listened to. If we can arrange for a computer to be the tester it makes the logistics much simpler:

1. Select a file that exhibits the difference you hear.
2. Make two copies: one WAV, the other FLAC.
3. Listen to them both, as often as you like, in order to acclimatise yourself to their differences.
4. Get SqueezeCenter to build a random playlist from the two files.
5. Listen to the playlist and note down what you think each one is. Make sure the Squeezebox's display is set such that it does not reveal the file type. To be statistically meaningful you'll need to audition about 20 instances.
6. Now compare your results with the actual playlist.

This test supposes that the listener can easily qualitatively classify the differences and attach each of such classification to a particular stream.
If it fails (and it will most certainly will), it will still not prove that there are no audible differences, sorry. ;)

Try doing this test between two different AAC compression levels, you will see what I mean.

[marcoc1712]

P
4. Get SqueezeCenter to build a random playlist from the two files.
6. Now compare your results with the actual playlist.


Please, could you Help me in build this kind of playlist (I'm not used to playlist) and how to ceck the order it was played?

thanks.

Marco

[marcoc1712]

HI,

Sound to me we all are missing the point:

As Phil proved to me, DIFFERENCE ARE AUDIBLE (and you could also measure it) even between two playback of the same file, not depending by the file or streaming format! Is hard to realize, but is true.

If we agree on this, we must accept that between a playback of the FLAC and the WAV version of the same file ARE differences, you could not avoid it, and are audible too!

At least since you are not beliving that IF A <> A1 AND A1 <> B, THEN A = B ...mmmh...

At this point, what we are discussing is "quality" of the differences, in other words if:

a) differences between the playback of FLAC and WAV version of the same file are somehow 'more affecting' the perceived quality than the one between two playback of the same version

b) this kind of "differences between differences" are "systemic" (means they always produce the same perceived effect on SQ, so you could recognise it every time you play the same file).

BE CAREFUL: A does not implies B, so if B is false this not prove A is false too!

This involve:

1. difference itself
2. ability of the equipment (and room) to reproduce it.
3. capability of the listener to perceive it.

Maybe someone could evaluate differences in itself (i.e. analyzing the ADM results)but not me, until this, we could only use an empiric approach, with a HUGE error margin!

We are going to prove nothing to anyone, but maybe having some clearer and shared idea about.

Let's we try the "proper" DBT and see what happen!

Marco.

[garym]

HI,
As Phil proved to me, DIFFERENCE ARE AUDIBLE (and you could also measure it) even between two playback of the same file, not depending by the file or streaming format! Is hard to realize, but is true.
Marco.

In reading this thread, it doesn't seem to me that Phil has said (or proved) that the differences are AUDIBLE. Phil, your comments?

p.s. I don't have these skills, but it would be nice if someone could create a plugin that worked similar to the ABX component in foobar2000 for doing random, volume adjusted, computer generated blind tests across two files along with statistical analysis of results.

[Phil Leigh]

In reading this thread, it doesn't seem to me that Phil has said (or proved) that the differences are AUDIBLE. Phil, your comments?

p.s. I don't have these skills, but it would be nice if someone could create a plugin that worked similar to the ABX component in foobar2000 for doing random, volume adjusted, computer generated blind tests across two files along with statistical analysis of results.

Gary - I definitely did not say that the playback and recording of the same file twice (with non-locked clocks) would give an audible difference. It does give a measurable difference which is predicted because of clock drift of a few parts per million. The same would be true of a record player or tape deck (even on state of the art machines, wow & flutter is orders of magnitude higher than the clock drifts we are talking about here).

In fact I cannot think of any replay mechanism that is free of such effects!

However, digital replay will get closer than any of the others and is improved by better clocks in the DAC and by locking the transport clock to the DAC.

[marcoc1712]

...

If you want to prove this, make two "identical" WAV (or flac) recordings and compare them. They will be different.

...

This was very explanatory to me, and after this we agree:

1. Until SPFID output they ARE the same (in Bit).
2. Differences are likely caused by drift.
3. In 'normal life' playback you could not lock the clocks (one was in the RECORDING AD converter of the CD)but only assume 44.100 Hz is the 'correct' frequency and try to be as close as you can.

Unless you could not eliminate the drift, you will always have differences, but maybe you could make them better (read having minor effect on the SQ you perceive).

Marco

[garym]

Gary - I definitely did not say that the playback and recording of the same file twice (with non-locked clocks) would give an audible difference. It does give a measurable difference which is predicted because of clock drift of a few parts per million. The same would be true of a record player or tape deck (even on state of the art machines, wow & flutter is orders of magnitude higher than the clock drifts we are talking about here).

In fact I cannot think of any replay mechanism that is free of such effects!

However, digital replay will get closer than any of the others and is improved by better clocks in the DAC and by locking the transport clock to the DAC.

Thanks Phil. Good explanation and I agree that clock drift, etc. can (and does) result in measurable difference. It was the unequivocal statement of AUDIBLE differences that Marco stated that seemed too strong based on the evidence. Thanks for clarifying.

[marcoc1712]

Please,

have a listen to the diff files I posted, DIFF are definitely Audible, then make your own using the same WAV or FLAC file, they will be of the same order.

We tried.

Marco

[andynormancx]

have a listen to the diff files I posted, DIFF are definitely Audible, then make your own using the same WAV or FLAC file, they will be of the same order.

The diffs are only audible because of the clock drift. We don't have the same clock drift issue with our ears/brains so the measured difference when the clocks aren't synced do _not_ prove that there is an audible difference.

[marcoc1712]

...

If you want to prove this, make two "identical" WAV (or flac) recordings and compare them. They will be different.

If I repeat your test setup I get similar results to you - but they aren't helpful or meaningful.

Try comparing one WAV recording to another using your method and see what happens...

This is very simple, could anyone try to do what Phil advice (as I did) AND let we know if they are audible or not?

Not interested in continue in such a discussion if we could not fix some shared point.

Marco

[Phil Leigh]

This is very simple, could anyone try to do what Phil advice (as I did) AND let we know if they are audible or not?

Not interested in continue in such a discussion if we could not fix some shared point.

Marco

Marco - this is the point: if you remove the effects of clock drift, then playback of the same wav file twice will be identical and also playback of wav vs flac will be identical.

In the real world, as Andy says, clock drift is unimportant, provided it is not so big that you can actually hear it - and it would have to be quite big for that to happen.

Ask yourself this: if you listen to the same song file twice does it ever sound different? If the answer is yes then there is no point even talking about listening for differences between wav and flac! We have no fixed baseline.

If the answer is no, then we can carry on trying to identify possible differences between wav and flac replay...

[marcoc1712]

The diffs are only audible because of the clock drift. We don't have the same clock drift issue with our ears/brains so the measured difference when the clocks aren't synced do _not_ prove that there is an audible difference.

I'm with you, but do they prove for sure there is NO audible difference?

THIS IS THE POINT! I'm not stating something is proving that FLAC AND WAV are different, but only that you could not say FOR SURE is not possible!

Marco

[garym]

I'm with you, but do they prove for sure there is NO audible difference?

THIS IS THE POINT! I'm not stating something is proving that FLAC AND WAV are different, but only that you could not say FOR SURE is not possible!

Marco

Aha! Now we're in the realm of hypothesis testing (and I agree that the null hypothesis in all of our discussions (other than yours perhaps) is that there is NO difference. And yes, many of us believe that the evidence does not support rejecting the null of no AUDIBLE differences. Of course now we can go down the path of which is more important here, Type I or Type II errors.

All evidence suggests that I am a human being, born on earth. But there is a probability distribution (of some shape) surrounding this assertion and there is a tail, albeit extremely small, to this distribution where at some p-value I could reject the null hypothesis of me being human!

This said, I can say that in my day job of 25 years, I publish scientific papers, and this discussion is starting to remind me of certain journal referee comments ("just because you can't prove it is related, does not mean it is not related under some circumstances" -- robustness tests aside, there is no answer to this question. See, for example, the question: Does God exist?

[Themis]

Aha! Now we're in the realm of hypothesis testing (and I agree that the null hypothesis in all of our discussions (other than yours perhaps) is that there is NO difference. And yes, many of us believe that the evidence does not support rejecting the null of no AUDIBLE differences. Of course now we can go down the path of which is more important here, Type I or Type II errors.

All evidence suggests that I am a human being, born on earth. But there is a probability distribution (of some shape) surrounding this assertion and there is a tail, albeit extremely small, to this distribution where at some p-value I could reject the null hypothesis of me being human!

This said, I can say that in my day job of 25 years, I publish scientific papers, and this discussion is starting to remind me of certain journal referee comments ("just because you can't prove it is related, does not mean it is not related under some circumstances" -- robustness tests aside, there is no answer to this question. See, for example, the question: Does God exist?
Well, as you know, the null hypothesis can only be falsified. Never proved. It is part of the theory.

You need a different framework if you want to prove equality. ;)

[marcoc1712]

Ask yourself this: if you listen to the same song file twice does it ever sound different? If the answer is yes then there is no point even talking about listening for differences between wav and flac! We have no fixed baseline.

If the answer is no, then we can carry on trying to identify possible differences between wav and flac replay...

This is a good point and someone already discussed it, remember Eraclito and the river? Still you recognising the river? Did you prefer it when is clear or when is dark becouse clouds in the sky? It's always the same river, try to mesure it!

I have to say I dont see the sun reflected on his surface when sky is clear, just becouse you could not set apart is effect from the (major) others?

Try to wait for sunset or cover the river and repeat tests...

P.s.

In metaphor, my question is: I do prefer stay by the river in a sunny day, do someone the same? What are you feeling better? Not realy intrested in much other, i'll never able to make sun shining in a cloudy day, nor im asking someone else to do.

Marco

[garym]

Marco, to answer your primary question (and not scientifically, just my personal opinion): For your benefit, I play several files (jazz and rock, quiet and loud) through my system in both WAV and FLAC versions and hear no difference or get any different "feeling". This is true through my TRANSPORTER (analog out to preamp>>amp), my BOOM, or my SB3 (3 different systems) or my SB3 through a BENCHMARK DAC > preamp>>amp. So in terms of asking whether any of us "hear" any differences in playback across WAV and FLAC files, I can say, no, I hear no differences whatsoever.

[andynormancx]

I'm with you, but do they prove for sure there is NO audible difference?

THIS IS THE POINT! I'm not stating something is proving that FLAC AND WAV are different, but only that you could not say FOR SURE is not possible!

Outside of maths it is very hard to prove anything with 100% confidence.

You keep going back to your comparison of WAV/FLAC with clock drift, you need to completely ignore those results, they were completely flawed. All they show is your test approach was broken.

Phil's tests with a synced clock clearly show that any differences been the WAV/FLAC playback, even if they exist at all, are incredibly, incredibly tiny. But no, no one is ever going to measure, to the level that it seems you would find acceptable that they are identical.

[marcoc1712]

Marco, to answer your primary question (and not scientifically, just my personal opinion): For your benefit, I play several files (jazz and rock, quiet and loud) through my system in both WAV and FLAC versions and hear no difference or get any different "feeling". This is true through my TRANSPORTER (analog out to preamp>>amp), my BOOM, or my SB3 (3 different systems) or my SB3 through a BENCHMARK DAC > preamp>>amp. So in terms of asking whether any of us "hear" any differences in playback across WAV and FLAC files, I can say, no, I hear no differences whatsoever.

Thanks Gary,

Is just what i'm intrested to know from as many people as I can, Next step (but is too difficult I suppose) is tring to relate the habits and opinions of people who say could eard it respect who say he could not, about all the fancy thinks audiophiles loves (i.e. interconnect, power suply, CD/LP, etc.) just to have a relative scale.

p.s.

If null hypothesis could be proved, we all probably were looking for berries just outside Eden...

Marco

[garym]

Thanks Gary,
If null hypothesis could be proved, we all probably were looking for berries just outside Eden...


Ah yes! Happy Holidays to you. /gary

[marcoc1712]

Outside of maths it is very hard to prove anything with 100% confidence.

You keep going back to your comparison of WAV/FLAC with clock drift, you need to completely ignore those results, they were completely flawed. All they show is your test approach was broken.

Phil's tests with a synced clock clearly show that any differences been the WAV/FLAC playback, even if they exist at all, are incredibly, incredibly tiny. But no, no one is ever going to measure, to the level that it seems you would find acceptable that they are identical.

You are rigth, And we were already there, IF you could lock the AD and DA clocks, OR both are as closed as possibe to 44.100 Hz.

SO, I think nobody would say is not true that:

1. FLAC and WAV are BIT PERFECT.
2. THE PLAYBAC (DIGITAL) is BIT PERFECT until the SPDIF OUT.

To prove this is VERY symple.

3. Also the ANALOG PLAYBACK has no or very little differencs if you are using a "perfect" clock (or you could lock the AD and DA).

I could not test myself, but no matter is based on evidences that Phil produced and I belive for sure.

4. In Analog Playback (only the DA is involde here, so no possibility to lock any other clock) difference are bigger and you can eard at them, even with the same source file with no transcoding at all.

I've tested this, Phil too and both agree ARE audible, very simple to replicate.

Until this point statistics is not involved at all, is just a matter of measuring and comparing, do we agree on this?

If I'm wrong please correct me, I think could be of general interst.

Marco

[bluegaspode]

4. In Analog Playback (only the DA is involde here, so no possibility to lock any other clock) difference are bigger and you can eard at them, even with the same source file with no transcoding at all.

I've tested this, Phil too and both agree ARE audible, very simple to replicate.
I think in this argumentation is a flaw.

Differences in analog playback ARE audible if you try to measure/hear them with a flawed measurement (i.e. recording analog audio with an unsynced clock).
Bitperfect ---> DA --> analog ---> AD ---> recorder/audio diff maker

So this doesn't prove anything, its merely a selffulfilling policy.

More important is the following chain:

Bitperfect --> DA ---> analog ---> ear ---> brain

Unfortunately this can't be measured (yet) but do you really claim that playing the same wav you can hear differences (without ADM) ?
As others said already - if thats the case then theres no need to talk about wav vs. flac.

[marcoc1712]

Let me figure out:

You state that the errors (all the errors) take place ONLY becouse whe inserted the AD stage of the recorder in the chain (I suppose you don't think could be the codec, the disk or else), without this, no errors at all.

This will explain for sure why ADM could dedect differences and if we assume you are rigth, will cut over any possible differences due to the DA converter, so NO DIFFERENCES AT ALL till the analog output.

So if I eard differences, i'm wrong, is just impossible; if the recorder could too it's wrong, just becouse is impossible I could eard differences...

...mmmh....

I think is more likely that errors occours in AD AND DA, if you lock them, you only make them operate as one (means make the same errors), but STILL you have drift over the original clock and the one you will use to convert back the sound at the playback time, that is not in your chain at the moment (and - of corse - you are not measuring it)so you are NOT testing a real word situation.

With this test, You eliminate the DRIFT Error (of the 2 clocks who nobody will ever listen to) and only confirm that is BIT PERFECT, but we already know this.

[andynormancx]

I'm afraid you don't really understand what you are talking about which makes your argument null and void.

If the sound card had really, really fast sampling rate then you wouldn't have to worry about syncing the clocks. If the sampling rate was fast enough then ADM would see two play backs of the same source file as just about identical (unless the clock drift was substantial).

But that isn't the case, the sampling rate in your sound card isn't that much faster (or is the same) as the bit rate of the digital audio you are measuring.

You need to remember that the output of a DAC isn't _really_ analogue. The output is generated from digital so it will always have discrete steps in it (even if there is clever maths/electronics to smooth these steps out). If the steps if your two sample don't quite line up, due to clock drift then you will see differences that don't really exist in a meaningful way.

That is what the clocks need to be synced for any meaningful measurements.

[Themis]

Marco, to answer your primary question (and not scientifically, just my personal opinion): For your benefit, I play several files (jazz and rock, quiet and loud) through my system in both WAV and FLAC versions and hear no difference or get any different "feeling". This is true through my TRANSPORTER (analog out to preamp>>amp), my BOOM, or my SB3 (3 different systems) or my SB3 through a BENCHMARK DAC > preamp>>amp. So in terms of asking whether any of us "hear" any differences in playback across WAV and FLAC files, I can say, no, I hear no differences whatsoever.
+1 I can't hear any either.
But I'll try to make a better test this weekend with 7.5.

[marcoc1712]

Hi All,

ok,in this little pool only me and maybe 2 others could eard any difference between FLAC and WAVE, all the others could not and experts insure Us is impossible for many obvious and good reason.

So, I've to conclude is probably in my Brain (...but what "is" out of it?) and my next question is force me to follow reason and keep listening in Flac or not?

Whel, I don't know, I'll keep on trying and in the meantime I'll enjoy some old LP (just to remember what good sound is).

One think is sure, FLAC is far better than WAV for tagging purpose, and also is better (to me) becouse you could store (and TAG) track by track, not so friendly with WAV (Foobar could not produce a .CUE for a single track file, maybe some other. Handling a big collection of classical music is not an easy job, using WAV and CUE could early demotivate you.

Is that enougth to give up, not sure...

I've got ca. 3500 CD Ripped and stored in FLAC till now, they take 1 TB + backup (1 TB), maybe I'll get a 2TB HD for Kristmas, make a new copy in WAV and Keep Flac files for Back Up.

Thanks, Merry Christmas and Happy new Years to Everybody.

Marco.

[Phil Leigh]

Merry Christmas and Happy new Years to Everybody.

Marco.

And to you Marco!

[Themis]

I've got ca. 3500 CD Ripped and stored in FLAC till now, they take 1 TB + backup (1 TB), maybe I'll get a 2TB HD for Kristmas, make a new copy in WAV and Keep Flac files for Back Up.
You don't need to convert the library to WAV. Just ask SqueezeServer software to transmit them to your Squeezebox as WAV. ;)

[Phil Leigh]

You don't need to convert the library to WAV. Just ask SqueezeServer software to transmit them to your Squeezebox as WAV. ;)

Themis, I think you meant stream as "PCM" ...

[Themis]

Themis, I think you meant stream as "PCM" ...
Yes, sorry. :) Worked too much today.

[Phil Leigh]

Yes, sorry. :) Worked too much today.

Time for rest now. Relax, have some food and a nice glass of wine perhaps?

[ilbravo]

You don't need to convert the library to WAV. Just ask SqueezeServer software to transmit them to your Squeezebox as WAV. ;)

Unfortunately, SqueezeCenter 7.3. seems to have lost its capability to transcode flac to wav which was working in 7.2. flawlessly . When I set flac < flac to 'disabled' and flac < wav to 'flac' there is no more playback of flac files at all.

[marcoc1712]

To Ilbravo: in my system (7.4.1) is working properly.

To Themis: As You can read in the early posts, I've tried out this at the really beginning, but no real benefits in SQ to me, in "blind" tests I was able to recognize the WAV file, not alwais the FLAC versus FLAC > PCM.

This moved me to start the discussion, just becouse some behavoir of SB seems to be depending on the 'source' file type and not on the stream format (i.e. FF/REW) and the same is for my SQ perception, so maybe a relashionship exist, but never ask to me wich one, based on what or else, let tech people investigate it, if they want.

P.S.

Critical listening is now suspended, due to the massive wine quantity assumed...

Have a good time!

Marco

[marcoc1712]

To Ilbravo: in my system (7.4.1) is working properly.

To Themis: As You can read in the early posts, I've tried out this at the really beginning, but no real benefits in SQ to me, in "blind" tests I was able to recognize the WAV file, not alwais the FLAC versus FLAC > PCM.

This moved me to start the discussion, just becouse some behavoir of SB seems to be depending on the 'source' file type and not on the stream format (i.e. FF/REW) and the same is for my SQ perception, so maybe a relashionship exist, but never ask to me wich one, based on what or else, let tech people investigate it, if they want.

P.S.

Critical listening is now suspended, due to the massive wine quantity assumed...

Have a good time!

Marco

[deadushka]

I've read through all of the posts in this thread just because I've had a similar experience a few months earlier and was hoping to find a solution/answer to the problem which I brushed aside at the time as insignificant but very intriguing one.

A few months after I purchased a Duet in addition to my SqueezeBox I read an article in Stereophile where an expert by way of offhand remark mentioned something like "I was shocked at the difference in sound of lossless compressed files and uncompressed wavs".

Being an IT professional and knowing that theoretecally there should be NO difference between a flac and a wav files (other than one file is actually zipped) I tried to prove this claim wrong in practice.

I took a wav-file (ripped from some audiphile CD) and a flac version of the same file and played these through my system (Duet -> Audio Alchemy DAC -> Parasound A21 power amp -> NHT 2.5i). To my surprise there was a diffirence. Wav played audibly better.

To confirm these results I invited my two friends-audiophiles and after a couple of glasses of wine asked them to tell if there was a difference between two versions of the song. This was what you call a blind test, they didn't know if there actually was a differnce, beause I wasn't 100% sure either, and they didn't know what file was actually playing flac or wav.

The funny thing was that they preferred and correctly identified 100% of wavs not knowing what I actually was trying to find out. They actually didn't know what flac is (they were CD-audiophiles) and why there should be no difference between the files until I explained to them the meaning of the test.

The version of the server was 7.2.

Well I took this result as a fact, but I had to live with this knowledge as the size of my collection was at the time 1.5Tb in flac files and I had to have this tag feature which allowed for convenient management of the collection.

Now that you've read all of the above the question is (I couldn't find an answer in this thread):

How can I make SqueezeCenter version 7.3.3 (which I'm running now) or any other Slim Server convert flac to wav (sorry, PCM) on the server side before it is sent to the receiver (if at all pssible).

[Pete Fowler]

I took a wav-file (ripped from some audiphile CD) and a flac version of the same file and played these through my system (Duet -> Audio Alchemy DAC -> Parasound A21 power amp -> NHT 2.5i). To my surprise there was a diffirence. Wav played audibly better.


I can't help with your question of how to force WAV output of FLAC files, but I can offer one (potential) reason why you're hearing a difference between the file types...at least with the Duet receiver.

It all depends on what the Xilinx receiver chip in the Duet has to do to process FLAC vs. WAV files. Does decompression of FLAC happen in the Duet receiver or on SqueezeServer? Is a WAV file playable as-is (or with minimal processing by the receiver chip)?

Because - anything that causes the Xilinx receiver chip to work harder in the Duet receiver will degrade the sound. The Xilinx puts out a lot of self-noise onto the power rails, master clock, etc. If sending it WAV files vs. FLAC files reduces the internal activity on the Xilinx you'll get lower jitter and noise sent to the I2S, SPDIF and onboard DAC chip.

I wish I knew more about the architecture of the Xilinx firmware in order to answer this definitively. I'm willing to bet that's the source of any difference between the two formats.

Pete

[JohnSwenson]

How can I make SqueezeCenter version 7.3.3 (which I'm running now) or any other Slim Server convert flac to wav (sorry, PCM) on the server side before it is sent to the receiver (if at all pssible).

All versions have this capability, its in the file formats page in SqueezeCenter (Squeezebox Server). You have to use a browser on a computer to connect to the server (http://<serverURL>:900) That is in the broweser address bar type http:// followed by the server URL followed by :9000. For my system that is http://192.168.1.50:9000 If you are doing this on the computer where the server is running this is http://localhost:9000

Once there you need to go to server settings and find the section for filetypes. I don't remember exactly where that is on 7.3. Poke around until you find it.

This will bring up a window which lists a bunch of file types on the left. For each file type you are given a list of stream options. Each stream option will have a box that you can check or uncheck. Find the FLAC file type and make sure the only stream option selected is wav. If you have more than one stream option chosen you have no idea which the server is going to choose so make sure you only have one stream option selected for each file type. If you don't have any stream options checked the server will not send that type of file at all.

Then click on the apply button and that should be it. The next song you go to should now be streaming PCM rather than flac.

The more recent Squeezebox Server uses a slightly different format, For each filetype you are given several boxes which have pull down menus. You have a choice of: disable, or a stream type. One of the boxes has a stream type of native. This sends the file with no change, one has a stream type of PCM. Make sure all the boxes say disabled except for the one with PCM. That is the same as having WAV selected in the earlier versions.

I hope you can figure it out from this. Its not really all that hard once you find the filetype page.

John S.

[deadushka]

To Pete:

Yes, that was my thought too. Some overhead calculations may generate some extra noise. But I don't want to make an issue about it I just want to solve this minor problem.

To John S: Thanks for the advice. But 7.3.3 doesn't have an option in web-interface to stream flac as WAV (PCM). You either stream flac as native or disable it. My music is in flac and properly tagged.

Someone in this thread hinted that some changes to "convert.conf" may help.

Andre

[marcoc1712]

Hi All,

nice to see that I'm no longer alone...

To deadushka, go to advanced settings, File types:

FLAC - FLAC > Disabled
- MP3 > DISABLED
- PCM > flac

if the option FLAC in PCM is not awaillable, maybe you need to installa FLAC.EXE in your system (I never had this problem until now) or why not install 7.4.1.

Anyway, I tried in this way but the result - in term of sound quality was any better to me, maybe Pete could investigate it, but I'm very intretsed about your listening opinion.

I'm looking for a solution to have some better chance in tagging files using WAV and .CUE files, not found any yet, but I think could be done.

At the moment, I'm using multiple values in PERFORMER tag in .cue file, putting there COMPOSER, ARTIST and BAND comma separated. GENRE, DATE and YEAR are working, but you need a REM before them in the file.

To do tis, you could use Foobar to tag without the risk of loosing info.

Bye, Marco.

[deadushka]

I've installed Slim Server 7.4.1.

If I disable FLAC -> FLAC in web interface and enable FLAC -> WAV streaming (that is flac in dropdown list) then I don't get any sound at all.

Is there a way to bypass this setting by editing convert.pref or custom convert.pref?

I've tried to figure out how to do it myself but format of the commands in that files is not that obvious. :-(

[marcoc1712]

Hi, I could not Help You with the pref file you mention, I havent got it in my system.

The only related file that i've got is Server.prefs and about formats I've only two lines:

disabledformats:
- flc-pcm-*-*
- wav-flc-*-*

Just becouse i've disabled the STANDARD conversion from WAV to FLAC (second line) and forced the FLAC streaming of Flac (first line).

I asking the following to you, becouse in my first time i misandestud the meaning of the file type menu, is not so clear and could make confusion:

Have you noticed that you have 3 lines with 3 combo per origin file type?

You need to check both FLAC and WAV as follows:

...

FLAC - FLAC - Disabled
- MP3 - Disabled
- PCM - Flac
...

WAV - FLAC - Disabled
- MP3 - Disabled
- PCM - Native
...

Just to be sure, I apologize if you already did it :-).

Let me know!

bye.

[deadushka]

Marco,

I've f@#$ up my installation of 7.4.1 by copying server.prefs and convert.conf from my previous installation of 7.3.3.

Now I have a clean install of 7.4.1 and all the settings are as you described them.

When settings are like this

FLAC:
FLAC - Disabled
MP3 - Disabled
PCM - flac

WAV:
FLAC - Disabled
MP3 - Disabled
PCM - Native

I can't hear any difference between a flac-file and a wav-file.

[Phil Leigh]

Marco,

I've f@#$ up my installation of 7.4.1 by copying server.prefs and convert.conf from my previous installation of 7.3.3.

Now I have a clean install of 7.4.1 and all the settings are as you described them.

When settings are like this

FLAC:
FLAC - Disabled
MP3 - Disabled
PCM - flac

WAV:
FLAC - Disabled
MP3 - Disabled
PCM - Native

I can't hear any difference between a flac-file and a wav-file.

good - there is no difference - ADM can't measure one and I don't think John Swenson's Spectrum Analyser can measure one either. John?

All these theories about extra noise from the Xilinx (or whatever) are simply not supported by any measurements. These effects should be completely repeatable and easily measured... but they aren't.

A properly controlled DBT would certainly fail as well.

If there was anything in this theory, you might like to try to hear a difference between flac compression level zero and flac C 8. The xilinx is going to be working a lot harder for C 8...

[deadushka]

Marco,
When settings are like this

FLAC:
FLAC - Disabled
MP3 - Disabled
PCM - flac

WAV:
FLAC - Disabled
MP3 - Disabled
PCM - Native

I can't hear any difference between a flac-file and a wav-file.

I didn't try though the following combination

FLAC:
FLAC - Native
MP3 - Disabled
PCM - Disabled

WAV:
FLAC - Disabled
MP3 - Disabled
PCM - Native

which I may test tomorrow. That is when the receiver is fed with flac not pcm.

[Pete Fowler]

good - there is no difference - ADM can't measure one and I don't think John Swenson's Spectrum Analyser can measure one either. John?

All these theories about extra noise from the Xilinx (or whatever) are simply not supported by any measurements. These effects should be completely repeatable and easily measured... but they aren't.

A properly controlled DBT would certainly fail as well.

If there was anything in this theory, you might like to try to hear a difference between flac compression level zero and flac C 8. The xilinx is going to be working a lot harder for C 8...

Hi Phil,

Your post (above) sent me back to the beginning of this thread and a full reread of the content.

If I understand the conclusion(s), then the Xilinx does a fantastic job of passing data out to the SPDIF and the I2S bus.

I also freely admit to having some interesting but ultimately bogus theories on how the Xilinx works. Oh well...;-)

Since I don't have my arms around the capabilities of ADM I would ask you what I hope is not too dumb a question:

Could I use ADM on the analog out of the Duet receiver to evaluate reductions in noise/jitter (if present) caused by cleaning up the master clock or the power to the DAC, etc?

In other words I could A/B the stock clock vs. a supposedly low-noise clock, etc? Would those types of changes show up? I'm hearing some pretty wild claims on another thread and it would be good to separate the delusions from the reality...

Many thanks,

Pete

[JohnSwenson]

Pete,
I have taken an SB3 and replaced the crystals with a very low jitter oscillator fed by very low noise external PS and was able to hear a very significant difference in the analog out. This one I'm pretty sure you could measure with ADM.

Phil,
I have not been able to hear a difference between flac or wav FILES, as long as both were being streamed using the same format. The difference I can hear is when streaming with different formats. So far I have just tested the clock jitter not the spectrum of the power supplies. I was surprised by the increase in jitter when the headphones were plugged in. One test to try is ADM on the analog outs with headphones plugged in or not. It will be interesting to see if the jitter difference I saw is measurable by ADM.

The headphone listening tests are going to be a little difficult right now, I was doing so much of it in the lab that I broke my headphones. I put a pair on my Christmas list, but no luck. I'm going to have to order a pair myself!

The next measurement is to hook the spectrum analyzer up to the PS pins at the DAC chip and see if I can see any difference there with stream format.

John S.

[Phil Leigh]

Hi Phil,

Your post (above) sent me back to the beginning of this thread and a full reread of the content.

If I understand the conclusion(s), then the Xilinx does a fantastic job of passing data out to the SPDIF and the I2S bus.

I also freely admit to having some interesting but ultimately bogus theories on how the Xilinx works. Oh well...;-)

Since I don't have my arms around the capabilities of ADM I would ask you what I hope is not too dumb a question:

Could I use ADM on the analog out of the Duet receiver to evaluate reductions in noise/jitter (if present) caused by cleaning up the master clock or the power to the DAC, etc?

In other words I could A/B the stock clock vs. a supposedly low-noise clock, etc? Would those types of changes show up? I'm hearing some pretty wild claims on another thread and it would be good to separate the delusions from the reality...

Many thanks,

Pete
Hi Pete!

Yes, ADM can help you out in at least 2 ways:
1) comparing changes to see if there really is a difference. For this test you'd play a file (usually a 30-second edit is adequate) and record the output via the analogue outs of the SBR. Then make a change to the SBR and record the same file again and compare. ADM won't tell you which is "better" but it will certainly tell you if there was any difference.

2) compare a recording (the original untouched WAV rip) with the analogue output. Since the aim is to get closer to what was on the CD, you are looking here for differences to be reduced as changes are made. This test is brutal on any DAC... frequency/phase response anomolies, noise etc are all revealed.


In all cases you need to use a recording setup that eliminates cyclical fluctuations caused by the natural drifts of the clocks in the Dacs and ADC's. I use an M-Audio 24/96 card that has spdif and analogue inputs and importantly lets you lock the card clock to the incoming spdif clock whilst recording the analogue signal. This eliminates any timing errors (and we are talking about very tiny relative drifts of +/- a few hundred samples). The drifts are temperature sensitive.


Jitter effects only occur within the SBR DAC (regardless of the underlying cause) and thus will be detected by these tests.

An interesting conundrum occurs when test 2 shows a bigger difference to the original CD waveform, but it sounds "better"...

Happy Listening
Phil

[Phil Leigh]

Phil,
I have not been able to hear a difference between flac or wav FILES, as long as both were being streamed using the same format. The difference I can hear is when streaming with different formats. So far I have just tested the clock jitter not the spectrum of the power supplies. I was surprised by the increase in jitter when the headphones were plugged in. One test to try is ADM on the analog outs with headphones plugged in or not. It will be interesting to see if the jitter difference I saw is measurable by ADM.

The headphone listening tests are going to be a little difficult right now, I was doing so much of it in the lab that I broke my headphones. I put a pair on my Christmas list, but no luck. I'm going to have to order a pair myself!

The next measurement is to hook the spectrum analyzer up to the PS pins at the DAC chip and see if I can see any difference there with stream format.

John S.

Thanks John. Unfortunately my main PC broke down on Dec 25th (!) and I am awaiting parts. I can't resume testing till that machine is up and working again. I managed to press an old laptop into service in about 15 minutes as a replacement Server (thanks heavens for external USB drives!) but obviously I have no suitable sound card in there...
regards
Phil

PS it would be really interesting to see if you could actually measure the noise spectrum of the DAC output when streaming PCM vs FLAC and also with FLAC level zero versus max compression.

[marcoc1712]

Phil,
I have not been able to hear a difference between flac or wav FILES, as long as both were being streamed using the same format. The difference I can hear is when streaming with different formats.

John S.

Hi John, could you explain a little the kind of differences you hear when streaming PCM instead of FLAC?

Thanks, Marco.

[Pete Fowler]

John - thank you for the insight. I've installed a Tent XO driven by a DIY Vreg and now a SuperTeddyReg in the receiver. Both were better than stock but quantifying the improvement by ear is impossible (for me, at least). I envy you your HP analyzer.

Phil - thank you for the excellent description of what ADM can do. Option 2 sounds really interesting as that's where the rubber meets the road. CD data in, noise and distortion out. ;-)

I also appreciate your comment re "improvement" vs. "change". I'm fighting that tendency now.

Pete

[JohnSwenson]

Hi John, could you explain a little the kind of differences you hear when streaming PCM instead of FLAC?

Thanks, Marco.

Hi Marco,
the two areas that are most noticeable are ambience and "aliveness". When streaming PCM the music is more at home in its acoustical space. You can hear the reverberation as naturally part of the environment, its there but doesn't call attention to itself. When streaming flac the reverberation seems somewhat artificial and painted on a screen in front of the music rather than filling the space. The whole thing feels somewhat "squished" and flat. The aliveness is a little hard to define, musicians seem more real and less canned. You can sense subtle emotional nuances of expression easier.

Its not that flac sounds BAD, if you never listened to it with PCM you would think it sounds great, but then when you hear the PCM stream its WOW, where did THAT come from?

Now I realize other people do not hear this and I have no explanation for that. Some people can and some can't, I don't know whether its people differences, environment differences or what.

So far I have not been able to measure any differences. Sometime early next year I'm going to attempt a blind test as outlined earlier in this thread. We'll see if I really CAN hear a difference.

John S.

[marcoc1712]

Hi John,

What you reported is quite similar to what I feel listening to WAV/PCM instead of FLAC (see previuos posts), and the major conseguence to me is that listening to FLAC drive to an early fadigue.

The strange thing is that in my system I could ear nearly the same difference also if I stream FLAC as PCM, and I know is not depending on the bits in the data stream...

Maybe Your trials and measures could help to understand, DBT could help to, but please try also some longer listening experience.

I realy hope to find out a bug in my configuration and fix it, then I'll use FLAC as storage file format, WAV and CUE are too bad for "tagging" purpose.

Thanks, Marco.

[marcoc1712]

Hi All,

In Italy we say "another little stone in the lake", and this is: Have you noticed that people in other forums claims to eard the same differences in different hardware too (i.e. LINN or AVFORUM)? I think I can't post links here, but just google...

Anyway,

I've tried again the "Blind Test" between WAV-> PCM and FLAC -> PCM in two different ways:

1) Listening to just one file at once, result 8/10 correct.

2) Listening 20 sec of 1 file, then the same 20 sec of the other and try to individuate the FLAC one, result 9/10 correct.

In both case My wife was randomly selecting the file to play, I was not able to see her and she was writing down results.

This was the better 'near blind' test I could arrange, but I stress that the major difference become clear to me after a much longer listening session!

Waiting for other people results.

p.s.

John, may I ask how are you managing WAV/CUE library? Any advice on how to have a better 'tagging' than only GENRE/ARTIST/ALBUM/YEAR/TRACK/TRACKNUM ? (maybe in PM or in other thread, if this question is OT).

p.p.s.

To Phil, Not using WAV could not be "the" solution, unless Logitech declare they will not support WAV and CUE anymore, and I've no evidence of this (and hope is not!) :-)

Thanks, Marco.

[Daverz]

Marco, when you say you can tell the difference after 20 seconds, can you describe the qualities of the sound that you use to differentiate?

Also, what about AIFF files? They can have an ID3 metadata block.

[deadushka]

I've just checked the sound quality of 7.4.1 against 7.3.3 server (with the help of Acronis).

With the same settings (flac converted into pcm on the server side) it is night and day difference.

The highs on 7.4.1 sound compressed and synthetic (reminds of the worst of sub $100 dvd-player)? the mid, well with this kind of highs you wouldn't properly hear them.

When compared to 7.4.1 the 7.3.3 server sounds WOW!

The problem is I can't get the controller back to 7.3.3. Any ideas?

[Robin Bowes]

On 31/12/09 09:45, deadushka wrote:
>
> I've just checked the sound quality of 7.4.1 against 7.3.3 server (with
> the help of Acronis).
>
> With the same settings (flac converted into pcm on the server side) it
> is night and day difference.
>
> The highs on 7.4.1 sound compressed and synthetic (reminds of the worst
> of sub $100 dvd-player)? the mid, well with this kind of highs you
> wouldn't properly hear them.
>
> When compared to 7.4.1 the 7.3.3 server sounds WOW!
>
> The problem is I can't get the controller back to 7.3.3. Any ideas?

Ho ho ho! "night and day" difference? Between server versions? I think
not...

Something else is at play here, eg. your transcoding settings are
different between server versions, you're bandwidth limiting on the
7.4.1 server, etc.

R.

PS. Anyone know the collective noun for audiophiles?

An assylum of audiophiles! :)

[deadushka]

On 31/12/09 09:45, deadushka wrote:[color=blue]
Ho ho ho! "night and day" difference? Between server versions? I think
not...

Something else is at play here, eg. your transcoding settings are
different between server versions, you're bandwidth limiting on the
7.4.1 server, etc.


The transcoding settings are the same on both versions. Any other bright ideas?

Obviously there's something wrong with the transcoding settings in the default configuration of 7.4.1. All I did was change the FLAC transcoding setting like this:

FLAC - DISABLE
WAV - FLAC

As I previously mentioned there IS a difference in sound between a flac beeing sent to the receiver undecoded and an uncompressed wav, so I managed to get my 7.3.3 back to work and will wait untill this bug with 7.4.1 transcoding is resolved, frankly I liked the interface of 7.4.1 more.

Well if you can't hear the difference you are a lucky man. At least you don't have to spend thousands on your hardware.

[marcoc1712]

Marco, when you say you can tell the difference after 20 seconds, can you describe the qualities of the sound that you use to differentiate?

Also, what about AIFF files? They can have an ID3 metadata block.

Hi, Daverz.

I was using two different track for the test:

- Old Love - Eric Clapton - Umplugged
- Coro con - La creazione, Joseph Haydn, NY philarmonic, L. Bernstein, J. Raskin, A. Young, J Reardon - 1968" (track 2 Cd1).

Note that I know very well those tracks, that i'm using since quite a lot of time to compare audio devices or testing purpose.

In the first test (listening to the entire track, one at once) I was using Hydn, and the major differences was:

a) Stereo Image:

Playng the Wave file, the scene is more focused and deeper, but smaller, the choir is in behind and well distributed over the scene, then you have the Orchestra and ahead soloist, Tenore in the left, Bass in the right, Sopran in the middle.

With Flac, the scene is larger but more 'compressed' in depth, there is a 'hole' in the middle of the choir and the bass is like it was 'sitted' (i'm using emphasis, just to explain), Choir is over the orchestra and Soprano is a little shifted to the left.

b)Sound 'color':

Playng Flac, voices & arcs are a little bit 'harder', 'brigthter' and cold, some 'electric' take place all over, in wave they are smoorher, some more air around and more 'natural', silence is more like ...silence.

Major difference in the Bass Voice, is more 'present' in WAV.

In the second test (listening to a short piece, until the firts few seconds of Eric Clapton singing of both tracks) I forced myself to point some detail:

a. The Guitar attach and swinging.
b. The piano.
c. The pubblic voices and applauses at the realy beginning.
d. The Eric Voice and the Bass.

Major differences in voices and applauses, in WAV are much more real, Eric Voice is smoother and Bass is behind and a little on the rigth side, Piano and Guitar are brigther in FLAC, but better focused and 'round' in WAV.

Over all, in FLAC I feel like the atmosphere is eletric, everythimg is brighter but a little hurting, something like (but is nor realy like that) when you listen a live show and at the end is silence, but when they switch off the AMPS you realize it was NOT realy silence...

Sorry about that, but my bad English cant't support me in describing this sort of feeling using the rigth words as I would like, I hope you could at least figure what i meant.

By the way, I did this 'blind' test becouse I was curious to try, but if you take the time to have a longer session listening for say 2 hours, you could experiment yourself how WAV is more relaxing and less hurting, or at least this is my feeling.

You can read other impressions in my previous post in this thread, but they become from tests that someone has defined 'not proper'. I think they move to similar conclusion.

Hope is useful.

Marco.

[marcoc1712]

To deadushka,

sorry but if I remeber whel, I switched form 7.2.xx directly to 7.4.1, and i've noticed any major change in SQ, but they were the days when I switched form duet + external DAC (AR 20.1) to SB+ too, so i never tried to point server or firmware difference realy.

p.s.

Have you upgrated the firmware too?

Regards.

Marco

[deadushka]

To Marco

I'll describe the whole chain of upgrades.

1) SqueezeBox (the one that looks like the bedside clock) -> analogue output directly into Parasound A21 power amp + a pair of NHT 2.5i. Can't recall what version of server was running.

The sound - racey, dynamic, untidy. Best suited for the likes of AC/DC.

2) SqueezeBox -> Audio Alchemy DAC-in-the-Box + Power Station -> Parasound A21 power amp + a pair of NHT 2.5i. Can't recall what version of server was running.

The sound - racey, dynamic. A definite improvement, more accurate sound, but the general character of sound is the same as in previous setup. Reminds of analogue gear.

3) Duet -> Audio Alchemy DAC-in-the-Box + Power Station -> Parasound A21 power amp + a pair of NHT 2.5i. Can't recall what version of server was running because I didn't realize that was important.

The sound - totally different from previous setup (to my surprise, because I bought it because of the controller). It's like you've made $10K upgrade. I've heard a very similar sound from a system costing in excess of $25K (VTL tube monoblocks + Vandersteen 3ce + Esoteric CD + DAC) only mine had a insignificant trade-offs in mid and overwhelming advantage in bass.

This is funny because I thought the digital signal from SB/receiver should be the same. Obviously I was wrong. Some processing is being done internally in the SB/receiver.

Then I noticed this issue with flac vs wav but brushed it off as inevitable trade-off. But then I've read this thread and started experimenting with different versions of the server. The results amaze me to say the least.

I forgot to mention a minor upgrade which made a huge difference - a computer grade Defender 2000 KVA AVR worth $60 for the receiver and DAC which resulted in no less than $2000 worth of improvement.

[Stratmangler]

I find the paranoia behind this thread quite intriguing. Paranoia is the correct word to use, especially when comments are made about sounds being shortened by 10 cms or so.

IT'S ONLY AUDIO, FOR GODS' SAKE !!!

There are far more important things in life, such as family & friends.
Spend time with your kids. Go play football in the park with them, fly a kite, whatever. It's far more important because it's time you will not get again.

If you don't like the SQ of such and such a version of Slimserver/Squeezecenter/Squeezebox Server that's fine. Stick with what you like and just get on with life. You don't have to use the latest version for things to work. Just use whatever it is that sounds good to you and be happy and enjoy the music.

Chris:)

[marcoc1712]

I Chris,

I could Agree with you, but please, I'll never shame nobody becouse - for istance - is spending is time watching 22 guys in paints, running after a ball, then figthing with others just for the color of the shirt, and worst off all, watching television 2 hours a day from monday to saturday, hearyng 'gurus' talking about kness or shape of players...

I do prefer listening to my preferred music AND look for the better way to do it in my free time, but for sure is not the only thing I do.

By the way, I don't know any audiophile divorced becouse his hobby, many football fans are!

...It' only a ball running on a field!

To Chris and everybody, have a nice New Year's Eve!

Marco.

[deadushka]

To Chris

I'm glad that it's intriguing. Otherwise you wouldn't waste you time here.

Happy New Year everybody! The guests wouldn't let me continue so I'm off for the next couple of days.

I promise I'll test the Duet under heavy party conditions.

[RadioClash]

I find the paranoia behind this thread quite intriguing. Paranoia is the correct word to use, especially when comments are made about sounds being shortened by 10 cms or so.

IT'S ONLY AUDIO, FOR GODS' SAKE !!!

There are far more important things in life, such as family & friends.
Spend time with your kids. Go play football in the park with them, fly a kite, whatever. It's far more important because it's time you will not get again.

If you don't like the SQ of such and such a version of Slimserver/Squeezecenter/Squeezebox Server that's fine. Stick with what you like and just get on with life. You don't have to use the latest version for things to work. Just use whatever it is that sounds good to you and be happy and enjoy the music.

Chris:)


Thanks for the speech.

[Themis]

Well if you can't hear the difference you are a lucky man. At least you don't have to spend thousands on your hardware.
Well, I am another lucky man (being in 7.5), although it doesn't prevent me from spending thousands... ;)

[Daverz]

Hmmm, I have The Creation in the new Bernstein Haydn box, maybe I'll try listening for these things.

[Daverz]

IT'S ONLY AUDIO, FOR GODS' SAKE !!!


Why are you taking the time to yell at us? We are only audiophiles, for FSM sake!



If you don't like the SQ of such and such a version of Slimserver/Squeezecenter/Squeezebox Server that's fine.

Why does it bother you that some folks may not be entirely happy with the sound from their Squeezeboxen? Perhaps you are too emotionally invested in these little black boxes.

Joking aside, and however skeptical I am, it does bother me a that there might be some real effect here that is degrading sound quality. I believe that a decent DAC should only care that the bits are delivered to it in order and in a timely fashion, and audiophile fussing about this annoys me, but I don't know enough to be able to dismiss the paranoia completely.

[Stratmangler]

Why are you taking the time to yell at us? We are only audiophiles, for FSM sake!

The thread has gone on for nearly 2 months now, and just keeps going round in circles. And it goes round in circles for the same reason - someone makes a claim and then fails to provide any proof. Any evidence provided by other forum members that is contrary to the claim is ignored.


Why does it bother you that some folks may not be entirely happy with the sound from their Squeezeboxen?

It doesn't bother me. I use an external DAC on my SB3. So as you see, I'm not entirely happy with my Squeezebox's sound. I am happy with the DAC in tow.


Perhaps you are too emotionally invested in these little black boxes.

Nope - although I still think they're a great way to play my digital music collection.


Joking aside, and however skeptical I am, it does bother me a that there might be some real effect here that is degrading sound quality. I believe that a decent DAC should only care that the bits are delivered to it in order and in a timely fashion, and audiophile fussing about this annoys me, but I don't know enough to be able to dismiss the paranoia completely.

Audiophile fussing got to me, as you're aware.

I've had similar concerns once before - I went from one version of server to another, and the sound quality went from excellent to dreadful. I also posted on this section of the forum to see if anyone else had experienced the same issues.

My problems were sorted out by an uninstal, registry cleanup, and totally clean reinstal.

Since then I've not encountered any problems or noticed any audible differences when switching from one version to another.

I also cannot hear any differences between wav and flac files. I have played around unpacking flacs to wavs and packing wavs up to flacs and listening to them - I'm buggered if I can detect any differences.

So I fall into the very contented camp.

Anyway, that's enough of this; may I take this opportunity to wish you all a very Happy New Year.

Chris:)

[marcoc1712]

The thread has gone on for nearly 2 months now, and just keeps going round in circles. And it goes round in circles for the same reason - someone makes a claim and then fails to provide any proof. Any evidence provided by other forum members that is contrary to the claim is ignored.

I do provide the proof, as I could, they ask me a DBT I did, I could not provide any other proof. If You don't trust me, sorry, I've no way to convince you, and realy I'm not intrested in.

All the other evidence provvided - indeed are useful and sometime very intresting, i..e the one Phil gave to me, ARE NOT definitive at all.

I agree it should be not like that, that is unlikely, that many people could not ear any difference and so on, but those are definetly no proof at all that I (and few others) could ear it.

Sorry about that, but logic has it's own roles...

So, please, moderate yourself, I don't need your apreciation, but I've never autorized you to shame me this way.

p.s. What about fly a Kite...?

Have a good - and cool - 2010.

Marco

[rgheck]

To Marco

I'll describe the whole chain of upgrades.

1) SqueezeBox (the one that looks like the bedside clock) -> analogue output directly into Parasound A21 power amp + a pair of NHT 2.5i. Can't recall what version of server was running.

The sound - racey, dynamic, untidy. Best suited for the likes of AC/DC.

2) SqueezeBox -> Audio Alchemy DAC-in-the-Box + Power Station -> Parasound A21 power amp + a pair of NHT 2.5i. Can't recall what version of server was running.

The sound - racey, dynamic. A definite improvement, more accurate sound, but the general character of sound is the same as in previous setup. Reminds of analogue gear.

3) Duet -> Audio Alchemy DAC-in-the-Box + Power Station -> Parasound A21 power amp + a pair of NHT 2.5i. Can't recall what version of server was running because I didn't realize that was important.

The sound - totally different from previous setup (to my surprise, because I bought it because of the controller). It's like you've made $10K upgrade. I've heard a very similar sound from a system costing in excess of $25K (VTL tube monoblocks + Vandersteen 3ce + Esoteric CD + DAC) only mine had a insignificant trade-offs in mid and overwhelming advantage in bass.

This is funny because I thought the digital signal from SB/receiver should be the same. Obviously I was wrong. Some processing is being done internally in the SB/receiver.

There needn't be any "digital processing" for you to hear a difference. The issue is likely the amount of jitter in the output signal. It wouldn't be a great shock if the newer Receiver had lower jitter. And that can make a HUGE difference.

[rgheck]

I also cannot hear any differences between wav and flac files. I have played around unpacking flacs to wavs and packing wavs up to flacs and listening to them - I'm buggered if I can detect any differences.


I haven't tried any such test, but I am puzzled why anyone would be puzzled about why there COULD be such a difference. The answer, in the digital world, is always "jitter". More processing has to be done to decode the FLAC file than to play the WAV, and it's easy to see in principle how that could lead to higher jitter, even to signal-correlated jitter (the worst), or to various sorts of nasties getting into the power supply, or who knows what.

In principle, it could even be the other way around. You can imagine some device that buffers the output when decoding FLAC but not when streaming WAV, and that could lead to better timing on output.

Whether any of that is in fact going on here, I have no idea. But I do know that the digital outputs on the Transporter are VASTLY superior to those on the Receiver. I'd have been perfectly happy to spend less money on the latter and spend the difference on a new cartridge (say), but the improvement with the Transporter difference was sufficient to justify the additional expense.

[Themis]

More processing has to be done to decode the FLAC file than to play the WAV, and it's easy to see in principle how that could lead to higher jitter, even to signal-correlated jitter (the worst), or to various sorts of nasties getting into the power supply, or who knows what.
Transcoding is asynchronous and does NOT execute as a music stream : merely as a data file processing. Why would you think that such a thing as "jitter" exists in a computer program ?
Why this particular processing could cause power supply overload or whatever else ?

[bhaagensen]

it's easy to see in principle how that could lead to higher jitter, even to signal-correlated jitter (the worst),

Since its easy, could you explain exactly how?

(Bear in mind that decoding of flac to wav is not at all related to timing)

[rgheck]

Since its easy, could you explain exactly how?

(Bear in mind that decoding of flac to wav is not at all related to timing.)

I wasn't talking about the decoding. I was talking about the digital signal that is eventually passed to the DAC. There's jitter there, of course. And, in principle, how much there is, and how correlated it is with the signal, could be affected by the flac to wav conversion (which is happening in the unit, not on the server), for example, by noise generated by that conversion or power supply fluctuations due to just about anything you please.

Whether it IS affected by such things is not for me to say. Nor is it for me to say whether, given the particular design of the SB or Receiver or Transporter circuits, it CAN be affected in any particular one of those cases, since I don't know anything about those designs. My point is simply that, in principle, there is no reason to think no such thing CAN happen. To say otherwise is to put a bit too much faith in theory and to forget the limitations of any particular implementation.

[Themis]

The reason that such such thing cannot affect quality in a consistent (durable) way is that inflation (decompression from FLAC to PCM) is *not* a CPU-consuming process, contrarily to compression. To give you an example, the decompression of a 3-minute song should not take more than -say- 10 seconds. However you may distribute this activity into the 3 minutes, it is of no interest.

So, however such an activity could (possibly) distribute itself in time, still it cannot impact more than -for instance- the sliding of the letters on the display...

So, unless someone provides some *measured* proof of such an impact, I guess we have to look somewhere else for an -eventual- sonic difference explanation. :)

[bhaagensen]

rgheck: fair enough. But this is, IMO, very much from the department of "audible effects of the suns position on the hemisphere".

Even worse are some other threads I'm writing discussing the new Naim DAC. In essence this DAC buffers everything and clocks the entire pipeline from the buffer to the chip from the same crystal. Still, some claim that there are all kinds of transport-attributed audible differences...

I have yet to hear it so I don't have much to say, but if there is a difference it is truly inexplaniable.

[ilbravo]

Hi all,

let me contribute two observations to this interesting discussion

1. Streaming any flac file as pcm (wav) results in a higher volume level than streaming the same file in flac natively (even visible in a wider range of the movement of the pointers of the transporter's analogue VU-Meter, of which I thought, this display was only a nice gimmick). Could be a hint that the wohle phenomenon could have to do with gain (?).

2. Today I streamed a flac file (first movement of the symphony No 5 by Ralph Vaughan-Williams) natively and the transporter displayed as bitrate; "532 kb/s VBR".
When streaming the same file as pcm the display showed: "532 kb/s VBR (converted to 1411 kb/s ABR)".

So me too, I prefer to set the squeezeserver to convert flac to pcm and enjoy the result - despite of it is a placebo effect or not.

Cheers
ilbravo

[rgheck]

The reason that such such thing cannot affect quality in a consistent (durable) way is that inflation (decompression from FLAC to PCM) is *not* a CPU-consuming process, contrarily to compression. To give you an example, the decompression of a 3-minute song should not take more than -say- 10 seconds. However you may distribute this activity into the 3 minutes, it is of no interest.

Well, that would be the kind of information that was clearly relevant here. As I said, I do not know about the design.

That said, How much memory is there in a Receiver? Enough to buffer the whole song? And store the FLAC itself? I rather suspect, though of course I could be wrong, that the FLAC is being streamed and conversion is being done on the fly. Still, as you say, it may well be that there's not enough (additional) activity plausibly to make a difference, though that's hard to say for sure. If the conversion process is consuming CPU cycles, maybe it could occasionally be consuming them at just the wrong moment, with the result that you get timing errors in the data being fed to the DACs (again, I'm assuming one processor is doing both jobs and being scheduled by the kernel). But these would probably be random and hence appear as mere noise, and not very much.

FYI, my CDs are all ripped as FLAC; I'm not rushing off to do the WAV-FLAC comparison; and my system is about as tweak-free as it could be.

[rgheck]

Hi all,

let me contribute two observations to this interesting discussion

1. Streaming any flac file as pcm (wav) results in a higher volume level than streaming the same file in flac natively (even visible in a wider range of the movement of the pointers of the transporter's analogue VU-Meter, of which I thought, this display was only a nice gimmick). Could be a hint that the wohle phenomenon could have to do with gain (?).

2. Today I streamed a flac file (first movement of the symphony No 5 by Ralph Vaughan-Williams) natively and the transporter displayed as bitrate; "532 kb/s VBR".
When streaming the same file as pcm the display showed: "532 kb/s VBR (converted to 1411 kb/s ABR)".

So me too, I prefer to set the squeezeserver to convert flac to pcm and enjoy the result - despite of it is a placebo effect or not.

Cheers
ilbravo

On (1), are you using some sort of replay gain? If so, then of course that will make a very big difference.

(2) is expected, of course. The Transporter is telling you what's been done on the server.

Finally, as you mention, of course changing the server setting can change the way it sounds to you. If so, then so. Each of us should set it how it sounds, to us, the best.

[deadushka]

It doesn't bother me. I use an external DAC on my SB3. So as you see, I'm not entirely happy with my Squeezebox's sound. I am happy with the DAC in tow.
Chris:)

Try to change your SB3 for a receiver or a Transporter and you'll see what you actually listening to. A DAC doesn't have a major impact, it's just a link in the chain.

[rgheck]

Try to change your SB3 for a receiver or a Transporter and you'll see what you actually listening to. A DAC doesn't have a major impact, it's just a link in the chain.

Well, for what it's worth, I use external DACs with both of my Transporters, and they make a huge difference in the one case and a large difference in the other. And trust me: I'd have been perfectly happy with just the one piece of equipment if the DACs didn't make a significant difference to the sound. But they do.

[deadushka]

So, unless someone provides some *measured* proof of such an impact, I guess we have to look somewhere else for an -eventual- sonic difference explanation. :)

In what units are you going to measure music - volts and amps or 0/1? The results of any measurement is only vaguely related to the quality of the sound, IMHO.

[Stratmangler]

Try to change your SB3 for a receiver or a Transporter and you'll see what you actually listening to. A DAC doesn't have a major impact, it's just a link in the chain.

This chap uses the same DAC as I do. Read the link then repeat your statement with a straight face if you can !

http://theartofsound.net/forum/showpost.php?p=62300&postcount=245

Chris:D :D :D

PS - my tongue is firmly in cheek with this reply - there is no element of personal attack in my response.

[deadushka]

Well, for what it's worth, I use external DACs with both of my Transporters, and they make a huge difference in the one case and a large difference in the other. And trust me: I'd have been perfectly happy with just the one piece of equipment if the DACs didn't make a significant difference to the sound. But they do.

All I was trying to say is that if you change the Transporter for SB3 in your chain Transporter --> Pass Labs D1 --> Pass Labs Aleph 2s --> Thiel CS 1.6s you will surely notice the difference. Although in theory there should be none.

[deadushka]

This chap uses the same DAC as I do. Read the link then repeat your statement with a straight face if you can !

http://theartofsound.net/forum/showpost.php?p=62300&postcount=245

Chris:D :D :D

PS - my tongue is firmly in cheek with this reply - there is no element of personal attack in my response.

Again, sorry for partial cut'n'paste:

All I was trying to say is that if you change the SB3 for a Duet receiver in your chain you will surely notice the difference. Although in theory there should be none.

[Stratmangler]

Again, sorry for partial cut'n'paste:

All I was trying to say is that if you change the SB3 for a Duet receiver in your chain you will surely notice the difference. Although in theory there should be none.

No worries :D

I can't test your theory as I only have SB3 to play with.
It would be interesting to compare the different models via an external DAC.
And you're correct - they should all sound the same, as long as you limit the test to files that all of the players can natively cope with (ie. 24/48 files or less).

Chris:)

[rgheck]

All I was trying to say is that if you change the SB3 for a Duet receiver in your chain you will surely notice the difference. Although in theory there should be none.




I can't test your theory as I only have SB3 to play with.
It would be interesting to compare the different models via an external DAC.
And you're correct - they should all sound the same, as long as you limit the test to files that all of the players can natively cope with (ie. 24/48 files or less).

Why should there be no difference in theory? And why should they sound the same? Jitter is a real and measurable phenomenon, and its effects are well documented. It would be utterly unsurprising if the digital outputs of the various models had different jitter characteristics.

In any event, I've compared the Receiver to the Transporter, both feeding an external DAC. (I can't remember if it was the Pass Labs D1 or the Adcom GDA-600, at the time.) The difference was pretty obvious. And frankly, I was pretty bummed out. I was hoping to get away cheap in my second system. But I had to shell out for a second Transporter, instead.

[Themis]

Well, that would be the kind of information that was clearly relevant here. As I said, I do not know about the design.

That said, How much memory is there in a Receiver? Enough to buffer the whole song? And store the FLAC itself? I rather suspect, though of course I could be wrong, that the FLAC is being streamed and conversion is being done on the fly. Still, as you say, it may well be that there's not enough (additional) activity plausibly to make a difference, though that's hard to say for sure. If the conversion process is consuming CPU cycles, maybe it could occasionally be consuming them at just the wrong moment, with the result that you get timing errors in the data being fed to the DACs (again, I'm assuming one processor is doing both jobs and being scheduled by the kernel). But these would probably be random and hence appear as mere noise, and not very much.

FYI, my CDs are all ripped as FLAC; I'm not rushing off to do the WAV-FLAC comparison; and my system is about as tweak-free as it could be.
Well, as you say, the FLAC is streamed and conversion is on-the-fly.
There's a possibility that there's a slight peak "at the wrong moment", but, I doubt (as you also agree) that this could possibly do something more than any other CPU activity, or a slight noise if you prefer.
In other words, this should cause no more problem than -for instance- paging through the library.

Out of topic, I'm amazed that nobody has come to say that browsing degrades signal... :D

[Themis]

In what units are you going to measure music - volts and amps or 0/1? The results of any measurement is only vaguely related to the quality of the sound, IMHO.
I was talking about measuring the impact of the CPU activity during FLAC streaming compared to PCM streaming.
Well, if it makes a difference, then it's distortion and it's easily measurable. ;)

[Themis]

why should there be no difference in theory? And why should they sound the same? Jitter is a real and measurable phenomenon, and its effects are well documented. It would be utterly unsurprising if the digital outputs of the various models had different jitter characteristics.

In any event, i've compared the receiver to the transporter, both feeding an external dac. (i can't remember if it was the pass labs d1 or the adcom gda-600, at the time.) the difference was pretty obvious. And frankly, i was pretty bummed out. I was hoping to get away cheap in my second system. But i had to shell out for a second transporter, instead.
+1

[deadushka]

Why should there be no difference in theory? And why should they sound the same? Jitter is a real and measurable phenomenon, and its effects are well documented. It would be utterly unsurprising if the digital outputs of the various models had different jitter characteristics.

In any event, I've compared the Receiver to the Transporter, both feeding an external DAC. (I can't remember if it was the Pass Labs D1 or the Adcom GDA-600, at the time.) The difference was pretty obvious. And frankly, I was pretty bummed out. I was hoping to get away cheap in my second system. But I had to shell out for a second Transporter, instead.

Right. That's what I was talking about. If you listen to SB3, Duet and Transporter through one and the same DAC the sound differs greatly. And it's not just jitter related. Difference is too great to blame jitter for that. But in theory the digital out of all three players should be the same. So I think (maybe I'm wrong, but it will take an engineer who designed these players to prove it) some additional processing is carried out inside these players, it's not just pass through. Or the analogue part of the players is at work at some stage and this seems to me a more plausible explanation than jitter related problems.

I've only tested SB and Duet digital out on the same setup. And difference is "night and day". This doesn't require any special knowledge and anyone who is not completely deaf can carry out this simple test. But unfortunately many people rely on somebody else's opinion, which seems to be a rule in the Internet these days.

I myself wanted "to get away cheap" but I'm saving money for Transporter.

[rgheck]

All I was trying to say is that if you change the Transporter for SB3 in your chain Transporter --> Pass Labs D1 --> Pass Labs Aleph 2s --> Thiel CS 1.6s you will surely notice the difference. Although in theory there should be none.


And I'm still wondering why "in theory there should be none". Unless the D1 is immune to jitter, which it is not, there may well be an effect, which theory can perfectly well describe and explain.

[Robin Bowes]

On 02/01/10 17:26, rgheck wrote:
>
> Why should there be no difference in theory? And why should they sound
> the same? Jitter is a real and measurable phenomenon, and its effects
> are well documented.

Yes, it is well-documented that the level of jitter that is audible is
orders of magnitude *above* the measurable jitter level produced by most
digital devices.

R.

[rgheck]

Right. That's what I was talking about. If you listen to SB3, Duet and Transporter through one and the same DAC the sound differs greatly. And it's not just jitter related. Difference is too great to blame jitter for that. But in theory the digital out of all three players should be the same. So I think (maybe I'm wrong, but it will take an engineer who designed these players to prove it) some additional processing is carried out inside these players, it's not just pass through. Or the analogue part of the players is at work at some stage and this seems to me a more plausible explanation than jitter related problems.

I've only tested SB and Duet digital out on the same setup. And difference is "night and day". This doesn't require any special knowledge and anyone who is not completely deaf can carry out this simple test. But unfortunately many people rely on somebody else's opinion, which seems to be a rule in the Internet these days.

I myself wanted "to get away cheap" but I'm saving money for Transporter.

Only the designers could tell us for sure, but I think it is very, very unlikely that either (a) there is digital signal processing going on in the boxes (assuming we have replay gain, etc, turned off) or (b) that the analog circuitry is somehow involved.

More importantly, though, I don't see any reason to claim a priori that "it's not just jitter related". Jitter can cause quite enormous differences, especially if it is signal correlated and not just random. I've listened to analog recordings of digital signals where jitter had purposely been introduced, and it is not the sort of thing one can easily miss. If you listen to a few different transports, too, you can easily learn what kind of distortion jitter can cause. Try hooking up a cheap DVD player to whatever DAC you use and get ready to scream.

These discussions:
http://www.thewelltemperedcomputer.com/KB/BitPerfectJitter.htm
http://www.tnt-audio.com/clinica/diginterf1_e.html
http://www.digido.com/jitter.html
are pretty good.

[rgheck]

Actually, let me add one more thing. In some ways, the most astonishing way to see the effects of jitter is on CDR copies of CDs, made at different speeds. Until I got my Transporter, etc, I hoarded old Plextor CDR drives, which I used to make 1X copies of CDs. The differences between 1X, 4X, and 16X copies were readily apparent---the 16X usually sounded closest to the original, with the others sounding progressively better---as were the differences between copies made on the Plextor drives and copies made on DVD writers. It all sounds insane, but it is just due to the different levels of jitter in the signal written to the CD, which then appears at the input of the DAC.

[rgheck]

On 02/01/10 17:26, rgheck wrote:
>
> Why should there be no difference in theory? And why should they sound
> the same? Jitter is a real and measurable phenomenon, and its effects
> are well documented.

Yes, it is well-documented that the level of jitter that is audible is
orders of magnitude *above* the measurable jitter level produced by most
digital devices.

R.

It is controversial at what level jitter becomes audible. Some people thinks it takes a ton. Others disagree.

[DCtoDaylight]

But in theory the digital out of all three players should be the same. So I think (maybe I'm wrong, but it will take an engineer who designed these players to prove it) some additional processing is carried out inside these players, it's not just pass through.

But this has been questioned and proved false many many times.... Things like HDCD, which has control signals buried in the dithered noise floor, WILL NOT WORK if any additional signal processing been done. The fact that they do work proves there hasn't been any additional processing done....

[Robin Bowes]

On 02/01/10 22:48, rgheck wrote:
>
> It is controversial at what level jitter becomes audible. Some people
> thinks it takes a ton. Others disagree.
>

That's a rather different position to:

"Jitter is a real and measurable phenomenon, and its effects
are well documented."

....don't you think?

R.