There is a very specific reason why many (all?) Thalion games using weak bits will not work from any kind of raw file. They read 50 (!!!) revolutions of a track containing weak bits, and expect to have different data read from ALL of the previous revolutions.
In other words: during the 50 revolutions sampled no data should repeat at all.
The reason this mostly works on the real hardware is that the AGC in the drive produces a fairly random pattern - but even that can fail to be random enough for this depending on your drive...
When you use a raw image, the emulator effectively plays back what has been recorded from the disk. If you for example record 5 revolutions, 5 different values will be read of at the places where the weak bits are, then the same 5 patterns will repeat again and again...
Whatever you do to get the raw images reading, such as software PLL simulation etc. is deterministic in nature - it's programmed to be like that.
The only way to get a protection like this working is pre-processing the data.
With a format like IPF the CODEC is capable of generating random enough data that satisfies the 50 different values criterion.
With a raw format this is of course impossible - the emulator sees what's been read from the disk once, and that won't change.
Under emulation you'd have to process the entire raw track data sampled, detect weak bit areas, and then instead of playing back the sampled values, randomized data should be played back.
Not exactly worth the effort... and can increase load time of a raw file (or track access time) significantly, ie introduce glitches and frame skips when the track scanning happens. So it's better to do it when loading the image, but then it takes time to find weak areas - and this can be very expensive processing if it's foolproof enough to not turn legit real data into weak bits
Hope this helps understanding what happens and why