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.