No loss of audio integrity when transfering files via ftp. Very very common method of transfer to a mastering engineer.

Don't worry, it's extremely reliable way to transfer files. It's got a builtin error checker thingamabob.

A contrasting opinion...

It has been our experience that audio files delivered via the internet (ftp, iChat, iDisc, etc) has consistently sounded inferior to the same files delivered on physical media.

Did the data content become corrupted?: NO.
Is the data bit for bit accurate?: YES.
Does it pass the so-called "polarity test"?: YES.
So then it should sound the same: IT DOESN'T.
How can that be?: I DON'T KNOW.

We have not discovered the technical reason for this un-logical discrepancy. What we do know is what our ears have told us in many, many blind listening tests. Only once has the electronically delivered files sound equal to the physical media. Only once! Call it voodoo if you like, but apparently there is more to audio data playback than just bit content.

My advise (from best to worst):
1. Analog tape (only if you are experienced and have an excellent working deck)
2. Print (write) your mixes directly to a hard drive which can be sent to your ME and played from directly.
3. Transfer your data to a data CD/DVD-r.
4. Use a DAT, Masterlink, or the like.
5. FTP/Internet.

Things keep changing and hopefully improving. The internet will someday be able to move audio with the same losses as physical media. Then we will have quality as well as convenience.

Hi,

I'd be curious to hear the files that you have compared because like you said it is illogical...but not impossible. I am very sceptical about this if everything has been done correctly ie, data storage representations, coding from different type of systems. You should take a look at: http://www.w3.org/Protocols/rfc959/3_DataTransfer.html , it gives a pretty good picture about this and further more as well. I have done so many files transfered via internet (FTP) and never heard any degradation. Maybe it would be worthed to do a null test with these ?

Regards,

Richard

TrilliumSound wrote: ... Maybe it would be worthed to do a null test with these ?

That is what I meant by "polarity test". I am not arguing that the data content is compromised. In fact, I have run a battery of diagnostic tests for data parity/corruption. In almost all cases the data integrity has proven to been sound. The cause for the internet's current inferior sound must be something else.

TrilliumSound wrote: ...I have done so many files transfered via internet (FTP) and never heard any degradation.

Have you actually compared the "ftp" file to an original? Try this: Send an audio file to an ftp site. Retrieve it and import it into your DAW along with the original file. Now A/B them in real time. Can you hear a difference?

We have repeatably been able to distinguish the original from the copy with many engineers and clients. When a number of humans can accurately choose them blind, 19 out of 20 times, nobody is fooling themselves! Admittedly the differences are slight. An FTP transmitted file will not be the end of the world. But better IS better, so I advise our clients against it when practical.

I have personally never experienced this. What i have found is that SD2 files get their headers stripped if it is uploaded as the wrong format. I guess something could be causing some timing errors like jitter or something like that. If there is a difference, it's so little that it doesn't concern me any more than if they printed the files on a cheap cdr. I've bounced stuff back and forth and never noticed anything different from the original.

I've done polarity tests with so many things...

Disc brands -
Writing Speeds -
WAV to AIF and back -
FTP -
Copy n' Paste -

Always the same result...

Zero.

Zilla,

Maybe the files are losing some Quarks, i.e. sub-atomic particles, in the ftp transfer ? :D

Yes, I'm making a joke... BUT

a few times I've wondered if there is something invisible, smaller than bits & samples, that our analytical instruments can't measure...that can get lost in a transfer... ?

I know it sounds like superstitious audio voodoo.... sub nano j*tter, any thoughts ?

Usually I pass it off as the placebo effect, but I'm not 110% convinced.

Peace

8)

JerryTubb wrote: Maybe the files are losing some Quarks, i.e. sub-atomic particles, in the ftp transfer ? :D

I know it sounds like superstitious audio voodoo.... sub nano j*tter, any thoughts ?

Yes, we need a CONFIDENZ-MULATOR to restore the sub nano jitter that might lost in ftp transferring :lol:

No, I think Zilla is just a brilliant comedian, such that it almost didn't pass as a joke.

Thanks everyone for the feedback.
Im going to ftp the files and cautiously listen for any degredation and or quark loss.

I've never had/heard a problem...

yet

jamiey wrote: No, I think Zilla is just a brilliant comedian, such that it almost didn't pass as a joke.

For the record, I was not joking. But I think the nano-quark jitter remark was pretty funny. Maybe we should send Leonard Nimoy in search of........ . . . . .

Zilla wrote: Have you actually compared the "ftp" file to an original?

Yes I did and I do it several times a week.

