Not quite the case. Each layer parameter has its own phase and custom waveform and there is analysis of pre-post frequencies with a overall frequency sensitivity curve where the specific layer parameters are chosen. The entire thing is also digitally decoded (no sid oscillators used). However my past "frodigi" series did indeed do it the way you mentioned (and the quality was pretty subpar for many other reasons too - such as no phase data and only a sine waveform)

yes, all the decoding is done digitally and the output is sent to d418 (custom setup) to allow roughly 6 bits resolution

I have been experimenting with the other techmique. Playing digis over 1 voice. The quality is way superior to d018 toggling. Its 8 bit out, but since its controlled by the frequency, you can even play up to 16 bit digis. Only drawback is that it takes more cycles per push. Currently i am on a project to use a 2nd c64 stock connected with a parallel user port cable to have 1 c64 calculate continiously a pseudo 3d road. I could imagine something wih this too. Let 1 c64 decode and push its values into dd01 , so the other c64 can be dedicated to only pick up from dd01 and play the digi.

@@thealgorithm Or sync 2 c64s and have stereo :-)

@@thealgorithm Had to look it up, the voice playing digi is the sid vicious code as found at codebase.

@@acied6200 yes, its currently the highest quality method of getting digi output but needs to be cycle exact and uses more cpu time hence why I did not utilise that. Ideally you would need to write triangle or sawtooth, then set testbit, then write the sample value to high byte of freq register and then set silent waveform per sample update so that it will seek to the required value in the next update

There is no floating point maths or multiplications in the decoder. The core of the decoder is additive synthesis with each layer being added with different volume levels together and a phase accumulator per layer

@@thealgorithm How do you do different volume levels on the decoder side without multiplication or bit shifting?

@@AftercastGames Tables and indexing :-) 1k of tables for volume (32 levels with 32 values for each). The main core of the decoder reads an indexed channel and points to a volume table which adjusts the value and accumulates these for the other layers). Outside of the decoder, the parameter updater self modifies the decoder to point to the new volume tables, waveforms, pitch offsets etc. On a machine with such low cpu power, Tables are the key!

With phase optimisations and accuracy set to low, I can encode around 1 seconds worth of data in a minute (on a single core of a zen3 5800h) I would guess a supercomputer during that 1982 era (cray 1) would take several months to do that

In this current implementation (in this video) - since then there have been additions, But will talk about this particular one. The decoder on the C64 has 8 channels with each channel having 11 bit frequency resolution, 7 bit volume resolution and can place any one of the 8 predefined waveforms (sawtooth, pulse, triangle, noise, sine, res1, res2, trisaw) each having its own phase. The encoder does the heavy computational work being able to decompose a chunk (20/40/60/80ms) into multiple layers of waveforms, phase, amplitude and phase. The decoder mixes all these in realtime to recreate the audio on a stock c64 machine

Ok, so , in brief, we have are no digi music , but music recreated with the original Sid waveform, it's correct ? Very interesting .... I think never done before ....!

The encoder phase Is done on a regular PC ?

@@pasromano75 The music is recreated by simple waveforms yes and when these are layered together with phase, amplitude and frequency it recreates the source audio. All waveforms are digitally mixed hence it can be used on other hardware too

@@pasromano75 Yes

It really depends on the parameters and quality settings. The above example took (on a ryzen 5800h in single thread) around a minute per second of encode. If i want to maximize the quality further, it can take a massive half an hour just to encode 1 second!

There is a voice sample in this video, It contains a voice sample (tatu) unless its blocked in your region and muted. But to reiterate, this is not a speech encoder (other custom speech codecs will do a lot better for speech only). The whole purpose of this codec is to compress music to a "high" quality compared to its bitrate and to play it back on low cpu spec devices. Would be nice to see what other alternatives there are under 400-500 bytes a second playing on 80's retro hardware (without being a garbled mess) but not seen any yet. (exception being the amazing encodec or so but that requires powerful pc hardware and training data) and lots of ram and cpu for decode

