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

[Michael Niedermayer]

On Fri, Oct 28, 2011 at 12:08:31AM +0200, Reimar Döffinger wrote:
> 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

well, iam a bit undecided, reverting isnt really solving anything
except that with 16bit output its easier to play around with it.


> (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.

I noticed that too, also it should be relatively easy to figure out how
it works if we could inject some test data into the official
decoder. That is if someone has the game and someone has time and
interrest in reverse engeneering this.

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20111028/6450eba4/attachment.asc>