david-pace/wave-recovery-tool

Tool to display WAVE/AIFF file header information and to restore corrupted WAVE/AIFF file headers

wave-recovery-tool's Issues

UnicodeDecodeError on AIFF restore

I am trying to restore an AIFF file on macOS Catalina but having a few issues.

1. Running python3 -r wave-recovery-tool-master/waverecovery.py audio restored gave me the error Unknown option: -r
2. Changing the position of -r to give python3 wave-recovery-tool-master/waverecovery.py -r audio restored gets around that but then I'm getting an error saying

Creating destination directory restored...
Scanning directory audio...
------------------------------------------
waverecovery.py: UnicodeDecodeError('utf-8', b'\x15\xbd\xd2U', 1, 2, 'invalid start byte')

Do you have any thoughts about how I can get around this problem?

Thank you!

Support Partial Restoration of Stop/Djvu Encrypted Files

The Stop/Djvu ransomware encrypts the first 153605 bytes (150 kB + 5 bytes) of files and adds 334 additional bytes at the end. While still in encrypted state, the audio data after byte 153605 can still be recovered.

This involves:

• Computing the offset of the byte that is the first byte of a frame (example: bit depth 24 bit, stereo: frame size is 6 bytes; first usable byte in a WAVE file is at offset 44 + (25594 * 6) = 153608
• End offset is <total number of bytes> - 334

This mode should be activated by providing the following application parameter:

-a djvu

Add Support to Restore Ableton Live AIFF Files and Add Application Parameter

The current implementation assumes the audio data offsets of Apple Logic. However, there are cases where audio files have to be recovered from other applications, e.g. Ableton Live. There should be a possibility to provide a parameter that identifies the application in order to use different offsets during the restoration process.

Long parameter name: --application
Short parameter name: -a

Possible values for initial version:

• logic (Apple Logic, default)
• live (Ableton Live)

Provide Support to Detect Bit Depth and Number of Channels

In general it is not possible to tell the bit depth and the number of channels by analyzing the audio bytes. However, under certain conditions it is possible to exclude some combinations of bit depth and number of channels.

Assuming all audio bytes are still present, the following assumptions can be made:

• divisible by 6: 24 bit stereo
• divisible by 4: 16 bit stereo
• divisible by 3: 24 bit mono
• divisible by 2: 16 bit mono

The problem is that some of those cases apply at the same time, e.g. if the number is divisible by 6 it is also divisible by 3 and 2. Worst case would be multiples of 12, for which all possibilities would apply.

Expected Subchunk 2 (data chunk) Size for WAVE Files is Incorrect

When analyzing a restored file I noticed that the expected subchunk 2 size is wrong:

[WARNING] Data subchunk size does not match file size. Should be 59100458, but is: 59100450 (difference: 8)

After looking at the file (which has 59100494 bytes) I found that 59100450 is actually correct (<total size in bytes> - 44).

Could you provide Sample wave files?

Hi,

Could you provide sample refererenc & corrupted wave files?

Also i have made code automate repair wave file encrypted by stop/djvu ransomware here:

https://github.com/DRCRecoveryData/WAV-Repair-Tool-for-Stop-DJVU-Ransomware

AIFF Analysis Fails with error('unpack requires a buffer of 4 bytes')

This error occurred when analyzing a folder containing ~ 1300 AIFF files:

waverecovery.py: error('unpack requires a buffer of 4 bytes')
                 for help use --help

AIFF Recovery Does not Detect Completely Destroyed Headers

If an AIFF Header is destroyed completely, this is not detected correctly and data might be copied at the beginning that does not belong there. Instead, a completely new header should be written at the beginning of the destination file.

Chunk Sizes are not Always Correct

Sometimes the chunk sizes are not computed correctly.

The background is that these are computed based on the size of the source files (i.e. the damaged files). The computed chunk sizes are only correct if the restored file is exactly as big as the damaged file. While this is correct in most cases, it does not hold true if:

• custom start or end offsets are used
• if the header is destroyed completely and the audio data does not start at the default offsets (by default, audio data is copied starting from offset 44 for WAVE files and at offset 512 for AIFF files)
• if files are partially restored

This is a bit tricky because at this point it is not yet clear which chunks will be written, so the write operation has to be delayed.

A good approach would probably be to analyze the input file completely, detect the chunks that are still intact (if any), compute a plan which chunks should be written (including their sizes) and then finally write the complete file with correct chunk sizes.

AIFF-C Support

Support analyzing and restoring AIFF-C files as requested by @joekroese in #2.

How you calculate the data subchunk2size?

Hi,

I used your waverecovery to wave encrypted files, i cut 153644 bytes from the header and it working without noise, but i wanna know how to get the data subchunk2size from offset 41-44

Sample:
https://drive.google.com/file/d/1D_MS6ko7zXVEGiM2K5m3TUasw9xpXPMO/view?usp=drivesdk

This sample using 41000 and 2 channel

Could you made recovery tool for mp3 file?

Hi,

I have some encrypted mp3

https://drive.google.com/drive/folders/1oKg7Zvl2E-9GvWVHtTwHyhxADAx1HEc0

The encrypted data is 25805 bytes ( hex ) from the header

Could you made a repair for this case and error mp3 files?

Add Parameter for End Offset of Audio Data

In some cases the input files have to be cut off at the end. For this purpose, it should be possible to specify an end offset indicating the position of the last audio byte.

Long parameter name: --end-offset
Short parameter name: -e

Allowed values: integer values, including negative values. Negative values are interpreted as offset from the end of the file.

Add Parameter for Start Offset of Audio Data

It should be possible to specify the offset of the first byte in the damaged file that is part of the raw audio data. This will allow to restore arbitrary audio files.

Long parameter name: --offset
Short parameter name: -o

Allowed values: integers (negative values are interpreted as offsets from the end of the file)

AIFF Support

Add support to display AIFF header infos and to restore corrupted AIFF headers.