I think there is something really obvious in terms of degradation if there is several people that can accurately choose them blind, 19 out of 20 times !! I don't know...I still maintain that there might be something wrong with the FTP processes on your end. Otherwise, at least 6 or 7 people here in this thread would have said that they heard a degradation because of FTP transferts, no?

Did you read a bit the link that I previously posted ? Maybe it can lead you to something or ring a bell, never know.

All the best,

Richard

TrilliumSound wrote: ... there might be something wrong with the FTP processes on your end....Did you read a bit the link that I previously posted ?

Possibly so. But all our other documents and emails arrive without apparent change, I don't know. We are currently having a T1 line installed, so maybe that will move things in the right direction. Thanks for that link. I did download it but its not light reading (for me anyway). When the studio schedule relaxes a little, I will give it a study.

Great, let us know...I am personally very interested about this.

Thanks,

Richard

Me too (interested). To me it would seem that bits are bits and if they match there should be no difference. Also, if I thought that I heard a difference but the null test said otherwise I would chalk it up to the error being in my ear/head. Several people who hear a difference consistently though... wierd things happening.

I'm having a REAL hard time with this one. It can't be timing / jitter - the file is just *data* and there is no timing associated with the file. It's simply a numbers game. If the ftp'd and original file are identical (and that's a pretty simple test for any good file editor), how in the world can they sound different?

Zilla wrote: But I think the nano-quark jitter remark was pretty funny. Maybe we should send Leonard Nimoy in search of......

OK Zilla

Let's coin a new term here... Quark-Bits... a.k.a. Sub Atomic Bits !

Maybe when it's actually proven... we'll get the Nobel from AES !

Peace 8)

dpd wrote: I'm having a REAL hard time with this one. It can't be timing / jitter - the file is just *data* and there is no timing associated with the file. It's simply a numbers game. If the ftp'd and original file are identical (and that's a pretty simple test for any good file editor), how in the world can they sound different?

Thats my view on this as well. If it sounds different then the data must be different somewhere.

Or the testing method is influencing the descision somehow.

jamiey wrote: Or the testing method is influencing the descision somehow.

Yes, that too !

Richard

jamiey wrote: Or the testing method is influencing the descision somehow.

Is it possible... that the process of importing music data into the DAW for a null test renders the differences to zero... or at least below normal measurement by ear or test gear? Just a simple question or idea, do we need to look from a diff angle?

In the world of physics, they're finding new info that doesn' t fit the trad Newtonian model.... maybe we should be a little more open minded... rather than say... "well data is data, and bits are bits, and that's all there is"
8)

Random thoughts....

What happens when you burn a CDR and there are those little errors all over the place that many claim are unavoidable (plextor burners seems to be best, supposadly). Do those tracks pass the null test? I've never tried this, but maybe it's a related issue.

Another idea I just thought of (maybe someone else has as well) is that data is stored in many different places on a hard-drive (fragmented), so apon real-time playing back there may be slight errors due to the hard drive seeking or some other related crap like that - I don't know much about it. When you do the null test, are you actually "rendering" the mix, or playing back real-time? Doesn't multitrack software 'sync' files together, in which case it wouldn't matter if you rendered the null test or not.

We're not just talking about null tests but also, bit for bit data verification. If every piece of the data between the 2 are exactly the same, how could the computer read it any differently to make it sound any different?

The two files may have identical bit-for-bit data, but they are stored on the harddrive differently, one may be alot more fragmented then the other. That was what I was trying to say.

I don't think a bit or byte are fragmented, I think fragmentation is the result of non-contiguous clusters ,and in a file, depending of the size and the type of formatting (cluster sizes). So, if you have 4kb cluster size then you have 4,000 bytes. So even if it is fragmented, the information (data) is exactely the same, but not stored contiguously, so it could take few more ms for your hard disk to read it.

Richard

"I think fragmentation is the result of non-contiguous clusters"

Right, this is one reason why when you open the properties of a file it'll display two different amounts that it takes up on the harddrive.

No, I don't think so,

Size refers to the files actual byte count. Size on disk refers to the amount of cluster allocation the file is taking up.

When you write a file to disk, the smallest unit it can take up is 1 cluster. If you have a 1024MB (1GB) partition, and the default cluster size is 32KB, a 1KB file will take up a 16k cluster.
Since you can't have more than one file occupying a cluster, the remainder of that cluster is considered wasted space. In this example, a 1KB file is taking up 32KB of disk space, and wasting 31KB of that space.

Sorry I didn't eleborate, I assumed you would put two and two together.

Jamiey,

Don't be sorry, it may sounded rude but believe me it was not my intention. Ok, hmmm...what was the subject of this thread again ? :D

Richard