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

[cshepherd]

As a few of you know, I've been experimenting with s/pdif transfers from the 722 into the SEK'D Prodif+ sound card. I bought the 722 last Fall.  I used a firewire cable from a local computer store for all of my transfers.  Dale and I continually noticed that the 16 bit CDs seemed too dull compared to the master recording.  Even taking the 24 bits into consideration, the CDs seemed to lack fidelity.  Something did not seem right.

We set out on a quest to minimize the loss in fidelity that happens going from 24/96>16/44.  It started with an experiment using Vibrapods under the laptop and 722.  We use them under everything in our hi-fi systems.  The difference was noticeable. Noticeable enough to make me delete the original and archived files of the Steve Kimock show I had just finished and start over.  Dale came over and agreed after only a short amount of time spent listening. 

Not long after, we picked up Atlas Cables for Eugene Hi-Fi.  We stumbled onto a UHF review digital cable lengths, testing the theory that 1.5m s/pdif cables sound better than 1.0m s/pdif cables.  Atlas' Opus All Cu 1.5m s/pdif wound up replacing their existing s/pdif cable in their reference system.  It was around that time we started talking about trying the old-school, DAT style s/pdif transfer again.  We ordered an Opus All Cu 1.5 meter cable for the project.

Later that Spring, we bought an FIM Energy Center for our reference hi-fi system.  It's an a/c distribution outlet box.  No filters, just top-knotch raw materials and a dedication to excellence.  It's powered by a van den Hul Mainsstream Hybrid a/c cable that has passive filtering qualities to control noise in the a/c line.  We use Quantum's QRT technology to control EMI/RF Intererence instead of dynamic-robbing series filters.  This a/c maintenance package easily takes an audio or video system to the next level.  It's profound effect on the hi-fi system left us no choice but to plug the computer and 722 into it when we started doing the real time spdif transfers.

We recorded six shows this past summer, doing real-time transfers on all of them.  edit for clarity:  We waited until the end of summer before doing any direct comparisons.  Our first impression [/b](before any direct comparisons) was that the s/pdif transfer was better.  The 16 bit sources seemed to be comparing more favorably to the original 24 bit sources.  We chose this stretch of music for our first serious look at the two methods.

The Source:
String Cheese Incident 8/5/2006 1st set
"MLT>New Pollution>MLT"
Neumann km 184s>van den Hul Orchid mic cables>Sound Devices 722 2nd row, dfc in the TS. 
The Cuthbert Amphitheatre is an open air venue with a copper half-shell over the stage. 

What We Heard:
The firewire transfer came up noticeably short on fidelity.  It has a darker, less extended sound.  The bass is less detailed.  The overall sound is muddy.  It lacks in dynamics as well.  Myself and three other people have all easily agreed on which sounds better. 

What We Saw:
I have not done any waveform analysis on the samples.  I don't know how.  Looking closely at the waveforms on my laptop's 1900 dpi widescreen, they look identical.  I'm not sure what I was expecting to see, but I wasn't ready for that.  I would appreciate it if someone would do the analysis to confirm this.

Please download the files and compare them if you are currently using firewire.  I'm sure the technical conversation will flow. 

Thanks for reading.  Have a great weekend,
Chris

http://eugenehifi.com/Downloads/Transfer_Comparison.htm

[Brian Skalinder]

As a few of you know, I've been experimenting with s/pdif transfers from the 722 into the SEK'D Prodif+ sound card. I bought the 722 last Fall.  I used a firewire cable from a local computer store for all of my transfers.  Dale and I continually noticed that the 16 bit CDs seemed too dull compared to the master recording.  Even taking the 24 bits into consideration, the CDs seemed to lack fidelity.  Something did not seem right.
< snip >
We set out on a quest to minimize the loss in fidelity that happens going from 24/96>16/44.  It started with an experiment using Vibrapods under the laptop and 722.  We recorded six shows this past summer, doing real-time transfers on all of them.  Our first impression was that the s/pdif transfer was better.  The 16 bit sources seemed to be comparing more favorably to the original 24 bit sources. 
< snip >
What We Heard:
The firewire transfer came up noticeably short on fidelity.  It has a darker, less extended sound.  The bass is less detailed.  The overall sound is muddy.  It lacks in dynamics as well.  Myself and three other people have all easily agreed on which sounds better.

For comparing firewire transfers v. S/PDIF transfers, there's far too much going on here across the two sample sets, i.e. too many variables:  normalization, resampling, dithering, AC filter (FIM Energy Center?) on one but not the other, different PCs (desktop v. laptop), etc.  To really compare firewire v. S/PDIF transfers, I think it makes sense to:

