Hi
Yes, I have something in mind that checks how much better a search like
this would perform. The primary motivation would be sanity checking. It
is also useful when computing new codebooks - AQ codebook computation
seems like an open area of research, and fast encoding is a key part.
A build option for whether to generate the table could easily be added.
Another option is to compute it either when the library is loaded or in
the first call to codec2_create().
It's also possible to decompose the xx_half table
0.5*<x1+x2,x1+x2> = 0.5*<x1,x1> + <x1,x2> + 0.5*<x2,x2>
where 0.5*<x1,x1> and 0.5*<x2,x2> are 2 KiB each. But then you have to
compute a dot product in the inner loop, which is likely too slow for an
exhaustive search. But still faster than a square Euclidean distance
computation, so useful in a beam search on an embedded device. So even
if quality doesn't improve, CPU use will go down.
/Tomas
On 2018-02-16 09:21, David Rowe wrote:
Hi Tomas,
The mbest algorithm searches the first codebook, stores the top 5 (or
so) candidates, then using each of those 5 candidates searches the
second stage, etc ...
It's an approximation of an exhaustive search.
VQ searching is an interesting area of study, so feel free to
experiment with other search methods. You could use an exhaustive
search as a control for any new techniques, measured say in terms of
MSE against the target across a test database.
However I suspect the real quality gains are elsewhere, i.e. even a
perfect VQ search won't make 700C sound _much_ better. I've been
prototyping a 2D VQ search metric that I hope is closer to a
perceptual match, can tell you more if you're interested.
One comment - 1Mbyte of pre-computed values is significant for an
embedded platform (the STM32F4 has 512 kbytes of flash total), but not
really for a PC. However I'd be interested to see (and hear) the
quality improvements of a better MSE search.
Cheers,
David
On 14/02/18 23:54, Tomas Härdin wrote:
Hi
I was poking inside the 700 bit/s code a few days ago and ran across
the mbest quantization code. It struck me as suboptimal, not even a
full beam search as far as I'm able to tell. codebook1 is searched
first, then codebook2, rather than both in parallel.
It turns out that the style of quantization the 700 modes use is
called Additive Quantization in the literature. There are ways to
speeding up such encoders, see [1].
I have attached a sketch of how we could implement this for the 700
modes, which use D=20, M=2, K=512. Because the search ends up just
being one table lookup and two subtractions per combination of n1 and
n2, I think we might be able to go with an exhaustive search. A
middle ground could be a wider beam search, possibly tuneable.
I'll likely give this a proper go once I've pushed the codec2 wrapper
into FFmpeg, this Sunday.
Thoughts?
/Tomas SA2TMS
[1]
https://www.cv-foundation.org/openaccess/content_cvpr_2014/papers/Babenko_Additive_Quantization_for_2014_CVPR_paper.pdf
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
