Best compressed audio?

[Steam Ranger]

How do I apply delta encoding? What file format is it? Can I do it in Audacity?

[Karlos]

Originally Posted by Steam Ranger

How do I apply delta encoding? What file format is it? Can I do it in Audacity?

1. Start with a current value, initially set to zero.
2. Read the next sample
3. Delta = sample - current
4. Choose the quantized delta value from your table that gets you closest to the the actual sample value.
5. Current = Current + quantized delta
6. Repeat from 2.

The idea here is that each quantised delta step is usually going to undershoot or overshoot the desired target but it's always correcting towards it rather than just drifting off all over the place.

[Steam Ranger]

Originally Posted by Karlos

1. Start with a current value, initially set to zero.
2. Read the next sample
3. Delta = sample - current
4. Choose the quantized delta value from your table that gets you closest to the the actual sample value.
5. Current = Current + quantized delta
6. Repeat from 2.

And to decode I basically just do the procedure in reverse?

[No.3]

http://aminet.net/package/mus/misc/wavepak

[Karlos]

Originally Posted by Steam Ranger

And to decode I basically just do the procedure in reverse?

Yeah, except you just directly look up the quantised delta value from the table. The value you store in the compressed stream is just the nybble index position of the quantized delta value in the table.

[Karlos]

Originally Posted by No.3

http://aminet.net/package/mus/misc/wavepak

This looks entirely cromulent. Includes source too by the look of it.

[koobo]

Off topic:
This AGA demo by Union from 1995 had a whole Pink Floyd tune encoded into it: https://www.pouet.net/prod.php?which=7824

[smack]

All this talk about 4-bit delta and XPK SQSH compression reminds me of a program that I wrote a few (well almost exactly 26 ) years ago:
http://aminet.net/package/mus/play/psmp = IFF-8SVX player (source code included)

[pandy71]

Originally Posted by No.3

http://aminet.net/package/mus/misc/wavepak

Name can be confusing with https://en.wikipedia.org/wiki/WavPack but seem that Wilhelm Noeker was first.

[Karlos]

Many years ago, I wrote an adaptive, frame based delta encoder for 16 bit audio, intended for sound effects and speech. It had frames encoded as 0, 1, 2, 3, 4 or 5 bits per sample packed into 16 bit words. 0 was a special case for silence encoding (used in noise gated speech). A stream had a uniform output frame length, e.g 1024 samples, but this applied to that stream only. Each frame had a header that contained the actual delta decode table (only as many as the distinct number of values present) followed by the packed data. Although this was somewhat wasteful, the point was that the encoder was free to choose the best N delta values for the set of input samples in the fram. Costs were assigned to each bit depth, 5 being the most expensive (from a compression perspective) while the overall RMS quantisation noise of the output compared to the input was scored for quality. The encoder, with an overall quality parameter value, would weigh the encoding cost against the quantisation error cost and try to find the best fit.

This was all compression time overhead. Decompressing was the same as described in earlier posts, except that the delta table wasn't global, but unique per frame.

The encoder actually had a UI. Screenshot, showing the analysis of a single frame: https://github.com/0xABADCAFE/ancien...shot/xdac1.png

[Karlos]

I should revisit and simplify that some time. For one thing, when you have a frame of hundreds or samples your delta values, when sorted ascending, always follow a sigmoidal sort of shape. Rather than storing the delta values maybe the parameters of the curve of best fit could be used. That does imply more runtime effort to decode, bur there'd be better compression of the frame overall.

[Steam Ranger]

Does anyone know where I can get the source code for a media player or something? I want a sample to pick apart and build a working set of audio functions.

[paraj]

Originally Posted by Steam Ranger

Does anyone know where I can get the source code for a media player or something? I want a sample to pick apart and build a working set of audio functions.

The source code linked in post 13 should be close to what you want (though you may want to strip it down a bit). Otherwise maybe something like http://aminet.net/package/mus/play/playsound could be a decent starting point (a bit old school, but system friendly).

Originally Posted by Karlos

The table was to be illustrative rather than a real world example.

Yes, sorry, I'm a dunce.

Originally Posted by Karlos

The encoder actually had a UI. Screenshot, showing the analysis of a single frame: https://github.com/0xABADCAFE/ancien...shot/xdac1.png

Very cool! I see there's also very readable source code there. Some neat ideas, and maybe a tweaked version could even make sense for OP's use case. You could precalc a number of tables ahead of time, make optimized decode routines for each bit/sample version (maybe only 0/2/4 or something), and have a tiny header for each frame (the length of which could be optimized to match the playback rate).

[Karlos]

Originally Posted by paraj

The source code linked in post 13 should be close to what you want (though you may want to strip it down a bit). Otherwise maybe something like http://aminet.net/package/mus/play/playsound could be a decent starting point (a bit old school, but system friendly).


Yes, sorry, I'm a dunce.

Very cool! I see there's also very readable source code there. Some neat ideas, and maybe a tweaked version could even make sense for OP's use case. You could precalc a number of tables ahead of time, make optimized decode routines for each bit/sample version (maybe only 0/2/4 or something), and have a tiny header for each frame (the length of which could be optimized to match the playback rate).

Damn I wouldn't call that crap readable, it was like my first day

