Minimal SeqBox container decoder

[Mark0]

Here's a most simple decoder for a SeqBox container.

Code: Select all

' SeqBox dumb decoder
' A minimal SeqBox container decoder sample with no checks     
' (resulting file will be &h1A padded - usually not an issue)

DIM inFileName AS STRING
DIM outFileName AS STRING

InFileName = "test.sbx"
OutFileName = inFileName + ".out"

DIM fIn AS INTEGER
DIM fOut AS INTEGER

fIn = FREEFILE
OPEN InFileName FOR BINARY AS fIn

KILL OutFileName
fOut = FREEFILE
OPEN OutFileName FOR BINARY AS fOut

DIM SBXBlock AS STRING * 512 ' SeqBox v1 block size
DIM BlockNum AS LONG         ' SeqBox block sequence number
DIM DataBuffer AS STRING     ' Actual file content

DO WHILE NOT EOF(fIn)
  GET #fIn, , SBXBlock
  ' This is where one would check for a valid SBX block signature,
  ' verify the CRC, blocks numbers sequences, etc.
  ' but we can just assume the SBX file is OK
  BlockNum = CVL(MID(SBXBlock, 13, 4))
  ' Skip metadata block if present (0 is endian agnostic so no BE-LE conversion)
  IF BlockNum <> 0 THEN
    DataBuffer = MID(SBXBlock, 17)
    PUT #fOut, , DataBuffer
  END IF
LOOP

CLOSE

[MrSwiss]

Well, the time for Diskettes is definitely in the past / as is FAT16.
Therefore, the size of the SeqBox should be enlarged accordingly,
in order to be useful, in this day and age ... e.g. NTFS = 4KB min.

[Mark0]

I thought about it. And it's actually quite possible and easy to use a larger/different block size, just by adding a new ver. and different parameters in the seqbox.py module. For example I put in a v2 with an absurdly low 128 byte size just to test that all the tools were working right with different sizes, and also because I like to play with old systems and that just happens to be the usual sector size for CP/M! :)

But, there are reasons why I choose 512 bytes as the default and "regular" size.
First, while 4KB would be OK on many systems, 512 bytes works in nearly all, without having to worry about older or more unconventional formats / FS that one may encounter, and give the "peace of mind" of not having to worry at all about that detail.
Seconds, the overhead of 512B vs 4KB blocks is about 3.5-3.2% vs 0.5%. While the difference is definitely there, it's not really that much.
Third, more granularity may come handy, for example if bitrot or damages in general happens and blocks are lost. Losing 512 bytes here and there may be recoverable if the file encoded was a RAR with standard recovery records settings, for example, while losing 4KB would be a bit too much.

Anyway, it's obviously a tradeoff, but I think it's a sensible one.