| FRODIGI - Free Running Oscillator Digi | ||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 55% |
|||||||
alltime top: #12220 |
|
|||||||
|
||||||||
added on the 2014-05-27 02:43:45 by algorithm  |
||||||||
popularity helper
comments
I'm not hugely familiar with everything that's been achieved on C64s, but this absolutely blew my mind. Brilliant.
Madness!
quite cool idea...!
even if it's sometimes hard to recognise...but some are quite cool like kraftwerk or ofra haza
even if it's sometimes hard to recognise...but some are quite cool like kraftwerk or ofra haza
Finally released! \:D/
Great job Algorithm, your routine is ACE! :)
Great job Algorithm, your routine is ACE! :)
Is there a youtube for this?
can this be adapted to other platforms somehow? POKEY?
The decoder is nothing special at all. It reads 9bits for each channel per frame to point to one of 512 predefined notes and a 4 bit volume control for that frame.
The encoder does all the hard grunt work.
Heaven, yes it can be adapted to any sound chip :-) More flexibility on the C64 side due to ringmodulation/filters (which this implementation does not do anyhow)
Youtube link as below
https://www.youtube.com/watch?v=CBWdGWRIvMQ
The encoder does all the hard grunt work.
Heaven, yes it can be adapted to any sound chip :-) More flexibility on the C64 side due to ringmodulation/filters (which this implementation does not do anyhow)
Youtube link as below
https://www.youtube.com/watch?v=CBWdGWRIvMQ
Heh. Thats a nifty trick!
nice! would be cool to have a more detailed explanation, so we can try and port this to another chips (e.g. AY8912 is in desperate need of some love)
just checked the youtube vid again...
did you try not just to replay and before encode for 50hz...maybe 100hz or 200hz? if so how does this sound ?
did you try not just to replay and before encode for 50hz...maybe 100hz or 200hz? if so how does this sound ?
such BOOM TSCHAK! <3
super brilliant stuff!
Thanks all for the comments.
The encoder specifically encodes each chunk for 50fps update (A sample at 44100hz would be equivelant to around 883 bytes.
As the oscillators are free running, the decoder may start waveforms from an unknown point per frame (While the encoder internally trys to find best sliding matches for each channel internally). This can be somewhat rectified if taking into account cycle exact writing in the decode and configuring the encoder to take this into account as well as saving the last state of the waveform position
This error is recognisable even more when there are more updates per frame unfortunately.
You would have noticed that there are less low frequencies on the audio. This is deliberate, as the error audibility is more on low frequency waveforms. Higher frequency data overlaps more occasionally with the other channels to reduce the error somewhat.
A brief technical insight into the routine as follows
An index into the predefined frequencies and waveforms for the three channels and a master volume are randomly selected initially
the "wavemerger" performs the calculations required and this is compared with the source audio chunk. In essence, this finds the error based on the three waveforms, frequencies and optimal offsets
A multishot-hill climbing method is used to reduce the error and to find a more optimal match. approximately 10,000 iterations are used and frequency data saved. the process is repeated for each shot, and the best final result is used.
This selection of data is passed onto the next generation where further tweaks are made
Without changing the encoder, improvement in quality can be made by using more note-tables. I chose to use notetables in order to provide the necessary compression as this uses 31 bits per frame (9bitsx3 channels+master volume for chunk)
By utilising for example 4096 note tables, it would increase quality rather more and use 40 bits only per frame.
The encoder specifically encodes each chunk for 50fps update (A sample at 44100hz would be equivelant to around 883 bytes.
As the oscillators are free running, the decoder may start waveforms from an unknown point per frame (While the encoder internally trys to find best sliding matches for each channel internally). This can be somewhat rectified if taking into account cycle exact writing in the decode and configuring the encoder to take this into account as well as saving the last state of the waveform position
This error is recognisable even more when there are more updates per frame unfortunately.
You would have noticed that there are less low frequencies on the audio. This is deliberate, as the error audibility is more on low frequency waveforms. Higher frequency data overlaps more occasionally with the other channels to reduce the error somewhat.
A brief technical insight into the routine as follows
An index into the predefined frequencies and waveforms for the three channels and a master volume are randomly selected initially
the "wavemerger" performs the calculations required and this is compared with the source audio chunk. In essence, this finds the error based on the three waveforms, frequencies and optimal offsets
A multishot-hill climbing method is used to reduce the error and to find a more optimal match. approximately 10,000 iterations are used and frequency data saved. the process is repeated for each shot, and the best final result is used.
This selection of data is passed onto the next generation where further tweaks are made
Without changing the encoder, improvement in quality can be made by using more note-tables. I chose to use notetables in order to provide the necessary compression as this uses 31 bits per frame (9bitsx3 channels+master volume for chunk)
By utilising for example 4096 note tables, it would increase quality rather more and use 40 bits only per frame.
must. thumb.
great
Fucking awesome.
I can just imagine if there was 2 other coders with you, and talented graphic artists and musician... I think the result will be a surprising quality demo with newest techniques which will bring a new way of doing demos on the 64... just like trackmo bring a wind of change in the '90...
Does not sound very useful with only 2 rasterlines active, at least I had a good laugh.
cannot wait to see video+audio all together in a 64kb file... ;)
don't know anything about platform, technical stuff and will never use it. still thumb up because it seems to be some wicked shit. looking forward for demos/intros that use it :)
clever, even an old cart can learn new tricks!
ace
for the boom-tschak
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !
It demonstrates the output of my new audio encoder that produces output that is able to be decoded on the c64 using only a few raster lines per frame.
It uses the free running sid oscillators on the c64's sid chip in 3 channels and a master volume to recreate the audio.
Mainly suited for speech, but can also work on other sources. This demonstration packs a few minutes of audio into less than 41k and running in a c64 made in the early 80's with only 1mhz processor. Enjoy