[dallan]

I use Amarra, originally full version but I have updated several times.

 

[r010159]

   
Good article, here's another - http://archimago.blogspot.com/2013/05/measurements-bit-perfect-audiophile.html - in which 6 pieces of software are tested, including some DSD tests. So, if we can trust that a piece of software claiming to be bit-perfect is in fact bit-perfect... that is, the exact data from your file is going to your DAC unadulterated, the exact same bits are making it in the exact right order from point A to point C (despite the detour at point B, the media player)... where do the discrepancies in sound come from? Jitter is a possibility, expectation bias is another, what other pieces to this puzzle are there? I can't imagine any sort of processing happening prior to hitting the DAC that would mean a change in sound with no change in data (bit-perfection). 

 
I do not understand this. In blind testing the guitarist successfully chose J River. I notice an obvious difference with the Audirvana+, which is not necessarily a good change. I will try with integer mode off, like THAT should make a difference. I do not think so. The USB interface, the CoreAudio stack  (which Audirvna+ replaces) and the cable are the only parts left in the comparison between players with the wave editor.The only difference with my blind testing is in Audirvana's case that bypasses CoreAudio driver. Why the difference between J River and Fidelia? I am reaching here, but perhaps the software interface which the player chooses to use to the digital output, the USB interface, like the Audirvana+ player. Maybe jitter is part of this, the more direct route works better. I will report the results with direct mode and integer mode off. I will coopt the guitarist in this again. She has no stake in which one sounds different and better.
 
EDIT: The article on differences only provides a frequency, noise, THD plots, and so forth. These plots come from an analysts of cumulative data, essentially summing all the waveform data into a composite. This can show very little but some differences. But a waveform by waveform comparison of the entire track can yield more obvious aperiodic results. I know. I am reaching for a cause to explain results. But I think that this is something to consider.
 
Bob Graham
 
PS: Here is an interesting article by the maker of Audirvana+. Sure, he has a stake in his article. But he does provide notes that refer to outside supporting reference material. One item he highlights is jitter. 
 
http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf

 

[r010159]

Here is what I did. I recorded into a wave editor a track from each music player. This is between Audirvana+ and J River. I then brought the two stereo waveforms together in one edit window, side by side. I then aligned both of their zero crossings at the start of each waveform. I checked this by the "find zero crossings" function. I then inverted one waveform and then mixed them together. I should end up with nothing, one canceling the other out.  I ended up with a definite waveform. It end up going from an almost nonexistent periodic waveform to a much larger amplitude waveform that was complex in shape. Furthermore, later in time, there are time spans where the two waveforms do cancel each other out.
 
I do not know yet if this is audible. I have to figure how the amplitude maps to the decibel scale, But there is definitely a difference. Also, the difference in zero crossings wobbles a bit. I confirmed this by the successive location of zero crossings. This is what I think is jitter. This is probably what showed up as an almost nonexistent periodic like waveform mentioned above.
 
What does this prove? First, there is measurable jitter. Now what causes those relatively larger amplitude, more complex, but still periodic-like waveforms? Either jitter can be significant enough to mismatch the waveforms  to cause this to happen  Or at least one player is not bit-perfect all the time. It is interesting how the topic of jitter keeps coming up. I will continue my research attempting to explain the difference for instance buy finding differences in configuration of the music players.
 
Remember what I mentioned earlier about Audirvana+ allowing the user to change the settings of a filter?This can be another explanation. J River just has implemented a set of fixed values. But this is one example of a tradeoff by the decision to use differing filter values.
 
Bob Graham

 

[TrollDragon]

I really don't know what you are looking for in an answer as I don't really spend that much time listening to the equipment.
 
I fired up Miles Davis "Kind of Blue" in Fidelia tonight,  optical out to the E17 docked in the E09K, then Line Out to the tube amp. Miles just sounds amazing on the GMP 8.300 D Pro's through a nice Soviet 6Н23П.
 
Isn't it all about enjoying the music?

 

[r010159]

  I really don't know what you are looking for in an answer as I don't really spend that much time listening to the equipment.
 
I fired up Miles Davis "Kind of Blue" in Fidelia tonight,  optical out to the E17 docked in the E09K, then Line Out to the tube amp. Miles just sounds amazing on the GMP 8.300 D Pro's through a nice Soviet 6Н23П.
 
Isn't it all about enjoying the music?

 
What you are saying sounds too reasonable. 

 I am just trying to prove that the difference I am hearing between the music players is real and not imaginary. I am a bit anal about this topic.
 
