Does anybody have any possible ideas?
You can also try to add more payload and/or make it more robust using forward error coding, the other thing is that the type of compromise that you can make and the type of audio that you want to compress have a lot of influence in what you can use and in some situations even Codec 2 at 700bps can be an option. Also try to view some things about digital modulation for radio communications as it have a lot of things in commom of what you want to do.
Quote from: OrthographicCube on 20 September, 2017, 04:11:25 AMDoes anybody have any possible ideas?Here's one: make, say, an Android application that can "scan" your image/sound files (from a display, or printed) and automagically plays them. Kind of like QR-codes, but not for text/links - for audio!
Thank you very much for your reply.As of now, lossless encoding mode (to store any file assuming it isn't too big) uses 8 bits every 1016 bits to store the checksum (custom algorithm) for those bits, and will report any mismatch.For lossy audio encoding, I have discovered something.Opus has gotten good enough, that encoding a 16kbps Opus whole song into a lossless mode image will have a size that does NOT exceed Facebook's limitation, while sounding a wee bit better than mono 16KHz images. The problem is, the resulting image will not be incremental.The default lossy mode image allows having 1 image for mono audio and having the other image to form an image pair will let you hear stereo audio. Unfortunately, I don't see a way to spread the audio into 2 images without cutting the Opus in half. Also, for every row in the image, 8 bits (8 pixels) are used to set the "ADPCM jump parameter" thingy (I don't know how to call it LOL ) which gives the codec its "Adaptive" quality and improves audio quality, making it acceptable even if there are quiet and very loud parts in the song.My goal is to store 32KHz sampling rate stereo audio in up to 4 images, while keeping the images incremental.Still thinking of ways to achieve this