>>>Maybe it would make sense to us concerning your quality loss if you explained step for step the process you did <<<

There is nothing to explain.

Select a folder to zip and that's it. Next day unzip. Next day zip these unziped files and so on for a week. It took a week because it took almost an hour to zip , and almost the same to unzip each time.

To the guy above. yes please stop, you have no idea how amp simulators or reverb algorithms work, so let's just stop it here. I'm fine with that. I don't feel like entering that discussion and I don't want to argue with people who run to google and wikipedia after every post looking for confirmations of their bias.

My point was simply that once you record an amp digitally you have all of it in 0 and 1s, perfectly laid out. Then you have to develop an algorithm based on that. In the end nobody can do it the way it's supposed to be done even though they have all of the info in 0s and 1s. It's possible that algorithms used for lossless compression aren't as perfect as we think they are. That's all, why is that so difficult to understand. To a computer it's all 0s and 1s and all the same thing anyway, comparison is therefore valid.

>>>It has nothing to do with amp simulators, it is a mathematical function<<<

Also called an algorithm which is exactly what is used in all these examples. It's all a mathematical function.

>>>By the way, all file compressors like ZIP, RAR and 7ZIP use CRC-32 checksum signatures to determine if a file has changed through the process and will warn you if the values don't match.<<<

And we know for a fact that all computer programs are perfect and never make any mistakes. Maybe that's why Sony support doesn't answer your e-mails, because they know there is no way anything can be wrong ( I personally don't know, Vegas has actually been perfect for me, so never had to contact them ).

That is interesting. So many people on this forum bitch and moan about Vegas, but one insinuation that zip utilities also make mistakes, it's heresy, it's the end of the world.

They are both computer code which does something using 1s and 0s. If one can screw up so can the other.


>>>deusx, as far as I'm concerned, your credibility on this forum has just reached zero<<<

That's good. When I logged into my account yesterday credibility was at -7

deusx, I can't believe that this thread has gone on for so long trying to convince you that ZIP is lossless. You are absolutely, positively, 100% dead wrong.

"It's possible that algorithms used for lossless compression aren't as perfect as we think they are."

No, it's not possible. Considering how many people use lossless compression programs, if there were a problem, the entire Internet would be ablaze with people complaining about it.

I offered you irrefutable proof and you have ignored it. Just try the test I suggested a few posts up, it is a way to independently verify whether two files are bit-for-bit identical. It is certainly far more accurate than your method of looking at the playback of a video file and saying, "hmmm, that looks a little weird to me."

I think deusx's tests should be run again in a repeatable environment. It's easy to compare two image files bit-for-bit. Of course I already think I know the answer.
;?)

Perhaps what deusx did wasn't what he and we think he did??

I recall doing something that if I hadn't paid attention to what I was doing might have given the result deusx is claiming he'd seen. Unfortunately I cannot recall exactly what it was.

Certainly if I was writing some form of "archive" utility for the unwashed masses that likely had a zillion uncompressed image files offering them the ability to convert from say PNG or RAW to JPG on the fly or downscale JPGs would save them a lot of space. I know some Windows utilities do this without much warning.

Bob.

Original poster 'LV studio' must really be confused right now.

How File Compression Works.

VMP

deusx is using the "7zip" file compressor, it has no option to convert files to another format, lossy or otherwise.

" If it has to be 'told" to look harder that means it doesn't always "see" everything therefore it can make mistakes. "

No, it doesn't make mistakes. By looking harder, the zip program looks for more difficult patterns and patterns within the tokens. If the zip program sees a repeat pattern of tokens while doing a "try harder" or "more compression" mode, then it can replace all those tokens with a single token. It does work, but the zip time is longer and usually doesn't help much.

All zip algorithms are lossless.

Digital simulations of analogue amps do not create an exact copy of an analogue waveform. That is mathematically impossible because of the nature of digital sampling which samples the analogue waveform at intervals rather than continuously. This means the sampling of the waveform is switched on and off or its binary equivalent, 1/0, to create a digital snapshot of the waveform over time.

It might be true that as technology advances the digital sampling of the waveform improves (increases) therefore providing greater accuracy but it is impossible for a digital waveform to replicate an analogue waveform exactly.

As for ZIP files they are lossless end of story.

>>>>>Digital simulations of analogue amps do not create an exact copy of an analogue waveform. That is mathematically impossible because of the nature of digital sampling which samples the analogue waveform at intervals rather than continuously. This means the sampling of the waveform is switched on and off or its binary equivalent, 1/0, to create a digital snapshot of the waveform over time. <<<