I personally enjoy all the players mentioned. But I prefer Audirvana+ and Amarra. Both have a type of ambiance to the sound, with Amarra actually sounding warmer (more analog) to me. But I think the Fidelia and the J River player are probably more accurate.
 
So there, I am commenting about the subjective aspect of all of this. 

 
Bob Graham
 
PS: I do like Miles Davis "Kind of Blue". IMO Fidelia is a good player, worth every penny.

 

[TrollDragon]

   
What you are saying sounds too reasonable. 

 I am just trying to prove that the difference I am hearing between the music players is real and not imaginary. I am a bit anal about this topic.
 
I personally enjoy all the players mentioned. But I prefer Audirvana+ and Amarra. Both have a type of ambiance to the sound, with Amarra actually sounding warmer (more analog) to me. But I think the Fidelia and the J River player are probably more accurate.
 
So there, I am commenting about the subjective aspect of all of this. 

 
Bob Graham
 
PS: I do like Miles Davis "Kind of Blue". IMO Fidelia is a good player, worth every penny.

 
Fully understood, carry on good sir with your analysis!
 
I am moving on to some Sonny Rollins right now.

 

[r010159]

Hello!
 
I have some results. I will get to the point. There are differences in the output of J River and that of Audirvana, Both claim to be bit-perfect. All relevant configuration parameters between players, and the same track was used for testing.  It is interesting that the differences between them seem to cancel each other out. The frequency spectrum is an empty graph, like one would think. But obviously there are differences, some significant.
 

 
The waveform of the difference between the two players,
 

 
The waveform from Audirvana for comparison. 
 
I want to note that both images are from the same track, and pictures the exact same regain of the wave. The only cause I can think of that is fairly random in nature is jitter.
 
Any comments?
 
Bob Graham

 

[groovyd]

I recently started demoing JRiver (about a month ago) and cued up the exact same track in both iTunes and JRiver and had then playing at the same time just switching between which was being output to my McIntosh D100 DAC.  I verified this actually was switching by adjusting the volume of each and verifying the DAC actually reporting the correct bitrate on the display for JRiver vs the Midi setting bitrate for iTunes.  I compared the two using a number of songs in my library like this being sure to always set the midi output so that the two would both agree (in other words 96/24 for a 96/24 track, etc).  With no additional processing from the JRiver DSP or the iTunes EQ or audio units.  Switching back and forth I heard a clear difference but it only had an effect on the very high frequencies (10k+).  What I found was JRiver was less siblant and sounded more natural in these high frequencies where iTunes would lose the details in the highs.  Things like cymbals, singers S's, drum rim taps, claps, etc.  The JRiver output was clearly clearer.  Since then I have been using it exclusively.  The other advantage of JRiver is it has various DSP settings for things like crossfeed and high quality volume leveling.  It does all processing in 64 bit and therefore can apply most of these DSP operations without losing any musical precision.  For example if you feed a 44/16 track it does all processing and outputs 44/32 to my DAC which gives it those extra 16 bits to hold the LSBs of division.  In any case it is clear it retains those fractional bits until the very end.
 
My biggest problem is that I cannot use Direct or Integer mode because I rely on Core Audio to mix the audio from various applications like Skype and web video while listening to music.  I want to be able to still answer calls and watch web videos which all get locked out if I turn on Integer mode.  According to JRiver however this has no material affect on what actually is delivered to the DAC.  Atleast they claim that the same values are being sent to the DAC regardless of Integer mode or CoreAudio, both they say are bit perfect.
 
My understanding of jitter is it is the micro second jitter of the sample clock that the DAC is being gated by caused by the hardware clock containing this variability.  I was also under the impression that Async USB prevents this since the clock is referenced off the DAC side not the computer side assuming the DAC hardware clock is low jitter then the software has nothing to do with it.  It is simply sending a stream of numbers which are the same on every playback of the same file regardless of hardware clock jitter.
 
In comparing both waveforms you may want to try using something like matlab to calculate cross-correlation between the two over time and see if the 'jitter' you are referring to is really the difference.

 

[groovyd]

What I would like to see done is to forget the DAC and just do a bus grab of the digital data being sent via each SW player.  Lets first just see if the data is identical for each player playing the same song.  This is something you can do a binary diff of.  Im not convinced jitter is at the mercy of the SW unless it is unable to fill the USB data buffer headed to the DAC then samples are missed.

 

[r010159]

  [snip]
 
