User:Gmaxwell/celt - Revision history

Gmaxwell at 22:18, 14 July 2009

2009-07-14T22:18:56Z

← Older revision		Revision as of 22:18, 14 July 2009
Line 1:		Line 1:
	==~~Short term CELT TODO~~==		{\|width="70%"
			\|
			===Overview===

	~~===Updated version~~ with these ~~features===~~		The CELT codec is a compression algorithm for audio. Like MP3, Vorbis, and
	*Allocation out of bounds memory access patch (done: 3b34e188ede286d7a4ecc9fdf66831397a352cb3)		AAC it is suitable for transmitting music with high quality. Unlike these
	*Denorm fixes (done: de1fd28740a33930b661a64a0ca52bd7c32fa20e)		formats CELT imposes very little delay on the signal, even less than is
	*96kHz support (done: 179206a5ac6079470f53d2c231264aa40783e63f)		typical for speech centric formats like Speex, GSM, or G.729.
	*Merging of the ~~last band if it's 20% of the prior band size or smaller (not done yet)~~
	*Celtclient fixes (done: ae2fb591b89a8a5cc29fcb89fc53639ebfe84314)
	*Celtclient proper UI (easy, ~~but not done)~~
	*Celtclient selective building (screw you autotools; not done)
	*Activity interface (started: 06768a7fe7fb3368a00b03540cb9ec83f321005f)
	*Lowpass intelligence (not decided how this should work)
	**Lowpass as a function of sample rate?
	**Lowpass as a function of bytes/frame? Bitrate? Bitrate is problematic because the mode doesn't know the bitrate, ~~although I feel this would be best~~.
	*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)
	**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)
	*Fixes for torbenh's LF tone test case (done: 8256ed4cf745436f4c9b9cd5857917614193f22c)
	**Ability to allocate more bits to narrow bands? (more pulses? memory usage? some other approach?)
	*CELT_SET_USE_LTP function to disable the use of pitch regardless of the complexity (done: 98046cadcfc1160df434d97b0bdd40f3116f3161)
	*Fully tested

	==CELT ~~regular testplan==~~		Using CELT application developers can build software that allows musicians to
	*In both --fixed-point and floating point mode		perform together across the Internet, or simply build great sounding
	**Using a single very short test file:		telephony systems. Why shouldn't your telephone sound as good as your
	***testcelt in valgrind at frame sizes of 64,128,256, 512, ~~with all supported sample rates~~		stereo?
	**Using a collection of a 8 samples for PEAQ testing plus 8 torture samples:
	***testcelt in valgrind at 64,128,256, 512 at 32,44.~~1,48, and 96kHz, at 8,20,40,60,80,100,200 bytes/frame~~
	***Collect PEAQ results on PEAQ test samples (?)
	*PEAQ scan - Collection of 8 PEAQ test files (takes ~16 CPU days)
	**In both LC and normal mode at 48kHz PEAQ results for every framesize and byte/frame combination

	~~==Paranoia==~~		CELT is open and unencumbered technology from the Xiph.Org Foundation.
	~~Candidates for assert instrumentation:~~		\|}
	* enc_bits/enc_uint should range check their inputs

Gmaxwell: /* Updated version with these features */

2008-12-15T21:25:02Z

Updated version with these features

← Older revision		Revision as of 21:25, 15 December 2008
Line 15:		Line 15:
	*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)		*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)
	**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)		**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)
	*Fixes for torbenh's LF tone test case		*Fixes for torbenh's LF tone test case (done: 8256ed4cf745436f4c9b9cd5857917614193f22c)
	**Better approach for pulse placement approximation
	**One pulse placed at a time in high complexity mode
	**Ability to allocate more bits to narrow bands? (more pulses? memory usage? some other approach?)		**Ability to allocate more bits to narrow bands? (more pulses? memory usage? some other approach?)
	*CELT_SET_USE_LTP function to disable the use of pitch regardless of the complexity		*CELT_SET_USE_LTP function to disable the use of pitch regardless of the complexity (done: 98046cadcfc1160df434d97b0bdd40f3116f3161)
	*Fully tested		*Fully tested

Gmaxwell at 18:08, 4 December 2008

2008-12-04T18:08:11Z

← Older revision		Revision as of 18:08, 4 December 2008
Line 19:		Line 19:
	**One pulse placed at a time in high complexity mode		**One pulse placed at a time in high complexity mode
	**Ability to allocate more bits to narrow bands? (more pulses? memory usage? some other approach?)		**Ability to allocate more bits to narrow bands? (more pulses? memory usage? some other approach?)
			*CELT_SET_USE_LTP function to disable the use of pitch regardless of the complexity
	*Fully tested		*Fully tested

