Packing method seemingly depends on volume size.
Using the following release: https://www.srrdb.com/release/details/The.Vanishing.Of.Ethan.Carter.UPDATE.5-CPY
I ran into trouble reconstructing this using rescene, but I'm not 100% sure why. However, while reconstructing this release manually, I noticed the following:
Using this command the correct compressed data is generated:
2013-08-22_rar500.exe a -m3 -mdG -mm -s- -ds -mt8 -vn -ma4 -o+ -v100000000b with_volumes.rar ...
However, with the following command, the setup-16.bin file is seemingly stored uncompressed:
2013-08-22_rar500.exe a -m3 -mdG -mm -s- -ds -mt8 -vn -ma4 -o+ one_piece.rar ...
In the case of using volumes, the first volume containing setup-16.bin is r24. This is the header for that file from r24:
Raw header bytes : 9bcf74c2903800909ce504403c97280245439c0f9d7099451d331300200000005570646174655c73657475702d31362e62696e00b0a14d95
File Header
------------------
Checksum : 0xcf9b
Type : 0x74 (File header)
Flags : 0x90c2
0x0002: File continued in next volume
0x1000: Extended time field present
0x8000: This bit always is set
Size : 0x0038 (56 bytes)
Compressed size : 0x04e59c90 (82156688 bytes)
Uncompressed size: 0x28973c40 (681000000 bytes)
Source OS : 0x02 (Windows)
File CRC : 0x0f9c4345
Date and time : 0x4599709d
RAR Version : 0x1d
Packing method : 0x33 (Normal Compression / -m3)
Dictionary size : 0x06 (4096k / -mdG)
File attributes : 0x00000020
File name : 'Update\setup-16.bin'
Extended time : 0x43000000
This is the header for the same file in the single rar:
Raw header bytes : ae0a74c0903800403c9728403c9728021b0f23589d7099451d301300200000005570646174655c73657475702d31362e62696e00b0a14d95
File Header
------------------
Checksum : 0x0aae
Type : 0x74 (File header)
Flags : 0x90c0
0x1000: Extended time field present
0x8000: This bit always is set
Size : 0x0038 (56 bytes)
Compressed size : 0x28973c40 (681000000 bytes)
Uncompressed size: 0x28973c40 (681000000 bytes)
Source OS : 0x02 (Windows)
File CRC : 0x58230f1b
Date and time : 0x4599709d
RAR Version : 0x1d
Packing method : 0x30 (Storing / -m0)
Dictionary size : 0x06 (4096k / -mdG)
File attributes : 0x00000020
File name : 'Update\setup-16.bin'
Extended time : 0x00000000
Looking at the individual compressed sizes in the multi-volume case, I see that the total size becomes: 0x04e59c90 + 0x05f5e0a0 + 0x05f5e0a0 + 0x05f5e0a0 + 0x05f5e0a0 + 0x05f5e0a0 + 0x05e91274 = 0x289C1224, or 681316900 bytes. Thus it seems that by compressing, the file got bigger. I think this is why RAR decided to store the file instead. However, it may be that if it has already output a volume containing compressed data for that file, it won't/can't switch to storing, which is why the multi-volume case still has the (larger) compressed data.
I'm not sure exactly how this impacts rescene, but I can imagine a scenario where due to the volume size that is chosen during reconstruction a file could be just in the right/wrong place to be (or not be) split, causing rescene to not be able to find a good rar version.
