Blue or red pill?

[fas42]

14 minutes ago, STC said:

 

There was someone like him who used a JVC player, a mysterious clock, stacked speakers and 8 subwoofers. During his lifetime he probably visited more setups than anyone else and known to almost all audiophiles in my country. The first time I met him was when he tagged along another audiophile who came over for a visit. After he made several visits, he invited me over to his place but I procrastinated for along time considering his ridiculous setup. Finally, out of common courtesy I decided to visit him and invited my other audiophile friends to join me. None of them wanted to join me. Among them one guy who previously visited him criticized his bed room cum listening room (  10ft x 8ft) and his cheap system.

 

Having no choice, I reluctantly went there alone. 

 

That's when I learned not to look down at someone's setup based on the price or approach. I heard a good setup, much better than some tens of times more expensive system.

 

@fas42 could be doing something like that and until then I will give him the benefit of doubt.  

 

 

 

 

 

 

I've come across a few fellow travellers over the years - all have used very different methods and ideas; but the common element has been that they've understood that one has to be pedantically fussy about 'strange' areas of the setup. Of course, those areas are not really strange; they just happen to be focus points of weakness in the system, and by manipulating or addressing these the key audible artifacts, that really matter, can be sufficiently attenuated.

 

What these setups had in common were invisibility of the speakers, being able to project "big sound", a sense of deep immersion in the musical event captured in the recording - this is beautiful stuff to experience, and makes all the tiresome efforts to "get it right" worthwhile.

[Ralf11]

a boombox can produce  an almost hypnotic rhythm of pure sound, with the right drugs

[fas42]

Ahhh! ... I found a videotape, of one of my listening sessions ...

 

 

[SoundAndMotion]

7 hours ago, gmgraves said:

All ABX tests are generally done double-blind, but not all double blind tests are ABX. Simple double blind tests are done with some (hopefully) non-interested party simply switching randomly between two test units, where the listeners never know which DUT they are listening to and don't know when (or, indeed, if) the DUTs are being switched. ABX comparators are usually more complex than just someone turning a selector switch on some pre-amp or amp between two high-level inputs (for example). 

 

We are definitely not using the same terms.

I use double blind as described here and elsewhere. ABX tests as DBT's, where both the subject and the experimenter both (= double) don't know whether A or B is playing, are common in the scientific literature, but IME rare in audio forums. Most that I see are single blind or performed alone (using software). There is no need for double blind when the subject has no interaction with an experimenter, either because there isn't one (e.g. using software to compare two files using foobar2k, for example) or because they are separated (different rooms) during the trials (that's how I do experiments). In these cases, there is no reason to hope that the experimenter is a "non-interested party".

I'm not sure what Mani had in mind when he said switching between A and B would take "5-10 seconds at least", but it doesn't seem to be foobar.

When you mentioned that 

13 hours ago, gmgraves said:

I've never been convinced that the ABX comparator doesn't color the result.

I assumed you meant a hardware comparator, such as the one produced by the ABX company.

 

I'm not sure whether you meant to say ABX, rather than DBT, here:

6 hours ago, gmgraves said:

Ostensibly, the only thing a DBT can do is show differences between two test units in an instantaneous and sharp relief. It is not its purpose to show which is better or preferred, although I suppose it could be used for that, although the results would be very personal and not statistically computable.  

but it is not correct either way, although ABX is closer.

The standard ABX protocol is not used for preference testing. Auditory preference tests, such as MUSHRA (BS.1534) or  abc/hr (BS.1116), should be done without experimenter influence, either double blind (DBT) or by having the subject alone in the room.

[mansr]

3 hours ago, SoundAndMotion said:

We are definitely not using the same terms.

I use double blind as described here and elsewhere. ABX tests as DBT's, where both the subject and the experimenter both (= double) don't know whether A or B is playing, are common in the scientific literature, but IME rare in audio forums. Most that I see are single blind or performed alone (using software). There is no need for double blind when the subject has no interaction with an experimenter, either because there isn't one (e.g. using software to compare two files using foobar2k, for example) or because they are separated (different rooms) during the trials (that's how I do experiments). In these cases, there is no reason to hope that the experimenter is a "non-interested party".

When the "experimenter" is a computer, it is as good as double blind.

 

3 hours ago, SoundAndMotion said:

I'm not sure what Mani had in mind when he said switching between A and B would take "5-10 seconds at least", but it doesn't seem to be foobar.

The hypothesis is that identical files played from different storage media sound different. Presumably, the 5-10 seconds is the time it takes to stop the software player and start playing a different file.

 

3 hours ago, SoundAndMotion said:

