PDA

View Full Version : Sound quality between wav and flac



Pages : 1 [2]

Robin Bowes
2010-01-02, 18:28
On 02/01/10 22:38, rgheck wrote:
>
> 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.

Aha! Proof that you really don't know what you're talking about.

I suggest you go and read up on what jitter actually is, and then use
your new-found knowledge to understand why the above-quoted paragraph is
just plain wrong.

R.

rgheck
2010-01-02, 20:56
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.

No, I don't. The statement, "P, but some people don't believe that P, despite the strong evidence in favor of P", is not remotely contradictory. That I didn't previously mention that some people, such as yourself, don't agree with my position and that of many other people who have investigated the matter, was the omission I meant to rectify. But then, there are many people who do not believe in evolution, contemporary cosmology, or who knows what else. Shocking, I know, but true. So I don't always feel the need to mention such outliers.

If you don't understand this, perhaps you should take a course in basic logic, such as Brown's Philosophy 0540.

rgheck
2010-01-02, 21:03
On 02/01/10 22:38, rgheck wrote:
>
> 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.

Aha! Proof that you really don't know what you're talking about.

I suggest you go and read up on what jitter actually is, and then use
your new-found knowledge to understand why the above-quoted paragraph is
just plain wrong.

I have, very recently, read a good deal on the subject, and apparently know a lot more about it than you do. (Get a clue, dude: Sony cares a LOT about this sort of thing.) But since you are obviously nothing but a troll who is too much of a coward even to register for the site, I don't care to discuss this with you any further.

Too bad forums don't have .kill files.

Phil Leigh
2010-01-03, 01:53
...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.

Oh dear. This is just incorrect. What you are actually experiencing is the varying ability of a CD player to accurately retrieve and replay information from disks that were written under different circumstances. This has nothing to do with jitter "written to the CD", as there is no clock on a CD. Jitter in the dac might be caused by noise on the psu lines affecting the clock quality as the servos struggle to track the disk pit/land transitions.
However, this jitter is not burned into the disk.

Robin Bowes
2010-01-03, 03:48
On 03/01/10 04:03, rgheck wrote:
>
> Robin Bowes;501888 Wrote:
>> Aha! Proof that you really don't know what you're talking about.
>>
>> I suggest you go and read up on what jitter actually is, and then use
>> your new-found knowledge to understand why the above-quoted paragraph
>> is
>> just plain wrong.
>
> I have, very recently, read a good deal on the subject, and apparently
> know a lot more about it than you do. (Get a clue, dude: Sony cares a
> LOT about this sort of thing.)

Then I suggest you hone your reading skills.

As Phil Leigh has also pointed out, "jitter" is not burned to disk. The
fact that you suggest the contrary is clear evidence that you don't
really understand what jitter is.

> But since you are obviously nothing but a
> troll who is too much of a coward even to register for the site, I don't
> care to discuss this with you any further.

Dude, I am user #480 [1], joined on 5/5/2005. How 'bout you?

However, I read/post to the forum via the mailing list which is why I
show up as "guest".

R.

[1] http://forums.slimdevices.com/member.php?u=480

Themis
2010-01-03, 03:53
Oh dear. This is just incorrect. What you are actually experiencing is the varying ability of a CD player to accurately retrieve and replay information from disks that were written under different circumstances. This has nothing to do with jitter "written to the CD", as there is no clock on a CD. Jitter in the dac might be caused by noise on the psu lines affecting the clock quality as the servos struggle to track the disk pit/land transitions.
However, this jitter is not burned into the disk.
Perhaps he means disk burst read errors.

Phil Leigh
2010-01-03, 03:55
Perhaps he means disk burst read errors.

I was thinking of "seek jitter"...?

Themis
2010-01-03, 04:10
I was thinking of "seek jitter"...?
Yes. Iwasn't aware that someone had put the word "jitter" on it...

Phil Leigh
2010-01-03, 04:15
Yes. Iwasn't aware that someone had put the word "jitter" on it...

:-) I think you can put the word "jitter" after anything...

Returning to the topic of this thread, as my measuring rig is broken until tomorrow (hopefully), I've been doing some listening tests (with the Touch via spdif) and still can't hear anything different when streaming flac vs wav. I've had a week away from my system so I thought returning to it cold might give me a new baseline but apparently not.

Patrick Dixon
2010-01-03, 05:32
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.

Maybe that's true for 'random' jitter, but in the real world jitter is seldom random and it's spectral content is likely to have an effect on its audibility, just as much as its absolute amplitude.

Jitter is just another form of distortion, and as with distortion, the character of the jitter is an important element in its audible effect.

Phil Leigh
2010-01-03, 05:51
Maybe that's true for 'random' jitter, but in the real world jitter is seldom random and it's spectral content is likely to have an effect on its audibility, just as much as its absolute amplitude.

Jitter is just another form of distortion, and as with distortion, the character of the jitter is an important element in its audible effect.

I'm still trying to get my head round the idea that correlated jitter might be consistently different when playing flac vs wav. The more I think about it the less sense the "cpu working harder=more noise=more jitter" theory makes to me.

Surely this would be measurable using a jitter analyser?

DCtoDaylight
2010-01-03, 07:33
The more I think about it the less sense the "cpu working harder=more noise=more jitter" theory makes to me.

Surely this would be measurable using a jitter analyser?

The mechanism would be noise on the power supply internal to the FPGA. Variations of supply voltage do affect gate timing, and we have to allow for this when designing chips. If I recall Sean's description of the touch's spdif circuitry correctly though, there's a retiming flop, external to the FPGA isn't there? It would greatly reduce, if not eliminate, this source of jitter.

And yes, there's no reason that this can't be measured and put to bed!

Phil Leigh
2010-01-03, 07:56
The mechanism would be noise on the power supply internal to the FPGA. Variations of supply voltage do affect gate timing, and we have to allow for this when designing chips. If I recall Sean's description of the touch's spdif circuitry correctly though, there's a retiming flop, external to the FPGA isn't there? It would greatly reduce, if not eliminate, this source of jitter.

And yes, there's no reason that this can't be measured and put to bed!

ah - I see... internal to the FPGA - good point. Thanks, DC.
That would difficult to measure directly?
I think John Swenson mentioned something about that FLOP... I'll have to look back at his posts!

rgheck
2010-01-03, 08:55
Oh dear. This is just incorrect. What you are actually experiencing is the varying ability of a CD player to accurately retrieve and replay information from disks that were written under different circumstances. This has nothing to do with jitter "written to the CD", as there is no clock on a CD. Jitter in the dac might be caused by noise on the psu lines affecting the clock quality as the servos struggle to track the disk pit/land transitions.
However, this jitter is not burned into the disk.

Sorry, I mis-spoke. What I should have said was, "It all sounds insane, but it is just due to the different levels of jitter that appear at the DAC depending upon features of the data written to the CD that have nothing to do with which bits are recovered. One might somewhat inaccurately refer to this as 'jitter written to the CD'."

That said, is it not true that the electrical signal emerging from the disk reader will depend upon the precise locations of the pit-land transitions in ways that do not affect the digital data? I.e., vary in where precisely the zero-crossings occur? I know that FIFO buffers are often used in an attempt to nullify this *sort* of thing, but it seems to be widely agreed that the simplest forms of such things don't succeed, for reasons that aren't so well understood.

rgheck
2010-01-03, 08:57
Ba 03/01/10 04:03, eturpx jebgr:
>
> Ebova Objrf;501888 Jebgr:
>> Nun! Cebbs gung lbh ernyyl qba'g xabj jung lbh'er gnyxvat nobhg.
>>
>> V fhttrfg lbh tb naq ernq hc ba jung wvggre npghnyyl vf, naq gura hfr
>> lbhe arj-sbhaq xabjyrqtr gb haqrefgnaq jul gur nobir-dhbgrq cnentencu
>> vf
>> whfg cynva jebat.
>
> V unir, irel erpragyl, ernq n tbbq qrny ba gur fhowrpg, naq nccneragyl
> xabj n ybg zber nobhg vg guna lbh qb. (Trg n pyhr, qhqr: Fbal pnerf n
> YBG nobhg guvf fbeg bs guvat.)

Gura V fhttrfg lbh ubar lbhe ernqvat fxvyyf.

Nf Cuvy Yrvtu unf nyfb cbvagrq bhg, "wvggre" vf abg ohearq gb qvfx. Gur
snpg gung lbh fhttrfg gur pbagenel vf pyrne rivqrapr gung lbh qba'g
ernyyl haqrefgnaq jung wvggre vf.

> Ohg fvapr lbh ner boivbhfyl abguvat ohg n
> gebyy jub vf gbb zhpu bs n pbjneq rira gb ertvfgre sbe gur fvgr, V qba'g
> pner gb qvfphff guvf jvgu lbh nal shegure.

Qhqr, V nz hfre #480 [1], wbvarq ba 5/5/2005. Ubj 'obhg lbh?

Ubjrire, V ernq/cbfg gb gur sbehz ivn gur znvyvat yvfg juvpu vf jul V
fubj hc nf "thrfg".

E.


Sorry, I don't speak Troll.

rgheck
2010-01-03, 09:02
Maybe that's true for 'random' jitter, but in the real world jitter is seldom random and it's spectral content is likely to have an effect on its audibility, just as much as its absolute amplitude.

Jitter is just another form of distortion, and as with distortion, the character of the jitter is an important element in its audible effect.

The main problem with most studies I've seen of this is that they use a pure test tone (17kHz, in one widely quoted study, for example), and see if people can detect the presence of jitter in that signal. And then, when people can't, they conclude that jitter is inaudible. This is very strange methodology. Similar tests long ago showed that nothing matters except THD.

rgheck
2010-01-03, 09:07
And yes, there's no reason that this can't be measured and put to bed!

It would be nice to see those measurements, though, personally, I'm not holding my breath and don't suspect it matters where the FLAC->WAV conversion is done. My only point was that it isn't completely inconceivable that there should be some such effect---where I was assuming, of course, that jitter is audible, etc.

Robin Bowes
2010-01-03, 09:08
On 03/01/10 15:57, rgheck wrote:
>
> Sorry, I don't speak Troll.

....or sense, it would seem.

Bury your head in the sand and change your story all you like.

You're wrong, mate.

R.

DCtoDaylight
2010-01-03, 16:03
the electrical signal emerging from the disk reader will depend upon the precise locations of the pit-land transitions in ways that do not affect the digital data? I.e., vary in where precisely the zero-crossings occur? I know that FIFO buffers are often used in an attempt to nullify this *sort* of thing, but it seems to be widely agreed that the simplest forms of such things don't succeed, for reasons that aren't so well understood.

Yes, the exact timing of the pit-land transitions may vary, but it's totally irrelevant. Many people persist in thinking that data is read off a CD like a record, where timing matters, but it doesn't work that way. Data is read off in a block, with left and right channels happening sequentially. They're processed through the error detection/correction circuitry, where the data is filled into a table, and check sums are calculated both vertically and horizontally. Once the data has been checked for errors (and corrected if required), it's then loaded into a FIFO buffer, and clocked out to oversampling filter and DAC. The data coming off the disc, and that being sent to the DAC are totally isolated by asynchronous interfaces. Jitter on the disc can't make it to the outside world, until it's large enough to be causing uncorrectable bit errors....

DCtoDaylight
2010-01-03, 16:10
It would be nice to see those measurements, though, personally, I'm not holding my breath and don't suspect it matters where the FLAC->WAV conversion is done. My only point was that it isn't completely inconceivable that there should be some such effect---where I was assuming, of course, that jitter is audible, etc.

I agree it's conceivable, but have no idea if the jitter would be data correlated, or not (which affects it's audibility).

As for measuring it, it would be interesting to measure at the output of the FPGA, and again at the output of the re-timing flop. Both measurements would be difficult though, as attaching the scope probes to these points will affect their loading, often increasing the noise & jitter. I work with guy's who design and build telecom fibre optic gear, measuring some of this stuff is really tough...

Phil Leigh
2010-01-03, 16:17
... Jitter on the disc can't make it to the outside world, until it's large enough to be causing uncorrectable bit errors....

Which you will hear as clicking noises as samples are dropped/doubled...

garym
2010-01-03, 16:18
Uh-oh. The measurement act itself can change the thing we are interested in measuring. Now we are entering the world of the Heisenberg uncertainty principle. Interesting discussion guys. I'm pleased that you keep folks in this thread grounded to reality a bit whenever it drifts off into subjective impressions. Although nothing wrong with subjective impressions (otherwise my wife would have never married me....)

JohnSwenson
2010-01-03, 16:33
If you look earlier in this thread I used a spectrum analyzer to measure the clock going into the DAC chip on a Touch. This doesn't directly measure the jitter, it measures the sidebands caused by the jitter. I could not discern any difference between decoding PCM or FLAC in the Touch. This jitter on this clock was so low the sidebands were below the noise floor of the spectrum analyzer. There might be differences in the sidebands, but the tool I have is not sufficient to measure it. There are tools that are better than this and might be better able to see it but they are VERY expensive and WAY WAY outside of what I can afford! (this was a 30K analyzer that I found used on ebay for $900, its rather rare to find 100K ones like that!)

And yes there is a reclocking flop for the clock that goes into the DAC and and a flop for the S/PDIF stream. I was measuring the DAC clock after the reclocking flop.

I think its interesting to note that I DID see significant sidebands on the DAC clock when the headphones were plugged in, which does seem to show that different electrical loads on the board CAN affect the jitter of the clock.

John S.

deadushka
2010-01-03, 17:02
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....

It was just my guess about additional processing. If there is none I'm still curious about the differences in sound of SB and Duet. As I understand jitter affects soundstage, focusing of stereo image and things like that (minor things IMHO). But why this two machines sounds totally different through DAC.

Does anybody here know how jitter actually demonstrates itself in a recording of a reasonable quality?

DCtoDaylight
2010-01-03, 17:28
Which you will hear as clicking noises as samples are dropped/doubled...

Not necessarily... it depends on how much data is lost. A period of single bit errors might only result in a temporary increase in noise & distortion. Perhaps enough to be subconsciously heard as worse sounding, without obviously being dropped samples.

Some very early CD players had error lights on them, which flashed when an uncorrectable error was detected. This feature was discarded almost immediately, as there were too many customer complaints that the error light was always flashing! Ignorance is bliss! I don't believe modern CD players suffer nearly as much from this, but it would be fairly easy to test. Record the spdif stream a few times, and run them through Audio Diff Maker. You could compare the original CD with ripped and burned copies on different media, or compare different CD players this way.

marcoc1712
2010-01-04, 05:30
Hi All,

i'm back from a W.E. spent with my family, not flyng Kite but Hill Walking on the snow, hope is the same for you ... :-).

Wow, lot of people now in this Thread! I think you are moving far too deep in techical matter for me, but is Ok, I'll keep on reading, may be I could learn something.