[1]  MD5 the original 24-bit source on the 722
[2]  transfer from 722 to PC via S/PDIF using a known-bit-transparent soundcard and MD5 the resulting file <a>
[3]  transfer from 722 to PC via firewire and MD5 the resulting file <b>
[4]  compare the MD5s from steps [1-3]
[5]  perform a WAV compare in Wavelab or other app of files <a> and <b>
[6]  listen to <a> and <b>

Granted creating the MD5 in [1] also uses firewire, but we're effectively doing it again in [3] to confirm whether the transfer is consistent across multiple firewire passes, and then, of course, also referencing against [2].  Theoretically, anyway, the waveforms should be identical.  This should be easy to determine via [4,5].  If they're identical, then [6] is really just for kicks.  And if they're not identical, and you hear a difference in [6], then your playback / ears are better than mine!

At least that's what my currently quasi-foggy brain thinks about it.

Edit to add:  In taking another look at the comp notes, I noticed a couple additional variables I didn't catch before as I glanced at the notes.  Of course, if performing the test I outlined above to compare firewire v. S/PDIF transfer, one must isolate the transfer by ensuring everything else is as identical as possible across both methods:  same PC, same AC filtering on all devices, same EFI/RFI stabilization, etc. 

[cshepherd]

Hi Brian,
I agree that the Energy Center not being used in the firewire transfer is an issue, but I think it's a small issue.  The only variables are the a/c distribution outlet, the computer used and the transfer cable used.  The 722 and laptop were on battery power for the firewire transfer.  My older desktop does not have a firewire input and my laptop doesn't have a good sound card. 

The common thought on the digital realm is that it is all 1's and 0's and that they reproduce an exact copy (with the exception of cable-induced jitter).  Both sources should have sounded the same.  The waveforms look the same.  They were mastered using the same processes and parameters.  Both transfers had QRT and Vibrapod treatments.  Yet, when you judge with your ears they are noticeably different.  Why aren't the differences showing up in the waveform?  This is a very serious question, imo (regardless of how the waveforms were generated).   I don't know if the waveforms are truly identical, but I can't tell them apart no matter how close I zoom in on them.

I'm leaving town in a few days and may not have time to do the md5 analysis.  I would be up for another transfer test that is more tightly controlled on the firewire, but it may not happen until I get back in mid-October.

Brian, thanks for your input and starting the conversation.

Chris

[Brian Skalinder]

The common thought on the digital realm is that it is all 1's and 0's and that they reproduce an exact copy (with the exception of cable-induced jitter).  Both sources should have sounded the same.  The waveforms look the same.  They were mastered using the same processes and parameters.  Both transfers had QRT and Vibrapod treatments.  Yet, when you judge with your ears they are noticeably different.  Why aren't the differences showing up in the waveform?  This is a very serious question, imo (regardless of how the waveforms were generated).   I don't know if the waveforms are truly identical, but I can't tell them apart no matter how close I zoom in on them.

The differences do show up, at least in file analysis if not listening.  First, I trimmed the t06 files to the same sample and according to a waveform compare the files are not identical.  I even split L and R channels to do the trimming since visually it seemed the L channel of one file had an offset relative to the other.  While I could not hear a difference between the trimmed t06's in an ABX listening test (though perhaps my ears-brain and/or playback just aren't up to it), the waveform comparison revealed differences, as did the frequency analysis.  This makes sense since editing doesn't always produce the same results when given identical inputs.  For example, dithering uses random rounding, so even performing the same editing operation on identical source files will not result in identical result sets.

And so I still think there are too many variables.  Hence my suggestion to remove all variables except the transfer method so that we may determine <1> whether the different transfer methods result in identical files (theoretically, they should), and <2> whether the identical (or not) files sound the same (if identical, theoretically they should).  I've performed my fair share of comps, so I know it's not always easy to find the time and I appreciate your taking the time do put this one together.  But until we isolate the transfer method, we have no way of knowing whether the different results - whether audible or not - are a result of the transfer method or some other variable(s).

Edit to add:  Upon first listen, I thought I heard differences in t08.  So I performed the same trimming, waveform and frequency analyses, and listening comparison on t08, with the same results:  different waveform, different frequency analysis results, unable to hear a difference in ABX listening.  I think the original difference I thought I heard was due to listening to different stretches of music, or the same stretch with different starting / ending points. 

[cshepherd]

