Van den Hul introduces 2.9 mm balanced cable -"The Orchid" (Tunnel Technology)

[Lil Kim Jong-Il]

i make an md5 of the file on the recorder, and then use that md5 sig to test the one that is copied to the harddrive...

If you are using a firewire connection to access the recorder harddrive as a mounted block device, the data transfer should be through the asynchronous channel and error correction handled by the physical layer protocol should ensure that the upper layers see no bit errors.  When I saw MD5 issues with the 722 file transfers way back when, I blamed the 722's buffer management and not the firewire link layer.  But who really knows?

I assume that you are doing your MD5 test with the recorder mounted as a drive on your PC.  If so, then the file data is being transfered once to your workstation for the initial digest calculation and then again when you do the transfer to the PC HD.  You are using the same link twice.   If your digests don't match, you can't be sure which is the correct one or even if either is correct.  The only sure solution is to have a recorder that can internally calculate a digest and report that for comparison against the digest calculated on the file after it has been transferred.   

It is a nice sanity test because a random error won't appear the same way twice but it does not ensure that the firmware isn't sending erroneous data in a repeatable way.  If the device has a fault in the firewire driver, an internal digest calculation would reveal a problem.

[macdaddy]

lil kim-

if i have a card in the reader, and i run md5sum.exe on that wav file on the cf drive, the file on the card (recording) is being read. i save the signature as an md5 file.

then i copy the wav file from the cf to the hd (i use usb 2.0, but the interface is moot). i then take the md5 and run it against the file on my hardrive. if they check ok, then i know they are the exact same...

[it-goes-to-eleven]

Over a firewire link, file transfers are performed using asynchronous mode which does provide error correction.

Good to know.  Though I'm gonna start checking checksums with rsync (very easy). Just to see if there are any consistency problems.  Should be quicker with the new firmware.

I had a pc that had an incurable and *silent* dma transfer corruption problem.  It would mess flac files up every once in a while when they were copied from disk to disk or just written. I ended up installing a promise ata controller and moved all drives off the system interface.

As others have mentioned.. It isn't if you will get silent data corruption, it is when.

[Lil Kim Jong-Il]

macdaddy:
Oh.  If you have a card reader in your PC, its a different story.  You see MD5 mismatch when accessing the card in a reader?

freelunch:
Thats a good point that it could have been the firewire driver in the PC and nothing to do with the 722.

I used to do what Bean suggests above (mounting the 722 over firewire and doing a sanity check digest) and every once in a while I would get an error.  Sometimes I got 3 different digests when I ran three transfers of the same file.  I can't remember the exact differences in the data but iirc it looked like a dropped sample or two, which is inaudible.   Now I just blow it off because it was making me tense.  When I get the new firmware, I might go back to doing the test and see what happens.  It was just too painful at the speeds of the revision I have loaded.

[macdaddy]

once, but that couldve been a 'puter hiccup, ya'know..? i get them when copying from the archived dvd-rs. and i also get them when i check the md5s on dvd-rs, so sometimes your burns arent perfect - i always check the md5 of burns...

[F.O.Bean]

macdaddy:
Oh.  If you have a card reader in your PC, its a different story.  You see MD5 mismatch when accessing the card in a reader?

freelunch:
Thats a good point that it could have been the firewire driver in the PC and nothing to do with the 722.

I used to do what Bean suggests above (mounting the 722 over firewire and doing a sanity check digest) and every once in a while I would get an error.  Sometimes I got 3 different digests when I ran three transfers of the same file.  I can't remember the exact differences in the data but iirc it looked like a dropped sample or two, which is inaudible.   Now I just blow it off because it was making me tense.  When I get the new firmware, I might go back to doing the test and see what happens.  It was just too painful at the speeds of the revision I have loaded.

yeah, it was painful w/ 1.74, 1.79 is about 2x faster i would guess, maybe faster

once, but that couldve been a 'puter hiccup, ya'know..? i get them when copying from the archived dvd-rs. and i also get them when i check the md5s on dvd-rs, so sometimes your burns arent perfect - i always check the md5 of burns...

i also include md5's w/ all of my data wavs/flacs and even after burning in nero w/ nero verifying, i still verify the md5's w/ mkwact before i put them away, a bit anal, but whatever, rather safe than sorry.

CRC errors are a nightmare

[F.O.Bean]

Damn straight.  The 7xx is all about hitting record and the calm that comes from knowing you'll get it.

word!

[cshepherd]

Hi Jason,
It's just an experiment to see if there's an audible difference between firewire and s/pdif.  We honestly don't know, but want to find out for ourselves.   I've got a file transferred via firewire on my laptop.  We're looking forward to listening to both transfers.  I'd be happy to make them available to anyone interested.  We've got two Wilco shows to experiment with and Panic's coming up next week as well.

Thanks for checking it out,
Chris

Chris,
thanks for responding to me.  I don't really mean to make a big deal out of this, but I'm still wondering.  assuming you agree that the firewire copy is an exact copy of the file on the 722, then it's true that any possible difference would be inaccuracies in the S/PDIF data stream.  ok, that's fine.  just testing the accuracy and the reliability of the S/PDIF output, I can see that as worthwhile.  but instead of a listening test as to whether or not you can hear any differences, wouldn't it be better and more precise to just trim both files (the one transferred via S/PDIF and the one transferred via firewire) to start and end at the exact same point, and then compare wav files.  there are numerous ways to do it.  you could create an .md5 file for each .wav, you could invert one file and then mix together.  if they are identical, that would yield an absolutely flat line.  and I think even EAC has a "wav compare" feature.  Don't you think this would be the best way to compare the two files?
- Jason

Jason,
We're not making the assumption that firewire is a flawless transfer platform.  We're trying to find out if one sounds better than the other, not just documenting differences between the platforms.   This may seem like reinventing the wheel, but we want to hear for ourselves.

Chris

you don't need to make an assumption that firewire is flawless. it's a fact.  if the firewire wasn't perfect files transferred throught it would be corrupt.

Comp files are available for download here:  http://taperssection.com/index.php?topic=71964.0 . 

[Gaze]

That cable looks and sounds (description-wise) just like the Semflex HPI120, only with a pink sleeve.

http://www.semflex.com/pdf/HPI120.pdf 

I'm sorry, but it's funny, I can't seem to figure out, what the "hulliflex" really are. I can see it is patented, but that's about it. Don't mean to sound like a troll, but there's quite a lot of fluff in the text about the hulliflex, but no real information. Same with the cable itself. Loads of fluff, about the "hulliflex" making the cable sound better over time (it's a type of plastics, so good luck with that one), and such. But I guess that it's like Coca Cola - it sells because there is an image and a story to go with it. You're buying the story to quench your thirst. And that Coke all of sudden is doing a much better job than water.

Each to his own, though.

I do like the "skinnyness" of the cable, though, but I am not convinced.