"invalidframe-then-buzz.ac3" illustrates a problem in ac3 decoding in ffmpeg
SVN-r15735 when the AC3 CRC is equal to the syncword. The file is stereo at 192
kbps and consists of 25 AC3 syncframes.

$ ffmpeg -i invalidframe-then-buzz.ac3 ffmpeg-out.wav FFmpeg version SVN-r15735, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --enable-postproc --enable-libfaac --enable-libx264 --enable-pthreads --enable-pthreads --enable-gpl --enable-libfaad --extra-libs=-L/usr/local/lib --enable-libmp3lame
  libavutil     49.12. 0 / 49.12. 0
  libavcodec    52. 1. 0 / 52. 1. 0
  libavformat   52.23. 1 / 52.23. 1
  libavdevice   52. 1. 0 / 52. 1. 0
  libpostproc   51. 2. 0 / 51. 2. 0
  built on Oct 28 2008 15:04:35, gcc: 4.1.2 20071124 (Red Hat 4.1.2-42) Input #0, ac3, from 'invalidframe-then-buzz.ac3':
  Duration: 00:00:00.80, bitrate: 192 kb/s
    Stream #0.0: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s Output #0, wav, to 'ffmpeg-out.wav':
    Stream #0.0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
[ac3 @ 0x9b44420]incomplete frame
[ac3 @ 0x9b44420]invalid frame size
[ac3 @ 0x9b44420]incomplete frame
[ac3 @ 0x9b44420]invalid frame size
size=     156kB time=0.83 bitrate=1536.4kbits/s
video:0kB audio:156kB global headers:0kB muxing overhead 0.027544%

It decodes without errors in a52dec: (which doesn't prove anything by
itself)

$ a52dec invalidframe-then-buzz.ac3 -o wav > a52dec-out.wav
a52dec-0.7.4 - by Michel Lespinasse <walken@zoy.org> and Aaron Holtzman No accelerated IMDCT transform found

25 frames decoded in 0.00 seconds (0.00 fps)

Comparing the output files:

$ ls -l *.wav
-rw-rw-r-- 1 philr philr 153644 Oct 28 15:06 a52dec-out.wav
-rw-rw-r-- 1 philr philr 159788 Oct 28 15:05 ffmpeg-out.wav

a52dec-out.wav has the expected size of 25*1536*4+44 bytes, but ffmpeg-out.wav is 1536*4 bytes larger.

Listening to the two files, there is a brief buzzing at the very beginning of
ffmpeg-out.wav which is not present in a52dec-out.wav.
There are no glitches audible in a52dec-out.wav, and looking at the waveform in
audacity leads me to believe that there isn't a blanked frame either.

Having investigated further, this appears to happen when the AC3 header CRC mimics the syncword. I poked around in libavcodec/ac3_parser.c a bit and added this instrumentation:

    err = ff_ac3_parse_header(&gbc, &hdr);

    if(err < 0) {
+       av_log(NULL, AV_LOG_DEBUG, "ff_ac3_parse_header: %d
[%016"PRIx64"]\n", err, state);	    
        return 0;
    }

    hdr_info->sample_rate = hdr.sample_rate;
    hdr_info->bit_rate = hdr.bit_rate;
    hdr_info->channels = hdr.channels;
    hdr_info->samples = AC3_FRAME_SIZE;

    *need_next_header = (hdr.frame_type != EAC3_FRAME_TYPE_AC3_CONVERT);
    *new_frame_start  = (hdr.frame_type != EAC3_FRAME_TYPE_DEPENDENT);

+   av_log(NULL, AV_LOG_DEBUG, "AC3 packet size: %d\n", hdr.frame_size);
    return hdr.frame_size;


This results in the following output when decoding
invalidframe-then-buzz.ac3:

ff_ac3_parse_header: -1 [000000000000000b]
ff_ac3_parse_header: -1 [0000000000000b77]
ff_ac3_parse_header: -1 [00000000000b770b]
ff_ac3_parse_header: -1 [000000000b770b77]
ff_ac3_parse_header: -1 [0000000b770b7714]
ff_ac3_parse_header: -1 [00000b770b771440]
AC3 packet size: 768
ff_ac3_parse_header: -1 [0b770b771440530b]
AC3 packet size: 698
ff_ac3_parse_header: -1 [0b771440530b7727]
ff_ac3_parse_header: -1 [771440530b772784]
ff_ac3_parse_header: -1 [1440530b77278449]
ff_ac3_parse_header: -1 [40530b772784499a]
ff_ac3_parse_header: -2 [530b772784499a87]


The first packet size reported is correct. The second appears to be the result of misinterpreting the CRC as a syncword. I don't yet understand why ac3_sync is being called after identifying the packet size.