[FFmpeg-devel] Review request - ra288.{c,h} ra144.{c,h}

[Vitor Sessak]

Siarhei Siamashka wrote:
> On Tuesday 16 September 2008, Vitor Sessak wrote:
>> Michael Niedermayer wrote:
> [...]
>>>>>>> how has the .ra file been generated?
>>>>>>> what happens with a 2x as long input file? does the size difference
>>>>>>> stay constant or grow?
>>>>>>>
>>>>>>> what does the binary decoder produce for it? is that also too big?
>>>>>> Original     wav:  967706 bytes
>>>>>> FFmpeg   decoder:  990764 bytes
>>>>>> Original decoder: 1013804 bytes
>>>>>>
>>>>>> Go figure...
>>>>> the decoder outputs 3 seconds more than what is in the claimed
>>>>> original. How does it sound? is the audio stretched to the bigger
>>>>> length are there 3 seconds of distortion or silence somewhere?
>>>> Original     wav:  967706 bytes
>>>> FFmpeg   decoder:  990764 bytes   1 second  of silence in the end
>>>> Original decoder: 1013804 bytes   3 seconds of silence in the end
>>>>
>>>> Anyway, nothing of that explains the PSNR discrepancy...
>>> ok, so lets forget about the PSNR, and rather try a simpler test for
>>> the accuracy, just try to cast a float to an int and try lrintf()
>>> and print the differens, or sum or squared differences, it should be
>>> obvious which is more accurate.
>> The problem is not just when using PSNR, but I also fail to see any
>> similarity between the two files in a hex editor. I'd say that it is
>> very unlikely that using lrintf() would worsen the quality (and even if
>> it does, such a small change would be completely inaudible in such a low
>> quality codec). So I'd change to lrintf() and put a comment explaining
>> the situation. Are you fine with this?
> 
> This is getting quite interesting. Could you upload original wav file and
> encoded->decoded ones somewhere (maybe loslessly compressed)?

Sure:

http://samples.mplayerhq.hu/real/AC-28_8/luckynightmono2.ra
http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.flac

$ ffmpeg -i luckynightmono2.ra decoded.wav
$ ffmpeg -i luckynight.flac -ac 1 -ar 8000 original.wav

> Did the updated tiny_psnr that I sent before detect any shift or it failed
> completely?

$ tiny_psnr  decoded.wav original.wav 96 - 44
shift autodetection...
done, detected as 78
trying to confirm shift... failed (detected as 878)

$ tiny_psnr  decoded.wav original.wav 2 96 44
stddev: 6039.35 PSNR: 20.70 bytes:   990624/   967666

$ tiny_psnr  decoded.wav original.wav 2 0 44
stddev: 5994.93 PSNR: 20.76 bytes:   990720/   967666

> You can try experimenting with compression of a simple signal, something like
> sine and check if you can see similarities in the input and output files. And
> then change this signal to something more complicated until the differences
> start getting more visible.

I'm not sure that it is worth the trouble just to decide on using 
lrintf() or not...

-Vitor