Topic: Transfer Comp.: Real-Time S/PDIF vs. Firewire - Files Available for Download

[scb]

listened to track 1 over etymotic er4ps and i can't hear any difference

[nickgregory]

alright, I just listened to all three files on my home playback (Pioneer Elite DV45A->SPDIF->Sony 3000ES->Tannoy M3s) and over headphones (Pioneer Elite DV45A->RCA out->Airhead Amp->Grado SR80s) and I cant hear a bit of difference on any track.

[cshepherd]

Of course, the downloaded files may not be as pristine as audio cds off of the master files.  But who would buy into that theory.

Chris

well explain to me, how is copyng a file between 2 hard drives over firewire different from copying a file between 2 hard drives over tcp?  you say 1 absolutely affects the sound, but the other won't?  the processes are the same

Scott...Sorry, it was a joke about controlling the variables.  Clearly the wrong place for it.  I don't have an answer regarding tcp...I don't even know what tcp is.  I think we should figure out what's improving the sound before that issue gets addressed.  BTW, thanks for listening.  I hope you also listen to them on your stereo as well.

Hyperplane...Yes, the s/pdif transfer was recorded in at 32 bit float mode.  It is the only option with Samplitude when using 24 bit files.  The firewire file came over at 24/88.2, but was opened with Samplitude and worked in 32 bit float in the same manner as the 32 bit float s/pdif file. 

Chris:

IMHO, the only way to validly conduct this test is to a) not be working with dithered/resampled test tracks; and b) have test tracks that are, in fact bit-perfect identical to one another.  This means that not only would the md5 need to pass on each track when going between the 722 and the destination device, but that each track would need to have the exact same md5 signature (this means that each track is bit-identical to the other).  This is what Brian was able to accomplish in his testing example above (i.e. the source>spdif>destination sample was bit-identical to the source>firewire>destination sample). 

dnsacks...I'm going to borrow my friend's desktop for a fresh s/pdif transfer tomorrow night hopefully.  He uses Sound Forge and an Egosys sound card.  He can do s/pdif transfers without going into 32 bit float.  I'll trim the blank space off of the wav file and verify with md5summer.  If there's a firewire port on his desktop, I'll also do a fresh firewire transfer with everything plugged into the Energy Center.

If you think about it, each sample that's recorded is nothing more than a series of numbers.  If either the spdif or firewire transfer is changing the way the numbers are recorded on the destination device (computer) then you're not achieving a bit-perfect transfer and the device that's changing the zeros and ones is the cause of the different sound you're hearing.

I said it was better, not different.  The firewire verified with md5 summer but doesn't sound as good.

It's my belief that one bit-perfect transfer should ultimately sound exactly the same no matter what the means of transmission or recording (i.e. bit-accurate transmission of the digital data via morse code or smoke signals should sound no different than bit-accurate transmission via firewire, spdif, ethernet, usb, etc.). 

I can fathom how the use of clean ac power, better/less jittery cables, etc. can make a difference in the way an analog signal sounds or in the effectiveness of an asynchronous digital transfer, but simply can't see how otherwise bit-identical transfers can sound different throught the use of different transfer means.

That is what this comp is suggesting, though.  The list of tweaks we applied to the spdif transfer improved the sound of the resulting file, as compared to an md5 verified firewire transfer.  As for some of you not hearing it, I can't really address that issue (thanks for your input, Nick).  The waveforms are verified to be different.  They should sound different.  They do on all of our hi-fi systems.

Chris

[scb]

Scott...Sorry, it was a joke about controlling the variables.  Clearly the wrong place for it.  I don't have an answer regarding tcp...I don't even know what tcp is. 

jokes are fine, i just don't see how firewire is any different from transfer over the internet.  both use protocols which can be verified for accuracy.  so if you say firewire was different, then an internet transfer could do the same.  so technically you might be introducing another variable (i don't agree with that statement though)

but like i said in my first post, the only source with a ton of different variables is the spdif one.  the clock on the card is one big variable.  maybe the card is introducing something that you seem to prefer?  that could be

