You need a program to browse your collection and select the songs you want to hear.
As these application comes with different codecs and drivers there might be audible differences between them.
A popular piece of free ware is Foobar. Its claims are very modest:
Does foobar2000 sound better than other players?
No. Most of “sound quality differences” people “hear” are placebo effect (at least with real music), as actual differences in produced sound data are below their noise floor (1 or 2 last bits in 16bit samples). foobar2000 has sound processing features such as software resampling or 24bit output on new high-end soundcard's, but most of other mainstream players are capable of doing the same by now.
http://www.foobar2000.org/FAQ.html
Others claim high-end performance due to using their software like cPlay or XXHighend.
I would like to present a minimalist GUI-less audio player for Windows Vista, which uses Vista's new audio WASAPI in exclusive mode, and with "Pro Audio" priority.
It loads the whole audio file into memory before playing.
The main feature of this player is that it does not have a GUI interface.
I intentionally do not do any GUI for this player.
I strongly believe that any interaction with any part of the OS influences the sound.
Once you get both direct sound and kernel streaming both working you might find the differences between players and even various plugins start to fade. Some audiophiles here have indeed caught audiophile nervosa when it comes to PC audio and hear the difference when they switch to a different color drive tray. I'm not saying there are not subtle differences between players in you do things RIGHT, but I am saying if you do things WRONG the differences then become VERY audible. To me, getting bit perfect playback gets you 90% of the way there, and after that you can tweak and compare to your hearts content.
If we assume that a media player is program having an interface allowing you to pick a song and send it to the OS audio, there is little reason to expect any difference in sound between them because OS audio=OS audio.
There are claims that even in this case they can sound different.
The reasoning is that any electrical activity going on inside the computer will affect sound quality. Probably because more activity=more disturbance of the DA of the sound card (jitter). RFI and PSU are often mentioned.
My sense is that subjective impressions of these media players sounding different is probably wrong. I have some experience here. I was playing Foobar2000 to test my iPad remote. As soon as I played one of my reference clips, I was shocked that it sounded "better" than I remembered. So I play the same track with the media player and it indeed sounds worse to me. I think at first it has to do with a different audio pipeline. I research and confirmed that it was using the identical pipeline to WMP. With that knowledge, I time aligned WMP and Foobar next to each other so that I could switch over in 1 to 2 seconds. In that situation, I could find no difference at all. Placebo effect was incredibly strong here. I can't explain it in words as to how much better I thought Foobar sounded the first time I started it.
Of course a media player is not a library manager only.
It is also the glue between Codecs and the audio device.
It will invoke a Codec to translate the content of the audio file to something the audio device (raw PCM) will understand.
It controls the communication with the audio device. This is a matter of buffer management.
Maybe some of the audible differences between media players are due to the way buffer management is implemented.
Here's what I know.
1. Changing player software has affected the sound on both my Windows computers (one PIV XP Pro with 1 Gig RAM, one I5 W7 Pro with 12 Gig RAM).
2 The effect on sound persists when the players compared are running in a bit perfect mode, i.e. delivering the exact PCM samples without any gain changes, resampling or other DSP. In several cases, this was verified by loopback tests.
3. The load averages you quote are probably derived from samples taken by the operating system. From considerable experience with computer system performance analysis I know that these statistics are not to be trusted, as the sample times are correlated with operating system activity and usually underestimate operating system overhead.
4. Audio activities tend to be periodic and are related to buffer sizes, e.g. the size of disk buffers, the size of buffers used for lossless decoding, the size of buffers used by the sound card, etc. When buffers are being filled or emptied, the CPU overhead is temporarily 100%, and this constitutes a periodic demand that manifests in periodic currents on power and ground traces, etc.
5. It is possible to detect (measure) the effect of these periodic cycles in the output of DACs, as the jitter spectrum is affected by these cycles. The effect of these can be seen as sidebands from the phase modulation of test audio signals and the sidebands move as software buffer parameters are changed. These effects have been measured by researchers.
6. When you listen to music through a DAC you are listening to the clock, much as when you listen to an LP you are listening to the motion of the turntable platter. The clock is affected by electrical noise and also mechanical vibration. In addition, the distribution circuitry between the clock oscillator and the actual switching circuits in the DAC is affected by small amounts of noise in the power and ground wiring of these circuits which move the switching threshold and thereby introduce jitter in the effective clock. That's a known physical mechanism for how EMI/RFI can make it through to the analog output of a DAC even if the clock in question is supposedly local to the DAC.
7. Most of the supposed Operating System overhead is transient and depends on user action, e.g. the overhead of graphic eye candy exists only for short bursts of time as in moving windows around, etc. These do not represent a continuous and incessant impact on the sound that gets attributed to the musical reproduction.
8. Some of the common audio players may have "low overhead" measured on average as you suggest, but when looking at system statistics these still manage to be one of the largest consumers of system resources.
9. With the memory playback software that I use (cPlay) I do not hear any difference between playback of FLAC and playback of WAV files. This is not surprising, because cPlay nearly always completes all the necessary FLAC decoding at the start of each track, generally a silent period where there is no music playing.
10. Many audiophiles note differences they hear. Some are more careful experimenters than others. Some may correctly attribute causes to the effects they hear, others may not. This does not make their work insignificant or useless.
11. The posters who are reporting on compiler changes are often the authors of the software and the person who ran the compilations involved. Presumably they have debugging tools and can tell what is happening inside the operating system. None of this is to be considered "magic" in any way. The same goes for driver software. In any event, for most people who aren't doing compilations they do their testing in terms of specific program release versions and I don't find most of these people talking much about compilers.
Tony Lauck
Now for a concrete example. Let's take a simple program that is just copying audio data from a file to a buffer and then to an simple output port. It has two threads, one reading the file and putting the data in the buffer, and one taking data out of the buffer and putting it on the out port using an external clock to time the opperation. The first thread waits until the buffer is empty then fills it up and goes back to sleep. (in reality there would be two buffers used in a ping pong arrangement, but that is irrelevant to the issue at hand). So lets take this program and make two copies, one which has a small buffer and one which has a large buffer.
The total amount of processing is exactly the same, the code is exactly the same, but is the ground plane noise the same? NO! In the case of the small buffer the first thread spends a fairly short period of time waiting since the buffer empties out quickly. It spends a small amount of work often. With the large buffer each time it wakes up it has to handle a lot more data, but it waits a much longer time between sessions.
So why does this matter? If you look at the "work performed by the thread" over time the large buffer version shows a very "bursty" activity, but the small buffer shows a much more uniform activity. If you look at this in the frequency domain the small buffer version is dominated by relatively low intensity at high frequencies, mostly above the human hearing range. But when you look at the large buffer version you see higher intensity at much lower frequencies that are right smack dab in the middle of the human hearing range. This latter noise is going to have a much bigger affect on audibility. And note this was exactly the same code, just different buffer sizes.
Think what can happen when you are comparing different programs that use very different program architectures.
As an analogy, think about getting a group of people from point A to point B, either using a two seater sports car or a 30 person bus. The sports car has to go much faster and more often, the bus can only take a few trips and lumber along. But the result is the same. All the people get from poingt A to point B in the same total amount of time. But if you stand at the side of the road and have to put up with the noise, is it the same?
Today we totally isolate the USB and Processor so the noise generated by all that action above is kept away from the sensitive DAC chips and Audio Oscillators. This also breaks the ground path to the computer which is also a huge deal in keeping the sonics on par with what customers really need.
AmirM measured the jitter performance of two media players.
Surely the identical bits are being played in either case. And of course the hardware is the same and the DAC is not even inside the PC. What explains the difference is that the CPU activity in the case of WMP is very different in the way it buffers (reads) a big chunk of the file first and then cruises. That burst of activity has created noise that has travelled through the ground coupling to the external DAC, polluting its reference or clock, causing those distortion sidebands.
Often a bit more is done than sending a file to the audio device only.
Sample rate conversion (SRC) is a nice example.
The way DSP is implemented is crucial for the results.
You do have to choose your algorithms carefully, program it correct and very important, the variables used should have the right precision.
Roughly speaking, a 16 bits audio path is inadequate, any DSP will degrade de sound probably due to quantization error.
32 bits is fine, most major OS use it. The artifacts are small and probably not audible most of the time.
Best result needs a 64 bit audio path. A lot of pro-audio software uses this.
Even when doing many calculations (exactly what happens when producing audio) the precision is such that any artifact is well below the noise floor of top quality gear.
64 bits and still artifacts? Yes, everything on earth is finite. Analogue components don’t have an infinite precision, it ends definitely in the thermal noise. Likewise DSP has a finite resolution but as long as it remains below the (thermal) noise floor we won’t notice.
Drivers can make a difference.
There are examples of drivers incapable of delivering bit perfect output.
If de media player allows you to do so, you can select different drivers.
Look for drivers allowing for bit perfect playback like ASIO or WASAPI.
There is a strong believe in the computer audiophile community that any activity going on during play back has a negative impact on sound quality.
Some media players can decode an entire track and loads it in memory to avoid access to the hard disk and the processing needed to decode the audio during playback.
This is called memory playback.
The fun about computer based audio is that you can simply try a lot for free.
Download Foobar or MusicBee and do a listening test, try different drivers, memory playback, digital volume control, etc.
But don’t forget the ergonomics, it is the tool you will use to handle your audio.
The ideal media player has excellent sound quality and an excellent interface.
My observations on creating a computer-based system - Tony Lauck
Music Software - John Swenson
MEASUREMENTS: Bit-Perfect Audiophile Music Players - Archimago's Musings