What sound strange to me is that we need to debate about the possibility that different transport sound different via the same DAC. They do, If not, why should we have so many company selling transports (and different models of them) on the market?

It's an easy test, just plug different transports to your dac and listen...

I did it (CD Players, DVD Player, SB Receiver and SB+) and for sure I could ear differences, if you don't, forget about the one I reported between FLAC and WAV.

I don't know why TRPs sound different, but what I know for sure is that - at least in my system - they do.

I also noticied that the more you take care to insulate them from power line noise and vibrations, the 'open' is the sound you have in output, cheaper equipement normaly change in greater way (SB+ less than receiver, for instance), and also cable (DIG ONE) plays his role.

I did not try with headphones, as John said, but in my experience is better to unplug the Analog OUT of the TRP when you are listening throu the SPDIF.

Some tech people says this is not just becouse the electrical charge, but also becouse the cables could operate as an 'antenna' for RFI/EMI, I'm only reporting this, I'll never sign it for sure!

Could all of the above be refletced in Jitter?

In previous posts someone reported the same I've noticied myself:

When playng FLAC converted to PCM, SB reports XXX VBR converted to 1411.2 Kbps ABR instead of 1411 CBR (WAV PCM).

Why "Average" and not "Constant" bitrate? Are they exactly the same so far as SB is involved?

Thanks to all and a special one to Phill who wanted to try once more and he could still not ear any difference, whe are here with the original pool:

The majority of us could not ear any difference.

Some of Us (at least me, John and deadushka) could ear differences between WAV/PCM and FLAC/FLAC stream of the same music.

I'm still the only one (and probably I'm wrong!) who could ear differences between WAV/PCM and FLAC/PCM stream of the same music.

Regards.

Marco

pfarrell
2010-01-04, 11:25
marcoc1712 wrote:
> What sound strange to me is that we need to debate about the
> possibility that different transport sound different via the same DAC.
> They do, If not, why should we have so many company selling transports
> (and different models of them) on the market?

Because we are a capitalistic economy, and they sell to folks with money
to burn.

Most of the transports use the same $10 reader that is sold in the
hundreds of millions for PCs. The economies of scale essentially require
that. Engineering the speed and track following logic is non-trivial,
and you can buy it for pennies.

> I did it (CD Players, DVD Player, SB Receiver and SB+) and for sure I
> could ear differences, if you don't, forget about the one I reported
> between FLAC and WAV.


There is more to this. Assorted things we think of as "transports" are
doing more than just reading the bits and stuffing them out the S/PDIF
port. Oversampling, upsampling, filters, who knows.


> Could all of the above be refletced in Jitter?

I think jitter is an excuse for the vendors to claim that their products
are better. i.e. pure marketing hype.



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

DCtoDaylight
2010-01-04, 17:02
I think jitter is an excuse for the vendors to claim that their products
are better. i.e. pure marketing hype.

I think the big problem is that the term jitter has been miss-used so much, that it has lost much credibility. I've seen -speaker cables- marketed as being low jitter!

pfarrell
2010-01-04, 17:11
DCtoDaylight wrote:
> pfarrell;502588 Wrote:
>> I think jitter is an excuse for the vendors to claim that their
>> products are better. i.e. pure marketing hype.
>
> I think the big problem is that the term jitter has been miss-used so
> much, that it has lost much credibility. I've seen -speaker cables-
> marketed as being low jitter!

Which proves my point.

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

NewBuyer
2010-01-05, 20:59
I think the big problem is that the term jitter has been miss-used so much, that it has lost much credibility. I've seen -speaker cables- marketed as being low jitter!

Well we should all probably be using those instead then, for S/PDIF... :)

Daverz
2010-01-08, 23:04
I think it's a failure of the industry that jitter from the transport is still an issue. Perhaps it's a failure that many benefit from (sort of like a certain operating system and anti-virus software).

Asynchronous USB sounds like a promising solution. It has to be licensed, which may reduce it's popularity, though.

Themis
2010-01-09, 16:36
It has to be licensed, which may reduce it's popularity, though.Why so ? Asynchronous Isochronous is part of the USB specification. ;)

Daverz
2010-01-09, 23:24
Why so ? Asynchronous Isochronous is part of the USB specification. ;)

I guess I must be thinking of a particular implementation.

Stratmangler
2010-03-12, 06:53
I was intrigued by this notion of there being an audible difference between FLAC and WAV files, so I have conducted a little experiment of my own.

I ripped just one track of a CD.
To make it a bit more all encompassing I decided to rip to 2 lossless uncompressed formats and 2 lossless compressed formats.
These formats are WAV, AIFF, ALAC & FLAC respectively.
All tracks were ripped with the same ripping tool (dbPoweramp), and all tracks were ripped securely on first pass and returned identical AccurateRip results. Indeed, the checksums for all of the rips were identical.

I then copied the file over into My Music on my system, and adjusted the value of WAV playback to native in my Squeezebox Server client - all the other formats were already set as native, so no need to adjust anything.

Then I sought out the folder with the four rips and had a listen.
I used my laptop to control the playback and view the gui interface remotely, and I had no indication as to which track was which in terms of playback.
And I can't hear any bloody difference between any of them !

Which leads me to a number of possible conclusions.

Either there are no audible differences or my system does not resolve highly enough to make the differences audible or my hearing is shot, or maybe any combination of the previous options apply.

YMMV

Chris :)

Themis
2010-03-12, 07:05
Chris, very few people claim to hear any differences, and the test procedures used are often far from ideal, I'm afraid.

So, the most probable conclusion, afaik, is that there are no audible differences.

wtnh
2010-03-16, 07:33
I have had an SB3 for 5+ years. It feeds into a passive preamp (Alps attenuator) and a McCormack DNA .5 amp, driving a pair of Martin Logan Aerius i's. Pretty mimimal signal path. The MLs, like most electrostatics, are very revealing and unforgiving when it comes to bad source material.

Anyway, I have long thought that the SB3 sounded slightly better at decoding WAV streams (I am using it wirelessly) than FLAC. I never worried about it too much - just set the server to transcode and forgot about it.

Then two things occured at roughly the same time: I upgraded to Squeezebox Server 7.4.1 (running on Windows Server 2003) and ripped the entire new Beatles box set to FLAC. I did not change the default transcode settings.

It sounded really bad. It's as if there was some sort of digital grunge on many tracks. It hurt my ears. Very similar in sound to the early days of CD players with lousy DACs.

Initially, I thought I had created bad FLAC files, since I had just recently upgraded the pc I use for ripping to Windows 7 64 bit and re-installed EAC. But then I did a bulk conversion of my FLAC files to high bitrate MP3s and they sounded fine on my iPod Touch with Sennheiser earphones.

So I started looking at the trascode settings on the server (which frankly I found confusing in 7.4.1). I disabled FLAC native and WAV to FLAC transcoding.

Problem solved!

Now to be honest, I did not even attempt any blind or AB testing and I will admit that psychoacoustics is full of subjective interpretation. But my wife and I attend lots of live symphonic music events (we are long-time season ticket holders to the BSO) and I will always prefer live music to mechanically reproduced stuff. So I am a critical listener and feel comfortable in saying that there was a noticeable difference.

FWIW - the only thing I can think of is that there is some sort of error in the SB3 FLAC decoder firmware and that it grew even worse with 7.4.1 - which confirms why some posters may prefer the sound of 7.2 when using FLAC.

JJZolx
2010-03-16, 07:50
Anyway, I have long thought that the SB3 sounded slightly better at decoding WAV streams (I am using it wirelessly) than FLAC. I never worried about it too much - just set the server to transcode and forgot about it.

OK, so you _were_ transcoding FLAC to PCM and streaming the PCM, right?


Then two things occured at roughly the same time: I upgraded to Squeezebox Server 7.4.1 (running on Windows Server 2003) and ripped the entire new Beatles box set to FLAC. I did not change the default transcode settings.

You did not change the _default_ settings or you did not change your _previous _settings? Did you do a completely fresh install and lose all of your old settings, or did you upgrade and keep the old setings?


So I started looking at the trascode settings on the server (which frankly I found confusing in 7.4.1). I disabled FLAC native and WAV to FLAC transcoding.

You said you had already disabled FLAC native (unless you lost the previous setting). The WAV to FLAC transcoding doesn't enter the picture unless you're playing WAV files.

It's not at all clear what you're comparing.

Phil Leigh
2010-03-16, 08:39
So, your settings look like this now?

Phil Leigh
2010-03-16, 08:47
FWIW - the only thing I can think of is that there is some sort of error in the SB3 FLAC decoder firmware and that it grew even worse with 7.4.1 - which confirms why some posters may prefer the sound of 7.2 when using FLAC.

That's simply impossible. The FLAC decoder (whether on the server or in the firmware) will either work 100% perfectly or not at all. Its code can't introduce subtle or even serious degradations in audio quality.
Whatever the explanation is, it can't be that.

wtnh
2010-03-16, 08:52
Correct - plus setting WAV > FLAC > Disabled.

To answer the previous post - yes, with 7.2 and previous versions, I was trasnscoding FLAC to PCM (actually I think the setting was WAV back then).

I did a fresh install of 7.4.2 and lost my old settings (and I did not bother to check them).

Current settings:

Phil Leigh
2010-03-16, 08:59
The wav setting would only impact any wav rips you have...

Phil Leigh
2010-03-16, 09:00
What do you use for ripping? do you go straight to flac?

wtnh
2010-03-16, 09:09
Ripping on a HP PC with a Xeon processor running Windows 7 64 bit. Using the latest download of EAC I could find (as of about 12/2009). Ripping straight to FLAC - pretty much the same process I have used for years.

I am tempted at this point to do some A/B with the CDs and the SB3 and FLAC/WAV.

Phil Leigh
2010-03-17, 10:23
Ripping on a HP PC with a Xeon processor running Windows 7 64 bit. Using the latest download of EAC I could find (as of about 12/2009). Ripping straight to FLAC - pretty much the same process I have used for years.

I am tempted at this point to do some A/B with the CDs and the SB3 and FLAC/WAV.

That would be helpful

firedog
2010-03-19, 00:29
A few points:

1. Some users with very good audio systems report 16/44 rips of CD that are upsampled, first to 24/44.1 and then to 96 (2 stage process) sound "better", e.g. more "space and air" between instruments. Both FLAC and WAV.

This is a matter of taste, but I think files upsampled this way do sound slightly different the one or two times I've tried it. And BTW, not all upsamplers are equal. Some do a better job than others, the differences can be heard.

2. In spite of the fact that FLAC files and WAV files can be shown to be mathematically the same after decompression, some users claim they sound different in actual playback. They think the difference comes from the fact that playback done with "on the fly" decompression may not work perfectly on some systems.

3. I personally have done A - B blind testing on good systems with experienced listeners. None of us could reliably differentiate FLAC and WAV files. This is in spite of the fact that we didn't think all files sounded identical. But if you can't reliably pick which file is which, probably the apparent differences are imaginary.

Phil Leigh
2010-03-19, 09:55
A few points:

1. Some users with very good audio systems report 16/44 rips of CD that are upsampled, first to 24/44.1 and then to 96 (2 stage process) sound "better", e.g. more "space and air" between instruments. Both FLAC and WAV.

They must have access to better drugs than I do. This 2-stage process is sheer nonsense. They clearly don't understand how computers or digital audio works...



This is a matter of taste, but I think files upsampled this way do sound slightly different the one or two times I've tried it. And BTW, not all upsamplers are equal. Some do a better job than others, the differences can be heard.

Upsampling + a suitable DAC can create an audible difference - no question. Mostly by allowing aliasing/filter artefacts and their intermodulated products to be moved out of harms way. But it is Very Subtle...



2. In spite of the fact that FLAC files and WAV files can be shown to be mathematically the same after decompression, some users claim they sound different in actual playback. They think the difference comes from the fact that playback done with "on the fly" decompression may not work perfectly on some systems.


"The Cuervo Gold, The fine Columbian..."

This is categorically not true of SB systems. Can't vouch for anything else...


3. I personally have done A - B blind testing on good systems with experienced listeners. None of us could reliably differentiate FLAC and WAV files. This is in spite of the fact that we didn't think all files sounded identical. But if you can't reliably pick which file is which, probably the apparent differences are imaginary.

[/QUOTE]
So have I.
There is NO difference. It's all in their minds. Fortunately, the ADM software doesn't lie and is completely repeatable, unlike our hearing and brains.

firedog
2010-03-23, 01:18
They must have access to better drugs than I do. This 2-stage process is sheer nonsense. They clearly don't understand how computers or digital audio works...


Correction: It turns out the people that use the 2 step process were referring to a specific program, Wave Editor, that they use for upsampling. They think the program has a superior upsampler to other programs, but that a "bug" results in the two step process giving better results than a one step process.

Phil Leigh
2010-03-23, 02:26
Correction: It turns out the people that use the 2 step process were referring to a specific program, Wave Editor, that they use for upsampling. They think the program has a superior upsampler to other programs, but that a "bug" results in the two step process giving better results than a one step process.

Ah - that makes more sense!

Erik L
2010-06-08, 13:44
When I bought my SqueezeBox Duet and hooked it up digitally connected to my DAC I was disappointed to find that the sound quality was not up to the standard I was used to with my Teac Esoteric DV-50 as a CD transport. And I just assumed that, OK, maybe one should not expect better performance from such a cheap device as the SB Duet.

But recently I happened to check the transmitted bitrate with Netpersec and relized that the SB server only sent data at a variable bitrate at around half the bitrate for wav. I then found through this thread how to change the settings so I got wav to be sent in its native format. Actually, I never expected much difference. Flac is lossless compression and many people seem not to be able to hear any difference between the settings. But to my big surprise the difference was very easy to hear. Now I got quite a bit more air, space and deeper soundstage. Comparing this with the Esoteric I found that the SB was now on par or even better than the Esoteric. I repeated the tests a number of times, and there was no question about it, when using the flac compression the sound got flatter and duller.

I do not know why the difference is so clearly audible in my system when others cannot distinguish one configuration from the other. I know that my DAC (the hand made Bremen Licence No. 1), although a great performer when fed a high quality signal, is very sensitive to cheap transports and poor digital cables, probably because it does not have any jitter reduction. (I really had problems with previous transports and cables than I have now.) Other DACs could be less senstive to a small difference in the signal. Another possibility could be if there are other bottle necks in the signal chain in a system obscuring the difference. My system is pretty good and I have tweaked it quite a bit to make it perform optimally, but then it is quite sensitive when introducing imperfections in the system.

Anyway, I am very grateful that I found the information in this thread how to change the settings. It made me quite a lot more satisfied with my SB Duet.

tonyptony
2010-06-08, 16:29
Erik, are you saying that you changed the settings to do server based decoding to WAV before sending to the SB?

Erik L
2010-06-08, 22:10
Erik, are you saying that you changed the settings to do server based decoding to WAV before sending to the SB?

