IPB

Welcome Guest ( Log In | Register )

Experimental release of Ghost/CELT 0.0.1
jmvalin
post Dec 9 2007, 11:53
Post #1


Xiph.org Speex developer


Group: Developer
Posts: 480
Joined: 21-August 02
Member No.: 3134



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.git

I'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!
Go to the top of the page
+Quote Post
 
Start new topic
Replies
radorn
post Dec 20 2007, 14:36
Post #2





Group: Members
Posts: 52
Joined: 12-May 04
Member No.: 14052



So this codec is not intended to eventually replace vorbis?

From what monty said here, I thought that was the case.

This post has been edited by radorn: Dec 20 2007, 14:42
Go to the top of the page
+Quote Post
jmvalin
post Dec 20 2007, 21:40
Post #3


Xiph.org Speex developer


Group: Developer
Posts: 480
Joined: 21-August 02
Member No.: 3134



QUOTE (radorn @ Dec 20 2007, 22:36) *
So this codec is not intended to eventually replace vorbis?

From what monty said here, I thought that was the case.


What I mean is that in its current form, there's no way it'll beat Vorbis. However, if you add sinusoidal coding and use CELT just to encode the noise, that's another matter. That's what Monty is currently hoping to do with Ghost. Whether we'll end up with one codec or two is still an open question. Even then, a codec that will replace Vorbis is still a long way off, so don't hold your breath.

For those interested, I've posted this overview of CELT along with some technical details on energy coding.
Go to the top of the page
+Quote Post
SebastianG
post Dec 21 2007, 20:51
Post #4





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (jmvalin @ Dec 20 2007, 21:40) *
For those interested, I've posted this overview of CELT along with some technical details on energy coding.


Nice!

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)?

Cheers!
SG
Go to the top of the page
+Quote Post
jmvalin
post Dec 22 2007, 03:57
Post #5


Xiph.org Speex developer


Group: Developer
Posts: 480
Joined: 21-August 02
Member No.: 3134



QUOTE (SebastianG @ Dec 22 2007, 04:51) *
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.


In the CELT context, the pulse codebook has the following properties:
  • Decent (though suboptimal) tesselation of the sphere
  • algebraic representation (no storage)
  • slight "bias" towards impulses (i.e. tonal signals)
  • Fast recursive search even for huge codebooks (one pulse at a time)

Of course, none of that is frozen, so I'm always open to other ideas. Did you have something in particular in mind?

QUOTE (SebastianG @ Dec 22 2007, 04:51) *
Regarding pitch prediction: Am I correct when I say what you do is pretty much the same thing as LTP (MPEG4)?


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.
Go to the top of the page
+Quote Post
SebastianG
post Dec 23 2007, 12:17
Post #6





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (jmvalin @ Dec 22 2007, 03:57) *
In the CELT context, the pulse codebook has the following properties:
(...)

Oh, okay. I almost forgot the "algebraic representation" thing. You're right, this is a big advantage.

QUOTE (jmvalin @ Dec 22 2007, 03:57) *
Of course, none of that is frozen, so I'm always open to other ideas. Did you have something in particular in mind?

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 because
  • En- and decoding is fast and doesn't require big tables either
  • It'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)
QUOTE (jmvalin @ Dec 22 2007, 03:57) *
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.

LTP is an MPEG4-AAC tool and is short for long term prediction. The decoder just remembers the past decoded samples. The encoder might signal that the following block looks similar to one that was xyz samples ago (aka "pitch period"). Then the decoder would do an (forward) MDCT on the block referenced by the "pitch period", apply frequency-adaptive prediction gains and subtract this from the current MDCT block's samples.

I'm not sure right now but I guess LTP can be coupled with LD-AAC (low delay, 480 samples/frame) which would then be very similar to your CELT except for the special pulse codebook.

Cheers!
SG

This post has been edited by SebastianG: Dec 23 2007, 12:24
Go to the top of the page
+Quote Post
jmvalin
post Dec 26 2007, 13:15
Post #7