or maybe the symphony stuff actually altered the transfer and you seem to prefer that?  it doesn't mean firewire sounds bad.  it might mean you actually colored the sound in a way that you prefer. 

or maybe you're just hearing things

[Brian Skalinder]

but simply can't see how otherwise bit-identical transfers can sound different throught the use of different transfer means.

That is what this comp is suggesting, though.  The list of tweaks we applied to the spdif transfer improved the sound of the resulting file, as compared to an md5 verified firewire transfer.

   No, that's not what the comp suggests - as we've covered at least several times so far.

or maybe you're just hearing things

I'm not surprised Chris hears differences in his comp - there are differences in his files, brought on by at least one variable (dither, random by definition so we know it introduced changes in the files), and possibly more variables, in the comparison.  The real question is whether he (or anyone, for that matter), when presented with a tightly controlled blind comparison (like the one I posted), is able to do the same:  <1> hear differences in the files, and <2> reliably and consistently identify which file(s) were transferred via firewire due to their "loss of fidelity".

[nickgregory]

I'm not surprised Chris hears differences in his comp - there are differences in his files, brought on by at least one variable (dither, random by definition so we know it introduced changes in the files), and possibly more variables, in the comparison.  The real question is whether he (or anyone, for that matter), when presented with a tightly controlled blind comparison (like the one I posted), is able to do the same:  <1> hear differences in the files, and <2> reliably and consistently identify which file(s) were transferred via firewire due to their "loss of fidelity".

And for informations sake, my listening test was based on Brians comp...as the other comparison wasnt controlled, I didnt bother to listen...though maybe I should

[Shawn]

It's my belief that one bit-perfect transfer should ultimately sound exactly the same no matter what the means of transmission or recording (i.e. bit-accurate transmission of the digital data via morse code or smoke signals should sound no different than bit-accurate transmission via firewire, spdif, ethernet, usb, etc.). 

I can fathom how the use of clean ac power, better/less jittery cables, etc. can make a difference in the way an analog signal sounds or in the effectiveness of an asynchronous digital transfer, but simply can't see how otherwise bit-identical transfers can sound different throught the use of different transfer means.

That is what this comp is suggesting, though.  The list of tweaks we applied to the spdif transfer improved the sound of the resulting file, as compared to an md5 verified firewire transfer.  As for some of you not hearing it, I can't really address that issue (thanks for your input, Nick).  The waveforms are verified to be different.  They should sound different.  They do on all of our hi-fi systems.

Chris

chris ... think about it like this. Lets say you guys got a new shipment of high end speaker cables in at your shop, and you wanted to compare them to your favorite brand of cables. So you hook your favorite cables up to one stereo and the new set of cables up to a stereo containing completely different components. You then listen to the same piece of music on both stereos. If one sounded better than the other would you credit it to the cables, or would you conclude that since the two systems were completely different you can't point to one single thing that makes one sound better.

[cshepherd]

It's my belief that one bit-perfect transfer should ultimately sound exactly the same no matter what the means of transmission or recording (i.e. bit-accurate transmission of the digital data via morse code or smoke signals should sound no different than bit-accurate transmission via firewire, spdif, ethernet, usb, etc.). 

I can fathom how the use of clean ac power, better/less jittery cables, etc. can make a difference in the way an analog signal sounds or in the effectiveness of an asynchronous digital transfer, but simply can't see how otherwise bit-identical transfers can sound different throught the use of different transfer means.

That is what this comp is suggesting, though.  The list of tweaks we applied to the spdif transfer improved the sound of the resulting file, as compared to an md5 verified firewire transfer.  As for some of you not hearing it, I can't really address that issue (thanks for your input, Nick).  The waveforms are verified to be different.  They should sound different.  They do on all of our hi-fi systems.

Chris

chris ... think about it like this. Lets say you guys got a new shipment of high end speaker cables in at your shop, and you wanted to compare them to your favorite brand of cables. So you hook your favorite cables up to one stereo and the new set of cables up to a stereo containing completely different components. You then listen to the same piece of music on both stereos. If one sounded better than the other would you credit it to the cables, or would you conclude that since the two systems were completely different you can't point to one single thing that makes one sound better.

