First one is easy:
Yes, thank you for spotting this as well as for your explanation.
It's one for the hall of shame as i am familiar with how this c construct works. I seem to have missed this when i re-cleaned the sources with those from my local working dir (not branch).
fwiw: there is another one exactly like that at line 1516
The second was VERY hard, took me 2 hour to figure out whats wrong there ;-)
Hmz, i wonder if all that casting was a premonition :-)
1. the C program is not 64 bit safe :-(, so if you compile 64 bit the pseudorandom go havoc
That would propbably have been encountered and/or addressed with the (recent) jessie 64 bit conversion as well (i just noticed that it was worked upon).
2. the behavior for Pascals "shr" and Cs ">>" is different for negative numbers
(pascal shifts as it would be unsigned value, C fills the leading places with "1", so the number stay negative)
I am somewhat familiar with the differences between c and Pascal with regards to shifting. I just not had any clue that the implementation in the replayer was depending on this behaviour.
TBH i probably would not have been able to find that myself, so thank you very much for having spotted that.
Am i correct when stating that using the (new) SarLongInt intrinsic would have similar results as your manual solution ? , e.g.:
if ( voice^.vc_Waveform = (4-1) ) then
AudioSource := AudioSource + ( voice^.vc_WNRandom and (2*$280-1) ) and (not 1); // FPC note: check not(1)
voice^.vc_WNRandom := int32( int64(voice^.vc_WNRandom) + int64(2239384) ) ; // FPC: overflow
// voice^.vc_WNRandom := ((((voice^.vc_WNRandom sar 8) or (voice^.vc_WNRandom shl 24)) + 782323) xor 75) - 6735;
voice^.vc_WNRandom := ((( sarLongInt(voice^.vc_WNRandom, 8) or (voice^.vc_WNRandom shl 24)) + 782323) xor 75) - 6735;
I have not seen the results with this change with my own two eyes (i had to rely on reports from 3th party) but that seems to have been a major improvement over pre-existing wav output.
If i have to trust the reports then this would make about 75 percent of the outputted wav similar to the wav as outputted by the original hvl2wav utility and those values that are different are close to its original counterpart. There are no complete diff blocks anymore, only several values (which seems another indication something is still wrong with one of the applied effects).
I'll apply the fixes to my tree as soon as i'm able to. Please feel free to a pull request if wanted. (fwiw: i'll credit you for the fixes anyway)
Thank you very much for your input, analysis and solutions. At the least you gave me a very good motivation to try my other changes again in order to try locate where else i did go wrong. Feel free to further aid me in this though