While attempting to rebuild the "Little.My.Maid-FASiSO" release, the program after rebuilding the bin properly acted like this:
…..
Re-creating RAR file: fas-lmym.r37
Trying to rebuild compressed file fas-lmym.cue.
Compressing fas-lmym.cue
RAR 3.20 Copyright <c> 1993-2003 Eugene Roshal 15 May 2003
Registered to user
Creating solid archive c:\users\user\appdata\local\temp\tmprudw5u_pyReScene\pyReScene_compressed.rar
Adding E:\SRR\fas-lmym.bin
…..
This goes on until the end with the last file not having the proper CRC and the cue file being corrupted. I tried this with different version of RAR 3.xx, same results. The normal behavior should be:
…..
Re-creating RAR file: fas-lmym.r37
Trying to rebuild compressed file fas-lmym.cue.
Grabbing large enough data piece size for testing.
Trying 2003-05-15 3.20.
Testing with previous file
…..
After some testing I realized that the problem came from the header of the cue. The 9th character of the header, in this case D0 (hex value) is the problem. Here is the header as save in the SRR (hex values):
00 B0 40 F2 48 EB C4 74 D0 90 31 00 4F 00 00 00 4D 00 00 00 02 02 CF D6 19 F0 A2 50 32 1D 35 0C 00 20 00 00 00
As soon as you change the D (the 0 doesn't seem to have any effect) to an acceptable character (0,2,C,E,F and maybe some more, didn't test them all) the program behavior return to normal. I have also noticed that this character is very important since as soon as you change it the program modify (recalculate?) the first characters in the header, making it impossible to recreate the original release.
After recreating the release manually with the command used by the program when rebuilding the bin:
2003-05-15_rar320.exe a -m5 -mdG -s- -ds -vn -o+ -ep -idcd -vn -v15000000b
I ended up with a compressed cue of 75-76 bytes. Since I needed 79 Bytes I used this command:
2003-05-15_rar320.exe a -m5 -mdG -s -ds -vn -o+ -ep -idcd -vn -v15000000b
And got the proper 79 bytes size for the compressed cue. As you notice the -s switch changes the way the RAR program compresses the cue. But I ended up with the same D at the same position in the header, making this release also impossible to rebuild with the program in the present state.
I also noticed that every time that the program try to rebuild a release the -s- switch is used. I realized that on many releases the switch must be -s to get a proper compressed cue size. Maybe this should be something to look into at the same time than that 9th character creating weird behavior as for the moment these releases can't be rebuilt.
If you need this release (bin-cue) to do some test, let me know. If you already have the release or someone else has, I would really appreciate to be able to get the last 200 bytes of the "fas-lmym.r37" so that I can complete the rebuilding of this release in his original state.