I have not tried with letting the server decode flac to wav before transferring the data to the receiver. What I did was just to avoid that the server coded wav files into flac before sending them to the receiver. Now I have uncompressed data all the way.

Phil Leigh
2010-06-08, 23:57
I've done extensive listening and measurement tests of:
FLAC streamed as FLAC
FLAC streamed as WAV
WAV streamed as WAV
WAV streamed as FLAC

...and can find no measurable or audible difference. These tests were with an SB3 (2 different ones) and a Touch.

However, there is a theoretical possibility that client-side processing of FLAC MIGHT inject extra noise onto the spdif signal which MIGHT impact certain DAC's. This would certainly be player-specific and could not be taken as a general case conclusion such as "WAV always sounds different to FLAC".

I do not believe anyone has yet been able to actually measure this noise/jitter. I wish someone would...

I'm not disagreeing with Erik's findings, but I believe they may be specific to the Receiver and/or his DAC (or similar DAC's).

Themis
2010-06-27, 03:44
I've done extensive listening and measurement tests of:
FLAC streamed as FLAC
FLAC streamed as WAV
WAV streamed as WAV
WAV streamed as FLAC

...and can find no measurable or audible difference. These tests were with an SB3 (2 different ones) and a Touch.My own listening tests come to the same conclusion as Phil's ones.

Nevertheless, for various practical reasons (and also because my SB is wired) I do FLAC->PCM conversion on the server.

mswlogo
2010-06-29, 21:34
My own listening tests come to the same conclusion as Phil's ones.

Nevertheless, for various practical reasons (and also because my SB is wired) I do FLAC->PCM conversion on the server.

I used to that but doing Fast Forward, Rewind and Next Song etc. all were kindy herky jerky. With Flac it's nice and smooth. It may be improved now since I last tried it or with a beefier server. But I don't see any value in doing so.

Phil Leigh
2010-06-29, 22:47
Server-side FLAC-PCM also doesn't handle >24/96.
Some hacking of the custom_convert.conf file is required.
Has anyone got this working?

Themis
2010-07-02, 23:21
Server-side FLAC-PCM also doesn't handle >24/96.
Some hacking of the custom_convert.conf file is required.
Has anyone got this working?
It works for me on the 7.5.1 (required for Touch) without customizing the convert.conf

michael123
2010-07-02, 23:42
when you say PCM, is it same as WAV? Header-less WAVE?
If I customize SOX to send uncompressed WAV, is it equivalent to PCM?

Phil Leigh
2010-07-03, 00:26
It works for me on the 7.5.1 (required for Touch) without customizing the convert.conf

Interesting...
You are correct! - I had a corrupted convert.conf file (doh!)

Phil Leigh
2010-07-03, 00:29
when you say PCM, is it same as WAV? Header-less WAVE?
If I customize SOX to send uncompressed WAV, is it equivalent to PCM?

Yes - In audio data terms, PCM and WAV are equivalent. Slight differences in physical format.
SBS can't stream "WAV" - it streams PCM.

michael123
2010-07-03, 01:38
Yes - In audio data terms, PCM and WAV are equivalent. Slight differences in physical format.
SBS can't stream "WAV" - it streams PCM.

What about AIFF?
I can't get (at the moment) to stream PCM, but AIFF - easily.

TheRooster2000
2010-07-03, 02:28
It works for me on the 7.5.1 (required for Touch) without customizing the convert.conf

Hi!

How can this be configured from within SbS?
Under [Settings] -> [Advanced] -> [File Types] -> [FLAC] I have:
FLAC native
MP3 flac/lame
PCM flac

What do I have to change there if I want to stream FLAC as PCM?

Regards,
Christian

Phil Leigh
2010-07-03, 04:49
Hi!

How can this be configured from within SbS?
Under [Settings] -> [Advanced] -> [File Types] -> [FLAC] I have:
FLAC native
MP3 flac/lame
PCM flac

What do I have to change there if I want to stream FLAC as PCM?

Regards,
Christian

set flac - native to disabled

TheRooster2000
2010-07-03, 04:56
Okay, thanks for your advice!

I'll do some tests later when the weather gets a bit colder again.
31°C and rising here in Germany at the moment.
Not the best conditions for extensive listening tests ;)

Christian

Phil Leigh
2010-07-03, 05:28
Okay, thanks for your advice!

I'll do some tests later when the weather gets a bit colder again.
31°C and rising here in Germany at the moment.
Not the best conditions for extensive listening tests ;)

Christian

Indeed :-)
30 here in southern UK - soon be football time... I am of course supporting Germany!

TheRooster2000
2010-07-03, 06:03
(...)I am of course supporting Germany!

Thanks very much! I think it's very helpful because it's against Argentinia today!
I have to go watching now. Kick-off soon! :)

Bye,
Christian

Themis
2010-07-04, 00:42
Thanks very much! I think it's very helpful because it's against Argentinia today!
I have to go watching now. Kick-off soon! :)

Bye,
Christian
A bit OOT, of course, but congrats for Germany. Nice football. :)

Louishlomador
2010-08-14, 13:44
Finally it seems squeezebox version 7.5 and 7.5.1 works perfectly with squeezebox classic. There is certainly a big massive improvement on the sound quality between other versions. 7.5 or 7.5.1 is the best i have ever heard my squeezbox play music in wave format though. I havent tried it in flac, dont see the need as storage mediums are becoming bigger and bigger. Slim devices have certainly got it right with these 2 versions. The sound is open, clarity is fantastic and spacious, especially the vocals. All the natural instruments just come clear and precise. Stereo imaging is brilliant. I will now certainly buy my the squeezebox touch. Good work slim/logitech.

I personally will not use Flac as i still can tell differences bewteen Flac and wave. There isn't even a camparism between Flac and Wave, on the official flac website. I just find that a bit strange. link below. Wavepack is not the same as wave. on the same website flac files are converted to wav as an approximation. Anyway, I'm happy with my wave playing and decoding well on SB3. Happy days.

http://flac.sourceforge.net/comparison.html

andynormancx
2010-08-15, 02:05
I personally will not use Flac as i still can tell differences bewteen Flac and wave. There isn't even a camparism between Flac and Wave, on the official flac website. I just find that a bit strange. link below. Wavepack is not the same as wave. on the same website flac files are converted to wav as an approximation.

http://flac.sourceforge.net/comparison.html

*sigh*

There is no comparison to WAV because that is a comparison of different lossless codecs to see how fast they operate and what file size reduction they manage. It is not a comparison to see how they sound compared to each other, as it is TRIVIALLY easy to check that they all decode to EXACTLY the same WAV data as they were supplied with to encode.

What do you mean by "on the same website flac files are converted to wav as an approximation" ???

TiredLegs
2010-08-16, 09:40
Finally it seems squeezebox version 7.5 and 7.5.1 works perfectly with squeezebox classic. There is certainly a big massive improvement on the sound quality between other versions. 7.5 or 7.5.1 is the best i have ever heard my squeezbox play music in wave format though.

*sigh*x2

If you check the complete list of changes in v7.5.0 from prior versions, there isn't anything that would affect Squeezebox Classic sound quality under normal operation. (See http://svn.slimdevices.com/repos/slim/7.5/tags/7.5.0/server/Changelog7.html)

Phil Leigh
2010-08-16, 11:22
*sigh*x2

If you check the complete list of changes in v7.5.0 from prior versions, there isn't anything that would affect Squeezebox Classic sound quality under normal operation. (See http://svn.slimdevices.com/repos/slim/7.5/tags/7.5.0/server/Changelog7.html)

+1 - sound quality is identical.

probedb
2010-08-17, 05:13
I personally will not use Flac as i still can tell differences bewteen Flac and wave. There isn't even a camparism between Flac and Wave, on the official flac website. I just find that a bit strange. link below. Wavepack is not the same as wave. on the same website flac files are converted to wav as an approximation. Anyway, I'm happy with my wave playing and decoding well on SB3. Happy days.

http://flac.sourceforge.net/comparison.html

Wow, just wow. What sort of comparison do you expect to see? It's LOSSLESS, do you not understand what that means?

Sigh....

m1abrams
2010-08-17, 07:03
I havent tried it in flac, dont see the need as storage mediums are becoming bigger and bigger.

How about a standard tag support? WAV format has no standard tag support.

Also bandwidth savings of FLAC.

As people have already jumped on you about the fact that FLAC has exactly the same quality as the WAV file. Of course their is no comparison on sound quality because that would be silly since they are exactly the same.

earwaxer9
2010-08-17, 15:49
I have some high res. flac downloads that sound great. I havent really compared CD res. sound to flac. What I have done is rip some CD's to 24/96 with dbpoweramp. I transfer them over ethernet. I will say that they clearly sound "better" than the rips at native res. I thought about ripping to flac but I cant control the resolution in the same way as with a wave file. The best rip I could get didnt sound any better than wave (no worse, as I remember). So - I have about 250 GB of 24/96 files ripped from CD that I play through my Transporter. I couldnt be happier! My next laptop will have at least 1TB for this crazyness!

lrossouw
2010-08-17, 20:57
I thought about ripping to flac but I cant control the resolution in the same way as with a wave file.

It was always my understanding that you can convert pretty much any wav to flac. So you could have 24/96 flac by just converting your 24/96 wav.

pfarrell
2010-08-17, 21:07
On 08/17/2010 06:49 PM, earwaxer9 wrote:
> I thought about ripping to flac but I cant control the resolution in the same way
> as with a wave file.

This makes no sense. The resolution of a flac file is exactly the same
as the input wave/pcm file. Flac is lossless. You can uncompress the
flac file and get exactly the original file, bit for bit.

Perhaps you are confused by the common use of the term "rip"
In reality, its a two step process, you extract the data, and then you
compress the data into a storage format. The early programs did it in
one step, and the term "ripping" became popular, but not a good
description of what actually happens.

There is no difference in sound quality, there is no difference in the
decompressed files. Its easy to test for yourself.

Any person who claims otherwise is blowing smoke.

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

firedog
2010-08-18, 01:16
I have some high res. flac downloads that sound great. I havent really compared CD res. sound to flac. What I have done is rip some CD's to 24/96 with dbpoweramp. I transfer them over ethernet. I will say that they clearly sound "better" than the rips at native res. I thought about ripping to flac but I cant control the resolution in the same way as with a wave file.

dbpoweramp can rip wav files to flac at any bitrate and resolution you want. It's one of the DSP options (not in the free version, you need at least the PowerPack version).
http://www.dbpoweramp.com/db-versions.htm

Lots of listeners think 96k files sound better, even when the source isn't hi-res. One of the possible explanations is that the filtering during the D>A conversion is done at higher frequencies than with standard res, and the result sounds better to some ears. If you like it, do it.

Soulkeeper
2010-08-18, 04:38
One of the possible explanations is that the filtering during the D>A conversion is done at higher frequencies than with standard res, and the result sounds better to some ears. If you like it, do it.

If you upsampled the track at playback with SOX instead, wouldn't you that get you the same result?

earwaxer9
2010-08-18, 08:43
dbpoweramp can rip wav files to flac at any bitrate and resolution you want. It's one of the DSP options (not in the free version, you need at least the PowerPack version).
http://www.dbpoweramp.com/db-versions.htm

Lots of listeners think 96k files sound better, even when the source isn't hi-res. One of the possible explanations is that the filtering during the D>A conversion is done at higher frequencies than with standard res, and the result sounds better to some ears. If you like it, do it.

Interesting - I will have to play around with dbpoweramp some more! I have the full version. What DSP option would I use?

thanks

Stratmangler
2010-08-18, 11:15
Interesting - I will have to play around with dbpoweramp some more! I have the full version. What DSP option would I use?

thanks

There are two things you'd need to set up - resample to, and bit depth.

Why you'd want to is beyond me - all you're going to do is add lots of noughts.
You can't just "magic" information out of thin air if it doesn't exist already.

Phil Leigh
2010-08-18, 12:05
There are two things you'd need to set up - resample to, and bit depth.

Why you'd want to is beyond me - all you're going to do is add lots of noughts.
You can't just "magic" information out of thin air if it doesn't exist already.

Chris - the benefit is that the DAC will shift its anti-alias filter well away from the audible frequency range. It's not about extra info - as you say there isn't any. It's a trick - but a good one.

cliveb
2010-08-19, 00:28
Chris - the benefit is that the DAC will shift its anti-alias filter well away from the audible frequency range. It's not about extra info - as you say there isn't any. It's a trick - but a good one.
And one which pretty much all DACs (except for those off-the-wall NOS jobbies) have been doing since the late 1980s.

If you want the benefit of moving the reconstruction filter out of harm's way, simple oversampling does the trick (and as I said above, happens inside most DACs anyway).

I've never understood why people think that "upsampling" (stuffing invented samples in between the actual ones) could achieve anything more, but they swear it sounds better, so there must be something in it - almost certainly psychological.

c3p0
2010-08-19, 01:47
Hi Folks,
Just reviewed this whole thread and I think it could benefit from some Paraphrasing.

It started of by someone (Louis) saying that he converted his book (CD:16/44.1), to a digital format, WORD (wav) doc but then if he emailed them as pdf (flac), they didnt read the same, he prefered the story as a WORD document as the PDF didnt have the breadth or depth of storyline.

But Interestingly by magnifying (upscaling) the book (16/44.1)to higher resolution (24/ 48khz), he read more words than the author had written in the original version and prefered the story with the additional script.

Other people then chipped in by saying that by running a spellchecker (ADM)there was no difference with the story in word or pdf format.

Other people then said in with how important Font (jitter) was and that of the font was bad then it made the words harder to discern.

Other people then thought that there was a possability of Babelfish or google translate kicking in (poor transcription in the squeezebox) and that it was much better to do this on a higher power pc.

It has also been suggested that the ability to read and understand the story depended on your physiological state at the time and that this could affect your enjoyment of the story especially if you were predisposed to thinking that a Word document is the truer version.

I would be especially grateful if someone could pharaphrase a conclusion

andynormancx
2010-08-19, 01:53
Funny, but a flawed analogy. A PDF of a Word document is not lossless in the same way a FLAC is compared to the original WAVE data. A Word doc contains all sorts of data that doesn't make it into the PDF version.

c3p0
2010-08-19, 02:08
Funny, but a flawed analogy. A PDF of a Word document is not lossless in the same way a FLAC is compared to the original WAVE data. A Word doc contains all sorts of data that doesn't make it into the PDF version.

Exactly but they tell the same story, using the same words, neither more nor less, same Paragraphs, chapters.Same number of sentances, words per sentance, letters within words. There is no additional Storyline or less Dialog. The plot isnt enhanced or edited.

firedog
2010-08-19, 02:28
There are two things you'd need to set up - resample to, and bit depth.

Why you'd want to is beyond me - all you're going to do is add lots of noughts.
You can't just "magic" information out of thin air if it doesn't exist already.

Agreed, but as Phil says, it changes the filtering. Some people think the result sounds better. Personally, it doesn't do anything for me (although I do think the result sounds "different").

