The DRAFT format is purposefully being kept very simple. It is structured in such a way that although altering existing data in one file is inconvenient, appending new data or deleting such data by simply truncating the file is very easy. You can then convert it to simpler or more complex formats, the goal of the format is to have all the data in one place without irrecoverable changes, pre or post-processing.
Compression is likely to be needed, as standard compressors won’t understand the data enough to produce useful file sizes. There is a high possibility of doing a much better job by altering the data (in a lossless way) and then use standard compression on top (probably external to the file format itself, e.g. .gz files. We wouldn’t normally bother with any of this, but the files will be large, and we archive everything submitted. The storage costs add up.
We would like this to be a format that everyone’s happy with, keeping in mind that for most purposes it is a “transient format” - not intended for emulator use (you’ll be better off using something else, that is already pre-processed, fast to decode, etc.). It is intended for storing every bit of information needed to faithfully reproduce all that has been sampled - what you do with such data besides archival is up to you.
Things to add to the host software (easy once the flux periods are properly converted to bit cells):
- Command line support
- Error handling
- Amiga .ADF decoder
- Atari ST .ST decoder
- C64 .d64 decoder? (some doubts remain here due to the false signal level problems experienced with crappy 5.25 drives)
- If people want to create a user interface tool, they could use the source of the command line code pretty much unaltered apart from adding the GUI handling. Maybe we’ll do one, we’ll see.
Right now the host software can already produce CT (SPS Disk Imager) RAW files and can save the captured stream files used for communication.