The standard ABX protocol is not used for preference testing. Auditory preference tests, such as MUSHRA (BS.1534) or  abc/hr (BS.1116), should be done without experimenter influence, either double blind (DBT) or by having the subject alone in the room.

Preference testing is meaningless without first establishing that a difference exists.

[manisandher]

1 hour ago, mansr said:

The hypothesis is that identical files played from different storage media sound different.

 

That's a specific case of the more general hypothesis: a file played* back bit-identically can sound different.

 

Specific cases then include:

- different storage media

- different digital cables (spdif, USB, etc)

- different software player configurations (buffers, etc)

 

I'm considering which of these would be best for the ABX, and am leaning towards different software player configs. Once you're satisfied that there really is an audible difference between a file played back bit-identically (whether you hear it too, or whether I manage to prove it in the ABX), then we can certainly explore the other specific cases, if you have the time and inclination.

 

*The hypothesis very much includes conversion from digital to analogue during playback, as this is where the effects of different noise profiles entering the DAC might come into play.

 

Mani.

[manisandher]

3 hours ago, manisandher said:

 

That's a specific case of the more general hypothesis: a file played* back bit-identically can sound different.

...

*The hypothesis very much includes conversion from digital to analogue during playback, as this is where the effects of different noise profiles entering the DAC might come into play.

 

Paul McGowan shares his views as to what might be happening here:

 

 

 

The relevant discussion starts at around 12 mins.

 

Mani.

[gmgraves]

12 hours ago, SoundAndMotion said:

We are definitely not using the same terms.

I use double blind as described here and elsewhere. ABX tests as DBT's, where both the subject and the experimenter both (= double) don't know whether A or B is playing, are common in the scientific literature, but IME rare in audio forums. Most that I see are single blind or performed alone (using software). There is no need for double blind when the subject has no interaction with an experimenter, either because there isn't one (e.g. using software to compare two files using foobar2k, for example) or because they are separated (different rooms) during the trials (that's how I do experiments). In these cases, there is no reason to hope that the experimenter is a "non-interested party".

I'm not sure what Mani had in mind when he said switching between A and B would take "5-10 seconds at least", but it doesn't seem to be foobar.

When you mentioned that 

Doesn't matter. An ABX hardware test uses a comparator, a piece of equipment which chooses X. 

 

12 hours ago, SoundAndMotion said:

I assumed you meant a hardware comparator, such as the one produced by the ABX company.

Yeah, that should be pretty obvious.

 

12 hours ago, SoundAndMotion said:

but it is not correct either way, although ABX is closer.

The standard ABX protocol is not used for preference testing. Auditory preference tests, such as MUSHRA (BS.1534) or  abc/hr (BS.1116), should be done without experimenter influence, either double blind (DBT) or by having the subject alone in the room.

OK. 

[Fitzcaraldo215]

41 minutes ago, gmgraves said:

Doesn't matter. An ABX hardware test uses a comparator, a piece of equipment which chooses X. 

 

Yeah, that should be pretty obvious.

 

OK. 

Ahem, George, an ABX comparator can also exist as a piece of software, not hardware or equipment.  For example, Foobar has ABX capability useful for comparing different digital files from a PC through an identical playback system with near instantaneous switching.  

 

As as someone already said, ABX is a conceptual test protocol, not necessarily a piece of equipment.  You are somewhat out of date in your understanding, regrettably.

[esldude]

5 hours ago, manisandher said:

 

Paul McGowan shares his views as to what might be happening here:

 

 

 

The relevant discussion starts at around 12 mins.

 

Mani.

 Where is the measurement data showing the clock changes?  If they can't measure, then how do they work on improving it?

[fas42]

8 hours ago, manisandher said:

 

That's a specific case of the more general hypothesis: a file played* back bit-identically can sound different.

 

Specific cases then include:

- different storage media

- different digital cables (spdif, USB, etc)

- different software player configurations (buffers, etc)

 

I'm considering which of these would be best for the ABX, and am leaning towards different software player configs. Once you're satisfied that there really is an audible difference between a file played back bit-identically (whether you hear it too, or whether I manage to prove it in the ABX), then we can certainly explore the other specific cases, if you have the time and inclination.

 

Mani.

 

I find it interesting that some people seem oblivious to the major changes in perceived quality when altering the software used for playback, and the settings used - on 2 quite ordinary PCs, one a desktop, the other the laptop, I went through quite a long process for each, on separate occasions, finding the player, and settings which gave the best sound over the inbuilt circuitry, and auxiliary, basic monitor speakers. Different players gave the best result for each one - and reverting to the much lower standard of the usual suspects is then quite irritating to the ear.

[fas42]

5 hours ago, manisandher said:

 

Paul McGowan shares his views as to what might be happening here:

 

The relevant discussion starts at around 12 mins.

 

Mani.

 