​​​@@thealgorithmBy "voice only" I meant normal speech, not singing, no reverb or echo effects. I know you are optimizing for music only, but hearing a speech example of only talking helps evaluate the codec. Speech-only codecs are not appropriate for music, but music-only codecs are usually also appropriate for speech. (Essentially, I'm trying to evaluate if your codec is fixed wide band, fixed narrow band, or adaptive wide band)

@@JimLeonard here, this is an old example from a few years back, but you should get the rough example of the type of quality to expect from speech only (at under 300 bytes a sec) It is singing albeit more in a monotonous voice. suffice to say, this will give an example of how it will sound quality wise even if there is just pure monotonous speech www.dropbox.com/scl/fi/qq3lyxmq863csz5s7vfi4/awd3-diner50hz.mp4?rlkey=agipfhfo3f91onzo3hutpxccq&dl=0 Will encode a speech only with no singing example and link it to you soon

total monotonous speech here (its actually under 160 bytes a second after packing) as there are the gaps between the speech. (but if including the gaps inbetween its roughly at 250 bytes per second www.dropbox.com/scl/fi/d51bor98i6itgeubtcd3c/speechtesta.avi?rlkey=e0b20kppa2zohtaofz2le9htk&dl=0 The toms diner one does sound considerably better though By the way the spectrogram is in realtime so you will have a rough idea of the ranges used (mainly it falls in the mid/low frequencies)

@@thealgorithm Thanks! It seems to adapt pretty well, all things considering. At 500 B/s it is still competitive with other low-power speech codecs.

The quality at higher bitrates is considerably higher (high enough to sound just the same nearly as the source pre-encode) however the pack rate in this case is roughly 5:1 (May be more beneficial to use other codecs such as adpcm in this case which would use less cpu time compared to the AWE method of decode. Fastest IRQ loader at the moment is roughly 7.7k a second on the c64 (However this is if you give it all cpu for loading). As the AWE decode uses 90% of cpu time and has non maskable interrupts for sample playback, This would roughly reduce loading speed to perhaps 600 bytes a second (which is just about enough to stream and playback larger segments of audio

It would be roughly 1 and a half minutes as there would be roughly 46k or so of spare ram left, but ofcourse can be resequenced for repeating sections and in most cases should be able to fit whole songs into it (There was a human league example and la isla bonita example in earlier tests that were all in a single load)

@@thealgorithm What if you add a ram expander, or go the C128 route?

@@LPChip Then the possibilities are more. For example, I can then write data to the REU at a higher sample rate (and more layers) or/and with more accuracy, then play the decoded sample from REU at these high sample rates without using much cpu time.. For the C128, 2mhz can be activated in the border areas which can speed up decode and allow me to have a higher sample rate/or/and layers. However both these are not stock (I prefer coding on a stock machine - even though i have coded some easyflash cartridge music video demos before)

All from one prg file

dedicated speech only codecs should perform better than this (This encoder is not specifically aimed at speech). The preencoded source file does not sound that different to the encoded output (and its still packing the data to 12:1) even with the additional degradation of phase accuracy. The freddie mercury part for example. The others suffer more when comparing source pre-encode to decoded output (which gets considerably better with the phase set to full resolution). These examples also were mainly at 40ms (with transient sensitivity set to very low). Bear in mind that the sample rate is pretty low. At some point I will implement the decoder on the Amiga side (This will allow me to have higher sample rates and less restrictions on waveform size) - and still use the same filesize increasing the compression ratio Still a lot of improvements to make and on the pipeline. For example, more updates and less layers (and vq'd volumed codebooks) should improve the overall quality (even though the volume tables will then be non optimal)

@@thealgorithm I look forward to your Amiga experiments!

At some point yes, there is quite a lot of things to cover both on the decoder side and the encoding

​@@thealgorithmcan't wait to read about it. Your work keeps pushing the boundaries of 8bit home computers, and the c64 specifically, not to mention that thw results are amazing from the algorithmic viewpoint (no pun intended, at least not by me 😊)

Amazing

Sure. Look at my earlier examples on my channel which have examples from various pop songs. Though since then i have improved and refined the encoder by quite a bit

@@thealgorithm yep i know and i remeber that you have a problems with publishing commercial songs on KZbin. Maybe next time make something with voice from someone less known than Madonna :-)

@@thealgorithm Can we hear something with voice encoded in the new algo?

@@dwsel here you are (this is using phase quantisation, but expect around 15% better if this option is not used) kzbin.info/www/bejne/gpislJloateHn9k

I have some unreleased code that is able to play back 4 channel protracker songs (but also is able to depack each sample on the fly while mixing too) - This would allow large mods to fit in ram at one time. I have an earlier version of this in one of my single file c64 demos kzbin.info/www/bejne/aWPXaKiZpb-dpbc

I definately love your work. No .MOD player on c64? You could do yours. Congratulations again for your work.

Added 5 bit resolution now (without increasing precalced wavetable size. Quality is better though still needs some quality improvements. Have some ideas on improving it further at the same size. (Then when happy with it, will post some higher bitrate versions) kzbin.info/www/bejne/qabceGpuf92Xnas

Thanks. Yes, this is the idea for this demo (to have lyrics in time to the singing). Though i am also still considering instead to encode at a higher bitrate and have snippets of songs instead. (By doubling the file size to 400 bytes a second, it nearly sounds as good as the original resampled original) - at least in the same madonna example

@@thealgorithm I know this idea is far more complicated, but thinking about how we were doing our digimix back in 1991... our music guy was using the original song track and also an instrumental version only... to create a mix of the song. Maybe this kind of idea can be use here where the song refrain is with lyrics and high quality and other part instrumental but still in digital with higher compression rate?

@@fcycles in theTCBI50k single filer demo released in December 2021 or so, i used a higher quality background layer and lower quality speech layer. However I had to choose a track specifically that had many repeating background patterns (and the rick astley track was exactly that). It did comprise of a suboptimal quality speech layer though The only issue here is that there is not many tracks that have such repeated sequences of background audio. I did also experiment in separating the bassline, drums etc and reconstructing them like a mod track - which may be somewhat promising and something to look into

The original song has background chords, drums, bassline (deep bassline) and speech combined, so it is a hard case for the encoder considering the low bitrate used. For more demanding titles, I can increase the layer amount or/and parameter updates though there is a limit on how many layers i can mix on the C64 decoder end (due to the slow processor)

@@thealgorithm I see. So easier case would be something with less layering.

@@tsonez Less layering is needed for audio that is less complex (e.g speech) - this in turn will use even less space

It uses digital mixing without using the oscillators of the SID. Of-course the thing runs on a stock c64 regardless. Plus point of this is that it can be feasible on other machines too. More information on the technique here kzbin.info/www/bejne/j6PInIeoeLZljNU

@@thealgorithm Gotcha.. So the only register involved is the volume register then?

@@AftercastGames correct. its output via one register only. This also means that its not machine specific and can be used on other devices (as it does not rely on sid specifics such as its channels or oscillator)