Amnios support for disk 1 is incorrect

[rhester72]

Please see the details in this post/thread:

http://eab.abime.net/showpost.php?p=1604430&postcount=45

The short version is the PROTEC track 0 on side 1 does not appear to be encoded correctly with disk-analyse per the CAPS/SPS team (as compared to the official encoder).

I can provide disk-analyse and SPS images for comparison if helpful.

[keirf]

Raw dump and SPS IPF please. Should be easy to fix.

[keirf]

Ah I see they are in the Zone

[keirf]

To be clear, the disk-analyse generated IPF does not pass the protection check?

[rhester72]

It seemed to to me - the game worked as expected. I didn't know anything was amiss until dlfrsilver commented about it in the longer thread (page 3):

http://eab.abime.net/showthread.php?p=1604447#post1604447

[keirf]

If it works, it works. I'll have a look though.

[keirf]

I can't see any important difference. Track length differs slightly but should still be a "good" PROTEC track. I have responded on EAB. Perhaps dlfrsilver spotted something else, or perhaps he believes the track length difference is important. I doubt it is. If it passes the in-game protection check it is good enough for me.

[rhester72]

Understood - I'm with you on this one, but there's long been a divide between 'preservation' and 'playability' as far as the SPS group is concerned. From where I sit, neither is good enough for preservation - only raw flux is. shrugs

[keirf]

Yes for preservation it should always be the original flux. Downstream formats always lose detail. For example in this case both analysers replace the true track gap value with 00. So even the SPS analyser is far from 100% accurate. I just don't pretend to be and I know what the PROTEC code tests for! My bar for acceptability is that the converted image works with the original track loader and protection checks. Actually that is true for SPS too but they won't admit it.