The common thought on the digital realm is that it is all 1's and 0's and that they reproduce an exact copy (with the exception of cable-induced jitter).  Both sources should have sounded the same.  The waveforms look the same.  They were mastered using the same processes and parameters.  Both transfers had QRT and Vibrapod treatments.  Yet, when you judge with your ears they are noticeably different.  Why aren't the differences showing up in the waveform?  This is a very serious question, imo (regardless of how the waveforms were generated).   I don't know if the waveforms are truly identical, but I can't tell them apart no matter how close I zoom in on them.

The differences do show up, at least in file analysis if not listening.  First, I trimmed the t06 files to the same sample and according to a waveform compare the files are not identical.  I even split L and R channels to do the trimming since visually it seemed the L channel of one file had an offset relative to the other.  While I could not hear a difference between the trimmed t06's in an ABX listening test (though perhaps my ears-brain and/or playback just aren't up to it), the waveform comparison revealed differences, as did the frequency analysis.  This makes sense since editing doesn't always produce the same results when given identical inputs.  For example, dithering uses random rounding, so even performing the same editing operation on identical source files will not result in identical result sets.

And so I still think there are too many variables.  Hence my suggestion to remove all variables except the transfer method so that we may determine <1> whether the different transfer methods result in identical files (theoretically, they should), and <2> whether the identical (or not) files sound the same (if identical, theoretically they should).  I've performed my fair share of comps, so I know it's not always easy to find the time and I appreciate your taking the time do put this one together.  But until we isolate the transfer method, we have no way of knowing whether the different results - whether audible or not - are a result of the transfer method or some other variable(s).

Thanks for your help and efforts, Brian. 

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 found some instructions on md5 verification from Bean (thanks for posting that).  The firewire transfer verified with MD5 Summer.  I'm glad you were able to verify the waveform differences and frequency response.  It allows the conversation to progress without getting bogged down over wether or not the differences exist.

This is still very much true...The s/pdif transfer process w/clean a/c power produced superior results when (theoretically) they should have been the same as the firewire transfer results.  The loss of fidelity in the firewire transfer had to be caused by something.  If it's not the firewire cable, the other variables are even more dubious as culprits of poor fidelity (lack of Energy Center / different PC / poor mastering by Samplitude).

The channel offset, was that in the s/pdif or firewire filesets?  Are you saying the L/R channels were not perfectly aligned?

Chris

[Brian Skalinder]

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 understand the desire to make 16/44 products closer to the original 24/xx masters - I undertook similar efforts in dithering and resampling comps I performed.  (The dithering comps are linked here at TS and hosted on tapers.org).

I found some instructions on md5 verification from Bean (thanks for posting that).  The firewire transfer verified with MD5 Summer.

I'm not sure I understand.  Did you MD5 the original 24/96 file while it resided on the 722 and then verify the MD5 v. the WAV after firewire transfer to PC?  And if so, did you also MD5 the 24/96 S/PDIF transfer file to see if they're identical?

The channel offset, was that in the s/pdif or firewire filesets?  Are you saying the L/R channels were not perfectly aligned?

I don't know if there's an offset (can't really tell because the files aren't identical).  It just looked visually like in one of the files there might be a single sample offset between L and R channel's relative to the other file.  So to ensure that wasn't the cause of my WAV compare differences, I trimmed and compared each channel separately.

I'm glad you were able to verify the waveform differences and frequency response.  It allows the conversation to progress without getting bogged down over wether or not the differences exist.

I was genuinely curious about it, so I figured I'd give it a waveform / frequency analysis as well as listening test.  Ultimately, how it sounds to my ears is the key, but I also like to comprehend what's going on in the file(s) via analysis.

This is still very much true...The s/pdif transfer process w/clean a/c power produced superior results when (theoretically) they should have been the same as the firewire transfer results.  The loss of fidelity in the firewire transfer had to be caused by something.  If it's not the firewire cable, the other variables are even more dubious as culprits of poor fidelity (lack of Energy Center / different PC / poor mastering by Samplitude).

Even though I don't hear any differences (again, probably due to my ears/brain/playback), I don't doubt that you hear differences.  But I guess I don't understand how it's possible to state S/PDIF transfer produces superior results when that's not what the files actually compare.  As best I can tell, the files compare the following:

<01>  S/PDIF transfer v. firewire transfer
<02>  desktop w/ Atlas EOS power cord v. laptop (I assume no special cord)
<03>  FIM Energy Center v. none
<04>  dither results v. dither results (which, by definition, are different)
<05>  maybe resampling results v. resampling results (maybe different, maybe not...unsure how Samplitude handles resampling)

