It might be helpful to disclose which version of FLACCL is being used in the testing. As Gregory stated earlier: " i should update or remove the separate FLACCL download to avoid confusion - right now it's out of date compared to the one that comes with CUETools 2.1.5."

It might be helpful to disclose which version of FLACCL is being used in the testing. As Gregory stated earlier: " i should update or remove the separate FLACCL download to avoid confusion - right now it's out of date compared to the one that comes with CUETools 2.1.5."

I downloaded the latest version I could find of the standalone Flaccl (0.3) since I didn't need/want cuetools. Why this would be a less recent version than what is bundled with the cuetools eludes me. I expected these to be the same.

If you follow the thread you'll see i always test the latest versions bundled with CUEtools. I reported several issues over time to Grigory. Unfortunately the flacCL page at the CUEtools Wiki isn't exactly well documented. This means i sometimes find out it suddenly behaves different without a notice anywhere. I always copy out the needed files to use it with a frontend for my usage.You need CUETools.Codecs.FLACCL.dll, CUETools.FLACCL.cmd.exe, CUETools.Codecs.FLAKE.dll, CUETools.Codecs.dll, OpenCLNet.dll and flac.cl

Is troll-adiposity coming from feederism?With 24bit music you can listen to silence much louder!

That's very interesting, but i'm afraid not very practical for FLACCL for a number of reasons - prohibitive cost, tiny potential audience, and finally - unlikely to live up to this 15x promise.FLACCL on any average discrete GPU already runs faster than disc IO. Any significant improvement would be limited by SSD speed.And the saddest part - it's just not likely to be that fast on actual tasks such as FLAC compression.A quick look at the specs of some of those shows significant hardware limitations as compared to GPUs - for example, one of them sports a 72-bit data bus. That's 2-3 times less that your average GPU. And that is what will likely determine the speed on compression tasks.

That's very interesting, but i'm afraid not very practical for FLACCL for a number of reasons - prohibitive cost, tiny potential audience, and finally - unlikely to live up to this 15x promise.FLACCL on any average discrete GPU already runs faster than disc IO. Any significant improvement would be limited by SSD speed.And the saddest part - it's just not likely to be that fast on actual tasks such as FLAC compression.A quick look at the specs of some of those shows significant hardware limitations as compared to GPUs - for example, one of them sports a 72-bit data bus. That's 2-3 times less that your average GPU. And that is what will likely determine the speed on compression tasks.

. It used to be just "order" instead of "order + 1" and as a result it creates bigger files. Changing it back fixes the issue and still creates non-broken FLAC files(I had issues with Error : unsupported residual coding and a few other errors that created FLAC files which did not decode properly).

It seems that my previous assertion was incorrect. "order + 1" sometimes creates smaller files and other times just "other" does. It seems to be very content dependent. For example, the files which previously failed to verify usually become smaller with "order" whereas the files which were fine prior to the update tend to be smaller with "order + 1".

Needs more testing.

edit: Looks like the files which gave "Error : unsupported subframe coding (ch == 1)" are smaller with just order while the "Error : frame crc mismatch" files become smaller with order + 1.

This is a great encoder, but there are a few issues I have with it.1. It doesn't copy the vorbis comment block when it encoded. Is there an option to enable this?2. The initialization, which I assume includes compiling the kernels, takes a while. Because of this, encoding a folder of FLAC tracks can take longer with the GPU than with the CPU (Based off my 4770K and r9 290x). Is there any way to tell one process to encode all the flacs in a folder, replacing each one?

Is there any reason I can't reliably use foobar's multiple thread encoding? It basically spawns 4 instances of flaccl. Memory isn't an issue according to gpu-z (400-500MB out of 896MB used), but about half of the tracks fail to encode with "encoder exited prematurely with code 4"

The thing is, it works fine for say, 10 albums. Then I have to restart the PC to make it work again, so something goes wrong.Running 4 openCL instances gives me a boost of about 50%, so it's not bottlenecking anything. It's more like there is some sort of memory leak except it doesn't show on gpu-z's memory usage.

Disregard the --lax not working, I somehow had two flaccl encoder presets and the one that was saved as a converter preset was the standalone flaccl.exe. That version didn't have a --lax option yet, hence the error code 1 termination.

I'm not getting crashes with 4 threads at the moment (with either flacuda, old or new flaccl), so I don't know what caused it. Might be a driver issue, my GPU is pretty picky when it comes to that (old 260GTX). Should I get any, I'll try messing around with driver versions, but I doubt it's worth it, considering encoding in 4 threads with the upcoming libflac 1.3.1 is faster than flacCL on my GPU...

The thing is, it works fine for say, 10 albums. Then I have to restart the PC to make it work again, so something goes wrong.Running 4 openCL instances gives me a boost of about 50%, so it's not bottlenecking anything. It's more like there is some sort of memory leak except it doesn't show on gpu-z's memory usage.

If you look at the commit date, that change is from 2013-10-15, while the flac.cl file in the latest cuetools beta is from 2013-12-31, so the change is already included. It wasn't the issue anyway just me using an old exe.