It's based on a very early C++ framework, before I found my preferred style and had much understanding how to wield it properly. On the plus side, the UI was fully hardware rendered, using a drawing library on top of Warp3D in that example. It's running on an unreleased driver iteration that actually does line drawing on the GPU I had. All the shading (which reflects the signal intensity ranges) are Gouraud shaded rectangles and the character glyphs are actually alpha blended textures.

It's coming back to me now. The lower graph shows the distinct, ordered deltas as the yellow plot, their population as the blue plot (almost always flat you'll notice) and the best fit curve based on the chosen 16 values in white. The overlay of this graph doesn't look that ideal but that's because the horizontal coordinates of each point don't take any weighting of the input values into consideration, they are just evenly spaced.

[Karlos]

On a semi related note, I do have an improved 8 bit format intended for Paula specifically but I've not implemented playback for real, only simulation. If you are interested, it's here https://github.com/0xABADCAFE/paula-hdr

It's very different. Rather than being a second rate 16-bit alternative, it aims to be the best 8-bit. 16 bit data are converted to 8 bit, using gain adjusted frames. The gain adjustment at runtime is intended to happen via Paula channel volume modulation being applied in hardware. So every frame has 8-bit precision but a gain that changes the channel volume. The simulation produces excellent results but I've not implemented it for Paula yet.

[ross]

Originally Posted by Karlos

On a semi related note, I do have an improved 8 bit format intended for Paula specifically but I've not implemented playback for real, only simulation. If you are interested, it's here https://github.com/0xABADCAFE/paula-hdr

It's very different. Rather than being a second rate 16-bit alternative, it aims to be the best 8-bit. 16 bit data are converted to 8 bit, using gain adjusted frames. The gain adjustment at runtime is intended to happen via Paula channel volume modulation being applied in hardware. So every frame has 8-bit precision but a gain that changes the channel volume. The simulation produces excellent results but I've not implemented it for Paula yet.

This is interesting, but there is possibly a flaw in this approach: amplitude modulation is word based, so volume change is per two samples* (usual "14-bit" player is byte based).
Also sure it's faster (than 14-bit) and sounds better than normal 8 bit, but it only works for two maximum usable channels.
In any case I'd like to hear the results, it might be unexpectedly good

An alternative method that had been floating around in my mind a while back was to use copper to apply volume to individual channels.
But it would be annoying because it would require mixing on a frequenncy multiple of video line in order not to lose any other effects with the copper.
Theoretically the result would be absolutely similar to amplitude modulation on a single sample per 4 channels.

EDIT: *actually with modulator channel at doubled frequency you could do it per sample, but then the modulated channel is at half max frequency..

[Karlos]

Originally Posted by ross

This is interesting, but there is possibly a flaw in this approach: amplitude modulation is word based, so volume change is per two samples* (usual "14-bit" player is byte based).
Also sure it's faster (than 14-bit) and sounds better than normal 8 bit, but it only works for two maximum usable channels.
In any case I'd like to hear the results, it might be unexpectedly good

An alternative method that had been floating around in my mind a while back was to use copper to apply volume to individual channels.
But it would be annoying because it would require mixing on a frequenncy multiple of video line in order not to lose any other effects with the copper.
Theoretically the result would be absolutely similar to amplitude modulation on a single sample per 4 channels.

EDIT: *actually with modulator channel at doubled frequency you could do it per sample, but then the modulated channel is at half max frequency..

That was already taken into consideration. The shortest possible frame is 2 samples of the same overall volume. The actual intention is that a frame would be longer than that, but always a multiple of 2 for the very reason you state.

See: https://github.com/0xABADCAFE/paula-...ee/master/data

The encoded.raw file is 44kHz signed 8 bit with the volume sample (0-64) followed by 16 8-bit signed samples to be played at that volume. It's also mono.

The decoded.raw file is the simulation output where we assume no latency applying the volume modulation in hardware. It's 44kHz 16 bit, mono, little endian encoded because I just did the prototyping on my pc initially. Based on subtracting it from the original 16 bit input and measuring the RMS error, it seems pretty decent.

The original input file is the one that's labelled test_raw16bit_LE.raw

Obviously the real file format would have a header and would probably arrange the data in a way better suited for playback under the proposed channel modulation scheme.

[Karlos]

Just thinking a moment. Let's say the automatic gain adjustment idea works, i.e. using hardware volume modulation updated every "frame". The 8 bit PCM data itself is always as close to normalised in intensity. It makes me wonder if you could then compress that to 4 bit using the basic techniques we've been describing so far. You'd still have better dynamic range than 8 bit overall and much smaller data than 16 bit.

[robinsonb5]

I saw a blog post today and immediately thought of this thread:
https://phoboslab.org/log/2023/02/qo...io-compression
Maybe it could be adapted for Amiga use - or maybe not - but either way there's some good information there - I hope it least makes for interesting reading.

[ross]

Originally Posted by robinsonb5

I saw a blog post today and immediately thought of this thread:
https://phoboslab.org/log/2023/02/qo...io-compression
Maybe it could be adapted for Amiga use - or maybe not - but either way there's some good information there - I hope it least makes for interesting reading.

Yes, it may be adapted but it definitely wouldn't be as fast as an ADPCM decoder.
From a quick look the only sticking point would be a multiplication per sample (data structures designed for 64-bit architectures can simply be redesigned).

For sure for a (fast?) 020+ machine.