of thanks for that tip with sarLongInt, yes it seems it does the same... I did not know that.I didn't either.... it just seemed odd to me that FPC would not have an implementation for doing an arithmetic shift (and it actually officially didn't until recently ).
Learning something new every day
*"Magic Elixier of mighty bug finding" wears off*
I had a couple of minutes to spare for a quick test that shows what that magix elixer of yours brought sofar:
"a moon light.ori.wav" and "a moon light.ori.wav" have 0 different bytes ( 100.0000% similarity )
"a moon light.ori.wav" and "a moon light.pas.wav" have 37074380 different bytes ( 1.9812% similarity )
"a moon light.ori.wav" and "a moon light.pas.fix.d3.wav" have 34541768 different bytes ( 8.6770% similarity )
"a moon light.ori.wav" and "a moon light.pas.fix.fxparam.wav" have 13649319 different bytes ( 63.9133% similarity )
"a moon light.ori.wav" and "a moon light.pas.fix.random.wav" have 2360052 different bytes ( 93.7604% similarity )
That's an improvement of about 92 percent against my initial results and much better then the earlier reported 75 percent similarity
Hmz... that makes me wonder what my contribution was to that code i've committed
I know, what the problem is: it is some rounding error in the basic waveforms which is rather strange in the C program, I really did get not why it happens and what is wrong there.I did a small readup on that and some SO answers seem to indicate that indeed there are 'better' conversion techniques, depending on the compiler (static casts etc).
But I can tell you how to find it.Hmz that is very interesting.
I also recognized the pattern when looking at the diff files and therefor was initially suspecting GenWhiteNoise() routine to be the cause for that as that seemed the most likely candidate to me. I wasted quite some cycles on that
I could have sworn that i've tested the waveforms with running a checksum over the generated waveforms and compare c against Pascal results. I either remember this wrongly or i made a boo boo in the checksum calculation :-S
At least I can not hear a difference when playing the wav. For me this would be ok to keep it like that.You are quite right about that.
Very important lesson learned/reminded though: always ever doubt your own work as for certain you will keep making mistakes with these kind of conversion. A second set of eyes is a god-bless for such cases.
Thank for that mate !
(*) changing float64 type inside chelpers unit from double to extended seems to have done the trick.
"a moon light.ori.wav" and "a moon light.pas.fix.extended.wav" have 0 different bytes ( 100.0000% similarity )
Weird, as i figured float64 to comply to FPC's type double ? did i go wrong there ?