Online file transfer added glitch to audio

[Suade]

Hello, I'm posting to ask if any of you have had any issues like the one I've just experienced. I'd like to avoid a repeat of it so any information could be helpful.

I've just received feedback that a mastered file received by a client contains a glitch in the audio. They sent this picture as an illustration:


The same file here on my computer has no problem so it seems that something in the transfer process caused it. The file was zipped with two others and uploaded via Sendspace so I deduce that one or the other of those two processes is the likely culprit.

Any ideas??

[16/44.1]

And the zip was not corrupted?
Strange.

[Waltz Mastering]

I would download the zip file that you sent yourself to verify and rule out that anything on the other end could have caused it.

[Greg Reierson]

I'd look for another possible cause. Zipping and then successfully unzipping a file is pretty much bullet proof. Any corruption along the way and it will not unzip. Something must have happened to the file before or after it was zipped.


GR

[Virtalahde]

Originally Posted by Greg Reierson

I'd look for another possible cause. Zipping and then successfully unzipping a file is pretty much bullet proof. Any corruption along the way and it will not unzip.

I'm still a little confused in this matter. I thought it would be like this, but I remember Bob Ohlsson explaining me @ PSW how it isn't exactly like this and you can still corrupt an audio file inside a ZIP.

A RAR is a little bit more bulletproof, but not everyone uses them. I like RAR.

[UnderTow]

Originally Posted by Virtalahde

I'm still a little confused in this matter. I thought it would be like this, but I remember Bob Ohlsson explaining me @ PSW how it isn't exactly like this and you can still corrupt an audio file inside a ZIP.

ZIP uses a CRC. (Cyclic Redundancy Check). It is extremely unlikely the zip file got corrupted during transit and the receiver had no errors on unzipping. So unlikely that I would say it didn't happen and the error occurred somewhere else.

Alistair

[Petrus]

If there was a glitch caused by zip or transfer, it would not look like some kind of " normal" audio glitch, it would be just a total mess. Those bits are measuremet data, how could a compression/decompression program know how to make a neat, but wrong shape waveform by mistake?

This has happened before zipping. Or at the other end for some reason.

[CJ Mastering]

The file was zipped with two others and uploaded via Sendspace so I deduce that one or the other of those two processes is the likely culprit.

Is it possible, anything is possible, but its highly unlikely.

Send the files, but dont zip them. Its only 3 files. Its not a 15 song album. But I really dont think the zip is the problem.

Cj

[bigdoghat]

This happened to me once sending a mix via mediafire - I'm 100% positive that the mix was good before it was sent. I checked it twice then later after learning about the glitch on the mix, I loaded up the file I sent and the file they received. Huge glitch at the end of the file they received, no glitch on the file I sent.

I asked a mastering friend of mine about this - he said you need to use a delivery system that does a 'parity check'. What this means is, the host looks at the file you sent and the file received and makes sure they are identical. A lot of people seem to have good success with yousendit, don't know about the other ones

[Greg Reierson]

Originally Posted by bigdoghat

I asked a mastering friend of mine about this - he said you need to use a delivery system that does a 'parity check'. What this means is, the host looks at the file you sent and the file received and makes sure they are identical.

That's what zipping does. You can tell YouSendIt to zip the file before sending.


GR

[Ben F]

Originally Posted by Greg Reierson

That's what zipping does. You can tell YouSendIt to zip the file before sending.


GR

TCP/IP does that anyway (checks for lost packets).

I've seen audio glitches happen due to a fragmented hard drive.

[zenmastering]

Originally Posted by CJ Mastering

Send the files, but dont zip them. Its only 3 files. Its not a 15 song album.
Cj

I disagree. You really don't want to send any kind of media file without protecting it with either a Zip or RAR encoding. The built-in CRC is what lets you know the file is accurate to the source (or not). RAR is most preferable and lets you work with files over 4GB.

