pouët.net

algorithm information 172 glöps

• general:
• level: user
• personal:
• first name: Naveed
• last name: Khugiani

• demo Amiga OCS/ECS Amigaluscious by Onslaught [web]
• The whole video sequence would be nearly fine with youtube apart from the few seconds in the middle of the video sequence that would be classed as extreme adult visual content in comparison with boobs. Youtube would no doubt have issues with this section :-)
  
  This is just really a test showcase of the encoder (and by all means, the video and audio decode is severely unoptimised) Huge room for improvement here (in particular also changing the entire video decode method) Tile based 8x8 decode is not one of the amiga's strong points in comparison to the C64 (that can output a whole 8x8 4 color block with a single byte plot).
  
  Furthermore I am using a really crude version of "deblocking" via shifting x and y offset by 4 pixels per alternate field. If not looking too great on real amiga and CRT, it will look even worse on an emulator or video upload if not at 50hz
  
  For those that want to see the demo without having to run the amiga emulator, below is the dailymotion link.
  
  http://www.dailymotion.com/video/x2ebl4a_amigaluscious-a-demo-for-the-amiga-500-ocs-512k_tech
• isokadded on the 2015-01-09 14:17:47
• demo Amiga OCS/ECS Amigaluscious by Onslaught [web]
• My first Amiga demo since the late 90's, so try not to take it too harshly.
  Its rather a demonstration of my video and audio encoders on the pc reflected via realtime audio and video decompression with floppy disk streaming from a OCS Amiga (512k chip) It should also run on other more powerful amiga configurations.
  
  The audio compression method is based on a high bitrate version of my VOA encoder for the C64. I have also implemented amiga output decode in my CSAM super video encoder for the PC.
• isokadded on the 2015-01-09 01:22:20
• demo Commodore 64 Frodigi 5
• Quality is not too desirable due to attempting to encode a more complex audio source (in comparison to only speech/drums etc).
  For further examples on the quality that can be produced with other examples, there are a few c64 output examples here. https://www.youtube.com/watch?v=rpH3wLKPHCU&feature=youtu.be
  
  The whitepaper on the FFT method that is used in this demo is at the below link. http://csdb.dk/release/download.php?id=167729
