No worries.
that util, looks the business.
i am using a normal hex compare tool.
only the tapes (CAS files) that throw errors, are brought to my attention.
The more i examine these CAS files, the more i am convinced it is to do with the different CAS conversion tools used.
Various dumps of the same game have different pause block sizes (length of bytes) before and after a filename.
I have seen many random sizes... 1,2,10,352 bytes long.
when that gap/test tone is modified and fixed to 256 bytes long, they start to work in Xroar and MAME.
*which is all the editing i am doing in most cases.
reading the hex in the CAS, it has a FF (256 bytes) value at the start of the block with the ammount of data it is looking for.
I have seen a few tapes which have smaller value "F8" (possibly as part of a copy protection) where saving on real hardware would write the larger block (normal 256 size) so the resulting copy will fail (makes sense to me).
If the data (gap) in the CAS conversion is incorrect, then converting CAS back to WAV will probably fail in some cases.
but that all depends on the tools used.
Also if the CAS will not load in Xroar or MAME you can not use those tools to convert it back.
I guess a few tape players (real hardware) could still read and ignore this shorter gap.
As you could get various sizes with different tape recorder speeds writing to a tape ribbon that has been stretched overtime.
but i think the correct 1.1 size of 256bytes is the perfect "software" CAS dump.
a real WAVE tone could be longer or shorter, but i think a fixed length is what MAME is looking for.
Where the WAV version works but the available CAS doesn't.
converting the CAS again has worked for me in some cases (possibly from a newer redumped WAV).
so with every new WAV created the CAS should be updated to match.
if you only use WAV on real hardware, you won't have any of these problems.
