On Fri, Oct 2, 2020 at 1:27 PM Chuck Guzis via cctalk <[email protected]> wrote:
> Actually, they're neither. I append the metadata after the EOI marker > on mine. Doesn't seem to bother the emulators. > Some programs (but probably very few) that use various so-called .tap files assume that they can seek to the EOF (of the container file) and read records backwards (supported by lengths being at both ends of blocks in the container). Tacking metadata on the end breaks that. I'm not criticizing, mind you. It's just something that people may need to be aware of. The .tap file formats are horrible. Originally there was at least the virtue of simplicity, but because they've diverged we don't even have that. Al wrote: > Bordynuik's at least had some provisions for reporting a bad block, > as I'm sure yours does. > Aeons ago when I was doing stuff with tape images, I made a proposal for representing bad blocks of either known or unknown length. I don't know whether anything other than some of my own unpublished code adopted that particular proposal. IIRC, I proposed using a record length of 0xffffffff to designate any kind of "metadata" record, with the real length of the metadata record in the next word in on both ends (to still support backwards reading), and the third word at the beginning only being a tag of what kind of metadata it was, etc. Of course, that scheme breaks programs that use tape images but don't expect enormous or "negative" record lengths. I contributed to the morass by still calling my files .tap files.