But I think it is a matter both of taste and system synergy. YMMV depending on your "ears" and the sound of your equipment.

m1abrams
2010-08-19, 05:51
Exactly but they tell the same story, using the same words, neither more nor less, same Paragraphs, chapters.Same number of sentances, words per sentance, letters within words. There is no additional Storyline or less Dialog. The plot isnt enhanced or edited.

Would be better to say that you zipped the word doc and emailed the zipped file to a friend and that friend read the doc after unzipping it.

c3p0
2010-08-19, 07:36
Better analogy with the zip file..... But still waiting a paraphrased conclusion to 34 pages of comments.

Phil Leigh
2010-08-19, 07:46
And one which pretty much all DACs (except for those off-the-wall NOS jobbies) have been doing since the late 1980s.

If you want the benefit of moving the reconstruction filter out of harm's way, simple oversampling does the trick (and as I said above, happens inside most DACs anyway).

I've never understood why people think that "upsampling" (stuffing invented samples in between the actual ones) could achieve anything more, but they swear it sounds better, so there must be something in it - almost certainly psychological.

yes - sorry, I was thinking about NOS DAC's. I should have made that clear.
Modern DAC's always oversample so they can use a digital recon filter out of harms way.
Which rather begs the question why anyone would ever UPSAMPLE anything these days. I mean, it would have made sense years ago before digital recon filters...

Phil Leigh
2010-08-19, 07:51
Better analogy with the zip file..... But still waiting a paraphrased conclusion to 34 pages of comments.
OK...

Some people think they can hear a difference when sending PCM to an SB vs a FLAC file... and others don't. No known measurement system has yet produced any reliable evidence that they produce audibly different results (in fact quite the opposite), yet peoples opinions still differ. There are some credible theories as to why they might sound different, but so far no proof that they actually do sound different to a statistically significant number of people in a controlled test.

How's that?

soundcheck
2010-08-19, 09:03
OK...

Some people think they can hear a difference when sending PCM to an SB vs a FLAC file... and others don't. No known measurement system has yet produced any reliable evidence that they produce audibly different results (in fact quite the opposite), yet peoples opinions still differ. There are some credible theories as to why they might sound different, but so far no proof that they actually do sound different to a statistically significant number of people in a controlled test.

How's that?

Hi there.

Thx Phil for refering to me. ;)

The issue behind all this flac vs. wav discussion is about system load originated non linearities, timing variations, PS irregularities and/or EMI/RFI.

As everybody knows the PCM bits will be the same on flac or wav.

Of course it requires quite good systems to hear the differences.

One fact that seems to underline above is if you start streaming HiRes
24/96 in PCM which means x times more load on the communication interface
the advantages from not doing the flac decoding locally will be wiped out by the extreme load caused by the 24/96 communication.
24/96 flacs locally decoded sound better then 24/96 PCM streams.

Based on this you could conclude that the error on 24/96 will always be higher then on a server decoded 16/44.1 stream!!!! Got it? ;)


Beside my flac to PCM recommendation for 44.1/16 I am also advise to
turn off one Alsa channel - either analog or digital should be active.
It will make a difference. Very subtle differences, much less then flac2PCM, though you'll hear or rather experience it.

Don't get fooled by people claiming they have measured it. There is no
difference.

These people are just wrong about it or do follow other interests with these claims. I wouldn't have any other interest then sharing my stuff with the community.

I am a graduated engineer by myself. Believe me I wouldn't make myself look like a fool if I couldn't replicate what I am claiming.

If you look at Audio Asylum there are guys like Gordon Rankin from Wavelength. He claimed for years that there wouldn't be a difference
if bits are bitperfect transfered. "He measured it all with +20k equipment."
His problem: More and more people reporting very strange things
about his "outstanding"?!?!? DACs over at AA.
Sound improves if a RAMDISK is used, if services are stopped,
if HDDs gets replaced with SSDs and so on and so on. Especially those people who are using now Amarra and PureMusic under OSX are cathing up now - slowly but surely. On the other systems you can achieve similar ( even better) performance free of charge.


And Phil - please don't forget to mention that well known people such as John Svensson have confirmed what I am saying - he applied my tweaks.


I do see more improvement potential for the Touch. Unfortunately quite some error sources are not easily accessible. The worst thing I think is the monitor. It would be great if we would be able to switch that one off.

On my own headless rt-Linux systems I even hear clearly differences when streaming or playing locally from ramdisk. There is even a slight difference if I do realtime volumecontrol vs. offline volume digital control. ( I'd love to give SB server volume control a try. I am sure it'll sound slightly better. Afaik this is not possible.)


Just to summarize the whole thing I'd say the whole discussion should not be about flac vs. wav. The data is the same.

It is about reducing load on the audio client.

Enjoy.

P.S:
I btw converted my whole collection from wav to flac to enjoy the tagging features. Since I am able to do "offline" or "remote" decoding flac is not considered a problem anymore.

Wombat
2010-08-19, 09:29
More and more people reporting they saw Aliens.

c3p0
2010-08-19, 09:36
" Just to summarize the whole thing I'd say the whole discussion should not be about flac vs. wav. The data is the same.

It is about reducing load on the audio client."

So that would suggest that only analog outputs would be affected but not the spdif/tos to an external DAC. Or does it affect the Jitter?, which should be measurable. Therebye the ability to hear a difference is not only external DAC/System dependant but also dependant upon the scale of Jitter, which will vary between systems. But then again all this should be measurable.

If a difference exits it must be measuarable.

soundcheck
2010-08-19, 09:53
" Just to summarize the whole thing I'd say the whole discussion should not be about flac vs. wav. The data is the same.

It is about reducing load on the audio client."

So that would suggest that only analog outputs would be affected but not the spdif/tos to an external DAC. Or does it affect the Jitter?, which should be measurable. Therebye the ability to hear a difference is not only external DAC/System dependant but also dependent upon the scale of Jitter, which will vary between systems. But then again all this should be measurable.

If a difference exits it must be measuarable.

1. You'll experience it on both outputs.
2. If you have the right skills and the right equipment you should manage.
Though I doubt that any average electronic freak will be able to do
that. ( For sure G. Rankin must be considered a quite capable engineer.
He and Steve Nugent (Empirical Audio) failed to come up with an explanation. Both of them and many more professionals are well aware of what I am describing. )
Manufacturers do have to deliver standard specs such as THD/SNR etc.
If you're very lucky you'll see jitter measurements ( which usually
doesn't mean anything).
The manufacturers won't be even interested to do more then required.
Marketing strategy, cost and competition will dictate the efforts taken.

Enjoy.

Phil Leigh
2010-08-19, 10:01
Hi there.

Thx Phil for refering to me. ;)

...

I was deliberately not referring to any one person. You aren't the first person to have made similar claims on this forum, you know!.

:-)

For what it's worth, I haven't tested your claims/tweaks on the analogue outputs (as I don't use them at all). For me they had no effect on the digital output - I am not speaking for anyone else here.

Phil Leigh
2010-08-19, 10:04
" Just to summarize the whole thing I'd say the whole discussion should not be about flac vs. wav. The data is the same.

It is about reducing load on the audio client."

So that would suggest that only analog outputs would be affected but not the spdif/tos to an external DAC. Or does it affect the Jitter?, which should be measurable. Therebye the ability to hear a difference is not only external DAC/System dependant but also dependant upon the scale of Jitter, which will vary between systems. But then again all this should be measurable.

If a difference exits it must be measuarable.

Jitter on the s/pdif is measurable with the correct (expensive) equipment and test procedures. The debate is about how/to what extent it impacts the DAC and its analogue output - ie what we actually hear.

On audition some DAC's are impervious to even quite high jitter, others are rather sensitive to it.

earwaxer9
2010-08-19, 21:17
I agree with most here - this discussion is a bit on the edge, from a logical and technical perspective. It took me some years to even think of trying this because I knew it made no sense. I was a huge doubter of "cables" for many years!

The point is becoming more and more universal - there is a positive effect on sound quality from up-sampling redbook CD to "high res." at least in respect to the Transporter/SB. I couldn't be more confident of this effect from day to day as I continue to evaluate what I am hearing. The music is just that much more musical. It has gone from sound that reproduces music, to music itself. Quite striking. I have since rigged a 30V battery power supply for my t-amp. Even more of the same. Music. More depth, more natural.

What has been very interesting to me is that, the "deficiencies" in my system have been mostly solved by some very inexpensive methods. Where I thought I needed more "power" (I'm not saying that I wont revisit that one), for example, I have largely solved through "data handling techniques" and power supply modifications. A happy camper again! - for now.

soundcheck
2010-08-20, 00:06
For what it's worth, I haven't tested your claims/tweaks on the analogue outputs (as I don't use them at all). For me they had no effect on the digital output - I am not speaking for anyone else here.

It took you a while to come up with this feedback. ;)

Anyhow. It might shows that your TACT and/or the rest of your system is either that good or even that low-level that the changes are not audible
to you.

In fact there are only very few DAC systems I am aware of out there which manage to decouple quite good from a PC or Touch. It usually requires galvanic isolation and serious buffering, reclocking or jitter suppression on the receiver side. Those systems become pretty immune against incoming distortions.
This is actually one reason why the Touch is pretty immune against distortions generated by the server.
Unfortunately they made the Touch a PC again. All those decoupling advantages which we could experience on a DUET were again eliminated on the Touch by introducing that Linux-OS, monitor asf. Not to forget we still face poor ethernet-groundloops on Duet and Touch - which should be avoided in any case. Logitech should have just chosen a different ethernet jack respectively implementation to stay away from the dirty network ground.
I shouldn't forget to mention though that the new reclocking and better digital outputs on the Touch got Logitech a little out of Trouble.
For the marketing it was good enough to stay a little above Duet. (Challenging the Transporter with a 100$ DUET MKII device wouldn't have been a very smart marketing decision I guess :D )
I am sure that Logitech could have made a Duet MUCH better sounding then a Touch by introducing the same Touch reclocker and digital output environment to it.
Those devices would have been sold like mushrooms at a 100$ each -- for sure at a fragment of the production-cost of a Touch. ;)


And finally - To be honest - I never expected that -- especially you -- would hear a difference. ;)
The interesting thing though, the vast majority of feedback I am getting pretty much confirms what I am claiming/promise to happen.

There is actually no need for me to get into arguments with people who are "experiencing" different things.

Enjoy.

soundcheck
2010-08-20, 00:57
What has been very interesting to me is that, the "deficiencies" in my system have been mostly solved by some very inexpensive methods. Where I thought I needed more "power" (I'm not saying that I wont revisit that one), for example, I have largely solved through "data handling techniques" and power supply modifications. A happy camper again! - for now.


I made great progress over the last years by applying the "less is more" philosophy to my entire (DIY) system.

No connectors , no binding posts, no interconnects, no extra parts, no filters, asf. asf. Everything got reduced to its absolute minimum.
The remaining limited number of parts are of course of highest quality.
As a final step I started to apply that "less is more" logic to the PC 4 years ago. Surprise, it actually also worked on the PC side.

All this effort saved me a hell lot of money and made my system better sounding then anything else I had before.


Enjoy.

P.S: I am also running battery supplies.

Phil Leigh
2010-08-20, 05:19
It took you a while to come up with this feedback. ;)


Sorry - I forgot.


Anyhow. It might shows that your TACT and/or the rest of your system is either that good or even that low-level that the changes are not audible
to you.




It might - Or it might equally show they have no effect... let's have some logic applied to this.




In fact there are only very few DAC systems I am aware of out there which manage to decouple quite good from a PC or Touch. It usually requires galvanic isolation and serious buffering, reclocking or jitter suppression on the receiver side. Those systems become pretty immune against incoming distortions.
This is actually one reason why the Touch is pretty immune against distortions generated by the server.
Unfortunately they made the Touch a PC again. All those decoupling advantages which we could experience on a DUET were again eliminated on the Touch by introducing that Linux-OS, monitor asf. Not to forget we still face poor ethernet-groundloops on Duet and Touch - which should be avoided in any case. Logitech should have just chosen a different ethernet jack respectively implementation to stay away from the dirty network ground.
...



Not sure what you are saying here - unshielded cat 5/6 is galvanically isolated - each end of the twisted pair terminates in the primary of a transformer. There's no continuity on my system between the PC earth/groundplane and the groundplane of my Touch, connected via unshielded cat 5 to router and then to PC.



And finally - To be honest - I never expected that -- especially you -- would hear a difference. ;)

Why "especially me"? - Is it because I don't trust my own ears/brain, or yours or any other so-called expert?. Thats why I use ADM. It's impartial.

I haven't tested your claims with ADM - only by listening. I will though, when I get time. And before anyone reels off the usual excuses as to why ADM won't work:

1) Soundcard not sensitive enought - nonsense, it's more resolving than the majority of soundcards/adc's used to digitise the things in the first place! (Sony pcm f1 anyone?)

2) The software doesn't work / isn't accurate - demonstrably untrue, can be proven in 5 minutes using a control test.

3) The differences are more than 100dB down but still easily audible to humans... well, for uncorrelated artefacts such as jitter that's true. We are very sensitive to uncorrelated distortions. Correlated distortions are altogether different. The vast majority of people cannot detect a slight change (+/- 1dB) in frequency response or even quite high doses of even order harmonic distortion... There's lots of well-researched material published about this.

There are many peoples ears that I do trust - and they are all musicians. None of them make, sell or review audio equipment.




The interesting thing though, the vast majority of feedback I am getting pretty much confirms what I am claiming/promise to happen.

I'm sure you appreciate that doesn't actually make it true...


I'm happy to be different. :-)

When I get time I'll do the adm tests and let's see what happens.

Thanks for suggesting these things and triggering the debate. Let's see if it leads anywhere.

audiomuze
2010-08-20, 08:10
thik we should rename this the Seinfeld thread...the thread about nothing, that we keep revisiting.

Phil Leigh
2010-08-20, 09:24
thik we should rename this the Seinfeld thread...the thread about nothing, that we keep revisiting.

But - where do YOU stand?
:-)

audiomuze
2010-08-20, 11:37
But - where do YOU stand?
:-)

Lossless = WAV = Lossless...if there's something about decoding lossless at the player side my Transporter and ATCs can't resolve it or I'm too old to hear it.

Phil Leigh
2010-08-20, 11:42
Lossless = WAV = Lossless...if there's something about decoding lossless at the player side my Transporter and ATCs can't resolve it or I'm too old to hear it.

Cool - I'm with you.

ralphpnj
2010-08-20, 11:50
cool - i'm with you.

+1

Mnyb
2010-08-20, 13:29
+1

garym
2010-08-20, 13:38
thik we should rename this the Seinfeld thread...the thread about nothing, that we keep revisiting.

Love it. But I laugh even harder when I change the font of my webbrowser.

Mnyb
2010-08-20, 13:53
What many fail to recognize , is that the many treads articles post etc claiming this is WAV>FLAC is never backed up by real fact's .

