This file is for demonstration of the error concealment when parsing
broken mp3 file where some mp3 frames got broken (i.e. bit damaged).

j.mp3 is minimalistic mp3 stream - constains 3 initial correct mp3
frames - then faulty zeroed frame is inserted and again 3 normal
mp3 frames are there.

Mp3 stream could be build from source_mp3_frames/ 

(i.e. cat source_mp3_frames/* >j.mp3)

dump/ contains result of current  pktdumper - as could be seen

original source:

9b76973f281729c3b341b054ca05a81a j0.bin
1c0a2ec79fa7ddeb3d98b4e8dae25684 j1.bin
d05b7ef061677de8a12c16b7930d4c63 j2.bin
90947e3479154523f3bdf3ea242538c8 j3_zero0.bin
80221e0c0fe06bf7c658b50f85d32392 j4.bin
8b106db5ccbf00738c300501a18d5368 j5.bin
81fe2e0840249253a7d11edbe8753441 j6.bin

pktdump results:

9b76973f281729c3b341b054ca05a81a j_00000000_00_0000000000_000480_K.bin
1c0a2ec79fa7ddeb3d98b4e8dae25684 j_00000001_00_0000002160_000480_K.bin
d05b7ef061677de8a12c16b7930d4c63 j_00000002_00_0000004320_000480_K.bin
81fe2e0840249253a7d11edbe8753441 j_00000003_00_0000006480_000480_K.bin

Packets j4.bin & j5.bin are missing - they got lost because
libavcodec/mpegaudio_parser.c around lines 130 requires new header
resynchronization - thus its loosing 2 correct mp3 frames here.

Another thing that should be noted is the difference in wav conversion.
Should ffmpeg -i j.mp3 j.wav   try to convert as much valid frames - or
just some some frames - or should it even try to keep the timeline of
the stream when broken data is found? (i.e. should it output silent
samples to fill error gaps) ?

So the question is how many frames should be in .wav.
Should we keep 4, 6 or 7 decoded mp3 frames ?