Porcus, your statement is interesting to me but I can't believe it until I make my own tests.
I have the reissue of this album by Irond Records. Are we talk about the track:
I Lead You Towards Glorious Times (live)
5:29.800 (14 544 180 samples)

Thank you for the new test, Porcus. I would be glad if I can get information about the operating system and processor you use.

In most cases, Halac-Fast is better than FLAC-0 in the compression ratio. Because I especially set it like that. Of course, there is always space for exceptions.

And once again, these tests are performed using "Ram Disk". In terms of speed, even HALAC(not fast) is always faster than FLAC-0 in normal systems. With ordinary SSDs, HALAC will perform much better in slow and normal systems.

And I added a quick data verification system with V.0.2.0, especially because it was persistently requested.

$ time for f in */*.wav;do halac_enc_2.0.1 "$f" "$f.halac";done

real	0m11.848s
user	0m10.116s
sys	0m1.615s

$ time for f in */*.wav;do ~/Downloads/flac143/flac-1.4.3/src/flac/flac --no-md5 --totally-silent -0 "$f";done

real	0m17.009s
user	0m12.440s
sys	0m3.622s


$ time for f in */*.halac;do halac_dec_2.0.1 "$f" "$f.wav";done

real	0m18.359s
user	0m16.082s
sys	0m2.232s

$ time for f in */*.flac;do ~/Downloads/flac143/flac-1.4.3/src/flac/flac --totally-silent -d "$f" -o "$f.fdec";done

real	0m17.172s
user	0m13.083s
sys	0m3.842s

Sizes:
2916907812 wav
2017463945 flac
2016873005 flac stripped of metadata
1994734822 halac
1979508435 sum of best (best of flac/halac unstripped)

Encode
real	0m27.496s
user	0m24.736s
sys	0m2.417s

Decode
real	0m19.158s
user	0m16.150s
sys	0m2.807s

Size: 1983908820

On the encode stream, so that you can later implement verify without full decode?
Per block? "All" competing formats have something like that, except a couple that suck ... (ALAC has nothing, and TTA claims to offer it, but I know no implementation that actually uses it.)

What I want to say is that HALAC's performance will be better in normal cases, except the use of "Ram Disk".

Thank you for the Linux binaries, particularly the static binary I did need that. This laptop is still on Ubuntu 20.04 so the glibc you compiled with is too old, also the static version should work on non-glibc like alpine linux.

I have been following this thread with some interest because five years ago I created a codec called SLAC along these lines. It was intended to be as simple as reasonably possible so that it could be easily understood. It was also assumed that it would also be very fast, but it never really lived up to that, at least compared to FLAC.

Quote from: Hakan Abbas on 2024-01-11 08:25:59

What I want to say is that HALAC's performance will be better in normal cases, except the use of "Ram Disk".

Why???

RAM disk should have a much higher performance than other forms of storage, if nothing else then simply because it is not accessed over a serial interface.  So why is performance worse?  Is it because you are performing other operations while waiting for disk accessed to complete?

In addition, HALAC also has extra processes for data verification. Flac does not make any verification in the tests.

1secCORR.flac: *** Got error code 2:FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH
*** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC


1secCORR.flac: ERROR while decoding data
               state = FLAC__STREAM_DECODER_ABORTED

SLAC might be the fastest decoding of the entire bunch?

I did not know that. Thanks for information.
However, the CRC-8 can only take 256 value.

Yeah, it has been found that file handling had a certain impact on speed.
But IIRC, the differences were not consistently this or that direction ... @cid42 was that you? Corrections?

Quote from: bryant on 2024-01-10 21:08:07

I have been following this thread with some interest because five years ago I created a codec called SLAC along these lines. It was intended to be as simple as reasonably possible so that it could be easily understood. It was also assumed that it would also be very fast, but it never really lived up to that, at least compared to FLAC.

Hello David.
When I check after the decode process, some files have differences. I came across this situation by chance. I'm adding the images.
[attach type=image]28554[/attach][attach type=image]28556[/attach][attach type=image]28558[/attach]

flac's frame hashing format is messy, but it does provide "good enough" hashing. It's somewhat more than the 16 bits of crc if you checked fully because there's hell of a lot of structure in there, you mostly know the expected values in the header not that they're needed for the most part anyway, and any corruption in the residual likely results in a different frame size which will cause a desync on the next frame read.

Not ideal and not something you'd choose in a greenfield project, but good enough as the status quo. Here's a discussion on flac's strong design decisions to make sync performant, it's related as making sync performant is where a lot of the structure comes from: https://hydrogenaud.io/index.php/topic,123569.0.html

Thanks for testing! I did these speedups using only a couple 2h19m files, and so it's certainly possible that an edge-case bug crept in. I would certainly be surprised if this exists in the master branch. And no, there is no error checking.

Where can I find one of the files that fails, like the Shun Ward track? Thanks!

Quote from: bryant on 2024-01-11 17:59:53

Thanks for testing! I did these speedups using only a couple 2h19m files, and so it's certainly possible that an edge-case bug crept in. I would certainly be surprised if this exists in the master branch. And no, there is no error checking.

Where can I find one of the files that fails, like the Shun Ward track? Thanks!

I uploaded 2 sample wav files. You can try it with these. In addition, it will be better to have a data verification mechanism.

{links removed}