it could be but who knows ? even if 1000000 Audiophiles claims this, in so many beautiful words in some fora, it does not prove a thing the information content is = 0 or even less as flac vs wav is tested to death in non squeezebox contexts, you do it yourself if you are using the -V parameter when encoding.

it tells me that's something interesting is going on.

But interesting to whom.

An audio engineer ?

A phd in psychology and behavioral science etc, for an interesting case study in audiophile delusions ?

A philosopher as audiophilia is rapidly turning in to a cargo cult religion , worshiping pseudo technology ? (it once was a respectable hobby).

Hopefully some one with an working ADM installation can test it in the squeezebox context. and make the Seinfeld tread a sticky.

One could apply Occam's razor now, but better give it the benefit of a doubt and measure it.

Phil Leigh
2010-08-20, 14:03
...(it once was a respectable hobby)...



And you know who I blame for this? - retailers, manufacturers and reviewers. A cosy, self-serving relationship.

Not all of them. But enough - and they know who they are.

Andy8421
2010-08-20, 14:37
I am afraid that this pseudo science nonsense is not restricted to audio. One of my other interests in life is tuning and racing cars. In the car world, the equivalent of an after market linear PSU is an 'induction kit' where the car's perfectly good inlet piping and air filter is replaced by something that is usually shiny, noisy and more often than not less effective than the original.

I think the issue is that owners generally want to tinker, customise and improve, and technology has moved to the point where there is nothing left that matters that an owner can really tinker with, or come to that, fully understand.

So in the audio world, owners are left to argue about speaker cables, fit shielded mains cords and buy magnetic pyramids to put under the feet of their equipment. The bits of their equipment that really impact the sound are all out of reach of the owner and often beyond their understanding.

JohnSwenson
2010-08-21, 19:40
I've already posted my thoughts on this subject back towards the beginning of this thread but I'll restate them here.

It seems to me there are two parts to this debate: 1, can people hear it. 2, is there a measurable mechanism that can account for it.

In regards to 1:

I CAN hear a definite difference between decoding FLAC and PCM on the Touch through its analog outs. I HAVE done blind tests and can still detect the difference. Some people have chimed up and said that these are scientifically useless tests and are thus meaningless. To which I say, please post an officially sanctioned protocol that IS valid and I will be glad to take part. I am NOT an expert at such testing and don't know what constitutes an acceptable test. It seems to me that the people that insist on such tests are the ones that are responsible for providing the terms of such a test. Where are they?

On 2, one possible mechanism is jitter feeding the DAC chip. I do have some equipment that can be used to measure jitter, but its not super sensitive. The jitter in the Touch is just below the level of what my equipment can measure. With this setup I cannot measure a difference between FLAC and PCM decode, but that is not conclusive. I need a more sensitive jitter analyzer for this test. When headphones are plugged into the Touch I CAN see an increase in jitter above the threshold of my equipment, so it IS possible for the jitter to change in the Touch. (it doesn't mean decoder differences affect jitter, but it does say that something going on inside the Touch can change the jitter)

There are much more sensitive jitter analyzers, but they cost $35K to $50K and I can't afford that. If anyone wants to donate to the cause I will be glad to accept a donation or loan of such an instrument to make the tests.

Another test being performed is Audio Diffmaker. This sounds like it should be a perfect test. The problem I have is that the AD converters being used for the testing have several times the jitter of the Touch. How can you hope to make a valid test of the affect of a small jitter change on a waveform when what you are using to sample that waveform has jitter 10 times greater than the what you are trying to measure? If someone has an AD converter with a 10ps jitter or less sampling clock that would be a MUCH better instrument to use. I could build one, but again that takes money I don't have.

So there you have my stand, I'm convinced that I can hear the difference between FLAC and PCM decoded on the Touch (via wired ethernet) on the analog outputs. As of this time I have not been able to measure anything electrical that could be causing this. BUT I don't think I have the proper test equipment to to do a decent job of measuring it if it does exist.

John S.

Phil Leigh
2010-08-22, 01:42
John,

The jitter in the soundcard used with ADM should not matter (provided it is not excessive). Why? - because, as you know, jitter in the source DAC can only audibly manifest itself as amplitude or frequency effects that distort the analogue signal.
Modern soundcards (24/96 and up) are easily capable of capturing these subtle distortions. They are in most cases of better or equal capabilities than the ADC's used to put the music into the digital domain in the first place.

The biggest challenge in using ADM is to get the two recordings time-aligned correctly at a sample level, without relying on the software to "guesstimate". This is easily achieved using the methods I've decribed before - with a suitable soundcard, lock the soundcard clock to the SB s/pdif clock whilst simultaneously recording the analogue outs into the card ADC.


Once this has been mastered, miniscule differences between two renditions are revealed - and where there are no differences, a deep null occurs. A deep null CANNOT occur by chance or error. The odds against that are incalculable.

Provided it's snr/noise floor is low enough, the inherent jitter in the ADC does not matter. Obviously a raised noise floor might mask subtle changes in the input.

The empirical proof of this is the ability to return a > -100dB null using two identical recordings. This is best achieved using a software audio function generator to drive the soundcard DAC and looping back in to the ADC.
This is as close to a perfect, repeatable digital-analogue-digital test as it is possible to get.


The jitter contribution of the ADC IS nulled out. If it wasn't, a deep null would be impossible in the above test. As a byproduct, it also implies that the predominant jitter elements are either correlated with the analogue signal or a constant factor - they aren't highly random and they aren't readily audible - or else they wouldn't be nullable.

This is all discussed in the 2008 AES paper; the ADC jitter does NOT have to be equal to or lower than that of the source. ADM is about differences, not absolute values. A 24/96 ADC is easily capable of capturing differences (or not) originating from comparisons of 16/44.1-sourced analogue signals.
Regards
Phil

earwaxer9
2010-08-23, 16:08
I've already posted my thoughts on this subject back towards the beginning of this thread but I'll restate them here.

It seems to me there are two parts to this debate: 1, can people hear it. 2, is there a measurable mechanism that can account for it.

In regards to 1:

I CAN hear a definite difference between decoding FLAC and PCM on the Touch through its analog outs. I HAVE done blind tests and can still detect the difference. Some people have chimed up and said that these are scientifically useless tests and are thus meaningless. To which I say, please post an officially sanctioned protocol that IS valid and I will be glad to take part. I am NOT an expert at such testing and don't know what constitutes an acceptable test. It seems to me that the people that insist on such tests are the ones that are responsible for providing the terms of such a test. Where are they?

On 2, one possible mechanism is jitter feeding the DAC chip. I do have some equipment that can be used to measure jitter, but its not super sensitive. The jitter in the Touch is just below the level of what my equipment can measure. With this setup I cannot measure a difference between FLAC and PCM decode, but that is not conclusive. I need a more sensitive jitter analyzer for this test. When headphones are plugged into the Touch I CAN see an increase in jitter above the threshold of my equipment, so it IS possible for the jitter to change in the Touch. (it doesn't mean decoder differences affect jitter, but it does say that something going on inside the Touch can change the jitter)

There are much more sensitive jitter analyzers, but they cost $35K to $50K and I can't afford that. If anyone wants to donate to the cause I will be glad to accept a donation or loan of such an instrument to make the tests.

Another test being performed is Audio Diffmaker. This sounds like it should be a perfect test. The problem I have is that the AD converters being used for the testing have several times the jitter of the Touch. How can you hope to make a valid test of the affect of a small jitter change on a waveform when what you are using to sample that waveform has jitter 10 times greater than the what you are trying to measure? If someone has an AD converter with a 10ps jitter or less sampling clock that would be a MUCH better instrument to use. I could build one, but again that takes money I don't have.

So there you have my stand, I'm convinced that I can hear the difference between FLAC and PCM decoded on the Touch (via wired ethernet) on the analog outputs. As of this time I have not been able to measure anything electrical that could be causing this. BUT I don't think I have the proper test equipment to to do a decent job of measuring it if it does exist.

John S.

I think John has put his finger on an important point here! -

It reminds me of college physics. Specifically the "Heisenberg uncertainty principle". Sometimes when you try to observe/measure something you cant help but change what it is you are trying to observe/measure! Hense - some things are inherently unmeasurable. - probably all bs, but its fun to think about!

lrossouw
2010-08-23, 19:18
I CAN hear a definite difference between decoding FLAC and PCM on the Touch through its analog outs. I HAVE done blind tests and can still detect the difference. Some people have chimed up and said that these are scientifically useless tests and are thus meaningless. To which I say, please post an officially sanctioned protocol that IS valid and I will be glad to take part. I am NOT an expert at such testing and don't know what constitutes an acceptable test. It seems to me that the people that insist on such tests are the ones that are responsible for providing the terms of such a test. Where are they?


Not much of an audiophile myself but have been following this debate. I am a firm believer in digitial is digital and lossless is lossless, but I don't know much of audiophile side of things. I do think you make very reasonable and fair comments in this forum so I am a bit at odds here.

As a bit of stats geek I'd imagine that a good test of this would be doing 10 (or more, stats people always like more data) listening tests with A & B pairs where you don't know which source is which and you can't in any way figure out which is which other than by hearing. A & B has to be randomly switched in each test. Every test you chose the better sounding version. Afterwords this is compared to what actually was played as A & B in each case.

You'd need someone else to help you with this (to randomly assign wav/flac and to record your responses) and they would probably be out of your sight as in theory you could read there body language etc.

Not sure about the music. I think it could be changed in each test and/or kept the same, though it'd probably feel better if it were different music.

If you consistently pick the wav over flac in such case I'd say that this would be objectively measured. Given the actual number of times you picked wav over flac we can work out a probability that you did this when in fact they are the same.

To me that should be pretty conclusive as a result if you pick the the wav 8 or more times out of 10 tests, as the chances of doing this, if in fact they are the same, is only <=5.5%. I'd even be happier with 15 or more out 20 (probability <=2.1% of doing that if they are in fact the same).

This would probably take a lot of time. I don't know how long you need to listen to sources to hear these differences. It may need to be done over some time (e.g. a test each evening or something). It is also best if you chose the number of tests without looking at the results. E.g. if you get to 10 tests and you are not happy with the result you shouldn't then go further and do more tests. It should be chosen without reference to the results.

Having said all of that I'd still stream flac as I won't know the difference and it is easier, but I like the debate :)

I'd be happy to set up a spreadsheet to do the stats. Pretty easy with Excel and the BINOMDIST function.

RonM
2010-08-23, 20:33
Ideally, of course, you'd want the helper to also be "blind" as to which session was WAV or FLAC. Double-blind, the way to go.

Also, controlling for volume would be critical.

You'd think we were testing pharmaceuticals, or psychological procedures. Hmm. I guess it really IS the latter!

Suggestion and belief are really powerful things. What we experience is mediated by many variables, including not only verifiable truth but a host of other factors ranging from our perceptual limitations through our expectations to our learned responses to stimuli.

It's why the least reliable evidence is "eyewitness" evidence. Every lawyer and every judge (and every psychologist) knows that people will truly believe, and insist on, what they "saw", even when confronted with concrete proof that they are mistaken. The conviction with which people will assert their own version of the truth has led to many unjust "convictions" (in the legal sense).

Healthy scepticism about our own beliefs and convictions is a good thing. Looking for verifiable proof is also a good thing. The convictions expressed in this thread go two ways; systematic proof as suggested above would be a good thing, assuming anyone has the time and resources to do it.

For the record, I'm in the lossless is lossless camp; but open to the possibility (however slight) that there is some artifact in the processing of WAV or FLAC that leads to audible differences on some systems.

R.

Grahame
2010-08-23, 20:52
How about one of the ITU or EBU recommendations that address this exact area
e.g. ITU-R BS.1116,
www.ebu.ch/trev_274-hoeg.pdf

http://www.madebydelta.com/delta/Business_units/TC/Services+by+technology/Sensory+Evaluation/slo_ITU-R_BS.1116-1.page

or this Masters Thesis http://www.hydrogenaudio.org/forums/index.php?showtopic=69463

Mnyb
2010-08-23, 20:56
Ideally, of course, you'd want the helper to also be "blind" as to which session was WAV or FLAC. Double-blind, the way to go.

Also, controlling for volume would be critical.

You'd think we were testing pharmaceuticals, or psychological procedures. Hmm. I guess it really IS the latter!

Suggestion and belief are really powerful things. What we experience is mediated by many variables, including not only verifiable truth but a host of other factors ranging from our perceptual limitations through our expectations to our learned responses to stimuli.

It's why the least reliable evidence is "eyewitness" evidence. Every lawyer and every judge (and every psychologist) knows that people will truly believe, and insist on, what they "saw", even when confronted with concrete proof that they are mistaken. The conviction with which people will assert their own version of the truth has led to many unjust "convictions" (in the legal sense).

Healthy scepticism about our own beliefs and convictions is a good thing. Looking for verifiable proof is also a good thing. The convictions expressed in this thread go two ways; systematic proof as suggested above would be a good thing, assuming anyone has the time and resources to do it.

For the record, I'm in the lossless is lossless camp; but open to the possibility (however slight) that there is some artifact in the processing of WAV or FLAC that leads to audible differences on some systems.

R.

It's caled EBM "evidence based medicine" and was a revolution ,drugs are double blindly tested usually the doctors involved are "blind" too, to not bias the test etc.
Before the 1850 roughly you where statistically more likely to die if you contacted a doctor than if you did nothing . Then they started to test things for real , they invented good hygiene before anyone know what a germ or virus was, it worked so they used it .

Gone are the days of bloodletting and curing syphilis with mercury.

Strange that audiophiles loathe methods proven so successful everywhere in the field of science in general

There are other method,s Phil suggest to test it technically an partly inderect proof CD is 96dB if a deep null at -100dB is found, whatever is found can not influence what we hear .

John is suggesting that the internal workings of the Touch itself
influence it's analog out . This is no longer WAV vs FLAC can that die please, it is what happens in the touch when decoding.
This can be tested with ADM

And the digital out, are people still suggesting that the digital output is affected ?

Btw, Please check your replay gain tags and uncheck volume adjustment in player settings, 10dB louder would be a night and day difference to me to.

Phil Leigh
2010-08-23, 23:08
I think John has put his finger on an important point here! -

It reminds me of college physics. Specifically the "Heisenberg uncertainty principle". Sometimes when you try to observe/measure something you cant help but change what it is you are trying to observe/measure! Hense - some things are inherently unmeasurable. - probably all bs, but its fun to think about!

Heisenberg was talking about the Quantum level - where all bets are basically off!
We are a long way from that in this discussion. We are in the material world, where the effect of jitter on a DAC can only appear as deviations in frequency/amplitude in the analogue audio signal. Using a 24/96 or 24/192 DAC to capture these miniscule variations is entirely possible. Bear in mind that the a critical use of ADC's outside of Audio is as scientific analogue measurement tools (OK so they often have to be supercooled to minimise Johnson noise, but...)

JohnSwenson
2010-08-23, 23:52
And the digital out, are people still suggesting that the digital output is affected ?



Yes, if something in the Touch changes the jitter of the clock going to the DAC chip it will also change the jitter of the clock used for S/PDIF (its the same clock in the Touch), so the jitter on the S/PDIF signal wall also change.

I think the issue is not so much can the digital out timing be changed, but how does the input receiver in the DAC respond to this. THAT varies all over the map. And how the receiver responds is also very sensitive to the spectrum of the jitter, not just the "ps number". Almost all receivers do a pretty good job rejecting high frequency jitter (say above 1KHz), its the lower frequency jitter they don't deal with very well.

John S.

michael123
2010-08-23, 23:54
We are in the material world, where the effect of jitter on a DAC can only appear as deviations in frequency/amplitude in the analogue audio signal.

Phil,
I think you ignored time scale, what about phase response?

JohnSwenson
2010-08-24, 00:16
Fortunately the test between flac and PCM stream decode is very easy to do. It can be be done remotely, in another room and there is no indication on the Touch itself what the state is.

A predetermined random sequence can be devised (computer or real coin flip or whatever). The tester sends an email to the "changer person" who looks up the next state on the list and changes the setting in the server. After sending the email the tester waits one minute then starts listening again. There is no direct contact between the person changing the setting and the tester and its only one way, there is no communication at all between the person changing the setting and the test subject.

The test subject gets to listen to whatever music desired for as long as wanted to make the decision. Then requests a change. (which may not actually be a change of course).

It would be nice to make it completely automated. When the tester wants a change he/she runs a program which grabs the next state from a file (or computes it and saves the result) and sets the server over the net.

There are several very nice things about this test, first its the same hardware for all tests, you don't have to switch between devices. The change can be done remotely with no contact to the local device doing the playing. There is no indication of the state on the player. These get rid of a lot of traditional problems when trying to blind test audio equipment.

I would like to design the test such that the tester gets to request either a or b or next random setting. Is there a problem from a protocol standpoint doing so? Particularly if the test is done over several days it would be nice to "refresh" the experience of a and b.

Then the big question is how many tests to run. When others have done other tests and only done 8 or 10 tests they have been beaten up by some people saying that is way too small a number of tests, you need to do several hundred to be scientifically valid. Whats the score on that? Ten tests is not hard at all to do. 500 gets to be a little more difficult.

John S.

soundcheck
2010-08-24, 00:25
As I mentioned before.

It is not about flac vs. wav.

It is about different (non-linear) load conditions caused by the realtime decoding.


@John: You might have seen that Gordon Rankin strictly avoids to use the
term jitter in a discussion like this. Since quite some time he is
referring to "timing variations" instead !?!?!

lrossouw
2010-08-24, 01:20
Fortunately the test between flac and PCM stream decode is very easy to do. It can be be done remotely, in another room and there is no indication on the Touch itself what the state is.

A predetermined random sequence can be devised (computer or real coin flip or whatever). The tester sends an email to the "changer person" who looks up the next state on the list and changes the setting in the server. After sending the email the tester waits one minute then starts listening again. There is no direct contact between the person changing the setting and the tester and its only one way, there is no communication at all between the person changing the setting and the test subject.

The test subject gets to listen to whatever music desired for as long as wanted to make the decision. Then requests a change. (which may not actually be a change of course).

It would be nice to make it completely automated. When the tester wants a change he/she runs a program which grabs the next state from a file (or computes it and saves the result) and sets the server over the net.

There are several very nice things about this test, first its the same hardware for all tests, you don't have to switch between devices. The change can be done remotely with no contact to the local device doing the playing. There is no indication of the state on the player. These get rid of a lot of traditional problems when trying to blind test audio equipment.

I would like to design the test such that the tester gets to request either a or b or next random setting. Is there a problem from a protocol standpoint doing so? Particularly if the test is done over several days it would be nice to "refresh" the experience of a and b.

Then the big question is how many tests to run. When others have done other tests and only done 8 or 10 tests they have been beaten up by some people saying that is way too small a number of tests, you need to do several hundred to be scientifically valid. Whats the score on that? Ten tests is not hard at all to do. 500 gets to be a little more difficult.

John S.

We are trying to get whether the two processes result in different sound to a user. This test would allow us to reject the hypotheis that method 1 (stream pcm) is not better than method 2 (stream flac) with a probability of error of x%. The smaller you want x% to be the more tests you need to do.

I reckon I'd be more than happy with <1% chance of error. If you were just randomly chosing between the two, the chances of chosing the pcm version 16 times (or more) is just 0.59%. If you pick the right stream as better 16 out 20 times the chance of us being wrong to say that pcm is better is only 0.59%.

With 30 tests the magic number is 22 giving 0.81%.

Note it says nothing about the the reason for the difference (i.e. the streaming format or the processing in the touch).

1) To me, each test should have A = randomly one of pcm or flac and B the other. I think it should be fine to switch between these and listen for some time (I think everyone agrees the differences would be small). At the end of the test a call should be made which is better quality and this should be recorded along with which method were used for A and B. This is one iteration.

