ILBC decompression

So, what you're saying is, you want to do some pre-process (which you're calling "inflate") before the audio goes to ILBC (which is "Internet Low Bitrate Codec") so that at the other end (presumably after some other process) you get back the original audio.

Even without knowing the specifics of iLBC I'm almost certian that this is impossible.

Quote:

Original post by Andrew Russell So, what you're saying is, you want to do some pre-process (which you're calling "inflate") before the audio goes to ILBC (which is "Internet Low Bitrate Codec") so that at the other end (presumably after some other process) you get back the original audio.

Exactly [smile]

Quote:

Original post by Andrew Russell Even without knowing the specifics of iLBC I'm almost certian that this is impossible.

why?

I wonder if it could work if one would "inflate" the audio stream by slowing it down. If it is compressed to N bits/second, and you would slow it down by half, you'd have 2N bits/second as a result... kinda.

Of course this makes it rather unusable, but could it work in theory?

Quote:

Original post by Mobster why?

OK, the given example is "slowing it down". I'll run with this one, because it's simple to explain.

So, we slow the audio stream right down, say to 10%*. Now, assume that our slow audio stream will now come through unscathed (not that it necessaraly will).

Now the problem you immediatly run into is that the audio can't be sent live, because 1 second of audio data will now take 10 seconds to download.

So, assume for a moment that iLBC will let you "speed up" transmission, so that it reads data at 10 times the rate, transmits it at 10 times the rate, and replays it at 10 times the rate. I think the problem with this is obvious - it now takes up 10 times the network bandwidth.

So it essentially comes down to a problem of compression ratios. How small can you get it to push it across the network. Now the thing is - if preprocessing audio and running it through iLBC were a good way to compress it, that is what everyone would be doing. But this is obviously not the case. FLAC is a common and popular lossless format that achieves a compression of about 53%. So essentially the question is - is your network pipe fat enough to push the live audio data at that compression ratio? If not, you'll have to use lossy compression (or not do it live).

* Note that in the real world, you might have to slow down much, much more than 10%. You'd probably have to do something more than a simple slow-down, but it would still make the length of audio much longer.

Then the problem is that even though the bytes can be transffered correctly, the guy on the other side will hear something really twisted which he won't be able to understand?

No, the original problem is that you only have received so much information from the initial microphone -- you can't "inflate" it to add quality prior to being compressed.

It's like trying to prepare an image to go through a JPEG compressor, then making sure that you can decompress it back so you have a perfect original image -- JPEG is by nature a lossy compression format, and so is ILBC's compression routines, according to what you've said.

If you're wanting to send lossless audio, why use something like ILBC, which is lossy? Why not send the audio yourself?

And do you *really* need it lossless? MP3 / OGG is lossy, and the quality is generally very good.

If you have 4 minutes of audio at 44,100Hz, Stereo (CD quality), that'll be 88200 bytes / second (~86KB/sec). That'll require a pretty good internet connection to actually use at that. Even if you compress it with FLAC, that's still about 47KB/sec.
If you were to use MP3 or OGG, we'll assume that the filesize is 6MB (Which is pretty huge for 4 minutes of audio). That's only 21KB/sec, which is still pretty high, but much more feasable for streaming over an Internet connection.

If you're streaming over a network, then you don't even need it compressed (Although you still probably should). Most networks can cope with 100Mb/sec.

Mobster: No.

It essentially comes down to network bandwidth. iLBC is good for really, really compressing audio into a tiny file size. But it's very lossy too.

If you try and get around the lossy-ness, the only way to do it is to make the file larger. Hacking your way around iLBC to get lossless audio will probably leave you with a file even bigger than what you started with. And certianly larger than what you could get with dedicated lossless audio compression codecs (like FLAC).

thanks everybody :)