Very simple help when you run just the command line.
Seems to only accept 16-bit and 44.1kHz WAV files. Probably stereo only, too.

Tried a 24bit/96kHz file I bought from one of those digital stores and tried it out.
Resampled and lowered bit depth using "eac3to" to 16/44.1.
eac3to uses TPDF dithering and SSRC for resampling.

sample file: The Imperial Suite ("Rogue One: A Star Wars Story" soundtrack score by Michael Giacchino)
2:29.760 (14 376 961 samples), 24-bit, 96kHz (which metaflac says its 24bit (no wasted bits); do not care about the validity of the sample rate, as I downsample for encodes, anyway).
^{You can check out the track on DisneyMusicEVO on youtube to get an idea of what the content sounds like: https://www.youtube.com/watch?v=-C2wCcuKmLI}

---

Using the 16/44.1 WAV file, the compressed encodes turned out as such:
14.3 MB (15,059,940 bytes) | Compression level 8 (exhaustive)
14.3 MB (15,075,885 bytes) | Compression level 8
14.4 MB (15,121,612 bytes) | Compression level 5 (default)
15.0 MB (15,796,422 bytes) | Compression level 0
15.1 MB (15,933,971 bytes) | SELA (unknown compression level)

Closer to Compression level 0 in FLAC, for default SELA parameters (as there are none to tweak).

---

Played it back in the command prompt window... THAT was weird. But it didn't sound bad. Wouldn't really know a difference unless I put headphones on and did a full double-blind ABX test.
Also, did not manage to record the timings for each encoding. FLAC.exe only tells me how many bytes were written and what the compression ratio was for each encode. I used CLI and no GUI.

Overall, not a bad experiment!

Last version's exe file doesn't work, asks for three DLLs (libgcc_s_seh-1.dll, libstdc++-6.dll, libwinpthread-1.dll), after downloading god knows which versions from net, it won't start, 'Applications was unable to start correctly'.

Test the latest version because the last version is ancient, written 4 years ago. The latest one is basically a rewrite to bring code quality up to modern standards.

Those dependencies are supposed to be copied from whichever version of MinGW was used to build the project, and are supposed to be bundled when distributed, since they change with every version of MinGW, therefore cannot simply be "downloaded from a DLL site".

Quote from: coolirisme on 2020-04-07 15:53:10

Test the latest version because the last version is ancient, written 4 years ago. The latest one is basically a rewrite to bring code quality up to modern standards.

2.0.1, yes? That is the version that gives me problems. I've downloaded exe file and started it from command line.

Interesting project! Kind of the same goal as my project SLAC, except that SLAC is just pure C.

I also had trouble running your new version because of its dependencies, but I was able to run your previous version (0.1.2-alpha). Surprisingly the compression ratio was almost identical to SLAC on the 1-hour corpus file I use for comparison testing.

Unfortunately, in about 3 places the restoration was not bit-exact over several samples. Hopefully that's been fixed in your new version, which I'll definitely try once there's a version without dependencies.

RE: dependencies, I did a search for the first file mentioned (libgcc_s_seh-1.dll) and found it in several places (python, git, gnuplot,etc).
The only place where it's in the system's environment variables seems to be gnuplot.

For python and git, the env_var paths don't lead to where libgcc_s_seh-1.dll is located.

And regarding the sampling rate, I tried with 96kHz and it spat out some error that I've seen when the wrong format is used.

Quote from: Sparktank on 2020-04-09 03:24:43

RE: dependencies, I did a search for the first file mentioned (libgcc_s_seh-1.dll) and found it in several places (python, git, gnuplot,etc).
The only place where it's in the system's environment variables seems to be gnuplot.

For python and git, the env_var paths don't lead to where libgcc_s_seh-1.dll is located.

And regarding the sampling rate, I tried with 96kHz and it spat out some error that I've seen when the wrong format is used.

Did you manage to run v2.0.1/v2.0.2? What error did you receive for the file you tested?

Quote from: bryant on 2020-04-08 21:19:23

Interesting project! Kind of the same goal as my project SLAC, except that SLAC is just pure C.

I also had trouble running your new version because of its dependencies, but I was able to run your previous version (0.1.2-alpha). Surprisingly the compression ratio was almost identical to SLAC on the 1-hour corpus file I use for comparison testing.

Unfortunately, in about 3 places the restoration was not bit-exact over several samples. Hopefully that's been fixed in your new version, which I'll definitely try once there's a version without dependencies.

Hi David, I have switched to MSVC and created a new release. Can you check now? I was aware of the issue you mentioned. That was one of the motivations for the rewrite. 

Quote from: coolirisme on 2020-04-09 11:08:13

Quote from: bryant on 2020-04-08 21:19:23

Interesting project! Kind of the same goal as my project SLAC, except that SLAC is just pure C.

I also had trouble running your new version because of its dependencies, but I was able to run your previous version (0.1.2-alpha). Surprisingly the compression ratio was almost identical to SLAC on the 1-hour corpus file I use for comparison testing.

Unfortunately, in about 3 places the restoration was not bit-exact over several samples. Hopefully that's been fixed in your new version, which I'll definitely try once there's a version without dependencies.

Hi David, I have switched to MSVC and created a new release. Can you check now? I was aware of the issue you mentioned. That was one of the motivations for the rewrite. 

Okay, the new MSVC works for me now. Tried a 1-minute and a 5-minute file and they decoded bit-perfect, except that a tiny portion was missing from the end in both cases.

However, when I tried my 1-hour plus file the program gobbled up all available memory and most of the CPU and I could barely regain control of the system! Not sure what's going on there, but it prevented me from verifying the data (it had generated no output once I was finally able to kill it). I'm on Windows 7.

Another thing I noticed is that it crashes if the input file doesn't exist. 

It turns out a very strong break with FLAC  > test file

Quote from: Gravitator on 2020-04-12 16:00:56

It turns out a very strong break with FLAC  > test file

Whelp, that is definitely one of the worst results I have seen from this codec.