So this codec is not intended to eventually replace vorbis?From what monty said here, I thought that was the case.
For those interested, I've posted this overview of CELT along with some technical details on energy coding.
What's the rationale behind "pulse code books"? I read Timothy's pulse coding web site and I'm not sure of what he's trying to do. Is it an attempt to uniformly tesselate the unit sphere or only a code book specialized tor "pulsy" signals? Judjung by the way it is used in CELT I'd say it's the former -- which is weird because at first glance the formulas don't look like the resulting codebooks do tesselate the unit sphere well. It might be me as I'm not familiar with those kind of specialized vector code books.
Regarding pitch prediction: Am I correct when I say what you do is pretty much the same thing as LTP (MPEG4)?
In the CELT context, the pulse codebook has the following properties:(...)
Of course, none of that is frozen, so I'm always open to other ideas. Did you have something in particular in mind?
I'm not aware of any other codec doing things like I'm doing, but then again, I've no idea what this mpeg4 LTP is or does. Can you give some details about that codec? BTW, the next part on CELT will be on the pitch prediction.
No, sorry. None that fits the strict gain/shape separation you are striving for. But there is something that I always wanted to see tested: A combination of trellis-coded quantization with subtractive dithering. "Subtractive dithering" is achieved by a randomized trellis graph using the same pseudo random number generator within both, the encoder and decoder. I believe it's worth a try becauseEn- and decoding is fast and doesn't require big tables eitherIt's possible to fade seamlessly between PNS (perceptual noise substitution) and high rate coding.No odd (ie metallic sounding) artefacts besides white noise even on large MDCT blocks (dithering is "the right thing to do"^TM which unfortunately got lost on the way to the lossy coding world -- until now -- *hint hint*) ;-)it should be possible to keep the quantized signal's energy close to the original's even at very low rates (thanks to subtractive dithering and adaptive rate-distortion optimization)
Here's some information on the pitch predictor.
pred[k] = gain * real( (X[k] + Y[k]*i) * e^(ssd*(k+0.5)*2*pi*i) )
I've just made the first public release of some new *experimental* codec work I've been doing (part of the vague Ghost project) with help from Monty and Timothy. This is mainly intended for developers with DSP knowledge, not for doing anything useful with it (but it does encode and decode already). Also, the main idea is *not* to replace either Speex or Vorbis, but to code audio with really low latency -- currently 8 ms.This is still very experimental and everything is still likely to change, including the exact goals. The algorithm is called (temporary name) Code-Excited Lapped Transform (CELT) and the main ideas are:- Using an MDCT on very short frames- Dividing into 15 bands and transmitting the energy for each band- Using a pitch predictor (good for speech, but helps for music as well).- The rest is coded using a unit-pulse codebook.At this point, I'm still trying to figure out how to fit psychoacoustics into this.CELT is based on a paper I submitted to ICASSP and which I'm hoping will be accepted so I can make it available to everyone. The only difference is that the ICASSP paper was based on the FFT (non critically sampled), whereas this version is based on the MDCT. One part that is already published though is Tim's explanation of the pulse codebook encoding.The full source for CELT is available at: http://downloads.us.xiph.org/releases/celt/celt-0.0.1.tar.gz or through git at http://git.xiph.org/celt.gitI've put some music samples at 56 kbps CBR at http://people.xiph.org/~jm/comp_celt58cbr.wav with the original at http://people.xiph.org/~jm/comp44.wav . As you can hear, it definitely doesn't suck as much as Speex on music, but there's still room for improvement.I'm open to interesting ideas, but don't bother complaining if it doesn't work or if it explodes in your face :-) Oh, and don't expect a final codec any time soon.Have fun!
Now, I know this is not your "thing" or your responsibility but what about Vorbis and Theora? There's been very little activity on both fronts and as user and proponent of open source applications, I am deeply concerned to say at least. Vorbis is a great codec and my music collection is > 50% Vorbis right now (and the rest mp3) but the lack of activity, except the tunings of Ayomi, makes it very difficult to continue using it. It's like Vorbis has been completely abandoned by xiph and I believe this is one of the reasons why people start to look for alternatives. I think this is at least one of the reasons why the Vorbis usage has dropped significantly the last two years here at HA.http://www.hydrogenaudio.org/forums/index....showtopic=60145http://img406.imageshack.us/my.php?image=lossydi7.png
Keep in mind that it's not because you don't see anything that we're not doing anything. That being said, we do have a "resource" problem. All of us have day jobs, little of which involves Xiph codecs.
All we can do is waiting patiently, hopefully a few lines of text one or twice a month can ease the pain of the people waiting endlessly.
A sense of "progress" I suppose. Every now and then there's a new Nero AAC release or a new Lame, but from the Xiph codecs there's rarely official news. Although it's a fully OS codec, development aparently isn't that open to us mere fanboys/users.