That's five potential causes of the differences between the two files.  All we may reasonably determine from this comp is that at least one (<04>) and maybe more of the five options above caused the differences and that we don't know which option (or set of options) is the cause of the difference(s).  Hence the need for better controls and isolation of the potential causes if we truly want to compare firewire v. S/PDIF transfer mechanisms.  I still believe the only way to determine if S/PDIF or firewire transfer produces superior results is to truly isolate the transfer mechanism - something this comp simply doesn't do.  That's not to say it isn't an interesting listening exercise, I just don't think it's a valid comparison of the two transfer methods.

Curious - if these fidelity differences are a function of the firewire transfer, would you also expect fidelity differences from USB transfers?  And transfers over ethernet/IP networks?  And transfers via the PC's bus from one HD to another?

[cshepherd]

I found some instructions on md5 verification from Bean (thanks for posting that).  The firewire transfer verified with MD5 Summer.

I'm not sure I understand.  Did you MD5 the original 24/96 file while it resided on the 722 and then verify the MD5 v. the WAV after firewire transfer to PC?

Exactly.  The files are still on the 722.  I just did the md5 yesterday.

And if so, did you also MD5 the 24/96 S/PDIF transfer file to see if they're identical? 

No, the raw s/pdif transfer is no longer on my hard drive.  I will do that the next time I transfer a show. 

This is still very much true...The s/pdif transfer process w/clean a/c power produced superior results when (theoretically) they should have been the same as the firewire transfer results.  The loss of fidelity in the firewire transfer had to be caused by something.  If it's not the firewire cable, the other variables are even more dubious as culprits of poor fidelity (lack of Energy Center / different PC / poor mastering by Samplitude).

quote from brian yesterday
Even though I don't hear any differences (again, probably due to my ears/brain/playback), I don't doubt that you hear differences.  But I guess I don't understand how it's possible to state S/PDIF transfer produces superior results when that's not what the files actually compare.  As best I can tell, the files compare the following:

<01>  S/PDIF transfer v. firewire transfer
<02>  desktop w/ Atlas EOS power cord v. laptop (I assume no special cord)
<03>  FIM Energy Center v. none
<04>  dither results v. dither results (which, by definition, are different)
<05>  maybe resampling results v. resampling results (maybe different, maybe not...unsure how Samplitude handles resampling)

That's five potential causes of the differences between the two files.  All we may reasonably determine from this comp is that at least one (<04>) and maybe more of the five options above caused the differences and that we don't know which option (or set of options) is the cause of the difference(s).Hence the need for better controls and isolation of the potential causes if we truly want to compare firewire v. S/PDIF transfer mechanisms.  I still believe the only way to determine if S/PDIF or firewire transfer produces superior results is to truly isolate the transfer mechanism - something this comp simply doesn't do.  That's not to say it isn't an interesting listening exercise, I just don't think it's a valid comparison of the two transfer methods.

I agree that we can't definitively say it's the firewire cable.  In that sense, the comp was not strict enough. I think the comp still offers much food for thought regarding digital transfer of audio.

Curious - if these fidelity differences are a function of the firewire transfer, would you also expect fidelity differences from USB transfers?  And transfers over ethernet/IP networks?  And transfers via the PC's bus from one HD to another?

If the firewire cable is the cause, I would expect similar performance from a USB cable.  The PC bus and ethernet connections...I don't know.

Chris 

[Brian Skalinder]

Alright, I quickly put together a more controlled comp:

ftp:  tapers.org
port:  21
dir:  /drive1/_gear_comparisons/firewire_v_spdif
login:  ftp4all
pass:  ftp4all

I'll be surprised if anyone can hear differences across the files.  And I'll be downright flabbergasted if anyone can identify which is which.

From the info file:

*****************************************************************
*  S/PDIF v. FIREWIRE COMPARISON                                *
*****************************************************************

There are three files in the comparison:

  - t01.wav
  - t02.wav
  - t03.wav

Each of these files matches to one of the following files before renaming to mask their source:

  - A.wav = master S/PDIF transfer
  - B.wav = firewire transfer x 2
  - C.wav = firewire transfer x 20

See notes below for more info.

The goal:

  <01>  identify any audible (or otherwise) differences between these three files
  <02>  identify which comp file (t01.wav, t02.wav, t03.wav) matches which source file (A.wav, B.wav, C.wav)


*****************************************************************
*  SOURCE                                                       *
*****************************************************************

Donna The Buffalo
2002-11-06
Cleveland, OH - Beachland Ballroom