My understanding of jitter is it is the micro second jitter of the sample clock that the DAC is being gated by caused by the hardware clock containing this variability.  I was also under the impression that Async USB prevents this since the clock is referenced off the DAC side not the computer side assuming the DAC hardware clock is low jitter then the software has nothing to do with it.  It is simply sending a stream of numbers which are the same on every playback of the same file regardless of hardware clock jitter.
 
In comparing both waveforms you may want to try using something like matlab to calculate cross-correlation between the two over time and see if the 'jitter' you are referring to is really the difference.

 
I think there is also software induced jitter. This is where kernel extensions are not very well behaved and take up inordinate amount of exclusive processing time. I have had device driver problems like this in Windows.
 
I believe you have a good idea with using matlab. I am not convinced it is jitter, but the only possibility that comes to mind.
 
Bob Graham
 
EDIT: [Was a long winded analysis of waveforms which turned out to be in error]

 

[groovyd]

Well I am an embedded software engineer who has written to the wire level drivers for DACs in the past and typically between the USB and DAC there would be a FIFO buffer of at least 3-4 KB to hold the samples which are then clocked into the DAC using a local hardware clock next to the DAC which has jitter of its own and is not under SW control by the host.  The only way the host SW can have any affect on the DAC output is to starve the buffer and not keep the buffer full.  But I wouldn't call this jitter, it is considered a 'buffer under-run error' which normal hw/sw design avoids at all cost because you will certainly hear this sort of problem and it would more then piss off any user, not just an audiophile.  Could be wrong but I would expect the USB interface of any decent DAC has a sufficient buffer to avoid this and considering USB has more then enough bandwidth to completely fill the buffer at a moments notice at any bit rate especially Async USB where the DAC-side clock is in charge of when data is delivered.
 
I recommend running a cross correlation to find out if the two waveforms are slowly shifting in time.  A cross correlation should have a peak at the number of samples the two waveforms are shifted in time.  Take frames of the audio say 1K and run the correlation between them and plot the result over the length of the track should give you a graph of the shift in timing in units of samples. If it is flat zero then there is no 'jitter' at the 1K resolution, then try halving the frame size until you see the jitter.
 
I think the only true way to answer this though is to snoop the data on the USB bus going to the DAC using the various players and do a simple binary diff on that data to see if they are identical or not.  I am not convinced pulling this data using a SW redirect is giving you the same data that is actually being sent over the bus.  Could even use a logic analyzer to grab the usb data and save it.

 

[r010159]

  Well I am an embedded software engineer who has written to the wire level drivers for DACs in the past and typically between the USB and DAC there would be a FIFO buffer of at least 3-4 KB to hold the samples which are then clocked into the DAC using a local hardware clock next to the DAC which has jitter of its own and is not under SW control by the host.  The only way the host SW can have any affect on the DAC output is to starve the buffer and not keep the buffer full.  But I wouldn't call this jitter, it is considered a 'buffer under-run error' which normal hw/sw design avoids at all cost because you will certainly hear this sort of problem and it would more then piss off any user, not just an audiophile.  Could be wrong but I would expect the USB interface of any decent DAC has a sufficient buffer to avoid this and considering USB has more then enough bandwidth to completely fill the buffer at a moments notice at any bit rate especially Async USB where the DAC-side clock is in charge of when data is delivered.
 
I recommend running a cross correlation to find out if the two waveforms are slowly shifting in time.  A cross correlation should have a peak at the number of samples the two waveforms are shifted in time.  Take frames of the audio say 1K and run the correlation between them and plot the result over the length of the track should give you a graph of the shift in timing in units of samples. If it is flat zero then there is no 'jitter' at the 1K resolution, then try halving the frame size until you see the jitter.
 
I think the only true way to answer this though is to snoop the data on the USB bus going to the DAC using the various players and do a simple binary diff on that data to see if they are identical or not.  I am not convinced pulling this data using a SW redirect is giving you the same data that is actually being sent over the bus.  Could even use a logic analyzer to grab the usb data and save it.

 
An experienced embedded systems programmer! Thanks for joining in! Yes, I do understand about the buffers. And the data is buffered to the USB. So the only thing that can happen is over-run or under-run errors, the  candidate being under-run errors.  I guess I am tired and not thinking.

 I agree that a correlation analysis is warranted. A data snooper would be the best choice. I do have a storage oscilloscope. But this is not practical.  A logic analyzer would work. I do have a PC based logic probe.
 
[deleted reference to previous post]
 