Turning off the compression and just converting the audio file into a RAR 'container' (same size as source) speeds up encoding and offers exactly the same level of reliability.

As you said, the original poster's issue most likely isn't the zip-encoding. Who knows what's going on at the client's end of the chain?

Graemme

[streetbeats]

Originally Posted by zenmastering

I disagree. You really don't want to send any kind of media file without protecting it with either a Zip or RAR encoding. The built-in CRC is what lets you know the file is accurate to the source (or not). RAR is most preferable and lets you work with files over 4GB.

This... thumbsup

Turning off the compression and just converting the audio file into a RAR 'container' (same size as source) speeds up encoding and offers exactly the same level of reliability.

Graemme

personally I never really have a need to use WinRARs 'store' (zero compression) algorithm....even using the 'best' algorithm on large archives doesn't seem to be problematic on most modern cpus.

[Suade]

Ok - well - I've unzipped my local version of the zipped archive and the file inside is intact - no problem.

Now I'm downloading the zip archive from the server to see if there's anything different there. Will post again once I've checked.....

[aleatoric]

Originally Posted by Suade

Will post again once I've checked.....

Update? I'm interested to hear if you got to the bottom of this.

[Mark D.]

Yeah, me too.

[da goose]

this is strange indeed... though i had something quite similar recently with a rar file that i transfered to a customer.
In some kind of way there was a really small silence (sounded like a glitch and looked like it) 'inserted' in the file which, if you just removed it, fixed the problem. The file i had didn't have the problem but the file that was online had this. Not sure if it was because of the RAR'ing or uploading but it was there for sure..

[bkuijt]

Two questions for TS:

- if the archive was zipped, did you unzip it again to see if it was perhaps an error during unzipping?

- I'm not sure but it seems unlikely that a file-error will result in an identical audio-error in left and right channel.
But this is what you screen shot tells us... Maybe the source of the glitch is somewhere else?

After being bitten before by the problem TS is having I stick with MD5 checksums where and when I can.
Verifying md5 after all processes is very secure.

bests,

[Suade]

Hi - sorry for the delay in reporting back - I've been away from home for a few days.

I've downloaded the zipfile from the Sendspace server and unpacked it here and there's no problem. It seems that this file damage happened somewhere at the clients end where, as far as I know, they've simply downloaded, unzipped and opened the file in Sound Forge 10.

Is this a Sound Forge issue? Or just a mystery....

[UnderTow]

Originally Posted by Suade

Hi - sorry for the delay in reporting back - I've been away from home for a few days.

I've downloaded the zipfile from the Sendspace server and unpacked it here and there's no problem. It seems that this file damage happened somewhere at the clients end where, as far as I know, they've simply downloaded, unzipped and opened the file in Sound Forge 10.

Is this a Sound Forge issue? Or just a mystery....

The most likely explanation is operator error. The client did something to the file. Maybe they opened it in SF and then accidentally did something to it. Who knows...

ZIP having a CRC, the chances that it unzipped without errors compared to the chance that the client made a mistake is probably one to one quadrillion. The chances of the client knowing exactly what they did at the time is zero. (If they did, they wouldn't have done it!)

Alistair

[hifitubes]

Originally Posted by UnderTow

The most likely explanation is operator error. The client did something to the file. Maybe they opened it in SF and then accidentally did something to it. Who knows...

ZIP having a CRC, the chances that it unzipped without errors compared to the chance that the client made a mistake is probably one to one quadrillion. The chances of the client knowing exactly what they did at the time is zero. (If they did, they wouldn't have done it!)

Alistair

A remote possibility, is that they unzipped, and copied the file, and bad RAM acted up, or starting throwing errors at exactly that time.

Or, maybe the unzipped and copied to another machine, and starting working/copying it using that machine which has bad RAM.

With bad RAM, your PC can still be used, but even a defrag can corrupt files. I suggest any of the free online mem testers, and run two instances at once, or have them try Prime95 focused on memory.