to reiterate, quicklookup is a hash calculated from bits of a track.

case 1) is correct. case 2) is not. in my mind, jemplode assumes that a quicklookup match is the same file, no hash checking involved. since all its doing is either skipping or setting a ref, hash should already be in the tags. the user purposely risks a collision when enabling this feature. speed vs accuracy.

if the user becomes ultra paranoid that quicklookup is missing songs, he has the option to do a full hash compare (i.e. sync in previous post above). in this case, jemplode should notify user if quicklookups are the same but the full hash isn't. if this situation ever happened, i would imagine that you can "blacklist" the quicklookup, so matching songs will revert back to calculating the hash for the one track.

so, 3 cases when using quick lookup.
1) quicklookup has no hits, hash is calculated, track uploaded
2) quicklookup has a hit, ref/skip the track, hash not calculated
3) quicklookup has a hit on thats blacklisted, hash calculated and looked up for hits (regular algorithm).