[FFmpeg-cvslog] pcm_zork: use AV_SAMPLE_FMT_U8 instead of shifting all samples by 8.

[Reimar Döffinger]

On Thu, Oct 27, 2011 at 01:55:50PM +0200, Michael Niedermayer wrote:
> On Thu, Oct 27, 2011 at 09:32:06AM +0200, Reimar Döffinger wrote:
> > 
> > 
> > On 27 Oct 2011, at 01:46, git at videolan.org (Justin Ruggles) wrote:
> > 
> > > ffmpeg | branch: master | Justin Ruggles <justin.ruggles at gmail.com> | Wed Sep 28 19:31:05 2011 -0400| [67a3b67c717e4e53b9217ec1d579f2dff5e46717] | committer: Justin Ruggles
> > > 
> > > pcm_zork: use AV_SAMPLE_FMT_U8 instead of shifting all samples by 8.
> > > 
> > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=67a3b67c717e4e53b9217ec1d579f2dff5e46717
> > > ---
> > > 
> > > libavcodec/pcm.c |   22 +++++++++++-----------
> > > 1 files changed, 11 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/libavcodec/pcm.c b/libavcodec/pcm.c
> > > index e7cf874..ec2660c 100644
> > > --- a/libavcodec/pcm.c
> > > +++ b/libavcodec/pcm.c
> > > @@ -172,10 +172,11 @@ static int pcm_encode_frame(AVCodecContext *avctx,
> > >         dst += n*sample_size;
> > >         break;
> > >     case CODEC_ID_PCM_ZORK:
> > > -        for(;n>0;n--) {
> > > -            v= *samples++ >> 8;
> > > -            if(v<0)   v = -v;
> > > -            else      v+= 128;
> > > +        srcu8 = data;
> > > +        for (; n > 0; n--) {
> > > +            v = *srcu8++;
> > > +            if (v < 128)
> > > +                v = 128 - v;
> > 
> > That can't be right, now an input value of both 0 and 128 give a result of 128.
> > A encode-decode cycle via fate should show such issues quite obviously (at least for 8-bit data where input and final output should match).
> 
> zork might be a (A)DPCM variant with 16bit output, we sadly have just
> one lossy (mp3 based) reference sample (thanks to justin for that btw)
> for how it is supposed to sound which makes reverse engeneering a bit
> hard.
> 
> If there are no objections then ill revert these commits as i dont
> think they are a step toward getting zork working

No idea, I was at least wrong the change did not change the output
(except for 8-bit vs. 16-bit).
However I'd like to point out that the codec shares a tag with
the (4-bit) IMA ADPCM codec, so it is very likely it is ADPCM,
the fact that the byte format is also in the sign-residual form
also speaks for that.
However there definitely differences: block align is 0x400, but it's
not possible to see any block patters, so there are probably no special
raw predictors.
The very end of the sample file is also suspicious, it contains mostly
values of the form 0x?F, 0x00 and a few 0x?7.
In general the histogram is very odd (I don't know a good program for
visualizing this though), you could say the fewer of the lowest bits are
set the rarer the value is, though the more reasonable "the larger the
value (ignoring the sign) the rarer it is" still applies.
The AVI file also contains "Compressed with Adobe Premiere 4.2", but I
guess that went through some not generally available audio filters...