Releases: hasenbanck/toa
v0.4.0
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
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
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.