pouët.net

algorithm information 172 glöps

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

• demo Commodore 64 Frodigi 2
• Thanks all. Some very brief technical information as below.
  
  Ok some technical information as follows
  
  Current Encoder capabilities as follows
  
  25hz/50hz mode (25hz mode has half the data rate and aimed mainly at speech)
  12bit frequency in each channel normalised to $0000-$ffff
  usage of all 4 waveforms
  optional usage of empty channels for higher amplitude resolution
  Greedy or Step counting hill climbing mode with variable parameter
  Optional window overlap mode x2/x4 (helps smooth and reduce distortion)
  Multi-attempt mode for higher error reduction
  Optional brute force volume in conjunction with selection/hill climbing
  Single channel mode utilising sustain for amplitude changes
  Ability to use only 1 waveform for the three channels/1 channel for higher compression
  
  In very basic terms, the encoder reads an audio chunk equivelant to a 50th of a second and initially feeds a seed of data into the analysis engine which in turn responds and
  allows tweaking and improvement of the small data set until it is refined to a sub-optimal set of frequencies and waveforms for the 3 SID channels)
  
  There are many other adjustments that take place in order to improve on quality including multishot attempts and future generation creation as well as variance static.
  
  There are still many improvements to be made which will be released in the Frodigi3 demo.. Yes there will be another one.
  
  The c64 data in this example demo consists of 6 bytes bitpacked data per frame (equating to 300 bytes per second) After final compression, data size is at around
  180-190 bytes per second
  
  The decoder merely reads the bit-packed data, normalises the frequencies, extracts the waveform data and volume data for each chunk per frame
  
  Code was put together in half an hour and i am aware that the decoder is not optimised in any way whatsover, but i guess can be optimized to use only a few rasterlines at most per frame.
  
  To reduce clicks due to amplitude changing in old sid, i am interpolating the volume data inbetween frames. Preferably use a new sid and a real c64!
• isokadded on the 2014-07-23 16:50:28
• demo Commodore 64 Frodigi 2
• Since the release of Frodigi, I had implemented many changes in the encoder for the PC that generates compressed audio data that can be played back on a C64.
  
  For anyone that has not heard the previous frodigi demo, this demonstration produces "audio samples" by changing waveforms and frequency only once per frame in order to recreate the audio.
  
  More technical details to follow. Use new SID for higher quality
• isokadded on the 2014-07-23 01:40:30
• demo Commodore 64 Bad Apple 64
• Actually to come to think of it, You can save the codebook as bitmap, then use the "convert studio" option, select any mode and then save raw LUT. The codebook saving can be ignored (and you can use the original codebook that was saved in the main gui instead)
  
  However selecting the compression studio module does remap and optimize blocks, hence do not use this option as the codebook order and LUT's wont match the original saved codebook
• isokadded on the 2014-07-01 23:13:20
• demo Commodore 64 Bad Apple 64
• It is specifically for the c64 when using the conversion and compression sections in the encoder, however there is the option to save the codebook or converted frame sequences as bitmap streams before it is converted to c64 format)
  
  You can then create a simple program that reads and stores different 8x8 char data in the bitmap streams and then remap into Lookup data.
  
  Some types of customizations are possible (such as reducing codevector amount) e.g I believe atari800 has a tile limit of 128. Unfortunately at this stage, the encoder only operates on images that are 320x200 in size as well as using 8x8 pixels (rather than 2x2,4x4 etc) Although the encoder does map over small chunks (e.g 4x4) to specific areas of the 8x8 codevectors to reduce error when required.
• isokadded on the 2014-07-01 23:10:58
• demo Commodore 64 Bad Apple 64
• I have experimented in many clustering methods and ultimately released one of my tools (CSAM Super) that uses the genetic / hill climbing methods
  
  Example of some of its functions here..
  
  https://www.youtube.com/watch?v=-jSUS4nBaqE
  
  The main core of the encoder is in assembler and uses 4 cores utilising "lazy error updates" which increase the encoding speed greatly without GPU.
  
  Unfortunately the 16x16 tile method is encoded using traditional LBG (and pruning codebook selection) hence quality in the first encode step is a lot worse than it should have been. I would have estimated twice the quality increase if I had got around to recoding this to use my new method of clustering.
  
  Based on tests, the genetic/hill climbing method does result in higher quality than ELBG (Enhanced LBG) and even more so when utilising the weighting options to target regions of interest.
  
  Furthermore unlike the traditional LBG/ELBG cluster blocks are not snapped and clustered in fixed area's, they can traverse using single pixels or 4x4, 8x4 chunks in the source merging into specific area's of the 8x8 block codevectors.
• isokadded on the 2014-07-01 21:30:05
• demo Amiga OCS/ECS State of the Art by Spaceballs [web]
• Absolutely ruled at the time and still stands the test of time. This was probably the only demo I had ever seen at the time which put my jaw to the floor and inspired me to start coding and becoming interested in video based compression
• rulezadded on the 2014-07-01 18:39:28
• demo Commodore 64 Bad Apple 64
• Sam, the actual encoding was a multiple stage process with the first process taking the longest (due to using a very early 16x16 tile encoder). Overall took a few hours for all frames (although 90% of this was saving individual bitmaps generated from the encoder.. i know i know, too lazy to code multiple stream saving, but not lazy to save thousands of frames :-)
  
  F-cycles. I know, I should have just left it as it is, besides ignoring these type of creatures is better, but felt I should at least say something once and not say it again after I am all for drama :-) bring it on :-)
  
  Kabuto, yes, i saw the megadrive version very very nice and not many artifacts, but what may be ok for megadrive 8mb would be disastrous on stock c64 (would require nearly 20 c64 disks double sided) :-) and could not keep up with the data rate. Reu would be an option, but i am against non-stock hardware
• isokadded on the 2014-07-01 17:05:12
• demo Commodore 64 Bad Apple 64
• Hehehe. Nice to see people get angry
• isokadded on the 2014-07-01 01:18:56
• demo Commodore 64 Bad Apple 64
• Its actually slightly more different. there are 128000 cells in 128 frames (320x200) this is condensed to 256 8x8 cells, but furthermore to achieve even higher compression, there is a predefined 1k table lookup that has combinations of these 8x8 cells to form a large 16x16 pixel block (hence no total freedom on which cells can occur at any point on the screen (apart from the clustered 16x16 pixel cells) This gives an additional 4:1 compression rate on the lookup display (to 240 bytes - instead of 1000 bytes) - After delta (due to the extreme simplicity of the video data) this normally packs each frame to around 60-70 bytes or so (in combination with lz encode)
• isokadded on the 2014-07-01 00:53:29
• demo Commodore 64 Bad Apple 64
• Dude, did you pay for the demo? This is a c64 running the animation from a floppy with 170k of gfx data, not a pc or amiga streaming it from a harddrive. Anyway, enough ranting from me, small minded idiots who will never in their lifetime be able to code anything decent seem to behave this way... Write all you want, Just felt that I had to say something here just once to respond. You are the only one here that had given extremely negative remarks not taking in to accounts the limitations of the c64, while everyone else has praised this.. Wow, you must be some type of amazing coder :-) Go do something else non-scene wise with your small brain :-)
• isokadded on the 2014-06-30 23:31:27