Shawn,
I understand your point.  Using your metaphor, let's say the system with the new cables and completely different components sounded better than our current brand of cables in our current reference system.  I could not say the new system sounded better because of the new cables.  However, I can still decide which system sounded better.  The md5summer-verified firewire transfer did not sound as good.  I can't tell you why at this point.  I don't pretend to know.  It could be any of the already well-documented list of variables.

Chris

Cheers Everybody

[BC]

One thing I want to mention is that the whole project started under the premise of making 16/44 CDs sound closer to the 24/96 masters...to minimize the loss of information during the CD transfer process.  The dithered down product is what we are trying to improve on and also why I posted samples at 16/44. 

I'm kinda confused here, I first thought the point of your test was to compare firewire vs SPDIF transfers. But then you state you want to make 16/44 sound more like 24/96. To me, it seems like there was a personal agenda under the guise of a test here, and that you personally wanted one to sound better than the other.

If you really want to compare firewire to SPDIF, the best thing to do is to keep everything the same (same gear, vibrapods, cables, etc) the same and compare the raw 24/96 files transferred via firewire and SPDIF. No other changes than that, as Brian has tried to point out. If you really want to find out if variable X is making a difference, you have to keep all other variables the same except for X. Simple as that.

If you want to maximize the quality of 24/96 > 16/44 transfers, I think the place to look is via better resampling schemes (or even better, record at 88.2 KHz) and alternative dither mechanisms. There was an interesting article in Stereophile a year or two ago where Tony Faulkner discusses a novel downsampling technique where he just takes every 4th point from a 176.4 KHz file and says it compared favorably to conventional resampling/downsampling.

I think you need to consider what it is you are trying to test for, then design a test with appropriate setup that actually addresses that issue. This test you have put together has way too many changes in A vs B to conclusively prove anything.

[lonewolfrecords]

I venture not too many people even have 24 bit sound cards these days. 

I have been following this thread with some interest, and just have to chime in. In particular this statement about not too many people having 24 bit sound cards. 24 bit soundcards have been available for several years now, and I would guess that most people have a 24 bit card unless they are running a fairly old system (over 5 years?). Heck, my first system from 1997 had the Echo Gina soundcard which was 20 bit.