• isokadded on the 2014-12-08 02:56:04
• demo Commodore 64 Strip-a-minute
• Read the disclaimer before commenting :-)
• isokadded on the 2014-12-03 22:00:10
• demo Commodore 64 Frodigi 4
• 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.
• isokadded on the 2014-11-12 03:21:11
• demo Commodore 64 Frodigi 3 by Onslaught [web]
• The basics of this encoding method have been explained previously. Below is a summary as well as some information on the additional improvements in the encoder and decoder.
  
  The Frodigi method is simply conversion of audio into sid waveforms and frequencies. In very much the same way as wavetable changes in SID music. The two main advantages in this method is the very small file size in the output data as well as minimal cpu usage (the decoder only needs to write a few values to sid registers once per frame
  
  This updated encoder and decoder now supports seperate amplitude per channel (this greatly increases the definition of the audio) I did actually incorporate this method in my older encoder previously but had discarded it due to the annoying clicking that was produced.
  
  A few days ago, was talking to agemixer and he had mentioned that changing the sustain and setting gate off/on produces peaks of amplitude on every change (This was already known previously) However setting sustain value of $f brings down the amplitude level to zero (and then the sustain value can be placed (0-e)
  
  Depending on the current sustain level, Lets say for example it was $04. (and previous value to this was $03), The sustain can be changed to $0f, and then $04. This results in amplitude previously being $03, then falling to $00 and then $04. Using the previous implementation, it would be amplitude $03, then rising to $0f and then $04 (which is more noticable)
  
  Ok that is the decoder out of the way. It sets gate off/on only if sustain is rising and if it is, then there is one of two ways to adjust the sustain.
  
  
  There has been around a dozen changes and updates to the encoder as follows
  
  Sustain static (keeps current sustain level if possible) and not a specific threshold higher. e.g if current sustain level for channel 1 was $04, the encoder would make sure it would only use sustains $00-$04 or $06-$0e (and not 1 or more above) This reduces definition, but decreases the occurance of sustain fluctuations
  
  Sub-band preprocessing and encode
  The low frequencies of the source are simplified and encoded seperately into the first channel
  The remaining two channels are encoded together using the second frequency band to recreate the audio
  
  Multiple window overlap. To keep transients sharp and bass smooth, various size windowing options are used. In this example 50% windowing on low frequencies and no overlap in the rest.
  
  frequency refine
  One an "optimum" seed is found, the local area is searched in order to lock on further to a more accurate volume/frequency for that particular channel
  
  The basic idea of the encoder is to start of with a population of data and to feed it into the virtual ear. the ear then gives the feedback to the encoder and the population is analysed, mutated, replaced, merged with multiple iterations.
  
  Multiple attempts as well as combining the above methods with stepcount hill climb allow local minima problems to be minimised.
  
  The c64 decoder used in this demo uses 7 bytes of data per frame updating at 50 frames per second (This equates to 350 bytes per second) I am however also using inline depacking in the demo that decompresses chunks of data while the audio is playing (This was to give me some space to put some gfx in)
  
  Will there be a frodigi4? Yes, I have idea's on improving the quality further (In particular smoother) but this would remove most of the naturality further (even though it sounds rather unnatural as it is)
• isokadded on the 2014-09-29 18:24:25
• demo Commodore 64 Frodigi 3 by Onslaught [web]
• Youtube link here.. https://www.youtube.com/watch?v=DFteV6YE7F0
• isokadded on the 2014-09-29 02:42:02
• demo Commodore 64 VOA by Onslaught [web]
• Its impossible to detect whether a sid chip has the resistor soldered on it. By default the SID detection will detect between old and new sid and adjust accordingly. Although I could have included an option to select "new sid with resistor" and then select 6581 mode
• isokadded on the 2014-09-03 01:02:11
• demo Commodore 64 VOA by Onslaught [web]
• The video is blocked in some countries due to youtube detecting the audio as copyrighted material.
  
  Solution? Either use a proxy or download the demo and run on emulator/real c64. Make sure the emulator is up to date and using accurate SID emulation otherwise audio will be reduced to mush.
• isokadded on the 2014-08-19 14:06:55
• demo Commodore 64 VOA by Onslaught [web]
• Demonstrates the output of my pc encoder that is able to convert full 3 minute audio tracks into a single disk side for playback on a c64.
  
  It is a huge improvement over VQ based methods as it freely allows sliding references into the 4k wavetable instead of being snapped to chunks (8,16 etc) furthermore for quality increase, each chunks amplitude can be updated to 1 of 16 volume levels.
  
  This allows a total of over 65000 16 byte chunks that can be recreated by only a 4k wavetable
  
  This particular example compresses each 16 byte sample into two bytes which consist of a 12bit value for the offset into the wavetable and 4bits of amplitude.
  
  I could have created the full decode via nmi and to reconstruct the next set of 16 bytes (or prepare offset/amplitude) while the previous 16 is being read, but this first implementation worked and left it at that
  
  The oscilliscope effect is rather basic and updates sprite y pointers after each 16 byte chunk has been decoded into the buffers. Per line update could have been possible, but most of the code had been finished already and did not recode the demo.
  
  The demonstration utilises the filter based d418 method, hence quality may vary on machine to machine, however autodetect is used in the demo in order to try and ensure that quality does not suffer between the two sid models.
  
  The example tune has many repeating sections, however this encode method works well for any type of audio including audio with no repeating sections.
  
  Quality can be increased further via multiple offsets and mixing (infact i have already created encoders that can mix 4 chunks with amplitude) To be implemented in a future demo
  
  Disk is 40 tracks. Also remember that if you are running this demo on an emulator, make sure it has accurate sid emulation (preferably latest version of winvice or micro64) It does not sound too great on hoxs64
• isokadded on the 2014-08-12 04:06:56