Since Paul asked me to look at it (and what’s equally important, provided the binary to look at), I did exactly that.
It turned out to be a rather simple codec, originally known as Sonic Foundry Lossless. The only really interesting detail is that it has intra- and inter-frames. Intraframes start with 0xFFFFFFFF and four last samples for each channel (for filtering purposes). Each frame stores the number of samples (I suppose), coded data size, Rice code parameter (per channel), filter method/order (ditto), LPC coefficients (same, only if global flags enable it though) and probably CRC.
Data is coded as fixed-parameter Rice codes (low bit is used for the sign)—unless it’s filter method 5 which means all zeroes, then optional LPC phase (LPC has order four and 8-bit coefficients) and then, depending on filter order, fixed prediction as in Shorten.
Finally there may be mid/stereo reconstruction (if global config signals it) and clipping for 24-bit mode (but not for 16-bit apparently).
I don’t know if they’ve added some improvements in the newer versions but this looks rather simple compared to other lossless codecs. There’s the final bit of weirdness: it’s usually stored in WAV which means it’s one of those codecs with variable-size frames in WAV. Not something I’d like to support.
P.S. I’ll document it for The Wiki (as well as DVC from the previous post) a bit later.
NihAV does not split random bitstream into packets with parsers? (NihAV needs to overcome such limitations ASAP!)
Just finished writing parser (easy task) for PAC bitstream, obviously parser splits at intra frames boundary, and that is enough work as wav demuxer is already using parsers if available.
I have a different design: normal demuxers are producing packets themselves and there are raw stream demuxers that produce raw stream chunks that have to be assembled into packets with packetisers.
It’s just in case of WAV this would be a hack and I still haven’t bothered to support variable-frame formats in it.