I encoded a WAV file with Shorten and LA, then I decoded them back to WAV with fb2k v0.8.3, and the resulting files differ - the one coming from .shn is bit-identical to the original WAV, while the one coming from .la is different (not only in header, size is different and actual audio data too). Version 0.4b of LA decoder was used. What's going on??

What happens when you use foobar2000's bitcompare function on the .shn and .la files?

slightly off-topic: is there an input component for LA format working with 0.8x serie?

Yes.

La04b.exe (windows version, 583 kb) include 0.6x component. I didn't tried, but it probably not works with 0.8x. I can't see anything else on Lossless Audio website. Could you be more precise?

Hmmmm....... works just fine for me with foobar2000 0.8.3. No problem except La's insane CPU consumption. But that's to be expected. Just so there's no confusion I've uploaded the one I use here.

Thanks
I'm finishing a comparison of lossless encoders, and it's exactly what I need to obtain precise measure of decoding speed!

SHN vs LA:

SHN vs original WAV:

LA vs original WAV:

WAV decoded from SHN vs WAV decoded from LA:

WAV decoded from SHN vs original WAV:

WAV decoded from LA vs original WAV:

LA vs WAV decoded from LA:

SHN vs WAV decoded from SHN:

Hello?? Is anyone able to give me an answer why it is like that?

To me it seems to be a problem with the la input plugin. Perhaps you should ask the author of this plugin about this issue? I don't think that the la coder frequents this forum.

I contacted the author and he replied that he doesn't know enough about fb2k to guess what could be going wrong, he also replied that he released the source to the fb2k plugin, so maybe someone could take a look at this and other issues and possibly fix them?

If the La author doesn't care enough to write a compliant fb2k input plugin which supports the reader system, he's kindly invited to fix the issues caused by his broken workaround himself instead of expecting someone else to try to make some sense ouf of the mess he created.

With current implementation of la API, would it be possible at all to create a clean input plugin, or are there some flaws in it which render it impossible ATM?

Impossible because his (closed-source) decoder backend opens files itself after being provided with a file name, instead of just accepting a reader stream to remain independent from file handling.

Using a reader interface in La libraries would be beneficial for the backend itself as well because it provides an abstraction layer between the actual purpose of La (number crunching) and auxiliary tasks like file reading which might as well be performed by the caller or helper libraries.

Sadly the La author is "not keen on" improving his own codebase.

i dont get it. where did you upload it? how do i get it, mine dosent work either...

I deleted it since my upload quota was full and it didn't mean nothing anyway, old post. It's the same as on la homepage anyways... Unless a little more compression is all you need stay away from la, it's a horrible format, OptimFROG is maybe what your looking for, I don't give a sh'''''. Used to like Monkey, but now it's WavPack for me. Best compromise compression, speed & features, and BSD license...