[Flac-dev] Serious bug in FLAC

[Nick Lamb]

As far as I can tell I've found a serious bug in the command line
flac encoder :(

I have created many hundreds of flac files and I was very annoyed to
discover that the XMMS flac plug-in had intolerably long seek times,
but since that had been mentioned on this list a bunch of times
without anyone actually investigating, I thought I had better actually
find the BUG which causes this.

1. I found that this isn't a bug in XMMS or the plug-in, affected
files will seek VERY slowly in any software that sues libFLAC

2. I found that libFLAC was always painfully seeking from the start

3. I found that it did this because it always concluded that the
sample needed was in the first block at the front of the file.

4. I found that the SEEKTABLE for my .flac looks like this:

sample_number: 0 stream_offset: 0 frame_samples: 0
sample_number: 110592 stream_offset: 0 frame_samples: 0
sample_number: 221184 stream_offset: 0 frame_samples: 0
sample_number: 331776 stream_offset: 0 frame_samples: 0
sample_number: 442368 stream_offset: 0 frame_samples: 0
sample_number: 552960 stream_offset: 0 frame_samples: 0
sample_number: 663552 stream_offset: 0 frame_samples: 0
sample_number: 778752 stream_offset: 0 frame_samples: 0

etc.

5. I found that the command line app "flac" causes this by never
actually writing the seektable data. It writes an empty seektable
and then never fills it in. I tested with flac 1.0.2 on Red Hat
Linux 7.2 with various ordinary upgrades. This has been broken for
many months AFAICT.

Does it only do this for me? Josh, can you reproduce this? Because I
think this is a pretty serious bug, even if it only happens to a few
people it's still going to require a big rethink and a new release.

Nick.