Isn't that exactly what happens when you just record it digitally? It's digitally sampled and it sounds ( more or less ) like a real amp. But, when you try to simulate it it does not.

If I use winzip and 7 zip to compress the same file ( same settings, algorithm compression level and so on ), will the resulting zip file be exactly the same?

If not, there is your answer. There is room for discrepancies, therefore error is possible.

I mentioned in one of the posts above that I tried zip/unzip on one file, 5 times in a row and I could not see the difference which would confirm that it is lossless, but I also know that I wasn't dreaming when I noticed the difference in quality in that other case.

Your use of the term discrepancy is invalid in this context. Different Zip algorithms may use different methods for compressing and therefore result in different compressed files. However, decompressing them ALWAYS results in restoring the exact original file bit-for-bit.

No, there is no error possible.

Also, your comparison of compression to the digital simulation of analogue is invalid. Zip algorithms are not modeling an analog original. They start with something that is already digital. You are comparing apples and orange thumbtacks.

No, Amp simulators do not start with an analog original. They record ( sample ) the analog first and then try to simulate that. They are simulating a digital recording of an analog amp therefore it's the same thing. In both cases it's digital to digital.

"They record ( sample ) the analog first"

Sure sounds like they're starting with analog.

Regardless, it's a completely different and unrelated process. There simply is no comparison. There is no common ground between what the two different applications are doing, so trying to compare them is absurdly pointless.

I'm not sure how many times you have to be told this, but ... Zip compression is always lossless.

"I mentioned in one of the posts above that I tried zip/unzip on one file, 5 times in a row and I could not see the difference which would confirm that it is lossless, but I also know that I wasn't dreaming when I noticed the difference in quality in that other case."

If you were using just 7zip as you said, then yes, you were dreaming. You can not "confirm" it is lossless just by looking at it, that is utterly ridiculous. Once again, go up to my post where I gave you the link to the CRC-32/MD5 checksum calculator and try what I said, you will find that there is NO DIFFERENCE WHATSOEVER between the source file and the resulting unzipped file. You can go through 1,000 ZIP/UNZIP passes and the results will be EXACTLY the same. Perhaps you don't want it proven to you and you would rather continue defending your blatantly ignorant position.

i shouldn't really be amazed at this thread, after all, there are climate change deniers ;-)

You make a good point, ushere.

WARNING: I am no IT Expert!

Premis: Is it at all, AT ALL, possible to unzip and have pixels "appear" in different places than they should, and STILL have the exact same checksum? Enough to make it look/appear different? I know, I know the whole process SHOULD be transparent.

Just wanted to add this to the discussion, as deusx comes across still as very strong on "appearance" that I for one can't shake loose his tenacious grip on that.

Also, could a Preview badly/incorrectly reveal, incorrectly, the unzip?

Grazie

"Is it at all, AT ALL, possible to unzip and have pixels "appear" in different places than they should, and STILL have the exact same checksum?"

In the case of calculating CRC-32 and MD5 values, it is NOT possible to have the same checksum if the bytes are the same but just rearranged into a different order. Look, file archivers like ZIP, RAR and 7zip are absolutely lossless, what comes out of the archive is absolutely identical in every way to what went in and if they aren't identical, the archive program will tell you with a very clear warning. Grazie, there's no getting around it, deusx is flat out wrong.

Thanks John.

G

VMP, LV studio is doing fine. Thanks for your concern. I got enough info within the 1st ten posts.

Yes, this thread has become a poster child of sorts . . .

Good to know LV studio.

VMP

Oh, dear, climate change.

Yeah, the climate has warmed (though not much, and something contrarian has been happening for the past couple decades). Yeah, CO2 is a "greenhouse gas." The degree of influence is the issue. If we're talking "We're all doomed!" then put me in the skeptical category.

By the way, a very interesting aspect of using an MD5 or SHA1 hash to verify the validity of a file is that if a SINGLE BIT is changed in the file then the MD5 "fingerprint" will radically change. Here's an example I just did:

I took an old MS Word doc file that was 1.4MB in size and using "MD5 Check" I generated an MD5 fingerprint of: 7B69073A9888A54C1F1BFAE148863FA2.

Then I got inside that Word file using "Hex Editor" and changed a SINGLE BIT and saved the new file. The MD5 Check tool now returned an MD5 fingerprint of: 42FC4AEA93C1F379337BD7B763B8B24A. Pretty cool, eh?