2) For the next iteration A again should be randomly one method and B the other. This should be on the same song.

3) Repeat N times. N=20? 30? 40?

Note that A shouldn't be always flac or always pcm as we want the tests to be independent of each other. Otherwise you can use information from one test to the the next which would invalidate our distribution we use for the probability calculations.

EDIT1: To summarise in layman's terms this design will tell us a) whether they sound different and b) whether pcm can be considered better in the ears of the listener of course over the music included in the test. This would still leave healthy gaps for debate :). Assuming the cut-off is made most would concede at least part a).

EDIT2: Also thinking about it more each repetition of the test should be done on the same song or same sample of music (perhaps 2 or 3 songs/pieces) as in theory pcm could sound better on some pieces and flac better on others. To reduce the chances of this messing up our results we should limit it to the same music in each iteration.

NewBuyer
2010-08-24, 04:59
We are trying to get whether the two processes result in different sound to a user. This test would allow us to reject the hypotheis that method 1 (stream pcm) is not better than method 2 (stream flac) with a probability of error of x%. The smaller you want x% to be the more tests you need to do.

I reckon I'd be more than happy with <1% chance of error. If you were just randomly chosing between the two, the chances of chosing the pcm version 16 times (or more) is just 0.59%. If you pick the right stream as better 16 out 20 times the chance of us being wrong to say that pcm is better is only 0.59%.

With 30 tests the magic number is 22 giving 0.81%.

Note it says nothing about the the reason for the difference (i.e. the streaming format or the processing in the touch).

1) To me, each test should have A = randomly one of pcm or flac and B the other. I think it should be fine to switch between these and listen for some time (I think everyone agrees the differences would be small). At the end of the test a call should be made which is better quality and this should be recorded along with which method were used for A and B. This is one iteration.

2) For the next iteration A again should be randomly one method and B the other. This should be on the same song.

3) Repeat N times. N=20? 30? 40?

Note that A shouldn't be always flac or always pcm as we want the tests to be independent of each other. Otherwise you can use information from one test to the the next which would invalidate our distribution we use for the probability calculations.

EDIT1: To summarise in layman's terms this design will tell us a) whether they sound different and b) whether pcm can be considered better in the ears of the listener of course over the music included in the test. This would still leave healthy gaps for debate :). Assuming the cut-off is made most would concede at least part a).

EDIT2: Also thinking about it more each repetition of the test should be done on the same song or same sample of music (perhaps 2 or 3 songs/pieces) as in theory pcm could sound better on some pieces and flac better on others. To reduce the chances of this messing up our results we should limit it to the same music in each iteration.

Some (possibly incorrect) observations here: If you wish to use the binomial sign test, then you should probably not use the same piece of music for separate trial iterations (as this could possibly violate the independence of trials requirement). If your research hypothesis is that the sound samples are sonically distinguishable, then you should perhaps also conduct a two-sided test (currently your test appears to be only one-sided), since this would not ignore either preference direction.

CharlieG
2010-08-24, 06:09
Variables have not been talked about in recent posts about testing.
A) Which stereo equipment will be used?
Can’t you hear it now, “of course you didn’t hear a difference Charlie, your gear isn’t revealing enough”.
B) Do you need a stock or modified Touch to be able to hear the differences? How many and what type modifications be allowed/required, if you choose to allow a modified Touch in the test?
C) Because there is an option for “there is no difference” some would be biased toward this position before the test began and this could influence the test results. The results would be cleaner if one went into the test expecting a diffence and were proven right or wrong, than if one went into the test expecting to hear no difference and heard none.
D) My ears are fifty-something years old. I have a significant loss of hearing and tinnitus in my left ear. Obviously I would be a bad candidate for this type of testing. I'll admit I am an extreme example, but no one’s hearing is exactly the same as the next person. There would always be room to say this influenced the results.

cliveb
2010-08-24, 06:51
A predetermined random sequence can be devised (computer or real coin flip or whatever). The tester sends an email to the "changer person" who looks up the next state on the list and changes the setting in the server. After sending the email the tester waits one minute then starts listening again. There is no direct contact between the person changing the setting and the tester and its only one way, there is no communication at all between the person changing the setting and the test subject.
I think it need not be as complicated as requiring a partner to be involved during the test, getting them to change the SB Server streaming settings.

Just take a track you say exhibits an audible difference between FLAC and PCM, and store it on the SB Server in both FLAC and PCM formats. Then get someone to build a playlist containing these two versions at random. (Flipping a coin to decide each item is probably the simplest approach). Once the playlist is built and stored, your accomplice absents themselves from the remainder of the test so there can be no suggestion of influence.

All you then have to do is play the playlist through the same system that has previously revealed the audible difference. Use a Controller to skip back and forth between tracks however you wish. For each item in the playlist, write down whether you believe you're hearing FLAC or PCM. After the test, check your results against the actual items in the playlist to see how well you've done. You are at liberty to train yourself by listening to the known FLAC and PCM versions as much as you like before the test.


Then the big question is how many tests to run. When others have done other tests and only done 8 or 10 tests they have been beaten up by some people saying that is way too small a number of tests, you need to do several hundred to be scientifically valid. Whats the score on that? Ten tests is not hard at all to do. 500 gets to be a little more difficult.
The guys over at Hydrogen Audio are probably the most fanatical about requiring statistically valid ABX tests to back up audibility claims, and they generally accept 20 trials as being sufficient. You don't have to face the prospect of 500.

Incidentally - if you do find a provable audible difference, and are looking for an explanation, don't limit yourself to jitter. Isn't it also plausible that the RFI generated by the CPU in the Touch (which might be different when decoding FLAC and PCM) could influence the analogue circuitry?

cliveb
2010-08-24, 06:58
Specifically the "Heisenberg uncertainty principle"
Quantum Mechanics introduced - thus the Audiophile Variant of Godwin's Law applies, and the thread is dead :-)

RonM
2010-08-24, 07:41
Then the big question is how many tests to run. When others have done other tests and only done 8 or 10 tests they have been beaten up by some people saying that is way too small a number of tests, you need to do several hundred to be scientifically valid. Whats the score on that? Ten tests is not hard at all to do. 500 gets to be a little more difficult.

John S.

I think the issue is purely statistical. You can estimate the statistical probability of a measured difference being significant with a small sample, but a larger sample increases the precision with which this can be done. In other words, if the differences between the two test conditions are small, demonstrating significance will be easier with a larger sample size. I'd have thought that double digit numbers, perhaps 20 or so, should suffice.

Ron

Phil Leigh
2010-08-24, 08:32
As I mentioned before.

It is not about flac vs. wav.

It is about different (non-linear) load conditions caused by the realtime decoding.


@John: You might have seen that Gordon Rankin strictly avoids to use the
term jitter in a discussion like this. Since quite some time he is
referring to "timing variations" instead !?!?!

http://www.positive-feedback.com/Issue41/ca_rankin.htm

If that is the same GR as talking here... he still talks about jitter... and a lot of other highly contentious statements... most of which I vehemently disagree with.

I'm not sure why you hold his opinion in such high esteem?

"AIFF/WAV always sounds better than FLAC/ALAC" - p-lease...

Phil Leigh
2010-08-24, 08:45
Phil,
I think you ignored time scale, what about phase response?

Timescale is fixed by the DAC clock, which is supposed to be a constant for the duration of a replay event.

Almost no DAC's take their clock directly from the s/pdif stream any more - they almost all lock on to determine the Fs and then read data out of a word buffer using a local high-precision clock, set to match the rate of the s/pdif clock. They are thus immune to changes (jitter) in the s/pdif embedded clock as they rely on their internal clock to drive the data into the DAC at a constant rate. This is why improving the DAC clock and its PSU CAN have a dramatic effect on reproduction quality, regarless of what is happening in the transport. The Transport just has to get the correct bits to the DAC... without introducing RF/noise into the s/pdif line that can worm its way through to the DAC and upset the DAC clock and other post-DAC circuitry.

{dons flame-proof suit and waits for fireballs from hell...)

All we have is a bunch of samples (digital words) that represent instantaneous amplitude values, replayed at a fixed (ignoring jitter) clock rate, creating amplitude changes over time = frequencies. Variations in clock rate will alter the frequencies.
Or to put it another way, phase response accuracy is a function of frequency response accuracy - you can't change them independantly, even by accident.

lrossouw
2010-08-24, 09:58
Some (possibly incorrect) observations here: If you wish to use the binomial sign test, then you should probably not use the same piece of music for separate trial iterations (as this could possibly violate the independence of trials requirement). If your research hypothesis is that the sound samples are sonically distinguishable, then you should perhaps also conduct a two-sided test (currently your test appears to be only one-sided), since this would not ignore either preference direction.

We don't need separate music as we make them independent by randomly swapping A & B. He doesn't know which is which.

Two show you how selecting different music in each test is a problem consider this example. It may be possible that there is a difference and it may be possible that he accidentally chose 10 songs for which flac sounds better and 10 songs for which pcm sounds better. John listens to them pics 10 flac and 10 pcm. They are in fact different but John ends up chosing half of each and we incorrectly deduce that he can't tell the difference.

I think John should actually chose a song (or maybe 2 or 3) where he believes the pcm is better than the flac streaming (as this is what he believes right?). And these should should be listened to in each test.

null hypothesis (H0): is that they sound the same
the alternative (H1): is that pcm is better (to him)

If he picks pcm in 22 out 30 trials then we can be pretty sure that we can reject H0 in favour of H1 with only a 0.81% (i.e. <1%) chance of being wrong in rejecting this. I.e. there is a less than 1 in 100 chance of him picking pcm 22 times if they in fact do sound the same to him.

If he happens to pic the pcm <8 times then we should possibly conclude that there is also a difference but that flac is better :)