The other issue is that you keep refering to doing the transfer at 32 bit float. I can not find any tech specs on your soundcard (it looks like it was discontinued), but there is no such thing as 32 bit converters (or at least in prosumer type computer soundcards). 32 bit float is an internal format used by processing in many audio programs to preserve the quality of the audio files during EQ, fades, dither, etc (I can not explain it completely, but it has to do with ensuring that the full 16 bit is preserved during processing). I think that there are also programs that have an internal 48 bit float now as well, but that may be limited to Pro Tools TDM systems (I am running Pro Tools LE but don't have the specs handy at the moment).

I would guess that at best your soundcard has 24 bit A/D - D/A converters, and may in fact only have 20 bit or 16 bit converters - do you know the specs of the card? Take a look at the Sek'd website to see that even their most current card is a 24 bit card, not 32 bit.

Actually, from my memory, when I was running the Gina 20 bit soundcard, the highest bit-rate I had the option to record at was 16 bit or "32 bit float" in wavelab or Sound Forge. That is probably why you don't see an option to record at 24 bit with your software - it is not a 24 bit card. I could be wrong about this, but it is worth looking into.

I would suspect that what Scott Brown suggested is what is happening here - the S/PDIF output of the 722 through the soundcard is adding some color that you prefer, which may actually be truncation of the 24 bit down to 20 bit or 16 bit.

Take care,

Tom.

[Shawn]

It's my belief that one bit-perfect transfer should ultimately sound exactly the same no matter what the means of transmission or recording (i.e. bit-accurate transmission of the digital data via morse code or smoke signals should sound no different than bit-accurate transmission via firewire, spdif, ethernet, usb, etc.). 

I can fathom how the use of clean ac power, better/less jittery cables, etc. can make a difference in the way an analog signal sounds or in the effectiveness of an asynchronous digital transfer, but simply can't see how otherwise bit-identical transfers can sound different throught the use of different transfer means.

That is what this comp is suggesting, though.  The list of tweaks we applied to the spdif transfer improved the sound of the resulting file, as compared to an md5 verified firewire transfer.  As for some of you not hearing it, I can't really address that issue (thanks for your input, Nick).  The waveforms are verified to be different.  They should sound different.  They do on all of our hi-fi systems.

Chris

chris ... think about it like this. Lets say you guys got a new shipment of high end speaker cables in at your shop, and you wanted to compare them to your favorite brand of cables. So you hook your favorite cables up to one stereo and the new set of cables up to a stereo containing completely different components. You then listen to the same piece of music on both stereos. If one sounded better than the other would you credit it to the cables, or would you conclude that since the two systems were completely different you can't point to one single thing that makes one sound better.

Shawn,
I understand your point.  Using your metaphor, let's say the system with the new cables and completely different components sounded better than our current brand of cables in our current reference system.  I could not say the new system sounded better because of the new cables.  However, I can still decide which system sounded better.  The md5summer-verified firewire transfer did not sound as good.  I can't tell you why at this point.  I don't pretend to know.  It could be any of the already well-documented list of variables.

Chris

Cheers Everybody

cool. I'm glad we agree. I'm also glad you found a transfer method that sounds better to your ears. If you are happy with it then by all means go right ahead.

I am still interested in the results of Brian's double blind test, because I think that they will clearly demonstrate that the differences you are hearing are not because of spdif vs. firewire. Brian proved what my existing knowledge lead me to believe, and that is that a file transferred via spdif without any errors is bit identical to a file transferred via firewire. Scientifically speaking if we disregard things like the placebo effect it is impossible for completely identical files to sound different. 

[it-goes-to-eleven]

Scientifically speaking if we disregard things like the placebo effect it is impossible for completely identical files to sound different. 

But why does one of them sound better?

[SparkE!]

When comparing different means of transfer, we only need to concern ourselves with whether each transfer accurately moves the bits from the source media to the destination media without altering the transferred data. Period.

You don't need double blind listening tests to tell whether two identical files represent the same waveform.

Firewire transfers will transfer the entire source file to the destination media.  If the MD5's match, there are no differences between the source and destination files.

S/PDIF transfers require that the destination device synchs with the source.  In order to synch, you send bits over the interface.  Until it synchs, the transmitted bits are not correctly received. Once synch has been obtained, the remaining bits should make it across the interface unaltered.  So, although S/PDIF is generally considered a lossless means of transfer (as long as the receiving device does not resample), it should not be considered as a way of making a literal copy.  It will always drop some portion of the first bits to go across the interface simply because the receive device must synch to its incoming bit stream and it will receive supsequent bits without modifying them.

Firewire is capable of transferring the entire recorded waveform with no bit errors.  S/PDIF is capable of transferring without bit errors only after the receiving device synchs to its incoming bit stream.  It is not capable of transferring the entire source recording because it cannot receive the bits correctly during the process of getting in synch with the incoming bit stream.

All that being said, I'm betting that Chris is sitting there laughing at us for even engaging in this debate with him.  He's in the business of selling $300 S/PDIF cables.  What do you expect him to say?  Do you expect him to tell the truth about transfers and say that firewire, by its very nature, will do a better job of transferring a bit literal copy from the source media to the destination media?  His position is not likely to change until he identifies a source for $300 firewire cables.  (Get on it, Chris.  You're losing sales fast.)

[it-goes-to-eleven]

His position is not likely to change until he identifies a source for $300 firewire cables.  (Get on it, Chris.  You're losing sales fast.)

I could make you one in silver teflon.  And leather.  Leather techflex.

[rustoleum]

If the file's MD5 sums can be compared and match perfectly, then the wavs are identical.  There will be no difference in the files because they are identical.  One cannot sound  better than the other because they are identical.  If the MD5 sums don't match, then there could be a difference in sound quality because the files are not identical.