What, exactly, is the history of that particular file? The process of salvaging it requires reversing each step that got it to where it is now... precisely. The steps required cannot be determined by inspection, only by knowledge of the history.
So, for example, if an encrypted recording from HDR (all recordings are encrypted in the process of recording) is transferred to HDR and decrypted, it has been (effectively) scrambled twice. You would need to unapply DECRYPT, then apply DECRYPT to obtain a recording in-the-clear.
Fortunately we now have PC tools capable of applying ENCRYPT and DECRYPT, so long as you can obtain the serial number and MAC for HDR (from which KEY is obtained, the necessary input parameter to make the generalised ENCRYPT and DECRYPT functions into ENCRYPT and DECRYPT). However, unless you know exactly what encrypt and decrypt operations to apply, with what keys, and in what sequence, you would be fishing in the dark (apply the wrong operation, or with the wrong key, or in the wrong order, and you would be making it worse not better).
For constant k:
DECRYPT[k]( ENCRYPT[k](file) ) = file
ENCRYPT[k]( DECRYPT[k](file) ) = file
DECRYPT[k](file) ≠ ENCRYPT[k](file)
The DECRYPT function scrambles a file just as effectively as the ENCRYPT function, unless the file was originally encrypted with the same key.