Taper:      Brian Skalinder
Location:   Center, 30' back, 10' stand
Config:     DIN (20cm, 90º)
Source:     MBHO KA200/603A > Lunatec V2 > Oade modSBM-1 > D100
Conversion: D100 > Waveterminal 2496~ > Cool Edit 2000 > CD-Wave

~ verified bit-accurate soundcard


*****************************************************************
*  STEPS                                                        *
*****************************************************************

I followed these steps in generating the comp:

  <01>  transferred original DAT to PC via known bit-accurate soundcard (see source notes above)
  <02>  tracked WAV
  <03>  transferred WAVs (as data) to CD for archival
  <04>  transferred WAV track from CD to my current PC setup - this is the master, track A
  <05>  copied track A from hard drive, via firewire, to another hard drive, and back - this is track B
  <06>  copied track A from hard drive, via firewire, to another hard drive, and back, 10 times - this is track C
        (10 roundtrip firewire transfers = 20 total firewire transfers)
  <07>  generated and verified MD5s for tracks A, B, and C (see MD RESULTS section below)
  <08>  performed a WAV comparison in WaveLab (see WAV COMPARE section below)
  <09>  renamed tracks A, B, and C to t01.wav, t02.wav, and t03.wav, but not necessarily in that order


*****************************************************************
*  MD5 RESULTS                                                  *
*****************************************************************

All three tracks generated the same MD5 checksum:

eaf38593208d43b562f954138b884b4d *A.wav
eaf38593208d43b562f954138b884b4d *B.wav
eaf38593208d43b562f954138b884b4d *C.wav

I verified each MD5 result with each of the files individually, i.e. verified...

  - A.wav against track A, B, and C's MD5 signatures individually
  - B.wav against track A, B, and C's MD5 signatures individually
  - C.wav against track A, B, and C's MD5 signatures individually

...and all files passed verification with all MD5s.


*****************************************************************
*  WAV COMPARE                                                  *
*****************************************************************

I used WaveLab 5.00a's "Audio File Comparer" utility to each track against the other two, i.e. compared...

  - A.wav to B.wav
  - B.wav to C.wav
  - A.wav to C.wav

The results matched in each case:  "The two files are exactly equal!"

[scb]

a friend who saw the thread wrote me this:

>>A firewire transfer is a firewire transfer is a firewire transfer. No
matter how many times you transfer it, you're going to get the same
results (modulo downright corruption).

The spdif transfer has actual potential for variance, especially if
either (a) they're using same sample / bit rate but the clocks aren't
sync'd or (b) they're actually dithering in the conversion.<<


and he's right.  the spdif transfer is the one with the potential for variance, not the firewire one

anyway, my question for Chris is this:

your source info for the 2 tracks says this for the spdif transfer:

 SEK'D Prodif Plus sound card (32 bit float)

Does that mean that you handled it in Samplitude as a 32 bit float?  So you dithered from 32 bit to 16?

Did you do the same for the firewire transfer?

[Brian Skalinder]

your source info for the 2 tracks says this for the spdif transfer:

 SEK'D Prodif Plus sound card (32 bit float)

Does that mean that you handled it in Samplitude as a 32 bit float?  So you dithered from 32 bit to 16?

Did you do the same for the firewire transfer?

Ahhh, good catch, Scott.  If the S/PDIF transfer was edited at 32-bit and the firewire not, that might very well result in the differences Chris is hearing.

[scb]

maybe i'll listen to this stuff tonight

[it-goes-to-eleven]

On a comp like this, I have only one question and that is to ask for the md5s of the orignal master sources.  In the analysis, if they do not match, you stop right there, determine why, and fix the problem.  Either the transfers are correct or they aren't.

I verified a 4.8GB show last week 10 times with rsync via firewire.  No variation.

[cshepherd]

a friend who saw the thread wrote me this:

>>A firewire transfer is a firewire transfer is a firewire transfer. No
matter how many times you transfer it, you're going to get the same
results (modulo downright corruption).

The spdif transfer has actual potential for variance, especially if
either (a) they're using same sample / bit rate but the clocks aren't
sync'd or (b) they're actually dithering in the conversion.<<


and he's right.  the spdif transfer is the one with the potential for variance, not the firewire one

anyway, my question for Chris is this:

your source info for the 2 tracks says this for the spdif transfer:

 SEK'D Prodif Plus sound card (32 bit float)

Does that mean that you handled it in Samplitude as a 32 bit float?  So you dithered from 32 bit to 16?

