| 28kbs | ||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 59% |
|||||||
alltime top: #6770 |
|
|||||||
|
||||||||
added on the 2015-04-11 04:06:17 by algorithm  |
||||||||
popularity helper
comments
Don't really care for the video but the music quality is awesome!
youtube link here.. Warning, video quality suffers even more.. https://www.youtube.com/watch?v=02a07-nTm4k&feature=youtu.be
very interesting, but if you're able to do "unrestricted non-looping audio", why choose such repetitive style of music? ;) hey, you could have recorded a protracker module! or a c64 chiptune?
The audio encoder works well for any type of audio regardless of complexity, the track was chosen as I had previously test encoded the video (which took some time) and did not want it to gather dust :-)
Amazing.
Dragon's Lair could be redone with it :P
Dragon's Lair could be redone with it :P
algo rules
Ace!!!!! Moar!
:)
another nice tech demo from algorithm.
Technical Details? :D is it an evolution of audio-vq?
The audio in essence is a dictionary variant with adjustable amplitudes within the dictionary.
The main work is recreating the 4k sample table which is generated via iterations and genetic refinement.
From a 4k dictionary, its possible to gain 4088 8 byte unique sample data. combined with one of 16 ampitudes, this gives 15x4088+zero amplitude=61321 8 byte pieces that are used to recreate the audio.
For each 8 byte chunk, 12bits store the offset into the 4k dictionary and the other 4 bits store the amplitude. This way a fixed pack rate of 4:1 (in this example)
Ofcourse chunk sizes can be increased for higher pack rate along with increasing the 4k table to a larger amount.
Using the above variant. It beats ADPCM3 in quality in combination to overall being the equivalent of 2bits of data per byte.
There are many other variations possible as well including multiple mixing of offsets into a chunk as well as repeat/fill methods which increase the pack rate and keep similar quality.
Decode is very straightforward. convert the 12bit value to the offset into the table, then read each byte and lookup the desired byte from the amplitude table.
The main work is recreating the 4k sample table which is generated via iterations and genetic refinement.
From a 4k dictionary, its possible to gain 4088 8 byte unique sample data. combined with one of 16 ampitudes, this gives 15x4088+zero amplitude=61321 8 byte pieces that are used to recreate the audio.
For each 8 byte chunk, 12bits store the offset into the 4k dictionary and the other 4 bits store the amplitude. This way a fixed pack rate of 4:1 (in this example)
Ofcourse chunk sizes can be increased for higher pack rate along with increasing the 4k table to a larger amount.
Using the above variant. It beats ADPCM3 in quality in combination to overall being the equivalent of 2bits of data per byte.
There are many other variations possible as well including multiple mixing of offsets into a chunk as well as repeat/fill methods which increase the pack rate and keep similar quality.
Decode is very straightforward. convert the 12bit value to the offset into the table, then read each byte and lookup the desired byte from the amplitude table.
Briliant!!!
Algo pushing the boundaries.
Great!
Great stuff!
Here's the original video btw: Masoud feat. Aneym - No More :)
Here's the original video btw: Masoud feat. Aneym - No More :)
Clearly, there is no limit to Amiga limitations.
nice
Yes, this is awesome !
Impressive.
love the idea, but wish the video has more movement into it.
Awesome as always
Very nice as always. But I have some questions:
Wouldn't it be better quality to just generate a 64K codebook, instead of a 4K codebook * 16 permutations?
Quote:
From a 4k dictionary, its possible to gain 4088 8 byte unique sample data. combined with one of 16 ampitudes, this gives 15x4088+zero amplitude=61321 8 byte pieces that are used to recreate the audio.
Wouldn't it be better quality to just generate a 64K codebook, instead of a 4K codebook * 16 permutations?
Trixter. Yes it would be better. However there was not enough disk space left :-). However I did underestimate the decode speed and could have used more efficient final packing of each 256 frame chunk to fit the 64k code book. In the current implementation, it manages to load and semi depack a 256 frame chunk in around 3 seconds. (Where it has around 20 seconds or so till the next section :-) also ram usage is 4k instead of 64k. But that could have been resolved by only using dual stream buffer instead of quad.
very very geil
@Algorithm : makes my dream come true, I Would like "Bad Apple 4 Amiga" PLEASEEEE ;)
Very good job
Very good job
Haha.. crazy.... :D
Impressive tech demo (at least for a layman with no in-depth knowledge of such compression), terribly cheesy music though :)
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 has been tested on other configurations as well (using Winuae) from 68000 to 68040 AGA - Let me know if there are any bugs on other configs on the real thing.
The data rate in the demo is the equivalant of a 28kbs stream (3.5k a second). The audio is at 2.5k per second stereo while the video is running at over 12 frames per second using 1k per second.
The main magic comes from my pc based video and audio encoders that utilise some state of the art genetic algorithms and meta-heuristics to generate the data.
The video leaves a lot to be desired, treat this more as a swirling motion effect with emphasis towards audio quality instead.
The demo for flashback was complete two months before schedule and due for release in June 2015. I was rather bored the last couple of days, hence decided to put this quick audio/video stream demonstration together.