Xiph.org Speex developer


Group: Developer
Posts: 480
Joined: 21-August 02
Member No.: 3134



Here's some information on the pitch predictor.
Go to the top of the page
+Quote Post
SebastianG
post Jan 2 2008, 18:01
Post #8





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (jmvalin @ Dec 26 2007, 13:15) *
Here's some information on the pitch predictor.


Thanks! Yup, it looks "LTPish".

Another thought that just struck me is: Did you check whether there's any gain in subsample delay accuracy? There's a slim chance that the probability distributions of the prediction gains for higher bands look different with subsample delay accuracy because of the higher phase error at higher frequencies.

subsample delay accuracy could be achieved by doing both, the MDCT (X[]) and an MDST (Y[]) on the referenced block (as kind of real and imaginary components) and predict the current k-th MDCT sample by
CODE
pred[k] = gain * real( (X[k] + Y[k]*i) * e^(ssd*(k+0.5)*2*pi*i) )

with
i = sqrt(-1)
0 <= k < n, k=current frequency index, n=number of transform coeffs
ssd = subsample_delay / n

The MDST code could reuse most of the MDCT code. Or one could write a dedicated MCLT (modulated complex lapped transform) which is really nothing more than both MDCT and MDST combined (but easier to compute together).

Some more stuff to digest is waiting in your EMail in-box smile.gif

Cheers!
SG
Go to the top of the page
+Quote Post

Posts in this topic
- jmvalin   Experimental release of Ghost/CELT 0.0.1   Dec 9 2007, 11:53
- - radorn   So this codec is not intended to eventually replac...   Dec 20 2007, 14:36
|- - Benjamin Lebsanft   QUOTE (radorn @ Dec 20 2007, 14:36) So th...   Dec 20 2007, 16:04
|- - jmvalin   QUOTE (radorn @ Dec 20 2007, 22:36) So th...   Dec 20 2007, 21:40
|- - SebastianG   QUOTE (jmvalin @ Dec 20 2007, 21:40) For ...   Dec 21 2007, 20:51
|- - jmvalin   QUOTE (SebastianG @ Dec 22 2007, 04:51) W...   Dec 22 2007, 03:57
|- - SebastianG   QUOTE (jmvalin @ Dec 22 2007, 03:57) In t...   Dec 23 2007, 12:17
|- - jmvalin   QUOTE (SebastianG @ Dec 23 2007, 20:17) N...   Dec 23 2007, 13:22
|- - jmvalin   Here's some information on the pitch predictor...   Dec 26 2007, 13:15
|- - SebastianG   QUOTE (jmvalin @ Dec 26 2007, 13:15) Here...   Jan 2 2008, 18:01
- - radorn   Sorry for the misunderstanding and thank you both ...   Dec 21 2007, 11:27
- - Kef   QUOTE (jmvalin @ Dec 9 2007, 12:53) I...   Jan 19 2008, 13:34
|- - jmvalin   QUOTE (Kef @ Jan 19 2008, 21:34) Now, I k...   Feb 3 2008, 11:57
|- - johnsonlam   QUOTE (jmvalin @ Feb 3 2008, 18:57) Keep ...   Feb 21 2008, 06:18
|- - jmvalin   QUOTE (johnsonlam @ Feb 21 2008, 14:18) A...   Feb 22 2008, 03:16
- - Nicos   I absolutetly agree with what u stated above Kef. ...   Jan 22 2008, 12:23
- - Brent   A sense of "progress" I suppose. Every n...   Feb 22 2008, 23:38
|- - jmvalin   QUOTE (Brent @ Feb 23 2008, 07:38) A sens...   Feb 24 2008, 10:53
- - Saoshyant   Xiph also made an announcement of everything that ...   Mar 6 2008, 03:16
- - Bourne   -   Mar 6 2008, 04:09
- - Saoshyant   The recent aoTuV tunings have not yet been merged ...   Mar 7 2008, 04:08


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th September 2014 - 09:05