Did you do the same for the firewire transfer?

Samplitude handles all signals with more than 16 bits in 32 bit float.  Both s/pdif and firewire transfers were processed in 32 bit float, going through the same processes. 

The firewire transfer verified through md5 summer and it is inferior in sound quality to the s/pdif transfer.  How did that happen?   

Was the difference in sound quality a result of using a $300 s/pdif cable over a $10 firewire cable?  OR

Was the difference due to my desktop and sound card performing better as a result of access to clean a/c power with a quality a/c cable?  OR

A combination of both?

NO, I did not sabotage the firewire transfer.  I don't actually enjoy doing real time transfers.  I would have been nice to be wrong in this experiment.

Scott, your aes-ebu cable from AM retails for $800.  Why would you have something like that if firewire is perfect for $10?

Chris

Has anybody burned the tracks out and listened to them on a stereo?

[scb]

Samplitude handles all signals with more than 16 bits in 32 bit float.  Both s/pdif and firewire transfers were processed in 32 bit float, going through the same processes. 

The firewire transfer verified through md5 summer and it is inferior in sound quality to the s/pdif transfer.  How did that happen?   

Was the difference in sound quality a result of using a $300 s/pdif cable over a $10 firewire cable?  OR

Was the difference due to my desktop and sound card performing better as a result of access to clean a/c power with a quality a/c cable?  OR

A combination of both?

Has anybody burned the tracks out and listened to them on a stereo?

i'll check them out tonight and see if i hear a difference.  but you're claiming it's a dramatic difference?

Scott, your aes-ebu cable from AM retails for $800.  Why would you have something like that if firewire is perfect for $10?
Chris

well i did NOT pay anywhere near to  800 for it.  not even close

but to answer your question, it's not the same.  i can't go firewire out of my mytek box into my 722.  but if i could, i would. 

i'll fire another question at you, though.  if you're so convinced that the firewire transfer sounded different, how can you be sure that the files that I download are going to sound the same as the ones you're listening to there?  they're being transferred over a protocol in the same way the files were transferred from your 722 to your computer...

[Brian Skalinder]

Has anybody burned the tracks out and listened to them on a stereo?

Burned - no, listened on a stereo - yes, but a very modest one (PC > Waveterminal 2496 digi-out > Bel Canto DAC 1.1 > Audio Experiences Symphonies > McCormack DNA-1 > Von Schweikert VR-1s).

i'll check them out tonight and see if i hear a difference.  but you're claiming it's a dramatic difference?

FWIW, I don't hear a difference.  But maybe it's because I don't -want- to hear a difference (just as people sometimes hear differences because they want to - but that's one of the reasons I ABX  in these sorts of comps).  Curious to hear your take on the files I posted, too.  The files I posted removed the other variables (listed in a previous post) from the equation and should provide a better comparison.

[cshepherd]

Hi Scott,
I think dramatic is a little too subjective for this, but it is not hard to hear.  The firewire transfer does not have as much extention in the treble frequencies, the bass is not as detailed and controlled and dynamics also suffer.  The s/pdif transfer has better spatial cues.  The sound has a shine to it that the firewire transfer clearly does not have.  I played the files for my brother as well as two of my friends.  Nobody needed more than a couple of minutes of listening to agree that the s/pdif transfer was noticeably better.  I heard the difference on three different hi-fi systems.

As for me, I've heard everything I need to hear.  I'm using the real-time transfer from here on out.

Chris

Brian, I'll check your files out this afternoon.

[Shawn]

We set out on a quest to minimize the loss in fidelity that happens going from 24/96>16/44.  It started with an experiment using Vibrapods under the laptop and 722.  We use them under everything in our hi-fi systems.  The difference was noticeable. Noticeable enough to make me delete the original and archived files of the Steve Kimock show I had just finished and start over.  Dale came over and agreed after only a short amount of time spent listening.  

One last question...  are you claiming that putting vibrapod feet under the 722 and the computer when doing a fire wire transfer has an audible difference?

[Brian Skalinder]

As for me, I've heard everything I need to hear.  I'm using the real-time transfer from here on out.

Once again - honest, last time I'll say it - the comp did not effectively compare firewire v. S/PDIF transfer, so to base this decision on the comp doesn't make sense.

Brian, I'll check your files out this afternoon.

If, as you suggest, S/PDIF transfers are superior to firewire transfers, and firewire transfers result in a loss of fidelity, it should be easy to hear the differences in the files and even pick out which file is the S/PDIF source, which the firewire transfer, and which the 20x firewire transfer.  Nothing like a blind comp to get to the bottom of things.  Happy listening. 

