Rar2 v20,v26 Multimedia (Audio) decoder fix #896
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a fix for the Audio Decoder in unpack20 (v20/v26). When decoding a rar that uses the old multimedia compression algorithm an error is raised:
This is because the MultiDecode[] objects are never instantiated.
private readonly MultDecode[] MD = new MultDecode[4];(Unpack20.cs:17)I looked back through the repo hoping to find and old working commit, but they have never been set. I even dug out the original Unrar project (pre SharpCompress) and that was the same.
Initialising them fixed the crash, but the decompression still wasn't correct. After many hours, I decided to compare the code with the C++ implementation used by 7zip and finally tracked it down to 2 bad casts in the Audio Decoder - (byte) when it should actually be (sbyte). Fortunately the rest of the code seemed to work perfectly after that (big relief).
I've not got any small archives that display this behaviour for use with unit tests. Current tests pass and this fix is being tested on many archives.
:-)
Edit: A combination of this fix and possibly Morilli's fix have fixed the remaining 170 ish archives that were failing to read. There's one outlier to investigate, but it may not be a sharpcompress issue :P