Lossless Audio Codec

[encode]

A small announcement.

Just started working on my own lossless audio codec. Having said that I'm keeping such thing in mind for a long time and I'm not happy with current audio codecs - most of them not open source, others often obsolete. So as a high graduated sound engeener and musician (I have two diplomas - Bassoon player/teacher and Sound engineer/audio director of TV and Broadcast) write own thing.
The basic idea behind this codec:
+ Use an advanced LPC + own highly efficient PAQ/ARI encoder
In other words - combine all my knowledge and audio experience with my data compression experience.

This can be a bombshell...

[LovePimple]

A small announcement.

Just started working on my own lossless audio codec. Having said that Im keeping such thing in mind for a long time and Im not happy with current audio codecs - most of them not open source, others often obsolete. So as a high graduated sound engeener and musician (I have two diplomas - Bassoon player/teacher and Sound engineer/audio director of TV and Broadcast) write own thing.
The basic idea behind this codec:
+ Use an advanced LPC + own highly efficient PAQ/ARI encoder
In other words - combine all my knowledge and audio experience with my data compression experience.

This can be a bombshell...

Thats excellent news!

How old are you?

[encode]

How old are you?

As can be obtained from Squeeze Charts Hall of Fame, my birthday is 31 July 1984.

[LovePimple]

my birthday is 31 July 1984.

Soon to be 23 years old. Thanks!

[PinkysBrain]

Bombshell? Audio lossless coding is a bad place to make an impact unless you really think you can get big gains (tens of percent) in compression. Highly unlikely though when you look at the present field and how close everything is together despite big differences in technical complexity. Maybe if you can be about as good in compression as LA while being about as fast as Wavpack you could raise some eyebrows ... but with PAQ the odds are against you either way.

There is always the satisfaction of a job well done of course

[encode]

Anyway, at least will make some experiments...

I already wrote a generic codec. Compression and speed is about the same as with FLAC - sometimes better than FLAC, somethimes not. But it's an extremely simple! I compared it to OptimFROG - OptimFROG has a higer compression, but notable slower.

The catch of my generic codec is a special arithmetic encoder. I tried many variants of LPC and entropy coder variants:
Generic Order-1 ARI
Generic Order-0 ARI
Order 1-0 CM
FPAQ0P-like Order-1 coder
One of the most efficient is FPAQ0P-like. It's very fast and close at compression with Order 1-0 CM. However CM is the best at compression anyway.

Why bit-oriented is the most efficient?
Analog sources contain a noise. Bit-oriented coders are the most efficient ones since they code each bit separetely as a result we can fight with this garbage statistics more efficiently.

Sample:

00101101

Imagine that the last bit is a noise. If we use a byte oriented encoder we will code 45. Most likely the statistics for such value will be wrong.

But with bit oriented coder, we will encode seven bits with accurate statistics and possibly only one last bit will be encoded not so efficiently.

For example, PAQ6's analog model just drops the lower bits - to discard noise.

So, I'm coming for the more complex modeling, probably even without actual LPC - as a similar thing can be modelled inside.

If you think that PAQ stuff is dead slow - you're wrong. I have my own PAQ-like encoders which fast enough even for real time audio codec.

Continue digging, to be continued...

[PinkysBrain]

Hmm, as fast as FLAC? I guess I deeply underestimated just how much processing time is taken up by prediction.

Do you have a guess where the effectiveness of using an order 1 coder comes from? I thought that since the previous bit is already used in matching it would not provide benefit in the final entropy coding.

[encode]

Do you have a guess where the effectiveness of using an order 1 coder comes from?

Look at the waveforms shape. Even after LPC, some correlation between values (errors) is present. So, order-1 or order-2 model can help. At least, in my experiments order-1 is always better than order-0. I didnt play with order-2 yet, since order-2 can ruin the performance.



Continue playing with audio compression. In addition, a new coder, a further evolution of QUAD, also floats in my mind. Just optimized my arithmetic encoder (from LZPM). In plans, it might be something LZ-based. An optimized/fast arithmetic encoder form LZPM + LZ77/ROLZ/LZP. Will try all variants. For example will make some research to see how LZP with various orders works with Flexible parsing. By the way, the better hash function improves compression with LZP, however, potentially, LZP is slower at decompression than say ROLZ or LZ77. Note that the aim of this project is some sort of Deflate replacement - fast decompression, low memory usage, and various encoding modes witch can cover from fast to high compression with no decompression speed impact. Modern Deflate in other words.

[PinkysBrain]

I understand higher order coding helps in general, I just thought you were already using PAQ to determine the probabilities for the bits (in which case the arithmetic coder gathering it's own statistics doesn't make a lot of sense).