Hmmm ... same ol', same ol' - isn't it amazing, that the precision of the analogue areas may be affected by noise and interference from digital circuitry behaviours, etc - gosh, you would think those stupid electrons on the two sides of the fence would know how to keep out of each other's way, rather than relying on human engineers to skillfully keep them apart   ...

[sandyk]

7 minutes ago, fas42 said:

 

I find it interesting that some people seem oblivious to the major changes in perceived quality when altering the software used for playback, and the settings used - on 2 quite ordinary PCs, one a desktop, the other the laptop, I went through quite a long process for each, on separate occasions, finding the player, and settings which gave the best sound over the inbuilt circuitry, and auxiliary, basic monitor speakers. Different players gave the best result for each one - and reverting to the much lower standard of the usual suspects is then quite irritating to the ear.

 

Yes, many people, E.E.s and Software people especially, seem to think that all software players must sound the same provided that the same binary data is exported to the DAC. Thus many insist that the Foobar 2K comparator should be used for comparison purposes ! Not all players even play from System Memory.

There are quite a few software players for both Windows and Mac that sound considerably better than the " Jack of all trades, Master of none" Foobar 2000.

[mansr]

1 minute ago, sandyk said:

Yes, many people, E.E.s and Software people especially, seem to think that all software players must sound the same provided that the same binary data is exported to the DAC.

Here we go again, insulting entire professions. Do you seriously believe it's possible to construct and program a computer without knowing how it works?

 

1 minute ago, sandyk said:

Not all players even play from System Memory.

Oh, but they do. There is no other way to write one.

[sandyk]

16 minutes ago, mansr said:

Here we go again, insulting entire professions. Do you seriously believe it's possible to construct and program a computer without knowing how it works?

 

Oh, but they do. There is no other way to write one.

 

That is not what I am saying. The  simple fact is that many software player programs do sound different.

It's your problem if you are unable to hear what so many other C.A. members report, especially with the various Mac software players. 

Many even report hearing a difference between the various CD Ripping programs used, quite a few expressing a preference for a more "solid" sound from dBPoweramp compared with E.A.C. !

That is with correct checksums from both Rippers too.

 

Perhaps I didn't word my reply carefully enough, but many players such as .VLC Media player, Power DVD etc. etc. do NOT load the contents into system memory before playing them. This is especially evident when you play from a USB memory stick for example, where there may be several seconds of delay before play starts, where you can see it's LED flashing before play starts , then cease when  the file is being played. 

[mansr]

7 minutes ago, sandyk said:

Perhaps I didn't word my reply carefully enough, but many players such as .VLC Media player, Power DVD etc. etc. do NOT load the contents into system memory before playing them.

They do. There is no other way of getting the data to the DAC.

[fas42]

13 minutes ago, sandyk said:

Perhaps I didn't word my reply carefully enough, but many players such as .VLC Media player, Power DVD etc. etc. do NOT load the contents into system memory before playing them. This is especially evident when you play from a USB memory stick for example, where there may be several seconds of delay before play starts, where you can see it's LED flashing before play starts , then cease when  the file is being played. 

 

Sometimes it can be easy to pick the obvious signs of non-optimised programming - on the laptop, the "poor" performers were constantly driving the physical media throughout the track, and chewing up significant CPU cycles - Media Monkey, which turned out best, buffered like crazy initially - and then ignored the drive; and the CPU effectively went to sleep during the replay ... the effort had been made to tune the software to just do the job it had to do, well - by not disturbing the rest of the system any more than necessary.

[sandyk]

21 minutes ago, mansr said:

They do. There is no other way of getting the data to the DAC.

With a USB memory stick it's clear when the contents were NOT buffered before playing, when the LED continues to flash during playing. Does that suit you better ? Note also that jRiver didn't originally play from System Memory, as Jim didn't believe that it made any difference. It was customer demand that saw it happen !

  As is so often the case, you are playing word games , when you know damn well what I  , and others, are trying to say.

With you, it looks like we need to carefully dot all the "i"s and cross the "t"s every time we say something to you.

[sandyk]

25 minutes ago, fas42 said:

 

Sometimes it can be easy to pick the obvious signs of non-optimised programming - on the laptop, the "poor" performers were constantly driving the physical media throughout the track, and chewing up significant CPU cycles - Media Monkey, which turned out best, buffered like crazy initially - and then ignored the drive; and the CPU effectively went to sleep during the replay ... the effort had been made to tune the software to just do the job it had to do, well - by not disturbing the rest of the system any more than necessary.

 

Mansr knows that far better than most.

What we need is for highly qualified members like Mansr and Archimago to see (hopefully) from listening results by members like Mani, that there are still some unexplained areas where current theory doesn't quite cut it, and carry out further investigations.

 

