[Ffmpeg-devel] [PATCH] Shift autodetection for tiny_psnr.c

[Michael Niedermayer]

Hi

On Sat, Oct 07, 2006 at 04:16:54PM +0300, Siarhei Siamashka wrote:
[...]
> > > What I'm having troubles now with is shift value. I tried to encode
> > > some wav file ripped from CD with lame and decode it with different
> > > decoders (using mplayer, -ac mad, -ac ffmp3, -ac mp3). They all are
> > > quite similar to each other (according to tiny_psnr stats), but have a
> > > major difference from the original file, probably because of shift.
> >
> > And the reason that mp3 throws away lots of information from the audio.
> > IMHO a sse metric is useless for this, atleast over the whole file. Use
> > a "good" mp3 decoder and use that file as reference.
> 
> Yes, as I see now, even 320kbps mp3 file has a relatively large difference
> from original according to sse metric. Maybe different psychoaccustics 
> tricks could affect that? They could be good for human ear but bad for sse.

yes


> 
> > > And I have difficulties with figuring this shift out. I'll try to make
> > > an automatic shift detection patch for tiny_psnr.c to solve this
> > > problem.
> >
> > You can use Octave and it's xcorr function to figure out the shift.
> 
> Well, don't know what this Octave thing is (links are always welcome), but a
> simple patch for automatic shift autodetection is attached. It works only for
> shifts +-16384 and is quite slow, but probably could be useful nevertheless.
> At least I use it in my mp3 decoding quality experiments now :)

does the shift detection have an anything in common with tiny_psnr.c?
if no it should either br changes to reuse the comparission code or
be a seperate tool (detect_shift.c or so maybe)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is