[cshepherd]

We set out on a quest to minimize the loss in fidelity that happens going from 24/96>16/44.  It started with an experiment using Vibrapods under the laptop and 722.  We use them under everything in our hi-fi systems.  The difference was noticeable. Noticeable enough to make me delete the original and archived files of the Steve Kimock show I had just finished and start over.  Dale came over and agreed after only a short amount of time spent listening. 

One last question...  are you claiming that putting vibrapod feet under the 722 and the computer when doing a fire wire transfer has an audible difference?

Yes.

As for me, I've heard everything I need to hear.  I'm using the real-time transfer from here on out.

Once again - honest, last time I'll say it - the comp did not effectively compare firewire v. S/PDIF transfer, so to base this decision on the comp doesn't make sense.

Brian, I'll check your files out this afternoon.

If, as you suggest, S/PDIF transfers are superior to firewire transfers, and firewire transfers result in a loss of fidelity, it should be easy to hear the differences in the files and even pick out which file is the S/PDIF source, which the firewire transfer, and which the 20x firewire transfer.  Nothing like a blind comp to get to the bottom of things.  Happy listening. 

If firewire was perfect, the firewire tranfer files would have sounded just like the real time files...Energy Center and all.  You can't improve on perfect, right? 

Chris

[Shawn]

As for me, I've heard everything I need to hear.  I'm using the real-time transfer from here on out.

Once again - honest, last time I'll say it - the comp did not effectively compare firewire v. S/PDIF transfer, so to base this decision on the comp doesn't make sense.

Brian, I'll check your files out this afternoon.

If, as you suggest, S/PDIF transfers are superior to firewire transfers, and firewire transfers result in a loss of fidelity, it should be easy to hear the differences in the files and even pick out which file is the S/PDIF source, which the firewire transfer, and which the 20x firewire transfer.  Nothing like a blind comp to get to the bottom of things.  Happy listening. 

It's obvious he doesn't care Brian. You pretty clearly explained why his test was invalid but he had already made up his mind. It sounds to me like he thought the real time transfer was superior from the begining, in which case you can probably attribute the difference he hears in sound to the placebo effect.

I am willing to bet that if you conducted a true double blind test, with a reasonable number of test cases, that compared real time spdif transfers and fire wire transfers on a set of files with no post processing the results would show people are unable to accuratley and consistently determine one from the other. You could use any playback system you want. It wouldn't matter because the difference is going to be indistinguishable to the human ear.

[Shawn]

We set out on a quest to minimize the loss in fidelity that happens going from 24/96>16/44.  It started with an experiment using Vibrapods under the laptop and 722.  We use them under everything in our hi-fi systems.  The difference was noticeable. Noticeable enough to make me delete the original and archived files of the Steve Kimock show I had just finished and start over.  Dale came over and agreed after only a short amount of time spent listening. 

One last question...  are you claiming that putting vibrapod feet under the 722 and the computer when doing a fire wire transfer has an audible difference?

Yes.

chris I hate to break it to you, but you are just dead wrong there.  do the md5 test with and without the vibrapod. you'll see for yourself.

[Brian Skalinder]

If firewire was perfect, the firewire tranfer files would have sounded just like the real time files...

I don't know how else to say it:  the comp includes too many variables to declare that firewire is the culprit for the loss of fidelity you hear.  Believe what you will, but the suggestion that firewire is the cause of the differences you hear is is not supported by logic or reason.

I controlled for the other variables in my comp.  If you're able to repeatedly identify which file in my blind test - out of the three bit-for-bit identical files - is S/PDIF, I'll eat crow publicly.  And maybe even buy some vibrapods! 

[cshepherd]

We set out on a quest to minimize the loss in fidelity that happens going from 24/96>16/44.  It started with an experiment using Vibrapods under the laptop and 722.  We use them under everything in our hi-fi systems.  The difference was noticeable. Noticeable enough to make me delete the original and archived files of the Steve Kimock show I had just finished and start over.  Dale came over and agreed after only a short amount of time spent listening. 

One last question...  are you claiming that putting vibrapod feet under the 722 and the computer when doing a fire wire transfer has an audible difference?

Yes.

chris I hate to break it to you, but you are just dead wrong there.  do the md5 test with and without the vibrapod. you'll see for yourself.

Do you analize video with your ears and audio with your eyes?  You do the test.  I don't need to. 

edit:  remember, the firewire transfer verified with md5 summer and it doesn't sound as good.

Chris

