On 09/07/2010 03:21 AM, Marcelo Galvão Póvoa wrote:
Hello,
On 6 September 2010 10:13, Ronald S. Bultje<[email protected]> wrote:
Hi,
On Mon, Sep 6, 2010 at 5:54 AM, Vitor Sessak<[email protected]> wrote:
On 09/06/2010 02:46 AM, Marcelo Galvão Póvoa wrote:
Ok, fortunately I've found the bug!
It was just a MIN_ISF_SPACING parameter which I extracted from the
reference code but was unsure about it's Q level. After some time, I
thought I have it figured out but I was wrong. Now I know the answer
the hard way...
The clipping and the sharp peaks are gone, the waveforms are really
close now!
That's great news!
Also, the stddev against the reference decoder decreased a
lot (it was ~884 before):
all_men.awb stddev: 51.72 PSNR: 62.05 MAXDIFF: 1089 bytes: 473600/
473600
stddev of 51 looks pretty good to me for this case.
Maxdiff of 1089 looks like a lot to me, with a low stddev that
suggests that one particular part is off. Can you trace which part is
off and why (phase shift vs. actual bug)?
Sorry, but can you suggest a way of doing it?
Your method of inverting one sample and summing in audacity would work
on showing where it is happening (some point will have an amplitude of
1089). To know if is a phase shift or a bug, you will have to compare
visually both waves.
Also, what do MAXDIFF
and the "2" at the end of the command line mean?
MAXDIFF is the biggest difference among two samples. The "2" at the end
of the command line says to read two-byte integers (16-bit). If you were
comparing video pixels, you would use "1". You can also see the source
of tiny_psnr.c, it is pretty simple.
This sample have long silence parts and I'm comparing my floating
point implementation to the reference 16-bit fixed point. How close
you think they should be?
A very small stddev (< 1.00) would assure there is no bug in your
decoder, but the fact that it is large does not means there is one.
I suggest you do the following test:
a) Get a biggish file (> 30 minutes)
b) Convert it to the a WAV with the sample rate and number of channel
the AMR encoder takes as input
c) Encode the file obtained in (b) it with the reference encoder
d) Decode the file obtained in (c) with the reference decoder
e) Decode the file obtained in (c) with ffamrwb
f) Compare the stddev of files obtained in (b) and (d) with that of (b)
and (e). If file decoded with ffamr are as close to the original as that
decoded with the reference decoder, it's good.
-Vitor
_______________________________________________
FFmpeg-soc mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
