Skip to content

Releases: hasenbanck/toa

v0.4.0

01 Oct 14:54
9b2be72

Choose a tag to compare

This release contains a small fixes that makes the decoders more robust when reading files that contain errors.
There is now also a small function, that tests which SIMD features the current CPU is supporting.
The support for older CPU is also improved.

Fixed

  • Don't trust MSB of header/trailer without ECC
  • Fix panic when running RS on the header with 11 errors

Added

  • "--test-simd" command to test available instruction set of the CPU

Changed

  • Removed cargo/config.toml to achieve maximal compatibility with x86_64 CPUs

v0.3.0

31 Aug 13:47
ef609d2

Choose a tag to compare

This version finalizes the version 1.0 of the specification. Since the last release there was one breaking change: The polynomial used changed to the polynomial used by AES-GCM and is used by the GFNI. This allowed us to suport fast SIMD based error correction both when encoding and decoding. We have runtime feature detection, so it will automatically x86_64 GFNI if available. Under x86_64 SSSE 3, AVX2 and GFNI are supported. Under aarch64 we support NEON. The CLI also now support globbing (wildcards).

This is the first version that I personaly entrust my data.

Changed

  • Freeze of the specification version 1.0
  • Breaking change: Use different polynomial for Reed-Solomon ECC. Switched from 0x11D (x^8 + x^4 + x^3 + x^2 + 1) to 0x11B (x^8 + x^4 + x^3 + x + 1). This is the polynomial used by AES-GCM and is used by the GFNI x86_64 instruction set. This enables us to provide highly optimized RS ECC implementations.
  • Provide SIMD implementation for the ECC encoder and decoder. This resulted in a speed-up of 10-15x for the ECC encoding and validation when decoding.

Added

  • Wildcard / Globbing support for the input files

Fixed

  • Fixed delta encoding bug of uncompressed chunks, where the direction was wrong on the encoder side (encoding "more" with - instead of +).

v0.2.0

23 Aug 18:07
f1fd183

Choose a tag to compare

First functional release, which allows for basic usage. The format is still experimental, until I got some more feedback. But I have a general good feeling. Once I implemented tha repair command to even repair corrupted files and got a feeling on how robust the file format is, the format itself will get "frozen" for version 1.0 of the specification pretty soon. Some aspects, like the LZMA algorithm used is a bit underspeced, but that I also want to work on in the near future.