Note: I do see the zero crossings of the two waveforms to vary a little with respect to each other. This is what had me think of jitter.  But as you say, this should not be.
 
Bob Graham

 

[groovyd]

I can believe each player has some filtering of some sort even in it's default settings, not because they are actually filtering the data perhaps because some open source library they are using is doing it before they even get it simply by decoding the file.  Granted lossless files should decode identically across all players assuming they are implimented properly but anything lossy will indeed have a different output  depending on the precision of the decoder and the various decode algorithms sometimes used to trade off speed and precision.  Let's assume a lossless file to make this simple.  So we would expect the data sent over the USB to be simply the same as the audio file decodes to in raw format.  So take a short clip of lossless data with known values and see if the data heading to the DAC is the same sequence.
 
Personally I heard a distinct difference between iTunes playback and JRiver and my ears aren't all that great.  The difference was in the high frequencies being less sharp for JRiver then iTunes and being able to hear actual texture within the siblance if that makes sense instead of just a hiss i could hear the true sound of the thing that was hissing.  I have to admit now though that thinking back on my experiement I don't think I was only using lossless files so it could be I was hearing the difference in codecs used to decode the file.  In any case my library is only part lossless and mostly iTunes matched files so it makes sense to use a player that has a higher accuracy decoder even if both are 'bit perfect'.
 
Are you sure the file you were using is a lossless format file?  Could it be differences in the codecs reconstructing the audio?  If there is a difference in the codecs used to decode the lossy files I would put money on the table to say that JRiver has done a better job of retaining precision decoding this data using more precision at the expense of compute cycles and memory. Two codecs for AAC for example can return very different data for the same frame of audio. I used to impliment audio codecs as a research assistant for Alan Gersho during my Masters program in Digital Signal Processing at UCSB.

 

[r010159]

  [delete]
 
Personally I heard a distinct difference between iTunes playback and JRiver and my ears aren't all that great.  The difference was in the high frequencies being less sharp for JRiver then iTunes and being able to hear actual texture within the siblance if that makes sense instead of just a hiss i could hear the true sound of the thing that was hissing.  I have to admit now though that thinking back on my experiement I don't think I was only using lossless files so it could be I was hearing the difference in codecs used to decode the file.  In any case my library is only part lossless and mostly iTunes matched files so it makes sense to use a player that has a higher accuracy decoder even if both are 'bit perfect'.
 
Are you sure the file you were using is a lossless format file?  Could it be differences in the codecs reconstructing the audio?  If there is a difference in the codecs used to decode the lossy files I would put money on the table to say that JRiver has done a better job of retaining precision decoding this data using more precision at the expense of compute cycles and memory. Two codecs for AAC for example can return very different data for the same frame of audio. I used to impliment audio codecs as a research assistant for Alan Gersho during my Masters program in Digital Signal Processing at UCSB.

 
The musician that I put through several A/B/X tests noticed the same difference between J River and Audirvana+. Also, the files I am testing with are AAC compressed files. Bingo! Still, don't you think players can process the audio for its own distinct sound signature? Also since I am measuring in the software domain well before the data gets to the USB output buffer, cannot there be timing variations? Just some thoughts.
 
Bob Graham
 
PS: I envy your work experience.

 

[groovyd]

How about you try the same test with the same person using a flac or AAC lossless file, or even an uncompressed wav file for that matter.  In other words don't let the player make any decisions about the audio if possible.  It would be interesting to see if the musician who obviously has good ears can distinguish the players then.  It would be instructive to me too since I would finally know if the difference I was hearing was the codec as opposed to the 'bit perfectness'.  I am hoping at least they cannot distinguish as it would make the whole thing easier for me to come to terms with mentally.  I mean if they do sound different then you really do start wondering what 'bit perfect' even means.
 
In either case though this justifies the reason for using one player over another since most people have at least a percentage of compressed files in their collection and there are going to be differences is how each player handles the various tradeoffs in decoding the file.  It would be nice to see which player decodes a compressed file more true to the original uncompressed source which is entirely possible to test as well.  For me iTunes was harsher on my ears using through my T1 cans (which are good at amplifying that harshness) then JRiver was.  It got tiring actually and when I switched to JRiver I immediately noticed the smoother more relaxing highs and ever so slightly lower volume which really helped make it more enjoyable to listen to.  Like pulling the 20k slider down a few db or so just enough to take the bite off.
 
Could be that advertising bit-perfect isn't the real discriminator between a good player and a lesser one.