9 track tapes and block sizes

Er, no. The blocks aren't necessarily of equal size. Unix people who are used to tar often seem to have this mindset, but the general case is that records can be of varying size. DON'T DO THAT. If you use dd, you're throwing away information. Specifically, you're throwing away knowledge of the block size. Most of the conventional unix utilities don't care. Many other things do. In many cases, it's difficult or impossible to reconstruct the block sizes There are file formats for containing tape image data. The most common one is probably the simh .tap format. These all preserve block lengths, tape marks, indications of errors in reading the original, etc. Many fail to provide a means to embed metadata, but you can put that in separate adjacent files. Generally speaking, do a read of a blocksize as large or larger than the max on the tape, and the system will hand you the full record, and the actual number of bytes read. If you're writing C or scripting code, the unix read() call does this. From the command line, you can do it with dd - specify a large block size and a count of 1, and it'll tell you what it actually got as it exits. For 9 track, few systems could write blocks larger than 32k or 64k, so those are decent guesses for "large" there. If it's DLT or something more modern, then the largest possible block might be a lot larger. The system reading the tape may impose a limit based on available buffer space. You should able to iteratively determine the largest size it will accept. Many of the quarter-inch cartridge formats actually don't support block sizes other than 512 bytes. If they were used on systems that expected to be able to write larger and/or variable records, the system hardware or software may have implemented a logical blocking layer on top of the 512 hardware layer. If you're reading one of these and don't have the original hardware/software to decode it, you'll have to figure out how to decipher it yourself. De