lrossouw
2010-08-24, 10:16
Variables have not been talked about in recent posts about testing.
A) Which stereo equipment will be used?
Can’t you hear it now, “of course you didn’t hear a difference Charlie, your gear isn’t revealing enough”.
B) Do you need a stock or modified Touch to be able to hear the differences? How many and what type modifications be allowed/required, if you choose to allow a modified Touch in the test?
C) Because there is an option for “there is no difference” some would be biased toward this position before the test began and this could influence the test results. The results would be cleaner if one went into the test expecting a diffence and were proven right or wrong, than if one went into the test expecting to hear no difference and heard none.
D) My ears are fifty-something years old. I have a significant loss of hearing and tinnitus in my left ear. Obviously I would be a bad candidate for this type of testing. I'll admit I am an extreme example, but no one’s hearing is exactly the same as the next person. There would always be room to say this influenced the results.

Well the tests need to be done with whoever believes it to be different. E.g. someone who says I can hear the difference on system XYZ.

The equipment shouldn't make a difference unless there is something that artificially changes the sound depending on what type of stream it is. A stock touch should be preferred as we don't want someone to say this or that mod favours the flac or pcm.

Of course the main problem with this test is that let's say John choses PCM 12 / 20 times. In this case all we proved is that we can't reject that they are not the same. This doesn't prove that they *are* the same but merely that they aren't different to his ears on his system.

The big thing is not to accidentally reveal to the person which is which through the rest of the design.

I wish Phil could run the test and John can be subject :D That way we'd be 100% sure that it is objective. Perhaps we can arrange something if John gets a result that is significant.

Anyway if John or anyone does find a difference we would also just know that there is a difference in their setup. They could then play with their setup and/or mod the touch until they figure out what is causing the difference.

lrossouw
2010-08-24, 10:24
Just take a track you say exhibits an audible difference between FLAC and PCM, and store it on the SB Server in both FLAC and PCM formats. Then get someone to build a playlist containing these two versions at random. (Flipping a coin to decide each item is probably the simplest approach). Once the playlist is built and stored, your accomplice absents themselves from the remainder of the test so there can be no suggestion of influence.


This sounds like it could work assuming you could set wavs to stream as pcm and flac to stream as fac (not sure if you can?) on the same server. You would need say 20 consecutive pairs of the same song. in the playlist and one would need to chose each one.

Mnyb
2010-08-24, 10:34
I still like phils idea about measuring it better .

If it can be measured we don't need an elaborate dbt test.

Dbt is great for weeding out if there is a difference if we have many unknown to fight with .

The output is not an unknown it is an electrical signal and it can be measured.

If it can be measured that the signal from the Touch when playing WAV is identical (or not) to the signal when playing FLAC then we are done.

Or it would be satifactory to prove that the difference "signal WAV" minus "signal FLAC" is -100dB to -120dB or something then it would be beyond human hearing or the analog Noise floor of the Touch itself.
If the difference signal is random noise even better .

Would ADM with 24bit 96kHz input be doable, to get a really deep "null" .
If that 0 is much weaker than the lSB of 16bit redbook CD then it can be proved that CD quality would be identical if differences shows up at signal levels not present at a normal CD .
Most people do not have any hi-rez files at all anyway.

Or I'm totally wrong here ?

Mnyb
2010-08-24, 10:40
Hey we have thoose very low level test signals that MSWlogo used in his dac resolution test .

Why not play for example the -108dB 3500Hz tone crank up the volume sit with the ear next to the speaker and listen .
This is ofcourse totally unatural to how you use your stereo normally but if the WAV FLAC processing does something it sure would show up at <100dB

Phil Leigh
2010-08-24, 11:16
Well the tests need to be done with whoever believes it to be different. E.g. someone who says I can hear the difference on system XYZ.

The equipment shouldn't make a difference unless there is something that artificially changes the sound depending on what type of stream it is. A stock touch should be preferred as we don't want someone to say this or that mod favours the flac or pcm.

Of course the main problem with this test is that let's say John choses PCM 12 / 20 times. In this case all we proved is that we can't reject that they are not the same. This doesn't prove that they *are* the same but merely that they aren't different to his ears on his system.

The big thing is not to accidentally reveal to the person which is which through the rest of the design.

I wish Phil could run the test and John can be subject :D That way we'd be 100% sure that it is objective. Perhaps we can arrange something if John gets a result that is significant.

Anyway if John or anyone does find a difference we would also just know that there is a difference in their setup. They could then play with their setup and/or mod the touch until they figure out what is causing the difference.

Well, leaving aside the 3,500 miles between us...

Anyway, I'm happy to play. If we can agree on a set of test files and a methodology, I'm game.

Phil Leigh
2010-08-24, 11:19
I still like phils idea about measuring it better .

If it can be measured we don't need an elaborate dbt test.

Dbt is great for weeding out if there is a difference if we have many unknown to fight with .

The output is not an unknown it is an electrical signal and it can be measured.

If it can be measured that the signal from the Touch when playing WAV is identical (or not) to the signal when playing FLAC then we are done.

Or it would be satifactory to prove that the difference "signal WAV" minus "signal FLAC" is -100dB to -120dB or something then it would be beyond human hearing or the analog Noise floor of the Touch itself.
If the difference signal is random noise even better .

Would ADM with 24bit 96kHz input be doable, to get a really deep "null" .
If that 0 is much weaker than the lSB of 16bit redbook CD then it can be proved that CD quality would be identical if differences shows up at signal levels not present at a normal CD .
Most people do not have any hi-rez files at all anyway.

Or I'm totally wrong here ?

I'm going to setup my test rig again at the weekend.
I never did test John's headphone observation. Let's see if that one goes anywhere. It SHOULD be observable via ADM.

JohnSwenson
2010-08-24, 13:06
I'm going to setup my test rig again at the weekend.
I never did test John's headphone observation. Let's see if that one goes anywhere. It SHOULD be observable via ADM.

I actually did the test the other day where I had the Touch analog outs plugged into the main system and listened with and without the headphones plugged into the Touch. BTW my headphones are 32 ohms. That might be a significant factor.

The difference was rather striking. I was listening to a chorus accompanied by a small orchestra. In several places a harp was playing. With the headphone plugged in it was barely noticeable, it kind of blended in with the rest of the instruments. With the headphones unplugged the harp was perceived as a separate instrument rather than just part of the rest. I could easily hear the decay of each note, the subtlety in expression as the harpist played the instrument. The melody being played by the harp was much easier to follow rather than being subsumed by the rest of the instrumental music.

The decay of notes seemed to go on much longer in the unplugged state. For example at one point the chorus and orchestra just stopped (grand pause), in unplugged mode the reverberation in the room could be heard for at least 6 seconds, in pugged state it was only about 2 seconds. Its kind of astonishing to hear such a difference with the same recording. Kind of an Energizer Bunny experience (do people outside the US get that?)

BTW this was definitely sighted, I had to plug the headphones in or out so I knew what the state was.

John S.

Mnyb
2010-08-24, 13:09
The headphone things sound nasty , Id love to use phones again .

Maybe I'll get another Touch for that or use the analog out of the one I have to drive my headphone amp in parallel when it sends spdif to my hifi.

JohnSwenson
2010-08-24, 13:33
Thanks everyone for responding on the test methodology. Thats some good debate on this, thats what I hoped would happen.

I like the playlist concept, I just see one major problem, at least on my system wav and flac show up differently on the screen of the Touch and controller. In order for this to work they would have to display exactly the same. Thats the reason I mentioned changing the server streaming settings, it doesn't change the display in any way.

Lets make sure I understand this: we have a wav and flac of the same song. We have a playlist with a random distribution of those two songs. The person performing the test can listen to the playlist as many times as desired, skip forward, back etc. Now what should the output be? A list of tracks and whether they are pcm or flac OR which ones are prefered? Its seems to me that adding preference into it rather than just flac or pcm is complicating the test.

John S.

lrossouw
2010-08-24, 19:45
I like the playlist concept, I just see one major problem, at least on my system wav and flac show up differently on the screen of the Touch and controller. In order for this to work they would have to display exactly the same. Thats the reason I mentioned changing the server streaming settings, it doesn't change the display in any way.

Lets make sure I understand this: we have a wav and flac of the same song. We have a playlist with a random distribution of those two songs. The person performing the test can listen to the playlist as many times as desired, skip forward, back etc. Now what should the output be? A list of tracks and whether they are pcm or flac OR which ones are prefered? Its seems to me that adding preference into it rather than just flac or pcm is complicating the test.

I knew taking stats would come in useful one day!

You'd need to set it up so that you can't see the difference on your touch screen or can't tell the difference in some other way. In theory the touch could be slower to respond to flac (or pcm) songs or some other random interface thing.

I propose the following 3 formats. 1 is my original idea. 2 is the idea above and 3 is another format. I'm liking 3 as it most directly answers the basic question of whether you can hear a difference. The other two give stronger results though.

Format 1

As I originally proposed. N pairs of the same song/set of music. Identify the better.
H0: pcm not better than flac streaming
H1: pcm is better.

Here you'd need to get enough of PCM as better to reject H0. E.g. 22 out of 30.

Format 2

A playlist of N entries with the same song repeated randomly flac or pcm. You just go through and specify which entry is flac and which is pcm. Before you start you can listen to known examples of the song in flac and pcm.

H0 = you can't identify flac or pcm on that song;
H1 = you can identify;

Here you need to identify enough songs correctly to reject H0. E.g. 22 out of 30.

You can listen to the whole list jump forward/back etc. If you can't tell the difference in the end it will just be still a 50% chance of getting it right on each song.

This is a more specific result. The minor problem with this is that if you do not manage to do it they can still be different, you could just be bad at identifying them. This involves less tracks. I.e. only N. The other both involve 2*N.

Format 3

N pairs of songs. Each is a pair of the same track. But different pairs can be different tracks. Here we simply randomly flip pairs such that they are the same (both pcm or both flac) or different (1 pcm and 1 flac). You just identify which pairs are different and which are the same.

H0: You cannot reliably tell which pairs are different and which not.
H1: You can.

Again identify enough of the pairs correctly as different or the same then we can reject H0.

This is the best one in my mind. This specifically looks just at whether you can correctly identify when they are different . You don't need to identify them as flac or pcm or to pronounce one as better. Also we could use different tracks for each pair.

Music

For all the below you should chose the music used as the hypothesis that is supported by the lossless is lossless camp is that you cannot tell the difference whatever the music. So you can use music where you think you can tell the difference. Obviously it would be nice for everyone if it covers a broad range of genres (another reason to like format 3 as it can be different music) but if you can only tell the difference on Kylie Mingogue's Locomotion then that is still a difference. :D

Mnyb
2010-08-24, 21:37
re Music:

It has to be of good sound-quality or else nobody is going to hear a difference at all any case, so it all will be a pointless exercise.

Btw would not an 24/96 file maximise the "problem" . As decoding of these bitrates "stresses" the Equipment even more
Many of these are "audiphile music" and would put you to sleep oh well...
Something from AIX (itrax) as these are *real* 24/96 recordings not refried analog or upsampled reedbook or DSD.

Why not use music the test perssons is familiar with.
Or in case of some agreed upon 24/96 tunes let them have it an week in advance.

Would this increase chances of detection, it would not give you a general case but thats not needed, if someone can here it it is a difference that proves that there is a difference at al.

Changing the server streaming settings is the way to go, just keep the test subject from using the context menu then you can spot the difference .
Or files without tags will the display show them as *.flc or *.wav

lrossouw
2010-08-24, 22:03
re Music:
Why not use music the test perssons is familiar with.
Or in case of some agreed upon 24/96 tunes let them have it an week in advance.

Would this increase chances of detection, it would not give you a general case but thats not needed, if someone can here it it is a difference that proves that there is a difference at al.

Changing the server streaming settings is the way to go, just keep the test subject from using the context menu then you can spot the difference .
Or files without tags will the display show them as *.flc or *.wav

Agreed. I was suggesting that the person who is doing the tests chose the music they think there is a difference in. It would be great if we can limit it to normal 16/44 CD quality music as this is what most people listen to most of the time.

Agreed on settings too. I assume one can set wav to stream as pcm and flac to stream as flac at the same time. This would allow the person to switch between the two without changing convert file?.

Mnyb
2010-08-24, 22:15
Agreed. I was suggesting that the person who is doing the tests chose the music they think there is a difference in. It would be great if we can limit it to normal 16/44 CD quality music as this is what most people listen to most of the time.

Agreed on settings too. I assume one can set wav to stream as pcm and flac to stream as flac at the same time. This would allow the person to switch between the two without changing convert file?.

Deepends, you want to prove or disprove if this is at possible to hear or not "normally" possible to hear.

16/44 would increase the amounts of good recordings thou..

NewBuyer
2010-08-25, 06:05
...
Format 3

N pairs of songs. Each is a pair of the same track. But different pairs can be different tracks. Here we simply randomly flip pairs such that they are the same (both pcm or both flac) or different (1 pcm and 1 flac). You just identify which pairs are different and which are the same.

H0: You cannot reliably tell which pairs are different and which not.
H1: You can.

Again identify enough of the pairs correctly as different or the same then we can reject H0.

This is the best one in my mind. This specifically looks just at whether you can correctly identify when they are different . You don't need to identify them as flac or pcm or to pronounce one as better. Also we could use different tracks for each pair.
...

I think you are certainly doing better now, with this last proposal. No longer is there a subjective "better" involved in the research hypothesis, but rather a more realistic test of a detected "difference". Also using different songs for different trial pairs will in fact allow a more realistic approximation to the independence-of-trials requirement - particularly if the test subject is NOT involved in the choice of songs used. I believe you could still benefit the test structure further by doing a two-sided test here - otherwise your P-values will likely be too artificially low. Also, if you are trying to establish that detection success is generally more likely than merely random selection, you absolutely would need to utilize randomly selected subjects, and definitely more test subjects than just one (even if that one is John!) :)

cliveb
2010-08-25, 10:53
Lets make sure I understand this: we have a wav and flac of the same song. We have a playlist with a random distribution of those two songs. The person performing the test can listen to the playlist as many times as desired, skip forward, back etc.
Quite so.

Moreover: you are allowed to listen to the flac and pcm versions (knowing which one is which) too, in order to "acclimatise" yourself.


Now what should the output be? A list of tracks and whether they are pcm or flac OR which ones are prefered? Its seems to me that adding preference into it rather than just flac or pcm is complicating the test.
Just in case it isn't clear from lrossouw's follow up, preference is NOT important. All you need to do is correctly identify flac or pcm.
The skeptics here believe you won't be able to tell the difference - all you have to do is show that you can, to a statistically significant degree.

As for the problem of the Touch and Controller displaying different info for FLAC and PCM, that is an issue. On the assumption that you aren't interested in cheating, can I suggest that you:
a) turn the Touch so its screen faces away from you (or cover the screen up in some other way).
b) cover the Controller's screen with some sort of mask, so that the only part of it you can see is the number of the track in the playlist. You do of course need to know the track number otherwise your results can't be compared to the playlist after the test.

Listener
2010-08-25, 18:10
Heisenberg was talking about the Quantum level - where all bets are basically off!