Gmaxwell at 18:04, 4 December 2008

2008-12-04T18:04:06Z

← Older revision		Revision as of 18:04, 4 December 2008
Line 15:		Line 15:
	*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)		*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)
	**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)		**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)
			*Fixes for torbenh's LF tone test case
			**Better approach for pulse placement approximation
			**One pulse placed at a time in high complexity mode
			**Ability to allocate more bits to narrow bands? (more pulses? memory usage? some other approach?)
	*Fully tested		*Fully tested

Gmaxwell: /* Updated version with these features */

2008-12-03T01:20:25Z

Updated version with these features

← Older revision		Revision as of 01:20, 3 December 2008
Line 12:		Line 12:
	*Lowpass intelligence (not decided how this should work)		*Lowpass intelligence (not decided how this should work)
	**Lowpass as a function of sample rate?		**Lowpass as a function of sample rate?
	**Lowpass as a function of bytes/frame? Bitrate?		**Lowpass as a function of bytes/frame? Bitrate? Bitrate is problematic because the mode doesn't know the bitrate, although I feel this would be best.
	*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)		*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)
	**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)		**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)
	*Fully tested		*Fully tested


	==CELT regular testplan==		==CELT regular testplan==

Gmaxwell at 01:14, 3 December 2008

2008-12-03T01:14:04Z

← Older revision		Revision as of 01:14, 3 December 2008
Line 13:		Line 13:
	**Lowpass as a function of sample rate?		**Lowpass as a function of sample rate?
	**Lowpass as a function of bytes/frame? Bitrate?		**Lowpass as a function of bytes/frame? Bitrate?
	*Merge of raw bits (~~I want to get this in before the next testing cycle~~)		*Merge of raw bits (done: 241b5f0c4506f4d01611c98f296a8c337c2f1f4c)
	**bit to uint changes for mode bits (~~easy;~~ done ~~before but lost~~)		**bit to uint changes for mode bits (done: 363be091b32324d4b552109b5c174d9b304e18d1)
	*Fully tested		*Fully tested

Line 27:		Line 27:
	*PEAQ scan - Collection of 8 PEAQ test files (takes ~16 CPU days)		*PEAQ scan - Collection of 8 PEAQ test files (takes ~16 CPU days)
	**In both LC and normal mode at 48kHz PEAQ results for every framesize and byte/frame combination		**In both LC and normal mode at 48kHz PEAQ results for every framesize and byte/frame combination

			==Paranoia==
			Candidates for assert instrumentation:
			* enc_bits/enc_uint should range check their inputs

Gmaxwell at 17:23, 2 December 2008

2008-12-02T17:23:24Z

New page

==Short term CELT TODO==

===Updated version with these features===
*Allocation out of bounds memory access patch (done: 3b34e188ede286d7a4ecc9fdf66831397a352cb3)
*Denorm fixes (done: de1fd28740a33930b661a64a0ca52bd7c32fa20e)
*96kHz support (done: 179206a5ac6079470f53d2c231264aa40783e63f)
*Merging of the last band if it's 20% of the prior band size or smaller (not done yet)
*Celtclient fixes (done: ae2fb591b89a8a5cc29fcb89fc53639ebfe84314)
*Celtclient proper UI (easy, but not done)
*Celtclient selective building (screw you autotools; not done)
*Activity interface (started: 06768a7fe7fb3368a00b03540cb9ec83f321005f)
*Lowpass intelligence (not decided how this should work)
**Lowpass as a function of sample rate?
**Lowpass as a function of bytes/frame? Bitrate?
*Merge of raw bits (I want to get this in before the next testing cycle)
**bit to uint changes for mode bits (easy; done before but lost)
*Fully tested

==CELT regular testplan==
*In both --fixed-point and floating point mode
**Using a single very short test file:
***testcelt in valgrind at frame sizes of 64,128,256, 512, with all supported sample rates
**Using a collection of a 8 samples for PEAQ testing plus 8 torture samples:
***testcelt in valgrind at 64,128,256, 512 at 32,44.1,48, and 96kHz, at 8,20,40,60,80,100,200 bytes/frame
***Collect PEAQ results on PEAQ test samples (?)
*PEAQ scan - Collection of 8 PEAQ test files (takes ~16 CPU days)
**In both LC and normal mode at 48kHz PEAQ results for every framesize and byte/frame combination