|
| |
Credits :
SIDs used in this release :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by algorithm on 25 November 2014
User Comment
Submitted by algorithm on 13 November 2014
| Arrrghh edit feature disabled.. the 50hz update in frodigi4 of the below link sounds better. now the aim is to perhaps incorporate quad speed using the awd method.. |
User Comment
Submitted by algorithm on 13 November 2014
And as comparison to the knight rider single speed method (frodigi awd), below is the link to the same fft method as used in the link I posted previously (myhump sample) Only slight modification to select a bass frequency only for the first channel
https://www.dropbox.com/s/06cidk4c85qs4hj/knightfft.prg?dl=0 |
User Comment
Submitted by algorithm on 13 November 2014
Ok. Did a quick test with quad speed using the myhump audio file and FFT(but not preprocessed in anyway yet)
https://www.dropbox.com/s/1jggm6eocema27a/dd.prg?dl=0
Filter is turned off, hence will notice some artifacts.
Excuse the unoptimized code (only for test purposes) It is also using the same player as frodigi (but the fft encoder is placing values into the player as it is) - without converting to lookups to save space |
User Comment
Submitted by algorithm on 13 November 2014
| For speech/drums, a 2048 point fft would result in 1024 frequency steps from 0-22050hz (assuming that the sample rate was 44100hz) around 190 of these would be in the 0-4000hz region. which is enough to store 3 channels of frequency data in 3 bytes (which would point to a lookup table (512 bytes) containing the freq values. This is what i am using in my fft unreleased implementation and data rate is at 3.5 bytes per frame (or 4.5 bytes using seperate sustain for each channel) |
User Comment
Submitted by algorithm on 13 November 2014
@jammer. My assumption is that it is using 3.5 bytes per update x 4 = 14 bytes per frame (around 700 bytes per second) For speech compression, c64mp3 for example compresses to half the size or so.
Frodigi 4 uses around 200 bytes per second packed (and 350 bytes per second unpacked) The larger size is due to any waveforms being used for the three channels as well as having seperate sustain data per channel and 12bit freq per channel. This is a necessity when attempting to recreate full musical content in a single update per frame |
User Comment
Submitted by Jammer on 13 November 2014
| So what is the bitrate in My Humps then? ;) |
User Comment
Submitted by algorithm on 13 November 2014
@oswald. Yes, the other alternative via fft would be to mix the required sid waveforms for the three channels and then to perform an fft and compare the magnitudes. This would have the issue of different values however based on the offsets of the mixing of waveforms.
The method i am using solves this issue without using FFT by component seperation into the c64's 4 waveforms (which also solves the issue with the phase overlaps) Genetic algorithms with analysis is also used.
Currently all the frodigi1-4 updates only at 50hz. There are ways around this limitation without introducing distortion.
The issue with the distortion is due to the smaller window size (e.g at 44100hz, this would equate to around 882 bytes for a 50th of a second. Quad speed would only have 220 bytes. With the FFT method that i have also incorporated (but not used in a demo yet) this is less of an issue as the source chunk is mapped over to 3 sine waves only with different frequencies. (The low frequency resolution is solved via higher fft size and padding with 50% overlap) - ofcourse this does not actually increase the frequency resolution, but does give a more approximate frequency latch in particular when only dealing with 3 sine outputs. furthermore i am locking magnitude analysis in low frequencies and dedicating that to the first sid channel.
Using my method, and having quad speed, a larger window size/higher sampling rate or/and overlap would solve the issue partially (as well as only using triangle waveform, where the distortion is less pronounced) In the current implementation, A pre-subband transform is used and the windowing/overlap is used in the low frequencies finding the most dominant timbre/frequency and mapping it over to a single sid channel. The other two channels are used to recreate the other content including sharp transients.
This overcomes the limitations that are inherent in FFT conversion in a limited amount of sine waves.
The demo uses filters and on some c64's and micro64, the audio sounds extremely muffled on the 6581.
@jammer. The quality of the speech in the cyberbrain demo is excellent. No doubt about that. but 200hz update using this method would use nearly 2k a second. Can near or enough have audio quality using other methods (without oscillator) sounding near lossless at that rate for any audio source. (at the expense of eating cpu time ofcourse) |
User Comment
Submitted by Oswald on 13 November 2014
| algo, you mentioned square-fft problem, how about representing c64 side square as sine components and comparing that with the original? same could be done for all waveforms, maybe even including mixed ones :> |
User Comment
Submitted by Jammer on 13 November 2014
| I also didn't know that My Humps is updated 4x. No sense in comparison then, especially in ranting Algo, you lamers ;) I assume it goes right direction - maybe try 2x/4x update with shorter audio? ;) |
User Comment
Submitted by algorithm on 12 November 2014
Ahh indeed the other demo updates 4 times a frame. (200hz)
I have quickly made a few amendments to the fft module in my encoder to support quad speed and it does sound a lot better in the samples I have tried (speech, drums etc) but data rate is too high. (I would rather use my other audio compression methods if data usage is above 1k a second
Again, using fft for the basis of analysis does not work very well with a very limited amount of destination channels |
User Comment
Submitted by algorithm on 12 November 2014
@soci. I was not aware that the cyberbrain demo updated at 200hz. I did look at the code briefly and it seemed to have three fixed sustain values with $d418 adjustments to control the volume of the waveforms (and a byte usage sent to the hi frequency registers (with fixed triangle)
The concept of this demonstration is to demonstrate the timbre/transients and frequency accuracy in comparison with FFT based approach. I would happily like to hear something with low frequency instruments, drums and speech using the fft approach in 3 channels |
User Comment
Submitted by soci on 12 November 2014
| Could you try how it would sound a with 200 Hz update rate, like in that other demo for fair comparison? |
User Comment
Submitted by Mixer on 12 November 2014
| I think that the encoder would have use as a pitch and "color" detector that could be used to translate mono solo inatruments to sid tracker notation. On the other hand there is melodyne and the like daw tools that can do conversion to midi and then one can import the midi file to sid tracker. It has been interesting to follow the developement of this tech. |
User Comment
Submitted by chatGPZ on 12 November 2014
| no offence, but what i like most in this production is the charset |
User Comment
Submitted by algorithm on 12 November 2014
@burglar. Please read the notes for the advantages and disadvantages of this method in comparison. All is explained there. I have clearly mentioned that for speech examples, the fft method works normally better but would fail to recreate drums, timbre and pitch data for instrumentation in combination with speech etc. Try the fft method on the audio sources here :-)
@Oswald. Not much audible difference in 16bit frequency in particular for mid/high frequencies. For extremely low frequencies, it may be more beneficial. |
User Comment
Submitted by Burglar on 12 November 2014
User Comment
Submitted by Oswald on 12 November 2014
| why not just store 16 bit freq for all 3 channels, instead all of these compromises? you get a whole frame for a dozen of bytes of data anyway. |
User Comment
Submitted by Peacemaker on 12 November 2014
| have "seen" something like that at the x party this year. |
User Comment
Submitted by algorithm on 12 November 2014
The final instalment of the series.
Numerous improvements in quality (in particular the addition of more sophisticated frequency analysis)
Overall the demo demonstrates sample playback via using sid waveforms. This has the advantage of using very minimal cpu time (only a few raster lines) and taking a very small amount of space (around 200 bytes per second packed)
The decoder demonstrates the output of the AWD (Algo Wave Decomposition) which has its plus and minus sides in comparison with the traditional FFT based approach.
+advantages in AWD
Precise frequency/pitch resolution 0-4000hz and up to 16bit frequency range
timbre and harmonic detection with modules for speech, drums and other instrumentation
produces higher quality sounds for more complex data in comparison with fft approach due to utilising the c64's 4 waveforms (Pulse wave alone is the equivalent of many sine waves which the fft would decompose)
-disadvantages in AWD
It encodes very slowly
It does not produce optimum data due to local minima issues (although this is somewhat minimised due to different methods of escaping from local minima
For more simple data (speech), quality can suffer
+advantages in the FFT approach
Very fast
produces more optimum quality for more simple sounds and 3 sine outputs. (and usually sounds smoother for speech)
-disadvantages in the FFT approach
frequency resolution is very low at small time frames. Furthermore due to not being able to utilise the full
frequency range (0-22050) for 44100hz samples, it would only use a quarter of the frequencies 0-4000
e.g a 44100hz sample with fft size of 1024 would produce 512 slots with each slot in 43hz intervals (44100/1024)=43. 43*512=approx 22050hz
only the first 93 slots would be in the range 0-4000hz
Solution would be to have a longer chunksize but this would affect transients.
Another alternative would be to pad the large chunksize (which would interpolate values normally giving a
better representation of the frequencies
decomposes audio to sine. With the limitation of 3 channels on the c64, this would not give ideal quality for
more complex data
There are variants of the FFt which allow finer frequency resolution or non-linear resolution which may work well. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
