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.
* Nick Lamb (njl98r@ecs.soton.ac.uk) wrote:> 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?I know I'm not the Josh you were addressing, but I can't reproduce this problem, using 1.0.2 on Debian: point 0: sample_number=0, stream_offset=0, frame_samples=4608 point 1: sample_number=41472, stream_offset=89899, frame_samples=4608 point 2: sample_number=82944, stream_offset=176858, frame_samples=4608 This may be a silly question, but you're not piping the decoder output, are you? Joshua -- Joshua Haberman <joshua@haberman.com>
Are you sure it's not your compiler? That's the first thing I would check. I know that RedHat is famous for including broken pre-releases of GCC in their distributions since 7.0. I'd try recompiling with GCC 3 or GCC 2.95 (available as "kgcc"). -- Asheesh. On Sat, 16 Mar 2002, Nick Lamb wrote:> 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. > > _______________________________________________ > Flac-dev mailing list > Flac-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flac-dev > >-- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3