[Shawn]

We set out on a quest to minimize the loss in fidelity that happens going from 24/96>16/44.  It started with an experiment using Vibrapods under the laptop and 722.  We use them under everything in our hi-fi systems.  The difference was noticeable. Noticeable enough to make me delete the original and archived files of the Steve Kimock show I had just finished and start over.  Dale came over and agreed after only a short amount of time spent listening. 

One last question...  are you claiming that putting vibrapod feet under the 722 and the computer when doing a fire wire transfer has an audible difference?

Yes.

chris I hate to break it to you, but you are just dead wrong there.  do the md5 test with and without the vibrapod. you'll see for yourself.

Do you analize video with your ears and audio with your eyes?  You do the test.  I don't need to.

Chris

chris I don't need to do the test because I can tell you the results. The files will be identical. The vibrapod will not effect a fire wire transfer. In fact it can't effect the transfer. If it did the files would be corrupt, and be unusable. If you hear a difference you are wrong. It's a fact.

[scb]

edit:  remember, the firewire transfer verified with md5 summer and it doesn't sound as good.

Chris

so far, only according to YOU

[cshepherd]

Well, we all know what happens when you assume.  Don't get mad at me.  I would have loved firewire to prove me wrong.  It's insanely more convenient.  I venture not too many people even have 24 bit sound cards these days.  Brian's right...we can't say for sure it's firewire being deficient.  But, something we used during the real time transfer produced better results.  It could be the

FIM Energy Center ($1200) w/the van den Hul Mainsstream Hybrid a/c cord ($485)
Atlas All Cu 1.5m s/pdif cable ($305 retail)
The Atlas EOS a/c power cord ($300) on the computer
My older desktop sounds better than my newer laptop  (my desktop does not have firewire ports)
Samplitude could be unreliable for consistent dithering

You can't discount the improved sound just because the controls weren't tight enough to narrow it down to only one variable.  Brian verified there are differences in the waveforms so you can't say it's psycho-acoustic nonsense.  By everyone's definition, we should not have been able to  improve on a firewire transfer.  I believe these files disprove that assumption.

edit:  remember, the firewire transfer verified with md5 summer and it doesn't sound as good.

Chris

so far, only according to YOU

Scott, three other people came to identical conclusions befeore I even made this post.  It's not just me.  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

[dnsacks]

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). 

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.  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.

[hyperplane]

I'm not intending this as an attack toward anyone, I merely have a question.

This is related to what Scott Brown said earlier in this thread:

Chris, when you did the real-time S/PDIF transfer, and recorded the WAV file to your hard disk, was it recorded as a 32-bit (float) WAV file?


I don't know if this would make much difference (24-bit via firewire vs. 32-bit float via S/PDIF)... but what I'm trying to get at is this: if you recorded the file as a 32-bit (float) WAV file (if this is even possible) via S/PDIF transfer, then would there be a difference between doing that vs. taking a 24-bit file and 'upsampling' it to 32-bit (float) file???

Again, I don't know, so I'm posing the question about how the S/PDIF file was recorded onto hard disk (to Chris), and posing the 24-bit upsampled to 32-bit question to anyone with insights/input.

[Shawn]

You can't discount the improved sound just because the controls weren't tight enough to narrow it down to only one variable.  Brian verified there are differences in the waveforms so you can't say it's psycho-acoustic nonsense.  By everyone's definition, we should not have been able to  improve on a firewire transfer.  I believe these files disprove that assumption.

scientifically speaking the test is invalid. You say that it sounds better because of the transfer method, but in reality the difference in the wave forms could be because of any combination of the variables in the test. You seem uninterested in doing a very simple test with only one variable that could prove which method is superior.

I didn't say that you couldn't improve on a firewire transfer. For all I care your transfer process could involve running the files through a DAC and a bunch of outboard analog gear into a ADC and back into another hard drive recorder. That may improve the sound, but that's not my point. My point is that a firewire transfer is going to be an exact copy of the files from the 722, which you seem to disagree with. You seem to think that an anti vibration pad placed underneath a computer during the firewire transfer makes the end product sound better, which is absolute nonsense.

edit for speling.

[scb]

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

[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.

[twatts (pants are so over-rated...)]

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.

Hence why we use the MD5 system to verify that we have perfect copies of shows.  The 2 samples, if the have the same MD5s, are exactly identical PERIOD.  If you hear a difference, its because you want to.  If everything is done correctly, a perfect digital copy is a perfect digital copy (the MD5 verify as so), so any discrepency is all in your head.

Terry