[mansr]

1 hour ago, sandyk said:

With a USB memory stick it's clear when the contents were NOT buffered before playing, when the LED continues to flash during playing.

Wrong. When reading from a storage device, the data is placed in RAM (system memory). The USB controller then retrieves the data from the same RAM when sending it to the DAC. In a normal computer, there is no way to bypass the RAM buffer, nor is there any reason to do so.

[sandyk]

5 minutes ago, mansr said:

Wrong. When reading from a storage device, the data is placed in RAM (system memory). The USB controller then retrieves the data from the same RAM when sending it to the DAC. In a normal computer, there is no way to bypass the RAM buffer, nor is there any reason to do so.

 

Well, looks like all the members who pestered jRiver must be wrong, and my own (and others) observations based on the activity LED of the USB memory stick are wrong too !

Using cPlay, as I described, there is a delay before playing starts with the activity LED flashing , then when  play starts the LED stops flashing and the USB memory stick can be removed. With other programs such as .VLC Media player etc. where the activity LED continues to flash while playing, you can  NOT remove the USB memory stick without play stopping.

There is obviously something very different happening.

In this case , I believe that Frank summed it up nicely. He pointed out all the extra activity going on which could change the noise profile.

So you are claiming that playing a file from System Memory using certain programs is all BS ?

I doubt that you will have a great deal of support for that claim.

[kumakuma]

13 minutes ago, sandyk said:

 

Well, looks like all the members who pestered jRiver must be wrong, and my own (and others) observations based on the activity LED of the USB memory stick are wrong too !

Using cPlay, as I described, there is a delay before playing starts with the activity LED flashing , then when  play starts the LED stops flashing and the USB memory stick can be removed. With other programs such as .VLC Media player etc. where the activity LED continues to flash while playing, you can  NOT remove the USB memory stick without play stopping.

There is obviously something very different happening.

In this case , I believe that Frank summed it up nicely. He pointed out all the extra activity going on which could change the noise profile.

So you are claiming that playing a file from System Memory using certain programs is all BS ?

I doubt that you will have a great deal of support for that claim.

 

As mansr said, files are always played from system memory.

 

What you're referring to is whether or not the program loads the entire track or just part of the track into system memory before starting playback.

[mansr]

1 minute ago, kumakuma said:

As mansr said, files are always played from system memory.

 

What you're referring to is whether or not the program loads the entire track or just part of the track into system memory before starting playback.

Exactly. In addition, any decent OS will detect the access pattern and preload the remainder of the file before the application has asked for it.

[STC]

I have been using JRiver and did experiment with Memory playback to have better sync with different DACs. I think there is no way JRiver could bypass the RAM. If I understand correctly, it is impossible to run anything without RAM. The computer won’t even boot. 

 

Going back to JRiver’s memory playback, my understanding is it can hold decoded data up to 1GB only.  

 

 

•  

NEW: Improved memory playback

« on: July 15, 2013, 11:45:13 am »

 

---

Overview
Memory playback now holds decoded data in memory instead of encoded data.

This means playing any form of lossless (WAV, FLAC, APE, ALAC, etc.) will have identical data in memory and identical resource usage.

Benefits
The theoretical benefits of memory playback are that no disk or network I/O occurs while playing and that CPU load during playback could be reduced.

Technical Considerations
With a modern computer, playback of a standard CD-quality file will have the fully decoded file in memory in around one second.

Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage).

In some cases, the work of decoding and caching a file quickly as a track starts could lead to other problems.  For example, when playing over Wi-Fi some machines exhibit high resource usage when reading a file quickly.  This resource usage as a track starts could lead to audio playback glitches.

Some files like DSD played as PCM have very large decoded data so that they might require more memory to cache than (most) any system has.  In these cases, the program will cache 1GB, play it mostly out, then cache another 1GB, etc.

With memory playback enabled, the player will no longer report a real-time bitrate (ie. 872 kbps) during playback.  This is because asking the decoder its current bitrate is not possible when the decoder has finished with the current track completely in the first couple seconds of playback.

Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback.  

The option was added due to popular demand.

How to Use
You enable or disable memory playback in Options > Audio > Play files from memory instead of disk.

It is off by default.

[gmgraves]

3 hours ago, Fitzcaraldo215 said:

Ahem, George, an ABX comparator can also exist as a piece of software, not hardware or equipment.  For example, Foobar has ABX capability useful for comparing different digital files from a PC through an identical playback system with near instantaneous switching.  

 

As as someone already said, ABX is a conceptual test protocol, not necessarily a piece of equipment.  You are somewhat out of date in your understanding, regrettably.

Yes, I'm aware of that. That's the reason I was careful to say "hardware".