Thanks. About that help error:
errhlp.png
About CRC, you may need to test that on big enough data (300gb+) and containing TONS of very small chunks(64-256k or ~128k) for it to be robust enough for all scenarios. Crc32 may reach iteration limit(collisions start way before that). Good idea is to compare srep m3 vs m5, m3 use VMAC(which is either 64bit or 128bit, dunno which use srep but very likely 128bit) and m5 is re-read bit perfect, so following attachment could help you get some hints regarding collision vs data:
srep-readme.zip
Thanks for that reliability reassuring, from now on I start use it exclusively instead ztool. Crilayla ditching is a disappointment though as this one is very common format in Japanese games and could also help with compressing console roms. You mentioned low speed as a reason but if I recall from past oodle was even slower?
~4 bytes in dedup per stream only?! So then you don't store distance, only single 32bit hash and nothing else me think. You compare with each newly found chunk if there is a crc match right?
About endians, ok but you still do have to search for a byte sequences in order to find something no? For example when I wrote bms script to decompress oodle chunks from xcom2 I searched for a oodle clues, in my case:
Then it matter if its that or in reverse. I dunno maybe zlib have same header ID order in all endians, but then what about deflate detection? That have no header, just a bytes test..