Some people are more uncertain than others.


We are a long way from that in this discussion.

In an audiophile discussion, you are never far from someone's invoking the Uncertainty Principle.

Bill

lrossouw
2010-08-25, 19:02
I think you are certainly doing better now, with this last proposal. No longer is there a subjective "better" involved in the research hypothesis, but rather a more realistic test of a detected "difference". Also using different songs for different trial pairs will in fact allow a more realistic approximation to the independence-of-trials requirement - particularly if the test subject is NOT involved in the choice of songs used. I believe you could still benefit the test structure further by doing a two-sided test here - otherwise your P-values will likely be too artificially low. Also, if you are trying to establish that detection success is generally more likely than merely random selection, you absolutely would need to utilize randomly selected subjects, and definitely more test subjects than just one (even if that one is John!) :)

Thanks, agree generally, but specifically:
- Different songs are not required, but may be preferred. Independence is provided by random pairs of songs that are the same format or different formats, even if all the pairs are the same song.
- It should be one tailed as to prove he hears a difference he has to correctly identify difference or sameness in enough cases. If he often states the opposite of what the reality it will certainly be strange but it would mean that he couldn't hear the difference in pairs that were in fact different.
- I think the H0 should be expanded that nobody can hear the difference on any song. H1 in this case (assuming John as subject) is that John can hear the difference on songs he chose. It would of course be better to do this on more subjects though, but it does have to be on people who claim they can hear a difference. If I don't think I hear the differences I cannot take these tests.

I think most of the lossless is lossless camp believes nobody can hear any difference on any song. So a reasonable alternative is someone can hear some difference on some songs.

I think I'll set up a spreadsheet to help people set this and check the result.

RonM
2010-08-25, 19:03
I would never have guessed I'd find such an animated discussion of research methodology on this forum! Coco Love Alcorn would have so much fun over here!

(see my recent post in the Music forum, 1 week 1 song)

Ron

NewBuyer
2010-08-26, 01:46
Thanks, agree generally, but specifically:
- Different songs are not required, but may be preferred. Independence is provided by random pairs of songs that are the same format or different formats, even if all the pairs are the same song.
- It should be one tailed as to prove he hears a difference he has to correctly identify difference or sameness in enough cases. If he often states the opposite of what the reality it will certainly be strange but it would mean that he couldn't hear the difference in pairs that were in fact different.
- I think the H0 should be expanded that nobody can hear the difference on any song. H1 in this case (assuming John as subject) is that John can hear the difference on songs he chose. It would of course be better to do this on more subjects though, but it does have to be on people who claim they can hear a difference. If I don't think I hear the differences I cannot take these tests.
...


I do appreciate what you're saying and I think your ideas are good - Just for the record I for some reason feel compelled to reiterate the following, (hopefully) for further consideration and clarity (as usual with statistical procedures, the details can be deceptively subtle):

- Independence would definitely require different songs on different trials, since we don't wish to identify the properties of, or limit our test results to, only certain specifically pre-chosen (and thus biased / non-generally-representative) songs.
- It really would ideally require two tails as well, since any differences in either direction could potentially be statistically significant, and we definitely don't want to deliberately ignore either of these directions. Remember we aren't trying to measure "better" any more, only "distinguishable". Equally important is the point that it's not only about the mere counts of "distinguishable" or not here either, but about how far from expected the evidence may fall - and this could presumably occur in either tail-direction from the expected result under the null hypothesis.
- The tests would theoretically require many randomly selected test subjects and should most definitely not be restricted to any kind of self-selected audience of subjects that already believe they can hear a difference - nor should it use only pre-screened or subject-selected songs. Otherwise any test results would definitely be limited at best and horribly biased at worst, and thus could not at all support the research hypothesis stating that the general audience can distinguish a difference on general songs. Any selection bias, whether self-selection or otherwise, should definitely and always be avoided. Significance tests by their design absolutely require randomization for their legitimacy, and ideally will also proceed from a simple random sample (not just a random sample). Any deviation whatsoever from these requirements can always, at the theoretical level, undermine and invalidate the results of any statistical significance test.

JohnSwenson
2010-08-26, 13:13
and thus could not at all support the research hypothesis stating that the general audience can distinguish a difference on general songs

Where did this come from? It was never what I was attempting. This came about because I (and others) say we can hear the difference between PCM and FLAC decoding on the Touch. Others emphatically state this is theoretically impossible and any claim that it is possible to hear is purely psychological caused by foreknowledge of which is playing.

What I was after was to come up with a procedure to test if it is even possible to hear a difference without foreknowledge of which decoder is being used. How wide spread the capability is and if its applicable to a wide range of music was not the emphasis of at least the original test. Doing those is certainly interesting research but I think it complicates what I was trying to get at, can a difference really be heard at all.

I have stated before that its much easier to hear the difference on some songs than on others, so I don't think I was trying to say that its equally applicable to all music.

Now it might turn out that I can't tell them apart, but somebody else might. The only way to find that out is to do the test on a large number of people. Similarly the songs I say are the best at distinguishing the two may not prove to do so ,but there might be others that are. A large number of people with a large number of songs seems to be the only way to determine that.

But for at least me it seems that running the test with someone who says they can hear it, using a song they say shows it well, is a worthwhile initial test.

Thanks again for everybody responding to this, we might actually be able to come up with a decent test here.

I'm leaning towards the playlist with pairs of the same song, which may or may not be the same format. As long as we can find a way to make them display identically it seems like its easy to implement. The remaining questions I have are: should song 1 and 2 be known? Say song one be WAV and song 2 be FLAC? Should it be all the same song or should half the trials be one song and the rest a different one?

My inclination is that if the person says they can hear it for a particular song, that just using that song should be sufficient for determining if they can distinguish or not when there is lack of foreknowledge.

If the test is with someone who says they can't or with someone who has never tried to distinguish or never listened to the two formats you probably do need a broad range of music.

John S.

KFal
2010-08-26, 15:20
Hi John,

I have not read the entire thread so apologies if there are any repetitions in my post.

What you want to do is a so-called ABX test where the crucial factors are the randomness and the double-blindness of the setup combined with a strict methodology of statistical evaluation. There is software available which does this for comparing for instance the results from different codecs or quality settings, see e.g. foobar2000. Unfortunately, this is not applicable here because I can't see a way to directly link foobar to controlling the Touch.

Anyway, there are specialists in these matters at hydrogenaudio, http://www.hydrogenaudio.org. They have experience to setup a proper ABX test in even more complicated situations and are usually helpful if the intent is properly described.

Karl

lrossouw
2010-08-26, 19:12
I'm leaning towards the playlist with pairs of the same song, which may or may not be the same format. As long as we can find a way to make them display identically it seems like its easy to implement. The remaining questions I have are: should song 1 and 2 be known? Say song one be WAV and song 2 be FLAC? Should it be all the same song or should half the trials be one song and the rest a different one?

My inclination is that if the person says they can hear it for a particular song, that just using that song should be sufficient for determining if they can distinguish or not when there is lack of foreknowledge.

If the test is with someone who says they can't or with someone who has never tried to distinguish or never listened to the two formats you probably do need a broad range of music.


EDIT: Updated method to ABX per Hydrogenaudio website. See post below.

Agreed with everything. I think you are referring to Format 3. Indeed you can run it with the same song, or different ones. Anywich way. The test won't be flawed as the songs are swapped randomly. Under the assumption that you cannot hear the difference it shouldn't matter that the songs are the same as you would essentially still be randomly picking answers.

*For format 1 & 2 I beleive it has to be the same song throughout*

You should pick songs that you beleive you can hear differences on.

In lay terms if you can consistenly pick out the differences then it means that it is not random and that there must be something in what you say. If you can't then it should not matter if the song is the same or not as you'd still be randomly guessing.

I've setup an spreadsheet to randomise the playlist and to fill in results for all 3 formats.

It is important to get setting up right. You shouldn't have an expectation that half could be different and half could be the same. So this spreadsheet sets up a random number of pairs like this. It could result in a scenario where only a couple of pairs are different or the same.

The spreadsheet just suggests how to setup the playlist. Someone will still physically have to do set it up. Obviously someone else needs to do all this.

EDIT: Updated method to ABX per Hydrogenaudio website. See post below.

Blue = inputs
Enter the song name(s) and press setup test. It will tell you what you need for each item in the list. Then you listen and once you are done you fill in your recorded the results and it tells you whether you can reject H0. Obviously don't press the setup button again after the test is started!

andynormancx
2010-08-27, 02:22
This came about because I (and others) say we can hear the difference between PCM and FLAC decoding on the Touch. Others emphatically state this is theoretically impossible and any claim that it is possible to hear is purely psychological caused by foreknowledge of which is playing.

I haven't seen anyone in this thread claim that it is impossible that FLAC and PCM might sound different when decoded on a Touch.

The black and white statements that have been made are:

- FLAC decodes to exactly the same bits as the WAVE
- a difference between FLAC and PCM decoding has not yet been able to be measured on the analogue out of the Touch

But that isn't the same as saying that it isn't theoretically possible that decoding FLAC and outputting on the analogue could sound subtly different to PCM on the Touch. I don't think anyone has stated that they believe it is impossible that the different load of decoding FLAC could somehow introduce some extra noise.

Phil Leigh
2010-08-27, 03:43
I haven't seen anyone in this thread claim that it is impossible that FLAC and PCM might sound different when decoded on a Touch.

The black and white statements that have been made are:

- FLAC decodes to exactly the same bits as the WAVE
- a difference between FLAC and PCM decoding has not yet been able to be measured on the analogue out of the Touch

But that isn't the same as saying that it isn't theoretically possible that decoding FLAC and outputting on the analogue could sound subtly different to PCM on the Touch. I don't think anyone has stated that they believe it is impossible that the different load of decoding FLAC could somehow introduce some extra noise.

I Agree with all of that + I would add the digital output to the assertion.

Has anyone actually measured the Touch CPU load for PCM vs FLAC? I can't believe it's very different...

andynormancx
2010-08-27, 03:54
Has anyone actually measured the Touch CPU load for PCM vs FLAC? I can't believe it's very different...
Of course, if it really does sound different, the difference might not from from noise from the CPU load. What if the noise was coming from the bus between the network cards and the CPU ? Then with less data being transferred with FLAC it could be FLAC that sounds "better" than WAV ;)

NewBuyer
2010-08-27, 05:43
Where did this come from?... I (and others) say we can hear the difference between PCM and FLAC decoding on the Touch. Others emphatically state this is theoretically impossible... What I was after was ... test if it is even possible to hear a difference... How wide spread the capability is and if its applicable to a wide range of music was not the emphasis ... I think it complicates what I was trying to get at, can a difference really be heard at all. I have stated before that its much easier to hear the difference on some songs than on others, so I don't think I was trying to say that its equally applicable to all music... at least me it seems that running the test with someone who says they can hear it, using a song they say shows it well, is a worthwhile initial test.
...


Good questions John - You're right that it can indeed quickly get complicated. It completely depends upon the population about which you are trying to make your "theoretically possible to hear a difference" conclusion. Are you trying to establish non-scientific evidence for something that is *only* applicable to simply yourself and a few others highly nonrepresentative of the general user base? Or, do you wish to find evidence that could reasonably describe the general population of users? If the former, your conclusions statistically speaking will of course be extremely biased and thus not of much use to anybody outside of the "special" group, since for example that group's perceptive abilities may be extraordinarily different from most others, or somehow merely connected to sloppy experiment design/lack of a control group and resulting placebo affect complications. What's more, any number of potential lurking variables can then also have much more than chance likelihood to in reality influence any apparent correlation, instead of the particular connection you are wishing to find evidence for via such a test. If the latter (i.e. you wish the test results to be generalizable to the greater population of users), then all sources of reasonably imaginable bias - e.g. self-selected subjects, special songs, specified listening equipment, etc - must certainly be controlled and minimized to the greatest possible degree, in order for the results to have validity in any statistical sense. You can still perform a test in the absence of these considerations and get collections of numbers/results/etc, but their validity and usefulness can of course be thus compromised. That said, if these concerns don't matter to you or to others, then great! It can still be fun to do. But otherwise, I still felt obligated to make these statements regardless, just in case anybody else reading this thread might relate to these observations and the associated potential issues with the actual statistical validity of any conclusions drawn.

Nonreality
2010-08-30, 02:14
Hi John,

I have not read the entire thread so apologies if there are any repetitions in my post.

What you want to do is a so-called ABX test where the crucial factors are the randomness and the double-blindness of the setup combined with a strict methodology of statistical evaluation. There is software available which does this for comparing for instance the results from different codecs or quality settings, see e.g. foobar2000. Unfortunately, this is not applicable here because I can't see a way to directly link foobar to controlling the Touch.

Anyway, there are specialists in these matters at hydrogenaudio, http://www.hydrogenaudio.org. They have experience to setup a proper ABX test in even more complicated situations and are usually helpful if the intent is properly described.

Karl
You really don't think that anyone that still doubts that there is a difference that they can hear is still onboard at this time is a credible person and can state that, you need drugs at this time.

lrossouw
2010-09-02, 21:16
OK I've updated the testing method. Hydrogenaudio testing involves this method: http://wiki.hydrogenaudio.org/index.php?title=ABX

This is each trial has 3 tracks. 2 of the tracks are known to be pcm and flac (A & B). Track X is unknown and one needs to decide whether X is the same as A or B. I suppose this method give the person who believe they can hear the difference the benefit of the doubt as they would in each trial have sample of both known cases available to them.

So in the interest of whoever wants to do these tests I've updated the spreadsheet to reflect this method for now.

They reccomend 16 as an optimal numebr to avoid listener fatigue, but have enough data. I've left it at 30 for now. Just delete rows as required.

Otherwise comments as above applies.

Note that in their method they most frequently also use the same track throughout. Independence is provided by the fact that X is randomly assigned in each case. Note that this does not mean X should be 50:50 split between A & B.

JohnSwenson
2010-09-03, 00:22
I have a little bit of time this weekend, I'm going to try and come up with a method so that wav and flac show up exactly the same on the screen.

I like the concept of a playlist pointing at the two files, it makes it simple.

John S.

lrossouw
2010-09-03, 01:42
I have a little bit of time this weekend, I'm going to try and come up with a method so that wav and flac show up exactly the same on the screen.

I like the concept of a playlist pointing at the two files, it makes it simple.

John S.

That's great John. Can you just do them in sets of 3 as described using playlists. This seems to be the preferred method by the Hydrogenaudio people. This is A = flac B = pcm and X = unknown. And you need to identify if X = flac or X = pcm. I think this should help you as you can listen to the unknown side by side with a flac and pcm version.

They seem to do it with the same music but I can't see why it won't work with different music either.

You could have a playlist of A, B, X1 , A, B, X2 or just one with the unknowns and be able to swap between that and a known flac version and a known pcm version.

You are allowed to switch between A,B and X as much as you like.